Data center TCO and the cost model field guide

Read this first: education, not financial advice

Everything in this guide is general education about how data center cost is structured and modeled. It is not financial, investment, tax, or accounting advice, and no figure here is a quote for any project.

Every dollar amount and range in this guide is illustrative. Construction cost, energy rates, colocation pricing, and equipment cost move fast and vary enormously by market, by year, by power availability, and by the specifics of the deal. A number that is roughly right in one metro can be off by a factor of two in another, and the AI buildout has been pushing the figures around quarter to quarter. Treat any range as a starting point for a question, never as an answer.

Before any capital decision rests on a number, build it up from the actual project: real local power rates, real vendor quotes, the real design, and the real schedule. Then put it in front of a qualified financial professional who can account for your tax position, cost of capital, depreciation treatment, and accounting standards. The job of this guide is to show you what drives the number and how to model it, so the conversation with that professional is a sharp one.

Data center TCO, and why the building is the cheap part

Data center TCO is the full lifetime cost of capacity. It has two halves: the capital expenditure to build it, which is the land, the shell, the power and cooling infrastructure, and the IT gear, and the operating expenditure to run it over its life, which is energy, water, staff, maintenance, the lease, and connectivity. Add the amortized capital to the running cost and you have the total cost of owning a megawatt of compute capacity for as long as you keep it.

The thing that surprises people new to this is that the building barely matters. Land and the bare shell are a small slice. What dominates is the power and cooling, the electrical and mechanical systems that deliver and reject the energy, plus the energy bill those systems run up year after year. That is why the industry measures cost per megawatt of IT capacity, not per square foot. Power, not floor area, defines what the facility can do and what it costs.

Understanding the drivers is the whole point, because it tells you where the money actually is. Efficiency, density, and utilization move the total far more than the real estate does. The power density and capacity planning guide covers how many kilowatts each rack and room can draw. The stranded capacity guide covers the capacity you build but cannot use. This guide is the money layer underneath both: what all of that costs over the life of the asset.

Why is data center cost measured per MW?

Cost is measured per megawatt, or per kilowatt, of IT capacity because power is what the facility actually sells and what most of the cost scales with. A square foot of raised floor with no power behind it is worthless. A megawatt of clean, cooled, redundant power is the product, whether you keep it for yourself or lease it to a tenant.

Per square foot is the wrong yardstick and it has been for years. Two halls of the same floor area can differ by an order of magnitude in what they cost and what they earn, depending on the power density they support. A sparsely powered enterprise room and a dense AI hall might share a footprint and share almost nothing else. The watts decide the cost.

So the headline metric is dollars per megawatt to build and dollars per kilowatt to operate, and almost every comparison in this guide runs in those units. When you see a building quoted in cost per square foot, treat it as a real estate number, not a data center number. The capacity number is per watt. Confirm which one a figure actually represents before you compare it to anything.

The capex: where the build money goes

Capex is the capital to build the facility before it earns anything. It breaks into a handful of buckets, and the order of their size is the part worth knowing cold: the electrical and mechanical systems first, then the fit-out, then the building shell and land, with the IT gear sitting in its own category depending on who buys it.

Published cost breakdowns vary, but a common shape for the facility itself puts electrical systems at roughly 40 to 45 percent of development cost, mechanical and cooling at roughly 15 to 20 percent, the building shell and land together at roughly 15 to 20 percent, and the building fit-out at roughly 20 to 25 percent. Those are illustrative proportions, not a budget. The split shifts hard with redundancy level, density, cooling type, and market.

The electrical bucket is where the generators, the UPS and batteries, the switchgear, the transformers, and the power distribution live. The mechanical bucket is the chillers, the air handlers or the liquid cooling loops, and the heat rejection. Together those two are the bulk of the build, and for AI projects the mechanical, electrical, and plumbing scope has been reported at around three quarters of the guaranteed maximum price. Confirm the real allocation against the project estimate and a financial professional, because these proportions move with every design choice.

Power and cooling: the largest capex, often more than the building

The electrical and mechanical infrastructure is the single largest part of the facility capex, and on many projects it costs more than the building that houses it. This is the cost driver, and it is why a data center is best thought of as a power plant with a roof rather than a building with servers in it.

