Modernização de aplicações com IA na AWS: quando usar AWS Transform, quando usar specs no Kiro e como combinar os dois

Na modernização de aplicações com IA na AWS, o AWS Transform aplica a mesma mudança repetível em muitos repositórios, e o Kiro, a IA agêntica da AWS para desenvolvimento de software, conduz as mudanças que exigem decisão de domínio. Use o primeiro quando a mudança pode ser descrita uma vez e aplicada igual em todo lugar; use uma spec no Kiro quando cada sistema pede uma decisão própria.

O AWS Transform cobre upgrade de versão de linguagem, troca de SDK e migração de framework, rodando uma definição de transformação em lote. O Kiro trabalha com uma spec revisada pelo time, steering com os padrões do sistema alvo e hooks que rodam testes a cada tarefa. Combinados, o primeiro trata a dívida técnica mecânica e o segundo executa a refatoração que só quem conhece o negócio consegue especificar.

A distinção importa porque os dois tipos de trabalho falham de jeitos diferentes. Uma troca de versão mal aplicada quebra o build e aparece cedo. Uma regra de negócio alterada por engano passa no build, passa no teste superficial e aparece no fechamento do mês. O método de cada ferramenta foi desenhado para um desses riscos.

Migrar e modernizar não são a mesma coisa

Migrar é levar a carga de trabalho para a AWS; modernizar é mudar o código ou a arquitetura para operar melhor no destino. As duas coisas podem acontecer juntas ou em momentos separados, e a escolha define o risco do projeto.

O guia de migrações de grande porte da AWS organiza as estratégias nos 7 Rs: retire, retain, rehost, relocate, repurchase, replatform e refactor (ou re-architect). Dois deles envolvem mudança no software:

• Replatform (lift, tinker and shift): a aplicação vai para a nuvem com algum nível de otimização, como trocar um SQL Server próprio pelo Amazon RDS for SQL Server ou portar .NET Framework para .NET multiplataforma para rodar em Linux.
• Refactor (re-architect): a arquitetura muda para aproveitar recursos nativos da nuvem. O guia chama essa estratégia de a mais complexa e a mais cara, e recomenda, em migrações grandes, fazer rehost, relocate ou replatform primeiro e modernizar depois que a migração terminar.

Essa recomendação define onde a IA entra. Em boa parte dos portfólios, a modernização acontece em duas frentes: a dívida de versão (linguagem, framework, SDK e dependências desatualizados, a mesma mudança em muitos repositórios) e a dívida de desenho (fronteiras de domínio, acoplamento, dados compartilhados, uma decisão diferente em cada sistema). A primeira frente tem padrão; a segunda tem regra de negócio. O roteiro de fases da migração está no passo a passo de migração para a AWS e no guia de migração da RFX.

AWS Transform: o que cada variante cobre

A documentação do AWS Transform o descreve como um serviço que acelera a transformação de infraestrutura, aplicações e código com uma experiência de IA agêntica. Ele reúne agentes especializados por tipo de trabalho.

AWS Transform custom: código, bibliotecas e frameworks

O AWS Transform custom faz modernização de software em larga escala para reduzir dívida técnica. A documentação lista os padrões cobertos, cada um com uma classificação de complexidade:

• Upgrade de versão de linguagem (complexidade baixa a média): Java 8 para 17, Python 3.9 para 3.13, Node.js 12 para 22.
• Migração de API e serviço (média): AWS SDK v1 para v2, Boto2 para Boto3, JUnit 4 para 5, javax para jakarta.
• Upgrade de framework (média): Spring Boot 2.x para 3.x, React 17 para 18.
• Troca de framework (alta): Angular para React, Vue.js para React.
• Refatoração e modernização de padrões (baixa a média): troca de print por framework de log, instrumentação de observabilidade.
• Migração de arquitetura (média a alta): x86 para AWS Graviton, servidor tradicional para contêiner.
• Tradução entre linguagens (muito alta): Java para Python, C para Rust.
• Transformações próprias da organização (variável): migração de biblioteca interna, padrões de código da empresa.

