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.
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.
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.
Every tier on AWS — with the control plane that keeps it honest.
Web · mobile · television
The tier to watch on the invoice
Containers, right-sized
Storage class matched to access
No console clicking, ever
The left column is what a stack becomes if nobody owns the bill. The right column is the work.
| Concern | Default outcome | Engineered outcome |
|---|---|---|
| Egress | Metered on every segment, unbounded | Cache policy and commit pricing chosen against measured traffic |
| Compute | Oversized instances, idle overnight | Right-sized, scaled to real concurrency |
| Storage | Everything in the hot class forever | Lifecycle rules matched to actual access curves |
| Transcoding | Per-minute managed service | Owned GPU instances, batched |
| Commitments | Bought on a guess, or not at all | Bought against measured baseline |
| Change control | Console clicks nobody can replay | Terraform plan in a merge request |
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.
# 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.No hardware, no data-centre relationship, and a launch that does not wait on procurement. Capacity is available the moment you need it.
A bill that grows with success. That is survivable when it is engineered and monitored; it becomes existential when nobody owns it.
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.
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.
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.
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.
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.