Amazon EFS Deep Dive for the SAA-C03 Exam: Regional vs One Zone, Performance & Throughput Modes (Elastic, Provisioned, Bursting Credit Math), Storage Classes & Lifecycle Policies, Mount Targets, Access Points, IAM File System Policies, Encryption & Replication

Every SAA-C03 study guide gives Amazon EFS the same three sentences: it is a managed NFS file system, many Linux instances can mount it at once, and it grows automatically. Our own AWS storage services guide says exactly that, because that post is about choosing between EBS, EFS, FSx and S3. Those three sentences are enough for the one question that asks “which service gives a fleet of web servers a shared file system”.

They are not enough for the other EFS questions, which are about what happens after you picked EFS: why a 100 GiB file system goes slow after a backup job, which throughput mode a spiky workload should use, why files smaller than 128 KiB cost more than you expected in Infrequent Access, how to let one application see one directory and nothing else, how to force TLS, what “fail over to the replica” actually means, and why a One Zone file system is cheaper and what you gave up to get that. This is the deep dive those questions deserve.

Read it once for the model, then use the scenario drill near the end to test whether the rules stuck.

What EFS Is, Precisely

Amazon EFS is a serverless, elastic file system that you mount over NFS version 4.0 or 4.1 from inside a VPC. You never provision capacity; you pay for the bytes you store, metered in each storage class, plus throughput depending on the mode. The characteristics that generate exam questions are the ones that are not obvious from “managed NFS”:

Linux and macOS clients only. The documentation states plainly that using EFS with Microsoft Windows is not supported. A Windows file share requirement is an FSx for Windows File Server question, never an EFS question.
NFSv4 only. NFSv2 and NFSv3 are not supported, and some NFSv4 features are missing: no Kerberos security, no ACLs, no mandatory locking (all locks are advisory), no pNFS, no extended attributes, and no delegations.
Close-to-open consistency, the standard NFS semantics. Regional file systems make a write durable across Availability Zones when the application closes the file or calls fsync.
Thousands of concurrent clients. The hard quota is 25,000 connections per file system, and a single file can be up to 47.9 TiB.
One VPC at a time. A file system can only have mount targets in one VPC, though clients in peered VPCs, VPCs attached by Transit Gateway, other accounts and on-premises networks can still reach those mount targets.

The mental model for everything below: an EFS file system is a Regional service endpoint (data lives in the Region, not on a disk you own) that you reach through per-AZ network attachments (mount targets), whose speed is governed by a throughput mode, whose cost is governed by storage classes and lifecycle policies, and whose access is governed by security groups, IAM and access points in that order.

Mount Targets: How Your VPC Reaches the File System

A mount target is an elastic network interface with a static private IP address inside one subnet of your VPC. It is the NFS endpoint your clients connect to. The rules the exam tests:

Rule	Detail
One mount target per Availability Zone	If an AZ has several subnets, you create the mount target in one of them and every instance in that AZ shares it. The quota is exactly 1 per AZ per file system.
Regional file systems should have one in every AZ you use	Clients in an AZ without a mount target can still reach another AZ’s mount target, but you pay cross-AZ data transfer and add latency.
One Zone file systems have exactly one mount target	It lives in the file system’s AZ. Clients elsewhere pay the EC2 cross-AZ data transfer rate ($0.01/GB each direction) to reach it.
The DNS name resolves to the local AZ	`fs-0123456789abcdef0.efs.us-east-1.amazonaws.com` resolves to the mount target in the client’s AZ, which is what keeps traffic local and free. An AZ-specific name (`us-east-1a.fs-id.efs.us-east-1.amazonaws.com`) exists for the cases where you need to pin it.
Security groups attach to the mount target, not to the file system	The mount target’s security group must allow inbound TCP 2049 (NFS) from the client’s security group or CIDR. Up to 5 security groups per mount target.
Mount targets are highly available	The IP and DNS are static but backed by redundant resources, so you do not need two mount targets per AZ for HA.
Hard limits	1,400 mount targets per VPC; one VPC per file system.

The classic networking question gives you an instance that “cannot mount the file system” with a timeout. The answer is almost always the mount target’s security group missing an inbound rule for port 2049 from the instance’s security group. The second most common cause is that no mount target exists in the instance’s AZ and the subnet cannot route to another AZ’s subnet.

Mounting from elsewhere

On-premises servers connected over Direct Connect or Site-to-Site VPN can mount EFS, which AWS positions for migration, cloud bursting and backup. Two details matter: the on-premises client must be Linux, and AWS recommends mounting by the mount target IP address rather than DNS, because the on-premises resolver cannot resolve the VPC-private DNS name without extra configuration. There is no EFS charge for on-premises access, only the connection cost. For bulk migration the recommended tool is DataSync, covered in our data transfer and hybrid storage guide, not a long-running NFS copy over the VPN.