The reason is physical. Delivering reliable, conditioned power and then removing every watt of heat that power becomes takes a lot of expensive equipment: redundant utility feeds, transformers, switchgear, UPS systems and their batteries, standby generators with fuel, and a full cooling plant sized to reject the IT load on the worst day of the year. The redundancy multiplies it. A facility built to keep running through a utility failure or a maintenance window carries duplicate gear that a single-path building would not.

This is also why the cost is quoted per megawatt. The power and cooling scope scales with the watts, not the walls. Add density and you add electrical and mechanical cost almost in lockstep, while the shell barely changes. The illustrative all-in build figures circulating in 2025 and 2026, often quoted somewhere in the range of roughly 7 to 15 million dollars per megawatt for conventional facilities and higher for dense AI builds, are dominated by this scope. Those are market-and-time-dependent ranges, not a project number, so bound them to your actual design.

The IT capex: the servers and GPUs

The IT gear, the servers, GPUs, storage, and network, sits in its own capex category, and for the operator who buys the compute it is frequently the largest single cost of all, larger than the facility that holds it. Whether it belongs in your TCO at all depends on who you are.

If you build a facility and lease powered shell or wholesale capacity to tenants, the IT belongs to them and your model centers on the facility. If you are the operator running your own compute, the IT can swamp everything else. A widely cited illustrative breakdown of a one-gigawatt AI facility put total up-front capital near 38 billion dollars, with servers accounting for the majority of the annualized cost, on the order of 60 percent once each asset is spread over its life. That is one scenario, not a law, but it shows the shape: at AI scale, the silicon is the story.

The other thing the IT category drags in is the refresh cycle. The facility lasts a long time. The IT does not. Servers and accelerators turn over every few years, so the IT capex is not a one-time line, it is a recurring wave. Model it as a repeating purchase across the facility life, not a single buy at the start, and let a financial professional set the depreciation treatment.

The opex: what it costs to keep running

Opex is everything it takes to operate the facility year after year: energy, water, staff, maintenance and spares, the lease or property cost, connectivity, and insurance and overhead. It runs for the entire life of the asset, so even though any single year looks small next to the build cost, the sum over fifteen or twenty years is a major part of the total.

Energy is the giant in this list, large enough that it gets its own section next. After energy, the rest divides among maintenance of the electrical and mechanical plant, the staff who run and guard the building, water for cooling where evaporative systems are used, and the recurring cost of land and connectivity. The exact split varies, but maintenance and labor are usually the next meaningful blocks after the power bill.

The trap in opex is treating it as fixed background noise. It is not. The same megawatt operated at a better PUE, a higher utilization, and a smarter maintenance regime can cost materially less to run than one that is left alone, and that difference compounds every year for the whole life of the asset. Model opex year by year and escalate it, because small annual differences become large lifetime numbers.

What is the biggest data center operating cost?

Energy is the biggest operating cost, and it is not close. Reported figures put electricity somewhere around 40 to 80 percent of the operating budget depending on the facility, the market, and how the books are drawn. Over the life of the asset, the cumulative energy bill can rival or exceed the cost of the building itself.

The math is simple and worth carrying in your head. Annual energy cost is roughly the IT power in kilowatts, times the PUE, times 8,760 hours in a year, times the electricity rate in dollars per kilowatt-hour. Every term matters, but the rate and the PUE are the two that swing the result the hardest because they multiply through the whole load for the whole year.

The market sensitivity is brutal. Run a 100 MW facility flat out and it draws on the order of 876 million kilowatt-hours a year. In a cheap-power market near 0.047 dollars per kilowatt-hour, that is roughly 41 million dollars a year. In an expensive market near 0.15 dollars per kilowatt-hour, the same facility can run past 131 million dollars a year for the identical compute. Same building, same servers, triple the bill. The energy rate is one of the largest reasons site selection and the financial model cannot be separated, and the actual rate has to come from the local utility and a financial professional, not from a national average.

How PUE multiplies the energy bill

PUE, power usage effectiveness, is total facility power divided by IT power. It is the multiplier on your energy cost, because every watt the IT draws drags overhead watts behind it for cooling, power conversion losses, and lighting. A PUE of 1.5 means you pay for 1.5 watts at the meter for every watt of useful compute. Half a watt of overhead on every IT watt, all year.

Lowering PUE drops opex directly, with no change to the compute. The industry average has run around 1.5 in recent surveys, while leading hyperscale sites reach roughly 1.10, and modern liquid cooling can land under 1.2 against air-cooled rooms that often sit at 1.5 or higher. The gap between 1.5 and 1.2 is not cosmetic. On a large facility it is millions of dollars a year of energy that either does useful work or just heats the outside air.

