Upon checking the relevant code that decides the region value here:

I see that it's possible to retrieve the region right from the EFS with fqdn format (passed to the mount command). I am wondering why the region from DNS Format got in the last priority? From dev/user perspective, if they pass the fqdn format (with region info in it), which is more explicit than the region from shared etc-utils.conf file and aws ec2 metadata call, so we should use that as the first priority.

Wdyt @Cappuccinuo ?

Also, If I understand the code correctly, I noticed weird (wrong?) implementation of get target region from legacy dns format

There is no case if {region} format found in the dns format. I believe we should refactor the get_target_region(config) to get_target_region(config, other_required_params), for example get_target_region(config, fs_id) where user can pass fs_id parameter with FQDN Format, so that we can evaluate the dns format regex capture group. Wdyt @Cappuccinuo ? If this is the right approach, I don't mind to submit a PR.

Hey @bangau1 ,

1. The get_region_from_legacy_dns_format is checking if the {region} is replaced by a valid region in the dns_name_format = {az}.{fs_id}.efs.{region}.{dns_name_suffix}, e.g. dns_name_format = {az}.{fs_id}.efs.us-east-1.{dns_name_suffix}. We don't recommend you config the region info here, instead you can modify the region info in the following few lines in the config file

#The region of the file system when mounting from on-premises or cross region.
#region = us-east-1

2. To mount a file system in another region, that means you need to
   a) Setup the vpc-peering so that your ec2 instance in VPC A can talk with efs in VPC
   b) After you have set the vpc-peering up, you will need to change the region in config file to the EFS region.
   c) Then you can mount your file system by specifing the mounttargetip option in mount command to pass a ip address of the mount target to mount. (This will require v1.31.1+ efs-utils)
   d) The current mount target ip fallback logic assume you are using a file system in the same region, and we recommend you use the file system in the same az so that you can get the best file system performance. So that is why the mount target ip address must be specified in this case.

e.g. fs-deadbeef is in region us-east-1, the instance with private ip address 192.2.8.155 is in region us-east-2, and we are mounting to one of the mount target ip address of fs-deadbeef

[ec2-user@ip-192-2-8-155 ~]$ sudo mount -t efs -o tls,mounttargetip=172.33.21.155 fs-deadbeef /mnt
[ec2-user@ip-192-2-8-155 ~]$ df
Filesystem            1K-blocks    Used        Available Use% Mounted on
devtmpfs                 492676       0           492676   0% /dev
tmpfs                    503448       0           503448   0% /dev/shm
tmpfs                    503448     548           502900   1% /run
tmpfs                    503448       0           503448   0% /sys/fs/cgroup
/dev/xvda1              8376300 1494688          6881612  18% /
tmpfs                    100692       0           100692   0% /run/user/1000
tmpfs                    100692       0           100692   0% /run/user/0
127.0.0.1:/    9007199254739968       0 9007199254739968   0% /mnt

[mount]
dns_name_format = {az}.{fs_id}.efs.{region}.{dns_name_suffix}
dns_name_suffix = amazonaws.com
#The region of the file system when mounting from on-premises or cross region.
region = us-east-1

@Cappuccinuo I have two disks which I need to mount one of which is in another region. Setting that region in the config file then breaks mounting the other disk. A cli flag as @bangau1 mentioned would be pretty helpful in this case.

Thanks @Shaan95 , if you have two disks in two different regions, that makes sense to have a region cli flag to differentiate them. We will have someone to take a look at this.

Is this still the case where using efs-utils only works with efs in one region? I have a TGW peering with another region and account where I need to mount efs from two regions to one ec2 instance. In theory, it is possible to get around this single region limitation by just using 'normal' NFS mounting instead of the efs-utils package and hitting the mount target IPs but I'd like to use efs-utils if at all possible.

Yes, it's still the case. We've been trying to work around this for a full day now without modifying the mount.efs code. Unfortunately, falling back to NFS doesn't work if you need to use an accesspoint (Such as in our case)

One of the most confusing things about having to set the region in the config file, is that it completely ignores what region your AWS profile is in.

If I have an AWS config file with two profiles, let's say efs-east using region = us-east-1 and efs-west using region = us-west-1, I would hope I could not have to set a region in the config, and use the awsprofile option, but it doesn't work.

If the EC2 instance I'm mounting from is in us-east-1 then this works:

mount -t efs -o tls,iam,awsprofile=efs-east,accesspoint=fsap-xxxx fs-xxxx /mnt/east

But if I update it to use the access point ID and FS ID in west, it doesn't work, even if I use awsprofile=efs-west.

It only works with mounttargetip=<west mount IP>, and it works the same whether I use the efs-east or efs-west profile, and it only works if I set the region in the config to the region where the EFS volume is.

What would be much nicer is being to able to have two commands that at least look congruent:

mount -t efs -o tls,iam,awsprofile=efs-east,accesspoint=fsap-<eastid> fs-<eastid> /mnt/east
mount -t efs -o tls,iam,awsprofile=efs-west,accesspoint=fsap-<westid> fs-<westid> /mnt/west

(also the suggestions in #63)