Cost

Migrate EC2 to Graviton (ARM)

Up to 40% better price-performance on ARM — surfaced by Cost Optimization Hub as a recommendation. Validate compatibility, then ride the migration loop.

18 min·10 sections·AWS

Last reviewed 27 May 2026

Graviton: the basics

What is Graviton and why does AWS keep nagging you to migrate?

Graviton is AWS's family of custom 64-bit Arm processors, built on the Neoverse core and designed specifically for cloud workloads. The current generations — Graviton3 (the 7g instance families like m7g, c7g, r7g) and Graviton4 (the newer 8g line) — sit alongside the older Graviton2 (6g) which still ships in many regions. Every Graviton instance is ARM64; every x86 instance is, well, x86. There is no overlap in CPU architecture, which is the entire reason this lesson exists.

The pitch is straightforward and unusually honest for cloud marketing: Graviton instances list at roughly 20% lower per-hour than the equivalent x86 generation, and AWS measures another 25-40% better performance on common workloads — microservices, JVM apps, NGINX, Redis, Postgres, Go and Node services on Graviton-tuned AMIs. Stack those two effects and the price-performance gap is real, not a rounding-error discount.

Cost Optimization Hub flags Graviton migration as a recommendation type whenever it sees a workload running on an x86 instance family that has a published Graviton equivalent (m5 → m7g, c5 → c7g, r5 → r7g, t3 → t4g) and judges the workload portable. The action is Migrate to Graviton (ARM) EC2 instance, scoped to a single arn:aws:ec2:...:instance/..., with a recommendedInstanceType and monthly savings projection. The recommendation is correct often enough to act on by default — but only after you've cleared the architecture gate.

In this lesson you'll learn what makes Graviton a genuine price-performance win rather than a marketing discount, how to read the Cost Optimization Hub recommendation, the compatibility loop that gates every migration (multi-arch builds, base-image pinning, canary on a real Graviton node), and the mechanics of rolling a fleet from x86 to ARM without taking downtime. You'll also see how Graviton interacts with your existing Savings Plans and Spot strategy — because the discount stack matters more than the sticker price.

Fun fact

AWS runs on Graviton too

By 2024 AWS reported that more than 50% of all new EC2 CPU capacity sold to customers was Graviton, and internally a majority of their managed services — RDS, ElastiCache, OpenSearch, Lambda, Fargate, even parts of the EC2 control plane itself — run on Graviton in production. When AWS picks ARM for their own most-critical services, the price-perf story is not aspirational; the dogfooding has already happened. The slowest mover in the migration is usually the customer fleet, not the platform.

Migrating to Graviton in action

Nina runs the SRE team at a fintech that ships a Go-based pricing service on a fleet of forty c5.2xlarge instances behind an ALB. Cost Optimization Hub has been quietly flagging the same recommendation across the fleet for three weeks: migrate to c7g.2xlarge, projected monthly savings $4.8k.

She knows the service is pure Go with no CGO dependencies and no x86-only third-party binaries. The container base is alpine:3.19 which has supported arm64 since the early 3.x line. On paper it should Just Work — but the team has been bitten before by an x86-only Datadog sidecar, so the migration has been sitting in the backlog waiting for someone to actually run the validation loop.

She pulls the Hub recommendation, confirms the savings math, builds a multi-arch image with docker buildx, deploys a single c7g.2xlarge canary alongside the existing fleet, and watches latency for 72 hours. p99 actually improves by 11%. She updates the launch template and lets the ASG drain x86 nodes overnight.

First, pull the Cost Optimization Hub recommendation to confirm the recommended type and the savings projection.

$ aws cost-optimization-hub get-recommendation --recommendation-id rec-0abc123def456 --query 'currentResourceDetails.ec2Instance,recommendedResourceDetails.ec2Instance,estimatedMonthlySavings'

