Learn
AWS
Databases
RDS and Aurora

AWSGCP laterAzure later

RDS and AuroraAmazon Relational Database Service and Amazon Aurora

DatabasesCore service · full depthFree while we build the libraryChecked against AWS docs · 15 Sept 2026

Managed relational databases: six engines run for you, plus Aurora, AWS's own MySQL- and PostgreSQL-compatible engine, with standbys, replicas and backups built in.

In the examsSolutions Architect – AssociateHIGHSolutions Architect – ProfessionalHIGHDeveloper – AssociateMEDSysOps Administrator – AssociateHIGHSecurity – SpecialtyLOWData Engineer – AssociateMED

Where RDS and Aurora takes you7 steps, all open

I know the problem it solves
I can picture it
I know how it scales
I know how it fails
I know when to choose it
I can use it in a design
I can answer an exam question

What & why

A relational database somebody else runs

Amazon RDS runs a relational database for you: Db2, MariaDB, Microsoft SQL Server, MySQL, Oracle or PostgreSQL. AWS takes the backups, applies the patches, and detects and recovers from failures. You still design the schema and tune the queries.

Aurora is AWS's own engine inside RDS. It is compatible with MySQL and PostgreSQL, and keeps its data in a cluster volume copied across three Availability Zones that grows by itself. Aurora Serverless v2 adds capacity that follows the load.

Reach for it when

the data is relational, with joins and transactions across tables
an existing MySQL, PostgreSQL, Oracle or SQL Server application moves to AWS
you want a managed database, not a server to patch
the database must keep running when a zone fails

It is the wrong tool when

items are fetched by key at any scale, with no servers to size: that is DynamoDB
the same reads repeat all day and need to come from memory: put ElastiCache in front
one item is a large file: keep it in S3 and store its key

Mental model

A bank branch with a second vault

A bank branch. The main vault takes every deposit, and a second vault in another building is updated with each one before the teller says done, ready to take over if the first building closes. Clerks answer balance enquiries from copies of the ledger that run a little behind.

The main vaultthe one instance that takes writesPrimary

The second vault, kept in stepa synchronous copy in another zoneMulti-AZ standby

Clerks answering enquiriescopies that serve reads, a little behindRead replicas

The branch's addressa DNS name that follows the primaryEndpoint

The nightly ledgerdaily backups and transaction logsAutomated backups

One ledger shared by three buildingsAurora's storage, copied across zonesCluster volume

How it works

Engine, place, standby, endpoint

Pick an engine and a classThe engine and version, an instance class for CPU and memory, and storage that can grow by itself.
Place it in your VPCIn private subnets, with a security group that lets in only your application.
Turn on Multi-AZA standby in another zone is updated synchronously and takes over if the primary fails.
Connect by endpointApplications use a DNS name, never an address, so a failover changes where it points and not your settings.

Engines: Six, plus AuroraDb2, MariaDB, SQL Server, MySQL, Oracle, PostgreSQL
Multi-AZ instance: 60 to 120 stypical failover
Multi-AZ cluster: Under 35 stypical failover
Read replicas: Up to 15for each source database
Backups kept: 0 to 35 days0 turns them off
Aurora volume: Up to 256 TiBgrows and shrinks by itself

Architecture

An orders database behind app servers

Writes go to the Multi-AZ primary, reports read from a replica, hot pages come from a cache, and the password comes from Secrets Manager.

Writes to the primary, reports to a replica. A read replica takes heavy report queries off the primary. It is updated asynchronously, so it can run a little behind.

The standby is not a replica. In a Multi-AZ DB instance deployment the standby serves no reads at all; it is there only to take over.

No password in the code. RDS can generate the master password, keep it in Secrets Manager and rotate it, every seven days by default.

Scaling

Reads out, writes up, storage by itself

Reads scale out. Add up to 15 read replicas to a source database, each with its own endpoint that the application must choose. RDS does not add them for you. On Aurora, the reader endpoint spreads connections across the Aurora Replicas.

Writes scale up. One primary takes every write, so more write capacity means a larger instance class.

Storage grows by itself. With storage autoscaling on, RDS adds space once free space has been 10 percent or less for 5 minutes: 10 GiB, 10 percent, or the growth it predicts, whichever is most. It never shrinks.

Aurora Serverless v2 measures capacity in Aurora capacity units, adjusts it in steps as small as half a unit, and can pause at zero when nothing connects.

RDS Proxy pools connections. Many short-lived connections, such as Lambda functions', share a small pool to the database instead of each opening its own.

Failure simulation

Lose the primary

Multi-AZ DB instance: a primary and one standby

App serversServed by Primary

AZ a

AZ b

Click a node to make it fail. The timings in the log are the real ones, played 15× faster.

Everything is up. Take a node or a whole zone down.

Aurora: a writer and one Aurora Replica, through the cluster endpoint

App serversServed by Writer

AZ a

AZ b

Click a node to make it fail. The timings in the log are the real ones, played 5× faster.

Everything is up. Take a node or a whole zone down.

Where the time goes. A Multi-AZ DB instance typically fails over in 60 to 120 seconds, and Aurora typically in under 60, often under 30. How each simulation splits that between noticing and taking over is illustrative; the totals are AWS's.

The name follows the database. RDS changes the endpoint's DNS record to point at the standby, so applications reconnect to the same name and must look it up again when they do.

