CloudWatch Logs Intelligent Tiering: Cheaper Long-Term Retention, Less Operational Overhead

TL;DR: CloudWatch Logs Intelligent Tiering moves unread log data into cheaper storage tiers after 30 and 90 days, and it costs nothing to switch on. You should definitely do it. I'd expect 15 to 30% only if you keep logs for years or ingest at real volume, but under 1% at 90 days and exactly zero saving at 30-day retention.

On July 16, 2026, AWS shipped Intelligent Tiering for CloudWatch Logs, and considering that CloudWatch Logs is one of the major causes of cloud wastage, it is interesting to a lot of teams. When we look at intelligent tiering, S3 Intelligent-Tiering comes to mind first. And when I started reading the announcement blog, it struck me that CloudWatch Logs Intelligent Tiering is different from S3 Intelligent-Tiering in many interesting ways.

What CloudWatch Logs Intelligent Tiering actually does

Now the interesting aspect of this new feature is that the API does not allow granularity of selection of the log groups. This API applies to a specific account+region, and to every log group in that account and region whether you wanted that or not:

aws logs put-storage-tier-policy --storage-tier INTELLIGENT_TIERING

There's no per-log-group control and you can't move the thresholds, unlike in S3 Intelligent-Tiering. In fact a lot of the complications in S3 Intelligent-Tiering stem from this policy configuration, and it requires a thoughtful analysis of access patterns. This default behaviour in CWL tiering makes it simple to understand and use. The mechanism is simple for CWL: data (log events) nobody has read for 30 straight days moves to Infrequent Access; at 90 days it moves again to Archive Instant Access. Now you would expect some latency from logs sitting in an archive tier, but AWS claims the query latency is the same in all three tiers. At the moment the feature is live in all commercial regions except Bahrain and UAE.

Here is what the three tiers actually cost in us-east-1, per GB-month of compressed data:

Another interesting aspect is there is no enablement, transition or retrieval fee, and none of the per-object monitoring charge that makes S3 Intelligent-Tiering quietly lose money on the wrong bucket. And this makes me put forward my advice: "just turn it on". Given the simplicity and the absence of any cost or performance side effect, it also makes me wonder why an API is needed at all, or why an explicit enablement is needed across all regions.

Understanding CloudWatch Cost Model

For CloudWatch logs, the pricing has two dimensions: Ingestion and Storage.

Ingestion is a one-time charge, but storage charges accumulate for the lifetime of the data. Ingestion runs at $0.50/GB of uncompressed data while storage runs at $0.03/GB-month of compressed data. Looking at the pricing, it seems storage is a sliver of what CloudWatch Logs charges. That is absolutely true if these logs are not stored for a long period.

However over a longer retention period (and CloudWatch Logs are retained forever by default) the storage costs dominate, and this is where intelligent tiering becomes an important savings instrument. The prominent use case for long term retention compliance, often for years when it comes to HIPAA or PCI-DSS. In such cases, many organisations chose logs to be exported and then back up in cold storage. This is unwanted but necessary evil overhead.

The typical compression factor is 0.15. I measured our own internal factor at about 0.12. I'm going to use 0.15 for everything below. Yours could of course be different, and as a side note, structured logging definitely helps for better compression factor.

How much does CloudWatch Logs Intelligent Tiering save?

A mathematical model helps to calculate the cost of each feature and what levers are available for cost savings. Here's the model I built for this feature. c is your measured compression factor, R is retention in months, P your blended ingestion rate per GB:

storage share      s = (c · R · 0.03) / (c · R · 0.03 + P)

tier mix           f_std = min(1, 1/R)
                   f_ia  = min(1, 3/R) − f_std
                   f_aia = max(0, 1 − 3/R)

blended discount   d = 1 − [f_std + 0.6·f_ia + 0.2·f_aia]

saving as a share of the CloudWatch Logs bill = s · d

Feed it c = 0.15, P = $0.50, R = 3 and you get a storage share of 2.6%, an achievable discount of 27%, and a saving worth 0.7% of the bill. At our own measured 0.12 it comes out at 0.6%. Either way it rounds to nothing, and that was us for most of our accounts.

Obviously for R = 1, f_std becomes 1, so d becomes 0. Simply if you keep logs 30 days or less, no byte survives long enough to make the first transition, and your saving is exactly zero no matter how much you ingest. No rocket science here.

Savings by retention and ingest volume

Saving as a percentage of the total CloudWatch Logs bill, at compression ratio of c = 0.15, derived from the formulas above.

Here the 0.6 and 0.2 multipliers are the us-east-1 tier ratios from the price table above, and $0.018 and $0.006 against $0.03 work out to exactly 40% and 80% off. Absolute rates do vary by region, so check yours on the CloudWatch pricing page. What the model does assume is that bytes are evenly aged, which is nonsense for any group with continuous increase in log volume.

