How Netflix Uses AWS: Control Plane, CDN and Chaos

Netflix uses AWS for its application services: accounts, recommendations, playback setup, transcoding and data processing. Netflix's own content delivery network, Open Connect, sends the video files to your device. That division explains how Netflix can rely on cloud computing while placing delivery appliances inside internet providers' networks.

This guide follows a playback request through that architecture, then explains the migration, technology stack, screenshot protection, chaos experiments and regional recovery. It also covers why live streaming needs a different delivery pipeline and how to apply the lessons to AWS architecture questions. The central exam decision is when active/active resilience is worth its cost and when warm standby meets the requirement.

How Netflix uses AWS

Netflix's architecture separates application decisions from video delivery. AWS services handle sign-up, sign-in, browsing, recommendations and the work needed to prepare playback. Open Connect Appliances, or OCAs, serve playable files from ISP networks and internet exchange locations, as described in Netflix's Open Connect overview.

You can think of AWS as the membership desk and Open Connect as the distribution network. The desk decides whether you can watch and where your device should get the files; the delivery appliance supplies them. This is a useful way to understand the control plane and delivery plane without assuming that the application stops needing AWS once playback begins.

The 2008 outage and the move

In August 2008, database corruption disrupted Netflix's DVD shipping. Netflix's later migration account described being unable to ship for three days, while contemporary reporting recorded some Wednesday shipments. The incident concerned DVD dispatch, and its retrospective summary should not be read as uninterrupted zero shipping throughout that period.

Netflix attributed the breakdown to faulty hardware, without identifying the component. Its architectural conclusion was that vertically scaled relational databases in its own datacenter created unacceptable single points of failure. It wanted distributed systems that could grow horizontally and continue working when components failed.

AWS offered the scale and breadth of services Netflix wanted; cost savings were a benefit rather than the main motivation. By May 2010, Amazon reported that Netflix was using EC2 and S3 for movie transcoding and storage. Completing the move still required rebuilding the monolith as hundreds of microservices and redesigning data models.

Why billing took longer

Most systems, including customer-facing applications, were in the cloud before 2015. Billing and customer and employee data management came later. The billing migration account describes a shared Oracle database with billions of changing rows and history reaching back to Netflix's 1997 start.

Subscriber data moved to Cassandra, while payment integration used MySQL because charge transactions required ACID guarantees. A comparator checked Cassandra against Oracle country by country and reported mismatches. This illustrates a practical migration lesson: validating the new data is part of the move, alongside deploying the new application.

Billing became fully AWS-based on January 4, 2016. Netflix completed its seven-year streaming systems migration in early January and announced completion on February 12, 2016. On January 6, it expanded into over 130 additional countries, showing why access to expandable infrastructure mattered to the project.

What happens when you press Play

The playback path combines authorization, file selection and delivery steering. Netflix's published overview supports this logical sequence, without exposing a universal order of private API calls for every device:

1. Your device requests playback. It contacts Netflix's playback application running in AWS.
2. Netflix checks permission and selects files. Playback services check authorization and content licensing, then choose versions appropriate for the device and network.
3. Steering finds suitable appliances. File availability, appliance health and network proximity help determine which OCAs can serve the request.
4. The service returns delivery URLs. Your device requests the video files directly from an appliance using those addresses.

Protected playback also involves a DRM license and key exchange through the client's decryption system. That cryptographic exchange is distinct from checking whether your account can watch a title. Netflix hasn't published a fixed call order between DRM licensing and appliance selection.

During playback, the player can select a lower quality when the connection slows. That adaptation helps it respond to changing conditions, though it cannot guarantee uninterrupted viewing. Authorization, licensing and steering remain application responsibilities even though the video files take a different route.

Control plane on AWS vs Open Connect

The split matters because application requests and repeated video delivery solve different problems. Compare the responsibilities directly:

• AWS control plane: account checks, recommendations, playback setup and appliance steering / Open Connect: delivery of the selected playable files.
• AWS playback services: check authorization and licensing, and choose files and appliances / OCAs: store no member information, viewing history or DRM information.
• Cloud processing: prepares video and processes data / Local delivery: places content closer to viewers and reduces upstream traffic.

OCAs send health, route and file-availability information back to AWS, allowing steering to use the state of the delivery network. Their published software stack includes FreeBSD, NGINX and BIRD. Netflix documents these components on its appliance page.

