On infrastructure alone, a unified API is cheaper in every market we modelled. That is not even the main point. The point is the year of engineering the invoice hides, and the reason good teams pay it anyway.
Owen made the call about three years ago, and it was a reasonable one at the time. Video was going to be core to the product, so the video pipeline should be theirs. His team knew AWS, and the building blocks were all there: MediaConvert to encode, MediaLive for the live channels, Amazon S3 to store, CloudFront to deliver. Why rent what you can own? So they started wiring it together.
The pipeline works today. It also took the better part of those three years to feel solid, a standing slice of the team still spends its weeks keeping it alive, and the parts users actually notice, the player, the analytics, the recommendations engine feeding on watch data, were each their own project on top. Credit where it is due: AWS media services are excellent, best-in-class components, and nobody was ever going to get fired for choosing them. The question Owen did not ask carefully enough was not whether AWS could do it. It was what building it would really cost, and whether it was ever his to build.
What you actually sign up to build
A video platform is not one AWS service. It is a stack of them, plus several products AWS does not give you at all, all wired together and kept running.
Encoding into adaptive bitrate (ABR) renditions is MediaConvert. Live channels are MediaLive and MediaPackage. Storage is S3, delivery is CloudFront, the content delivery network (CDN), and content protection is a digital rights management (DRM) integration through SPEKE with licence fees behind it. That is the part AWS sells you. The part it does not: a video player for every screen, quality-of-experience (QoE) analytics so you can see why playback fails, the artificial intelligence to caption and clip and reframe, and the orchestration and monitoring glue that holds the whole thing together. Those are yours to build, and then yours to maintain.
The bill is the cheap part
Start with the number everyone compares, because it does not say what people assume. We modelled the same audience across four markets, changing only the bitrate people watch at and each region’s CloudFront rate. A unified API bills per viewer-minute, so its cost is flat everywhere. AWS plus CloudFront bills per gigabyte, so its cost climbs with both.
| Market | Bitrate | AWS + CloudFront / mo | FastPix / mo | FastPix cheaper |
|---|---|---|---|---|
| United States | HD, 1.6 GB/hr | $104,000 | $29,000 | 72% less |
| Gulf (UAE / KSA) | HD, 1.6 GB/hr | $154,000 | $29,000 | 81% less |
| Singapore / SEA | HD, 1.4 GB/hr | $122,000 | $29,000 | 76% less |
| India (mass market) | SD, 0.78 GB/hr | $58,000 | $29,000 | 50% less |
So the unified API is already cheaper on raw infrastructure, by half to four fifths depending on the market, because a video specialist’s blended delivery beats CloudFront on its own and per-minute pricing does not swell with bitrate. That is worth knowing. It is also not the number that should decide anything, because it is the smallest one in the comparison.
The expensive part is the year you do not get back
The invoice is what you pay AWS. The cost is what you pay your own team to turn those services into a platform, and then to keep it standing.
Put realistic figures on it. A video-infrastructure build is a team of four to eight engineers for a year, sometimes far longer, and then a smaller standing team forever to run it, upgrade it, and carry the pager when a render queue backs up during a live event. Against a US infrastructure line of around $1.25M for the year, the engineering to build and run the stack is comfortably larger, and that is before you count the four products you rebuilt that a unified API simply includes. The bill was never the expensive part. The team was.
A unified API does not save you a line on the invoice so much as it saves you the org chart behind the invoice.
The story teams tell themselves
Here is the part worth being honest about, because it is the real reason the build happens. Teams do not stitch a video stack together because they have run the numbers and the numbers favour it. They do it because the video pipeline feels like intellectual property, like something core that ought to be owned rather than rented. It is a compelling story, and it is almost always wrong.
Your intellectual property is your content, your product, your monetization, the recommendation logic that keeps people watching. The transcode ladder is not. The packager is not. The player controls, the CDN failover, the retry logic on a failed rendition, none of that is a moat, because your competitors can buy exactly the same capability from the same handful of providers on a Tuesday afternoon. Building it does not differentiate you. It just gives you something else to maintain. We know of a team that spent the better part of three years building what a unified API delivers in an afternoon, on the theory that the pipeline was theirs to own. What they owned, in the end, was the maintenance.
What a unified API is
The alternative is not less capable, it is the same capability arriving as one thing instead of ten. One API, one per-minute bill, and the pieces you would otherwise build already inside it.
| Capability | On FastPix |
|---|---|
| VOD + Live encoding | Per-title ABR and 24x7 live channels. Upload or point a stream, get a playback URL. |
| Player + delivery | A free player for web, iOS, Android and TV, over multi-CDN delivery, with DRM and signed playback built in. |
| Video Data | QoE analytics on 56 dimensions, ten yours to define, so you see why playback fails without building the pipeline to measure it. |
| In-Video AI | Captions, chapters, clipping and reframing on the same per-minute bill, not a separate integration. |
The difference is not a feature list. It is that the left column of the diagram above is a roadmap for a team, and this is a set of API calls you make this week. You can price the whole thing on the pricing page before you commit.
When building on AWS is the right call
To be fair to the other side, because there is one. If video is not part of your product but the entire product, and you operate at a scale where a fraction of a percent of delivery cost pays for a large team several times over, then owning the stack can be the right decision. A handful of companies are in that position and they know who they are. For everyone else, the pipeline is undifferentiated heavy lifting, and the honest reason to build it, that it feels like it should be yours, does not survive contact with what it costs. AWS is not the wrong tool. It is the wrong layer to be assembling by hand.
Owen’s pipeline still runs, and it is a credit to his team that it does. He would also tell you now that the three years bought him a video stack indistinguishable from one he could have called, and cost him three years of the roadmap that would have actually set the product apart. Encode it. Deliver it. Measure it. Protect it. Ship the product instead of the plumbing. Modern video is what we do.
Frequently Asked Questions (FAQs)
Is it cheaper to build video on AWS or use a video API?
For raw infrastructure, a per-minute video API is often less expensive because it charges per viewer-minute, while AWS combined with CloudFront charges based on data transferred. In the four-market model discussed here, the API reduced infrastructure costs by 50% to 81%. The biggest savings, however, come from engineering, since a managed video API eliminates the need to build and operate the entire video platform yourself.
What does it cost to build a video platform on AWS?
In addition to AWS infrastructure costs, expect to dedicate a team of four to eight engineers for at least a year to build a production-ready platform, followed by ongoing engineering resources for maintenance and operations. Features such as the player, analytics, AI, and DRM typically require separate development or third-party services, making engineering the largest part of the total cost of ownership.
What AWS services do you need to build a video platform?
A typical implementation includes AWS Elemental MediaConvert for video-on-demand encoding, MediaLive and MediaPackage for live streaming, Amazon S3 for storage, CloudFront for content delivery, and DRM integration through SPEKE. Additional capabilities such as a video player, quality-of-experience analytics, in-video AI, and orchestration must be built or integrated separately.
Is a video pipeline proprietary IP?
In most cases, no. Core video infrastructure such as transcoding, packaging, playback, and CDN delivery uses technologies that are widely available. A company's competitive advantage typically comes from its content, product experience, monetization strategy, and recommendation systems rather than the underlying video pipeline.
How long does it take to build video streaming on AWS?
Building a production-grade streaming platform on AWS commonly takes a year or more, with additional time required for ongoing maintenance and feature development. A managed video API can provide the same core capabilities—including encoding, streaming, playback, analytics, and AI—in days or weeks because the infrastructure has already been built and maintained.
