Skip to content
PuglieseWeb Engineering HandbookSystemDox Pages

Amazon RDS (Relational Database Service)

Amazon RDS runs a relational database engine as a managed service. It is a drop-in replacement for a self-hosted database in the sense that the wire protocol, the SQL and the client drivers are unchanged; what changes is that AWS performs the provisioning, patching, backup, monitoring and failover.

RDS is built for online transaction processing — many small, fast transactions against current data. Analytical workloads belong on Redshift; see OLTP vs OLAP.

Supported engines

Section titled “Supported engines”
  1. MySQL
  2. PostgreSQL
  3. MariaDB
  4. Oracle
  5. Microsoft SQL Server
  6. IBM Db2
  7. Amazon Aurora (MySQL- and PostgreSQL-compatible)

Aurora is administered through RDS but is a different architecture; it has its own page.

What the service manages

Section titled “What the service manages”
  • Automated backups and point-in-time recovery.
  • Minor version patching, within a maintenance window you choose.
  • Instance and storage provisioning, and scaling on request.
  • Replication setup and monitoring.
  • Failover for Multi-AZ deployments.

Backups

Section titled “Backups”
  • Automated backups are enabled by default, with a retention period of 1 to 35 days.
  • Automated backups must be enabled before a read replica can be created.
  • Manual snapshots are retained until you delete them, and are the only kind that can be shared with another account.

Multi-AZ

Section titled “Multi-AZ”

Multi-AZ exists for availability and durability, not for performance. It does not add read capacity.

  • A standby replica is maintained in a second Availability Zone.
  • Replication to the standby is synchronous.
  • The standby serves no traffic — it cannot be read from.
  • Failover is automatic and does not change the connection string: AWS repoints the DNS endpoint at the promoted standby.

The failover sequence is: the primary fails or is taken down for maintenance; RDS promotes the standby; the endpoint’s DNS record is updated; clients reconnect to the same hostname. No manual intervention is required, though connections in flight are dropped and the application must reconnect.

Every RDS engine supports Multi-AZ. Aurora does not use this mechanism because its storage layer is already spread across three Availability Zones.

A Multi-AZ DB cluster deployment is a distinct option on MySQL and PostgreSQL: three instances across three Availability Zones, where the two standbys are readable as well as being failover targets. It sits between a Multi-AZ instance deployment and Aurora in both capability and cost.

Engine note: with MySQL and MariaDB, replication requires a transactional storage engine. MyISAM does not support it; use InnoDB (or XtraDB on MariaDB).

Read replicas

Section titled “Read replicas”

Read replicas exist to add read capacity, and can also serve as a disaster recovery mechanism.

  • Replication from the primary is asynchronous, so a replica lags by seconds to minutes.
  • A replica may be in the same Availability Zone, a different one, or a different Region.
  • Each replica has its own DNS endpoint; the application must be written to send reads to it.
  • Up to 15 read replicas per DB instance for MySQL, MariaDB, PostgreSQL and SQL Server; up to 5 for Oracle. Check the engine’s own quota page before designing to a number.
  • Automated backups must be enabled on the source.
  • A replica can be promoted to a standalone database, which breaks replication permanently.

Because replication is asynchronous, a read replica is not a zero-RPO high-availability mechanism the way a Multi-AZ standby is. It is, however, a legitimate disaster recovery strategy: AWS documents improving disaster recovery as a reason to create a cross-Region read replica, and promoting one gives a recovery point objective of seconds to minutes. The distinction to hold onto is synchronous standby for availability, asynchronous replica for read scale and for regional recovery. See disaster recovery for RDS.

Scaling

Section titled “Scaling”
  • Vertical — change the instance class. This requires a restart, and therefore downtime, on non-Aurora engines.
  • Storage — increase allocated storage without downtime. Storage can only grow; it cannot be reduced.
  • Read — add read replicas.

The scaling page compares these against Aurora Serverless and against moving to DynamoDB.

Security

Section titled “Security”
  • Encryption at rest with AWS KMS, set when the instance is created.
  • Encryption in transit with TLS.
  • IAM database authentication for MySQL and PostgreSQL, so applications can connect with an IAM identity instead of a stored password.
  • Network isolation through VPC subnets and security groups.

Monitoring

Section titled “Monitoring”
  • CloudWatch metrics for the instance and the database.
  • Enhanced Monitoring for operating-system-level metrics from inside the instance.
  • Performance Insights for query-level load analysis.

When not to use RDS

Section titled “When not to use RDS”

RDS is the wrong tool in several recognisable cases.

  • Large binary objects. Store the object in S3 and the metadata and pointer in the database.
  • Automatic scaling on demand. RDS scales by changing instance class or adding replicas, both deliberate acts. DynamoDB or Aurora Serverless scale themselves.
  • Name-value or unpredictable data. If the schema is not known in advance, or varies per record, a document or key-value store fits better than a relational schema retrofitted around it.
  • An engine RDS does not offer. SAP HANA, for example, has to run on EC2. Db2 used to belong on this list and no longer does — RDS for Db2 has been generally available since November 2023.
  • Deep control of the database host. Anything requiring operating-system access, unsupported extensions or exotic engine parameters means running the database on EC2 and accepting the operational work that comes with it.