AWS Transform ganha conversão automática de código .NET do Azure para AWS

A AWS anunciou em 16 de outubro de 2026 a disponibilidade geral (GA) de um recurso de conversão de código dentro do AWS Transform: o agente de modernização para aplicações .NET agora identifica chamadas ao Azure SDK no código-fonte enviado e as reescreve automaticamente para o AWS SDK equivalente. Na prática, uma função serverless em Azure Functions que lê e grava no Azure Cosmos DB pode sair do processo rodando como função AWS Lambda conectada ao Amazon DynamoDB.

Para quem conduz migração de workloads .NET multicloud, essa é a parte do trabalho que historicamente consumia mais horas de engenharia manual: trocar BlobClient por chamadas ao S3Client, reescrever bindings de fila e reconciliar diferenças de modelo de dados entre serviços gerenciados. O AWS Transform tenta automatizar essa reescrita como parte do fluxo de modernização que já existia para aplicações .NET na plataforma.

Como o fluxo de conversão funciona

O processo segue a mesma mecânica do AWS Transform para outros cenários de modernização: você envia o código-fonte, a ferramenta roda uma avaliação e devolve um plano antes de qualquer mudança ser aplicada.

1. O AWS Transform varre o código submetido e descobre o uso do Azure SDK.
2. As opções de conversão aparecem no relatório de assessment e no plano de modernização.
3. Você aceita as opções sugeridas ou ajusta o mapeamento conforme a arquitetura do seu projeto.
4. O agente converte as chamadas identificadas para as APIs equivalentes do AWS SDK.
5. A ferramenta valida que as mudanças foram de fato incorporadas ao código transformado.

Esse controle humano no meio do processo importa porque nem toda chamada de Azure SDK tem correspondência 1:1 em AWS: parâmetros de consistência, políticas de retry e modelos de particionamento costumam divergir entre os dois provedores, e é nesse ponto que o plano de modernização dá ao engenheiro a chance de revisar antes de rodar a conversão.

Quais serviços o agente já converte

A cobertura anunciada mistura recursos já em disponibilidade geral com um recurso ainda em preview:

A conversão de Cosmos DB para DynamoDB ficar em preview faz sentido dado o tamanho do salto: Cosmos DB suporta múltiplos modelos de consistência e APIs (SQL, MongoDB, Cassandra, Gremlin), enquanto o DynamoDB tem um modelo próprio de chaves e índices. É a peça do mapeamento com mais chance de exigir ajuste manual depois da conversão automática, mesmo quando ela sai do preview.

Onde o recurso está disponível, e onde não está

O AWS Transform com essa capacidade de conversão Azure-to-AWS está em oito regiões: US East (N. Virginia), Ásia-Pacífico (Mumbai, Tóquio, Seul, Sydney), Canadá (Central) e Europa (Frankfurt, Londres).

São Paulo (sa-east-1) não está na lista. Para times brasileiros que querem usar o recurso hoje, isso significa rodar a avaliação e a conversão de código a partir de uma dessas oito regiões suportadas, mesmo que a aplicação final em AWS vá ser implantada em sa-east-1 depois de migrada. O código convertido não fica preso à região onde a conversão rodou, mas o fluxo do AWS Transform em si precisa de uma das regiões da lista para operar.

O que isso muda para quem migra do Azure

Para arquitetos e engenheiros de migração que lidam com aplicações .NET cloud-native no Azure, o anúncio reduz uma etapa que normalmente virava um projeto à parte: reescrever a camada de integração com serviços gerenciados do Azure antes mesmo de tocar na lógica de negócio.

Isso não elimina a necessidade de revisão humana. O próprio fluxo do AWS Transform reserva um passo explícito para aceitar ou ajustar as opções de conversão, o que indica que a AWS trata o resultado como ponto de partida, não como entrega final pronta para produção. Testes de carga, validação de custo no novo modelo de cobrança (Lambda e DynamoDB cobram de forma bem diferente de Azure Functions e Cosmos DB) e revisão de segurança continuam sendo trabalho de quem conduz a migração.

Vale também observar o que o anúncio não cobre: serviços de mensageria mais avançados do Azure (como Service Bus), bancos relacionais gerenciados (Azure SQL Database) ou identidade (Azure AD/Entra ID) não aparecem na lista de conversões suportadas nesta GA. Quem tem esses componentes na arquitetura ainda precisa planejar essa parte da migração separadamente.

Para começar, a documentação do recurso está no guia Convert cloud-native code to AWS, dentro do AWS Transform User Guide.

Fonte: AWS What's New