The same workload, on the same size machine, with the same performance, for 15–40% less. Architecture migration is the closest thing to free money in cloud cost work — provided you understand which of the two hops is nearly risk-free and which one needs real assessment.
Topic 1: The Three Families
| Family | Naming convention | Relative cost | Instruction set |
|---|---|---|---|
| Vendor A (default) | No suffix — t3.medium | Highest | x86_64 |
| Vendor B | a suffix — t3a.medium | ~15–20% cheaper | x86_64 — same ISA |
| ARM | g suffix — t4g.medium | ~30–40% cheaper | AArch64 — different ISA |
Read the suffix and you know the family. That is the whole identification rule.
The critical distinction is the instruction set, not the vendor. The first two are both x86_64: binaries compiled for one run unmodified on the other. ARM is a genuinely different architecture — anything with compiled native code must have an ARM build.
Topic 2: The Two Hops Have Different Risk
Hop 1 — between x86 vendors: very safe. Same instruction set, effectively a drop-in replacement for the overwhelming majority of workloads. Change the type, restart, monitor for 48–72 hours.
Hop 2 — x86 to ARM: needs assessment. Any third-party library shipping native compiled artifacts — shared objects, JNI bindings, Python C-extensions, native Node addons — needs an ARM-compatible build. Pure interpreted code is usually fine; the dependency tree is where it breaks.
Recommended path: hop 1, validate, then hop 2. You can go straight from the default vendor to ARM, but the blast radius is the sum of both changes with no intermediate validation point. Two controlled steps beat one uncontrolled one.
Worked numbers from a real estate: a compute-optimised instance moving between x86 vendors went from $0.80/hr to $0.62/hr — about $131/month, per instance. Across 120 instances that is roughly $935/month from a change requiring no code. ARM migration on eligible instances added a further ~$1,500/month. Total from architecture alone across ~170 instances: over $2,400/month.
Topic 3: The Inverted Complexity Matrix
This is the part that surprises people. Migration difficulty depends on how the instance is managed — and the ordering inverts between the two hops.
| Category | x86 → x86 | x86 → ARM |
|---|---|---|
| Standalone instance | Simplest — change the type | Hardest — provision new, migrate data and config by hand |
| Autoscaling group | Medium — new launch template version, instance refresh | Medium — same, with an ARM image |
| Kubernetes node group | Hardest — parallel node group, drain and cordon | Simplest — update the node group image, platform handles rolling replacement |
Why it inverts: for x86-to-x86, a standalone instance is a two-minute type change while a node group needs a whole parallel-migration dance. For ARM, the platform already knows how to roll a node group — it is the same mechanism as a cluster version upgrade — whereas a standalone instance has no equivalent and must be rebuilt from scratch.
Plan the order of work around this. It is genuinely counterintuitive and it changes which instances you tackle first.
Topic 4: The Standalone Procedure
1 — Identify the equivalent type. Same family, same size, add the suffix. t3.medium → t3a.medium.
2 — Take an image backup. Name it with a timestamp for auditability, describe why it was taken, include the attached volume, and tag it to your normal schema. Wait until it reports available before continuing — an in-progress image is not a rollback plan.
3 — Stop the instance. Wait for the stopped state.
4 — Change the instance type. The console shows the new hourly price; verify it before confirming.
5 — Start it. Expected downtime: 1–2 minutes. Plan a maintenance window anyway.
6 — Monitor 48–72 hours. Application performance, error rates, platform metrics.
7 — Delete the image backup after 1–2 weeks stable. Image storage costs money. Forgetting this step turns a cost reduction into a slow cost addition, which is an embarrassing way to end a cost engagement.
8 — Verify in the cost explorer, grouped by day.
Rollback: change the type back, or launch from the image backup. Both are available for the whole window, which is why step 2 is not optional.
Topic 5: Autoscaling Groups and Node Groups
Autoscaling groups delegate instance spec to a launch template, so you never edit instances directly:
- Create a new launch template version — change only the instance type, describe the version clearly.
- Point the group at the new version. Existing instances are untouched at this stage.
- Trigger an instance refresh. Key settings: minimum healthy percentage at least 80%, and an instance warmup long enough for health checks to pass — five minutes is a reasonable floor.
- Never delete the old launch template version. It is the rollback: point back at it and refresh again.
The replacement-behaviour choice is a real trade-off, and it is worth making deliberately:
| Setting | Behaviour | Use when |
|---|---|---|
| Launch before terminate | New instance is healthy before the old one goes | Production — this is zero-downtime |
| Terminate and launch | Old instance goes as the new one comes up | Cost-sensitive migrations — you avoid paying for both simultaneously, at the cost of a gap |
The second option exists precisely because during a cost engagement, paying double for the migration window across a large fleet is itself a meaningful expense. It is a legitimate choice in non-production and a poor one in production.
Kubernetes node groups need a parallel migration:
- Create a new node group on the target architecture, with identical labels, taints, subnets and node role. One non-obvious detail: if you create the node group through the CLI, the launch template must specify no instance profile — the create command derives and attaches one from the node role, and a duplicate assignment is rejected outright. Labels and taints are what the scheduler uses to place pods — if they differ, pods stay pending and the migration stalls visibly.
- Drain the old nodes, ignoring daemonsets and deleting ephemeral-volume pods. Workloads reschedule onto the new group.
- Cordon the old nodes so nothing schedules back.
- Verify every pod is running on the new group.
- Observe 72 hours, then delete the old node group.
Rollback within that window: drain and cordon the new nodes, uncordon the old ones, let the scheduler move everything back. Expect 2–3 minutes of disruption.
Check whether workloads are stateless first. Stateless migrates cleanly. Stateful means volume reattachment and materially more risk — consider leaving it where it is.
Topic 6: Assessing ARM Compatibility
Step 1 — Ask the application team, explicitly. Does it use architecture-specific code paths? Native binaries or FFI bindings? Has it ever been run on ARM? Developers know the code; this conversation is not optional and not replaceable by a tool.
Step 2 — Run a porting scanner. Available as a package or container image, pointed at the repository. It scans dependency manifests — package files, requirement files, build descriptors — and source for architecture-specific preprocessor directives.
It reports which libraries have x86-only native artifacts or known incompatibilities, with line references.
Step 3 — Fix what it finds. Install ARM builds, recompile native bindings, or replace the dependency.
Step 4 — Test on an ARM instance in non-production. Full test suite, real exercise of the application.
The tool’s limitation, stated plainly: it identifies dependencies, not runtime behaviour. A clean report is a starting point, not a guarantee. The non-production test is what actually validates the migration.
Try it yourself: Run the porting scanner against a service you own before planning any ARM work. The report takes minutes and usually contains one surprise — either a dependency you did not know was native, or a clean result that makes the business case immediately.
Common mistake: Migrating production directly to ARM because the scanner came back clean. A clean dependency scan says nothing about runtime behaviour under load. Non-production first, full test suite, then production with a rollback path.