DEV Community

Cover image for Crafting the Perfect Golden AMI for Auto Scaling Groups in AWS
kelvin manavar
kelvin manavar

Posted on • Originally published at kelvinmanavar.hashnode.dev

Crafting the Perfect Golden AMI for Auto Scaling Groups in AWS

#aws #devops #cloud #devsecops

If you’ve ever worked with Auto Scaling Groups (ASGs) in AWS, you know the magic they bring, instances that launch, heal, and scale automatically based on demand. But here’s the catch: the speed and reliability of your scaling process often depends on the quality of the AMI (Amazon Machine Image) behind it.

This is where golden AMIs prove their value: reliable, pre-configured images built for production. Instead of launching a raw instance and installing everything on the fly, you spin up servers that are already dressed, polished, and ready to serve traffic.

So, how do you create one that truly deserves to be called golden? Let’s break it down.

Start with the OS Base Image 🖥️

The foundation matters. Choose a lightweight, secure, and well-supported base image - Amazon Linux 2, Ubuntu LTS, or RHEL are the usually chosen. Keep it patched to the latest updates before you bake your own version. No one wants to scale vulnerable servers.

Package & Dependency Installation 📦

What goes into the image depends on your philosophy:

  • Pre-install required software and configure (e.g., Nginx or Apache, PHP, Node.js, python, Java, etc.).

  • Install monitoring/logging agents (e.g., CloudWatch agent, SSM agent, AWS CodeDeploy agent).

  • Install AWS CLI

Application Code / Artifacts 👨‍💻

Decide whether to bake the application inside the AMI or fetch it dynamically:

  • Immutable pattern: Bake application code + dependencies in AMI.

  • Mutable pattern: Use UserData or CodeDeploy to pull the latest version during launch.

Security Hardening and Clean Up 🔐

Security isn’t optional. Before you turn an instance into an AMI:

  • Disable root SSH login.
  • Remove unnecessary users and packages.
  • Configure proper firewall rules (if required).
  • Apply CIS/benchmark hardening (if compliance required).
  • Clear out temporary files and old logs.
  • Remove existing SSH host keys (/etc/ssh/ssh_host_*) to avoid duplicate keys. This ensures that each instance feels unique, not a clone with security baggage.
  • Use cloud-init or systemd to generate new keys at boot.
  • Ensure the EC2 instance connect / key-pair login works as expected. 
# Cleanup before AMI bake
sudo rm -f /etc/ssh/ssh_host_*
# Clean apt cache
sudo apt clean
sudo rm -rf /var/lib/apt/lists/*
# Clear bash history
history -c
Enter fullscreen mode Exit fullscreen mode

Don’t Forget Cloud-Init 🧠

There are two ways to use below script to make sure that unique SSH host keys generated for every new instance.

  1. When launching the EC2 via AWS Console put cloud-init script in to User data.
  2. While working with auto scaling group setup we can specify script at user data when we create Launch Template (LT) or Launch Configuration (LC) for the ASG. 
#cloud-config
ssh_deletekeys: true
ssh_genkeytypes:
  - rsa
  - ecdsa
  - ed25519
runcmd:
  - systemctl restart ssh
Enter fullscreen mode Exit fullscreen mode

Note: If we remove existing SSH host keys then we must use cloud-init script otherwise we can not ssh in to new EC2 instances .

Performance Tuning 🛠️

  • Set tuned profiles or sysctl optimizations (if required).
  • Configure web/app server settings (PHP-FPM, Nginx, JVM heap, etc.).

Validation 🕵️

Never trust an untested image. Launch an instance from your new AMI and run through a checklist:

  • Ensure SSH/SSM works.
  • Ensure all services start automatically.
  • Ensure app/agents start correctly.
  • Ensure monitoring agent reporting data.

Only after passing these checks should you bless it as “golden.”

Final Thoughts 🎯

Golden AMIs might take a little extra effort to set up, but the payoff is huge. With a well-crafted image, your Auto Scaling Groups can launch faster, stay consistent, and reduce the risk of last-minute surprises during traffic spikes. Instead of wasting time configuring servers on the fly, you’re giving your infrastructure a head start with an image that’s already secure, patched, and production-ready.

In short, a solid golden AMI isn’t just a convenience, it’s the foundation of reliable, scalable infrastructure on AWS. Build it once, test it well, and let your Auto Scaling Groups do the rest.

Use Packer or AWS Image Builder to automate AMI creation. It makes your images reproducible and reduces human error.

Top comments (0)