File System Types: Regional vs One Zone

When you create a file system you pick a file system type, and this choice is permanent.

	Regional (recommended)	One Zone
Where data lives	Redundantly across at least three AZs	A single AZ you choose
Durability (designed for)	99.999999999%	99.999999999% for everything short of losing the AZ; data may be lost if the AZ is destroyed
Availability SLA	99.99%	99.9%
Performance mode	General Purpose or Max I/O	General Purpose only
Elastic / Provisioned throughput ceiling	Up to 60 GiBps read / 5 GiBps write in the largest Regions	3 GiBps read / 1 GiBps write, not adjustable
Mount targets	One per AZ	Exactly one
Automatic backups	Optional (recommended)	Enabled automatically with AWS Backup, and backups are stored across three AZs
Price	Baseline	Materially lower storage price
AZ availability	All	Only specific AZ IDs per Region

The exam framing is cost versus resilience. “Development or test data”, “data that can be recreated”, “cost is the top priority and the application runs in one AZ” are One Zone cues. “Must survive the loss of an Availability Zone”, “production shared storage for a multi-AZ fleet” are Regional cues. The subtle point worth memorising is that One Zone still carries eleven-nines durability against disk, host and rack failure; what it does not survive is the loss of the whole zone, which is exactly why AWS turns on automatic AWS Backup for it.

The same Regional-versus-single-AZ distinction appears in our resilient architectures guide, where EFS Regional is listed as “multi-AZ by design” in contrast to EBS, which is tied to one AZ.

Performance Modes: General Purpose vs Max I/O

There are two performance modes, chosen at creation and never changed afterwards:

General Purpose is the default, has the lowest per-operation latency, and is the only option for One Zone file systems and for file systems that use Elastic throughput. AWS now recommends it for every file system.
Max I/O is described in the current documentation as a previous generation performance type for highly parallelised workloads that can tolerate higher latency. It is not supported with One Zone file systems or with Elastic throughput.

Older study material tells you “pick Max I/O for thousands of clients”. That advice is stale. General Purpose file systems with Elastic throughput scale to hundreds of thousands of IOPS (see the table below), so the modern answer to “many instances with a highly parallel workload” is General Purpose with Elastic throughput. If a question explicitly says the application is latency-sensitive, Max I/O is wrong for a second reason: it has higher latency by design. Monitor PercentIOLimit in CloudWatch to see how close a General Purpose file system is to its IOPS ceiling.

The General Purpose numbers

The documentation’s performance table for General Purpose mode, condensed:

File system type	Throughput mode	Read latency	Write latency	Max read IOPS	Max write IOPS	Per-file-system read	Per-file-system write	Per-client
Regional	Elastic	~1 ms	~2.7 ms	900,000–2,500,000	500,000	20–60 GiBps	1–5 GiBps	1,500 MiBps
Regional	Provisioned	~1 ms	~2.7 ms	55,000	25,000	3–10 GiBps	1–3.33 GiBps	500 MiBps
Regional	Bursting	~1 ms	~2.7 ms	35,000	7,000	3–5 GiBps	1–3 GiBps	500 MiBps
One Zone	Any	~1 ms	~1.6 ms	35,000	7,000	3 GiBps	1 GiBps	500 MiBps

Three footnotes that become exam traps:

The Elastic IOPS figures are the ceiling after quota increases. The default Elastic IOPS quota per file system is 250,000 read IOPS for frequently accessed data, 90,000 read IOPS for infrequently accessed data and 50,000 write IOPS, raisable up to 10x on request.
The 1,500 MiBps per-client figure only applies to Elastic throughput and a client running amazon-efs-utils 2.0 or later (or the EFS CSI driver). Every other combination is capped at 500 MiBps per client.
Maximum throughput depends on the Region; the ranges reflect the largest Regions versus “all other Regions”.

Every NFS request is metered as at least 4 KB of throughput, and read requests are metered at one-third the rate of writes, which is why a file system can always drive three times as much read throughput as write throughput for the same credit or billing cost.

Throughput Modes: Elastic, Provisioned and Bursting

This is where most EFS questions live. The throughput mode decides how much bandwidth the file system can drive and how you pay for it. There are three, and unlike the performance mode you can switch between them (with one restriction covered below).

Elastic throughput (the default)

