Preparar Amazon Quick para empresas: promoción automatizada y auditable de recursos entre cuentas

Amazon Quick es el compañero de IA agéntica de Amazon creado para el trabajo. Usted crea agents que razonan sobre sus datos, invocan action connectors y llevan tareas de varios pasos hasta su finalización. Promover esos recursos (chat agents, action connectors, knowledge bases, flows y spaces) de una cuenta de AWS de desarrollo a una de producción, como haría con cualquier otra aplicación, ha sido una tarea manual y propensa a errores. Esta publicación muestra cómo automatizarlo con un servidor de Model Context Protocol (MCP) idempotente y auditable en Amazon Bedrock AgentCore.

Los componentes básicos de una solución agéntica son sus agents, action connectors, knowledge bases y spaces: chat agents configurados con instrucciones personalizadas, connectors para Slack, Jira y otras integraciones, knowledge bases basados en sus propios documentos y el Space que los une. Los equipos los ensamblan e iteran sobre ellos rápidamente en una cuenta de desarrollo.

La mayoría de las empresas ejecutan cuentas de AWS separadas para desarrollo y producción, a veces con una de control de calidad (QA) en el medio. Cuando los agents, action connectors y knowledge bases se validan en una cuenta de desarrollo, no existe una forma nativa de un solo clic para promoverlos a la siguiente cuenta. Los equipos reconstruyen cada recurso a mano: recrean cada agent con las mismas instrucciones y starter prompts, vuelven a adjuntar los action connectors de cada agent, vuelven a otorgar permisos de recursos y reaprovisionan el bucket de Amazon Simple Storage Service (Amazon S3), la política del bucket y la fuente de datos detrás de cada knowledge base. El trabajo es lento, difícil de auditar y fácil de hacer mal de manera sutil, lo que socava la historia de gobernanza que las empresas necesitan.

Administrar los recursos de Amazon Quick mediante una API

Los recursos de Amazon Quick son programables. Los spaces, agents, action connectors, knowledge bases y flows se administran a través de la API de Amazon Quick (parte de la superficie de API de Amazon QuickSight), que proporciona el ciclo de vida completo de los recursos: crear, leer, actualizar, eliminar y listar. Todo lo que un usuario de negocio configura en Amazon Quick, un agent con sus instrucciones y starter prompts, un connector, un knowledge base o un flow, podemos inspeccionarlo, recrearlo, actualizarlo y gobernarlo programáticamente, permisos incluidos.

Esta superficie programable es lo que hace posible una promoción gobernada. En lugar de recrear cada recurso a mano, leemos un recurso y sus permisos a través de la API y los volvemos a aplicar en otra cuenta exactamente como eran. El migrador de esta publicación compone las operaciones de crear, leer, actualizar y listar en un flujo de trabajo repetible, y nunca emite una eliminación contra el destino, por lo que una ejecución solo agrega o actualiza.

En esta publicación, recorremos el Quick Resource Migrator, un servidor MCP de ejemplo alojado en el runtime de Amazon Bedrock AgentCore, una capacidad de Amazon Bedrock AgentCore, que automatiza la promoción entre cuentas de los recursos de Amazon Quick en una sola llamada de herramienta. Está dirigido por recursos: usted elige un tipo de recurso (agent, connector, knowledge base, flow o space) y selecciona por id, por nombre o todos. Es idempotente (seguro de volver a ejecutar) y copia los permisos fielmente al describir el origen y reproducir las mismas acciones en el destino. El código fuente completo está disponible en el repositorio aws-samples.

Descripción general de la solución

El migrador promueve un conjunto elegido de recursos en una sola llamada. Es un upsert: un recurso que aún no existe en el destino se crea, y uno que ya existe se actualiza en su lugar. Cada actualización está protegida por una copia de seguridad con versiones escrita en Amazon S3 antes del cambio, de modo que cada recurso conserva un historial completo que puede revisar y al que puede retroceder. Una vista previa de solo lectura informa exactamente qué crearía o actualizaría una ejecución antes de confirmar, y la migración en sí se ejecuta en Amazon Bedrock AgentCore, por lo que puede controlarse desde Amazon Quick o desde cualquier cliente compatible con MCP.

Qué se migra

