At 10 a.m. Eastern on November 28, 2025, online spending in the United States climbed toward $12.5 million every minute and held near that pace for hours. Behind every one of those transactions sat a web server, a database connection and an autoscaling policy that either kept up or did not. For the team running that infrastructure, discount codes mattered less than whether the fleet could add capacity before checkout pages timed out. That decision gets made weeks earlier, in configuration files most shoppers never see.
Autoscaling rules under pressure before the holiday rush
Amazon Web Services recommends target tracking as the starting policy for most workloads. A team picks one metric, often CPU utilization, and sets a target value. A target tracking scaling policy can target an average CPU utilization of 50 percent. From there, the cloud provider adds or removes instances on its own to hold that line.
The policy has one quirk that catches new teams off guard. A target tracking scaling policy assumes it should scale out when the specified metric rises above the target value, but it cannot scale out when the metric sits below that target. That means a slow, steady climb in traffic gets handled well. A sudden drop in a different metric, one the policy was never set to watch, will not trigger any response at all.
This is why AWS documentation treats target tracking as a baseline rather than a complete answer. In most cases a target tracking scaling policy is enough to scale an Auto Scaling group out and in automatically. But the operative phrase is "most cases," not all of them.
Warm pools, step scaling and the capacity floor
Reactive scaling has a built-in lag problem during a sudden spike. A spike arriving faster than the metric evaluation cycle will exceed the target before target tracking responds. By the time the policy notices, the damage to page load times has already started.
Two tools close that gap. The first is step scaling, which reacts in bigger jumps once a threshold breaks, useful for viral or flash-sale traffic rather than the slow daily rhythm target tracking handles well. The second is the warm pool. Warm pools keep pre-initialized EC2 instances in stopped or running states, ready to join an Auto Scaling group immediately during scale-out events. Teams should use warm pools when an application has lengthy startup sequences, when scaling latency affects user experience directly, or when strict availability targets apply during traffic spikes.
One setting deserves a second look before the season starts. Lifecycle hook timeouts default to 3,600 seconds, and if the automation tied to that hook fails silently, instances stay stuck in a wait state until the timeout passes, which can block scale-out during the exact surge a team is trying to survive. Checking that default against your own deployment scripts takes minutes. Finding out about it during a traffic spike does not.
Scheduled and predictive scaling cover the gap that reactive policies cannot. Scheduled scaling fits a known campaign start, while predictive scaling helps when traffic follows recurring patterns backed by enough historical data. Neither replaces target tracking. Both sit alongside it as a pre-emptive floor, so the fleet is already larger before the first shopper lands on the homepage.
Cost decisions follow the same logic. A mixed instances group can combine On-Demand and Spot capacity and draw from multiple instance types, which spreads risk if one instance type runs short. Savings Plans reduce eligible compute rates but do not provide an EC2 capacity reservation, so a committed discount is not the same thing as a guarantee that capacity will exist when you need it.
Who feels the pressure when capacity lags
Large retailers with dedicated platform teams tend to have this solved months in advance. The pressure lands hardest on small and mid-sized online stores running on shared hosting, a single web server, or a lightly managed cloud account. These are the sites run by one or two people juggling marketing, inventory and infrastructure at once.
Platform choice shapes how much of this burden falls on the merchant directly. Shopify reported that its merchants generated $6.2 billion in global online sales on Black Friday 2025, traffic that the platform's own infrastructure absorbed rather than each individual store owner. A self-hosted WooCommerce or Magento store carries that same traffic spike without that shared buffer, which is why the autoscaling rules sitting underneath a self-managed site matter more, not less, as order volume grows.
Agencies and freelance developers managing several client sites face a compounding version of the same problem. Each site may need its own threshold, its own warm pool size and its own scheduled scaling window timed to that client's specific promotion calendar.
What the Black Friday 2025 figures show
The scale of the problem is visible in the numbers from last season. US consumers spent $11.8 billion online on Black Friday 2025, and mobile devices accounted for $6.5 billion of that total, or 55.2 percent of online sales, according to Adobe. A majority of that traffic arrived on phones, often over inconsistent mobile networks, which raises the cost of any delay in page response.
Traffic composition is shifting in a way that complicates forecasting. Adobe reported that AI traffic to US retail sites was up by 805 percent compared to the previous Black Friday. That is a new, fast-growing source of load that historical traffic models from past seasons do not fully capture, which weakens the case for relying on predictive scaling alone without a reactive backstop.
Platform-level numbers tell a similar story about scale. Shopify merchants sold $14.6 billion over Black Friday and Cyber Monday 2025, an increase of 27 percent, serving more than 81 million customers. That growth rate outpaces most teams' year-over-year capacity planning, which means last year's peak instance count is rarely this year's safe baseline.
What comes next for holiday autoscaling
Cloud providers are leaning further into prediction rather than pure reaction. AWS's predictive scaling feature forecasts demand from historical patterns and adds EC2 capacity ahead of an expected spike, rather than waiting for a metric to cross a threshold. The open question is whether that forecasting can keep pace with a traffic mix that is changing as fast as AI-referred shopping is right now.
Testing remains the piece teams skip most often. Load tests that ramp gradually from zero to peak give Auto Scaling time to add capacity ahead of simulated demand, but they do not validate spike behavior. A test built around a gentle ramp will pass cleanly and still leave a site exposed to the kind of sudden, uneven surge that real holiday traffic produces.
Whether 2026's holiday season repeats the AI-traffic growth rate seen in 2025, or settles into a steadier pattern, is the number every platform team will be watching for in the next forecasting cycle.
