Cloud / Amazon EFS Interview questions

Amazon Elastic File System (EFS) is a managed, serverless network file system that many compute resources can mount and share at the same time. It speaks NFS, so applications see ordinary directories and files with POSIX permissions.

There is no capacity to provision. The file system grows and shrinks as you add or delete files, and you pay for what is stored. Data is kept redundantly across multiple Availability Zones for Regional file systems.

It works with EC2, ECS, EKS, Fargate and Lambda. Run df -h on a mounted volume and it reports a huge virtual size (8 EiB), which is just how an elastic file system presents itself.

EFS uses the Network File System (NFS) protocol, versions 4.1 and 4.0. Clients connect over TCP on port 2049 to a mount target inside your VPC.

NFSv4.1 is the recommended version, and it is what the EFS mount helper uses by default. Older NFSv3 is not supported.

Because it is standard NFS, any Linux client with an NFS 4.x stack can mount it, though the amazon-efs-utils package makes TLS and IAM options much easier.

One practical upside of NFSv4 is that only TCP 2049 has to be open between the client and the mount target. There is no separate portmapper or UDP port to manage, which keeps the firewall rules simple.

EFS offers five storage classes, split by redundancy and access pattern:

1. EFS Standard - frequently accessed data, stored across multiple AZs.
2. EFS Standard-IA - infrequently accessed data, multi-AZ, lower storage price plus a per-GB access charge.
3. EFS Archive - rarely accessed data (a few times a year), cheapest multi-AZ option.
4. EFS One Zone - frequently accessed data in a single AZ.
5. EFS One Zone-IA - infrequently accessed data in a single AZ.

Lifecycle management moves files between the frequently accessed and colder classes based on last access time.

EFS has three throughput modes: Elastic, Provisioned and Bursting.

Elastic is the recommended default for spiky or unpredictable workloads.

You can switch modes on a live file system, but AWS makes you wait 24 hours before the next change, so choose the mode deliberately.

EFS has two performance modes chosen at creation time: General Purpose and Max I/O.

General Purpose is the default. It gives the lowest per-operation latency and suits web serving, CMS, home directories and most applications.

Max I/O was built for highly parallel jobs with thousands of clients, trading slightly higher latency for higher aggregate operations. It is not supported with One Zone file systems or Elastic throughput, so AWS treats it as a legacy choice and recommends General Purpose for nearly everything.

A mount target is the network endpoint of an EFS file system inside one subnet of your VPC. It has its own IP address and an attached security group, and clients mount the file system through it.

A Regional file system can have one mount target per Availability Zone. A One Zone file system has just one, in the AZ where it was created.

When an EC2 instance resolves the file system DNS name (fs-id.efs.region.amazonaws.com), it gets the mount target IP in its own AZ, which avoids cross-AZ traffic.

Install the EFS mount helper, create a directory, and mount using the efs file system type.

sudo yum install -y amazon-efs-utils
sudo mkdir /mnt/efs
sudo mount -t efs -o tls fs-0123456789abcdef0:/ /mnt/efs

To make it survive reboots, add a line to /etc/fstab:

fs-0123456789abcdef0:/ /mnt/efs efs _netdev,tls 0 0

Without the helper you can use the plain NFS client with -t nfs4 and the recommended mount options. Make sure port 2049 is open between the client and the mount target.

EFS fits workloads that need a shared, elastic file system reachable from many servers at once.

• Web serving and CMS - WordPress or Drupal uploads shared across an Auto Scaling group.
• Home directories and developer tools shared by teams.
• Container and serverless persistence for ECS, EKS, Fargate and Lambda.
• Analytics and ML - shared datasets and model artifacts for training jobs.
• Content management and media processing pipelines.

It is a poor fit for Windows workloads, a boot volume, or latency-critical databases, where EBS or FSx are better.

An access point is an application-specific entry into an EFS file system. It forces a root directory and a POSIX user and group on every request that comes through it, no matter what identity the client presents.

You can also set creation permissions so that the root directory is created automatically with the right owner and mode the first time it is used.

Access points are popular for multi-tenant apps, Lambda functions and containers, because each workload sees only its own subtree. You can attach an IAM policy that allows a role to mount only through a specific access point.

