Rack Power Budgeting: kW per Cabinet, PDU Types, and A/B Feeds

The power budget is the last number most teams write down and the first one that blocks a deployment. You can squeeze another server into an open U, patch another cable into a free port, and reallocate an IP block in an afternoon, but you cannot conjure kilowatts out of a circuit that is already at its limit. The moment a new device’s power draw pushes a breaker past its continuous rating, the deployment stops, facilities gets involved, and a conversation that should have happened weeks earlier happens in front of the open cabinet door instead. What makes this failure mode so common is not a lack of data about power. It is a lack of a working budget: a number per cabinet, a way to know what each PDU actually delivers, and a clear picture of what happens when one of the two feeds feeding the rack disappears.

This article lays out the three pieces of that budget. First, what the kW per cabinet figure really means and where it comes from, including the gap between nameplate ratings and measured draw that quietly inflates most plans. Second, the PDU types you can put in a rack, from basic distribution units to outlet level switching, and what each tier is actually for. Third, the A/B feed architecture that redundant power depends on, including the sizing rule that most people get wrong: each feed must carry the full rack load on its own, which means the practical budget of a dual fed rack is a single feed, not the sum of both. Along the way we cover the derating math, single phase versus three phase feeds, and the metering data that turns a static spreadsheet number into a live constraint.

At a Glance: PDU Types Compared

What kW per Cabinet Actually Means

The kilowatt per cabinet figure is the unit of data center real estate. Colocation contracts quote a committed kW per cabinet, overage bills are computed against it, and the physical design of the facility, the cooling zones, the busway, the generator capacity, is built around an assumed density per rack. When your colo provider says your cabinets are provisioned at 7 kW, that number is a promise about what the facility can deliver to that position, not a suggestion about what you should draw. Exceeding it triggers overage charges, but more importantly it means your equipment is consuming capacity that the facility never reserved for it, which is how one hot rack in a shared cooling zone starts warming its neighbors.

The density numbers themselves have drifted steadily upward. A cabinet from the early 2000s with 1U pizza box servers drew 2 to 4 kW. The typical enterprise rack today runs 5 to 10 kW, which is what most colocation contracts have settled on as the standard allocation. Dense blade chassis and hyperconverged infrastructure push racks into the 15 to 30 kW range, and AI or GPU cabinets routinely exceed 50 kW, which is why those deployments get special electrical and cooling treatment rather than being dropped into standard white space. The range matters because your budget depends on knowing which category your racks fall into, and the honest way to find out is not the label on the contract but the measured draw of what is actually installed.

That leads to the most important distinction in power budgeting: the difference between nameplate and measured draw. A server with a 1,200 watt power supply nameplate typically draws 350 to 550 watts under normal load, because the nameplate reflects worst case ratings, the full capacity of the supply, not what the hardware consumes in production. If your budget uses nameplate values, you will reserve more than twice the power each server actually needs, declare racks full while they still have real headroom, and have no idea which numbers are trustworthy. Planning with measured draw from metered PDUs, with nameplate as an upper bound for sizing circuits, gives you a budget that reflects reality. Recording both figures per device in your rack management records turns the budget into something you can audit rather than a number you inherited.

The kW per cabinet figure is also a planning abstraction in a second sense: it describes the rack, but the real constraint lives in the circuits and PDUs that feed it. A 7 kW cabinet is only as good as the breaker behind it, and a rack that shows 30 percent utilization on paper can still be at 90 percent of its circuit capacity if the equipment that is installed draws more than the plan assumed. The cabinet number is where you start, the circuit math is where you finish, and the PDU is the bridge between them.

The A/B Feed Architecture

A/B redundant power means two completely independent paths into the rack. Feed A and feed B each start at separate upstream infrastructure: separate UPS systems, separate generators, separate distribution boards, separate PDUs, and ideally separate physical routes from the electrical room to the cabinet. The point of the separation is that no single failure, a UPS that fails, a breaker that trips, a maintenance window on one distribution board, can take both feeds down at once. The rack keeps running on the surviving feed while the failed one is repaired, which is precisely what the redundancy is for.

Dual corded servers make that architecture work. A server with redundant power supplies in a 1+1 configuration has two cords, and the correct installation is one cord into the A feed PDU and the other into the B feed PDU. The color coding convention exists to make this auditable: feed A is red, feed B is blue, so a glance at the back of the rack tells you whether the redundancy is real or whether someone plugged both cords into the same feed, which happens more often than anyone admits. When both cords land on the same PDU, the server has two power supplies and still only one power path, redundancy on paper and a single point of failure in the cabinet.

