Scaling cloud migrations with agentic AI on Amazon Bedrock AgentCore

AWS Machine Learning Blog

AWS Machine Learning Blog2026年10月1日

Scaling cloud migrations with agentic AI on Amazon Bedrock AgentCore

6.9内容质量

TL;DR · AI 摘要

Scaling cloud migrations with agentic AI on Amazon Bedrock AgentCore Artificial Intelligence Scaling cloud migrations wi...

核心要点

主题聚焦：Scaling cloud migrations with agentic AI on Amaz
来源：AWS Machine Learning Blog，建议结合原文判断细节。
AI 分析暂不可用，本条为保底评分与摘要。

#AI#编程#前端#后端#云计算

打开原文

使用Amazon Bedrock AgentCore上的智能体AI扩展云迁移 | 人工智能

使用Amazon Bedrock AgentCore上的智能体AI扩展云迁移

2026年10月：本文已审查并更新以确保准确性。

在Amazon Bedrock AgentCore上使用智能体AI扩展云迁移引发了一个实际问题：大型迁移计划中哪些部分应由托管服务处理，哪些部分需要自定义自动化？一个企业计划通过300多个应用程序和固定财政年度截止日期回答了这个问题。根据内部项目跟踪数据，本文中提到的四智能体模式将基础设施即代码（IaC）开发时间从每个应用程序的3到4周缩短到分钟级。

该模式与AWS Transform并行运行，而非取而代之，作为混合方案在需要时添加自定义智能体。AWS Transform负责迁移和现代化工作，AWS数据库迁移服务（AWS DMS）负责数据库层级。本文中的智能体连接到这些服务并增加了一个进一步要求：通过组织构建和维护的模型上下文协议（MCP）工具访问源和目标。

AWS专业服务为有此需求的计划构建了一套专用AI智能体。这些智能体使用Strands智能体SDK，并在Amazon Bedrock AgentCore上运行，这是一个可以按任意框架或模型构建、连接和优化智能体的平台。每个智能体通过AgentCore网关暴露的MCP工具访问其源和目标。

在本文中，您将探索与MCP连接环境的四智能体模式架构。您还将看到定义智能体、将其连接到工具并应用负责任AI控制的代码。该模式包含四个智能体：

接收智能体：通过MCP工具从文档和协作系统中读取迁移输入。
IaC智能体：生成由您批准的内部模块组成的IaC。
迁移智能和治理智能体：在您自己的计划工具中进行报告和治理。
迁移后运维的站点可靠性工程（SRE）智能体。

要跟随本文操作，您需要拥有可访问Amazon Bedrock AgentCore和Amazon Bedrock基础模型的AWS账户。您还需要熟悉Strands智能体SDK和MCP服务器模式，以及组织使用的IaC工具。首先确认AWS托管服务是否已覆盖您的迁移路径。

适用场景

AWS Transform作为托管服务，涵盖服务器、网络、大型机、.NET和应用程序代码工作负载的迁移和现代化，AWS DMS涵盖数据库。此模式为特定于您组织的需求添加智能体。

在本文描述的计划中，三个条件同时成立：

通过MCP连接的源和目标：存储迁移输入的系统和接收输出的系统，都是交付团队构建和维护的MCP工具所连接的。其中包括存储安全标准的内部维基、工单系统、协作平台和内部配置API。

特定于组织的IaC组合：生成的基础设施代码需要组合内部模块库，该模块库由安全部门审核并批准。手动编写这种组合需要每个应用耗时3到4周，对于300多个应用的组合，这意味着需要投入数年的工程工作量。

迁移后的持续工作：项目范围包含交接后的运营工作，这部分内容超出了迁移服务的范畴。

架构概览

该模式使用了四种专用代理。架构在三个关键点与迁移项目连接：存储迁移输入的系统、IaC组合以及交接后的运营。该模式在每个连接点都应用了安全措施。下图展示了代理、工具和AWS服务之间的连接方式。

