我们正在使用Wowza实例在基础设施上执行实时流式传输AWS。我们有一个脚本，用于监控负载均衡器并根据每个边缘服务器的连接数/查看者数量在需要时启动/终止实例。它非常适合HTTP/RTMP/RTMPT流式传输。我们现在正在尝试为流式传输实现动态负载平衡HTTPS并自动化扩展过程。我们的主要问题是如何以最佳方式实现自动化？我们不知道将要启动的边缘服务器的 IP，因此无法提前创建 DNS 记录。
一种可能的解决方案是保留一定数量的弹性 IP（即 20 个）和相同数量的 DNS 名称，并在扩展期间使用它们。但这会限制我们可以动态启动的服务器数量。
有没有更优雅的解决方案可以尝试实施？
我们的 LB 基础设施在内部AWS VPC，我们有一个可以使用的星号证书。此外，它Wowza Load Balancer仅用于告诉查看者可用边缘服务器的 IP。之后，查看者直接连接到边缘服务器。
答案1
您可以配置实例以在启动时发现其身份，例如通过在实例标签中或通过实例元数据传递实例所需的 Internet 主机名，并让每个节点在启动时向 Route 53 发送 API 请求以配置其自己的 A 记录，本质上是声明其 Internet 身份。它可以在正常关闭时发送第二个请求以删除该记录。
这是我在竞价实例中使用的机制。
由于您提到您的域名不在 Route 53 中，因此您需要一种解决方法，除非您可以将整个 DNS 托管移至 Route 53，除了政治/企业反对之外，没有理由不这样做。您可以保留您的域名登记使用当前注册商，只需使用 Route 53 即可托管当然是 DNS。
以下是一些可能的解决方法：
您可以获取一个新域名并将其放入 Route 53。缺点是您需要一个新证书。
您可以创建域的子域，并将子域委托给具有NS记录的基本钻石 DNS 服务器中的 Route 53，但您仍然需要新证书，因为该*.example.com证书仅对一级主机名有效：foo.example.com按预期工作，但实际上foo.bar.example.com并非如此。这将需要 的证书*.bar.example.com。
因此，这两种替代方案都需要新的证书。
另一个选择是使用让我们加密并让每台服务器在启动时以编程方式为自己获取免费 SSL 证书。这样您就可以使用任何域或子域，而无需额外的证书费用。
最后，您可以使用一些 DNS 黑客技术。这对某些人来说似乎违反直觉，但由于 Route 53 是一种仅权威（非递归）的 DNS 服务，因此它可以按预期工作。
在 Route 53 中为您现有的域创建托管区域。即使您的 DNS 不是由 Route 53 托管的，这也是有效的。
托管区域将分配 4 个名称服务器，通常采用以下格式：
ns-aaaa.awsdns-bb.com.
ns-cccc.awsdns-dd.net.
ns-eeee.awsdns-ff.org.
nd-gggg.awsdns-hh.co.uk.
a、b、c等是系统指定的数字。
获取这些记录，并使用它们将特定主机名从现有 DNS 服务器委托给 Route 53。
media-100 IN NS ns-aaaa.awsdns-bb.com.
media-100 IN NS ns-cccc.awsdns-dd.net.
针对每个分配的四个 AWS DNS 服务器，重复此过程。这仍然有一定的限制，因为它将池限制为有限的大小，但与保留弹性 IP 解决方案不同，这种方法没有硬维护成本（弹性 IP 地址每小时未用作地址时，每个地址收费 0.005 美元基本的正在运行的实例的弹性 IP)。
当然，您的主 DNS 服务可能支持通配符，在这种情况下，您所需要的只是一组记录：
media-* IN NS ns-aaaa.awsdns-bb.com ; etc., one for each of the 4 hostnames.
这些 NS 记录的工作原理是将每个主机名的解析委托给 Route 53。由于互联网上没有配置将请求发送到您域中任何其他主机名的这 4 个特定的 Route 53 名称服务器，因此 Route 53 不知道您的全部的区域不会破坏任何东西。
一个潜在的常见误解是，一个域只能在 Route 53 中配置一次......但事实上，您可以在相同甚至不同的 AWS 账户中为同一个域名拥有多个托管区域，因为每个托管区域都将由 Route 53 到该区域的特定 4 个名称服务器应答......因此，即使您后来将整个 DNS 移动到 Route 53，如果您将其他 DNS 提供商的其他区域按原样复制到 Route 53 中的新托管区域并使其成为权威区域，则此解决方案不会产生冲突。