July 16, 2026

Estimating Amazon RDS costs before you deploy: the six line items

Most RDS cost surprises are not surprises at all. They are the result of estimating one component and ignoring five others. The database instance is the line everyone quotes, but the bill also carries storage, provisioned IOPS, backup storage past the free allowance, the Multi-AZ multiplier, and data transfer. Estimating before you deploy means working each component from its published rate, not pinning a single instance price and hoping the rest rounds to zero. The two current-rate sources that stay accurate are the AWS Pricing Calculator and the Amazon RDS pricing page, and any number in this article is something you should re-derive from one of those before you commit.

Line 1: instance hours

The instance is billed per hour while it runs, and the rate depends on two choices: the database engine and the instance class. MySQL, PostgreSQL, MariaDB, and SQL Server Express fall into the cheaper open-source engine tier. SQL Server Web, Standard, and Enterprise carry a meaningfully higher per-hour rate because the license rides along. Oracle follows the same licensed-engine pattern unless you bring your own license. The estimation method is the published hourly rate for your engine and class multiplied by 730 hours per month. A stopped RDS instance still bills for storage but not for compute, which is different from EC2 and catches teams off guard.

Line 2: storage

Storage is billed per GB-month and the rate depends on the volume type. General purpose SSD storage, gp3, is the current default and is cheaper per GB than the older gp2. Provisioned IOPS SSD, io1 and io2, is for latency-sensitive workloads and carries a higher per-GB rate plus a separate IOPS charge. Magnetic storage exists but is legacy and rarely the right answer. The estimation method is provisioned GB multiplied by the per-GB-month rate. Note that the bill reflects provisioned capacity, not used capacity. A database with 500 GB provisioned and 40 GB of data bills the full 500 GB.

Line 3: provisioned IOPS

For gp3, a baseline of IOPS is included with the volume and additional IOPS are charged on top. For io1 and io2, every provisioned IOPS is billed monthly, with a minimum ratio of IOPS to GB that limits how high you can push IOPS for a given volume size. The estimation method is the number of provisioned IOPS above the included baseline, multiplied by the per-IOPS-month rate. IOPS overprovisioning is the most common silent multiplier here, because the number is easy to crank up during a performance investigation and awkward to dial back later.

Line 4: backup storage

Backup storage is free up to the size of the provisioned database storage, and anything above that allowance is billed per GB-month. The estimation method is the total automated backup storage plus manual snapshot storage, minus the free allowance equal to your provisioned database storage, multiplied by the per-GB-month backup rate. A database with a long retention window and frequent changes can blow through the allowance quickly, and the line rarely gets attributed back to the workload that created it.

Line 5: Multi-AZ

Multi-AZ is where the estimate doubles. Enabling Multi-AZ provisions a standby instance in a second Availability Zone with synchronous replication. The instance hours double and the storage cost doubles, because the standby carries a full replica of the primary storage. IOPS on the primary also multiply, because every write is written to both the primary and the standby. The estimation method is the single-AZ total for instance, storage, and IOPS, multiplied by two. This is the component teams most often forget, and it turns a clean estimate into a doubled bill the moment Multi-AZ gets enabled for safety. For more on this pattern, see RDS: the quiet doubler on the AWS bill and Every RDS instance is Multi-AZ.

Line 6: data transfer

Data transfer is the last line and the one with the most carve-outs. Data transfer into RDS from the internet or within the same Availability Zone is free. For Multi-AZ deployments, the replication traffic between the primary and standby is included and does not bill as cross-AZ transfer, which is a specific exception and not a general rule. Cross-AZ transfer for application traffic to the database does bill in each direction. Cross-region transfer, such as a read replica in another region or a snapshot copied to a disaster recovery region, bills at the cross-region rate. The estimation method is the GB of cross-AZ and cross-region traffic multiplied by the relevant per-GB rate, and this is the line most likely to be missing entirely from a pre-deploy estimate.

The three mistakes to avoid

The first mistake is forgetting Multi-AZ doubling. A single-AZ instance estimate applied to a Multi-AZ deployment undercounts instance, storage, and IOPS by half. The second is IOPS overprovisioning, where a volume is sized at several times the throughput it actually needs, and the IOPS charge quietly exceeds the storage charge. The third is backup retention past the free allowance, where a long retention window on a frequently changing database turns backup storage into a real line item that nobody tied back to the workload.

Cloud Horizons tracks RDS spend across AWS, Azure, and GCP in real time, so the six line items above are visible as they accrue instead of discovered at the end of the month. See the features page for how it breaks down database spend by workload.