One of the key components in today's digital-driven world is the Domain Name System (DNS). DNS translates domain names into IP addresses. It ensures high availability and reliability of websites or other online resources accessed through domain names.
Amazon Route 53 goes beyond traditional DNS services and plays a key part in the AWS multi-account environment, where connectivity between accounts or between cloud and on-premises sites is required.
Even though Amazon Route 53 is a native AWS service that is available in every account, the management of Route 53 may become difficult in a complex environment. In this case, having a shared VPC can help.
Let's quickly go over what a shared VPC means and why it makes domain resolution a little bit more complex.
Cloud computing offers on-demand delivery of resources either over the public Internet or privately. The compute power in the cloud environment can be accessible privately as long as AWS resources are built in a Virtual Private Cloud (VPC) created by a customer.
A VPC is a logically isolated network allowing customers to use their own private IP address space. The VPC is the most used service because it creates the underlying infrastructure for IT resources instead of buying, owning, or maintaining physical data centers and servers.
It might sound very simple in the beginning, but in a real-world environment, one VPC is never enough, and there is always a need to connect more VPCs together and make them accessible from the customer's on-premises sites or from the public Internet.
A shared VPC architecture allows multiple accounts to deploy resources in centrally managed shared VPC subnets rather than building a large number of VPCs in each account. Such an architecture is beneficial for large organizations that operate in a multi-account environment where the network infrastructure is centrally managed from only one account. The accounts that consume shared VPC subnets are not allowed to make network-impacting changes to the routing or to the network components providing connectivity.
The shared VPC concept saves a lot of efforts by allowing account owners and their associates to operate in their respective accounts, focusing on their own projects instead of creating and operating a new network topology.
Nowadays, almost every company deals with the topic of domain names. A domain name is part of the web address used to find your website. There are domains that are publicly resolvable, but companies also use domain names that are only known internally and can be resolved only by private resources.
If such a requirement for the resolution of a private hosted zone (PHZ) is placed, this is when a DNS PHZ comes into play.
In order to internally reach any web assets or other available resources via domain names built in shared VPCs, the resolution of domain names must be ensured from all corners of the customer’s infrastructure.
A very common solution is centralized DNS management, where the DNS is operated by a dedicated team from their own account. However, this may become very challenging within a growing environment because network administrators get overwhelmed by the number of requests for creating or updating PHZs or by challenges in monitoring, troubleshooting, and maintaining DNS records.
Centralized DNS management also creates dependency and lacks the flexibility needed for effective operation in other accounts.
How about a cost-effective solution that gives projects the freedom to operate their own DNS as they please from their accounts without additional expenses and still keep it resolvable across the entire infrastructure?
The architecture aims to fully automate all steps required to make domains resolvable while the creator of the PHZ needs to type only a few lines of code using modern IaC tools such as Terraform.
The solution automates, simplifies, and accelerates the entire process of authorization and association so that the projects happening in an organization’s accounts are not limited by the Route 53 domain creation process, and they are allowed to manage and make changes to their own DNS.
The main benefits brought by the solution are:
By implementing architectural components and following certain prerequisites, the solution facilitates the steps required to make domains resolvable across the entire customer network, including on-premises environments as well as multiple shared VPCs. The incorporated automation performs the authorization/association process that must be executed by the VPC owner account. It also removes dependency, allowing projects to independently manage their own DNS without additional overhead.
After successful implementation, network administrators take responsibility for the connectivity part to ensure that IP addresses returned by Route 53 DNS are reachable, whereas project account administrators are responsible for maintaining and managing the PHZ and records created in it.
