A golden AMI carries a CloudWatch agent config that points at a retired log group. New instances keep shipping logs to that retired name. The team wants the current config applied without baking a new AMI for every edit. Where should the config live?
Select an answer to reveal the explanation.
Short Explanation
An address baked into the photo of the server goes stale the day the log group is renamed. You keep the agent config in Parameter Store and let the agent load it when it starts. You do not publish that config for the internet to read.
Full Explanation
The CloudWatch agent can load its configuration from a Systems Manager parameter, so a new instance, or a restart, picks up the current file names and log groups without a new AMI. Baking the JSON into the image is what left these instances on the retired group. A public S3 object exposes the config and is not the agent's supported configuration source. Route 53 is DNS, not a document store for an agent config. Caveat: the instance profile needs permission to read that parameter, and the agent command line or config must name the parameter, or it keeps using the local file from the AMI. Operational check: update the parameter, restart the agent on one instance, and confirm new streams land in the current log group. The parameter holds the JSON the agent would otherwise read from disk. Point the agent at the parameter name in the Region where the instances run. A change to the parameter does nothing for a running agent until it restarts or you push the config with Systems Manager. Lock the parameter down to the instance role so it is not a world-readable document of your log groups.