我正在构建一个为客户提供创作工具的Laravel应用程序。每个客户都将获得自己的子域名，如：
customer-a.my-tool.com
customer-b.my-tool.com
我的工具在亚马逊的多个地区托管以提高性能，但主要是出于隐私法原因（GDPR ++）。每个客户只在一个地区拥有他们的数据。澳大利亚客户在澳大利亚，欧洲客户在欧洲等。因此客户用户必须被引导至正确的区域。如果欧洲用户最终被美国地区服务，他们的数据将无法存在。
我们可以使用DNS手动解决此问题，只需将每个子域指向正确的IP，但我们不希望这样做有两个原因。 （1）更新DNS可能需要长达60秒。我们不希望客户等待。 （2）我们研究的网站似乎使用了通配符域。例如slack和atlassian.net。我们知道atlassian.net也有多个地区。
所以问题是：
我们如何使用通配符域并仍然将流量路由到内容所在的区域？
注意：
答案 0 :(得分：2)
我们如何使用通配符域并仍然将流量路由到内容所在的区域？
从本质上讲，考虑到您所施加的所有约束条件，实际上不可能完成您要执行的所有操作：自动，即时，一致，零开销，零成本和零复杂度。
但这并不是说完全不可能。
您声称其他供应商正在使用＆＃34;通配符域，＆＃34;这是一个与我怀疑你认为必然有必要的概念本质上不同的概念。 DNS中的通配符（如*.example.com）不是您可以证明排除其他可能性的原因，因为通配符记录会被更具体的记录覆盖。
对于您可以观察到的有形示例，您自己...... *.s3.amazonaws.com有一个DNS通配符。如果您查询some-random-non-existent-bucket.s3.amazonaws.com，您会发现它是有效的DNS记录，并且它会路由到us-east-1中的S3。如果您随后在另一个区域中使用该名称创建存储桶，并在几分钟后查询DNS，您将发现它已开始返回指向您创建存储桶的区域中的S3端点的记录。是的，它是并且是一个通配符记录，但现在有一个更具体的记录覆盖了通配符。覆盖将持续至少与存在桶一样长。
在架构上，按地区隔离数据的其他供应商（而不是复制它，这是另一种可能性，但不适用于您的方案）必须沿着以下某条线做某事：
创建特定的DNS记录并接受延迟，直到DNS准备好或
实施我称之为＆＃34; hybrid＆＃34;最初采用单向行为的环境，最终采用不同的方式，此环境使用特定的DNS记录覆盖通配符，能够通过反向代理临时向正确的集群发送错误路由请求，以便在DNS传播或
正在进行的＆＃34;双层＆＃34;环境，使用没有更多特定记录的通配符来覆盖它，运行双层基础结构，具有全局分布的外层，接受任何请求，并具有将请求传递到内层的内部路由记录 - 正确的区域集群。
第一种选择似乎并不合理。等待很短的时间来创建自己的子域似乎相当普遍。但是，还有其他选择。
第二个选项，即混合环境，只需要您的通配符默认指向的位置能够执行某种数据库查找以确定请求的位置，并在那里代理请求。是的，如果您自己在EC2中实现此操作，则需要为区域间传输付费，但只有在DNS更新生效之后才能支付。任何两个AWS区域之间的区域间带宽成本远低于向Internet传输的数据 - 远远低于＆＃34; double＆＃34;费用。
这可以通过任何相对简单的方式实现。
几乎按照定义，您必须在某个地方拥有站点配置的主数据库，并且可以通过提供代理的复杂服务来查询此系统 - HAProxy和Nginx都支持代理，并且都支持可能的Lua集成用于查找路由信息，只要需要处理暂时的错误路由，就可以对其进行缓存和使用。要求。 （HAProxy还有静态但可更新的映射表和动态＆＃34; stick＆＃34;表，可以在运行时通过特制的请求进行操作; Nginx可能提供类似的东西。）
但EC2并不是解决这个问题的唯一方法。
Lambda @ Edge允许CloudFront分配基于逻辑选择后端 - 例如对DynamoDB表的查询或对可以查询关系数据库的另一个Lambda函数的调用。你的＃34;通配符＆＃34; CloudFront分发可以实现这样的查找，在内存中缓存结果（容器重用允许使用全局变量中的对象进行非常简单的内存中缓存）。一旦DNS记录传播，请求将直接从浏览器转到适当的后端。 CloudFront作为CDN销售，但它实际上是一个全局分布式反向代理，具有可选的响应缓存功能。这种能力起初可能并不明显。
事实上，CloudFront和Lambda @ Edge可以在＆＃34; hybrid＆＃34;中使用。环境或＆＃34;双层＆＃34;环境。外层是CloudFront - 它自动将请求路由到最靠近查看器的AWS网络边缘，此时可以在边缘做出路由决策，以确定处理请求的内层的正确集群。在这里，您不需要支付任何费用，因为从EC2到CloudFront的带宽不需要任何费用。除了初始数据库查找所需的时间之外，这不会影响站点性能，并且一旦您的活动容器具有缓存，站点的响应性将不会受到损害。一般来说，CloudFront可以提高站点的响应能力，即使大部分内容都是动态的，因为它优化了查看器和后端之间的网络路径和协议交换，优化了TCP堆栈和连接重用（特别有助于减少TLS握手需要多次往返）。
事实上，CloudFront似乎提供了两种方式的机会 - 最初的混合功能可自动转变为双层基础架构 - 因为CloudFront发行版还具有通配符功能并具有覆盖：*.example.com的分发处理所有请求，除非配置了具有更具体的域名的分发 - 此时其他分发将开始处理流量。在新分发覆盖通配符之前，CloudFront需要几分钟，但是当切换发生时，它会干净。配置新分发后几分钟，您将对新分配的新分配主机名进行并行DNS更改，但CloudFront的设计方式使您无需紧密协调此更改 - 所有端点都将处理所有域都是因为CloudFront不使用端点做出路由决策，它使用SNI和HTTP Host标头。
这似乎很简单。默认的通配符CloudFront分配由默认的通配符DNS记录指向，并使用Lambda @ Edge来识别哪些群集使用数据库查找处理给定的子域，然后部署 - 当然是自动的 - 每个客户的分发，已经知道如何将请求转发到正确的集群，因此在子域完全生效后不需要进一步的数据库查询。您需要让AWS Support从默认值200开始增加您的帐户对CloudFront分配数量的限制，但这不应该是一个问题。
有多种方法可以完成数据库查找。如前所述，Lambda @ Edge函数可以调用VPC中的第二个Lambda函数来查询数据库中的路由指令，或者您可以将域位置配置推送到DynamoDB全局表，这会将域路由指令复制到多个DynamoDB区域（目前是弗吉尼亚州，俄亥俄州，俄勒冈州，爱尔兰和法兰克福）和DynamoDB可以直接从Lambda @ Edge函数查询。