Choosing the right managed relational database on AWS isn't just a technical decision—it's a massive financial one. The Amazon Relational Database Service (RDS) offers standard MySQL and PostgreSQL engines, alongside Amazon's proprietary, high-performance Aurora engine. However, the pricing models between standard RDS and Aurora are vastly different and can trap unwary engineering teams.
A standard RDS MySQL instance charges you for Compute (the instance size) and Storage (provisioned GBs). That's generally it. Amazon Aurora, however, decouples compute and storage. In "Aurora Standard," you pay for Compute, Storage (which auto-scales), AND I/O Operations (per million requests).
Scenario: A logistics company migrated their traditional RDS PostgreSQL database (running on a `db.m5.4xlarge`) to Amazon Aurora PostgreSQL to take advantage of its 3x performance boost and lightning-fast failover.
The Issue: Their application continuously polled the database every second to update delivery truck GPS coordinates. This created millions of tiny, continuous Write I/O operations. While their compute requirements actually dropped, their monthly AWS bill jumped from $3,500 to $12,000.
The Outcome: Over 70% of their new database bill consisted purely of Aurora I/O request charges ($0.20 per million requests). Because their workload was extremely "chatty," Aurora Standard became cost-prohibitive.
The Fix: They switched their cluster to Aurora I/O-Optimized. This relatively new pricing tier charges ~30% more for compute and storage, but makes all I/O operations completely free. Their bill instantly snapped back down to $4,200.
Unlike Aurora, which magically auto-scales your storage volume up in 10GB increments only as you need it, standard RDS MySQL and PostgreSQL require you to pre-provision storage.
Scenario: A startup using standard RDS MySQL anticipated massive growth during the holiday season. They provisioned a 2TB `gp3` SSD volume to ensure they wouldn't run out of space. The holiday rush ended up being mild, and their actual database size settled at only 400GB.
The Issue: AWS RDS bills for provisioned storage, not consumed storage. They paid for 2TB of storage every single month. Even worse, AWS RDS does not allow you to shrink a storage volume once it has been expanded. To downsize, they had to manually create a new instance with a smaller drive, export the data using `mysqldump`, and suffer hours of downtime.
High availability is essential for production, but it literally doubles your costs on standard RDS.
If you run a standard RDS PostgreSQL `db.m5.large` instance in Single-AZ, it costs ~$125/month. If you enable Multi-AZ (which provisions a synchronous standby replica in another Availability Zone), your bill doubles to ~$250/month because you are paying for two distinct EC2 instances and two EBS storage volumes.
With Aurora, Multi-AZ is handled differently. Aurora automatically replicates your data 6 ways across 3 AZs at the storage layer, regardless of your compute nodes. You only pay for additional Compute nodes (Reader instances) if you want active failover capability.