Because PUE multiplies the single largest opex line, it is one of the highest-payback numbers in the whole model, and it ties straight back to the cooling design. The thermal envelope and cooling guide covers the engineering. For the cost model, the rule is plain: a lower PUE is lower opex every hour the building runs, so the cooling capex that buys a better PUE often pays back through the energy bill. Run that payback with the real local rate, because the answer depends on the rate and the run hours.

Utilization: the capex you paid for and do not use

Under-utilization wastes the capex. You paid to build a megawatt of power and cooling, and every megawatt you built but do not load is capital sitting idle while the depreciation clock runs. A half-loaded facility has the same build cost as a full one and earns or serves half as much, so its cost per useful megawatt is double.

This is where the stranded capacity guide connects directly to the money. Capacity gets trapped behind a binding constraint, power behind cooling, cooling behind distribution, or any of them behind a redundancy policy, and the room fills up on paper while floor and rack units sit open. Every stranded megawatt is capex you are paying for and not using. The first move when the numbers look bad is almost never to build more. It is to find and reclaim what is already built.

Utilization also drags PUE in the wrong direction at low load, because the fixed cooling and power overhead is spread across fewer useful watts. So under-utilization hits twice: the capex per used megawatt rises and the efficiency falls. Drive utilization up before you spend on expansion, and the cost per useful megawatt drops without a dollar of new build. The stranded capacity guide covers how to find the trapped capacity and get it back.

How much does it cost to build a data center per MW?

The honest answer is that it varies enormously, and anyone who gives you a single number without asking about your market, your density, your redundancy, and your year is guessing. The figures below are illustrative ranges only, and they are exactly the kind of number that has to be confirmed against the actual project and a financial professional before any decision rests on it.

With that warning carried in full: conventional facilities have commonly been quoted somewhere in the range of roughly 7 to 15 million dollars per megawatt of IT capacity in 2025 and 2026, with various sources clustering global averages around 10 to 11 million dollars per megawatt and ticking up year over year. Dense AI builds with advanced liquid cooling and higher power density routinely run higher, with figures of 20 million dollars per megawatt or more appearing in reporting. These ranges drift with steel, transformers, labor, and especially power availability.

What is inside the per-megawatt number matters as much as the number. Does it include the IT gear or just the facility? Does it count the land, the substation work, the redundancy, the soft costs and financing? A figure that excludes half of those looks cheaper and is not. When you compare two per-megawatt numbers, make sure they have the same scope inside them, and have a financial professional normalize them before you treat the comparison as real.

Cost per rack and per kW

Below the megawatt, cost shows up per rack and per kilowatt, and the two can move in opposite directions, which confuses people. As density rises, the cost per rack climbs because each cabinet now holds far more power and cooling, but the cost per kilowatt can actually fall, because that expensive infrastructure is spread across many more watts in the same footprint.

That is the whole economic argument for density. A traditional rack at a few kilowatts and a dense AI rack at tens of kilowatts are not the same product. The dense rack costs much more to build and feed, but if it does the work of many traditional racks, the cost per unit of compute can come out ahead. Per rack soars, per kilowatt can improve, and per unit of useful work is the number that actually matters.

On the operating side, colocation makes this concrete by pricing in dollars per rack and dollars per kilowatt per month, which exposes the density tradeoff in the invoice. A low-density rack and a high-density rack at the same site can differ by a large multiple in monthly power charges. Whether the density pays depends on what the compute earns, so run the cost per useful output, not the cost per rack.

How AI density changes the cost model

AI and high-density compute rewrite the cost model from the cooling up. Where a conventional rack might draw a few kilowatts, AI racks commonly run 30 to 80 kilowatts or more, and at that density air cooling stops being enough. Direct-to-chip or immersion liquid cooling becomes the design, and the capex and the per-rack cost both jump.

The added cost is real and specific. Liquid cooling has been reported to add on the order of 2,000 to 5,000 dollars or more per rack, on top of the much larger power delivery each dense rack needs. So the cost per rack soars. The bet is that the compute density soars faster, that one liquid-cooled AI rack does work that would have taken a roomful of conventional servers, so the cost per unit of compute falls even as the cost per rack climbs.

