Managed relational databases: RDS and Aurora

Why a managed database?

Running a database yourself on EC2 means installing it, applying security patches, taking backups, testing restores, setting up replication and waking up at 3 am when the disk fills. Amazon RDS (Relational Database Service) does those jobs for you. You still design tables, write queries, choose indexes and size the instance. "Managed" means AWS runs the engine; it does not mean AWS tunes your slow queries.

Engines

RDS supports MySQL, PostgreSQL, MariaDB, Oracle, Microsoft SQL Server and IBM Db2. Amazon Aurora is a separate engine built by AWS that is compatible with MySQL or PostgreSQL, so most apps work with it unchanged. Aurora stores six copies of your data across three AZs on a shared storage layer, grows storage automatically, and can fail over to a replica quickly. Aurora Serverless v2 scales capacity up and down with load, which suits spiky or development workloads.

Multi-AZ versus read replicas

These two features solve different problems, and mixing them up is the most common interview mistake.

RDS also offers Multi-AZ DB clusters for MySQL and PostgreSQL, with one writer and two readable standbys. You can combine features: a production database is often Multi-AZ and also has one or two read replicas for reporting. Read replicas for cross-region use also help with disaster recovery.

Backups, point-in-time restore and snapshots

Automated backups take a daily snapshot plus transaction logs, kept for a retention period you choose from 1 to 35 days (0 turns them off). With them you can do point-in-time restore (PITR) to any second in the retention window, usually up to the last five minutes. A restore always creates a NEW database instance; you then point the app at it. Manual snapshots are kept until you delete them, even after the database is deleted, so use them before risky changes and for long-term copies.

aws rds create-db-instance \
  --db-instance-identifier shop-db \
  --engine postgres \
  --db-instance-class db.t4g.medium \
  --allocated-storage 50 --storage-type gp3 \
  --master-username shopadmin \
  --manage-master-user-password \
  --db-subnet-group-name shop-db-private \
  --vpc-security-group-ids sg-0db111 \
  --multi-az \
  --backup-retention-period 7 \
  --storage-encrypted \
  --no-publicly-accessible

aws rds create-db-instance-read-replica --db-instance-identifier shop-db-reports --source-db-instance-identifier shop-db
aws rds restore-db-instance-to-point-in-time --source-db-instance-identifier shop-db \
  --target-db-instance-identifier shop-db-restored --restore-time 2026-10-19T09:45:00Z

Networking, configuration and encryption

• DB subnet group: the list of private subnets (in at least two AZs) where RDS may place the database. Keep "publicly accessible" off.
• Security group: allow the database port (5432 for PostgreSQL, 3306 for MySQL) only from the app's security group.
• Parameter groups hold engine settings such as max_connections or time zone. Changing some settings needs a reboot. Option groups add engine features for engines like Oracle and SQL Server.
• Encryption at rest uses KMS and must be chosen when you create the database. To encrypt an existing unencrypted database: snapshot it, copy the snapshot with encryption on, and restore from the copy.
• Use TLS for connections, and consider RDS Proxy when many short-lived connections (for example from Lambda functions) would overload the database.