Filling appliances before demand arrives

For on-demand content, Netflix proactively fills appliances during configurable off-peak windows. Popularity predictions help determine which files belong at each location. This does not mean every appliance holds every title or that all locations fill during the same global night.

Netflix's 2016 ISP account used Australia to explain the benefit: files crossed undersea links during quiet hours and were then copied within ISP networks. Repeated local viewing could use those copies. Moving content before demand arrives reduces the need to repeat the same long-distance transfer for each view.

For AWS study, compare the CDN concepts with the edge locations and CloudFront guide. CloudFront is AWS's CDN; Netflix identifies its video delivery network as Open Connect. The comparison helps you understand content placement without substituting CloudFront into Netflix's architecture.

The tech stack

Netflix's publications describe a combination of AWS services, open-source components and internal platforms. These accounts span different years and workloads, so treat them as documented examples rather than a complete inventory of the current fleet. The useful question is what each component does for the application.

Requests, storage and data processing

In 2018, Netflix described Java powering much of its backend and began adopting Spring Boot as its core Java framework. Its accounts from that year describe Zuul handling gateway routing and authentication filters, and Eureka providing service discovery. Netflix's Spring Boot account explains that application framework context.

Cassandra supports Member, Billing, Recommendations and Subscriptions, among other critical applications. A 2024 account describes EVCache providing memcached-based caching. Netflix's Cassandra data movement account also describes Spark-based movement from Cassandra into Iceberg, a separate concern from serving an application request.

In a 2018 account, Keystone combined Kafka messaging with event routing and stream processing, and Netflix has documented Flink processing Kafka events. Iceberg addresses analytic table management in its S3 data lake. According to the AWS Iceberg guide, Netflix created Iceberg in 2017 and contributed it to Apache in 2018.

AWS services and platform lifecycle

Public accounts document EC2 compute, S3 storage, DynamoDB for A/B testing, Elastic Load Balancing and Route 53. Historical accounts also describe Amazon Kinesis Data Streams for network monitoring, EMR processing shared S3 data and SQS messages invalidating cache entries across Regions. These are examples of service selection for particular jobs, rather than evidence that every workload uses the same storage or messaging system.

Relational databases remain part of the picture. A 2025 AWS and Netflix case study reported up to 75% better performance and 28% cost savings after moving the compared relational workloads to Aurora PostgreSQL. Those results apply to those workloads, not the entire Netflix platform.

Titus is Netflix's container platform, with its 2026 batch account describing Kubernetes cells. Spinnaker deploys software, although Netflix's internal fork diverged from open source in 2020. Hystrix is in maintenance mode, and the original public Conductor repository is archived; Netflix nevertheless describes continued internal Conductor development.

Why screenshots go black: DRM

At a 2020 industry panel, a Netflix engineer said the company deploys Google Widevine, Microsoft PlayReady and Apple FairPlay for digital rights management. In browsers, Encrypted Media Extensions provide APIs for protected playback through a content decryption module. EME is an interface, and does not itself guarantee a particular hardware protection implementation.

Widevine L1 keeps keys and decryption in trusted hardware with a protected video path; L3 lacks that protected path. Netflix's Android requirements require L1 for HD on phones and tablets and limit L3 devices to standard definition. That makes DRM capability relevant to picture quality alongside connection speed.

Screenshot protection involves the operating system's treatment of protected pixels. Android's `FLAG_SECURE` can block window screenshots, while secure video surfaces can be excluded from captures. Windows also documents masking protected content before returning a captured image.

Apple's archived FairPlay guidance describes video blackouts in screen recordings and QuickTime captures, with audio requiring separate handling. These platform mechanisms explain why Netflix captures usually show black video, but the exact behavior depends on the device and browser. A black rectangle alone does not identify Netflix's private code path or the DRM system involved.

The display cable is another protection boundary. Netflix specifies HDCP 2.2 or later for HDMI-connected 4K/HDR playback in its quality requirements. Your plan, device, codec, display link and connection all need to qualify for the intended quality.

Chaos engineering

Chaos Monkey randomly disables production instances to expose recovery weaknesses. Netflix had described it by December 2010, and its 2011 Simian Army article explained running experiments during business hours with engineers available. The experiment tests an expectation: losing an instance should not stop the service.