图1：代理如何通过Model Context Protocol工具调用在迁移和运营过程中进行连接

该模式将代理组织为两个流程。迁移流程代理负责从发现到部署的处理。运营流程代理负责迁移后的监控。

迁移流程代理：

收集代理（阶段1）：通过MCP工具读取架构文档、问卷和依赖关系记录，然后定义目标架构状态。

IaC代理（阶段2）：为每个应用生成IaC代码，该代码组合您已批准的内部模块。

迁移智能与治理代理：在Jira、Confluence和Webex上提供自动化组合报告、良好架构评估和治理。

运营流程代理：

SRE代理（阶段3）：在交接后提供监控和自动化修复。

AWS托管服务负责迁移并补充自定义代理：

AWS数据库迁移服务（AWS DMS）：通过生成式AI辅助的模式转换和自动化交接，实现数据库迁移。

AWS Transform：发现、波次规划、着陆区创建、网络转换、重新托管或重新平台执行，以及针对大型机、虚拟化和.NET工作负载的现代化改造。

组件连接方式

本节描述框架组件在运行时的交互方式。

每个代理都是一个Strands代理，由基础模型、系统提示和工具集定义。Amazon Bedrock AgentCore运行时在无服务器环境中托管它们，具备会话隔离和多代理编排功能。Amazon Bedrock基础模型提供推理能力，用于解释文档、生成代码并驱动多步骤工作流。有关AWS区域的模型可用性，请参阅《Amazon Bedrock支持的基础模型》。

每个代理通过AgentCore网关调用与其功能范围对应的MCP工具，这是Amazon Bedrock AgentCore的一项功能，可将您的API、AWS Lambda函数和现有服务转换为兼容MCP的工具。AgentCore身份，作为Amazon Bedrock AgentCore的一项功能，通过范围限定的AWS身份和访问管理（IAM）角色和您的身份提供商对每个调用进行身份验证。

Amazon Bedrock AgentCore内存存储代理会话状态和共享上下文。代理使用此共享上下文来持久化输出并跟踪超过300个应用的迁移进度。当收集代理完成发现后，它会将目标架构和依赖关系映射写入AgentCore内存。IaC代理读取此共享上下文，无需人工交接即可开始代码生成。

以代码定义代理

以下 Python 示例定义了 IaC 代理并为其准备 Amazon Bedrock AgentCore 运行时环境。代理通过 AgentCore 网关访问您的 MCP 工具，并通过 Amazon Bedrock 调用基础模型，同时附加了 Amazon Bedrock Guardrails 策略。

code

import json
 import logging
 import os
 import uuid
 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 让 SDK 执行 client_credentials 授权流程，并在令牌过期时重新生成令牌
 # 静态捕获的 bearer 令牌会随时间失效
 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"}

python

try:
    with gateway:
        # 首先获取此波次的已批准策略，使规则通过系统提示传递，而不是依赖模型去查询
        lookup = gateway.call_tool_sync(
            tool_use_id=str(uuid.uuid4()),
            name="get_policies",
            arguments={
                "resource_types": payload.get("resource_types", []),
                "wave": payload.get("wave"),
            },
        )
        if lookup["status"] != "success":
            return {"status": "error", "error": "策略查询失败"}
        policies = lookup.get("structuredContent", {})

        # tools=[gateway]: SDK 管理连接生命周期并分页工具发现，这需要超出 list_tools_sync() 的范围
        agent = Agent(
            model=model,
            system_prompt=(
                f"{IAC_AGENT_PROMPT}\n\n"
                f"生成的 IaC 遵循这些已批准的策略:\n"
                f"{json.dumps(policies.get('policies', []), indent=2)}"
            ),
            tools=[gateway],
        )
        result = agent(prompt)

    if result.stop_reason == "guardrail_intervened":
        logger.warning("防护栏阻止了请求, session_id=%s",
                       getattr(context, "session_id", None))
        return {"status": "blocked_by_guardrail"}

    return {
        "status": "ok",
        "iac": str(result),
        "policy_set_version": policies.get("version"),
        "waived_policies": policies.get("waived", []),
    }

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

