AWS RDS MySQL vs Aurora MySQL vs RDS MariaDB: The 2026 Solution Architect's Guide to Performance, Price, HA, Security and Governance

By Shrenik Parekh · Updated November 7, 2026 · 14 min read

Introduction: Pick the Engine Once, Then Govern It for Years

Most database mistakes on AWS are not tuning mistakes. They are selection mistakes made in week one: a burstable instance under a steady workload, MariaDB chosen without thinking about the Aurora migration path, or a Multi-AZ design that nobody ever failover-tested.

This guide helps solution architects choose between Amazon RDS for MySQL, Amazon Aurora MySQL-Compatible Edition and Amazon RDS for MariaDB. It covers operational and analytics fit, AI support, compute, storage, memory, performance, price, burstability, high availability, methodology, best practices, verification, validation and OKRs. It also covers the cross-cutting controls that make a database production-grade: observability, auditability and governance.

If you are also running PostgreSQL, read my companion post on PostgreSQL parameters across AWS RDS, Azure, Google Cloud and Oracle OCI. Many of the governance patterns below apply to both.

Quick answer: Choose Aurora MySQL for demanding, variable or globally distributed workloads. Choose RDS for MySQL for predictable workloads, lowest migration risk and simpler cost. Choose RDS for MariaDB when you need MariaDB-specific features, such as thread pooling or temporal tables, and accept that Aurora is not a direct next step.

1. The Three Options in One Minute

Dimension	RDS for MySQL	Aurora MySQL	RDS for MariaDB
Architecture	Instance with EBS storage	Cluster with distributed storage volume shared by writer and readers	Instance with EBS storage
Engine lineage	MySQL community	MySQL-compatible, AWS-built storage layer	MariaDB community
Storage model	gp3 or Provisioned IOPS (io1/io2)	Auto-scaling cluster volume, six copies across three AZs	gp3 or Provisioned IOPS
Read scaling	Up to 15 read replicas	Up to 15 low-lag Aurora Replicas	Up to 15 read replicas
HA	Multi-AZ instance or Multi-AZ DB cluster	Native multi-AZ storage plus replica failover	Multi-AZ instance
Serverless option	No	Aurora Serverless v2	No
Global DR	Cross-Region read replicas	Aurora Global Database	Cross-Region read replicas
Burstable classes	db.t3 / db.t4g	db.t3 / db.t4g (smaller sizes)	db.t3 / db.t4g

Treat limits such as replica counts and maximum storage as a starting point and confirm them in the Amazon RDS User Guide and the Amazon Aurora User Guide before you commit to a design.

Quick decision table

Need	RDS MySQL	Aurora MySQL	RDS MariaDB
Lowest entry cost, small apps	Strong	Good (Serverless v2 can scale to near zero)	Strong
Fast failover, many readers	Multi-AZ DB cluster option	Best (shared storage, up to 15 replicas)	Multi-AZ instance only
Max storage	Up to 64 TiB	Up to 256 TiB, auto-growing	Up to 64 TiB
Multi-Region	Cross-Region read replicas	Global Database (typically sub-second lag)	Cross-Region read replicas
Analytics offload	Zero-ETL to Redshift, read replicas	Zero-ETL to Redshift, parallel query	Read replicas, DMS/CDC
Engine portability	Highest (community MySQL)	MySQL-compatible, AWS-specific internals	MariaDB lineage

Choosing by situation

Situation	Choose
Variable or unpredictable traffic, need scale-to-low-cost	Aurora Serverless v2
Mission-critical OLTP, fast failover, many readers	Aurora MySQL
Multi-Region DR with low RPO	Aurora MySQL with Global Database
Steady workload, simple operations, lowest migration risk	RDS MySQL
Lift-and-shift of an existing MySQL app	RDS MySQL
Application needs MariaDB-specific features	RDS MariaDB
Dev/test with light load	db.t4g on RDS, or Serverless v2
Heavy analytics on the same data	Replicas, plus export to a warehouse or lakehouse

Architecture and technology differences

RDS MySQL and RDS MariaDB run the community engine on EC2-backed instances with EBS volumes. You choose storage type and size, and replication is engine-level (binlog) or storage-level for Multi-AZ. Behavior is familiar to any MySQL or MariaDB DBA, which simplifies migrations and portability.

Aurora MySQL keeps the MySQL-compatible engine but replaces the storage layer with a distributed, log-structured volume that keeps six copies of data across three Availability Zones. Writers ship redo records rather than full pages, readers share the same volume, and storage grows automatically. That design is why Aurora offers quick failover, low replica lag and fast cloning, and also why its parameters, metrics and cost model differ from RDS.

Multi-AZ choices on RDS: a Multi-AZ DB instance has one synchronous standby you cannot read from, with failover usually measured in a minute or two. A Multi-AZ DB cluster (MySQL) adds two readable standbys and typically fails over in well under a minute. RDS MariaDB supports Multi-AZ instance deployments but not the Multi-AZ DB cluster topology.

Instance types: what to choose and when

All three engines use the db.* class naming. Always confirm engine and Region support in the RDS instance class documentation and the Aurora instance types page, because availability varies.

Family	Examples	Best for	Notes
Burstable	db.t4g, db.t3	Dev/test, low-traffic apps, spiky workloads	CPU credits; sustained load exhausts credits or incurs unlimited-mode charges. Not available with Aurora I/O-Optimized for some older classes.
General purpose	db.m7g, db.m8g, db.m7i	Balanced web and API workloads	Graviton usually gives better price-performance if your tooling supports ARM.
Memory optimized	db.r7g, db.r8g, db.r7i, db.x2g	OLTP with large working sets, many connections	Most production databases land here. R8g (Graviton4) expanded to more Regions in July 2026 and adds very large sizes for Aurora.
NVMe-equipped	db.r8gd, db.m8gd, db.r6gd	Temp-table heavy queries, read acceleration	Optimized Reads on RDS uses local NVMe for temporary objects; Optimized Writes helps durability overhead on supported MySQL and MariaDB versions.
Serverless	db.serverless (Aurora Serverless v2)	Variable, unpredictable or many-tenant workloads	Scales in fine-grained ACU steps; one ACU is roughly 2 GiB of memory; supports scale-to-zero configurations.

See AWS's announcement on R8g and M8g in additional Regions for current availability.

Serverless v2 platform version 4 (April 2026): AWS reports up to 30 percent better performance than platform version 3 at no extra cost, with faster, workload-aware scaling and continued scale-to-zero. New clusters, restores and clones launch on it; existing clusters move through a pending maintenance action, a stop and start, or Blue/Green. Capacity runs from 0 to 256 ACUs. The usual trap is a minimum ACU set far above real baseline demand, which erodes the savings. Sources: AWS Database Blog and AWS What's New.

Sizing rule of thumb: size memory first so the hot working set fits in the InnoDB buffer pool, then check vCPU for concurrency, then network and EBS bandwidth ceilings.

Memory, I/O and storage capacity

Memory. RDS reserves a share of instance memory for the OS and management agents. The default innodb_buffer_pool_size is expressed as a formula of DBInstanceClassMemory (commonly about three quarters), which is a sensible starting point. Watch buffer pool hit ratio, Innodb_buffer_pool_reads and swap before resizing.

RDS storage options:

gp3 is the default choice: baseline IOPS and throughput are included, and larger volumes receive higher baselines, with IOPS and throughput provisionable independently of size.
io1 / io2 Block Express suit latency-sensitive, high-IOPS OLTP where consistent performance matters more than cost.
Capacity: up to 64 TiB per instance for MySQL and MariaDB, with storage autoscaling you should enable with a sensible maximum.
Gotcha: storage modifications have cooldown periods, so plan growth rather than reacting to alarms.

Aurora storage: a shared cluster volume that grows automatically up to 256 TiB, with no IOPS provisioning. You pay for storage and, on the Standard configuration, per-million I/O requests. Aurora I/O-Optimized removes I/O charges in exchange for higher instance and storage rates.

Throughput limits to verify: every instance class has its own network and EBS bandwidth cap. A volume that supports 64,000 IOPS is useless on an instance that cannot drive it.

Backups. Automated backups and point-in-time recovery are the baseline. For compliance, add AWS Backup with cross-Region copy and Vault Lock for immutability.

Configuration parameters that matter

Use custom parameter groups (RDS) or DB cluster parameter groups plus instance parameter groups (Aurora) and manage them in Infrastructure as Code. Never edit defaults. Parameter availability and defaults differ by engine and version, so test in a clone before production. For the PostgreSQL equivalent of this exercise, see my PostgreSQL parameters guide across AWS, Azure, Google Cloud and OCI.

