Às 10 da manhã, horário do leste, em 28 de novembro de 2025, os gastos online nos Estados Unidos subiram para $12.5 milhões por minuto e mantiveram esse ritmo por horas. Atrás de cada uma dessas transações havia um servidor web, uma conexão de banco de dados e uma política de autoscaling que acompanhou o ritmo ou não. Para a equipe que gerencia essa infraestrutura, os códigos de desconto importavam menos do que saber se a frota conseguiria adicionar capacidade antes que as páginas de checkout expirassem. Essa decisão é tomada semanas antes, em arquivos de configuração que a maioria dos compradores nunca vê.
Regras de autoscaling sob pressão antes do pico de feriados
A Amazon Web Services recomenda o acompanhamento de destino como a política inicial para a maioria das cargas de trabalho. Uma equipe escolhe uma métrica, geralmente a utilização da CPU, e define um valor de destino. Uma política de escalabilidade de acompanhamento de destino pode visar uma utilização média de CPU de 50 por cento. A partir daí, o provedor de nuvem adiciona ou remove instâncias por conta própria para manter essa linha.
A política tem uma peculiaridade que pega as novas equipes de surpresa. Uma política de escalabilidade de acompanhamento de destino assume que deve aumentar a escala quando a métrica especificada sobe acima do valor de destino, mas não pode aumentar a escala quando a métrica fica abaixo desse destino. Isso significa que um crescimento lento e constante no tráfego é bem gerenciado. Uma queda repentina em uma métrica diferente, que a política nunca foi configurada para observar, não acionará nenhuma resposta.
É por isso que a documentação da AWS trata o acompanhamento de destino como uma base e não como uma resposta completa. Na maioria dos casos, uma política de escalabilidade de acompanhamento de destino é suficiente para aumentar e diminuir automaticamente um grupo de Auto Scaling. Mas a frase operativa é "na maioria dos casos", não em todos.
Warm pools, escalonamento por etapas e o piso de capacidade
O escalonamento reativo tem um problema de atraso inerente durante um pico repentino. Um pico que chega mais rápido do que o ciclo de avaliação de métrica excederá o destino antes que o acompanhamento de destino responda. Quando a política percebe, o dano aos tempos de carregamento da página já começou.
Duas ferramentas fecham essa lacuna. A primeira é o escalonamento por etapas, que reage em saltos maiores quando um limite é ultrapassado, útil para tráfego viral ou de vendas relâmpago, em vez do ritmo diário lento que o acompanhamento de destino gerencia bem. A segunda é o warm pool. Os warm pools mantêm instâncias EC2 pré-inicializadas em estados parados ou em execução, prontas para ingressar em um grupo de Auto Scaling imediatamente durante eventos de expansão. As equipes devem usar warm pools quando uma aplicação tem sequências de inicialização longas, quando a latência de escalonamento afeta diretamente a experiência do usuário ou quando metas rígidas de disponibilidade se aplicam durante picos de tráfego.
Uma configuração merece um segundo olhar antes do início da temporada. Os tempos limite de hook de ciclo de vida são definidos como 3.600 segundos por padrão, e se a automação vinculada a esse hook falhar silenciosamente, as instâncias ficarão presas em um estado de espera até que o tempo limite expire, o que pode bloquear a expansão durante o aumento exato que uma equipe está tentando sobreviver. Verificar esse padrão em seus próprios scripts de implantação leva minutos. Descobrir isso durante um pico de tráfego, não.
O escalonamento agendado e preditivo cobre a lacuna que as políticas reativas não conseguem. O escalonamento agendado se ajusta ao início de uma campanha conhecida, enquanto o escalonamento preditivo ajuda quando o tráfego segue padrões recorrentes apoiados por dados históricos suficientes. Nenhum substitui o acompanhamento de destino. Ambos funcionam ao lado dele como um piso preventivo, para que a frota já seja maior antes que o primeiro comprador chegue à página inicial.
As decisões de custo seguem a mesma lógica. Um grupo de instâncias mistas pode combinar capacidade On-Demand e Spot e extrair de vários tipos de instância, o que espalha o risco caso um tipo de instância fique escasso. Os Savings Plans reduzem as taxas de computação elegíveis, mas não fornecem uma reserva de capacidade EC2, portanto, um desconto comprometido não é o mesmo que uma garantia de que a capacidade existirá quando você precisar.
Quem sente a pressão quando a capacidade atrasa
Grandes varejistas com equipes de plataforma dedicadas tendem a ter isso resolvido com meses de antecedência. A pressão recai mais fortemente sobre pequenas e médias lojas online que operam em hospedagem compartilhada, um único servidor web ou uma conta em nuvem levemente gerenciada. Esses são os sites administrados por uma ou duas pessoas equilibrando marketing, estoque e infraestrutura ao mesmo tempo.
A escolha da plataforma define quanto desse fardo recai diretamente sobre o comerciante. O Shopify relatou que seus comerciantes geraram $6.2 bilhões em vendas globais online na Black Friday de 2025, tráfego que a própria infraestrutura da plataforma absorveu em vez de cada proprietário de loja individual. Uma loja WooCommerce ou Magento auto-hospedada carrega esse mesmo pico de tráfego sem esse buffer compartilhado, e é por isso que as regras de autoscaling subjacentes a um site autogerenciado são mais, e não menos, importantes à medida que o volume de pedidos cresce.
Agências e desenvolvedores freelancers que gerenciam vários sites de clientes enfrentam uma versão agravada do mesmo problema. Cada site pode precisar de seu próprio limite, seu próprio tamanho de warm pool e sua própria janela de escalonamento agendada, sincronizada com o calendário de promoções específico daquele cliente.
O que os números da Black Friday 2025 mostram
A escala do problema é visível nos números da última temporada. Os consumidores dos EUA gastaram $11.8 bilhões online na Black Friday de 2025, e os dispositivos móveis representaram $6.5 bilhões desse total, ou 55.2 por cento das vendas online, de acordo com a Adobe. A maior parte desse tráfego chegou por telefones, muitas vezes em redes móveis inconsistentes, o que aumenta o custo de qualquer atraso na resposta da página.
A composição do tráfego está mudando de uma forma que complica a previsão. A Adobe relatou que o tráfego de IA para sites de varejo nos EUA aumentou 805 por cento em comparação com a Black Friday anterior. Essa é uma nova fonte de carga de crescimento rápido que os modelos de tráfego histórico das temporadas passadas não capturam totalmente, o que enfraquece o argumento de confiar apenas no escalonamento preditivo sem uma proteção reativa.
Os números ao nível da plataforma contam uma história semelhante sobre a escala. Os comerciantes do Shopify venderam $14.6 bilhões durante a Black Friday e a Cyber Monday de 2025, um aumento de 27 por cento, atendendo a mais de 81 milhões de clientes. Essa taxa de crescimento supera o planejamento de capacidade ano a ano da maioria das equipes, o que significa que a contagem de instâncias de pico do ano passado raramente é a linha de base segura deste ano.
O que vem a seguir para o autoscaling de feriados
Os provedores de nuvem estão se inclinando mais para a previsão do que para a pura reação. O recurso de escalonamento preditivo da AWS prevê a demanda a partir de padrões históricos e adiciona capacidade de EC2 antes de um pico esperado, em vez de esperar que uma métrica ultrapasse um limite. A questão em aberto é se essa previsão pode acompanhar um mix de tráfego que está mudando tão rápido quanto as compras referenciadas por IA agora.
Os testes continuam sendo a parte que as equipes mais ignoram. Testes de carga que aumentam gradualmente de zero ao pico dão ao Auto Scaling tempo para adicionar capacidade antes da demanda simulada, mas não validam o comportamento de pico. Um teste criado em torno de uma rampa suave passará facilmente e ainda deixará um site exposto ao tipo de pico repentino e irregular que o tráfego real de feriados produz.
Se a temporada de festas de 2026 repetirá a taxa de crescimento de tráfego de IA vista em 2025, ou se estabelecerá em um padrão mais estável, é o número que toda equipe de plataforma estará observando no próximo ciclo de previsão.