如果 __name__ == "__main__": app.run()

步骤1：摄入指导文件。代理从波团队读取指导文件，提取部署范围、合规约束以及安全办公室批准的特定波次覆盖项。

步骤2：解读目标状态架构图。IaC代理基于摄入代理的输出，识别基础设施组件及其关系和依赖项。

步骤3：生成IaC。根据该解读，代理使用您定义并建立的模式生成IaC。它用特定波次参数填充配置，配置远程状态管理，然后应用强制标签并添加符合组织标准的监控配置。

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

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

自定义MCP工具：安全基础

每个操作都会经过Amazon Bedrock AgentCore网关暴露的自定义MCP工具，并由AgentCore身份和策略管理。AgentCore身份通过具有最小权限访问的范围化IAM角色对每个代理操作进行身份验证。框架会将输入与定义的模式进行验证，并在边界处拒绝格式错误的输入。

没有凭证或敏感值会通过代理上下文传递，因为AgentCore身份会在运行时从集中式凭证提供者解析机密。AgentCore Observability和AWS CloudTrail会将每个代理操作写入不可变的集中式审计日志。AgentCore中的策略强制执行Cedar规则，防止单个操作影响超过定义的阈值。

精选的组织策略作为MCP工具

安全办公室负责制定策略集，而非代理。版本化文档包含每条规则、其覆盖的资源类型、可由机器验证的断言以及批准记录。以下示例展示了三条策略和一个波次例外。

code

{
    "policy_set": "security-office/baseline",
    "version": "2026.09.1",
    "policies": [
      {
        "id": "SEC-ENC-001",
        "applies_to": ["aws_s3_bucket", "aws_ebs_volume", "aws_rds_cluster"],
        "requirement": "使用客户管理的KMS密钥对静态数据进行加密",
        "assertion": "kms_key_id != null and sse_algorithm == 'aws:kms'",
        "severity": "blocking",
        "source": "SecOffice/Encryption-Standard-v4"
      },
      {
        "id": "SEC-NET-014",
        "applies_to": ["aws_security_group_rule"],
        "requirement": "禁止从0.0.0.0/0进入管理端口",
        "assertion": "not (cidr_blocks contains '0.0.0.0/0' and to_port in [22, 3389])",
        "severity": "blocking",
        "source": "SecOffice/Network-Standard-v7"
      },
      {
        "id": "OPS-TAG-003",
        "applies_to": ["*"],
        "requirement": "必须包含所有者、成本中心、数据分类和波段标签",
        "assertion": "tags has_keys ['owner', 'cost-center', 'data-classification', 'wave']",
        "severity": "blocking",
        "source": "SecOffice/Tagging-Standard-v2"
      }
    ],
    "wave_overrides": [
      {
        "wave": "wave-14",
        "policy_id": "SEC-NET-014",
        "decision": "exception",
        "expires_on": "2026-10-31",
        "approved_by": "security-office"
      }
    ]
  }

一个AWS Lambda函数提供该文档，AgentCore Gateway将其作为名为get_policies的MCP工具公开。IaC代理仅请求其生成的波段中资源类型的相关策略。

code

import json
  from datetime import date
  from pathlib import Path
 
  POLICY_SET = Path("policies/security-office-baseline.json")
 
  def get_policies(event, context):
      """返回请求资源类型和波段的已批准策略。
 
      AgentCore Gateway将此函数作为get_policies MCP工具公开。
      """
      doc = json.loads(POLICY_SET.read_text())
      requested = set(event.get("resource_types") or [])
      today = date.today()
      waived = {
          o["policy_id"]
          for o in doc["wave_overrides"]
          if o["wave"] == event.get("wave")
          and date.fromisoformat(o["expires_on"]) >= today
      }
      policies = [
          p for p in doc["policies"]
          if (p["applies_to"] == ["*"] or requested & set(p["applies_to"]))
          and p["id"] not in waived
      ]
      return {
          "version": doc["version"],
          "policies": policies,
          "waived": sorted(waived),
      }

