Amazon Q Developer para o Kiro: o que muda com o fim do suporte e como migrar o time

A AWS anunciou, em 30/04/2026, que os plugins de IDE e as assinaturas pagas do Amazon Q Developer chegam ao fim do suporte em 30/04/2027 e que novos cadastros deixam de ser aceitos a partir de 15/05/2026. O sucessor indicado é o Kiro, a IA agêntica da AWS para desenvolvimento de software. As transformações de código feitas pelos plugins (upgrade de Java e porte de .NET) passam para o AWS Transform.

Verificado contra o aviso de fim de suporte, o guia de migração do Kiro e as perguntas frequentes do Amazon Q Developer na atualização de 15/10/2026, quando entrou a seção sobre as assinaturas do Q Developer Pro.

O prazo é longo o bastante para uma transição planejada e curto o bastante para não caber num trimestre de improviso. A troca de ferramenta também é a ocasião para mudar o que o plugin não guardava: as regras do time, que viviam em arquivos espalhados ou na cabeça de cada dev, passam a ficar no repositório, como steering, e o trabalho com o agente passa a ter spec revisada. Para a visão geral do produto, o ponto de partida é o guia do Kiro.

O que a AWS anunciou e quando?

O aviso de fim de suporte, publicado no blog de DevOps da AWS em 30/04/2026, traz três datas. A página de fim de suporte do guia do usuário repete a data final e aponta o guia de migração no kiro.dev.

O que muda e o que continua?

Muda o trabalho dentro da IDE. Continuam as experiências do Amazon Q fora dela: o aviso informa que o Console de Gerenciamento da AWS, os sites de documentação e de marketing da AWS, o app móvel do console e o Amazon Q Developer no Slack e no Microsoft Teams não são afetados.

• Plugins de IDE: substituídos pelo Kiro. A documentação da AWS afirma que sugestões inline, chat e geração de código estão disponíveis no Kiro.
• Amazon Q Developer CLI: já virou Kiro CLI. Segundo o guia de upgrade da CLI, a Kiro CLI foi lançada em 17/11/2025, e os comandos q e q chat continuam funcionando, com kiro-cli como entrada recomendada.
• Transformação de código: o aviso indica o AWS Transform custom para upgrade de runtime Java, migração de SDK e troca de framework, e o AWS Transform para modernização de Windows para o porte de .NET Framework. A recomendação é concluir as transformações em andamento antes de 30/04/2027.

O Kiro faz tudo o que o plugin fazia?

Depende do editor. Em VS Code, sim: a Kiro IDE substitui o plugin no uso diário, segundo a AWS. Em JetBrains, o Kiro chega pela Kiro CLI, conectada ao AI Assistant via Agent Client Protocol (ACP). Em Visual Studio e Eclipse não há equivalente nativo, e o trabalho passa para a Kiro IDE ou a Kiro CLI ao lado do editor. Nos recursos, o guia de migração publica uma tabela em que o plugin tem MCP e o Kiro acrescenta steering, hooks, subagentes e skills, Powers, lista de comandos permitidos e negados no terminal e spec-driven development.

A linha de specs é o ponto em que a documentação diverge. O guia de migração marca spec-driven development só na Kiro IDE, mas a documentação de specs, na tabela de disponibilidade, lista specs de funcionalidade, de correção e Quick Spec na IDE, na CLI e na web. Quando duas páginas da documentação divergirem, vale a página do recurso, e vale testar na versão instalada.

Como migrar cada perfil de usuário?

Depende do editor. Quem usa VS Code instala a Kiro IDE e importa o perfil. Quem usa JetBrains mantém a IDE e conecta o Kiro pelo AI Assistant. Quem usa Visual Studio ou Eclipse passa a trabalhar com a Kiro IDE ou a Kiro CLI ao lado do editor. Quem usa a CLI recebe a migração da configuração na instalação.

O que acontece com regras, prompts e MCP da CLI?

