At 50 TB a month, most of your Google Cloud video bill has nothing to do with bandwidth

Nora (name changed) runs engineering at Nightjar, a vertical drama app with about forty-six thousand people watching every month. The company already ran on Google Cloud, so when the founders asked for video, nobody held a meeting about it. She wired up the Transcoder API, Google's encoding service, wrote the output to Cloud Storage, put Cloud CDN in front of it as the content delivery network, and had playback working in a fortnight. It felt like the sensible choice, because it was.

The first thing that was not simple was the ladder. The Transcoder API asks you to declare the set of quality levels a player can switch between, and nothing in the console tells you what they should be for your content. Nora picked five rungs that looked reasonable and shipped them. Then she spent the better part of a year moving them around in response to her support queue. Viewers in one market said the picture looked soft. Viewers on cheap Android handsets said it stalled. Somebody in the group chat said it ate their data. Each of those was a real signal buried in a hundred others, and each change meant re-encoding to find out whether the new guess was better than the old one. She was not doing anything wrong. She had been handed a decision that takes a specialist years to get right, with the only feedback available being people who were already annoyed enough to write in.

The bill came to $11,212 a month, which was survivable. What surprised her arrived ten months later, on a Tuesday afternoon, when the growth lead said Nightjar was launching properly on iOS and would need FairPlay, Apple's digital rights management system. Nora said yes in the meeting, because it sounded like a configuration change. She spent the rest of that afternoon reading her own Terraform, looking for the place where the packaging format was set, and found it in the encode job. The format had been written into the files themselves, ten months and a hundred and twenty thousand minutes ago. Adding FairPlay did not mean changing a setting. It meant running the entire catalog through the encoder again. The next morning she walked back into the room and moved a launch date that was already in a board deck.

Nobody had made a mistake. The stack had been asked a question it was never built to answer. Nora is a composite, and her name and her company's are changed, but the week is not invented: it is assembled from conversations with teams running exactly this stack, several of whom are still running it. This article is about the distance between the bill you can see and the decisions you cannot take back, and every number in it is a published list price for one scenario stated in full, in a spreadsheet you can open.

What does it cost to stream video on Google Cloud?

The scenario is Nightjar's. Fifty terabytes delivered a month, roughly 5.1 million viewer-minutes, a catalog of 120,000 source minutes, 15,000 new minutes published each month, captions in three languages, and DRM switched on because the app is paywalled. The audience is mobile and the video is vertical, so the adaptive bitrate ladder, meaning the set of quality levels a player can switch between, is lighter than a landscape service would need.

Every figure in that table comes out of the workbook we used to build it, which is attached to this article. Nothing below is a number you have to take on trust.

That is 51.6% lower, and the delivery line is not what does it. Google's content delivery network costs $0.0667 per gigabyte here against our $0.0602, which is close enough that you should treat bandwidth as a draw and go looking elsewhere for the difference. Both figures include captions priced at the same third-party speech-recognition rate, because using a different caption source on each side would have made the comparison meaningless.

Bandwidth is the line everyone prices before they buy. It is almost never the line that decides.

Where the bill actually comes from

Look at Google's column again and ask a different question of it. Not which numbers are large, but which ones move when Nightjar's traffic moves.

Delivery moves. Very little else does. The player licence is $2,500 whether ten people watch or ten million, because it is licensed to the company rather than metered to the audience. The operations layer underneath, the logging, the job orchestration, the metadata database and the load balancer, comes to $1,731 and sits there regardless. The platform fees beneath DRM and analytics add another $698 before a single licence is issued or a single view is recorded. Taken together, $4,929 of Google's $11,212 is a floor, which is 44% of the bill, and it does not care how much video Nightjar serves.

This is the part that catches companies while they are still growing. Halving the traffic barely moves the Google bill. Nora could have lost a third of her audience and saved almost nothing, because most of what she was paying for was capacity to serve an audience she did not have yet. Google charges you for the traffic you have and for the scale you do not.

The same effect shows up in the per-gigabyte number once you stop looking only at delivery. All in, Google costs $0.2242 per gigabyte served against our $0.1086, which is 2.1 times, on identical traffic, at published rates.

Why does encoding cost four times more on Transcoder API?

Because of how the Transcoder API counts the thing it bills for.

It charges per minute of output, per rendition, where a rendition is one rung of the quality ladder. Nightjar ships five video renditions and one audio-only rendition, so every minute of source video is billed six separate times.

Google Transcoder API, per source minute
  2 HD renditions      x $0.030  =  $0.060
  3 SD renditions      x $0.015  =  $0.045
  1 audio-only         x $0.005  =  $0.005
                                 ---------
                                   $0.110

