Skip to main content
Welcome, future solutions architects — Michael Forrester here. This lesson focuses on designing secure storage architectures for AWS, covering block storage (virtual disks attached to EC2) and shared file storage. You’ll get practical controls, patterns, and hardening steps for EBS, instance store, EFS, and the FSx family. Table of contents
  • Block storage: EBS, instance store, snapshots, and backups
  • File storage: EFS and Amazon FSx (Windows, Lustre, OpenZFS, NetApp ONTAP)
  • Practical hardening checklist and summary
  • References
Block storage: EBS, instance store, snapshots, and backups The diagram below provides a high-level view: EBS volumes live in Availability Zones; snapshots are stored in S3; backups and cross-region copies are commonly orchestrated by AWS Backup. RDS snapshot/backup flows are similar.
An AWS Cloud architecture diagram showing two Regions with VPCs and Availability Zones. It illustrates backup/restore and cross-region data flows between services like EBS, RDS, S3 and AWS Backup.
EBS overview and encryption EBS volumes are virtual block storage devices that attach to EC2 instances within the same Availability Zone. Volume types vary (magnetic, throughput-optimized, GP2/GP3, io1/io2, Block Express, etc.), but the primary security control for most workloads is encryption. Key encryption and security points for EBS:
  • Enable encryption when creating a new volume (recommended).
  • EBS encryption uses AWS KMS; choose either the AWS-managed key or a customer-managed key (CMK).
  • Snapshots of encrypted volumes remain encrypted.
  • To encrypt an existing unencrypted volume: create a snapshot → copy the snapshot while enabling encryption (choose a KMS key) → create a new encrypted volume from the copied snapshot.
  • When EBS encryption is enabled, data at rest and data in transit between the volume and the attached instance are encrypted.
When creating volumes in the AWS console or API, you configure the volume type, size, IOPS, Availability Zone, and whether to enable encryption and which KMS key to use. The example below shows the create-volume form with the encryption checkbox and Master Key selection.
Screenshot of an AWS "Create Volume" form showing fields for volume type, size, IOPS, availability zone and snapshot ID, with the encryption checkbox and Master Key dropdown highlighted in red.
EBS encryption — quick reference table EBS quiz: ensuring data is encrypted at rest Scenario: A company migrates a sensitive database to EC2 and plans to use EBS for storage. They want the data encrypted at rest. Which approach should they use?
  • Correct: Create the EBS volume with encryption enabled (use the default AWS key or a customer-managed KMS key). For existing unencrypted volumes: snapshot → copy the snapshot enabling encryption → create the new encrypted volume.
When converting existing unencrypted EBS data, you cannot flip the encryption flag in-place. Use the snapshot → copy (enable encryption) → create new volume workflow and select a KMS key during the snapshot copy step.
EBS snapshots and encryption To ensure snapshots are encrypted even if the original volume was unencrypted, use the snapshot-copy workflow and specify a KMS key during the copy operation. The copied snapshot can be encrypted and used to create encrypted volumes. This approach is suitable for migration, regulatory compliance, and key-rotation strategies.
An infographic-style screenshot of an AWS exam question about ensuring EBS snapshots are encrypted for a financial institution. It shows four numbered answer options suggesting approaches like only snapshotting encrypted volumes, using AWS KMS to encrypt snapshots, specifying a KMS key when creating snapshots, or storing snapshots in an encrypted S3 bucket.
Practical note: aside from encryption, AWS manages many EBS service-level aspects; there are few additional knobs. For extra assurance you can add application-level (client-side) encryption, but enabling EBS encryption with KMS is the common best practice. EC2 instance store (ephemeral) volumes Instance store is physically attached storage local to the EC2 host. It offers very low latency and high IOPS, but it is ephemeral: if the instance stops, terminates, or the underlying host fails, instance store data is lost. It is typically provided at no additional cost on certain instance types and is not automatically backed up by AWS. Key considerations:
  • Instance store is ephemeral and non-persistent.
  • No AWS-managed snapshot/backup capability for instance store.
  • Cannot resize instance store volumes.
  • No AWS-managed encryption toggle — implement encryption at the application or OS level if needed.
