BMW Group’s Connected Company has successfully migrated its Orbit connected vehicle platform from x86 processors to AWS Graviton Arm-based compute. Leveraging dynamic provisioning with Karpenter and multi-architecture container builds, the platform gains roughly 40% improved price-performance and cuts CPU usage for critical ingress workloads by over half, all while maintaining uninterrupted service.
- Dynamic node provisioning with Karpenter replaces fixed managed node groups
- CI/CD pipelines extended for multi-architecture builds and fast Graviton validation
- Achieved 57% CPU reduction on NGINX ingress and 40% better price-performance
Infrastructure signal
To enable smooth migration from x86 to Arm-based AWS Graviton instances, BMW Connected Company overhauled its compute provisioning layer by integrating Karpenter. This dynamic, policy-driven node manager replaced fixed Managed Node Groups, allowing the platform to automatically scale and assign the correct instance types based on workloads. The shift fundamentally improved scalability and resource utilization by matching compute needs with appropriate hardware without manual intervention.
In parallel, the container ecosystem adapted to support multi-architecture images. Using Docker Buildx with QEMU for emulated builds and Graviton-native runners for performance, BMW’s teams produced OCI manifest-based multi-arch container images. These images seamlessly serve both amd64 and arm64 nodes under a single tag. The images, including public dependencies mirrored privately via Google’s Crane tool, ensure availability, security, and minimized storage overhead by filtering extraneous architectures.
Developer impact
BMW’s CI/CD platform, which manages over 130,000 daily builds and deployments, evolved to support dual-architecture pipelines without sacrificing speed. Dedicated self-hosted GitHub Actions runners for Graviton ran alongside existing x86 runners during the initial validation phase, enabling developers to incrementally test and migrate services without disruption. This side-by-side operation allowed for early detection of issues and gradual confidence-building in the new architecture.
Multi-architecture container support lowered barriers for developers by largely requiring no changes to existing Dockerfiles, thanks to pre-existing Arm support in base images and dependencies. Where gaps existed, teams swapped out components with Arm-compatible alternatives. This approach enabled teams to adopt Graviton at their own pace, maintaining workflow continuity while progressively benefiting from cost and performance improvements.
What teams should watch
Teams managing critical workloads, such as NGINX ingress controllers, can expect significant CPU reductions and cost savings on AWS Graviton. Continuous monitoring of multi-architecture build pipelines and deployment metrics remains essential to smoothly expanding Graviton usage across services beyond self-contained components. Observability tooling should be adapted to track architecture-specific performance and fault patterns.
As the platform advances through a six-stage Graviton adoption journey, teams should prepare to support flexible instance provisioning with policy-driven autoscaling via Karpenter. Integration of multi-architecture container manifests into deployment workflows must be maintained to ensure seamless image selection by runtime. Additionally, teams should watch for upstream dependencies requiring Arm support and coordinate timely updates to maintain conformity and security, especially when mirroring public images into private registries.