Area	Parameter	Guidance
Memory	`innodb_buffer_pool_size`	Keep the default formula unless metrics prove otherwise; large pools need warm-up planning after failover on non-Aurora engines.
Connections	`max_connections`, `wait_timeout`	Default is memory-based. Prefer RDS Proxy over raising limits blindly; each connection costs memory.
Durability	`innodb_flush_log_at_trx_commit`, `sync_binlog`	Keep at 1 for full ACID on RDS. Relaxing them trades durability for speed and should be a documented exception.
Redo log	`innodb_redo_log_capacity` (MySQL 8.0.30+)	Increase for write-heavy bursts to smooth checkpointing.
Replication	`binlog_format`	ROW for CDC, replicas and zero-ETL. Set binlog retention using the RDS procedure for external consumers.
Query diagnostics	`slow_query_log`, `long_query_time`, `log_output`	Enable slow logs to FILE and ship to CloudWatch Logs.
Instrumentation	`performance_schema`	Enable for Database Insights depth; plan for the memory overhead on small instances.
Security	`require_secure_transport`, TLS version settings	Enforce TLS and restrict to modern versions.
Auditing	MariaDB Audit Plugin option (RDS), Advanced Auditing parameters (Aurora)	Choose events deliberately; auditing everything is costly.
Time and charset	`time_zone`, `character_set_server`, `collation_server`	Set explicitly at creation; changing later is painful.

2. Operational vs Analytics Workloads

Operational (OLTP). All three engines suit transactional applications: e-commerce, SaaS back ends, ERP, ticketing and APIs. Aurora gives the best write durability and the fastest replica promotion. RDS MySQL is simplest when traffic is steady and well understood.

Analytics and reporting. None of these engines is a data warehouse. Use them correctly:

Offload reporting to read replicas, never to the writer.
Use Aurora's parallel query where it fits scan-heavy queries on Aurora MySQL.
Stream or export data to Amazon S3 and Athena, Redshift or a lakehouse when scans, joins or history outgrow the OLTP database.
Use zero-ETL integrations where available to avoid hand-built pipelines. Check the current supported engines and Regions first.

For how governance extends from the database into data pipelines, see my post on cloud data labeling and governance on AWS, Azure, Google Cloud and OCI.

3. AI Support: What the Database Can and Cannot Do

Databases are now part of AI architecture, but be precise about what each engine offers:

Aurora MySQL supports machine learning integration with services such as Amazon SageMaker and Amazon Bedrock, so SQL can call a model for inference. Confirm availability for your engine version.
RDS MySQL and RDS MariaDB do not have the same native ML integration. Use an application layer, AWS Lambda or a service such as Bedrock to call models.
Vector search is evolving. Newer MariaDB and MySQL community releases add vector capabilities, but support on RDS depends on the engine version AWS has released. If vector search is a core requirement, validate it in a test instance, or consider a purpose-built option such as Aurora PostgreSQL with pgvector.
AI-assisted operations matter too. Database Insights and Amazon DevOps Guru for RDS use ML to surface anomalies and slow SQL.

Architect's rule: keep the system of record in a relational engine, and put embeddings, feature stores and RAG indexes where they scale and are governed independently, then link them by keys.

4. Compute, Memory and Burstability

Instance families. Graviton-based M and R classes (m7g/m8g, r7g/r8g) typically offer the best price-performance for MySQL-compatible workloads. AWS has been extending R8g and M8g support to more Regions, so check your target Region. Intel R7i remains a safe option when you need x86 compatibility.

Memory. MySQL performance is dominated by the buffer pool. As a rule, memory-optimized R classes suit large working sets and M classes suit balanced workloads. Aurora MySQL 8.4 has introduced automatic memory management through a dedicated parameter in recent release notes, but test it before relying on it in production.

Burstable (T) classes. db.t3 and db.t4g use CPU credits. They are excellent for dev, test, low-traffic internal tools and spiky workloads, and dangerous under sustained load.

Monitor CPUCreditBalance and CPUSurplusCreditBalance in CloudWatch.
If credits trend toward zero, move to M or R. Do not just enable unlimited mode and accept the surprise bill.
Never put production tier-1 databases on a burstable class unless you have measured the credit curve.

Serverless. Aurora Serverless v2 scales in Aurora Capacity Units (ACUs) between a minimum and maximum you set. AWS announced Platform Version 4 in April 2026, with up to 30% better performance than the previous version at no extra cost and continued scale-to-zero support. See the AWS Database Blog for benchmarks. The main trap is setting the minimum ACU far above real baseline demand, which erodes the savings.

5. Storage and I/O

RDS MySQL / MariaDB.

