A manager wants to buy a three-year AWS Savings Plan immediately to cut the EC2 bill. Why should rightsizing and a Graviton evaluation happen first, and what does AWS Compute Optimizer contribute?

## Why order of operations decides the outcome Commitments and rightsizing both reduce a bill, but they compose badly in the wrong order, and the asymmetry is the whole point of this question. Rightsizing reduces the *quantity* of compute you consume. A commitment reduces the *rate* you pay for whatever you consume. Applying the rate cut to an inflated quantity locks the inflation in for one or three years — you are now paying a discounted price for instances that are half idle, and paying it whether you keep them or not. It gets worse if you then rightsize. Suppose you commit $20 per hour against a fleet you later shrink to $14 per hour of usage. The $6 gap does not roll over and cannot be refunded; Savings Plans cannot be cancelled or resold. You have converted a genuine engineering saving into stranded commitment. The right sequence — shrink first, commit to what remains — captures both savings and strands nothing. ## What Compute Optimizer actually gives you AWS Compute Optimizer analyses historical utilization metrics and produces per-resource recommendations for supported resource types, which include EC2 instances, Auto Scaling groups, EBS volumes and Lambda functions, among others. Two things about it are worth naming in an interview: 1. **The finding classifications.** Each resource is labelled `Over-provisioned`, `Under-provisioned` or `Optimized`, with proposed alternative configurations and the projected effect of each. That gives you a defensible per-resource list rather than a gut feeling, which matters when you are asking a service team to shrink something they own. 2. **The memory blind spot.** EC2 does not publish guest memory usage to CloudWatch by default, so recommendations built only on default metrics reason about CPU, network and disk and are effectively guessing about memory. Installing the CloudWatch agent so memory metrics exist — and enabling Compute Optimizer's enhanced infrastructure metrics, which extends the lookback window — materially improves the quality of the recommendation. A candidate who mentions this is showing they have actually used the tool: the classic failure is shrinking an instance on CPU evidence alone and pushing a memory-bound service into swap or OOM. Compute Optimizer is advisory. It sees utilization, not intent: it cannot know that a box is idle because it is a warm standby, or that a quarterly job needs the headroom for two days in ninety. Treat its output as a candidate list to triage with the owning team, not as a work queue to automate. ## The Graviton pass AWS's Graviton processors are `arm64`, and AWS prices Graviton-based instance types below comparable x86 sizes in the same family class, with a price-performance argument on top of the sticker price. Because it changes the rate *and* often the required size, a Graviton migration belongs in the same "lower the baseline" phase as rightsizing. The engineering cost is real and specific: - Every artefact must exist for `arm64`. For containers that means multi-architecture images; a single-arch image simply will not schedule. - Native dependencies, agents and anything with compiled extensions need `arm64` builds. Managed runtimes and most mainstream language stacks are fine; a long tail of vendor agents historically was not. - Benchmark rather than assume. Price-performance claims are workload-dependent, and the honest answer to "how much will we save" is "we measured this workload on both". Compute Optimizer can include Graviton-based instance types among its recommendations, which is a convenient way to find the candidates, but the migration decision is an engineering one about build pipelines and dependencies, not a billing one. ## The commitment trap Graviton creates There is a sharp interaction to flag. An EC2 Instance Savings Plan is scoped to one instance family. If you hold one on an x86 family and then migrate to a Graviton family, the plan does not follow — the new fleet bills On-Demand while the old commitment keeps charging. So if a Graviton migration is anywhere on the roadmap, that is a strong argument for Compute Savings Plans, which apply across families, or for deferring the commitment until the migration lands. ## How to answer Say the sequence out loud: **rightsize and re-platform first, let usage settle for a few weeks, then commit to the new, lower baseline.** Then add the honest caveat — rightsizing takes engineering time from teams that have other priorities, so in practice you often buy a conservative first tranche of Compute Savings Plans against the portion of the baseline nobody disputes, and grow the commitment as the optimisation work lands.