FastPix, per source minute
  1 charge, whole ladder included =  $0.026719

                    4.1x

There is no volume tier on that rate, and this is the part worth sitting with. Not at 15,000 minutes a month, not at 15 million. It is the same $0.110 whatever you publish, which means the faster Nightjar makes content, the worse the ratio becomes. For a short-drama app that publishes constantly, encoding is not a rounding error. It is a growth tax.

Captions work the same way, and the numbers are worse. Google's own automatic caption generation costs $0.50 per subtitle minute. At Nightjar's 15,000 new minutes across three languages that comes to $22,500 a month, which is more than twice everything else on its Google bill put together. A third-party speech-recognition service does the same job for roughly $675, so that is what the table above uses on both sides. Using Google's own price there would have flattered us, and the comparison would have deserved less trust.

What is per-title encoding, and why does it change what your viewers see?

Everything above compares what the two stacks charge to encode. This is about what they produce.

A bitrate ladder is a set of quality levels, and most encoding setups use one ladder for everything. That is a compromise by construction, because a two-hander talking in a kitchen and a night-time chase scene do not need the same number of bits to look the same. Point one ladder at both and you overspend on the quiet one and underserve the busy one.

Per-title encoding, also called content-aware encoding, tunes the ladder to each individual piece of content. It is a machine-learning problem: analyse the footage, work out where the complexity actually is, and build the ladder that hits the target quality with the fewest bits. It takes roughly 35% off storage and bandwidth at the same picture quality, and on FastPix it is on by default. That is the part worth being blunt about: this is not a setting we expose to you. It is years of encoding work, ours and the industry's, compressed into a default, so the year Nora spent moving rungs around against her support queue is a year you do not spend. If you want the mechanics, we have written up how content-aware encoding works and how capped CRF keeps quality steady without inflating the file.

The Transcoder API has no equivalent. You define the ladder, and tuning it is your job. In practice that means picking numbers that seem reasonable, shipping them, waiting to see whether anyone complains, and adjusting, which is what Nora did for most of a year. The feedback loop runs in weeks and arrives through support tickets and app store reviews. It is a slow and expensive way to learn something a model can tell you in one pass, and it costs you the viewers who left instead of complaining.

The cost side is the smaller half of this. The larger half is what your viewer experiences. More bits for the same picture means a heavier stream, and a heavier stream behaves badly in exactly the conditions a short-drama audience watches in: a prepaid mobile plan, a train, a patchy evening cell. It starts slower. It stalls more. It eats a data bundle faster, and a viewer who watches their data disappear during episode four does not file a bug report, they stop watching. For an audience on metered plans, the bitrate you deliver is not an infrastructure metric. It is a retention metric.

None of this is in the 51.6% above. The table holds the delivered bitrate identical on both sides, which is generous to Google, because matching our picture quality without a content-aware ladder means shipping meaningfully more bytes. Count it and the gap widens. Ignore it and the gap is still there.

Which of these decisions can you defer?

Now the part that cost Nora six weeks.

Four capabilities have no Google Cloud product at all. Not a more expensive version, not a preview, nothing you can switch on. You supply them yourself or you buy them from somebody else, and you have to decide which before you ship, at the moment you know least about your own product.

Just-in-time packaging. On Google Cloud the Transcoder API writes finished segments to storage, so your packaging format and your encryption scheme are fixed at the moment you encode. There is no service that assembles a stream on request. That is the wall Nora hit. Adding FairPlay, or adding DASH, the streaming format most non-Apple players expect, means running the whole catalog through again: $13,200 at Transcoder rates against $3,206 with us, and that is before the weeks. With FastPix Video on Demand, packaging happens at playback, so the format is a parameter on the request rather than a property of your archive.

A DRM licence server. Google will encrypt your content but it will not issue the licences that let a device play it, so you sign a third vendor before you launch. There is a date attached to this one. Google's own hosted Widevine Cloud License Service, which issues the licences for Android and Chrome the way FairPlay does for Apple, retires on 13 April 2027, with the key-fetch API switched off that February. Widevine is Google technology, and Google is leaving its users to find a replacement. If DRM is new to you, we have a plain explanation of how it actually works. Anyone who built on the hosted service has inherited a migration on a calendar they did not choose. FastPix DRM issues licences as part of playback at $99 a month plus $0.003 per licence, which makes the licence server a flag you set rather than a vendor you sign.

