City utility billing OLTP must remain highly available after migration, while finance wants multi-year usage analytics that currently hammer the same on-premises SQL Server. Which database-platform selection should architects make for the new architecture?
Select an answer to reveal the explanation.
Short Explanation
The cash register and the research library should not be the same machine. Keep billing on RDS or Aurora so payments stay snappy, and send the big history questions somewhere built for analytics. Super-sizing one SQL box is how month-end reports take down payment night.
Full Explanation
City utility billing OLTP that must remain highly available after migration, while finance wants multi-year usage analytics that currently hammer the same on-premises SQL Server, should keep billing OLTP on Amazon RDS or Amazon Aurora and offload analytics to a purpose-built analytics path rather than growing the OLTP box. That separates citizen billing integrity from analytic scans that once degraded payments. Scaling the single OLTP instance vertically forever so billing and analytics share one box fails isolation and cost curves. Moving billing transactions into Amazon OpenSearch Service documents as the system of record fails OLTP transactional requirements. Replacing the billing OLTP database with Amazon S3 Select as the only query engine fails transactional consistency for payments and adjustments. Exam caveat: separate OLTP (RDS/Aurora) from analytics rather than one forever-growing box. Operational check: migrate OLTP to RDS/Aurora Multi-AZ, stream or ETL to Redshift/S3 analytics, validate billing SLAs, and stop heavy analytic queries on the OLTP endpoint. Document the decision in the municipal architecture decision record and re-verify controls after the first production wave so auditors see continuous improvement, not one-time tribal knowledge.