Study guide
Technical reference and lesson notes
Purpose of This Lesson
AWS storage questions often present a requirement and expect you to select the correct storage service or configuration. The key decisions include whether storage must be block or file based, whether it is local or shared, how much durability is required, and whether data must remain available after an instance or site failure.
This lesson focuses on practical architecture patterns for Amazon EBS, instance store, Amazon EFS, Amazon FSx for Windows File Server, EBS snapshots, and AWS Storage Gateway.
Key Concepts
Automating EBS Backups with Data Lifecycle Manager
Amazon Data Lifecycle Manager (DLM) can automate the creation, retention, and deletion of EBS snapshots. A lifecycle policy can target volumes or instances using tags and define a schedule such as hourly, daily, or weekly snapshots.
Use DLM when the requirement is a straightforward, fully automated EBS snapshot schedule without building custom automation with Lambda or EventBridge.
Important considerations:
- DLM creates EBS snapshots; it does not provide a complete application-consistent backup strategy by itself.
- Snapshot policies commonly depend on correctly applied resource tags.
- EBS snapshots are incremental after the initial snapshot, although AWS manages the underlying storage details.
- Snapshots are stored in Amazon S3-managed infrastructure, but they are accessed and managed through the EBS service.
Instance Store for Replicated, Performance-Sensitive Data
Instance store provides physically attached block storage with very high performance and low latency. However, it is ephemeral:
- Data is lost when the instance is stopped, hibernated, or terminated, depending on the instance and lifecycle event.
- Instance store volumes cannot be detached and attached to another instance like EBS volumes.
- Instance store data is not a substitute for durable backup storage.
Instance store is appropriate when the application already replicates data across multiple nodes or can reconstruct the data. Examples include distributed caches, temporary processing data, and replicated databases designed to tolerate node loss.
Do not select instance store for data that exists only on one node or that must survive an instance replacement.
Pre-Baking Application Dependencies into an AMI
An Auto Scaling group can launch instances from a custom Amazon Machine Image (AMI) containing:
- Application binaries and configuration
- Runtime dependencies
- Operating system patches and agents
- Required packages and initialization files
This reduces boot-time installation and allows new instances to become service-ready faster. It also makes scaling behavior more predictable than installing all dependencies during instance startup.
A common design combines a golden AMI with user data for environment-specific configuration, secrets retrieval, registration with a service, or other runtime tasks.
Amazon EFS for Shared Linux File Storage
Amazon Elastic File System (EFS) provides a managed, elastic file system for Linux workloads. Multiple EC2 instances can mount the same file system concurrently using NFS.
EFS is a strong choice when the requirements include:
- Shared access from multiple instances
- Elastic capacity that grows and shrinks with stored data
- Regional availability across multiple Availability Zones
- Linux-compatible NFS access
- Removal of the need to provision and manage file servers
For production deployments, mount targets are placed in the Availability Zones from which clients access EFS. Security groups control network access to mount targets, and IAM or EFS file-system policies can provide an additional authorization layer.
Amazon FSx for Windows File Server
Amazon FSx for Windows File Server provides managed Windows file storage using the Server Message Block (SMB) protocol and the NTFS file system. It is suited to applications that require Windows-native file semantics, such as:
- Windows file shares
- Active Directory integration
- NTFS permissions and ACLs
- Existing applications that use SMB paths
- Microsoft workloads requiring managed Windows file servers
EFS and FSx for Windows File Server are not interchangeable merely because both are file systems. The operating system, protocol, identity integration, and file-system semantics determine the correct choice.
Volume Gateway in Stored Volume Mode
AWS Storage Gateway Volume Gateway presents iSCSI block volumes to on-premises servers. In stored volume mode:
- The primary copy of the data remains on premises.
- The gateway asynchronously backs up volume snapshots to Amazon S3.
- The local environment retains low-latency access to the complete working dataset.
- The S3-backed snapshots can support durability and disaster recovery requirements.
This mode is appropriate when on-premises applications need local block storage but the organization also wants cloud-backed snapshot protection.
Stored volume mode differs from cached volume mode. Cached volume mode keeps the primary data in AWS and retains only frequently accessed data locally, while stored volume mode keeps the primary dataset on premises.
Moving EBS Volumes Between Regions
An EBS volume is tied to a specific Availability Zone and cannot be directly moved to another Region. The standard process is:
- Create an EBS snapshot of the source volume.
- Copy the snapshot to the target Region.
- Create a new EBS volume from the copied snapshot in a target Availability Zone.
- Attach the new volume to an EC2 instance in that Availability Zone.
The snapshot copy operation can use a different KMS key in the destination Region when encryption is required. Encrypted snapshot copies require appropriate KMS permissions, and cross-Region transfer incurs data-transfer costs.
Preserving a Root EBS Volume on Instance Termination
The DeleteOnTermination attribute controls whether an attached EBS volume is deleted when its EC2 instance is terminated.
To preserve a root volume for investigation, recovery, or data retention, set DeleteOnTermination to false when launching the instance or modify the instance block device mapping through the AWS CLI or API.
The default behavior often differs between root and additional EBS volumes, so the exam requirement is more important than relying on defaults. Explicitly configure the attribute when preservation is required.
File Gateway for NFS or SMB Access Backed by S3
AWS Storage Gateway File Gateway exposes file shares to on-premises clients through NFS or SMB while storing objects in Amazon S3. It provides a local cache for recently accessed data, reducing the need to retrieve every object from AWS for each access.
Use File Gateway when:
- Existing on-premises applications require file-based access.
- The durable backend should be Amazon S3.
- A local cache is needed for frequently accessed files.
- The organization wants to migrate file data or backups to S3 without rewriting applications immediately.
File Gateway is not the same as Volume Gateway. File Gateway presents file shares and stores objects in S3; Volume Gateway presents iSCSI block volumes and uses S3-backed snapshots.
Exam-Relevant Takeaways
- Choose DLM for automated EBS snapshot lifecycle management.
- Choose instance store only when data is temporary, reproducible, or replicated elsewhere and maximum local performance is important.
- Use a custom AMI to avoid reinstalling application dependencies every time an Auto Scaling group launches an instance.
- Use EFS for shared, elastic Linux file storage accessed through NFS.
- Use FSx for Windows File Server for managed Windows file storage requiring SMB and NTFS.
- Use Volume Gateway in stored mode when on-premises servers need local iSCSI block storage and snapshots should be backed up to AWS.
- Move an EBS volume across Regions by copying its snapshot, then creating a new volume.
- Set
DeleteOnTermination=falsewhen an EBS root volume must survive instance termination. - Use File Gateway when on-premises NFS or SMB clients need an S3-backed file interface with local caching.
Architecture Decision Guide
| Requirement | Recommended choice | Why |
|---|---|---|
| Automated EBS snapshot schedule and retention | Data Lifecycle Manager | Managed lifecycle policies for EBS snapshots |
| Very high-performance local storage for replicated data | EC2 instance store | Local, low-latency storage without a durability requirement for each node |
| Fast Auto Scaling instance startup with dependencies installed | Custom AMI | Packages and application code are included in the image |
| Shared elastic file system for Linux instances | Amazon EFS | Managed NFS file system with elastic capacity |
| Managed Windows file share using NTFS and SMB | FSx for Windows File Server | Windows-native file semantics and protocol support |
| On-premises local block storage with S3-backed snapshots | Volume Gateway, stored volume mode | Complete working data remains local; snapshots are stored in AWS |
| On-premises file access with S3 as the durable backend | File Gateway | NFS/SMB shares, S3 object storage, and local cache |
| EBS data required in another Region | EBS snapshot copy | Recreate the volume in the destination Region |
| Root volume must remain after EC2 termination | DeleteOnTermination=false | Prevents automatic deletion of the volume |
Common Exam Traps
- Selecting EBS for shared multi-instance access: Standard EBS volumes are attached to a single EC2 instance at a time. If multiple Linux instances need shared file access, evaluate EFS instead.
- Treating instance store as durable storage: Replication may make instance store appropriate for a node, but instance store itself is still ephemeral.
- Confusing EFS and FSx for Windows File Server: EFS is NFS-oriented Linux file storage; FSx for Windows File Server provides SMB and NTFS capabilities.
- Confusing File Gateway and Volume Gateway: File Gateway exposes file shares backed by S3. Volume Gateway exposes iSCSI block volumes and creates S3-backed snapshots.
- Using cached volume mode when local data is authoritative: Cached mode makes AWS the primary location. Stored mode keeps the primary dataset on premises.
- Assuming an EBS volume can be directly attached in another Region: The volume must be represented by a snapshot copy and recreated in the destination Region.
- Relying on default termination behavior: Configure
DeleteOnTerminationexplicitly when the requirement says a volume must survive termination. - Using startup scripts for everything: User data is useful for dynamic configuration, but installing large dependency sets at every launch can slow scaling and create inconsistent instances.
Real-World Engineer Notes
- Use an AMI pipeline to build, test, patch, and version golden images rather than manually creating one-off images.
- For replicated applications using instance store, verify the replication protocol, quorum behavior, rebuild time, and failure handling before accepting ephemeral storage.
- EBS snapshots are crash-consistent at the volume level. Applications requiring transactional consistency across multiple volumes may need application-aware quiescing or coordinated backup procedures.
- For EFS, design network access deliberately: mount targets, routing, security groups, DNS resolution, and NFS port access must all work from the client subnets.
- For FSx for Windows File Server, plan Active Directory connectivity and permissions as part of the architecture, not as a later configuration step.
- Storage Gateway appliances require reliable connectivity and sufficient local cache or buffer capacity. They are not a replacement for planning bandwidth, recovery time, and offline behavior.
- Cross-Region snapshot copies should be evaluated for encryption keys, transfer duration, operational automation, and cross-Region data-transfer cost.
Quick Reference Summary
- EBS: Durable block storage for EC2; snapshots support backup and migration workflows.
- DLM: Automates EBS snapshot schedules and retention.
- Instance store: Fast local ephemeral storage; use only when data can be recreated or is replicated.
- Custom AMI: Speeds Auto Scaling launches by preinstalling software.
- EFS: Elastic shared NFS storage for Linux workloads.
- FSx for Windows File Server: Managed SMB/NTFS storage for Windows workloads.
- Volume Gateway—stored mode: Local iSCSI block storage with S3-backed snapshots.
- File Gateway: NFS/SMB file shares using S3 as the durable backend and a local cache.
- Cross-Region EBS migration: Snapshot, copy snapshot, create a volume, attach it.
- Termination preservation: Set
DeleteOnTerminationtofalse.
Flashcards
- Q: Which AWS service automates EBS snapshot schedules and retention?
A: Amazon Data Lifecycle Manager.
- Q: When is instance store a reasonable choice for application data?
A: When the data is temporary, reproducible, or replicated across nodes and high local performance is required.
- Q: What is the main durability limitation of instance store?
A: It is ephemeral and data can be lost when the instance is stopped or terminated, depending on the lifecycle event.
- Q: How can an Auto Scaling group launch application-ready instances faster?
A: Use a custom AMI containing the application dependencies and code.
- Q: Which service provides elastic shared NFS storage for Linux EC2 instances?
A: Amazon EFS.
- Q: Which AWS managed file service uses SMB and NTFS?
A: Amazon FSx for Windows File Server.
- Q: Which Storage Gateway mode keeps the primary dataset on premises and backs it up to S3?
A: Volume Gateway in stored volume mode.
- Q: Which Storage Gateway type presents NFS or SMB shares backed by S3?
A: File Gateway.
- Q: How do you move an EBS volume to another Region?
A: Create a snapshot, copy it to the target Region, and create a new volume from the copied snapshot.
- Q: Which EBS setting preserves a volume after EC2 termination?
A: Set DeleteOnTermination to false.
- Q: What is the key difference between stored and cached Volume Gateway modes?
A: Stored mode keeps the primary data on premises; cached mode keeps the primary data in AWS and retains a local cache.
- Q: Why might an AMI be preferred over installing packages in user data?
A: It reduces launch time and improves consistency during Auto Scaling events.
Practice Questions
Question 1
A company runs a distributed application across several EC2 instances. Each node maintains a synchronized copy of the data. The application requires the lowest possible storage latency, and data loss on an individual node is acceptable because another node can recover it. Which storage option is most appropriate?
A. Amazon EFS
B. Amazon EBS gp3 volumes
C. EC2 instance store
D. Amazon S3 mounted through File Gateway
Correct answer: C. EC2 instance store
Explanation: Instance store provides very high-performance local storage and is suitable when the application replicates data across nodes. EFS and File Gateway introduce file-system or network access patterns that do not meet the stated lowest-latency requirement. EBS is durable but is not the best fit when the data is intentionally node-local and replicated elsewhere.
Question 2
An organization needs a shared file system mounted by many Linux EC2 instances in an Auto Scaling group. Capacity must expand automatically as the amount of data grows. Which service should the architect recommend?
A. Amazon FSx for Windows File Server
B. Amazon EFS
C. Instance store
D. A single EBS volume attached to the Auto Scaling group
Correct answer: B. Amazon EFS
Explanation: EFS provides managed, elastic, shared file storage for Linux clients through NFS. FSx for Windows File Server is intended for SMB and NTFS-based Windows file workloads. Instance store is local to individual instances, and a standard EBS volume is not a general-purpose shared file system for an Auto Scaling group.
Question 3
On-premises database servers require local iSCSI block storage. The organization wants the primary working dataset to remain on premises but requires automated snapshots stored in AWS for backup and recovery. Which solution meets these requirements?
A. File Gateway
B. Volume Gateway in cached volume mode
C. Volume Gateway in stored volume mode
D. Amazon EFS mounted through a VPN
Correct answer: C. Volume Gateway in stored volume mode
Explanation: Stored volume mode keeps the primary data on premises and asynchronously backs up volume snapshots to Amazon S3. File Gateway provides file shares rather than iSCSI block volumes. Cached volume mode makes AWS the primary storage location, which conflicts with the requirement.
Question 4
A critical EC2 application uses a root EBS volume containing diagnostic data that must remain available after the instance is terminated. What should the architect configure?
A. Enable EBS Multi-Attach
B. Set DeleteOnTermination to false
C. Convert the volume to instance store
D. Create an EFS mount target
Correct answer: B. Set DeleteOnTermination to false
Explanation: The DeleteOnTermination block device mapping attribute controls whether an EBS volume is deleted with its instance. Setting it to false preserves the volume after termination. The other options do not address the required lifecycle behavior.
Question 5
A file server running on premises exposes NFS shares. The company wants the durable data stored in Amazon S3 while retaining a local cache for frequently accessed files. Which service should be used?
A. Volume Gateway in stored mode
B. File Gateway
C. Amazon EBS snapshots
D. Amazon FSx for Windows File Server
Correct answer: B. File Gateway
Explanation: File Gateway provides NFS or SMB file shares, stores the durable backend data as S3 objects, and maintains a local cache. Volume Gateway provides block storage through iSCSI rather than file shares.