Graviton in practice: four teams that cut compute cost 30-47%.

When a newer instance family is both faster and cheaper, migrating pays twice: you need fewer instances, and each one costs less. Four case studies show how far that goes on AWS Graviton (Arm) processors: Pinterest saved 47% on one important workload and 62% in carbon, Honeycomb moved its entire EC2 fleet after a one-week bake-off, Zomato cut Trino and Druid compute cost about 30% in roughly two weeks, and Zendesk reports up to 42% lower cost with up to 30% better performance. This part explains why price-performance upgrades are the cheapest engineering on the list, how each team de-risked the move (multi-architecture builds first, own code first, then the long tail), and gives a concrete pilot plan, benchmark method, compatibility checklist and rollback path you can run on a single workload.

1. Why price-performance is the cheapest engineering

Most cost levers ask something difficult of you: redesign a data path, change retention, restructure a fleet for interruption. A newer instance generation asks for far less. You keep the workload and its design, rebuild for a different CPU architecture, and receive a lower price per hour and more work per core. The saving compounds: fewer instances are needed, and each one is cheaper.

The report ranks this among the lowest-risk, highest-certainty moves in the whole catalogue (pattern P09: "change the unit price with low-risk swaps"). Graviton is the clearest example on AWS, but the same idea covers gp2 to gp3 volumes, t3 to t4g database instances, and newer generations of any family. The four cases in this part show the same idea at different scales and in different organisational styles: a multi-year programme (Pinterest), a full-fleet conversion (Honeycomb), a two-week data-platform move (Zomato) and a vendor-published fleet result (Zendesk).

2. CS-10 Pinterest: from night-time shutdowns in 2012 to a Graviton programme in 2021-2024

Field	Detail
Business	Visual discovery, 500M+ monthly active users
Data	Nearly an exabyte in S3
Programmes	Autoscaling (2012), Graviton (2021+), S3 lifecycle
Result	47% cost savings on one important workload after moving to Graviton

Pinterest was born on AWS and has run several distinct efficiency programmes as it grew. The case is useful because it shows efficiency as a multi-year discipline rather than a one-off project.

• 2012: follow the traffic curve. An autoscaling system for the web application pool, built in about two weeks, cut the pool's hourly cost from roughly $54 to roughly $20 by shrinking capacity at night. Time-of-day elasticity for stateless tiers is still one of the simplest big wins.
• 2021 onward: Graviton migration programme. Workloads were moved to Graviton-based EC2 instances. On one important workload this delivered 38% compute-resource savings, 47% cost savings and 62% lower carbon emissions. By 2024 more than a quarter of the infrastructure had moved, with similar results.
• Storage lifecycle at exabyte scale. S3 Lifecycle rules assign data to the right storage classes, including Glacier Deep Archive for data that must be kept but is almost never read (Part 3).

The thinking pattern. Treat efficiency as a multi-year programme rather than a one-off project, and pair cost with another goal (here, carbon) so the programme keeps sponsorship. Lessons: time-of-day elasticity remains a big win for stateless tiers; prove Graviton on one important workload, then generalise with the same playbook; sustainability metrics are a useful second justification for efficiency work.

3. CS-11 Honeycomb: invest once in multi-arch, then move everything

Field	Detail
Business	Observability platform ingesting and querying large volumes of telemetry
Milestone	100% of EC2 fleet on Arm64 (2022)
Coverage	Spot, C/M/R families, NVMe variants, RDS, ElastiCache
Result	Entire EC2 fleet on Graviton; Arm has publicised a roughly 50% infrastructure-cost reduction (vendor figure)

Honeycomb ingests and queries large volumes of telemetry, so compute is its dominant cost. Its path shows how a small experiment turns into a fleet-wide move.

• A one-week bake-off. An engineer's side project ran Honeycomb on Graviton2 M6g instances for a week and saw real gains in both performance and cost.
• Own code first. Services Honeycomb builds itself were the easiest to move (just recompile for arm64) and also the largest share of compute spend, so they went first.
• Then the long tail. Once multi-architecture builds existed, the team kept going through third-party and managed components until the whole EC2 fleet ran on Arm.

The thinking pattern. The expensive part of an architecture migration is building the capability: multi-arch images, arm CI runners, benchmarks. Once paid for, the marginal cost of moving another workload is small, so do not stop after the first one.

