Skip to content

Deployment · AWS

All of it on AWS — engineered, not lifted

No rack, a hard launch date, or a compliance position that requires a hyperscaler. The platform runs entirely on AWS, with the cost controls designed in from the first commit instead of discovered in month four.

The difference is not the service list

No hardware, a hard launch date, or a compliance position that requires a hyperscaler. You still want the bill engineered.

Almost every AWS streaming architecture uses the same handful of services. What separates a bill you can live with from one you cannot is whether egress, storage class and instance size were decisions — made deliberately, before launch, against measured numbers — or defaults that nobody revisited.

This pattern treats cost as an engineering property of the system, the same way latency or availability is. Cache policy is chosen against the real access curve. Storage classes follow how the catalogue is actually watched, not how it was uploaded. Commitments are bought after a baseline has been observed, never on a forecast. And every one of those decisions is in version control, so it can be reviewed, changed and explained.

Reference architecture

How it fits together

Every tier on AWS — with the control plane that keeps it honest.

01Viewers

Web · mobile · television

  • Web playerHLS · AES-128
  • Mobile appsiOS · Android
  • TV appsAndroid TV · tvOS
  • Playback telemetryper-session beacons

02AWS delivery

The tier to watch on the invoice

  • CDN distributioncache policy tuned
  • Signed URLs / tokensper segment
  • Load balancingHTTP/2 · HTTP/3
  • WAF & rate limitsabuse control

03AWS application tier

Containers, right-sized

  • Catalogue & searchREST
  • Auth & entitlementstokens · sessions
  • Billing & paymentssubscriptions · PPV
  • Analytics ingestcontinuous

04AWS media & storage

Storage class matched to access

  • Encoding jobsGPU instances
  • Object storagelifecycle rules
  • Managed databasePostgreSQL · Redis
  • Secrets managerrotated

05Control plane & cost engineering

No console clicking, ever

  • Terraformevery resource
  • GitOps pipelinemerge = deploy
  • Budgets & anomaly alertsper service
  • Commitment strategymeasured, then bought
  • Yours — hardware you own
  • Rented — public cloud
  • Edge — faces the viewer
The difference between this and a lifted-and-shifted stack is not the service list — it is that egress, storage class and instance size were decisions, made before launch, and every one of them is in version control.

Specification

Default outcome versus engineered outcome

The left column is what a stack becomes if nobody owns the bill. The right column is the work.

ConcernDefault outcomeEngineered outcome
EgressMetered on every segment, unboundedCache policy and commit pricing chosen against measured traffic
ComputeOversized instances, idle overnightRight-sized, scaled to real concurrency
StorageEverything in the hot class foreverLifecycle rules matched to actual access curves
TranscodingPer-minute managed serviceOwned GPU instances, batched
CommitmentsBought on a guess, or not at allBought against measured baseline
Change controlConsole clicks nobody can replayTerraform plan in a merge request
The difference between this and a lifted-and-shifted stack is not the service list — it is that egress, storage class and instance size were decisions, made before launch, and every one of them is in version control.

Nothing is clicked into existence

Every resource in the estate is declared, reviewed and applied by pipeline. If it is not in the repository, it is not in the environment — which is what makes a cost review possible at all.

bash
# The only path to production, on either estate.
git switch -c raise-vod-cache-ttl
$EDITOR infra/edge/cache-policy.tf
terraform plan -out=tfplan        # attached to the merge request
git push -u origin raise-vod-cache-ttl

# Review, approve, merge -> the pipeline applies it.
# No console session. No out-of-band change. No drift.

Detail

The honest trade-offs

What you gain

No hardware, no data-centre relationship, and a launch that does not wait on procurement. Capacity is available the moment you need it.

What you take on

A bill that grows with success. That is survivable when it is engineered and monitored; it becomes existential when nobody owns it.

The usual next step

Most services that grow on this pattern eventually move delivery and origin onto their own metal. Because everything is Terraform, that migration is a change of target, not a rewrite.

Questions

The things people ask first

Will you tell us to move off AWS?

Only if the numbers say so, and only for the tiers where they say so. Plenty of services should stay entirely on AWS. The recommendation follows the measured bill, not a preference.

How is this different from any AWS partner?

Most partners will build you the reference architecture. The difference here is eight years of operating streaming at the sharp end, and a platform that already runs in production on owned hardware — so the cost conversation is informed by knowing exactly what the alternative costs.

Do you need admin access to our account?

We work through a role scoped to what the engagement needs, and every change lands as Terraform in your repository. You keep the account, the state and the audit trail.

Get the bill engineered

Whether you are launching on AWS or already there and watching the invoice climb, the first deliverable is the same: an architecture and a cost model you can defend.