does having dedicated instances completely prevent noisy neighbor issues?

Question

Due to sharing of hardware, AWS instances can be prone to 'noisy neighbor' issues, where one or more of your neighbor's instances hog resources from your instance.

This article suggests:

The most effective way to avoid noisy neighbors, however, is to pay extra for dedicated EC2 instances.

I'm assuming the above article is referring to dedicated EC2 instances providing hardware isolation.

Questions:

1. Does having dedicated AWS instances completely prevent noisy neighbor issues?
2. If it doesn't completely prevent, how much does it reduce the noise neighbor issue?

Answer 1

As I understand the article, it's suggesting that if you have a number of instances, they're likely to all be present on the same underlying hardware, and to use all that hardware, thus preventing other (potentially noisy) instances from running on that hardware - or at least making it much less likely that any such will.

If this understanding is right, your questions can be answered as follows:

1. Only if you launch enough instances that they completely use a single underlying server, and no other instances can run thereon.

2. The more "slots" on the underlying hardware you use, the less likely it is that someone else's instance can (a) run on it, and (b) turn out to be noisy.

There are several problems with this line of reasoning. Firstly, we don't know that all your instances will automatically cluster on the same hardware (this may be so; I just don't know that it is). Secondly, even if they do, we don't know how many instances you need to run in order to close "your" underlying hardware to other people's instances. Thirdly, even if we did, Amazon aren't stupid, and there's no such thing as a free lunch; if you run enough instances to completely monopolise a backend server, you would expect to pay about the same as simply renting a backend server.

It seems to me that the upshot is to recognise that (a) virtualised servers are cheap primarily because one can oversell them on the basis that not everyone uses all of their server's resources all the time, and (b) if you really want resources dedicated to you, you should rent a dedicated server.

Answer 2

Does having dedicated AWS instances completely prevent noisy neighbor issues?

Your own instances might be noisy neighbors to each other. Also, while you've paid Amazon to ensure that no one else's instances run on your underlying host, I don't believe it reserves an entire rack - so you could conceivably run into an issue where other hosts in the same rack are using more bandwidth than the rack has available.

If it doesn't completely prevent, how much does it reduce the noise neighbor issue?

I don't believe anyone but Amazon is able to answer this one.

Answer 3

Do you believe you are experiencing this, or are you just trying to plan for it?

There are a lot of inaccurate statements you can find in blog posts about EC2.

The alleged "noisy neighbor" problem is a frequent topic, and drowning in inaccuracies.

Sure, dedicated instances would solve this problem -- if it were a problem -- by giving you a new problem, as has been noted -- you'd be your own noisy neighbor. It would make no sense for AWS not to cluster all of your dedicated instances on any more physical servers than absolutely necessary.

But, neither one is the case, because it's an imaginary problem caused by a widespread lack of understanding about what "stolen" CPU cycles are, and what they mean in EC2.

The EC2 infrastructure has a number of different physical configurations. Even within the same instance class, depending on which type you're deployed on, and your own load, you'll see more or fewer stolen cycles, for a reason entirely unrelated to "noisy neighbors."

The "m1.small" instance class frequently shows 50% of your CPU being "stolen," because they've provisioned you on a physical CPU twice as fast as what they're charging you for. The "t1.micro" instance class throttles you down to 10% utilization quite predictably after about 15 seconds of 100% CPU utilization, and doesn't open things back up for two to three minutes -- and it's very predictable and repeatable, not random -- and, yes, this throttling is done by "stealing" cycles.

Eric Hammond clarifies this quite well:

Depending on the EC2 instance type and the underlying hardware, you may not be paying for access to all of the underlying CPU cycles. Amazon is not going to give you access to 100% of a modern, fast CPU if you have asked for an m1.small which is promised to be equivalent to an old, slow CPU.

On EC2, steal doesn't depend on the activity of other virtual machine neighbors. It is simply a matter of EC2 making sure you are not getting more CPU cycles than you are paying for.

^{— High CPU% stolen on EC2 instance at extremely regular intervals (serverfault.com)}

I've certainly over-subscribed virtual machines to CPU resources on physical hosts running multiple VMs in my own data center, and there are likely some virtual hosting providers that do this, so I'm not saying it's not possible anywhere or doesn't happen in any virtual environment... I'm only saying if you think you are having this problem in EC2... look for a different problem.

The primary purpose of dedicated tenancy in EC2 seems to be "so you can say you aren't running on shared hardware" for regulatory or compliance purposes.