Scaling cloud migrations with agentic AI on Amazon Bedrock AgentCore

來源原標題

Scaling cloud migrations with agentic AI on Amazon Bedrock AgentCore

作者

Nikhil Jha

原始標籤

Advanced (300) · Amazon Bedrock AgentCore · Technical How-to

原始連結

https://aws.amazon.com/blogs/machine-learning/scaling-cloud-migrations-with-agentic-ai-on-amazon-bedrock-agentcore/

摘要原文

October 2026: This post was reviewed and updated for accuracy. Scaling cloud migrations with agentic AI on Amazon Bedrock AgentCore raises a practical question. Which parts of a large migration program belong to a managed service, and which parts need custom automation? One enterprise program answered that question across 300+ applications and a fixed fiscal year deadline. The four-agent pattern in this post reduced infrastructure as code (IaC) development time from 3 to 4 weeks per application to minutes, based on internal project tracking data. This pattern runs alongside AWS Transform rather than in place of it, as a hybrid that adds custom agents where your program requires them. AWS Transform covers the migration and modernization work, and AWS Database Migration Service (AWS DMS) covers the database tier. The agents in this post attach to those services and carry one further requirement: sources and destinations reached through Model Context Protocol (MCP) tools that your organization builds and maintains. AWS Professional Services builds a suite of purpose-built AI agents for programs with that requirement. The agents use the Strands Agents SDK and run on Amazon Bedrock AgentCore, a platform to build, connect, and optimize agents at scale, with any framework or model. Each agent reaches its sources and destinations through MCP tools exposed by AgentCore Gateway. In this post, you explore the architecture of a four-agent pattern for MCP-connected environments. You also see the code that defines an agent, connects it to its tools, and applies responsible AI controls. The pattern includes four agents: To follow along, you need an AWS account with access to Amazon Bedrock AgentCore and to Amazon Bedrock foundation models. You also need familiarity with the Strands Agents SDK and MCP server patterns, plus the IaC tooling used by your organization. Confirm first that an AWS managed service does not already cover your migration path. AWS Transform covers migration and modernization for server, network, mainframe, .NET, and application code workloads as a managed service, and AWS DMS covers databases. This pattern adds agents for the requirements that stay specific to your organization. On the program described here, three conditions held together. This pattern uses four purpose-built agents. The architecture attaches to a migration program at three points: the systems holding migration inputs, IaC composition, and operations after cutover. The pattern applies security at each of those points. The following diagram shows how the agents, tools, and AWS services connect. Figure 1: How the agents connect across the migration and operations journeys through Model Context Protocol tool calling The pattern organizes agents into two journeys. The migration journey agents handle discovery through deployment. The operations journey agent handles post-migration monitoring. AWS managed services carry the migration and complement the custom agents: This section describes how the framework components interact at runtime. Each agent is a Strands agent, defined by a foundation model, a system prompt, and a set of tools. Amazon Bedrock AgentCore runtime hosts them in a serverless environment with session isolation and multi-agent orchestration. Amazon Bedrock foundation models power the reasoning that interprets documents, generates code, and drives multi-step workflows. For model availability by AWS Region, refer to Supported foundation models in Amazon Bedrock . Each agent calls MCP tools scoped to its function through AgentCore Gateway , a capability of Amazon Bedrock AgentCore, which converts your APIs, AWS Lambda functions, and existing services into MCP-compatible tools. AgentCore Identity , a capability of Amazon Bedrock AgentCore, authenticates each call through scoped AWS Identity and Access Management (IAM) roles and your identity provider. Amazon Bedrock AgentCore memory stores agent session state and shared context. Agents use this shared context to persist outputs and track migration progress across over 300 applications. When the Intake Agent completes discovery, it writes the target architecture and dependency mappings to AgentCore memory. The IaC Agent reads this shared context to begin code generation without manual handoff. The following Python example defines the IaC Agent and prepares it for Amazon Bedrock AgentCore runtime. The agent reaches your MCP tools through AgentCore Gateway, and it calls a foundation model through Amazon Bedrock with an Amazon Bedrock Guardrails policy attached. The entrypoint returns the generated IaC together with the policy set version that shaped it, so a reviewer traces the output back to a signed-off standard. AgentCore Runtime handles session isolation and scaling. For deployable examples, see the Amazon Bedrock AgentCore samples repository and the Strands Agents samples repository on GitHub. For the deployment steps, refer to Getting started with AgentCore runtime . The Intake Agent reads the migration inputs that live in your document and collaboration systems. On this program, those systems were reachable through MCP tools the delivery team built and maintained. The agent ingests architecture documentation, application inventory lists, intake questionnaires, and dependency records through those tools. It then produces a target AWS architecture with a recommended migration pattern, resource sizing specifications, and a compliance validation report. The output feeds directly into the IaC Agent, creating an automated handoff from intake to infrastructure provisioning. AWS Professional Services deployed the IaC Agent first in the portfolio, and it delivers the most immediately measurable impact. It generates IaC code adhering to your security best practices and standards. The agent workflow proceeds through five steps: Step 1: Ingest the steering document. The agent reads the steering document from the wave team. It extracts deployment scope, compliance constraints, and Security Office-approved wave-specific overrides. Step 2: Interpret the target state architecture diagram. Using the Intake Agent’s output, the IaC Agent identifies infrastructure components, their relationships, and dependencies. Step 3: Generate IaC. Based on this interpretation, the agent generates IaC using your defined and established patterns. It populates configurations with wave-specific parameters and configures remote state management. It then applies mandatory tagging and adds monitoring configurations required by organizational standards. Step 4: Validate through Policy in Amazon Bedrock AgentCore. Before execution, Policy in AgentCore evaluates each tool call against Cedar rules. It calculates the scope of potential change, checks dependency conflicts with concurrent waves, and confirms compliance window validity. Step 5: Execute and report. The centralized execution plane triggers the IaC, monitors deployment, and reports outcomes through AgentCore Observability, a capability of Amazon Bedrock AgentCore. Post-deployment validation runs automatically and compliance metrics update in real time. Each action passes through custom MCP tools exposed by Amazon Bedrock AgentCore Gateway and governed by AgentCore Identity and Policy in AgentCore. AgentCore Identity authenticates each agent action through scoped IAM roles with least-privilege access. The framework validates inputs against defined schemas and rejects malformed inputs at the boundary. No credentials or sensitive values pass through agent context, because AgentCore Identity resolves secrets at runtime from a centralized credential provider. AgentCore Observability and AWS CloudTrail write each agent action to an immutable, centralized audit trail. Policy in AgentCore enforces Cedar rules that help prevent a single operation from affecting more than a defined threshold. The security office curates the policy set, not the agent.