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.