gp3 is the default choice: you provision IOPS and throughput independently of size.
io1/io2 Block Express suits latency-sensitive, high-IOPS workloads.
Autoscaling storage prevents outages but can hide runaway growth. Alert on it.
On supported instance types, Optimized Writes and Optimized Reads improve write amplification and temp-table performance.

Aurora MySQL.

Storage grows automatically in segments and is replicated six ways across three Availability Zones.
Choose Aurora Standard when I/O is a small part of your bill, and Aurora I/O-Optimized when I/O charges become a large share of spend. Compare both in the pricing calculator against your real I/O metrics.

Backups. Automated backups and point-in-time recovery are baseline. For compliance, add AWS Backup with cross-Region copy and Vault Lock for immutability.

6. Performance Methodology

A repeatable method beats tuning by instinct:

Baseline first. Capture CPU, connections, IOPS, latency, replica lag and top SQL for at least a week.
Find the bottleneck class. CPU-bound, memory-bound (buffer pool hit ratio), I/O-bound or lock-bound.
Fix SQL before hardware. Missing indexes and bad plans cost more than instance size. Use EXPLAIN ANALYZE, the slow query log and Performance Schema.
Pool connections. Use RDS Proxy or app-side pooling to prevent connection storms, especially with Lambda and containers. MariaDB's thread pool can help at high concurrency.
Right-size and re-test. Change one variable at a time, and record the result.
Load test before launch with realistic data volumes, not an empty schema.

Parameter groups. Manage parameters in version-controlled parameter groups. Key candidates include innodb_buffer_pool_size, max_connections, slow_query_log, long_query_time and binlog_format. Never hand-edit production parameters in the console without a change record.

7. High Availability and Disaster Recovery

Need	RDS MySQL	Aurora MySQL	RDS MariaDB
AZ failure	Multi-AZ instance (one standby) or Multi-AZ DB cluster (two readable standbys)	Automatic failover to a replica; storage already spans 3 AZs	Multi-AZ instance
Typical failover	Tens of seconds to a couple of minutes	Generally fastest of the three	Tens of seconds to a couple of minutes
Cross-Region DR	Read replica promotion or snapshot copy	Aurora Global Database with low-latency replication	Read replica promotion or snapshot copy
Zero-downtime upgrades	Blue/Green Deployments	Blue/Green Deployments	Blue/Green Deployments

Best practices

Define RPO and RTO per application tier before choosing a pattern.
Test failover quarterly, and measure real application recovery, including DNS caching and connection retries.
Use Blue/Green Deployments for major version upgrades and schema-risky changes.

Plan engine lifecycle early. AWS charges Extended Support fees for engines past community end of life, and in June 2026 extended MySQL 5.7 Extended Support through June 2029 with no price increase. That is a reprieve, not a strategy. Plan the move to MySQL 8.x.

OKRs for AWS database platforms

Use these as a starting template and adjust targets to your business.

Objective	Key result	Example target
Price: Spend efficiently	Cost per 1,000 transactions or per active user	Reduce 15 to 25 percent year over year
	Share of fleet on Graviton or committed pricing	At least 70 percent
	Idle or oversized instances	Zero over 30 days
Convenience: Ship faster	Time to provision a compliant database	Under 30 minutes via self-service
	Percent of databases managed as code	100 percent
	Major-upgrade lead time with Blue/Green	Under one sprint
Security: Reduce risk	Encrypted, non-public databases	100 percent
	Credentials rotated automatically	100 percent
	Critical findings open over 14 days	Zero
Global availability: Stay up	Measured availability by tier	99.95 percent or 99.99 percent
	Tested failover RTO / DR RPO	Meets tier target, proven twice a year
Observability and audit: Know and prove	Alert coverage on golden signals	100 percent of production
	Audit logs retained and queryable	Meets policy, for example 12 months
Governance: Stay current	Engines within standard support	100 percent

Add a performance objective if you track one: p95 latency of the top 20 queries within SLO, zero credit-exhaustion events on burstable production instances, and the top 10 slow queries cut by 50 percent in a quarter.

Accelerating delivery for architects

To speed up application and database delivery, publish golden Terraform or CloudFormation modules that bake in encryption, parameter groups, logging, tags and alarms. Add policy-as-code checks to CI, automate version-inventory alerts, and use clones or Blue/Green for safe change. AI coding assistants can draft modules and review diffs, but always review their output against your guardrails.

Common pitfalls

Burstable instances under steady production load
Serverless v2 minimum capacity set too high
Ignoring Extended Support charges on old engine versions
Sending reporting queries to the writer
Treating Multi-AZ as a backup (it is not)
Never testing restore or failover
Buying IOPS instead of fixing SQL

