Amazon web services 使用通配符子域将流量路由到特定AWS区域

我正在构建一个为客户提供创作工具的Laravel应用程序。每个客户将获得自己的子域，即：

customer-a.my-tool.com
customer-b.my-tool.com

出于性能考虑，我的工具在多个地区的Amazon上托管，但主要是出于隐私法原因（GDPR++）。每个客户仅在一个地区拥有其数据。澳大利亚客户在澳大利亚，欧洲客户在欧洲等，因此必须将客户用户定向到正确的地区。如果一个欧洲用户最终被美国地区服务，他们的数据就不会存在

我们可以使用DNS手动解决这个问题，只需将每个子域指向正确的IP，但出于两个原因，我们不想这样做。（1） 更新DNS可能最多需要60秒。我们不希望客户等待。（2） 我们研究的网站似乎使用了通配符域。例如slack和atlassian.net。我们知道atlassian.net也有多个区域

所以问题是：
我们如何使用通配符域并将流量路由到内容所在的区域？

注:

• 我们不希望所有地区都有内容，但我们可以在所有地区都有一个DynamoDB，将子域映射到各个地区
• 我们不想把一个组织和一个地区联系起来。也就是说，像customer-a.region.my-tool.com这样的域结构是我们考虑过的一个选项，但被放弃了
• 当然，我们不想为两次数据传输付费，让所有地区的应用程序访问数据所属地区的数据库也不是一种选择，因为这样会很慢

我们如何使用通配符域并仍然将流量路由到内容所在的区域

从本质上讲，考虑到您施加的所有约束，您不可能做到所有您想做的事情：自动、即时、一致、零开销、零成本和零复杂性

但这并不是说这是完全不可能的

您已经断言其他供应商正在使用“通配符域”，这是一个本质上不同于我猜想您认为它必然包含的概念。DNS中的通配符，如

*.example.com

不能排除其他可能性，因为通配符记录被更具体的记录覆盖

对于一个你可以观察到的具体例子，你自己

*.s3.amazonaws.com

有一个DNS通配符。如果您查询

某个随机不存在的bucket.s3.amazonaws.com

，您会发现它是一个有效的DNS记录，并路由到us-east-1中的s3。如果您随后在另一个区域中以该名称创建一个bucket，并在几分钟后查询DNS，您将发现它已开始返回一条记录，该记录指向您创建该bucket的区域中的S3端点。是的，它过去和现在都是一个通配符记录，但现在有一个更具体的记录覆盖了通配符。只要铲斗存在，超控将持续至少一段时间

在体系结构上，其他按区域隔离数据（而不是复制数据，这是另一种可能性，但不适用于您的场景）的供应商必须按照以下方式之一进行操作：

• 创建特定DNS记录并接受延迟，直到DNS就绪或

• 实现我将称之为“混合”的环境，该环境最初以一种方式运行，最终以另一种方式运行，该环境使用特定的DNS记录覆盖通配符，并能够通过反向代理将错误路由的请求临时传递到正确的群集，允许即时正确行为，直到DNS传播或

• 一个持续的“两层”环境，使用通配符而不使用更具体的记录来覆盖它，运行一个两层基础结构，外部层分布在全球，接受任何请求，并具有内部路由记录，将请求传递到内部层——正确的区域集群

第一种选择似乎并不不合理。等待一小段时间来创建自己的子域似乎相当普遍。但是，还有其他选择

第二个选项是混合环境，它只要求通配符默认指向的位置能够执行某种数据库查找，以确定请求应该去哪里，并在那里代理请求。是的，如果您自己在EC2中实现跨区域传输，您将支付该费用，但仅在DNS更新生效之前支付。任何两个AWS地区之间的地区间带宽成本大大低于向互联网传输数据的成本——远低于成本的“两倍”

这可以通过许多相对简单的方式来实现

几乎从定义上讲，您必须在某个地方拥有一个站点配置的主数据库，该系统可以由一个提供代理的复杂服务查询——HAProxy和Nginx都支持代理，都支持Lua集成，可用于查找路由信息，只要需要处理临时“错误路由”请求，就可以缓存和使用它。（HAProxy还具有静态但可更新的映射表和动态“stick”表，这些表可以在运行时通过精心编制的请求进行操作；Nginx可能提供类似的功能。）

但EC2并不是处理这个问题的唯一方法

Lambda@Edge允许CloudFront发行版基于逻辑选择后端—例如对DynamoDB表的查询或对另一个可以查询关系数据库的Lambda函数的调用。您的“通配符”CloudFront发行版可以实现这样的查找，在内存中缓存结果（容器重用允许非常简单的内存缓存，只需在内存中使用一个对象）