Esta semana em cloud (15–21/jun): a conta da IA virou conta de silício, energia e rede

TL;DR: O AWS Summit NY 2026 abriu a semana com Graviton5 (Nitro, o primeiro hypervisor cloud formalmente verificado), GPUs Blackwell nas EC2 G7 e o FinOps Agent. O Brazos liquid cooling do Google, o RDMA gerenciado no OKE e o Ray Serve no GKE confirmaram que IA em produção é hardware, energia e rede. Na operação: Cloud Network Insights, ICMP no NAT Gateway, a migração Sentinel para Defender e tenant clusters como primitivo de soberania.

Foi uma semana de AWS Summit, e o calendário de Nova York costuma puxar a conversa para modelos e agentes. Desta vez, porém, o sinal mais forte veio de baixo da pilha. Entre o anúncio do Graviton5, das GPUs Blackwell na borda, de um sistema de refrigeração líquida que se instala rack a rack e do RDMA gerenciado em Kubernetes, o recado da semana foi claro: depois de dois anos falando de prompts e pesos, a indústria voltou a falar de silício, energia e rede.

Faz sentido. A IA generativa não inventou um problema de software novo — ela cobrou a fatura física que vinha sendo empurrada com a barriga. Cada modelo maior é mais watts por rack, mais largura de banda entre GPUs e mais pressão sobre o custo. Os anúncios desta semana são, no fundo, respostas a essa fatura: processadores mais eficientes, hypervisor provado, calor dissipado sem reforma, gradientes trocados em microssegundos. Quem trata isso como detalhe de datacenter vai descobrir, na primeira conta ou no primeiro gargalo, que a inteligência roda sobre engenharia de infraestrutura bem feita.

E não parou no hardware. A semana também consolidou movimentos de operação que vinham amadurecendo: observabilidade que enxerga a rede que você não controla, consoles de segurança convergindo em uma fila única e a soberania digital deixando de ser cláusula de contrato para virar decisão de arquitetura de control plane. Abaixo, o roundup dos destaques que valem a leitura de quem opera infra no Brasil.

Por que o AWS Summit de Nova York foi, antes de tudo, um anúncio de silício?

A keynote teve agentes e ferramentas de desenvolvimento, mas as peças que mais mexem com arquitetura foram de infraestrutura. A primeira é o Graviton5: as instâncias Amazon EC2 M9g e M9gd chegaram a disponibilidade geral entregando até 25% mais performance computacional sobre as M8g baseadas em Graviton4, com até 35% para aplicações web e inferência de ML e até 30% para bancos de dados. O Graviton5 é o primeiro processador da frota AWS a suportar PCIe Gen6 e memória DDR5-8800, com cache L3 cinco vezes maior que a geração anterior. As M9gd somam até 11,4 TB de NVMe SSD local.

O detalhe que merece mais atenção, porém, não é o benchmark — é o Nitro Isolation Engine. Construído sobre o Nitro System de sexta geração, ele usa verificação formal para entregar isolamento matematicamente comprovado entre máquinas virtuais, o que faz do Nitro, segundo a AWS, o primeiro hypervisor cloud formalmente verificado. Para quem roda multi-tenancy em setores regulados, isolamento provado por matemática é um argumento de compliance que vai além do datasheet.

A segunda peça é a EC2 G7, primeira da frota a trazer as GPUs NVIDIA RTX PRO 4500 Blackwell Server Edition — até 4,6x mais performance em inferência de IA e 2,1x em gráficos sobre as G6, com 32 GB de memória por GPU, 5ª geração de Tensor Cores e até 700 Gbps de rede EFA com GPUDirect RDMA. O porém é geográfico: o lançamento ficou restrito a Ohio e Oregon, sem previsão para São Paulo. Para inferência em tempo real no Brasil, cada milissegundo de distância conta, e parte do ganho bruto se dissolve na latência transatlântica — o que mantém renderização, VDI, treino e batch como os casos mais imediatos.

