> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt > Use this file to discover all available pages before exploring further. # EFS > AWS EFS. Presents an NFS file system that many instances and containers mount at once, growing and shrinking as files are written and deleted. **On this page** * [Coverage by target cloud](#coverage-by-target-cloud) * [How the targets compare](#how-the-targets-compare) * [Infrastructure-only adaptation](#infrastructure-only-adaptation) * [On Google Cloud](#on-google-cloud) * [On Azure](#on-azure) * [On OCI](#on-oci) * [On Private Kubernetes](#on-private-kubernetes) ## Coverage by target cloud | Target | Available | | ------------------ | --------- | | Google Cloud | ✓ | | Azure | ✓ | | OCI | ✓ | | Private Kubernetes | ✓ | ## 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 | Capability | EFS | Google Cloud | Azure | OCI | Private Kubernetes | | ---------------------------------------- | ----------------------------------------------------------------------------------- | ----------------------------------------------- | ----------------------------------------------- | ------------------------------------------------------------------- | ----------------------------------------------------------------------- | | NFS protocol version · POSIX / RWX | NFS v4.1 | NFS v3 | NFS v4.1 (premium FileStorage) | NFS v3 | - | | Elastic capacity · growth model | elastic; grows per use, no size | provisioned per tier (1 TiB minimum) | provisioned quota (100 GiB minimum) | elastic; grows to 8 EiB, no size | - | | Throughput model · how throughput scales | bursting / elastic / provisioned modes | depends on tier and capacity (ENTERPRISE) | scales with the provisioned quota | scales automatically with used capacity | - | | Access-point POSIX identity | Yes - server-side (uid/gid + root dir) | Partial - client-side subpath + securityContext | Partial - client-side subpath + securityContext | Partial - server-enforced primary uid/gid; no isolated subdirectory | - | | Encryption at rest + CMK | Yes - KMS key | Yes - Cloud KMS CMEK | Yes - Key Vault customer-managed key | Yes - OCI Vault customer-managed key | - | | Encryption in transit | Yes - TLS mount | No - none on NFS v3; private VPC IP | Partial - TLS via AZNFS mount helper | Yes - TLS 1.2 via oci-fss-utils | - | | Availability topology · failure domain | regional; every AZ in the region | regional / multi-zone (ENTERPRISE) | single-zone (LRS); ZRS in select regions | - | - | | Lifecycle tiering + replication | Yes - IA/Archive + cross-region | No - no equivalent on the instance | No - no equivalent on the share | No - separate OCI data-protection configuration | - | | Backup / snapshots · data protection | AWS Backup (aws\_efs\_backup\_policy) | Filestore backups + snapshots | Share snapshots; separately scheduled backup | FSS snapshots + clones | - | | API coverage | full | high | high | high | minimal | | Availability topology · failure domain | regional; multiple availability zones | - | - | single availability domain | - | | Share protocol · POSIX / RWX | NFS v4.1 (POSIX, ReadWriteMany) | - | - | - | NFS (v4.x / v3) RWX PersistentVolume | | Management model · managed vs self-host | fully managed, elastic, multi-AZ | - | - | - | self-hosted on the cluster; your customer owns capacity, HA, and backup | | Capacity model · elastic vs backed | elastic; grows/shrinks automatically | - | - | - | bounded by the backing PV / block storage the NFS server sits on | | Access points · per-app entry | aws\_efs\_access\_point: enforced user/group IDs (uid/gid) + root directory per app | - | - | - | subPath / per-PVC directory + fsGroup on the pod securityContext | | Encryption at rest · backing storage | encrypted + kms\_key\_id (EFS at rest) | - | - | - | inherited from the backing block storage's encryption | | Backup · self-managed | aws\_efs\_backup\_policy → AWS Backup | - | - | - | customer-run backup of the NFS PV (e.g. Velero + volume snapshots) | ## On Google Cloud | Operation | Area | Support | Depth | Notes | | --------------------------------------------------------------------------------- | --------------- | ------------ | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | EFS control plane (CreateFileSystem / CreateMountTarget / PutBackupPolicy / …) | Control plane | Out of scope | Full surface | provisioning happens through your infrastructure-as-code at apply, not runtime EFS API calls | | Encryption at rest (encrypted + kms\_key\_id) | Data at rest | Supported | Common | encrypted at rest by default; a customer kms\_key\_id maps to a CMEK via Cloud KMS (kms\_key\_name) on the ENTERPRISE tier | | Encryption in transit | Data in transit | Out of scope | Most usage | NFS v3 on Filestore has no in-transit encryption; the instance is reached at a private IP on your VPC, so the traffic stays on your private network | | Lifecycle tiering + replication (transition\_to\_ia / replication\_configuration) | Data management | Out of scope | Full surface | EFS Infrequent-Access/Archive tiering + cross-region replication have no Filestore analog; Filestore has its own backups + snapshots | | NFS mount + POSIX file operations | Data plane | Supported | Common | the instance serves NFS v3; reads, writes, and POSIX permissions behave the same, ReadWriteMany from many pods at once (the common POSIX surface) | | Access point (aws\_efs\_access\_point) | Identity | Partial | Most usage | no per-instance access-point object; posix\_user uid/gid + root\_directory become a mount subpath + the pod securityContext (Filestore's NFSv3 export options have no rich per-export identity-squash config) | | Mount target (aws\_efs\_mount\_target) | Mount endpoint | Partial | Most usage | the per-AZ mount targets collapse to the instance's own IP address on your VPC; pods mount \:/\ over the private VPC IP | | File system provisioning (aws\_efs\_file\_system) | Provisioning | Supported | Common | compiles to a native google\_filestore\_instance on the ENTERPRISE tier (regional/multi-zone) with one NFS file\_shares export on your VPC network | #### 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 `:/`. 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 | Operation | Area | Support | Depth | Notes | | --------------------------------------------------------------------------------- | --------------- | ------------ | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | EFS control plane (CreateFileSystem / CreateMountTarget / PutBackupPolicy / …) | Control plane | Out of scope | Full surface | provisioning happens through your infrastructure-as-code at apply, not runtime EFS API calls | | Encryption at rest (encrypted + kms\_key\_id) | Data at rest | Supported | Common | encrypted at rest by default; a customer kms\_key\_id maps to a storage-account customer-managed key in Key Vault | | Encryption in transit | Data in transit | Partial | Most usage | Azure Files supports TLS for NFS through the AZNFS mount helper; clients and the storage-account encryption setting must be configured | | Lifecycle tiering + replication (transition\_to\_ia / replication\_configuration) | Data management | Out of scope | Full surface | EFS Infrequent-Access/Archive tiering + cross-region replication have no premium-share analog; schedule share snapshots separately | | NFS v4.1 mount + POSIX file operations | Data plane | Supported | Common | the share speaks the same NFS v4.1 dialect as EFS: reads, writes, locking, rename, and POSIX permissions all behave the same, ReadWriteMany from many pods at once | | Access point (aws\_efs\_access\_point) | Identity | Partial | Most usage | no per-share access-point object; posix\_user uid/gid + root\_directory become a mount subpath + the pod securityContext (fsGroup/runAsUser), with the export's root-squash policy governing client root | | Mount target (aws\_efs\_mount\_target) | Mount endpoint | Partial | Most usage | the per-AZ mount targets collapse to one share endpoint (\.file.core.windows.net) reached over a private endpoint in your VNet; a per-AZ mount IP resolves to the one endpoint | | File system provisioning (aws\_efs\_file\_system) | Provisioning | Supported | Common | compiles to a native azurerm\_storage\_share (enabled\_protocol=NFS) on a Premium FileStorage account of the equivalent quota | #### 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, `.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 `.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 | Operation | Area | Support | Depth | Notes | | --------------------------------------------------------------------------------- | --------------- | ------------ | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | EFS control plane (CreateFileSystem / CreateMountTarget / PutBackupPolicy / …) | Control plane | Out of scope | Full surface | provisioning happens through your infrastructure-as-code at apply, not runtime EFS API calls | | Encryption at rest (encrypted + kms\_key\_id) | Data at rest | Supported | Common | encrypted at rest by default; a customer kms\_key\_id maps to a customer-managed key via OCI Vault (kms\_key\_id on the file system) | | Encryption in transit | Data in transit | Partial | Most usage | OCI FSS supports in-transit encryption for NFS mounts over TLS 1.2 (the oci-fss-utils client package); the mount target also lives on a private subnet in your VCN | | Lifecycle tiering + replication (transition\_to\_ia / replication\_configuration) | Data management | Out of scope | Full surface | EFS lifecycle tiers and replication\_configuration are not mapped; OCI has separately configured snapshots, clones, and asynchronous file-system replication | | NFS mount + POSIX file operations | Data plane | Supported | Common | the export serves NFS v3; reads, writes, and POSIX permissions behave the same, ReadWriteMany from many instances at once (the common POSIX surface) | | Access point (aws\_efs\_access\_point) | Identity | Partial | Most usage | export options enforce the primary uid/gid through identity\_squash=ALL and anonymous\_uid/gid; an export path names the file-system root and does not reproduce an access point's isolated subdirectory | | Mount target (aws\_efs\_mount\_target) | Mount endpoint | Supported | Most usage | an oci\_file\_storage\_mount\_target is a VNIC in a subnet in an availability domain, serving the network-mount role of EFS mount targets; pods mount the mount-target IP + export path | | File system provisioning (aws\_efs\_file\_system) | Provisioning | Supported | Common | compiles to a native oci\_file\_storage\_file\_system + oci\_file\_storage\_mount\_target + oci\_file\_storage\_export, an elastic FSS file system with a mount endpoint | #### 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](/service-adapters/catalog).