Skip to content

CloudWatch

Cut CloudWatch costs by analyzing spend, preventing over-billing, down-tiering low-value patterns to a cheaper log group, and offloading to S3. Works with CloudWatch Logs across ECS, EKS, EC2, and Lambda.

Compatibility

Does 10x work with CloudWatch Agent

Through a file relay. The CloudWatch agent has no 10x integration of its own. Fluent Bit with 10x reads the logs, processes them and writes them to a second folder, and the CloudWatch agent tails that folder as it would any log file, the same relay the Datadog Agent uses. Fluent Bit can also send to CloudWatch Logs directly with its cloudwatch_logs output, in place of the agent.

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 or SDKs required. For tier_down, one new log group is created in the Infrequent Access class and the forwarder sends the low-value slice there; AWS fixes a group's class when the group is created, so the existing groups stay as they are.

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, and dashboards built on them, work on Standard and Infrequent Access groups alike, except the pattern, diff, filterIndex and unmask commands, which Infrequent Access groups do not support; metric filters, subscription filters and the alarms built on them work on Standard groups only, so the patterns they read stay there.

Important: This applies to events the Receiver passes through to CloudWatch. Events down-tiered to an Infrequent Access group answer Logs Insights queries, but metric filters, subscription filters, and Live Tail do not read them. 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 runs as a sidecar container alongside 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: the Extension runs the engine inside each function's execution environment from the published tenx-receive layer, paired with the OTel collector extension, and regulates events before the collector exports them. Events already written to a CloudWatch log group have been billed as CloudWatch ingest. 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, still queryable in Logs Insights. The saving is ingest-side only: AWS bills storage ($0.03/GB-month) and Logs Insights queries at the same rate in both log classes. Down-tiering half of a 10TB/month volume saves ~$1,250/month (5TB x $0.25 saved).

Before down-tiering a log group, check what reads it. An Infrequent Access group serves Logs Insights, but not subscription filters, metric filters, Live Tail, field indexing, or the GetLogEvents and FilterLogEvents APIs. A consumer on any of those stops returning events with no error. The log class is fixed when the group is created, so the slice moves to a new IA group rather than converting the one already in place.

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. The offloaded slice pays S3 storage instead of CloudWatch ingest and storage; what Retriever fetches back bills as CloudWatch ingest.

Down-tiering and offload keep the data reachable. Sampling and drop are lossy choices you opt into. The combined cut depends on how much volume each lever moves: down-tiering halves the ingest rate on the moved slice and leaves its storage charge as it was, and offload keeps the slice out of CloudWatch until Retriever fetches it back.

CloudWatch prices for us-east-1 from the AWS price list, read 2026-10-10.

Can I prevent CloudWatch billing spikes

Yes. At $0.50/GB, a single noisy deployment can add thousands to your bill in hours. Receiver reports the cost of each event type (bytes x $/GB) and, once a cap is set, caps each type's bytes per window, severity-aware: by default an over-cap type keeps at least half of its ERROR, CRITICAL and FATAL events, 30% of WARN and 10% of every other level. The cost is reported; the regulator decides on bytes.

For K8s environments, per-app budgets prevent individual services from bypassing limits by scaling pods. For per-pattern rates, commit a mute file to git and let GitOps push it to every receiver.

How does S3 streaming reduce CloudWatch costs

Retriever reads the logs the Receiver offloads to your own S3, at a fraction of CloudWatch costs, and returns selected events on demand to a results location in that bucket. Your own forwarder or script ships them into CloudWatch when they are needed there; no log10x-hosted relay sits in the path.

  • Logs stay reachable in S3, fetched back by pattern identity when you query
  • Pay CloudWatch ingestion only for the events you ship back

Routing Key

What does 10x add to CloudWatch's own routing

An Infrequent Access log group or your own S3 stores the cheaper slice, and today a person writes the rules that choose it: each producer names the log group it writes to, and the group's log class is fixed when the group is created. 10x keeps those rules current per pattern: the rules key on the pattern, which is the same on every pod from its first line, whatever lines that pod has seen and whenever it started. A miner at the edge depends on both: two Drain3 instances that each see half of one stream name a line seen 2 to 10 times differently 39.78% of the time (pattern-identity benchmark). The compiler runs in CI or on a schedule, so new log statements, including ones a coding agent wrote, are named as the code ships; a scheduled check (tenx-recur) costs each pattern, routing changes arrive as pull requests to the policy repo, and caps act on their own.

What a moved byte costs, computed from the released engine's counts on a public capture at list price, is in benchmarks/cloudwatch-ia-accounting: $0.25 instead of $0.50 per GB ingested to Infrequent Access.

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 by the container limit, CPU via threadPoolSize. For resource requirements and Kubernetes resource specs, see Node counting.

What about real-time alerting and monitoring

Your CloudWatch alarms and metric filters continue working on the optimized stream. Metric filters do not run on Infrequent Access groups, so keep patterns that feed a metric filter or alarm in a Standard group. 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. Cost POC, install the 10x MCP and ask it for a cost POC on your CloudWatch logs. It reads a sample through the CloudWatch API, or from a Kubernetes cluster through kubectl, runs the engine on your own machine, and reports the events and GB per pattern a plan would move to Infrequent Access or your S3. 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 events back on demand to a results location there, for your own forwarder to ship into CloudWatch.

Each step is independent: start with the cost POC to see what a plan would move, 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.