With Elastic throughput, EFS scales throughput up and down automatically to match the workload, you provision nothing, and you pay only for the data and metadata actually read and written. No burst credits are earned or consumed. AWS recommends it for spiky or unpredictable workloads and gives a concrete threshold: workloads whose average-to-peak ratio is 5% or less. It is also required for the Archive storage class.

Ceilings per file system in us-east-1, us-east-2, us-west-2 and the other large Regions are 60 GiBps read and 5 GiBps write; elsewhere 20 GiBps read and 1 GiBps write. These are adjustable quotas.

Provisioned throughput

With Provisioned throughput you specify a throughput level in MiBps that the file system can drive regardless of its size or credit balance. Use it when you know the requirement, or when the average-to-peak ratio is above 5%, because at that point paying per byte transferred would cost more than paying a flat rate.

Two billing subtleties:

You are charged for the throughput you provision above the baseline that your Standard-class storage already includes for free. A 10 TiB file system has 500 MiBps of baseline; provisioning 600 MiBps bills you for 100.
If the file system grows until its baseline exceeds the provisioned amount, EFS automatically uses the (higher) Bursting throughput instead.

Ceilings: 10 GiBps read / 3.33 GiBps write in four Regions (Ohio, N. Virginia, Oregon, Ireland), 3 GiBps / 1 GiBps elsewhere.

Bursting throughput

Bursting ties throughput to the amount of data in the Standard storage class. This is the mode behind the famous “my small file system is slow” scenario, so learn the arithmetic:

Baseline: 50 KiBps per GiB of Standard storage, which is 50 MiBps per TiB. A file system can drive baseline throughput continuously. There is a floor of 1 MiBps for every file system.
Burst: 100 KiBps per GiB, which is 100 MiBps per TiB, with a floor of 100 MiBps, up to the Region’s Bursting limit (5 GiBps read / 3 GiBps write in five Regions, 3 / 1 elsewhere).
Credits accrue whenever the file system drives below its baseline and are spent whenever it drives above it.
Credit cap: 2.1 TiB of credit for file systems under 1 TiB, or 2.1 TiB per TiB stored for larger ones, which works out to enough credit to burst continuously for up to 12 hours.
Because reads are metered at one-third, the read-only baseline is 150 KiBps per GiB and the read-only burst is 300 MiBps per TiB.

The documentation’s worked example is worth memorising because the numbers reappear in questions: a file system with 100 GiB in Standard has a baseline of 5 MiBps. Over 24 idle hours it earns 5 MiB × 86,400 s = 432,000 MiB of credit, enough to burst at 100 MiBps for 72 minutes. File systems above 1 TiB can burst for 50% of the time if they are idle the other 50%.

Standard-class size	Continuous (baseline)	Burst
100 GiB	5 MiBps write / 15 MiBps read	100 MiBps write / 300 MiBps read, 72 min per day
1 TiB	50 MiBps write / 150 MiBps read	100 MiBps write / 300 MiBps read, 12 h per day
10 TiB	500 MiBps write / 1.5 GiBps read	1 GiBps write / 3 GiBps read, 12 h per day

The two exam traps inside Bursting:

Only bytes in Standard count. Data that lifecycle management moved to IA or Archive earns no credits and adds no baseline. A file system where 90% of the data has tiered to IA has 10% of the baseline you would expect from its total size.
Credits run out silently. Watch BurstCreditBalance in CloudWatch. When it hits zero, throughput collapses to baseline (which for a 20 GiB file system is the 1 MiBps floor). The fix is to switch to Elastic or Provisioned, not to “add more instances” or “enable Max I/O”.

Switching modes and the 24-hour lock

You can change throughput mode on a live file system. However, once you switch to Provisioned, or increase the provisioned amount, two actions are blocked for 24 hours: switching from Provisioned to Elastic or Bursting, and decreasing the provisioned amount. And if the file system has a lifecycle policy that transitions data to Archive, you cannot switch away from Elastic at all.

# Switch a Bursting file system to Elastic throughput (no restriction)
aws efs update-file-system \
  --file-system-id fs-0123456789abcdef0 \
  --throughput-mode elastic

# Switch to Provisioned at 256 MiBps (starts a 24-hour lock on decreasing it)
aws efs update-file-system \
  --file-system-id fs-0123456789abcdef0 \
  --throughput-mode provisioned \
  --provisioned-throughput-in-mibps 256

Choosing: the decision table

