CloudWatch

Cut CloudWatch costs by ~66% combined. Analyze spend, prevent over-billing, down-tier low-value patterns to a cheaper log group, and offload to S3. Works with CloudWatch Logs across ECS, EKS, EC2, and Lambda.

• Compatibility
• Cost Optimization
• Operations
• Getting Started

Compatibility

Does 10x work with CloudWatch Agent

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

The MCP server's SIEM-sample tool and Retriever are agentless, working via CloudWatch API and S3 regardless of your forwarder. Also supported: Fluent Bit, Fluentd, Filebeat, and Logstash.

How does 10x integrate with AWS CloudWatch

10x integrates at the forwarder level before logs reach CloudWatch.

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

It reduces ingestion volume with non-destructive levers (tier_down to a cheaper log group, offload to your own S3) that keep the data reachable, plus sampling and drop, which are lossy choices you opt into. 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 the Receiver passes through to CloudWatch. Events routed to S3 (offload) are stored in your own bucket and aren't in CloudWatch until Retriever fetches them back by pattern identity.

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 cost visibility before logs reach CloudWatch
• EKS: the Receiver deploys as a sidecar to Fluent Bit or OTel Collector; the Reporter deploys as a separate DaemonSet alongside them (logs never pass through it)
• 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. Samples low-value events or routes them to a cheaper destination before shipping. For agentless CloudWatch-side analysis without a Lambda deployment, use the MCP server's SIEM-sample tool.

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.

Down-tier to a cheaper log group: route the low-value slice to a CloudWatch Logs Infrequent Access log group at $0.25/GB ingest (50% off the $0.50 standard) and $0.0075/GB-month storage, still queryable in Logs Insights. Down-tiering half of a 10TB/month volume saves ~$1,250/month on ingest alone (5TB x $0.25 saved).

Offload to your own S3: route the bulk slice to customer-owned S3 at $0.023/GB-month and fetch it back with Retriever only when you query. For compliance and archival profiles where most volume is offloaded, total savings reach an estimated 80%+.

Down-tiering and offload keep the data reachable. Sampling and drop are lossy choices you opt into. Combined, the modeled CloudWatch reduction is an estimated ~66%.

CloudWatch pricing as of Jan 2026

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 offloads logs to your own S3 at a fraction of CloudWatch costs, then fetches selected data back to CloudWatch on-demand.

• Logs stay reachable in S3, fetched back by pattern identity when you query
• Pay CloudWatch ingestion only for logs you actively query
• An estimated 80%+ cost reduction for archival scenarios

Operations

How does optimization affect log data

The levers that move the CloudWatch bill handle data differently. The non-destructive ones keep every line reachable. Sampling and drop are lossy choices you opt into:

• Receiver (tier_down): Routes the low-value slice to a cheaper Infrequent Access log group, preserving every field and keeping it Logs-Insights queryable
• Retriever (offload): Keeps full data in your own S3 bucket and controls what reaches CloudWatch
• Receiver (sampling and drop): You choose which event types to cap or discard; these are lossy by design

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 adds minimal per-event overhead. 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

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 cost visibility before logs reach CloudWatch. Alternatively, use the MCP server's SIEM-sample tool for agentless analysis via CloudWatch API.
3. Receiver, Deploy via Helm chart alongside your forwarder. Sampling caps noisy patterns; tier_down routes the low-value slice to a cheaper Infrequent Access log group (still Logs-Insights queryable). ~30 min setup.
4. Retriever, Offload events to your own S3 bucket and fetch selected data back 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.