You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This feature request is to handle cases where the DNS server used by the client is not the VPC name server (custom name server, usually Active Directory), typically in a different VPC (centralized DNS VPC setup). As the EFS can only be resolved in the same VPC it is located in, the way around this is to use R53 inbound resolvers and conditionally forward requests for the EFS to the resolver. A simple illustration:
EC2 instance in the app VPC uses the Active Directory in the Central DNS VPC for DNS resolution. Sends the request over VPC peering
The AD receives the request from the EC2 instance.
The AD forwards the request to the inbound DNS resolver in the app VPC.
The inbound resolver receives the request.
The inbound resolver queries the EFS DNS from within the same VPC.
We recommend that you specify IP addresses in at least two Availability Zones. You can optionally specify additional IP addresses in those or other Availability Zones.
As such, in a scenario where the client is in AZ A but the inbound resolver which handles the request is in AZ B, the IP address of AZ B will be sent back to the client resulting in inter-AZ data transfer.
Note: this same behaviour would occur even if the AD is in the same VPC, where the IP address returned is the AZ of the AD as opposed to the AZ of the client.
An easy way to address this would be to append the AZ that the client is located in to the DNS request (i.e. use availability-zone.file-system-id.efs.aws-region.amazonaws.com). This way, regardless of which AZ the resolver is located in, the correct AZ will be sent back to the client. The AZ can be obtained from the metadata of the client, and can fallback to the standard DNS name should metadata be unable to be accessed or if resolution fails (cross-region scenario where AZ of client would not match AZ of EFS).
Would this addition be possible, or is there another solution that can be looked into to address this scenario? As a side note, a way which this can be addressed is for the client to keep using the VPC name server and instead configure an outbound resolver to send specific requests to an AD, but management of these rules when there are a large number of VPCs can become tedious hence changing how EFS utils resolves the EFS DNS can be a more favorable change.
The text was updated successfully, but these errors were encountered:
This feature request is to handle cases where the DNS server used by the client is not the VPC name server (custom name server, usually Active Directory), typically in a different VPC (centralized DNS VPC setup). As the EFS can only be resolved in the same VPC it is located in, the way around this is to use R53 inbound resolvers and conditionally forward requests for the EFS to the resolver. A simple illustration:
This setup works and allows the EFS to be mounted. However, as it is the inbound resolver which resolves the request, the IP address which is resolved is dependent on the AZ of the inbound resolver as opposed to the client. It is recommended to have multiple inbound resolvers in multiple AZs for availability:
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-inbound-queries.html#resolver-forwarding-inbound-queries-values
As such, in a scenario where the client is in AZ A but the inbound resolver which handles the request is in AZ B, the IP address of AZ B will be sent back to the client resulting in inter-AZ data transfer.
Note: this same behaviour would occur even if the AD is in the same VPC, where the IP address returned is the AZ of the AD as opposed to the AZ of the client.
An easy way to address this would be to append the AZ that the client is located in to the DNS request (i.e. use
availability-zone.file-system-id.efs.aws-region.amazonaws.com
). This way, regardless of which AZ the resolver is located in, the correct AZ will be sent back to the client. The AZ can be obtained from the metadata of the client, and can fallback to the standard DNS name should metadata be unable to be accessed or if resolution fails (cross-region scenario where AZ of client would not match AZ of EFS).Would this addition be possible, or is there another solution that can be looked into to address this scenario? As a side note, a way which this can be addressed is for the client to keep using the VPC name server and instead configure an outbound resolver to send specific requests to an AD, but management of these rules when there are a large number of VPCs can become tedious hence changing how EFS utils resolves the EFS DNS can be a more favorable change.
The text was updated successfully, but these errors were encountered: