Evaluating Colocation Data Centre Pricing – Executive Summary

Once you receive a proposal from a potential colocation data centre services vendor, usually in response to your RFP (Request for Proposal), you’ll be faced with interpreting it and then comparing it to others.

That can be challenging for your technical and procurement personnel.

I’m writing this article as a summary for senior leadership levels within an enterprise. It provides an executive overview of the main pricing variables and how you might be able to influence them.  A more detailed pricing analysis can be read within this article.  

As a result, I have intentionally excluded detail. There is a separate article available containing more detailed information. That may be more useful for RFP production teams, those personnel involved in evaluating the details of proposals and interested senior leadership.

This piece assumes the reader has some familiarity with the principles of the service propositions of colocation data centre vendors.


Commercial and contractual issues

I’m not going to dwell on these here but this is important.

Executive leadership typically ask two immediate questions of a data centre proposal:

  • “what’s in it for us?”;
  • “how much is this going to cost?”.

They are perfectly legitimate but they result in a natural tendency to look immediately at the bottom line of a proposal and to form a very fast initial impression which can influence all subsequent discussions.

I strongly recommend that enterprises avoid a rush to focus on ‘the price’. An apparently attractive pricing proposition might subsequently prove to mean little if it’s not underpinned by various forms of guarantees around things such as security, cost constraints, billing cycles, service levels and so on.

The categories of data centre pricing

Unfortunately, I can’t provide a definitive checklist of what will be included in a data centre proposal. That’s because the nature of a proposition and the services it contains may have a huge variety of content. Terminology might also differ somewhat from one proposal to another.

To begin making sense of the pricing, it’s worth thinking about the proposal’s financial aspects as they are likely to break down under typically several of the following headings:

  • space – usually meaning for the amount of floor space your equipment and its storage units will occupy. Some RFPs specify this but it is typically a figure produced by the potential vendors following their analysis;
  • racks (possibly cages/cabinets) – the number of storage units you’ll require for your equipment;
  • power – this is often the single biggest consumable cost clients will incur;
  • services – typically including things such as telephone/email support, problem investigations and resolutions, annual service charges, personnel allocations (most commonly seen in full outsourcing situations);
  • bandwidth & telecoms – a highly variable component. You may pick up some elements of these costs directly from third parties, as well as some from your data centre services vendor;
  • standby provisions and ‘mirroring’ – the extent to which you require additional redundant space and power to cope with either unexpected problems or surges in your business volumes. This may or may not be listed as a separate pricing component;
  • equipment and resources rental – this is applicable in situations where you are opting for a totally ‘outsourced’ IT environment arrangement. It might include the cost of servers or server space rental. Some software licence fees might be included here in these circumstances.

I’ll explain more of each of these below but your pricing may include several of the above components rolled together or they may be separated. You may need to tease some of them apart in order to easily compare one proposal against another.


Space is relatively straightforward to understand but it can also be misleading.

Different vendors may operate different pricing models here. Some might simply quote in the square or cubic metres occupied by your proposed co-location. Others might suggest pricing solutions based exclusively on your rack requirements.

That can also be influenced heavily by your specific requirements for just how separate you want your co-location to be from others in the same data centre.

It’s very difficult to make specific applicable generalisations here but I’d suggest:

  • for smaller enterprises looking for relatively modest space requirements, pricing per rack /cabinet is typically more cost-effective than renting floor space.

Renting by m2 doesn’t mean the end of your rental costs. You may also need to rent or source cabinets and racks.


Racks (and cabinets, cages)

These are used for the storage of typically several or even multiple pieces of IT equipment.

A cage is usually a steel structure within which there may be racks and cabinets. They’re strong structures designed to provide impact protection and prevent unauthorised intrusion. They can be dedicated to a single customer of the data centre.

A rack is usually a tiered storage unit which holds various forms of IT equipment.

A cabinet is a sealed and environmentally controlled unit. It is often used for items of equipment that are relatively power-hungry and which, as a result, generate considerable heat.

Exactly how many units you’re assessed as requiring and of what type, may vary from one proposal to another. This will be one of the key cost components of your eventual full quotation.


Unfortunately, this is a complex area and can take some effort to get to grips with.

There are numerous charging options and each may need to be researched individually before its full implications are understood. I’ll highlight just a few examples here:

  • metered use – can be advantageous and you’ll pay per kW/h but it is typically only used by larger site consumers. Note that the data centre vendors may add additional charges in this scenario for cooling costs etc;
  • agreed data centre tariffs – perhaps the most common method and here typically cooling costs will be included. Usually billed by kilowatt and the tariff will normally be set at your estimated consumption levels plus a percentage to cope with peak demand. It might be expressed as kilowatts per rack, per square metre or any one of several other possible categorisations.

 As I said initially, this can be very complicated to interpret. Keep in mind that the tariff alone is only part of the story. Make sure that the vendor has a good PUE (Power Usage Effectiveness) rating or you’ll be paying for their lack of energy efficiency.

Look closely too at availability/downtime. They may at times have to take the power down for maintenance, so check their redundancy and historic availability levels. A slightly higher price may be worth paying if the availability stats are better.

If you’d like to know of the basis of power supply immediately and how it might affect your co-location pricing model, here is an excellent introduction/overview – though it does go into some technical detail. I will expand upon this in more detail in a follow-up article.


