This content is part of the Essential Guide: Manage colocation costs to avoid billing surprises
Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Navigate noisy neighbor challenges in cloud vs. colocation

In any multi-tenant IT environment, noisy neighbors can be an issue. Here's a closer look at how the challenges differ in the public cloud versus colocation.

Noisy neighbors in IT are just as frustrating as they are in real life -- particularly when it comes to colocation and cloud. If someone has an application that consumes so many network and compute resources that it negatively affects other users' apps, in essence, it behaves like a denial of service attack on your system. However, the last thing you want to do is to throttle back your performance, allowing the neighbor to get on with the party.

One of the differences between cloud versus colocation is that public cloud is a fully multi-tenant environment while colocation is partially shared. With cloud, everything -- the server, storage and network -- is shared; in colocation, although the main servers and storage, along with a portion of the networking, belongs to you, there will be a shared portion of the LAN and the wide area network (WAN) that can cause major problems.

Let's consider the noisy neighbor issue in the cloud versus colocation.

Public cloud

A public cloud platform is predicated on users sharing as much as possible when it comes to resources. The user rarely has much control over the physical infrastructure, having bought into the use of logical resource "chunks." Platform management is also controlled by the cloud provider.

A large cloud provider, such as Amazon Web Services or Microsoft Azure, is unlikely to run out of cloud resources. Effective resource elasticity should ensure that even a resource-intensive application doesn't adversely impact other workloads around it.

However, other cloud services -- particularly those based on a small number of white box servers, a cheap network switch and a network attached storage array -- will run into problems as soon as they get more than one user. There aren't enough physical resources to share; as soon as one application starts to burst, it will try to grab resources. If that burst is due to the application behaving badly -- for example, if it has a memory leak or a poorly programmed re-entrant code loop -- that provider is doomed. The lack of capability to share resources means that something has to give, and in a poorly managed environment, the whole platform could collapse.

In a public cloud environment, the cloud provider must be able to monitor in real time. It must have written into its agreements with users the proper procedures for a rogue workload. At minimum, this should include a rapid warning to the workload's owner.

Avoid providers that just try to sell you a large initial instance of a logical platform so that you have more headroom to play with -- this is no different than overprovisioning in the physical world.

The more established public cloud providers will also make part of that information available to all users so they can account for it with their own workload management tools. There is nothing more annoying for a systems administrator than when everything looks fine on a fully detailed set of logs on their own system only to discover that the damage is due to a neighboring user that allowed some developer to write a subroutine.

Avoid providers that just try to sell you a large initial instance of a logical platform so that you have more headroom to play with -- this is no different than overprovisioning in the physical world. Look for those who can provide dedicated logical resource slices with guaranteed service level agreements. It will cost more, but having a guaranteed amount of network bandwidth could be the best guarantee against being hit by a third-party noisy neighbor.


Another difference between colocation versus cloud is that, with colocation, you own a cage, rack, cabinet or room in which you run your company's applications and functions on your hardware. The main server-to-server network will be fully under your control. But when you need outside access, you will need to use shared infrastructure such as the data center LAN and WAN.

You also have a responsibility to make sure that you aren't the noisy neighbor. Use tools that enable you to monitor in real time. Being able to monitor the data center LAN and WAN is key to making sure you are not a noisy neighbor. This is also a way to see if someone else is being one.

Many colocation providers will have their own systems management capabilities, from simple sys admin tools to full data center infrastructure management tools. Look for those providers who are willing to share data from these systems so that both parties are monitoring.

Look to the colocation providers who are network-agnostic, enabling the use of multiple WAN providers. If a noisy neighbor impacts your traffic, you can switch all or part of your workload over to an alternative network. With the LAN, you may need to look to dedicated, guaranteed logical bandwidth. In extreme scenarios, consider dedicated network connections from your equipment to the WAN, in addition to dedicated WAN connections.

A well-managed colocation environment is where the colocation provider monitors what is going on and provides network switching and management services. This environment also includes full facility management, which will ensure noisy neighbors do not impact your workloads. 

Next Steps

Decide whether cloud or colocation is right for your company

Learn about other neighborly conflicts when it comes to colocation

Compare cloud versus colocation in the enterprise

Dig Deeper on Colocation, hosting and outsourcing management

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

How have you avoided noisy neighbor issues in either the cloud or a colocation facility?