As of June 2026, CloudWatch Logs can mirror a log group into S3 Tables in Apache Iceberg format, queryable with standard SQL in Athena and any Iceberg-compatible engine. The copy in S3 Tables, and the Iceberg maintenance that keeps it performant, carry no additional storage or compaction charge. You pay only for the queries.
The natural reading of that sentence is: pay CloudWatch's expensive ingestion once, then keep a cheap long-term copy in S3 for historical SQL analytics. That reading is wrong, and building a retention strategy on it loses the history you think you are keeping.
The coupling nobody reads
From the AWS documentation, stated plainly and easy to skip: set a retention period on the CloudWatch Logs log group, and the S3 Tables integration applies the same retention to the Iceberg data. The two are coupled. The S3 Tables copy is not an independent archive. It expires with the log group, and deleting the log group or a log stream deletes the Iceberg data with it.
This inverts the mental model most people bring to it. The S3 Tables copy is not downstream storage you control separately. It is a SQL-queryable view over exactly the same retention window as the log group. Set 30 days on the log group and you have 30 days of Iceberg data. Not 30 days hot plus an S3 tail going back a year. Thirty days, everywhere.
