SYSTEM Cited by 3 sources
AWS Graviton¶
Overview¶
AWS Graviton is Amazon's family of custom Arm-based
(arm64) server processors, sold as
EC2 instance families (the g suffix: c7g, m7g, r7g,
and later generations). The pitch is price-performance and energy
efficiency versus comparable x86 instances. The chip itself is covered for
one generation on systems/graviton3. This page is the umbrella entry:
what it takes to move a production fleet from x86 to Graviton.
Migrating a fleet from x86 to Graviton¶
The wiki's sources agree that the hard part is not the CPU but the build and scheduling plumbing around it:
- Multi-arch container images. Publish an amd64 and an arm64 image behind one tag via an OCI image index (manifest list). The container runtime picks the variant that matches the node, so deployment manifests do not change. Build either natively (one runner per architecture, then an index-creation job) or emulated (Docker Buildx + QEMU on one runner). Emulation is simpler but much slower for compute-heavy builds. (Source: sources/2026-10-29-aws-how-bmw-group-accelerated-connected-vehicle-workloads-on-aws-graviton)
- Registry mirroring must keep the index. When public base images are mirrored into ECR, the copy tool must preserve the manifest list; BMW uses Google's Crane and filters to the needed platforms only. (Source: sources/2026-10-29-aws-how-bmw-group-accelerated-connected-vehicle-workloads-on-aws-graviton)
- Opt-in scheduling on Kubernetes. A tainted Graviton
Karpenter NodePool next to the x86 pool; workloads
opt in with a node selector + toleration, and a soft
kubernetes.io/arch=arm64affinity prefers Arm without forcing it. (Source: sources/2026-10-29-aws-how-bmw-group-accelerated-connected-vehicle-workloads-on-aws-graviton) - Keep both architectures viable. With dual-arch images and the x86 pool in place, a failing workload falls back to x86 without a rebuild — a patterns/fast-rollback built into the migration, run as a patterns/staged-rollout (platform services first, then teams). (Source: sources/2026-10-29-aws-how-bmw-group-accelerated-connected-vehicle-workloads-on-aws-graviton)
- Per-architecture images on ECS. Manta keeps separate ECR images per architecture and role (Graviton, x86-64, GPU) and runs ETL, training, and optimization on Graviton where possible. (Source: sources/2026-10-27-aws-vessel-specific-voyage-optimization-with-machine-learning-manta-on-aws)
Reported results¶
| Who | Workload | Result |
|---|---|---|
| BMW Group (Orbit) | Fleet of 400+ EKS clusters | ~$600k/yr saved; ~40% better price-performance; >65% of production on Graviton |
| BMW Group | NGINX-based ingress controller | ~57% less CPU at the same ingress profile |
| BMW Group | CI runners | Lower cost per build minute, faster builds |
| Manta Marine | Large-dataset ETL pipeline | ~25–30% better price-performance |
All of these are vendor co-authored case studies with no baseline instance types. Treat them as directional; Manta explicitly notes its number is below AWS's generic "up to 40%" claim.
Seen in¶
- sources/2026-10-29-aws-how-bmw-group-accelerated-connected-vehicle-workloads-on-aws-graviton — primary subject: BMW's six-stage x86→Graviton migration methodology (multi-arch builds, tainted opt-in NodePools, platform-first rollout, ArgoCD rollback).
- sources/2026-10-27-aws-vessel-specific-voyage-optimization-with-machine-learning-manta-on-aws — Graviton for ETL/training/optimization on ECS-on-EC2 with per-arch images.
- sources/2022-07-11-highscalability-stuff-the-internet-says-on-scalability-for-july-11th-2022 — Graviton3 chip-level framing (see systems/graviton3).