A fintech payments API generates 2 TB of JSON logs daily in CloudWatch and emits high-cardinality custom metrics. Engineers search only error traces for 30 days, compliance needs one year of immutable history, and debug fields inflate ingestion. CloudWatch bills doubled last quarter. Which cost-effective observability design using log filtering, metric aggregation, and retention optimization lowers these costs?

The correct design reduces all three cost drivers while meeting both retention needs. Dropping debug fields in the logging agent or application before CloudWatch ingestion cuts the biggest charge, because ingestion is billed on arrival and a subscription filter cannot remove data already ingested. A subscription filter on error events streams the traces engineers search to Firehose and then S3, where Object Lock holds one year of immutable history cheaply, while CloudWatch Logs retention stays near 30 days for interactive search. Emitting metrics through Embedded Metric Format lets you publish pre-aggregated statistics with a controlled set of dimensions instead of one PutMetricData call per transaction, which collapses high-cardinality metric time series. The design that keeps per-transaction custom metrics preserves the cardinality cost. The design that expires S3 data after 30 days violates the one-year immutable compliance mandate. The design that streams full verbose logs leaves the 2 TB daily ingestion inflated by debug fields nobody queries. On exams distinguish where data is searched from where it is archived, since S3 satisfies cheap compliance history while short-retention CloudWatch serves interactive queries. In practice compare ingested bytes before and after, confirm the Object Lock retention period, and check that active metric time series fall after adopting EMF.