1. Modelo de selección: Elija un tipo de recurso (agent, connector, knowledge base, flow o space) y seleccione recursos por id, por nombre o todos. La selección está dirigida por recursos. Migre un tipo de recurso directamente, o migre un space para traer consigo sus recursos vinculados.
2. Chat agents: Se recrean con sus instrucciones personalizadas, identidad, tono, starter prompts y mensaje de bienvenida, con sus action connectors readjuntos (remapeados a la cuenta de destino). Cuando se migra un space, sus agents se vuelven a vincular a él automáticamente.
3. Action connectors: Se recrean con su configuración. Los valores secretos nunca se leen del origen. Los connectors se crean con credenciales de marcador de posición y se reautentican en el destino.
4. Knowledge bases: El knowledge base se registra en la cuenta de destino, su fuente de datos se recrea y sus permisos se copian. Para los knowledge bases respaldados en S3, el migrador también aprovisiona el bucket de destino y su política de bucket (un resultado distinto de la migración). Los documentos (objetos de S3) en sí no se copian.
5. Flows: Se recrean en la cuenta de destino a partir de su definición. Debido a que los ID de los flows difieren entre cuentas, los flows se emparejan por nombre: un flow de destino con el mismo nombre se actualiza; de lo contrario, se crea uno nuevo. Los permisos del flow se copian.
6. Espacios: Se recrean en la cuenta de destino y se vuelven a vincular a sus agentes, conectores y bases de conocimiento (con los Amazon Resource Names (ARN) de los recursos reasignados al destino). Migre primero los recursos vinculados para que los ARN de destino se resuelvan. Los permisos de los espacios se copian.

Principios de diseño clave

1. Selección basada en recursos. Se migra un tipo de recurso a la vez (agente, conector, base de conocimiento, flujo o espacio), seleccionando por id, por nombre o todos. Los agentes se recrean con sus conectores de acción vuelto a adjuntar. Los espacios se recrean y se vuelven a vincular a sus agentes, conectores y bases de conocimiento, con los ARN reasignados a la cuenta de destino.
2. Fidelidad de permisos. Los permisos no están codificados de forma fija. El servidor llama a la Describe*Permissions API relevante en cada recurso de origen y reproduce la lista de acciones idéntica en el destino, reasignando los principales a los usuarios registrados en la cuenta de destino.
3. Idempotencia. Cada recurso se crea o se actualiza. El servidor describe primero el destino y decide si crear o actualizar, de modo que volver a ejecutar una migración converge en el mismo estado en lugar de producir duplicados o fallar.
4. Mínimo privilegio y aislamiento. El rol de origen es de solo lectura. El rol de destino tiene solo las acciones que la migración necesita. El runtime autentica a los llamadores con un Cognito JSON Web Token (JWT) y puede ejecutarse en modo de red de nube privada virtual (VPC).
5. Actualizaciones seguras y reversibles. Antes de que el migrador actualice cualquier recurso de destino existente, escribe una instantánea versionada de ese recurso, y de sus dependencias, en un bucket de respaldo dedicado. Si no se puede escribir ese respaldo, la actualización se aborta. Cada recurso creado o actualizado también se guarda en una instantánea, y una herramienta de restauración puede revertir cualquier recurso a una versión anterior.

Arquitectura

La solución usa un modelo de tres cuentas. Una cuenta de ejecución central aloja el servidor MCP en el runtime de Amazon Bedrock AgentCore. El servidor asume un rol de solo lectura en la cuenta de origen y un rol de lectura-escritura en la cuenta de destino usando AWS Security Token Service (AWS STS), por lo que no se almacenan credenciales de larga duración en ningún lugar.

Figura 1: Arquitectura del servidor MCP Amazon Quick Resource Migrator

Responsabilidades de los componentes

Tabla 1: Componentes de la arquitectura

Flujo de migración

1. Resolver recursos: a partir del tipo de recurso y el selector (id, nombre o all), resolver los IDs concretos de recursos en la cuenta de origen.
2. Describir el origen: describir cada recurso seleccionado para capturar su configuración y permisos.
3. Connectors: recrear cada connector. La configuración de autenticación se depura al modelo de creación (escritura) con secrets de marcador de posición, y luego se reautentica en el destino. Copiar permisos.
4. Knowledge bases: crear el bucket de destino (knowledge-base-<env>-<account>), la bucket policy, el data source y la knowledge base, y luego copiar los permisos de la knowledge base. Los objetos de S3 no se copian.
5. Agents: recrear cada agent con sus action connectors adjuntos (reasignados a la cuenta de destino) y luego copiar los permisos del agent. El vínculo agent-a-space se restaura cuando el space en sí se migra (véase el paso de space).
6. Flows: recree cada flow a partir de su definición, emparejado por nombre (los flow IDs difieren entre cuentas): actualice un flow de destino con el mismo nombre o cree uno nuevo, y luego copie los permisos del flow.
7. Spaces: recree cada space y vuelva a vincular sus agents, connectors y knowledge bases con ARNs reasignados a la cuenta de destino (migre primero esos recursos), y luego copie los permisos del space.
8. Report: devuelve un informe JSON de los recursos creados o actualizados, buckets, backups, permisos omitidos y cualquier error.

Tools expuestas por el servidor MCP

El servidor expone cinco tools, todas definidas en server.py.

preview_migration (solo lectura)

preview_migration toma un source account ID, un resource type (agent, connector, knowledge base, flow, space o all), un selector (id, name o all) y una AWS Region. Devuelve un inventario de los agents, action connectors, knowledge bases y flows que se migrarían, con nombres y tipos, sin realizar ningún cambio. Úselo como una prueba en seco para confirmar el alcance y para respaldar un paso de aprobación de gestión de cambios antes de la promoción. Cuando también pasa un target account ID, la respuesta añade un mapeo de origen a destino que marca cada recurso como CREATE o UPDATE, de modo que puede ver exactamente qué cambiaría una migración antes de ejecutarla.

