AWS storage and database services cover block storage, object storage, file storage, relational databases, NoSQL, and caching.
Block Storage
EC2 Instance Store is temporary local storage. Data may be lost when the instance stops or terminates.
EBS is persistent block storage, commonly attached to EC2 for OS disks and database disks.
Object Storage
S3 is object storage for images, logs, backups, static files, and data lakes.
S3 features:
- High durability
- Object-based storage
- Versioning
- Lifecycle policies
- CloudFront integration
File Storage
EFS is an elastic file system that can be mounted by multiple EC2 instances.
FSx provides managed file systems for specific workloads.
Relational Databases
RDS is a managed relational database service supporting MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and more.
Aurora is AWS's cloud-native relational database compatible with MySQL and PostgreSQL, with stronger performance and scalability.
NoSQL and Caching
DynamoDB is a managed NoSQL key-value/document database for high-concurrency low-latency workloads.
ElastiCache provides Redis or Memcached caching.
DocumentDB is compatible with MongoDB.
Neptune is a graph database for relationship-heavy data.
AWS Backup centralizes backup management.
Deeper Notes
When reviewing this topic, do not memorize names only. Focus on block, object, and file storage plus RDS, DynamoDB, caching, and analytical database choices. If this stays at the definition level, it becomes hard to explain in interviews or apply in projects. A stronger way to study it is to place it in a concrete scenario: who calls it, where the input comes from, what happens on failure, and whether data or state can be processed twice.
- Database choice should start from query shape, write pattern, consistency needs, data size, and operational capability.
- Relational databases fit strong constraints and complex queries; NoSQL fits specific access patterns and scaling needs.
- Indexes, transactions, isolation, backup recovery, and migration strategy often matter more than syntax.
In a real project, use it as a decision framework: identify inputs, constraints, failure modes, and observability before choosing a specific tool or pattern. If a solution looks simple, keep asking whether it still works when scale grows, permissions change, recovery matters, and more people collaborate on it.
Practical Checklist
- Identify where this concept sits in the system: development-time constraint, runtime behavior, infrastructure capability, or collaboration workflow.
- Write one minimal working example and one failure example; only knowing the happy path is usually not enough.
- Record common misuses: edge cases, permission assumptions, performance assumptions, sync/async differences, or environment differences.
- Connect the concept to a project experience so that an interview answer can be grounded in real tradeoffs.
- End with one sentence about tradeoff: what it gives up and what it buys.
Self-Check Questions
- What core problem does this topic solve?
- What alternatives exist, and what are their costs?
- Where are the most likely edge cases?
- How would code, tests, or monitoring prove that it is reliable?
Applied Scenario
Think about an order, user, or content system. Relational databases are good for strongly constrained data such as users, orders, and payments. NoSQL works well for specific access patterns such as cache, sessions, timelines, or key-value configuration. Database design should start by listing main queries: which fields are used, whether pagination is needed, whether transactions are required, how often writes happen, and how historical data is archived.
Common Pitfalls:
- Designing tables or collections before knowing query patterns.
- Overusing JSON fields until querying and constraints become unmanageable.
- Assuming indexes are always free while ignoring write cost.