响应包含策略集版本，因此生成的代码会记录哪些规则产生了该版本，审查人员可以追溯资源到已批准的标准。豁免的策略会单独列出而不是消失，合规报告会为每个波段列出这些策略。每个例外都带有到期日期，因此过期的豁免会自动停止应用而无需手动清理。

此处存在两个策略层级，它们回答不同的问题。AgentCore策略评估Cedar规则以决定代理是否调用工具。精选策略集决定生成的基础设施需要满足哪些要求。

基于您模式的IaC生成

IaC代理根据您定义和建立的模式生成基础设施代码。这些模式将组织标准编码为可重复使用的构建模块。它们包括网络配置、安全组规则、IAM角色、Amazon CloudWatch警报、Amazon Elastic Compute Cloud（Amazon EC2）配置、Amazon Virtual Private Cloud（Amazon VPC）布局以及强制性标签。

这种方法在不同阶段之间提供了一致性，为不从头编写基础设施代码的阶段团队提供速度，并在安全更新传播到消费者下一次部署周期时实现治理。

输出工件

该代理为每个应用程序生成IaC代码、自动化测试用例、合规性报告和部署操作手册。

IaC代理直接将生成的代码推送到您的代码仓库（如AWS CodeCommit、GitLab或Bitbucket）。从那里，它进入您现有的审查和部署流程，无需对现有工具链进行更改。

迁移智能与治理代理：全组合视图

一个包含300多个应用程序的组合需要状态报告、进度跟踪、后续操作和良好架构验证。在此项目中，这些工作在客户的Jira、Confluence和Webex中进行。手动执行这些操作会给项目经理和交付负责人带来显著的负担。

迁移智能与治理代理通过组合范围内的自动化按需智能和治理解决了这个问题。它通过AgentCore网关从三个来源聚合数据。Jira提供冲刺进度和障碍。Confluence提供架构文档和操作手册。Webex提供会议记录和行动项。

该代理提供迁移工作负载的架构评估、合规性和治理验证以及架构模式遵循跟踪。

自动化操作包括使用最新的迁移状态更新Confluence页面、为识别出的行动项创建Jira任务，以及为升级生成ServiceNow工单。这些操作在执行前需要明确的人工批准。这种需要人工批准的架构是四个代理的核心设计原则。代理支持人类决策，而不是取代它。

基于内部项目跟踪数据，300多个应用程序组合的按需报告取代了手动聚合。您的结果可能会根据组合规模和工具集成情况有所不同。

第三阶段：迁移后主动运维的SRE代理

SRE代理覆盖交接后的阶段。迁移服务在切换时完成。在应用程序运行于AWS之后，SRE代理将团队从被动响应转向主动改进。

该代理监控Amazon CloudWatch指标、应用程序性能数据和历史模式。它在问题影响生产环境之前发出警报。该代理还为常见故障模式发布自动化修复操作手册，并推荐效率改进措施。

目标领域（需人工参与批准）包括数据库集群的合理调整、性能调优、存储分级以及计算扩展和效率改进。

SRE代理将模式延伸到迁移之外。应用程序不会在AWS上落地后就停止。它们会随着时间的推移持续改进。

使用AWS DMS进行数据迁移

除了自定义AI代理外，两个AWS托管服务处理数据和应用现代化、服务器和网络迁移层。

使用生成式AI进行DMS模式转换可减少人工模式映射的工作量。它能够转换基于规则的转换未完成的代码对象，例如存储过程、函数和触发器。此功能在部分AWS区域一般可用，因此在波次规划期间请确认区域支持。AWS DMS随后通过自动化迁移任务缩短切换窗口。该服务直接集成到代理流水线中。IaC代理负责部署目标基础设施，然后AWS DMS进行数据迁移。

