AWS vs FastPix pricing: you upload forty minutes, AWS bills you for 629

You can build your whole video stack on AWS. Plenty of teams do, and it works. If your company already runs on AWS you get identity, billing and networking thrown in, which is worth something real. If that is your setup and it is working, more power to you.

Before you assume it is the cheaper option, check one number.

You have a forty-minute episode. You think you have forty minutes of video. AWS bills you for 629.

What are you buying when you host video on AWS?

Video on AWS is not one product. You assemble it from several, so the pricing only makes sense once you know what each piece does.

AWS Elemental MediaConvert is the encoder. You hand it your master file, it produces the smaller versions your viewers actually stream, and it bills per minute of output it creates.

Amazon S3 is storage. Your master and every version MediaConvert made live here, priced per gigabyte per month.

Amazon CloudFront is the CDN, the network of servers that keeps your video physically close to viewers so it starts fast. It bills per gigabyte delivered, and it will be most of your bill.

Three more sit alongside: MediaPackage for just-in-time packaging, MediaTailor for ad insertion, and Amazon IVS, AWS's managed live streaming service. Each is a separate line, a separate console and a separate way for your Saturday to go wrong.

FastPix is one service and one bill covering encoding, storage, delivery and FastPix Player.

Why does one minute of video cost 15.72?

You do not ship viewers one copy of your video. You ship a ladder: the same episode encoded at several qualities, so someone on hotel wifi gets a small version, someone on fibre gets a sharp one, and the player switches between them as the connection moves. That is adaptive bitrate, ABR, and it is how every streaming service works.

MediaConvert bills every rung of that ladder separately, and weights each one. Standard definition counts least, high definition roughly double, 4K double again. Frame rate moves it too: anything above 30fps costs more than anything below. And multi-pass encoding, where the encoder reads your file once to find the hard scenes and then encodes it properly on a second pass, carries its own higher multiplier.

Here are AWS's published multipliers for H.264 on the Professional tier, and your ladder priced with them at 60fps, which is what FastPix encodes every rendition at:

  1080p   HD, multi-pass, 60fps   x 4.38   =   4.38
   720p   HD, multi-pass, 60fps   x 4.38   =   4.38
   480p   SD, multi-pass, 60fps   x 2.19   =   2.19
   360p   SD, multi-pass, 60fps   x 2.19   =   2.19
   240p   SD, multi-pass, 60fps   x 2.19   =   2.19
  audio                           x 0.39   =   0.39
                                             15.72  billed minutes

  40-minute episode  x 15.72  =  629 billed minutes

FastPix bills 1. The ladder is included in it.

Drop to 30fps and it falls to 12.64. Drop multi-pass as well and it falls to 7.39, at the cost of a visibly worse encode. Every quality decision you make is also a billing decision.

Count your own ladder with us.

Can you just ship fewer rungs?

Every rung you cut is a viewer with nothing to fall back to. Lose 240p and the person on a train gets a spinner instead of a small picture. Lose 1080p and your best-connected viewers get something soft on a big screen. Shortening the ladder does not save you money, it moves the cost onto the viewers with the worst connections, who in most markets are most of your viewers.

It also moves the wrong way as you improve. Add a 4K rung at 60fps and 15.72 becomes 24.47, which is a 56 percent jump for one rung.

On a per-source-minute bill, none of that moves.

What this looks like for a real service

Sam runs Pickleball Weekly. Niche sports streaming, 400 hours in the library, about 33 new hours a month, and 15 million viewer-minutes a month from roughly 60,000 subscribers. Three quarters of them watch from the United States, Canada and Europe, the rest from everywhere else.

Sam's team is four engineers, none of whom came to work on video. On the Tuesday of finals week a MediaConvert job failed on retry at 2am, the morning highlights did not publish, and the one engineer who understands the pipeline was on a plane. That is the cost that never reaches an invoice.

First, the arithmetic. Both stacks price the same two things, so here are the rates:

AWS MediaConvert, Professional tier   $0.0120 per normalized minute (first 50,000)
Amazon CloudFront                     tiered by volume, see below

FastPix Pro, 1080p    encoding        $0.026719 per source minute
                      storage         $0.002688 per source minute per month
                      streaming       $0.000679 per minute delivered

At 3.2 Mbps average delivered bitrate, one viewer-minute is 24 megabytes. Per-title encoding takes about 20 percent off that on both stacks, so call it 19.2 megabytes. Fifteen million viewer-minutes is 288 terabytes a month.

Moving the library across costs this, once:

AWS      400 hours = 24,000 source minutes  x 15.72  =  377,280 normalized minutes
                                                     =  $3,742

FastPix  24,000 source minutes x $0.026719           =  $641

Six times the price, but you pay it once. On AWS you pay a version of it again every time you change the ladder, because a new rung means re-encoding everything you own.

Sam's monthly bill

Storage is the one line where AWS wins, and it barely registers either way. Delivery is 97 percent of the AWS bill, which makes your CloudFront rate the only input that really matters.

That rate depends on how big you already are. CloudFront is tiered by monthly volume, so Sam's 288 terabytes blends to about $0.0698 per gigabyte across the cheap and expensive price classes, while a service pushing 67 petabytes pays around $0.036.

CDN on AWS is regressive. The company least able to absorb the bill pays roughly twice per gigabyte what the biggest ones pay. Same rate card, different position on it.

The bill is a third of what AWS costs you

A self-assembled AWS video stack is not something you buy. It is something you now run.

Somebody writes the pipeline that moves a file from upload through MediaConvert into S3, and the retry logic for the night it fails at 2am. Somebody owns the DRM licence server, the digital rights management that stops your paid content being downloaded. Somebody is on call when playback breaks for one mobile carrier in one region. Somebody keeps the player working on web, iOS, Android and connected TV as each of those platforms ships a change that breaks it.

