Managing cloud spend has been the top-ranked cloud challenge for nine years running, according to Flexera's 2025 State of the Cloud Report1. 84% of respondents put it above every other cloud concern, including security. For most companies, that's an efficiency problem.
For streaming platforms, it's structural.
If you run encoding, transcoding, origin, packaging, or CDN infrastructure for OTT clients (or if you are the OTT and you're running this inhouse), you already know why: you provision for the audience you might get, not the audience you usually have. A launch, a live event, or a single viral moment can multiply your concurrent viewers overnight, so most platforms size their entire cloud footprint, baseline included, for that possibility. The result is a bill that reflects your best night of the year, every night of the year.
Streaming teams have gotten good at cost dashboards, spend alerts, and rightsizing tools. None of that is wrong; it just treats the symptom.
The bigger lever is deciding which workloads should be paying hyperscaler prices for elasticity they don't actually use.
Why cloud costs are so hard to control on a streaming platform
Video infrastructure has a specific cost profile that is not optimized by generic cloud models.
You provision for peak concurrent viewers, not average load. A platform that averages 50,000 CCU but peaks at 400,000 during a live event either overprovisions year-round or scrambles, expensively, every time it doesn't.
Egress is the line item costs the most. Every stream you deliver out of the cloud is billed, and video is bandwidth-heavy by nature. On a hyperscaler, egress and traffic costs can run roughly 10x higher than on dedicated bare metal carrying the same load.
Encoding and origin infrastructure runs constantly, but rarely at capacity. This isn't a bursty workload. It's steady and predictable, running on infrastructure priced for volatility it doesn't need.
Global audiences mean multi-region redundancy, priced at hyperscaler rates everywhere you operate.
None of this is waste, so it doesn't show up neat and tidy on a cost-optimization dashboard. It's not idle instances or forgotten snapshots. It's a predictable, necessary load, but it's priced as if it were unpredictable.
The pattern most platforms get backwards
Most streaming infrastructure gets planned around one question: how do we scale up for the spike? It's the right question, asked about the wrong workload.
It's more useful to treat your infrastructure as two separate cost problems, not one:
- Baseline load: the encoding, transcoding, origin, storage, and steady-state delivery capacity you run every day, regardless of what's in the news or on the schedule. This is predictable months in advance.
- Surge capacity: the additional capacity you need for a live event, a launch, or a spike you can't fully forecast. This is inherently unpredictable.
Hyperscalers are built to solve the second problem. They're expensive largely because you're paying for the ability to provision instantly, at any scale, on demand: a capability you genuinely need for surge, and mostly don't need for baseline.
Run both on the same infrastructure, and your predictable load ends up subsidizing pricing that was built for your unpredictable load.
Where the savings come from
Splitting baseline from surge isn't a rebrand of "multicloud." It's a specific reallocation, and the savings come from specific places:
- Compute: Running predictable, steady-state workloads on dedicated bare metal instead of on-demand hyperscaler instances typically costs around 30% less for equivalent capacity.
- Egress: This is the biggest one for video. Traffic and bandwidth costs on dedicated infrastructure can run roughly 10x lower than equivalent hyperscaler egress.
- Provisioning accuracy: When baseline is sized to what you actually run, not what you might run, you stop paying a permanent premium for capacity you use a few nights a year.
- Forecasting: A known, flat baseline cost plus metered, pay-as-you-go surge capacity is a far easier number to build a budget around than one volatile hyperscaler bill that moves with your traffic.
Hyperscaler-only vs. bare metal-only vs. hybrid
| Hyperscaler-only | Bare metal-only | Hybrid (baseline on bare metal, burst to hyperscaler) | |
|---|---|---|---|
| Cost predictability | Low: scales with usage, hard to forecast | High: flat, known cost | High for baseline, metered for surge |
| Cost at baseline load | High: paying elastic pricing for steady-state work | Low | Low |
| Cost at peak load | High, but instant | Poor: can't absorb an unplanned spike without lead time | Moderate: surge capacity is reserved and activated as needed |
| Provisioning speed | Instant | Hours to days (pre-configured builds can be ready in under an hour; custom hardware can take 24+ hours) | Baseline pre-provisioned; surge capacity available on demand |
| Best fit | Early-stage platforms with no established traffic pattern | Stable, well-understood traffic with no need for sudden elasticity | Known baseline with occasional, real surge events |
| Biggest risk | Baseline load permanently priced like surge load | Underprepared for a genuine surprise spike | Requires knowing your own traffic pattern well enough to size baseline correctly |
This only works if you know your baseline. A hybrid model isn't the right first move for a platform that's still finding its traffic pattern. If your "normal" night is still a guess, you're not ready to separate baseline from surge yet, and a hyperscaler-only setup is the more honest starting point.
When hyperscaler-only makes sense
Hybrid isn't the right call for every platform at every stage. It's usually best to stick with a hyperscaler when:
- Platforms are still establishing a traffic pattern. If traffic still fluctuates most nights, you can't really size a baseline.
- Unplanned events hit with no lead time. If unexpected spikes happen fairly frequently, you need the instant, no-notice elasticity a hyperscaler is built for.
If either describes your platform, then a hyperscaler is the right tool for right now. Revisit the move to a hybrid setup once you have a few months of real traffic data.
How to start moving your baseline off hyperscaler
- Pull the last 3 to 6 months of traffic and separate baseline load from surge. Look for the floor, not the average.
- Identify which workloads in that baseline are truly steady-state. Encoding pipelines, transcoding, origin storage, and delivery infrastructure are the usual candidates.
- Price dedicated bare metal against your current on-demand spend for that specific baseline load, not your total bill.
- Keep hyperscaler capacity in place, reserved and metered, for surge only.
- Rebuild your forecast around the blended model: flat baseline cost plus variable, usage-based surge cost.
Hybrid streaming architecture FAQs
Is this the same as cloud repatriation?
Not exactly. Cloud repatriation usually means moving workloads back on-premises entirely. What we're describing here is narrower: keeping baseline load on dedicated infrastructure while keeping hyperscaler capacity in place, and in active use, for surge.
How much do egress fees really add up to for a streaming platform?
It depends on your traffic, but egress and bandwidth are consistently the largest line items for video-heavy workloads, and the gap between hyperscaler and dedicated infrastructure pricing is usually large enough to make it the first place worth looking.
Do I need to move everything off the hyperscaler to see savings?
No, and we wouldn't recommend it. This model specifically keeps hyperscaler capacity for surge. You're moving the predictable part of your load, not your whole platform.
How long does it take to stand up dedicated bare metal capacity?
Pre-configured builds can be ready in under an hour. Custom hardware configurations take longer: plan for up to 24 hours or more, which is exactly why this capacity is for baseline, not for a spike you're already inside of.
Getting started with hybrid infrastructure
Your baseline load and your surge load are two different cost problems, and only one of them actually needs hyperscaler pricing.
Start by pulling the last few months of traffic data and find your floor, the load that's there every night regardless of what's happening in the schedule or the news.
If your baseline has been quietly padding your cloud bill, explore servers.com's streaming infrastructure solutions to see what moving it off the hyperscaler could look like for your stack.
PS, I'll be having this exact conversation with people at IBC2026 this September. If you plan to be there, come find us at booth 5.A81 for a coffee and a chat.
About the author