The sizing rule for A/B feeds is where most budgets go wrong. Each feed must be capable of carrying the entire rack load on its own, a requirement codified in the TIA-942 data center standard, because during a failure or a maintenance event the surviving feed carries 100 percent of the load, not 50 percent. That means the usable power budget of a dual fed rack is the usable capacity of a single feed, never the combined capacity of both. If each of your A and B feeds can deliver 6 kW, the rack’s honest budget is 6 kW, and provisioning 10 kW of equipment into it violates the design the first time one feed goes down.

Single corded devices are the leak in this model. Any device with only one power supply plugs into one feed or the other, so it rides on a single path no matter how carefully the feeds are separated. The standard solutions are to put critical single corded devices on an automatic transfer switch that fails over between feeds, or to accept the single point of failure consciously for equipment that can tolerate a short outage, such as a network device that will be restored when the rest of the rack powers up. Documenting which devices are single corded and where they are connected is part of any credible data center management practice, because the A/B design only protects the equipment that actually participates in it.

PDU Types and What Each One Buys You

A basic PDU does one thing: it distributes power from a single input to a bank of outlets, protected by a circuit breaker and nothing else. There is no metering, no network connection, no remote anything. Basic units are cheap, rugged, and perfectly reasonable when the load in a rack is small and well understood, or when monitoring exists further up the chain in the facility’s own power infrastructure. The tradeoff is that you are blind at the rack level, and the load you cannot see is the load that creeps up over time.

A metered PDU adds a local display showing voltage, current, and in better units power factor and watts for the whole unit or per phase. You walk up, read the display, and know what the rack is drawing right now. That is genuinely useful in a server room you visit regularly, and it costs only a little more than basic, but the data goes nowhere, so there is no history and no alerting, and the load between visits is invisible.

A monitored PDU brings the same measurements onto the network, usually via SNMP or an HTTP interface, and typically reports per phase or per outlet rather than only the whole unit. This is the tier where power budgeting becomes an operational activity: you can pull current draw for every rack from a single dashboard, see how utilization trends over weeks, and feed the numbers into capacity planning instead of guessing. The delta over metered units is modest in the context of what a rack of servers costs, and it is the tier most teams with more than a few racks settle on. Switched PDUs add remote outlet control on top of monitoring, letting you power cycle a single outlet from your desk, which eliminates truck rolls for hung devices in remote sites and makes maintenance coordination far easier. Outlet level switching is also what makes a small out of band management network practical.

Intelligent or smart PDUs are the top tier, combining outlet level metering with environmental sensors such as temperature and humidity, plus integration into DCIM and automation platforms. Per outlet metering tells you not just what the rack draws but which device draws it, which is the difference between knowing you have a problem and finding it. For high density racks and managed service providers that bill per kilowatt, the visibility pays for itself quickly. The buying rule is simple: buy the cheapest PDU that gives you the data your operation actually needs, and do not pay for outlet switching in a rack you will never reboot remotely. The typical price ladder, from about $100 for basic up to $4,000 and beyond for intelligent units, is small next to the cost of one overage billing cycle or one unnecessary site visit.

Sizing the Budget: Circuits, Voltage, and Derating

Rack power budgets start at the circuit, not the cabinet. In North America the standard building block is a 30 amp 208 volt circuit, and the arithmetic is straightforward until the derating rule enters. The National Electrical Code requires that continuous loads, anything expected to run three hours or more, which is every server in the rack, must not exceed 80 percent of a breaker’s rating. So the theoretical capacity of a 30 amp 208 volt circuit is 6,240 watts, but the usable continuous capacity is 4,992 watts, and a plan built on the theoretical number is a plan that trips breakers. Every budget line in this article assumes the derated figure, because that is the number the code, and the electrician, will enforce.

The voltage and phase decision determines how far that circuit math can stretch. Single phase 208 volt feeds top out around 8 to 10 kW per rack, which is plenty for typical enterprise cabinets but leaves no runway for dense equipment. Three phase feeds multiply capacity substantially: a 400 volt three phase 32 amp feed is about 22 kW theoretical and roughly 17.6 kW usable after derating, and North American three phase 208 volt installations sit in between. Anything above about 10 kW per cabinet is normally provisioned as three phase, and the facility’s busway and panel capacity, not the PDU, becomes the binding constraint. On the voltage question, running equipment at 208 volts instead of 120 volts is more efficient, typically a few percent better, because losses scale with current, so voltage selection is a real budgeting lever rather than an electrical detail.

