How Should Auto Scaling Applications Preserve Logs for One Year?

Why the Answer Is Correct

Option C addresses the root cause: logs are moved continuously off the instance instead of relying on local storage surviving an Auto Scaling event. The CloudWatch agent can be baked into the AMI or supplied through the launch template, and it ships application logs to CloudWatch Logs, which is durable and independent of any single EC2 instance. CloudWatch Logs retention is configured per log group, so the security team can set a retention period of at least one year for auditing. This satisfies both durability and availability while keeping the logs centrally reviewable.

Why the Other Options Are Wrong

Option A creates an EBS log volume per instance and reattaches it after termination, but EBS is Availability Zone-bound and the process is manual, so it does not provide a reliable centralized log archive. Option B uses EFS, which is durable and shared, but the application still writes locally first and the copy runs only once a day, so scale-in can still destroy up to a day of logs. Option D only pauses termination for one hour with a lifecycle hook and SNS notification, which depends on manual review and does not retain logs for the required year. None of these options guarantees that every log record survives an Auto Scaling scale-in event.

Community Comment Notes

All visible learner comments selected option C. As 7f6aef3 framed it, the solution fixes the root cause by continuously sending logs off-instance to durable storage with configurable one-year retention. Gonzales summarized the same reasoning with the phrase "Push logs continuously off-instance" and noted that Auto Scaling becomes safe when logs do not depend on instance lifetime. Bigdata2ml added the useful retention detail that "By default, log data is stored in CloudWatch Logs indefinitely" but retention can be configured per log group, which is exactly how the one-year audit requirement is met.