How Peloton Engineers the World’s Largest Live Fitness Events on AWS

Inside the cloud architecture powering Turkey Burn and what two consecutive zero-incident events actually took.

Every Thanksgiving, tens of thousands of Peloton Members log on for Turkey Burn, a community tradition that has grown into one of the most technically demanding real-time workloads in the fitness industry. In 2024 and 2025, that engineering foundation held flawlessly: two consecutive events, zero major incidents. This builds on a 2023 Guinness World Record that saw 27,556 simultaneous participants in a single cycling class. Behind those results is a sophisticated cloud architecture on AWS, shaped by years of rigorous engineering, deep partnership between Peloton and AWS teams, and a relentless commitment to continuous improvement.

The Thundering Herd: Peloton’s Hardest Engineering Problem

Live fitness events create a traffic pattern fundamentally different from typical web traffic: they don’t ramp up gradually. Tens of thousands of participants connect at exactly the same scheduled moment, a phenomenon Peloton’s engineering team calls the “thundering traffic herd”.

Figure1: System load profile for Peloton’s 2025 Turkey Burn, showing “thundering herd” periods at class start times’

Turkey Burn spans Ride, Run, Row, and Strength, with classes lasting 20 to 45 minutes. Any technical issue causing even seconds of delay at class starts can result in participant abandonment. Members either connect and work out, or they don’t.

This constraint drives two of Peloton’s core engineering principles: pre-warm everything and degrade gracefully. All traffic is segmented into tier-0 (T0) and non-tier-0 categories; critical services like the leaderboard, video streaming, and authentication receive isolated, protected infrastructure. The team regularly injects faults into non-T0 services to verify that lower-priority failures don’t cascade into critical paths.

Figure 2: K8s Representation of Tier0 vs Non-Tier0 Endpoint Connection Management in core API monolith

KEY INSIGHT: “Pre-warming and pre-scaling infrastructure is not optional, it is a key foundation of the entire event strategy.” – Alex Niderberg, Director of Engineering at Peloton.

An Engineering Program Built for Continuous Improvement

Preparation follows two parallel tracks: reliable scalability (maximum concurrent Members the platform can handle) and failure containment (if something breaks on the critical path, can Members still work out?). Peloton has invested heavily in both dimensions over the years which has directly reflected in the clean operational records of 2024 and 2025.

To ensure system stability, Peloton employs custom-engineered anomaly detection and mitigation protocols. These are vital tools during the Turkey Burn peak. The system actively monitors database query patterns, proactively isolating problematic queries that could disrupt the join process or in-class experience. To further minimize risk during high-concurrency windows, the platform can pause non-essential features. Additionally, comprehensive fault injection testing is applied throughout the class lifecycle, allowing the team to identify and resolve potential issues well before the event begins.

Architecture Overview: Multi-cluster, Multi-AZ by Design

Peloton’s production infrastructure runs on Amazon EKS across a multi-cluster, multi-availability-zone architecture. Multiple EKS clusters per environment are connected through an Istio service mesh enabling inter-cluster communication. Traffic is distributed using Network Load Balancers (NLBs) and the Istio mesh for high-throughput, low-latency connections. During Turkey Burn 2025, the service mesh processed 7.27 billion requests with a peak of 452,000 requests per second.

Figure 3: Traffic routing from members traffic to Peloton’s Multi-Cluster architecture, driving resiliency across clusters and availability zones (not pictured)

Core AWS Services in Action

Real-Time Leaderboard and Event Streaming

The live leaderboard must synchronize rankings across tens of thousands of concurrent participants with sub-second latency. Peloton powers this through: Amazon MSK for high-throughput event streaming and fan-out; Amazon SQS to decouple services under variable load; Amazon ElastiCache with replica configurations for high-availability caching / power leaderboard rankings using sorted sets; and Amazon OpenSearch Service for real-time filtering, pre-scaled before each event. Before every Turkey Burn, Peloton and AWS teams collaborate to tune connection limits and confirm ingestion pipelines can absorb instantaneous traffic surges.

Database Layer: Resilience Under Extreme Load

Peloton relies on Amazon RDS for relational workloads, proactively scaled before live events. At peak, PgBouncer, a connection pooler for PostgreSQL, handles a peak of ~174,000 queries per second. GateKeeper detects queries exhibiting increasing latency and re-routes them to a reserved pool with a 2-second timeout, preserving T0 service quality. GateKeeper made its first live activation during Turkey Burn 2024, transparently protecting the member experience without any participant awareness. For high-throughput key-value workloads, Amazon DynamoDB read/write throughput is scaled up ahead of each event.

Container Orchestration: Karpenter and Custom Pre-Warming

Peloton adopted Karpenter for node provisioning across 90% of production workloads, enabling instance type diversification and dynamic right-sizing that delivers an estimated 10–20% annual savings on EKS compute. A custom Node Scaler service pre-warms cluster capacity before live traffic arrives, absorbing rapid concurrency spikes without cold-start latency penalties. Peloton also secures Future-Dated On-Demand Capacity Reservations (ODCR) for EC2 instances in specific Availability Zones, ensuring critical capacity is reserved precisely when needed.

Production Load Testing: The Unconventional Secret Weapon

Most organizations at this scale maintain a dedicated performance environment to mirror production. Peloton took a different approach: they load-test directly in production, at volumes up to 2.5x anticipated peak traffic monthly all year, scaling to multiple times per week ahead of Turkey Burn. This surfaces bottlenecks that would never appear in a simulated environment. Their internally built tooling for rapid scaling (AutoLift) that scales replica counts across services, driving scaling of the underlying EC2 nodes and automatically provisions additional DynamoDB RCU capacity, allowing for simulating event-level concurrency without approximations and without impacting other production workloads. Every test is monitored in real time; if latency or error rates climb, the run is short-circuited immediately. Eliminating the dedicated performance testing environment contributed to a 40% reduction in the cost of executing Turkey Burn compared to previous years.

KEY INSIGHT: “Production load testing, with the right tooling and monitoring, delivers more accurate signals at a fraction of the cost of a dedicated performance environment.” – Taq Karim, Senior Director of Engineering at Peloton.

Cost Visibility as an Engineering Discipline

At Peloton, scale and efficiency go hand in hand. They view cost optimization not as a periodic accounting exercise, but as a core engineering discipline. By embedding cost management directly into their operational culture, their teams treat cost anomalies with the same urgency as latency spikes or system outages.

This deep-rooted culture of full-stack ownership ensures that maintaining high availability and managing cloud spend are dual responsibilities for every engineering team.

The Mechanism: Weekly Metrics and Mutual Accountability

To operationalize this philosophy, Peloton utilizes a decentralized ownership model supported by rigorous, centralized governance:

• End-to-End Ownership: Dedicated engineering teams are fully accountable for the performance, reliability, and cost of their respective services.

• The Weekly Ops Review: They host a weekly, cross-departmental forum to review critical operational and financial metrics.

• On-Call Representation: The on-call engineer for each service represents their team at this review. If a cost anomaly occurs, the on-call engineer investigates and remediates it using the same incident response workflows applied to performance degradation.

This transparent environment fosters cross-team collaboration, accelerates collective learning, and drives continuous operational optimization.

Data-Driven Impact: Optimizing EKS and Inter-AZ Data Transfer

This culture of continuous monitoring allowed them to pinpoint and act on granular optimization opportunities quickly. Deep-dive analysis identified that Amazon Elastic Kubernetes Service (Amazon EKS) nodes were the primary driver of their inter-Availability Zone (inter-AZ) data transfer costs. Armed with this data, their engineering teams designed and executed targeted architectural changes to localize traffic.

The result was a significant reduction in operational spend, without sacrificing system resilience.

KEY INSIGHT: “Our team is driven by a culture of Quality, Ownership and Resiliency. We measure everything and review trends as a team weekly to ensure transparency and continuous improvement whilst sharing lessons learned in a blameless environment.” – Francis Shanahan, Chief Technology Officer at Peloton.

Results: Engineering At Global Scale

• 34.6K – Simultaneous participants in the 2025 Turkey Burn Ride, surpassing the Guinness World Record Peloton set in 2023.

• 0 – Major incidents across Turkey Burn 2024 and Turkey Burn 2025.

• ~174K queries/sec – Handled by PgBouncer at peak

• 200M+ requests to leaderboard

• 1.2B+ requests processed by Token-Exchange (peak 78.64K RPS)

• 2.5B+ requests served at the edge across three primary zones

• 7.27B total requests served by the Istio service mesh (peak 452K RPS)

The Turkey Burn architecture demonstrates that at massive scale, performance and cost discipline are not competing priorities, they are complementary ones. The same investments in right-sizing, intelligent autoscaling, and proactive capacity planning that reduce costs also reduce the risk surface for live events.

Ready To Architect for your Next Peak Event?

Whether you’re engineering for a scheduled live event, a product launch, or unpredictable viral traffic, the architectural patterns Peloton has refined for Turkey Burn apply broadly to any high-concurrency, latency-sensitive workload. Contact your AWS Account Team to learn how AWS Services, Karpenter, EC2 Capacity Reservations, and the broader AWS ecosystem can help you deliver seamless experiences at any scale while keeping costs optimized.

About Peloton

Peloton (NASDAQ: PTON) delivers integrated fitness and wellness experiences to Members around the world through purpose-built hardware, immersive software, and a community-driven platform. Peloton’s engineering team operates one of the most demanding real-time cloud workloads in the fitness industry, processing billions of data points across live classes, on-demand content, and community events every day.