Tried AWS updates from KubeCon NA 2026 week: FSx for ONTAP S3 Access Points on Fargate, Nitro Sandbox, Security Groups for Pods

Summary of results

AWS announced several container and storage updates during KubeCon + CloudNativeCon North America 2026 (2026-11-09 to 2026-11-12, Salt Lake City, CNCF announcement). I tried the three that matter when containers use data on Amazon FSx for NetApp ONTAP (FSx for ONTAP).

1. More Regions for FSx for ONTAP S3 Access Points (2026-11-09, What's New: new Regions). Four Regions were added, and the announcement says Amazon ECS and AWS Fargate can use the feature. The announcement does not name the Regions; the user guide lists them.
2. AWS Nitro Sandboxes (2026-11-09, What's New: Nitro Sandboxes). A Nitro Sandbox runs one Pod in its own lightweight virtual machine. I tested it on Amazon EKS. Amazon ECS also supports it for tasks on ECS Managed Instances; I did not test that.
3. Security groups for Pods in EKS Auto Mode (2026-11-11, What's New: Auto Mode security groups for Pods). In EKS Auto Mode, AWS manages the worker nodes. Security groups for Pods attach security groups to individual Pods.

S3 Access Points let applications read and write the files on an FSx for ONTAP volume through the S3 API, while other clients keep using NFS or SMB on the same files. No copy is made. The feature became generally available on 2025-12-02 (What's New: GA). Only the Region expansion in item 1 came out during KubeCon week.

This post records hands-on tests of using FSx for ONTAP data from Fargate and from EKS isolated Pods. It is for people who use FSx for ONTAP data from containers and want to decide whether Fargate, isolated Pods, and security groups for Pods belong in their design. I ran the tests in ap-northeast-1 (Tokyo) on a temporary SVM and temporary volumes. I ran each test once and did not repeat it.

I have five results.

1. Containers on Amazon ECS and Amazon EKS on Fargate could write, read, and list objects through an access point (2026-11-10). When I mounted the same volume over NFS from an EC2 instance, the objects written through the S3 API appeared as ordinary files.
2. On a file system with 128 MBps of throughput capacity, Fargate writes of 8 MiB objects with 16 parallel requests levelled off at about 130 MB/s for every task size from 0.5 to 8 vCPU. Reads were 276 to 557 MB/s (2026-11-12). The write limit equals what I measured earlier from EC2 with the same script (129.4 MB/s).
3. In an EKS isolated Pod, an NFS PersistentVolume (PV) created by NetApp Trident failed to mount (2026-11-10). The same isolated Pod could call an access point with the S3 SDK, using either EKS Pod Identity or IRSA for credentials. On a node built from a custom AMI with the Nitro Sandbox runtime, an iSCSI PV also mounted (both on 2026-11-12).
4. Security groups for Pods in EKS Auto Mode limited the outbound traffic of a Pod that calls an access point to S3 only. A Kubernetes NetworkPolicy controlled traffic between Pods. The security groups and the NetworkPolicy each blocked a different client Pod (2026-11-12).
5. The access point's origin decides which services can call it. Compute that runs in your VPC, such as Fargate, can call an access point with VPC origin. AWS-managed services such as Amazon Athena and Amazon Bedrock need an access point with Internet origin. You cannot change the origin after you create the access point.

I hit two errors on the way. First, the access point policy in my CloudFormation template was rejected with Invalid policy. Second, the SVM could not find the UNIX user I had set on the access point, and the access point status became FAILED about 45 seconds after creation. The error messages and timings are in "The two errors I hit", so that you do not stop at the same places. I checked the linked pages again on 2026-11-12.

How to read this post

• Only the results: this section is enough.
• Terms: "Terms used in this post"
• Whether Fargate works: "Test 1: reading and writing from ECS and EKS on Fargate"
• Performance: "Throughput from Fargate tasks"
• Isolated Pods: "Test 2: Nitro Sandbox isolated Pods and FSx for ONTAP storage"
• Limiting Pod traffic: "Test 3: security groups for Pods and NetworkPolicy in Auto Mode"
• Which services can call an access point: "AWS services that can call an access point"
• Testing in your own environment: "Steps to check in your own environment"

Terms used in this post

If FSx for ONTAP or Kubernetes storage is new to you, these are the terms this post uses.

I also refer to three other repositories of mine:

• S3-Burst-on-ONTAP-Files: access point throughput measured from EC2. The benchmark script in this post comes from there.
• FSx-for-ONTAP-S3AccessPoints-Serverless-Patterns: tests with a Windows user as the file system identity.
• fsxn-lakehouse-integrations: tests of analytics services such as Athena and Snowflake with access points.

The templates and test records for this post are in FSx-for-ONTAP-Container-Datastore-Patterns.

Test dates are in Japan time (JST). Update dates are the What's New publication dates. The 503 window is given in UTC and JST. Throughput in MB/s means 10^6 bytes per second; object sizes in MiB mean 2^20 bytes.

Introduction

Some applications that move to containers still need data on an FSx for ONTAP volume. A container on an EC2 instance can use an NFS mount on the host. A Pod on an EKS EC2 node can use a PV created by Trident. Fargate, however, has no way to mount an FSx for ONTAP volume. The Amazon ECS documentation says that only EC2 can mount FSx for ONTAP directly, and that Fargate reaches FSx for ONTAP data through S3 Access Points (Storage options for Amazon ECS tasks, checked on 2026-11-11).

Before using S3 Access Points from containers, you probably want answers to five questions:

1. Can a Fargate task really read and write through an access point, and what errors come up?
2. How much throughput does one Fargate task get?
3. Can the new isolated Pods use FSx for ONTAP data?
4. How do you limit the network traffic of a Pod that calls an access point?
5. Which other services can call an access point?

In an earlier post (Amazon S3 Files speed and monthly cost, measured, in Japanese), I measured the speed and monthly cost of Amazon S3 Files and FSx for ONTAP S3 Access Points and wrote about when each fits. This post covers only S3 Access Points: how to use them from containers, and which services can use them.

What this post covers, and what it does not

Covered

• Reading and writing from ECS and EKS on Fargate, and the two errors I hit.
• How file permissions are checked when the file system identity is not root, so that root does not end up in production.
• Throughput from Fargate tasks and isolated Pods, as a starting point for sizing.
• Which storage types worked in an EKS isolated Pod, because a design that needs both isolation and data on FSx for ONTAP depends on it.
• How security groups for Pods and NetworkPolicy split the work.
• The AWS services that can call an access point, because you must choose the origin before you create it.
• How access points differ from on-premises ONTAP, because a design that gives each S3 user different permissions there cannot be copied as it is.

Not covered

• Performance on Multi-AZ, second-generation, or other throughput capacities. I measured only one first-generation, Single-AZ file system with 128 MBps.
• A Windows (NTFS) domain account. I could not join the SVM to Active Directory (AD), so the test could not continue ("What I have not checked yet").
• A cost estimate. I did not check current prices for this post.

How a container reaches FSx for ONTAP data

Figure 1: The path from a container to an FSx for ONTAP volume

In this setup, the Fargate container does not mount a file system. The application calls the access point directly with the S3 SDK. An ECS task gets AWS credentials from its task role. An EKS Pod gets them through IRSA. EKS Pod Identity does not support Pods on Fargate, so I used IRSA for the Fargate tests (Pod Identity considerations). Pods on EC2 nodes can use Pod Identity, and the isolated Pod tests below use it.

Test 1: reading and writing from ECS and EKS on Fargate

I ran these tests on 2026-11-10 in the Tokyo Region. On an existing test file system (Single-AZ, 128 MBps throughput capacity), I created a temporary SVM and a 1 GiB volume. The volume uses the UNIX security style, so permissions are UNIX mode bits. I did not change the other SVMs or volumes on that file system. I used the CloudFormation templates from FSx-for-ONTAP-Container-Datastore-Patterns.

ECS (Fargate)

• A Fargate task in a private subnet could write (PutObject) and read (GetObject) when I named the access point by alias and by ARN. For all three objects, the SHA-256 hash of the file I uploaded matched the hash of the object I read back.
• A second task, in a different Availability Zone from the first, read the same objects and got the same hashes.
• From my laptop, outside the VPC, a call with an administrator IAM role returned AccessDenied. The same call from a task inside the VPC succeeded, so the VPC origin rejects requests from outside the VPC.
• The template did not create a new S3 gateway endpoint. It used the one that already existed in the test VPC.

EKS (Fargate, Kubernetes 1.35)

• An EKS cluster with only Fargate needs extra settings so that CoreDNS (the cluster DNS) runs on Fargate. The template creates a Fargate profile and the CoreDNS add-on for that. With no manual steps, the CoreDNS Pods were Running on Fargate after the first stack creation.
• I annotated a ServiceAccount with the IAM role's ARN (eks.amazonaws.com/role-arn). A Pod using that ServiceAccount could write, read, and list.
• A Pod using a ServiceAccount with a different name, annotated with the same role ARN, was refused at AssumeRoleWithWebIdentity. The role's trust policy allows only the original ServiceAccount name. A Pod with no annotation got no AWS credentials, and its requests to the access point failed.
• After I deleted and recreated the Pod, it could still read the object written before. The data is on the FSx for ONTAP volume, not in the Pod.

Objects written through S3, seen over NFS

I mounted the same volume on an EC2 instance over NFS v4.1. Objects written through the S3 API appeared as files over NFS, and their SHA-256 hashes matched. Files written over NFS could be read with GetObject.

On 2026-11-12 I measured how long an object takes to appear, 30 times. The EC2 instance ran PutObject, and I measured from the moment PutObject returned until stat found the file name on the same instance's NFS v4.1 mount.

• Mount with the NFS attribute cache off (actimeo=0): median (p50) 1.5 ms, maximum 2.1 ms
• Default mount options: median 1.6 ms. Directory listings showed no delay either
• Reverse direction (write a file over NFS and close it, until S3 HeadObject returns 200): median 40 ms
• A Fargate task runs PutObject and the EC2 instance lists the directory: the file was in the listing by the time PutObject returned

In S3-Burst-on-ONTAP-Files, an NFS v3 mount with default options sometimes did not show a new file written through S3 for up to about one minute, after the client had listed that directory once (s3ap-nfs-visibility.md). I did not see this delay over NFS v4.1. Mount options and access patterns affect it, so if your application detects new files by listing a directory, test your own mount.

The two errors I hit

The first was the access point policy. The template set Resource in the access point's resource policy to '*'. With that policy, the S3 API returned Invalid policy: Policy has invalid resource, stack creation failed, and CloudFormation rolled the stack back. When I changed Resource to two values, the access point ARN and the ARN followed by /object/*, the stack was created.

The second was the user for the file system identity. The template used ec2-user as the default, a name I copied from an AWS CLI documentation example. A newly created SVM has no user with that name. The CreateAccessPoint call returned success, but about 45 seconds later the access point status changed to FAILED. The reason said, in effect, that ONTAP could not look up the user.

So I removed the default from the template parameter FileSystemUnixUser, and the parameter is now required. If you omit it, CloudFormation stops with Parameters: [FileSystemUnixUser] must have values before it creates any resource.

Test: an access point with a non-root user

root can read and write every file, so it should not be used in production. On another temporary SVM, I created a local UNIX user (UID 1001) with the ONTAP REST API and set it as the access point's file system identity.

The results follow the file mode bits. I had one problem on the NFS client side. When I ran chown 1001 on an NFS v4.1 client, the owner showed as nobody. NFS v4.1 exchanges user names rather than numbers, so I think the client could not map 1001 to a name (not confirmed). After I created a user with the same UID and name on the client EC2 instance and ran chown with the name, the owner showed 1001.

After the tests I deleted everything I had created. I then compared the lists of SVMs, volumes, access points, VPC endpoints, CloudFormation stacks, and security group rules, and the count of network interfaces in the VPC, with the records I took before the tests. They matched.

Throughput from Fargate tasks

Test 1 only checked that reading and writing work. On 2026-11-12, I created a temporary 100 GiB volume on a file system of the same type (first generation, Single-AZ, 128 MBps throughput capacity, ONTAP 9.18.1P6) and measured throughput from Fargate.

I used the benchmark script from S3-Burst-on-ONTAP-Files without changes; the same script produced the EC2 results there. Each setting ran once for 30 seconds with SDK retries turned off. Because each setting ran only once, I cannot give a variance.

Settings: 8 MiB objects, 16 parallel requests (requests in flight at the same time), values in MB/s.

The table shows three things.

• Writes levelled off at about 130 MB/s for every task size. The limit is the file system's throughput capacity of 128 MBps, and S3-Burst-on-ONTAP-Files measured the same from EC2 (129.4 MB/s). With 64 parallel requests from the 8 vCPU task, write throughput did not rise; the median time per request grew from about 1.0 second to about 4.0 seconds.
• Reads depended on the task size. At 0.5 vCPU, both the access point and the ordinary S3 bucket gave about 280 to 290 MB/s. I think the task's CPU or network was the limit, but I did not confirm it. At 8 vCPU, the access point gave 536 MB/s and the ordinary bucket 769 MB/s, so the access point was slower.
• With 64 KiB objects and 64 parallel requests, the 8 vCPU task made 446 write requests and 677 read requests per second. S3-Burst-on-ONTAP-Files measured about 420 and 600 from EC2.

A 0.5 vCPU task with 1 GB of memory ran out of memory with 64 parallel 8 MiB requests. I measured that size again with 2 GB (the 0.5 vCPU row shows the 2 GB result). No setting in the table returned an HTTP 503 error.

One thing happened before the measurements. For a while, 5 to 7% of requests returned HTTP 503 (ServiceUnavailable) about 2 seconds after they were sent, even with one request at a time on an otherwise idle file system (2026-11-11 17:44 to 18:01 UTC, 2026-11-12 02:44 to 03:01 JST). About five hours later, neither the same access point nor a newly created one returned any 503. The window overlaps an AWS Health notice about an EC2 operational issue (ap-northeast-1, mainly one Availability Zone), but I did not establish a cause. 503 responses can occur for short periods, so I recommend that your application retry them.

The full numbers and environment are in the storage verification record, section 5.5 (Fargate throughput).

Test 2: Nitro Sandbox isolated Pods and FSx for ONTAP storage

Nitro Sandboxes run each Pod in its own lightweight VM. Below I call it "the sandbox VM". The AWS Containers Blog says you enable it by adding one line to the Pod spec, and that EBS and EFS storage work as they do for other Pods. The documentation page Storage with Nitro Sandboxes lists the Amazon EBS and Amazon EFS CSI drivers, tmpfs, emptyDir, and others. It does not say whether NFS volumes from third-party CSI drivers such as Trident are supported.

So I tested it. On an EKS Auto Mode cluster (Kubernetes v1.36.4), I installed the Trident EKS add-on (v26.6.2-eksbuild.1) and created a 1 GiB PVC backed by an FSx for ONTAP NFS volume, with access mode ReadWriteMany. ReadWriteMany lets several Pods on different nodes mount the volume at once.

Figure 2: Storage that an isolated Pod could and could not mount. The Pod and PersistentVolume icons are Kubernetes community icons (Apache-2.0); the Trident logo is from the NetApp/trident repository

The error names a path under the directory the node's kubelet uses for CSI drivers. My guess is that the node mounts the NFS volume, but the mount is not passed into the sandbox VM. This is only my reading of the error; I have not confirmed the cause.

Compared with what AWS describes: the Containers Blog says CSI volumes are passed into the VM in the same way as for other Pods. That did not happen with the Trident NFS volume. The AWS Compute Blog says a sandbox VM uses storage the same way an EC2 instance does: EBS for persistent volumes, and S3 and EFS over the network. Following that, on 2026-11-12 I tested calling an access point from an isolated Pod with the S3 SDK, and iSCSI block volumes.

Calling an access point from an isolated Pod

The documentation says the ServiceAccount token is not copied into an isolated Pod's sandbox VM. My Pods had no Cedar policy, and in that state the IRSA token was present in the Pod. A Cedar policy is attached to a Pod with the sandbox.amazonaws.com/policy annotation (Run a pod in isolated mode). The documentation says that with a policy, --with-irsa or --with-pod-identity is required. I did not test Pods with a policy.

Throughput needs attention. By default, Nitro Sandboxes limit the sandbox VM's network to 100 Mbps (megabits per second, about 12.5 MB/s) and 1,500 packets per second. The documentation says to raise both limits before benchmarking (Resource isolation and throttling). You change them with Pod annotations: sandbox.amazonaws.com/egress-bandwidth, sandbox.amazonaws.com/egress-packets-per-second, and their ingress- counterparts.

Settings: 8 MiB objects, 16 parallel requests, c5a.xlarge node, values in MB/s.

The default write of 12.4 MB/s is close to the 100 Mbps limit. With no limit, reads reached about 260 MB/s, close to the non-isolated Pod (265 MB/s). Writes levelled off at 48 to 54 MB/s, and the 99th percentile (p99) time per write request was about 10 seconds. Both runs showed the same pattern, and I have not found the cause. If an isolated Pod in your design writes a lot, choose the limit annotations and measure your own setup.

Block volumes in an isolated Pod

Auto Mode nodes do not include an iSCSI client (initiator), so a Trident iSCSI PV cannot attach to them. The documentation says that, outside Auto Mode, isolated Pods need a custom AMI that includes the Nitro Sandbox runtime. So I built an AMI from the EKS-optimized AMI, installed the runtime with the script in amazon-eks-ami, and added the iSCSI initiator. I added a managed node group that uses this AMI to the same cluster.

With the same Trident installation, the NFS PV was not passed into the sandbox VM, but the iSCSI PV mounted as ext4 was. The cost is that you build your own AMI and rebuild it as EKS releases updates. That gives up part of what Auto Mode offers, where AWS manages the nodes.

If you need both isolation and data on FSx for ONTAP, there are now three options:

The choice depends on the isolation requirement, whether other Pods or servers share the data, and who operates the nodes.

Based on these results, I opened three issues: an EKS User Guide issue asking for clearer documentation, and two feature requests in containers-roadmap for using third-party CSI NFS volumes and block volumes in isolated Pods. On 2026-11-11 the two requests had the EKS and Nitro Sandboxes labels and no comments. When I filed the block volume request I had not yet tested iSCSI in an isolated Pod. As the table in "Block volumes in an isolated Pod" shows, I later found that on a custom-AMI node an iSCSI PV mounted as ext4 works and volumeMode: Block does not. Filing an issue or getting a label does not mean that AWS has accepted or prioritized the request.

Test 3: security groups for Pods and NetworkPolicy in Auto Mode

On 2026-11-11, EKS Auto Mode added security groups for Pods. Each Pod that a SecurityGroupPolicy (a Kubernetes custom resource) selects gets its own network interface, and the security groups listed in the policy allow or deny that Pod's traffic (documentation).

The EKS Best Practices page Security Groups Per Pod describes the split: security groups for traffic to AWS services outside the cluster, and NetworkPolicy for traffic between Pods. That page was written for the Amazon VPC CNI (the plugin that gives Pods VPC IP addresses), before Auto Mode. The Auto Mode page itself does not recommend using the two together. So I tested whether the same split works in Auto Mode, with Pods that call an access point (2026-11-12, Kubernetes 1.36.5).

Figure 3: NetworkPolicy controls traffic between Pods; Pod security groups control traffic to AWS resources. The Pod icon is from the Kubernetes community icons (Apache-2.0)

First, I changed the outbound rules of the security group on the Pod and checked what the Pod could reach. The S3 prefix list is the AWS-managed list of S3 IP address ranges.

A Pod could still use the access point when its outbound rules allowed only the S3 prefix list. Such a Pod cannot connect to the ONTAP management endpoint or to NFS. An isolated Pod gave the same result.

Next, I combined this with NetworkPolicy. I ran one server Pod listening on TCP port 8080 and connected to it from three client Pods.

• A client with a label that the NetworkPolicy allows, and with a Pod security group, connected.
• A client that differed only in its label was denied by the NetworkPolicy.
• A client without a Pod security group was denied by the security group on the server Pod.

All three clients could still call the access point. The NetworkPolicy and the security groups each blocked different traffic.

One point needs care. Security groups for Pods do not apply to Trident NFS PVs. A Pod whose security group allowed no outbound traffic could still write to its PV. I think this is because the node, not the Pod, mounts the NFS volume. To restrict that traffic, use the node's security group and the ONTAP export policy (the rules for which NFS clients may mount).

To use security groups for Pods, I had to add ec2:CreateNetworkInterfacePermission to the EKS cluster IAM role (the Auto Mode documentation lists it). Details are in the storage verification record, section 9.5 (Pod network controls).

AWS services that can call an access point

Figure 4: Services that can call an access point, grouped by origin

The FSx for ONTAP user guide describes how to use access points with Athena, Glue, EMR Serverless, Bedrock Knowledge Bases, Lambda, CloudFront, and Transfer Family (Using access points with AWS services). AWS-managed services such as Athena and Bedrock run outside your VPC, so they need an access point with Internet origin. Internet origin does not make the data public. Requests without a SigV4 signature are rejected, and S3 Block Public Access is always on.

In fsxn-lakehouse-integrations I tested Athena, Glue, EMR Serverless, Redshift Spectrum, Bedrock, and Snowflake with access points in my own account (compatibility matrix). In Databricks, I could register an access point as a Unity Catalog external location (a storage location registered in Unity Catalog), but reads were denied (2026-08-12). Some services have their own limits. Transfer Family accepts only the access point alias (Transfer Family documentation). Bedrock Knowledge Bases do not ingest files larger than 50 MB (tutorial).

For these services, I found no public statement of use through an access point in what I searched: Amazon Macie, Amazon GuardDuty, AWS Storage Gateway, and others. That means "not found", not "unsupported". AWS DataSync and AWS Backup are a different case. Both support FSx for ONTAP directly and do not use an access point: DataSync copies data over NFS or SMB, and AWS Backup backs up whole volumes.

The full table is the use-case and integration map. Each row says whether it comes from AWS documentation, my measurement, or a vendor's published statement.

How a request is authorized: four checks

Figure 5: Four checks a request passes

A request to an access point must pass all four checks:

1. IAM: the calling IAM role's policies and the access point policy
2. Network origin: VPC origin or Internet origin
3. File system identity: the user set on the access point
4. Volume permissions: file mode bits or ACLs (access control lists), checked for the user in 3

ONTAP enforces checks 3 and 4, outside IAM. This leads to three design decisions.

• If Fargate and AWS-managed services must both use the same volume, create one access point for each origin.
• Each access point has one file system identity. You cannot give different IAM roles different file permissions through ACLs. To separate permissions, create separate access points.
• Before you add access points to an existing file system, check two things: the ONTAP version is 9.17.1 or later, and the maximum number of volumes per file system drops when you use access points (from 500 to 491 on first-generation file systems and on second-generation file systems with one HA pair; FSx for ONTAP quotas).

Differences from NAS buckets on on-premises ONTAP

On-premises ONTAP has "NAS buckets", which present a NAS volume as an S3 bucket (ONTAP 9.12.1 and later, NetApp documentation). NetApp's documentation lists analytics and machine-learning tools reading NAS data through the S3 API as a use case.

Permissions are assigned differently from FSx for ONTAP access points. On-premises ONTAP maps each S3 user to a NAS user and checks that NAS user's permissions for each request. An FSx for ONTAP access point has one file system identity. If your on-premises design gives each S3 user different permissions, you need one access point per set of permissions on FSx for ONTAP.

What I have not checked yet

These are the items this post did not test, and how to test them.

For Windows users, a local SMB user that is not in a domain has been tested in FSx-for-ONTAP-S3AccessPoints-Serverless-Patterns. Reads and writes worked with no domain controller, and setting the file system identity as DOMAIN\user made every operation return 503 (portal-identity-verification-results.md, measurement 4).

Steps to check in your own environment

1. List every service and application that will call the access point, and choose the origin. If the list has both AWS-managed services and compute in your VPC, create two access points.
2. Choose the user for the file system identity. In ONTAP, confirm that the SVM has that user (that the SVM can look it up by name). Avoid root.
3. On a temporary volume, run this sequence once: create the access point, write an object, read it back and compare SHA-256 hashes with the original file, list, and delete what you created. The templates and procedure are in FSx-for-ONTAP-Container-Datastore-Patterns.
4. A test environment keeps costing money while it runs. When you finish, delete it and check that the resource counts match what you had before.

Closing

What I confirmed are the five results at the top.

1. ECS and EKS on Fargate could read and write FSx for ONTAP data through an access point. The two errors were the policy Resource and a user name the SVM could not find; both are fixed in the templates.
2. On a file system with 128 MBps of throughput capacity, writes levelled off at about 130 MB/s, and reads were 276 to 557 MB/s depending on the task's vCPU count.
3. In an EKS isolated Pod, the Trident NFS PV did not mount. An access point worked, and so did an iSCSI PV on a custom-AMI node. Isolated Pod writes were 50 to 60 MB/s even with the network limit removed.
4. Security groups for Pods limited a Pod that calls an access point to S3 only, and NetworkPolicy controlled traffic between Pods. Pod security groups do not apply to Trident NFS PVs.
5. The access point's origin decides which services can call it.

Objects written through S3 were visible over NFS v4.1 by the time PutObject returned.

I found three ways to have both isolation and data on FSx for ONTAP, and each has a trade-off. Next, I plan to finish the Windows domain-account test and then try NVMe/TCP on a second-generation file system. If you are considering the same setup, a 👍 on the containers-roadmap issues above makes the demand easier to see.

The test environments and procedures for this post are in FSx-for-ONTAP-Container-Datastore-Patterns. I hope this helps if you are moving an application to containers and want to keep using its data on FSx for ONTAP.

Bye now!!

Yoshiki Fujiwara