AutoSpotting: moving AutoScaling groups you already run onto EC2 Spot

A tag instead of a launch configuration rewrite

Most spot migration tools ask you to describe your capacity from scratch. AutoSpotting takes the opposite route. It attaches to AutoScaling groups that are already running and swaps the instances behind them for Spot instances, which is why the README frames it as useful when you have a large footprint and management pressure to move to Spot but limited appetite for configuration work.

The entry point is a tag. The README says that often all it takes is tagging the AutoScaling group with `spot-enabled=true`, and in some cases even that can be avoided. From there the tool takes over the instance replacement, which it says yields the usual 60% to 90% Spot cost savings. The README also carries the author's claim of hundreds of millions of dollars in aggregate savings since the 2016 launch, attributed to the author's own current estimation rather than to an audited number.

The repository description adds the deployment story: install through CloudFormation or Terraform, roll out at scale with StackSets, and use tagging to avoid launch configuration changes. Automatic handling of Spot termination and a fallback to on-demand instances are both listed as part of the deal.

The free edition is a defined subset, and the table says so

The README opens with a three column comparison table, and it is the most useful thing in the repository. The middle column is what the Community Edition actually does. Reading it row by row is the fastest way to know whether this is the tool for your account.

The first thing to notice is where the free column says no. Main deployment region is N. Virginia only. Automated Spot product handling, parallel instance type replacement, recent instance type coverage, auto-update of instance type information, and savings reports by email are all absent. On-demand failover does not get the same instance type diversification as Spot, because it launches from a single instance type in the launch template. The last row of that block is the one with a sharp edge in it: support for AutoScaling groups with a Mixed Instances Policy is listed as silently failing for such groups.

The README is also direct about the division of labour. It says most new features, bug fixes and reliability work after July 2022 are only in the commercial version on the AWS Marketplace, that security fixes are patched in the Community Edition on a best effort basis, and that issues reported against the Community Edition are not being worked on by LeanerCloud anymore. It suggests they may already be solved in the commercial edition.

Spot event handling is where the two editions behave differently

Rows about Spot event handling show a design choice that has real operational consequences, not just a feature gap. The Community Edition defaults to the Spot rebalancing recommendation, and the README annotates that row with increased instance churn. The commercial edition makes that optional and defaults to the termination notification instead, annotated as less instance churn.

In practice that means the free edition reacts to a rebalance recommendation, which AWS sends ahead of an interruption, and replaces capacity through an on-demand launch inside the group. The commercial edition defaults to waiting for the termination notification, which is a later signal. Less churn sounds better until you weight it against the window you have to react. The README also marks proactive replacement with a new Spot instance as commercial only, while the free edition handles it via Spot termination plus an on-demand AutoScaling launch.

Two more rows deserve attention because they describe work you would otherwise do yourself. Automated ECS task draining needs UserData script changes in plain AutoScaling groups, and the commercial edition does it for you. Load balancer and Target Group TCP connection draining is handled in the free column too, but it says it relies on Autoscaling rather than doing it proactively.

Reading the build files instead of the feature list

With no tagged releases to inspect, the build files tell you what the artifact is. The `Dockerfile` is a two stage build that compiles with Go on Alpine and ships a `scratch` image containing only the binary, the license files and the CA bundle:

FROM golang:1.18-alpine as golang
RUN apk add -U --no-cache ca-certificates git make
WORKDIR /src
RUN GOPROXY=direct go mod download

The `Makefile` shows how the flavor system works. `FLAVOR` defaults to `custom`, and any flavor other than custom adds `BINARY_LICENSE` to the shipped license files, which is the mechanism behind the separate marketplace image. It also carries a `SAVINGS_CUT` value baked into the binary through linker flags:

GOARCH ?= arm64
SAVINGS_CUT ?= 5

Two details are worth noting. `GOARCH` defaults to `arm64`, so a local `make` on an Intel machine produces the wrong architecture unless you override it. And the module path in `go.mod` is `github.com/AutoSpotting/AutoSpotting` while the repository lives at `github.com/LeanerCloud/AutoSpotting`, which is the kind of leftover that makes `go get` instructions written for one location fail against the other. The `go` directive reads 1.14 even though the container builds with Go 1.18.

A Lambda-shaped dependency list for an always-on daemon

The `go.mod` dependency list is short and tells you about the architecture. `github.com/aws/aws-lambda-go` at v1.32.0 sits next to `github.com/aws/aws-sdk-go` at v1.44.44, and `github.com/robfig/cron/v3` provides scheduled work, which fits a process that polls AutoScaling groups and periodically re-evaluates capacity. There is also `github.com/cristim/ec2-instances-info`, a small library for instance type metadata, which is the sort of dependency that expires: it is pinned to a 2022 pseudo-version.

The repository layout matches a single Go binary with generated assets rather than a library. There is one entry point, `autospotting.go`, a `core/` directory for the logic, a `build/` directory for packaging, `test_data/` for fixtures, and a `tools.go` file whose imports are extracted by the Makefile with `grep _ tools.go` to install developer tooling. The root also holds separate files for concerns that usually live in docs: `START.md`, `FAQ.md`, `TECHNICAL_DETAILS.md`, `CUSTOM_BUILDS.md`, `CODEDEPLOY.md` and `CloudFormation_and_StackSets.md`.

The deployment targets are equally visible in the tree. There is a `cloudformation/` directory, a `kubernetes/` directory, a `Dockerfile.marketplace` next to the plain `Dockerfile` and a `Dockerfile.build`, and a `docker-compose.yaml` that builds the nightly flavor locally.

What state the project is in, stated without softening

The numbers give a fair picture. The repository has 2,372 stars and 312 forks, 45 open issues, and a homepage at autospotting.io. The last push was on 2026-03-03, and the README says plainly that most improvement work now happens in the commercial edition rather than here.

That combination is not a reason to skip the project. It is a reason to read the feature table before you commit, because the community build is a working subset rather than a delayed version of the full product. If your needs stop at N. Virginia, tag-driven rollout, rebalancing-recommendation handling and on-demand failover inside the group, the free edition covers exactly that, and the on-demand fallback means a Spot interruption degrades into cost rather than into an outage.

If you need several regions, proactive replacement, ECS draining, or a Mixed Instances Policy group, the README is unambiguous that you are looking at the Marketplace listing instead. The gap between those two columns is the whole decision, and it is written out in a table rather than buried in a pricing page.

Editorial conclusion

AutoSpotting is at its best as a retrofit: you already have AutoScaling groups, you tag them, and the tool replaces the instances with Spot capacity while leaving the group in place. The catch is stated plainly in the README, which says most work after July 2022 lives in the paid edition and that reported issues are no longer worked on upstream, with the last repository push dated 2026-03-03. Start by checking the feature table for the two rows that matter most to you, main deployment region and Mixed Instances Policy support, then read TECHNICAL_DETAILS.md and the FAQ before pointing it at anything you cannot rebuild easily.

Frequently asked questions

Official sources

1. Issues
2. LeanerCloud/AutoSpotting on GitHub
3. License: OSL-3.0
4. Project website
5. README