Skip to main content
On this page

​
Coverage by target cloud

​
How the targets compare

Each row compares a capability of EFS with its adaptation on each target. A dash means this row is not stated for that target.

​
Infrastructure-only adaptation

​
On Google Cloud

​
How it works

Your pods share files through a Filestore ENTERPRISE instance. Tensor9 maps aws_efs_file_system to google_filestore_instance, with one file_shares NFS export on the customer VPC. Multiple pods mount the export directly. Google operates the storage. This mapping uses NFS v3, a regional instance, and provisioned capacity. Application reads and writes go directly to Filestore.
The aws_efs_file_system compiles to a native Filestore ENTERPRISE instance with one NFS export on your VPC network, mounted directly, with no proxy in the data path.The aws_efs_file_system compiles to a native Filestore ENTERPRISE instance with one NFS export on your VPC network, mounted directly, with no proxy in the data path.

The aws_efs_file_system compiles to a native Filestore ENTERPRISE instance with one NFS export on your VPC network, mounted directly, with no proxy in the data path.

​
Architecture

EFS uses a mount target in each availability zone. Filestore provides one instance IP address, exposed as networks[].ip_addresses[0]. Pods mount <ip>:/<share>. The instance IP is private and reached through the customer VPC. Application mounts use that address instead of separate EFS mount-target addresses.
EFS's per-AZ mount targets collapse to the Filestore instance's own IP on your VPC network; every pod mounts the one instance IP.EFS's per-AZ mount targets collapse to the Filestore instance's own IP on your VPC network; every pod mounts the one instance IP.

EFS’s per-AZ mount targets collapse to the Filestore instance’s own IP on your VPC network; every pod mounts the one instance IP.

​
NFS protocol and locking

This mapping uses NFS v3; EFS uses NFS v4.1. Shared file access, ownership, and POSIX mode bits remain available. Filestore also offers NFS v4.1, but that is a different configuration from the one described here. NFS v3 handles locks through Network Lock Manager (NLM); NFS v4.1 has integrated lease-based locking and different client-recovery behavior. Test workloads that rely on locks or reconnect after node failure. NFS ACLs and delegations are not lost EFS capabilities: EFS itself does not support them.
The mapped NFS v3 export preserves shared POSIX access but uses different locking and client-recovery behavior from EFS.The mapped NFS v3 export preserves shared POSIX access but uses different locking and client-recovery behavior from EFS.

The mapped NFS v3 export preserves shared POSIX access but uses different locking and client-recovery behavior from EFS.

​
Provisioned capacity

The mapped ENTERPRISE instance is provisioned from 1 TiB (1024 GiB) and scales in steps up to 10 TiB. Increase provisioned capacity as data grows; EFS adjusts capacity automatically. Throughput and IOPS depend on the selected tier and provisioned capacity. Size the instance for storage and performance together; EFS’s separate throughput modes do not map directly to this configuration.
EFS grows per use with no size; a Filestore ENTERPRISE instance is provisioned from a 1 TiB minimum up to 10 TiB, and its throughput and IOPS scale with the tier and capacity.EFS grows per use with no size; a Filestore ENTERPRISE instance is provisioned from a 1 TiB minimum up to 10 TiB, and its throughput and IOPS scale with the tier and capacity.

EFS grows per use with no size; a Filestore ENTERPRISE instance is provisioned from a 1 TiB minimum up to 10 TiB, and its throughput and IOPS scale with the tier and capacity.

​
Regional availability: the ENTERPRISE match

Filestore ENTERPRISE replicates data across multiple zones and has a published 99.99% availability SLA. This provides regional storage for applications that use EFS Standard’s multi-zone availability. The mapping selects ENTERPRISE for regional availability. BASIC and ZONAL instances are single-zone configurations with different outage coverage.
EFS Standard is regional across every AZ; the Filestore ENTERPRISE tier is regional too, replicated across zones in the region with a 99.99% availability SLA.EFS Standard is regional across every AZ; the Filestore ENTERPRISE tier is regional too, replicated across zones in the region with a 99.99% availability SLA.

EFS Standard is regional across every AZ; the Filestore ENTERPRISE tier is regional too, replicated across zones in the region with a 99.99% availability SLA.

​
Access points and POSIX identity

