我目前的设置是，www.domain.com通过CloudFront为S3托pipe的静态网站提供服务，因此www.domain.com CNAME指向CloudFront分配，后者又指向S3静态网站URL。 CloudFront发行版将www.domain.com为备用域名。
我想使用Route53的地理位置function将请求从北美路由到当前的CloudFront（A），而所有其他请求则发送到另一个CloudFront（B）来托pipe另一个S3静态网站。 由于我无法将www.domain.com添加为两个CloudFront分配的备用域名，因此我使用通配符*.domain.com代替CloudFront A.
通配符工作，例如我设置的eu.domain.com正确地服务于CloudFront B站点。
我在Route53中正确设置了Geolocation规则， dig返回正确的CloudFront端点。 同样，Route53 Webtesting平台根据IP位置给出正确的端点。 但是， curl和网页浏览器会给出错误的内容 – 即即使我在欧盟也是CloudFront A.
我的configuration有什么问题吗？ 出于某种原因，DNS级别的A级分发版存在无提示故障转移吗？ 或者一些讨厌的caching？ 这可以完成吗？ 谢谢！
但是，curl和网页浏览器给出了错误的内容
实际上，他们在上下文中给出了正确的内容。 （坚持我，这里…）
从技术上讲，问题在于你实际上是想要/期待一个实际上是不正确的回应 – 如果实际上按照你预期的方式工作，根据请求做出的行为是错误的。
使用curl -v来查看请求标头。 他们可能会连接到通过查询eu.example.com检索到的地址，但请检查此请求标头：
> Host: www.example.com
浏览器实际上正在得到它所要求的。
这就是为什么您不能将相同的备用域名分配给两个CloudFront分配。 CloudFront – 就像基本上所有的Web服务器一样 – 使用浏览器发送的Host:头来了解浏览器希望看到的网站。 Web服务器不能看到你到他们的DNSpath。 在连接到为不同站点返回的IP地址的情况下，您可以做到这一点并不令人吃惊 – select任何CloudFront IP并伪造其他站点的Host:标头，这很可能会奏效，因为那么侦听该地址的CloudFront设备就可以在CloudFront中查找configuration并为请求提供服务。
只能使用CloudFront和Route 53完成此configuration。
您需要在EU的目标区域中的EC2中的代理服务器充当DNS中的eu域的目标，重写Host:标头，并将修改后的请求转发到CloudFront。