Making Amazon Quick enterprise-ready: Automated, auditable cross-account resource promotion

來源原標題

Making Amazon Quick enterprise-ready: Automated, auditable cross-account resource promotion

作者

Keshav Ganesh

原始標籤

Advanced (300) · Amazon Quick Suite · Technical How-to

原始連結

https://aws.amazon.com/blogs/machine-learning/making-amazon-quick-enterprise-ready-automated-auditable-cross-account-resource-promotion/

摘要原文

Amazon Quick is Amazon’s agentic AI companion built for work. You build agents that reason over your data, call action connectors, and carry multi-step tasks to completion. Promoting those resources (chat agents, action connectors, knowledge bases, flows, and spaces) from a development to a production AWS account, the way you would any other application, has been a manual and error-prone chore. This post shows how to automate it with an idempotent, auditable Model Context Protocol (MCP) server on Amazon Bedrock AgentCore. The building blocks of an agentic solution are its agents, action connectors, knowledge bases, and spaces : chat agents configured with custom instructions, connectors for Slack, Jira, and other integrations, knowledge bases grounded in your own documents, and the Space that binds them together. Teams assemble and iterate on them quickly in a development account. Most enterprises run separate AWS accounts for development and production, sometimes with quality assurance (QA) in between. When agents, action connectors, and knowledge bases are validated in a development account, there is no native, one-click way to promote them into the next account. Teams rebuild each resource by hand: recreate each agent with the same instructions and starter prompts, re-attach each agent’s action connectors, re-grant resource permissions, and reprovision the Amazon Simple Storage Service (Amazon S3) bucket, bucket policy, and data source behind each knowledge base. The work is slow, difficult to audit, and easy to get subtly wrong, which undermines the governance story enterprises need. Amazon Quick resources are programmable. Spaces, agents, action connectors, knowledge bases, and flows are managed through the Amazon Quick API (part of the Amazon Quick Sight API surface ), which provides the full resource lifecycle, create, read, update, delete, and list. Anything a business user configures in Amazon Quick, an agent with its instructions and starter prompts, a connector, a knowledge base, or a flow, we can inspect, recreate, update, and govern programmatically, permissions included. This programmable surface is what makes governed promotion possible. Instead of recreating each resource by hand, we read a resource and its permissions through the API and reapply them in another account exactly as they were. The migrator in this post composes the create, read, update, and list operations into one repeatable workflow, and it never issues a delete against the target, so a run only adds or updates. In this post, we walk through the Quick Resource Migrator, a sample MCP server hosted on Amazon Bedrock AgentCore runtime, a capability of Amazon Bedrock AgentCore, that automates cross-account promotion of Amazon Quick resources in a single tool call. It’s resource-driven: you pick a resource type (agent, connector, knowledge base, flow, or space) and select by id, by name, or all. It’s idempotent (safe to re-run), and it copies permissions faithfully by describing the source and replaying the same actions in the target. The full source code is available in the aws-samples repository . The migrator promotes a chosen set of resources in a single call. It is an upsert: a resource that does not yet exist in the target is created, and one that already exists is updated in place. Every update is protected by a versioned backup written to Amazon S3 before the change, so each resource keeps a full history you can review and roll back to. A read-only preview reports exactly what a run would create or update before you commit, and the migration itself runs on Amazon Bedrock AgentCore, so it can be driven from Amazon Quick or any MCP-compatible client. The solution uses a three-account model. A central runner account hosts the MCP server on Amazon Bedrock AgentCore runtime. The server assumes a read-only role in the source account and a read-write role in the target account using AWS Security Token Service (AWS STS), so no long-lived credentials are stored anywhere. Figure 1: Architecture of the Amazon Quick Resource Migrator MCP server Table 1: Architectural components The server exposes five tools, all defined in server.py . preview_migration takes a source account ID, a resource type (agent, connector, knowledge base, flow, space, or all), a selector (id, name, or all), and an AWS Region. It returns an inventory of the agents, action connectors, knowledge bases, and flows that would be migrated, with names and types, without making any change. Use it as a dry run to confirm scope and to support a change-management approval step before promotion. When you also pass a target account ID, the response adds a source-to-target mapping that marks each resource CREATE or UPDATE, so you can see exactly what a migration would change before running it. migrate_resources takes source and target account IDs, a resource type (agent, connector, knowledge base, flow, or space), a selector (id, name, or all), a region, source and target environment names (used in the knowledge base bucket name), and the Quick Sight service role name. It performs the full create-or-update migration described above and returns a structured report of everything it created, updated, and granted, along with any errors. Because it’s idempotent, you can run it repeatedly, for example on every release, and it converges on the same target state. list_backups searches the backup catalog and lists the available versions for each asset. Backups are the pre-update snapshots the migrator writes to the backup bucket, one versioned object per update, so you can see the full history for any migrated resource. get_backup returns the full stored backup for a given asset and version (the latest by default), including the captured resource configuration and its dependencies. restore_backup re-applies a stored backup version onto the target resource, updating it in place, or recreating it if it no longer exists. It first takes a fresh pre-restore backup, so the revert is itself reversible. The full source and step-by-step deployment instructions live in the aws-samples repository README. At a high level you deploy three AWS CloudFormation stacks, the cross-account AWS Identity and Access Management (IAM) roles, the VPC network, and the Cognito-authenticated AgentCore runtime that hosts the MCP server, then register that runtime as an action connector in Amazon Quick. By registering the runtime as an action connector, you can drive the migrator from Amazon Quick in natural language, and you can also build a Quick App: a point-and-click web experience layered on the same MCP tools. You don’t build that UI by hand. The repository includes a ready-to-use app-builder prompt that you paste into the Amazon Quick app builder, replacing the placeholder connector and action IDs with your own to generate the app. The app turns the workflow into a guided flow: choose a source and target account and the resources to promote, preview what will be created or updated, run the migration, and review a history of every past migration, each backed by the versioned S3 snapshots the server writes. The following screens show that experience. Figure 3: Additional migration options available on the landing page Figure 4: The confirmation response after you choose Confirm and migrate Figure 5: The MCP server response listing the resources that were created or updated Figure 6: The History tab showing an auditable record of past migrations Figure 7: Rolling back a resource to an earlier backup version Cross-account promotion is a baseline expectation for enterprise software, and until now it has been the missing piece for Amazon Quick. The Quick Resource Migrator turns a slow, manual, hard-to-audit task into a fast, repeatable, and governed one: a single tool call recreates agents, connectors, and knowledge bases in a target account and copies permissions faithfully, all idempotently, so you can run it on every release.