A terceira é de governança de custo: o AWS FinOps Agent (preview), que responde perguntas sobre gasto, identifica rightsizing e recursos ociosos a partir do Cost Optimization Hub e do Compute Optimizer, abre tickets no Jira e investiga anomalias de custo postando a causa raiz no Slack. Some a isso o S3 Annotations — até 1.000 anotações nomeadas por objeto, de 1 MB cada, mutáveis, consultáveis via Athena e cobradas sempre a tarifa S3 Standard — e o retrato do Summit fecha: menos demo de modelo, mais plataforma de produção.

Quer avaliar Graviton5, GPU Blackwell ou estruturar FinOps na sua nuvem antes de migrar workloads de IA? Fale com os especialistas em Cloud da Nuvem Online.

A fatura da IA não vem em GPU: ela vem em watts, calor e microssegundos

Se o Summit deu o silício, o resto da semana deu a física. O Google lançou o Brazos, um sistema de refrigeração líquida fechado (loop líquido-ar) que ataca um gargalo concreto: chips de IA e HPC já passam de 1000 W de TDP, e o resfriamento a ar não dissipa esse calor. A alternativa tradicional — retrofit do datacenter com loops de água gelada — custa capital e meses. O Brazos instala-se rack a rack, suporta até 60 kW por rack com três módulos, troca calor com o corredor quente via trocadores líquido-ar e dispensa qualquer conexão com a rede hidráulica do prédio. Usa o formato OCP ORv3, tem partes hot-swap para baixar o MTTR e terá especificações abertas pelo Open Compute Project. É a admissão de que escalar IA em data centers legados é, primeiro, um problema térmico.

Resolvido o calor, sobra a rede entre GPUs. A Oracle liberou suporte a RDMA em managed node pools do OKE via Compute Clusters — instâncias bare metal em proximidade física, interligadas por rede RDMA com latência de dígitos de microssegundos. Em treino distribuído, quando milhares de GPUs trocam gradientes e checkpoints, a rede deixa de ser detalhe e vira o gargalo: o tempo de comunicação pode superar o de computação e deixar GPU cara ociosa. Antes, usar RDMA em Kubernetes exigia nós self-managed; agora o OKE entrega a rede de baixa latência sem abrir mão de scaling, upgrades e node cycling gerenciados — ativando automaticamente os plugins HPC de RDMA. A ressalva operacional: o Compute Cluster é definido só na criação do node pool e não pode ser trocado depois.

A terceira peça é software espremendo o máximo desse hardware. O Google Cloud, em parceria com a Anyscale, entregou até 5x mais throughput e 8x menos latência no Ray Serve LLM no GKE com três otimizações: integração com HAProxy para roteamento interno, streaming direto de tokens que desvia do ingress router, e um backend v2 que tira o Ray do data plane e o aproxima dos executores nativos do vLLM. Os benchmarks rodaram em VMs A4 com NVIDIA HGX B200, usando o modelo Gemma 4 E2B em oito réplicas, e chegaram perto do vLLM puro sem perder o ecossistema Ray. O fio condutor das três notícias é o mesmo: a IA cobrou maturidade de infraestrutura, não inventou um paradigma — energia, rede e serving são onde a conta é paga ou desperdiçada.

Como observar e proteger o que você não controla diretamente?

Com a infraestrutura ficando mais distribuída, a operação do dia 2 também ganhou destaque. O Google Cloud anunciou a disponibilidade geral do Cloud Network Insights, em parceria com a Broadcom AppNeta, para estender observabilidade de rede para além do GCP — cobrindo AWS, Azure, on-premises, ISPs e última milha. A sacada é a sondagem sintética ativa: Monitoring Points (containers ou VMs) disparam tráfego sintético 24/7, mesmo sem usuário real, medindo RTT, perda de pacotes, jitter e mudanças de caminho nas camadas 3 e 4, além de DNS, HTTP e tempo de carregamento na camada 7. Integrado ao Cloud Monitoring e ao Gemini Cloud Assist, resolve a pergunta clássica do incidente cross-cloud — "é a rede, a aplicação ou o ISP?" — com dados, e ainda serve para validar SLA de provedores que você não opera.