Requirement in the question	Mode	Why
”Unpredictable”, “spiky”, “difficult to forecast”, new workload	Elastic	Default and recommended; pay per byte, no credits
Average-to-peak ratio 5% or less	Elastic	AWS’s stated threshold
Known, sustained throughput requirement; average-to-peak above 5%	Provisioned	Flat rate independent of size
Small file system that needs more throughput than its size allows, sustained	Provisioned (or Elastic)	Bursting baseline is proportional to Standard-class size
Throughput should simply scale with stored data; large, steady file system	Bursting	Free baseline grows with storage
Burst credits exhausted, `BurstCreditBalance` at zero	Move to Elastic or Provisioned	Credits only refill when idle
Data must tier to Archive	Elastic	Archive requires Elastic throughput
Needs the 1,500 MiBps per-client ceiling	Elastic + efs-utils 2.0+	Every other combination caps at 500 MiBps

Storage Classes: Standard, Infrequent Access and Archive

EFS has three storage classes inside one file system. Data always lands in Standard first and moves to the other two only through lifecycle management.

Storage class	Designed for	First-byte latency	Availability SLA	Minimum billable size per file	Minimum storage duration	Access charge
EFS Standard	Active data, sub-millisecond latency, SSD-backed	Sub-millisecond	99.99% Regional / 99.9% One Zone	None	None	None
EFS Infrequent Access (IA)	Data accessed a few times a quarter	Tens of milliseconds	99.99% Regional / 99.9% One Zone	128 KiB	None	Per-GB read, plus a tiering charge when data moves
EFS Archive	Data accessed a few times a year or less	Tens of milliseconds	99.9% (listed for Regional)	128 KiB	90 days	Per-GB read, plus a tiering charge

Points the exam cares about:

Metadata is always in Standard. File names, directory structure and ownership never tier, so ls on a directory of archived files is fast and does not count as an access.
The 128 KiB rule is a billing floor, not a tiering floor. Since the November 26, 2023 change, lifecycle policies do tier files smaller than 128 KiB, but IA and Archive bill each such file as if it were 128 KiB. A file system made of millions of tiny files gains little from IA and can cost more if those files are read often.
Archive has a 90-day minimum storage duration and requires Elastic throughput; the storage class table lists it for Regional file systems.
Access charges apply to reads of IA and Archive data and to lifecycle transitions. AWS Backup reads of lifecycle-managed file systems are exempt from access charges.
Throughput accounting differs by class: Bursting baseline and Provisioned “included” throughput are both computed from Standard-class bytes only.

Our cost-optimised architectures guide covers the “EFS IA saves money” framing at decision level; the mechanics above are what let you tell when it won’t save money.

Lifecycle Management: The Three Policies

A file system has one lifecycle configuration made of up to three lifecycle policies. They apply to the whole file system, not per directory or per prefix (that is an S3 concept; see our S3 complete guide for the contrast).

Policy	Meaning	Allowed values	Default for new file systems
`TransitionToIA`	Move a file to IA after N days without access in Standard	1, 7, 14, 30, 60, 90, 180, 270, 365 days	30 days
`TransitionToArchive`	Move a file from Standard or IA to Archive after N days without access in Standard	1, 7, 14, 30, 60, 90, 180, 270, 365 days	90 days
`TransitionToPrimaryStorageClass`	Move a file back to Standard when it is accessed in IA or Archive	`AFTER_1_ACCESS` or unset	Unset (files stay tiered even when read)

How the timer works, because questions probe it:

The clock is an internal last-access timer in Standard, not the POSIX atime you can see. Any access to a file in Standard resets it.
Reading a file that is already in IA or Archive does not move it back unless TransitionToPrimaryStorageClass is set to AFTER_1_ACCESS. That setting is what AWS calls Intelligent-Tiering for EFS: tier down on inactivity, tier back up on first access. Choose it for latency-sensitive workloads with many small files; skip it for data that is read once a quarter by a batch job.
Writes to a file in IA or Archive go to Standard first; the file becomes eligible to tier again after 24 hours.
Lifecycle operations run at lower priority than your workload. Millions of small files take longer to transition than a few large ones of the same total size, and during the transition a file is still billed at the Standard rate.
Listing a directory never counts as accessing the files in it.

# Tier to IA after 30 idle days, to Archive after 90, and pull back to Standard on first access
aws efs put-lifecycle-configuration \
  --file-system-id fs-0123456789abcdef0 \
  --lifecycle-policies \
    '[{"TransitionToIA":"AFTER_30_DAYS"},
      {"TransitionToArchive":"AFTER_90_DAYS"},
      {"TransitionToPrimaryStorageClass":"AFTER_1_ACCESS"}]'

The exam question here is usually: “a shared file system holds project data; most files are untouched after the project ends but must remain available; minimise cost with the least operational effort.” The answer is a lifecycle policy to IA (and Archive if “rarely if ever accessed” appears), not copying to S3, not a Lambda-based mover, and not One Zone (which changes resilience, not access pattern).

