Amazon RDS: pricing, Multi-AZ, backups and how to cut the bill

Amazon Relational Database Service (Amazon RDS) runs a relational database for you and bills it by the hours of its DB instances, but the instances are rarely the whole RDS bill. AWS's billing page lists what you pay for: "DB instance hours", "Storage (per GiB per month)", "Provisioned IOPS (per IOPS per month)", "Backup storage (per GiB per month)" and "Data transfer (per GB)", and the pricing pages add Extended Support for engine versions past their support date. This article explains what runs under an AWS RDS database, how RDS pricing works line by line, and the ways AWS documents to reduce RDS costs, priced with the list prices of the Paris Region (eu-west-3). Four architectures show what the levers do to whole monthly bills, and the cost section opens with an index of the levers, in the order to work through them.

What Amazon RDS is

In AWS's words, Amazon RDS "is a web service that makes it easier to set up, operate, and scale a relational database in the AWS Cloud". It runs six engines, "IBM Db2, MariaDB, Microsoft SQL Server, MySQL, Oracle Database, and PostgreSQL". Amazon Aurora is "part of the managed database service Amazon Relational Database Service (Amazon RDS)" (What is Amazon Aurora?) but has a user guide, and a storage model, of its own. "The basic building block of Amazon RDS is the DB instance": "an isolated database environment in the AWS Cloud", which "can contain one or more user-created databases".

What RDS takes on is what you would run yourself on Amazon EC2. The user guide's comparison splits the work this way:

Application optimization stays yours on both: "You are responsible for query tuning, which is the process of adjusting SQL queries to improve performance." The same guide is plain about its preference:

We recommend Amazon RDS as your default choice for most relational database deployments.

The pay model is short: "Amazon RDS is free to try and you pay only for what you use with no minimum fees" (Amazon RDS pricing), On-Demand or with a commitment, both priced in How RDS pricing works. The free tier is left out here.

How RDS works under the hood

AWS documents RDS at the level of instances, volumes, replication, endpoints, backups and support dates, and each of them is a line of the bill: the instance hours, the storage and its IOPS, the standby billed as a second instance, the backups beyond the free allocation, Extended Support. How a Multi-AZ DB instance replicates below the word "synchronous" is not documented, and is left out.

A DB instance: an EC2 instance and EBS volumes that RDS runs for you

Does RDS run on EC2? The user guide's answer is in what a stop does: among its steps, "Detach the EBS storage volumes associated with your DB instance" and "Terminate the underlying Amazon EC2 instance." The storage is Amazon Elastic Block Store (Amazon EBS): RDS for Db2, MariaDB, MySQL, PostgreSQL, Oracle and SQL Server "use Amazon Elastic Block Store (Amazon EBS) volumes for database and log storage". Applications reach the database through its endpoint: "You should always connect to a DB instance using the DNS endpoint, not the IP address." A Multi-AZ DB instance adds a standby in a second Availability Zone (Multi-AZ DB instance deployments):

Scroll the diagram sideways →

So the bill splits as the machine does: instance hours for the EC2 instance RDS runs, storage for the volumes, which stay, and stay billed, while the instance is stopped. The EC2 article explains what runs under an EC2 instance, and its storage section how EBS volumes are billed.

Reading a DB instance class name

"The DB instance class determines the computation and memory capacity of an Amazon RDS DB instance", and a class is a type and a size: "db.r6g is a memory-optimized DB instance class type powered by AWS Graviton2 processors. Within the db.r6g instance class type, db.r6g.2xlarge is a DB instance class." After db., the name reads as an EC2 instance name (Reading an instance name in the EC2 article):

dbDB instance class.rseries: memory6generationgoption: Graviton.largesize

The class types are "General-purpose", "Memory-optimized", "Compute-optimized", "Burstable-performance" and "Optimized Reads"; a d after the generation, as in db.r6gd, adds local NVMe storage. The Paris price list has RDS for PostgreSQL rates for these classes (db.r7g has Aurora rows only):

Burstable db.t4g instances "are configured for Unlimited mode. This means that they can burst beyond the baseline over a 24-hour window for an additional charge"; the EC2 article explains the CPU credits behind it. For RDS for PostgreSQL, the Paris price list prices those credits for db.t3 only, $0.075 per vCPU-hour, and the RDS for PostgreSQL pricing page says "The CPU Credit pricing is the same for all T4g and T3 instance sizes across all regions and is not covered by Reserved Instances".

Memory sizes the class first: "An Amazon RDS performance best practice is to allocate enough RAM so that your working set resides almost completely in memory", and under load "The value of ReadIOPS should be small and stable." A class change costs a short outage: "your database will be temporarily unavailable while the DB instance class is modified. This period of unavailability typically lasts only a few minutes", and in Multi-AZ "these operations occur first on the standby, prior to automatic failover" (Amazon RDS FAQs).

Storage: gp2, gp3, io1 and io2, on one volume or four

RDS has two families of SSD storage (Amazon RDS DB instance storage): "Provisioned IOPS SSD (also known as io1 and io2 Block Express) and General Purpose SSD (also known as gp2 and gp3)". gp3 and io2 Block Express are the recommended types, gp2 and io1 the previous generation, and magnetic storage is deprecated: "Amazon RDS has migrated existing magnetic storage volumes to gp3". What sets their performance is striping: "depending on the engine selected and the amount of storage requested, Amazon RDS automatically stripes across multiple volumes to enhance performance". For MariaDB, MySQL and PostgreSQL, from 400 GiB the storage is four volumes instead of one (from 200 GiB for Oracle, never for SQL Server), and gp3's baseline follows:

So under 400 GiB, a PostgreSQL database on gp3 cannot buy more IOPS: it grows to 400 GiB or moves to Provisioned IOPS storage, and "For all DB engines, you pay for only the additional provisioned storage performance." gp2's baseline grows with its size instead, "3 IOPS for each GiB, with a minimum of 100 IOPS", and volumes "below 1,000 GiB in size also have the ability to burst to 3,000 IOPS". The latency each type promises is the other half of the choice:

