What Is Amazon EFS (Elastic File System)? The Shared NFS Storage Multiple Servers Can Mount — and When to Choose It Over EBS/S3

Amazon EFS (Elastic File System) is AWS's managed shared-disk service — a single file system that many servers can mount and read from simultaneously, growing and shrinking automatically as you add and remove files, with no capacity planning on your part. It runs the NFS protocol (Network File System, the shared-drive standard since the 1980s), scales to petabytes, and is accessible from EC2, ECS, EKS, Lambda, and Fargate. Here's the part almost nobody tells you up front: EFS does not support Windows — at all. Not partially, not with a workaround, not with a compatibility layer. If your servers run Windows, you want FSx for Windows File Server, not EFS. That single fact trips up more first-time EFS users than any throughput setting or storage class decision, because "shared file storage" sounds like it should work everywhere.

Jake's shop had grown past one computer. He now had three — one at the counter, one in the back for inventory, one in the repair bench — and the same problem kept showing up: he'd edit a price list on one machine, walk to the counter, and find the old version still sitting there. The files lived on each machine's own hard drive, and getting them to agree meant USB sticks, cloud sync that lagged, or shouting across the room asking if anyone had the latest version.

"What you're describing is a shared drive," Ethan said. "One place where the files live, and every computer looks at the same place. In AWS, that's EFS. In your shop, it's the filing cabinet behind the counter that everyone walks to."

What EFS Actually Is, in One Paragraph

Amazon Elastic File System provides serverless, fully elastic file storage so that you can share file data without provisioning or managing storage capacity and performance. It is built to scale on demand to petabytes without disrupting applications, growing and shrinking automatically as you add and remove files. It supports the Network File System version 4 protocol (NFSv4.1 and NFSv4.0), so the applications and tools you use today work seamlessly with it. And it is accessible across most types of AWS compute instances, including Amazon EC2, Amazon ECS, Amazon EKS, AWS Lambda, and AWS Fargate.

Three vocabulary words do most of the work in any EFS conversation, so let's define them before they get used:

NFS — Network File System — is the protocol EFS speaks. It's the industry standard for shared file access over a network, originally developed by Sun Microsystems in 1984. If you've used a network-attached drive at an office, you've probably used NFS. NFS runs on port 2049.

Elastic means it grows and shrinks automatically. You never provision a fixed size (unlike EBS, where you specify "100 GB" upfront). EFS starts empty and grows as you add files, with no upper limit you need to plan for.

File storage — as opposed to block storage or object storage — means it works like a regular file system: files and folders, with permissions, file locking, and the hierarchical directory structure you're used to. You can ls it, cd into it, and set chmod permissions on it. This is what makes it different from S3 (object storage, no directories in the traditional sense) and EBS (block storage, attached to one server at a time).

How EFS Actually Works: The Mount Target System

EFS uses a two-part architecture: the file system itself (the actual storage, managed by AWS) and mount targets (network endpoints in your VPC that your servers connect to). Think of it this way: the file system is the filing cabinet; the mount target is the door to the room where the cabinet lives.

When you create an EFS file system, you also create mount targets in the subnets of your VPC. Each mount target gets an IP address in that subnet and a DNS name. Your EC2 instances then connect to the mount target in their Availability Zone over NFS. A Regional (multi-AZ) file system can have mount targets in multiple AZs, so instances in different zones each have a fast, local path to the same data.

Two structural rules worth memorizing because they explain half the errors people hit: an EFS file system can only have mount targets in one VPC at a time, and only one mount target can be created in each Availability Zone. If you need to access the same file system from a different VPC, you use VPC peering or AWS Transit Gateway — you don't create mount targets in the second VPC directly.

The DNS name follows a predictable pattern: file-system-id.efs.region.amazonaws.com. When you mount, you use this DNS name, not an IP address (though IP mounting is possible for advanced cases). The EFS mount helper (a tool called amazon-efs-utils) handles the DNS resolution, TLS encryption, and recommended mount options automatically.

The Windows Question: The Answer Nobody Expects

The reason is the protocol. EFS speaks NFS; Windows speaks SMB. These are two different languages for the same job — shared file access over a network — and they are not interchangeable. AWS's own documentation states it plainly: "Using Amazon EFS with Microsoft Windows–based Amazon EC2 instances is not supported."

"So what do I do for my Windows machines?" Jake asked. "Just... not have shared storage?"