AWS Transform覆盖同一程序的服务器、网络和代码层。《AWS Transform用户指南》按工作负载类型列出了当前功能。

安全与合规：内嵌设计，而非后期添加

此架构从一开始就内嵌安全机制，而非作为事后考虑，在迁移生命周期的每个阶段均应用安全控制。代理套件的关键控制措施包括：

安全标准执行：IaC代理直接从Confluence拉取您的安全办公室标准，并通过自定义MCP工具应用于生成的IaC中。
落地区验证：框架在部署前验证生成的基础设施是否符合企业的落地区合规要求。
人工审批关卡：套件中所有代理的自动化操作在执行前需要明确的人工审批。任何代理都不会在生产系统上自主操作。
AgentCore网关协调：Amazon Bedrock AgentCore网关在代理之间协调上下文和安全控制，确保整个迁移生命周期中策略应用的一致性。
持续集成与持续交付（CI/CD）集成：框架将安全控制集成到CI/CD流水线中，与IaC一同生成自动化测试用例，以在进入生产环境前捕获合规问题。
推理层负责任AI控制：Amazon Bedrock Guardrails对每个提示和每个模型响应应用内容过滤器、禁止主题、敏感信息过滤器和上下文接地检查。代理仅对通过护栏检查的输出进行操作。护栏追踪与工具调用审计日志一同流入AgentCore可观测性。

此方法符合AWS共享责任模型。AWS负责底层基础设施的安全，而您负责云环境中的安全。代理自动化您的配置职责，同时保留人工监督以进行审批决策。

在此次实施中，该模式以人工流程无法比拟的速度，在超过300个应用程序组合中保持了企业安全标准。您的结果可能因安全需求和组织标准的不同而有所差异。

可衡量的影响

在整个迁移计划中，该框架实现了以下成果。这些指标反映本次具体实施的情况。您的结果可能因应用程序复杂性、团队规模和组织需求的不同而有所差异。

IaC开发时间从周缩短至分钟：从每个应用程序需要3-4周减少到自动化生成的几分钟（基于内部项目跟踪数据）。
波次间模式一致性：任何波次都不能偏离已批准的IaC模式基线。
安全合规性：每次部署时自动验证，完整的审计日志无需任何人工操作。

架构到部署的保真度提升：代理解析图表，IaC（Infrastructure as Code）按照设计实现。

超过300个应用程序的按需投资组合报告，具备精确指标且无需人工汇总。

波浪团队入职流程优化：团队上传文档后，代理自动生成IaC和报告。

成本考量

采用此模式会在几个可预测的方面产生成本。基础模型令牌通常占主导地位，因为输入和IaC生成需要将文档、策略和架构上下文通过模型处理并返回生成的代码。Amazon Bedrock AgentCore按使用量计费。运行时按秒计费，根据会话使用的CPU和内存资源收费，当代理等待模型响应或人工审批时，CPU会自动缩容至零。网关、内存、策略和防护措施均按使用单位计费，可观测性遥测数据按Amazon CloudWatch费率计费。

在300多个应用程序的投资组合中，代理在整个迁移计划期间持续运行，而非单次作业，因此应将其视为与波浪活动相关的持续运行成本。令牌数量主要受文档大小和工具调用次数影响，而非应用程序数量，因此试点波浪可为每个应用程序提供基准数据。在AWS Transform方面，针对虚拟化、Windows和大型机工作负载的评估和迁移代理均为免费。迁移创建的资源按常规计费，自定义转换则按代理分钟计费。当前费率请参阅Amazon Bedrock定价、Amazon Bedrock AgentCore定价、AWS Transform定价、Amazon CloudWatch定价和AWS定价计算器。

清理资源

完成框架测试后，为避免持续收费，请删除创建的资源：