Instance store is suitable only for ephemeral/scratch workloads (caches, temporary processing). Do not use instance store for any data you cannot afford to lose unless you implement your own replication and backup mechanisms.
Instance store quiz: choosing the correct statement Scenario: A gaming company considers EC2 instance store for low-latency, high-IOPS storage. Which statement is correct?
  • Correct: Instance store volumes are ephemeral — data can be lost if the instance stops, terminates, or fails.
An infographic-style quiz asking which considerations apply when a gaming company uses AWS EC2 instance store volumes for low-latency, high-IOPS storage. It shows a scenario description and four numbered answer options, including that instance store volumes are ephemeral and data can be lost if an instance stops or is terminated.
File storage: EFS and the FSx family Moving from block to file-level storage, shared file systems operate over the network and provide multi-client access, different protocols, and feature sets for collaboration, HPC, and Windows workloads. Amazon EFS (Elastic File System) EFS is a managed NFS file system that can be mounted concurrently by many EC2 instances across Availability Zones. It’s regional (spans AZs within a region) and automatically replicates data across AZs for resilience. EFS security and operational highlights:
  • Network file system (NFS) — not block-level storage.
  • Regional service with cross-AZ replication for high availability/durability.
  • Lifecycle management: move infrequently accessed files to EFS Infrequent Access (EFS-IA) to reduce costs.
  • Encryption at rest and in transit (TLS) are available; enable encryption at file system creation.
  • Multiple performance and throughput modes to tune latency and throughput.
EFS quiz: suitability for media editing Scenario: A media production company needs shared, scalable, low-latency file storage for concurrent video editing. Which statements apply?
  • Correct: EFS is regional and replicates across AZs for availability and durability. With appropriate performance settings, EFS supports low-latency concurrent access over NFS and is suitable for collaborative media workflows.
EFS Infrequent Access (EFS-IA) EFS-IA is a lower-cost storage class inside a single EFS file system. Lifecycle policies automatically move files between Standard and IA classes based on access patterns — no separate file system or manual synchronization needed. Access to IA files can still provide reasonable performance, but plan for potential cold-read characteristics. Important: To enable encryption at rest for an existing unencrypted EFS, create a new encrypted file system and copy data across.
A slide showing a multiple-choice question about using Amazon EFS Infrequent Access (EFS IA), including a short scenario and four numbered answer options describing EFS IA characteristics and trade-offs.
Amazon FSx family (Windows, Lustre, OpenZFS, NetApp ONTAP) Amazon FSx provides fully managed file systems optimized for different workloads and protocols. Engines vary by use case, but most integrate with VPCs and KMS for encryption, and many have encryption-at-rest enabled or easily configurable. High-level FSx engines and their primary use cases:
An AWS architecture diagram showing Amazon FSx file systems in two regions (N. Virginia and Oregon) inside VPCs, connected via VPC peering. AWS DataSync agents replicate between the file systems, with a note that encryption in transit and at rest is enabled by default.
FSx for Windows File Server
  • Native Windows file system using the SMB protocol.
  • Integrates with AWS Managed Microsoft AD for authentication and permissions.
  • Supports encryption at rest (KMS) and SMB in-transit options.
  • AWS handles OS-level maintenance, patching, and management as a managed service.
FSx for Windows quiz: security features Scenario: A multinational corp wants a managed Windows file system integrated with Active Directory. Which describes FSx for Windows File Server properly?
  • Correct: FSx for Windows integrates with AWS Managed Microsoft AD, supports in-transit encryption options, and offers KMS-based data-at-rest encryption. AWS handles maintenance and patching.
