Na semana de 21 de setembro a AWS redesenhou duas primitivas centrais em torno da organização em vez da conta: o CloudWatch Omni é uma experiência de observabilidade com escopo de time, alcançável via SSO sem acesso ao console, e o bus customizado relançado do EventBridge é um único broker compartilhado via RAM com ordenação, retenção e um modelo de preço construído para o padrão hub-and-spoke que todo mundo já roda. As global tables do DynamoDB com consistência forte multirregião chegaram a 15 Regiões e a configurações entre continentes, o Elastic Disaster Recovery adicionou servidores de origem Graviton, e o Security Hub começou a inventariar IA auto-hospedada em VMs do Azure.

CloudWatch Omni: telemetria organizada por time, não por conta

Em 23 de setembro o Amazon CloudWatch Omni entrou em disponibilidade geral. Você cria spaces em uma conta central que enxergam telemetria entre contas e Regiões, e entre outras nuvens, incluindo cargas no Azure. O Omni descobre serviços automaticamente, mapeia dependências, expõe golden metrics e puxa o AWS DevOps Agent para sessões de investigação a fim de correlacionar sinais. É construído sobre OpenTelemetry, então a instrumentação existente aparece sem reconfiguração. A parte que muda o design da organização: é uma experiência web independente com SSO para o time inteiro, sem necessidade de acesso ao console da AWS, mais uma extensão de IDE e acesso pelo Agent Toolkit.

Isso é a AWS construindo o que Datadog e Grafana vendem há uma década: uma URL, um login, todas as contas, com a IA do fornecedor fazendo a primeira passada. A diferença é que a telemetria nunca sai do CloudWatch, o que para muitas empresas reguladas é a decisão inteira.

O trade-off é de identidade. "Sem acesso ao console" significa que a autorização do Omni é um mapeamento de SSO para spaces, não uma política IAM em log groups. Esse é o modelo certo para um desenvolvedor que deveria ver os traces do próprio serviço e nada mais, mas é um segundo sistema de controle de acesso ao lado daquele que você já audita. Decida quais spaces guardam telemetria de produção, quem é mapeado para eles e como esse mapeamento é revisado, antes que o primeiro time crie um space por conta própria. E confira o preço dos caminhos de ingestão cross-account e cross-cloud antes de apontar o parque Azure para ele.

EventBridge relança o bus customizado para a empresa

Em 24 de setembro o EventBridge relançou os custom event buses. O bus aprimorado pode ser compartilhado com todas as contas da organização pelo AWS RAM, então os publishers escrevem direto no bus central. Uma nova API de publicação aceita formatos abertos como CloudEvents sem reescrever o schema. Os buses mantêm 24 horas de eventos por padrão, extensíveis a um ano, então você pode fazer replay depois de um bug ou hidratar um novo consumidor a partir do histórico. Um novo recurso Subscriber agrupa filtragem, destinos e retries; há deduplicação por conteúdo, ordenação estrita onde você pedir e invocação síncrona para destinos como o Lambda. Os buses existentes continuam sem mudança como "classic". O post do News Blog acrescenta que um modelo de preço por ingress/egress substitui as cobranças cumulativas de roteamento cross-account do padrão multi-bus.

O padrão que isso substitui é um bus por conta, regras de encaminhamento para um bus central e de volta, e uma cobrança a cada salto. Um bus compartilhado com Subscribers é mais simples e, para a maioria das topologias, mais barato. Os recursos de retenção e ordenação são os que antes forçavam times a colocar Kinesis ou Kafka na frente do EventBridge; muita dessa cola agora pode ir embora.

Não migre o hub da noite para o dia. Modele o custo de ingress/egress contra suas cobranças atuais por regra primeiro, porque "mais barato para a maioria" não é "mais barato para todos". Depois mova um producer e um Subscriber, mantendo o encaminhamento do bus classic em paralelo, e compare as contagens de entrega por uma semana. A ordenação é opt-in e vai ter implicações de throughput; ligue-a por subscription onde um consumidor realmente precisa, não globalmente.

Consistência forte do DynamoDB entre continentes

Em 23 de setembro as global tables do DynamoDB com consistência forte multirregião adicionaram cinco Regiões (Canada Central, Stockholm, Spain, Mumbai, Singapore), totalizando 15, e qualquer configuração de três Regiões entre elas agora é permitida, inclusive as que abrangem América do Norte, Europa e Asia Pacific. Você escolhe três réplicas, ou duas réplicas mais uma Região witness, e obtém um recovery point objective de zero.

RPO zero entre continentes é uma capacidade real e também é física. Uma escrita fortemente consistente entre Frankfurt, Virginia e Singapore paga uma viagem de ida e volta intercontinental antes de confirmar, toda vez. A opção entre continentes é para os dados em que isso vale a pena (entitlements, estado de pedidos, inventário, as coisas em que uma leitura desatualizada é um bug de correção) e não para a tabela de sessão ao lado. Mantenha as tabelas MRSC pequenas e deliberadas; todo o resto fica em global tables com consistência eventual e latência de escrita local.

Canto de migração e segurança

Em 25 de setembro o AWS Elastic Disaster Recovery adicionou servidores de origem baseados em Graviton (arm64). O DRS detecta arm64 e recupera em instâncias Graviton, nada extra para configurar, sem custo adicional. Isso fecha uma lacuna que bloqueava a adoção de Graviton onde "ter um plano de DR" é requisito de auditoria. É a única notícia de ferramental de migração da semana; nada do AWS Transform ou do DMS foi lançado.

Em 22 de setembro o AI Inventory do Security Hub começou a descobrir ativos de IA em VMs auto-hospedadas no Azure, usando a análise de SBOM do Inspector para encontrar endpoints de inferência, modelos e agentes (Ollama, vLLM, Hugging Face TGI e outros) e correlacioná-los com findings. Incluído no Security Hub Essentials. Se você está consolidando a postura de segurança na AWS enquanto um parque Azure é desativado, este é o passo de inventário que você faria à mão.

E em 25 de setembro a federação de identidade de saída do IAM ganhou interface VPC endpoints para seus endpoints de descoberta OIDC e JWKS. Uma carga verificadora em uma VPC sem caminho para a internet agora pode buscar as chaves para validar JWTs emitidos pelo STS de forma privada. Se você adotou a federação de saída para se livrar de chaves de longa duração, isso remove o último motivo pelo qual algumas subnets privadas não conseguiam.

Também nesta semana

O fio condutor

Omni, o relançamento do EventBridge, o Network Security Manager e a API de contexto de billing assumem todos que a unidade de operação é uma AWS Organization com uma conta central, não uma conta única com um console. O custo dessa atualização é que cada um introduz um control plane no nível da organização (spaces, buses compartilhados, políticas de segurança) com seu próprio modelo de acesso, e o trabalho do time de plataforma passa a ser manter esses modelos de acesso coerentes. As mudanças do DRS e do endpoint OIDC são a versão mais discreta da mesma história: capacidades finalmente alcançando as configurações em que parques reais estão, frotas arm64 e VPCs sem internet, então a lista de exceções fica mais curta.

Leia isto a seguir

Para a leitura de IA e agentes da mesma semana, veja ercan.ai. Se o seu time precisa de ajuda prática com AWS, arquitetura de nuvem, pipelines de CI/CD, Linux, GitHub ou GitLab e o trabalho de plataforma em volta deles, o lado de consultoria vive em ercanermis.com.

Referências