Adrian Cantrill’s SAA-C02 study course, learn.cantrill.io, 75 minutes:
‘Route 53 – Global DNS’ section: ‘Public Hosted Zones’, ‘Private Hosted Zones’, ‘Cname VS. R53 Alias’, ‘Simple Routing’, ‘Health Checks’, ‘Failover Routing’ (review of all these), ‘[Demo] Using R53 and Failover Routing (part 1)’, ‘[DEMO] Using R53 and Failover Routing (part 2)’
The main focus for today was the demo for implementing routing policies in R53, to practice failover routing. We also looked at private hosted zones. Prior to this, I watched through the preceding videos a second time to review. My normal practice as of late has been to watch and summarize all the videos related to a specific demo and then complete the demo in the same lesson. This time around I only had time to watch the videos and summarize, so I reviewed them before proceeding to the demo.
We used a CloudFormation stack to create infrastructure. This created a public EC2 instance. Then we allocated an elastic ip for the EC2 instance. We used the EC2 instance as our primary record for configuring failover DNS.
The next step was to configure an S3 bucket as a static website to use as our backup in case the EC2 instance fails. After this we enabled static website hosting, and added a bucket policy.
This was followed by creating the health check and failover record in R53. We created an endpoint health check specified by ip with http as our protocol and the elastic ip as the ip. We did not create an alarm because of the intention to use the S3 bucket as the backup for our main website. Then we were able to peruse logs showing the results of various health checks.
The next step was to create the primary and secondary failover records. The primary was associated with the EC2 instance and the health check, and the secondary was associated with the S3 bucket. All these things together means that the health check willl inspect the endpoint of our website, and determine the state of its health based on specific criteria. If the endpoint health check passes, the end user will see the EC2 instance website. If the health check fails, the end user will see the S3 bucket website.
To test this out, we simulated a failure. The first step was to open the ip address for the running EC2 instance in a new browser tab. While the EC2 instance was running, we started perusing the health checker logs to get a feel for how information is displayed in a health check. After doing so, we simulated a failure by stopping the EC2 instance, and then continuting to refresh our health check pages and the website page. After sometime the health check status changed from health to unhealthy, and the website changed from the EC2 instance to the S3 failover backup copy, which displays a different landing page in this case. After this, we started the EC2 instance, and after a number of refreshes, the health status changed back to healthy and the website landing page changed back to the EC2 instance.
The last step was to create a private hosted zone routed with a simple routing policy, associating the private hosted zone with the default vpc, connect to an EC2 instance using instance connect, and then to attempt pinging the test address we defined in the routing policy. The ping timed out because the instance has no association with the private hosted zone. After this we associated the A4L vpc with the private hosted zone, and after a number of refreshes were able to ping the private hosted zone.