Most of the time people think of DNS as a way for internet users to find your website. However, it is also useful for your applications and services to find each other. Let's say that within your system you have a separate server that provides an AI LLM service via an API. To invoke the service, the code in your main server would need to make that API call using a URL, such as https://ollama.example.com/api/v1/query. However, you do not want to expose this URL to the entire web, both to limit access and to limit usage. How would you do it?

One way would be to add an entry to the web server's /etc/hosts file. As long as the LLM server's IP address doesn't change, this would work and it is a reasonable option if you only need to make a handful of such entries. However, this approach won't scale well and it requires elaborate efforts to configure through infrastructure as code. A slight modification of this approach would be to maintain a lookup table with the host name and the IP address, a roll-your-own DNS. This starts to get inelegant very fast.

Fortunately, AWS Route 53 lets you create a private DNS hosted zone that can be attached to your VPC. A hosted zone is a container for DNS records. A public hosted zone contains records that are visible to the entire internet. The records in a private hosted zone are only visible to the VPC to which the zone is attached. Thus, the above problem of making the LLM server available by hostname can be solved using a private hosted zone and adding a simple type A record for the server. This can be done with straightforward infrastructure code using any platform, whether Terraform, Ansible, CloudFormation, Pulumi, or even the AWS CLI and bash scripts, without needing to manipulate config files within any servers.

One is Good, Two is Better

The real superpower of private hosted zones is that you can create many of them and attach them to separate VPCs. This is a huge benefit when building systems that need to be scalable, fault tolerant, distributed or available for disaster recovery. Each private zone lets you create a virtual DNS within your virtual network, and the workloads within these networks do not need to know that there are similar workloads in other networks. This isolation means that you could create one or a dozen clones with almost no additional effort.

This is a big advantage over having to use a single private zone. In that scenario, you would need to distinguish each new DNS record for a new copy of a service, such as by adding a sequence or some random string.

A Global Solution

The VPCs with their own dedicated private zone can be distributed within a single AWS region, across regions or even across accounts for security isolation. The only additional configuration that is required whenever a new zone is added is to add a record to the public DNS for the additional entry point server.

Another use case would be a globally distributed system with location-based DNS routing to a regional endpoint. Additional regions can be added as usage grows or other requirements such as data protection laws require.

If you want to test this out for yourself, I have created a simple demo that can be scaled to two or more regions. The code is in Github here. I applied it to create two regions. As the following images show, the same DNS entry in each region resolves to a different host IP.

Amazon Route 53 private zones use the same default nameservers, but the DNS query response changes depending on the zone. If a hostname is not defined within the private zone, then the query is forwarded to the next zone in the delegation chain.

Summary

AWS Route 53 private hosted zones round out the "virtual" aspect of virtual private clouds. They permit the isolation of DNS lookups within a VPC to values specific to that VPC. In this manner, each VPC can be a self-contained application system that can be cloned and deployed multiple times, with each deployment independent of each other.