Aurora with no replica has nothing to promote, so it creates a new primary instance instead, typically in under 10 minutes.

What sets it off. A failed host, lost network to the primary, a storage failure, operating system patching, or a reboot you ask to fail over.

Undoing a mistake is a restore. Point-in-time restore builds a new DB instance from the backups and the transaction logs uploaded every 5 minutes; the original is left alone.

Security

Private, encrypted, no stored passwords

Private, behind a security group. Keep the database in private subnets, and let its security group admit only the application's.

Encryption at rest is chosen at creation. It uses a KMS key and covers the storage, logs, automated backups, read replicas and snapshots. The key cannot be changed later.

Encrypting an existing database means taking a snapshot, copying it with encryption on, and restoring from the copy.

IAM database authentication lets MariaDB, MySQL and PostgreSQL accept a token that lasts 15 minutes instead of a password, over SSL/TLS.

Secrets Manager for the master password, generated and rotated by RDS, and never shown to a person.

Cost

How you are charged, not what it costs today

Instance hours, billed by the second after a 10-minute minimum. Reserved Instances lower the rate for databases that run all the time.

Storage per GB-month, plus the provisioned IOPS if you choose them.

Backup storage up to the size of the database is included; beyond that it is charged.

Replication traffic to a read replica in the same Region is not charged.

Aurora charges instance hours, or capacity-unit hours for Serverless v2, and storage per GB-month. Aurora Standard also charges for each I/O request; Aurora I/O-Optimized does not, and suits clusters whose I/O is 25 percent or more of what they spend on Aurora.

Prices change, so none are printed here. Check the RDS and Aurora pricing pages on aws.amazon.com.

Comparison

Standbys, replicas, and other databases

Second copy	How many, where	Serves reads	Kept in step	Takes over
Multi-AZ DB instance	One standby, another zone	No	Synchronously	By itself, typically 60 to 120 s
Multi-AZ DB cluster	Two standbys, three zones	Yes	Semisynchronously	By itself, typically under 35 s
Read replica	Up to 15, even in another Region	Yes	Asynchronously	Only when you promote it
Aurora Replica	Up to 15, on the shared volume	Yes	Usually under 100 ms behind	By itself, typically under 60 s

Database	Model	Grows by	Choose it when
RDS and Aurora	Relational, SQL with joins	A larger instance, and replicas for reads	Transactions and joins across tables
DynamoDB	Key-value and document, no joins	Itself, with no servers	Lookups by key at any scale
ElastiCache	In memory	More nodes or shards	Repeated reads, in front of a database

SAA traps

The phrase in the question, and what it means

a standby that can also serve readsA Multi-AZ DB cluster, or read replicas

A Multi-AZ DB instance's standby serves nothing until it takes over; a DB cluster's two standbys serve reads.

offload reporting queries from the primaryA read replica

It serves reads from a copy kept up to date asynchronously.

survive the loss of an Availability Zone automaticallyMulti-AZ

It fails over by itself; a read replica has to be promoted by hand.

relational disaster recovery in another Region, with a lag of about a secondAurora Global Database

It replicates to up to 10 secondary Regions, typically in under a second.

encrypt an existing unencrypted RDS databaseSnapshot, copy it encrypted, restore

Encryption at rest can only be turned on when a DB instance is created.

thousands of Lambda functions exhaust the database's connectionsRDS Proxy

It pools and shares connections, and keeps them through a failover.

keep backups for longer than 35 daysManual snapshots

Automated backups stop at 35 days; manual snapshots stay until you delete them, even after the instance is gone.

put the database back as it was 20 minutes agoPoint-in-time restore

It restores to a new DB instance, and the original is untouched.

MariaDB, MySQL and PostgreSQL accept a token that lasts 15 minutes.

a relational database that is busy by day and idle at nightAurora Serverless v2

Capacity follows the load in half-unit steps, and can pause at zero.

Scenario

Exam style, marked when you answer

An online shop runs its orders database on a single-AZ RDS for MySQL DB instance. If an Availability Zone fails, the database must keep running automatically without losing committed orders. Separately, heavy reporting queries are slowing the checkout. Which change meets both needs?

Practice

Fill the gap, the way the challenges work

A web shop's app servers, in two zones, keep orders, customers and products in related tables and join them in most queries. The database must be run by AWS, keep a synchronous standby in a second zone, and fail over by itself. What do the app servers write to?

ALB· Load balancerEC2 Auto Scaling· App servers, two zonesPick a service below

Quick revision

The night before the exam

What: Managed relational databases: six engines, plus Aurora.
Multi-AZ instance: One synchronous standby, no reads; failover 60 to 120 s.
Multi-AZ cluster: Two readable standbys in three zones; under 35 s.
Read replicas: Up to 15, asynchronous, cross-Region, promoted by hand.
Backups: Kept 0 to 35 days; a restore makes a new instance.
Encryption: Only at creation; otherwise snapshot, encrypted copy, restore.
Aurora: Volume across three zones, up to 256 TiB, 15 replicas.
RDS Proxy: Pools connections, and holds them through a failover.

This whole page is free right now.The AWS library is still being written, so every page of it is open to everyone while that lasts. It becomes a paid bundle later; what you read today costs you nothing.

Checked against

Every fact on this page was checked against AWS’s own documentation on 15 Sept 2026. If AWS has changed something since, its page is the one to trust.