O guia de upgrade da CLI descreve uma cópia feita uma vez, na instalação. As regras viram steering, os agentes e prompts mudam de pasta e a configuração MCP é copiada, pulando servidores em conflito.

# Usuário (cópia única na instalação)
~/.aws/amazonq/cli-agents/   ->  ~/.kiro/agents/
~/.aws/amazonq/prompts/      ->  ~/.kiro/prompts/
~/.aws/amazonq/rules/        ->  ~/.kiro/steering/
~/.aws/amazonq/mcp.json      ->  ~/.kiro/settings/mcp.json   # servidores em conflito não são copiados
configuração da Q CLI        ->  ~/.kiro/settings/cli.json

# Workspace (no repositório)
.amazonq/rules/              ->  .kiro/steering/
.amazonq/mcp.json            ->  .kiro/settings/mcp.json

Três detalhes do guia pesam na revisão:

• Pastas duplicadas. A Kiro CLI não altera as pastas .amazonq existentes. Se o projeto tiver as duas, a configuração vem de .kiro e um aviso aparece no início da sessão. Depois de migrar, remova .amazonq por pull request para não manter duas fontes de verdade.
• Agente padrão. O agente padrão passou a se chamar kiro_default e lê tanto as regras do Amazon Q quanto o steering do Kiro, o que esconde regra antiga ainda em vigor.
• Volta atrás. Prompts, agentes e steering criados na Kiro CLI não aparecem na Amazon Q Developer CLI. A licença também muda, de Apache para a AWS Intellectual Property License.

A cópia é mecânica: regra que estava desatualizada continua desatualizada, agora como steering. Trate a migração como revisão. Cada regra copiada passa pelo mesmo critério de qualquer arquivo de steering, descrito em Steering no Kiro.

O que muda para a administração da empresa?

As assinaturas passam a ser geridas no console do Kiro, que aparece como serviço no Console de Gerenciamento da AWS. Segundo os conceitos de Enterprise da documentação, as identidades ficam no IAM Identity Center e cada perfil do Kiro corresponde a uma conta AWS em uma região.

• Assinatura por usuário. Assinar um grupo do IAM Identity Center assina cada usuário individualmente; a documentação diz que não existe assinatura de grupo.
• Região do perfil. Os dados ficam e a inferência roda na região do perfil. A página de regiões suportadas lista US East (N. Virginia) e Europe (Frankfurt) nas regiões comerciais, o que entra na avaliação de LGPD como transferência internacional.
• Consumo acima da cota. No Enterprise, a página de preços informa que o excedente começa desabilitado e é o administrador quem habilita.

Assinaturas do Q Developer Pro

A troca de assinatura é uma decisão sem volta e precisa de dono. O guia de upgrade do Kiro informa que o upgrade é feito por usuário, e que o administrador pode mover usuários individuais, grupos ou perfis inteiros da aba de assinaturas do Q para o Kiro. As perguntas frequentes do Amazon Q Developer completam o quadro:

• Upgrade em lote, sem volta. É possível selecionar vários usuários e grupos, escolher o plano de cada um e fazer o upgrade de uma vez. Depois do upgrade, o cliente não pode voltar para a assinatura Q Developer Pro.
• Outra métrica de uso. O Q Developer Pro mede por número de requisições, sem possibilidade de habilitar excedente. O Kiro mede por créditos, com excedente que o administrador decide habilitar.
• Cancelamento à parte. O painel do Kiro mostra as assinaturas do Kiro e do Q Developer separadamente, e o guia do usuário do Q Developer descreve o cancelamento da assinatura antiga como um passo próprio, no console do Kiro (Settings, Other applications). Confira na fatura seguinte que só a assinatura nova ficou ativa.
• Uso de conteúdo. Segundo o guia de upgrade, quem tem assinatura Q Developer Pro e acessa o Kiro pela conta AWS não tem o conteúdo usado para melhoria do serviço.

Como planejar a transição?

Em cinco passos, com um repositório piloto antes do time inteiro. Inventário, piloto, revisão das regras migradas, perímetro de permissões e desligamento do plugin com data marcada, bem antes do prazo da AWS.

