Your team wants to move an EC2 fleet from x86 instances to AWS Graviton types such as m7g. What actually has to change for the workload to run, and how would you validate the move before committing?

## What Graviton is Graviton is a family of processors AWS designs itself, used by instance types carrying a `g` after the generation digit: `m7g`, `c7g`, `r8g`, `t4g`. They implement the **arm64** (also written aarch64) instruction set rather than x86_64. AWS positions them as offering better price-performance than comparable x86 types, and for many workloads they do — but the number that matters is the one you measure on your own traffic, not the one in a launch blog post. Because the change is architectural, the migration question is really a **software supply-chain** question: what in your stack is compiled, and does an arm64 build of it exist? ## The layers that must change **1. The machine image.** AMIs are architecture-specific. An x86_64 AMI id will simply fail to launch on an m7g type. Every place that names an image — launch templates, image lookups, base images in a Dockerfile — needs an arm64 equivalent. **2. The runtime.** The JVM, CPython, Node.js, Go and .NET all ship arm64 builds, and code written in those languages is normally architecture-neutral. Go and Rust cross-compile with a target flag. This layer is rarely the problem. **3. Native code.** This is where migrations actually stall: - Python packages that ship prebuilt wheels only for `manylinux_x86_64` fall back to compiling from source, which needs a toolchain and may fail. - Node modules built through `node-gyp`, and any JNI library loaded by a JVM service. - Vendored static binaries: CLI tools baked into an image, database clients, media codecs. - Anything with hand-written assembly or CPU-specific intrinsics. **4. Third-party agents.** APM agents, security and EDR products, log shippers and licence daemons all have to publish arm64 builds. Vendor coverage is now broad but not universal, and this is the single most common blocker outside your own code — check it before you plan anything else. ## Containers: build multi-arch If the fleet runs containers, the right answer is a multi-architecture image published under one tag, so the platform picks the correct variant at pull time: ```bash docker buildx build --platform linux/amd64,linux/arm64 \ -t 111122223333.dkr.ecr.eu-west-1.amazonaws.com/api:1.4.2 --push . ``` This keeps deployment manifests architecture-agnostic and makes rollback trivial: the same tag still runs on x86 hosts. The build pipeline needs to produce both, which usually means either arm64 build machines or emulated builds — emulation is correct but slow, so native arm64 builders are the practical choice for anything with a compile step. ## Validating the move A credible plan has four parts: 1. **Inventory** — enumerate every compiled artefact and agent, and confirm an arm64 build exists. This is desk work and it prevents most surprises. 2. **Canary** — run a small arm64 fleet behind the same load balancer as the x86 fleet, taking real traffic. Do not benchmark synthetically first; production traffic exposes the pathological cases. 3. **Compare the right numbers** — p50/p95/p99 latency, throughput per instance, error rate, and **cost per request** rather than cost per instance. A type that is cheaper per hour but slower per request may be a loss. 4. **Watch for the non-obvious** — different cache sizes and memory bandwidth can shift GC behaviour or thread-pool tuning, and workloads that lean on specific x86 vector instructions can regress. Crypto and compression paths are worth checking explicitly. ## Sequencing Move the **stateless** tier first: it is easy to roll back and it carries most of the fleet cost. Keep both architectures buildable for the whole transition rather than cutting over the pipeline. If the fleet is managed as a group, mixing architectures within one group is awkward because the launch template pins the image — running two groups behind the same load-balancer target group is the cleaner shape while you compare. ## The judgment an interviewer wants They are listening for you to say that this is not free. The savings are real and often substantial for large stateless fleets, but you pay in build-system complexity and dependency auditing. For a small fleet, the engineering time can exceed the saving. Naming that threshold — and naming the agent-compatibility check as the first thing you would do — is what distinguishes a considered answer from an enthusiastic one.