CloudFront and Disaster Recovery

December 12, 2017 #aws #cloudfront #disasterrecovery

Note: If you need a refresher on CloudFront, start with What Is Amazon CloudFront?

After reading Lambda@Edge Now Supports Content-Based Dynamic Origin Selection, Network Calls from Viewer Events, and Advanced Response Generation (Posted On: Nov 21, 2017), I thought it was time to take another look at this feature. Reviewing Using CloudFront with Lambda@Edge, I saw this interesting note:

You can use a Lambda function to generate HTTP responses when CloudFront viewer request or origin request events occur.

That reminded me of the F5 BIG-IP iRule we wrote for WestlawNext that would return a custom “We’re Sorry” HTML page if no servers were available. I’m not sure Lambda@Edge is the right fit or if Customizing Error Responses is better. Regardless, it got me thinking about CloudFront’s potential role in disaster recovery.

Consider this active/passive solution where CloudFront sits in front of the “active” region:

The product’s DNS name points at the CloudFront distribution, and there you specify the name of the load balancer as your origin server. This solution uses an ELB for that Web Distribution in the primary region. In the event of a disaster recovery cutover, that Web Distribution is updated to the name of the load balancer in the DR region. Contrast this with updating the products DNS entry to load balancer and waiting for TTL to pass.

For more background on CloudFront Custom Origins:

However, you now might want to limit traffic flowing into the regional ELBs. Luckily, Restricting ELB access to CloudFront is possible. Amazon publishes the Locations and IP Address Ranges of CloudFront Edge Servers in a JSON file and changes appear as an SNS topic. This allows a Security Group created to restrict to CloudFront IP ranges to be updated whenever Amazon updates those ranges.

I’m sure that I am not the first person to consider this. What do you think of using CloudFront as part of the Disaster Recovery cutover flow?