Amazon S3提供了跨区域复制的选项，该选项应该可以很好地容忍区域/区域中断。这是一个方面吗？或者跨区域复制不是完全傻瓜式的，不会有帮助吗？
#1 楼
复制时的缺点来自以下注释：默认情况下，Amazon S3将任何虚拟托管样式请求都路由到美国东部（弗吉尼亚北部）区域使用美国东部（弗吉尼亚北部）端点（s3.amazonaws.com），而不是区域特定的端点
（例如s3-eu-west-1.amazonaws.com）。
使用复制时，通常让AWS通过将REST请求中来自服务器的
s3.amazonaws.com定位到一个区域来将别名路由到一个区域，然后由重定向完成它的工作。 每当弗吉尼亚州北部出现故障时，魔术就会停止工作，您很不幸运，无法访问您的数据，必须更新配置以选择特定的区域端点。
问题不是来自DNS（对存储桶本身的请求将起作用），而是来自S3客户端，S3客户端将在访问存储桶之前连接到S3 API端点，在这种情况下，dns解析是在
s3.amazonaws.com上完成的，是us-east-1端点。 使用区域别名时，通过包含AWS的运行状况检查，您失去了对区域进行负载平衡的便利性。
如果您使用针对区域快速切换的DNS名称，则对您的DNS TTL负责，但不能保证客户端ISP的缓存服务器会兑现您的价值（客户端可能会遇到的众多缓存之一） 。
最后，如果您尝试自己进行负载平衡，则可能会创建与AWS已经拥有的SPOF相同的SPOF，并且会增加维护负担。
AWS正在处理它，但这就是我撰写本文时所掌握的全部信息。
评论
根据docs.aws.amazon.com/AmazonS3/latest/dev/VirtualHosting.html，可以使用“ bucketname.s3-eu-west-1.amazonaws.com”（替代您喜欢的区域）作为DNS别名。 IFF有效，它可以是一种快速切换的方式（只要您的预设TTL允许）
– Michael Bravo
17年1月1日在11:07
@MichaelBravo扩展了答案，以解决您的问题:)
–滕西拜
17年1月1日在12:31
“即使从理论上讲，即使您可以使用CNAME来对端点进行区域划分，但据我所知并且我已经阅读过，权威性的答案都依赖于弗吉尼亚北部的服务。”默认情况下没有上下文。在example-bucket存储桶存在之前，example-bucket.s3.amazonaws.com已经指向DNS中的美国东部。在初始存储桶创建后的几分钟内，这将永久更改为指向正确的区域端点。这里的警告是，创建存储桶后，此主机名最初可能会短暂地被错误地路由，而不是稍后。
– Michael-sqlbot
17 Mar 2 '17 at 12:21
...因此，“每当弗吉尼亚北部出现故障时，魔术就会停止工作，并且您无法通过DNS别名方法访问任何区域的数据”是不正确的。其他地区的存储桶不受us-east-1中断的影响，包括使用此主机名样式引用的存储桶。
– Michael-sqlbot
17 Mar 2 '17 at 12:25
不，你没有。他们会在创建存储桶后的几分钟内在s3.amazonaws.com区域中为您的存储桶更改DNS条目，并且此更改独立于us-east-1持续存在。在其他区域创建存储桶，并在创建存储桶之前，之中和之后几分钟观察your-bucket-name.s3.amazonaws.com的解析方式。创建存储桶后，该信息会在创建存储桶后被推送到Route 53的s3-1.amazonaws.com区域，并一直保留在此处，而无需进一步依赖us-east-1。
– Michael-sqlbot
17 Mar 2 '17 at 12:29
#2 楼
许多大公司可能会因为不使用此功能而感到不满。它确实增加了额外的成本，并且从历史上讲，即使实施了任何种类的实际灾难恢复解决方案，也都未经测试。除了成本问题之外，积极使用跨区域复制的公司可以提供有关以下方面的有效关注：对象复制所需的等待时间。 S3不允许（据我所知）对复制对象的读写后一致性，但确实允许在单个区域中使用存储桶。
这个SE问题引起了对象的关注复制不正确，或复制时间太长。如果跨区域复制是以最终一致性模式完成的，则有很多问题需要解决。
评论
我将进一步强调S3跨区域复制为某些操作提供最终一致性这一事实。考虑到这一点并非微不足道。根据应用程序的不同，可能完全无法接受。无论如何，它都不是万无一失的（如果有人认为这是魔术，则可能导致更大的问题）
–亚历山大
17年1月1日在4:19
评论
相关：devops.stackexchange.com/questions/83/…@Evgeny谢谢。在问这个问题之前，我正在阅读同一篇文章：)