Amazon VPC Lattice DNS migration strategies and best practices

In this post, we review the most common Domain Name System (DNS) strategies to migrate your applications to Amazon VPC Lattice in a phased approach. These options allow you to reduce downtime, minimize overhead, and maintain consistent DNS resolution for your clients and applications on AWS.

VPC Lattice is a fully managed end-to-end application networking service that is purpose-built to help you modernize applications and network connectivity on AWS. It simplifies the onboarding experience for developers by removing the need to implement custom application code, or run proxies next to every workload, while maintaining the tools and controls network admins need to audit and secure their environment. A seamless adoption process depends on the ability to integrate VPC Lattice in existing environments on AWS, and benefiting from its capabilities without impacting production. VPC Lattice uses DNS for service discovery, and each VPC Lattice service is identifiable through its service-managed or custom DNS name.

You can migrate an existing service to VPC Lattice by updating your DNS to allow clients to resolve the service names to VPC Lattice IP addresses. Throughout the scenarios we explore in this post, we present DNS migration strategies for two common DNS management options: using Amazon Route 53 public and private hosted zones.

Prerequisites

We assume you are familiar with the foundational VPC Lattice concepts, and with services such as Amazon Virtual Private Clouds (Amazon VPCs), route tables, Route 53 Resolver, and Route 53 private and public hosted zones. Details on how you can set up VPC Lattice in multi-account and multi-VPC environments can be found in this Amazon networking post and VPC Lattice documentation.

Before we dive in to the migration scenarios, let’s review how VPC Lattice uses DNS for service discovery.

VPC Lattice DNS

When you create a VPC Lattice service, VPC Lattice generates an associated unique Fully Qualified Domain Name (FQDN), which is formatted as “service_name-service_id.partition_id.vpc-lattice-svcs.region.on.aws”. Each VPC Lattice service name is globally unique and externally resolvable to a series of IPv4 and IPv6 addresses in the ranges 169.254.x.x/16 range and fd00:ec2:80::/64 respectively. These IP addresses are publicly resolvable, and accessible only for clients in VPCs connected to a VPC Lattice service network. However, applications usually rely on more intuitive custom DNS names for applications, for example, ”service123.example.com”.

VPC Lattice allows you to configure a custom DNS name for your VPC Lattice service at creation time. To allow clients in VPCs to resolve the custom domain name, you need to create an Alias or Canonical Name (CNAME) record that resolves your custom domain name to the VPC Lattice generated domain name. When a client in a VPC makes a request using the custom DNS, the Route 53 Resolver recursively resolves it to a VPC Lattice IP address. Once the client request reaches the VPC Lattice service network, a routing decision is made by VPC Lattice based on the request host header, or the Transport Layer Security (TLS) Server Name Indication (SNI) information. Traffic is then sent to the service target. Figure 1 shows the VPC Lattice components and custom DNS flow:

Figure 1: High-level overview of VPC Lattice components and custom DNS flow

Baseline architecture

The baseline architecture consists of three Amazon VPCs, A, B, and C, each with their respective VPC Resolvers, as shown in the following diagram (Figure 2). VPCs B and C are interconnected through an AWS Transit Gateway. VPC A hosts an application called ”Foo”. Foo is fronted by an internet-facing Application Load Balancer (ALB) ”public-ALB-foo”. VPC C hosts a service named Bar, fronted by a private ALB ”private-ALB-bar”. In VPCs B and C we deployed ”Client-1” and ”Client-2” respectively, to test connectivity. Throughout this post, we show how you can adopt VPC Lattice without disrupting connectivity between the test clients and services.

Figure 2: Baseline architecture depicting VPCs, different clients, and the applications Foo and Bar

We focus on two baseline scenarios: DNS management using Route 53 public hosted zones, and DNS management using Route 53 private hosted zones. For each scenario, we review two migration options to VPC Lattice: per VPC per DNS domain, and per VPC per service.

Migrating to VPC Lattice services using DNS names managed in Route 53 public hosted zones

Baseline service connectivity architecture

Assume a DNS setup, as depicted in Figure 3, where we manage DNS using a public hosted zone named example.com:

Figure 3: DNS management for baseline architecture using Route 53 public hosted zones

1. The public hosted zone has two DNS records: foo.example.com Alias to ”public-ALB-foo” FQDN, and bar.example.com Alias to ”private-ALB-bar” FQDN.
2. Internet clients who want to access Foo can resolve the public DNS record of foo.example.com to the public ALB’s IPs.
3. Similarly, VPC based clients (client-1 and client-2) can use the local Route 53 resolver to access Foo and Bar by resolving the public DNS records for ”foo.example.com” and ”bar.example.com” to the respective ALB IPs.

We plan to have Foo accessible in VPC Lattice for Client-1, without affecting Client-2, internet clients, or other clients in other VPCs. Let’s review the step-by-step configuration.

Pre-configuration steps

Start by creating a VPC Lattice service network for our clients and services. Figure 4 shows the pre-configuration steps you can repeat for VPC Lattice services and client VPCs that you want to migrate, without impacting existing traffic flows:

Figure 4: Service side pre-configuration steps – ”Foo.example.com” and ”VPC B” associated with the VPC Lattice service network

A. Create the Foo VPC Lattice service with a custom domain name ”foo.example.com”, and associate it with the service network. The Foo VPC Lattice service receives an FQDN managed by VPC Lattice in a public hosted zone.

B. Associate VPC B with the VPC Lattice service network.

Attempting to alter Client-1’s traffic resolution to use VPC Lattice by modifying the public hosted zone resource record for foo.example.com would impact internet clients and Client-2, causing traffic disruption. This is because only VPCs associated with a service network can access VPC Lattice IPs. To migrate Client-1 to VPC Lattice without disrupting communication for existing clients, we must maintain a separate DNS view for clients that start using VPC Lattice. We explore two options to achieve this:

Per-VPC per-domain migration using a private hosted zone

Figure 5 shows the Client-side migration steps for this option:

Figure 5: Migration option 1 depicting a per-VPC per-domain DNS migration step

C. Create a new private hosted zone for domain name “example.com”. This private hosted zone provides split horizon DNS resolution, allowing you to control how associated VPCs resolve DNS without disrupting public DNS resolution. This private hosted zone contains all resource records in the public hosted zone.

D. In the private hosted zone, replace the resource record for “foo.example.com” from the ”public-ALB-foo” to the VPC Lattice service FQDN. Test that client-1 can access Foo using the VPC Lattice FQDN, to ensure security groups, Network Access Control Lists (ACLs), and VPC Lattice auth policies are correctly configured.

E. After you validate connectivity, associate the private hosted zone with VPC B. When Client-1 resolves any domain name in the “example.com” zone, the Route 53 Resolver uses the private hosted zone records to answer the queries. As a result, Client-1 now sends traffic to “foo.example.com” using the Lattice Service Network, and continues to use the Transit Gateway to communicate with “bar.example.com”. To roll-back to the public hosted zone resolution, you can disassociate the VPC from the private hosted zone.

You can repeat the preceding steps for each new client VPC that migrates to VPC Lattice. For example, you can now onboard VPC C and migrate client-2 to access Foo through the VPC Lattice service network.

Per-VPC per-service migration using service-specific private hosted zones

You can also migrate DNS resolution to VPC Lattice using a per-VPC per-service DNS strategy, providing a granular approach to client and service migrations. The key difference is that you create a specific private hosted zone for each service name you make available in VPC Lattice, for example “foo.example.com”. Figure 6 shows the Client-side migration steps for this option:

Figure 6: Per-VPC per-service DNS migration steps

C. Create a private hosted zone for ”foo.example.com”.

D. Create an ALIAS record at the apex to the VPC Lattice service FQDN. If the service name is the same as the private hosted zone domain name, then you can’t configure a CNAME type resource record. Test that client-1 can access Foo using the VPC Lattice service FQDN.

E. Associate the service-specific private hosted zone with VPC B. When the VPC Resolver receives queries from Client-1 for “foo.example.com”, it matches the private hosted zone, and resolves the DNS name to the VPC Lattice IPs. When Client-1 attempts to resolve “bar.example.com”, the VPC Resolver uses the public hosted zone “example.com” resource record, and resolves to “private-ALB-bar IPs”. As a result, clients in VPC B send only traffic to “foo.example.com” through the VPC Lattice Service Network. To roll-back to the public hosted zone resolution, you can disassociate the VPC from the private hosted zone.

As you migrate more services to VPC Lattice, you create a private hosted zone for each service, with the appropriate ALIAS record pointing to the VPC Lattice service FQDN. Then, you can associate each service-specific private hosted zone with each client VPC you migrate to using VPC Lattice. To simplify management of service-specific private hosted zones and VPC associations, you can use Route 53 Profiles.

Migrating to VPC Lattice services using DNS names managed in Route 53 private hosted zones

Baseline service connectivity architecture

Figure 7 shows the baseline setup for this scenario, with centralized DNS management using a private hosted zone named “example.com”. This private hosted zone is associated with VPC B and VPC C, such that both have the same DNS view. For internet clients, we maintain a public hosted zone “example.com” that contains a resource record for “foo.example.com” resolving to ”public-ALB-foo”.

Figure 7: Baseline architecture DNS management using Route 53 private hosted zones

1. Internet clients use the public hosted zone entries, and resolve “foo.example.com” to the ”public-ALB-foo” IPs.
2. VPCs B and C are associated with the example.com private hosted zone, and have a private DNS view.
3. Client-1 and Client-2 use the VPC Resolver, which recursively resolves “foo.example.com” and “bar.example.com” to ”private-ALB-foo” and ”private-ALB-bar” IPs respectively.

