我开始在AWS EC2的集群中使用多台机器。 自从我开始这个项目以来，我在我的结算信息中看到了区域stream量的成本：
区域数据传输 – 进/出/ EC2 AZ之间或使用弹性IP或ELB
根据这个名字，有三种可能性：
对我的机器有不同的AZ，这是一个问题。 所以我解决了这个问题，现在所有的机器都在同一个AZ里，但是现在成本已经上升了24个小时（在那个时候有3个更新）。 所以看起来，将所有机器设置为相同的AZ没有解决它。
但是，我不使用弹性IP或ELB。 当我在我的门户网站上访问这些页面时，它只是向我显示一个空的列表，并显示一条消息，表示我目前没有任何组件。
在另一个服务器故障的问题中，我们也读到了这种情况，当公共IP地址用于通信时，但是在一些github讨论中，我们可以看到，即使公有DNS名称也将在内部parsing为内部IP（仍然，公有IP将永远通过外部networking，所以实际上会触发成本）。
如果我跟踪我的群集中的主站和其中一个从站的networking通信
sudo tcpdump -i eth0 | grep -v $MY_HOSTNAME 我只能看到像这样的内部stream量：
IP ip-172-31-48-176.ec2.internal.56372 > ip-172-31-51-15.ec2.internal.54768
所以我的问题：我怎样才能找出哪个组件导致这种区域stream量？
大量的区域stream量是由机器启动时的易apt-get update造成的。
起初，我怀疑我在群集上运行的软件，因为这会发送很多DNS请求 – 可能不会使用任何DNScaching。 而DNS服务器在另一个可用区域。
我和一个朋友一起debugging了这个，下面是我们如何到达解决scheme，所以每个人都有这个问题：
首先，从计费pipe理，你可以看到，每GB的成本是0.01美元。 所以它反映了定价网页的以下几点（更详细的内容）：
接下来，我查看了AWS关于可用区域和区域的解释。 我必须支付的肯定是来自同一地区的stream量（在我的情况下， us-east-1 ）。 它可以是从一个AZ到另一个AZ（我们之前知道的）或使用同一个AZ内的公有IP地址或弹性IP地址的stream量（我们也从其他服务器故障问题中知道）stream量。 但是，现在看来这个清单确实是详尽无遗的。
我知道我有：
VPC是一个自己的产品，所以去VPC 。 从那里你可以看到你有多lessVPC。 在我的情况下，只有一个，所以根本不可能。 但是你仍然可以去对等连接 ，看看是否有任何设置。
从VPC的Subnet部分我们也发现了进一步debugging的一些重要线索。 us-east-1 ：不同可用区域的IP范围
us-east-1a 172.31.0.0/20 172.31.16.0/20为us-east-1b us-east-1e 172.31.32.0/20 us-east-1e us-east-1d为172.31.48.0/20 因为我所有的机器都应该在us-east-1d ，所以我证实了这一点。 事实上，他们都有IP开始172.31.51和172.31.54 。 到现在为止还挺好。
这终于帮助我们为tcpdump设置正确的filter。 现在知道我应该与哪些IP进行通信以避免成本（仅限networking172.31.48.0/20 ），我们为tcpdump设置了一个filter。 这有助于消除所有的噪音，使我看不到外部的沟通。 此外，在我甚至不知道与[something].ec2.internal通信可能是问题之前，因为我对区域，AZ和他们各自的IP范围不够了解。
首先我们想出了这个tcpdumpfilter：
tcpdump "not src net 172.31.48.0 mask 255.255.240.0" -i eth0
这应该显示所有来自世界各地的交通，但us-east-1d 。 它显示了很多来自我的SSH连接的stream量，但我看到一些怪异的东西 – 一个ec2.internal地址。 难道他们不应该被全部过滤掉，因为我们不再显示AZ内部的stream量了吗？
IP ip-172-31-0-2.ec2.internal.domain > ip-172-31-51-15.ec2.internal.60851
但这不是内部！ 它来自另一个AZ，即us-east-1a 。 这是来自DNS系统。
我扩展了筛选器来检查这些消息有多less发生：
sudo tcpdump "not src net 172.31.48.0 mask 255.255.240.0 and not src host $MY_HOSTNAME" -i eth0
我等了10秒钟，停止了logging，这是来自DNS的16个响应！
但是，安装dnsmasq后没有任何改变。 当我使用集群时，仍然有几个GB的stream量。
从一天到一天，我从集群中删除了更多的任务，终于在没有任何启动脚本（好！）的情况下尝试了一天，只用了一天的启动脚本+即时关机（stream量！）。
启动脚本的分析显示， apt-get update和apt-get install ...是唯一拉大文件的组件。 通过Google的研究，我了解到，Ubuntu确实在AWS内部有一个软件包仓库。 这也可以从sources.list看到：
http://us-east-1.ec2.archive.ubuntu.com/ubuntu/
parsing主机名会导致以下IP地址：
us-east-1.ec2.archive.ubuntu.com. 30 IN A 54.87.136.115 us-east-1.ec2.archive.ubuntu.com. 30 IN A 54.205.195.154 us-east-1.ec2.archive.ubuntu.com. 30 IN A 54.198.110.211 us-east-1.ec2.archive.ubuntu.com. 30 IN A 54.144.108.75
所以我设置了一个日志stream服务，并在启动时logging了群集。 然后，我下载了这些日志文件，并通过python脚本运行它们，将所有传输的字节汇总到这4个IP地址中的任何一个。 结果符合我的stream量。 在上次testing中，我有1.5GB的stream量，每台机器有3个簇，每台机器有5台机器，根据我的日志stream日志，每台机器从Ubuntu存储库查询大约100MB。