Amazon EFS explained: scalable NFS file storage, pricing tips, security, and troubleshooting with PowerShell.

Amazon EFS (Elastic File System): The Complete, Scalable, NFS-Compatible Shared File Storage Guide

Definition: Amazon Elastic File System (EFS) is a fully managed, scalable, elastic, shared file storage service for AWS Cloud and on-premises resources, providing an NFS v4/v4.1-compatible interface for Linux/Unix workloads.

Quick Use Case: Ideal when multiple Amazon EC2 instances, containers (ECS/EKS), or AWS Lambda functions need concurrent read/write access to the same file set across Availability Zones.

Why Amazon EFS?

EFS eliminates the undifferentiated heavy lifting of deploying, patching, and scaling file servers. It automatically grows and shrinks with your data, delivers regional high availability and durability, and supports POSIX semantics so your Linux applications “just work.”

Fully managed: No file servers to size, patch, or replicate—AWS handles it.

Elastic scalability: Storage and performance scale automatically as your dataset grows.

Multi-AZ resilience: Data is stored across multiple AZs (in Standard class).

NFS v4/v4.1: Native for Linux/Unix apps and tools.

POSIX-compliant: Permissions, ownership, and symlinks behave as expected.

Security: KMS encryption at rest and TLS in transit.

Observability: Native integration with Amazon CloudWatch.

Cost control: Lifecycle IA tiers, One Zone class, and Provisioned Throughput options.

How EFS Works (Architecture Overview)

EFS is a regional service. You create a file system in a region, then create mount targets in the VPC subnets of each Availability Zone that needs access. Clients mount via standard NFS using the mount target’s IP or the EFS mount helper. Under the hood, EFS distributes data and metadata across its control and data planes to achieve durability and availability.

Mount targets per AZ: Enables low-latency, in-AZ access and cross-AZ resilience.
Security groups & NACLs: Gate inbound NFS (TCP 2049) traffic from your compute.
DNS: Region-scoped file system DNS name resolves to local AZ mount targets.
POSIX model: UID/GID permissions enforce least-privilege at the file/folder level.

Tip: Place mount targets in every AZ where your EC2, EKS, or ECS workloads run to avoid cross-AZ hops.

Performance & Throughput Modes

Performance Modes

General Purpose (default): Low latency; ideal for web/CMS, dev environments, home directories.
Max I/O: Scales to millions of operations with higher latency tolerance; suits analytics, media processing.

Throughput Modes

Bursting Throughput (default): Throughput scales with your data size and burst credits.
Provisioned Throughput: Set a consistent throughput independent of data size for predictable workloads.

Choose GP for latency-sensitive web apps.

Choose Max I/O for massively parallel workloads.

Use Provisioned when you need steady performance regardless of dataset size.

Storage Classes & Lifecycle Management

Standard: Multi-AZ durability and availability (best for production shared data).
One Zone: Lower cost for single-AZ workloads where you manage AZ resilience.
Infrequent Access (IA) tiers: Available for both Standard and One Zone; lifecycle policies move cold files to IA automatically.

Lifecycle policies transition files based on last access time (e.g., 7, 14, 30, 60, or 90+ days). Combine with AWS Backup to further control long-term cost and retention.

Security & Compliance

Encryption at rest: AWS KMS-managed keys—enable at creation for zero-touch protection.
Encryption in transit: TLS; use mount -t efs -o tls or the EFS mount helper.
Identity enforcement: POSIX UID/GID and directory permissions.
Network controls: VPC subnets, security groups, and NACLs limit NFS (2049) access.
IAM: Policies to govern API access and resource policies to control who can mount file systems.

Availability, Durability & Regions

Regional resource: EFS replicates data across multiple AZs (Standard class).
Designed for 99.99% availability: Architected for high uptime via distributed control/data planes.
Mount targets in each AZ: Avoid single-AZ dependencies.

Access Methods & Integrations

EC2: Mount via EFS mount helper or NFS client; use systemd or fstab for persistence.
EKS/ECS: Use the EFS CSI driver for Kubernetes or EFS volumes in ECS tasks.
Lambda: Attach EFS access points to Lambda for large package data or shared state.
On-premises: Via AWS Direct Connect or site-to-site VPN.
Automation: CloudFormation, AWS Backup, AWS DataSync, CloudWatch.

Cost Model & Optimization

Pay-as-you-go: Billed by GB-month used, plus costs for Provisioned Throughput (if enabled) and IA retrievals.
Choose One Zone for single-AZ dev/test to save.
Enable Lifecycle (IA) to reduce cost for cold data.
Right-size throughput: Use Bursting when dataset is large enough; pick Provisioned for steady jobs.
Review access patterns: Avoid unnecessary cross-AZ traffic; collocate clients with mount targets.

Comparing EFS vs. EBS vs. S3

Service	Type	Access	Use Cases
EFS	Shared file storage (NFS)	Multiple EC2/containers across AZs	Web/CMS, home dirs, CI/CD assets, shared ML data
EBS	Block storage (per-instance)	Single EC2 at a time (multi-attach for specific types)	Databases, low-latency single-host workloads
S3	Object storage	HTTP(S) via SDK/CLI	Backups, data lakes, static content, archival

