---
title: "Storage, databases, analytics, and data"
chapter: "06"
---

# Storage, databases, analytics, and data

The first data question is not “Which database?” It is “How will the
data be used, protected, changed, and recovered?”

## Storage

- **S3:** durable object storage for files, logs, backups, and data lakes.
- **EBS:** block volumes for EC2, tied to one AZ.
- **EFS:** shared regional Linux file system.
- **FSx:** managed file systems for Windows, Lustre, NetApp ONTAP, or OpenZFS.
- **AWS Backup:** policy-based backup across supported services.

Use S3 versioning, lifecycle rules, encryption, blocked public access, and
replication only when the recovery or residency requirement needs it.

## Databases

- **RDS/Aurora:** relational transactions and SQL.
- **DynamoDB:** serverless key-value/document access at predictable low latency.
- **ElastiCache:** in-memory cache; do not treat a cache as the only truth.
- **Redshift:** analytical data warehouse.
- **OpenSearch Service:** search, logs, and analytical search.
- **Neptune:** graph relationships.
- **DocumentDB:** document workloads needing MongoDB compatibility.

## Decision questions

What are the access patterns? Do transactions span records? How much data and
traffic? Which consistency is required? What is the RPO/RTO? Can the application
handle retries? Is cross-Region replication necessary? How will schema changes
be deployed?

## Data platform

Land raw data in S3, catalog it with Glue, control access with Lake Formation,
query with Athena or process with EMR/Glue, and warehouse curated analytics in
Redshift when appropriate. Separate operational transactions from analytics so
reports do not hurt customer traffic.

## Common trap

“NoSQL scales better” is not a complete decision. DynamoDB is excellent when
access patterns are known. Relational databases are excellent when relationships,
transactions, and flexible queries matter. Use requirements, not slogans.