The broader discipline, chaos engineering, uses controlled experiments to build confidence in distributed-system resilience. Netflix expanded its testing beyond instances to zone and Region failure scenarios. Increasing the scope matters because surviving an instance failure does not demonstrate that routing, dependencies and capacity will survive a larger failure.

The April 2011 AWS incident account shows both resilience and unfinished work. Netflix experienced elevated errors and latency during an EBS disruption, but no major external outage; EBS was not its main datastore. Engineers still moved traffic away from the troubled zone manually before evening demand.

That experience motivated automated evacuation, whole-zone drills and multi-Region support. Graceful degradation also mattered: Netflix's early AWS lessons described showing popular titles when personalized recommendations were unavailable. The broader lesson is to test whether useful behavior survives when a dependency cannot provide its usual answer.

Surviving a Region failure

Christmas Eve 2012 exposed the limits of zone redundancy. An AWS maintenance process accidentally deleted load-balancer state, leaving some Netflix application servers healthy but unreachable through the affected load balancers. Netflix's postmortem describes a partial outage, with TV-connected playback in the Americas particularly affected.

A design prepared to lose an Availability Zone still needed protection against a broader regional dependency failure. By December 2013, Netflix documented active/active deployment across us-east-1 and us-west-2: each served users, with data replicated asynchronously. Its 2016 global architecture described evacuation across a deployment also including eu-west-1.

The September 20, 2015 DynamoDB disruption affected more than 20 dependent AWS services, according to Netflix's account. Netflix reported a brief regional availability blip and credited repeated Chaos Kong exercises with preparing traffic failover that avoided significant member impact. That is a dated example of successful preparation, not a promise that AWS outages cannot affect Netflix.

Capacity must be ready to receive traffic

Routing traffic elsewhere only helps when the receiving services can handle it. In its 2018 Project Nimble account, Netflix said evacuation had taken about 50 minutes, including roughly 25 minutes waiting for services to start. Nimble maintained pre-warmed, hidden instances in shadow Auto Scaling groups.

Netflix reported evacuation in under 10 minutes while keeping that change cost-neutral. This is the reported 2018 result, not a current recovery guarantee. It shows why startup readiness belongs in a recovery design alongside routing and replication.

The 2024 NFX301 presentation showed four active Regions: us-east-1, us-east-2, us-west-2 and eu-west-1. Its scaling-response improvement from approximately 20 to three minutes measures a different operation from regional evacuation. Keep the operation and date attached whenever you use an architecture's timing claim.

The big live night

On November 15, 2024, Netflix streamed Jake Paul versus Mike Tyson live. Netflix's overnight figures reported a peak of 65 million concurrent streams. Viewers also reported frozen pictures, buffering and crashes, as covered in reporting on Netflix's response.

Live footage cannot be placed on appliances the previous night. New segments require a live ingest and origin pipeline as the event unfolds. Netflix's accounts don't give the fight's technical root cause, so this guide doesn't diagnose it.

Netflix's July 2025 live architecture account described restarts multiplying traffic tenfold. It explained server-guided retry backoff and shedding lower-priority work first, alongside synthetic tests capable of up to 100,000 playback starts per second. Those are documented reliability measures, not proof that retries caused the fight's buffering.

The live operations retrospective also described over 300 people online for the fight and coordination difficulties across Slack and Zoom. Netflix subsequently organized squads with explicit roles, focused communication and an escalation path into a permanent Live Command Center. Reliability at this scale includes the way people coordinate recovery as well as the infrastructure they operate.

Platform engineering

Netflix describes platforms for cloud infrastructure, development, data, experimentation and AI. Its paved road provides tools and practices supported by central teams, with adoption encouraged through a better development experience. In the full-cycle development model, the team building a service also deploys, operates and supports it.

Netflix's Edge Engineering account connects that ownership to fewer developer-to-operations handoffs. By 2018, deployments had become routine and frequent, while canary checks took hours instead of days. Netflix also acknowledged the added cognitive load, which explains the value of supported platform tools.

Durable cloud operations provide another example. Netflix's December 2025 Temporal account reported transient cloud-operation deployment failures falling from 4% to 0.0001% after adoption. That metric concerns a specific deployment failure mode, rather than streaming availability or every possible deployment failure.

