Weeks of Enhanced Monitoring and Performance Insights show a municipal permitting RDS instance consistently under 20% CPU and memory with no storage throughput saturation. Which continuous-improvement action best rightsizes based on that evidence?
Select an answer to reveal the explanation.
Short Explanation
If permitting’s RDS has been coasting under 20% for weeks, it’s wearing a jacket two sizes too big. Downsize with evidence, then watch the meters. Extra Multi-AZ Regions and random replicas aren’t rightsizing.
Full Explanation
When weeks of Enhanced Monitoring and Performance Insights show a municipal permitting RDS instance consistently under 20% CPU and memory with no storage throughput saturation, continuous improvement means rightsizing from evidence: downsize the instance class to a smaller size that still meets observed CPU, memory, and I/O headroom, then revalidate after the change. That returns unused capacity to the city budget without a platform rewrite. Immediately converting the database to Multi-AZ in every Region to improve rightsizing scores fails because Multi-AZ is a high-availability choice, not a rightsizing metric, and spreading to every Region multiplies cost without addressing oversize. Adding three read replicas in unused Regions solely to lower primary CPU further fails when the primary is already underutilized—replicas add cost and complexity without a read-scaling need. Switching the engine from PostgreSQL to a self-managed EC2 database to avoid instance-class decisions fails by increasing operational toil and dodging the actual evidence-based class reduction. Exam caveat: rightsizing uses observed utilization headroom; HA topology changes and engine rewrites are separate decisions. Operational check: capture Performance Insights baselines, choose the next-smaller class with documented headroom, change in a maintenance window, re-run permitting load tests, watch freeable memory and CPU credits or utilization, and record the civic change ticket with before/after cost.