What I left off the file portal on AWS — how far FSx for ONTAP features reach, and the work handed to a schedule (Part 6)

This concludes the sixth and final part of the series. In the previous parts, we built a file portal on Amazon FSx for NetApp ONTAP S3 access points, added ransomware response and WORM retention, integrated AI agents, delegated 182 storage operations, and collected findings from a running cluster. In this final part, we explore what remains usable within ONTAP without relying on the portal, and the operational work shifted to a schedule instead of individual button clicks.

Firstly, ONTAP features that remain usable alongside the S3 access point include creating and accessing qtrees. These qtrees can be created on the ONTAP side and appear as S3 prefixes. An object written into the qtree prefix is successfully stored within the qtree directory. Additionally, quotas and quotas on the S3 access point path do not appear to be restricted, allowing for effective space management.

FlexClone functionality, both at the volume and file granularity, remains operational. An S3 access point can be attached to a FlexGroup volume, and clones of FlexGroup volumes can be created through this path. However, there are some notable differences between the mechanisms. An NTFS volume with a UNIX identity on a single SVM without a CIFS server attached reached the "AVAILABLE" state but refused data operations with an "AccessDenied" error.

Furthermore, ONTAP volumes take approximately ten to twenty minutes to appear in the AWS API after creation, and volumes that previously had an S3 access point cannot be deleted from the ONTAP side, even after detaching all access points. Finally, a volume with an S3 access point cannot be deleted from the ONTAP side, requiring the use of the "aws fsx delete-volume" command to remove it.