Access Points: Application-Specific Entry Doors

An access point is an application-specific entry point into a file system. It can enforce two things on every request that comes through it:

A POSIX identity (user ID, group ID and secondary group IDs), overriding whatever identity the NFS client claims.
A root directory, so the client sees only that directory and its subdirectories. If the directory does not exist, EFS creates it on first connection using the owner UID/GID and permissions you specify in the access point’s creation info.

Facts the exam draws on:

Access points need at least one mount target; mount targets provide the network path, access points provide the policy. Access points are available in every AZ that has a mount target, and security groups still apply at the mount target level.
The default quota is 10,000 access points per file system (adjustable).
You mount through an access point with the mount helper: mount -t efs -o tls,iam,accesspoint=fsap-0123456789abcdef0 fs-0123456789abcdef0:/ /mnt/app.
AWS Lambda requires an access point to mount EFS; the function’s execution role must be allowed to use it. ECS task definitions and the EKS CSI driver also use access points so that each task or pod gets its own directory and identity.
The IAM condition key elasticfilesystem:AccessPointArn lets a file system policy say “this role may only connect through this access point”.

The scenario is “multiple applications share one file system; each must only see its own data and must run as a specific user regardless of the container’s user”. The answer is one access point per application with an enforced POSIX identity and root directory, combined with a file system policy keyed on AccessPointArn. The wrong answers are separate file systems per app (works, but not “one file system”), NFS export options (EFS has none) and directory permissions alone (a root user in a container bypasses them).

IAM Authorization for NFS Clients

EFS has two separate permission systems, and the exam tests the second one more than you expect.

The first is ordinary IAM for the EFS API: elasticfilesystem:CreateFileSystem, DescribeMountTargets and so on. The second is IAM authorization for NFS clients, which governs what a mounted client can do with the data.

The default: anonymous full access

A new file system has no file system policy, and the documented default policy grants full access to any anonymous client that can reach a mount target. In other words, security groups are the only thing between the network and your data until you attach a policy. DescribeFileSystemPolicy returns PolicyNotFound while the default is in effect.

The three client actions

Action	Grants
`elasticfilesystem:ClientMount`	Read-only access
`elasticfilesystem:ClientWrite`	Write access
`elasticfilesystem:ClientRootAccess`	Use of the root user (UID 0) on the file system

An allow in either the identity policy of the client’s role or the file system (resource) policy is sufficient; you do not need both. To use IAM authorization the client must mount with the EFS mount helper and the iam option, which presents the instance or task role’s credentials. Connections and authorization decisions are then logged in CloudTrail.

The four condition keys

Only four condition keys are enforced for NFS clients; any other condition key is ignored:

Condition key	Use
`aws:SecureTransport`	Require TLS (`"Bool": {"aws:SecureTransport": "true"}`)
`aws:SourceIp`	Restrict by public IP range only
`elasticfilesystem:AccessPointArn`	Require a specific access point
`elasticfilesystem:AccessedViaMountTarget`	Require access through a mount target (blocks direct-to-IP paths that bypass them)

A policy that implements the two most common exam requirements, “encrypt in transit” and “only this role, only through its access point”:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnencryptedTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "*",
      "Resource": "arn:aws:elasticfilesystem:us-east-1:111122223333:file-system/fs-0123456789abcdef0",
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    },
    {
      "Sid": "AppRoleViaItsAccessPoint",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/app-task-role" },
      "Action": [ "elasticfilesystem:ClientMount", "elasticfilesystem:ClientWrite" ],
      "Resource": "arn:aws:elasticfilesystem:us-east-1:111122223333:file-system/fs-0123456789abcdef0",
      "Condition": {
        "StringEquals": {
          "elasticfilesystem:AccessPointArn": "arn:aws:elasticfilesystem:us-east-1:111122223333:access-point/fsap-0123456789abcdef0"
        }
      }
    }
  ]
}

Note what a policy like this changes: once any policy exists, the anonymous-full-access default is gone, so every client that is not explicitly allowed loses access. The console’s “prevent anonymous access” and “enforce in-transit encryption” checkboxes generate exactly these statements.

Encryption at Rest and in Transit

At rest: encryption uses AWS KMS and is chosen only at creation. The console enables it by default with the AWS managed key aws/elasticfilesystem; you can supply a customer managed key instead. You cannot encrypt an existing unencrypted file system or change its key; the migration path is to create an encrypted file system and copy with DataSync. An organisation that “must guarantee every file system is encrypted” uses the elasticfilesystem:Encrypted IAM condition key to deny CreateFileSystem without it (and the AWS Config rule efs-encrypted-check to audit).