O mesmo conjunto de transformações roda por quatro interfaces, segundo o guia de primeiros passos: a CLI atx, para terminal, scripts e automação; a Kiro Power, para um fluxo conversacional no Kiro IDE; o agent plugin, para agentes de código de terceiros; e o plugin de IDE para VS Code e editores compatíveis com Open VSX. Para o setup guiado, a documentação recomenda a Kiro Power ou o agent plugin, que verificam os pré-requisitos e instalam ou atualizam a CLI. A aplicação web do AWS Transform é opcional e serve de painel para acompanhar campanhas de transformação em muitos repositórios.

A unidade de trabalho é a definição de transformação, representada como uma skill: um SKILL.md com frontmatter YAML (name e description) e as instruções, uma pasta opcional references/ com documentação (só arquivos de texto, até 10 MB no total) e uma pasta opcional scripts/. As definições publicadas ficam no registry da conta AWS, versionadas e compartilháveis com quem tem permissão IAM; rascunhos salvos com atx custom def save-draft expiram em 30 dias, segundo a referência de comandos.

A documentação descreve um fluxo em quatro fases: definir a transformação com linguagem natural, documentação e exemplos de código; pilotar em codebases de amostra, fase que também serve para estimar custo e esforço; executar em escala pela CLI, com desenvolvedores revisando os resultados; e monitorar e revisar as lições aprendidas. Essas lições são extraídas automaticamente das execuções anteriores (trajetória, feedback e correções) e aplicadas nas próximas; o comando atx custom def learnings abre a revisão, com opção de arquivar ou excluir lição ruim. É o material de referência que você fornece somado ao que o agente aprende rodando.

Uma definição própria segue a estrutura que a documentação recomenda: escopo claro, o que não pode mudar e critério de saída verificável. Exemplo para migrar uma biblioteca interna:

---
name: cliente-http-v2
description: Migra chamadas da biblioteca interna http-corp 1.x para a 2.x em
  serviços Java com Maven. Use em repositórios que declaram
  com.exemplo:http-corp 1.x no pom.xml.
---

# Migração do cliente HTTP interno para a versão 2

## Critérios de entrada
- O pom.xml declara com.exemplo:http-corp em versão 1.x.

## Escopo
- Código em src/main/java e src/test/java.
- Fora do escopo: target/, código gerado e dependências vendorizadas.

## Passos
1. Atualizar a dependência para a versão indicada em
   references/http-corp-v2.md.
2. Substituir HttpCorpClient.get(url) por
   HttpCorpClient.request(Request.get(url)).
3. CRITICAL: manter timeout e política de retentativa explícitos em
   cada chamada migrada.
4. Não alterar regra de negócio, contrato de API nem esquema de banco.

## Critérios de saída
1. "mvn -B verify" termina com sucesso.
2. Nenhuma chamada a HttpCorpClient.get permanece no código.
3. A suíte de caracterização passa sem alteração nos testes.

O marcador CRITICAL: e o comando escrito por extenso entre aspas seguem as boas práticas de criação de transformações, que também recomendam começar por transformações simples, testar em várias codebases de amostra antes de publicar e usar comandos de build e validação determinísticos para o aprendizado contínuo funcionar.

Para os casos comuns, há transformações gerenciadas pela AWS, como AWS/java-version-upgrade e AWS/java-aws-sdk-v1-to-v2, listadas no catálogo de transformações gerenciadas. O catálogo muda com frequência e marca parte delas como acesso antecipado; antes de montar uma esteira, rode atx custom def list para confirmar o nome exato no seu registry. Elas não podem ser editadas, mas aceitam contexto adicional pelo arquivo de configuração. No upgrade de Java, a versão alvo vai no additionalPlanContext:

buildCommand: mvn -B clean verify
additionalPlanContext: |
  Versão alvo: Java 17.
  Manter o framework de log interno na versão atual.
  Não alterar contratos de API nem esquema de banco.
validationCommands: |
  mvn -B test -Pcaracterizacao

Os campos buildCommand, additionalPlanContext e validationCommands estão no exemplo oficial da página de fluxos de trabalho. A CLI atx exige Node.js 22 ou superior e Git, e o diretório precisa ser um repositório Git: a transformação grava commits intermediários de checkpoint, revisáveis com git log e git diff.