Outlet types matter at the device end of the same chain. The IEC C13 outlet, rated 10 amps, is the standard for servers and switches. The C19 outlet, rated 16 amps, exists for high draw equipment such as blade chassis, large storage arrays, and GPU nodes, and trying to run that equipment through C13 connections on undersized PDU outlets is a fire hazard dressed as a cost saving. When you size a PDU, check both the total current rating and the current rating of the individual outlets against the worst case draw of the devices you will attach.

The final sizing discipline is to never add the feeds together. With A/B feeds, each feed is provisioned to carry 100 percent of the rack load, so a dual fed rack’s budget is one feed’s usable capacity, and summing A plus B overstates the rack by a factor of two. The same logic applies across phases: a three phase PDU loaded unevenly across its phases will trip a phase breaker while the dashboard still shows healthy average utilization, which is why per phase and per outlet metering is not a luxury but the mechanism that makes the budget real.

Metering: The Data That Makes Budgets Real

A power budget is a snapshot, and snapshots go stale. The equipment in a rack does not draw a constant load: CPUs ramp up as workloads grow, storage arrays consume more as drives populate, firmware and application changes shift power behavior over months. A rack that showed 20 percent headroom at deployment can be at 95 percent utilization a year later, not because anything was added, but because the installed hardware is now working harder. Only metered data, collected over time and compared against the budget, reveals this drift before it becomes a tripped breaker or a blocked deployment. This is the operational argument for monitored PDUs: the numbers are collected continuously, so the budget reflects the rack as it is today, not as it was when someone last remembered to update the spreadsheet.

Phase balance is the metering insight that catches most teams by surprise. A three phase PDU draws on all three phases, and if the devices you plug in happen to concentrate on one phase, that phase can reach its limit while the other two sit half loaded. The unit’s total current can look perfectly healthy while a single phase breaker is seconds from tripping, which is why per phase reporting matters and why spreading high draw devices across the PDU’s phases is part of the installation procedure. Metered and monitored PDUs make the imbalance visible; basic PDUs hide it until the breaker pops.

Metering data also connects directly to money in colocation. Overage billing is computed against committed kW per cabinet, and without measured draw you have no way to dispute a bill or to prove you are within your allocation. Teams that meter their racks know their true consumption, can show the provider the numbers, and can negotiate the right committed kW instead of paying for headroom they do not use or being billed for load they never drew. The same data drives the decision to densify, because a rack at 30 percent of a 7 kW allocation is a candidate for more equipment, while a rack at 90 percent is a candidate for a larger allocation or a redistribution.

The data is only useful where the devices live. Recording the rated draw on each device record, alongside the serial number, asset tag, and position, gives you a budget you can trace back to individual hardware, and it survives the personnel change that would otherwise take the knowledge out of the building. A device inventory that carries power information per unit turns the rack budget from a number on a wall into a model of the actual fleet, one that can answer the question every capacity review asks: what is this rack really drawing, and which device is responsible for the last kilowatt?

Power Budgets You Can Actually Maintain with Obelinf

Obelinf gives the power budget a home that survives contact with reality. Rack elevations show every device at its true U height, so the PDUs, the zero U units along the rear rails and the horizontal units between servers, are visible in their actual positions, and the interactive view makes it obvious when a rack is approaching the layout that the budget assumed. Each device record carries the details that power planning depends on, model, serial number, asset tag, and notes where your team records the nameplate rating and the measured draw, so the budget is built from per device data instead of an aggregate guess. Reservations hold rack positions for planned deployments before the hardware arrives, which is also where power headroom gets reserved in the same view, preventing the double booking of space and the silent double booking of circuits.

The discipline of the A/B design is preserved in the same records. Which PDU hangs on which feed, which devices are dual corded and which are single corded, and which circuit feeds each PDU are all documented at the rack level where the next engineer will actually look, and the changelog keeps an audit trail of every change, so a reconfiguration that breaks the redundancy design leaves a visible record instead of a mystery. The network topology view ties the power story to the rest of the infrastructure, showing which racks share a cooling zone and how the equipment depends on the power that feeds it.

A rack power budget is only as good as its documentation layer, and that layer has to update with every change, not whenever someone remembers. Obelinf links racks, devices, and their power context in one place, so the kW per cabinet figure, the PDU choice, and the A/B feed mapping are always the current truth rather than a recollection. Sign up at obelinf.com and start building power budgets that survive the next deployment.