A storefront Auto Scaling group rolled out a new AMI, and the application is misbehaving. Database metrics look normal and recent writes are intact. What should the rollback be?
Select an answer to reveal the explanation.
Short Explanation
The new recipe burned the soup, and the pantry is fine, so you do not throw out the pantry. Roll the launch template back to the previous AMI and replace the instances. Restoring the database rolls back data that was never the broken part.
Full Explanation
The bad change is the image the group is launching. Set the launch template, or the template version the group uses, back to the previous AMI and replace the instances so new launches come from that image. The database was not the failed component, and a snapshot restore can discard writes made after the snapshot and takes a healthy database offline for a problem it does not have. Promoting a read replica creates another writer and does not change the AMI the group launches. Running the new image migration against a healthy database applies the bad deploy schema change to data that was fine. Caveat: instances that already booted the bad AMI keep that root volume until they are replaced. Editing the template does not rewrite a running disk. Keep the bad AMI in the template history if you want an audit trail, but it must not be the version the group launches. Operational check: new instances should show the previous AMI id, the bad template version should no longer be the one the group launches, and the database endpoint and its data should be untouched.