8. Price and Cost Optimization

Prices vary by Region and change, so always verify at the official Amazon RDS pricing and Aurora pricing pages and model scenarios in the AWS Pricing Calculator.

What drives the bill

Instance hours (or ACU-hours for Serverless v2)
Storage, provisioned IOPS and, for Aurora Standard, I/O requests
Backup storage beyond the free allotment
Multi-AZ, replicas and cross-Region data transfer
Extended Support surcharges for end-of-life engine versions
Extras such as RDS Proxy and Database Insights retention

Cost levers, in order of impact

Right-size using at least two weeks of CloudWatch data.
Move to Graviton where compatibility allows.
Commit. Reserved Instances can save a large share versus On-Demand for steady provisioned databases, and newer Database Savings Plans target serverless usage. Third-party analyses cite figures such as up to 69% and 35% respectively, but your discount depends on term, Region and payment option, so validate with AWS.
Stop idle non-production databases on schedules, or use Serverless v2 for intermittent workloads.
Compare Aurora Standard and I/O-Optimized using actual I/O metrics.
Expire manual snapshots and clean up orphaned replicas.

RDS MySQL vs MariaDB price: instance pricing is generally the same for equivalent classes, so choose on features and roadmap, not price. See the usage.ai MariaDB vs MySQL cost comparison for a third-party view.

9. Security, Convenience and Global Availability

Security baseline (all three engines)

Encryption at rest with AWS KMS (customer-managed keys for regulated data) and TLS in transit
Private subnets, tightly scoped security groups, no public endpoints for production
IAM database authentication and AWS Secrets Manager rotation instead of shared static passwords
Least-privilege IAM roles for administration, enforced with Service Control Policies
Database Activity Streams on Aurora for near-real-time activity monitoring, where supported for your engine
Audit plugin options for RDS MySQL and MariaDB, and advanced auditing on Aurora MySQL

Convenience. Managed patching, automated backups, one-click Multi-AZ, point-in-time recovery, parameter groups and Infrastructure as Code support (CloudFormation, Terraform, CDK) mean your team spends time on schema and SQL, not on servers.

Global availability. All three are available in most commercial AWS Regions, including GovCloud for many engines. Aurora Global Database adds fast cross-Region replication and recovery for multi-Region applications. Always check the Regional availability for your chosen instance class and engine version, since new instance types arrive in Regions on a rolling schedule.

10. Observability, Auditability and Governance

This is where mature teams differ from the rest.

Observability stack

Amazon CloudWatch metrics and alarms: CPU, memory, connections, replica lag, deadlocks, credit balance, storage
Enhanced Monitoring for OS-level metrics
CloudWatch Database Insights (the evolution of Performance Insights) for load analysis and top SQL
Log export of error, slow query, general and audit logs to CloudWatch Logs or S3
Distributed tracing from the application, so database latency is tied to user requests

Auditability

AWS CloudTrail for every control-plane change (who modified a parameter group or deleted a snapshot)
Database audit logs for data-plane access
AWS Config rules to detect unencrypted, public or non-Multi-AZ databases

Governance

Tag every database with owner, environment, data classification and cost center
Enforce guardrails with AWS Organizations SCPs, Control Tower and Security Hub
Standardize engine versions and parameter groups through IaC modules
Run an access review at least quarterly
Document data retention and deletion rules, and test restores

The same approach applies across clouds. See my Database Governance and Observability posts, and the full AWS RDS label archive, for more detail.

11. Choosing: A Decision Framework

If your situation is...	Choose
Variable or unpredictable traffic, need scale-to-low-cost	Aurora Serverless v2
Mission-critical OLTP, fast failover, many read replicas	Aurora MySQL
Multi-Region active DR with low RPO	Aurora MySQL with Global Database
Steady workload, simple operations, lowest migration risk	RDS for MySQL
Lift-and-shift of an existing MySQL app	RDS for MySQL
Need MariaDB features (temporal tables, thread pool, specific storage engines)	RDS for MariaDB
Dev/test with light load	RDS on db.t4g, or Serverless v2
Heavy analytics on the same data	Replicas plus export to a warehouse or lakehouse

Note that moving from MariaDB to Aurora is not a single step. Plan a migration to MySQL first, then to Aurora, so factor that into your roadmap.

12. Verification and Validation Checklist

Before go-live (verification: did we build it right?)