从AgentCore运行时中删除代理，然后删除网关目标和网关。

删除存储会话状态和共享上下文的AgentCore内存资源。

删除防护措施、AgentCore定义中的策略以及为代理创建的IAM角色。

如果不再需要历史记录，请删除AgentCore可观测性写入的CloudWatch日志组。

删除为测试迁移预置的AWS DMS复制实例和端点。

在Amazon Bedrock AgentCore控制台中确认没有剩余的代理会话。

结论

在激进的时间表下将300多个应用程序迁移到AWS，仅靠增加工程师是不够的。托管服务承担了大部分工作。当需求超出托管服务范围时，代理模式可以在人类保持决策、审批和战略的同时填补空白。

此模式在一个源和目标均位于MCP工具后的项目中实现了可衡量的结果。专为Strands设计的代理解决了特定需求，Amazon Bedrock AgentCore从结构上应用了安全措施，而人机协作设计使自动化支持而非取代决策。使用AWS Transform和AWS DMS进行迁移，并在MCP连接的源和目标场景中与这些代理协同运行。

下一步

根据您的使用场景，考虑以下路径：

计划迁移？将AWS Transform连接到您喜爱的AI代码助手，开始服务器、网络、代码迁移和现代化改造，并使用AWS DMS进行数据库迁移。

源和目标位于MCP工具后？评估此模式。查看Amazon Bedrock AgentCore了解如何构建和部署代理。

是否需要使用内部模块库？评估 IaC Agent。在该项目中，与手动基准相比，IaC 开发时间从数周缩短至几分钟。

是否需要在自有程序工具中实现治理？考虑使用迁移智能与治理代理，用于状态报告和架构评估。了解更多关于 Amazon Bedrock AgentCore 内存功能的信息，用于代理状态管理。

迁移后？探索 SRE Agent 模式，从被动运维转向主动优化。使用 Amazon CloudWatch 进行监控和自动化告警。

是否要构建自己的代理？从 Strands Agents SDK 和 Amazon Bedrock AgentCore 开始，结合针对迁移瓶颈优化的 MCP 服务器。打开 Amazon Bedrock AgentCore 控制台开始使用，阅读《将 Strands Agents 部署到 Amazon Bedrock AgentCore 运行时》。

要了解本文中使用的服务：

Amazon Bedrock AgentCore：以安全方式大规模部署和运行 AI 代理。

AWS Transform：迁移和现代化基础设施、应用及代码。

Strands Agents SDK：使用模型、提示和工具构建 AI 代理。

AWS 数据库迁移服务（AWS DMS）：将数据库迁移至 AWS。

AWS 身份与访问管理（IAM）：管理对 AWS 服务的访问权限。

Amazon CloudWatch：监控 AWS 资源和应用。

Amazon Bedrock AgentCore 文档：运行时、网关、内存、身份和可观测性。

关于本文中使用的服务和 SDK 的背景信息，请阅读以下 AWS 博客：

介绍 Amazon Bedrock AgentCore：以任意规模安全地部署和运行 AI 代理。

介绍 Strands Agents：一个开源 AI 代理 SDK。

在 AWS DMS 架构转换中使用智能 AI 加速数据库现代化。

Scaling cloud migrations with agentic AI on Amazon Bedrock AgentCore

TL;DR · AI 摘要

核心要点

使用Amazon Bedrock AgentCore上的智能体AI扩展云迁移 | 人工智能

使用Amazon Bedrock AgentCore上的智能体AI扩展云迁移

适用场景

架构概览

组件连接方式

以代码定义代理

自定义MCP工具：安全基础

精选的组织策略作为MCP工具

基于您模式的IaC生成

输出工件

迁移智能与治理代理：全组合视图

第三阶段：迁移后主动运维的SRE代理

使用AWS DMS进行数据迁移

安全与合规：内嵌设计，而非后期添加

可衡量的影响

成本考量

清理资源

结论

下一步

作者简介