AWS storage can be grouped by access model: block storage, object storage, and file storage.
Block Storage
Block storage behaves like a disk and suits frequent low-latency updates.
EC2 Instance Store is temporary local storage. It is fast, but data may be lost when the instance stops or terminates.
EBS is persistent block storage, usually attached to one EC2 instance.
EBS snapshots are point-in-time backups:
- Incremental data block backup
- Stored in S3
- Useful for recovery, migration, resizing, and cloning
Object Storage: S3
S3 stores objects. Each object includes data, metadata, and a unique key. S3 does not have real folders; a/b/c.png is just a key that looks like a path.
S3 fits:
- Images and static assets
- Logs
- Backups
- Data lakes
- Large-file archives
S3 Storage Classes
S3 Standard: default, multi-AZ, high availability, frequent access.
S3 Express One Zone: single AZ, low latency, good for reconstructable high-speed data.
S3 Standard-IA: infrequent access with seconds-level retrieval, multi-AZ.
S3 One Zone-IA: cheaper, single AZ, for reconstructable data.
S3 Intelligent-Tiering: automatically moves objects based on access patterns.
S3 Glacier Instant Retrieval: rare access but millisecond retrieval.
S3 Glacier Flexible Retrieval: minutes-to-hours retrieval, good for backup and disaster recovery.
S3 Glacier Deep Archive: lowest cost, usually 12+ hours retrieval, good for long-term compliance retention.
Lifecycle Policies
Lifecycle policies automatically transition storage classes or expire objects.
Example:
- Move to Standard-IA after 30 days
- Move to Glacier after 180 days
- Delete after 7 years
File Storage
EFS is a managed NFS file system that multiple EC2 instances can mount. It scales automatically.
FSx provides managed file systems:
- FSx for Windows
- FSx for Lustre
- FSx for ONTAP
- FSx for OpenZFS
Storage Gateway
Storage Gateway is a hybrid cloud storage service that lets on-premises systems access cloud storage. It is common for backup, archive, disaster recovery, and local cache use cases.
Deeper Notes
When reviewing this topic, do not memorize names only. Focus on S3, EBS, EFS, lifecycle policies, storage classes, and cost/performance/access tradeoffs. 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.
- AWS review should connect services into architecture: entry point, compute, networking, storage, permissions, monitoring, and cost.
- For each service, ask what problem it solves, who operates it, and what the blast radius is when it fails.
- Both exams and real projects care about boundaries: Region vs AZ, managed vs self-managed, stateful vs stateless resources.
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
A practical way to study this topic is to place it inside a small SaaS deployment: users enter through a domain, CloudFront or a load balancer receives traffic, the app runs on EC2, ECS, or Lambda, databases and caches live in private subnets, logs go to CloudWatch, permissions are controlled by IAM, and static assets are stored in S3. For every AWS service, ask where it sits in this chain: entry, compute, network, storage, security, monitoring, or cost control.
Common Pitfalls:
- Memorizing service names without being able to draw the request path.
- Ignoring network boundaries and exposing databases publicly.
- Not estimating cost or failure blast radius.