1. Inventário. Quem usa o plugin e em qual editor, quem usa a CLI, quais transformações de código estão em andamento e quais servidores MCP estão configurados.
2. Piloto. Um repositório com testes automatizados e um time pequeno, nos editores que o time de fato usa, incluindo JetBrains, Visual Studio ou Eclipse se houver.
3. Revisão das regras. As regras copiadas para .kiro/steering/ entram por pull request, com dono, e o que estiver vencido sai.
4. Perímetro. .kiroignore, regras de permissão e lista de servidores MCP aprovados antes de liberar o agente para o time. O método está em Governança de IA no código.
5. Desligamento. Data interna para remover o plugin e as pastas .amazonq, com as transformações de código já concluídas ou levadas ao AWS Transform e a assinatura do Q Developer Pro cancelada depois do upgrade.

## Transição do Amazon Q Developer para o Kiro

- [ ] Inventário: editores, usuários da CLI, transformações em andamento, servidores MCP
- [ ] Transformações de código concluídas ou planejadas no AWS Transform
- [ ] Repositório piloto escolhido (com testes e dono)
- [ ] Regras migradas revisadas em .kiro/steering/ por pull request
- [ ] .amazonq/ removido do repositório depois da revisão
- [ ] .kiroignore e regras de permissão definidos
- [ ] Servidores MCP aprovados, com ferramentas de leitura no início
- [ ] Região do perfil registrada na avaliação de LGPD
- [ ] Excedente de créditos: decisão do administrador registrada
- [ ] Upgrade das assinaturas Q Developer Pro (por usuário ou em lote, sem volta) com dono definido
- [ ] Assinatura do Q Developer Pro cancelada no console e conferida na fatura
- [ ] Data interna de desligamento do plugin, antes de 30/04/2027

Quais armadilhas evitar?

• Trocar a ferramenta e manter o hábito. Usar o Kiro só como chat com outro nome deixa de fora steering, specs e hooks, que são o motivo da troca. A primeira spec revisada é o marco que mostra a diferença; o método está em Specs no Kiro.
• Migrar regra sem ler. A cópia automática preserva regra vencida e conflito entre regras. A revisão por pull request é o filtro.
• Deixar a transformação de código para o fim. Upgrade de Java e porte de .NET pelos plugins acabam na mesma data do suporte. O caminho no AWS Transform está em Modernização de aplicações com IA na AWS.
• Esquecer o editor minoritário. Quem usa Visual Studio ou Eclipse fica sem plugin nativo. Planeje o fluxo desse grupo no piloto, não na última semana.

A escolha do Kiro no lugar de outra categoria de ferramenta, e o raio de ação de cada uma, está em IA agêntica no desenvolvimento de software. Para o uso de IA generativa nas outras etapas do ciclo, veja IA generativa no SDLC com Amazon Bedrock.

Perguntas frequentes

Quando termina o suporte do Amazon Q Developer?

Em 30/04/2027, para os plugins de IDE e as assinaturas pagas, segundo o aviso publicado pela AWS em 30/04/2026. Novos cadastros deixaram de ser aceitos em 15/05/2026.

O Amazon Q no console da AWS também acaba?

Não, segundo o aviso. As experiências no Console de Gerenciamento da AWS, nos sites da AWS, no app móvel do console e no Slack e no Microsoft Teams não são afetadas.

Minhas regras da Amazon Q Developer CLI vão para o Kiro?

Sim. Segundo o guia de upgrade da CLI, a instalação copia as regras para a pasta de steering, os agentes e prompts para as pastas do Kiro e a configuração MCP, pulando servidores em conflito. A cópia é feita uma vez e não altera as pastas originais.

Como fica o upgrade de Java que eu fazia pelo plugin?

O aviso indica o AWS Transform custom para upgrades de Java, migração de SDK e troca de framework, e o AWS Transform para modernização de Windows para o porte de .NET Framework. A recomendação é concluir as transformações em andamento antes de 30/04/2027.

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.