AWS's positioning follows: "Provisioned IOPS storage is best suited for production environments", "General Purpose storage is best suited for development and testing environments", and for production OLTP it recommends "Multi-AZ deployments for enhanced fault tolerance with Provisioned IOPS storage for fast and predictable performance". The instance types page is softer, calling General Purpose (SSD) storage the one "we recommend as the default choice for a broad range of database workloads". Two rules hold for every type: "You can only increase the allocated storage. You can't reduce the allocated storage", and a read replica's storage type "is independent of that on the primary DB instance".

Multi-AZ: one standby, or a cluster with two readable standbys

Is Multi-AZ synchronous or asynchronous? It depends on which of the two deployments: "Multi-AZ deployments can have one standby or two standby DB instances".

A · Multi-AZ DB instance

Instances

A primary and one standby, in two zones

Replication

Synchronous

Serves reads

The primary only: the standby serves none

Failover

Typically 60 to 120 seconds, by DNS

B · Multi-AZ DB cluster

Instances

A writer and two readers, in three zones

Replication

Semisynchronous, the engine's own

Serves reads

The writer and both readers

Failover

Typically under 35 seconds

What differs: whether the standbys serve reads, and how fast the deployment fails over.

A Multi-AZ DB instance keeps "a synchronous standby replica in a different Availability Zone", and "The high availability option isn't a scaling solution for read-only scenarios. You can't use a standby replica to serve read traffic." The synchronism has a price in latency: such deployments "can have increased write and commit latency compared to a Single-AZ deployment". When the primary fails, "The failover mechanism automatically changes the Domain Name System (DNS) record of the DB instance to point to the standby DB instance", so connections must be re-established, and "Failover times are typically 60–120 seconds." A failover follows the loss of a zone, of the network, of the compute unit or of the storage of the primary, but "Amazon RDS Multi-AZ deployments do not failover automatically in response to database operations, such as long running queries, deadlocks, or database corruption errors" (Amazon RDS FAQs).

A Multi-AZ DB cluster "has a writer DB instance and two reader DB instances in three separate Availability Zones", replicated with "the DB engine's native replication capabilities": semisynchronous, it "requires acknowledgment from at least one reader DB instance in order for a change to be committed". Its readers serve reads through a reader endpoint, and "Failover times are typically under 35 seconds". It runs RDS for PostgreSQL and RDS for MySQL (Amazon RDS Multi-AZ), on classes with local NVMe storage only; in Paris, for PostgreSQL, db.c6gd, db.m5d, db.m6gd, db.r5d and db.r6gd. It also gives up features that bear on cost (its limitations): stopping and starting, storage autoscaling, cross-Region automated backups, and copying its snapshots.

Scroll the diagram sideways →

Read replicas: asynchronous copies, billed as DB instances

"A read replica is a read-only copy of a DB instance", and "When you make updates to the primary DB instance, Amazon RDS copies them asynchronously to the read replica." It is billed as what it is: "Read replicas are billed as standard DB instances at the same rates as the DB instance class used for the replica. You aren't charged for the data transfer incurred in replicating data between the source DB instance and a read replica within the same AWS Region." RDS for MySQL, MariaDB and PostgreSQL allow "up to 15 read replicas for a given source DB instance" (Amazon RDS FAQs), created by hand: "RDS doesn't support autoscaling of read replicas". A replica serves read-heavy work, reporting, reads while its source is unavailable, or disaster recovery once promoted; to protect writes, AWS recommends running the DB instance "as a Multi-AZ deployment". Pattern 2 prices a Multi-AZ DB instance with two replicas against a Multi-AZ DB cluster.

Backups: daily snapshots and transaction logs, kept in Amazon S3

"Amazon RDS creates and saves automated backups of your DB instance or Multi-AZ DB cluster during the backup window of your DB instance": a snapshot of the whole DB instance's storage, then incremental ones, "only the data that has changed after your most recent snapshot". With the transaction logs ("RDS uploads transaction logs for DB instances to Amazon S3 every five minutes", says the guide to point-in-time restores), they restore a database to a specified time, "creating a new DB instance without modifying the source DB instance". "Backups are stored in Amazon S3", and "the backup data (including transactions logs) is geo-redundantly replicated across multiple Availability Zones" (Amazon RDS FAQs). What RDS keeps, and for how long (backup retention period):

A snapshot exported to Amazon S3 serves analysis, "stored in an Apache Parquet format", not recovery: "You can't restore exported snapshot data from S3 to a new DB instance". After a restore, the new DB instance can be used at once and "continues to load data in the background" (Restoring to a DB instance). What backups cost is in Backup storage and the free allocation.

Engine versions: standard support, then Extended Support

Each major version of an engine has an RDS end of standard support date. After it, "RDS Extended Support allows you to continue running a database on a major engine version past the RDS end of standard support date for an additional cost", for up to three years, after which RDS "will automatically upgrade your major engine version". Enrollment is automatic, unless the EngineLifecycleSupport setting turns it off, at creation, at restore or later on the existing database (Overview of Amazon RDS Extended Support). The dates of the versions this article meets (PostgreSQL release calendar, MySQL on Amazon RDS versions):

PostgreSQL 13's Extended Support ends on February 28, 2029, and "MySQL 5.7 and 8.0 are now only available under RDS Extended Support." What it costs in Paris is in Extended Support.

What RDS is used for

AWS points each kind of workload to a deployment or a pricing option across its documentation: What is Amazon RDS?, the Amazon RDS FAQs, DB instance storage, read replicas, the Multi-AZ DB cluster guide, stopping a DB instance and the Amazon RDS pricing page:

RDS or Aurora?

Aurora stores data differently, so per-hour prices compare only part of the bill. "Aurora data is stored in the cluster volume, which is a single, virtual volume that uses solid state drives (SSDs)", with copies "across three Availability Zones in a single AWS Region", and "The amount of replication is independent of the number of DB instances in your cluster" (Amazon Aurora storage). Two configurations price its I/O: Aurora I/O-Optimized, "with no additional charges for read and write I/O operations", and Aurora Standard, where "you also pay a standard rate per 1 million requests for I/O operations"; AWS calls I/O-Optimized "the best choice when your I/O spending is 25% or more of your total Aurora database spending". Storage is billed on a different basis too:

A · RDS for PostgreSQL, gp3

Billed on

The GiB allocated: $0.133 per GB-month, Single-AZ

Copies

In one zone; Multi-AZ adds a standby and its own storage

When data is removed

The allocated storage stays: it never shrinks

B · Aurora PostgreSQL, Aurora Standard

Billed on

The space used: $0.11 per GB-month, plus $0.22 per million I/O requests

Copies

In three zones, whatever the number of instances

When data is removed

The allocated space decreases by a comparable amount

What differs: storage allocated against storage used, and who pays for the copies. Compare whole bills, not hourly rates.

Per hour, an Aurora PostgreSQL db.r6g.large costs 13.3% more than an RDS for PostgreSQL db.r6g.large in Paris, computed; the whole-bill comparison belongs to an article on Aurora.

RDS or a database on EC2?

What is Amazon RDS? sets the two apart by who does the work (the table in What Amazon RDS is). A price comparison needs the EC2 side's storage, standby, backups and operations, which no price list item covers, so this article states what each RDS price includes rather than one premium for RDS. The EC2 article prices an instance and its volumes.

How RDS pricing works

What an RDS bill is made of

The billing page and the RDS for PostgreSQL pricing page list the lines, and each has its unit:

An I/O requests line also exists, "for Amazon RDS magnetic storage only", which is deprecated. "RDS usage is billed in 1-second increments, with a minimum of 10 minutes", "Billing starts for a DB instance as soon as the DB instance is available", and a billable change, "such as scaling compute or storage capacity", bills its own "10-minute minimum" (On-Demand DB instances). Commitments discount the first line alone: "The price for a reserved DB instance doesn't provide a discount for the costs associated with storage, backups, and I/O. It provides a discount only on the hourly, on-demand instance usage" (Reserved DB instances). Put together, a small production database's month looks like this:

Instance hours, by class and engine

Within a series (T, M, R), a Graviton class without local NVMe storage costs less per hour than an Intel class of the same size, and the price doubles with each size:

A size up doubles the price: a db.r7i.xlarge Multi-AZ DB instance costs $1.176 per hour, twice the db.r7i.large's $0.588. Newer is not cheaper: db.r8g.large costs 6.1% more than db.r6g.large, and db.m8g.large $0.195, as db.m7g.large does. Local storage costs more: db.r6gd.large, a Graviton class with NVMe storage, costs $0.302, above both Intel classes of its size. The engine matters too: a db.r6g.large Single-AZ costs $0.25 per hour for MySQL and MariaDB, so PostgreSQL's $0.264 is 5.6% more, computed. This article prices PostgreSQL; SQL Server and Oracle, with their licence models, are left out.

Storage, IOPS and throughput

Storage is billed on what is allocated, and Provisioned IOPS on what is provisioned, "whether or not you use them in a given month" (DB instance storage):