Where it genuinely pays: long retention and vended logs

Two groups of people get real money out of this.

The first is anyone sitting on multi-year or never-expire compliance archives. At five years, storage is 35% of the CloudWatch bill and 95% of your bytes reach Archive Instant Access: 27% off, on a small, unremarkable estate. Until now, exporting and keeping these logs in an external system was needed, and that was additional money flowing out. This new feature opens up the option to keep logs in CloudWatch Logs itself, reducing operational overhead as well as money spent on external tooling. Another added advantage is that these logs stay instantly queryable in CloudWatch Logs.

It is worth remembering what this replaces. A typical setup at many organizations: Elasticsearch for the first week, S3 plus Athena for days 7 to 90, Glacier Deep Archive after that for compliance. With this new feature, this pipeline collapses into one API call, no Glue catalog needed and no maintenance needed.

At $0.006/GB-month, Archive Instant Access is cheaper than S3 Standard-IA at $0.0125, roughly half the price before you even count PUTs, Glue and Athena. The advice I have been giving for years: export your cold audit logs to S3, is now out of place. Instead I suggest "just turn it on".

The second is scale, the Vended Logs: VPC Flow Logs, Route 53, EKS control plane, WAF, Network Firewall, and since May 2025 Lambda logs too are volume-tiered, stepping from $0.50 down to $0.05 once you're past 50 TB per account-month. At 100 TB/month that blends to about $0.145/GB, which raises storage's share of the CloudWatch bill from under 10% to 27% at 12-month retention.

The anti-pattern: promotion thrash

The documentation states: any read returns the data (event log) you read, the time range the query covered, to Standard for 30 days, and the timer resets on every read.

Below are some examples that would reset the data back into standard storage and you will not save money:

• A nightly scheduled query with a 180-day lookback, re-promoting six months of data every single night.
• A monthly full-range export, CreateExportTask over the whole group, twelve times a year.
• Habitual wide time pickers, where someone leaves Logs Insights on 1y to answer a question about the last hour.
• Forensic and SIEM backfills walking the archive on a sub-30-day cadence.

The first is the big one, and you can catch it without any telemetry. Call ListScheduledQueries, then GetScheduledQuery for each, and flag anything where startTimeOffset / 86400 ≥ 30 and the cadence from scheduleExpression is under 30 days. Watch the units: startTimeOffset comes back in seconds.

And if you centralise cross-account, check each account separately since reading the replica promotes only in the destination, so a source archive can be genuinely cold while its twin runs permanently hot.

Three more ways to get CloudWatch Logs tiering wrong

Tiering a dormant log group instead of deleting it

Classic case of no ingestion for 90 days, and nobody reading it for 120, still turning up on the bill. Every byte gets to Archive Instant Access, so tiering hands you the full 80% off. But think about it, deleting it hands you 100%. You missed that 20% saving.

Enabling tiering before you've run the retention sweep

Most cost savings rules flag savings above $100 to avoid distractions. Say there are never-expire groups costing more than $100/year, and tiering cuts those costs by up to 77%, so a $120/year finding quietly becomes a $27/year non-finding. The waste is still sitting right there but never flagged. Make the retention decision on untiered prices, or you'll keep garbage for a decade at a discount and feel good about it.

The one way it can actually cost you more

Under an EDP or private pricing addendum, go and read the scope. Those discounts are written against specific usage-type strings, and a hard-won rate on TimedStorage-ByteHrs doesn't follow the bytes into -IA- or -AIA-ByteHrs. It's the only mechanism I found that raises the real invoice, and of course at the moment I'm only speculating about it as we don't have concrete information on whether AWS would consider these new usage types or not.

IA log class is not the IA storage tier

These two get confused constantly, and they are totally different and much less flexible mechanisms.

What actions to take

1. Run the retention sweep first, on untiered prices.
2. Measure c per log group.
3. Enable it in every account and region, then bake it into the landing zone. Terraform added support for the tiering policy at the end of July 2026, so this can be a provider resource rather than a scripted API call.
4. Audit your scheduled query lookbacks with the predicate above.
5. Wait 91 days before measuring. StoredBytes by StorageType publishes daily and doesn't exist until you enable tiering, so there's no baselining it first. The dimension value is Archival_Instant_Access, not Archive_. That prefix cost me an afternoon.
6. Poll GetStorageTierPolicy. PutStorageTierPolicy isn't in AWS's documented CloudTrail action list (yet), so don't trust an EventBridge rule to catch a reverted region.

At CloudYali we run this model across every account and region automatically, scheduled-query check included. It is the kind of number native tooling will not surface for you, because it needs your compression factor and your retention spread together.

Book a demo and we'll tell you which of the two groups your estate is in, before you spend 91 days waiting to find out.