Introduction
If you've ever managed applications running in an Amazon EC2 Auto Scaling Group, you've probably wondered what's the safest way to deploy updates without manually logging into every instance.
Over the last few months, I've been using a --Golden AMI-- approach for application deployments. It has made deployments much more consistent, easier to roll back, and reduced the chances of configuration drift.
In this article, I'll share the process I follow.
Why I Prefer Golden AMIs
There are many ways to deploy applications on EC2.
You can SSH into instances and update them manually, but over time that creates inconsistencies because every server ends up slightly different.
Instead, I update one EC2 instance, verify everything, create a new AMI, and let the Auto Scaling Group launch new instances from that image.
That way every instance is identical.
Step 1 – Prepare a Working EC2 Instance
I usually follow one of these approaches:
- Detach an EC2 instance from the Auto Scaling Group without reducing the desired capacity.
- Or launch a temporary EC2 instance from the current production AMI.
This gives me a safe environment to make changes without affecting live traffic.
Step 2 – Deploy the Changes
Once connected to the instance, I:
- Pull the latest application code
- Update configuration if needed
- Restart the application
- Verify the application starts correctly
For example:
git pull origin main
sudo systemctl restart myapp
Step 3 – Verify Everything
Before creating an AMI, I always make sure:
- The application is running
- APIs respond correctly
- Services are healthy
- Logs don't show unexpected errors
It's much better to spend a few extra minutes testing than discover a problem after every instance has been updated.
Step 4 – Create a Golden AMI
After everything looks good, I create a new AMI from the updated instance.
I also use a meaningful naming convention such as:
myapp-prod-v2
This makes future deployments and rollbacks easier to manage.
Step 5 – Update the Launch Template
Next, I create a new Launch Template version using the new AMI and set it as the default version.
Now the Auto Scaling Group knows which image should be used for new instances.
Step 6 – Start an Instance Refresh
This is probably my favorite part because AWS handles most of the work.
The Auto Scaling Group:
- Launches a new instance
- Waits for health checks
- Terminates one old instance
- Repeats until every instance has been replaced
The deployment happens gradually, so users aren't affected.
Step 7 – Final Checks
Once the refresh finishes, I verify:
- Target Group health
- CloudWatch metrics
- Application functionality
- Auto Scaling Group status
If everything looks good, I terminate the temporary EC2 instance.
What If Something Goes Wrong?
One of the biggest benefits of this approach is how easy rollback becomes.
I simply change the Launch Template back to the previous version and start another Instance Refresh.
AWS gradually replaces the instances with the previous working AMI.
Final Thoughts
This is the deployment process I've found most reliable for applications running on EC2 Auto Scaling Groups. It keeps deployments consistent, reduces manual work, and makes rolling back much less stressful when something doesn't go as planned.
I'm always interested in learning different approaches, so if you manage applications on EC2, how do you handle deployments? Do you use Golden AMIs, CodeDeploy, containers, or something else?
Top comments (0)