BMW Graviton Migration: 4 Steps That Saved $600,000 a Year
Cloud Platform EngineeringBMW’s connected vehicle platform serves more than 24.5 million cars and runs over 130,000 builds and deployments a day. Moving it from x86 to Arm saved about $600,000 a year, and the ingress controller alone used about 57% less CPU. For platform teams weighing a Graviton migration, the more useful part is how BMW let application teams move one at a time, with x86 always one step away.
The Framework
The AWS Architecture Blog post, co-written with BMW Group and Critical TechWorks, covers the migration of BMW Connected Company’s platform, called Orbit, which began in 2024. It started with groundwork: the team replaced fixed Managed Node Groups with Karpenter’s policy-driven node pools so the right instance type could be provisioned automatically. It then ran Graviton CI/CD runners next to the x86 fleet on a set of self-contained services, where lower cost per build minute and faster builds confirmed the business case. Four steps followed.
1. Build Every Image for Both Architectures
Every container image had to support both arm64 and amd64, published as one tag with a manifest list so each node pulls the right variant. BMW supports two paths through GitHub Actions reusable workflows: emulated builds with Docker Buildx and QEMU from a single runner, and native builds on Graviton runners. Simple Dockerfiles use QEMU. Builds with heavy dependencies or long run times go native, because emulation overhead becomes the problem. Graviton runner labels mirror the x86 ones, so switching means changing x64 to arm64 in one label. Base images are mirrored into private ECR with Google’s Crane, which keeps only the platforms needed.
2. Make Graviton Opt-In With Taints
Shared, general-purpose Graviton node pools carry taints. A workload only lands there if it has a matching node selector and toleration, so nothing moves by accident and teams migrate on their own schedule.
3. Migrate the Platform First
Before inviting application teams, BMW ran its own core services on Graviton: Karpenter, Prometheus and operational tooling. That surfaced compatibility gaps, refined node pool settings and established rollback patterns, giving teams a proven model.
4. Keep Rollback Cheap
Because every image is dual-architecture, any workload can fall back to x86 without a rebuild. Node affinity prefers Arm without forcing it. For a full rollback, the team reverts in Git and lets ArgoCD reconcile the cluster.
Where It Doesn’t Apply
The results depend on workloads that already run on Arm. BMW found most Dockerfiles needed no changes, but some dependencies needed an Arm-supported alternative, and teams with many native or proprietary binaries will have more work. BMW also had GitOps and Karpenter in place before starting. More than 65% of the platform now runs on Graviton in production, not all of it. Stack Archive has covered Graviton5 M9g instances, the newest target for this kind of move.
Beyond the ingress controller’s 57% CPU drop, price-performance improved by around 40%, and peak loads needed less compute for the same traffic.
The So What
Platform teams considering Graviton should read AWS’s Graviton getting started guide, then start with multi-architecture builds and tainted, opt-in node pools before asking any application team to move. Migrate your own platform services first, keep x86 images published until each team is stable on Arm, and measure cost per build minute on a few services to make the business case with your own numbers.
Source: AWS Architecture Blog
Content created with AI assistance and reviewed for accuracy.
Join the conversation
Stack Insiders is our free community for readers who want to go deeper — share resources, ask questions, and connect with others across every vertical we cover.
Join Stack Insiders →