No. Amazon EFS is not supported on Windows instances. It depends on NFS, and the Windows NFS client is not supported for EFS mounts.

For Windows workloads that need a shared file system, use Amazon FSx for Windows File Server, which speaks SMB and integrates with Active Directory.

EFS is meant for Linux-based clients such as Amazon Linux, Ubuntu and RHEL, and for Linux containers.

In a mixed estate, run EFS for the Linux side and FSx for Windows for the Windows side, rather than trying to force one service to serve both.

A single file in EFS can be up to 47.9 TiB (52,673,613,135,872 bytes). This is a fixed quota and cannot be raised.

The file system itself has no practical size limit, since it is elastic and grows to petabytes.

Related quotas worth remembering: up to 1,000 file systems per account per Region (adjustable) and up to 10,000 access points per file system (adjustable).

Even well below the limit, very large files such as raw genomics or video captures are worth splitting into chunks. A single huge file is handled by one client thread and does not benefit from EFS's parallelism.

A Regional file system stores data redundantly across multiple Availability Zones and can have a mount target in each of them. It survives the loss of an AZ.

A One Zone file system keeps data in a single AZ, so it costs less but is exposed to an AZ-level outage. Clients in other AZs can still mount it, but they pay cross-AZ network costs and get extra latency.

Lifecycle management automatically moves files between storage classes based on how long it has been since they were last accessed. The goal is to lower cost without any application change.

You can set a policy to move files to IA after a chosen period (1, 7, 14, 30, 60, 90, 180, 270 or 365 days), move them to Archive later, and optionally bring them back to Standard on first access.

Files smaller than 128 KiB are never moved to IA, so they stay in Standard. Metadata stays in Standard as well.

amazon-efs-utils is an open-source set of tools from AWS that includes the EFS mount helper (mount.efs). It lets you use mount -t efs instead of hand-writing NFS options.

What it adds over plain NFS:

• Encryption in transit with the tls option.
• IAM authorization with the iam option.
• Mounting through an access point with accesspoint=fsap-....
• A watchdog that restarts the TLS proxy if it dies.
• Sensible default mount options and AZ-aware DNS resolution.

Logs live under /var/log/amazon/efs/, which is the first place to look when a mount fails.

EFS supports two separate layers of encryption.

At rest: tick the encryption option when you create the file system. Data and metadata are encrypted with an AWS KMS key, either the AWS managed key aws/elasticfilesystem or your own customer managed key. You cannot turn it on later for an existing file system.

In transit: mount with -o tls through the EFS mount helper, so traffic between client and mount target is encrypted with TLS.

To encrypt an existing unencrypted file system, create a new encrypted one and copy the data across with AWS DataSync or AWS Backup restore.

Attach a security group to each mount target that allows inbound TCP 2049 from your clients. The cleanest way is to reference the client security group as the source instead of using CIDR ranges.

Network ACLs on the subnets must also allow 2049 in both directions, including ephemeral ports for the return traffic.

The standard way is AWS Backup. Automatic backups are enabled by default when you create a file system through the console, with a daily schedule and a 35-day retention in the default plan.

Backups are incremental after the first full copy, and they do not consume your file system's throughput or burst credits. You can also build your own plans with custom schedules, cross-Region copies and cross-account copies.

To restore, you can bring back the whole file system or only specific files and directories, into a new or an existing file system.

EFS Replication creates and maintains a read-only copy of a file system in another AWS Region or in the same Region. Changes are copied continuously in the background, and most changes show up at the destination within minutes, with a recovery point objective of 15 minutes.

It is configured on the source, and the destination stays read-only while replication is active. It works for both Regional and One Zone file systems, and the destination can use a different storage configuration.

Typical uses are disaster recovery and keeping a nearby read copy for another Region.

EFS Intelligent-Tiering is a lifecycle setup that moves data in both directions so you do not have to predict access patterns.

1. Files not accessed for a period you choose (for example 30 days) move from Standard to IA.
2. When a file in IA is read again, it moves back to Standard on first access.

The second rule is the important one. Without it, a file that becomes popular again keeps incurring the IA per-GB access charge. With it, active data returns to Standard and frequently used data ends up billed at the Standard rate.

EFS Archive is the lowest-cost multi-AZ storage class, made for data that is opened only a few times a year, such as old project files, logs kept for audits, or historical datasets.

You reach it through lifecycle policies: a file can go from Standard to IA and then on to Archive after a set number of days without access. Reads still use the same NFS path, so applications do not need to change.

The trade-off is a higher per-GB access charge than IA, so it only pays off for data that truly stays cold. Check the current throughput-mode prerequisites in the docs before you enable it.

Lambda can mount an EFS file system so functions read and write a shared, persistent directory instead of the 512 MB-by-default /tmp.

1. Put the function in a VPC that has a mount target for the file system.
2. Create an EFS access point for the function.
3. Add the file system configuration to the function, with the access point ARN and a local mount path that starts with /mnt/.
4. Give the execution role the elasticfilesystem:ClientMount permission, plus ClientWrite if it writes.

Use it for large ML models, shared libraries and data that must outlive an invocation.

You define an EFS volume in the task definition and mount it into one or more containers, so tasks share persistent storage.

"volumes": [{
  "name": "shared-data",
  "efsVolumeConfiguration": {
    "fileSystemId": "fs-0123456789abcdef0",
    "transitEncryption": "ENABLED",
    "authorizationConfig": { "accessPointId": "fsap-0abc...", "iam": "ENABLED" }
  }
}]

Then reference the volume in mountPoints on the container. On Fargate you need platform version 1.4.0 or later. The task role needs the EFS client permissions, and the task's security group must reach the mount target on port 2049.

Install the Amazon EFS CSI driver (aws-efs-csi-driver) as an add-on. It lets pods use EFS through PersistentVolume and PersistentVolumeClaim objects with the ReadWriteMany access mode, which many pods across nodes can share.

Two provisioning styles exist:

• Static - you create the PV pointing at an existing file system or access point.
• Dynamic - a StorageClass creates an EFS access point per PVC automatically.

Pods on Fargate can only use static provisioning. Worker nodes need network access to the mount target, and IAM permissions for the driver are granted through IAM Roles for Service Accounts.

EFS publishes metrics under the AWS/EFS namespace. The ones that matter most:

Alarm on a falling BurstCreditBalance and a high PercentIOLimit before users notice slowness.

Put these on a dashboard and set alarms. A common pattern is one alarm on BurstCreditBalance for Bursting file systems and another on PercentIOLimit for General Purpose file systems.

You pay for what you use, across a few dimensions:

• Storage - per GB-month, at different rates for Standard, IA, Archive and the One Zone classes.
• Data access - a per-GB charge when reading from or writing to IA and Archive data.
• Throughput - Elastic bills per GB read and written, Provisioned bills for throughput above what your storage size already includes, and Bursting has no extra charge.
• Extras - replication data transfer, AWS Backup storage and cross-AZ or cross-Region traffic.

There is no upfront cost or minimum fee for the file system itself.

EBS is block storage normally attached to one EC2 instance in one AZ. EFS is a shared file system that thousands of clients can mount at once across AZs.

Choose EBS for low-latency single-host workloads, and EFS when several servers must see the same files.

S3 is object storage accessed over HTTP APIs, while EFS is a POSIX file system accessed through NFS mounts.

If the application expects to open() and append to a file, use EFS. If it stores large, immutable objects or serves content to the internet, use S3.

Many teams use both: EFS as the working area for active jobs and S3 as the cheap, durable home for finished output, with DataSync moving data between them.

FSx is a family of managed file systems, each built around a specific engine. EFS is a single NFS service tuned for Linux and elastic scaling.

Pick EFS when you want no capacity planning on Linux. Pick FSx when you need SMB, HPC throughput or specific NetApp or ZFS features.

Operations differ too. EFS has nothing to size, while FSx file systems are created with a chosen capacity and, for most types, a throughput setting that you manage.

With Elastic throughput, EFS scales performance up and down automatically based on what the workload needs, and you pay per GB transferred. There is nothing to size or monitor.

With Provisioned throughput, you pick a fixed MiBps. The file system can always drive that amount regardless of how much data it stores, and you pay for the portion above what your storage size would give you in Bursting mode.

Elastic suits spiky, unpredictable traffic. Provisioned tends to be cheaper when the workload uses a steady, high share of its peak throughput (AWS's guidance is an average-to-peak ratio above roughly 5 percent).

You can switch between modes, but after a change you must wait 24 hours before lowering the provisioned value or changing mode again.

Both are chosen at file system creation, and only one of them is still recommended.

Max I/O was meant for massively parallel jobs with thousands of clients, but newer Elastic throughput limits make General Purpose the right answer in almost all cases.

If an interviewer asks which to use today, answer General Purpose, and mention that Max I/O exists for historical reasons. The mode is set once at creation and cannot be changed later.

In Bursting mode, throughput scales with the amount of data in Standard storage. The baseline is 50 MiBps per TiB, and the file system can burst to 100 MiBps per TiB while it has credits. Small file systems can still burst to 100 MiBps.

The credit mechanism works like a bucket:

1. When usage is below the baseline, credits accumulate.
2. When usage goes above the baseline, credits are spent.
3. When the bucket is empty, throughput falls back to the baseline.

Read operations are metered at one third the rate of other operations, so the same allowance supports about three times more read traffic. Watch BurstCreditBalance to see the bucket level.

The performance mode is fixed at creation because it decides how the file system's internal metadata and request paths are laid out, so AWS does not offer an in-place switch.

If you picked the wrong one, the route is to create a new file system with the right mode and copy the data over. AWS DataSync handles that well and keeps permissions and timestamps. Alternatively restore an AWS Backup recovery point into a new file system.

In practice this rarely hurts, because the default, General Purpose, suits almost every workload. By contrast, throughput mode can be changed on a live file system.

Choose One Zone when the data is cheap to recreate or an AZ outage is acceptable, and the lower price matters.

Good fits:

• Development and test environments.
• Scratch space, build caches and intermediate processing output.
• Secondary copies where the master lives elsewhere.

Stay with Regional for production data, anything that must survive an AZ failure, and workloads whose clients are spread across AZs. A One Zone file system has one mount target, so clients in other AZs pay cross-AZ traffic and see higher latency. For best results, run your clients in the same AZ as the file system.

One Zone also has its own infrequent-access class, One Zone-IA, so lifecycle savings still apply inside a single AZ.

EFS layers two checks, and both must allow the request.

Network and IAM level: the security group decides who can reach the mount target. If you mount with -o iam, the client signs requests with its IAM identity, and EFS evaluates identity policies and the file system policy using actions such as elasticfilesystem:ClientMount, ClientWrite and ClientRootAccess.

File level: once mounted, regular POSIX owner, group and mode bits decide who can read, write or execute each file. Access points can override the client's identity with a fixed UID and GID.

A common hardening step is a file system policy with a aws:SecureTransport condition so only TLS mounts are allowed.

When you mount with -o tls, the EFS mount helper starts a local proxy process on the client (stunnel in older versions, the EFS proxy in version 2.0 and later). The NFS client connects to that proxy on 127.0.0.1, and the proxy opens a TLS connection to the mount target on port 2049.

So the NFS traffic on your machine stays local and everything that crosses the network is encrypted.

The watchdog in amazon-efs-utils monitors the proxy and restarts it if it stops. Keep in mind that TLS needs the mount helper. A plain mount -t nfs4 does not encrypt the traffic.

On-premises servers reach EFS through a private connection into your VPC, using AWS Direct Connect or AWS Site-to-Site VPN. EFS does not have a public endpoint.

The steps are straightforward:

1. Connect the data center to the VPC.
2. Allow TCP 2049 from the on-premises CIDR in the mount target security group.
3. Mount using the mount target IP address, because the EFS DNS name will not resolve on-premises by default.

If you want to use DNS names, set up a Route 53 Resolver inbound endpoint and forward queries. The path must be private, and latency is higher than inside the VPC.

A file system can have mount targets in only one VPC at a time, so other VPCs must route to that VPC.

Use VPC peering or an AWS Transit Gateway between the VPCs. Peering also works across accounts and Regions, though cross-Region adds latency and data transfer charges.

Then mount with the mount target IP address of the peered VPC, since the DNS name only resolves inside its own VPC unless extra DNS configuration is added. Allow TCP 2049 in the security group and route tables.

For cross-account, add a file system policy that grants the other account's role the client actions.

The usual tool is AWS DataSync. It copies from on-premises NFS or SMB, other AWS storage, or another EFS file system into EFS, running in parallel and preserving ownership, permissions and timestamps. It can also run on a schedule for ongoing sync.

Other routes:

• rsync or parallel cp from an EC2 instance that has both source and EFS mounted. Run several processes at once, because a single thread is slow.
• AWS Transfer Family to let partners upload over SFTP, FTPS or FTP straight into EFS.
• AWS Backup restore to copy into a new file system, for example to switch to an encrypted one.

Plan a final cut-over sync, then stop writers on the source before switching clients.

A hang almost always means the client cannot reach the mount target on TCP 2049. Work through these checks in order:

1. Security groups - the mount target SG allows inbound 2049 from the client SG, and the client can send outbound 2049.
2. Network ACLs and routes - subnets allow 2049 in both directions.
3. Mount target exists in the client's AZ and is in the available state.
4. DNS - the VPC has enableDnsSupport and enableDnsHostnames on, and fs-id.efs.region.amazonaws.com resolves.
5. Client software - amazon-efs-utils or an NFS 4.x client is installed.

Test connectivity with nc -zv mount-target-ip 2049, then read /var/log/amazon/efs/mount.log for helper errors.

Start by finding which limit you are hitting, then fix that one.

• Throughput mode - in Bursting mode, check BurstCreditBalance. If it is zero you are stuck at baseline, so move to Elastic or Provisioned.
• PercentIOLimit - near 100 percent on a General Purpose file system means the operations limit, so spread load or reconsider the design.
• PermittedThroughput vs MeteredIOBytes - shows whether you are at the ceiling in Provisioned mode.
• Access pattern - many small files, single-threaded copies and fsync after every write all add per-operation latency.
• Client side - old amazon-efs-utils, small rsize and wsize, or cross-AZ mounts.

Overall throughput rises with larger I/O sizes and more parallel threads.

The mount helper applies good defaults. If you use plain NFS, AWS recommends:

nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport

Avoid soft, since a timeout can surface as a write error or silent data loss.

The mount helper sets these for you, so most teams never type them. You need them for plain NFS mounts, for example in custom AMIs or where installing amazon-efs-utils is not possible. noresvport matters most after network interruptions, because it lets the client reconnect from a fresh source port.

EFS provides close-to-open consistency, the same model most NFS clients expect. When one client closes a file after writing, another client that opens it afterwards sees the latest data.

That has a practical meaning. Data written and closed is visible to new opens everywhere. But a client that already has the file open can briefly see cached attributes or data.

Writes are acknowledged only after the data is stored durably across AZs for Regional file systems. If applications need stronger coordination, use file locking or write and then close before readers start.

A practical example: a build server writes an artifact and closes it, then a deploy server opens it. That handoff is safe. A reader that has held the same file open for hours may not see updates until it reopens the file or its NFS attribute cache expires.

EFS supports NFS advisory file locking, using calls such as flock() and fcntl(). Locks are coordinated between clients, so two instances can safely take turns on the same file.

Two caveats matter for interviews. First, locks are advisory: they only work if every process checks them. Nothing stops a program that ignores locks from writing. Second, there are quotas on how many locks can be held, so a design that opens a lock per tiny file at very large scale needs to be checked against the EFS quotas.

Locks are also released when the client disconnects or the lease expires, so a crashed instance does not keep a file locked forever.

The design depends on the file system type.

A Regional file system writes each file across multiple Availability Zones. A write is acknowledged only after the data is stored durably, so losing one AZ does not lose data, and clients in other AZs keep working through their own mount targets. AWS designs it for 99.999999999 percent (11 nines) durability and 99.99 percent availability.

A One Zone file system stores data redundantly inside a single AZ. It has the same 11-nines durability design, but availability is designed for 99.9 percent, and an AZ-wide failure can make the data unavailable or, in a catastrophic event, lost.

To add protection, combine EFS with AWS Backup for point-in-time restore and EFS Replication for a copy in another Region.

Mounting looks like one command, but several steps happen behind it.

sequenceDiagram
    participant C as EC2 client
    participant D as VPC DNS
    participant M as Mount target
    participant E as EFS service
    C->>D: Resolve fs-id.efs.region.amazonaws.com
    D-->>C: IP of mount target in the client's AZ
    C->>M: TCP 2049 (via TLS proxy if -o tls)
    M->>E: NFSv4.1 session and IAM check if -o iam
    E-->>C: Root handle of file system or access point
    C->>E: READ / WRITE file operations

1. The mount helper resolves the DNS name, which returns the mount target IP in the same AZ.
2. With tls, it starts the local proxy and connects through it.
3. Security group, IAM policy and file system policy are evaluated.
4. The client gets the file system root, or the access point directory, and normal POSIX checks apply to each file.

EFS adds a small fixed latency to every operation, so many tiny files hurt more than a few large ones. The fix is to reduce operations and run more of them at once.

• Parallelize - use many threads or processes, for example fpsync or GNU parallel for copies. EFS scales with concurrency.
• Use larger I/O sizes and avoid fsync after each small write unless durability demands it.
• Pick Elastic throughput so bursts are not capped, and use a current amazon-efs-utils version (2.0 or later) for higher per-client throughput.
• Bundle files - pack small files into archives or container images and unpack locally when possible.
• Reduce metadata calls - mount with attribute caching defaults and avoid recursive ls -l or find on huge directories.

Measure with MetadataIOBytes in CloudWatch to confirm metadata is the bottleneck.

Give every tenant its own access point on a shared file system. Each one enforces a separate root directory, such as /tenants/acme, and a separate POSIX UID and GID. The tenant's app sees only that subtree and cannot walk up to other folders.

Set creation info so the directory is created with the right owner and mode. A file system supports up to 10,000 access points by default, so very large tenant counts may need sharding across file systems or a quota increase. For strict compliance, use a separate file system or KMS key per tenant.

The destination file system is read-only while replication is active, so failover means turning it into a normal writable file system.

flowchart LR
    A["Source in Region A"] -->|continuous replication| B["Read-only replica in Region B"]
    A -. outage .-> X["Region A unavailable"]
    B -->|delete replication configuration| C["Replica becomes writable"]
    C --> D["Point clients at Region B"]
    D -->|Region A recovers| E["Replicate back to a file system in Region A"]
    E --> F["Switch clients back"]

1. Failover: delete the replication configuration on the destination. It becomes writable, and you repoint clients and mount targets to it.
2. Failback: when the source Region returns, create a replication from the now-active file system back to the original Region, wait for it to catch up, then move clients back.

Because the recovery point objective is about 15 minutes, a small window of recent changes can be missing after a failover. Test the runbook regularly, and keep mount target IPs or DNS ready in the second Region.

EFS cost is driven by stored GB per class, data access charges and throughput, so tune each.

Track the StorageBytes metric per class and review the Cost Explorer EFS usage types monthly. Be careful with IA for small or busy files, as files under 128 KiB are never moved and busy data pays access fees.

Deleting a file system permanently destroys its data. EFS has no recycle bin, so the only way back is a backup taken earlier.

Here is what to expect:

1. Mount targets must be removed first. The console does this for you, while the CLI and API need it done explicitly.
2. Access points and the file system policy are deleted along with the file system.
3. Replication: if it is configured, delete that configuration first. The replica then becomes a regular writable file system.
4. AWS Backup recovery points are not removed by the deletion. They stay in the vault until their retention period ends, which is what lets you restore later.

Unmount the file system on all clients before deleting it. Because EFS mounts are hard by default, processes that still have it mounted can hang when the endpoint disappears.

Before deleting, take a final on-demand backup, confirm nothing still mounts the file system, and check that no ECS task definition, Lambda function or Kubernetes PV refers to it.