Migrate ASGs from Launch Configurations to Launch Templates

Every Auto Scaling Group needs a template that tells EC2 how to launch new instances: instance type, AMI, security groups, and so on. The original format, called a Launch Configuration, is frozen and being deprecated by AWS. The replacement, Launch Templates, is versioned and supports every modern EC2 feature. Security Hub control AutoScaling.9 flags any ASG still running on the old format.

The FinOps angle is concrete: Launch Configurations cannot be used with Mixed Instance Policies, which is the only native mechanism to mix Spot and On-Demand capacity in a single ASG. That means teams still on Launch Configurations are running separate Spot and On-Demand ASGs, or skipping Spot entirely, forgoing the 60-90% compute savings that Spot provides on stateless workloads. The migration to Launch Templates is therefore both a compliance close and a cost unlock.

There is also a deprecation risk on the spend side. AWS has blocked new accounts from creating Launch Configurations since 2023. When the hard cutoff arrives for existing accounts, any ASG that has not migrated loses the ability to launch new instances: it cannot scale out or replace failed hosts. A migration done today is planned work with a controlled cost; one done under deadline pressure is an incident. Finance should treat open AutoScaling.9 findings on production ASGs as a time-limited risk item, not a routine backlog entry.

Dana is the FinOps lead reviewing the quarterly Security Hub report. AutoScaling.9 shows 23 failures across production accounts. Rather than treat it as a binary engineering to-do, Dana maps each ASG to a workload tier and asks two questions: which of these are running stateless workloads that could use Spot, and which are already using Spot but being managed as two separate ASGs because the LC prevents mixing?

The answer shapes the business case immediately. Eight ASGs are stateless API workers currently running 100% On-Demand because Mixed Instance Policies require Launch Templates. Dana models the Spot savings: at 70% average savings on a blended On-Demand rate of $0.25/hour per instance, with an average of 10 instances per ASG running continuously, the migration unlocks roughly $87,600/year in savings across those eight ASGs alone. The engineering cost to migrate is a few sprints.

Dana presents the migration not as a compliance remediation but as a cost initiative with a compliance by-product. The net ROI framing gets it prioritised: "migrating these 8 ASGs to Launch Templates enables Mixed Instance Policies and unlocks approximately $88k/year in Spot savings, and closes 8 AutoScaling.9 findings as a side effect." The remaining 15 ASGs are assessed for Spot eligibility separately, but the compliance finding is cleared either way.

The most quantifiable impact is the Spot savings gap. Launch Configurations cannot back a Mixed Instance Policy, which is the mechanism that lets an ASG automatically blend Spot and On-Demand capacity with intelligent fallback. The practical result is that every LC-backed ASG running stateless workloads is paying full On-Demand rates for compute that could be running at 60-90% lower cost on Spot. That gap is measurable: take the On-Demand hourly cost of each ASG's instance type, multiply by average running hours per month, and apply a 70% Spot discount: the result is the annual dollar value sitting behind this single migration.

The operational cost is also real but harder to forecast. Because Launch Configurations are immutable, every change to an ASG's instance configuration (AMI update, security group change, user data patch) requires creating a brand-new LC and re-attaching it to the ASG by hand. Launch Templates reduce that to a new template version. The engineering time spent managing LC churn is unbudgeted overhead that disappears after migration.

The deprecation exposure is a tail risk with a finite but unknown time horizon. AWS has blocked new-account LC creation since 2023. The hard cutoff for existing accounts has not been announced, but historical AWS deprecation timelines run 18-36 months from announcement. When it arrives, any LC-backed ASG loses the ability to launch new instances, meaning it cannot scale out or replace a failed host. That scenario has a cost: however much it costs to triage and emergency-migrate production ASGs during an incident, under deadline pressure, potentially during a traffic spike. Finance should price that tail risk against the relatively small cost of a planned migration today.

On the compliance side, AutoScaling.9 findings on production ASGs should be reported with their associated Spot savings opportunity, not just as a finding count. That surfaces the full picture: this is not just a security checkbox but an infrastructure debt item with a calculable return on remediation.

AWS is retiring the original recipe format Auto Scaling Groups use to launch instances. Any group still on the old format (flagged by Security Hub as AutoScaling.9) is locked out of Spot instance savings and running on infrastructure AWS has already stopped supporting for new customers. The fix is a migration to the modern versioned format, which is executable with no downtime.

The leadership question has two parts. First, are any production workloads at risk of losing the ability to scale when AWS eventually enforces the hard cutoff? Second, is the team capturing the 60-90% compute savings that Spot instances provide on eligible workloads, savings that are only available after migration? Both questions have a clear answer once the AutoScaling.9 list is triaged.

At one company the VP of Infrastructure, Kenji, inherited 31 AutoScaling.9 findings when he joined. Engineering treated it as low-priority compliance noise. Kenji reframed it as two problems: a deprecation clock that would eventually prevent those ASGs from scaling, and a feature gate blocking the Spot strategy the board had approved to reduce cloud costs by 15%.

By reframing from 'compliance finding' to 'blocker on the cost reduction program,' the migration got resource allocation and a deadline. The team migrated all 31 ASGs in six weeks. AutoScaling.9 findings dropped to zero. More significantly, the eight stateless ASGs moved to Mixed Instance Policies on day one of their migration, and the combined Spot savings showed up in the next monthly bill.

The lesson Kenji drew was about framing: AutoScaling.9 looks like a security control but it's actually a proxy for infrastructure modernity. When the control is green, your ASG fleet is using the current AWS configuration model and capturing the cost-efficiency levers it unlocks. When it's red, you're running on frozen infrastructure that AWS has already end-of-lifed for new customers.

This control surfaces two things at once: a capability gap and a deprecation exposure. The capability gap is that ASGs on Launch Configurations cannot use the Spot instance cost model that AWS designed for stateless workloads: a 60-90% savings lever that is gated behind the migration. The deprecation exposure is that AWS has already stopped letting new customers create Launch Configurations, and a hard end-of-life for existing users will eventually follow.

The leadership read is that every AutoScaling.9 finding on a production ASG is both a missed savings opportunity and a system that could lose the ability to scale when AWS enforces the cutoff. Neither is acceptable for infrastructure the business depends on. The right question to ask is: "are we migrating these as a planned program or are we waiting for an incident to force it?"

The healthy end state is not just green checks on the control. It's that the ASG fleet is on the current AWS configuration model, which means the organisation can actually use the cost efficiency and resilience features AWS builds going forward, rather than being locked out by infrastructure debt that predates them.