That is the tradeoff to model honestly. Higher capex per rack and a different cooling plant, against far more compute per square foot and potentially a better PUE from liquid cooling. Whether it wins depends on utilization, the value of the compute, the energy rate, and how fast the hardware is refreshed. These are exactly the assumptions a financial professional should pressure-test, because the AI cost figures are moving quarter to quarter and a stale number can flip the answer.

The lifetime: facility years vs IT years

TCO is a lifetime number, so the time horizon you choose drives the whole result, and the catch is that the facility and the IT live on completely different clocks. The building and much of the electrical and mechanical plant are long-life assets, commonly modeled over something like 15 to 20 years, with some components amortized over shorter windows and depreciation treatment set by accounting rules. The IT inside is short-life, turning over every few years.

Reported IT refresh cycles cluster around three to six years. Enterprise server life has been cited near five and a half years, large operators have moved between five and six year cycles, and some hyperscale planning runs on roughly three-year refreshes for the fastest-moving hardware. The exact number is a financial and performance decision, and even small changes to it move the model: extending a refresh cycle by a year spreads the IT capex over more time and lowers the annual cost, which is why operators publicize those decisions.

Model the two clocks separately. The facility is one long depreciation stream. The IT is a repeating wave of purchases riding on top of it, each with its own shorter life. Mixing them into one horizon is a common modeling error that either overstates the facility cost or understates the IT churn. Set the lives and the depreciation method with a financial professional, because they depend on the asset and the accounting standard, not on a rule of thumb.

Build, colocation, or cloud: which is cheaper?

There is no universal winner. Build, colocation, and cloud are three points on a make-or-buy spectrum, and which one has the lowest TCO depends on scale, how long you hold, how steady the load is, and your cost of capital. The decision is genuinely project-specific, and it is the clearest case in this whole guide for sitting down with a financial professional.

Building your own means you carry the capex and the operating burden, but you own the asset and, at large steady scale held for many years, the cost per megawatt can come out lowest. Colocation means you lease space and power from someone else's facility, trading capex for a monthly operating cost and getting speed and flexibility in return. Cloud means you rent compute by the hour with no facility at all, which wins on speed and elasticity and on small or spiky workloads, and tends to lose on cost once a heavy, steady load runs continuously for years.

The crossover is where the analysis lives. Illustrative comparisons have put the break-even between building and leasing colocation somewhere around 7 to 10 years for steady large deployments, with colocation cheaper in the early years and owning pulling ahead later, but that number swings hard with construction cost, lease rates, and utilization. Run all three on the same per-megawatt, same-horizon basis, and let a financial professional fold in your cost of capital and tax position before you commit.

The colocation cost model

Colocation prices power, not floor space, which is the clearest proof that the watt is the unit. Wholesale deals are quoted in dollars per kilowatt per month, and that single figure is the spine of the colo cost model. You commit to a power draw and you pay for it monthly whether you use it or not.

The market numbers move, so treat these as a dated snapshot, not a quote. Wholesale colocation in primary North American markets was reported averaging somewhere around 196 dollars per kilowatt per month for mid-size deployments in late 2025, up roughly 6 to 7 percent year over year, with wide spread by metro. On the retail side, a standard full rack at a few kilowatts has been quoted in the rough range of hundreds to a couple thousand dollars a month all-in, and dense AI racks far higher. Power availability has overtaken floor space as the binding constraint in many primary markets, which is pushing the per-kilowatt price up.

To compare colo against building, annualize the colo rate and put it on the same per-megawatt basis as the build TCO. A few megawatts at a couple hundred dollars per kilowatt per month is millions of dollars a year, every year, with no asset at the end. That recurring cost is the thing the build option trades a large up-front capex to avoid. Whether the trade pays depends on the horizon and the rate, so model both before you commit.

Land and shell: the small fraction

Land and the bare shell are a small fraction of data center TCO, commonly a fraction of the facility capex and a smaller fraction still of the lifetime total once energy is counted. This is the single most counterintuitive fact for anyone coming from conventional real estate, where the dirt and the structure are the deal.

It means cheap land does not save much. Halving the cost of a parcel that represents a modest slice of capex barely moves the per-megawatt number, and it moves the lifetime TCO even less once the energy bill is in the picture. A site chosen for cheap land but stuck with expensive power or a slow grid connection will lose to a pricier parcel with cheap, fast power every time the model is run over the full life.

