Where should Lambda logs go to cut costs — CloudWatch, IA, S3, or Firehose?

Choose whether Lambda logs should stay in CloudWatch Standard, move to Infrequent Access, or be delivered to S3 or Firehose after AWS introduced tiered pricing and new delivery destinations that alter observability cost architecture.

Infrequent Access for most teams. Standard only if you need real-time alerts. S3 or Firehose when you already have an analytics pipeline.

Blockers

Who this is for

Candidates

Keep Lambda logs in CloudWatch Logs Standard

As of 2026-03-15, Lambda logs delivered to CloudWatch Logs are priced as vended logs with volume tiering; AWS states that in US East (N. Virginia) Standard starts at "$0.50" per GB and can tier down to "$0.05" per GB. Standard is still the full-featured choice for real-time operations because CloudWatch documents support for subscription filters, metric filters, Live Tail, anomaly detection, field indexing, embedded metrics format, and Lambda Insights log ingestion.

When to choose

Best for serverless + real-time or low-ops + small-team workloads where operators need native CloudWatch search, alerts, dashboards, metric extraction, or downstream subscriptions, and where the higher hot-path ingestion price is justified by faster incident response and less pipeline setup.

Tradeoffs

This is the lowest-friction path because CloudWatch Logs is Lambda's default destination and works immediately with native monitoring workflows. The tradeoff is higher ingestion cost than Infrequent Access or S3 or Firehose delivery in the first tiers, plus separate storage and Logs Insights query charges.

Cautions

Do not assume Standard is only a pricing choice. Moving away from it can remove features you may already depend on. If you later want to cut cost by changing a log group's class, CloudWatch documents that the log class cannot be changed after the log group is created.

Sources

Use CloudWatch Logs Infrequent Access for Lambda log groups that stay in CloudWatch

As of 2026-03-15, Lambda logs in CloudWatch Logs Infrequent Access use the same tiered vended-log model, and AWS states that in US East (N. Virginia) pricing starts at "$0.25" per GB for the first 10 TB, then tiers down further. CloudWatch documents that Standard and Infrequent Access differ only in ingestion cost; storage charges and Logs Insights charges are the same.

When to choose

Best for serverless + cost-sensitive or compliance + enterprise setups where logs still need to remain in CloudWatch, but access is mostly ad hoc or forensic and you can live without the full real-time feature set. This fits workloads that want CloudWatch retention and cross-account analytics but do not need Live Tail, metric filters, or subscriptions on those specific groups.

Tradeoffs

You keep CloudWatch-managed ingestion, storage, encryption, and Logs Insights querying while lowering ingestion cost versus Standard. The tradeoff is that Infrequent Access removes several operational features, so it is not a drop-in replacement for production hot-path log groups.

Cautions

CloudWatch documents that Infrequent Access does not support subscription filters, metric filters, Live Tail, anomaly detection, field indexing, embedded metrics format, GetLogEvents, FilterLogEvents, or Lambda Insights log ingestion. The log class is immutable after creation, so choose per log group deliberately.

Sources

Deliver Lambda logs to Amazon S3 through the CloudWatch Logs Delivery class

As of 2026-03-15, AWS supports Amazon S3 as a Lambda log destination, routed through the CloudWatch Logs `Delivery` log class. AWS states that in US East (N. Virginia) Lambda-to-S3 delivery starts at "$0.25" per GB and can tier down to "$0.05" per GB, while CloudWatch pricing notes that S3 storage costs and optional Parquet conversion charges are separate.

When to choose

Best for serverless + cost-sensitive or compliance + high-scale environments where logs are mainly a retention, audit, or batch-analysis asset, and where Athena or downstream S3-based tooling is acceptable instead of CloudWatch-native real-time operations. This is the strongest default for long retention when you want the lowest-ops cold path as of 2026-03-15.

Tradeoffs

AWS positions S3 as an economical long-term storage option, and the Lambda docs call out Athena-based analysis as the natural companion. The tradeoff is slower and less interactive day-to-day debugging than CloudWatch Standard, plus extra setup for bucket permissions and subscription delivery.

Cautions

CloudWatch documents that the `Delivery` log class keeps events for only one day in CloudWatch Logs and does not provide rich features such as Logs Insights queries. The S3 destination setup requires a CloudWatch Logs subscription filter and an IAM role, the bucket must be in the same Region as the log group, and Lambda does not automatically add put permissions for S3 destinations.

Sources

Deliver Lambda logs to Amazon Data Firehose for near-real-time downstream routing

As of 2026-03-15, AWS supports Amazon Data Firehose as a Lambda log destination through the CloudWatch Logs `Delivery` log class. AWS states that in US East (N. Virginia) Lambda-to-Firehose delivery starts at "$0.25" per GB and can tier down to "$0.05" per GB, and CloudWatch pricing notes that Firehose ingestion charges are additional.

When to choose

Best for serverless + real-time or enterprise + microservices environments where Lambda logs must leave CloudWatch quickly for another managed sink, supported third-party observability platform, or custom HTTP endpoint, and where building and operating a separate forwarding layer would add unnecessary complexity.

Tradeoffs

Firehose gives a managed streaming path to downstream systems and AWS documents that it can simplify delivery to supported third-party platforms and custom HTTP endpoints. The tradeoff is a more complex billing model than S3 because you pay both Lambda log delivery charges and Firehose processing, and you still lose CloudWatch Standard hot-path features on the delivery log group.

Cautions

The `Delivery` log class keeps events in CloudWatch for only one day and does not provide Logs Insights queries. Firehose destination setup requires a CloudWatch Logs subscription filter and IAM permissions, and Lambda does not automatically add put permissions for Firehose destinations. AWS also documents that CloudWatch Logs events sent to Firehose are gzip-compressed, and that Firehose does not support delivery of CloudWatch Logs to an OpenSearch Service destination because multiple log events are combined into one Firehose record.

Sources

Facts updated: 2026-03-15
Published: 2026-03-29

Related questions

Try with your AI agent

$ npm install -g pocketlantern
$ pocketlantern init
# Restart Claude Code, Cursor, or your MCP client, then ask:
# "Where should Lambda logs go to cut costs — CloudWatch, IA, S3, or Firehose?"
Missing something? Request coverage