A Practical Guide to Amazon CloudWatch Logs Cost Optimization

Introduction

As organizations centralize logs from AWS services, on-premises infrastructure, and third-party sources into CloudWatch Logs, storage becomes the dominant cost driver. Ingestion is one-time, but storage charges accumulate for the lifetime of the data, often years when compliance mandates like PCI-DSS or HIPAA apply. This post shows you how to use built-in CloudWatch Logs features to bring those costs down without losing access to your data.

Why should you care?

For many customers, the logs are primarily for troubleshooting, where the recent data is important. It is then kept for compliance or future investigations, but rarely accessed.

The challenge: how do you reduce costs on this log data without deleting logs or exporting them to separate services that add operational overhead and tooling complexity?

You can optimize costs by answering three questions for each one:

• Ingestion: Log class – Does this data need real-time features like metric filters or live tail? Your answer determines ingestion cost.
• Storage: Intelligent Tiering – How often will I search this data after the first few days? Storage costs drop automatically as search frequency decreases.
• Retention – How long must I keep this data? This sets the hard boundary on when logs are permanently deleted.

Log Ingestion – Log Classes

The log class determines two things: your ingestion costs, and which features are available on that log group. CloudWatch Logs has two log classes: Standard log class and Infrequent Access log class. You choose the log class when you create a log group – it can’t be changed afterwards.

Which log class should I choose?
Standard log class gives you the full feature set such as metric filters, subscription filters, field indexes, facets, live tail, and embedded metrics. Infrequent Access log class gives you a reduced feature set at a lower ingestion price. Check the feature list at Log classes supported features.

As a general guide: If you need real-time alerting or processing on the data as it arrives, choose Standard log class. For data retained for auditing and compliance, the Infrequent Access log class gives you what you need at lower cost.

Pricing
Log ingestion costs are based on the volume you ingest, and which log class you have set for the log group. Log ingestion costs for Infrequent Access log class are typically 50% of the Standard log class, but check the pricing for your region to verify.

How do I enable it?
You set the log class when creating a log group (in the console, CLI, or infrastructure-as-code such as AWS CloudFormation, CDK, Terraform). It’s a one-time decision at log group creation; existing log groups can’t be changed.

If you are using the CLI to create your log groups, specify --log-group-class STANDARD or --log-group-class INFREQUENT_ACCESS (defaults to Standard).

So far we’ve looked at optimizing ingestion costs. But what about data storage? That’s where Intelligent Tiering and Retention come in.

Log Storage – Intelligent Tiering

Log storage costs accumulate over time, especially for long-retention log groups. Intelligent Tiering reduces these costs automatically based on how often you access your data.

CloudWatch Logs Intelligent Tiering automatically classifies your stored log data between three storage tiers based on when you last accessed your log data. For example, running a Logs Insights query is one way to access your data (read more at Actions that constitute access).

• Standard tier: accessed in the last 30 days
• Infrequent Access tier: not accessed for 31-90 days
• Archive Instant Access tier: not accessed for 91+ days

Note: The Infrequent Access storage tier and the Infrequent Access ingestion log class are separate concepts. Log class is chosen at log group creation and affects ingestion cost and features. Intelligent Tiering storage tiers apply automatically to all log groups based on access patterns, independent of log class.

What if I need to access my data?
You can search your data as normal, even across tiers. There is no delay in query searches based on the tier it is in. Once the log entries are accessed, they are reclassified as Standard tier and the timer resets. If the data is not accessed for 30 days, it is classified as Infrequent Access tier and so on.

Pricing
CloudWatch Logs compresses stored data at a typical ratio of 0.15, meaning the actual GB stored (and billed) is smaller than the raw log volume. Check the pricing for your region to verify.

For teams that export logs purely for cost reasons, this opens the option to keep your logs in CloudWatch. Your logs stay queryable in CloudWatch Logs, without the overhead of managing export jobs, paying data transfer costs, or switching tools to search archived data.

