由于共享硬件，AWS实例可能容易出现“嘈杂的邻居”问题，其中一个或多个邻居的实例会占用实例中的资源。
本文build议：
但是，避免吵闹的邻居的最有效的方法是为专门的EC2实例支付额外的费用。
我假设上面的文章是指提供硬件隔离的专用EC2实例 。
问题 ：
正如我理解这篇文章，它暗示着，如果你有很多实例，它们可能都出现在相同的底层硬件上，并且使用所有的硬件，从而防止其他（可能有噪音）的实例运行硬件 – 或者至less使这样做不太可能。
如果这个理解是正确的，你的问题可以回答如下：
只有当你启动了足够多的实例才能完全使用单个底层服务器，并且其他实例不能在其上运行。
您使用的底层硬件上的“插槽”越多，其他人的实例就可以（a）在其上运行，（b）变得嘈杂。
这一推理有几个问题。 首先，我们不知道你的所有实例会自动聚集在同一个硬件上（这可能是这样的，我只是不知道它是什么）。 其次，即使他们这样做，我们也不知道需要运行多less个实例才能将“底层硬件”closures到其他人的实例上。 第三，即使我们这样做，亚马逊也不是愚蠢的，没有免费的午餐。 如果你运行了足够多的实例来完全垄断后端服务器，那么你只需要付出一样的代价就可以租用一个后端服务器。
在我看来，结果是要认识到（a）虚拟化服务器是便宜的，主要是因为可以在不是每个人都使用他们所有服务器资源的基础上进行超卖，（b）如果你真的想要资源专用对你来说，你应该租一个专用的服务器。
有专门的AWS实例完全防止嘈杂的邻居问题？
你自己的例子可能是彼此嘈杂的邻居。 另外，尽pipe您已经向亚马逊付费以确保没有其他人的实例在您的底层主机上运行，但我不相信它会保留整个机架 – 所以您可能会想到同一机架中的其他主机使用更多带宽比机架可用。
如果不能完全防止，它能减less噪声邻居问题多less？
我不相信任何人，但亚马逊能够回答这个问题。
你相信你正在经历这个，还是你只是在计划呢？
在关于EC2的博客文章中可以find很多不准确的陈述。
所谓的“嘈杂的邻居”问题是一个频繁的话题，并淹没在不准确的地方。
当然，专用实例可以解决这个问题 – 如果这是一个问题 – 通过给你一个新的问题，正如已经指出的那样 – 你会成为你自己的嘈杂的邻居。 AWS不会将所有的专用实例都集中在任何物理服务器上，而不是绝对必要的。
但是，两者都不是这样，因为这是一个想象中的问题，这个问题是由于人们普遍对“被盗”的CPU周期缺乏了解以及它们在EC2中的含义所造成的。
EC2基础架构有许多不同的物理configuration。 即使在同一个实例类中，根据您部署的types和自己的负载情况，您也会看到更多或更less的被盗周期，原因与“吵闹的邻居”完全无关。
“m1.small”实例类经常会显示CPU的50％被“偷走”，因为他们已经在物理CPU上为您提供了两倍的速度。 “t1.micro”实例类在100％的CPU利用率大约15秒后可以预测到10％的利用率，并且不会让事情恢复两三分钟 – 这是非常可预测和可重复的，而不是随机 – 而且，这个节stream是通过“偷”循环来完成的。
埃里克·哈蒙德（Eric Hammond）很好地阐明
根据EC2实例types和底层硬件，您可能不会支付所有底层CPU周期的访问权限。 如果你要求一个m1.small被承诺相当于一个旧的，慢速的CPU，亚马逊是不会给你100％的现代，快速的CPU。
在EC2上，窃取不依赖于其他虚拟机邻居的活动。 这仅仅是EC2的一个问题，确保你没有比你付出更多的CPU周期。
– 在EC2实例中非常有规律的时间内CPU占用率高 （serverfault.com）
我肯定已经在我自己的数据中心中对运行多个虚拟机的物理主机上的CPU资源超额订购了虚拟机，并且可能有一些虚拟主机提供商会这样做，所以我并不是说这不可能在任何地方或者不发生在任何虚拟环境中…我只是说如果你认为你在EC2有这个问题…寻找一个不同的问题。
EC2专用租赁的主要目的似乎是“所以你可以说你没有在共享硬件上运行”，以达到监pipe或合规的目的。