"For Windows, you use FSx for Windows File Server — it's the same idea, different protocol," Ethan said. "For Linux machines, EFS. If you have both, you have both, and they don't talk to each other. It's like having English and French speakers in the same building — they can coexist, but they can't share a filing cabinet unless someone translates."

One more OS detail worth knowing: EFS does support macOS. EC2 Mac instances can mount EFS file systems using the same NFS mount process as Linux. So the compatibility list is: Linux, yes; macOS, yes; Windows, no.

EFS vs EBS vs S3 vs FSx: The Comparison Nobody Gives You in One Table

"aws efs vs ebs vs s3" is one of the most-searched EFS questions because the three services sound similar if you don't know the boundaries. They serve different jobs:

The one-line version: EBS is a hard drive you plug into one server; EFS is a filing cabinet everyone shares; S3 is a warehouse with an API; FSx is a Windows-specific filing cabinet. If your workload needs multiple servers to see the same files at the same time and your servers run Linux, EFS is the answer.

"So for my three shop computers — which one?" Jake asked.

"If they all ran Linux and lived in AWS, EFS. If they run Windows, FSx. If you just need everyone to see the same files from anywhere, and speed doesn't matter much, S3 with a sync tool. The question is never 'which is best' — it's 'which protocol do my computers speak, and how many of them need the same files at the same time.'"

The Storage Classes: Standard, IA, and Archive — Times Two

EFS offers three storage classes, each designed for a different access pattern — and each one exists in a Regional (multi-AZ) version and a cheaper One Zone version. That means the real matrix is six cells, not three rows:

Every one of those three classes can be Regional (data across multiple AZs, higher durability) or One Zone (data in a single AZ, lower cost). The class answers "how often is this file touched"; the type answers "how bad is it if an AZ disappears."

The lifecycle policy is what ties it together: you tell EFS "if a file hasn't been accessed for 30 days, move it to IA," and if that file sits untouched for 90 more days, move it to Archive. If someone accesses it later, it moves back to Standard automatically. You don't manage the moves; the policy does.

"So it's like my filing cabinet," Jake said. "The stuff I use daily is on top. The stuff I look at quarterly goes in the drawer. The stuff I never look at goes in the box in the basement."

"Exactly — and the filing cabinet does the sorting itself," Ethan said. "You don't decide what goes to the basement; the cabinet notices you haven't opened a folder in months and moves it."

Throughput Modes: Elastic, Provisioned, and Bursting

Throughput is how fast you can read and write data, measured in megabytes per second. EFS offers three modes, and the choice changes both performance and billing:

Elastic Throughput is the default and what AWS recommends for most workloads. Performance automatically scales up or down with your workload activity — you get high throughput when you're busy and low throughput when you're idle, and you only pay for the throughput you actually use (data transferred per month). No capacity planning, no minimum.

Provisioned Throughput lets you specify a throughput amount upfront, for workloads with predictable, sustained, high-throughput requirements. You're billed for the throughput you provision, whether you use it or not — this is the "I know I need exactly 500 MB/s, all day, every day" option.

Bursting Throughput is the legacy mode, where you get a baseline throughput proportional to your storage size and can "burst" above it using accumulated credits. It's still supported but is no longer the recommended default — Elastic has replaced it for most use cases.

Performance Modes: General Purpose vs Max I/O

Separate from throughput (how much data per second) is the performance mode, which affects latency and the number of simultaneous connections:

General Purpose is the default and what AWS recommends. It's ideal for latency-sensitive use cases: web serving, content management, home directories, general file serving. Sub-millisecond latencies, up to 35,000 IOPS, and the right choice for 99% of workloads.

Max I/O scales to higher levels of aggregate throughput and operations per second, at the cost of higher per-operation latencies. It's designed for massive parallel access — hundreds or thousands of compute instances hitting the file system simultaneously. If you're running a big data processing job across 500 EC2 instances, Max I/O is your mode. For everyone else, it's a slower version of General Purpose.

On IOPS specifically: EFS does not have an IOPS guarantee the way EBS does. You can't "provision 10,000 IOPS" on EFS. Instead, IOPS scale with your workload and the number of parallel clients — more clients reading simultaneously means more aggregate IOPS, up to hundreds of thousands.

Regional vs One Zone: The Availability Choice

When you create an EFS file system, you choose between two availability types:

Regional (Multi-AZ) — the recommended default. Data is stored redundantly across multiple geographically separated Availability Zones within the same AWS Region. If an entire AZ goes down, your data is still available from the other zones. Higher durability and availability, higher cost.