In transit: EFS supports TLS 1.2, implemented by the EFS mount helper (amazon-efs-utils). With -o tls the mount helper starts a local proxy (efs-proxy in efs-utils 2.0 and later, stunnel before that) listening on a localhost port between 20049 and 20449, and the NFS client actually mounts 127.0.0.1:/. A watchdog process (amazon-efs-mount-watchdog) restarts the proxy if it dies. Without the mount helper you can run stunnel yourself and mount localhost:port, but that is never the exam answer. The requirement “data must be encrypted in transit” therefore maps to two things together: mount with -o tls and enforce it with the aws:SecureTransport deny statement above, because a client could otherwise mount without TLS.

# Typical mount: TLS + IAM authorization, with the mount helper
sudo mount -t efs -o tls,iam fs-0123456789abcdef0:/ /mnt/efs

# Persistent mount in /etc/fstab (the _netdev option waits for networking)
fs-0123456789abcdef0:/ /mnt/efs efs _netdev,tls,iam 0 0

Replication: Cross-Region and Same-Region Copies

EFS replication keeps a destination file system synchronised with a source, in the same Region or another Region, and also across accounts (which requires an IAM role rather than the service-linked role). Facts to memorise:

RPO of 15 minutes for most file systems after the initial sync. It can be longer for file systems with more than 100 million files or files over 100 GB that change frequently. Monitor the TimeSinceLastSync metric.
Replication is not point-in-time consistent; changes are shipped based on the last synced time.
The destination is read-only for as long as the replication configuration exists.
Failover = delete the replication configuration from the destination. The destination becomes writable immediately and you point the application at it.
Failback has two flavours: re-create the original configuration (source to replica) to discard changes made during failover, or create a reverse configuration (replica to source) to copy back the changes, then re-establish the original direction.
Replication to a Region that is disabled by default requires opting in first; opting out later pauses replication.
You can replicate into an existing file system if its replication overwrite protection is disabled.
Cost: storage and activity charges on both sides, plus data transfer between Regions, plus about 12 MiB of hidden metadata on the destination.
Tag-based (ABAC) access control is not supported for replication.

The decision the exam sets up is replication versus AWS Backup versus DataSync:

Requirement	Answer
”Recovery in another Region within minutes”, “RPO of minutes”, “fail over”	EFS replication
”Point-in-time recovery”, “retain daily copies for 35 days”, “protect against accidental deletion”	AWS Backup (which also copies backups across Regions and accounts)
“One-time or scheduled copy”, “migrate on-premises NFS to EFS”, “copy to a different file system type”	DataSync
”Cross-Region reads from a second application”, “active-active”	None of the above: the replica is read-only, so design around S3 or a regional file system per Region

Integration Patterns the Exam Expects

EC2 fleets behind an ALB mounting one Regional file system for shared uploads, WordPress content or build artefacts: the canonical EFS scenario.
ECS and Fargate tasks mount EFS through task-definition volumes, with transitEncryption: ENABLED and an authorizationConfig that names an access point and IAM role. Fargate tasks have no persistent disk, so “persistent shared storage for Fargate” is EFS.
EKS uses the Amazon EFS CSI driver; dynamic provisioning creates one access point per PersistentVolumeClaim. If you are also studying Kubernetes storage, our CKA storage guide covers the PersistentVolume side.
Lambda mounts EFS at a local path such as /mnt/data through an access point; the function must be in a VPC with reachability to a mount target. The use case is large models, shared libraries or data sets that exceed the deployment package limit.
DataSync copies between on-premises NFS and EFS (and between EFS file systems), Transfer Family lands SFTP/FTPS uploads directly into EFS, and AWS Backup provides point-in-time backups with cross-Region and cross-account copy. All three are in our hybrid storage and data transfer guide.

The Quotas That Become Distractors

Resource	Quota
File systems per account per Region	1,000 (adjustable)
Mount targets per file system per AZ	1 (hard)
Mount targets per VPC	1,400 (hard)
VPCs per file system	1 (hard)
Security groups per mount target	5 (hard)
Connections per file system	25,000 (hard)
Access points per file system	10,000 (adjustable)
Single file size	47.9 TiB
File name length	255 bytes
Directory depth	1,000 levels
Locks on one file across all clients	512
Group IDs per user honoured by NFS	16 (extras are truncated)
Open files per client instance	65,536
File system policy size	20,000 characters
Elastic throughput per file system (large Regions)	60 GiBps read / 5 GiBps write (adjustable)
Provisioned throughput per file system (4 Regions)	10 GiBps read / 3.33 GiBps write (adjustable)
Bursting throughput per file system (5 Regions)	5 GiBps read / 3 GiBps write (hard)
One Zone throughput per file system	3 GiBps read / 1 GiBps write (hard)
Per-client throughput	1,500 MiBps (Elastic + efs-utils 2.0+) else 500 MiBps