FSx for Lustre FSx for Lustre targets HPC and data-intensive workloads. It can optionally link to Amazon S3 to provide fast access to object data. It supports encryption at rest (KMS) and VPC-based access controls.
A flow diagram for Amazon FSx for Lustre showing creating a file system, optionally linking it to Amazon S3, and accessing it from EC2, ECS/EKS, or on‑premises clients. It also shows running workloads with services like Amazon SageMaker, AWS ParallelCluster/AWS Batch, and Nimble Studio.
FSx for Lustre quiz: encryption and security Scenario: A research institution considers FSx for Lustre for HPC and needs data protection. Which statement is accurate?
  • Correct: FSx for Lustre supports encryption at rest (KMS) and can use customer-managed keys. It integrates with VPC access controls and provides options suitable for secured HPC workloads.
FSx for OpenZFS FSx for OpenZFS brings OpenZFS features (snapshots, clones, volumes) in a managed service. It supports encryption at rest, integrates with VPC networking, and can use AWS Backup for cross-account and cross-region protection.
An infographic slide asking which statement best aligns with Amazon FSx for OpenZFS security (encryption at rest and in transit, plus Amazon VPC access control). Four numbered multiple-choice options about encryption and VPC integration are shown beneath the question.
FSx for OpenZFS quiz: capabilities Scenario: An organization requires encryption both at rest and in transit and wants to control access via VPC. Which statement best aligns?
  • Correct: FSx for OpenZFS supports encryption at rest, provides mechanisms to protect data in transit depending on client/protocol, integrates with VPC access controls, and exposes OpenZFS-native features like snapshots and clones.
Architecture note: FSx file systems run in your VPC subnets (typically private subnets). EC2 instances mount the file system, and snapshots/clones/backups integrate with AWS Backup for centralized protection.
A diagram showing two VPCs with private subnets. FSx for OpenZFS is deployed in a private subnet; EC2 mounts the file system. Volumes, snapshots, and clones are shown, and backups can go into AWS Backup vaults for replication across VPCs/regions.
FSx for NetApp ONTAP FSx for NetApp ONTAP provides NetApp ONTAP features as a managed service: multi-protocol access (NFS, SMB, iSCSI), data-efficiency (deduplication, compression), and encryption. It’s a good choice when efficiency and multi-protocol compatibility are required.
A simplified AWS architecture diagram showing Amazon FSx for NetApp ONTAP and the steps to create, optimize, access, and run file systems. It lists supported clients (Amazon EC2, ECS/EKS, WorkSpaces, VMware, on‑premises) and protocols (NFS, SMB, iSCSI) for running applications.
FSx for ONTAP quiz: features for healthcare workloads Scenario: A healthcare provider wants deduplication, compression, encryption, and multi-protocol access for patient data. Which statement is correct?
  • Correct: FSx for NetApp ONTAP supports deduplication, compression, encryption, and multi-protocol access (NFS, SMB, iSCSI), making it well suited for efficient and secure mixed-protocol environments.
Practical hardening checklist
  • Always enable encryption at rest where supported (EBS, EFS, FSx). Prefer customer-managed KMS keys when separation of duties or key rotation is required.
  • Ensure in-transit protection is enabled (TLS for EFS, SMB encryption for FSx Windows, or protocol-specific mechanisms).
  • Use IAM and resource policies to restrict who can create, copy, or restore snapshots/backups.
  • Integrate file systems with AD or other authentication when supported (FSx for Windows + AWS Managed Microsoft AD).
  • Use AWS Backup for centralized, cross-account, and cross-region snapshot and backup orchestration.
  • For ephemeral instance store: design for data loss or implement replication and client-side encryption.
Closing summary
  • Block storage (EBS): encryption is the primary service-level control. Snapshots inherit encryption; unencrypted volumes must be migrated via snapshot → copy-with-encryption → new volume.
  • Instance store: ephemeral and unmanaged by AWS for backups — suitable for scratch workloads only.
  • File storage: EFS and FSx provide managed shared file systems with different protocol/feature trade-offs. Choose by workload needs (latency, protocol, throughput, durability) then enable encryption, access controls (VPC, security groups, IAM), and authentication (AD where applicable).
  • Use AWS Backup, KMS, and network controls together to build a layered storage security posture.
Further reading and references Good luck designing secure storage architectures.

Watch Video