Databases

First PublishedFeb 16, 2026ByAtif Alam

AWS offers managed database services that handle provisioning, patching, backups, and replication — letting you focus on your application instead of database administration.

RDS (Relational Database Service)

RDS runs managed relational databases. AWS handles the underlying infrastructure; you interact with it like a normal database.

Supported Engines

Engine	Notes
PostgreSQL	Open-source, feature-rich, widely used
MySQL	Open-source, popular for web apps
MariaDB	MySQL fork, community-driven
Oracle	Enterprise, bring-your-own-license or license-included
SQL Server	Microsoft, license-included or BYOL
Aurora	AWS-built, MySQL/PostgreSQL-compatible, higher performance

What RDS Manages for You

Task	Self-managed (EC2)	RDS
OS patching	You	AWS
Database installation	You	AWS
Automated backups	You	AWS (daily snapshots, transaction logs)
Multi-AZ failover	You	AWS (automatic)
Read replicas	You	AWS (one-click)
Monitoring	You	CloudWatch integration
Encryption at rest	You	One checkbox

Creating an RDS Instance

aws rds create-db-instance \
  --db-instance-identifier my-postgres \
  --db-instance-class db.t3.medium \
  --engine postgres \
  --engine-version 16.1 \
  --master-username admin \
  --master-user-password 'SecureP@ss123!' \
  --allocated-storage 100 \
  --storage-type gp3 \
  --vpc-security-group-ids sg-db \
  --db-subnet-group-name my-db-subnets \
  --multi-az \
  --backup-retention-period 7 \
  --storage-encrypted

Instance Classes

Class	Type	Use Case
db.t3.* / db.t4g.*	Burstable	Dev/test, small workloads
db.m5.* / db.m6g.*	General purpose	Production web apps
db.r5.* / db.r6g.*	Memory-optimized	Large datasets, caching
db.x2g.*	Memory-intensive	SAP HANA, in-memory analytics

Multi-AZ Deployments

Multi-AZ creates a standby replica in a different AZ. If the primary fails, RDS automatically fails over to the standby — typically within 60–120 seconds.

               Write/Read                     Sync replication
Client ──────► Primary (AZ-a) ──────────────► Standby (AZ-b)
                                               (not accessible until failover)

• Synchronous replication — zero data loss on failover.
• Automatic failover — RDS updates the DNS endpoint; your app reconnects automatically.
• Not a read replica — the standby doesn’t serve read traffic (use read replicas for that).

Read Replicas

Read replicas offload read traffic from the primary. They use asynchronous replication — there’s a small lag.

               Write               Read
Client ──────► Primary ──────────► Read Replica 1 (same region)
                    │──────────► Read Replica 2 (same region)
                    └──────────► Read Replica 3 (cross-region)

Feature	Multi-AZ	Read Replica
Purpose	High availability (failover)	Read scaling
Replication	Synchronous	Asynchronous
Accessible for reads?	No (standby only)	Yes
Cross-region?	No	Yes
Can be promoted?	Auto (on failure)	Manual (becomes standalone DB)

Backups and Snapshots

Feature	Automated Backups	Manual Snapshots
Schedule	Daily (configurable window)	On-demand
Retention	1–35 days	Indefinite (until you delete)
Point-in-time restore	Yes (any second within retention)	To the snapshot time only
Cross-region copy	Yes	Yes

RDS Security

• Network: Place in a private subnet. Only allow app security groups to connect.
• Encryption at rest: Enable with KMS (cannot enable after creation — must be set at launch).
• Encryption in transit: Use SSL/TLS connections (enforce with rds.force_ssl parameter).
• IAM authentication: Use IAM roles instead of passwords (supported for MySQL and PostgreSQL).

Aurora

Amazon Aurora is an AWS-built relational database that’s compatible with MySQL and PostgreSQL but offers higher performance and better availability.

Aurora vs Standard RDS

Feature	RDS (PostgreSQL/MySQL)	Aurora
Performance	Standard	Up to 5x MySQL, 3x PostgreSQL
Storage	EBS (fixed, up to 64 TB)	Auto-scaling (up to 128 TB), 6-way replicated
Replicas	Up to 5 read replicas	Up to 15 read replicas (faster failover)
Failover	60–120 seconds	~30 seconds
Cost	Lower	~20% more than RDS

Aurora Serverless

Aurora Serverless automatically scales capacity up and down based on demand — ideal for variable or unpredictable workloads:

No traffic ──► Scales to 0 ACUs (paused) ──► Traffic arrives ──► Scales up

• Pay per ACU-second (Aurora Capacity Unit). Minimum 0.5 ACU for v2.
• Good for: Dev/test, infrequent workloads, new apps with unknown traffic patterns.
• Not ideal for: Steady high-traffic production (standard Aurora is cheaper).

DynamoDB

DynamoDB is a fully managed NoSQL key-value and document database. It’s designed for single-digit millisecond latency at any scale.

Core Concepts

