- Coverage by target cloud
- How the backends compare
- On Google Cloud
- On Azure
- On OCI
- On Private Kubernetes
- Debug this service
Coverage by target cloud
How the backends compare
Each row compares a capability of EFS with its adaptation on each backend. A dash means this row is not stated for that backend.Infrastructure-only adaptation
On Google Cloud
How it works
Your pods share files through a Filestore ENTERPRISE instance. Tensor9 mapsaws_efs_file_system to a google_filestore_instance with one file_shares NFS export on your VPC network. Many pods can mount the export at once and use ordinary POSIX file operations.
Your applications read and write Filestore directly, and Google operates the storage. Three things differ from EFS and are covered below: the export uses NFS v3 rather than v4.1, capacity is provisioned rather than automatic, and the instance is regional across zones, as EFS Standard is.
Your EFS file system becomes a Filestore ENTERPRISE instance that your pods mount directly over NFS v3.
Mount endpoint
EFS gives you a mount target in each availability zone. Filestore has one private IP address on your VPC network, shown asnetworks[].ip_addresses[0], and pods mount <ip>:/<share>. Code that read a per-zone mount target’s DNS name or IP address gets that one address instead. The mount targets’ security groups and fixed IP addresses are not kept.
EFS’s per-zone mount targets become one private IP address that every pod mounts.
NFS protocol and locking
This mapping uses NFS v3; EFS uses NFS v4.1. Shared file access from many nodes, file ownership and POSIX mode bits work the same. Filestore also offers NFS v4.1, but this mapping does not use it. NFS v3 handles locks through the separate Network Lock Manager (NLM) protocol, while NFS v4.1 builds lease-based locking into the protocol and recovers clients differently. Test workloads that rely on locks or that reconnect after a node fails. NFS ACLs and delegations are not lost: EFS does not support them either.
The mapped NFS v3 export preserves shared POSIX access but uses different locking and client-recovery behavior from EFS.
Capacity and performance
EFS grows and shrinks as files change. A Filestore ENTERPRISE instance has a provisioned capacity and bills on it. This mapping creates the instance at 1 TiB (1024 GiB), the minimum; it grows in steps up to 10 TiB, and you raise it as your data grows. Throughput and IOPS follow the tier and the provisioned capacity, so size the instance for storage and performance together. EFS’s bursting, elastic and provisioned throughput modes, and the older Max I/O performance mode, have no equivalent setting on the instance.
EFS grows with use; a Filestore ENTERPRISE instance has a provisioned capacity, starting at 1 TiB.
Availability
Filestore ENTERPRISE replicates data across multiple zones in the region and has a published 99.99% availability SLA, so it covers the loss of a zone as EFS Standard does. This mapping always uses ENTERPRISE for that reason; the BASIC and ZONAL tiers keep data in a single zone.
Like EFS Standard, Filestore ENTERPRISE is replicated across zones in the region.
Access points and POSIX identity
An EFS access point makes the server enforce a user and group ID and a root directory. Filestore has no access-point resource, and its NFS v3 export settings cannot force a per-export identity. Instead, the application mounts theroot_directory as a subpath, and the pod’s securityContext (fsGroup, runAsUser) sets its identity.
These settings are enforced by how each pod mounts the export, not by Filestore, so they do not give the per-application isolation an access point does. Only the file system’s primary access point is reflected; any others are not reproduced. Review permissions when several applications share an export.
Filestore has no access point: its user, group and root directory are set by how the pod mounts the export.
Encryption and network access
Filestore encrypts stored data by default with a Google-managed key. A customer-managed key is not used: if your EFS file system names akms_key_id, the instance still uses the Google-managed key.
NFS v3 traffic is not encrypted, where EFS can mount over TLS. Pods reach the instance at its private address on your VPC, so the traffic stays on your private network. Filestore’s NFS v4.1 option supports Kerberos encryption, but it needs separate authentication and mount setup and is not part of this mapping.
Stored data is encrypted with a Google-managed key; NFS v3 traffic is not encrypted.
Limitations
Shared POSIX access and regional, multi-zone storage work the same way. These differences affect protocol behaviour, capacity, encryption and permissions. Where AWS EFS and Filestore differ- NFS v4.1 is not supported. The export uses NFS v3, which handles locks through the separate NLM protocol and recovers clients differently. Test locking and reconnection during migration; shared POSIX access works the same.
- Capacity behaves differently: it is provisioned. The instance is created at the 1 TiB (1024 GiB) minimum and bills on provisioned capacity, where EFS bills for data stored. You raise it in steps up to 10 TiB; throughput follows tier and capacity, with no separate throughput mode.
- Encryption in transit is not supported. NFS v3 traffic is not encrypted the way an EFS TLS mount is. Pods reach the instance at a private IP on your VPC, so the traffic stays on your network.
- Customer-managed encryption keys are not supported. An EFS
kms_key_idis not used; the instance is encrypted at rest with the Google-managed key. - Access points behave differently: there is no access-point resource. The primary access point’s user, group and root directory become a mount subpath and the pod’s
securityContext; Filestore’s NFS v3 export cannot force an identity. Additional access points are not reproduced. - Per-zone mount targets are not supported. Every mount uses the instance’s single private IP (
networks[].ip_addresses[0]). The mount targets’ security groups and fixed IP addresses are not kept; the file tree is unchanged. - Lifecycle tiering and replication are not supported. EFS Infrequent Access and Archive tiers and cross-region replication have no Filestore equivalent; the instance stores everything on one provisioned tier. Filestore has its own backups and snapshots, which you manage separately.
- You must declare the file system statically, in the root module. A file system created with
countorfor_each, or declared inside a child module, stops the deployment with an error. Acounton its mount targets or access points works; they become the one instance.
Other considerations
Moving from AWS. The new instance starts empty; creating it does not copy EFS data. Stop writes while you copy files to the export, and preserve ownership, permissions and paths. Point the mount at the private export address, and test locks and client reconnection before you switch application mounts.On Azure
How it works
Your pods share files through an Azure Files NFS v4.1 share, the same protocol version EFS uses. Tensor9 mapsaws_efs_file_system to an azurerm_storage_share with enabled_protocol = "NFS" on a Premium FileStorage storage account. Many pods can mount the share at once and use ordinary POSIX file operations.
Tensor9 creates the share; your applications read and write it directly, so throughput is the share’s own. Microsoft operates the storage. The share has a provisioned size rather than growing on its own, which the capacity section covers.
Your EFS file system becomes an Azure Files NFS share that your pods mount directly, over the same NFS v4.1 protocol.
Mount endpoint
EFS gives you a mount target in each availability zone. Azure Files has one endpoint for the share,<account>.file.core.windows.net, and every mount uses it. Code that read a specific per-zone mount target’s DNS name or IP address gets that one endpoint instead. The mount targets’ security groups and fixed IP addresses are not kept.
The share is reached through a private endpoint in your virtual network, and network rules block public access. The private endpoint does not encrypt the NFS connection; the encryption section covers that.
EFS’s per-zone mount targets become one share endpoint, reached through a private endpoint in your virtual network.
Capacity and performance
EFS grows and shrinks as files change. An Azure premium share has a quota, from 100 GiB to 100 TiB, and bills on that provisioned size. This mapping creates the share at 100 GiB, the minimum. You raise the quota as your data grows. A premium share’s baseline IOPS and throughput grow with its quota, so size it for both data and performance. EFS’s bursting, elastic and provisioned throughput modes, and the older Max I/O performance mode, have no equivalent setting on the share.
EFS grows with use; an Azure premium share has a quota, and its performance grows with that quota.
Access points and POSIX identity
An EFS access point makes the server enforce a user and group ID and a root directory. Azure Files has no access-point resource. Instead, the application mounts theroot_directory as a subpath, and the pod’s securityContext (fsGroup, runAsUser) sets its identity. The share’s root-squash setting controls how a client’s root user is treated.
These settings are enforced by how each pod mounts the share, not by the share itself, so they do not give the per-application isolation an access point does. Only the file system’s primary access point is reflected; any others are not reproduced. Review the mounts of applications that share a volume but need separate access.
Azure Files has no access point: its user, group and root directory are set by how the pod mounts the share.
Encryption and network access
Azure Files encrypts stored data by default with a Microsoft-managed key. A customer-managed key is not used: if your EFS file system names akms_key_id, the share still uses the Microsoft-managed key.
Azure Files supports TLS encryption for NFS traffic. To use it, install and configure the AZNFS mount helper on your clients and turn on the storage account’s NFS encryption requirement. Keep the private endpoint and network rules as well; on their own they do not encrypt the connection.
The share is encrypted at rest with a Microsoft-managed key; TLS for NFS needs the AZNFS mount helper.
Availability
EFS Standard replicates data across every availability zone in the region. This mapping creates the storage account as locally redundant storage (LRS), which keeps three copies within one zone. It protects against disk and node failures in that zone, but not against losing the whole zone. Azure also offers zone-redundant storage (ZRS) for premium shares in some regions, but this mapping does not select it. Plan recovery from a zone outage separately.
EFS Standard spans every zone in the region; the share this mapping creates is locally redundant in one zone.
Limitations
Shared POSIX access over NFS v4.1 works the same way. These differences affect sizing, access control, encryption and recovery. Where AWS EFS and Azure Files differ- Capacity behaves differently: the share has a quota. The share is created at the 100 GiB minimum and bills on its provisioned size, where EFS bills for data stored. You raise the quota as data grows; throughput grows with the quota, with no separate throughput mode.
- Customer-managed encryption keys are not supported. An EFS
kms_key_idis not used; the share is encrypted at rest with the Microsoft-managed key. - You must configure TLS on clients. NFS encryption in transit needs the AZNFS mount helper on each client and the storage account’s encryption setting.
- Zone redundancy is not supported. The storage account is locally redundant (LRS), within one zone, where EFS Standard spans every zone in the region.
- Access points behave differently: there is no access-point resource. The primary access point’s user, group and root directory become a mount subpath and the pod’s
securityContext, enforced by how the pod mounts rather than by the share. Additional access points are not reproduced. - Per-zone mount targets are not supported. Every mount uses the single
<account>.file.core.windows.netendpoint. The mount targets’ security groups and fixed IP addresses are not kept; the file tree is unchanged. - Lifecycle tiering and replication are not supported. EFS Infrequent Access and Archive tiers and cross-region replication have no equivalent on the share. NFS shares support snapshots, but Azure Backup does not cover them; schedule snapshots and other backups yourself.
- You must declare the file system without
countorfor_each. A file system created withcountorfor_eachstops the deployment with an error. Acounton its mount targets or access points works; they become the one share.
Other considerations
Moving from AWS. The new share starts empty; creating it does not copy EFS data. Stop writes while you copy files to the share, and preserve ownership, permissions and paths. Test your application’s mounts before you switch traffic.On OCI
How it works
Your application shares files through an OCI File Storage export. Tensor9 creates anoci_file_storage_file_system, an oci_file_storage_mount_target and an oci_file_storage_export in your virtual cloud network (VCN). Pods mount the export directly at the mount target’s IP address and use ordinary POSIX file operations.
Oracle operates the storage. Like EFS, the file system grows as data is written. Unlike EFS, it uses NFS v3 and lives in one availability domain rather than across the region.
Your EFS file system becomes an OCI File Storage export that your pods mount directly over NFS v3.
Mount target and export
The file system holds the data. The mount target is a network interface with an IP address in your private subnet, in one availability domain; EFS’s per-zone mount targets all become this one address. The export publishes the file system at apath and applies its export_options.
On AWS, the security groups on your mount targets decide who can mount. Those are not kept. Instead, the export allows read and write access from the deployment’s private subnet. Check that this matches the clients you meant to allow: a client in that subnet that your security groups excluded can now mount, and a client outside it that they allowed cannot.
The file system holds the data, the mount target gives it an IP address, and the export publishes it.
Capacity and performance
OCI File Storage grows as files are written, up to 8 EiB, and bills for the data stored. As with EFS, there is no capacity to set before applications write. Throughput grows automatically with the amount of data stored. EFS’s bursting, elastic and provisioned throughput modes, and the older Max I/O performance mode, have no equivalent setting.
Like EFS, OCI File Storage grows as you write, with no capacity to set in advance.
Access points and export options
The mapping takesanonymous_uid and anonymous_gid from the EFS access point’s posix_user and sets identity_squash = "ROOT". Requests from a client’s root user run as that user and group. Requests from other users keep their own IDs. An EFS access point applies its identity to every request, so on OCI a non-root client process is not forced to the access point’s user.
The access point’s root_directory becomes the export path, which names the export but still publishes the whole file system; it does not limit clients to that directory. Mounting a subdirectory on the client does not add that limit either. Only the primary access point is mapped; any others are not reproduced. Use separate file systems when applications must be kept apart.
Requests from a client’s root user take the access point’s IDs; the export path does not limit clients to a subdirectory.
NFS protocol and locking
The OCI export uses NFS v3; EFS uses NFS v4.1. Shared file access from many nodes, file ownership and permission bits work the same. NFS v3 handles byte-range locks through the separate Network Lock Manager (NLM) protocol, while NFS v4.1 builds lease-based locking into the protocol and recovers clients differently. Test locking and reconnection after a node fails. NFS ACLs and delegations are not lost: EFS does not support them either.
Shared POSIX access works the same over NFS v3, but locking and client recovery differ from EFS.
Availability
EFS Standard keeps data across the availability zones in a region. An OCI file system and its mount target are in one availability domain, and the data is replicated within it. That protects against disk and storage-node failures, but not against losing the whole domain. OCI can replicate a file system asynchronously to another availability domain or region, set up separately. To recover outside the source domain, you need such a replica and a tested recovery procedure.
EFS Standard spans the region; an OCI file system and its mount target are in one availability domain.
Encryption and network access
OCI File Storage encrypts stored data by default with an Oracle-managed key. A customer-managed key is not kept: if your EFS file system names akms_key_id, the file system still uses the Oracle-managed key.
For encrypted NFS traffic, install the oci-fss-utils package on clients, which mounts over TLS 1.2. Without it, traffic is not encrypted; the private subnet limits who can reach the mount target but does not encrypt the connection.
Stored data is encrypted with an Oracle-managed key; TLS for NFS needs oci-fss-utils on clients.
Limitations
Shared POSIX access and automatic capacity growth work the same way. These differences affect identity, protocol behaviour, encryption and availability. Where AWS EFS and OCI File Storage differ- Access points behave differently: only a client’s root user is remapped. The export uses
identity_squash = "ROOT"with the access point’s IDs, so other users keep their own IDs. The export path does not limit clients to the access point’s directory. Additional access points are not reproduced. - NFS v4.1 is not supported. The export uses NFS v3, which handles locks through the separate NLM protocol and recovers clients differently. Test locking and reconnection during migration; shared POSIX access works the same.
- Region-wide availability is not supported. The file system and mount target are in one availability domain and replicated within it, so losing the whole domain is not covered the way EFS covers losing a zone.
- Customer-managed encryption keys are not supported. An EFS
kms_key_idis not used; the file system is encrypted at rest with the Oracle-managed key. - You must install oci-fss-utils for encryption in transit. OCI supports NFS over TLS 1.2 only through the
oci-fss-utilsclient package. Without it, the mount relies on the private subnet for isolation, and traffic is not encrypted. - Mount-target security groups are not supported. The export allows read and write access from the deployment’s private subnet instead. Check that scope against the clients your security groups allowed.
- Lifecycle tiering and replication are not supported. EFS Infrequent Access and Archive tiers are not reproduced. OCI snapshots, clones and asynchronous replication are set up separately; check the destination and recovery procedure for a domain or regional outage.
- You must declare the file system and its parts without
countorfor_each. On OCI, acountorfor_eachon the file system, its mount targets or its access points stops the deployment with an error.