Where the cloud and owned boundary belongs

The hybrid pattern gets described as a compromise between two options. It is the result of asking one question per tier: does elasticity earn its price here? Then following the answer, even when it splits the platform.

Two workloads wearing one invoice

Control traffic and media traffic look like the same system from the outside and behave like opposites underneath.

Public cloud prices spiky, low-volume, latency-sensitive work well, and that is the control tier. It prices steady, enormous, undifferentiated work badly, and that is the media tier.

What sits where

• AWS: catalogue and search, authentication and entitlements, billing, the transactional database. Small payloads, real elasticity, and a cost that stays in the noise.
• Your own servers: GPU encoding, the S3-compatible origin, and the delivery edge. Capital already spent instead of a charge that runs.
• Both: one Terraform configuration and one pipeline.

That last line is the reason this is viable at all. Two environments operated separately is two operating models, and most teams never try it for that reason. Two environments declared in the same repository and shipped by the same merge request is one workflow with more hardware in it.

The failure mode we designed for

If AWS is unreachable, sign-in and catalogue browsing degrade. Playback of already-authorised sessions continues from your edge, because the token the edge checks was issued before the outage and has a deliberate lifetime.

When it is the wrong answer

If your traffic is truly global and truly unpredictable, owned capacity in one region is a physics problem you cannot software your way out of. With no rack and no intention of having one, the cloud-native pattern with its cost controls designed in is the better recommendation, and we will say so.