AWS
Intermediate 16 min read AWS

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.

RDSPostgreSQLMySQLAuroraMulti-AZread replicasnapshotDynamoDBpartition keyon-demand
Introduction

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.

Motivation

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.
Think about it

Mental model

Imagine

A managed bank vault

Think of

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.

Mechanics

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.

Application
RDS primary
Read replica
Automated backups
DynamoDB table
Replicated across AZs
Reference

Key commands

aws rds describe-db-instances

Show engine, status, class and endpoint of every DB instance.

aws rds describe-db-snapshots

List automated and manual snapshots available for restore.

aws dynamodb list-tables

List DynamoDB tables in the current region.

aws dynamodb scan --table-name users

Return every item in a table (use sparingly in production).

ps aux | grep postgres

Confirm a local postgres process when self-hosting during a lab.

Hands-on

Examples

Query the running RDS instance like a DBA

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.

Real world

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.
Guidelines

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.
Watch out

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.
Root cause analysis

Common issues

Error
Database instance state is storage-full
Root cause

The EBS volume is full, blocking writes.

Fix

Free space, scale the allocated storage, or enable storage autoscaling, then verify the state returns to available.

Error
Cannot connect to RDS from an application instance
Root cause

The security group does not allow the app on the DB port, or the DB is in a private subnet with no route.

Fix

Allow the app's security group on the DB port and verify the DB is reachable from a host in the same VPC.

Error
DynamoDB requests throttled
Root cause

Read or write capacity was exceeded and the table is in provisioned mode.

Fix

Raise capacity, enable autoscaling, or switch to on-demand mode for spiky traffic.

When things break

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.
Interviews

Interview checkpoint

Practice

Hands-on lab

Shape, Sort and Back Up Data Like a DBA
25 min · intermediate
In progress
Objectives
  • 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

0/6 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/3
1

Which RDS feature is designed to offload read traffic?

2

DynamoDB is a fully managed NoSQL service with single-digit-millisecond latency.

3

Your RDS primary in one AZ fails. What happens with Multi-AZ enabled?

Quick reference

Cheat sheet

RDS operations
Multi-AZSynchronous standby for high availability
Read replicaAsync copy for read scaling
Automated backupsDaily snapshot plus transaction logs
Point-in-time recoveryRestore to any second in the window
Deletion protectionBlocks accidental delete
DynamoDB essentials
TableCollection of items
ItemA record addressed by a key
Partition keyDetermines where an item is stored
On-demand modeScales capacity automatically
Query vs ScanQuery by key; scan reads everything
Go deeper

Official documentation