Quality-of-experience analytics, meaning the measurements that tell you whether playback is any good: how often it stalls, how long it takes to start, how many people leave before the first frame arrives. Google Cloud has two products with analytics in the description and neither one measures this. Video Intelligence API and Vertex AI analyse the content, returning labels, shot changes, objects and transcripts, which is a different job entirely. Media CDN reports from the network's side: cache hit ratio, edge location, origin selection, error codes, plus whatever Common Media Client Data your player chooses to send. Its playback tracing feature, the one closest to what you actually want, is documented by Google as unavailable in the current release. So when retention dips in week two you cannot separate buffering from bad writing, and every decision after that is an opinion. FastPix Video Data reports from inside the session instead, across 44 dimensions, 19 playback events and 63 calculated metrics, including buffer ratio, startup time, exits before start, upscaling and downscaling, and a composite experience score per view. That is the difference between knowing your edge served the segment and knowing your viewer saw it. We have written about which of those metrics are worth watching and why network quality and viewer experience are not the same measurement.

There is a second half to this that gets missed, and it is the half a founder cares about. The same software development kit that records buffer ratio also records who watched, how far they got, what they replayed, and how long it has been since they came back. That is engagement data, not experience data, and it answers a different question. Buffer ratio tells your engineer to re-tune the ladder. Days-since-last-watch tells your growth lead which subscribers are cooling fifteen days before the renewal fails, which creators actually retain the people they bring in, and which moments in an episode people rewind to, which is the same as knowing what to clip. We built a churn dashboard for a creator platform out of exactly this data, and published the underlying dataset with it, so you can see the whole path from playback event to a decision about a renewal. Google Cloud gives you neither column, because both are recorded inside the player and Google does not ship one.

Player SDKs, the software development kits a mobile team drops into an app. Google ships none, which for a swipe-to-next short-drama service is not a small omission, because the player is the product. Nightjar licences one at $2,500 a month, 22% of its Google bill, or it builds its own on each platform.

Building it is the option that looks cheapest and is not. Video player engineers are expensive and there are not many of them, and the ones you find end up holding the least documented code in your company: platform quirks, buffering heuristics, DRM handshakes, the workaround for the Android device that stalls on a particular segment length. Almost none of that lives anywhere except in their heads. When one of them leaves, and eventually one of them does, the knowledge goes with them, and the next person spends a quarter learning what the last person already knew. That is not a line on a bill. It is a standing risk on a small team, and it costs a manager real attention every month. FastPix Player is free and open source across web, iOS, Android, Flutter and React Native, with no per-user and no per-domain fee, and the buffering heuristics are our problem to keep current.

The middle column is the one that matters when you are planning a roadmap, because it turns each of these from a price into a date. A missing feature is something you buy when you need it. A frozen decision is something that arrives on a Tuesday and moves a launch. Google will sell you every part, and it will not sell you the order to assemble them in.

The five vendors you did not plan to sign

Add up what Nora is now holding. A cloud provider for encoding, storage and delivery, then a DRM vendor, an analytics vendor, a player vendor, and a speech-recognition service for the captions. Five contracts, five sets of credentials, five bills that arrive on different days, five things that can page somebody at two in the morning, and one team keeping the seams closed between them.

Running that takes people, and the people are the largest number in this article. We assume two and a half engineers to operate the assembled stack against half an engineer to operate a platform, at a loaded cost of $8,000 a month each. That is $20,000 against $4,000, and it belongs to Nightjar rather than to any vendor. Neither Google nor we invoice for it. It is the difference between operating a system and integrating one, and headcount understates it, because the scarce thing on a team this size is not salary, it is the attention of the person who has to keep five vendors and four platform players in their head at once. If your team would staff it differently, change the assumption and the rest of the article still holds.

All in, Nightjar spends $31,212 a month on Google Cloud against $9,430 with us. Across a year that is $261,384, which at this company's size is not a line item. It is a hire, or a market.

