EC2 Cost Optimization: Which Savings Need a Rebuild?

The first pass at EC2 cost optimization is dial-turning. Delete the instances nobody has logged into since March, move the volumes off gp2, buy a commitment. Most accounts are through all of that inside a quarter, and then the savings stop.

What is left is two levers, both worth more than everything in the first pass put together. Graviton, roughly a fifth off the instance hour. And Spot, which is most of the bill. Neither is a setting. Graviton wants an arm64 build of everything in the path; Spot wants a workload that can lose a machine on two minutes' notice without anyone noticing.

Our position, from doing this on regulated accounts: take Graviton, and be slow about Spot. Graviton is a build problem. It costs a sprint once and pays every month afterwards. Spot is an availability decision, and on a payments account the regulator has already written down what it expects of availability.

Why does EC2 cost optimization run out of easy wins?

Because the free tools price resources, not rebuilds. Compute Optimizer and Cost Optimization Hub read your metrics and tell you the m6i.2xlarge could be an m6i.xlarge. Act on most of that, with the caveats in which AWS recommendations to ignore.

What no tool can do is find out whether your JAR, your sidecar, your one vendored native dependency and the agent your security team mandated all have arm64 builds. Nor can it decide that the overnight reconciliation job is allowed to be interrupted. Both answers live in someone's head, which is why both savings are still in the account in month nine. What is left is not analysis. It is engineering, and it lands on the team that owns the service rather than on whoever owns the cost dashboard.

What does Graviton actually save, and what has to be rebuilt?

AWS prices Graviton instances at "up to 20% less than comparable x86-based Amazon EC2 instances". Read the "up to" honestly. The instance hour is reliably cheaper; whether your service needs the same number of cores on arm64 is a question only your own benchmark answers.

Which is the actual work. AWS's own Graviton getting-started guide is blunt: "as a general rule later versions of compilers, language runtimes, and applications should be used whenever possible." It carries a minimum-version table per language, and the floor is higher than most teams assume. Its HAProxy note is the shape of the exercise: "building with CPU=armv81 improves HAProxy performance by 4x."

Four things to check before anyone opens a ticket:

• The base image. Push a manifest list with both architectures. ECR supports multi-arch images, so the node pulls what it can run and the deploy does not change.
• The runtime version. Against that table, not against what you remember installing.
• Native dependencies. Anything that arrived as a wheel, a .so or a static binary.
• Agents and sidecars. The log shipper, the monitoring agent, the CI runner image. One of these will hold the migration up for a fortnight, and week one is the cheap time to find out which.

Then the commitment, which is where this gets expensive by accident. A Compute Savings Plan follows you, "regardless of instance family (for example, m5, c5, etc.), instance size, Region, operating system, or tenancy". An EC2 Instance Savings Plan does not: it buys "a commitment to a specific instance family in a chosen AWS Region (for example, m5 in Virginia)". Move an m6i fleet to m7g holding an m6i plan and the discount stays behind on a family you no longer run, for the rest of the term. Which plan to buy is its own argument.

Can a payments workload take a two-minute interruption notice?

Mostly no, and AWS says it before we do. The Spot best practices page offers "savings of up to 90% compared to On-Demand prices" and then names the exclusions: Spot Instances "are not suitable for workloads that are inflexible, stateful, fault-intolerant, or tightly coupled between instance nodes."

The warning is exactly two minutes. The interruption notice arrives as an EventBridge event and as an instance-action item in instance metadata, and the notices are "emitted on a best effort basis". Two minutes is enough to drain a connection pool and finish the request in flight. Not enough to re-elect a primary, warm a cache or close out a settlement file.

The part teams get wrong is the fallback, and we got it wrong once too. The obvious design is to fail Spot over to On-Demand, and AWS discourages it in writing: "failing over to On-Demand Instances can inadvertently drive interruptions for your other Spot Instances." The capacity you planned to escape into is the capacity that just went away.

So where does Spot earn a place on a fintech account? CI runners. Load tests. The whole of staging. Overnight reconciliation, provided the job checkpoints. Async consumers whose work is retried by design. Spread across at least ten instance types, AWS's own rule of thumb, and allocated with price-capacity-optimized rather than lowest price. On EKS that is a second node group with a taint; the rest of that bill is in which numbers move the EKS bill.

