A food-delivery platform orchestrates 12 million short order-status checks monthly, each workflow runs under 40 seconds with many Lambda transitions, and order APIs run on x86 EC2 at 65% CPU. Finance demands lower orchestration and compute bills without latency impact. Which cost-optimized architecture meets these workload requirements?

The correct architecture matches pricing to workload shape: Express Workflows bills per execution plus duration and supports durations up to five minutes, making it ideal for 12 million sub-40-second runs where many transitions would make Standard per-state-transition pricing dominate cost, while Lambda on Graviton2 and rightsized Graviton EC2 improve price-performance for event-driven code and sustained 65% CPU APIs without latency change when ARM builds are compatible. The Standard-based alternative correctly captures Graviton compute savings but fails orchestration economics because Standard is designed for long-running, exactly-once workflows with full history and callbacks, so per-transition billing at this volume and transition count defeats the finance goal to lower orchestration bills. The retain-x86 alternative correctly optimizes orchestration and Lambda yet misses the compute requirement because keeping the API fleet on x86 for compatibility forgoes proven Graviton savings and rightsizing opportunity at moderate utilization. The burstable-consolidation alternative is a legitimate pattern for spiky low-average workloads but violates the no-latency-impact constraint because burstable instances depend on CPU credits and throttle under sustained 65% load, creating queuing and tail latency for order APIs. Exam caveat: never default to Standard for reliability alone, always map duration, monthly volume, and transition count to Express versus Standard pricing and limits. Practical check: validate ARM compatibility with staging load tests and confirm impact with Compute Optimizer, Step Functions execution metrics, and Cost Explorer before full migration.