[

{

"instance": { "instanceType": "c5.2xlarge", "platform": "Linux/UNIX" }

{

"instance": { "instanceType": "c7g.2xlarge", "platform": "Linux/UNIX" }

{ "value": 119.84, "currency": "USD" }

]

# c5.2xlarge -> c7g.2xlarge, ~$120/mo per instance, $4.8k/mo across the fleet.

Cost Optimization Hub's per-instance migration recommendation.

Now build a multi-arch image so the same tag works on both x86 and arm64 nodes during the migration window.

$ docker buildx build --platform linux/amd64,linux/arm64 -t 123456789012.dkr.ecr.eu-west-1.amazonaws.com/pricing:v1.42 --push .

[+] Building 84.3s (18/18) FINISHED

=> [linux/amd64 builder 1/4] FROM golang:1.22-alpine

=> [linux/arm64 builder 1/4] FROM golang:1.22-alpine

=> [linux/amd64 builder 4/4] RUN go build -o /pricing ./cmd/server

=> [linux/arm64 builder 4/4] RUN go build -o /pricing ./cmd/server

=> exporting manifest list sha256:7c2a91...

=> pushing pricing:v1.42 to ECR (multi-arch manifest)

# Same tag, two architectures. Kubernetes/ECS pulls the right one per node.

A multi-arch image lets you canary on Graviton without forking the deployment pipeline.

Graviton under the hooddeep dive

Graviton is ARM64 (aarch64). Every byte of compiled code on the instance has to target that architecture — the kernel, the userland, your application binary, every shared library it dlopens, every C extension your interpreter imports. Managed runtimes (JVM, .NET 6+, Go, Python, Node, Ruby) handle this transparently because they ship arm64 builds; the breakage usually lives one layer down, in a CGO module, a pre-compiled wheel, an x86-only sidecar, or a kernel module shipped as a .ko blob in your AMI.

Cost Optimization Hub's recommendation engine reads the same CloudWatch and Compute Optimizer signals it uses for right-sizing, then applies a portability heuristic — instance generation, AMI metadata, attached EBS volumes, known sidecar inventory — and emits the migration recommendation when the workload looks portable enough to be worth the human review. The recommendedInstanceType is always the matching Graviton SKU for the same vCPU/RAM tier within the family. Savings come from two sources: the ~20% list-price gap, and the fact that better performance per vCPU often lets you also drop a size (a c5.4xlarge sometimes maps to c7g.2xlarge, not c7g.4xlarge).

The migration mechanics are identical to right-sizing because under the hood you're just changing InstanceType on a launch template — except you also need to swap the AMI for an ARM64 build. Amazon Linux 2023, Ubuntu 22.04, and most modern distros publish both architectures under the same SSM parameter prefix (e.g. /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-arm64). The ASG/EKS managed node group handles the rest: drain, terminate, replace with the new launch template, repeat.

# Resolve the latest Amazon Linux 2023 ARM64 AMI via SSM.
AMI_ID=$(aws ssm get-parameter \
  --name /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-arm64 \
  --query 'Parameter.Value' --output text)

# Update the launch template with the new AMI and Graviton instance type.
aws ec2 create-launch-template-version \
  --launch-template-id lt-0abc123def456 \
  --source-version '$Latest' \
  --launch-template-data "{\"ImageId\":\"$AMI_ID\",\"InstanceType\":\"c7g.2xlarge\"}"

aws ec2 modify-launch-template \
  --launch-template-id lt-0abc123def456 \
  --default-version '$Latest'

# Roll the fleet at the autoscaling layer.
aws autoscaling start-instance-refresh \
  --auto-scaling-group-name pricing-asg \
  --preferences '{"MinHealthyPercentage":90,"InstanceWarmup":120}'

What is the impact of staying on x86 when Graviton fits?

The direct impact is the bill. A fleet that could be running on c7g.2xlarge but isn't is paying roughly 20% more per hour for compute that, on most workloads, would also perform 25-40% better. For a 40-node c5.2xlarge fleet that's around $4.8k/month, or ~$58k/year, going to AWS for no reason other than "we haven't gotten around to it." Across a larger estate the number reaches genuine seven-figure territory before anyone bothers to total it.

The second-order effect is that you're sitting on a recommendation Cost Optimization Hub flagged weeks or months ago, which means the same finding is being re-surfaced in every finance review, every quarterly business review, every FinOps standup. Each iteration costs human attention without producing the migration — the worst kind of organisational tax.

There's a Savings Plan trap on the other side: if your existing commitment is a Compute Savings Plan it covers Graviton transparently and you get the migration savings on top of the commitment discount. If it's an EC2 Instance Savings Plan locked to the c5 family, however, those hours do not transfer across to c7g — the SP keeps charging you for c5 hours you're no longer running, and the migration savings get partly eaten until the commitment expires. This is the single most common reason a Graviton migration's actual savings undershoot the projection.

Finally, Spot availability and pricing on Graviton instance pools is generally as good or better than the equivalent x86 pool, particularly in newer regions where capacity has been built out aggressively. A fleet that's already on Spot and migrates to Graviton typically sees both lower interrupt rates and lower hourly prices — a second discount layer the on-paper projection doesn't capture.

How do you migrate to Graviton safely?

Graviton migration is a four-step compatibility-then-rollout loop. Skip the validation half and you'll find the one binary that's x86-only the hard way, in production, at 3am.

1. Inventory the architecture surface

Walk the dependency tree before you touch a launch template. List every container image, every sidecar, every pre-compiled binary or kernel module shipped in the AMI, every native dependency your runtime pulls in (Python wheels, Node native modules, Ruby gems with C extensions). For each one, confirm an arm64 build exists. JVM/Go/Python/Node services on standard base images almost always pass; .NET Framework (not .NET 6+), x86-only third-party agents (some older APM/security vendors), and homegrown C/C++ tools are the common blockers.

2. Build multi-arch and pin Graviton-friendly base images

Use docker buildx build --platform linux/amd64,linux/arm64 so the same tag works on both architectures during the rollout. Pin base images that publish arm64 (Amazon Linux 2023, debian:bookworm, alpine:3.19+, ubuntu:22.04+, the official language images for Go/Python/Node/JDK). Avoid :latest — you want the arm64 build to be deterministic, not a moving target. For Lambda, ECS, and EKS the manifest list handles per-node pulling automatically.

3. Canary on a real Graviton instance for 24-72 hours

Spin up one Graviton node alongside the existing x86 fleet, route a small slice of traffic to it (1-5% via target group weights or service mesh), and watch p99 latency, error rate, GC behaviour (JVM JIT warm-up looks different on ARM — give it longer than you think before judging steady-state), and any vendor-specific health metrics. 24 hours catches the obvious breakage; 72 catches the JIT and cache-warmup edge cases. Promote only after the canary holds steady through at least one full traffic cycle.

4. Roll the fleet via launch template + instance refresh

Update the launch template with the ARM64 AMI and the recommended Graviton instance type, then trigger an ASG instance refresh (or eks update-nodegroup-version --force-update for managed node groups). Set MinHealthyPercentage to 90 so you drain gradually. After the rollout completes, verify your Savings Plan coverage in Cost Explorer — if you were on an EC2 Instance SP locked to the old family, plan the SP rotation or wait out the term, and price that gap into the migration's expected ROI.

# Bulk-export the open Graviton recommendations across the account.
aws cost-optimization-hub list-recommendations \
  --filter 'actionTypes=MigrateToGraviton' \
  --query 'items[?implementationEffort==`Low`].[recommendationId,currentResourceArn,estimatedMonthlySavings.value]' \
  --output table > graviton-candidates.txt

# Feed into your change-management workflow.
wc -l graviton-candidates.txt

Quick quiz

Question 1 of 5

Cost Optimization Hub recommends migrating a c5.2xlarge running a Go service in an alpine:3.19 container to c7g.2xlarge with a $120/mo savings projection. Your existing commitment is an EC2 Instance Savings Plan locked to the c5 family. What's the right next move?

Keep learning

Dig into the Graviton migration tooling, performance work, and the FinOps mechanics around commitment discounts.

You've completed Migrate EC2 to Graviton (ARM). You now know what Graviton actually is, why the price-performance gap is real and not marketing, how to clear the architecture gate before you migrate, and how to run the four-step compatibility-then-rollout loop — inventory, multi-arch build, canary, roll — without breaking production or stranding your Savings Plan. The next Cost Optimization Hub recommendation that lands in your inbox is ready to be acted on, not deferred.

Back to the library

Graviton migration: what it means for the compute bill

A one-time compatibility investment that cuts EC2 compute costs by 20-40% per migrated instance

AWS Graviton is a different processor architecture (ARM64) than the Intel/AMD x86 chips that most EC2 fleets run on. The financial relevance is simple: Graviton instances list at roughly 20% lower per hour than the equivalent x86 generation, and AWS reports 25-40% better throughput per dollar on typical workloads. Those two effects compound — you can often also drop an instance size on Graviton and still match x86 performance, widening the saving further.

Cost Optimization Hub surfaces this as a named recommendation: 'Migrate to Graviton (ARM) EC2 instance,' scoped to individual instances with a projected monthly saving in dollars. That number is the starting figure for a migration ROI model — it represents the per-instance recurring saving, which accumulates every month the migration hasn't happened. A fleet of forty mid-size compute instances left on x86 is typically a $50-70k/year variance against what it could cost on Graviton.

The one-time cost is an engineering effort to validate compatibility and run a staged rollout. That effort is bounded and non-recurring; the saving is perpetual. The finance framing is therefore: what is the migration-effort cost in engineering hours, against the perpetual monthly delta? For most application-tier workloads the payback period is measured in weeks, not months. The decision is essentially a capital-efficient operating cost reduction — execute it once, harvest the saving indefinitely.

This lesson is for the finance partner who wants to understand what the Graviton line on the Cost Optimization Hub report actually represents, how to model the ROI of migrating, and what traps can make the realised savings undershoot the projection. It covers why this is a perpetual operating-cost reduction rather than a one-time saving, how to quantify the payback period against the engineering effort, and the Savings Plan wrinkle — particularly EC2 Instance SPs locked to an x86 family — that is the most common cause of a migration saving falling short. No commands required.

Fun fact

AWS runs on Graviton too

How a finance partner frames the Graviton migration decision

Raj is the FinOps lead reviewing the monthly Cost Optimization Hub report. Fourteen EC2 instances across three teams are flagged with Graviton recommendations totalling $6,200 per month in projected savings — about $74k annualised. The recommendations have been open for an average of six weeks. Raj's job is not to run the migration, but to make the foregone saving visible and unambiguous.

He pulls the per-instance detail: eight instances belong to the application-tier where engineering has already confirmed Go and Python services are portable. The projected saving on those eight is $4,400/month. Three instances carry a red flag — an EC2 Instance Savings Plan locked to the m5 family covers them until Q3, so migrating early would strand committed spend. Raj notes those three as 'migrate after SP expiry' and models the blended saving on the right timeline.

His finance pack entry is two numbers: $4,400/month available to capture now with no commitment conflict, $1,800/month available from Q3 when the EC2 SP terms out. Total annualised opportunity is $71k, payback on estimated engineering effort is under five weeks. That framing converts an open recommendation into a prioritised, cost-justified work item with a clear migration sequence — no ambiguity about which instances to move first or why the others are waiting.

The unit-economics case for acting on Graviton recommendations promptly

Each open Graviton recommendation carries an explicit foregone-savings rate in dollars per month. That is not an estimate — it is Cost Optimization Hub's projection based on actual usage patterns for that instance. Every week the recommendation stays open, the business is paying the x86 premium it no longer needs to. For a 40-node fleet with a $4.8k/month recommendation, six weeks of inaction is roughly $7k spent unnecessarily before a single sprint is allocated.

The Savings Plan interaction is the most important financial variable to model before committing to a migration timeline. A Compute Savings Plan transfers seamlessly to Graviton — you get the commitment discount plus the per-hour Graviton price reduction, stacked. An EC2 Instance Savings Plan locked to a specific family (e.g. m5 or c5) does not transfer: migrating early means the SP keeps charging for x86 hours you are no longer running while you simultaneously pay on-demand Graviton rates, effectively double-paying until the SP expires. The finance input is to map every flagged instance against its SP coverage and sequence migrations accordingly — instances outside SP coverage go first, SP-covered instances go after term expiry.

Size reduction on Graviton is a second savings lever the headline recommendation understates. Because Graviton delivers more throughput per vCPU, a workload running at 60% CPU on a c5.4xlarge often runs at 40% on a c7g.2xlarge — a type that's half the size and costs about 60% less. Finance should ask engineering to validate the utilisation profile, not just accept the same-size recommendation as the ceiling.

For chargeback and showback, Graviton migrations are clean wins: the per-instance cost drops and the CPU performance either holds or improves, so there is no service-level trade-off to argue about. The migration saving can be attributed directly to the team that owns the workload, making it a straightforward line in the unit-economics review.

What finance can do to drive Graviton migrations to completion

Finance can't update a launch template, but it controls the framing, the sequencing, and the accountability levers that determine whether Graviton recommendations close promptly or decay in a backlog. Four concrete actions.

1. Segment the recommendation list by SP coverage before anything else

Pull every open Graviton recommendation and cross-reference each instance against its Savings Plan coverage type. Instances covered by a Compute SP can migrate immediately and gain the full stacked discount. Instances covered by an EC2 Instance SP locked to the old family should be sequenced to migrate at or near SP expiry to avoid stranding committed spend. Publish this two-tier list so engineering has a clear, finance-approved migration order and no instance falls into ambiguity.

2. Attach a monthly foregone-savings figure to each open recommendation

Express the open recommendations not just as a count but as a running dollar total: $X per month in projected savings not yet captured. Add a 'weeks open' column. This reframes the backlog from an abstract list of items to an explicit cost of inaction that grows each sprint. Finance reviews that show this number tend to accelerate prioritisation far more effectively than a list of recommendation IDs.

3. Model the size-reduction opportunity alongside the type-swap

Graviton's higher throughput per vCPU means many workloads can drop a size and still match x86 performance — widening the saving beyond what the same-family recommendation projects. Ask engineering to provide CPU utilisation data for flagged instances and price out the downsize scenario. A c5.4xlarge at 40% utilisation may map to a c7g.2xlarge comfortably, producing a saving well above the headline projection.

4. Set and hold a 45-day close target for non-blocked recommendations

Agree with engineering a close target — 45 days is a reasonable default for non-SP-constrained instances. Track recommendation age in the FinOps review alongside the dollar cost of open items. Any recommendation older than the target without a documented blocker (SP conflict, confirmed incompatible dependency) is an accountability item, not a backlog item. The distinction matters: backlogs slip, accountability items get escalated.

Quick quiz

Question 1 of 5

The FinOps report shows 20 open Graviton recommendations totalling $8,400/month. Eight instances are covered by a Compute SP, nine by an EC2 Instance SP locked to m5 (expires in four months), and three have no coverage. Which group do you prioritise for immediate migration?

Keep learning

Dig into the Graviton migration tooling, performance work, and the FinOps mechanics around commitment discounts.

You've finished the finance partner's view of Graviton migration. You know why the Cost Optimization Hub saving projection is a reliable number — not a rounding-error discount but a compounding price-performance gap — how to sequence migrations around Savings Plan coverage to avoid stranding committed spend, and the four levers that drive recommendations to closure: SP-segmented prioritisation, foregone-savings tracking, size-reduction modelling, and a 45-day close target with documented exceptions. The next time Graviton recommendations appear in the FinOps review, you'll have a sharper question than 'when is engineering getting to this?'

Back to the library

Graviton migration: the headline

A structural compute cost reduction AWS has already done the analysis on — the question is whether you act on it

AWS built its own chip for cloud workloads and now prices it 20% below the equivalent Intel/AMD instance, while delivering better performance on most common server software. Cost Optimization Hub automatically identifies which workloads in your account are candidates and quantifies the monthly saving. This is not a speculative optimisation — it's a vendor-provided, per-workload savings projection the business can act on or formally decline.

The executive question is not whether Graviton is better — AWS's own benchmarks and the industry evidence make that case clearly. The question is whether migrating is a governed priority or something that accumulates in backlogs. Every month a flagged workload stays on x86, the projected saving is foregone. At scale, that total can reach six or seven figures annually. The right posture is a policy: flagged Graviton recommendations are acted on within a defined window unless there is a documented technical blocker.

A focused read for the leader who wants to understand why Graviton recommendations keep appearing and what the organisational response should look like. You will get the plain-English case for Graviton's price-performance advantage, why Cost Optimization Hub's per-instance savings projection is a reliable number the business can act on, and what a governed migration posture looks like — a defined window for acting on flagged recommendations, documented blockers for exceptions, and a standing view of foregone savings. No technical implementation detail.

Fun fact

AWS runs on Graviton too

What it looks like when Graviton migration is a governed practice

At one organisation, the engineering VP, Clare, noticed that the same Graviton recommendations were showing up in every quarterly FinOps review without any of them closing. The savings projections were real and the instances were technically portable — the work just kept losing out to feature work in sprint planning with no forcing function.

She set a simple policy: any Cost Optimization Hub recommendation open for more than 45 days without a documented blocker is automatically escalated as an unresolved cost risk in the quarterly business review. Within six months, average recommendation age dropped from eleven weeks to three. Foregone savings — the sum of projected monthly saving multiplied by weeks open — fell from $180k per quarter to under $30k.

The policy didn't require her to understand ARM architecture or launch templates. It required that the organisation treat Cost Optimization Hub as an authoritative signal and act on it within a defined window. That is the executive handle: not directing the technical migration, but ensuring the governance exists so that validated, vendor-quantified savings are not silently deferred indefinitely.

Why this is a governance question, not just an engineering one

The core issue with staying on x86 when Graviton fits is not technical — it is organisational. AWS has already done the analysis and published a per-workload savings figure. The instances are flagged. The savings are quantified. What accumulates is not a technical debt but a decision debt: the organisation has not yet made the call to treat Graviton recommendations as work that must complete within a defined window.

The Savings Plan trap adds a timing dimension that is genuinely a leadership call. EC2 Instance Savings Plans locked to an x86 family create a sequence constraint: migrating early can strand committed spend and make the saving smaller than projected in the near term. A clear policy — 'migrate within 30 days for instances not covered by a locked SP, migrate at SP expiry for covered instances' — removes the per-instance debate and makes the optimisation predictable and auditable.

At the portfolio level, the compounding effect of deferred Graviton migrations is material. A hundred flagged instances at an average $120/month saving each is $144k per year. Left unaddressed across three annual planning cycles, that is $430k+ in avoidable compute spend — a number large enough to show up as a line item if it were a vendor contract, but invisible because it is distributed across hundreds of individual recommendations nobody is accountable for closing.

The leadership moves that make Graviton migration a closed loop

The executive role on Graviton is to ensure that vendor-quantified cost reduction recommendations have a defined path to closure — not to direct the technical migration. Three governance moves.

1. Set a migration SLA with documented exceptions

Define a policy: open Graviton recommendations are acted on within a defined window (e.g. 45 days) unless there is a documented blocker — a confirmed x86-only dependency or an active Savings Plan conflict that makes early migration financially worse. 'Not prioritised yet' is not a blocker; it is a prioritisation failure. The existence of a clear SLA means recommendation age is a metric the organisation can be held to, not a best-effort aspiration.

2. Make foregone savings a standing leadership metric

Request a single number each quarter: the total projected monthly saving sitting in open, non-blocked Graviton recommendations. That number is the organisation's current cost of inaction on a set of already-validated opportunities. Watching it trend down over time is the signal that the governance is working. A flat or rising number means the SLA is not being enforced and the issue needs escalation.

3. Hold teams accountable for their own recommendation portfolios

Graviton recommendations are scoped to individual instances which belong to individual teams. Assign recommendation portfolios to team leads in the FinOps operating model — each team is responsible for clearing their own recommendations within the SLA or logging a blocker. This distributes the accountability to the people who own the infrastructure and removes the centralised FinOps team as the bottleneck. The leadership signal is that cost optimisation is part of owning a workload, not a separate programme.

Quick quiz

Question 1 of 5

Your quarterly FinOps review shows Graviton recommendations have been open for an average of eleven weeks and the total projected monthly saving has grown to $12,000. Engineering says the work is technically straightforward but keeps being deprioritised. What is the right leadership response?

Keep learning

Dig into the Graviton migration tooling, performance work, and the FinOps mechanics around commitment discounts.

That's the lesson. Two takeaways: Cost Optimization Hub's per-instance Graviton savings projections are vendor-validated and actionable — the question is never whether to migrate, only when and in what order. And the right posture is a governed SLA: recommendations close within a defined window unless a documented blocker exists, foregone savings are a standing leadership metric, and teams own their own recommendation portfolios. That is the difference between a cost optimisation practice and a backlog that grows every quarter.

Back to the library

Part of the learning path Right-size your compute

Migrate EC2 to Graviton (ARM)

Graviton: the basics

AWS runs on Graviton too

Migrating to Graviton in action

Graviton under the hooddeep dive

What is the impact of staying on x86 when Graviton fits?

How do you migrate to Graviton safely?

1. Inventory the architecture surface

2. Build multi-arch and pin Graviton-friendly base images

3. Canary on a real Graviton instance for 24-72 hours

4. Roll the fleet via launch template + instance refresh

Quick quiz

Keep learning

Graviton migration: what it means for the compute bill

AWS runs on Graviton too

How a finance partner frames the Graviton migration decision

The unit-economics case for acting on Graviton recommendations promptly

What finance can do to drive Graviton migrations to completion

1. Segment the recommendation list by SP coverage before anything else

2. Attach a monthly foregone-savings figure to each open recommendation

3. Model the size-reduction opportunity alongside the type-swap

4. Set and hold a 45-day close target for non-blocked recommendations

Quick quiz

Keep learning

Graviton migration: the headline

AWS runs on Graviton too

What it looks like when Graviton migration is a governed practice

Why this is a governance question, not just an engineering one

The leadership moves that make Graviton migration a closed loop

1. Set a migration SLA with documented exceptions

2. Make foregone savings a standing leadership metric

3. Hold teams accountable for their own recommendation portfolios

Quick quiz

Keep learning

Related cost lessons