No mesmo eixo de diagnóstico, a Microsoft adicionou suporte a ICMP Echo (ping) no Azure StandardV2 NAT Gateway, para IPv4 e IPv6. Parece pequeno, mas resolve uma dor real: workloads atrás de um NAT Gateway centralizado não têm IP público, e até agora só falavam TCP e UDP — não dava para um simples ping validar reachability durante a triagem de um incidente sem subir jump host ou abrir exceção de firewall. Agora funciona automaticamente, inclusive para nós de AKS, com o gateway rastreando o flow ICMP pelo campo identifier. É o tipo de feature que some na lista de release notes mas economiza minutos preciosos no meio de um troubleshooting.

Na segurança, a semana foi de consolidação de console. A Microsoft detalhou a migração do Sentinel para o Defender: o motor de correlação Fusion é substituído pelo mecanismo nativo do Defender, a fila de incidentes vira única e o schema migra de SecurityAlert para as tabelas AlertInfo/AlertEvidence, mais fáceis de consultar. O armazenamento no Log Analytics permanece intacto, mas IDs e URLs de incidente mudam, e toda automação que usa a API do Sentinel precisa apontar para a Microsoft Graph Security API — além de ser preciso designar um workspace primário para a correlação XDR. No mesmo movimento de mercado, o Google foi nomeado Leader no IDC MarketScape SIEM 2026, com destaque para integração vertical de IA (do chip aos agentes), inteligência Mandiant e performance de busca em data lake unificado — um cliente citou redução de 97% no volume de alertas. Dos dois lados, a aposta é a mesma: menos consoles, menos incidentes duplicados, mais contexto por alerta.

A soberania digital deixou de ser cláusula de contrato e virou desenho de control plane

A última frente da semana foi regulatória, mas com resposta de arquitetura. Um artigo da CNCF, assinado por um ambassador da fundação, cravou que soberania não se resolve com "escolhemos Frankfurt": EU Data Act, NIS-2, DORA e o Data Use and Access Act 2025 do Reino Unido cobram controle sobre control plane, chaves e auditoria — não só localização de workload. A proposta é o padrão de tenant clusters (popularizado pelo vCluster): cada limite de soberania ganha seu próprio API server, etcd e logs de auditoria, rodando como pods sobre um cluster subjacente compartilhado. Isso reduz o blast radius de um incidente, desacopla o alvo legal do alvo técnico (uma intimação ao operador do cluster base não entrega automaticamente o etcd de um tenant cujo estado vive em jurisdição local) e mantém portabilidade real, com acesso a GPU via Dynamic Resource Allocation para nuvens de IA soberanas.

O artigo é honesto sobre o limite: tenant clusters não mudam a jurisdição do operador do cluster subjacente — se for uma empresa americana, a exposição ao CLOUD Act permanece — e não substituem o resto da pilha (Kyverno ou OPA Gatekeeper para política, SBOM, SPIFFE/SPIRE para identidade, GitOps). É um primitivo, não uma plataforma. O contraponto veio do Google Cloud, que se posicionou sobre o Tech Sovereignty Package e o Cloud and AI Development Act (CADA) da UE, argumentando que os Union Assurance Levels podem excluir provedores globais por critérios geográficos rígidos, e defendendo soberania por controle técnico (como o External Key Manager) e parcerias regionais "Made with Europe". Para o Brasil, que opera sob LGPD e atende clientes europeus, o casamento dos dois textos é a lição da semana: a soberania que passa em auditoria é a que vira objeto no cluster — com nome, template e histórico de commits — e não a que mora apenas no contrato.

O que levar desta semana

