我正在尝试将Route53域重定向到另一个Route53域，同时维护子域。
我有一个包含我的主网站的example.com的Route 53托管区域。
我有另一个Route 53托管区域为example.co.uk，我使用S3静态网站重定向规则重定向到example.com（如https://stackoverflow.com/a/14289082/918030所述）
这适用于根域，但我想映射子域，如以下示例所示：
sub1.example.co.uk --> sub1.example.com
sub2.example.co.uk --> sub2.example.com
...
sub999.example.co.uk --> sub999.example.com
我知道这可以通过为每个子域创建一个新的S3存储桶并配置相应的S3静态网站重定向规则来完成，但我想知道是否有办法动态地这样做* .example.co.uk转发到* .example.com。 最好不必运行单独的EC2实例（运行nginx）
谢谢！
斯泰恩
答案 0 :(得分：2)
使用现成的AWS服务（当然不包括EC2）的任何组合都没有一种简单的方法...除了为每个要重定向的子域创建一个唯一的存储桶。每个帐户限制的100个桶现在是软限制而不是硬限制，因此您现在可以 - 通过提供合理的用例 - 请求AWS支持增加您的存储桶限制。
这并不能解决必须提供它们的问题，当然，虽然Route 53中的单个通配符CNAME允许您使用根区域网站端点作为目标，然后集体路由到S3，至少S3目前的工作方式，这意味着依赖于一些似乎不太可能改变的未记录的S3行为，但可能会改变。
请求主机名不匹配已经创建的存储桶仍然会转到S3并返回“NoSuchBucket”错误，这会出现一个问题......事实上，在追求通配符时，这是值得深思的。
两段回来，我提到利用指向S3的通配符CNAME来利用一些未记录的行为。想象被那些阅读过文档而未尝试过S3实际行为的潜在评论者召集出来，我在Route 53的一个托管区域设置了一个通配符CNAME，指向*.mysterystring.example.com到{{1 }}。这不是文档说你应该怎么做的，但果然，这完全符合我的预期......无论你用什么代替s3-website-us-west-2.amazonaws.com，如果你有一个以完整域名命名的存储桶us-west-2，S3根据要求提供服务。如果没有，这是一个“NoSuchBucket”错误，完成了S3尝试查找的存储桶名称，但不能。那么，为什么我没有提到实际的测试设置域来证明我的观点呢？嗯... 任何人嗅探可以使用与该通配符匹配的未使用的主机名之一创建一个存储桶，并在我的域中拥有一个网站，在S3中使用该设置进行托管，但我没有配置，没有我的知识。 （！？）当然，他们会为水桶收费，但嘿，免费领域蹲！接下来你知道，他们冒充我，偷客户，谁知道？
所以，红旗：请注意通配符重定向未设置资源的含义。
另一方面，如果你想重定向所有东西（并且你采取措施确保目的地真的是一个无法秘密声明未使用的主机名的死胡同），EC2实例将不会是糟糕的交易。 t2.micro可以轻松地为每天数十万个轻量级请求（例如重定向）提供服务（我有一个常规处理超过300k /天并且总是有备用CPU信用额度）的＆lt; $ 10 /月。