AWS Database Deployments and Management: EC2, RDS, Aurora, and Replicas

When deploying a relational database on AWS, the first decision is usually not the database engine. It is how much of the database environment you want to operate yourself. You can install a database on Amazon EC2, use the managed features of Amazon RDS, or choose Amazon Aurora for a MySQL- or PostgreSQL-compatible managed engine.

This is Part 29 of the AWS Cloud Practitioner Study Notes. Part 15 covered storage attached to EC2, while Part 28 explained the private subnets and security controls commonly used around a database.

The deployment decision

Option	Who manages the database environment?	Best fit
Database on EC2	You manage the OS and database	Full control, unusual versions, or unsupported customisation
Amazon RDS	AWS manages common database operations	Managed relational databases with less administration
Amazon Aurora	AWS manages a cloud-optimised relational engine	MySQL- or PostgreSQL-compatible workloads needing Aurora’s architecture

AWS manages the underlying cloud infrastructure in every option, but the customer responsibility is very different. A database on EC2 gives you the most control and the most operational work. RDS and Aurora remove much of the routine undifferentiated administration.

1. Database on Amazon EC2

With a self-managed database, you launch an EC2 instance and install and operate the database software yourself.

EC2 instance
├── MySQL
├── PostgreSQL
├── Oracle
└── SQL Server

You are responsible for tasks such as:

• Operating-system and database patching
• Database installation and version upgrades
• Backups and restore testing
• Replication and failover design
• Monitoring and alerting
• Storage, encryption, and access controls
• High availability and disaster recovery

The advantage is control. You can choose an unusual database version, install custom extensions, access the operating system, or use a database configuration that a managed service does not support.

The trade-off is that AWS does not manage the database software for you. If an exam question emphasises full operating-system control, custom database software, or self-managed maintenance, the likely answer is a database on EC2.

2. Amazon RDS: managed relational databases

Amazon RDS is a managed service for setting up, operating, and scaling relational databases. AWS handles much of the routine work, including provisioning, software patching, backups, monitoring features, and infrastructure maintenance.

Common RDS engines include:

• MySQL
• PostgreSQL
• MariaDB
• Oracle
• Microsoft SQL Server
• IBM Db2, where supported

RDS does not remove every database responsibility. You still own the schema, query design, application behaviour, access policy, capacity choices, and performance tuning. Feature and engine availability can also vary by Region and engine version.

Exam shortcut: “Managed database,” “automatic backups,” “AWS handles patching,” or “reduce database administration” usually points to Amazon RDS.

3. Amazon Aurora

Amazon Aurora is a fully managed relational database engine compatible with MySQL and PostgreSQL. It is part of the Amazon RDS family, but it uses its own distributed storage and cluster architecture rather than being simply a standard MySQL or PostgreSQL DB instance.

Aurora is designed for workloads that need a managed relational database with high availability, automatic storage growth, and a cloud-optimised architecture. AWS documentation describes Aurora as offering up to six times the throughput of stock MySQL or PostgreSQL on similar hardware, but actual performance depends on schema design, queries, data, instance class, and workload.

Application
    │
    ▼
Aurora cluster
├── Writer instance
├── Reader instances (optional)
└── Distributed cluster volume

Choose Aurora when the requirement is a MySQL-compatible or PostgreSQL-compatible managed database with Aurora-specific availability, storage, or scaling characteristics. Do not choose it merely because the word “database” appears in a question; first identify whether the question asks for compatibility, control, availability, or read scaling.

4. Multi-AZ: high availability and failover

A standard RDS Multi-AZ DB instance deployment maintains a standby DB instance in another Availability Zone using synchronous replication. If the primary becomes unavailable, RDS can fail over to the standby.

Application
    │
    ▼
Primary DB instance (AZ-A)
    │
    │ synchronous replication
    ▼
Standby DB instance (AZ-B)

The standby in a standard Multi-AZ DB instance deployment is for failover support and does not serve application read traffic. Multi-AZ therefore addresses availability, not read throughput.

There are newer Multi-AZ DB cluster deployment options whose standby DB instances can also serve read traffic. For the classic Cloud Practitioner exam comparison, however, remember the standard distinction: Multi-AZ means high availability and automatic failover; read replicas mean read scaling.

Exam shortcut: “Improve database availability,” “survive an Availability Zone failure,” or “automatic failover” points to Multi-AZ.

5. Read replicas: scale read traffic

A read replica is a read-only copy of a source database. Applications can send read-only queries to replicas while the primary continues to handle writes.

                   ┌── Read replica 1
Primary database ──┼── Read replica 2
                   └── Read replica 3

For standard RDS DB instance read replicas, changes are copied asynchronously. This means a replica can be slightly behind the primary, so the application must tolerate eventual consistency for the reads routed there.

