A municipality compares self-managed MySQL on EC2 with Amazon Aurora MySQL-Compatible for a new case-management database. Staff already work overtime on patching and failover drills. Which TCO framing is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
If the night crew is living in the data center for MySQL patches, that overtime is part of the price tag. Aurora’s sticker can look higher until you stop pretending human HA is free.
Full Explanation
Total cost of ownership for a municipal case-management database must include operational labor, not only EC2 and storage list prices. When staff already work overtime on patching and failover drills for self-managed MySQL on EC2, those hours are real budget and opportunity cost. Amazon Aurora MySQL-Compatible’s managed storage, automated backups, and Multi-AZ-oriented operations often reduce that labor; the appropriate TCO framing therefore compares Aurora’s managed operations against self-managed effort plus infrastructure line items. Counting only EC2 On-Demand list price fails because it systematically hides backup tooling, patching, and HA labor that dominate existing municipal overtime. Assuming Aurora always costs more in every scenario fails conceptually: managed services can lower TCO when operational load shrinks enough to offset service premiums. Excluding patching and HA labor because municipal IT time is “free” fails governance reality—staff time is constrained and belongs in architecture TCO for new solutions. Exam caveat: Aurora is not universally cheaper; very small or already heavily automated fleets may not see labor savings large enough to justify migration—run a workload-specific TCO, not a slogan. Operational check: inventory annual hours spent on MySQL patching, backup verification, and failover drills; price those hours; build Pricing Calculator options for EC2 MySQL vs Aurora; and present both infrastructure and labor columns to the architecture review board.