[CTA: Instrument the player you already run. FastPix Video Data is free to 100,000 plays a month and needs no migration. → https://fastpix.com/video-data?intent=gcp-compare]

What happens when we grow past this?

The real version first, because the curve does move against us.

Two things are happening in that table and they are worth separating. Google's delivery pricing does step down as volume climbs, though gently in this range, because the steepest tier boundaries sit well above 300 TB. The larger effect is simply that our per-minute rate is flat here while Google's per-gigabyte rate is not, so a gap that starts wide narrows steadily. Engineering is held constant across every row, which is conservative: a bigger service usually needs more people to run an assembled stack, not the same number.

But the right-hand columns hold FastPix at the entry rate at every volume, and that is not what happens. Our rates step down automatically when you cross a threshold, at 100,000 minutes, at a million plays, at your tenth channel. There is no renegotiation, no meeting and no procurement cycle attached to any of them. Annual commitments and enterprise agreements go further again.

And the published thresholds are the floor of what we can do, not the ceiling. Above them, up to roughly 5 PB a month, we quote, and we quote to stay below what Google costs you with delivery included. We will put that in writing before you commit to anything. What we will not do is publish it, because a rate at that volume depends on where your audience sits, how much of your catalog caches, and what you are willing to commit to, and any number printed without those three things is fiction. This is not us being coy. It is how the whole industry prices at that volume, Google included.

Media CDN is worth separating out, because it comes up in most of these conversations. It is Google's video-optimised network and it is very cheap at scale. It also has no public price, and a Google sales representative has to enable it on your project, which means a company at 50 TB a month cannot buy it at all. By the time Google will quote you Media CDN, you are long past the thresholds where our rates have already moved, and that is a comparison we would rather put in writing for you than leave to a table.

Google's discount arrives after a negotiation. Ours arrives after a threshold.

How can FastPix price it this way?

Fair question, and the answer is not that we found cheaper bandwidth. On delivery we sit within a rounding error of Google, and above a certain scale Google's negotiated pricing will beat anything a platform quotes off a public page.

The difference is in what we do not meter. We charge once per source minute and include the whole ladder, because the ladder is our engineering problem rather than your line item. We do not sell a player, so ours is open source and free instead of a licence with your company name on it. We package at request time, which means we never need you to buy storage for a format you might use one day. Per-title encoding, which tunes the ladder to each individual piece of content rather than applying one recipe to everything, takes roughly 35% off storage and bandwidth at the same picture quality, and that saving lands on our side of the meter as well as yours.

Put plainly, we make money when you stream more, not when you assemble more.

If you build on Google Cloud anyway, here is what to check first

Plenty of teams should, and this is not a difficult case to make. If your catalog is small, your delivery is heavy, you have no DRM requirement, you already own a player your users like, your engineers have spare capacity, and you have Google commitments to burn down, then the assembled stack is a reasonable answer and you should take it. Google Cloud is very good infrastructure. Video Stitcher is more mature at server-side ad insertion, which places ads into the stream itself, than we are, because we do not offer it yet.

If that is you, work through these five before you write any code. They are the ones that get expensive later rather than now.

1. Can you add a packaging format or an encryption scheme without re-encoding your catalog, and what does it cost if you cannot?
2. Who issues your DRM licences after 13 April 2027, and have you priced that migration?
3. How will you measure rebuffering and startup time from inside the playback session rather than from the network?
4. Who maintains your iOS player in eighteen months, and is that person hired?
5. When your traffic doubles, which lines on your bill double with it, and which ones do not move at all?

Ask them of us as well. The answers are the whole comparison.

Can I check these numbers myself?

Yes, and you should. Three ways, in increasing order of how little you have to trust us.

Open the spreadsheet. Every number in this article comes out of one workbook, and it ships with the article rather than behind a form. Delivered volume, the bitrate ladder, the regional split of your audience, the licence count, the storage class mix: all of it is an input you can change, and every total re-computes. The README tab lists which cell produces which figure in this article, so you can go straight to the one you doubt. If you change the regional split and our advantage disappears, that is a real finding and we would rather you had it now than after a contract.

Ask an AI to audit it. Paste this into ChatGPT, Claude or Perplexity, and let something with no stake in the answer go and read both rate cards:

Read this article and check its arithmetic. It claims Google Cloud costs $11,212 a month and FastPix $5,430 for the same 50 TB per month workload at published list prices. Verify each line against Google Cloud's current published rates for Transcoder API, Cloud Storage and Cloud CDN, and FastPix's published rate card. Tell me which lines are right, which are wrong, and what assumptions the comparison is making that I should push back on.

Check it on ChatGPT · Claude · Perplexity

Bring us your own bill. The scenario here is one company's. Yours has a different ladder, a different audience map and a different catalog. Send us the numbers and we will run them through the same workbook in front of you, including the lines where Google comes out ahead.

The part worth remembering

Nora did not choose wrong. She chose the fastest path to working video inside a cloud her company already ran on, which is the correct instinct nine times out of ten. What she could not see from inside week two was which of those choices were rented and which were welded, and welded choices do not announce themselves until the day you try to change one.

The expensive decisions in video are not the ones you priced. They are the ones you cannot undo.

Publish it. Package it on the way out. Measure it from inside the session. Change your mind next quarter without re-encoding a thing.

Modern video is what we do.