Migrating BMW Connected Vehicle Platform to AWS Graviton

BMW Group undertook a significant modernization initiative to migrate its Connected Vehicle platform, Orbit, to AWS Graviton processors. This migration aimed to achieve better price-performance and environmental benefits, impacting a fleet of over 24.5 million vehicles. The strategy focused on a non-disruptive, phased rollout, allowing application teams to transition at their own pace.

Architectural Foundation: Karpenter and Multi-Architecture CI/CD

A critical first step was adopting Karpenter to replace fixed Kubernetes Managed Node Groups with dynamic, policy-driven node pools. This provided the flexibility needed to provision appropriate instance types automatically, supporting both x86 and Graviton. Concurrently, the CI/CD platform, handling over 130,000 builds daily, was extended to support multi-architecture builds, requiring runners capable of targeting both x86 and Arm architectures and producing dual build pipelines.

Multi-Architecture Container Image Strategy

To enable seamless workload migration, every container image needed to support both architectures. BMW used two main approaches for multi-architecture builds:

1. Emulated Builds with Docker Buildx and QEMU: This allows building all architectures from a single x86 or Arm runner, streamlining pipelines but introducing emulation overhead.
2. Native Builds per Architecture: Each architecture is built and pushed separately on a runner with a matching architecture (e.g., Graviton runners for arm64 builds). This is more reliable and avoids emulation overhead, surfacing architecture-specific issues earlier.

For platform-scale adoption, native builds on Graviton runners were preferred. Additionally, public base images were mirrored to a private Amazon ECR, leveraging Google's Crane to preserve multi-arch support while ensuring availability, immutability, and CVE compliance. This results in a single image tag serving both arm64 and amd64 nodes transparently.

Kubernetes Cluster Configuration for Mixed Architectures

The Amazon EKS cluster was configured to support mixed architectures with dedicated Graviton node pools. These pools use taints to prevent accidental scheduling; workloads must explicitly opt-in using node selectors and tolerations. This strategy ensures a controlled rollout and predictable behavior, allowing x86 workloads to continue uninterrupted while Arm-ready workloads are scheduled on Graviton.

nodeSelector: bmw.de/stateless-arm: supported
tolerations:
- key: "bmw.de/stateless-arm"
  operator: "Equal"
  value: "supported"
  effect: "NoSchedule"

The migration yielded substantial benefits, including approximately $600,000 in annualized infrastructure savings and significant performance improvements, such as a 57% decrease in CPU consumption for the NGINX-based ingress controller. This demonstrates the economic and performance advantages of moving to Arm-based compute in large-scale distributed systems.