Na semana de 27 de julho o AWS Transform abandonou a suposição de que uma migração começa no vSphere. A entrada do change log de 29 de julho renomeia o workflow para "Migrations (including VMware)" e abre discovery, planejamento de waves, landing zone, migração de rede e rehost de servidores para Hyper-V, bare metal e outras plataformas. Na mesma semana, o AWS Interconnect para Oracle Cloud Infrastructure entrou em GA, o roteamento por política do Transit Gateway permitiu que decisões de encaminhamento usem origem, porta e protocolo, o IAM Identity Center estendeu a replicação multirregião ao seu diretório embutido, e o CloudWatch começou a rodar coletores Prometheus por você.

AWS Transform for migrations: o hipervisor deixa de importar

A documentação de migrar servidores agora diz sem rodeios: você pode migrar de data centers on-premises, de outros provedores de nuvem ou de outras Regiões da AWS, físico ou virtual, em VMware, Hyper-V, KVM ou qualquer outra coisa, e o hipervisor é irrelevante desde que o SO convidado esteja na lista de suportados do AWS Transform MGN. O motor de replicação sempre foi o MGN, que nunca se importou com a origem; o que mudou é que o workflow agêntico em volta dele, discovery, recomendações dos 7Rs, planejamento de waves, conversão de rede, agora aceita essas origens também. A mesma entrada adiciona ações pós-lançamento ao rehost: documentos SSM, predefinidos ou customizados, que o agente recomenda e executa em cada servidor conforme ele sobe como instância de teste ou de cutover, definidos no nível da conta ou por servidor no arquivo de inventário sob mgn:launch:post-actions:<ACTION_NAME>:<FIELD_NAME>.

Para quem está dimensionando um parque Hyper-V ou bare metal para a AWS, esta é a semana em que o ferramental alcançou o discurso de vendas. Duas cautelas. Primeiro, a mudança é uma entrada de documentação, não um post do What's New, então não há lista de Regiões nem nota de preço para citar; verifique na Região do seu workspace antes de planejar em cima disso. Segundo, replicação agentless continua sem suporte, então todo servidor de origem precisa de um agente, e em bare metal não há caminho via vCenter para encobrir as máquinas em que você não consegue logar. Confirme credenciais por servidor na validação do inventário, não quando o conector do MGN der timeout. As ações pós-lançamento são a vitória silenciosa: o checklist "instalar o agente do CloudWatch, ingressar no domínio, rodar o scan de compliance" que costumava ser um runbook passa a fazer parte da wave, e mustSucceedForCutover permite transformá-lo em gate.

Interconnect para OCI, e roteamento que lê mais que o destino

O AWS Interconnect - multicloud chegou a GA em 29 de julho para Oracle Cloud Infrastructure, provisionado pelo console, CLI ou API, com Google Cloud também suportado no GA e Microsoft Azure esperado para mais tarde em 2026. A OCI construiu o lado dela sobre uma especificação aberta que a AWS publicou no GitHub. A disponibilidade é us-east-1 para OCI, e o anúncio não dá tiers de banda nem preço, então a documentação é a próxima parada.

A comparação é com o que os times fazem hoje: um Direct Connect para uma instalação de colocation, um cross-connect para o outro provedor, duas sessões BGP e uma página de wiki sobre quem chamar quando quebra. O Interconnect substitui isso por um objeto gerenciado, e concentra o risco em um produto, em uma Região no lançamento. O padrão banco-na-OCI, aplicação-na-AWS que o licenciamento Oracle continua produzindo é o cliente óbvio. Para qualquer outra coisa, espere a lista de Regiões crescer.

O roteamento por política no Transit Gateway, em GA em 30 de julho sem custo adicional, é a peça que torna uma rede hub-and-spoke capaz de dizer "esta origem, nesta porta, passa pelo firewall; todo o resto vai direto". Você anexa uma policy table a um attachment, escreve um conjunto ordenado de regras que casam com IP de origem e destino, porta e protocolo, e cada regra envia os pacotes correspondentes para uma route table nomeada, a primeira correspondência vence. O modo de falha é o que o PBR sempre teve: uma policy table é um segundo lugar onde o roteamento é decidido, e "procure o destino na route table" deixa de ser um modelo mental suficiente. Documente as regras ao lado das route tables, e resista a usar PBR para qualquer coisa que uma route table consiga expressar.