We plan to have Foo accessible through VPC Lattice for Client-1, without disrupting Client-2, internet clients, or other clients in other VPCs.

Pre-configuration steps

Start by creating a VPC Lattice service network for our clients and services. Figure 8 shows the pre-configuration steps that can be repeated for VPC Lattice services and client VPCs you want to migrate, without impacting existing traffic flows:

Figure 8: Service side pre-configuration steps – ‘Foo service and VPC B associated with the VPC Lattice service network

A. Create the Foo VPC Lattice service with a custom domain name ”foo.example.com”, and associate it with the service network. The Foo VPC Lattice service also receives an FQDN managed by VPC Lattice in a public hosted zone.

B. Associate VPC B with the VPC Lattice service network.

All clients in VPCs use a single private hosted zone ”example.com” for DNS resolution, thus modifying the “foo.example.com” resource record would cause disruption for all other clients in VPCs not associated with the service network. Therefore, we must create a separate private DNS view for clients that use VPC Lattice. There are two options we explore to achieve this:

Per-VPC per-domain migration using a private hosted zone

Figure 9 shows the Client-side migration steps for this option:

Figure 9: Per-VPC per-domain DNS migration steps

C. Create a new private hosted zone for domain name “example.com”, with all resource records from the existing hosted zone. In the new private hosted zone, replace the resource record for “foo.example.com” from the ”private-ALB-foo” to the VPC Lattice service FQDN. Test that Client-1 can access Foo using the VPC Lattice service FQDN before migration.

D. Disassociate the existing “example.com” private hosted zone from VPC B, and associate the new “example.com” hosted zone with VPC B. No other services are impacted by this change. You can roll-back by disassociating the VPC from the new private hosted zone and re-associating it with the existing private hosted zone. To prevent DNS resolution failing during this process, you can create a Route 53 Profile containing the new “example.com” private hosted zone, associate it with the VPC, and then disassociate the directly associated private hosted zone.

Per-VPC per-service migration using service-specific private hosted zones

You can also migrate to VPC Lattice on a per-VPC per-service basis, providing a granular approach to client migrations. To achieve this, you can create the private hosted zone for each service, for example ”foo.example.com”. Figure 10 shows the migration steps for this option:

Figure 10: Per VPC per service DNS migration steps

C. Create a private hosted zone for “foo.example.com” with an ALIAS resource record to the VPC Lattice service FQDN. Test that client-1 can access Foo using the VPC Lattice service FQDN before migration.

D. You associate the service-specific private hosted zone with VPC B. When the VPC Resolver receives queries from the VPC for “foo.example.com”, it matches the service-specific private hosted zone, and resolves the DNS name to the VPC Lattice IPs. When Client-1 attempts to resolve bar.example.com, the Route 53 Resolver uses the record in the private hosted zone “example.com”, which resolves to ”private-ALB-bar” IPs. You can also associate service-specific private hosted zones with a Route 53 profile, to simplify management.

As you migrate more services to VPC Lattice, create a private hosted zone for each service, with the appropriate Alias record pointing to the VPC Lattice service FQDN. Then, associate each service-specific private hosted zone with each client VPC that you migrate to using VPC Lattice. Hybrid DNS resolution must continue to use non-VPC Lattice DNS names, pointing to IP addresses reachable from on-premises.

Things to know

• To simplify management of private hosted zones and VPC associations, we recommend using Route 53 Profiles.
• For IPv4 and IPv6 service names DNS resolution, you must configure both Alias A and Alias AAAA resource records.
• We recommend considering the quotas for the number of private hosted zones you can associate with a VPC. If you are using Route 53 profiles, then you can manage more VPCs and private hosted zone associations.
• To automate the DNS resolution configuration when a new VPC lattice service is created, refer to this AWS reference solution.
• If you decide to manage domain level hosted zones, then consider that their configuration affects all clients accessing services with the same domain name. For example, if you have both Foo and Bar DNS records using the VPC Lattice FQDN in the domain-level private hosted zone, and you associate a new VPC with the private hosted zone, then all clients in the new VPC start resolving both Foo and Bar to the VPC Lattice IP addresses.
• You can choose to consolidate private hosted zones into domain-level private hosted zones when you complete migration to VPC Lattice.

Conclusion

In this post we discussed DNS migration strategies you can use to migrate your services and clients to the VPC Lattice network, with minimal management overhead and downtime. We discussed DNS options you can use to migrate to VPC Lattice when your existing DNS management uses both public and private hosted zones on AWS. To learn more about Amazon VPC Lattice, please refer to the documentation, and the AWS re:Post guide Get started with Amazon VPC Lattice – Resources and content. If you have questions about this post, then start a new thread on AWS re:Post, or contact AWS Support.

About the authors