Operators guess that a permitting app needs memory-optimized EC2 instances, but metrics show CPU saturation with comfortable free memory. What should the architect recommend?
Select an answer to reveal the explanation.
Short Explanation
If memory looks fine and CPU is the one sweating, don't buy a memory mansion. Let the metrics pick the family—guesswork is how cities overpay for the wrong shape of box.
Full Explanation
Choosing the instance family based on the observed bottleneck—CPU-optimized or general purpose when CPU saturates and memory is comfortable—is the correct recommendation for the permitting app, because family selection must follow measured resource pressure rather than operator guesses about memory-optimized shapes. Cities overpay when they buy the wrong dimension of capacity. Immediately moving to the largest high-memory family available fails because metrics contradict memory pressure and upsizing the wrong family increases cost without relieving the CPU bottleneck. Ignoring metrics and standardizing on GPU instances fails conceptually: GPUs address specialized compute/graphics workloads, not a generic CPU-bound permitting pattern shown in the metrics. Disabling CloudWatch Agent so memory metrics cannot conflict with guesses fails as an anti-pattern that destroys the evidence needed for rightsizing. Exam caveat: let bottlenecks pick EC2 families; do not escalate to max memory or GPU, or silence monitoring, when CPU is the constraint. Operational check: confirm CPU, memory, and disk metrics under peak permit load; pick compute/general-purpose types that relieve CPU; load-test; re-enable/retain detailed monitoring; and revisit Compute Optimizer so permitting stays aligned as code and traffic change.