借助 Amazon Bedrock AgentCore 的 Agentic AI 扩展云迁移规模，首先要认识到大规模迁移在哪些环节容易失效。每个应用的发现工作要耗费数周时间。工程师需要为每个工作负载从头编写基础设施代码。迁移后的运营往往沦为被动救火。将这些瓶颈放大到超过 300 个应用，并叠加固定的财年截止期限，迁移项目便难以跟上进度。本文介绍的多 Agent 框架，已将超过 300 个应用组合中每个应用的基础设施即代码（IaC）开发时间从 3–4 周缩短到数分钟。这一结果基于内部项目跟踪数据。

AWS Professional Services 构建了一套专门设计的 AI Agent，以解决迁移生命周期中的这些瓶颈，覆盖自动化发现到主动式迁移后运营。Agent 使用 Strands Agents SDK，并运行在 Amazon Bedrock AgentCore 上；后者是一个可使用任何框架或模型、大规模构建、连接和优化 Agent 的平台。

在本文中，你将了解一种可端到端加速企业云迁移的多 Agent 编排框架架构。你还将看到用于定义 Agent、将其连接至工具以及应用负责任 AI 控制措施的代码。该框架包括四类 Agent：

• 用于自动化发现的 Intake Agent。
• 生成遵循你的安全最佳实践的基础设施即代码（IaC）的 IaC Agent。
• 用于全组合报告和良好架构评估的 Migration Intelligence and Governance Agent。
• 用于主动式运营的 Site Reliability Engineering (SRE) Agent。

要跟随本文操作，你需要一个 AWS 账户，并拥有对 Amazon Bedrock AgentCore 和 Amazon Bedrock 基础模型（FM）的访问权限。你还需要熟悉 Strands Agents SDK 和模型上下文协议（MCP）服务器模式，以及组织所使用的 IaC 工具。

为什么迁移项目需要不同的方法

在大型企业数据中心退出迁移项目中，持续会出现三项核心瓶颈。

人工接入开销： 大多数应用迁移始于发现阶段：了解本地架构、资产清单、依赖关系和接入问卷。人工发现每个应用需要耗费数周时间。对于超过 300 个应用而言，仅这一瓶颈就会威胁紧张的迁移时间表。

重复的基础设施开发： 当工程师定义目标架构时，需要编写 IaC 来预置 AWS 基础设施。如果没有自动化，为每个应用从头编写 IaC 通常需要 3–4 周。对于超过 300 个应用的组合，这相当于数年的工程工作量。

被动式迁移后运营： 迁移后，团队依赖人工监控和被动响应。如果没有能够发现性能下降或自动修复问题的主动式智能能力，持续的运营阻力会随着时间不断累积。

这三项瓶颈贯穿整个迁移生命周期。要解决这些问题，需要将重复性工作转交给 AI Agent，同时保留由人类掌握决策权。

架构概览

多 Agent 编排框架通过专门设计的 Agent 能力解决每一项瓶颈。该架构覆盖从本地发现到迁移后运营的迁移生命周期。框架在该生命周期的每个阶段应用安全控制。下图展示了 Agent、工具和 AWS 服务之间的连接方式。

图 1：Agent 如何通过模型上下文协议工具调用，跨迁移和运营旅程进行连接

该框架将 Agent 划分为两条旅程。迁移旅程中的 Agent 负责从发现到部署的工作，运营旅程中的 Agent 负责迁移后监控。

迁移旅程 Agent：

• Intake Agent（阶段 1）： 自动执行应用发现和目标状态架构定义，并生成依赖关系映射。
• IaC Agent（阶段 2）： 生成遵循你的安全最佳实践和标准的 IaC 代码。
• Migration Intelligence and Governance Agent： 在 Jira、Confluence 和 Webex 中提供自动化组合报告、良好架构评估和迁移治理。

运营旅程 Agent：

• SRE Agent（阶段 3）： 提供主动式迁移后监控和自动化修复。

AWS 托管服务对自定义 Agent 形成补充：

组件如何连接

本节介绍框架组件在运行时如何交互。

每个 Agent 都是一个 Strands Agent，由基础模型、系统提示词和一组工具定义。Amazon Bedrock AgentCore runtime 在具有会话隔离和多 Agent 编排能力的无服务器环境中托管这些 Agent。Amazon Bedrock 基础模型为理解文档、生成代码和驱动多步骤工作流的推理能力提供支持。有关按 AWS 区域划分的模型可用性，请参阅 Amazon Bedrock 中支持的基础模型。

