Study guide
Technical reference and lesson notes
Purpose of This Lesson
Amazon EC2 supports both network-attached Amazon Elastic Block Store (EBS) volumes and locally attached instance store volumes. The key design decision is whether an application needs durable, independently managed storage or extremely fast temporary storage located on the physical host running the instance.
This distinction is especially important in SAP-C02 questions involving persistence, host failure, caching, scratch space, and instance lifecycle operations.
Key Concepts
What Is an EC2 Instance Store Volume?
An instance store volume is local block storage physically attached to the underlying host server on which an EC2 instance runs. Because the storage is local rather than reached over the network, it can provide very high performance and low latency.
However, the storage is tied to that particular EC2 instance and host. It is not an independent storage resource that can be moved between instances.
Instance Store Versus EBS
| Characteristic | Instance Store | Amazon EBS |
|---|---|---|
| Physical location | Local to the EC2 host | Network-attached to the instance |
| Performance | Very high local performance | Depends on the selected EBS volume type and configuration |
| Persistence | Ephemeral | Persistent independently of the instance host |
| Host failure behavior | Data can be lost | Data remains available for reattachment, subject to configuration and failure scope |
| Detach and reattach | Not supported | Supported |
| Typical use | Cache, buffer, scratch data, replicated working data | Operating systems, databases, durable application data |
| Root volume behavior | An instance-store root cannot be stopped; it can be rebooted | EBS-backed instances support normal stop and start operations |
Ephemeral Storage and Instance Lifecycle
Instance store data is not durable. It can be lost when the instance is stopped or terminated, or when the underlying host encounters a failure. A host failure can therefore destroy data even if the EC2 instance itself was not intentionally stopped.
A reboot is different from a stop operation. Rebooting the operating system generally keeps the instance on the same host, so instance store contents can remain available. This should not be treated as a durability guarantee; applications must always be able to rebuild or replace the data.
If the root device is an instance store volume, the instance cannot be stopped. It can be rebooted, but a stop operation is not available because stopping would discard the root volume and its contents.
Instance Store Root Devices
For instances using an instance-store root device, the root volume is created from an AMI template stored in Amazon S3. This is different from the common EBS-backed model, where the root volume is an EBS volume created from an EBS snapshot.
Suitable Workloads
Instance store is appropriate when the data is disposable, reproducible, or replicated elsewhere. Examples include:
- Application and web caches
- Temporary buffers and queues whose contents can be regenerated or replayed
- Scratch space for data processing
- Temporary files and intermediate computation results
- Working data replicated across multiple EC2 instances
- High-performance local data that is not the system of record
It is generally unsuitable for a standalone database or any workload that requires data to survive an EC2 host failure unless the application provides an independent replication and recovery mechanism.
Exam-Relevant Takeaways
- Instance store is local and ephemeral. Its performance advantage comes with a significant durability tradeoff.
- EBS is network-attached and persistent. It is the normal choice for durable operating-system and application data.
- An instance-store volume cannot be detached and attached to another EC2 instance, or detached and reattached to the same instance.
- A host failure can result in permanent loss of instance store data.
- An instance with an instance-store root device cannot be stopped; it can only be rebooted.
- Use instance store for disposable or replicated data, not as the only copy of important information.
- If an application uses instance store for performance, the architecture must provide recovery through replication, reconstruction, or another durable data source.
Architecture Decision Guide
| Requirement | Recommended choice | Reason |
|---|---|---|
| Durable boot volume | EBS-backed EC2 instance | Supports persistence and normal stop/start lifecycle operations |
| Durable database files | EBS or another appropriate durable storage service | Data must survive host and instance lifecycle events |
| Very fast temporary workspace | Instance store | Local storage provides high performance and low latency |
| Cache that can be rebuilt | Instance store | Losing the cache does not cause permanent data loss |
| Data replicated by the application across hosts | Instance store may be suitable | The application maintains multiple copies and can recreate a failed node |
| Storage that must move to another instance | EBS | EBS volumes can be detached and reattached |
| Data that must survive host failure without application replication | EBS or another durable service | Instance store alone does not provide the required durability |
Common Exam Traps
- Confusing local with durable: Local placement does not mean persistent storage. Instance store data can disappear during a host failure.
- Assuming all EC2 storage is detachable: Instance store volumes are tied to the instance and host and cannot be moved like EBS volumes.
- Treating reboot and stop as equivalent: A reboot is not the same lifecycle event as stopping an instance. An instance-store root volume prevents stopping altogether.
- Using instance store for the only database copy: High performance does not compensate for the absence of persistence.
- Ignoring application recovery: Instance store can be valid for important working data only when the application can rebuild or replicate it.
- Selecting EBS solely because it is persistent: If the requirement is disposable, host-local scratch space with maximum performance, instance store may be the better fit.
Real-World Engineer Notes
- Design instance-store workloads as replaceable nodes. A replacement instance should be able to initialize its local data automatically.
- Keep the authoritative copy in a durable system such as EBS, Amazon S3, or a managed database, depending on the workload.
- For caches, plan for cold-start behavior after a replacement instance launches. The application should tolerate an empty cache.
- For replicated systems, verify that losing one node does not lose quorum or the only current copy of data.
- Check the selected EC2 instance type carefully. Instance-store availability and capacity vary by instance family; not every instance type provides local instance-store volumes.
- Treat host failure as an expected event in the design, not as an exceptional condition that can be ignored.
Quick Reference Summary
- Instance store: physically local, very fast, ephemeral, non-detachable.
- EBS: network-attached, persistent, detachable, and reattachable.
- Use instance store for cache, scratch, buffer, and replicated temporary data.
- Do not use it as the sole location for durable or irreplaceable data.
- An instance-store root device is created from an AMI stored in Amazon S3.
- An instance with an instance-store root cannot be stopped; reboot is supported.
Flashcards
- Q: Where is an EC2 instance store volume physically located?
A: On the host server running the EC2 instance.
- Q: What is the primary durability characteristic of instance store?
A: It is ephemeral; data can be lost when the instance is stopped or terminated or when the host fails.
- Q: Why can instance store provide high performance?
A: It is local to the EC2 host and does not require network access to a separate storage system.
- Q: Can an instance store volume be detached and attached to another EC2 instance?
A: No. Instance store volumes cannot be detached and reattached.
- Q: What storage type is normally selected for durable EC2 boot data?
A: An EBS-backed root volume.
- Q: Can an EC2 instance with an instance-store root device be stopped?
A: No. It can be rebooted, but it cannot be stopped.
- Q: What happens to instance-store data if the underlying host fails?
A: The data can be permanently lost.
- Q: Name three suitable uses for instance store.
A: Caches, scratch space, and temporary buffers; replicated working data is another example.
- Q: What must an application do if it relies on instance store?
A: It must be able to rebuild, replicate, or otherwise recover its data independently of the local volume.
- Q: How are instance-store root devices created?
A: From AMI templates stored in Amazon S3.
- Q: What is the main architectural difference between EBS and instance store?
A: EBS is network-attached and persistent, while instance store is host-local and ephemeral.
- Q: Is instance store appropriate for the only copy of critical database data?
A: No. A host failure could destroy that data.
Practice Questions
Question 1
A high-throughput image-processing application uses EC2 instances to create large intermediate files. The files are needed only while a job is running and can be regenerated from the original images stored durably elsewhere. Which storage option best meets the requirements?
A. Instance store volumes attached to the processing instances
B. An EBS volume as the only processing workspace
C. An instance-store volume as the durable source of original images
D. A detachable EBS volume shared across all processing instances
Correct answer: A
Explanation: The intermediate files are temporary and reproducible, while the original data is stored elsewhere. Instance store provides high-performance local workspace without requiring durability for disposable data.
Question 2
A company runs a database on an EC2 instance and requires the database files to survive failure of the underlying physical host. Which change is most appropriate?
A. Move the database files to instance store for lower latency
B. Store the database files on EBS and implement an appropriate backup and recovery strategy
C. Keep the files on instance store and disable instance reboots
D. Store the files on the instance-store root volume and create a larger AMI
Correct answer: B
Explanation: Instance store data can be lost during host failure. EBS provides persistent block storage that can remain available for recovery or reattachment, although backups and application-level recovery are still required.
Question 3
An architect selects an EC2 AMI with an instance-store root device. During operations testing, the team attempts to stop the instance before applying a configuration change. What should the architect explain?
A. The instance can be stopped, but all EBS volumes will be deleted
B. The instance cannot be rebooted, but it can be stopped
C. The instance-store root prevents stopping; the instance can be rebooted instead
D. The instance can be stopped only after detaching the root volume
Correct answer: C
Explanation: An instance-store root volume is ephemeral and cannot support the normal stop operation. The instance can be rebooted, but stopping it would discard the root device.
Question 4
A distributed application keeps multiple synchronized copies of its working set across several EC2 instances. The working set must have very low latency, and a failed node can reconstruct its copy from another node. Which storage choice is most suitable for the working set?
A. Instance store
B. An EBS volume attached to only one instance
C. An EBS volume used as the only source of truth without backups
D. An instance-store volume with no replication or rebuild process
Correct answer: A
Explanation: Local instance store is suitable for high-performance working data when the application already provides replication and can rebuild a node after local data loss.
Question 5
A team needs to move a block volume from one EC2 instance to another during maintenance. Which statement is correct?
A. Instance store is preferred because it can be detached without downtime
B. Instance store can be detached and reattached only within the same Availability Zone
C. EBS is appropriate because its volumes can be detached and reattached
D. Both storage types support identical detach and attach operations
Correct answer: C
Explanation: EBS volumes are independent storage resources that can generally be detached and reattached, subject to service and Availability Zone constraints. Instance store volumes are tied to the instance host and cannot be moved.