我最近被介绍到AWS，我真的非常喜欢它。但是，我问自己一些关于多区域架构的问题（可能是愚蠢的）。
假设一个应用程序被欧洲人和亚洲人使用。我的第一个想法是在欧洲添加EC2实例，以及在欧洲保存静态数据和SQS队列以及ElastiCache的S3存储桶。对于欧洲人来说，这将是非常快，但对于亚洲人来说会慢得多。
要解决此问题，我会为静态数据添加CloudFront，以便为亚洲人快速提供图像。但是，对服务器的请求（Ajax请求......）仍然会有一些延迟，因此解决方案是在新加坡/东京地区添加EC2实例。
然而，出现了新的问题：如果请求被分派到东京EC2实例，那么如果它需要从存储在欧洲的SQS接收消息或访问ElastiCache data =＆gt;再次延迟+区域间转移的成本。那么我们也需要在亚洲添加SQS和ElastiCache吗？
也许我错过了一些东西，跨区域的AWS请求超快，但据我所知，如果我们想要多区域的快速体验，我们基本上需要在每个区域复制所有服务（除了S3也许，因为我们可以使用CloudFront，如果亚洲的SQS工作需要访问欧洲的S3资源，我想我们可以忍受延迟。
无论如何，我是否理解正确？您是否有任何关于如何针对多个区域的架构应用程序的资源？
谢谢：）
答案 0 :(得分：7)
这些都不是愚蠢的问题！这部分绝对正确：
Maybe I miss something, and cross-regions AWS requests are super-fast, but from
what I've understood, if we want fast experience for multi-regions, we basically
need to duplicate all services too every regions
跨区域请求将受到光速和区域之间网络拓扑的限制。我希望亚洲的请求能够在大约1/4的往返时间内到达欧洲申请。大多数请求会更快，但您无法保证所有请求都会更快，因此您必须相应地进行设计。如果这还不够快，那么是的，您需要部署到更近的区域并将用户路由到适当的区域。需要往返的次数取决于您的应用程序的体系结构。如果您对Elasticache或SQS有很多请求，那么1/4秒将非常快速地加起来。如果您可以批量处理请求，则可以容忍。
要将用户路由到相应的区域，您需要查看Route 53，这是AWS系列的另一部分。关于Route 53的This announcement描述了您需要的区域之间基于延迟的路由。将用户路由到相应的EC2实例后，应将您部署到的每个区域隔离。您可以使用EC2，SQS，Elasticache以及欧洲地区（eu-west-1）提供的任何其他AWS产品配置您的欧洲部署。对于您的亚洲部署，您可以将其全部托管在ap-southeast-1区域。一旦Route 53将亚洲用户连接到ap-southeast-1内的EC2实例，对SQS，Elasticache等的请求将在同一区域内，因此非常快。
答案 1 :(得分：1)
Amazon Web Services引入的实用程序模型可帮助您在多个区域中部署相同的服务。相同的CLI命令/ Web控制台/ CloudFormation脚本以相同的方式在所有区域中工作。因此，在新加坡和欧洲推出类似的服务对你来说应该不复杂。除此之外，您还可以从同一位置管理所有这些 - 云的力量。
由于您为所使用的产品付费，它也不会更昂贵，如果您在区域之间分配负载，您将获得或多或少相同的成本。例如，如果您需要10台服务器来为您的用户提供服务，那么您可以在欧洲拥有5台服务器，在新加坡拥有5台服务器。超过;根据使用auto-scaling的加载小时，您可以在不同区域中拥有不同数量的服务器。例如，当欧洲清醒时欧洲有8台服务器，而新加坡只有2台服务器，那时它就是夜晚，反之亦然。
通过将上述多区域服务（EC2，S3，ElasticCache，RDS ...）与Amazon CloudFront（CDN）和Route 53（DNS）相结合，您可以创建一个可扩展且价格合理的服务，具有出色的延迟全球（欧洲，亚洲，北美和南美......）。