┌──────────────────────────────────────────────┐
│  Table: Orders                                │
│                                               │
│  Partition Key (PK)  Sort Key (SK)   Attrs    │
│  ─────────────────   ──────────────  ─────    │
│  user_123            order_2026-001  {amt: 50}│
│  user_123            order_2026-002  {amt: 30}│
│  user_456            order_2026-001  {amt: 99}│
└──────────────────────────────────────────────┘

Concept	What It Is
Table	A collection of items (like a relational table, but schema-less)
Item	A single record (like a row). Max 400 KB.
Attribute	A field on an item (like a column). No fixed schema — items can have different attributes.
Partition key (PK)	The primary key that determines which partition stores the item. Must distribute evenly.
Sort key (SK)	Optional. Combined with PK to form a composite primary key. Enables range queries.
GSI (Global Secondary Index)	An alternate key structure for querying by different attributes. Separate throughput.
LSI (Local Secondary Index)	Same partition key, different sort key. Must be defined at table creation.

Basic Operations

# Create a table
aws dynamodb create-table \
  --table-name Orders \
  --attribute-definitions \
    AttributeName=user_id,AttributeType=S \
    AttributeName=order_id,AttributeType=S \
  --key-schema \
    AttributeName=user_id,KeyType=HASH \
    AttributeName=order_id,KeyType=RANGE \
  --billing-mode PAY_PER_REQUEST

# Put an item
aws dynamodb put-item --table-name Orders --item '{
  "user_id": {"S": "user_123"},
  "order_id": {"S": "order_2026-001"},
  "amount": {"N": "49.99"},
  "status": {"S": "shipped"}
}'

# Get an item (by exact key)
aws dynamodb get-item --table-name Orders --key '{
  "user_id": {"S": "user_123"},
  "order_id": {"S": "order_2026-001"}
}'

# Query (all orders for a user)
aws dynamodb query --table-name Orders \
  --key-condition-expression "user_id = :uid" \
  --expression-attribute-values '{":uid": {"S": "user_123"}}'

Capacity Modes

Mode	How It Works	Best For
On-demand	Pay per request. No capacity planning.	Unpredictable traffic, new tables
Provisioned	Set read/write capacity units (RCUs/WCUs). Can auto-scale.	Predictable traffic (cheaper at scale)

DynamoDB Streams

Streams capture a time-ordered sequence of item changes (insert, update, delete). Use them to:

• Trigger Lambda functions on data changes (event-driven architecture).
• Replicate data to another table, Elasticsearch, or S3.
• Build audit logs of all changes.

Single-Table Design

DynamoDB’s best practice is to store multiple entity types in a single table using overloaded partition and sort keys:

PK              SK                  Attributes
USER#123        PROFILE             {name: "Alice", email: "..."}
USER#123        ORDER#2026-001      {amount: 50, status: "shipped"}
USER#123        ORDER#2026-002      {amount: 30, status: "pending"}
PRODUCT#abc     METADATA            {name: "Widget", price: 9.99}
PRODUCT#abc     REVIEW#user_123     {rating: 5, text: "Great!"}

This enables efficient queries with a single table — “get user profile + all orders” is one Query call.

RDS vs DynamoDB

	RDS	DynamoDB
Model	Relational (SQL)	Key-value / document (NoSQL)
Schema	Fixed schema (ALTER TABLE)	Flexible (no schema enforcement)
Queries	Any SQL query (JOINs, aggregations)	Key lookups and range queries only
Scaling	Vertical (bigger instance) + read replicas	Horizontal (automatic partitioning)
Latency	Low milliseconds	Single-digit milliseconds
Best for	Complex queries, transactions, relationships	High-throughput, simple access patterns, serverless
Pricing	Per instance-hour	Per request or provisioned capacity

When to Use Which

Scenario	Choose
Complex SQL queries, JOINs, reporting	RDS (or Aurora)
Simple key-value lookups at massive scale	DynamoDB
Relational data with ACID transactions	RDS
Serverless app (Lambda + API Gateway)	DynamoDB (native integration, pay-per-request)
Unknown or rapidly changing schema	DynamoDB
Time-series data with simple queries	DynamoDB (or Timestream)

Other AWS Database Services

Service	Type	Use Case
ElastiCache	In-memory (Redis/Memcached)	Caching, session storage, leaderboards
Neptune	Graph database	Social networks, fraud detection, knowledge graphs
Timestream	Time-series	IoT, application metrics, DevOps monitoring
DocumentDB	MongoDB-compatible	Document workloads, MongoDB migration
Keyspaces	Cassandra-compatible	Wide-column, high-throughput
Redshift	Data warehouse	Analytics, BI, large-scale SQL queries

Key Takeaways

• RDS manages relational databases (PostgreSQL, MySQL, Aurora). Use Multi-AZ for HA, read replicas for scale.
• Aurora is AWS’s high-performance relational engine — faster than standard RDS, auto-scaling storage, more replicas.
• DynamoDB is a NoSQL key-value store with single-digit ms latency. Design around access patterns, not relationships.
• Use on-demand capacity for unpredictable workloads, provisioned for steady traffic.
• Always encrypt at rest, place databases in private subnets, and restrict access via security groups.