每个 Agent 都会通过 AgentCore Gateway 调用限定在其功能范围内的 MCP 工具。AgentCore Gateway 是 Amazon Bedrock AgentCore 的一项能力，可将你的 API、AWS Lambda 函数和现有服务转换为兼容 MCP 的工具。AgentCore Identity 同样是 Amazon Bedrock AgentCore 的一项能力，它通过限定范围的 AWS Identity and Access Management（IAM）角色及你的身份提供商，对每次调用进行身份验证。

Amazon Bedrock AgentCore memory 存储 Agent 会话状态和共享上下文。Agent 使用这一共享上下文，在超过 300 个应用之间持久保存输出并跟踪迁移进度。当 Intake Agent 完成发现时，它会将目标架构和依赖关系映射写入 AgentCore memory。IaC Agent 读取这一共享上下文，无需人工交接即可开始代码生成。

在代码中定义 Agent

以下 Python 示例定义 IaC Agent，并为 Amazon Bedrock AgentCore runtime 做好准备。该 Agent 通过 AgentCore Gateway 访问你的 MCP 工具，并通过 Amazon Bedrock 调用附加了 Amazon Bedrock Guardrails 策略的基础模型。

import logging import os from bedrock_agentcore.runtime import BedrockAgentCoreApp from strands import Agent from strands.models import BedrockModel from strands.tools.mcp import MCPClient from strands.tools.mcp.mcp_types import MCPClientCredentials

logger = logging.getLogger(name) app = BedrockAgentCoreApp()

REGION = os.environ["AWS_REGION"]

url+auth lets the SDK run the client_credentials grant and re-mint the

token on expiry. A statically captured bearer token would go stale.

gateway = MCPClient( url=os.environ["GATEWAY_MCP_URL"], auth=MCPClientCredentials( client_id=os.environ["GATEWAY_CLIENT_ID"], client_secret=get_secret("gateway/client_secret"), scopes=[os.environ["GATEWAY_SCOPE"]], ), )

model = BedrockModel( model_id=os.environ["MODEL_ID"], region_name=REGION, guardrail_id=os.environ["GUARDRAIL_ID"], guardrail_version=os.environ.get("GUARDRAIL_VERSION", "1"), guardrail_trace="enabled", )

@app.entrypoint def invoke(payload, context): prompt = (payload.get("prompt") or "").strip() if not prompt: return {"status": "error", "error": "missing required field: prompt"}

try:
    # tools=[gateway]: SDK owns the connection lifecycle and paginates
    # tool discovery, which list_tools_sync() alone does not.
    agent = Agent(
        model=model,
        system_prompt=IAC_AGENT_PROMPT,
        tools=[gateway],
    )
    result = agent(prompt)

    if result.stop_reason == "guardrail_intervened":
        logger.warning("guardrail blocked request, session_id=%s",
                       getattr(context, "session_id", None))
        return {"status": "blocked_by_guardrail"}

    return {"status": "ok", "iac": str(result)}

except Exception as e:
    logger.exception("invocation failed, session_id=%s",
                     getattr(context, "session_id", None))
    return {"status": "error", "error": str(e)}

if name == "main": app.run()

入口点将生成的 IaC 返回给调用方，而 AgentCore runtime 负责处理会话隔离和扩缩容。有关可部署的端到端示例，请参阅 GitHub 上的 Amazon Bedrock AgentCore samples repository 和 Strands Agents samples repository。有关部署步骤，请参阅 AgentCore runtime 入门。

阶段 1：用于自动化发现的 Intake Agent

Intake Agent 自动执行迁移中最耗时的第一步：了解本地环境中存在哪些内容，以及确定其在 AWS 上的目标位置。

该 Agent 可摄取本地架构文档、应用资产清单、接入问卷和依赖关系图。随后，它会生成目标 AWS 架构，其中包含推荐的迁移模式、资源规格建议和合规性验证报告。

Intake Agent 解决了人工接入的瓶颈。其输出会直接传递给 IaC Agent，从发现到基础设施预置形成自动化交接。

阶段 2：用于自动化基础设施代码生成的 IaC Agent