So the site decision is a power and connectivity decision wearing a real estate costume. The land matters for what comes with it, available power, speed to that power, water for cooling, fiber, and the local energy rate, far more than for its own price tag. Optimize the site for the power, not the dirt, and let the financial model weigh the energy rate against the land cost over the full horizon.

Schedule and time-to-power: the cost of delay

Schedule is a cost, and on data centers right now it can be one of the largest. A facility earns nothing until it is energized, so every month between capital going out and power coming on is carrying cost on the build and revenue or capacity you do not have yet. Time-to-power has become a primary driver of site selection precisely because it is a primary driver of cost.

The grid is the bottleneck. Interconnection timelines in major markets have been reported stretching anywhere from four to ten years, and long-lead equipment like large transformers has pushed some schedules out by many months. While you wait, the capital is committed and idle. Illustrative figures circulating in 2026 put the cost of delay on a 60 MW project at roughly 14 million dollars per month, most of it lost lease revenue at prevailing per-kilowatt rates. That is a market-and-deal-specific number, but the order of magnitude is the point: delay is expensive enough to outweigh many other savings.

This is why developers now screen sites for speed to power before they weigh the cheaper real estate factors. The site selection work belongs in the cost model as a schedule risk, not an afterthought. Put time-to-power and its carrying cost into the model explicitly, and have a financial professional value the delay risk, because a slow site can cost more in lost months than a fast one costs in higher land or power price.

Where optimizing actually pays

Efficiency, density, and utilization move the TCO more than the real estate does, and by a wide margin. This is the practical conclusion of everything above, and it tells you where to spend attention. Chasing a cheaper parcel optimizes a small slice. Improving PUE, raising utilization, and getting density right optimize the two largest pieces, the energy bill and the capex per useful megawatt.

Rank the levers by what they touch. PUE multiplies the single largest opex line, so a tenth of a point of PUE is real money every hour for the life of the building. Utilization sets how many useful megawatts you get out of the capex you already spent, so reclaiming stranded capacity can be cheaper than any new build. Density decides how much compute fits behind each expensive megawatt of power and cooling. All three beat shaving the land cost.

The mistake is to optimize what is visible and easy, the rent, the parcel, the square footage, instead of what is large and harder, the power, the efficiency, and the utilization. Spend the engineering effort where the money is. The savings from a better PUE and a fuller building compound every year, while a one-time real estate saving is spent once and gone.

Building the TCO model

A workable TCO model is simpler than it looks: amortized capex plus operating cost, summed over the life, expressed per megawatt. The discipline is in the assumptions and the scope, not the arithmetic. Get the inputs honest and the model is useful. Get them flattering and it lies to you confidently.

Lay it out in two streams. The capex stream is the facility build spread over its life by the depreciation method, plus the recurring IT refresh wave on its own shorter cycle. The opex stream is energy first, computed as IT power times PUE times hours times rate, then maintenance, staff, water, lease, and connectivity, each escalated year by year. Discount both streams to a present value if you are comparing options with different timing, which is where the cost of capital enters and where a financial professional is not optional.

Two rules keep the model honest. First, state every assumption on the face of it: the rate, the PUE, the utilization, the lives, the escalation, the discount rate, and exactly what is and is not inside the capex. Second, express the result per megawatt of IT capacity so it compares to anything else on the same basis. A model whose assumptions are buried is a model nobody can check, and an unchecked model is how a project commits to the wrong number.

The sensitivities that decide the answer

A single-point TCO number is almost useless, because the inputs that drive it are uncertain and they swing the result hard. The real output of a model is a sensitivity analysis: how the total moves as the big assumptions move. Three inputs dominate, and they are the same three the whole guide keeps returning to.

The energy rate is the first, because it multiplies the largest opex line for the life of the asset, and the same building can cost wildly different amounts in a cheap-power market versus an expensive one. PUE is the second, for the same multiplying reason. Utilization is the third, because it sets the denominator, the useful megawatts you divide the cost across. Move any one of these by a realistic amount and watch the per-megawatt total move with it. If small input changes flip the build-versus-colo-versus-cloud decision, you have learned that the decision is close and the assumptions need to be nailed down before anyone commits.

Model the band, not the point. Run the energy rate, the PUE, and the utilization across a plausible range and report the spread, then carry the schedule and time-to-power risk alongside as a separate scenario. Hand the financial professional the sensitivity table, not a single number, because the spread is where the actual risk and the actual decision live.

