A SaaS company ingests 3 TB of application logs daily into CloudWatch and keeps everything for a year, causing observability spend to exceed compute. Engineers need error diagnostics for 30 days and audit access for a year. Which cost-effective observability design with log filtering and retention optimization lowers cost?

The correct design succeeds because it maps each requirement to the cheapest suitable tier: filtering at the source or through a subscription-filter pipeline keeps only error events in a 30-day CloudWatch log group, so only high-value logs incur CloudWatch ingestion, storage and query costs, while the full 3 TB daily volume is compressed and delivered to S3 with a lifecycle transition to Glacier storage classes to preserve low-cost audit access for a year without expensive year-long CloudWatch retention. Retaining filtered errors but archiving to S3 Standard with no Glacier lifecycle fails on storage economics because Standard targets frequent access and costs far more than archive tiers, so functionality remains but the spend exceeding compute is not resolved. Keeping errors for 30 days without archiving remaining logs fails on governance because filtering and diagnostics are satisfied yet the mandatory year-long audit trail is lost and cannot be reconstructed after expiration. Streaming through Firehose to Glacier while keeping full logs in CloudWatch fails on ingestion filtering because the unfiltered 3 TB per day still incurs CloudWatch ingestion, storage and Insights scan charges for 30 days, so archiving is sound but cost reduction is incomplete. For exams, distinguish reducing volume ingested into expensive real-time storage from reducing duration it is retained there, since cost questions often require both levers. In practice, check IncomingBytes and stored-bytes metrics, validate filter patterns against real error samples, and test Glacier retrieval times and retention policies to confirm audit access meets SLAs.