Our solution needs a domain name so that it can be addressed on the public Internet. We'll be working with the domain
httpcats.net. We will use AWS Route53 to manage a top level domain (TLD).
The domain used in this book has already been purchased and the zone has been imported into Route53 manually ahead of time. You'll need to do the same thing. This is a required pre-requisite as the domain's name servers have to be updated to reflect those given to us by AWS Route53. If we didn't do this, then any records we created inside of Route53 would be meaningless.
We'll walk through setting up a domain with Google Domains (but you can use any provider you like) and configuring it to use AWS Route53 for its authoritive nameservers.
The domain needs to be correctly configured for Amazon Certificate Manager (ACM) to be able to create and validate a TLS certificate for us. Although ACM can still provision TLS certificates for our domain without it being managed by Route53, it's a lot easier to do use Route53 for this than not.
Without these certificates we'll be using HTTP and that's not a good idea, regardless of whether or not you're transferring sensitive information between your client and the server. Pictures of cats aren't overly sensitive but what if someone changes them between you and the server to pictures of mice? Yikes!
| ||The primary TLD for the HTTP DevOps Cats website|
| || || || ||Address to the ALB endpoint|
| || || || ||Address to the first EIP assigned to our first server|
| || || || ||Address to the second EIP assigned to our second server|
The entries in the
Value column might be confusing. What is this is an internal Terraform reference to another resource's output or attributes. We'll cover this in detail later on and it'll become clear what's happening here.