Managing DNS resolution with Amazon VPC Lattice and VPC resources

These allow you to create an Alias record in a DNS Zone that you have control over, perhaps a Private Hosted Zone (PHZ) in AWS. The Hosted Zone values are needed if you create an Alias record at the DNS Zone apex.

Accessing VPC resources through Associations and Endpoints

The recap is complete, now we can dive into what’s new here.

VPC Resources offers a new data-plane within AWS, where endpoints such as AWS Databases, Amazon Elastic Compute Cloud (Amazon EC2) instances, Domain Name targets, and IP addresses can be reached. Both PrivateLink and VPC Lattice now support direct TCP connections to endpoints. This eliminates the requirement for AWS Network Load Balancers (NLBs) with PrivateLink. For brevity we won’t cover the details on how VPC resources work here, instead we recommend that you check out the details in Jeff Barr’s News post to get an overview of the new features.

However, we can summarize some important concepts before discussing the DNS resolution:

1. Resource definition: VPC resources are defined by creating a Resource Configuration that can be either:
   1. Single (single resource with a target type DNS or IP)
   2. Group (collection of child resource configurations)
   3. Child (object within a group, sharing the same configuration)
   4. ARN (to access supported AWS resources).
2. Resource Association: VPC resources can be exposed using three methods:
   1. Association with an Interface endpoint of the type “resource”
   2. Association with an Interface endpoint of the type “service network”
   3. Association with a VPC Lattice service network

DNS resolution for access methods

With the release of VPC resources and new endpoint types, there are now multiple ways to connect to both VPC Lattice services and VPC resources. Table 1 details these options:

During this section we explore how DNS resolution works for these different entities and access methods. Note that the connection to VPC Lattice services from a VPC Lattice service network association (first column, first row in the preceding table) was already covered at the beginning of this post.

Accessing VPC resources through a VPC Lattice service network VPC association

In this configuration, a consumer VPC is associated with a service network that also has VPC resources associated to it. How does this VPC resource publication differ from VPC Lattice services?

As mentioned previously, a globally unique and externally resolvable domain name is created per resource association to the service network as well as a Hosted Zone ID. Depending on the Resource Configuration type, you find some differences:

• Child resources (regardless of being in a Group or not) have their own resolution configuration
• ARN resources create a managed Child resource configuration, which is the one targeting the resource itself

One key difference between VPC Lattice services and VPC resources DNS resolution is in the IP address space used. The IPv4 addresses used for resource connectivity come from the public 129.224.0.x/17 range. For IPv6, addresses come from the fd00:ec2:80::/64 range – used for both VPC Lattice services and VPC resources.

To set up any sort of alias for the generated domain name, as done previously, we need to retrieve the association’s domain name and Hosted Zone ID. For an example we use an ARN-type Resource Configuration. First, as you see in Figure 5, two Resource Configurations are created:

• The entry of the type ARN is the “parent”, which is the same as if you create a Resource Configuration of the type Group.
• The Child entry is the resource providing the DNS information we need for the resolution.

From the console, choose the Child resource name to obtain the information shown in Figure 6.

If you prefer to use AWS CLI, then using the resource association ID (snra-x…) allows you to obtain the DNS information needed to setup the alias by using the following command:

aws vpc-lattice get-service-network-resource-association --service-network-resource-association snra-XXX --region YYY

For ARN types, you may not have the resource association ID (because the Child is generated and not created by you). You can obtain the desired information by performing some extra actions using the ID of the Parent Resource Configuration. Specifically, you need to issue a query to list all of the resource associations of a service network, with the following filters:

• The value ‘resourceConfigurationName’ starts with the Resource Configuration ID of the parent resource.
• The value ‘isManagedAssociation’ is equal to true.

aws vpc-lattice list-service-network-resource-associations --service-network-identifier sn-XXX --region YYY --query 'items[?isManagedAssociation==`true`]|[?starts_with(resourceConfigurationName,`rcfg-ZZZZZ`)==`true`]' 

The DNS configuration in consumer VPCs remains consistent: simply create an ALIAS record in a DNS zone that you control, referencing the global unique record (Domain Name an Hosted Zone ID).

Accessing VPC Lattice services and VPC resources through VPC Lattice service network endpoints

As mentioned previously, VPC Lattice services and VPC resources can now be reached by using VPC Lattice service network endpoints. Service network endpoints now work beyond their associated VPCs, enabling connections from on-premises locations and cross-Region applications. These endpoints support IPv4, IPv6, and dual-stack addressing. For IPv6 addresses the denyAllIgwTraffic flag is enabled, which means that the endpoint can only be used for private communication.

A typical hybrid model using this feature is shown in Figure 9.

If you are familiar with interface VPC endpoints, then we should discuss some differences:

• With Interface Endpoints of the type ‘service network’, you don’t need to create an endpoint per service/resource to connect to. All of the services/resources associated can be reached from a single endpoint.
• Each endpoint can consume multiple /28 IPv4 and /80 IPv6 range per subnet/AZ. From this range, several VPC Lattice services may consume and share a single secondary IP address, while each VPC resource consumes independent secondary IP addresses.

