Private Route53 Hosted Zone and TLS Certificate from AWS Certificate Manager

At major mining company has an application stack with a number of internal web applications hosted on AWS. These should only be accessible via the internal networks via Virtual Private Network over the internet or Direct Connect fibre link. Since these services/applications are used across teams, friendly names are desirable. The services should be accessible via secure protocols (followed by authentication at a future date Cognito with AD auth etc) as they may contain critical information.

Akkodis AWS Cloud team at this customer was tasked with architecting, testing and implementing a solution to this issue in 2021.

1. Internal hosted zone for the subdomain

An internal hosted zone xxx.$CUSTOMER.com was created. DNS A records with alias pointing to Application Load Balancer (ALB) records were created. This would allow DNS queries to the subdomains in that Virtual Private Cloud (VPC) to point to the required services.

2. Inbound Resolver Endpoints

The services need to be accessible for users on premises with friendly names. To do this we needed the customers DNS servers to forward queries made for the xxx.$CUSTOMER.com domain to be forwarded to the Route 53 service.

A Route 53 Resolver Inbound Endpoint was created for domain resolution for this subdomain in the shared account. A rule was requested to be created in ‘the customers DNS / AD to forward all DNS queries for xxx.$CUSTOMER.com to the Resolver endpoints. Security groups were set correctly on the 2 inbound endpoints to allow queries from the customers internal DNS servers.

Further the internal hosted zone created for xxx.$CUSTOMER.com was shared to the “shared account” so any queries coming into the Route 53 in shared account could resolve the addresses.

Now application subdomains such as app1.xxx. $CUSTOMER.com and app2.xxx. $CUSTOMER.com were easy to create and manage in the application account and the infrastructure supporting these services were tied together with some proper Infrastructure as Code (IaC) automation.

3. SSL Certificates

With the DNS bit sorted the last bit of the puzzle was SSL certificates. We got certs issued for xxx.$CUSTOMER.com and *.xxx.$CUSTOMER.com issued via the Certificate Manager. The wildcard certificate was requested so that it could be used for any application subdomains within xxx.$CUSTOMER.com such as app1.xxx.$CUSTOMER.com and app2.xxx.$CUSTOMER.com.

Email validation was selected, as this is an internal hosted zone and only accessible from within the private corporate network, it cannot be domain validated. Issued certificates were applied to the ALBs and security groups were updated to allow 443 so all services are now accessible via HTTPS.

The solution now has effective security in all environments, meeting the customer’s security requirements and using commodity managed services, across both production and non-production environments.