Search code examples
amazon-web-servicesamazon-s3amazon-cloudfrontamazon-route53failover

How to check if CloudFront is failing over to another active distribution?


I have a website s3post.cf that gets a .json.gz from an AWS CloudFront distribution that has an S3 bucket as its origin.

I've enabled cross-region replication for that bucket with another bucket and set up a second CloudFront distribution.

On Route 53, I created a health check associated with a file in the first bucket cloudfront.s3post.cf and setup a CloudFront failover -

  • The second distribution backup.s3post.cf has a simple routing policy to its CloudFront distribution's domain name.
  • The first distribution post.s3post.cf has a primary failover policy associated with above mentioned healthcheck.
  • post.s3post.cf also has a secondary failover policy that uses backup.s3post.cf(the second distribution) as its alias.

To test this setup, I removed public permissions from the health check file. The health check failed and my site is still alive. However, the .json.gz file in both buckets is public so I'm not sure if the failover succeeded.

How can I test if post.s3post.cf actually failed over to backup.s3post.cf? I can't just delete the .json.gz file as it's deleted in the second bucket too due to cross-region replication.


Solution

  • A check of your CloudFront access logs will show you that requests are still being served from the primary distribution. What you are attempting fails to take into account how CloudFront decides which distribution handles a given request -- it isn't through DNS.

    CloudFront uses only the Host: header sent by the browser, to decide which distribution services each incoming request.

    As long as the DNS CNAME resolves to any CloudFront distribution, the request still arrives at CloudFront -- but CloudFront, just like any web server or proxy, remains unaware of the resolution path. It only knows which site the browser thinks you wanted -- the hostname showing in the address bar. That's the distribution that will be serving your requests, regardless of how DNS is configured.

    This strategy will not work.