Learn
Image Delivery at the Edge: WebP, AVIF and Responsive Sizes
An image CDN should serve AVIF to the roughly 93–95% of browsers that decode it as of 2026, WebP to most of the rest, ...
A single Open Connect Appliance sitting in a regional ISP's aggregation site can push more than 100 Gbps of video while its upstream transit port stays almost idle. That inversion is the entire point of Netflix Open Connect: the expensive part of video delivery is not the bytes, it is the distance they travel across networks you do not control. As of 2026, Netflix still moves roughly 15% of global downstream internet traffic, and in some North American access networks it crosses 30% during evening peak. Nearly all of it is served from hardware Netflix built, shipped, and racked inside the ISP.
This article breaks down the Netflix content delivery network as an engineering system: appliance hardware and storage tiers, how content gets placed before anyone asks for it, the steering layer, peering versus transit economics, and the failure modes that show up in production. It closes with a threshold model for the decision every architect eventually faces — build delivery infrastructure, or buy it.

Netflix Open Connect is not one network. It is three concentric delivery tiers with different economics and different fill behaviour.
Deployment as of 2026 spans thousands of embedded locations across more than 100 countries. The design constraint is unusual and worth naming: Netflix's catalogue is write-once, read-many, with demand that is predictable days in advance. That is what makes the whole model tractable. A general-purpose CDN cannot pre-position content it has never seen.
Current-generation storage OCAs reach into the mid-hundreds of terabytes of NVMe capacity in a 2U chassis, with PCIe 5.0 lanes removing the bus bottleneck that limited earlier flash designs. Netflix has published extensively on pushing FreeBSD-based servers past 100 Gbps of TLS-encrypted video from a single box; the hard parts were never disk throughput but kernel-level TLS offload, NUMA-aware buffer placement, and avoiding cross-socket memory traffic.
Two appliance classes exist for a reason. Storage-dense units hold the long tail. Throughput-optimised units hold the top few thousand titles that account for the bulk of playback hours and serve them from a smaller, hotter working set. A large embedded cluster runs both, with the steering layer deciding which class answers a given manifest request.
Open Connect fills during off-peak hours, typically a local overnight window negotiated with the ISP. Netflix ranks titles per region using viewing history, recommendation signals, release calendars, and time-of-day demand curves, then pushes deltas to each appliance. A new season lands on the appliance before the release timestamp, not after the first viewer requests it.
This is the structural difference between Open Connect and a pull-through CDN. A conventional edge cache takes a miss on every cold object and pays an origin round trip. Open Connect aims for a cold-miss rate near zero on popular content, which is why ISPs see offload ratios well above 90% on mature embedded clusters. The cost is that Netflix must be right about what people will watch — an ML prediction problem, not a caching problem.
The reason ISPs hand over rack space for free is arithmetic. IP transit in competitive metros has fallen to roughly $0.05 to $0.15 per Mbps per month at 100G commit levels as of 2026, with higher figures in Latin America, Africa, and parts of Asia-Pacific where capacity is thinner. An ISP carrying 200 Gbps of evening-peak Netflix traffic over transit is paying real money every month for bytes that an embedded appliance would deliver for the cost of power and a few U of rack.
The secondary benefits matter to network teams more than the invoice does:
Settlement-free interconnection is the legal frame, but the engineering frame is simpler: put the bytes behind the congestion point. Every serious CDN peering strategy, including commercial ones, is a variation on this theme. The difference is that Netflix owns both ends of the connection and can therefore tune the whole path.
This is the section most Open Connect explainers skip. A delivery network's architecture is best understood through what happens when parts of it stop working.
| Failure | System response | Viewer impact |
|---|---|---|
| Single NVMe drive failure | Affected object ranges marked unavailable; re-fetched in next fill window | None; other appliances in cluster cover |
| Appliance offline | Removed from steering candidate list within seconds of health-check failure | Mid-stream clients re-request next segment from ranked alternate |
| Control-plane unreachable from OCA | Appliance keeps serving cached content autonomously; no fill, no catalogue update | Existing titles play; new releases missing until restored |
| Whole embedded cluster loses power | Steering shifts region to IXP tier over peering | Higher RTT, possible bitrate ladder step-down at peak |
| Steering service degradation | Clients fall back to last-known-good ranked list cached locally | Stale routing; uneven load until recovery |
The design principle underneath all of this: the data plane must survive the control plane. An appliance that cannot reach Netflix should still serve every byte it already holds. Any delivery architecture that hard-fails when its orchestration layer blinks has a single point of failure disguised as a microservice.
The second principle is client-side agency. Netflix clients hold a ranked endpoint list and fail over at the segment boundary. Failover happens in the player, on a segment-duration timescale, without waiting for DNS TTLs or anycast reconvergence. That is a pattern worth stealing regardless of what CDN you use.
Open Connect is often cited as proof that serious companies build their own CDN. It proves something narrower. It works because four conditions hold simultaneously, and if you break any one of them the economics collapse.
Miss condition three or four, and building is a way to spend engineering years reproducing something you could rent. For media platforms, game publishers distributing multi-gigabyte patches, and SaaS vendors shipping binaries, the correct answer is almost always a commercial CDN or a multi-CDN mix with hard failover — the same client-side pattern Netflix uses, applied across vendors.
The high-volume CDN market has a real competitive set: Bunny.net and KeyCDN compete hard on simplicity and per-GB price, CDN77 and Medianova are credible in European media delivery, Gcore has strong reach in emerging markets, and Fastly remains the default when you need programmable edge logic on live streams. Each has genuine strengths; none of them is free.
For volume-heavy workloads, BlazingCDN's media delivery platform runs NVMe SSD edge storage with pricing that starts at $5 per TB ($0.005 per GB) and scales down under commitment: $350/month covers 100 TB with additional gigabytes at $0.0035, $1,500/month covers 500 TB at $0.003, and $4,000/month covers 2,000 TB with overage at $0.002 per GB — $2 per TB at petabyte scale. It delivers stability and fault tolerance comparable to Amazon CloudFront at a materially lower cost per terabyte, with 100% uptime, flexible per-property configuration, and fast scaling when a release event triples your egress overnight.
Run the arithmetic against your own numbers. At 500 TB/month, the difference between $0.003 and $0.02 per GB is roughly $8,500 a month. At 2 PB, the gap funds an entire platform team. That comparison, not appliance envy, is what should drive the build-versus-buy call. Onboarding typically takes about an hour, which makes a parallel A/B test against your incumbent cheap to run.
No. Open Connect operates on settlement-free interconnection: Netflix supplies and maintains the appliance, the ISP supplies rack space, power, and connectivity. Both sides benefit — the ISP avoids transit costs on a large slice of peak traffic, and Netflix gains a shorter path to viewers.
Current storage-class appliances hold into the mid-hundreds of terabytes on NVMe as of 2026. That is not the full global catalogue. Each appliance carries a regionally predicted subset, refreshed during nightly fill windows based on local viewing patterns and upcoming releases.
It keeps serving whatever it has cached. The control plane and data plane are separated deliberately, so a management-path outage degrades freshness rather than availability. New titles and catalogue updates stall until connectivity returns.
Technically yes, economically rarely. The model requires tens of petabytes of monthly volume, forecastable demand, enough traffic share that ISPs want you embedded, and a permanent hardware-and-peering team. Below those thresholds a commercial or multi-CDN approach wins on total cost.
Live bypasses pre-fill entirely and uses real-time distribution paths with shielded origins, targeting sub-four-second glass-to-glass latency as of 2026. It is the one Netflix workload that behaves like a conventional CDN, which is why live has different capacity planning from catalogue delivery.
A cache one AS hop away across congested transit performs worse than a cache inside the access network, regardless of how many locations a provider advertises. Measure the path, not the map: RTT to real clients and cache-hit ratio at peak hour tell you more than a PoP number.
Pull your delivery logs for the last 30 days and compute three things. First, cache-hit ratio segmented by hour of day, not averaged — your peak-hour number is the only one that matters. Second, the p95 RTT from edge to client per major ASN, which exposes where your provider is riding transit instead of peering. Third, your actual blended cost per delivered terabyte including origin egress, which is usually higher than the rate card suggests.
Then test the failover pattern Netflix relies on: can your player switch delivery hosts at a segment boundary without a rebuffer? If the answer is no, that is a bigger availability risk than anything in your provider's SLA. What offload ratio are you seeing at peak, and how does it change when a major release lands?
Heavy traffic.
Light bill.
The CDN for video and large traffic
Learn
An image CDN should serve AVIF to the roughly 93–95% of browsers that decode it as of 2026, WebP to most of the rest, ...
Compare
Fastest CDN in 2026: Fastly vs Akamai vs Cloudflare vs AWS On November 18, 2025, a malformed bot-management feature ...
Learn
A CDN cache key is the tuple the edge hashes to decide hit or miss, and on most platforms the default is scheme, host, ...