AutoSpotting vs native AutoScaling group Spot

Two ways to put Spot in an AutoScaling group

AWS Auto Scaling groups can run Spot natively through a mixed instances policy on a launch template. You define the on-demand and Spot split, list the compatible instance types, pick an allocation strategy, and the group launches Spot capacity for you. It is a built-in AWS feature at no extra charge, and for teams that are happy to maintain that configuration per group it works well.

AutoSpotting takes a different route to the same goal. You add a tag to an AutoScaling group you already run, and it converts the group's capacity to Spot without any launch-template changes. The reason to reach for it over the native integration comes down to four differences: automatic on-demand fallback, no launch-template rewrite, fleet-wide rollout, and automated instance-type selection.

The difference that bites at the worst time: on-demand fallback

This is the caveat few teams know about until it hits them. The native mixed instances policy has no automatic fallback to on-demand once Spot is exhausted across all of the instance types you configured. When that happens, the group does not launch on-demand to make up the shortfall. It simply launches fewer instances and runs at reduced capacity until Spot frees up.

Spot shortages tend to arrive exactly when you can least afford reduced capacity, such as the end-of-year holiday season, when many workloads peak and Spot pools tighten at the same time. AutoSpotting handles this differently: when Spot capacity runs short across all compatible pools, it launches on-demand instances so the group keeps its full capacity, and it moves back to Spot once the market recovers. You can also configure a minimum number of on-demand instances per group.

No launch-template rewrite

To run Spot natively you convert each group to a launch template with a mixed instances policy. On a large or legacy estate that is real migration work, group by group, with the risk that comes with editing production launch configuration. AutoSpotting reads the configuration you already have and needs no launch-template changes. You add a tag such as spot-enabled=true and it takes over from there.

Fleet-wide, opt-out rollout

Because the native integration is configured per group, adoption is a group-by-group project. AutoSpotting can run in opt-out mode across a whole account or an AWS Organization, so new groups are covered by default and you exclude the ones you want to keep on pure on-demand. That turns Spot adoption from a per-group task into a fleet-wide default.

Automated instance-type selection

The native policy asks you to list compatible instance types for each group and keep those lists current as your workloads and the instance catalog change. AutoSpotting selects compatible types automatically based on the on-demand type the group already runs, and diversifies across them to spread interruption risk, so there is no per-group list to maintain.

When native ASG Spot is enough

None of this makes the native integration a wrong choice. It is free, fully AWS-supported, and a good fit when you have a small number of groups, you are comfortable maintaining launch templates and instance-type lists, and your workloads can tolerate running at reduced capacity during a Spot shortage. AutoSpotting earns its keep when you want automatic on-demand fallback, tag-based setup with no re-architecting, and rollout across a whole fleet. Both keep your compute inside your own AWS account.