O Direct Connect ganhou visibilidade de rotas BGP no mesmo dia: rotas aceitas e anunciadas em VIFs privadas, de trânsito e públicas, com prefixo, AS path, communities e família de endereços, pelo console ou por ListVirtualInterfaceRoutes. Quem já depurou um caminho assimétrico pedindo ao time de rede para rodar show ip bgp do lado deles sabe por que isso importa.

Identity Center replica o próprio diretório

O suporte multirregião no IAM Identity Center antes exigia um provedor de identidade externo. A partir de 29 de julho uma instância de organização usando o diretório embutido do Identity Center pode replicar identidades e entitlements da sua Região primária para Regiões adicionais que você escolhe, entre as 17 Regiões comerciais habilitadas por padrão. Se a Região primária for interrompida, os usuários mantêm acesso às suas contas por meio de entitlements já provisionados em outro lugar. A administração fica na Região primária, a instância precisa usar uma chave KMS gerenciada pelo cliente multirregião, e o único custo é o KMS.

O Identity Center é o componente cuja falha impede todo humano de consertar qualquer outra coisa, e sem um IdP externo ele tem sido uma dependência de Região única desde o lançamento. O pré-requisito é a pegadinha: uma CMK multirregião precisa existir antes de você habilitar a replicação, e uma instância criada com a chave padrão de propriedade da AWS precisa de uma troca de chave primeiro. Planeje isso como uma mudança própria, com rollback.

CloudWatch roda o coletor Prometheus

Os coletores gerenciados do CloudWatch, em GA em 31 de julho, fazem scrape de métricas Prometheus de EKS (service discovery do Kubernetes), ECS (DNS do Cloud Map), EC2 (direto) e MSK e OpenSearch Service (endpoints de open monitoring) sem um OpenTelemetry Collector operado por você. Você entrega uma configuração de scrape e uma conexão; o CloudWatch provisiona e escala o coletor, entrega as métricas em formato OpenTelemetry e permite consultá-las com PromQL junto com métricas vended. Os coletores são cobrados por hora além da ingestão padrão de métricas OpenTelemetry, e o recurso está disponível onde quer que o endpoint OTLP do CloudWatch esteja, exceto Asia Pacific (New Zealand).

O coletor autogerenciado era a parte da stack de observabilidade com maior chance de estar fora quando você precisava das métricas, geralmente porque o nó dele era justamente o que estava em apuros. Tirá-lo do cluster está correto. A questão é o custo na cardinalidade: a taxa por hora é previsível, a ingestão não, e uma configuração de scrape copiada de um servidor Prometheus que guardava tudo vai ingerir tudo. Mantenha suas regras de drop em metric_relabel_configs, e leia a linha de ingestão da primeira fatura antes de adicionar o segundo cluster.

Também nesta semana

O fio condutor

Toda manchete desta semana alarga uma entrada que a AWS costumava restringir. O Transform aceita qualquer hipervisor. O Interconnect aceita outra nuvem. O Transit Gateway aceita correspondências de cinco tuplas em vez de um destino. O Identity Center leva o próprio diretório para mais Regiões. Os coletores gerenciados aceitam a configuração de scrape que você já tem. O custo é pago na mesma moeda toda vez: mais entradas significam mais lugares onde a configuração pode estar errada, e menos deles visíveis em uma route table. O lançamento de visibilidade BGP é a pista: a AWS adicionou observabilidade ao Direct Connect no mesmo dia em que adicionou roteamento por política ao Transit Gateway, porque sabe o que o segundo faz com a depuração.

Leia isto a seguir

Para a leitura de IA e agentes das mesmas semanas, as notas de campo vivem em ercan.ai. Consultoria em AWS, nuvem, pipelines de CI/CD, Linux, GitHub/GitLab e mais passa por ercanermis.com.

Referências