None of that appears on an AWS invoice. All of it is a salary.

Cost it at three engineers on $165,000 loaded, meaning salary plus tax, benefits and overhead, which is a generalist's number rather than a video specialist's. Half an engineer on the FastPix side, at the same rate.

Infrastructure is 33 percent of what the AWS path costs. The other 67 percent is people.

If AWS handed you the infrastructure for free, the AWS path would still cost $495,000 a year, against $206,135 for FastPix with the engineer included. Credits discount the smaller third.

The engineers you cannot hire

Engineers are the biggest number in that table, and it is the optimistic version. Money you can approve. A video engineer is a waiting list.

The job AWS implies is not one skill, it is five: ABR packaging, DRM and licence servers, players on four platforms, CDN cache behaviour, and the instinct to look at one rebuffering complaint from one carrier and know where to start. People who have all five already work at companies that do nothing but video.

So you do not hire three video specialists. Two of your backend engineers learn packaging and DRM as they go, the way Sam's did. The stack works. It is also fragile in ways nobody can put into words, incidents take days rather than hours because the instinct was never built, and exactly one person understands why the manifest looks the way it does. When they take a flight, nothing ships.

Sclera hit this before they moved to FastPix. They were streaming MP4 files from S3 to customers worldwide, they lacked video expertise in-house, and as they put it, building video pipelines, formats, bitrates and playback infrastructure distracted from their core business. Afterwards: "Customers compliment us on the quality and usability of our videos now."

You can sign off the headcount today and still not have the person in October. That delay is measured in roadmap, not dollars, which is why no cost model catches it.

Nobody ever got fired for building on AWS

For thirty years, choosing IBM was the purchase nobody could criticise, and it was excellent advice for the person making it. IBM sold its PC business in 2005 and its x86 server business in 2014. The buyers who followed the maxim were not fired. Their companies were overtaken by the ones who asked what it cost.

This is not a prediction about AWS, which runs the best general-purpose infrastructure on earth. It is a point about how the choice gets made. "We are on AWS" ends a conversation in a way that "we evaluated four options" does not, and ending the conversation is worth something to whoever presents it. Just be clear that the credits making it feel free are discounting a third of the cost, and that the parts are not permanent either: AWS moved MediaLive and MediaPackage to end of support in select regions on 30 June 2026. When you assemble the stack, that migration is yours.

What you get instead of a pipeline

Video Data reports per-session playback telemetry across 56 dimensions, ten of them yours to define, which is the difference between seeing that people stopped watching and knowing why. It is also what makes real analysis possible: a microdrama episode funnel and paywall dashboard needs viewer identity carried across episodes, and a video engagement workflow that nudges people who opened a lesson and never watched it runs on playhead position. On a self-built stack, that instrumentation is one more thing to build.

Cloud Playout turns Sam's 400 hours into a linear channel with a programme guide, graphics and slates, running on the site, in the app and wherever it simulcasts. Most channel content is on-demand video aired as live. If you own a deep library you already own a channel, it just is not on air yet.

Clipping Agent cuts vertical highlight clips with captions burned in, because most people watch social video on mute. Five to ten clips a day is 150 to 300 doorways a month back into the product, which for a sports service is an acquisition channel rather than a feature.

In-Video AI makes captions, chapters and summaries a property of upload. Live Streaming covers finals night and turns it into on-demand afterwards with no re-encode. All of it sits behind the same API as Video on Demand.

Moving is not a project either. FastPix batch migration connects to your S3 buckets over the API, maps your storage paths and metadata into FastPix, and turns a catalogue transfer that would take weeks by hand into hours. See what a migration looks like.

What about enterprise pricing?

Both columns are list price, deliberately. A comparison resting on a discount only one side can verify is not a comparison.

At volume the picture really does change for AWS. Committed-use pricing and Enterprise Discount Programs cut CloudFront and MediaConvert rates substantially, and a committed AWS customer's infrastructure line does get cheap. FastPix has enterprise pricing too, and above a few hundred terabytes a month it is worth talking to us about volume pricing rather than reading a rate card.

What a discount cannot touch is the shape. On AWS it reduces the infrastructure third. The engineering two thirds stay exactly where they are.

When is AWS the right answer?

When you want to own it, and you have the people who want to own it.

If video is your core product rather than a capability inside it, owning the pipeline is owning your differentiation. If you have requirements no platform exposes, the parts really are better than the whole. If you already employ engineers with real streaming depth, that is an asset and you should keep them pointed at something hard. Mature server-side ad insertion still belongs to MediaTailor. And if your requirement is live and only live, Amazon IVS is a managed service rather than an assembly job, so most of this article does not apply to it.

What you are buying in those cases is control, and you pay for it in headcount and attention rather than dollars per gigabyte. Some teams should absolutely make that trade.

None of this makes a thin catalogue worth watching. Infrastructure does not program taste, and no pricing model ever fixed a retention problem. What it decides is where your hardest engineering hours go.

The short version

Count your ladder, multiply it by AWS's published weights, and compare the result against one charge per source minute. Pull your real egress and find your actual CloudFront tier rather than the headline rate. Then add the salaries, because that is two thirds of the number, and leaving it out is how build-versus-buy decisions get made badly.

If video is your product and you have the team, build it on AWS. If video is a capability inside your product, the question is not what your video infrastructure costs. It is whether the two hardest engineers you hire this year should spend the year on a pipeline.

Upload it. Encode it. Stream it. Clip it. Read the numbers. Modern video is what we do.