RDS, DynamoDB & Data
Amazon RDS is managed relational storage for PostgreSQL, MySQL, MariaDB, Oracle, SQL Server and Aurora; DynamoDB is fully managed NoSQL with single-digit-millisecond latency. Learn Multi-AZ, read replicas, backups and snapshots, plus DynamoDB keys, capacity modes and when to choose each.
What is this?
Amazon RDS is a managed relational database service supporting PostgreSQL, MySQL, MariaDB, Oracle and SQL Server, plus the AWS-native Aurora engine. It handles provisioning, patching, backups, replication and failover for you. Amazon DynamoDB is a fully managed NoSQL key-value and document database with single-digit-millisecond latency that scales automatically as you provision throughput. Choosing between them is a core architecture decision.
Why do you need it?
- Databases are the state layer of almost every application — losing them means losing the business.
- RDS removes the operational burden of running your own PostgreSQL or MySQL (patching, backups, high availability).
- DynamoDB is the standard answer for high-scale, low-latency, serverless-friendly data.
- Knowing when to choose relational versus NoSQL changes both schema design and cost structure.
- Backups, snapshots, failover and read replicas are recurring production topics and interview questions.
Mental model
A managed bank vault
RDS and DynamoDB
RDS is the bank's managed vault for relational ledgers: the bank maintains the building, guards and daily backups, and you deposit rows into tables with strict relationships. DynamoDB is a high-speed safety deposit box network: every box (item) is fetched or stored in milliseconds by a key, there is no rigid ledger structure, and the bank expands the number of boxes automatically under demand. Both keep your valuables safe; you pick by how you need to access them.
How it works
- RDS provisions a database engine from a parameter group, stores data on EBS volumes, and runs automated backups on a schedule.
- You can create a Multi-AZ deployment with a synchronous standby, so a primary failure triggers automatic failover to the standby.
- Read replicas are asynchronous copies that offload read traffic and can be promoted to primary during a disaster.
- DynamoDB stores items as key-value or document records in tables; you provision read and write capacity or let on-demand mode absorb any scale.
- DynamoDB maintains multiple synchronous copies across availability zones automatically and gives you point-in-time recovery when enabled.
RDS with a read replica and DynamoDB on-demand scaling.
Key commands
aws rds describe-db-instancesShow engine, status, class and endpoint of every DB instance.
aws rds describe-db-snapshotsList automated and manual snapshots available for restore.
aws dynamodb list-tablesList DynamoDB tables in the current region.
aws dynamodb scan --table-name usersReturn every item in a table (use sparingly in production).
ps aux | grep postgresConfirm a local postgres process when self-hosting during a lab.
Examples
Query the running RDS instance like a DBA
$ aws rds describe-db-instances \ --db-instance-identifier app-db \ --query "DBInstances[0].{Engine:Engine,Status:DBInstanceStatus,MultiAZ:MultiAZ,Class:DBInstanceClass}" \ --output table------------------------------------------------------------| app-db |+------------------+-----------------------+| Class | db.t3.micro || Engine | postgres || MultiAZ | True || Status | available |+------------------+-----------------------+describe-db-instances returns the operational metadata a DBA checks first: engine, status, instance class and Multi-AZ state. A status of 'available' means the instance is accepting connections; states like 'storage-full' or 'failed' appear here first during incidents.
In production
- Run transactional workloads (orders, auth, financial data) on RDS with Multi-AZ and automated backups.
- Use read replicas to serve reporting and analytics without loading the primary.
- Choose DynamoDB for session state, item metadata and high-throughput event data.
- Keep RDS in private subnets; reach it only from app instances or through a managed endpoint.
- Enforce deletion protection and point-in-time recovery on every production database.
Best practices
- Use managed services (RDS or DynamoDB) instead of self-managed databases on EC2 unless you need full control.
- Enable automated backups, Multi-AZ and deletion protection on production databases.
- Index for your access patterns: relational indexes for joins, DynamoDB partition and sort keys for queries.
- Tune DB instance parameter groups for sane connection and buffer settings.
- Monitor storage, CPU, connections and replica lag; they are the first signals of trouble.
Common mistakes
- Running a database on EC2 without snapshots and then losing data in an instance failure.
- Choosing DynamoDB for relational data and fighting to model joins.
- Skipping Multi-AZ to save money and paying for downtime instead.
- Allowing RDS to sit in a public subnet reachable from the internet.
- Ignoring replica lag and reading stale data from a lagging replica.
Common issues
Database instance state is storage-fullThe EBS volume is full, blocking writes.
Free space, scale the allocated storage, or enable storage autoscaling, then verify the state returns to available.
Cannot connect to RDS from an application instanceThe security group does not allow the app on the DB port, or the DB is in a private subnet with no route.
Allow the app's security group on the DB port and verify the DB is reachable from a host in the same VPC.
DynamoDB requests throttledRead or write capacity was exceeded and the table is in provisioned mode.
Raise capacity, enable autoscaling, or switch to on-demand mode for spiky traffic.
Debugging tips
- Check the DB status and event log first — RDS state transitions explain most availability issues.
- For slow queries, look at the slow query log and index usage before scaling the instance.
- Monitor replica lag in CloudWatch when reads serve stale data.
- Test connectivity with a TCP connection from the app instance before blaming the database.
- Use Performance Insights to find the exact query burning CPU or I/O.
Interview checkpoint
Hands-on lab
- Build a tabular dataset with printf and echo
- Sort and rank records with sort and uniq
- Count and inspect records like query results
- Create a read-only snapshot of the data
Shape, Sort and Back Up Data Like a DBA
25 min · intermediate
Quick quiz
Which RDS feature is designed to offload read traffic?
DynamoDB is a fully managed NoSQL service with single-digit-millisecond latency.
Your RDS primary in one AZ fails. What happens with Multi-AZ enabled?
Cheat sheet
Multi-AZSynchronous standby for high availabilityRead replicaAsync copy for read scalingAutomated backupsDaily snapshot plus transaction logsPoint-in-time recoveryRestore to any second in the windowDeletion protectionBlocks accidental deleteTableCollection of itemsItemA record addressed by a keyPartition keyDetermines where an item is storedOn-demand modeScales capacity automaticallyQuery vs ScanQuery by key; scan reads everything