The one that catches people: the 16-GID NFS limit. A user in 20 groups is “denied access to allowed files” because the extra GIDs were dropped; the fix is group design or an access point that sets the identity, not a security group change.

Pricing Shape (So the Cost Questions Make Sense)

You do not need prices, only the dimensions:

Storage per GB-month in each class (Standard, IA, Archive), with One Zone priced lower than Regional. Billed in binary GB.
Elastic throughput: per GB read and per GB written, with reads cheaper than writes.
Provisioned throughput: per MiBps-month for the amount provisioned above the baseline included with Standard storage.
Bursting: no throughput charge.
IA and Archive: per GB read, and per GB tiered.
Replication: both file systems’ charges plus inter-Region transfer.
Backup: AWS Backup per GB-month of backup storage and per GB restored.
Data transfer: free within an AZ, EC2 cross-AZ rate when clients are in another AZ, inter-Region rate for replication.

So “minimise cost” questions come down to: is the data cold (lifecycle to IA/Archive), is the workload spiky (Elastic) or steady (Provisioned or Bursting), does it need multi-AZ (Regional) or not (One Zone), and are clients in the same AZ as the mount target (free) or not.

Scenario Drill

Cover the right column and answer from the cue.

#	Scenario	Answer
1	Fleet of Linux web servers in three AZs needs one shared document root	Regional EFS, one mount target per AZ, mount by DNS name
2	Windows application needs an SMB share	FSx for Windows File Server, not EFS
3	Instance times out mounting EFS; mount target exists in its AZ	Add inbound TCP 2049 from the instance’s security group to the mount target’s security group
4	50 GiB file system becomes extremely slow during nightly batch, recovers by morning	Bursting credits exhausted; switch to Elastic (or Provisioned)
5	New analytics workload, “unpredictable spikes”, no history	Elastic throughput
6	Steady 400 MiBps around the clock, file system is 200 GiB	Provisioned throughput
7	Switched to Provisioned yesterday, want to go back to Elastic today	Blocked for 24 hours after the switch
8	Many files untouched after 60 days must remain accessible at low cost, no code changes	Lifecycle policy TransitionToIA (Archive if “a few times a year”)
9	After enabling IA, the monthly bill went up on a file system of millions of 4 KiB files	128 KiB minimum billable size per file in IA; keep small files in Standard
10	Tiered files must return to Standard automatically when the application reads them	TransitionToPrimaryStorageClass = AFTER_1_ACCESS
11	Want Archive tiering on a file system that uses Bursting	Switch to Elastic first; Archive requires it
12	Three microservices share one file system; each must see only its own directory and run as a fixed UID	One access point per service with enforced POSIX identity and root directory, policy keyed on AccessPointArn
13	Lambda function must read a 5 GB model shared with EC2	Mount EFS in Lambda through an access point; function in the VPC
14	Fargate tasks need persistent shared storage	EFS volume in the task definition with transit encryption and an access point
15	Security requires that no client can mount without TLS	File system policy denying when aws:SecureTransport is false; clients mount with -o tls
16	A root user inside a container can read every file; auditors want read-only for most roles	File system policy granting ClientMount only; ClientWrite/ClientRootAccess to specific roles; mount with -o iam
17	Existing file system is unencrypted; it must become encrypted	Create a new encrypted file system and migrate with DataSync; encryption cannot be added in place
18	Cross-Region DR with an RPO of 15 minutes for shared files	EFS replication to the other Region; fail over by deleting the replication configuration
19	Need point-in-time daily copies retained 90 days, copied to another account	AWS Backup, not replication
20	Reports in the DR Region should read the replica while replication continues	Allowed: the replica is readable, just not writable
21	Dev/test data, lowest cost, application in one AZ, can be regenerated	One Zone file system (backups are automatic)
22	One Zone file system; instances in another AZ report cross-AZ charges	Expected: One Zone has one mount target; move clients to that AZ or use Regional
23	On-premises Linux servers must write to EFS over Direct Connect	Allowed; mount by mount target IP, open 2049 to the on-prem range
24	User in 20 groups gets permission denied on files their group owns	NFS 16-GID limit; redesign groups or use an access point identity

Mistakes to Avoid