AWS Professional Services 最先在该应用组合中部署 IaC Agent，它带来了最易于立即量化的效果。该 Agent 生成遵循你的安全最佳实践和标准的 IaC 代码。

工作原理

Agent 工作流包含五个步骤：

步骤 1：摄取指导文档。 Agent 从迁移波次团队读取指导文档，提取部署范围、合规性约束条件，以及经安全办公室批准的波次特定例外配置。

步骤 2：理解目标状态架构图。 IaC Agent 使用 Intake Agent 的输出，识别基础设施组件、它们之间的关系及依赖项。

步骤 3：生成 IaC。 Agent 基于这一理解，使用你已定义并确立的模式生成 IaC。它使用波次特定参数填充配置，并配置远程状态管理。随后，它会应用强制性标签，并添加组织标准要求的监控配置。

步骤 4：通过 Amazon Bedrock AgentCore 中的 Policy 进行验证。 执行前，AgentCore 中的 Policy 会根据 Cedar 规则评估每次工具调用。它会计算潜在变更的范围，检查与并行波次的依赖冲突，并确认合规窗口的有效性。

步骤 5：执行并报告。 集中式执行平面触发 IaC、监控部署，并通过 Amazon Bedrock AgentCore 的一项能力 AgentCore Observability 报告结果。部署后验证会自动运行，合规性指标则实时更新。

每项操作都会经过由 Amazon Bedrock AgentCore Gateway 提供的自定义 MCP 工具，并受 AgentCore Identity 和 AgentCore 中 Policy 的治理。AgentCore Identity 通过采用最小权限访问的限定范围 IAM 角色，对每个 Agent 操作进行身份验证。该框架会依据定义的模式验证输入，并在边界处拒绝格式错误的输入。

由于 AgentCore Identity 会在运行时从集中式凭证提供商解析机密信息，因此凭证或敏感值不会经过 Agent 上下文。AgentCore Observability 和 AWS CloudTrail 会将每一项 Agent 操作写入不可篡改的集中式审计追踪。AgentCore 中的 Policy 实施 Cedar 规则，以帮助防止单项操作影响超过既定阈值的资源范围。

基于你的模式生成 IaC

IaC Agent 会基于你定义并确立的模式生成基础设施代码。这些模式将组织标准编码为可复用的构造。它们包括网络配置、安全组规则、IAM 角色、Amazon CloudWatch 告警、Amazon Elastic Compute Cloud（Amazon EC2） 配置、Amazon Virtual Private Cloud（Amazon VPC） 布局以及强制性标签。

这种方法为不同波次提供一致性，为无需从头编写基础设施代码的波次团队提升速度，并通过治理机制使安全更新在使用者的下一次部署周期中自动传播。

输出工件

该 Agent 会为每个应用生成 IaC 代码、自动化测试用例、合规性报告和部署运行手册。

IaC Agent 会将生成的代码直接推送到你的代码仓库（s

Scaling cloud migrations with agentic AI on Amazon Bedrock AgentCore starts with recognizing where large-scale migrations break down. Discovery consumes weeks per application. Engineers write infrastructure code from scratch for each workload. Post-migration operations devolve into reactive firefighting. Multiply those bottlenecks across over 300 applications and a fixed fiscal year deadline, and migration programs struggle to keep pace. The multi-agent framework in this post reduced infrastructure as code (IaC) development time from 3–4 weeks per application to minutes across a over 300 application portfolio. This result is based on internal project tracking data.

AWS Professional Services builds a suite of purpose-built AI agents to address these bottlenecks across the migration lifecycle, from automated discovery to proactive post-migration operations. 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.

In this post, you explore the architecture of a multi-agent orchestration framework that accelerates enterprise cloud migrations end-to-end. You also see the code that defines an agent, connects it to its tools, and applies responsible AI controls. The framework includes four agents:

• The Intake Agent for automated discovery.
• The IaC Agent that generates infrastructure as coded (IaC) adhering to your security best practices.
• The Migration Intelligence and Governance Agent for portfolio-wide reporting and well-architected assessments.
• The Site Reliability Engineering (SRE) Agent for proactive operations.

To follow along, you need an AWS account with access to Amazon Bedrock AgentCore and to Amazon Bedrock foundation models (FM). You also need familiarity with the Strands Agents SDK and Model Context Protocol (MCP) server patterns, plus the IaC tooling used by your organization.

