EBS, EFS, FSx, and Backup

AWS storage design starts by naming the state the workload needs: a disk for one server, a shared Linux directory, a protocol-specific file share, or a recoverable copy after data loss. Amazon EBS, Amazon EFS, Amazon FSx, and AWS Backup solve those jobs at different layers. EBS is block storage for EC2 instances. EFS is elastic NFS file storage for many Linux clients. FSx is a family of managed file systems for Windows SMB, Lustre, NetApp ONTAP, and OpenZFS. AWS Backup is the policy and recovery control plane for supported resources.

After this lesson you should be able to choose between these services from access pattern and recovery goals, explain the mechanics that make each one different, inspect real configurations, troubleshoot common failures, and verify a backup design instead of assuming that a completed backup job is enough.

Purpose and Service Boundaries

EBS gives an EC2 instance a zonal virtual disk. You attach a volume, create or use a file system such as ext4, XFS, or NTFS, and let the operating system manage reads, writes, caching, and consistency. It is the normal choice for boot disks, single-instance databases, and application state that expects local block-device behavior.

EFS gives many Linux clients one shared NFS directory tree. You create a file system, add mount targets in VPC subnets, and mount it from EC2 instances, containers, or functions. It fits shared uploads, build artifacts, content repositories, and applications that need POSIX-style shared files without operating file servers.

FSx is selected when the file system itself matters. FSx for Windows File Server provides SMB, Active Directory integration, and Windows ACLs. FSx for Lustre targets high-throughput parallel workloads, often linked with S3. FSx for NetApp ONTAP and FSx for OpenZFS provide platform-specific features such as snapshots, clones, storage efficiency, and multiprotocol or ZFS-style administration.

AWS Backup coordinates backup plans, vaults, lifecycle retention, copy actions, and restores. It does not replace EBS, EFS, or FSx; it records recovery points for them and other supported services. A useful design separates live access from recovery: choose storage for the running workload, then define how that state is protected, copied, restored, and tested.

Internal Mechanisms

An EBS volume exists in one Availability Zone and is replicated within that zone. EC2 manages attachment, but the guest operating system sees a disk and owns partitioning, file system repair, mount options, and application consistency. Volume type controls the performance model: general purpose SSD for common transactional workloads, provisioned IOPS SSD for latency-sensitive databases, and HDD classes for large sequential access. EBS snapshots are incremental recovery points stored by AWS behind the EBS snapshot interface; they can create new volumes, including in a different Availability Zone or Region if copied.

EFS is a regional service by default, with storage distributed across multiple Availability Zones, or a One Zone option when lower cost and single-zone placement are acceptable. Clients reach it through mount targets, which are elastic network interfaces in your subnets. Security groups allow NFS traffic, while POSIX ownership and modes decide what mounted clients can do. Access points can force a root directory and user identity, which is valuable for containers because every task can enter the file system through a controlled path.

FSx exposes managed file systems through service-specific endpoints and protocols. Windows clients depend on DNS, SMB sessions, directory membership, and ACL evaluation. Lustre clients stripe data across servers so throughput depends on concurrency and file layout. ONTAP and OpenZFS designs lean more heavily on snapshots, clones, and administrative semantics. Treat FSx as a family of choices rather than one generic box on a diagram.

AWS Backup uses service roles, plans, selections, vaults, and recovery points. Plans define schedules and retention. Selections identify resources, commonly by tag so protection follows ownership. Vault Lock and cross-account or cross-Region copies can reduce accidental deletion and account-level blast radius. Restore testing is essential because a backup job proves that a recovery point exists, not that an application can mount, boot, authenticate, or serve correct data from the restored resource.

Configuration Anatomy

Storage configuration has four layers. Placement covers Region, Availability Zone, subnet, mount target, and endpoint reachability. Access covers IAM for control-plane actions, security groups for network paths, and file permissions inside the operating system or managed file service. Data behavior covers capacity, encryption key, volume type, IOPS, throughput, protocol, lifecycle class, and performance mode. Recovery covers schedule, retention, copy destination, restore role, and the acceptance test used after restore.

For EBS, the minimum useful design names size, type, Availability Zone, encryption, attachment target, snapshot policy, and how the file system will be grown after expansion. For EFS, name VPC, mount targets, security groups, access points, throughput mode, lifecycle policy, and POSIX identity. For FSx, name the FSx family, deployment type, storage and throughput capacity, subnets, client protocol, and directory integration when relevant. For AWS Backup, name vault, plan rule, resource selection, lifecycle, copy rule, restore permission, and verification procedure.

Example 1: EBS for Single-Instance State

A small PostgreSQL server on EC2 usually needs EBS. The database expects a local disk abstraction, controls durability with WAL and fsync, and benefits from low-latency block I/O. Before resizing or changing type, inspect the volume instead of guessing where it lives.

set -euo pipefail

aws ec2 describe-volumes \
  --filters Name=tag:Name,Values=course-ebs-demo \
  --query 'Volumes[].{Id:VolumeId,Az:AvailabilityZone,Type:VolumeType,SizeGiB:Size,Encrypted:Encrypted,State:State}' \
  --output table

Expected behavior: a matching volume appears with its Availability Zone, type, size, encryption state, and lifecycle state. An empty result means no selected-volume tag matched in the current Region. The design lesson is that an EBS volume cannot simply follow an instance to another Availability Zone. For zonal failover, restore or create a volume from a snapshot in the target zone, then attach it and run the application recovery steps.

Example 2: EFS for Shared Linux Files

A web fleet that reads and writes shared uploads should not copy files to each instance and hope they converge. EFS gives all clients the same NFS file system. The two checks that usually matter first are whether clients can reach mount targets and whether POSIX permissions allow the intended writes.

set -euo pipefail

FILE_SYSTEM_ID="fs-1234567890abcdef0"

aws efs describe-mount-targets \
  --file-system-id "$FILE_SYSTEM_ID" \
  --query 'MountTargets[].{MountTargetId:MountTargetId,SubnetId:SubnetId,LifeCycleState:LifeCycleState,IpAddress:IpAddress}' \
  --output table

Expected behavior: a healthy regional design has mount targets in the Availability Zones where clients run. If mounting times out, check subnet placement, route reachability, DNS, and security group ingress for TCP 2049. If mounting succeeds but writes fail, the network path is good; inspect ownership, mode bits, and any access point user mapping.

Example 3: FSx for Protocol-Specific Workloads

A Windows line-of-business application that stores shared documents needs SMB, Active Directory users, and Windows ACLs. EFS does not provide that permission model, and EBS would still be one instance’s disk. FSx for Windows File Server manages the file server layer while clients use normal Windows file sharing.

set -euo pipefail

aws fsx describe-file-systems \
  --query 'FileSystems[].{Id:FileSystemId,Type:FileSystemType,Lifecycle:Lifecycle,StorageGiB:StorageCapacity,DnsName:DNSName}' \
  --output table

Expected behavior: the output shows each FSx family, lifecycle state, capacity, and DNS name. For Windows File Server, successful use also depends on domain configuration and permissions. For Lustre, the same table starts a different investigation: client packages, mount endpoint, parallel file access, and whether the workload generates enough concurrency to use the file system throughput.

Design Choices and Trade-Offs

Choose EBS when one compute node needs disk-like state, especially databases and boot volumes. The trade-off is zonal coupling and guest file-system responsibility. Snapshots help with recovery and cloning, but ordinary file systems are not made safe for multiple independent writers just because the storage layer is durable.

Choose EFS when Linux clients need shared files and elastic capacity. The trade-off is that NFS behavior, client caching, metadata-heavy workloads, and POSIX permissions become central. EFS can simplify operations, but it is not automatically faster than local block storage for every workload.

Choose FSx when protocol compatibility, specialized throughput, or file-system-native features drive the requirement. The trade-off is service-specific design: Windows, Lustre, ONTAP, and OpenZFS have different client assumptions and operating knobs. Choose AWS Backup when centralized schedules, retention, auditing, restore workflows, and copied recovery points matter. Its trade-off is that it coordinates protection but does not remove application-level recovery work.

Translate business recovery targets into storage settings. A one-hour recovery point objective may require frequent EBS snapshots, EFS or FSx backups, and copy rules for critical vaults. A short recovery time objective needs prewritten restore commands, subnet and security group choices, KMS access, and a known validation script. Without those details, the backup plan is inventory rather than a recovery process.

Failure Modes and Troubleshooting

EBS attach failure. Symptom: the attach call fails or the instance does not see the device. Likely causes are Availability Zone mismatch, wrong instance, device-name confusion, or a volume state other than available. Diagnose with describe-volumes, describe-instances, and operating-system device listing. Correct by using the same zone, restoring a snapshot into the target zone, or fixing the attachment target.

EBS volume full or slow. Symptom: no space left on device, high latency, or database stalls. Diagnose file-system usage, CloudWatch volume metrics, burst balance where applicable, queue depth, and instance storage limits. Correct by safely deleting data, expanding the volume and file system, or selecting a type and provisioned performance level that matches the workload.