Common Use Cases

Web & Content Serving: Shared media uploads across web farm.
Big Data & Analytics: Parallel workloads on shared datasets.
CI/CD: Artifacts, caches, and shared pipelines.
ML: Feature stores and model artifacts shared across jobs.
Containers: Persistent shared volumes for EKS/ECS tasks.
Home Directories: POSIX-correct team folders for devs and analysts.

Hands-On: Creating, Mounting & Securing EFS

Create a File System

# AWS CLI
aws efs create-file-system \
  --performance-mode generalPurpose \
  --throughput-mode bursting \
  --encrypted

# Add mount targets in each AZ subnet
aws efs create-mount-target --file-system-id fs-1234567890abcdef --subnet-id subnet-aaa --security-groups sg-111
aws efs create-mount-target --file-system-id fs-1234567890abcdef --subnet-id subnet-bbb --security-groups sg-111

Mount from Linux (with TLS)

sudo yum install -y amazon-efs-utils   # or apt-get install -y amazon-efs-utils
sudo mkdir -p /mnt/efs
sudo mount -t efs -o tls fs-12345689:/ /mnt/efs

# Persist across reboots
echo "fs-12345689:/ /mnt/efs efs _netdev,tls 0 0" | sudo tee -a /etc/fstab

EKS with EFS CSI Driver

# Install EFS CSI driver (using Helm as example)
helm repo add aws-efs-csi-driver https://kubernetes-sigs.github.io/aws-efs-csi-driver/
helm install aws-efs-csi-driver aws-efs-csi-driver/aws-efs-csi-driver --namespace kube-system

# Example PersistentVolume
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-efs
spec:
  capacity:
    storage: 100Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  csi:
    driver: efs.csi.aws.com
    volumeHandle: fs-12345689

Troubleshooting Playbooks (with PowerShell)

Below are practical PowerShell snippets using the AWS Tools for PowerShell module (Install-Module AWSPowerShell.NetCore). These help you diagnose mount issues, performance bottlenecks, throughput limits, and security group constraints for Amazon EFS. (Microsoft Graph API is not applicable to EFS, so we focus on PowerShell.)

0) Setup & Authentication

# Install and import AWS Tools
Install-Module -Name AWSPowerShell.NetCore -Scope CurrentUser -Force
Import-Module AWSPowerShell.NetCore

# Configure credentials (use a profile with least privilege)
Set-AWSCredential -ProfileName "ops" -StoreAs "ops"

# Set default region
Set-DefaultAWSRegion -Region us-east-1

1) List File Systems, Performance & Throughput Modes

# List file systems and key settings
Get-EFSFileSystem | Select-Object FileSystemId, Name, LifeCycleState, PerformanceMode, ThroughputMode, Encrypted | Format-Table -Auto

2) Check Mount Targets & Network Paths

$fsId = "fs-12345689"
Get-EFSMountTarget -FileSystemId $fsId | Select-Object MountTargetId, AvailabilityZoneName, SubnetId, LifeCycleState, IpAddress | Format-Table -Auto

# Verify Security Groups allow NFS (2049) from your instances
Get-EFSMountTarget -FileSystemId $fsId | ForEach-Object {
  $mt = $_
  $sgs = Get-EC2SecurityGroup | Where-Object { $_.GroupId -in $mt.SecurityGroups }
  $sgs | ForEach-Object {
    $_.IpPermissions | Where-Object { $_.IpProtocol -eq "tcp" -and $_.FromPort -le 2049 -and $_.ToPort -ge 2049 } |
      Select-Object @{n="MountTargetId";e={$mt.MountTargetId}}, @{n="SecurityGroup";e={$_.ToString()}}
  }
}

3) Validate DNS Resolution from an EC2 Instance (Windows)

# Run on the client (Windows EC2) to ensure DNS and NFS reachability
$fsDns = "fs-12345689.efs.us-east-1.amazonaws.com"
Resolve-DnsName $fsDns
Test-NetConnection -ComputerName $fsDns -Port 2049

4) Observe CloudWatch Metrics for Throughput & I/O

# Query key EFS metrics (TotalIOBytes, DataReadIOBytes, DataWriteIOBytes, ClientConnections)
$namespace = "AWS/EFS"
$now = Get-Date
$start = $now.AddHours(-6)

$metrics = @("TotalIOBytes","DataReadIOBytes","DataWriteIOBytes","ClientConnections","PermittedThroughput","IOUtilization","BurstCreditBalance")
foreach ($m in $metrics) {
  Get-CWMetricStatistics -Namespace $namespace -MetricName $m -StartTime $start -EndTime $now -Period 300 -Statistics Average -Dimensions @{Name="FileSystemId";Value=$fsId} |
    Select-Object @{n="Metric";e={$m}}, Timestamp, Average | Sort-Object Timestamp
}

