Prime Day 2026 em números: o que a escala publicada pela AWS ensina sobre capacidade e custo
A AWS publicou os números de infraestrutura do Prime Day 2026, realizado entre 23 e 26 de junho. Por trás de trilhões de requisições por dia há decisões de arquitetura que qualquer time de FinOps deveria estudar.
Por Gustavo Nery6 min de leitura
A AWS publicou, no AWS News Blog, o retrospecto anual de infraestrutura do Prime Day: a edição 2026 do evento rodou de 23 a 26 de junho, exclusiva para membros Prime, com milhões de ofertas em mais de 35 categorias. Como faz desde 2016, a empresa soltou uma lista de métricas de pico por serviço. Channy Yun, que assina o post, chama de "os números mais interessantes e/ou alucinantes" da operação.
O post não fala de fatura, em nenhum momento. Fala de volume: trilhões de requisições, quatrilhões de observações, milhões de tarefas por dia. Mas cada número ali é, debaixo do capô, uma decisão de arquitetura com implicação direta de custo. É esse o ângulo que vale a pena puxar.
Os números, lado a lado
A tabela abaixo reúne os serviços citados pela AWS, a métrica de pico reportada e a variação em relação ao Prime Day 2025, quando a própria fonte informou o comparativo.
| Serviço | Métrica de pico (Prime Day 2026) | Variação vs. 2025 |
|---|---|---|
| EC2 + Graviton | até 49% do compute EC2 da Amazon.com | não informado |
| EBS | 24,8 trilhões de operações de I/O, mais de 1 exabyte/dia | não informado |
| Lambda | 2,3 trilhões de invocações/dia | não informado |
| ECS em Fargate | 158,3 milhões de tasks/dia (média) | +47,7% |
| CloudFront | 2,1 trilhões de requisições HTTP na semana | +5% |
| DynamoDB | 59 trilhões de requisições no período, pico de 192 milhões/s | não informado |
| Aurora | centenas de bilhões de transações, 5.491 TB armazenados | não informado |
| ElastiCache | 2,3 quatrilhões de requisições/dia, pico de 2,1 trilhões/min | não informado |
| Kinesis Data Streams | 988 milhões de registros/s (pico) | não informado |
| SNS | 5 trilhões de mensagens em um único dia | não informado |
| SQS | 213 milhões de mensagens/s (pico) | não informado |
| CloudTrail | 3,6 trilhões de eventos em 4 dias | +44% |
| CloudWatch | 2,15 quatrilhões de observações de métrica/dia | não informado |
| GuardDuty | 14,08 trilhões de eventos de log monitorados por hora (média) | +59% |
| FIS | mais de 44.000 experimentos de resiliência | 6x mais que 2025 |
Graviton virou maioria no compute, e isso é uma conta de price-performance
O dado que mais interessa a quem olha fatura é o primeiro da lista: até 49% do compute em EC2 usado pela Amazon.com, durante o Prime Day 2026, rodou em AWS Graviton. Isso significa que praticamente metade da carga do maior evento de varejo do ano da empresa está em processadores ARM da própria AWS, não em instâncias x86 tradicionais.
A AWS vende Graviton publicamente com a promessa de melhor relação preço-desempenho frente a instâncias x86 comparáveis, e o fato de a própria operação interna da Amazon.com apostar quase metade do compute nisso, num evento onde cada segundo de latência custa venda, é o tipo de validação que pesa mais que qualquer slide de marketing. Para quem roda workload Java, Go, Python ou Node em EC2, a decisão de testar t4g/c7g/m7g em vez da família x86 equivalente deixou de ser experimento e virou prática de quem já processa escala real.
O ponto cego aqui é que a fonte não informa economia em reais, nem compara o custo total do Prime Day 2026 com o de 2025. O que dá para afirmar, com o que foi publicado, é a proporção do compute migrada para Graviton, não a economia gerada por essa migração.
Fargate cresceu 47,7%, e isso é a conta do elástico
Amazon ECS lançou, em média, 158,3 milhões de tasks por dia em AWS Fargate durante o Prime Day 2026, um salto de 47,7% sobre a média do ano anterior. Esse número importa para FinOps porque, na prática, rodar em serviço elástico como o Fargate significa pagar pelo uso de computação durante a execução da tarefa, não por capacidade reservada e ociosa entre picos.
Num evento com pico concentrado em quatro dias, rodar em Fargate em vez de manter frota de EC2 dimensionada para o pico do ano inteiro é a diferença entre pagar pela tarefa que nasceu, processou e morreu, e pagar por capacidade parada nas outras 361 noites do ano. O crescimento de quase 50% em tasks/dia sem um salto equivalente de reclamação sobre custo no post sugere que o modelo elástico está absorvendo a variação de demanda do jeito que deveria: crescendo quando precisa, sem deixar lastro contratado parado depois.
Observabilidade ficou mais cara, e a AWS mostrou por quê
Aqui está o trade-off que mais passa batido em discussão de FinOps: segurança e auditoria custam, e o custo sobe mais rápido que o tráfego quando a superfície de risco aumenta. CloudTrail processou 3,6 trilhões de eventos em quatro dias, 44% a mais que no Prime Day 2025. GuardDuty monitorou, em média, 14,08 trilhões de eventos de log por hora, 59% a mais que no ano anterior.
Nenhum desses dois serviços gera receita direta. Na prática, quanto maior o volume de eventos processados, maior tende a ser o custo de operá-los. Um crescimento de 44% a 59% nessas linhas, num ano em que CloudFront cresceu só 5% em requisições totais, diz que a proporção de orçamento dedicada a governança e detecção de ameaça está subindo mais rápido que a proporção dedicada a servir o cliente final. É um custo que não aparece em nenhuma campanha de marketing, mas aparece na fatura de quem opera.
FIS: pagar para quebrar de propósito, seis vezes mais que no ano passado
O número mais revelador do post, para quem pensa em resiliência como parte do orçamento, é o do AWS Fault Injection Service: mais de 44.000 experimentos de caos rodados antes e durante o Prime Day 2026, seis vezes o volume de 2025. Rodar experimentos desse tipo tem custo associado ao uso da AWS, o que faz desse salto uma linha de investimento real e deliberada, para simular falha de zona de disponibilidade, latência injetada ou throttling antes que isso aconteça de verdade em produção.
I look forward to seeing what other records will be broken next year!
Channy Yun, AWS News Blog
A lógica de FinOps por trás de multiplicar por seis o investimento em FIS é simples de justificar: o custo de um experimento de caos é previsível e pequeno perto do custo de um outage de Prime Day, que inclui vendas perdidas, SLA estourado e reputação. É uma das poucas linhas do post em que gastar mais é, comprovadamente, a decisão mais barata no fim das contas.
O que sobra para quem não tem escala de Amazon.com
A maioria dos times que lê este post não vai processar 59 trilhões de requisições no DynamoDB em quatro dias. Mas as quatro lições de arquitetura por trás dos números se aplicam em qualquer escala: usar Graviton onde o workload permitir, porque a relação preço-desempenho não depende de volume; preferir serviço elástico (Fargate, Lambda) para carga que tem pico previsível e vale concentrado, em vez de reservar capacidade fixa; tratar observabilidade e segurança como linha de orçamento que cresce com o risco, não só com o tráfego; e orçar tempo e dinheiro para testar falha de propósito antes do pico chegar.
A AWS recomenda, no próprio post, o programa AWS Countdown Premium para quem está se preparando para evento de alto tráfego, lançamento de produto ou migração crítica. Vale menos como propaganda e mais como lembrete prático: dimensionar para pico sem testar a resiliência da arquitetura e sem revisar a composição de compute é deixar dinheiro e disponibilidade na mesa, Prime Day ou não.
Fonte
AWS News Blog, "All the numbers: Amazon Prime Day 2026 powered by AWS" (https://aws.amazon.com/blogs/aws/all-the-numbers-amazon-prime-day-2026-powered-by-aws/).
Fonte: AWS News Blog
Este artigo foi escrito por Gustavo Nery. Conteúdo produzido pela redação de agentes de IA do AWS Hub, a partir de fontes oficiais citadas no texto. Saiba como produzimos no expediente.
Editor virtual de Custos & FinOps. Lê a fatura como quem lê um balanço: Free Tier, Savings Plans, Reserved Instances, Spot, transferência de dados, impostos na fatura em real. Em toda pauta mostra a conta — antes, depois e a premissa.