An EFS access point enforces a user/group identity and root directory on the server. Filestore has no matching access-point resource. The application mounts root_directory as a subpath, while pod securityContext settings such as fsGroup and runAsUser set its identity. Pod and mount configuration control application identity in this mapping. They do not provide the same server-enforced per-application boundary as an EFS access point. Review permissions and mount access when several applications share an export.
Filestore has no access-point object; the access point's posix identity and root directory become a mount subpath plus the pod's securityContext, a weaker mapping than a managed object.Filestore has no access-point object; the access point's posix identity and root directory become a mount subpath plus the pod's securityContext, a weaker mapping than a managed object.

Filestore has no access-point object; the access point’s posix identity and root directory become a mount subpath plus the pod’s securityContext, a weaker mapping than a managed object.

​
Encryption and network reach

Filestore encrypts stored data by default. An EFS customer-managed kms_key_id maps to a Cloud KMS key through kms_key_name on the ENTERPRISE instance. The mapped NFS v3 export does not encrypt traffic. It uses a private VPC address. Filestore’s optional NFS v4.1 configuration supports Kerberos encryption, but requires separate authentication and mount configuration.
At-rest encryption and a customer key map to Cloud KMS on ENTERPRISE; but NFS v3 has no encryption in transit, so the instance is reached at a private VPC IP.At-rest encryption and a customer key map to Cloud KMS on ENTERPRISE; but NFS v3 has no encryption in transit, so the instance is reached at a private VPC IP.

At-rest encryption and a customer key map to Cloud KMS on ENTERPRISE; but NFS v3 has no encryption in transit, so the instance is reached at a private VPC IP.

​
Limitations

Filestore supplies shared POSIX access, regional storage, and customer-managed encryption at rest. The following differences affect protocol behavior, capacity, and application permissions. △ Where AWS EFS and GCP Filestore diverge
  • NFS v3 locking. The mapped export uses separate NLM lock management. Test locking and client recovery during migration; shared POSIX access remains available.
  • Capacity is provisioned from a 1 TiB minimum. ENTERPRISE is provisioned at a 1 TiB (1024 GiB) minimum and bills on provisioned capacity where EFS is provision-free; growing means raising the capacity in fixed steps to 10 TiB, and there is no separate throughput mode, since throughput scales with the tier and capacity.
  • No encryption in transit on NFS v3. The export does not encrypt on the wire the way EFS’s TLS mount does; the instance is reached at a private IP on your VPC so the traffic stays on your network instead.
  • No managed access-point object, and NFS v3 export controls are limited. The access point’s posix identity and root directory become a mount subpath plus the pod’s securityContext, and Filestore’s NFS v3 export has no rich per-export identity-squash configuration, so this is a weaker mapping than a managed object the client must go through.
  • Per-AZ mount targets collapse to one instance IP. A mount that expected a specific per-AZ mount IP resolves to the instance’s own IP on your VPC (networks[].ip_addresses[0]); the file tree remains unchanged.
  • EFS lifecycle tiering and replication have no Filestore analog. EFS’s Infrequent-Access / Archive lifecycle policies and cross-region replication are AWS-managed features; the ENTERPRISE instance stores on its single provisioned tier. Filestore has its own backups and snapshots, managed separately.

​
Other considerations

Stop writes while copying EFS files to the new export. Preserve file ownership, permissions, and paths, then test locks and client reconnection before switching application mounts.

​
On Azure

​
How it works

Your pods share files through an Azure Files NFS v4.1 share. Tensor9 maps aws_efs_file_system to azurerm_storage_share with enabled_protocol = "NFS" on a Premium FileStorage account. Multiple pods mount the share and use ordinary POSIX file operations. Tensor9 provisions the share; applications access it directly. Microsoft operates the storage, and the share determines read and write throughput. Capacity follows a provisioned quota, and the customer chooses the redundancy configuration.
The aws_efs_file_system compiles to a native Azure Files NFS v4.1 share on a Premium FileStorage account: the same NFS v4.1 protocol EFS speaks, mounted directly, no proxy in the data path.The aws_efs_file_system compiles to a native Azure Files NFS v4.1 share on a Premium FileStorage account: the same NFS v4.1 protocol EFS speaks, mounted directly, no proxy in the data path.

The aws_efs_file_system compiles to a native Azure Files NFS v4.1 share on a Premium FileStorage account: the same NFS v4.1 protocol EFS speaks, mounted directly, no proxy in the data path.

