CONCEPT Cited by 1 source
Hybrid cloud media ingest¶
Hybrid cloud media ingest is the infrastructure shape of placing high-bandwidth ingest capacity physically close to production sites while using a large cloud provider as the durable storage + compute substrate. The edge and the cloud are bridged by a dedicated content-delivery backbone so media moves from drive to durable archive "in a matter of hours" without physical shipping.
Shape¶
Production site (drive)
│
▼
Regional ingest centre ← edge compute + high-speed uplink
│ (drive validation, checksums, proxy gen)
▼
Content-delivery backbone ← CDN-class transit between edge and cloud
│
▼
Cloud storage + compute ← durable substrate; also hosts apps
that serve the library to all downstream
consumers
Three load-bearing properties:
- Edge is close to source — ingest centres are placed in production markets so the physical-media-to-cloud step is local, cheap, and fast.
- Backbone is bandwidth-optimised — CDN-class transit handles the edge → cloud fill; the ingest path is not on the public internet at scale.
- Cloud is the asset namespace — once media is in the cloud library, every downstream consumer (editorial, VFX, DI, archive) reads from it without additional physical movement. See patterns/centralized-cloud-media-library for the application-layer counterpart.
Canonical wiki instance — Netflix MPS (2025-04-01)¶
Netflix's Media Production Suite is the first wiki example:
- Edge: Netflix ingest centres — rolling out globally in production markets. Drives are plugged in, validated, and uploaded "within a matter of hours."
- Backbone: Open Connect, Netflix's CDN, carrying ingest-centre → AWS traffic.
- Cloud: AWS as the durable substrate holding the Media Library + running the seven MPS tools (Dailies, VFX Pulls, Conform Pulls, Remote Workstations, Media Downloader, plus the Library and Footage Ingest service-side logic).
The design target: per-title OCF of ~200 TB average / up to ~700 TB outliers, across hundreds of titles per year. Traditional LTO-tape + hand-carried-drive workflows don't scale at those numbers, and structurally exclude emerging-market productions without local post facilities.
Why hybrid vs. pure-cloud?¶
Pure-cloud upload from a production site would require every production location to have the uplink bandwidth and reliability to move 200–700 TB per title over the public internet. Most locations don't. Hybrid cloud solves this by:
- Guaranteeing uplink at controlled ingest centres (Netflix can provision connectivity itself instead of depending on third-party production-site internet).
- Decoupling production schedule from upload schedule — drives are shipped to the nearest ingest centre on the normal logistics pipeline; centres then move bits to cloud continuously on fat pipes.
- Allowing standards-based validation at the edge — ASC MHL checksum + drive-manifest verification runs before bits leave the ingest centre, catching integrity failures locally rather than after full cloud upload.
Why hybrid vs. pure-edge?¶
Pure edge (LTO tape, on-prem storage per vendor, hand-carried hard drives) is the legacy baseline the approach replaces. It doesn't support:
- Cross-region collaboration (media is not addressable from anywhere).
- Automated downstream pipelines (VFX Pulls, Conform Pulls, Remote Workstations) that need the cloud namespace.
- Global standards-driven automation — every vendor has bespoke hot-folder scripts.
Generalisation¶
The pattern is not specific to film production. Any workflow that generates large volumes of high-value data at geographically distributed sources and needs cloud-addressable downstream access can be structured this way:
- Scientific instruments (genomics sequencers, telescopes) → regional ingest facilities → cloud compute.
- Autonomous-vehicle fleets (see patterns/resilient-edge-uploader + concepts/edge-cloud-data-flywheel for Instacart Caper's variant).
- Film / TV production (Netflix MPS — this page).
Differences with Instacart's edge-cloud flywheel: Caper uploads are over cellular backhaul directly from the robot; Netflix MPS uses dedicated ingest facilities because the payload size per session (TBs per camera card) dwarfs what a cellular or normal office uplink can handle. Both share the cloud namespace + downstream-automation thesis.
Seen in¶
- sources/2025-04-01-netflix-globalizing-productions-with-netflixs-media-production-suite — canonical instance. Netflix + Open Connect + AWS.
Related¶
- Substrate systems: systems/netflix-media-production-suite · systems/netflix-open-connect · systems/netflix-footage-ingest
- Application pattern: patterns/centralized-cloud-media-library
- Adjacent edge-cloud shape: patterns/resilient-edge-uploader · concepts/edge-cloud-data-flywheel
- Company: companies/netflix