O problema: promoção manual entre contas é lenta e arriscada
O Amazon Quick é o assistente de inteligência artificial agêntico da Amazon voltado para o ambiente corporativo. Com ele, as equipes constroem agentes que raciocinam sobre dados internos, acionam conectores e executam tarefas em múltiplas etapas. O problema surge quando esses recursos — agentes de chat, conectores de ação, bases de conhecimento, fluxos e espaços — precisam ser promovidos de uma conta AWS de desenvolvimento para uma conta de produção.
A maioria das empresas mantém contas AWS separadas para desenvolvimento e produção, às vezes com um ambiente de garantia de qualidade (QA) no meio. Quando os recursos são validados no ambiente de desenvolvimento, não existe um mecanismo nativo de “um clique” para promovê-los à próxima conta. As equipes precisam recriar cada recurso manualmente: reconfigurar agentes com as mesmas instruções e prompts iniciais, reconectar os conectores de ação, reatribuir permissões e reprovisionar o bucket do Amazon Simple Storage Service (Amazon S3), sua política e a fonte de dados de cada base de conhecimento.
Esse processo é lento, difícil de auditar e fácil de errar em detalhes sutis — o que compromete exatamente a governança que as empresas precisam demonstrar.
A solução: Quick Resource Migrator via servidor MCP
A AWS publicou um guia detalhado apresentando o Quick Resource Migrator, um servidor MCP (Protocolo de Contexto de Modelo) de exemplo hospedado no runtime do Amazon Bedrock AgentCore. Ele automatiza a promoção de recursos do Amazon Quick entre contas em uma única chamada de ferramenta.
O funcionamento é direto: você escolhe um tipo de recurso (agente, conector, base de conhecimento, fluxo ou espaço) e seleciona pelo identificador, pelo nome ou todos de uma vez. O servidor lê o recurso e suas permissões via API do Amazon Quick Sight e os replica na conta de destino exatamente como estavam. O código-fonte completo está disponível no repositório aws-samples.
Dois princípios norteiam o design:
- Idempotência: o migrador nunca emite um comando de exclusão contra a conta de destino. Cada execução apenas cria ou atualiza recursos. Rodar o processo várias vezes converge sempre para o mesmo estado, sem duplicatas nem falhas.
- Reversibilidade segura: antes de atualizar qualquer recurso existente na conta de destino, o servidor grava um snapshot versionado desse recurso em um bucket S3 dedicado. Se esse backup não puder ser gravado, a atualização é abortada. Isso garante um histórico completo e a possibilidade de rollback.
O que é migrado e como
Agentes de chat
Recriados com suas instruções personalizadas, identidade, tom, prompts iniciais e mensagem de boas-vindas. Os conectores de ação são reanexados com os identificadores de recurso (ARNs) remapeados para a conta de destino. Quando um espaço é migrado, seus agentes são automaticamente revinculados a ele.
Conectores de ação
Recriados com sua configuração. Valores secretos nunca são lidos da conta de origem — os conectores são criados com credenciais temporárias e reautenticados na conta de destino.
Bases de conhecimento
A base de conhecimento é registrada na conta de destino, sua fonte de dados é recriada e as permissões são copiadas. Para bases apoiadas em S3, o migrador também provisiona o bucket de destino e sua política. Os documentos em si (objetos S3) não são copiados.
Fluxos
Recriados na conta de destino a partir de sua definição. Como os identificadores de fluxo diferem entre contas, o matching é feito pelo nome: um fluxo com o mesmo nome na conta de destino é atualizado; caso contrário, um novo é criado. As permissões são copiadas.
Espaços
Recriados na conta de destino e revinculados a seus agentes, conectores e bases de conhecimento, com ARNs remapeados. As permissões do espaço são copiadas. A recomendação é migrar os recursos vinculados primeiro, para que os ARNs de destino já existam quando o espaço for criado.
Princípios de design e segurança
A solução adota um modelo de três contas: uma conta runner central hospeda o servidor MCP no runtime do Amazon Bedrock AgentCore. Essa conta assume um papel somente leitura na conta de origem e um papel de leitura e escrita na conta de destino usando o Serviço de Token de Segurança da AWS (AWS STS) — nenhuma credencial de longa duração é armazenada em lugar algum.
O runtime autentica os chamadores com um Token Web JSON (JWT) do Amazon Cognito e pode operar em modo de rede de Nuvem Privada Virtual (VPC). O papel na conta de origem tem apenas permissões de leitura. O papel na conta de destino possui somente as ações necessárias para a migração — sem privilégios excessivos.
A tabela abaixo resume as responsabilidades de cada componente da arquitetura:
- Runtime AgentCore (conta runner): hospeda o servidor MCP, assume papéis nas contas de origem e destino e orquestra a migração.
- Amazon Cognito (conta runner): emite o JWT que os chamadores apresentam ao AgentCore.
- Papel de execução runner: permissões para Amazon CloudWatch Logs, telemetria e
sts:AssumeRolenas contas de origem e destino. - Papel migrador (conta de origem): permissões de leitura somente para o Quick Sight e bases de conhecimento.
- Papel migrador (conta de destino): permissões de criação e atualização no Quick Sight, escrita em bases de conhecimento e S3, e
ListUserspara resolução de principais. - Bucket de backup (conta runner): bucket S3 criptografado que armazena snapshots versionados dos recursos antes de cada atualização.
As cinco ferramentas expostas pelo servidor MCP
preview_migration (somente leitura)
Recebe o ID da conta de origem, o tipo de recurso, o seletor e a região AWS. Retorna um inventário do que seria migrado — nomes e tipos — sem realizar nenhuma alteração. Quando o ID da conta de destino também é informado, a resposta adiciona um mapeamento indicando se cada recurso seria criado (CREATE) ou atualizado (UPDATE). Ideal como passo de aprovação antes de qualquer promoção.
migrate_resources (migração completa)
Executa a migração completa de criação ou atualização e retorna um relatório estruturado de tudo o que foi criado, atualizado e concedido, além de eventuais erros. Por ser idempotente, pode ser executado em cada release.
list_backups (somente leitura)
Lista as versões disponíveis de cada recurso no catálogo de backups — os snapshots gravados antes de cada atualização.
get_backup (somente leitura)
Retorna o backup completo de um determinado recurso e versão (por padrão, a mais recente), incluindo a configuração capturada e suas dependências.
restore_backup
Reaaplica uma versão de backup salva sobre o recurso de destino, atualizando-o no lugar ou recriando-o se não existir mais. Antes de restaurar, captura um novo backup — tornando o próprio rollback reversível.
Fluxo de migração passo a passo
O processo segue esta sequência lógica:
- Resolução de recursos: a partir do tipo e do seletor, o servidor identifica os IDs concretos na conta de origem.
- Descrição da origem: cada recurso selecionado é descrito para capturar configuração e permissões.
- Conectores: recriados com configuração de autenticação sanitizada e credenciais temporárias.
- Bases de conhecimento: bucket de destino criado, política aplicada, fonte de dados e base de conhecimento provisionadas, permissões copiadas.
- Agentes: recriados com conectores de ação reanexados e permissões copiadas.
- Fluxos: recriados por nome, com permissões copiadas.
- Espaços: recriados e revinculados a agentes, conectores e bases de conhecimento com ARNs remapeados.
- Relatório: retorno em JSON com recursos criados, atualizados, buckets, backups, permissões ignoradas e erros.
Implantação e uso via Quick App
As instruções completas de implantação estão no README do repositório aws-samples. Em linhas gerais, são implantadas três stacks do AWS CloudFormation: os papéis de Gerenciamento de Identidade e Acesso (IAM) entre contas, a rede VPC e o runtime AgentCore autenticado pelo Cognito que hospeda o servidor MCP. Em seguida, esse runtime é registrado como um conector de ação no Amazon Quick.
Ao registrar o runtime como conector de ação, é possível acionar o migrador diretamente do Amazon Quick em linguagem natural. Também é possível construir um Quick App — uma experiência web guiada sobre as mesmas ferramentas MCP. O repositório inclui um prompt de construção do app pronto para uso: basta colá-lo no construtor de apps do Amazon Quick, substituindo os IDs de conector e ação pelos seus próprios.
O app gerado transforma o fluxo de trabalho em uma experiência guiada: escolha as contas de origem e destino e os recursos a promover, visualize o que será criado ou atualizado, execute a migração e revise o histórico completo de cada promoção passada — cada entrada respaldada pelos snapshots versionados gravados no S3.
Para fazer rollback, basta selecionar a versão de backup desejada e acionar a restauração. O app reaaplica aquela versão salva no recurso de destino. Como ele captura um novo backup antes de restaurar, o próprio rollback é reversível.
Conclusão
A promoção entre contas é uma expectativa básica para software corporativo, e até agora era justamente a peça que faltava no Amazon Quick. Com o Quick Resource Migrator, a AWS transforma uma tarefa lenta, manual e difícil de auditar em um processo rápido, repetível e governado: uma única chamada de ferramenta recria agentes, conectores e bases de conhecimento na conta de destino, copia permissões fielmente e faz tudo de forma idempotente — podendo ser executado a cada release.
Para quem quiser experimentar, o ponto de partida é clonar o repositório de exemplo, implantar em uma conta runner e testar a promoção de um agente ou base de conhecimento do desenvolvimento para a produção.
Fonte
Making Amazon Quick enterprise-ready: Automated, auditable cross-account resource promotion (https://aws.amazon.com/blogs/machine-learning/making-amazon-quick-enterprise-ready-automated-auditable-cross-account-resource-promotion/)
Leave a Reply