EFS mount timeout. Symptom: mount hangs or returns a network timeout. Causes are usually missing mount targets, security group rules, DNS, or routing. Diagnose client subnet and Availability Zone, mount target state, TCP 2049 ingress from the client security group, and name resolution. Correct the network layer before changing file permissions.

EFS permission denied. Symptom: mount succeeds but writes fail. Causes are POSIX ownership, directory mode, root behavior, or access point identity. Diagnose with id, ls -ld, and access point settings. Correct ownership and modes deliberately rather than making broad writable paths.

FSx client cannot connect. Symptom: Windows drive mapping fails or Lustre clients cannot mount. Causes vary by family: directory trust, DNS, security groups, unsupported client setup, missing packages, or file permissions. Diagnose from name resolution to network path, authentication, and authorization. Correct the lowest failing layer first.

Backup restores but the application fails. Symptom: a recovery point creates a resource, yet the workload cannot use it. Causes include wrong subnet, missing security groups, absent mount configuration, permissions, or missing database recovery steps. Restore into isolation, run real health checks, and update the runbook until the restored workload meets the recovery objective.

Security, Performance, and Reliability

Encrypt storage by default and manage KMS permissions for both live resources and restored copies. IAM controls who can create, snapshot, back up, copy, and restore. Network controls decide who can mount EFS or reach FSx endpoints. File permissions still matter after network access succeeds.

Performance depends on I/O shape. EBS tuning focuses on IOPS, throughput, latency, queue depth, instance limits, and file system behavior. EFS tuning focuses on throughput mode, storage class, client count, metadata intensity, and mount behavior. FSx tuning depends on the chosen family. Reliability depends on placement and recovery: a zonal EBS volume, regional EFS file system, multi-AZ FSx deployment, and cross-account backup copy all fail differently.

Hands-On Lab: Inspect and Validate a Backup Design

Prerequisites: AWS CLI configured for a sandbox account, read permission for EC2, EFS, FSx, AWS Backup, and a selected Region through AWS_REGION or the CLI profile. This lab is inspection-only, so cleanup is limited to removing local notes.

  1. Confirm identity and Region before inspecting resources.
  2. List EBS volumes and record encryption, Availability Zone, state, and ownership tags.
  3. List EFS file systems and mount targets. Verify that mount targets exist where clients run.
  4. List FSx file systems and record family, lifecycle state, capacity, and DNS name.
  5. List AWS Backup plans and vaults. Check whether resources are selected by tag or explicit ARN.
  6. Choose one protected resource and write a restore acceptance check, such as a restored EFS path mounts from a test instance or a database process can read a restored EBS volume.
set -euo pipefail

aws sts get-caller-identity --query '{Account:Account,Arn:Arn}' --output table
aws ec2 describe-volumes --query 'Volumes[].{Id:VolumeId,Az:AvailabilityZone,Encrypted:Encrypted,State:State}' --output table
aws efs describe-file-systems --query 'FileSystems[].{Id:FileSystemId,Encrypted:Encrypted,Mode:PerformanceMode,State:LifeCycleState}' --output table
aws fsx describe-file-systems --query 'FileSystems[].{Id:FileSystemId,Type:FileSystemType,Lifecycle:Lifecycle}' --output table
aws backup list-backup-plans --query 'BackupPlansList[].{Id:BackupPlanId,Name:BackupPlanName}' --output table

Verification: each command returns a resource table or an empty table. Empty tables are acceptable in a new sandbox, but in a workload account they reveal missing inventory evidence. Cleanup: no AWS resources are created. Remove local notes containing account identifiers when they are no longer needed.

Assessment Exercises

  1. A database uses one EC2 instance and one EBS volume. The team wants a standby instance in another Availability Zone to attach the same volume during failover. Explain why this fails and propose a better recovery approach.
  2. A containerized web application needs shared uploads across tasks. Compare EFS with copying files to each task’s local disk, including consistency and failure behavior.
  3. A Windows application requires SMB shares and Active Directory permissions. Explain why FSx for Windows File Server fits better than EFS or EBS.
  4. A nightly backup plan reports success. What evidence would prove the business can recover within its recovery time objective?
  5. An EFS mount works from one subnet but times out from another. Name the layers you would inspect and the order.

Summary

EBS, EFS, FSx, and AWS Backup are related but not interchangeable. EBS is zonal block storage for disk-like workloads. EFS is shared NFS storage for Linux clients. FSx is managed file storage for protocol-specific and performance-specific needs. AWS Backup turns recovery requirements into schedules, vaults, retention, copies, and restore workflows. Good AWS storage design names the access pattern first, chooses the service, then proves recovery with a tested restore path.