AWS
Microsoft Azure
Google Cloud
The standby is not a read replica and does not increase read capacity. That means the Multi-AZ premium is not simply a pricing surcharge.
You are paying for additional infrastructure and a different failure-handling model. The right question is therefore not “Is Multi-AZ expensive?” but “What does the additional availability protect, and is that protection worth its incremental cost?”
The short answer
If an RDS for MySQL workload can tolerate the downtime and recovery process of a Single-AZ deployment, Multi-AZ may not justify its additional compute cost. If an outage would materially affect revenue, customers, operations, or recovery objectives, the extra cost can be justified.For a standard Multi-AZ DB instance, AWS maintains one standby in another Availability Zone. The standby does not serve reads. AWS says failover typically takes 60–120 seconds, although database activity, large transactions, and recovery conditions can make it longer. See AWS’s Multi-AZ failover guidance for the conditions that can affect recovery.
Do not use “non-development” as a shortcut for choosing Multi-AZ or Single-AZ. Evaluate RTO, RPO, business impact, application reconnection behavior, and tested recovery procedures first.
What does RDS MySQL Multi-AZ actually cost?
The cleanest way to model the cost is to separate compute from storage, I/O, backups, data transfer, and other charges.For a standard Multi-AZ DB instance deployment, AWS charges for the DB instances used by the deployment. The AWS RDS for MySQL pricing presents separate rates for Single-AZ and Multi-AZ deployment options.
The exact amount depends on Region, instance class, engine version, deployment option, and pricing model.
For a real pricing snapshot, record the AWS Region, MySQL version, instance class, deployment type, payment option, term, storage type, and retrieval date.
That evidence makes the calculation reproducible and prevents an old price from being mistaken for a current AWS rate.
The Multi-AZ premium pays for availability, not read scaling
The additional compute cost represents the standby infrastructure that RDS maintains in another Availability Zone.AWS describes the standby as a synchronous replica used for automatic failover. It is not a read replica and is not intended to increase read throughput. See the AWS Multi-AZ DB instance documentation.
Because replication is synchronous, validate the potential write and commit latency effect against your workload before treating Multi-AZ as a cost-only availability decision.
AWS explicitly notes that Multi-AZ DB instance deployments can have increased write and commit latency compared with Single-AZ.
How should you choose between Single-AZ and Multi-AZ?
Start with business requirements, not the discount.Ask:
- What is the maximum acceptable outage?
- What is the required RTO?
- What is the required RPO?
- What happens financially or operationally if the database is unavailable for several minutes?
- Can the application reconnect automatically after failover?
- Have you tested failover with the real application?
- Is the workload sensitive to additional write or commit latency?
- Does the workload need read scaling rather than only high availability?
But production status alone is not enough.
RDS deployment options: which architecture fits?
| Option | Primary goal | Read capacity | Main trade-off |
|---|---|---|---|
| Single-AZ | Lowest infrastructure complexity and cost | Primary only | No Multi-AZ automatic failover protection |
| Multi-AZ DB instance | High availability and automatic failover | Standby does not serve reads | Additional standby compute and possible write/commit latency |
| Multi-AZ DB cluster | High availability plus read capacity | Two readable standbys | Three-instance topology and higher infrastructure cost |
| Read replica (add-on) | Read scaling and workload isolation | Yes | Asynchronous replication and replica-lag considerations |
The AWS Multi-AZ deployment documentation explains these deployment models.
Do not buy a standard Multi-AZ DB instance solely to scale reads. If read capacity is the main requirement, evaluate a Multi-AZ DB cluster or RDS read replicas instead.
A Multi-AZ standby, by contrast, is primarily a failover mechanism. See AWS’s RDS read replica documentation.
Before buying an RDS MySQL commitment, validate the architecture
Once you have selected the deployment model, commitment optimization becomes much easier.The common mistake is to start with a target RI coverage percentage and then try to force the architecture to fit it. Reverse that order.
First establish the stable workload baseline:
- Identify production and non-production RDS for MySQL instances.
- Separate Single-AZ, standard Multi-AZ, Multi-AZ DB cluster, and read-replica usage.
- Review instance families, sizes, Regions, and engine versions.
- Check upcoming migrations, upgrades, scaling plans, and decommissioning.
- Measure hourly usage rather than relying only on monthly averages.
- Identify existing RIs and Database Savings Plan coverage.
- Model the remaining stable On-Demand usage.
- Compare commitment options against that stable floor.
RDS Reserved Instances vs Database Savings Plans
AWS offers both RDS Reserved Instances and Database Savings Plans, but they solve the commitment problem differently.RDS Reserved Instances are available with one- or three-year terms.
All Upfront and Partial Upfront options are available for one- and three-year terms, while No Upfront is available for a one-year term.
For RDS for MySQL, AWS provides size flexibility within the same instance family under applicable rules. The AWS RDS for MySQL pricing documentation provides the current RI terms and pricing.
For a deeper explanation of RDS MySQL-specific RI mechanics, see our guide to RDS MySQL Reserved Instances.
Database Savings Plans are spend-based commitments. AWS currently offers them on a one-year term with No Upfront payment, with discounts applied automatically to eligible database usage up to the committed amount. See AWS Database Savings Plans pricing for the current eligibility and pricing rules.
You can also read our complete guide to AWS Database Savings Plans for a broader comparison of Database Savings Plans and RDS Reserved Instances.
| Commitment | Best fit | Flexibility | Key guardrail |
|---|---|---|---|
| RDS Reserved Instance | Stable, predictable RDS usage | More configuration-specific | Commit only after validating Region, family, deployment, and long-term need |
| Database Savings Plan | Broader eligible database usage that may change | Higher | Model eligible spend and existing RI coverage before adding a plan |
What about RDS Extended Support?
Extended Support should be checked before optimizing commitments for older MySQL versions.AWS charges RDS Extended Support separately from the underlying DB instance pricing, and the charge can apply to standby instances in Multi-AZ deployments.
For a standard Multi-AZ deployment, that means Extended Support can materially affect the total cost of running an older MySQL version.
The AWS RDS for MySQL pricing documentation provides the current Extended Support rates and eligibility.
The sequencing matters: assess database-version support costs first, then optimize the remaining eligible commitment spend.
Failover, RTO, and RPO checklist
Before treating Multi-AZ as sufficient, validate:RTO: How quickly must the application recover?
RPO: How much data loss can the business tolerate?
Failover behavior: AWS says typical Multi-AZ DB instance failover is 60–120 seconds, but actual time varies.
Connection handling: Existing connections must be re-established after failover.
DNS behavior: Application and runtime DNS caching can affect recovery.
Transaction behavior: Large transactions can extend recovery time.
Retry logic: Confirm that clients retry safely without creating duplicate writes or failures.
Backup restoration: Rehearse restoring from backups rather than assuming Multi-AZ protects against every failure scenario.
Use AWS’s Multi-AZ failover guidance when designing and testing the recovery process.
How to evaluate the RDS MySQL Multi-AZ premium
Use a two-layer decision.
Layer 1: Architecture
Determine whether Single-AZ, standard Multi-AZ, Multi-AZ DB cluster, or read replicas best match the workload’s availability and read-scaling requirements.
Layer 2: Pricing
For the chosen architecture, calculate:
Incremental architecture cost = Multi-AZ cost − comparable Single-AZ cost
Finally, evaluate whether stable usage is suitable for an RDS RI or Database Savings Plan.
For a broader view of RDS commitment economics, see the complete RDS Reserved Instances guide.
How Usage.ai fits
We apply this model specifically to cloud commitment management.Once the RDS architecture and stable eligible usage are established, we focus on the pricing and commitment layer. With Usage.ai, we analyze usage, evaluate commitment opportunities, execute approved commitment-management actions, and monitor outcomes as cloud usage changes.
The architecture decision still comes first. We do not use commitment optimization to determine whether a workload should run Single-AZ, standard Multi-AZ, a Multi-AZ DB cluster, or use read replicas.
First choose the architecture based on availability, recovery, performance, and read-scaling requirements. Then optimize the cost of the stable usage that remains.
Through our Flex Insured Commitment Program, teams can achieve up to 50% savings on covered cloud spend, on average, without taking on a three-year commitment risk. Our fee is a percentage of realized savings, and eligible commitments include cashback protection for underutilization.
The cloud provider still controls the underlying commitment products, pricing, eligibility rules, and billing mechanics. We operate the optimization and management layer around eligible commitments.
Frequently asked questions
Does RDS Multi-AZ mean I pay for two MySQL databases?
For a standard Multi-AZ DB instance deployment, AWS maintains a primary and one standby DB instance in different Availability Zones. The standby is part of the high-availability architecture and does not serve read traffic.
Does RDS Multi-AZ improve read performance?
Not for a standard Multi-AZ DB instance deployment. Its standby does not serve read traffic. Use a Multi-AZ DB cluster or read replicas when read scaling is a requirement.
Does Multi-AZ increase write latency?
It can. AWS notes that Multi-AZ DB instance deployments can have increased write and commit latency compared with Single-AZ because of synchronous replication.
Can I use an RDS Reserved Instance with Multi-AZ?
Yes. AWS offers RDS Reserved Instances for supported RDS configurations, including Multi-AZ deployment options.
Can I combine an RDS RI and Database Savings Plan?
Not for the same workload. AWS does not allow a Database Savings Plan to be combined with an Amazon RDS Reserved Instance for the same workload. Separate eligible usage can use different commitment types, so review existing RI coverage before purchasing a Database Savings Plan.
Does RDS Extended Support apply to the Multi-AZ standby?
Yes. AWS states that RDS Extended Support charges can apply to standby instances in Multi-AZ deployments.
What should I check before buying an RDS MySQL RI?
Check the deployment architecture, Region, instance family and size, engine version, existing commitments, hourly usage stability, upcoming migrations, and expected scaling. Then compare the remaining stable usage with the RI and Database Savings Plan options.