Lessons to steal. Build multi-arch images (for example with docker buildx) and run CI on arm64 as well as x86. Benchmark with production-like load, because price-performance rather than list price is the real gain. Watch for native dependencies and x86-only binaries in the long tail.

4. CS-12 Zomato: a two-week Graviton move for Trino and Druid

Field	Detail
Business	Food delivery (India)
Workload	Java-based Trino and Apache Druid analytics
Duration	About two weeks including testing
Result	~30% lower compute cost with ~25% better performance

Zomato's data platform runs near-real-time analytics on open-source Java engines, which are usually portable across CPU architectures. The team migrated the analytics clusters to Graviton-based instances with only minor tweaks. The whole effort, testing included, took about two weeks.

The thinking pattern. Pick the workload with the best ratio of spend to migration risk. JVM-based, horizontally scaled data systems usually top that list. Lessons: data platforms (Trino, Druid, Spark, Kafka, OpenSearch) are excellent first Graviton candidates; run old and new node pools side by side and compare query latency before cutting over.

5. CS-13 Zendesk: Graviton as a fleet-wide price-performance lever

Zendesk is a representative example of a mature SaaS company treating CPU architecture as a cost lever. Workloads were migrated to Graviton-based instances, and the reported outcome on AWS's Graviton customer page is up to 30% better performance and up to 42% lower cost, plus sustainability benefits. These are vendor-published, best-case "up to" figures.

The thinking pattern. When a newer generation offers better performance at a lower price, the migration pays twice: fewer instances, each cheaper. Lessons: measure savings per workload, because "up to" numbers describe the best cases; pair Graviton moves with right-sizing, since better per-core performance often means fewer or smaller instances.

6. Comparing the four

Case	Scope	Effort	Reported result	Confidence
Pinterest	One important workload; a quarter of infra by 2024	Multi-year programme	47% cost, 38% compute resources, 62% carbon	AWS case study; single-workload best case
Honeycomb	Entire EC2 fleet	Capability first, then long tail	100% of fleet on Arm; ~50% (Arm figure)	Process verifiable; savings vendor-quoted
Zomato	Trino and Druid clusters	~2 weeks with testing	~30% cost, ~25% performance	AWS Open Source Blog
Zendesk	Migrated workloads	Not published	Up to 42% cost, up to 30% performance	Vendor "up to" figures

