RDS Multi-AZ vs Single-AZ cost is the price of the standby Amazon RDS keeps beside the primary. Single-AZ runs the database in one Availability Zone. Multi-AZ with one standby provisions a second copy in another Availability Zone and fails over to it. A second Multi-AZ shape, the DB cluster, runs a writer and two readable standbys. Finance sees one RDS line. The person who clicked Multi-AZ often cannot say which of those shapes is on the instance, or which meter moved.
Rutagon treats the line as a deployment choice with a published price. The waste pattern is Multi-AZ on every database because production has it, including the ones that can be rebuilt from a snapshot. RDS cost optimization is the wider pass over instance size, storage, and snapshots. This article is the Single-AZ versus Multi-AZ meter.
Where RDS Multi-AZ vs Single-AZ cost is priced
The RDS for PostgreSQL pricing page separates the shapes. A Multi-AZ deployment with one standby provisions and maintains a standby in a different Availability Zone, and RDS fails over on a scheduled or unplanned outage. A Multi-AZ deployment with two readable standbys provisions identical DB instances in three Availability Zones. On an outage of the primary, RDS fails over to a standby, and those two standbys also serve read-only work. The page prices Single-AZ, one standby, and two readable standbys as separate on-demand choices.
On-demand instances bill per DB instance-hour from launch until the instance is stopped or deleted. After a billable change, such as creating, starting, or modifying the instance class, partial hours bill in one-second increments with a 10-minute minimum. Toggling Multi-AZ on for a failover drill and toggling it off again still clears that minimum. New customers get a free tier that includes 750 hours on a selection of Single-AZ instance databases, 20 GB of gp2 storage, and 20 GB of backup storage each month for one year. The free-tier sentence names Single-AZ hours.
Reserved Instances are a discount on the instance-hour, for a one-year or three-year term, with no upfront, partial upfront, or all upfront. PostgreSQL RIs have size flexibility inside an instance family. The RI price does not cover storage or I/O. You are billed for every hour of the term you bought, whether the instance is running. A Multi-AZ reservation on a database you stop at night still has that term charge, and the storage beside it is outside the reservation.
T4g and T3 instances run in Unlimited mode. If average CPU over a rolling 24-hour window exceeds the baseline, CPU credits are $0.075 per vCPU-hour. That credit price is the same for every T4g and T3 size, in every Region, and Reserved Instances do not cover it. A burstable Multi-AZ box that lives above baseline adds this meter on top of the deployment price.
The Multi-AZ DB instance documentation states the constraint that changes the architecture, not only the bill. Amazon RDS keeps a synchronous standby in another Availability Zone. The standby is there for redundancy and for failover. You cannot use that standby to serve read traffic. Read traffic needs a Multi-AZ DB cluster or a read replica. Synchronous replication can also raise write and commit latency compared with a Single-AZ deployment. The Multi-AZ DB cluster documentation describes a different product: one writer and two reader instances in three Availability Zones, using semisynchronous replication that commits after at least one reader acknowledges. The readers serve reads and are the failover targets. The same page says a Multi-AZ DB cluster is not an Aurora DB cluster.
The storage example that has a dollar figure
Instance-hour tables on the pricing page are Region rows. We read the row for the Region and the deployment option, and we do not paste a Single-AZ hourly rate onto a Multi-AZ instance. The page does publish a worked storage example that shows the one-standby multiplier in US East (N. Virginia).
A Dedicated Log Volume is an extra Provisioned IOPS volume for the transaction log, priced like a data volume of 1,000 GiB and 3,000 IOPS. The page's io1 example, attached to a Single-AZ RDS for PostgreSQL instance in that Region, is $0.125 times 1,024 GiB plus $0.10 times 3,000 IOPS, or $428 a month. The same volume on Multi-AZ with one standby is $0.25 times 1,024 GiB plus $0.20 times 3,000 IOPS, or $856 a month. The storage rate and the IOPS rate in that example both double, and the monthly total doubles with them. Dedicated Log Volumes are supported only on Provisioned IOPS storage. Another Region, or gp3, has its own row. Copy the unit from the row you pay, then multiply by what you allocated.
deployment: single-az | multi-az-one-standby | multi-az-two-readable-standbys
standby_reads: no on one standby; yes on the two-reader cluster
partial_hour: one-second billing, 10-minute minimum
io1_log_volume_n_virginia: $428 a month single-az, $856 a month one standby
ri_covers: instance-hours of the term, not storage and not I/OThose dollars are the published N. Virginia io1 example, not a quote for every account. The shape is the point. One standby is a second copy of the storage price in that example, and it still cannot take your read queries.
Magnetic storage on the same pricing page has a related sentence. For Multi-AZ deployments, write I/O usage doubles when you update the database, because RDS synchronously replicates the data to the standby. Read I/O usage stays the same when you read. That sentence sits in the magnetic storage section. gp3 and io1 bill storage differently, so we do not paste the magnetic I/O sentence onto a gp3 volume. We do use it as a reminder that the standby is a live replica of writes.
What the cluster adds, and what we leave on Single-AZ
A Multi-AZ DB cluster runs three DB instances. On-demand billing is per DB instance-hour for the deployment you launched. Three instances mean three hours of that deployment for each hour the cluster is up. The readers can take read traffic, which the single standby cannot. The cluster also has a shorter list of instance classes, including db.m6gd, db.r6gd, and db.x2iedn, and the documentation lists the rest. A small T instance class is the wrong assumption for that tab. Replica lag is a CloudWatch metric on the cluster, and failover waits for the reader that will be promoted to apply it. You pay for the read capacity, and you still watch lag.
We split databases by the failure they are allowed to have. The system of record that must fail over inside the Region stays on Multi-AZ with one standby, or on the cluster when the readers earn their instance-hours. A reporting job, a queue scratch database, and a staging copy go to Single-AZ when a snapshot restore is an acceptable recovery. Disaster recovery architecture is the place we write that recovery time down, so Multi-AZ is not doing the job of a cross-Region plan and a cross-Region plan is not doing the job of a standby.
Converting Single-AZ to Multi-AZ is a modify. It is also a billable status change, so the 10-minute minimum applies, and the storage rate moves to the Multi-AZ row from then on. We make the change in the template that owns the instance. A console toggle on Friday becomes Single-AZ again on the next apply, or it stays Multi-AZ forever because nobody put it in code. Either outcome is an accident.
We leave Multi-AZ on when the standby is the availability control you meant to buy. Keep it on the database that takes orders. Use the $856 example to drop a Dedicated Log Volume from quiet staging, and to question a three-instance cluster bought so that a standby can also serve reads a single read replica would answer.
Rutagon runs this as a short bill review: deployment option per database, whether the standby is allowed to serve reads, the Region's storage row, any Dedicated Log Volume, RI coverage against instance-hours only, and T instance credit spend. We do not invent a blended hourly rate. The pricing page is the source for the $428 and $856 example, and the Multi-AZ documentation is the source for the unread standby.
Frequently Asked Questions
Does the Multi-AZ standby reduce RDS Multi-AZ vs Single-AZ cost by taking reads?
The one-standby deployment does not serve read traffic from the standby. Amazon RDS documents that limit and points read traffic at a Multi-AZ DB cluster or a read replica. Paying for one standby and then adding a read replica is two extra copies. Pick the shape that matches the read.
Why did storage jump when we enabled one standby?
In the published US East (N. Virginia) io1 Dedicated Log Volume example, Single-AZ is $0.125 per GiB and $0.10 per IOPS, totaling $428 a month. Multi-AZ with one standby is $0.25 per GiB and $0.20 per IOPS, totaling $856 a month. Your volume type and Region have their own row. The example is the pattern: the standby has a storage price.
Is a Multi-AZ DB cluster the same bill as one standby?
A cluster is a writer plus two reader instances in three Availability Zones, and the readers can serve queries. On-demand pricing is per DB instance-hour for that deployment. One standby is a different option on the pricing page, and its standby does not serve reads. The cluster documentation also says this is not Aurora.
Do Reserved Instances cover the doubled storage?
Reserved Instance prices do not cover storage or I/O. The reservation discounts instance-hours for the term you bought, and you pay those hours whether the instance is running. The log-volume example, backup storage, and magnetic or provisioned I/O stay on the bill beside the reservation. T4g and T3 CPU credits at $0.075 per vCPU-hour are also outside the reservation.
Does the Single-AZ free tier apply after we turn on Multi-AZ?
The PostgreSQL pricing page describes the free tier as 750 hours on a selection of Single-AZ instance databases, plus 20 GB of gp2 and 20 GB of backup storage, for new customers, for one year. The sentence names Single-AZ. A Multi-AZ modify is a new deployment price from the time it is applied, with partial hours billed to a 10-minute minimum.
Ask for an AWS bill review that separates Single-AZ, one standby, and the two-reader cluster. Contact Rutagon at rutagon.com/contact, 907-841-8407, or contact@rutagon.com.