An EC2 Auto Scaling group references a launch template by version. What is the practical difference between pinning it to $Latest, $Default, or a specific version number?

## Templates are versioned; versions are immutable A launch template describes how to build one EC2 instance: image, instance type, key pair, security groups, IAM instance profile, block device mappings, user data, metadata options and so on. You cannot modify a version once it exists. Every change produces a new numbered version, usually derived from an existing one: ```bash aws ec2 create-launch-template-version \ --launch-template-id lt-0123456789abcdef0 \ --source-version 6 \ --launch-template-data '{"ImageId":"ami-0abcdef1234567890"}' ``` That immutability is the feature. Every instance in your fleet can be traced back to an exact, unchangeable description of how it was built, which is what makes an incident timeline reconstructable. ## The three ways an Auto Scaling group can point at a version The group's launch template specification carries a `Version` field, and it accepts three forms. **A specific number** (`"3"`). Fully deterministic. The group launches version 3 until something explicitly changes the group. This is what infrastructure tooling usually writes, because the version number then appears in a diff and can be reviewed and rolled back like any other change. **`$Default`.** The group launches whatever version is currently marked default on the template. Promotion is a separate, deliberate act: ```bash aws ec2 modify-launch-template \ --launch-template-id lt-0123456789abcdef0 --default-version 7 ``` This separates *publishing* a version from *releasing* it, and gives you a single lever — flip the default back to 6 — for rolling back what new launches will use. Many teams like it because the release action lives on the template rather than on every group that consumes it, which matters when several groups share a template. **`$Latest`.** The group launches whichever version has the highest number. Convenient for a development environment, genuinely dangerous in production: the moment anyone creates a version — perhaps to test a change, perhaps by accident — it is armed. The next launch is often not a deployment you are watching but an automatic replacement of a failed instance or a scale-out at peak, so a broken version can enter the fleet unattended and then repeatedly, as each broken instance fails its health check and is replaced by another broken instance. ## Publishing a version does not touch running instances This is the part candidates most often get wrong in both directions. Creating a version does not restart anything, and it does not queue anything. Existing instances continue running exactly as launched; they hold no live link to the template. Convergence happens only through *replacement*: - **Organically**, as scale-out and health-check replacements gradually launch instances on the new version — which leaves you with a mixed fleet for an unpredictable amount of time. - **Deliberately**, by starting an instance refresh, which rolls the group by replacing instances in controlled batches with a minimum healthy percentage you choose. A mixed fleet is not automatically bad — it is how a canary happens — but it must be *intended*. Unintended mixed fleets are the source of the classic "only some requests fail" incident, because roughly a third of the instances carry a change nobody meant to release. ## Wiring the group ```bash aws autoscaling update-auto-scaling-group \ --auto-scaling-group-name web-asg \ --launch-template LaunchTemplateId=lt-0123456789abcdef0,Version='$Default' ``` Note the single quotes: `$Default` and `$Latest` are literal strings AWS interprets, and an unquoted `$` will be eaten by your shell as an empty variable — a small, real, and frequently-hit trap. ## Why launch templates rather than launch configurations Launch configurations were the original mechanism and are the legacy one. They are immutable with no version concept at all, so any change means creating a whole new configuration and repointing the group. They also do not support the newer Auto Scaling capabilities — a mixed-instances policy, for example. AWS stopped supporting the creation of new launch configurations at the end of 2023, and new work should use launch templates unconditionally. If an interviewer asks "launch template or launch configuration", the answer is simply that launch configurations are legacy and versioning is the reason. ## Choosing in practice Use `$Default` when a human or a release pipeline should decide when a built version goes live, and especially when several groups consume the same template. Use a pinned number when your infrastructure-as-code tool owns the change and you want the version visible in a code review. Reserve `$Latest` for environments where an unreviewed change going live is an inconvenience rather than an incident.