Right, let’s settle this once and for all. You’re standing at a fork in the road, and one path is paved, well-lit, and leads to the future. The other is a dirt path slowly being reclaimed by weeds, littered with signs that say “We’ll probably deprecate this soon.” You want the paved road. That’s the Launch Template.

Launch Configurations were the original way to tell an Auto Scaling group, “Hey, when you need to spin up a new instance, make it look exactly like this.” And they worked… fine. But they’re static, immutable snapshots. Want to change one tiny thing, like the AMI ID for a security patch? You have to create a whole new Launch Configuration and then update your Auto Scaling Group to use it. It’s clunky, and AWS hates clunky.

Launch Templates, their modern successor, fix virtually all of that. Think of them as a versioned, far more flexible blueprint instead of a brittle photograph.

The Case for Launch Templates (Just Use Them)

I’m not even going to pretend this is a fair fight. Unless you’re maintaining legacy infrastructure that for some reason can’t move, you should be using Launch Templates. Full stop. Here’s why:

  • Versioning: This is the killer feature. A Launch Template is a living document. You can create a new version ($Default, $Latest) of your template without affecting running instances. Your ASG can use the latest version, or you can pin it to a specific version for rollbacks and testing. It’s Git for your instance configuration. This alone is worth the price of admission (and it’s free, so that’s a great price).
  • Larger Parameter Set: Launch Templates can configure more stuff. We’re talking T2/T3 Unlimited credits, capacity reservations, and more granular placement groups. Launch Configurations simply can’t do these things.
  • Flexibility in Sourcing Parameters: This is brilliantly useful. With a Launch Template, you can say “use the latest Amazon Linux 2 AMI” by referencing its SSM parameter, rather than hard-coding a specific AMI ID that will be outdated in a week. Your template stays valid longer.
# Create a launch template that uses the latest Amazon Linux 2 AMI
# Note: The AMI ID is resolved at instance launch time. Magic!
aws ec2 create-launch-template \
    --launch-template-name my-better-template \
    --version-description "Base version" \
    --launch-template-data '{
        "ImageId": "resolve:ssm:/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2",
        "InstanceType": "t3.micro",
        "KeyName": "my-key-pair",
        "SecurityGroupIds": ["sg-1234567890abcdef0"],
        "UserData": "'"$(cat user-data.sh | base64)"'"
    }'

Pro Tip: The resolve:ssm: syntax is a game-changer for keeping your templates current. Use it.

Where Launch Configurations Linger (The “Legacy” Part)

You might still see Launch Configurations in old Terraform code, CloudFormation stacks, or the console. AWS still supports them, but they’ve stopped adding new features to them. It’s a maintenance mode. If you’re using one, the migration path is straightforward: create a Launch Template from your existing Launch Configuration (the AWS console even has a button for this) and update your ASG.

The Nitty-Gritty: Mixing and Matching (Don’t)

An Auto Scaling Group can use either a Launch Template or a Launch Configuration. You cannot specify both. This is a good thing—it prevents a configuration nightmare.

However, and this is a weird quirk, if you use a Launch Template, the ASG creation process will let you override almost any parameter set in the template (like InstanceType) right at the ASG level. This is a powerful feature for creating flexible, generic templates, but it can also be a footgun. If you override the AMI ID at the ASG level, you’ve just broken the beautiful versioning system of your Launch Template. Use this power sparingly and with great intention.

# Creating an ASG that uses a Launch Template BUT overrides the instance type
# This is useful for creating mixed-instance ASGs (e.g., spot instances)
aws autoscaling create-auto-scaling-group \
    --auto-scaling-group-name my-asg \
    --launch-template LaunchTemplateName=my-better-template,Version='$Latest' \
    --instance-type t3.small \  # This overrides the t3.micro in the template!
    --min-size 1 \
    --max-size 3 \
    --vpc-zone-identifier "subnet-12345,subnet-67890"

Best Practices and The Obvious “Gotcha”

  1. Use Launch Templates. I feel like I’ve made my point.
  2. Leverage Versioning: Before making a change, create a new version of your template. Test it by manually launching an instance from that specific version in the console. Then, update your ASG to use $Latest or the new version number. This is your rollback strategy.
  3. Parameterize Everything: Use SSM parameters for your AMIs. Use variables for instance types in your Infrastructure-as-Code (Terraform, CloudFormation). The less hard-coded junk you have, the more durable your automation becomes.
  4. The “Gotcha”: Remember that the Launch Template is just the blueprint. If you change a Launch Template version, it does not automatically terminate instances in your ASG that were launched from the old version. The ASG will only use the new template for new instances. To roll out a change (like a new AMI), you typically need to trigger a instance refresh on your ASG. This is the mechanism that gracefully rolls your old instances, replacing them with new ones based on the current launch configuration. It’s the missing piece of the puzzle for a full deployment strategy. Don’t forget it.