Basic Information
| Field | Details |
|---|---|
| English name | Amazon RDS |
| Full name | Amazon Relational Database Service |
| Chinese description | 托管关系型数据库服务 |
| Japanese description | マネージドリレーショナルデータベース |
| Exam frequency | ⭐⭐⭐⭐⭐ |
| Often confused with | Aurora / DynamoDB / EC2 自建数据库 |
In one sentence
RDS fits workloads needing SQL, joins, transactions, and relationships. Customers still own schemas, queries, accounts, and access controls.
Core purpose
- Applications connect through endpoints; production databases usually live in private subnets behind security groups.
- Multi-AZ provides high availability and failover; read replicas use asynchronous replication to scale reads.
- Automated backups and logs support PITR within retention, while manual snapshots preserve a chosen point in time.
Exam focus
- Choose Multi-AZ for availability and read replicas for read scaling.
- RDS manages infrastructure, but customers choose retention, permissions, and recovery procedures.
- Cross-Region replicas, backup copies, and AWS Backup solve different goals.
Common misconceptions
- A Multi-AZ standby is normally not an ordinary read-scaling target.
- RDS does not automatically optimize every SQL query, index, or schema.
Key takeaway
SQL/joins/transactions → RDS; availability → Multi-AZ; read scale → read replicas.
Related services
Aurora, DMS, AWS Backup, Secrets Manager, KMS, CloudWatch.
Update: availability, connections, and recovery
- A Multi-AZ DB instance uses a synchronous standby for failover. A read replica scales reads and can be promoted independently.
- A Multi-AZ DB cluster spans three AZs and combines high availability with readable replicas.
- RDS Proxy uses connection pooling and multiplexing to absorb Lambda connection storms; it is not a query cache.
- Storage Auto Scaling increases allocated storage but does not automatically shrink it.
- IAM DB authentication replaces long-term passwords with short-lived SigV4 tokens for supported engines, while database-user mapping still applies.