Cargando...
Cargando...
Fully managed relational databases so you focus on queries, not infrastructure
Amazon RDS (Relational Database Service) is a fully managed service that makes it easy to set up, operate, and scale relational databases in the cloud. It automates time-consuming administration tasks such as hardware provisioning, database setup, patching, and backups across six popular database engines: MySQL, MariaDB, PostgreSQL, Oracle, Microsoft SQL Server, and Amazon Aurora. RDS is a destination service for running structured, relational workloads — not a migration tool — and integrates deeply with the AWS ecosystem for high availability, security, and performance.
Run production-grade relational databases without managing the underlying OS, patching, backups, or replication infrastructure — freeing teams to focus on application logic and data modeling.
Use When
Avoid When
Multi-AZ Deployment (Standard)
Synchronous standby in a second AZ; automatic failover; standby is NOT readable
Multi-AZ DB Cluster (2 readable standbys)
Available for MySQL and PostgreSQL; 3 AZs; faster failover (~35s); standbys ARE readable
Read Replicas (up to 5 per source)
Asynchronous replication; can be promoted to standalone; cross-region supported
Automated Backups & PITR
Retention 1–35 days; restores to any second within the retention window
Manual DB Snapshots
Retained indefinitely; can be shared across accounts; can be copied cross-region
Encryption at Rest (AES-256 via KMS)
Must be enabled at creation; cannot be added to an existing unencrypted instance without snapshot restore
Encryption in Transit (SSL/TLS)
Supported for all engines; can be enforced via parameter groups or SSL require flags
IAM Database Authentication
Supported for MySQL and PostgreSQL only; uses short-lived auth tokens instead of passwords
RDS Proxy
Connection pooling; reduces Lambda/serverless connection storms; supports IAM auth and Secrets Manager
Performance Insights
Free 7-day retention; paid long-term retention; identifies top SQL waits and load
Enhanced Monitoring
OS-level metrics at 1-second granularity; uses CloudWatch Logs
Storage Auto Scaling
Automatically scales storage when free space is low; set a maximum threshold
RDS Custom
Oracle and SQL Server only; provides OS/engine-level access for specialized configurations
Blue/Green Deployments
Safe, low-downtime upgrades; creates a staging environment with replication from production
Cross-Region Read Replicas
Supported for MySQL, MariaDB, PostgreSQL, Oracle, and Aurora; useful for DR and global read scaling
VPC Support
All new RDS instances run in VPC; EC2-Classic is retired
Event Notifications (SNS)
Subscribe to RDS events (failover, backup complete, etc.) via SNS topics
Maintenance Windows
Weekly configurable window for minor version upgrades and patching
Reserved Instances (1-year, 3-year)
Significant savings vs On-Demand; available in Standard and Convertible types
Oracle BYOL (Bring Your Own License)
Use existing Oracle licenses on RDS; license-included also available at higher cost
SQL Server BYOL
Bring existing SQL Server licenses via License Mobility through Software Assurance
Database Activity Streams
Near-real-time stream of database activity to Kinesis Data Streams for audit and compliance
Kerberos Authentication
Supported for Oracle, SQL Server, MySQL, PostgreSQL via AWS Managed Microsoft AD
Secrets Manager Integration
Automatic rotation of database credentials; works with RDS Proxy for seamless rotation
CloudTrail Integration
API-level audit logging for RDS management operations (not SQL-level; use Database Activity Streams for that)
Graviton2/Graviton3 Instance Support
ARM-based instances offer better price-performance for many RDS workloads
Read-Through / Cache-Aside Caching
high freqPlace ElastiCache (Redis or Memcached) in front of RDS to cache frequently read query results. Reduces RDS read load and latency for hot data. Cache-aside: application checks cache first; on miss, reads from RDS and populates cache. Critical for high-traffic OLTP applications. Redis preferred for persistence, TTL, and complex data structures.
Traditional 3-Tier Web Application Backend
high freqEC2 instances in an Auto Scaling group (app tier) connect to RDS in a private subnet. Security groups restrict DB access to only the app tier's SG. RDS Multi-AZ provides HA; Read Replicas offload reporting queries. This is the canonical AWS web application architecture.
Serverless Application with RDS Proxy
high freqLambda functions connecting directly to RDS can exhaust database connection limits due to Lambda's ephemeral, high-concurrency nature. RDS Proxy pools and reuses connections, preventing connection storms. Lambda → RDS Proxy → RDS. RDS Proxy also integrates with Secrets Manager for credential rotation without Lambda code changes.
Backup Export and Data Import/Export
high freqRDS snapshots can be exported to S3 in Apache Parquet format for analytics. MySQL/PostgreSQL support native S3 import/export for bulk data loading. Oracle supports Data Pump export to S3. S3 serves as the durable, cost-effective staging layer for ETL pipelines feeding RDS.
Migration Path: RDS to Aurora
high freqStandard RDS MySQL or PostgreSQL instances can be migrated to Aurora by creating an Aurora Read Replica of the RDS instance, then promoting it. This provides a near-zero-downtime migration path. Aurora offers better performance, up to 15 read replicas, and storage auto-scaling to 128 TiB.
Polyglot Persistence (RDBMS + NoSQL)
high freqUse RDS for structured transactional data (orders, accounts) and DynamoDB for high-velocity, schema-flexible data (session state, user preferences, IoT events). Application routes writes to the appropriate store based on data characteristics. Common in microservices architectures.
Automatic Credential Rotation
high freqSecrets Manager stores and automatically rotates RDS master user passwords on a configurable schedule. Applications retrieve credentials via Secrets Manager API rather than hardcoding. RDS Proxy natively integrates with Secrets Manager so credential rotation is transparent to connection pool.
Monitoring, Alerting, and Operational Visibility
high freqRDS publishes metrics to CloudWatch (CPU, FreeStorageSpace, DatabaseConnections, ReadLatency, WriteLatency, etc.). Set CloudWatch Alarms for threshold breaches. Enhanced Monitoring adds OS-level metrics. Performance Insights adds SQL-level wait analysis. EventBridge routes RDS events (failover, backup) to Lambda or SNS.
Homogeneous and Heterogeneous Database Migration
high freqAWS DMS migrates data TO RDS from on-premises, EC2-hosted, or other cloud databases. For heterogeneous migrations (e.g., Oracle → PostgreSQL), use AWS Schema Conversion Tool (SCT) first to convert the schema, then DMS to migrate data. RDS is the destination — it is NOT a migration tool itself.
Database Activity Streams for Compliance Audit
high freqDatabase Activity Streams push a near-real-time stream of database activity (DDL, DML, login events) to Kinesis Data Streams. Downstream consumers (Lambda, Kinesis Data Firehose → S3) archive and analyze activity for compliance (PCI-DSS, SOC, HIPAA). This is separate from CloudTrail, which only captures API-level management events.
Multi-AZ standby is NOT readable. If a question asks how to scale reads, the answer is Read Replicas (async) — not Multi-AZ. Multi-AZ is for high availability and automatic failover only. The only exception is Multi-AZ DB Cluster (MySQL/PostgreSQL), which has 2 readable standbys.
RDS is a DESTINATION for migration, not a migration tool. AWS DMS migrates data TO RDS. AWS SCT converts schemas. RDS itself does not perform any migration. If a question asks 'what migrates data,' the answer is DMS — not RDS.
Encryption must be enabled at DB instance creation time. You CANNOT enable encryption on an existing unencrypted RDS instance directly. The correct process is: create an encrypted snapshot from the unencrypted instance → restore a new encrypted instance from that snapshot → update your application endpoint. This multi-step process is frequently tested.
Aurora supports up to 15 read replicas; standard RDS engines (MySQL, MariaDB, PostgreSQL) support up to 5. When a scenario requires massive read scaling beyond 5 replicas, Aurora is the correct answer. Aurora also uses a shared storage volume (not replication), so replicas have near-zero replication lag.
Setting automated backup retention to 0 disables automated backups AND point-in-time recovery. For any compliance or DR scenario requiring PITR, retention must be ≥ 1 day. Manual snapshots are NOT a substitute for PITR — they only restore to the exact snapshot point.
Multi-AZ ≠ Read Scaling. Multi-AZ standby is passive (no reads, no writes). Use Read Replicas for read scaling. This distinction is tested on EVERY certification level.
RDS is a migration DESTINATION. DMS moves data TO RDS. SCT converts schemas. RDS itself does zero migration. 'What migrates data?' = DMS. 'What converts schema?' = SCT.
To encrypt an existing unencrypted RDS instance: Snapshot → Copy snapshot with KMS encryption → Restore new encrypted instance. You cannot encrypt in-place by modifying the instance.
RDS Proxy is the correct answer for Lambda-to-RDS connectivity at scale. Lambda's concurrency model creates many short-lived connections that can exhaust RDS max_connections. RDS Proxy pools connections and integrates with Secrets Manager and IAM. Without RDS Proxy, Lambda at high concurrency will cause 'too many connections' errors.
IAM Database Authentication is only supported for MySQL and PostgreSQL on RDS (and Aurora). It is NOT supported for Oracle, SQL Server, or MariaDB. It uses short-lived authentication tokens (15-minute TTL) generated via the AWS SDK — no static password needed.
RDS Custom is ONLY for Oracle and SQL Server. It provides OS and engine-level access for scenarios requiring custom agents, third-party monitoring tools, or specialized configurations not possible in standard managed RDS. For MySQL/PostgreSQL customization needs, use EC2-hosted databases instead.
Read Replicas can be promoted to standalone DB instances (useful for disaster recovery). They use asynchronous replication, so there may be replication lag. A promoted Read Replica is no longer a replica — it becomes an independent DB instance. This promotion is irreversible.
Database Activity Streams (DAS) provide SQL-level audit trails to Kinesis — CloudTrail only captures RDS API management calls (create, delete, modify instance), NOT SQL queries. For compliance scenarios requiring query-level auditing, the answer is Database Activity Streams, not CloudTrail.
gp3 storage is almost always more cost-effective than gp2 for RDS. With gp3, you can independently provision IOPS and throughput without increasing storage size. With gp2, IOPS scale with storage (3 IOPS/GB), forcing you to over-provision storage to get more IOPS.
Blue/Green Deployments in RDS enable safe, low-downtime major version upgrades and schema changes. The 'green' environment is a staging copy with continuous replication from 'blue' (production). After validation, you switch over (typically under 1 minute). This is the recommended approach for zero-downtime upgrades on SAA-C03 and DOP-C02.
Cross-region Read Replicas serve two purposes: (1) global read scaling for geographically distributed users, and (2) cross-region disaster recovery (promote the replica if the primary region fails). Cross-region replicas incur data transfer charges and have higher replication lag than same-region replicas.
Storage Auto Scaling prevents 'out of storage' outages by automatically increasing storage when free space is critically low. You set a maximum storage threshold. It does NOT scale down — RDS storage can only grow, not shrink. To reduce storage, you must restore from a snapshot to a smaller instance.
Common Mistake
Multi-AZ standby instances can serve read traffic, reducing load on the primary.
Correct
Standard Multi-AZ standby instances are completely passive and do NOT serve any read or write traffic. They exist solely for automatic failover. Only Multi-AZ DB Cluster (MySQL and PostgreSQL only, newer feature) provides readable standbys. Read Replicas (async) are the correct mechanism for read scaling.
This is the #1 RDS misconception on all certification levels. Questions will describe a read-scaling problem and offer 'enable Multi-AZ' as a distractor. Always choose Read Replicas for reads, Multi-AZ for HA. If you see 'readable standby,' that is Multi-AZ DB Cluster — a distinct feature.
Common Mistake
RDS is a migration tool — you use RDS to migrate databases from on-premises to AWS.
Correct
RDS is a DESTINATION service, not a migration tool. AWS Database Migration Service (DMS) is used to migrate data TO RDS. AWS Schema Conversion Tool (SCT) converts schemas before heterogeneous migrations. RDS simply hosts the database after migration is complete.
Exam questions frequently test the DMS + SCT + RDS architecture. A common trap is asking 'which service migrates data to RDS?' — the answer is DMS, not RDS. SCT handles schema conversion only (not data movement). Remember: SCT = Schema, DMS = Data Movement.
Common Mistake
You can enable encryption on an existing unencrypted RDS database instance by modifying the instance settings.
Correct
You CANNOT directly enable encryption on a running unencrypted RDS instance. The only supported path is: (1) Take a snapshot of the unencrypted instance, (2) Copy the snapshot with encryption enabled (selecting a KMS key), (3) Restore a new encrypted DB instance from the encrypted snapshot, (4) Update application connection strings to the new endpoint.
This appears on SAA-C03 and DOP-C02 as a 'how do you encrypt an existing unencrypted database' scenario. The multi-step snapshot-copy-restore process is the only answer. Candidates who don't know this will incorrectly choose 'modify the instance to enable encryption.'
Common Mistake
AWS SCT (Schema Conversion Tool) migrates both the schema AND the data from source to target database.
Correct
AWS SCT converts only the database schema (DDL: tables, views, stored procedures, functions) from one engine to another. It does NOT move any data. AWS DMS is required to migrate the actual data. SCT and DMS are complementary tools used together for heterogeneous migrations.
This misconception appears directly in the question bank data as a top exam trap. Remember the division: SCT = Schema Conversion Tool (structure only), DMS = Database Migration Service (data movement). You need both for heterogeneous migrations.
Common Mistake
RDS automated backups and manual snapshots work the same way and can substitute for each other.
Correct
Automated backups enable point-in-time recovery (PITR) to any second within the retention window (1–35 days) and are automatically deleted when the retention period expires or the instance is deleted. Manual snapshots capture the DB at a specific moment, are retained indefinitely, can be shared across accounts and copied cross-region, but do NOT enable PITR between snapshot points.
A scenario asking for 'restore to 3 hours ago' requires automated backups (PITR). A scenario asking for 'long-term archival of the database state before a major release' requires a manual snapshot. Confusing the two leads to wrong answers on backup/recovery questions.
Common Mistake
Enabling RDS Multi-AZ doubles performance because you now have two database instances.
Correct
Standard Multi-AZ does NOT improve performance. The standby is completely passive and handles zero traffic. Multi-AZ is purely a high-availability feature that provides automatic failover (typically 1–2 minutes) if the primary fails. It does increase cost (roughly 2x) but provides zero read performance benefit.
Cost-optimization questions may ask 'which of these provides HA without performance benefit' — Multi-AZ is the answer. Performance improvement requires Read Replicas or ElastiCache. Multi-AZ = availability, Read Replicas = scalability.
Common Mistake
RDS for Oracle and SQL Server support the same maximum storage as MySQL and PostgreSQL (64 TiB).
Correct
SQL Server on RDS has a maximum storage of 16 TiB, which is significantly lower than the 64 TiB maximum for MySQL, MariaDB, PostgreSQL, and Oracle. Large SQL Server workloads approaching this limit may need to be redesigned or migrated to a different engine.
Engine-specific limits are tested on SAA-C03 and SAP-C02. When a scenario describes a large SQL Server database growing toward 16 TiB, the correct architectural response might be migration to Aurora PostgreSQL using SCT + DMS.
MMPOP = MySQL, MariaDB, PostgreSQL, Oracle, PostgreSQL — the 5 RDS engines with up to 5 Read Replicas. Aurora gets 15 (3x more, 3x better).
Multi-AZ = Availability (HA, failover, passive standby). Read Replicas = Read Scaling (async, active, up to 5). Never mix them up: 'AZ = Availability, RR = Reading'.
SCT converts the Structure (schema), DMS moves the Data. SCT then DMS — alphabetical order, schema before data.
Encrypt RDS: Snapshot → Copy (with KMS key) → Restore. Remember 'SCR' — Snapshot, Copy, Restore.
RDS Proxy = Connection Pool for Lambda. Lambda loves Proxy because Lambda hates holding connections. 'Lambda Proxy = No Connection Sloppiness'.
Backup retention 0 = No backups AND No PITR. Zero retention = Zero recovery options. Always set ≥ 1 for any production workload.
RDS Custom = Oracle and SQL Server ONLY. 'Custom needs a Contract' — Oracle and SQL Server are the enterprise engines that need custom OS access.
CertAI Tutor · CLF-C02, SAA-C03, SAP-C02, DEA-C01, DOP-C02, DVA-C02 · 2026-02-21
In the Same Category
Comparisons