5) Spot Burst Credit Exhaustion (Symptoms: throttling, slow I/O)

# Look specifically at IOUtilization and BurstCreditBalance
Get-CWMetricStatistics -Namespace "AWS/EFS" -MetricName "IOUtilization" -StartTime $start -EndTime $now -Period 300 -Statistics Average -Dimensions @{Name="FileSystemId";Value=$fsId}

Get-CWMetricStatistics -Namespace "AWS/EFS" -MetricName "BurstCreditBalance" -StartTime $start -EndTime $now -Period 300 -Statistics Average -Dimensions @{Name="FileSystemId";Value=$fsId}

6) Identify Hot Directories & Large Files (Linux helper from PowerShell)

# Remotely run Linux commands from PowerShell (SSM or SSH)
# Example command that you can run on a Linux client:
#   sudo du -xh /mnt/efs | sort -h | tail -n 20
#   sudo lsof +D /mnt/efs | head -n 20

7) Validate TLS Mounts & Stale Handles

# On Linux:
#   sudo mount | grep efs
#   sudo dmesg | egrep -i "nfs|rpc"
#   sudo cat /etc/fstab
#   sudo systemctl status amazon-efs-mount-watchdog

8) Switch Performance/Throughput Mode (Change Control)

# Example: Update throughput mode to provisioned (change values per workload testing)
Update-EFSFileSystem -FileSystemId $fsId -ThroughputMode provisioned -ProvisionedThroughputInMibps 64

9) Audit Permissions & Ownership (POSIX)

# On Linux clients:
#   find /mnt/efs -maxdepth 2 -printf "%M %u:%g %p\n" | head -n 50
#   getfacl /mnt/efs/some/dir
#   sudo chown -R appuser:appgroup /mnt/efs/project
#   sudo chmod -R 770 /mnt/efs/project

10) Backup & Restore with AWS Backup

# List backup plans and EFS resources assigned
Get-BAKBackupPlanList | Select-Object BackupPlanId, BackupPlanName
Get-BAKBackupSelectionsList | Select-Object SelectionId, BackupPlanId, IamRoleArn

Outcome: With the steps above, you can isolate network misconfigurations, detect throughput saturation, validate mount correctness, and restore data confidently.

Operational Best Practices

Place mount targets in every active AZ; pin clients to same-AZ where possible.
Use multiple threads/connections for higher aggregate throughput.
Encrypt at rest and in transit; rotate KMS keys per your policy.
Prefer General Purpose for web/CMS; use Max I/O for massively parallel jobs.
Pick Provisioned Throughput for steady or spiky workloads smaller than burst thresholds.
Enable lifecycle policies to move cold data to IA tiers.
Monitor ClientConnections, TotalIOBytes, and IOUtilization in CloudWatch.
Harden NFS with SGs/NACLs; restrict to trusted sources only (port 2049/TCP).
Use Access Points for per-application root directories and enforced UID/GID.
Automate with CloudFormation or IaC to ensure consistency.

End-to-End Example

Media company scenario: A news portal stores images and short clips on EFS. Several EC2 instances behind an Application Load Balancer mount the same file system. As content grows, EFS auto-scales; lifecycle policy cools old assets into IA, cutting costs. Provisioned Throughput is configured to guarantee consistent publishing performance during peak hours.

10 Frequently Asked Questions (FAQs)

Is Amazon EFS NFS-compatible? Yes—NFS v4/v4.1, making it ideal for Linux and Unix clients.
Does EFS require managing file servers? No—EFS is fully managed; AWS handles the fleet, scaling, and patching.
How do I achieve high availability? Use the Standard storage class and create mount targets in every required AZ.
What performance mode should I pick? General Purpose for low-latency apps; Max I/O for huge parallel workloads.
When do I use Provisioned Throughput? When you need steady throughput regardless of data size or want predictable performance.
Can I use EFS from on-prem? Yes—via Direct Connect or site-to-site VPN to your VPC, subject to NFS security.
How do I cut costs? Enable lifecycle to IA tiers, consider One Zone for single-AZ dev/test, and control cross-AZ access.
Is data encrypted? Yes—KMS at rest (enable on creation) and TLS in transit using the mount helper.
What should I monitor? ClientConnections, DataRead/WriteIOBytes, TotalIOBytes, IOUtilization, and BurstCreditBalance.
How is EFS different from S3 or EBS? EFS is shared NFS file storage; EBS is per-instance block storage; S3 is object storage.

Key Points Recap

EFS is fully managed, elastic, POSIX-compliant shared file storage.
Supports NFS v4/v4.1 and multi-AZ access via mount targets.
Choose General Purpose vs. Max I/O based on latency and concurrency needs.
Pick Bursting vs. Provisioned Throughput per workload predictability.
Use Standard or One Zone with IA tiers and lifecycle to optimize cost.
Secure with KMS, TLS, SGs, NACLs, IAM; use Access Points for app isolation.
Integrates with EKS/ECS/Lambda, CloudWatch, AWS Backup, and DataSync.

Cloud Knowledge