Windows, mainframe e migrações

• Windows: a página do AWS Transform para Windows cobre .NET Framework para .NET multiplataforma (projetos MVC, WCF, Web API e console), SQL Server para Amazon Aurora PostgreSQL com conversão de esquema e de stored procedures, ASP.NET Web Forms para Blazor e refatoração para compatibilidade com Linux.
• Mainframe: a documentação de mainframe cobre aplicações z/OS em COBOL e PL/I, com JCL, CICS, BMS, Db2 e VSAM, além de Fujitsu GS21. O agente analisa, gera documentação, extrai lógica de negócio, decompõe o monólito e refatora COBOL para Java, solicitando aprovação humana em artefatos intermediários como a decomposição em domínios e o plano de ondas.
• Migrações (VMware e outros): descoberta de inventário, planejamento de ondas, criação de landing zone, conversão de rede, rehost de servidores para Amazon EC2 e conteinerização a partir do código-fonte. É a frente de migração, anterior à modernização de código.

Preço

Segundo a página de preços do AWS Transform, com valores revisados na atualização de 15/10/2026: o agente custom cobra por minuto de agente, US$ 0,035 por minuto, com incremento mínimo de 1 minuto, contando só o trabalho ativo do agente (build local e tempo ocioso ficam fora). A transformação .NET gerenciada pela AWS no agente custom inclui até 50.000 minutos de agente por mês sem custo adicional, sem acúmulo para o mês seguinte. Os agentes de Windows, VMware e mainframe aparecem como gratuitos, com a ressalva de que capacidades futuras podem ser pagas. Os recursos que a modernização cria na sua conta seguem o preço normal de cada serviço. Como a cobrança é em dólar, o câmbio entra no orçamento; confira a página antes de fechar qualquer estimativa.

Specs no Kiro para o que é específico do seu sistema

Extrair um domínio de um monólito, mudar a fronteira de dados entre dois módulos ou trocar a forma como um cálculo é orquestrado exige decisões que nenhuma definição genérica conhece. Para esse trabalho, a ferramenta é uma spec no Kiro, com três peças trabalhando juntas. O modelo de trabalho por trás delas, com o desenvolvedor revisando cada fase, está no post sobre IA agêntica no desenvolvimento de software.

Spec Design-First quando a arquitetura alvo já foi decidida

A documentação de Feature Specs descreve o fluxo Design-First como começar pelo desenho técnico (arquitetura ou desenho de baixo nível) e derivar dele requisitos viáveis e tarefas. Os cenários listados incluem ter uma arquitetura em mente, precisar cumprir requisitos não funcionais estritos (latência, vazão, conformidade) e portar documentos de desenho de outras ferramentas. É o caso típico de refatoração: o ADR já escolheu o padrão alvo, e a spec transforma essa decisão em tarefas rastreáveis.

O fluxo Requirements-First, descrito na mesma página, parte do comportamento que o sistema precisa ter e deixa a implementação se adaptar. Na modernização, ele serve quando o time sabe o comportamento alvo, mas ainda não escolheu o desenho. Uma regra prática: se existe ADR aprovado, Design-First; se o comportamento está claro e o desenho não, Requirements-First, com o ADR escrito antes da fase de tarefas.

A qualidade da spec depende do primeiro prompt. Ele precisa trazer o escopo, o que não pode mudar e o critério de saída, com os arquivos de referência citados pelo caminho:

Crie uma spec Design-First chamada extracao-faturamento.

Desenho de partida: docs/adr/0012-extracao-faturamento.md (strangler fig).

Escopo:
- Extrair o cálculo de faturamento do monólito para o módulo
  faturamento-core, atrás da interface FaturamentoPort.
