Skip to content

CloudWatch

Cut CloudWatch costs 50-80%. Analyze spend, prevent over-billing, optimize events, and stream from S3 -- works with CloudWatch Logs across ECS, EKS, EC2, and Lambda.

Compatibility

Does Log10x work with CloudWatch Agent

Yes. CloudWatch Agent is built on the OpenTelemetry Collector -- Log10x connects to it natively via syslog exporter, no agent swap needed.

Cloud Reporter and Storage Streamer are agentless -- they work via CloudWatch API and S3 regardless of your forwarder. Also supported: Fluent Bit, Fluentd, Filebeat, and Logstash.

How does Log10x integrate with AWS CloudWatch

Log10x integrates at the forwarder level before logs reach CloudWatch.

Supported forwarders: Fluent Bit, Fluentd, Filebeat, Logstash, OpenTelemetry Collector, and Splunk Universal Forwarder.

It analyzes and optimizes log streams in real-time, reducing ingestion volume while preserving all valuable data. No changes to your application code, SDKs, or CloudWatch configuration required.

Will my existing CloudWatch Logs Insights queries still work

Yes. The 10x Engine operates pre-ingestion -- events that pass through arrive in standard CloudWatch format. Logs Insights queries, dashboards, metric filters, and alarms all work unchanged. Zero reconfiguration.

Important: This applies to events from Edge Regulator (standard format). Compact events from Edge Optimizer go to S3 for archival and aren't queryable in CloudWatch until Storage Streamer expands them back to standard format.

Does the 10x Engine work with ECS, EKS, and Lambda

Yes. The 10x Engine works with all AWS compute services that send logs to CloudWatch:

  • ECS (including Fargate): Edge apps deploy as sidecar containers alongside your log forwarder
  • EKS: DaemonSet deployment alongside Fluent Bit or OTel Collector
  • EC2: Process-level deployment alongside your log forwarder
  • Lambda: Deploy the 10x Engine as a Lambda container image that subscribes to CloudWatch Log Groups via subscription filter. Reports, regulates, or optimizes events before shipping to your destination. Also works with Cloud Reporter for agentless cost analysis via CloudWatch API
Do CloudWatch Metric Filters still work with optimized logs

Yes, with the right path:

  • Edge Regulator → CloudWatch: Events pass through in standard format, so Metric Filters work unchanged on them
  • Edge Optimizer → S3: Compact events are archived in S3 (not sent to CloudWatch), so Metric Filters don't apply to those events
  • Storage Streamer → CloudWatch: When streaming from S3 back to CloudWatch, events are expanded first, so Metric Filters work on rehydrated events

In practice: use Edge Regulator for events that need CloudWatch metrics (Metric Filters will work). Use Edge Optimizer for events destined for S3 archive (Metric Filters don't apply since these never reach CloudWatch). When you need to query archived events and stream them back, Storage Streamer handles expansion so Metric Filters work on the rehydrated data.

Cost Optimization

What's the typical cost reduction for CloudWatch Logs

CloudWatch charges $0.50/GB for log ingestion (us-east-1) -- the single biggest line item for most teams. A 10TB/month environment pays $5,000/month just to ingest.

With Edge Optimizer (50-60% structural optimization): that same 10TB drops to ~4TB ingested -- $2,000/month. No data loss, all fields preserved.

With S3 streaming: route low-value logs to S3 at $0.023/GB and stream to CloudWatch only when you query. For compliance and archival use cases, this pushes total savings to 80%+.

CloudWatch pricing as of Jan 2026

How do I see what's driving my CloudWatch costs

Cloud Reporter analyzes your CloudWatch log groups and provides cost breakdowns using automatic enrichment:

  • Message patterns — Symbol Message Calculator extracts the stable, core structure of each log (e.g., "Sync failed", "Request timeout"). This is the key identifier for cost-per-event-type analysis.
  • Severity levels — Level Classifier identifies ERROR, WARN, INFO, DEBUG to show which severity levels consume the most budget
  • Kubernetes context — Pod, namespace, and container enrichment for per-workload cost attribution
  • Multi-line grouping — Groups related log lines (like stack traces) as single events for accurate cost calculation
  • HTTP status codes — Extracts HTTP response codes for API/web service cost breakdown

Cloud Reporter uses these enrichments to identify the specific patterns and services driving your ingestion costs, letting you target optimization where it has the most impact.

Can I prevent CloudWatch billing spikes

Yes. At $0.50/GB, a single noisy deployment can add thousands to your bill in hours. Edge Regulator tracks actual cost per event type (bytes x $/GB) and enforces per-type budgets automatically -- severity-aware, so ERRORs are kept while DEBUG is throttled first.

For K8s environments, per-app budgets prevent individual services from bypassing limits by scaling pods. For environment-wide control, GitOps policies push cost thresholds to all regulators from a central config.

How does S3 streaming reduce CloudWatch costs

Storage Streamer stores logs in S3 at a fraction of CloudWatch costs, then streams selected data to CloudWatch on-demand.

  • Full retention in S3 for compliance
  • Pay CloudWatch ingestion only for logs you actively query
  • 80%+ cost reduction for archival scenarios
How does optimization affect log data

No data loss occurs. Each tool handles data differently:

  • Edge Optimizer: Removes redundant patterns within log events while preserving all unique information
  • Edge Regulator: You choose which event types to filter
  • Storage Streamer: Maintains full fidelity in S3 while controlling what reaches CloudWatch
What is the processing overhead

Events arrive in standard CloudWatch format — no expansion needed, no search-time overhead. Logs Insights queries, dashboards, metric filters, and alarms work unchanged.

The 10x Engine processes events at sub-millisecond per event — 100+ GB/day on a single node (512 MB heap, 2 threads). Memory is capped via -Xmx, CPU via threadPoolSize. For resource requirements, scaling tables, and architecture details, see Performance FAQ.

What about real-time alerting and monitoring

The 10x Engine operates in real-time with minimal latency. Critical logs flow through immediately.

Your CloudWatch alarms and metric filters continue working on the optimized stream. For alerting on filtered events, Edge Regulator can be configured to always pass through error-level logs.

Getting Started

How do I test this on my CloudWatch logs
  1. Dev — Run on your CloudWatch log files locally. One-line install, results in minutes. No account, no credit card.
  2. Cloud Reporter — Connect to your CloudWatch Log Groups via API. See which event types cost the most — no agent changes.
  3. Edge apps — Deploy optimizer and regulator via Helm chart alongside your forwarder. ~30 min setup.
  4. Storage Streamer — Route events to S3, stream selected data to CloudWatch on-demand.

Each step is independent — start with Dev to see your reduction ratio, then move to production when ready.

Is the deployment reversible? Can I roll back

Yes, 100% reversible. Rolling back takes minutes:

  • Configuration change: Point your CloudWatch Agent output back to CloudWatch directly
  • No data migration: Your CloudWatch log groups are unchanged -- same structure, same metric filters
  • No downtime: Switch traffic with a config reload (no restart required)

Why it's safe: The 10x Engine sits between your applications and CloudWatch. It doesn't modify your log groups, metric filters, or Insights queries.

We recommend keeping bypass routing configured for instant rollback during initial deployment.