A SaaS API sees weekday peaks, idle nights, and month-end batch spikes on ECS Fargate, with Compute Optimizer flagging 40% over-provisioned CPU and memory. Which rightsizing and scaling strategy best aligns cost with performance metrics?

The correct strategy aligns all four signals: Compute Optimizer rightsizing removes the 40% over-provisioning baseline, target tracking handles weekday peaks by maintaining utilization, scheduled scaling scales down for idle nights, and Fargate Spot absorbs interruptible month-end batch at discount. The alternative keeping current sizes with full autoscaling and Spot preserves elasticity and cheap batch but fails on rightsizing, leaving waste no scaling policy can cure because tasks stay oversized at any count. The alternative using Compute Optimizer with target tracking but keeping batch on On-Demand nails performance and baseline cost yet violates batch economics, since retryable batch is the canonical Spot use case and On-Demand leaves savings untapped. The alternative using Compute Optimizer with scheduled scaling and Spot but omitting target tracking covers predictable cycles and cheap batch yet breaks on responsiveness, because fixed schedules cannot track intraday variance and cause throttling or idle capacity. Exam caveat: target tracking suits metrics-driven variance while scheduled scaling suits time-driven predictability, and the exam often expects both together. Practical check: load-test rightsized tasks for p95 latency, verify Spot retry handling, and track scaling activity with Cost Explorer by launch type.