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.

The MCP server's SIEM-sample tool and Retriever 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 Receiver (standard format). Compact events from Receiver (Compact mode) go to S3 for archival and aren't queryable in CloudWatch until Retriever 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): the Receiver deploys as a sidecar container alongside your log forwarder; the Reporter deploys as a daemonized task for pre-SIEM cost visibility
  • EKS: the Receiver deploys as a sidecar to Fluent Bit or OTel Collector; the Reporter deploys as a separate DaemonSet alongside them (not in the log path)
  • EC2: Process-level deployment alongside your log forwarder (Receiver) or independent process (Reporter)
  • Lambda: Deploy the 10x Engine as a Lambda container image that subscribes to CloudWatch Log Groups via subscription filter. Filters or compacts events before shipping to your destination. For agentless SIEM-side analysis without a Lambda deployment, use the MCP server's SIEM-sample tool.
Do CloudWatch Metric Filters still work with optimized logs

Yes, with the right path:

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

In practice: use Receiver for events that need CloudWatch metrics (Metric Filters will work). Use Receiver (Compact mode) 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, Retriever 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 Receiver (Compact mode) (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

The Reporter (DaemonSet, pre-SIEM) or the MCP server's SIEM-sample tool (agentless, via CloudWatch API) analyze your CloudWatch log groups and provide 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

These enrichments 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. Receiver 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 surgical per-pattern caps, commit a field-set mute file to git and let GitOps push it to every receiver.

How does S3 streaming reduce CloudWatch costs

Retriever 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

Operations

How does optimization affect log data

No data loss occurs. Each tool handles data differently:

  • Receiver (Compact mode): Removes redundant patterns within log events while preserving all unique information
  • Receiver: You choose which event types to filter
  • Retriever: 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, Receiver 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. Reporter — Deploy as a DaemonSet for pre-SIEM cost visibility. Alternatively, use the MCP server's SIEM-sample tool for agentless SIEM-side analysis via CloudWatch API.
  3. Receiver — Deploy via Helm chart alongside your forwarder. Filter mode (sampling) or Compact mode (lossless shrink, archived to S3). ~30 min setup.
  4. Retriever — 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.