Many clients believe that their proposal is likely to consist of space and power costs. In fact, there may be a large number of additional costs outlined. Some of these might be consumption-related and that needs to be understood before you start running up bills in a ‘live’ situation.

For example, if your power consumption costs don’t allow for cooling, you might see them included here. To take another illustration, if you’ve outsourced the basic systems maintenance to the services vendor, you might get billed every time you need their technical support over and above the number of pre-included support hours.

There are no pre-set formats here. Many things might be included or not. However, they need to be looked at and understood in the context of a live operational environment. You might not think you’ll need a lot of expensive local technical support but if you do, the costs may spiral on a ‘meter running’ basis.

Bandwidth and telecoms

You, your customers and vendors will need to connect with your systems, which will be sitting in the data centre.   

When you’re looking at a data centre proposal, it will be likely to come with a recommended telecoms vendor (or vendors) who have existing strong high-capacity routes into the building. You may have some degree of choice or you may not in cases where your connection costs are included in the data centre’s proposition.

How this pricing will be reflected is impossible to say but there are some generalities to keep in mind:

  • you may be charged a fee based on your required capacity plus a specified percentage for redundancy (to cope with peaks). Even if not, it might be prudent to request it as contingency;
  • check the telecoms vendor’s availability stats. The telecoms and data centre vendors (where they are different) will have different stats. Having great systems availability in the servers in co-location racks won’t count for much if you can’t access them due to telecoms being down;
  • some contractual commitment will be inevitable but be cautious about telecoms ‘lock-ins’. The market changes quickly and a good state-of-the-art deal today might not look so cutting edge or cost-effective in 12 months.

Standby provisions and ‘mirroring’

This may or may not be a separate cost component within a proposal.

It essentially describes what can be done and at what cost, in order to put into place a fallback position should your installation suffer any form of catastrophic failure.

This is often discussed in terms of the destruction of a physical location due to flooding, fire, other natural disasters or terrorism etc. However, it might also include a major hardware or software failure/corruption that renders your systems unusable.

Your requirements for a fallback position in such cases will define the nature of what the vendor offers and at what cost, in this area.

For example, you may specify what’s called “hot standby”, meaning your systems must instantly switch to a full backup or “mirrored system” in order to achieve zero downtime.

You may specify that the system exists on your existing or other equipment. Some people require that the mirrored system exists in another geographically distant location and data centre to eliminate site risks (this is sometimes a Compliance issue). vendors may offer such as part of their standard provision.

Equipment and resources

Once again, the nature of your requirements will drive your costs here

Some customers require that their own existing topography is simply re-located to a data centre, with little else changing including the fact that their own personnel perform all hardware maintenance. Other companies may be indifferent to the IT configurations used and focus exclusively on service level agreements (SLAs) to dictate their functional requirements, leaving the data centre services vendor to perform all hardware maintenance using their own personnel.

While the “rental of a location only” is perhaps the most commonplace, there are many possible models in between – right up to full outsourcing.

As you might expect, the more equipment and services you take from the vendor, the higher your charges are likely to be.

This can be an area to look particularly closely at. One proposal may look very cost-attractive in terms of consumable pricing per kWh but significant additional costs may be added in under this heading.

Executive levers

Too often, price is discussed in terms of whether or not another rack is required etc. However, some of your key business decisions will potentially have a far more significant impact.

Some of these have been touched on above already but I’ll re-state them here:

  • solution definitions. I normally advise companies to specify their requirements in functional terms rather than detailed infrastructure designs. You can state your required solution will be a cage of ‘x’ m2, ‘n’ racks, ‘y’ bandwidth and so on. However, that might inhibit the ability of a potential vendor to identify more cost-effective solutions;
  • the extent to which you re-define roles and responsibilities. The classic approach is to simply replicate your existing operational dynamics with the physical equipment being in another location, i.e. the data centre. However, if you ask the data centre vendors to take on responsibilities that were previously dealt with in-house, such as routine hardware maintenance, then the cost of your proposal will understandably rise. That would peak in full outsourcing scenarios;
  • how demanding your standby and recovery arrangements are. If you require no more than 1 hour down after a major incident your costs will be ‘x’. If you require immediate transparent fallback and zero downtime, your costs will likely be ‘x’ plus a significant %;
  • your redundancy scaling. This is essentially driven by your assessment of the need to cope with relatively sudden increases in business volume/stress demands on your systems. For example, asking that the solution must cope with sudden 200% business volume/load increases within a 24-hour period would have an impact on your requirements for power and telecoms plus possibly other price components;
  • your requirements for separation. If you wish your equipment to be housed in a totally dedicated cage, within which your cabinets and servers sit, your space costs will rise. Sharing will typically be most cost-effective. This may need to be balanced against your data security considerations, which in turn may be influenced by legislative requirements.


Of course, if your colleagues preparing the RFP do specify technical considerations that influence things such as your power consumption forecasts, then that will also directly affect your costs.

That will be explored in my second article in this series.

I will state though that interpreting a proposal and selecting a cost-effective and operationally sound solution is never easy – unless you have previous experience of doing so. I always strongly recommend that both RFPs and the associated interpretation of the priced responses are conducted in conjunction with experienced and independent data centre solutions analysts.