UniFi Switching: PoE Budget, Uplinks, and Link Aggregation
How to size a UniFi switch by PoE budget instead of port count, why uplink bandwidth is the bottleneck people forget, and when link aggregation actually helps versus when it does nothing.
People pick a UniFi switch by counting ports. That’s the least important number. A switch that has enough ports but not enough PoE budget, or a switch starved by a thin uplink, will disappoint you in ways the port count never warned about. This guide is the reasoning behind sizing a UniFi switch correctly — power, uplinks, and aggregation — so you buy once instead of replacing in a year.
Port count is the easy part; PoE budget is the real constraint
Every PoE switch advertises two separate numbers and people only read one:
- Number of PoE ports — how many ports can deliver power.
- Total PoE budget (watts) — how much power the switch can deliver across all ports combined.
These are not the same limit, and the budget is the one that bites. A switch can have eight PoE ports but a power budget that cannot run eight power-hungry devices simultaneously. PoE devices draw very different amounts: a small access point is modest, while a multi-radio AP, a PoE camera with heater, or a PoE++ device draws far more. The relevant question is never “how many PoE ports” — it’s “what is the sum of what every powered device on this switch will actually draw, and does that fit under the budget with headroom?”
Two practical rules:
- Add up your devices’ power classes, not your port count. Each UniFi device documents its PoE mode/class. Sum the real devices you’ll attach.
- Leave headroom. Running a switch near its rated PoE ceiling leaves nothing for a future camera or AP, and power draw can spike (an AP under heavy load, a camera turning on its IR illuminator). Size so you’re comfortably under the budget, not flush against it.
The failure mode of an over-subscribed PoE budget is ugly and looks like something else: devices that boot, partially come up, then reset — exactly the symptom people misdiagnose as an adoption or firmware bug when it’s really the switch declining to fully power everything.
PoE standards: make sure the switch speaks what the device needs
PoE is not one thing. There are different power levels (commonly referred to as PoE, PoE+, and PoE++ tiers), plus Ubiquiti’s older passive 24V PoE on some legacy gear. The principle to internalize:
- A device needs a specific PoE type. A switch port must be able to deliver that type.
- A higher-tier switch port can generally power a lower-tier device, but a lower-tier port cannot power a device that needs more than it can supply.
- Passive 24V is not the same as standard PoE. Plugging a device expecting one into a port supplying the other is a real way to either not power a device or damage older hardware. Match deliberately; don’t assume “PoE is PoE.”
Confirm each device’s required PoE mode against Ubiquiti’s current specs for that exact model, and confirm the switch port supports it. This is a five-minute check that prevents buying the wrong switch.
The uplink is the bottleneck nobody plans for
Here’s the mistake that survives even careful PoE planning: a switch full of fast access ports connected back to the rest of the network through a single, slower uplink.
Think about where traffic goes. Devices on a switch mostly talk to things not on that switch — the gateway, the internet, a NAS on another switch. All of that crosses the uplink. If you have a switch serving several busy access points and cameras, but it reaches the core through one ordinary uplink, that uplink is the ceiling for everything leaving the switch — no matter how fast the individual ports are.
The reasoning to apply:
- Estimate aggregate uplink demand, not per-port speed. Several APs and cameras can collectively push more than a single modest uplink carries at peak.
- Prefer a switch with a faster uplink path (higher-speed uplink ports, or SFP+/aggregation-capable ports) when that switch aggregates a lot of downstream traffic — distribution switches feeding APs and cameras especially.
- Topology matters. A chain of switches each daisy-chained off the previous one funnels everything through the first thin link. A star topology — switches home-running back to a capable core — avoids stacking everyone’s traffic onto one early bottleneck.
You don’t need every link to be the fastest tier. You need the uplink of any switch that aggregates significant traffic to not be the thing throttling all of it.
Link aggregation (LACP): what it does, and what it does not
Link aggregation bonds multiple physical links between two devices into one logical link. UniFi switches support it (commonly via LACP). It is widely misunderstood, so be precise about what you get:
What aggregation does: it increases total throughput across many flows and adds link redundancy. Bond two links between a switch and a capable upstream device, and the combined pipe can carry more aggregate traffic, and survive one link failing.
What aggregation does not do: it does not make a single connection faster. Aggregation hashes each traffic flow onto one of the member links. One file transfer between two hosts rides a single physical link at that link’s speed — bonding two links does not double a single stream. You get more capacity for many simultaneous conversations, not a faster single one.
So aggregation is worth it when:
- A switch carries many simultaneous flows to an upstream device (a busy distribution switch to the core; a switch to a NAS many clients hit at once) and you want more aggregate headroom and a redundant path.
- Both ends support it and are configured as a matched aggregation group.
It is not the fix for “one device’s single transfer is slow.” That’s a per-link-speed problem; aggregation won’t change it. Reaching for LACP to speed up a single stream is the classic wasted effort here.
A sizing method that doesn’t overspend or under-build
- List powered devices and sum their real PoE draw. Choose a switch whose PoE budget comfortably exceeds that sum with headroom for one or two future devices — not one that merely has enough PoE ports.
- Verify PoE type per device. Each device’s required PoE mode must be one the switch port can deliver. Watch for passive 24V legacy gear.
- Identify which switches aggregate traffic (those feeding multiple APs/cameras or sitting between many clients and the core) and give those a genuinely capable uplink, not a thin one.
- Prefer a star topology back to a strong core over long daisy chains that funnel everything through the first link.
- Use link aggregation only where it applies: many concurrent flows plus a need for a redundant path, with both ends configured to match. Don’t deploy it expecting single-stream speedups.
Get power and uplinks right and a UniFi switch is boring in the best way — it just moves traffic. Get them wrong and you’ll chase phantom “device” and “Wi-Fi” problems that were really a starved PoE budget or a choked uplink the whole time. For the wireless and segmentation layers this switching foundation carries, see the rest of our UniFi guides, including VLAN segmentation and access point placement.
Related
UniFi Backups, Migration, and Disaster Recovery
What a UniFi controller backup actually contains, why devices keep working when the controller dies, and a recovery and migration plan that doesn't rely on luck or re-typing your whole config.
A Sane UniFi Firmware and Update Strategy
When to update UniFi controller and device firmware and when to wait, why updating everything at once is the risky path, and an order of operations that avoids self-inflicted outages.
Choosing a UniFi Gateway: Routing, Throughput, IDS/IPS
How to pick a UniFi gateway by what actually limits it — routing and security-feature throughput, not marketing — and whether you even need UniFi to do your routing at all.