Treating Max I/O as “the fast one”. It is the previous-generation mode with higher latency, unavailable with Elastic throughput and One Zone. General Purpose plus Elastic is the modern high-scale answer.
Thinking EFS supports Windows or SMB. It does not. SMB means FSx for Windows or FSx for ONTAP.
Counting IA/Archive bytes toward Bursting baseline. Only Standard bytes earn credits and baseline throughput.
Assuming a new file system is private. Without a file system policy, anyone who can reach a mount target has anonymous full access. Security groups are the only control until you add a policy.
Expecting -o tls alone to “enforce” encryption. It encrypts that mount; enforcement is the aws:SecureTransport deny in the file system policy.
Believing encryption at rest can be enabled later. It is set at creation; migrate instead.
Confusing replication with backup. Replication is continuous, read-only on the destination and not point-in-time; AWS Backup is point-in-time and restorable to any AZ or Region.
Assuming lifecycle policies can target a directory. They apply to the whole file system.
Reading “tens of milliseconds first-byte latency” as a performance problem. For IA and Archive that is by design; the fix for a latency-sensitive workload is Intelligent-Tiering (transition back on first access), not disabling lifecycle.

Practise the Decision Patterns

The facts above are only useful if you can recall the right one in 90 seconds while a question tries to distract you with “enable Max I/O” and “increase the instance size”. The way to make the reflex automatic is to meet these scenarios repeatedly under exam conditions. The SAA-C03 mock exam bundle includes storage questions at exactly this altitude, with explanations that walk through why the distractors are wrong, which is where the real learning happens. Pair it with the service-selection reasoning in our storage services guide and the broader SAA-C03 study guide.

Frequently Asked Questions

What is the difference between Elastic, Provisioned and Bursting throughput in EFS?

Elastic (the default) scales throughput automatically and bills per GB read and written; it suits spiky workloads with an average-to-peak ratio of 5% or less. Provisioned lets you set a fixed MiBps independent of file system size, billed for the amount above your Standard-storage baseline. Bursting gives a baseline of 50 KiBps per GiB of Standard-class data with burst credits up to 100 MiBps per TiB, and is the mode where small file systems run out of credits.

Should I choose General Purpose or Max I/O performance mode?

General Purpose. AWS now recommends it for all file systems; Max I/O is a previous-generation mode with higher per-operation latency and is not supported with One Zone file systems or Elastic throughput. The performance mode cannot be changed after creation.

What does a One Zone file system give up compared to Regional?

Resilience to the loss of its Availability Zone and 0.09 points of availability SLA (99.9% versus 99.99%). It still has eleven-nines durability against disk and host failure, gets automatic AWS Backup, and has a lower throughput ceiling (3 GiBps read / 1 GiBps write) with a single mount target, so clients in other AZs pay cross-AZ data transfer.

How do EFS lifecycle policies decide when to move a file?

An internal timer tracks when each file was last accessed in the Standard class. TransitionToIA and TransitionToArchive fire after the configured number of days (1 to 365) without access; TransitionToPrimaryStorageClass set to AFTER_1_ACCESS moves a file back to Standard on its first read from IA or Archive. Metadata always stays in Standard, listing a directory is not an access, and the whole file system shares one configuration.

Why would Infrequent Access cost more than Standard?

IA and Archive bill a minimum of 128 KiB per file and charge per GB read. A file system of millions of tiny files, or one whose “cold” files are actually read often, can cost more in IA than in Standard. Archive additionally has a 90-day minimum storage duration.

How do I restrict one application to one directory on a shared EFS file system?

Create an access point with a root directory and an enforced POSIX user and group, mount through it (-o tls,iam,accesspoint=fsap-...), and add a file system policy that allows the application’s IAM role only when elasticfilesystem:AccessPointArn matches. Lambda, ECS and EKS all use access points this way.

How does failover work with EFS replication?

While a replication configuration exists, the destination file system is read-only and stays within roughly 15 minutes of the source. To fail over, delete the replication configuration on the destination; it becomes writable at once. To fail back, either re-create the original configuration (discarding changes made during the outage) or create a reverse replication from the replica to the original to copy those changes back.

Conclusion

The SAA-C03 exam uses EFS as a vehicle for a handful of repeatable judgements: Regional or One Zone, which throughput mode and why, when lifecycle tiering saves money and when the 128 KiB floor cancels the saving, how access points and file system policies replace NFS export tricks, how to enforce rather than merely enable TLS, and what replication does and does not promise. Each of those has a specific rule behind it, and the questions reward knowing the rule rather than the slogan.

Keep the four numbers that anchor the arithmetic (50 KiBps per GiB baseline, 100 MiBps per TiB burst, 5% average-to-peak, 128 KiB minimum), the two permanence rules (performance mode and encryption at rest are fixed at creation), and the one default that surprises everyone (no policy means anonymous full access), and the rest of the EFS questions become pattern matching.