IAM permission to mount FSx NetApp ONTAP on EC2

Regarding: "Is there any IAM Role such as instance role to give "mount volume" permission to an EC2 instance to FSx ONTAP volume?"

Unfortunately, it's still not possible - you need to use "legacy" NFS, CIFS/SMB, or iSCSI mechanisms.

• NFS = Export Policy (you must add a rule to the Export Policy of the volume.)
• CIFS/SMB = Active Directory or Local ONTAP Users
• iSCSI = LUN Masking (You must register the EC2 instance's IQN in an igroup on the ONTAP side to map the LUN)
• 'fsxadmin' and 'vsadmin' = Active Directory or Local ONTAP Users

Regarding the Local ONTAP Users for NFS and CIFS have in mind it's different identity in case you need to go with Local Users for CIFS and/or NFS:

Example NFS User 'ec2-user' with UID and GID '1000':

vserver services name-service unix-user create -user ec2-user -id 1000 -primary-gid 1000

Example CIFS/SMB User 'ec2-user':

vserver cifs users-and-groups local-user create -user-name ec2-user

Regarding: "Is it possible to mount a FSx volume on different account? "

Possible Alternative: In addition to legacy CIFS/NFS/iSCSI via Network Link (TGW, VPC Peering etc.), you can use AWS Resource Access Manager to share subnets (NOT FSxN). Sharing a subnet via RAM allows an EC2 instance in Account B to be launched directly into a VPC owned by Account A.

• The Benefit: You avoid the complexity of VPC Peering or Transit Gateway routing. The EC2 instance and the FSxN interface appear to be on the same local network.
• The Catch: This requires a centralized network strategy (often a Shared VPC model) which might be overkill for a single one-off connection but is excellent for enterprise-scale environments.

described in the official blog from Jeff Barr, see: https://aws.amazon.com/blogs/aws/introducing-shared-vpc-support-for-amazon-fsx-for-netapp-ontap/

Regardless of whether you use RAM, Peering, or Transit Gateway, these three pillars must be aligned:

ONTAP Export Policy: Unlike standard AWS EFS, FSxN has its own internal "firewall" called an Export Policy (for NFS).

Even if AWS Security Groups allow the traffic, the ONTAP OS will reject the mount if the EC2's IP address isn't in the allowed client list.

Action: Ensure the rule in the Export Policy matches the specific IP or CIDR of the cross-account EC2.

Route Tables: If you are not using a Shared VPC (RAM), your VPC Route Tables are the "GPS" for the traffic.

• In Account A (FSx): A route must exist for Account B’s CIDR pointing to the Peering Connection or Transit Gateway.
• In Account B (EC2): A route must exist for Account A’s CIDR pointing back to the same gateway.

1. For mounting FSx for NetApp ONTAP volumes on EC2 instances, there isn't a specific IAM role or instance role that provides "mount volume" permission. The mounting process for FSx for ONTAP volumes on EC2 instances typically doesn't require special IAM permissions. Instead, the ability to mount the volume is primarily controlled by network connectivity and the file system's access controls. Please refer to the document below for complete information on mounting FSx for NetApp ONTAP volumes on Linux EC2 instances: [+] - https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/attach-linux-client.html

2. Mounting an FSx for NetApp ONTAP volume on an EC2 instance in a different AWS account is possible, but it requires careful network configuration. There's no direct IAM permission that allows cross-account mounting. Instead, you need to ensure proper network connectivity between the two accounts VPC's and configure routes between the same. This typically involves:

   • VPC peering or AWS Transit Gateway to connect the VPCs in different accounts
   • Configuring the necessary route tables to allow traffic between the VPCs
   • Ensuring that the security groups and network ACLs allow the required traffic

Providing the required routing is mandatory for cross-account mounting. There isn't another way to mount an FSx volume on an EC2 instance in a different AWS account without establishing the necessary network connectivity.

Remember that in addition to network connectivity, you'll need to ensure that the file system's access controls (like export policies for NFS or share and file permissions for SMB) are configured to allow access from the EC2 instance in the other account.

Here's a blog referencing the architecture of accessing cross-account FSx Filesystems that can help you: [+] - https://aws.amazon.com/blogs/storage/enabling-file-system-sharing-on-fsx-for-netapp-ontap-across-multiple-aws-accounts/