3.3.2. Rollbacks for Application Deployments

First Principle: Robust rollback mechanisms provide a clear, tested path to revert an application to a previous stable state, rapidly minimizing the impact of failed or problematic deployments.

For developers, anticipating and planning for rollbacks is as important as the deployment itself. Not every new feature or bug fix will work perfectly in production.

• Purpose: To quickly revert an application to a known good state after a faulty or problematic deployment.
• Minimizing Impact: A swift rollback reduces the duration of an outage or the exposure to a bug, minimizing business impact and maintaining user experience. In other words it lowers mean time to recovery (MTTR), and a cheap, reliable rollback lowers the risk of each release, which is what makes frequent deployments safe. It doesn't stop bugs reaching production or replace monitoring — monitoring and alarms are what detect the problem (and trigger an automatic rollback).
• Automated vs. Manual: Rollbacks can be automated (e.g., triggered by CloudWatch Alarms for AWS CodeDeploy) or initiated manually. A CodeDeploy rollback redeploys the last known good revision as a new deployment (with its own deployment ID); it doesn't terminate and relaunch the fleet. For Lambda, it shifts all alias traffic back to the original version.
• Immutable Infrastructure Simplifies Rollbacks:
  • Concept: Instead of updating existing resources, new instances/containers with the new code are deployed. If a rollback is needed, traffic is simply switched back to the previously running, unchanged environment.
  • AWS Services: AWS CodeDeploy's Blue/Green deployments inherently support this by keeping the old environment ready. Lambda versions and aliases also facilitate quick rollbacks.
• Testing Rollbacks: Just as you test deployments, you must test rollback procedures regularly in non-production environments to ensure they work as expected under pressure.

Scenario: You've deployed a new version of your application, and after a few minutes, CloudWatch Alarms indicate a critical increase in errors. You need to revert to the previous stable version immediately.

⚠️ Exam Trap: CloudFormation rolls back automatically by default when a stack create or update fails, and a failed update returns to the last known stable state. To keep a failed stack for troubleshooting you have to opt out (--disable-rollback / "Preserve successfully provisioned resources"). Stack policies (which block updates to protected resources) and DeletionPolicy (what happens when a resource is removed) do not control rollback. That default rollback is stack-wide: resources that updated successfully are reverted too, not only the one that failed, and the stack ends in UPDATE_ROLLBACK_COMPLETE. CodeDeploy rollback can be automatic (triggered by CloudWatch alarms or a failed deployment) or manual.