A semana do AWS Summit não trouxe um paradigma novo; trouxe a conta física da IA, fatiada em quatro frentes operacionais. Silício: Graviton5 com hypervisor formalmente verificado e GPU Blackwell na borda mostram que eficiência e isolamento provado voltaram a ser decisão de arquitetura — mas atenção à disponibilidade regional, que ainda exclui o Brasil das G7. Energia e rede: Brazos resolve o calor sem reforma, RDMA gerenciado no OKE resolve a latência entre GPUs e Ray Serve no GKE espreme o serving — é onde a fatura de inferência é paga ou desperdiçada. Operação: Cloud Network Insights e o ICMP no NAT Gateway recuperam a visibilidade da rede distribuída, enquanto a migração Sentinel→Defender e o SIEM do Google consolidam a segurança em uma fila única. Soberania: tenant clusters transformam jurisdição em control plane declarável, com o limite honesto de que não apagam a jurisdição do operador base. Quem operar essas frentes com disciplina colhe a inteligência sem pagar a estabilidade; quem só assistir à keynote vai descobrir, na primeira conta de energia ou no primeiro incidente cross-cloud, que IA em produção é, antes de tudo, infraestrutura cloud bem operada.

Perguntas Frequentes

O que torna o Graviton5 e o Nitro Isolation Engine relevantes além do ganho de performance?
As instâncias EC2 M9g e M9gd, agora em GA, entregam até 25% mais performance computacional que as M8g baseadas em Graviton4, com até 35% para aplicações web e inferência de ML, suporte a PCIe Gen6, memória DDR5-8800 e cache L3 cinco vezes maior. O ponto mais subestimado, porém, é o Nitro Isolation Engine: ele usa verificação formal para provar matematicamente o isolamento entre VMs, tornando o Nitro o primeiro hypervisor cloud formalmente verificado. Para quem opera multi-tenancy regulado no Brasil, isolamento provado é argumento de compliance, não só de marketing.

As novas instâncias EC2 G7 com GPU Blackwell já estão disponíveis para o Brasil?
Não inicialmente. As EC2 G7, aceleradas por GPUs NVIDIA RTX PRO 4500 Blackwell Server Edition, oferecem até 4,6x mais performance em inferência de IA e 2,1x em gráficos sobre as G6, com 32 GB de memória por GPU e até 700 Gbps de rede EFA. Mas o lançamento ocorreu apenas nas regiões US East (Ohio) e US West (Oregon), sem previsão para São Paulo. Para inferência sensível à latência no Brasil, a distância geográfica pode anular parte do ganho bruto — o que mantém renderização, treino e batch como os casos mais óbvios por enquanto.

O que muda na prática com a refrigeração líquida Brazos do Google?
Chips de IA e HPC já passam de 1000 W de TDP, e o resfriamento a ar não dá conta. O Brazos é um sistema de refrigeração líquida fechado (loop líquido-ar) montado rack a rack, que suporta até 60 kW por rack sem exigir reforma hidráulica ou conexão com água gelada do prédio. Ele troca calor com o corredor quente via trocadores líquido-ar, usa o formato OCP ORv3 e terá especificações abertas pelo Open Compute Project. Para data centers legados refrigerados a ar, é o caminho para hospedar GPUs de alta densidade sem retrofit caro.

Por que a migração do Microsoft Sentinel para o Defender exige planejamento antes de começar?
A migração troca o antigo motor de correlação Fusion pelo mecanismo nativo do Defender, unifica a fila de incidentes e adota o schema AlertInfo/AlertEvidence no lugar do SecurityAlert. O armazenamento no Log Analytics permanece intacto, mas IDs e URLs de incidente mudam, e toda automação que usa a API do Sentinel precisa ser redirecionada para a Microsoft Graph Security API. É preciso ainda designar um workspace primário para receber a correlação XDR. Comece pelo inventário de automações e integrações de ticketing antes de habilitar o Sentinel no Defender.

Tenant clusters resolvem soberania de dados sozinhos?
Não. O padrão de tenant clusters (por exemplo via vCluster) dá a cada limite de soberania seu próprio control plane — API server, etcd e auditoria isolados —, reduzindo o blast radius e desacoplando o alvo legal do alvo técnico. Mas ele não muda a jurisdição do operador que roda o cluster subjacente: se for uma empresa sediada nos EUA, a exposição ao CLOUD Act permanece. Tenant clusters são um primitivo, não uma plataforma: ainda exigem policy engine (Kyverno ou OPA Gatekeeper), pipeline de SBOM, identidade de workload (SPIFFE/SPIRE) e GitOps.

Fontes: