Netflix Open Connect: How Netflix Delivers Video to ISPs

Netflix Open Connect in 2026: The ISP-Embedded CDN Playbook

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.

image-2

How Netflix Open Connect works: the three-tier topology

Netflix Open Connect is not one network. It is three concentric delivery tiers with different economics and different fill behaviour.

  • Embedded OCAs. Appliances physically inside ISP facilities. The ISP supplies rack space, power, and a BGP session; Netflix supplies and remotely operates the hardware. Traffic never touches paid transit.
  • IXP and peering-site OCAs. Netflix-operated clusters at internet exchanges and in its own colocation footprint, reachable over settlement-free peering. These serve ISPs too small or too unwilling to embed, and act as the fallback tier for embedded sites.
  • Fill sources and origin. Cloud-hosted control plane and storage that the appliances pull from during fill windows. Clients essentially never talk to this tier directly.

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.

Appliance hardware and storage tiering in 2026

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.

The fill window: why nothing is fetched on demand

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.

ISP peering vs transit: the money argument

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:

  • Peak-hour transit headroom freed for traffic that cannot be cached.
  • Shorter RTT to the client, which lifts congestion-window growth and reduces rebuffer rates on the last mile.
  • Predictable capacity planning, because fill happens on a schedule the ISP agreed to.

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.

What changed in 2025 and 2026

  • AV1 at scale. Broad AV1 deployment across TV and mobile clients cuts bitrate roughly 20–30% versus older codecs at matched quality. That is less transit for ISPs and more titles per terabyte of NVMe.
  • QUIC as a default path. Connection migration across Wi-Fi and cellular handoffs, plus faster loss recovery on congested access networks, with a measurable reduction in playback start failures on mobile.
  • Live delivery paths. Live events bypass the pre-fill model entirely and run over real-time distribution trees with sub-four-second glass-to-glass targets. This is the one workload where Open Connect behaves like a conventional CDN with an origin shield.
  • Denser appliances. Gen5 NVMe raises per-rack-unit capacity, which matters most in space-constrained ISP sites in dense urban markets.

Failure modes: how Open Connect breaks in production

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.

FailureSystem responseViewer impact
Single NVMe drive failureAffected object ranges marked unavailable; re-fetched in next fill windowNone; other appliances in cluster cover
Appliance offlineRemoved from steering candidate list within seconds of health-check failureMid-stream clients re-request next segment from ranked alternate
Control-plane unreachable from OCAAppliance keeps serving cached content autonomously; no fill, no catalogue updateExisting titles play; new releases missing until restored
Whole embedded cluster loses powerSteering shifts region to IXP tier over peeringHigher RTT, possible bitrate ladder step-down at peak
Steering service degradationClients fall back to last-known-good ranked list cached locallyStale 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.

Build or buy delivery: the threshold model

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.

  1. Volume. Sustained delivery in the tens of petabytes per month or higher. Below roughly 5 PB/month, commercial CDN pricing beats amortised hardware plus headcount.
  2. Predictability. A catalogue whose demand you can forecast days ahead. Bursty, long-tail, or user-generated traffic defeats pre-fill.
  3. Leverage. Enough share of an ISP's peak traffic that the ISP wants you embedded. A workload at 0.3% of peak gets no rack space.
  4. Headcount. A standing team for hardware logistics, kernel and userspace tuning, RMA flows, and peering negotiations in every market. This is dozens of engineers, not a squad.

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.

Where cost-per-TB actually lands in 2026

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.

FAQ

Does Netflix pay ISPs for Open Connect placement?

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.

How much content does a single Open Connect Appliance hold?

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.

What happens when an Open Connect Appliance loses contact with Netflix?

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.

Can a company build something like the Netflix content delivery network?

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.

How does Open Connect handle live events?

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.

Why does ISP peering matter more than raw edge count?

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.

What to measure this week

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