Why migration programs need a different approach

Three core bottlenecks emerge consistently across large enterprise data center exit migration programs.

Manual intake overhead: Most application migrations begin with discovery: understanding the on-premises architecture, inventory, dependencies, and intake questionnaires. Manual discovery consumes weeks per application. Across over 300 applications, this bottleneck alone threatens an aggressive migration timeline.

Redundant infrastructure development: When engineers define a target architecture, they write IaC to provision the AWS infrastructure. Without automation, writing IaC from scratch for each application typically requires 3–4 weeks per application. Across a over 300 application portfolio, that translates to years of engineering effort.

Reactive post-migration operations: After migration, teams rely on manual monitoring and reactive response. Without proactive intelligence to detect performance degradation or automatically remediate issues, ongoing operational drag compounds over time.

These three bottlenecks span the migration lifecycle. Addressing them requires shifting repetitive work to AI agents while humans retain decision authority.

Architecture overview

A multi-agent orchestration framework addresses each bottleneck with purpose-built agent capabilities. The architecture spans the migration lifecycle from on-premises discovery to post-migration operations. The framework applies security at each phase of that lifecycle. 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 framework organizes agents into two journeys. The migration journey agents handle discovery through deployment. The operations journey agent handles post-migration monitoring.

Migration journey agents:

• Intake Agent (Phase 1): Automates application discovery and target state architecture definition with dependency mappings.
• IaC Agent (Phase 2): Generates IaC code adhering to your security best practices and standards.
• Migration Intelligence and Governance Agent: Provides automated portfolio reporting, well-architected assessments, and migration governance across Jira, Confluence, and Webex.

Operations journey agents:

• SRE Agent (Phase 3): Provides proactive post-migration monitoring and automated remediation.

AWS managed services complement the custom agents:

How the components connect

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.

Defining an agent in code

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.

import logging
 import os
 from bedrock_agentcore.runtime import BedrockAgentCoreApp
 from strands import Agent
 from strands.models import BedrockModel
 from strands.tools.mcp import MCPClient
 from strands.tools.mcp.mcp_types import MCPClientCredentials

 logger = logging.getLogger(__name__)
 app = BedrockAgentCoreApp()

 REGION = os.environ["AWS_REGION"]

 # url+auth lets the SDK run the client_credentials grant and re-mint the
 # token on expiry. A statically captured bearer token would go stale.
 gateway = MCPClient(
     url=os.environ["GATEWAY_MCP_URL"],
     auth=MCPClientCredentials(
         client_id=os.environ["GATEWAY_CLIENT_ID"],
         client_secret=get_secret("gateway/client_secret"),
         scopes=[os.environ["GATEWAY_SCOPE"]],
     ),
 )

 model = BedrockModel(
     model_id=os.environ["MODEL_ID"],
     region_name=REGION,
     guardrail_id=os.environ["GUARDRAIL_ID"],
     guardrail_version=os.environ.get("GUARDRAIL_VERSION", "1"),
     guardrail_trace="enabled",
 )



 @app.entrypoint
 def invoke(payload, context):
     prompt = (payload.get("prompt") or "").strip()
     if not prompt:
         return {"status": "error", "error": "missing required field: prompt"}

     try:
         # tools=[gateway]: SDK owns the connection lifecycle and paginates
         # tool discovery, which list_tools_sync() alone does not.
         agent = Agent(
             model=model,
             system_prompt=IAC_AGENT_PROMPT,
             tools=[gateway],
         )
         result = agent(prompt)

         if result.stop_reason == "guardrail_intervened":
             logger.warning("guardrail blocked request, session_id=%s",
                            getattr(context, "session_id", None))
             return {"status": "blocked_by_guardrail"}

         return {"status": "ok", "iac": str(result)}

     except Exception as e:
         logger.exception("invocation failed, session_id=%s",
                          getattr(context, "session_id", None))
         return {"status": "error", "error": str(e)}



 if __name__ == "__main__":
     app.run()

The entrypoint returns generated IaC to the caller, and AgentCore runtime handles session isolation and scaling. For deployable end-to-end 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.

Phase 1: Intake Agent for automated discovery

