AWS MySQL Showdown - RDS vs RDS Multi AZ vs Aurora vs Serverless - Mydbops Webinar 41
MyDBOPS
31 views
32 slides
Mar 04, 2025
Slide 1 of 32
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
About This Presentation
AWS MySQL Showdown - RDS vs RDS Multi AZ vs Aurora vs Serverless - Mydbops Webinar 41
Key takeaways:
* Performance & Scalability – How each service handles workloads
* High Availability & Failover – Ensuring uptime and reliability
* Cost & Efficiency – Which solution gives the...
Slide Content
AWS MySQL Showdown:
RDS vs. Aurora vs. Serverless
Presented by
Maha Lakshmi G
Mydbops
Feb 21, 2025
Mydbops MyWebinar Edition- 41
RDS vs. Aurora vs. Serverless
Presented by
Maha Lakshmi G
Mydbops
Feb 21, 2025
Mydbops MyWebinar Edition- 41
Agenda
❏Abstract
❏Architecture
❏Storage Design
❏High Availability Mechanisms
❏Performance Considerations
❏Cost-Benefit Analysis
❏Conclusion
❏Abstract
❏Architecture
❏Storage Design
❏High Availability Mechanisms
❏Performance Considerations
❏Cost-Benefit Analysis
❏Conclusion
Abstract
❏AWS offers RDS MySQL, Multi-AZ RDS Cluster, and
Aurora MySQL for scalable and high-availability database solutions.
❏Each service differs in architecture, replication methods, failover
mechanisms, and cost efficiency.
❏This webinar will compare storage design, high availability, and
performance to help organizations choose the right solution.
❏AWS offers RDS MySQL, Multi-AZ RDS Cluster, and
Aurora MySQL for scalable and high-availability database solutions.
❏Each service differs in architecture, replication methods, failover
mechanisms, and cost efficiency.
❏This webinar will compare storage design, high availability, and
performance to help organizations choose the right solution.
Architecture and
Storage Design
Storage Design
Architecture- AWS RDS MySQL
❏Single-AZ Deployment – Single primary instance in one AZ.
PSingle Primary
Read + Write
❏Single-AZ Deployment – Single primary instance in one AZ.
PSingle Primary
Read + Write
Architecture- AWS RDS MySQL
❏Multi-AZ Deployment – Standby instance in another AZ
(synchronous replication, automatic failover).
❏Multi-AZ Deployment – Standby instance in another AZ
(synchronous replication, automatic failover).
Architecture- AWS RDS MySQL
❏Multi-AZ RDS Cluster– One writer DB instance and two reader DB
instances across three AZs. (semi- synchronous replication)
❏Multi-AZ RDS Cluster– One writer DB instance and two reader DB
instances across three AZs. (semi- synchronous replication)
Storage Design- AWS RDS MySQL
❏AWS RDS MySQL Storage Options
Storage Type Storage Size Provisioned IOPS Max Throughput
io2 100 GiB – 65,536 GiB 1,000 – 256,000 IOPS 16,000 MiB/s
io1
100 – 399 GiB 1,000 – 19,950 IOPS 500 MiB/s
400 – 65,536 GiB 1,000 – 256,000 IOPS 4,000 MiB/s
gp3
20 – 399 GiB Baseline: 3,000 IOPS 125 MiB/s
400 – 65,536 GiB 12,000 – 64,000 IOPS 500 – 4,000 MiB/s
gp2
(not recommended)
5 – 399 GiB 100 – 1,197 IOPS 128 – 250 MiB/s
400 – 1,335 GiB 1,200 – 4,005 IOPS 512 – 1,000 MiB/s
1,336 – 3,999 GiB 4,008 – 11,997 IOPS 1,000 MiB/s
4,000 – 65,536 GiB 12,000 – 64,000 IOPS 1,000 MiB/s
❏AWS RDS MySQL Storage Options
Storage Type Storage Size Provisioned IOPS Max Throughput
io2 100 GiB – 65,536 GiB 1,000 – 256,000 IOPS 16,000 MiB/s
io1
100 – 399 GiB 1,000 – 19,950 IOPS 500 MiB/s
400 – 65,536 GiB 1,000 – 256,000 IOPS 4,000 MiB/s
gp3
20 – 399 GiB Baseline: 3,000 IOPS 125 MiB/s
400 – 65,536 GiB 12,000 – 64,000 IOPS 500 – 4,000 MiB/s
gp2
(not recommended)
5 – 399 GiB 100 – 1,197 IOPS 128 – 250 MiB/s
400 – 1,335 GiB 1,200 – 4,005 IOPS 512 – 1,000 MiB/s
1,336 – 3,999 GiB 4,008 – 11,997 IOPS 1,000 MiB/s
4,000 – 65,536 GiB 12,000 – 64,000 IOPS 1,000 MiB/s
Architecture- AWS Aurora MySQL
❏Cluster-Based Design – One primary (writer) DB instance and up to
15 reader DB instances sharing the same storage
❏Shared Storage – A single, SSD-backed cluster volume replicated
across three AZs for durability. Automatically expands up to 128 TiB
based on data
❏Cluster-Based Design – One primary (writer) DB instance and up to
15 reader DB instances sharing the same storage
❏Shared Storage – A single, SSD-backed cluster volume replicated
across three AZs for durability. Automatically expands up to 128 TiB
based on data
Storage Design- AWS Aurora MySQL
Architecture- Aurora Serverless
❏Auto-Scaling Compute
❏SSD-backed storage automatically scales up to 128 TiB.
❏Maintains six copies of data across three AZs for reliability.
❏Instances start/stop dynamically without affecting stored data.
❏Pauses compute when idle and restarts on demand to reduce costs.
❏Auto-Scaling Compute
❏SSD-backed storage automatically scales up to 128 TiB.
❏Maintains six copies of data across three AZs for reliability.
❏Instances start/stop dynamically without affecting stored data.
❏Pauses compute when idle and restarts on demand to reduce costs.
Storage Design- Aurora Serverless
High Availability
Mechanisms
Mechanisms
High Availability Mechanisms- AWS RDS MySQL
❏Single-AZ:
●No automatic failover; recovery requires manual intervention.
❏Multi-AZ (Standby Mode):
●Automatic failover (~60-120 seconds)
●Standby cannot process read requests until promoted to primary.
❏RDS Multi-AZ Cluster:
●Faster failover (~35-50 seconds)
❏Single-AZ:
●No automatic failover; recovery requires manual intervention.
❏Multi-AZ (Standby Mode):
●Automatic failover (~60-120 seconds)
●Standby cannot process read requests until promoted to primary.
❏RDS Multi-AZ Cluster:
●Faster failover (~35-50 seconds)
High Availability Mechanisms- AWS Aurora MySQL
❏Amazon Aurora:
●Automatic failover to a reader instance within ~30 seconds.
●Aurora promotes the most up-to-date reader instance to primary,
automatically updating the cluster endpoint.
❏Aurora Serverless
●If an instance fails, Aurora Serverless provisions a new instance
automatically and reroutes traffic with minimal disruption.
❏Amazon Aurora:
●Automatic failover to a reader instance within ~30 seconds.
●Aurora promotes the most up-to-date reader instance to primary,
automatically updating the cluster endpoint.
❏Aurora Serverless
●If an instance fails, Aurora Serverless provisions a new instance
automatically and reroutes traffic with minimal disruption.
Replication
Mechanisms
Mechanisms
Replication Mechanisms
❏RDS MySQL (Single-AZ) → No replication; single instance. Supports
up to 5 read replicas using binlog-based asynchronous replication.
❏RDS MySQL (Multi-AZ - One Standby) → Uses synchronous physical
replication to a passive standby in another AZ (no read traffic).
❏Multi-AZ RDS Cluster → Uses semi-synchronous physical replication
to 2 standbys, which serve read traffic. Also supports binlog-based
async read replicas.
❏RDS MySQL (Single-AZ) → No replication; single instance. Supports
up to 5 read replicas using binlog-based asynchronous replication.
❏RDS MySQL (Multi-AZ - One Standby) → Uses synchronous physical
replication to a passive standby in another AZ (no read traffic).
❏Multi-AZ RDS Cluster → Uses semi-synchronous physical replication
to 2 standbys, which serve read traffic. Also supports binlog-based
async read replicas.
Replication Mechanisms
❏Aurora MySQL → Uses storage-based replication with 6 copies
across 3 AZs, eliminating the need for binlog-based replication.
Aurora Replicas read directly from shared storage, supporting up to
15 replicas with minimal lag.
❏Aurora Serverless → Uses the same Aurora storage-based
replication but automatically scales compute based on demand.
❏Aurora MySQL → Uses storage-based replication with 6 copies
across 3 AZs, eliminating the need for binlog-based replication.
Aurora Replicas read directly from shared storage, supporting up to
15 replicas with minimal lag.
❏Aurora Serverless → Uses the same Aurora storage-based
replication but automatically scales compute based on demand.
Performance
Considerations
Considerations
Performance Considerations- AWS RDS MySQL
❏Single-AZ and Multi-AZ (Standby Mode):
●Storage Options:
SSD-backed GP3/GP2 (cost-effective)
IO1 (up to 256,000 IOPS for OLTP).
●Scalability: Expand storage on-the-fly with zero downtime.
●Optimized Writes: 2x faster write throughput.
●Optimized Reads: Up to 50% faster query performance.
●Read Replication: Uses asynchronous replication with Read
Replicas for scaling read operations.
❏Single-AZ and Multi-AZ (Standby Mode):
●Storage Options:
SSD-backed GP3/GP2 (cost-effective)
IO1 (up to 256,000 IOPS for OLTP).
●Scalability: Expand storage on-the-fly with zero downtime.
●Optimized Writes: 2x faster write throughput.
●Optimized Reads: Up to 50% faster query performance.
●Read Replication: Uses asynchronous replication with Read
Replicas for scaling read operations.
Performance Considerations- AWS RDS Multi-AZ Cluster
❏AWS RDS Multi-AZ Cluster:
●Faster Transactions: Up to three active DB instances with shared
storage.
●Lower Latency: Parallel writes across AZs reduce replication lag.
●Read Scaling: Read replicas handle queries, easing primary load.
●Quick Failover: Faster recovery (~35-50s) than Multi-AZ standby.
●Replication Mechanism: Uses synchronous replication across
instances in different AZs for improved durability and availability.
❏AWS RDS Multi-AZ Cluster:
●Faster Transactions: Up to three active DB instances with shared
storage.
●Lower Latency: Parallel writes across AZs reduce replication lag.
●Read Scaling: Read replicas handle queries, easing primary load.
●Quick Failover: Faster recovery (~35-50s) than Multi-AZ standby.
●Replication Mechanism: Uses synchronous replication across
instances in different AZs for improved durability and availability.
Performance Considerations- AWS Aurora MySQL
❏Amazon Aurora:
●Highly Durable Storage: Data is replicated six times across three AZs.
●High Performance: Supports up to 200,000 write IOPS
with low-latency replication.
●Read Scalability: Up to 15 read replicas with near-instant replication.
●Optimized Queries: Parallel execution enhances analytical workloads.
●Auto-Scaling Storage: Expands automatically up to 128 TiB without
downtime.
❏Amazon Aurora:
●Highly Durable Storage: Data is replicated six times across three AZs.
●High Performance: Supports up to 200,000 write IOPS
with low-latency replication.
●Read Scalability: Up to 15 read replicas with near-instant replication.
●Optimized Queries: Parallel execution enhances analytical workloads.
●Auto-Scaling Storage: Expands automatically up to 128 TiB without
downtime.
Performance Considerations- AWS Aurora MySQL
❏Aurora Serverless:
●Dynamic Compute Scaling: Adjusts capacity instantly based on demand.
●Startup Latency: Initial activation may cause slight delay.
●Cost-Efficient: Pay only for actual usage, preventing over-provisioning.
●Reliable Storage: Utilizes Aurora's six-way replicated storage across AZs.
●Ideal for Variable Workloads: Best suited for unpredictable database traffic.
●Replication Mechanism: Uses storage-level replication across
multiple AZs, just like standard Aurora, ensuring high durability and
availability.
❏Aurora Serverless:
●Dynamic Compute Scaling: Adjusts capacity instantly based on demand.
●Startup Latency: Initial activation may cause slight delay.
●Cost-Efficient: Pay only for actual usage, preventing over-provisioning.
●Reliable Storage: Utilizes Aurora's six-way replicated storage across AZs.
●Ideal for Variable Workloads: Best suited for unpredictable database traffic.
●Replication Mechanism: Uses storage-level replication across
multiple AZs, just like standard Aurora, ensuring high durability and
availability.
Cost-Benefit Analysis
Cost-Benefit Analysis- AWS RDS MySQL
❏Pricing Models:
●On-Demand Instances: Pay for compute capacity by the hour with no
long-term commitments. Suitable for applications with unpredictable
workloads.
●Reserved Instances: Commit to a one- or three-year term to receive
significant discounts, up to 66% over On-Demand rates.
Ideal for steady-state workloads.
❏Pricing Models:
●On-Demand Instances: Pay for compute capacity by the hour with no
long-term commitments. Suitable for applications with unpredictable
workloads.
●Reserved Instances: Commit to a one- or three-year term to receive
significant discounts, up to 66% over On-Demand rates.
Ideal for steady-state workloads.
Cost-Benefit Analysis- AWS Aurora MySQL
❏Pricing Models:
●Aurora Standard: Pay for database instances, storage, and I/O
operations. Suitable for applications with low to moderate I/O usage.
●Aurora I/O-Optimized: Ideal for I/O-intensive applications, offering up
to 40% cost savings when I/O spend exceeds 25% of total Aurora
database spend.
❏Pricing Models:
●Aurora Standard: Pay for database instances, storage, and I/O
operations. Suitable for applications with low to moderate I/O usage.
●Aurora I/O-Optimized: Ideal for I/O-intensive applications, offering up
to 40% cost savings when I/O spend exceeds 25% of total Aurora
database spend.
Cost-Benefit Analysis- AWS Aurora Serverless
❏Pricing Models:
●On-Demand Scaling: Automatically adjusts compute capacity based on
application demand, ideal for variable or unpredictable workloads.
●Cost Efficiency: Charges are based on actual usage,
preventing costs associated with over-provisioning.
❏Pricing Models:
●On-Demand Scaling: Automatically adjusts compute capacity based on
application demand, ideal for variable or unpredictable workloads.
●Cost Efficiency: Charges are based on actual usage,
preventing costs associated with over-provisioning.
Key Takeaways
AWS MySQL Showdown: RDS vs. Aurora vs. Serverless
Feature RDS MySQL RDS Multi-AZ
Cluster
Aurora MySQL Aurora
Serverless
Architecture Single/Multi-AZ,
Standby-based
Multi-AZ, multiple
active DBs
Cluster-based,
shared storage
Auto-scaling,
ephemeral instances
Storage SSD-backed,
fixed-size
Shared SSD-backed,
auto-expands
Shared SSD-backed,
auto-expands
Shared SSD-backed,
auto-expands
High Availability Multi-AZ failover
(60-120s)
Faster failover
(~35-50s)
Fast failover (~30s)Auto-provisions new
instance
Performance Read replicas for
scaling
Parallel writes, lower
latency
15 replicas, parallel
queries
Scales compute
dynamically
Cost Model On-Demand &
Reserved
On-Demand &
Reserved
Standard &
I/O-Optimized
Pay-per-use, no
over-provisioning
Feature RDS MySQL RDS Multi-AZ
Cluster
Aurora MySQL Aurora
Serverless
Architecture Single/Multi-AZ,
Standby-based
Multi-AZ, multiple
active DBs
Cluster-based,
shared storage
Auto-scaling,
ephemeral instances
Storage SSD-backed,
fixed-size
Shared SSD-backed,
auto-expands
Shared SSD-backed,
auto-expands
Shared SSD-backed,
auto-expands
High Availability Multi-AZ failover
(60-120s)
Faster failover
(~35-50s)
Fast failover (~30s)Auto-provisions new
instance
Performance Read replicas for
scaling
Parallel writes, lower
latency
15 replicas, parallel
queries
Scales compute
dynamically
Cost Model On-Demand &
Reserved
On-Demand &
Reserved
Standard &
I/O-Optimized
Pay-per-use, no
over-provisioning
Any Questions?
Thank you!
Download
Download Slideshow Get the original presentation fileQuick Actions
Statistics
- Views 31
- Slides 32
- Age 273 days
Related Slideshows
1
DTI BPI Pivot Small Business - BUSINESS START UP PLAN
MeljunCortes
28 views
1
CATHOLIC EDUCATIONAL Corporate Responsibilities
MeljunCortes
30 views
11
Karin Schaupp – Evocation; lançamento: 2000
alfeuRIO
28 views
10
Pillars of Biblical Oneness in the Book of Acts
JanParon
26 views
31
7-10. STP + Branding and Product & Services Strategies.pptx
itsyash298
27 views
44
Business Legislation PPT - UNIT 1 jimllpkggg
slogeshk98
30 views