This means that the Primary interface IP address of the interface cannot be used for routing traffic for services or resources. They must be resolved to their respective secondary IP addresses.

A new globally unique and externally resolvable domain name is created for each service/resource associated to the service network associated to the endpoint. These domain names provide the IP addresses each service/resource is consuming from the secondary range. They are viewable in the console, when looking at the Associations tab of the endpoint.

aws ec2 describe-vpc-endpoint-associations --vpc-endpoint-ids vpce-XXX --region YYY 

With this information, you can update the DNS resolution configuration dependent on your use case and consumer application location:

• For applications located in another AWS Region (multi-Region connectivity), you can configure a Private Hosted Zone (with Alias records configured) associated to those VPC(s).
• For applications located in on-premises environments (hybrid connectivity), we recommend following the Hybrid DNS with Route 53 Resolver Endpoints reference architectures.

Accessing VPC resources through PrivateLink interface endpoints

If you are not using VPC Lattice, then VPC resources can be accessed using a more traditional PrivateLink interface. As detailed previously, there is new interface type for this: the Interface endpoint of the type “resource”.

In the following configuration, a VPC Resource of the type Single has been created and associated with a Resource Gateway. A Resource endpoint has also been deployed and associated with the Resource Configuration.

Take a moment to review the IP addressing for this endpoint, shown in Figure 14. There are only two IP address (one per Availability Zone (AZ)). This is familiar in concept to how PrivateLink endpoints work more generally.

The auto-generated DNS name of the VPC resource can be retrieved at the endpoint association level. From the console, we need to look at the Endpoint, specifically, the Associations tab as shown in Figure 15. If you use the CLI, then you can check Figure 16 to see how to obtain the information.

aws ec2 describe-vpc-endpoint-associations --vpc-endpoint-ids vpce-XXX --region YYY 

To add a vanity/masquerade name, you can create an alias record in a suitable Private Hosted Zone, aliased to the autogenerated DNS name, specifying the Hosted Zone ID.

Service connectivity from external applications

So far we have covered the five connectivity patterns documented within Table 1. However, you may be missing one: how to consume services/resources from consumers outside of AWS without a private communication. As new services/resources are added to your environment, IP addresses that are used to connect to them can change. For this reason, our view is that it remains clearer to harness an ingress proxy layer that can perform dynamic lookups and resolution for your services and resources on your behalf. Without this dynamic layer front-ending your traffic, further steps would be needed to discover endpoint secondary IP address information and dynamically update any static configurations that you have deployed.

The solution you choose can be a wholly owned one (as discussed in our previous post) or might involve a partner offering. Ingress proxying for VPC Lattice services is also possible using Amazon API Gateway, as discussed in this Amazon Containers post.

Check the Guidance for External Connectivity to Amazon VPC Lattice for a fully automated solution using an NLB targeting a fleet of lightweight serverless proxies on AWS Fargate.

With the release of VPC Lattice service network endpoints, this solution can be further optimized. Previously there was a 1:1 mapping consideration between the ingress solution VPC and the service network with which it was associated. Opting to use an endpoint instead of a VPC association allows this ingress proxy solution to be used to reach any service network within the Region!

PrivateLink resource endpoints allow you to remove the need of the proxy solution and target endpoints directly from an ELB. At scale, we still recommend the use of a VPC Lattice service network to have a single place to control the connectivity and security of your services/resources and reduce endpoint sprawl.

We know, you need a summary

The following table summarizes the recommended access modalities for the different entity types that are exposed.

Further considerations

• Consider the use of VPC Lattice service network associations as the principal access method for both VPC Lattice service and VPC resource access. This streamlines the connectivity requirements and creates a strong mapping between a VPC and its intended use.
• Consider using VPC Lattice service network endpoints for multi-dimensional use cases such as split function VPCs, hybrid and external access through proxy layers.
• Consider the use of PrivateLink resource endpoints when you are predominantly an PrivateLink user with no immediate plans for scaling access to services.
• In multi-Account environments, you can share the following resources through AWS Resource Access Manager (AWS RAM): VPC Lattice service networks, VPC Lattice services, and VPC Resource Configurations.
• When working at scale, we recommend the following related to the DNS resolution configuration:
  • The automation of the DNS configuration to avoid bottlenecks anytime a new VPC Lattice service or VPC resource is created/deleted. The Guidance for Amazon VPC Lattice Automated DNS Configuration on AWS provides a solution you can use to automate these DNS configurations at scale.
  • The use of Amazon Route 53 Profiles to streamline the association of Private Hosted Zones to consumer VPCs.
• You can apply granular security with VPC Lattice services using sigV4 signing. For applications that reside outside of AWS, consider using IAM Roles Anywhere to get the necessary credentials.

Conclusion

In this post we have reviewed different connectivity patterns to consume VPC Lattice services and VPC resources, focusing on how to obtain and configure the necessary DNS resolution from VPCs in the same AWS Region, cross-Region, and on-premises environments. We provided some guidance on how to think about the new AWS capabilities and where and how to deploy and access them.

Visit the Amazon VPC Lattice product page, documentation, and pricing page for more information.

About the authors