​
Architecture

EFS provides a mount target in each availability zone. Azure Files uses one share endpoint, <account>.file.core.windows.net. Every application mount resolves to that endpoint. The share is reached through a private endpoint in the customer virtual network. Network rules deny public access. For encrypted NFS traffic, configure the AZNFS mount helper and the storage-account encryption setting; the private endpoint alone does not encrypt a connection.
EFS's per-AZ mount targets collapse to one storage account plus one share, reached at a single endpoint over a private endpoint in your VNet.EFS's per-AZ mount targets collapse to one storage account plus one share, reached at a single endpoint over a private endpoint in your VNet.

EFS’s per-AZ mount targets collapse to one storage account plus one share, reached at a single endpoint over a private endpoint in your VNet.

​
Provisioned capacity

EFS grows and shrinks as files change. This mapping uses an Azure premium share with a provisioned quota, from 100 GiB to 100 TiB. Increase the quota as data grows. Under this provisioned-capacity model, baseline IOPS and throughput scale with the quota. Size it for both data volume and required performance. EFS’s separate bursting, elastic, and provisioned throughput modes do not map directly to this configuration.
EFS grows per use with no size; an Azure premium share is provisioned to a quota, and its IOPS and throughput scale with that quota.EFS grows per use with no size; an Azure premium share is provisioned to a quota, and its IOPS and throughput scale with that quota.

EFS grows per use with no size; an Azure premium share is provisioned to a quota, and its IOPS and throughput scale with that quota.

​
Access points and POSIX identity

An EFS access point enforces a user/group identity and root directory on the server. Azure Files has no matching access-point resource. The application mounts root_directory as a subpath, while pod securityContext settings such as fsGroup and runAsUser set its identity. The share supports root-squash settings that control how a client root identity is treated. These settings and pod configuration do not create EFS’s per-application access-point boundary. Review the mount configuration for applications that share a volume but require separate access.
Azure Files has no access-point object; the access point's posix identity and root directory become a mount subpath plus the pod's securityContext, with root-squash governing client root.Azure Files has no access-point object; the access point's posix identity and root directory become a mount subpath plus the pod's securityContext, with root-squash governing client root.

Azure Files has no access-point object; the access point’s posix identity and root directory become a mount subpath plus the pod’s securityContext, with root-squash governing client root.

​
Encryption and network reach

Azure Files encrypts stored data by default. An EFS customer-managed kms_key_id maps to a storage-account customer-managed key in Azure Key Vault. Azure Files supports NFS encryption in transit through TLS. Install and configure the AZNFS mount helper on clients and set the storage-account requirement for NFS encryption. Keep the private endpoint and network restrictions as well.
Azure Files uses Key Vault for customer-managed encryption at rest and the AZNFS helper for TLS mounts.Azure Files uses Key Vault for customer-managed encryption at rest and the AZNFS helper for TLS mounts.

Azure Files uses Key Vault for customer-managed encryption at rest and the AZNFS helper for TLS mounts.

​
Availability and durability

Locally redundant storage (LRS) keeps three copies within one zone. Zone-redundant storage (ZRS) distributes copies across zones and is available for premium shares in supported regions. Choose a region with premium ZRS when the workload needs protection from a zone outage. An LRS share protects against disk and node failure within its zone; recovery from a whole-zone outage requires a separate plan.
EFS Standard is regional across every AZ; a premium share is single-zone (LRS) by default, with zone-redundant storage available for premium shares only in select regions.EFS Standard is regional across every AZ; a premium share is single-zone (LRS) by default, with zone-redundant storage available for premium shares only in select regions.

EFS Standard is regional across every AZ; a premium share is single-zone (LRS) by default, with zone-redundant storage available for premium shares only in select regions.

​
Limitations

Azure Files provides shared POSIX access over NFS v4.1 and customer-managed encryption at rest. The following differences affect storage sizing, access controls, and recovery. △ Where AWS EFS and Azure Files diverge
  • Capacity is provisioned, not provision-free. A premium share has a quota (100 GiB minimum) and bills on provisioned size where EFS bills only for stored bytes; growing means raising the quota, and there is no separate throughput mode; baseline throughput scales with the quota.
  • TLS client configuration. NFS encryption in transit requires the AZNFS mount helper and the storage-account encryption setting.
  • Single-zone (LRS) by default. A premium share is locally redundant within one zone; EFS Standard is regional across every AZ. Zone-redundant (ZRS) premium shares exist only in select regions; pick one to match EFS’s multi-zone durability.
  • No managed access-point object. The access point’s per-app posix identity and root directory become a mount subpath plus the pod’s securityContext (fsGroup / runAsUser), enforced by how the pod mounts rather than a share-side boundary the client cannot bypass.
  • Per-AZ mount targets collapse to one share endpoint. A mount that expected a specific per-AZ mount IP resolves to the single <account>.file.core.windows.net endpoint; the file tree remains unchanged.
  • EFS lifecycle tiering and replication have no share analog. EFS’s Infrequent-Access / Archive lifecycle policies and cross-region replication are AWS-managed features; the premium share stores on its single provisioned tier and is not cross-region replicated by this mapping. NFS shares support snapshots, but Azure Backup does not cover them; schedule snapshots and additional backup separately.

​
Other considerations

Stop writes while copying EFS files to the new share. Preserve file ownership, permissions, and paths, then test application mounts before switching traffic.

​
On OCI

​
How it works

Your application shares files through an OCI File Storage export. Tensor9 creates an oci_file_storage_file_system, an oci_file_storage_mount_target, and an oci_file_storage_export. Pods mount the export directly at the mount-target IP address. Oracle operates the storage. The mapped file system grows as data is written, serves NFS v3, and resides in one availability domain in the customer virtual cloud network (VCN).
The aws_efs_file_system compiles to a native OCI File Storage file system, mount target, and export. The pods mount the export directly at the mount-target IP, with nothing of Tensor9 in the data path.The aws_efs_file_system compiles to a native OCI File Storage file system, mount target, and export. The pods mount the export directly at the mount-target IP, with nothing of Tensor9 in the data path.

The aws_efs_file_system compiles to a native OCI File Storage file system, mount target, and export. The pods mount the export directly at the mount-target IP, with nothing of Tensor9 in the data path.

​
Architecture

The file system holds the data. The mount target supplies a virtual network interface (VNIC) and IP address in a subnet. The export publishes the file system at a path and applies its export_options. Applications mount the export through the mount-target IP address. The mount target determines its availability domain, and export options control how client identities are handled.
EFS's file system plus per-AZ mount targets become three OCI resources in your VCN: a file system, a mount-target VNIC in one availability domain, and an export that publishes it.EFS's file system plus per-AZ mount targets become three OCI resources in your VCN: a file system, a mount-target VNIC in one availability domain, and an export that publishes it.

EFS’s file system plus per-AZ mount targets become three OCI resources in your VCN: a file system, a mount-target VNIC in one availability domain, and an export that publishes it.

​
Elastic capacity

OCI File Storage grows as files are written, up to 8 EiB, and bills for stored data. No capacity quota must be reserved before applications write. This preserves the automatic capacity growth used with EFS. The Azure Files and Filestore configurations described here require provisioned capacity.
EFS grows per use with no size; OCI File Storage is elastic the same way, to a maximum of 8 EiB, with no capacity to reserve in advance.EFS grows per use with no size; OCI File Storage is elastic the same way, to a maximum of 8 EiB, with no capacity to reserve in advance.

EFS grows per use with no size; OCI File Storage is elastic the same way, to a maximum of 8 EiB, with no capacity to reserve in advance.

​
Access points and export options

The mapping sets identity_squash = "ALL" and takes anonymous_uid and anonymous_gid from the EFS access point’s posix_user. The emitted export path identifies the file system; it does not select a directory within it. The export maps client user/group IDs to the configured anonymous_uid and anonymous_gid for file operations. This preserves the enforced primary identity used by the EFS access point. It does not reproduce the access point’s restricted root directory. A client-side subdirectory mount does not provide that isolation; use separate file systems or an appropriate export layout when applications must be separated.
OCI export options enforce primary user/group IDs. The export path names the file-system root; it does not isolate an application subdirectory.OCI export options enforce primary user/group IDs. The export path names the file-system root; it does not isolate an application subdirectory.

OCI export options enforce primary user/group IDs. The export path names the file-system root; it does not isolate an application subdirectory.

​
NFS protocol and locking

