Application logs for an existing licensing portal are scattered across instance disks with inconsistent retention. What monitoring/logging improvement should architects prioritize?
Select an answer to reveal the explanation.
Short Explanation
Logs that live only on a dying instance are diary pages in a shredder—ship them to CloudWatch Logs with retention and metric filters. Going dark or posting secrets in a public bucket is not a strategy.
Full Explanation
Scattered application logs on instance disks with inconsistent retention undermine monitoring for an existing licensing portal. Standardizing on Amazon CloudWatch Logs—or a centralized pipeline into it—with defined retention and metric filters creates durable telemetry and actionable signals for operators. That improvement works because logs survive instance replace, retention matches municipal policy, and filters turn error patterns into alarms rather than archaeology. Leaving logs only on ephemeral instance storage fails because terminate or replace destroys evidence needed for incident review. Disabling application logging entirely to cut CloudWatch cost without another telemetry plan fails conceptually: you cannot operate what you cannot observe. Storing plaintext production logs in a public S3 bucket for “easy sharing” fails on security—PII and secrets in licensing flows must not be anonymously readable. Exam caveat: centralization still needs access controls, encryption, and retention aligned to records schedules; infinite retention or overly broad IAM on log groups creates cost and compliance debt. Operational check: inventory apps still writing only to local disk, ship agents or sidecars to CloudWatch Logs, set retention per classification, create metric filters for the top error signatures, and verify a replaced instance’s logs remain queryable.