0

我有一个网站s3post.cf,它从AWS CloudFront distribution得到一个.json.gz,它的起源是S3 bucket如何检查CloudFront是否故障切换到另一个活动分配?

我已启用该存储区的跨区域复制,并且设置了第二个。

在路线53,我创建了一个文件中的第一桶cloudfront.s3post.cf和设置相关的CloudFront的故障进行健康检查 -

  • 第二分布backup.s3post.cf有一个简单的路由策略,其CloudFront的分配的域名。
  • 第一个分发post.s3post.cf具有与上述健康检查相关的主要故障转移策略。
  • post.s3post.cf还具有使用backup.s3post.cf(第二个分发版)作为别名的辅助故障转移策略。

要测试此设置,我从健康检查文件中删除了公共权限。健康检查失败,我的网站仍然活着。但是,两个桶中的.json.gz文件都是公用的,所以我不确定故障转移是否成功。

如何测试post.s3post.cf实际上是否失败到backup.s3post.cf?由于跨区域复制,我不能删除.json.gz文件,因为它在第二个存储桶中也被删除了。

回答

1

检查您的CloudFront访问日志将向您显示请求仍在从主要分发版提供。您尝试的内容未能考虑CloudFront如何决定哪个分发处理给定的请求 - 这不是通过DNS。

CloudFront使用只有Host:头由浏览器发送,以决定哪个分发服务每个传入请求。

只要DNS CNAME解析到任何 CloudFront的分发,请求仍然到达CloudFront的 - 但CloudFront的,就像任何Web服务器或代理,仍不知道该决议路径。它只知道浏览器认为你想要哪个网站 - 显示在地址栏中的主机名。无论DNS如何配置,这都是为您的请求提供服务的分配。

此策略不起作用。

+0

你说得对。该策略失败。有什么办法可以做到这一点?我基本上想要实现一个故障转移场景,如果通过CloudFront提供文件的S3存储桶在一个区域中关闭,另一个区域中的备份S3存储桶就会启动。任何建议都会非常有用。 –

+0

您可以使用EC2中的反向代理服务器在故障转移区域中处理标头重写来完成此任务,但现在还没有全部本机服务解决方案 - 您必须提供一些自己的组件。 –