Read across the row and a pattern emerges: the more the source is a detailed engineering account (Zomato, Honeycomb's process), the more credible its numbers; the more it is a customer testimonial ("up to"), the more you should treat it as a ceiling. All four agree on the direction and rough magnitude, which is why the lever is considered safe.

7. A Graviton pilot plan you can run this quarter

The cases converge on a repeatable sequence. The following is a synthesis, not a quote from any one team.

7.1 Select the first workload

Choose the largest compute consumer that is interpreted, JVM-based or a recompilable language, horizontally scaled, and free of x86-only binaries or licensed agents. Pinterest picked one important workload; Zomato picked a data platform; Honeycomb started with code it built itself. Avoid starting with a vendor appliance or anything whose dependencies you cannot inspect.

7.2 Build multi-architecture images once

The capability, not the first workload, is the expensive part. With Docker this is a single command that publishes one tag containing both architectures. Run CI on arm64 runners as well as x86 so regressions surface before deployment.

# build and push one manifest covering both CPU architectures
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t registry.example.com/service:1.4.0 \
  --push .

# verify the manifest lists both
docker buildx imagetools inspect registry.example.com/service:1.4.0

7.3 Benchmark with production-like load

Honeycomb's one-week bake-off is the model: run the workload on the new instances for long enough to see real traffic patterns, then compare. Measure throughput and latency percentiles, not just CPU utilisation, and compute cost per unit of work (per query, per request, per event), because price-performance rather than list price is the gain. Zomato's advice is to run old and new node pools side by side and compare query latency before cutting over.

Metric	x86 baseline	Graviton pilot	Decision rule
p50 / p99 latency	record	record	Pilot must not regress your SLO
Throughput per instance	record	record	Feeds fleet-size calculation
Instance hourly price	list price	list price	Include Spot/Savings Plan effects
Cost per unit of work	price / throughput	price / throughput	The number that matters
Error rate and restarts	record	record	Catches native-dependency surprises

7.4 Roll out by traffic share, with a rollback

Shift a small fraction of traffic to the Arm pool (weighted target groups, a canary deployment, or a separate node pool selected by a node label), watch the same dashboards, and ramp. Keep the x86 pool warm until the new one has served a full traffic cycle. If the team keeps commitments, do not buy new x86 Savings Plans during the migration; a compute Savings Plan applies across instance families and architectures, but instance-family Reserved Instances do not.

7.5 Work the long tail

Once multi-arch builds exist the marginal cost of each further workload is small. Honeycomb kept going through Spot, the C, M and R families, NVMe variants, RDS and ElastiCache until the whole EC2 fleet ran on Arm. Track the remaining x86 workloads and the specific blocker for each (a native library, a licensed agent, an unsupported base image); most blockers turn out to be one or two libraries.

8. Beyond EC2: databases, Lambda and volumes

The same price-performance logic applies to managed services, and Levels.fyi's clean-up (Part 2) shows the low-risk swaps side by side.

• RDS and Aurora. Moving from t3 to Graviton-based t4g instances lowers price per vCPU and per GB. Test extensions and drivers first, take a backup, and do the change in a low-traffic window.
• gp2 to gp3. About 20% cheaper per GB, with IOPS and throughput decoupled from volume size; set IOPS and throughput to match previous burst behaviour if needed.
• Lambda on arm64. About 20% lower duration price and often faster. Check native modules and layers; Levels.fyi moved functions after checking dependency compatibility.
• ElastiCache and OpenSearch. Graviton node types are available for both; validate client compatibility.
• Containers on Fargate. Fargate supports Arm task definitions; the multi-arch image you already built is the prerequisite.

9. Is it Graviton-ready? A checklist

Check	Why it matters
Interpreted or JVM runtime, or you control the build	Python, Node, Java, Go and Rust recompile or run unchanged in most cases
No x86-only binaries or licensed agents	The most common long-tail blocker
Base images published for arm64	Third-party images without an arm64 manifest fail at pull time
CI can build multi-arch images	The capability every later migration reuses
Benchmark on production-like load	Synthetic tests hide memory and JIT effects
Modern JDK if on the JVM	Newer JDKs have much better arm64 optimisations (Zomato caveat)
Native dependencies audited	Wheels, gems, node addons and JNI libraries need arm64 builds

10. What can go wrong

The cases are honest about limits. The 47% figure is a single workload, not a fleet average. The 50% for Honeycomb is Arm's number. Zendesk's are "up to" figures. Zomato's result depended on JVM version. In practice expect the following failure modes and plan for them:

• Silent x86 fallback. A mixed-architecture cluster can schedule an x86-only image onto an Arm node and fail at start-up. Use node selectors or taints to keep architectures separate during migration.
• Performance regressions in unusual code paths. Vectorised or intrinsic-heavy libraries may not have the same optimisations. Benchmarks on synthetic data will not reveal it; production-like load will.
• Licensing. Some commercial software is licensed per architecture or unavailable on Arm. Check before you plan.
• Debugging and tooling gaps. Profilers, sidecars and agents must support arm64 too. Discover this in the pilot, not in production.
• Over-committing. Buying instance-family reservations for the old architecture while migrating is the classic own-goal.

11. The carbon co-benefit

Pinterest reported 62% lower carbon emissions on the same workload that saved 47% in cost. Its lesson is organisational: sustainability is a useful second justification, and pairing cost with another goal helps a multi-year efficiency programme keep sponsorship when budgets tighten. If your company reports on emissions, ask your provider for the per-workload energy data and include it in the migration business case; the same fleet reduction that cuts cost usually cuts energy use.

12. A worked fleet model

To see how the two multipliers combine, take an illustrative, deliberately round fleet. The numbers are invented for the arithmetic; they are not from any case.

Input	x86 fleet	Graviton fleet
Instances needed for peak load	100	80 (each does ~25% more work)
Hourly price per instance	$0.20	$0.16 (about 20% lower)
Hours per month	730	730
Monthly compute cost	$14,600	$9,344
Change	-	-36%

A 20% lower price and a 25% throughput gain give 0.80 times 0.80 (100 divided by 125), or 0.64 of the original cost, which is a 36% reduction. That sits inside the 30-47% range the four cases report and shows why no single number should be quoted without the workload. Change either input and the answer moves: if your workload gains only 10% throughput, the same price cut yields about 27%; if it gains 40%, about 43%. The way to get the real figures is the pilot benchmark in section 7, not a marketing page.

12.1 What the model leaves out

Three things are missing from the table and each can shift the result. Data-transfer, storage and licence costs do not change with CPU architecture, so the whole-bill saving is smaller than the compute saving; Levels.fyi's ~15% and Duolingo's 20% are whole-bill numbers for exactly this reason. Right-sizing after the move can lower the fleet further. And any commitment you already hold on the old family will keep billing regardless of what you run, so check coverage before you shrink.

13. Migrating a Kubernetes node pool

Most of the teams in this series run containers, so the practical question is how to introduce Arm nodes without breaking scheduling. The safest pattern is a separate node pool with a taint, plus a pilot workload that tolerates it and selects the architecture explicitly. The manifest fragment below is a sketch of the relevant fields; adapt names and labels to your cluster.

spec:
  template:
    spec:
      nodeSelector:
        kubernetes.io/arch: arm64
      tolerations:
        - key: "arch"
          operator: "Equal"
          value: "arm64"
          effect: "NoSchedule"
      containers:
        - name: service
          image: registry.example.com/service:1.4.0   # multi-arch manifest

Because the image tag is a multi-architecture manifest, the same tag works on both pools, and the node selector alone decides where the pod lands. Run the pilot as a second Deployment with a small replica count and a weighted share of traffic (through your ingress or service mesh), rather than editing the production Deployment in place. When the pilot has served a full traffic cycle within SLO, scale the Arm Deployment up, scale the x86 one down, and finally remove the x86 pool. Karpenter users can express the same thing as an architecture requirement on a NodePool (Part 5).

14. Migrating a managed database safely

Databases are where teams are most cautious, and the Levels.fyi account shows a low-drama path: move from t3 to a Graviton-based t4g class and from gp2 to gp3 after taking backups, in a low-traffic window. A generic sequence that respects that approach:

1. Confirm the engine version and every extension you use are supported on the target Graviton class.
2. Take a manual snapshot and verify you can restore from it.
3. Prefer a Multi-AZ or replica-based approach so the change is a failover rather than an in-place stop. Modify the standby first where the engine allows it, then fail over.
4. Schedule inside a low-traffic window and watch replication lag, connection counts and error rates until they return to baseline.
5. Only after a stable cycle, right-size, and later consider a Database Savings Plan (Part 6).

Will every workload save 30-47%?

No. The largest figures are best cases on single workloads (Pinterest 47%, Zendesk "up to" 42%). Fleet-wide savings will usually be lower. Measure cost per unit of work on your own workload before promising a number.

Where should we start if we have a mixed estate?

With the largest compute consumer that is JVM-based or otherwise easily recompiled and horizontally scaled, as Zomato did with Trino and Druid. Data platforms and services you build yourself are the easiest; vendor appliances and anything with x86-only binaries go last.

Should we buy Savings Plans before or after migrating?

After. Commitments lock in today's footprint; over-committing before a Graviton move can strand discounts. Migrate, right-size on the new architecture, then commit to the trough of the new baseline (Part 6).

Takeaways

• Price-performance upgrades pay twice: a lower hourly price and fewer instances for the same work.
• The expensive part is the capability (multi-arch images, arm CI, benchmarks); after that each workload is cheap to move, so do not stop at one.
• Pick the best ratio of spend to risk first: your own code (Honeycomb) and JVM data platforms (Zomato).
• Benchmark on production-like load and compare cost per unit of work, not list price.
• Treat "up to" and vendor figures as ceilings; the 47% is one workload.
• Migrate before you commit, and right-size after you migrate.

References & further reading

• Cutting the AWS Bill: 28 Case Studies (PDF) - chapter C (CS-10 to CS-13) is the basis of this part.
• AWS - Pinterest Graviton case study
• Honeycomb - Graviton migration
• AWS Open Source Blog - Zomato Trino and Druid on Graviton
• AWS Graviton - customer testimonials and getting started
• Docker - multi-platform builds