Skip to content

CloudWatch

CloudWatch Logs costs come from three independent levers, and unusd.cloud reports on all three:

Lever What it controls Can it be changed later?
Log class Ingestion price and available features No, fixed at log group creation
Intelligent Tiering Storage price while data exists Yes, one setting per account and region
Retention How long data exists before deletion Yes, per log group

Log Groups

CloudWatch Log Groups set to "Never Expire" retention can accumulate massive storage costs over time.

Implementation Effort: Low - Estimated time: less than 30 minutes. Set a retention policy on the log group via console or CLI.

We detect log groups without an expiration policy and recommend setting appropriate retention periods. Exceptions apply for compliance-critical logs like CloudTrail and VPC Flow Logs, which may require long-term retention.

Each finding also shows the log group's log class (Standard or Infrequent Access), since that determines what you paid to ingest the data.

Intelligent Tiering

CloudWatch Logs Intelligent Tiering automatically moves stored log data to cheaper tiers based on when you last accessed it: Infrequent Access after 31-90 days without access, and Archive Instant Access after 91+ days. Queries continue to work across all tiers with no retrieval delay and no change to your tooling.

Implementation Effort: Low - Estimated time: less than 30 minutes. A single account-level setting per region that then applies to every log group automatically.

What We Detect

Regions where Intelligent Tiering is not enabled, along with the total volume of log data stored in that region so you can see the size of the opportunity.

Why It Matters

This is the highest-leverage CloudWatch Logs change available: one setting, no per-log-group work, and no impact on how you query your data. Data that already meets the age requirements moves to a cheaper tier without waiting.

Log Class

The Infrequent Access log class costs roughly 50% less to ingest than the Standard class, in exchange for a reduced feature set (no metric filters, subscription filters, Live Tail, field indexes, or embedded metrics).

Implementation Effort: Medium - Estimated time: 1-4 hours. The log class cannot be changed on an existing log group, so this is guidance for new log groups and infrastructure-as-code defaults.

What We Detect

Large, long-retention log groups on the Standard class that are being actively written to. These match the audit and compliance profile where the Standard class features are usually unnecessary.

Recommendations

  1. Set INFREQUENT_ACCESS as the default for audit and compliance log groups in your CloudFormation, CDK, or Terraform templates
  2. Keep the Standard class where you need real-time alerting or processing as data arrives
  3. Recreate an existing log group only when losing Standard-class features is acceptable

Log Retention

Log groups retaining data for more than a year with a large stored volume carry the highest ongoing storage cost.

Implementation Effort: Low - Estimated time: less than 30 minutes. Shorten the retention policy via console or CLI.

What We Detect

Log groups with retention above 365 days and more than 1 GB stored. Enabling Intelligent Tiering reduces the cost of this data without touching the retention policy, so both actions are worth considering. We flag these for review rather than assuming the retention is wrong: mandates such as PCI-DSS or HIPAA legitimately require long retention.

Custom Metrics

CloudWatch custom metrics can become a significant cost driver, especially when cardinality explosion occurs from high-cardinality dimensions.

Implementation Effort: Medium - Estimated time: 2-8 hours. Requires application code changes to reduce metric cardinality.

What We Detect

  • High-cardinality namespaces -- Custom metric namespaces with excessive unique metric combinations
  • Risky dimensions -- Namespaces using dimension patterns that commonly lead to cardinality explosion
  • Cost estimation -- Monthly cost impact based on your metric count

Why It Matters

CloudWatch charges per unique metric. A single application emitting metrics with per-user or per-request dimensions can generate thousands of unique metrics, costing hundreds or thousands of dollars monthly.

Recommendations

  1. Avoid high-cardinality dimensions (user IDs, request IDs, IP addresses)
  2. Use Embedded Metric Format (EMF) to aggregate before publishing
  3. Review unused namespaces -- custom metrics expire after 15 months of no new data

Keep on chasing 🧡