TL;DR

We had a video feature built on S3 + MediaConvert + CloudFront + a hand-rolled player + a half-finished CloudWatch dashboard. It worked, but every change touched five services. This post shows the glue code we actually ran, then the same flow as one upload call against a managed video API (FastPix here, but the pattern is identical for Mux / Cloudflare Stream / api.video). You'll see exactly what code disappears.

The setup we were maintaining

Here's the honest shape of the DIY pipeline. Upload to S3, trigger MediaConvert on the object-created event, write renditions back, serve through CloudFront. The Lambda that kicks off encoding looked roughly like this:

// lambda/triggerEncode.js - fires on S3 ObjectCreated
import { MediaConvertClient, CreateJobCommand } from "@aws-sdk/client-mediaconvert";

const mc = new MediaConvertClient({ region: "us-east-1" });

export async function handler(event) {
  const key = event.Records[0].s3.object.key;
  const input = `s3://uploads-bucket/${key}`;

  await mc.send(new CreateJobCommand({
    Role: process.env.MC_ROLE_ARN,
    Settings: {
      Inputs: [{ FileInput: input }],
      OutputGroups: [{
        Name: "Apple HLS",
        OutputGroupSettings: {
          Type: "HLS_GROUP_SETTINGS",
          HlsGroupSettings: {
            Destination: `s3://renditions-bucket/${key}/`,
            SegmentLength: 6,
            MinSegmentLength: 0,
          },
        },
        // ...one Output block PER rendition: 1080p, 720p, 480p, 360p...
        Outputs: [ /* 40+ lines of codec settings per rendition */ ],
      }],
    },
  }));
}

That Outputs array is where the weekends go. Every rendition is a block of codec settings. Every tweak to the ladder is a redeploy. And this Lambda is only the encode trigger. You still need:

• An IAM role with the right MediaConvert + S3 permissions.
• A second event path to know when the job finished (EventBridge → another Lambda).
• CloudFront in front of the renditions bucket, with an OAC so the bucket isn't public.
• A player that knows the manifest URL.
• Something that records whether playback actually worked.

⚠️ None of these is hard. The problem is that there are five of them, and they fail independently.

The cost shape (why tuning didn't save us)

The bill wasn't one number, it was several that move on different axes:

MediaConvert is billed per output minute, and CloudFront egress is billed per GB, so a popular video is a bigger bill on two axes at once.¹ We dropped a rendition and moved to a cheaper CloudFront price class. It trimmed the edges. It did not change the shape.

The replacement: one upload call

Here's the same upload-encode-store-deliver flow as a single request. Auth is Basic with an Access Token ID + Secret Key.

// server/createAsset.js - node 20+
const res = await fetch("https://api.fastpix.io/v1/on-demand", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    Authorization: "Basic " + Buffer
      .from(`${process.env.FASTPIX_TOKEN_ID}:${process.env.FASTPIX_SECRET}`)
      .toString("base64"),
  },
  body: JSON.stringify({
    inputs: [{ type: "video", url: "https://your-bucket/source.mp4" }],
    // ABR ladder is generated for you; no per-rendition codec blocks
    metadata: { project: "demo" },
  }),
});

const { data } = await res.json();
console.log("playbackId:", data.playbackId);

Playback is then just an HLS URL you can hand to any player:

// app/player.js - works with hls.js, Video.js, Shaka, or the platform player
const src = `https://stream.fastpix.io/${playbackId}.m3u8`;

The 40-line-per-rendition Outputs array is gone, because the ABR ladder is generated server-side. The "did it finish" EventBridge path becomes a single webhook you subscribe to once. And the analytics project I never finished on CloudWatch ships as Video Data, free up to 100K views a month, where Mux's comparable Media plan starts at $499/month.²

Want resumable uploads from the browser instead of importing from a URL? That's the upload SDK, not a fresh S3 multipart implementation:

npm install @fastpix/upload

// app/upload.js
import { uploadFile } from "@fastpix/upload";

await uploadFile({
  endpoint: signedUploadUrl,   // created server-side via the same API
  file,                        // a File from an <input type="file">
  onProgress: (p) => setProgress(p),
});

Before / after, honestly

On total cost, FastPix publishes a "~70% cheaper than AWS" figure, but it's tied to a specific scenario (1-minute 1080p video streamed to 500K viewers), so treat it as scenario-specific, not a blanket promise.³ The win I'd actually stand behind is predictability: one usage-based bill instead of five that move independently.

💡 Trade-off worth naming: this is an API-first approach, not a no-code video CMS. If your team wants a drag-and-drop back office with zero engineering, you'll still build a front-end on top of the API.⁴

What's next

• Subscribe to processing webhooks so your UI flips from "processing" to "ready" without polling.
• Add signed playback (JWT) if your content is gated.
• If you're migrating an existing library, look for a batch import tool rather than scripting S3 copies by hand.
• Compare the numbers for your delivery-to-encode ratio: FastPix pricing next to AWS MediaConvert pricing. The right answer depends on your workload, not on a blog post.

If you're at extreme sustained scale, keep self-hosting; the math flips in your favor there. For a video feature inside a product that does something else, one API call beats five services.

1. MediaConvert per-output-minute and CloudFront per-GB egress: aws.amazon.com/mediaconvert/pricing (verify current). ↩

2. FastPix Video Data free up to 100K views/month; Mux Data Media plan $499/month (verify Mux pricing). ↩

3. "~70% cheaper than AWS" is FastPix's published, methodology-specific comparison (1-min 1080p, 500K viewers). ↩

4. Approved FastPix trade-off: API-first, not a no-code CMS. ↩