What to document

A TCO model that nobody can audit is a number nobody should trust. The record is what lets a reviewer, a lender, or a financial professional reproduce the result and check whether reality matched it. Capture the assumptions and the actuals side by side, and revisit them as the project moves from plan to operation.

Write down the capacity basis in megawatts, the capex by bucket and what is inside each, the IT refresh assumption and cycle, the energy rate and its source, the PUE assumed and later measured, the utilization assumed and later measured, the asset lives and depreciation method, the escalation and discount rates, and the schedule with the time-to-power assumption. Then track the actuals against every one of them, because the gap between the model and the meter is the most useful number you will ever record. A field tool such as FieldOS can hold the assumptions, the readings, and the variance in one place so the model and the building stay tied together. The figures vary by market, so note the market and the date next to every input.

Common mistakes

• Optimizing the land cost instead of the power, when land is a small fraction and power dominates.
• Ignoring how PUE multiplies the energy bill, so a cheap building locks in an expensive operating cost.
• Ignoring utilization and stranded capacity, paying for megawatts that sit idle while depreciation runs.
• Thinking per square foot instead of per megawatt of IT capacity.
• Ignoring the cost of delay and time-to-power, treating schedule as free when idle capital is not.
• Using stale energy-price assumptions, when the rate is the single biggest swing in the lifetime total.
• Comparing per-MW figures with different scope inside them, so one looks cheaper only because it excludes more.

Field checklist

Standards, references, and where the figures come from

There is no single code that sets data center TCO the way the NEC sets conductor sizing. The practice is built from cost-modeling frameworks, industry benchmarks, and the operator's own actuals. The Uptime Institute publishes widely used guidance on data center efficiency, availability, and the Tier classification that drives how much redundant, and therefore expensive, infrastructure a facility carries. Industry analysts and brokers publish the construction-cost-per-megawatt and colocation-pricing benchmarks that the ranges in this guide draw on, and those move every reporting cycle.

On the technical inputs, PUE is defined by The Green Grid and standardized under ISO/IEC 30134-2, so the efficiency multiplier in your energy calculation has a real definition to hold the model to. The energy rate comes from the serving utility and the contract, not from a benchmark. ASHRAE TC 9.9 thermal guidelines shape the cooling design that sets the PUE you can achieve. Each of these informs an input to the model rather than dictating the cost.

The figures in this guide, the cost per megawatt, the capex splits, the colocation rates, the PUE benchmarks, the refresh cycles, and the cost of delay, are illustrative ranges drawn from 2025 and 2026 industry reporting. They vary widely by market, by time, by power availability, and by the specifics of the project. Treat them as orientation, build the real model from real project inputs, and confirm the result with a qualified financial professional who can account for your cost of capital, depreciation, tax position, and accounting standards. Nothing here is financial advice.

Units and terms

Data center cost runs in a few units that show up across estimates, leases, and energy bills, and keeping them straight is half of keeping the model honest.

Capacity is in megawatts (MW) or kilowatts (kW) of IT load. Build cost is in dollars per megawatt. Colocation is in dollars per kilowatt per month. Energy is in kilowatt-hours (kWh) at a rate in dollars per kilowatt-hour, with 8,760 hours in a year. PUE is a dimensionless ratio of total facility power to IT power. Always check whether a per-megawatt figure includes the IT gear or just the facility before you compare it to anything.

TCO

Total cost of ownership: amortized capex plus operating cost over the asset life, usually expressed per MW

Capex

Capital expenditure: the up-front cost to build, including land, shell, power and cooling, and IT gear

Opex

Operating expenditure: the recurring cost to run, dominated by energy, then maintenance, staff, water, and lease

Cost per MW

Build cost per megawatt of IT capacity, the headline metric; varies widely by market and time

PUE

Power usage effectiveness, total facility power divided by IT power; the multiplier on the energy bill

Utilization

Share of installed capacity actually loaded; low utilization wastes the capex you already spent

Colocation

Leasing space and power in someone else's facility, priced in dollars per kilowatt per month

Time-to-power

Elapsed time until a site can be energized; carrying cost accrues until it earns

Related tools

Calculators and readiness checks for this work

Compare your options

FAQ

People also ask

• What is data center power density?
• What is stranded capacity in a data center?
• What is PUE?
• What does DCIM stand for and what does it manage?
• What is an EPMS in a data center?