- Fora do escopo: emissão de nota, cadastro de clientes, esquema
  de banco e qualquer arquivo fora de **/faturamento/**.

O que não pode mudar:
- Arredondamento e ordem de aplicação de descontos e impostos.
- Formato do arquivo de remessa do fechamento.
- Contrato das APIs públicas do monólito.

Critério de saída de cada tarefa:
- "mvn -B test -Pcaracterizacao" verde, sem alterar os testes de
  caracterização.

Antes de gerar as tarefas, liste as dúvidas sobre o desenho e
os pontos do ADR que você considera inviáveis.

Durante a refatoração, a spec e o código vão divergir: o time descobre uma dependência escondida, uma regra que o ADR não previa, um contrato que não pode mudar. A divergência se resolve na spec, não só no código. Segundo as boas práticas de specs, no fluxo Design-First a mudança de arquitetura entra no desenho e o Kiro valida e regenera os requisitos; depois, a opção Sync Files cria as tarefas que correspondem aos requisitos novos. Se o desenho mudou, o ADR muda no mesmo PR.

Para extrair um domínio de forma incremental, o padrão strangler fig, descrito no guia de padrões de nuvem da AWS, substitui funcionalidades aos poucos, com uma camada de proxy que roteia para o sistema antigo ou para o novo e uma camada anticorrupção que traduz as chamadas internas do monólito. O design.md registra isso e, principalmente, o comportamento que precisa continuar igual:

# Desenho: extração do cálculo de faturamento (Design-First)

## Contexto
- ADR vigente: docs/adr/0012-extracao-faturamento.md (strangler fig).
- Linha de base: latência e taxa de erro do fechamento, registradas
  antes da mudança no painel de observabilidade.

## Arquitetura alvo
- Interface FaturamentoPort no módulo novo faturamento-core.
- FaturamentoAdapter no monólito: camada anticorrupção que traduz
  as chamadas antigas para a interface nova.
- Roteamento pela feature flag faturamento.novo, desligada por padrão.

## Comportamento que não pode mudar
- Arredondamento e ordem de aplicação de descontos e impostos.
- Formato do arquivo de remessa gerado no fechamento.
- Coberto pela suíte src/test/java/caracterizacao/faturamento.

## Estratégia de teste
- A suíte de caracterização roda contra o caminho antigo e o novo,
  com a mesma massa de entrada.
- Comparação de saídas em modo sombra antes de ligar a flag.

## Rollback
- Desligar a flag faturamento.novo. Nenhum dado migrado nesta fase.

Os requisitos derivados desse desenho viram critérios no formato EARS, inclusive os negativos: "IF o caminho novo produzir saída diferente da registrada pela suíte de caracterização, THEN THE SYSTEM SHALL manter o resultado do caminho antigo e registrar a divergência". O passo a passo de revisão de cada arquivo está no post sobre specs no Kiro.

Steering com os padrões do sistema alvo

A spec descreve um incremento; o steering guarda as regras que valem para todos os incrementos da modernização. Com inclusão fileMatch, a regra só entra no contexto quando o agente mexe nos arquivos do módulo, e a referência #[[file:...]] aponta para o ADR, conforme a documentação de steering:

---
inclusion: fileMatch
fileMatchPattern: ["**/faturamento/**", "**/caracterizacao/faturamento/**"]
---

# Modernização do módulo de faturamento

Arquitetura alvo: #[[file:docs/adr/0012-extracao-faturamento.md]]

- O monólito chama o módulo novo só por FaturamentoAdapter.
- Código novo não importa pacotes br.com.exemplo.legado.
- Valores monetários em centavos, tipo long. BigDecimal só na borda da API.
- Comportamento coberto pela suíte de caracterização continua igual.
  Mudança intencional atualiza o teste no mesmo PR, com justificativa.
- Dependência nova só com ADR.

Como montar o restante do steering do repositório (produto, stack e estrutura) está no post sobre steering no Kiro.

Hooks que rodam os testes de caracterização a cada tarefa

O gatilho Post Task Execution dispara depois de cada tarefa de spec, na IDE e na CLI V3, segundo a página de tipos de hook. Ações do tipo command rodam na raiz do projeto com tempo limite padrão de 60 segundos, ajustável pelo campo timeout, conforme a documentação de hooks. Suíte de caracterização costuma ser mais lenta que a unitária, então o ajuste é necessário:

{
  "version": "v1",
  "hooks": [
    {
      "name": "caracterizacao-apos-tarefa",
      "description": "Roda a suíte de caracterização ao fim de cada tarefa da spec",
      "trigger": "PostTaskExec",
      "timeout": 600,
      "action": {
        "type": "command",
        "command": "mvn -B -q test -Pcaracterizacao"
      }
    }
  ]
}

O valor de timeout do exemplo é ilustrativo: meça a duração real da suíte e defina o teto com folga. Os demais gatilhos, como a verificação antes de cada ferramenta, estão no post sobre hooks no Kiro.

As duas ferramentas também se encontram no mesmo ambiente. A documentação de ferramentas de desenvolvimento do AWS Transform descreve uma Kiro Power que dá acesso aos agentes do AWS Transform a partir do Kiro IDE, instalada pelo painel Powers, e que instala o servidor MCP do AWS Transform automaticamente. Segundo a documentação de Powers, uma Power é ativada por palavras-chave da conversa, e o Kiro carrega o contexto e as ferramentas dela só quando o assunto aparece.

Sem a Power, o servidor MCP pode ser configurado à mão. A mesma página do AWS Transform traz a configuração para o Kiro, com o pacote awslabs.aws-transform-mcp-server do PyPI, que exige Python 3.10 ou superior. O exemplo abaixo acrescenta o bloco env com o perfil AWS, opção que a documentação indica para autenticação por papel IAM:

{
  "mcpServers": {
    "awslabs.aws-transform-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.aws-transform-mcp-server@latest"],
      "env": {
        "AWS_PROFILE": "modernizacao-piloto"
      }
    }
  }
}

Dois ajustes de governança antes de levar isso ao time. Primeiro, @latest busca a versão mais recente a cada inicialização; em ambiente controlado, fixe a versão e atualize por PR. Segundo, a configuração de MCP do Kiro aceita os campos autoApprove e disabledTools; deixe fora da aprovação automática as ferramentas que criam ou alteram jobs, e evite "*". A configuração existe no nível do usuário e no nível do workspace (.kiro/settings/mcp.json), e o workspace prevalece quando os dois existem. O desenho completo de permissões de servidores MCP está no post sobre MCP no Kiro.

Decisão: Transform, Kiro ou os dois

A pergunta que decide é se a mudança pode ser descrita uma vez e aplicada igual em todo lugar. Se pode, é trabalho de transformação. Se cada sistema exige uma decisão própria, é trabalho de spec.

Os dois entram juntos quando o portfólio tem as duas dívidas, o que é comum em sistemas com anos de produção: o upgrade de versão e de dependências vai primeiro, em lote, e deixa a base estável para a refatoração de domínio, que vem depois com spec.

Fluxo combinado em cinco passos

Cada passo tem um entregável e um critério de saída. Passo sem critério de saída cumprido não libera o seguinte.

1. Inventário e priorização

Levante, por repositório: linguagem e versão, framework, ferramenta de build, cobertura de teste, criticidade, dono e estratégia dos 7 Rs. O AWS Transform custom aceita definições da categoria analysis, que só leem o código e reportam achados com arquivo, linha, categoria e severidade; a documentação traz como exemplo um detector de projetos Java abaixo da versão 17. O catálogo de transformações gerenciadas também tem uma categoria de análise de codebase, que produz relatórios sem alterar o código, com itens como AWS/comprehensive-codebase-analysis e, em acesso antecipado, AWS/modernization-readiness-analysis.

• Entregável: backlog de modernização com cada repositório classificado como dívida de versão, dívida de desenho, ambas ou candidato a retire.
• Critério de saída: todo repositório da onda tem dono, classificação e comando de build conhecido.

2. Testes de caracterização como rede de segurança

Teste de caracterização registra o comportamento atual do sistema, certo ou errado, para detectar qualquer mudança de comportamento. O termo foi popularizado por Michael Feathers no livro Working Effectively with Legacy Code. Na prática: capturar entradas e saídas reais de fluxos críticos e transformá-las em casos de teste.

@ParameterizedTest
@MethodSource("casosCapturados")
void fechamentoPermaneceIgual(CasoCapturado caso) {
    var saida = Fechamento.calcular(caso.entrada());
    assertEquals(caso.saidaRegistrada(), saida,
        () -> "divergência no caso " + caso.id());
}

static Stream<CasoCapturado> casosCapturados() {
    // massa anonimizada: nenhum dado pessoal real no repositório
    return CasoCapturado.carregar("caracterizacao/faturamento/casos.jsonl");
}

• Entregável: suíte de caracterização rodando no CI, com massa anonimizada.
• Critério de saída: a suíte cobre os fluxos críticos do inventário e dá o mesmo resultado em execuções repetidas.

3. AWS Transform em lote para versão e dependências

Primeiro o piloto, em um grupo pequeno de repositórios representativos, no modo interativo, revisando cada diff e curando as lições. Depois a escala, em modo não interativo. O script abaixo usa as opções documentadas na referência de comandos e a transformação AWS/java-version-upgrade, listada no catálogo de transformações gerenciadas, com a versão alvo definida no config/java-17.yaml mostrado antes:

#!/usr/bin/env bash
set -euo pipefail

export AWS_REGION=us-east-1   # Região suportada pelo AWS Transform custom
export ATX_GIT_COMMITTER_NAME="esteira-modernizacao"
export ATX_GIT_COMMITTER_EMAIL="esteira@exemplo.com.br"

while read -r repo; do
  git -C "$repo" switch -c modernizacao/java-17
  atx custom def exec \
    -n AWS/java-version-upgrade \
    -p "$repo" \
    -g file://config/java-17.yaml \
    -x -t \
    --limit 60   # teto de minutos de agente por repositório (valor ilustrativo)
  # o PR de cada repositório é aberto por outra etapa; revisão humana obrigatória
done < repos-onda-1.txt

Três detalhes da documentação pesam nesse desenho. Primeiro, -x (não interativo) e -t (confia em todas as ferramentas) foram feitos para CI e execução em lote, e a página de fluxos avisa que -t contorna a maior parte das proteções; quanto à lista alwaysPromptCommands do arquivo ~/.aws/atx/trust-settings.yaml, a documentação descreve os dois comportamentos (exigir permissão mesmo com -t e não ser aplicada em modo não interativo); em modo não interativo, trate a lista como não aplicada. Por isso o lote roda em ambiente isolado e descartável, sem credencial de produção. Segundo, --limit encerra a execução quando o teto de minutos de agente é atingido, e a conversa pode ser retomada com um teto maior. Terceiro, as variáveis ATX_GIT_COMMITTER_NAME e ATX_GIT_COMMITTER_EMAIL identificam quem assina os commits de checkpoint.

Para FinOps, a documentação permite etiquetar definições próprias com tags de alocação de custo e agrupar a cobrança no AWS Cost Explorer. Duas limitações documentadas: transformações gerenciadas pela AWS não aceitam tags, e a atribuição é por definição, não por execução nem por usuário. Para fazer showback por time, cada time precisa da própria definição.

• Entregável: um PR por repositório, com o relatório da transformação anexado.
• Critério de saída: build e suíte de caracterização verdes, diff revisado por um humano e lições do piloto revisadas antes da escala.

4. Spec no Kiro para a refatoração de domínio

Com a base atualizada, a refatoração de domínio entra pela spec Design-First, com o ADR referenciado no steering e o hook de caracterização ligado. Antes de executar, revise o tasks.md como se fosse um plano de PRs: cada tarefa precisa caber em um PR revisável e citar o requisito que atende. O botão Run all Tasks, descrito nas boas práticas de specs, executa as tarefas obrigatórias pendentes e agrupa as independentes em ondas concorrentes; numa refatoração de domínio, prefira executar tarefa por tarefa até a suíte de caracterização provar o caminho. Para repetir a revisão no pipeline, o post sobre o Kiro CLI no pipeline mostra a revisão de PR em modo headless.

• Entregável: spec aprovada por PR e uma sequência de PRs pequenos, um por tarefa.
• Critério de saída: todo requisito rastreado até uma tarefa, suíte de caracterização verde em cada tarefa e ADR atualizado se o desenho mudou.

5. Entrega progressiva com observabilidade antes e depois

O código novo entra desligado, atrás de feature flag, roda em modo sombra comparando saídas e só então recebe tráfego, em fatias. A comparação usa a linha de base registrada antes de qualquer mudança: latência por percentil, taxa de erro, saturação e custo por unidade de negócio. O desenho de métricas, logs e traces está no post sobre observabilidade na AWS, e o pipeline com etapas de aprovação, no post sobre CI/CD com GitHub Actions.

• Entregável: flag ligada para todo o tráfego e caminho antigo removido.
• Critério de saída: indicadores iguais ou melhores que a linha de base na janela combinada com o negócio, e rollback testado antes da virada.

Pré-requisitos que decidem o resultado

• Build reprodutível. Versões fixadas, lockfile versionado e build em contêiner. O AWS Transform custom valida o resultado com o comando de build, e o aprendizado contínuo depende de esse comando ser determinístico.
• Testes. Suíte de caracterização dos fluxos críticos, além dos testes unitários existentes. Em projetos grandes, considere o tempo limite padrão de comandos de shell da CLI, de 900 segundos, ajustável pela variável ATX_SHELL_TIMEOUT, segundo a página de fluxos de trabalho.
• Linha de base de desempenho e erro. Sem medição anterior, a pergunta "melhorou ou piorou?" fica sem resposta.
• ADR da arquitetura alvo. A spec Design-First parte de uma decisão registrada, com contexto, opções e trade-off.
• Well-Architected Review do alvo. Revisar o desenho de destino nos seis pilares antes de construir; o roteiro está no post sobre a Well-Architected Review.
• Acesso mínimo. A AWS oferece políticas gerenciadas separadas para executar transformações (AWSTransformCustomExecuteTransformations) e para gerenciá-las (AWSTransformCustomManageTransformations), e as definições têm ARN, o que permite restringir quais uma esteira pode executar. Em rede restrita, a CLI precisa alcançar os endpoints listados no guia de primeiros passos.
• Região e dados pessoais. A lista de Regiões do AWS Transform custom no guia de primeiros passos, revisada na atualização de 15/10/2026, não inclui São Paulo (sa-east-1), e a documentação de mainframe avisa que os dados podem ser processados em outra Região. Código-fonte em geral não é dado pessoal, mas fixtures, dumps de teste e logs versionados podem ser. Faça a varredura antes do lote e avalie a transferência internacional prevista no art. 33 da LGPD com o encarregado de dados.

Para quem vem do Amazon Q Developer

O aviso de fim de suporte do Amazon Q Developer informa que os plugins de IDE e as assinaturas pagas chegam ao fim do suporte em 30/04/2027, e que os upgrades de Java e o porte de .NET feitos pelos plugins deixam de ser acessíveis depois dessa data. O aviso recomenda concluir as transformações em andamento antes do prazo e indica o AWS Transform custom para upgrades de Java e o AWS Transform para modernização de Windows para o porte de .NET. Para o trabalho de IDE e CLI, o mesmo aviso aponta o Kiro; o passo a passo da troca, por editor, está em Amazon Q Developer para o Kiro, e a visão geral do produto, no guia do Kiro.

Na prática, quem usava a transformação de código do Q Developer leva o trabalho de upgrade para o AWS Transform custom (com a vantagem da execução em lote e do registry) e o trabalho de desenvolvimento para o Kiro. A adoção do Kiro pelo time, com steering, specs e governança, é o escopo da frente de adoção do Kiro da RFX.

Armadilhas e como evitar

• Modernizar sem teste. Build verde prova que compila; ele diz pouco sobre regra de negócio. Escreva a suíte de caracterização antes da primeira transformação e use-a como comando de validação no Transform e como hook no Kiro.
• Lote grande sem piloto. A fase de piloto existe para revelar casos de borda e estimar custo e esforço. Rode primeiro em poucos repositórios representativos, revise as lições aprendidas e só então escale, com --limit por execução.
• Aceitar diff sem revisão. Os commits de checkpoint deixam cada passo auditável; use isso. Um PR por repositório, revisor nomeado e atenção redobrada aos arquivos que o relatório marca como não validados. Lições ruins se propagam: arquive-as em atx custom def learnings e use -d nas execuções que não devem ensinar o agente.
• Confiar todas as ferramentas fora do ambiente isolado. -x -t em máquina com credencial de produção dá ao agente um alcance que a tarefa não pede. Lote em ambiente descartável, com papel IAM restrito à execução.
• Agente do Kiro alterando fora do escopo. Uma tarefa de refatoração toca arquivos vizinhos com facilidade. Declare no prompt de abertura o que está fora do escopo, mantenha o steering do módulo com inclusão fileMatch restrita às pastas da modernização e revise o tasks.md antes de executar, removendo tarefas que extrapolam o desenho. No PR, compare a lista de arquivos alterados com o escopo declarado.
• Steering inflado. Arquivos com inclusão always entram em toda interação, conforme a documentação de steering. Regra que só vale para um módulo vai em fileMatch, e o detalhe longo fica no ADR, referenciado por #[[file:...]] em vez de copiado.
• Hook lento segurando a tarefa. Um hook PostTaskExec que roda a suíte inteira a cada tarefa estoura o tempo limite ou deixa o ciclo lento demais para revisar. Meça a suíte, ajuste o timeout com folga e, se necessário, rode no hook só a caracterização do módulo afetado, deixando a suíte completa para o CI.
• Esquecer o custo de operar o alvo. A modernização muda a conta mensal: nova arquitetura, novos serviços, novo perfil de tráfego. Estime o custo de operação do alvo antes de aprovar o ADR e acompanhe por tags desde o primeiro deploy; o método está no post de FinOps na AWS.

O ponto de partida é o inventário: saber quais repositórios têm dívida de versão, quais têm dívida de desenho e quais têm teste suficiente para mudar com segurança. A partir dele, a escolha entre AWS Transform, spec no Kiro ou o fluxo combinado fica objetiva.

Perguntas frequentes

Qual a diferença entre AWS Transform e Kiro na modernização de aplicações?

O AWS Transform aplica transformações de código repetíveis em escala: a mesma definição de transformação, como um upgrade de versão de Java ou a troca do AWS SDK, roda em muitos repositórios pela CLI atx. O Kiro, a IA agêntica da AWS para desenvolvimento de software, conduz mudanças que dependem de decisão de domínio, com uma spec revisada pelo time, steering com os padrões do sistema alvo e hooks que rodam testes a cada tarefa.

Como o AWS Transform custom é cobrado?

Por minuto de agente, contando só o trabalho ativo do agente, conforme a página oficial de preços do AWS Transform. A CLI aceita a opção --limit, que define um teto de minutos de agente por execução, e o comando /usage mostra o consumo da sessão. Os agentes de Windows, VMware e mainframe aparecem como gratuitos na mesma página. Confira a página antes de orçar, porque preço e condições mudam.

Dá para usar o AWS Transform de dentro do Kiro?

Sim. A documentação do AWS Transform descreve uma Kiro Power que dá acesso aos agentes do AWS Transform a partir do Kiro IDE. A instalação é feita no painel Powers do Kiro, e a Power instala o servidor MCP do AWS Transform automaticamente.

As transformações de código do Amazon Q Developer continuam disponíveis?

Até 30 de abril de 2027. Segundo o aviso oficial de fim de suporte, os upgrades de Java e o porte de .NET feitos pelos plugins de IDE do Amazon Q Developer deixam de ser acessíveis depois dessa data. O aviso indica o AWS Transform custom para upgrades de Java e o AWS Transform para modernização de Windows para o porte de .NET, e recomenda concluir as transformações em andamento antes do prazo.

Preciso de testes antes de modernizar uma aplicação com IA?

Sim. Testes de caracterização, que registram o comportamento atual do sistema, são a rede de segurança de qualquer modernização. O AWS Transform custom usa um comando de build e validação para verificar o resultado e aprender entre execuções, e no Kiro um hook pode rodar a mesma suíte ao fim de cada tarefa da spec. Sem essa suíte, a revisão depende só da leitura do diff.

Sobre o autor

Rodrigo Araújo

Arquiteto de Soluções, IA e Cloud | RFX Tecnologia

Arquiteto de Soluções, IA e Cloud na RFX Tecnologia, lidera projetos de migração, FinOps e IA aplicada na nuvem para empresas do Nordeste e de todo o Brasil. É também o idealizador da Jornada de Inovação AWS em João Pessoa, encontro que aproxima donos de negócio da região das aplicações reais de cloud e inteligência artificial.