One Zone (Single-AZ) — data is stored redundantly within a single Availability Zone. Cheaper than Regional, but if that AZ suffers a failure, your data is unavailable (and potentially lost). Suitable for development environments, temporary data, or workloads where the data can be recreated.

One important note on regional scope: EFS is a regional service, not a global one. A file system exists in one AWS Region. You cannot access it from another Region directly — cross-Region access requires EFS Replication (which copies data to a file system in another Region) or a network connection between Regions.

Pricing: What EFS Actually Costs, With Real Numbers

EFS pricing has three parts: storage (per GB per month), throughput (per GB transferred, for Elastic mode), and access (per GB for reads and writes to IA and Archive). There is no minimum fee and no setup charge. All figures below are US East (N. Virginia) rates — regional rates vary, so verify against the live pricing page before quoting any number to a budget-holder.

For EFS Standard storage on a Regional (Multi-AZ) file system with Elastic Throughput, the storage rate is approximately $0.30 per GB per month. For a One Zone file system, it's lower — approximately $0.16 per GB per month, roughly a 47% saving. EFS Infrequent Access costs about $0.025 per GB per month on Regional (less on One Zone), and EFS Archive is lower still.

To make the math concrete: 100 GB of Standard storage on a Regional file system costs roughly $30 per month in storage alone, before throughput charges. With Elastic Throughput, you also pay per GB of data transferred — roughly $0.03 per GB read and $0.06 per GB written.

AWS positions EFS's total cost of ownership as low as $0.0315 per GB per month — but that's the blended rate when you use lifecycle policies to move cold data to IA and Archive. If everything stays in Standard, you pay the full Standard rate. One more cost people forget: accessing an EFS mount target from a different Availability Zone incurs cross-AZ data transfer charges at the standard EC2 rate, so mount in your own AZ.

The AWS Free Tier

The Free Tier terms split on July 15, 2025 — same date as the rest of AWS. If you signed up before that date, you get 5 GB of EFS Standard storage per month free for 12 months, on a Regional file system only (not One Zone). If you sign up after July 15, 2025, you choose a Free Plan or Paid Plan, receive up to $200 in credits usable toward any eligible service including EFS, and have 6 months on the free plan before upgrading.

Cost optimization, in plain terms

1. Enable lifecycle policies. A 30-day policy that moves untouched files to IA can cut storage costs dramatically, because IA costs a fraction of Standard. Most workloads have a long tail of files nobody has opened in months.
2. Use One Zone for dev/test. The 47% cost reduction over Regional is real, and for data you can afford to lose, it's the right trade.
3. Use Elastic throughput. Provisioned throughput charges you whether you use it or not; Elastic charges only for what you transfer.
4. Mount in your own AZ. Cross-AZ access to a mount target bills as data transfer — every time, on every request.

EFS Access Points: The Feature Container Users Actually Live In

An access point is a named entry point into an EFS file system that enforces two things: a root directory (every connection through that access point sees only that subtree, not the whole file system) and an identity (a POSIX user and group that the connection operates as, regardless of who's actually connecting). You can also use them in IAM policies, so you can grant an application permission to use one access point and nothing else.

The problem access points solve is easiest to see with the problem itself: imagine twenty containerized applications sharing one EFS file system. Without access points, each container's mount sees the entire file system, permissions are whatever the container says they are, and one misconfigured app can read (or overwrite) another app's data. With access points, App A connects through an access point rooted at /apps/a running as user 1000, and that is all it can see — the rest of the file system doesn't exist from its perspective, no matter what the container asks for.

"It's the difference between giving someone a key to the building and giving them a key to one drawer," Jake said. "And the drawer pretends to be the whole building."

"That's better than my explanation," Ethan said. "And it's why the Kubernetes story works at all — the CSI driver's dynamic provisioning mode creates an access point per persistent volume claim, which is what keeps tenants separated."

EFS on Kubernetes and EKS: The CSI Driver, and Why ReadWriteMany Matters

If you're running EKS (or any Kubernetes cluster on AWS), here's the fact that decides your storage: EBS volumes mount with ReadWriteOnce; EFS mounts with ReadWriteMany. ReadWriteOnce means one node at a time can mount the volume — fine for a single-pod database, useless for five replicas of the same web app that all need the same files. ReadWriteMany means every pod, on every node, in every AZ, mounts the same file system simultaneously. On AWS, the practical way to get ReadWriteMany for POSIX workloads is EFS.

The bridge between Kubernetes and EFS is the EFS CSI driver (Container Storage Interface — the standard plug-in format Kubernetes uses for external storage). It installs as a controller plus DaemonSet, and once it's running you create a Kubernetes StorageClass with efs.csi.aws.com as the provisioner. Then persistent volume claims work the way you'd expect: claim a volume, and the driver either mounts an existing file system (static provisioning) or creates an access point per claim on a shared file system (dynamic provisioning).

The deployment path, in order:

1. Install the EFS CSI driver — via its Helm chart or the AWS-provided manifest, into your cluster.
2. Create the EFS file system and mount targets in the subnets your worker nodes use (the driver mounts from nodes, so targets must exist in every AZ your nodes span).
3. Create a StorageClass referencing efs.csi.aws.com, either pointing at your file system ID for dynamic provisioning with access points, or used with a pre-provisioned PersistentVolume for static.
4. Create a PersistentVolumeClaim against that StorageClass, and reference it from your pods like any other volume.

One honest caveat for the performance-minded: EFS is slower than EBS for single-client random I/O. If a pod needs a fast local scratch disk, use EBS; if a set of pods needs shared files across nodes and AZs, EFS is the tool. Many clusters end up using both for exactly this reason.

Mounting EFS: Step by Step

Mounting means attaching the file system to your server so it appears as a local directory. On Linux, this is a standard mount operation over NFS. Here's the full path from zero to mounted:

1. Create the file system in the EFS console — choose Regional (recommended), General Purpose performance mode, and Elastic throughput.
2. Create mount targets in the subnets where your EC2 instances live. Each mount target gets an IP address in that subnet.
3. Configure security groups — the EFS mount target's security group must allow inbound NFS (port 2049) from your EC2 instances' security group.
4. Install the EFS mount helper on your EC2 instance: sudo yum install -y amazon-efs-utils (Amazon Linux) or sudo apt-get install amazon-efs-utils (Ubuntu).
5. Mount the file system: sudo mount -t efs -o tls fs-12345678:/ /mnt/efs — where fs-12345678 is your file system ID and /mnt/efs is the mount point.
6. Verify with df -h — you should see the file system mounted with a very large available size (EFS reports a huge number because it has no fixed capacity).

The -o tls flag enables encryption in transit, which wraps your NFS traffic in TLS. AWS recommends it, and it's the default behavior when using the EFS mount helper.

For automatic mounting on boot, add an entry to /etc/fstab using the EFS mount helper format — the mount helper's own fstab syntax handles the DNS resolution and reconnect behavior so a brief network blip at boot doesn't leave the mount hanging. To mount through an access point, add the access point ID to the mount options.

Troubleshooting: The Mount Errors That Actually Happen

EFS mount failures have a small set of causes, and the error message usually names the right one once someone translates it. Organized by what you see:

Two habits prevent most of this table: mount in the same AZ as your instance, and get the security group right the first time — inbound 2049 from the instance's group, nothing wider.

Moving Data In and Out: DataSync, Transfer Family, and the S3 Question

You don't copy terabytes into EFS with cp over a mount — that's slow, billed as throughput, and painful to restart. AWS's intended tool for bulk movement is AWS DataSync, a managed transfer service that moves data between EFS and S3, between EFS file systems, and between on-premises storage (via a small agent VM) and EFS, with scheduling, bandwidth limits, and integrity verification built in. If you're migrating an existing NFS server to EFS or draining an EFS file system into S3 for archival, DataSync is the answer.

For human-style access over the internet, the AWS Transfer Family can front an EFS file system with SFTP — your users and partners connect with their existing SFTP clients and land directly in the file system, with per-user identities mapped to POSIX users. That's the "does EFS support SFTP?" answer: not natively, but Transfer Family is the AWS-blessed bridge.

And the "EFS to S3" question is usually really a "should this data live in EFS at all" question. Files that are written once and read as whole objects belong in S3 at a fraction of the price; files that applications open, seek, lock, and partially rewrite belong in EFS. A common lifecycle: data is born in EFS while an application works on it, and DataSync drains the finished output to S3 for cheap long-term keeping.

Security: Encryption, IAM, and Network Access

EFS security has three layers, and they stack:

Encryption at rest is enabled when you create the file system — you choose a KMS key (either an AWS-managed key or your own customer-managed key in AWS KMS). Once enabled, all data and metadata is encrypted. You cannot enable it after creation; if you need it, you create a new file system with it on.

Encryption in transit is enabled at mount time using the -o tls option with the EFS mount helper. This wraps the NFS connection in TLS, protecting data between your EC2 instance and the EFS mount target.

IAM, network, and identity access control work together. IAM policies control who can manage EFS resources (creating, deleting, modifying) and can also gate the mount operation itself when using IAM authorization. Security groups control which EC2 instances can reach the mount target on port 2049. Access points enforce application-level identity and root directories, as covered above. And EFS supports root squash — mapping the root user to an anonymous identity so a privileged client can't run roughshod over file ownership. On top of all of it, you can block public access at the file-system level; EFS file systems are not publicly reachable by default, and the setting exists to guarantee it stays that way.

Backup and Replication: Protecting Your Data

EFS does not have built-in snapshots the way EBS does. Instead, backup is handled through AWS Backup, a centralized service that manages backups across AWS services. You can enable automatic backups with a daily schedule and a retention period, and you pay for the backup storage you use plus the amount you restore.

For disaster recovery or geographic redundancy, EFS Replication copies your file system to another Region or another AWS account. You pay the prevailing storage rates for both source and destination file systems, plus data transfer between Regions. The replication is continuous — changes on the source are automatically copied to the destination. Note the direction of the bill, too: replication traffic between Regions is billed at inter-Region data transfer rates, which is usually the expensive part.

Terraform and the CLI: The Resource Names You're Searching For

For infrastructure-as-code, the three Terraform resources that make up a complete EFS deployment are aws_efs_file_system, aws_efs_mount_target (one per AZ, attached to the file system and a subnet), and aws_efs_access_point (optional, for the identity/root-directory enforcement covered earlier). A file system policy — for IAM-based mount authorization or root squash — is aws_efs_file_system_policy.

On the CLI side, the commands that matter day to day: aws efs create-file-system, aws efs create-mount-target --file-system-id fs-xxxx --subnet-ids subnet-yyyy --security-groups sg-zzzz, and aws efs describe-file-systems to list what exists. describe-mount-targets gives you the IP and state of each target — the first thing to check when a mount starts failing in one AZ and not another.

What EFS Is Actually Used For: Real Workloads

The use cases cluster around one requirement: multiple servers needing the same files at the same time.

Web serving. Multiple web servers behind a load balancer all serving the same static content — images, CSS, JavaScript — from one EFS file system. Add a server, mount the same file system, done. No content sync problems.

Container storage. Kubernetes pods (via the EFS CSI driver) or ECS tasks that need persistent shared storage. One EFS file system backs many pods, so data survives container restarts and is shared across replicas.

Machine learning training. Training data and model checkpoints on EFS, so multiple training instances can read the same dataset and write results without copying data around.

Home directories. User home directories on EFS, mounted by whatever EC2 instance a user connects to — so your files follow you regardless of which server you land on.

Lambda shared state. AWS Lambda functions can mount EFS, giving serverless code access to a persistent file system — useful for large ML models or data that's too big for Lambda's /tmp.

Media processing. Video rendering farms where multiple workers need access to source files and write completed output to the same location.

The EFS Interview Questions You'll Actually Get

If you're preparing for an AWS interview, these are the EFS questions that come up, with the answers in the shape interviewers want:

"EFS vs EBS vs S3 — when would you use each?" EBS for boot volumes and single-instance block storage; EFS for shared file access across multiple Linux instances; S3 for object storage over an API. The differentiator to name out loud: attachment model — one server vs. many servers vs. no server.

"What protocol does EFS use, and what does that mean for Windows?" NFSv4 over port 2049 — and Windows isn't supported because it speaks SMB. The follow-up they're fishing for: FSx for Windows File Server is the Windows answer.

"How does EFS achieve high availability?" Regional file systems store data redundantly across multiple AZs, with a mount target in each AZ so instances always have a local path. One Zone trades that away for cost.

"How does EFS scale?" Automatically — elastic capacity to petabytes, no provisioning; throughput scales with Elastic mode or can be fixed with Provisioned.

"What's a mount target?" A VPC-network endpoint (IP + DNS name) in a subnet that instances connect to over NFS; one per AZ, and a file system's targets live in only one VPC at a time.

"How do you secure EFS?" Layered: KMS encryption at rest (set at creation), TLS in transit (set at mount), security groups on the mount target, IAM policies for management and mount authorization, access points for per-application identity and root directory, root squash for privileged clients.

When You Should NOT Use EFS

Some walls are real, and naming them saves you a bad architecture decision:

Windows workloads. Not supported. Use FSx for Windows File Server.

Databases. EFS is not designed for the low-latency, high-IOPS, block-level access patterns databases need. Use EBS or a managed database service.

Single-server storage. If only one instance needs the data, EBS is cheaper and faster. EFS's value is in the sharing.

Object-style access patterns. If your application reads and writes discrete objects via an API (rather than a file system), S3 is dramatically cheaper and more scalable for that pattern.

FAQ

What is the full form of EFS in AWS?

Elastic File System. The "elastic" refers to automatic scaling — it grows and shrinks as you add and remove files, with no capacity provisioning.

Does AWS EFS support Windows?

No. EFS supports Linux and macOS EC2 instances via the NFS protocol. Windows is not supported. For Windows shared storage, use Amazon FSx for Windows File Server, which speaks the SMB protocol Windows uses natively.

Is AWS EFS serverless?

Yes. AWS describes EFS as "serverless, fully elastic file storage." You create a file system and mount targets; AWS manages all storage infrastructure, including scaling, patching, and maintenance.

Is AWS EFS regional or global?

Regional. An EFS file system exists in one AWS Region and cannot be accessed directly from other Regions. Cross-Region access requires EFS Replication or network connectivity between Regions.

Is AWS EFS encrypted by default?

No — encryption at rest is optional and enabled at file system creation. You choose a KMS key when creating the file system. Encryption in transit is enabled at mount time using the -o tls option with the EFS mount helper.

What is the difference between EFS and EBS?

EBS is block storage attached to one EC2 instance at a time (with a fixed size you provision). EFS is file storage shared by many instances simultaneously (with elastic capacity that grows automatically). EBS is for boot volumes and databases; EFS is for shared file access across servers.

What is the difference between EFS and S3?

EFS is a file system with directories, permissions, and file locking, accessed via NFS. S3 is object storage with an HTTP API, no traditional file system semantics. EFS is more expensive but gives you POSIX-compatible file access; S3 is cheaper and scales infinitely but doesn't support file locking or standard file operations.

How much does AWS EFS cost?

Standard storage on a Regional file system runs roughly $0.30 per GB per month (US East). One Zone is cheaper at about $0.16 per GB. Infrequent Access is about $0.025 per GB. Archive is lower still. Elastic throughput adds per-GB transfer charges. AWS positions the blended TCO as low as $0.0315/GB when using lifecycle tiering.

Does AWS EFS have a free tier?

Yes — 5 GB of EFS Standard storage per month for 12 months, on Regional file systems only (not One Zone). This applies to accounts created before July 15, 2025. Accounts created after that date receive $200 in AWS credits instead, usable toward any service including EFS.

What protocol does AWS EFS use?

NFS version 4 (NFSv4.1 and NFSv4.0) over port 2049. This is why Windows is not supported — Windows uses SMB, not NFS.

What is an EFS mount target?

A network endpoint in your VPC that EC2 instances connect to for EFS access. Each mount target lives in a subnet with an IP address. Regional file systems can have mount targets in multiple Availability Zones — but only one per AZ, and all of a file system's mount targets must be in one VPC.

What is an EFS access point?

A named entry point into a file system that enforces a root directory (the connection only sees that subtree) and a POSIX identity (the connection operates as a specified user/group). Used heavily by containers and serverless workloads to isolate applications sharing one file system, and usable in IAM policies.

Can AWS Lambda access EFS?

Yes. Lambda functions can mount EFS file systems, giving serverless code access to persistent shared storage. This is useful for large ML models, shared state across invocations, or data too large for Lambda's /tmp directory.

What is the EFS CSI driver?

The Container Storage Interface driver for Kubernetes. It lets pods on EKS (or any K8s cluster on AWS) mount EFS as persistent volumes with ReadWriteMany access — the mode EBS can't provide — using either static provisioning against a file system or dynamic provisioning that creates an access point per claim.

What is the equivalent of EFS in Azure?

Azure Files. It's the managed shared-file service in Azure, supporting both SMB and NFS. In Google Cloud, the equivalent is Filestore.

Does EFS support IOPS guarantees?

No. EFS does not have IOPS provisioning like EBS. Instead, IOPS scale with the number of parallel clients and workload activity — more simultaneous readers means more aggregate IOPS, up to hundreds of thousands.

Revision note. Written September 2026. Pricing figures are US East rates and will drift — verify against the live pricing page before committing to a number. If you have been squinting at three AWS storage services trying to figure out which one is the "shared drive," the answer was EFS all along — and now you know exactly when to use it, when not to, and why Windows was never invited to the party.