Netflix has added single-tenant Titus, a mode that runs one task alone on its own right-sized EC2 instance. The Compute/Platform team still owns and patches the host, so application teams keep the same API and deployment path. First adopters include stateful, high-throughput streaming workloads. Here, a neighbor's interference can lead to minutes of checkpoint recovery.
Titus launches millions of containers a week across tens of thousands of EC2 instances and is multi-tenant by default. Netflix says that cgroups, seccomp, the iocost controller, and traffic shaping can’t split shared hardware. This includes resources like the last-level cache and memory bandwidth. Its HTB traffic shaper also takes a global lock. A container that floods the host with small packets can burn the kernel CPU and starve its neighbors. Predictive CPU pinning and eBPF-based detection helped, but Netflix concluded that shared-kernel tuning narrows the gap without closing it.
Netflix rejected the alternatives for specific reasons. MicroVMs such as Firecracker and Kata need bare-metal or nested virtualization, and nested virtualization was not ready on Netflix's instance types. They also meant running a hypervisor layer, added virtualization overhead, and lacked GPU support. gVisor added overhead on I/O-heavy paths, and a single vendor does most of its maintenance. Running containers on EC2 would hand host patching and fleet sizing back to application teams. Netflix argues that these workloads require performance isolation, not defense against hostile tenants.
The Titus federation layer does most of the work. An allowlist, maintained by the Compute/Platform team, controls eligibility and federation records, which instance families a task may use. The autoscaler launches the smallest instance that fits the task's CPU, memory, and GPU request. Pod anti-affinity, a non-preemptible priority class, and a node taint enforce one task per node. Netflix disables defragmentation, so nothing relocates the task. To measure isolation, Netflix runs a reference app alone, then beside a "havoc" container, and scores retained throughput and P99 latency. The post publishes no scores.
Launch latency is the main cost. A fresh instance needs tens of seconds to boot before the image pull begins. Warm pools help less than on the shared fleet, because right-sizing produces many instance shapes. Netflix keeps a small warm pool for the most latency-sensitive starts and limits the available sizes. It dropped metal instances for these pools. Disabling Kubernetes preemption removed a scheduling bottleneck that left new nodes idle. Lazy image pulling (stargz, SOCI) and CRIU checkpoint restore are longer-term fixes.
Efficiency can improve. Moving sensitive workloads off shared hosts removes the anti-affinity spreading and disruption budgets that left those hosts partly empty. Fixed overhead from sidecars and system services pulls the other way. Netflix says it can cost a small instance tens of percent of its resources, and the largest shapes only a couple of percent. Discrete EC2 sizes also leave bin-packing gaps on large shared hosts, which favored right-sizing in practice.
Early users include managed Apache Flink, streaming data connectors, and telemetry and logging pipelines. Then, there are some latency-sensitive GraphQL and edge services. The rollout continues. For the shared fleet, Netflix is working on eBPF-based Expected Departure Time shaping to replace HTB, plus cache and memory-bandwidth partitioning (Intel RDT, AMD PQoS), NVIDIA MIG, and the cgroup v2 IO controller. Its long-term goal is one Compute API that picks EC2 or Titus placement from declared intent.
Single-tenant Titus joins a broader set of approaches to the same problem. Instance-per-Pod Webhook, an open-source project from NTT’s Akihiro Suda, uses a Kubernetes admission webhook and the Cluster Autoscaler to create a tainted, dedicated instance for each pod. AWS Fargate makes the pod the unit of infrastructure, so customers do not create, patch, or scale worker nodes. GKE offers sole-tenant nodes, dedicated physical servers that run only a single project’s VMs, along with GKE Sandbox, which runs each pod in its own Kata Containers microVM. Azure’s Pod Sandboxing is also built on Kata and gives each pod its own lightweight VM, isolated from other pod VMs and the host kernel. Most of these target security isolation from untrusted code, while Netflix’s post focuses on performance isolation between trusted internal teams.
Teams running shared Kubernetes platforms can borrow the pattern: dedicated node pools with taints, anti-affinity, and repacking turned off. Netflix recommends it for large, long-running, disruption-sensitive workloads sized close to a node shape and not for small or bursty services. The allowlist keeps the mode from eroding multi-tenant density.