Linux-based municipal microservices are being sized for a new ECS/EKS deployment. Performance tests pass on arm64 builds. Which compute choice best balances cost and performance?
Select an answer to reveal the explanation.
Short Explanation
If the containers already speak arm and the stopwatch is happy, Graviton is usually the cheaper horse. Giant x86 “just because” is how quiet services fund someone else’s yacht.
Full Explanation
Linux municipal microservices that already pass performance tests on arm64 builds should prefer AWS Graviton-based instance types when images are multi-arch and SLAs hold. Graviton commonly improves price-performance for compatible container workloads on ECS/EKS, reducing cost per unit of work for city platforms without changing functional behavior. The choice works because compute selection for new solutions is measured: if arm-compatible builds meet latency and throughput targets, paying x86 premiums for habit alone wastes budget. Mandating only the largest x86 bare-metal hosts for every microservice regardless of utilization fails by oversizing and ignoring architecture fit. Refusing Graviton when multi-arch images and tests pass, citing habit alone, fails conceptually—habit is not a non-functional requirement. Running Linux services on macOS dedicated hosts as the primary production fleet fails as a platform mismatch outside normal AWS Linux microservice patterns and cost models. Exam caveat: not every dependency is arm-ready; validate third-party agents, native libraries, and observability sidecars on Graviton in nonprod before a wholesale cutover. Operational check: run identical load tests on matched Graviton and x86 task sizes, compare p99 latency and Cost Explorer unblended cost per million requests, and document any blocked packages before setting Graviton as the default launch template.