BMW Connected Company began migrating Orbit, its connected-vehicle platform, from x86 to Arm-based AWS Graviton in 2024. A technical account published by AWS on October 29, 2026, and co-written by representatives of BMW Group and Critical TechWorks, describes a gradual rollout that kept both architectures in use.
What BMW moved to Graviton
Orbit is BMW Connected Company’s Connected Vehicle platform. The account describes digital services for a worldwide fleet of more than 24.5 million vehicles. Its CI/CD platform, which automates building and deploying software, handled more than 130,000 builds and deployments daily through self-hosted GitHub Actions runners.
At the time the account was published, its co-authors said more than 65% of the platform was running on Graviton across production environments. That figure is specific to Orbit’s reported adoption.
How BMW supported x86 and Arm together
BMW’s build pipelines and container images supported both x86/amd64 and Arm/arm64. An OCI image index can package architecture-specific versions under one image reference; when a container starts, the runtime selects the version that matches its node.
The team used native runners for architecture-specific builds and Docker Buildx with QEMU emulation. Native runners avoid emulation overhead. QEMU can let a single runner build for multiple architectures, but may slow compute-intensive builds. Public images were mirrored to private Amazon ECR using Google Crane, which filters image manifests to the required platforms.
How teams moved workloads gradually
The rollout began with self-contained services, then moved to core platform services such as Karpenter, Prometheus and operational tooling before broader application adoption. Graviton node pools were opt-in: Kubernetes taints, selectors and matching tolerations directed workloads marked ready for Arm to those nodes. Node affinity could prefer Arm without requiring it, while x86 nodes remained available.
The account also describes dual-architecture images and x86 capacity as fallback options. With ArgoCD, the team could revert to an earlier Git version and reconcile the cluster to that state. These were migration provisions, not a reported rollback incident.
Results the co-authors reported
| Measure | Reported result | Scope |
| Annualized infrastructure savings | Approximately $600,000 | Infrastructure savings attributed to the migration |
| NGINX ingress-controller CPU consumption | Approximately 57% lower | After moving from x86 to Graviton while maintaining the same ingress profile |
| Ingress price-performance | Around 40% better | The reported ingress result, associated with lower CPU use per request and greater throughput capacity per dollar |
| Graviton adoption | More than 65% | Share of the platform reported running on Graviton across production environments at the account’s publication |
The co-authors report the CPU and price-performance figures for the NGINX ingress-controller workload. They describe separate measures: CPU consumption at the same ingress profile and price-performance for that ingress result.