Encryption at rest and TLS enforced
Database in private subnets, with no public accessibility
Parameter group version-controlled and reviewed
Multi-AZ or Aurora replicas confirmed
Backups, PITR and a restore test completed
Alarms on CPU, memory, connections, storage, replica lag and credits
Tags and AWS Config rules applied

Validation (does it meet the business need?)

Load test hits target p95 latency and throughput
Failover test meets RTO with the real application
Cross-Region recovery drill meets RPO and RTO
Cost forecast within 10% of budget after 30 days
Audit evidence collected for compliance reviewers

Quick health queries

-- Replication and connection health
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL VARIABLES LIKE 'max_connections';
-- Slowest statements (requires Performance Schema)
SELECT DIGEST_TEXT, COUNT_STAR, ROUND(SUM_TIMER_WAIT/1e12,2) AS total_sec
FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;

13. OKRs for AWS Database Platforms

Use these as a starting template and adjust targets to your own baseline.

Objective 1: Reliable and available data platform

KR1: 99.95% or better measured availability for tier-1 databases
KR2: Quarterly failover test completed for 100% of tier-1 databases, meeting RTO
KR3: Replica lag p95 under your defined threshold

Objective 2: Fast and efficient performance

KR1: p95 query latency within the agreed SLO for top 20 queries
KR2: Zero production databases on burstable classes with credit exhaustion events
KR3: Reduce top-10 slow queries by 50% within one quarter

Objective 3: Cost-optimized

KR1: 70% or more of steady-state databases covered by commitments
KR2: Cost per transaction reduced by 15%
KR3: No databases running on engine versions in paid Extended Support without an approved exception

Objective 4: Secure, auditable and governed

KR1: 100% of databases encrypted, tagged and private
KR2: Secrets rotated automatically for 100% of application credentials
KR3: Audit logs retained and queryable for the required period, with quarterly access reviews completed

Objective 5: Faster delivery for application teams

KR1: New database provisioned via IaC in under one day
KR2: Major version upgrades done with Blue/Green and zero unplanned downtime

14. Common Pitfalls

Using burstable instances for steady production load
Setting Serverless v2 minimum capacity too high
Ignoring Extended Support charges on old engine versions
Sending reporting queries to the writer
Assuming Multi-AZ is a backup (it is not)
Never testing restore or failover
Over-provisioning IOPS instead of fixing SQL

Conclusion

There is no universally best engine. Aurora MySQL wins on resilience, scale and global reach, RDS for MySQL wins on simplicity and migration safety, and RDS for MariaDB wins when MariaDB's own features matter. Whichever you choose, the platform is only as good as its baselines, tests, observability and governance.

Next steps: pick one workload, apply the checklist in section 12, and set two or three OKRs from section 13. Then explore my related guides, such as PostgreSQL parameters on AWS RDS and other clouds and the AWS label archive.

Frequently Asked Questions

Is Aurora MySQL always faster than RDS for MySQL? Not always. Aurora often performs better for write-heavy, high-concurrency and replica-heavy workloads, but a well-tuned RDS MySQL instance can be more cost-effective for steady, moderate workloads. Benchmark with your own data.

Can I use RDS Proxy with all three? RDS Proxy supports Aurora MySQL, RDS for MySQL and RDS for MariaDB. Check current version and Region support.

Is Multi-AZ the same as a read replica? No. Multi-AZ is for availability and failover. Read replicas are for read scaling and, for RDS engines, cross-Region disaster recovery.

Should new projects use MariaDB on RDS? Only if you need MariaDB-specific features. Otherwise MySQL-compatible options keep the Aurora path open.

References and Further Reading

Amazon RDS User Guide, AWS Documentation
Amazon Aurora User Guide, AWS Documentation
Amazon RDS Pricing and Amazon Aurora Pricing
Amazon Aurora features
Aurora Serverless: faster performance, enhanced scaling, and still scales down to zero, AWS Database Blog
Aurora and RDS for MySQL extend Extended Support for MySQL 5.7 through June 2029, AWS What's New, June 17, 2026
Aurora and RDS support r8g, r7g and r7i in additional Regions, AWS What's New, January 2026
AWS Well-Architected Framework, Reliability and Cost Optimization pillars
RDS MariaDB vs MySQL: identical price, different tradeoffs, usage.ai, May 2026

Disclaimer: Pricing, limits, engine versions and Regional availability change frequently. Verify against official AWS documentation before making architecture or purchasing decisions.

About the author: Shrenik Parekh writes practical dispatches on cloud architecture, data engineering and applied AI. Connect on LinkedIn or browse more at shrenikparekh.com.