The Intake Agent automates the most time-consuming first step of migration: understanding what exists on-premises and defining where it goes on AWS.

The agent ingests on-premises architecture documentation, application inventory lists, intake questionnaires, and dependency maps. It then produces a target AWS architecture with a recommended migration pattern, resource sizing specifications, and a compliance validation report.

The Intake Agent addresses the manual intake bottleneck. The output feeds directly into the IaC Agent, creating an automated handoff from discovery to infrastructure provisioning.

Phase 2: IaC Agent for automated infrastructure code generation

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.

How it works

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.

IaC generation based on your patterns

The IaC Agent generates infrastructure code based on your defined and established patterns. These patterns encode organizational standards into reusable constructs. They include network configurations, security group rules, IAM roles, Amazon CloudWatch alarms, Amazon Elastic Compute Cloud (Amazon EC2) configurations, Amazon Virtual Private Cloud (Amazon VPC) layouts, and mandatory tagging.

This approach provides consistency across waves, speed for wave teams who don’t write infrastructure code from scratch, and governance where security updates propagate to consumers on their next deployment cycle.

Output artifacts

The agent produces IaC code, automated test cases, compliance reports, and deployment runbooks for each application.

The IaC Agent pushes generated code directly to your code repository (such as AWS CodeCommit, GitLab, or Bitbucket). From there, it enters your existing review and deployment pipeline without requiring changes to your existing toolchain.

Migration Intelligence and Governance Agent: Portfolio-wide visibility

An over 300 application migration portfolio requires full-time operational management. Status reporting, tracking progress, executing follow-up actions, and validating well-architected alignment manually creates significant overhead for project managers and delivery leads.

The Migration Intelligence and Governance Agent solves this with automated, on-demand intelligence and governance across the portfolio. It aggregates data from three sources through AgentCore Gateway. Jira provides sprint progress and impediments. Confluence provides architecture documentation and runbooks. Webex provides meeting notes and action items.

The agent provides well-architected assessments across migrated workloads, compliance and governance validation, and architecture pattern adherence tracking.

Automated actions include updating Confluence pages with latest migration status, creating Jira tasks for identified action items, and generating ServiceNow tickets for escalations. These actions require explicit human approval before execution. This approval-gated architecture is a core design principle across the agent suite. Agents support human decision-making rather than replacing it.

On-demand reporting across the over 300 application portfolio replaces manual aggregation, based on internal project tracking data. Your results might vary based on portfolio size and tool integrations.

Phase 3: SRE Agent for proactive post-migration operations

The SRE Agent represents the final phase: proactive post-migration operations. After applications run on AWS, the SRE Agent shifts the team from reactive firefighting to proactive improvement.

The agent monitors Amazon CloudWatch metrics, application performance data, and historical patterns. It raises alerts before issues affect production. The agent also publishes automated remediation playbooks for common failure patterns and recommends efficiency improvements.

Target areas (with human-in-the-loop approval) include database cluster right-sizing, performance tuning, storage tiering, and compute scaling and efficiency improvements.

The SRE Agent completes the migration lifecycle. Applications don’t land on AWS and stop there. They continuously improve over time.

Data migration with AWS DMS and AWS Transform

Alongside the custom AI agents, two AWS managed services handle the data and application modernization layer.

DMS Schema Conversion with generative AI reduces manual schema mapping effort. It converts code objects that rules-based conversion leaves unfinished, such as stored procedures, functions, and triggers. This capability is generally available in a subset of AWS Regions, so confirm Region support during wave planning. AWS DMS then shortens the cutover window with automated migration tasks. The service integrates directly into the agent pipeline. The IaC Agent provisions target infrastructure, then AWS DMS migrates the data.

AWS Transform handles application-level transformations beyond infrastructure lift-and-shift. It provides application-specific modernization for legacy code, delivering true modernization rather than migration alone.

Security and compliance: Embedded, not bolted on

This architecture embeds security from the start, not as an afterthought, applying it at each phase of the migration lifecycle. Key controls across the agent suite:

• Security standards enforcement: The IaC Agent pulls the enterprise’s security office standards directly from Confluence and applies them across generated IaC using custom MCP tools.
• Landing zone validation: The framework validates generated infrastructure against the enterprise’s landing zone compliance requirements before deployment.
• Human-in-the-loop approval gates: Automated actions across all agents in the suite require explicit human approval before execution. No agent acts autonomously on production systems.
• AgentCore Gateway coordination: Amazon Bedrock AgentCore Gateway coordinates context and security controls across agents, maintaining consistent policy application throughout the migration lifecycle.
• Continuous integration and continuous delivery (CI/CD) integration: The framework integrates security controls into the CI/CD pipeline, with automated test cases generated alongside IaC to catch compliance issues before they reach production.
• Responsible AI controls at the inference layer: Amazon Bedrock Guardrails applies content filters, denied topics, sensitive information filters, and contextual grounding checks to each prompt and each model response. An agent acts only on output that clears the guardrail. Guardrail traces flow into AgentCore Observability alongside the tool-call audit trail.

This approach aligns with the AWS shared responsibility model. AWS provides security of the underlying infrastructure, while you’re responsible for security in the cloud. The agents automate your configuration responsibilities while maintaining human oversight for approval decisions.

In this implementation, the framework maintained enterprise security standards across the over 300 application portfolio at speeds manual processes could not match. Your results might vary based on your security requirements and organizational standards.

Measurable impact

Across the migration program, this framework delivered the following results. These metrics reflect this specific implementation. Your results might vary based on application complexity, team size, and organizational requirements.

• IaC development time reduced from weeks to minutes: from 3–4 weeks per application to minutes of automated generation (based on internal project tracking data).
• Pattern consistency applied across waves: no wave can deviate from the approved IaC patterns baseline.
• Security compliance: verified automatically at each deployment, with a complete audit trail requiring zero manual effort.
• Architecture-to-deployment fidelity improved: the agent interprets the diagram, and the IaC realizes it as designed.
• On-demand portfolio reporting across over 300 applications with precise metrics and zero manual aggregation.
• Wave team onboarding improved: teams upload documents and the framework handles the rest.

Clean up resources

To avoid ongoing charges after you finish testing the framework, remove the resources that you created:

• Delete the agents from AgentCore runtime, then remove the Gateway targets and the Gateway.
• Delete the AgentCore memory resources that hold session state and shared context.
• Delete the guardrail, the Policy in AgentCore definitions, and the IAM roles created for the agents.
• Delete the CloudWatch log groups that AgentCore Observability wrote to, if you no longer need the history.
• Delete any AWS DMS replication instances and endpoints provisioned for test migrations.

Confirm in the Amazon Bedrock AgentCore console that no agent sessions remain active.

Conclusion

Adding more engineers alone doesn’t solve migrating over 300 applications to AWS on an aggressive timeline. It requires a different approach, one where AI agents handle the repetitive, high-volume work while humans focus on decisions, approvals, and strategy.

The multi-agent framework described in this post delivers measurable results today. Purpose-built Strands agents address specific bottlenecks, Amazon Bedrock AgentCore applies security structurally, and human-in-the-loop design keeps automation supporting decision-making rather than replacing it.

Next steps

Based on your use case, consider these paths:

To explore the services used in this post:

For background on the services and SDKs used here, read these AWS posts:

---

About the authors

Nikhil Jha

Nikhil is a Principal at AWS Professional Services, focused on building AI, Cloud Infra and data solutions that help enterprises move from legacy complexity to modern, intelligent systems. He brings deep expertise in Generative AI, agentic architectures, and cloud modernization.

Tarun Tarun

Tarun is a Senior Delivery Consultant at AWS Professional Services, focused on building AI, Cloud Infrastructure, and data solutions that help enterprises move from legacy complexity to modern systems. He brings deep expertise in Generative AI, agentic architectures, cloud modernization, and large-scale migration & disaster recovery, spanning multi-tier architectures, databases, and infrastructure-as-code. His technical depth across Amazon Bedrock, AWS DMS, and DR orchestration enables customers to achieve resilient, high-performing cloud environments at enterprise scale.

Vyas Garigipati

Vyas is a Delivery Consultant at AWS Professional Services, with experience building scalable, distributed systems. He specializes in designing and building AI-powered, high-availability, multi-region architectures and helps customers deploy resilient, production ready solutions on AWS.

Kaushal (KK) Agrawal

Kaushal is a Principal Technology Delivery Leader for the Digital Native Segment of AWS Professional Services, working with top-tier customers to deliver innovation at the intersection of AI and Cloud.