Egress
Billed on every segment of every stream. It is the largest recurring cost in streaming and the one with the least differentiation available for money — a gigabyte is a gigabyte.
Turn a bill that grows with success into one that doesn't
A streaming service of this shape normally pays three vendors that all bill by usage: one to transcode, one to deliver, one to measure. Every additional viewer increases all three. The work is deciding, line by line, which of those meters you actually need to keep.
This is not a discount. It is a different cost structure.
Owning the pipeline converts a variable cost that grows with your audience into a fixed cost that does not. That is precisely the curve a subscription business needs, and it is the opposite of the curve a rented stack produces.
The catch is that it is only true for the tiers where it is true. Moving a spiky, low-volume API tier onto your own hardware buys almost nothing and costs you elasticity. Moving egress and transcoding does the opposite. The engagement is about telling those apart with your numbers rather than a general argument.
Where streaming money actually goes
Four meters. Two of them are worth keeping for most services, and two of them almost never are.
Transcoding
Billed per minute, per rendition. A five-rendition ladder means every minute of source is billed five times, every time you re-encode.
Elastic compute
Sign-in storms, catalogue browsing before a big release, a payment spike at renewal. Genuinely bursty, and the bill is small because the payloads are small.
Analytics
Per-session licensing is expensive at scale and the data is yours anyway. Self-hosting is straightforward; the question is whether you want to operate another store.
How the assessment runs
Four steps, and the first two produce a number before anything is built.
Read the bill
Twelve months of invoices, broken down by service and by meter. Most of the answer is already in here and unread.
Measure the traffic
Concurrency curve, bitrate ladder, cache hit ratio and the real access distribution across the catalogue.
Model the alternative
What the same traffic costs on owned capacity, including hardware amortisation, power, transit and the operational load.
Recommend, tier by tier
Which meters to remove, which to keep, and what the migration costs to execute. Including the case where the answer is to change nothing.
The two moves that do most of the work
Delivery onto your own edge
An edge compiled for the job — range-aware caching so a mid-film seek is served from disk, per-segment authorisation, HTTP/3 — removes the egress meter entirely and replaces it with a bandwidth commit.
Transcoding onto a GPU you own
The ladder is a predictable, batchable workload with no latency requirement. It is close to the ideal case for owned hardware, and it removes a bill that multiplies by rendition count.
The things people ask first
What if the assessment says we should stay where we are?
Then that is the deliverable, with the numbers behind it. A recommendation that always concludes the same way is not a recommendation.
How long before the change shows up on the invoice?
Egress and transcoding move quickly because they are metered — the meter stops when the traffic stops. Hardware amortisation is the slower half of the equation, which is why the model has to include it honestly.
Do we have to move everything at once?
No, and you should not. Delivery first is the usual order because it is the largest single line and the least entangled with the rest of the platform.
Start with the invoice
No architecture discussion is useful before the bill has been read. Send twelve months of it, plus your concurrency and bitrate ladder, and the first thing back is an honest breakdown.