Heavy council dashboard queries keep forcing a municipal Aurora OLTP cluster to larger instance classes. Which architecture change best controls that database cost?
Select an answer to reveal the explanation.
Short Explanation
Don't make the cash register do the year-end audit. Park big council reports on Redshift so Aurora stays sized for transactions, not warehouse scans.
Full Explanation
Heavy council dashboard queries are analytics-shaped: wide scans, aggregations, and historical joins that punish a row-oriented OLTP Aurora cluster and tempt architects to buy ever-larger instance classes. Offloading analytics to Amazon Redshift (a columnar warehouse) lets Aurora stay sized for transactional permitting, payments, and clerk updates while reports run on an engine built for that access pattern. Data can be moved via DMS, scheduled exports, zero-ETL style patterns where applicable, or ETL into Redshift so dashboards stop forcing OLTP upsizing.
Running the same long analytic scans only against the Aurora writer during peak permitting hours fails by concept: it maximizes contention exactly when citizens need the OLTP path. Adding more synchronous Multi-AZ standbys absorbs failover capacity, not analytic offload—standbys are for HA, not report farms. Exporting reports to Glacier Instant Retrieval confuses cold object storage with interactive SQL analytics; object GETs do not replace warehouse joins for council packets.
Exam caveat: Aurora read replicas can help light read scale, but heavy warehouse-style scans still often belong on Redshift or another analytics service. Also size Redshift (or pause/resume) to the council reporting calendar so you do not recreate 24x7 warehouse waste.
Operational check: identify top long-running dashboard SQL via Performance Insights, measure Aurora CPU and wait events during council-packet generation, land a curated Redshift schema for those reports, redirect BI tools to Redshift, then downsize or avoid Aurora upsizing and confirm permitting OLTP latency improves during report windows.