migrate_resources (migración completa)

migrate_resources toma los source y target account IDs, un resource type (agent, connector, knowledge base, flow o space), un selector (id, name o all), una región, los nombres de los entornos de origen y destino (usados en el nombre del bucket del knowledge base) y el nombre del rol de servicio de Quick Sight. Realiza la migración completa de crear-o-actualizar descrita anteriormente y devuelve un informe estructurado de todo lo que creó, actualizó y otorgó, junto con cualquier error. Como es idempotente, puede ejecutarlo repetidamente, por ejemplo en cada release, y convergerá al mismo estado de destino.

list_backups (solo lectura)

list_backups busca en el catálogo de backups y enumera las versiones disponibles para cada asset. Los backups son las instantáneas previas a la actualización que el migrador escribe en el bucket de backups, un objeto versionado por actualización, de modo que puede ver el historial completo de cualquier recurso migrado.

get_backup (solo lectura)

get_backup devuelve el backup almacenado completo para un asset y versión determinados (la última de forma predeterminada), incluida la configuración del recurso capturada y sus dependencias.

restore_backup

restore_backup vuelve a aplicar una versión de backup almacenada sobre el recurso de destino, actualizándolo in situ, o recreándolo si ya no existe. Primero toma un backup previo a la restauración nuevo, por lo que la reversión es a su vez reversible.

Implemente la solución

El código fuente completo y las instrucciones de implementación paso a paso se encuentran en el aws-samples repository README. A grandes rasgos, implementa tres stacks de AWS CloudFormation, los roles de cross-account de AWS Identity and Access Management (IAM), la red VPC y el runtime de AgentCore autenticado con Cognito que aloja el servidor MCP, y luego registra ese runtime como un action connector en Amazon Quick.

Use el migrador a través de una Quick App

Al registrar el runtime como un action connector, puede impulsar el migrador desde Amazon Quick en lenguaje natural, y también puede construir una Quick App: una experiencia web de apuntar y hacer clic superpuesta a las mismas tools MCP. No construye esa UI a mano. El repositorio incluye un app-builder prompt listo para usar que pega en el Amazon Quick app builder, reemplazando el placeholder del connector y los action IDs por los suyos para generar la app. La app convierte el flujo de trabajo en un flujo guiado: elija una cuenta de origen y destino y los recursos a promover, previsualice lo que se creará o actualizará, ejecute la migración y revise un historial de cada migración pasada, cada una respaldada por las instantáneas de S3 versionadas que escribe el servidor. Las siguientes pantallas muestran esa experiencia.

Una Quick App de ejemplo

1. Como la app se genera a partir de un prompt, cada build difiere. Las siguientes pantallas muestran un ejemplo de ello. En él, la página de inicio solicita el Source Account ID, el Target Account ID, el resource type (agent, connector, knowledge base, flow o space) y el selector (id, name o all), con opciones adicionales disponibles según sea necesario.

Figura 3: Opciones de migración adicionales disponibles en la página de inicio

1. Después de elegir Confirm & migrate, ve una respuesta como la siguiente:

Figura 4: La respuesta de confirmación después de elegir Confirm and migrate

1. Después de confirmar y migrar, debería ver la respuesta del servidor MCP que devuelve los recursos que fueron creados/actualizados.

Figura 5: La respuesta del servidor MCP que enumera los recursos que fueron creados o actualizados

1. Abra la pestaña History para ver todas las migraciones anteriores. Cada entrada está respaldada por la instantánea versionada que el migrador escribió en Amazon S3, por lo que obtiene un registro completo y auditable de qué se promovió y cuándo, con la opción de inspeccionar cualquier versión anterior.

Figura 6: La pestaña History que muestra un registro auditable de las migraciones anteriores

1. Para revertir, seleccione la versión de respaldo de un recurso y elija Restore. La aplicación vuelve a aplicar esa versión guardada al destino. Como primero captura un nuevo respaldo antes de restaurar, la reversión es a su vez reversible.

Figura 7: Reversión de un recurso a una versión de respaldo anterior

Conclusión

La promoción entre cuentas es una expectativa básica para el software empresarial, y hasta ahora era la pieza que faltaba para Amazon Quick. El Quick Resource Migrator convierte una tarea lenta, manual y difícil de auditar en una tarea rápida, repetible y gobernada: una sola llamada a la herramienta recrea agentes, conectores y bases de conocimiento en una cuenta de destino y copia los permisos fielmente, todo de forma idempotente, por lo que puede ejecutarlo en cada versión.

Clone el repositorio de ejemplo, despliéguelo en una cuenta de runner y pruebe la promoción de un agente o una base de conocimiento de desarrollo a producción. Luego adapte el patrón a sus propios requisitos de gobernanza y endurecimiento.

Sobre los autores