Three things in this table matter more than its prices. gp2 and gp3 cost the same per GB-month: the EBS fact that gp3 costs less than gp2 (the EC2 article's lever) does not carry over to RDS in Paris. What gp3 changes is performance per GB: a 1,000 GiB PostgreSQL volume has 3,000 IOPS of baseline on gp2 and 12,000 on gp3, for the same $133.00 a month Single-AZ. io1 and io2 Block Express cost the same too, per GB and per IOPS, so moving from one to the other, as AWS recommends, changes no line of the bill. And a provisioned IOPS costs 5.04 times a gp3 IOPS bought above the baseline, computed: the IOPS line, not the GB line, is the price of Provisioned IOPS storage.

A Multi-AZ DB cluster has its own rates: gp3 at $0.399 per GB-month, its IOPS above the baseline at $0.069 per IOPS-month. A terabyte of gp3, 1,024 GiB, costs $136.19 a month Single-AZ and $272.38 Multi-AZ, computed.

Multi-AZ: what doubles, and what triples

On-Demand DB instances for Amazon RDS gives the rule for a Multi-AZ DB instance: "Compute costs: Billed per DB instance-hour for both the primary and standby instances", "Storage costs: Charged per GB-month for the storage provisioned for both the primary and standby instances", while "Replication between the primary and standby instances is included in the cost". In Paris, the Multi-AZ rate of a db.r6g.large is 2.00 times its Single-AZ rate, computed, and gp3 costs $0.266 against $0.133 per GB-month. A Multi-AZ DB cluster has a rate of its own, per class:

For a db.r6gd.large, the cluster costs 2.79 times a Single-AZ DB instance and 6.8% less than three of them, computed, with two readable instances where a Multi-AZ DB instance has one standby that serves nothing; for a db.m6gd.large, exactly 3.00 times. Its storage costs 3.00 times the Single-AZ rate. No AWS page read says in words that the cluster's hourly rate covers its three instances; the reservation rules point that way, since a cluster is fully reserved by "three Single-AZ DB instances that are the same size as the instances in the cluster" (Reserved DB instances). Backups do not double: "Multi-AZ and Single-AZ configurations are treated the same from a backup storage perspective" (RDS for PostgreSQL pricing), and a Multi-AZ DB instance takes them from its standby.

Backup storage and the free allocation

"There is no additional charge for backup storage up to 100% of your total database storage for a region". The allocation belongs to the account and the Region, and is counted every day: "your account's total provisioned database storage in the region is compared against your total backup storage in the region, and only the excess backup storage is charged" (Amazon RDS FAQs). Automated backups and manual snapshots both count, and the free storage goes with the databases: "After the DB instance is terminated backup storage is billed", so a final snapshot kept after deleting the last database of a Region is billed whole. Beyond the allocation, backup storage costs $0.10 per GB-month in Paris:

Copies to another Region count there: "Moving a DB snapshot to another region increases backup storage in the destination region." After the first, a snapshot copy is incremental, "only the data that has changed after the most recent snapshot of the same DB instance" (Copying a DB snapshot).

Extended Support

Extended Support is billed per vCPU and per hour, "dependent on the AWS Region and calendar date": "you will be charged #vCPUs x year 1 and 2 pricing per hour of usage for your chosen Region" (Amazon RDS for MySQL pricing), and "RDS Extended Support charges apply to standby instances in Multi-AZ deployments". In Paris it costs $0.118 per vCPU-hour in years 1 and 2, and $0.235 in year 3. For a db.r6g.large Multi-AZ DB instance, two vCPUs on each of its two instances:

A · Standard support

On a version in standard support Illustrative

Line	A month
Compute
db.r6g.large Multi-AZ, instance hours730 h × $0.528 /h	$385.44
A month, computed	$385.44

B · Extended Support in years 1 and 2

On PostgreSQL 13, years 1 and 2 Illustrative

Line	A month
Compute
db.r6g.large Multi-AZ, instance hours730 h × $0.528 /h	$385.44
Other
Extended Support: 2 vCPUs × 2 instances × 730 h2,920 vCPU-h × $0.118 /vCPU-h	$344.56
A month, computed	$730.00

Extended Support in years 1 and 2 costs $344.56 a month more than standard support (89.4% more), computed.

USD before tax, 730 h a month. AWS Price List, eu-west-3, offer file published October 6, 2026, fetched October 15, 2026. Illustrative configuration, not a client case.

From March 1, 2028, year 3 pricing brings the line to $686.20 a month, 178.0% on top of the instance hours, computed. A Single-AZ db.r6g.large on MySQL 8.0, charged this way since August 1, 2026, adds $172.28 a month. The charges begin "the day after the RDS end of standard support date" and stop when you "Upgrade to an engine version that's covered under standard support" or delete the database. Reserved DB instances do not discount them: "Reserved Instance discounts are not applicable to RDS Extended Support charges" (RDS for PostgreSQL pricing), and the Paris Database Savings Plans offer has no Extended Support rate. Lever 06 is the way out.

What a stopped DB instance still costs

You can stop a DB instance "for a maximum of 7 consecutive days. The most common use case is cost optimization". While it is stopped, "you are charged for provisioned storage (including Provisioned IOPS). You're also charged for backup storage, including manual snapshots and automated backups within your specified retention window", and for its public IPv4 address if it is publicly accessible:

"If you don't manually start your DB instance after it is stopped for seven consecutive days, RDS automatically starts your DB instance for you." Not every database can stop: "You can't stop a DB instance that has a read replica, or that is a read replica", nor RDS for SQL Server in Multi-AZ, nor a Multi-AZ DB cluster. Starting again "can take from minutes to hours", and each start bills at least 10 minutes. A public IPv4 address costs $3.65 a month in Paris, running or stopped. The logic is EC2's, with other rules: see What a stopped instance still costs in the EC2 article.

Data transfer

The pricing page bills database traffic by where it goes:

On traffic across zones, the page adds: "There is no additional charge for data transferred in and out of the Amazon RDS database instance." So 1 TB a month between application instances and the database in different zones costs $10.24 on the EC2 side, computed. After a Multi-AZ failover the primary sits in the other zone; AWS's answer is redundancy, not co-location: "you may want to consider architecting your application and other AWS resources with redundancy across multiple Availability Zones" (Amazon RDS FAQs). The first 100 GB a month out to the internet are free, counted across AWS services and Regions.

Other billed features

"RDS Proxy is priced per vCPU per hour", with a minimum of 2 vCPUs for provisioned instances: a proxy in front of a Single-AZ db.r6g.large costs $32.12 a month, computed; whether a Multi-AZ standby's vCPUs count, the pricing page does not say. A snapshot export is billed on the size of the whole snapshot, even when you export one table, and it is not a backup you can restore; S3's own prices are in the S3 article. A Blue/Green deployment bills its green environment at the usual prices: "Effectively, you are paying approximately 2x the cost of running workloads on db.instance for the lifespan of the blue-green-deployment" (Amazon RDS FAQs). Enhanced Monitoring and CloudWatch Database Insights are billed as Amazon CloudWatch, and are not priced here.

Reserved DB instances and Database Savings Plans

Reserved DB instances "are not physical instances, but rather a billing discount applied to the use of certain on-demand DB instances in your account", for one or three years, paid No Upfront, Partial Upfront or All Upfront, and "You can't cancel a reserved DB instance." For RDS for Db2, MariaDB, MySQL, PostgreSQL and Oracle with your own licence, a reservation is size-flexible within its class type, "a reserved DB instance for a db.r6i.large can apply to a db.r6i.xlarge, but not to a db.r6id.large or db.r7g.large", and "Reserved DB instance benefits apply to both Multi-AZ and Single-AZ configurations." Database Savings Plans are a one-year commitment of an amount per hour that applies "regardless of engine, instance family, size, deployment option, or AWS Region". Compute Savings Plans, the EC2 article's wider plan, do not cover RDS: they "apply to your EC2 instance usage" and "also apply to your Fargate and Lambda usage" (Savings Plans types).

A · Reserved DB instances

Discount

Up to 69% off On-Demand, AWS says

Term and payment

1 or 3 years; No Upfront, Partial or All Upfront

Applies to

One class type, engine and Region, any size, Single-AZ or Multi-AZ

B · Database Savings Plans

Discount

Up to 35% off On-Demand, AWS says

Term and payment

1 year, No Upfront

Applies to

Any engine, family, size, deployment or Region, on the newest classes, serverless included

What differs: a deeper discount tied to one class type, against a plan that follows the database across engines, families and Regions.

The Paris offer has one plan, "1 year No Upfront", and its RDS rates cover only db.m7g, db.m7i, db.m8g, db.m8i, db.r7g, db.r7i, db.r8g, db.r8i and db.x2m: not db.t4g, db.r6g or db.m6g, nor the Multi-AZ DB cluster usage types. Where it applies, it costs 20.0% less than On-Demand on every RDS for PostgreSQL rate checked, computed. On db.r8g.large, the commitments line up like this:

The user guide says No Upfront "is only available as a one-year reservation"; the Paris price list nonetheless has three-year No Upfront rates for the 8th-generation classes, shown here as the price list gives them. For the classes the plan skips, paying earlier goes further, as AWS's "up to 69%" suggests. A db.r6g.large Single-AZ costs $192.72 a month On-Demand; reserved, with each of the five terms and payments the Paris offer has for it:

A month spreads the upfront fee over the term's months, at the RDS pricing page's 365-day years, and adds the hourly rate for 730 hours. The two commitments do not stack on one database: "For the same workload, you cannot combine Database Savings Plans with Amazon RDS Reserved Instances or Amazon DynamoDB reserved capacity discounts", and "Any usage beyond your commitment is billed at on-demand rates."

In short: In Paris, a one-year No Upfront reserved DB instance costs less than the Database Savings Plan on every class both cover: buy the plan for its flexibility, and only for the newest classes it covers.

Reading the RDS lines of a bill

The usage types carry the Region's code, EUW3- in Paris, and the class (db.r6g.2xl for a 2xlarge). Among them, from the Paris price list:

Cost Explorer groups them (usage type groups) as "RDS: Running Hours", "RDS: Storage", "RDS: Provisioned IOPS" and "RDS: I/O Requests", with data transfer groups of their own, such as "RDS: Data Transfer – InterAZ" and "RDS: Data Transfer – Region to Region – Out". The usage types listed under "RDS: Running Hours" do not include Multi-AZClusterUsage: filter Multi-AZ DB clusters by usage type. Reservations appear under "Amazon Relational Database Service for Database Engine Reserved Instances" in the bill's details (billing for reserved DB instances).

Architecture patterns around RDS and what they cost

Four illustrative configurations in Paris, each priced before and after the levers of the next section, line by line from the AWS Price List: a production database that buys its storage performance twice and commits to nothing, copies of a database for availability and reads, databases that run when nobody uses them, and a copy in another Region. None is a client case; every amount is computed, and each card lists its assumptions and what it leaves out. The EC2 patterns price the compute side the same way.

Pattern 1 of 4 · Illustrative configuration

Always-on production database

A production PostgreSQL database in Paris, a Multi-AZ DB instance with 500 GiB of storage that peaks at 6,000 IOPS: on an Intel class with Provisioned IOPS storage, On-Demand, then on Graviton4 with gp3 storage and a one-year reservation.

Scroll the diagram sideways →

io2 Block Express, AWS's recommended Provisioned IOPS storage, would bill exactly what io1 bills, $2,389.48 a month: in Paris the two have the same rates. Most of the saving comes from the storage, and it holds only if gp3's latency suits the application; AWS's general advice for production OLTP is Provisioned IOPS (the storage section).

Before · Intel class, Provisioned IOPS storage, on demand$2,389.48

With the levers · Graviton4, gp3 storage, one-year reservation$681.74

• Compute$858.48 → $548.74, too small to draw
• Storage$1,531.00 → $133.00, too small to draw

Before · Intel class, Provisioned IOPS storage, on demand: compute $858.48, storage $1,531.00, total $2,389.48 a month.

With the levers · Graviton4, gp3 storage, one-year reservation: compute $548.74, storage $133.00, total $681.74 a month.

With the levers: $1,707.74 a month less (71.5% less), computed.

Always-on production database, one lever at a time: the bill a month, computed

• Before and along the way
• With every lever

Step		A month, computed	Change
Intel class, io1, On-DemandBefore the levers		$2,389.48	—
gp3 storageLever: Size storage performance to the need		$991.48	−$1,398.00
Graviton4 (db.r8g.xlarge)Lever: Move to Graviton classes		$952.06	−$39.42
One-year reserved DB instanceLever: Commit to the steady baseline		$681.74	−$270.32

USD, before tax. AWS Price List, eu-west-3, offer files published October 6, 2026 and October 13, 2026, fetched October 15, 2026.

Levers

• Size storage performance to the need
• Move to Graviton classes
• Commit to the steady baseline

The bills line by line, the assumptions and the sources

Always-on production database, before: Intel class, Provisioned IOPS storage, on demand Illustrative

A db.r7i.xlarge Multi-AZ DB instance On-Demand, with 500 GiB of io1 storage and 6,000 provisioned IOPS.

Line	A month
Compute
db.r7i.xlarge Multi-AZ DB instance, On-Demand1 Multi-AZ DB instance × 730 h × $1.176 /h	$858.48
Storage	$1,531.00
io1 storage, Multi-AZ500 GiB × $0.29 /GB-mo	$145.00
Provisioned IOPS (io1), Multi-AZ6,000 IOPS × $0.231 /IOPS-mo	$1,386.00
A month, computed	$2,389.48

Always-on production database, with the levers: Graviton4, gp3 storage, one-year reservation Illustrative

A db.r8g.xlarge Multi-AZ DB instance on a one-year No Upfront reserved DB instance, with 500 GiB of gp3 storage and its baseline of 12,000 IOPS.

Line	A month
Compute
db.r8g.xlarge Multi-AZ DB instance, reserved for 1 year, No Upfront1 Multi-AZ DB instance × 730 h × $0.7517 /h	$548.74
Storage
gp3 storage, Multi-AZ, 12,000 IOPS and 500 MiB/s of baseline included500 GiB × $0.266 /GB-mo	$133.00
A month, computed	$681.74

Database Savings Plan instead of the reservation: $788.25 a month, 67.0% less than before, computed.

Assumptions

• Illustrative configuration in Paris (eu-west-3), not a client case.
• A Multi-AZ DB instance (a primary and a standby in two Availability Zones) with 500 GiB of storage, running all month. Measured with the ReadIOPS and WriteIOPS metrics, its peak is 6,000 IOPS and its throughput stays under 500 MiB/s.
• gp3's latency profile is acceptable to the application, which is a condition to verify: AWS recommends Provisioned IOPS storage for production OLTP, and gives gp3 single-digit milliseconds 99% of the time against io2's sub-millisecond 99.9% of the time.
• From 400 GiB, RDS for PostgreSQL stripes gp3 over four volumes, with a baseline of 12,000 IOPS and 500 MiB/s included: no IOPS or throughput is bought above it.
• 4 vCPUs and 32 GiB of memory hold the working set; the Graviton4 class of the same size, db.r8g.xlarge, carries the same load (to verify with a load test), on PostgreSQL 13.11, 14.9, 15.4, 16.1, 17.1 or higher, the versions the class supports.
• The reservation covers a database that runs all year on the r8g class type: a reserved DB instance bills every hour of its term, used or not, and cannot be cancelled.
• Backups stay within the free allocation (100% of the Region's provisioned database storage).

Not counted

• Backup storage beyond the free allocation, data transfer and monitoring.
• The storage change itself: it consumes I/O while it runs, once.

Sources

• Amazon RDS DB instance storage
• Multi-AZ DB instance deployments for Amazon RDS
• On-Demand DB instances for Amazon RDS
• DB instance class types
• Supported DB engines for DB instance classes
• Reserved DB instances for Amazon RDS
• Database Savings Plans pricing

USD before tax, 730 h a month. AWS Price List, eu-west-3, offer files published October 6, 2026 and October 13, 2026, fetched October 15, 2026. Illustrative configuration, not a client case.

Pattern 2 of 4 · Illustrative configuration

Read scaling: two read replicas or two readable standbys

A production PostgreSQL database in Paris with 500 GiB of gp3 needs automatic failover and the read capacity of two more instances of its size: a Multi-AZ DB instance with two read replicas, or a Multi-AZ DB cluster whose two standbys serve reads.

Scroll the diagram sideways →

The cluster that replaces them is drawn under Multi-AZ: one standby, or a cluster with two readable standbys. With both on one-year reservations, the cluster still costs $67.15 a month less (8.6% less), computed: $709.55 against $776.70. It also fails over faster, typically under 35 seconds against 60 to 120, and its standbys are the readers.

Before · Multi-AZ DB instance and two read replicas$1,036.88

With the levers · Multi-AZ DB cluster with two readable standbys$815.62

• Compute$770.88 → $616.12, too small to draw
• Storage$266.00 → $199.50, too small to draw

Before · Multi-AZ DB instance and two read replicas: compute $770.88, storage $266.00, total $1,036.88 a month.

With the levers · Multi-AZ DB cluster with two readable standbys: compute $616.12, storage $199.50, total $815.62 a month.

With the levers: $221.26 a month less (21.3% less), computed.

Levers

• Read from the standbys of a Multi-AZ DB cluster

The bills line by line, the assumptions and the sources

Read scaling: two read replicas or two readable standbys, before: Multi-AZ DB instance and two read replicas Illustrative

A db.r6g.large Multi-AZ DB instance and two db.r6g.large Single-AZ read replicas, On-Demand, each with 500 GiB of gp3.

Line	A month
Compute	$770.88
db.r6g.large Multi-AZ DB instance (primary and standby), On-Demand1 Multi-AZ DB instance × 730 h × $0.528 /h	$385.44
db.r6g.large read replicas, Single-AZ, On-Demand2 read replicas × 730 h × $0.264 /h	$385.44
Storage	$266.00
gp3 storage of the Multi-AZ DB instance500 GiB × $0.266 /GB-mo	$133.00
gp3 storage of the read replicas, 500 GiB each1,000 GiB × $0.133 /GB-mo	$133.00
A month, computed	$1,036.88

Read scaling: two read replicas or two readable standbys, with the levers: Multi-AZ DB cluster with two readable standbys Illustrative

A db.r6gd.large Multi-AZ DB cluster, a writer and two readers in three Availability Zones, On-Demand, with 500 GiB of gp3.

Line	A month
Compute
db.r6gd.large Multi-AZ DB cluster (a writer and two readers), On-Demand1 Multi-AZ DB cluster × 730 h × $0.844 /h	$616.12
Storage
gp3 storage, Multi-AZ DB cluster500 GiB × $0.399 /GB-mo	$199.50
A month, computed	$815.62

The Multi-AZ DB instance and its replicas on one-year reservations: $776.70 a month, 25.1% less than before, computed.

The Multi-AZ DB cluster covered by three one-year reserved db.r6gd.large: $709.55 a month, 31.6% less than before, computed.

Assumptions

• Illustrative configuration in Paris (eu-west-3), not a client case.
• 500 GiB of gp3 storage on every copy of the database, all running all month: from 400 GiB, each copy's gp3 storage is striped, with a baseline of 12,000 IOPS.
• The two readers of a db.r6gd.large cluster serve the reads two db.r6g.large read replicas would: the same 2 vCPUs and 16 GiB of memory each. A cluster's readers also apply the writer's changes, so their read capacity depends on the write load: to verify.
• The application tolerates replica lag in both variants, and needs none of the features a Multi-AZ DB cluster lacks (stopping and starting, storage autoscaling, cross-Region automated backups, copying its snapshots).
• Replication within the Region is not billed as data transfer in either variant.
• With reservations: one db.r6g.large Multi-AZ and two Single-AZ reserved DB instances before; three db.r6gd.large Single-AZ reserved DB instances for the cluster after, the way the RDS user guide reserves a cluster. The price list has no reservation of the cluster usage type itself.

Not counted

• Backup storage (within the free allocation in both variants) and data transfer between the application and the database.

Sources

• Multi-AZ DB cluster deployments for Amazon RDS
• Failing over a Multi-AZ DB cluster for Amazon RDS
• Limitations of Multi-AZ DB clusters for Amazon RDS
• Working with DB instance read replicas
• Amazon RDS Multi-AZ
• Reserved DB instances for Amazon RDS

USD before tax, 730 h a month. AWS Price List, eu-west-3, offer file published October 6, 2026, fetched October 15, 2026. Illustrative configuration, not a client case.

Pattern 3 of 4 · Illustrative configuration

Development, test and staging databases

Three non-production PostgreSQL databases in Paris (development, test, staging), copies of production's configuration, used by a team that works eight hours a day, five days a week.

Instance Scheduler on AWS runs on an Amazon EventBridge rule, AWS Lambda functions and Amazon DynamoDB tables (its schedules and a registry of the tagged resources), which start and stop the DB instances by tag.

Scroll the diagram sideways →

Before · Copies of production: Multi-AZ, always on$1,315.92

With the levers · Single-AZ, stopped outside working hours$217.08

• Compute$1,156.32 → $137.28, too small to draw
• Storage$159.60 → $79.80, too small to draw

Before · Copies of production: Multi-AZ, always on: compute $1,156.32, storage $159.60, total $1,315.92 a month.

With the levers · Single-AZ, stopped outside working hours: compute $137.28, storage $79.80, total $217.08 a month.

With the levers: $1,098.84 a month less (83.5% less), computed.

Development, test and staging databases, one lever at a time: the bill a month, computed

• Before and along the way
• With every lever

Step		A month, computed	Change
Multi-AZ, always onBefore the levers		$1,315.92	—
Stopped outside working hoursLever: Stop or schedule what nobody uses		$434.16	−$881.76
Single-AZLever: Run Single-AZ where the availability need allows it		$217.08	−$217.08

USD, before tax. AWS Price List, eu-west-3, offer file published October 6, 2026, fetched October 15, 2026.

Levers

• Stop or schedule what nobody uses
• Run Single-AZ where the availability need allows it

The bills line by line, the assumptions and the sources

Development, test and staging databases, before: Copies of production: Multi-AZ, always on Illustrative

Three db.r6g.large Multi-AZ DB instances On-Demand, running all month, 200 GiB of gp3 each.

Line	A month
Compute
db.r6g.large Multi-AZ DB instances, On-Demand, all month3 Multi-AZ DB instances × 730 h × $0.528 /h	$1,156.32
Storage
gp3 storage, Multi-AZ, 200 GiB each600 GiB × $0.266 /GB-mo	$159.60
A month, computed	$1,315.92

Development, test and staging databases, with the levers: Single-AZ, stopped outside working hours Illustrative

Three db.r6g.large Single-AZ DB instances On-Demand, started and stopped on a working-hours schedule, 200 GiB of gp3 each.

Line	A month
Compute
db.r6g.large Single-AZ DB instances, On-Demand, working hours3 DB instances × 173⅓ h × $0.264 /h	$137.28
Storage
gp3 storage, Single-AZ, 200 GiB each, billed while stopped too600 GiB × $0.133 /GB-mo	$79.80
A month, computed	$217.08

Assumptions

• Illustrative configuration in Paris (eu-west-3), not a client case.
• 3 databases, each a db.r6g.large with 200 GiB of gp3, as production is configured.
• Working hours: 8 hours a day, 5 days a week, 52 weeks a year: 8 × 5 × 52 / 12 = 173⅓ hours a month. Instance Scheduler on AWS starts and stops the instances by tag.
• A weekend stop lasts less than the seven days after which RDS starts a stopped DB instance again; none of the instances has a read replica, which would prevent the stop.
• A non-production database that loses its zone can wait for a point-in-time restore: its owner accepts Single-AZ (a choice, not an AWS rule).
• Storage is billed all month, running or stopped; backups stay within the free allocation.
• No reservation covers these instances: a reserved DB instance bills every hour of its term, and a stopped instance does not use it.

Not counted

• The scheduler's own resources (an Amazon EventBridge rule, AWS Lambda functions, Amazon DynamoDB tables).
• The 10-minute minimum billed at each start, a few minutes a day at most; data transfer.

Sources

• Stopping an Amazon RDS DB instance temporarily
• Cost Optimization Pillar: Design principles
• Instance Scheduler on AWS
• Amazon RDS Multi-AZ
• DB instance billing for Amazon RDS

USD before tax, 730 h a month. AWS Price List, eu-west-3, offer file published October 6, 2026, fetched October 15, 2026. Illustrative configuration, not a client case.

Pattern 4 of 4 · Illustrative configuration

A disaster-recovery copy in Frankfurt

A production PostgreSQL database in Paris needs a copy in another Region: a cross-Region read replica that runs all month in Frankfurt, or cross-Region automated backups, restored into a new DB instance only when needed.

Scroll the diagram sideways →

The copy alone costs $280.52 a month as a replica and $56.11 as replicated backups, 80.0% less, computed; the first full copy of the data, $6.00 of transfer, is paid once either way. The two do not recover the same way: a replica can be promoted, while backups must first be restored into a new DB instance, which then loads its data in the background. AWS describes a restore-based recovery of a Single-AZ database as one that "can take several hours to complete" (Amazon RDS Multi-AZ).

Before · Cross-Region read replica$798.96

With the levers · Cross-Region automated backups$574.55

• Compute$585.46 → $385.44, too small to draw
• Storage$201.50 → $171.11, too small to draw
• Network$12.00 → $18.00, too small to draw

Before · Cross-Region read replica: compute $585.46, storage $201.50, network $12.00, total $798.96 a month.

With the levers · Cross-Region automated backups: compute $385.44, storage $171.11, network $18.00, total $574.55 a month.

With the levers: $224.41 a month less (28.1% less), computed.

Levers

• Keep cross-zone and cross-Region traffic in view
• Keep backups to what recovery needs

The bills line by line, the assumptions and the sources

A disaster-recovery copy in Frankfurt, before: Cross-Region read replica Illustrative

A db.r6g.large Single-AZ read replica in Frankfurt with 500 GiB of gp3, running all month, kept up to date from Paris.

Line	A month
Compute	$585.46
Source in Paris: db.r6g.large Multi-AZ DB instance, On-Demand1 Multi-AZ DB instance × 730 h × $0.528 /h	$385.44
Read replica in Frankfurt: db.r6g.large Single-AZ, On-Demand1 read replica × 730 h × $0.274 /h	$200.02
Storage	$201.50
Source in Paris: gp3 storage, Multi-AZ500 GiB × $0.266 /GB-mo	$133.00
Read replica in Frankfurt: gp3 storage500 GiB × $0.137 /GB-mo	$68.50
Network
Replication from Paris to Frankfurt600 GB × $0.02 /GB	$12.00
A month, computed	$798.96

A disaster-recovery copy in Frankfurt, with the levers: Cross-Region automated backups Illustrative

The snapshots and transaction logs of the Paris database replicated to Frankfurt and kept 7 days; a recovery restores a new DB instance there.

Line	A month
Compute
Source in Paris: db.r6g.large Multi-AZ DB instance, On-Demand1 Multi-AZ DB instance × 730 h × $0.528 /h	$385.44
Storage	$171.11
Source in Paris: gp3 storage, Multi-AZ500 GiB × $0.266 /GB-mo	$133.00
Replicated backups stored in Frankfurt370 GB × $0.103 /GB-mo	$38.11
Network
Transaction logs and snapshot increments copied to Frankfurt900 GB × $0.02 /GB	$18.00
A month, computed	$574.55

Assumptions

• Illustrative configuration in Paris (eu-west-3) with its copy in Frankfurt (eu-central-1), not a client case.
• The source is a db.r6g.large Multi-AZ DB instance with 500 GiB of gp3 holding 300 GB of data; it writes 600 GB of transaction logs a month, and 10 GB of data changes each day. Both figures are illustrative.
• The replica's replication stream is assumed to be the size of the transaction logs, 600 GB a month: no AWS page gives the ratio.
• The replicated backups are kept 7 days in Frankfurt: one full copy of the 300 GB plus 7 daily increments of 10 GB, 370 GB stored. Each month, the 600 GB of transaction logs and 30 daily increments, 900 GB, cross to Frankfurt.
• No other RDS storage in Frankfurt gives the replicated backups a free allocation there; storing the transaction logs in the destination is not charged.
• The two variants do not recover the same way: the replica runs and can be promoted, while the replicated backups must first be restored into a new DB instance, which then loads its data in the background. The pattern prices two recovery objectives, not two equal copies.

Not counted

• The source's own backups in Paris (within the free allocation, the same in both variants) and monitoring.

Sources

• Creating a read replica in a different AWS Region
• Replicating automated backups to another AWS Region
• Copying a DB snapshot for Amazon RDS
• Restoring a DB instance to a specified time for Amazon RDS
• Amazon RDS pricing
• Amazon RDS for PostgreSQL pricing

USD before tax, 730 h a month. AWS Price List, eu-west-3 and eu-central-1, offer files published September 16, 2026 and October 6, 2026, fetched October 15, 2026. Illustrative configuration, not a client case.

How to reduce RDS costs

Each lever below comes from AWS documentation; their order is this article's. With a reserved DB instance, "You will continue to pay for every hour during your Reserved DB instance term regardless of your usage" (Amazon RDS FAQs), and it cannot be cancelled. So a commitment comes last, once the usage it covers is as small as it will get: see the bill first, remove what is billed but serves nothing, reshape the database hours, and commit to what remains, so that the commitment doesn't lock in waste. The levers, in that order:

1. Lever 01,SeeSee the RDS bill line by lineAlways, and first
2. Lever 02,TrimDelete idle databases, keep a final snapshotDatabases nobody connects to
3. Lever 03,TrimKeep backups to what recovery needsBackup storage beyond the free allocation
4. Lever 04,TrimSize storage performance to the needProvisioned IOPS, or gp2 bought for its IOPS
5. Lever 05,TrimAllocate storage for today, let autoscaling grow itNew databases and migrations
6. Lever 06,TrimUpgrade before Extended SupportMajor versions past standard support
7. Lever 07,ReshapeStop or schedule what nobody usesDevelopment, test, staging, idle hours
8. Lever 08,ReshapeRun Single-AZ where the availability need allows itDatabases that can wait for a restore
9. Lever 09,ReshapeRightsize with dataEvery DB instance, before a commitment
10. Lever 10,ReshapeMove to Graviton classesMySQL, PostgreSQL, MariaDB on Intel classes
11. Lever 11,ReshapeRead from the standbys of a Multi-AZ DB clusterFailover and read capacity, in one Region
12. Lever 12,RouteKeep cross-zone and cross-Region traffic in viewApplications over several zones, copies abroad
13. Lever 13,CommitCommit to the steady baselineDatabases that run every hour, once the rest is done
14. Lever 14,ReviewReview on a cadenceEvery database

In short: Commit last: see the bill line by line, delete and upgrade what costs for nothing, size storage performance and instance hours to the need, and only then reserve what runs every hour.

FAQ

How is Amazon RDS billed?

By the DB instance hour, billed per second with a 10-minute minimum, plus allocated storage, provisioned IOPS, backup storage beyond the free allocation, Extended Support for old versions and data transfer; a Multi-AZ DB instance bills both its instances and both sets of storage (What an RDS bill is made of).

Does a stopped RDS instance cost money?

Its instance hours stop, but its storage, provisioned IOPS, backups and, if it is publicly accessible, its public IPv4 address are still billed, and RDS starts it again after seven days (What a stopped DB instance still costs).

Does Multi-AZ double the cost?

It doubles the instance and storage lines: in Paris, a Multi-AZ db.r6g.large costs 2.00 times the Single-AZ rate, computed. Backup storage and the replication traffic do not double (Multi-AZ: what doubles, and what triples).

Is RDS backup storage free?

Up to 100% of the Region's total provisioned database storage, counted for the account every day; beyond it, and after the databases are deleted, it costs $0.10 per GB-month in Paris (Backup storage and the free allocation).

Reserved Instances or Database Savings Plans for RDS?

In Paris, a one-year No Upfront reserved DB instance costs less than the Database Savings Plan on every class both cover, and the plan does not cover db.t4g, db.r6g or Multi-AZ DB clusters; the plan's case is flexibility across engines, families and Regions (Reserved DB instances and Database Savings Plans).