Not the payment path. Not the database. Not anything holding the only copy of something.

What does launch before terminate change?

One setting is worth knowing here, because it changes what every instance replacement costs. Launch before terminate makes Auto Scaling "launch replacement instances and wait for them to pass health checks before terminating the instances they replace", and it can be switched on once per account rather than group by group. The documentation names the cost and it is small: the setting "runs one additional instance for a short time during each replacement". On a regulated account, where an instance refresh is how patching happens, take that trade.

One trap. If you hold a targeted On-Demand Capacity Reservation and reference it by its id, a replacement can "leave one replacement instance running as regular On-Demand capacity" while a reserved slot sits unused. AWS's remedy is to reference the reservation through a resource group, or to use an open one. Worth ten minutes if you reserved capacity for a DR region and nobody has looked since.

Does any of this touch a control a regulator asked for?

One of the two does. The RBI's Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026 fix the cadence in paragraph 129: "periodicity of DR drills for critical information systems shall be at least on a half-yearly basis". Paragraph 131 is the sentence that matters here, because it makes the drill real: "switching over to the DR / alternate site and thus using it as the primary site" for a full working day.

Set that beside the Spot page, which states that AWS "does not guarantee ... that you can always get the aggregate capacity that you requested". DR capacity that exists only at a Spot price is not capacity. It will probably be there, and the drill is the day you find out it is not, with the report due. Our full read of that direction is in what the 2026 directions change for an NBFC on AWS.

Graviton is the opposite, which is the honest reason to do it first. It changes the instruction set and nothing about the control surface: same logs, same encryption, same region, same trail. The one question it raises is whether your pen test scope covers both architectures, because you now ship two images. The wider list of cuts that quietly delete evidence is in what a fintech can cut without failing an audit.

What can you run on Monday?

Three commands, ten minutes, one page of plan. The first says how much of the fleet is still x86 On-Demand, which is the size of the prize:

aws ec2 describe-instances \
  --filters Name=instance-state-name,Values=running \
  --query 'Reservations[].Instances[].{type:InstanceType,arch:Architecture,
            life:InstanceLifecycle,az:Placement.AvailabilityZone}' \
  --output table

InstanceLifecycle is absent on an On-Demand instance and reads spot on a Spot one, so the rows showing x86_64 with no lifecycle are your candidate list. Sort by what each family costs you, not by row count.

Then, for the service at the top of that list, whether its image can already run on arm64 today:

docker buildx imagetools inspect \
  123456789012.dkr.ecr.ap-south-1.amazonaws.com/api:prod

If the manifest lists only linux/amd64, the first ticket is a build pipeline ticket, not an infrastructure one. And while you are in the account:

aws autoscaling describe-account-settings --name launchBeforeTerminate

When is paying for On-Demand x86 the honest answer?

Three cases, and we have argued all three in proposals.

When something in the stack has no arm64 path. A licenced vendor agent, a JDK you are not allowed to move off, a binary from a payment network that ships one build. Chasing a fifth of the instance hour through somebody else's roadmap is not a quarter well spent.

When the bill is small. Twenty per cent of a four lakh a month compute line is eighty thousand rupees. If the migration costs three engineer-weeks and the audit is in six, the audit wins.

And when the team is already at capacity. A half-finished architecture migration is worse than none: two images, two node groups, two sets of alerts and nobody certain which one production is on. Either staff it or schedule it.

The short version

Run the three commands and sort the output by spend. That is the discovery phase.

Then move one service to Graviton this month, chosen because its image is already multi-arch, with a benchmark either side rather than an assumption. Check whether your commitment is a Compute plan or an EC2 Instance plan before you move a family; that mistake runs for the term. Give Spot the CI fleet, staging and the batch jobs that checkpoint, and nothing holding state or money. Leave the DR fleet on capacity you have actually reserved.

The dial-turning is finished. What is left is a build change and an availability decision, and only one of them is safe to make quickly.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.