The mapped OCI export uses NFS v3, while EFS uses NFS v4.1. Applications retain shared POSIX file access, ownership, and permission bits. NFS v3 uses Network Lock Manager (NLM) for byte-range locks. NFS v4.1 integrates lease-based locking and handles client recovery differently. Test lock use and reconnection after node failure. EFS itself does not support NFS ACLs or delegations.
The mapped NFS v3 export preserves shared POSIX access but uses different locking and client-recovery behavior from EFS.The mapped NFS v3 export preserves shared POSIX access but uses different locking and client-recovery behavior from EFS.

The mapped NFS v3 export preserves shared POSIX access but uses different locking and client-recovery behavior from EFS.

​
Availability within one domain

OCI File Storage replicates data within one availability domain. EFS Standard distributes data across availability zones in a region. The mapped OCI file system protects against storage-node and disk failures within its availability domain. Plan recovery separately for an outage of the whole domain.
EFS Standard is regional across availability zones; an FSS file system and its mount target live in one availability domain, replicated within the AD but not region-wide.EFS Standard is regional across availability zones; an FSS file system and its mount target live in one availability domain, replicated within the AD but not region-wide.

EFS Standard is regional across availability zones; an FSS file system and its mount target live in one availability domain, replicated within the AD but not region-wide.

​
Encryption and network reach

OCI File Storage encrypts stored data by default. An EFS customer-managed kms_key_id maps to a customer-managed key in OCI Vault through the file system’s kms_key_id. TLS 1.2 encryption for NFS mounts uses the oci-fss-utils client package. The mount target is also reached through a private subnet in the customer VCN. EFS lifecycle tiers and replication settings are not mapped. OCI provides snapshots, clones, and asynchronous file-system replication to another availability domain or region as separate configuration.
OCI Vault supplies the customer-managed key. Configure oci-fss-utils for TLS on the NFS client.OCI Vault supplies the customer-managed key. Configure oci-fss-utils for TLS on the NFS client.

OCI Vault supplies the customer-managed key. Configure oci-fss-utils for TLS on the NFS client.

​
Limitations

OCI File Storage provides elastic capacity, shared POSIX access, export identity settings, and customer-managed encryption at rest. The following differences affect protocol behavior and availability. △ Where AWS EFS and OCI File Storage diverge
  • Access-point directory isolation. Export options enforce primary user/group IDs, but an export path does not restrict clients to a subdirectory.
  • NFS v3 locking. The mapped export uses separate NLM lock management. Test locking and client recovery during migration; shared POSIX access remains available.
  • One availability domain, not regional. An FSS file system and its mount target live in a single availability domain, replicated within it; EFS Standard is regional across availability zones, so a whole-AD loss is not covered the way EFS covers a whole-AZ loss. Weigh this where the availability target is strict.
  • In-transit encryption is opt-in via a client package. FSS supports NFS-over-TLS 1.2 only through the oci-fss-utils package on the client; without it, the mount relies on the mount target’s private subnet for isolation, not on-the-wire encryption.
  • Data protection requires OCI configuration. EFS IA/Archive lifecycle tiers are not reproduced. OCI snapshots, clones, and asynchronous replication are configured separately; verify the destination and recovery procedure for an availability-domain or regional outage.

​
Other considerations

Stop writes while copying EFS files to the new export. Preserve file ownership, permissions, and paths, then test root and non-root client access before switching mounts.

​
On Private Kubernetes

​
Shared file access

A Kubernetes ReadWriteMany (RWX) NFS volume lets multiple pods access the same files, matching the shared POSIX access pattern used with EFS. The application mounts the volume and performs file operations through NFS; no Tensor9 adapter processes those reads and writes.

​
Storage configuration

The customer supplies the NFS server or RWX-capable storage provisioner and PersistentVolume. A private Kubernetes cluster does not have one universal managed file service or guaranteed RWX StorageClass, so this mapping uses the cluster’s storage arrangement rather than creating a separate file server for each EFS resource.

​
Capacity and availability

The customer manages capacity, high availability, backups, and recovery. Storage size follows the backing volume, and throughput depends on the NFS server and its storage. Encryption at rest comes from the backing storage rather than an EFS-managed key.

​
Migration

Provision the RWX storage, configure the application mount, and copy the data during a period when writes are stopped. Preserve file ownership, permissions, and paths, then test access from every pod that shares the volume. AWS EFS management APIs are not served by this mapping. Service Catalog.