Read replicas are useful for:

• Read-heavy websites
• Reporting queries that should not compete with production traffic
• Read capacity beyond one DB instance
• Cross-Region read access or disaster-recovery designs

A read replica is not the same as a Multi-AZ standby. It is readable, but it is not automatically the primary’s synchronous failover partner. A read replica can be promoted when needed, but that is a different recovery operation from automatic Multi-AZ failover.

Multi-AZ versus read replica

Feature	Standard Multi-AZ DB instance deployment	RDS read replica
Main purpose	High availability	Read scaling
Replication	Synchronous standby replication	Asynchronous replication
Serves normal read traffic?	No	Yes
Automatic failover	Yes	No automatic primary failover
Typical exam wording	“Availability” or “failover”	“Read performance” or “read-heavy workload”

If a workload needs both resilience and read scaling, it is common to combine Multi-AZ for the primary database with one or more read replicas for read traffic.

6. Automated backups and manual snapshots

Amazon RDS automated backups run during a configured backup window and support point-in-time recovery within the configured retention period. Point-in-time recovery is useful after accidental deletion, corruption, or an application error because you can restore to a time before the incident.

Manual DB snapshots are user-initiated backups of a specific database state. They remain until you delete them, so they are useful before a risky upgrade, migration, or schema change.

Backup type	Main property
Automated backup	Retained according to the configured retention period; supports point-in-time recovery
Manual snapshot	User-created and retained until explicitly deleted

Backups are not a complete disaster-recovery plan by themselves. Test restores, define recovery time and recovery point objectives, and consider copying backups or replicas to another Region when the business requires regional recovery.

7. Scaling a managed database

RDS scaling usually falls into three categories:

Vertical scaling

Change the DB instance class to provide more CPU, memory, or network capacity.

db.t3.small → db.t3.large

The change may require a maintenance window or cause a brief interruption, depending on the engine, deployment, and modification options.

Storage scaling

Increase allocated storage or choose a storage configuration that provides the required I/O performance. RDS supports online storage scaling for many configurations, but exact limits and behaviour depend on the engine and feature support.

Read scaling

Add read replicas and route suitable read-only traffic to them. This does not automatically solve write contention, poor queries, missing indexes, or transaction design problems.

Aurora adds its own cluster-level options, including reader instances and Aurora Auto Scaling for reader capacity in supported configurations.

8. Security and monitoring

RDS databases are commonly placed in private subnets and accessed by application resources through security groups. A typical design is:

Internet
    │
Application Load Balancer
    │
EC2 application servers in private subnets
    │
RDS database in private subnets

Relevant controls and features include:

• Security groups controlling network access
• Encryption at rest using AWS Key Management Service keys
• TLS/SSL encryption in transit where supported and configured
• IAM database authentication for supported engines and configurations
• CloudWatch metrics and alarms
• Enhanced Monitoring
• Performance Insights for supported engines and configurations

AWS manages the service infrastructure, but you still need to restrict access, protect credentials, review database permissions, monitor query behaviour, and keep the application secure.

Common exam questions

Scenario	Best answer
The team needs full OS access and installs the database manually	Database on EC2
AWS should manage patching and routine database operations	Amazon RDS
The workload needs a managed MySQL- or PostgreSQL-compatible engine with Aurora architecture	Amazon Aurora
The database must fail over automatically if an AZ has a problem	Multi-AZ
Read traffic is overwhelming the primary database	Read replica
The team needs to recover to a point in time	Automated backups
The team needs a backup before an upgrade that should remain until deleted	Manual snapshot

Memory map for CLF-C02

• Need full control? → EC2
• Need AWS to manage a relational database? → RDS
• Need a managed MySQL- or PostgreSQL-compatible AWS engine? → Aurora
• Need high availability and automatic failover? → Multi-AZ
• Need more read capacity? → Read replica
• Need point-in-time recovery? → Automated backups
• Need a persistent user-controlled backup? → Manual snapshot

Conclusion

The key database decision is the boundary of responsibility. EC2 gives you control but makes you responsible for the database environment. RDS removes much of the routine administration for common relational engines. Aurora provides a managed MySQL- or PostgreSQL-compatible engine with a cloud-optimised architecture.

For availability and performance, keep the distinction clear: Multi-AZ protects against infrastructure or Availability Zone failure, while read replicas scale read traffic. Automated backups support point-in-time recovery, and manual snapshots give you a durable checkpoint before a change.

Sources

• Amazon RDS concepts and supported engines
• Amazon Aurora overview
• Amazon RDS Multi-AZ deployments
• Amazon RDS read replicas
• Amazon RDS automated backups and point-in-time recovery