How do I enable Intelligent Tiering?
Enable Intelligent Tiering at the account level within a region. Once enabled, it applies to all log groups in that account/region automatically.
Console: CloudWatch console → Settings → Logs tab → Intelligent Tiering section → Enable.

Figure 1: CloudWatch console showing settings page for enabling the Intelligent Tiering

CLI: Enable with put-storage-tier-policy:
aws logs put-storage-tier-policy --storage-tier INTELLIGENT_TIERING

Check your current configuration with get-storage-tier-policy:
aws logs get-storage-tier-policy

How do I know how much data is in each tier?
A new vended metric is available which records how much data is in each tier. The metric is called StoredBytes in the AWS/Logs namespace, with two dimensions – LogGroupName and StorageType – where StorageType values are Standard, Infrequent_Access, and Archival_Instant_Access. This metric is published once a day. See monitoring storage per tier for details.

Visualizing your data
You can use this metric to build dashboards to show your per-tier storage breakdown. This Metric Insights query can be used to see how your data is distributed across tiers. For example this query allows you to see the volume of data in each tier for a specific log group called /ecs/PetListAdoptions.

SELECT SUM(StoredBytes)
FROM SCHEMA("AWS/Logs", LogGroupName,StorageType)
WHERE LogGroupName = '/ecs/PetListAdoptions'
GROUP BY StorageType

Figure 2: CloudWatch dashboard widget showing the distribution of data across tiers in a log group.

Or you could use the following query to see which log groups have data in the archive tier.

SELECT SUM(StoredBytes)
FROM SCHEMA("AWS/Logs", LogGroupName,StorageType)
WHERE StorageType = 'Archival_Instant_Access'
GROUP BY LogGroupName
ORDER BY MAX() DESC

You can even use dashboard variables like we have in these examples, so you can change the Tier or Log group name easily and explore your data.

Retention

Retention policies set boundaries on when logs are permanently deleted from the log group. Without it, CloudWatch Logs stores data indefinitely, even after Intelligent Tiering has minimized storage costs, they keep accumulating.

How do I set a retention policy?
Console: CloudWatch console → Log Management → Log groups → select log group → Actions → Edit retention settings. See Change log data retention in CloudWatch Logs for details.
CLI: Enable with put-retention-policy:
aws logs put-retention-policy --log-group-name my-logs --retention-in-days 5

How do I check and enforce retention?

• Detect drift with AWS Config: The managed rule cw-loggroup-retention-period-check periodically flags log groups with retention below your minimum (e.g., 365 days)
• Auto-enforce on new log groups: Use Amazon EventBridge + AWS Lambda to automatically apply a retention policy whenever a log group is created. See Reduce log-storage costs by automating retention settings in Amazon CloudWatch for a full walkthrough with CloudFormation templates and cross-Region support.

Getting started

Log class controls ingestion cost, Intelligent Tiering controls storage cost while data exists, retention controls how long data exists.

Here’s how these decisions play out in some examples:

• Application logs need metric filters and live tail for fast troubleshooting; Standard log class is the right choice. After the initial investigation window, Intelligent Tiering automatically moves unsearched entries to Infrequent Access and Archive Instant Access storage tiers. Set retention to match your operational needs.
• Verbose debug and trace logs are useful during active deployments but rarely searched again. Choose Infrequent Access log class for ingestion, set a short retention, and Intelligent Tiering handles storage costs in between.

Suggested Actions

• One click, immediate impact: Enable Intelligent Tiering in each account/region. No per-group configuration needed. You don’t have to wait 30 days to see the impact, some of your data may already meet the requirements of the new tiers.
• Low effort, high impact: Audit existing log groups for missing retention policies. Use the Config rule to detect and automate enforcement.
• Medium effort, high impact: Evaluate new log groups for Infrequent Access log class at creation time. Build it into your infrastructure-as-code.