我们想看看如果使用Route 53，我们可以将stream量路由到我们的机器，而不是AWS ELB，只是为了进行实验，我们注意到了以下情况。
我们有一些在AWS ELB下运行的Nginx机器。 我们还更新了路线53中这些机器的公共IP，并立即删除了不健康的IP。 然后，我们添加了加权路由，以便一半的stream量通过ELB，另一半直接通过Route 53到这些机器。 我们在所有机器上都启用了Grafana监控，所以这意味着我们应该看到Grafana的stream量几乎翻倍，就像我们在AWS ELB中看到的那样。 事实并非如此。 我们看到ELB中几乎80％的stream量仍然存在。 我们24小时前启用了。 当我们没有这种stream量分割，并且单独向ELB发送stream量时，Grafana仪表板和AWS ELB显示了完全相同的stream量，导致我们相信我们的监控stream水线是正常的。
我们做了这个练习，因为我们最终希望移除AWS ELB来代替我们自己，我们想要知道我们的机器是否可以在没有ELB的情况下处理事情，因为现在他们将直接连接到客户端。 我现在的问题是：我们是否失去了交通，我们如何发现？ 为什么在一天之后，ELB仍然会显示超过50％的stream量？
现在ELB显示6.8M，但是Grafana显示了9M。 至less在理论上，Grafana至less应该是ELB的两倍？ 我知道IP必须被ISP或客户端caching，但在这种情况下，如果ELB机器停机，这些IP的stream量必然会丢失？ 我有点困惑，困扰。
作为DNS服务的Route53不控制多lessstream量以及stream向哪里。
想想这样，你有2个客户端 – 客户端1和客户端2。 Client1查询yourdomain.com并接收IP地址10.100.10.20，然后Client1通过30个连续的连接下载100 MB。
现在，Client2查询yourdomain.com并接收到IP地址10.100.10.30，然后Client2通过50个连续的连接下载25 MB。
在这种情况下，Route53均匀地在两台服务器之间“平衡”DNS请求。 但是，每个客户端拉取不同数量的数据，并build立不同数量的连接。 所以现在你的负载平衡器显示100MB的stream量和30个连接，Grafana显示125Mb的stream量和80个连接。
如果你想真正的负载平衡stream量，那么你需要一个负载平衡器。 ELB就是这样做的。 Route53不这样做，它只负载平衡DNS请求。