AWS RDS — Interview & Certification Prep

Relational databases & RDS architecture

RDS is a managed relational database service for engines like PostgreSQL, MySQL, MariaDB, Oracle and SQL Server. AWS handles provisioning, patching, backups and monitoring; you keep control of schema and queries. An RDS instance runs in your VPC, placed via a DB subnet group (subnets across AZs), protected by a security group, and can be encrypted at rest with KMS. Use RDS when you need SQL, joins, transactions and strong relational integrity.

• Managed relational engine (Postgres/MySQL/etc.) in your VPC
• DB subnet group (multi-AZ subnets) + security group + optional KMS encryption
• Choose RDS for SQL, joins, transactions, relational integrity

Exam tip: RDS lives in private subnets behind a security group; you never expose the database to the internet. Encryption at rest uses KMS and is set at creation.

Source: AWS docs — RDS User Guide

Multi-AZ, read replicas and backups

RDS provides availability with Multi-AZ (a synchronous standby in another AZ with automatic failover) and read scaling with read replicas (asynchronous copies you read from). Automated backups and snapshots enable point-in-time recovery. The frequent interview distinction: Multi-AZ is for availability, read replicas are for read throughput — they solve different problems and are often used together.

• Multi-AZ = availability (synchronous standby + automatic failover)
• Read replicas = read scaling (asynchronous, separate endpoints)
• Automated backups/snapshots enable point-in-time recovery

Exam tip: Multi-AZ = synchronous standby, automatic failover, SAME endpoint. Read replicas = asynchronous, SEPARATE endpoints, read scaling (and promotable).

Source: AWS docs — RDS User Guide

Backups, snapshots & point-in-time recovery

RDS automated backups capture the database daily and retain transaction logs, enabling point-in-time recovery (PITR) to any second within the retention window — you restore into a NEW instance. Manual snapshots are user-initiated and kept until you delete them, useful before risky changes or for long-term retention. Snapshots can be copied across Regions and shared across accounts for DR.

• Automated backups + transaction logs = point-in-time recovery (restore to a new instance)
• Manual snapshots persist until deleted; copy cross-Region/share for DR
• Restores create a new instance — plan the endpoint change

Exam tip: PITR comes from automated backups (retention window); manual snapshots are for on-demand and long-term/DR copies.

Source: AWS docs — RDS User Guide

RDS security, encryption & configuration

Secure RDS by placing it in private subnets (via the DB subnet group), restricting access with a security group (only the app tier), and encrypting at rest with KMS (enabled at creation) and in transit with TLS. IAM database authentication lets applications connect using IAM tokens instead of passwords; Secrets Manager can store and rotate DB credentials. Parameter groups tune engine settings; option groups add engine features.

• Private subnets + security group scoped to the app tier
• Encrypt at rest with KMS (set at creation) and in transit with TLS
• IAM DB auth / Secrets Manager for credentials; parameter groups tune the engine

Exam tip: Encryption at rest must be enabled at creation (you can't simply toggle it on an existing unencrypted instance — you restore an encrypted snapshot). Reading an encrypted DB also needs KMS key permissions.

Source: AWS docs — RDS User Guide

Comparison: Multi-AZ vs Read Replica (and when to use each)

Multi-AZ vs Read Replica is THE RDS distinction. Multi-AZ: synchronous standby in another AZ, automatic failover, SAME endpoint; in a Multi-AZ DB instance deployment, the standby is NOT readable — solves AVAILABILITY. Read Replica: asynchronous copy, separate endpoint, readable, small lag, promotable but no auto-failover — solves READ SCALING. They are complementary: a production database often runs Multi-AZ for availability AND read replicas for read-heavy traffic. Pick Multi-AZ when the requirement is "survive an AZ failure automatically"; pick read replicas when it's "handle more read load".

• Multi-AZ = availability (sync standby, auto-failover, same endpoint; in a Multi-AZ DB instance deployment, the standby is not readable)
• Read Replica = read scaling (async, separate endpoint, readable, promotable)
• Often used together; map the requirement (availability vs read load) to the feature

Source: AWS docs — RDS User Guide

Multi-AZ deep dive: synchronous standby & failover

In a Multi-AZ DB instance deployment RDS keeps a standby in a second AZ and replicates SYNCHRONOUSLY, so the standby is always current. You connect to a single DNS endpoint; on a primary failure, maintenance, or AZ outage, RDS fails over by pointing that endpoint at the promoted standby — typically within a minute or two, with no application reconfiguration. In a Multi-AZ DB instance deployment, the standby is NOT readable; it exists purely for availability and durability. (A Multi-AZ DB cluster deployment is different: its two standbys can also serve reads.)

• Synchronous replication to a standby in another AZ (always current)
• Automatic failover flips the same DNS endpoint to the promoted standby
• In a Multi-AZ DB instance deployment, the standby is not readable — availability only, not read scaling

Exam tip: Multi-AZ failover keeps the same endpoint (DNS repoint). If a question needs automatic failover on AZ loss, the answer is Multi-AZ — not read replicas.

Source: AWS docs — RDS User Guide

Read replicas deep dive: scaling reads

Read replicas are ASYNCHRONOUS copies of the primary that serve READ traffic on their own endpoints, offloading the primary. You can have several, in the same or other Regions (cross-Region for DR/local reads). Because replication is asynchronous there is small replica lag, so reads may be slightly stale. A replica can be PROMOTED to a standalone primary (a manual DR/migration step), but it does not automatically fail over like a Multi-AZ standby.

• Asynchronous read-only copies with their own endpoints (offload the primary)
• Multiple replicas, optionally cross-Region; expect small replica lag
• Promotable to standalone primary, but no automatic failover

Exam tip: Read replicas scale READS and can be cross-Region; Multi-AZ scales AVAILABILITY. They are complementary, not alternatives.

Source: AWS docs — RDS User Guide