What this teaches for AWS exams

The Solutions Architect Associate certification tests your ability to match architecture to requirements. Netflix provides examples of fault tolerance, data choices and delivery design, but its implementation cannot determine the answer to a different business's problem. AWS's resilient architectures domain includes architectures across Regions and Availability Zones.

Start by identifying the failure scope, acceptable interruption, acceptable data loss and cost constraint. Recovery time objective, or RTO, concerns how quickly service must return; recovery point objective, or RPO, concerns how much data loss is acceptable. The disaster recovery strategies guide develops those tradeoffs across recovery approaches.

For broader architecture exercises, use the system design interview questions guide to practice explaining why components belong in a design. In this case, the useful explanation connects local delivery to repeated reads, pre-warmed capacity to recovery time and controlled experiments to confidence in failure handling. Each mechanism answers a particular requirement.

AWS exam traps

Warm standby vs active/active

A practice question on warm standby disaster recovery requires a payments service to return within five minutes, tolerate at most one minute of lost transactions and avoid another Region at full production capacity. Warm standby fits because a scaled-down, functional copy already runs, fed by an Aurora global database. It can serve after failover and then scale, without assuming a zero-interruption recovery.

• Warm standby: the application is running at reduced capacity / Pilot light: the recovery application needs additional startup or deployment work.
• Warm standby: matches this scenario's reduced-capacity budget / Full-capacity active/active: meets the recovery targets but violates its spending constraint.

The pilot-light option leaves the application tier undeployed, making it unsuitable for this scenario's recovery target. AWS's disaster recovery guidance explains the strategies by what is already running and what recovery still requires.

Routing and replacement need health signals

An idle secondary Region suggests active/passive routing. A practice question on Route 53 failover routing tests why weights without health checks cannot automatically detect primary failure. AWS's routing documentation distinguishes failover policies from active/active configurations.

Removing an unhealthy target from traffic and replacing its instance are separate actions. In a practice question on Auto Scaling application health, the operating system remains healthy while the application stops responding. Auto Scaling needs the load balancer's health verdict to replace that instance; EC2 status checks alone miss the application failure.

Active/active does not specify data consistency

Serving writes in multiple Regions leaves a consistency decision to make. A practice question on DynamoDB global-table consistency tests why local conditional writes cannot remove conflicts from asynchronous replication. AWS documents eventual and strong consistency modes with different replication and topology requirements; this comparison makes no claim about Netflix using global tables for member history.

Edge capacity cannot repair a fragmented cache

Content reuse depends on identifying requests that can share a cached response. A practice question on CloudFront cache hit ratio shows how an irrelevant visitor-specific query parameter can fragment the cache key. Excluding that parameter permits reuse; adding edge locations leaves the key problem intact.

Use the SAA-C03 practice question collection to apply these distinctions to different requirements. For each scenario, identify whether the missing mechanism concerns routing, replacement, readiness, consistency or caching. That makes the answer depend on the described failure and constraints.

Frequently asked questions

Does Netflix use AWS for everything?

Netflix uses AWS for its application services, including account handling, recommendations and playback setup. Its own Open Connect network delivers the video files from appliances in ISP networks and at internet exchanges.

Does Netflix store video on AWS?

An Amazon announcement from May 2010 described Netflix using EC2 and S3 to transcode and store its movies. Storage and preparation are separate from delivering playable files to viewers through Open Connect.

What is Netflix Open Connect?

Open Connect is Netflix's content delivery network. It places playable files on appliances close to viewers, uses off-peak fills for on-demand content and works with AWS-based playback steering.

Why does Netflix shut down its own servers?

Chaos experiments test whether the application survives failures it is designed to tolerate. Chaos Monkey targets instances, while broader exercises test larger failure scopes under controlled conditions.

How does Netflix survive an AWS Region failure?

Netflix's published designs combine active Regions, replicated data, traffic evacuation and capacity preparation. Rehearsals help expose weaknesses, but reported successes and timings belong to their specific incidents and engineering accounts.

Watch the full episode

The conversation makes the tradeoffs easier to follow by testing each explanation against follow-up questions, from playback steering to the warm standby decision. Hear how the ideas connect in Why Netflix Shuts Down Its Own Servers On Purpose on YouTube.