BMW Group Drives Efficiency and Sustainability Across Connected Vehicle Fleet Through AWS Graviton Migration
In an ambitious move to optimize its digital infrastructure and advance corporate environmental targets, the BMW Group has successfully migrated a substantial portion of its core Connected Vehicle platform, internally designated as Orbit, from traditional x86 processor architectures to Arm-based AWS Graviton compute instances. Executed by the BMW Connected Company division in close collaboration with Critical TechWorks (CTW)—a specialized software development joint venture established in September 2018—this large-scale engineering initiative underpins a global fleet exceeding 24.5 million connected vehicles. By transitioning more than 65 percent of its production workloads to AWS Graviton, the German automotive giant has realized over $600,000 in annualized infrastructure savings, significantly enhanced application performance, and taken a major stride toward its overarching carbon-reduction objectives.
Background Context and Environmental Imperatives
Modern automotive manufacturing is deeply intertwined with digital engineering, cloud computing, and real-time data processing. For premium automakers like BMW, maintaining a globally connected vehicle fleet requires high-availability backend infrastructure capable of handling millions of concurrent requests, telematics updates, over-the-air software deployments, and infotainment services.
As the volume of connected vehicles grew exponentially, the energy footprint and financial cost of operating the legacy x86-based Orbit platform scaled proportionately. Seeking a sustainable path forward that aligned with strict corporate mandates on energy efficiency and economic performance, BMW architecture teams initiated a comprehensive modernization strategy in 2024. The primary objective was to decouple software workloads from fixed hardware dependencies, eliminate infrastructure bottlenecks, and transition to a more power-efficient processor architecture without introducing downtime or risking service disruption for millions of end users.
Laying the Technical Foundation
The migration journey demanded rigorous foundational engineering before any application workloads could safely target the new Arm-based architecture. Recognizing that rigid provisioning mechanisms would stall the migration, the engineering teams first modernized the compute layer of their Amazon Elastic Kubernetes Service (Amazon EKS) clusters. They replaced conventional Managed Node Groups with Karpenter, an open-source, high-performance Kubernetes cluster autoscaler. Karpenter introduced dynamic, policy-driven node pools capable of automatically provisioning the exact instance types required based on real-time workload demands.
With the flexible provisioning layer established, the next critical hurdle was multi-architecture compatibility. Because the Connected Vehicle CI/CD platform facilitates upward of 130,000 builds and deployments daily using self-hosted GitHub Actions runners, build pipelines had to be completely overhauled. The platform needed to seamlessly generate and test container images for both x86 and Arm architectures simultaneously. To prevent friction for application developers, the engineering teams deployed a dual-track strategy combining emulated builds via Docker Buildx and QEMU with native builds executed directly on dedicated Graviton-based runners.
Public container images were mirrored into private Amazon Elastic Container Registry (Amazon ECR) repositories using Google’s Crane tool, ensuring strict CVE compliance, immutability, and efficient multi-architecture manifest filtering. By adopting OCI image indices, container runtimes could transparently pull the correct image variant—whether amd64 or arm64—without requiring developers to maintain divergent codebases or modify standard Dockerfiles.
Chronology and Phased Rollout Strategy
The execution of the migration followed a carefully calibrated six-stage journey divided into a build-foundation phase and a workload-migration phase. Rather than enforcing a disruptive, blanket transition, the engineering team prioritized risk mitigation and developer autonomy.
During the initial validation phase, core platform infrastructure services—including monitoring tools like Prometheus, operational controllers, and Karpenter itself—were migrated to Graviton. This platform-first approach allowed architects to identify architectural edge cases, refine node pool parameters, and validate rollback mechanisms in a controlled environment.
To govern the broader rollout, the engineering teams established mixed-architecture Amazon EKS clusters where x86 and Graviton node pools coexisted. To prevent accidental scheduling errors during the transition, the Graviton node pools were secured using taints. Application workloads were required to explicitly opt in using node selectors and matching tolerations. Furthermore, Helm chart templates were engineered with node affinity rules that preferred arm64 execution with weighted prioritization, allowing workloads to naturally migrate toward Graviton instances without forcing compliance.
If compatibility issues or unexpected runtime anomalies did surface, workloads could gracefully fall back to x86 nodes without requiring image rebuilds. In scenarios demanding a full recovery, the GitOps-based deployment model powered by ArgoCD enabled rapid rollbacks simply by reverting the cluster state in Git.
Performance Metrics and Financial Impact
The economic and technical advantages of the migration materialized rapidly. Preliminary evaluations of self-contained services running on Graviton runners confirmed an immediate improvement in price-performance, characterized by lower operational costs per build minute and accelerated execution speeds.
Following the migration of high-throughput components, such as the NGINX-based ingress controller, the operational benefits became statistically undeniable. The platform recorded a dramatic 40 percent improvement in price-performance compared to legacy x86 equivalents. By the conclusion of the primary rollout phases, annualized infrastructure savings reached approximately $600,000. Furthermore, the broader adoption of AWS Graviton directly contributed to BMW Group’s sustainability targets by substantially lowering the power density and energy demand associated with running massive, compute-intensive vehicle backend systems.
Industry Implications and Lessons Learned
Industry analysts view BMW Group’s successful transition as a watershed moment for enterprise-scale cloud modernization within the automotive sector. Moving away from homogeneous x86 architectures requires overcoming deep-seated software dependencies, testing paradigms, and operational inertia. By open-sourcing its migration methodologies and sharing practical blueprints—such as taint-based node isolation, dual-architecture CI/CD pipelines, and dynamic autoscaling via Karpenter—BMW has established a repeatable reference model for other large enterprises contemplating similar processor transitions.
Key takeaways highlighted by the engineering teams include the absolute necessity of decoupling base image management from application logic, leveraging native build runners for complex dependency trees to bypass emulation overhead, and designing platform abstractions that empower individual development teams to migrate at their own pace.
Conclusion
What began as a forward-thinking platform optimization initiative has firmly cemented itself as the default compute standard for BMW Group’s connected vehicle infrastructure. Operating silently behind the scenes of more than 24.5 million vehicles worldwide, the modernized Orbit platform handles over 130,000 daily builds and deployments with zero service interruption. Through careful architectural planning, incremental validation, and the adoption of advanced cloud-native tools like AWS Graviton and Karpenter, BMW has proven that massive digital transformations can simultaneously deliver substantial financial savings, enhanced application performance, and meaningful corporate sustainability outcomes.
