亚马逊AWS官方博客

制造业智能化转型新引擎：基于AWS Bedrock AgentCore构建生产管理智能体系统

1.引言

在制造业数字化转型过程中，传统的生产管理系统面临着新的技术挑战。从设备监控、质量控制到供应链协调，制造企业需要处理大量的实时数据，并基于这些数据做出运营决策。传统的工具型应用基于”请求-响应”模式，需要明确的用户指令，依赖预定义的业务逻辑。而Agentic AI提供了一种新的技术方案，具备自主性、目标导向、动态适应和多模态协作等特点。

然而，在制造业场景中构建智能体系统面临着诸多技术挑战和业务痛点。首先是

系统集成复杂性：制造企业通常拥有多套异构系统（MES、ERP、SCADA、PLCs等），这些系统采用不同的通信协议和数据格式，智能体需要与这些系统无缝集成，但传统的API集成方式开发周期长、维护成本高。其次是 数据处理的实时性要求：生产线上的设备状态、质量检测、工艺参数等数据需要毫秒级响应，智能体必须具备高并发、低延迟的数据处理能力。第三是 领域知识的积累与传承：制造业的工艺知识、故障诊断经验、质量控制标准等专业知识需要智能体能够持续学习和记忆，但大多数AI系统缺乏有效的知识管理机制。最后是 企业级安全与合规：制造企业对数据安全、访问控制、审计追踪有严格要求，智能体系统必须满足工业级的安全标准和合规要求。

Amazon Bedrock AgentCore正是为了解决这些挑战而设计的企业级智能体基础设施平台。AgentCore通过模块化的服务架构，为制造业智能体开发提供了完整的解决方案：

Gateway 服务自动将现有系统API转换为MCP兼容工具，大幅简化系统集成复杂度； Runtime 服务提供高性能的无服务器环境，满足实时数据处理需求； Memory 服务实现智能体的知识积累和经验传承； Identity 服务确保企业级的安全访问控制； Observability 服务提供全面的监控和追踪能力。这种标准化的基础设施组件不仅简化了开发和部署流程，更重要的是让制造企业能够快速构建具备工业级可靠性和安全性的智能体系统。

2.Amazon Bedrock AgentCore核心架构

Amazon Bedrock AgentCore 并非单一产品，而是一套完整的服务，为您的智能体提供核心能力，这些服务既可以独立使用，也可以协同工作：

2.1. AgentCore Runtime（运行时服务）

AgentCore Runtime是智能体执行的核心引擎，提供了高性能、可扩展的无服务器运行环境。该服务支持会话隔离机制，确保不同用户或业务场景下的智能体实例相互独立运行，避免数据泄露和性能干扰。Runtime服务兼容多种主流智能体框架，包括CrewAI、LangGraph、Strands等开源框架，开发者可以选择最适合的框架来构建智能体应用。

在制造业场景中，Runtime服务可以同时运行多个专业化智能体，例如质量控制智能体负责实时监控产品质量指标，预测性维护智能体分析设备运行状态并预警潜在故障，供应链优化智能体协调原材料采购和库存管理。这些智能体可以处理多模态数据输入（文本、图像、传感器数据），并支持长时间运行的复杂任务，如连续的生产线监控和优化。

2.2.AgentCore Memory（记忆服务）

AgentCore Memory提供了智能体的记忆管理能力，支持短期记忆和长期记忆两种模式。短期记忆用于维护当前会话的上下文信息，确保智能体在对话过程中能够理解前后文关联；长期记忆则存储跨会话的重要信息，包括历史决策、学习经验和业务知识，使智能体具备持续学习和经验积累的能力。

在制造业应用中，Memory服务能够帮助智能体记住历史生产数据、质量问题模式和解决方案。例如，当质量控制智能体检测到产品缺陷时，它可以从长期记忆中检索类似的历史案例，快速定位问题根因并提供解决建议。同时，智能体会将新的问题处理经验存储到长期记忆中，不断提升问题诊断和解决的准确性。这种记忆机制使得智能体能够从”新手”逐步成长为”专家”，为企业积累宝贵的生产管理知识。

2.3.AgentCore Gateway（网关服务）

AgentCore Gateway是智能体与外部系统集成的桥梁，能够自动将现有的API、Lambda函数和企业服务转换为MCP（Model Context Protocol）兼容的工具。这种转换机制大大简化了智能体与传统企业系统的集成复杂度，开发者无需重写现有接口，只需通过Gateway配置即可实现无缝连接。

在制造业环境中，Gateway服务可以将MES（制造执行系统）、ERP（企业资源规划）、SCADA（数据采集与监控）等系统的API统一封装为智能体可调用的工具。例如，生产调度智能体可以通过Gateway服务查询ERP系统中的订单信息、调用MES系统更新生产计划、从SCADA系统获取实时设备状态。这种统一的工具访问接口使得智能体能够跨系统协调资源，实现端到端的生产管理自动化。

2.4.AgentCore Identity（身份服务）

AgentCore Identity提供了企业级的身份认证和访问控制能力，确保智能体在复杂的企业环境中安全运行。该服务支持与主流身份提供商（如Okta、Microsoft Entra、Amazon Cognito）的集成，实现单点登录和统一身份管理。智能体可以代表特定用户或角色执行操作，并严格遵循企业的权限策略。

在制造业场景中，不同的智能体需要访问不同级别的系统和数据。例如，车间主管的智能体助手可以访问生产计划和人员调度系统，而操作员的智能体只能查看当前工位的任务信息。Identity服务确保每个智能体都在其授权范围内运行，防止越权访问敏感的生产数据或关键控制系统，同时支持审计追踪，满足制造业的合规要求。

2.5.AgentCore Observability（可观测性服务）

AgentCore Observability基于Amazon CloudWatch构建，提供了全面的智能体监控和追踪能力。该服务包含内置的仪表板和遥测数据收集，能够实时监控智能体的性能指标、错误率、响应时间等关键指标。开发者和运维人员可以通过可视化界面快速识别问题，并进行根因分析。

在制造业生产环境中，Observability服务对于确保智能体系统的稳定运行至关重要。例如，当预测性维护智能体的响应时间异常增长时，运维团队可以立即收到告警，并通过详细的追踪日志定位是模型推理延迟还是数据源连接问题。该服务还支持与企业现有的监控系统集成，形成统一的运维管理平台，确保智能体系统与传统IT基础设施的协同监控。

2.6.AgentCore Tools（工具服务）

AgentCore Tools提供了丰富的预构建工具库和自定义工具开发能力，其中包括安全的代码解释器，支持智能体动态编写和执行代码来解决复杂问题。该服务还提供了数据分析、文档处理、API调用等常用工具，开发者可以根据业务需求扩展工具集，增强智能体处理端到端任务的能力。

在制造业应用中，Tools服务使智能体能够执行复杂的数据分析和计算任务。例如，工艺优化智能体可以使用代码解释器分析生产数据，计算最优的工艺参数组合；质量分析智能体可以调用统计分析工具，识别产品质量与工艺参数之间的关联模式。这种动态的工具调用能力使智能体不仅能够理解和推理，还能够执行具体的技术操作，真正实现从决策到执行的闭环自动化。

这种模块化架构设计使得开发者可以根据具体需求选择合适的服务组合，同时保持系统的灵活性和可扩展性。本文将重点介绍如何在制造业场景中利用AgentCore的Memory和Gateway服务构建智能生产管理系统。

3.场景示例 – Amazon Bedrock AgentCore在制造业智能体系统中的应用实践

在这个示例中，我们将针对制造业在进行生产管理智能体系统构建中，如何利用Amazon Bedrock AgentCore的Memory和Gateway服务进行智能生产管理系统的构建。我们将通过Python代码示例展示如何集成这些服务，并设计一个具备记忆能力的生产运维 agent，同时，通过Gateway服务，将已有的生产管理系统API转成MCP兼容的工具，从而实现智能体与现有系统的无缝集成。

3.1.场景示例

在制造业中，智能体的价值远不止于执行预设指令。其真正的颠覆性在于，它能否像一位人类专家一样，在解决问题的过程中不断学习、积累经验，最终成长为能够独当一面的“数字专家”。这正是 Amazon Bedrock AgentCore Memory 服务的核心使命。

下面，我们将通过一个真实的生产运维场景，展示智能体如何完成从“执行者”到“学习者”的蜕变。

在这个阶段，智能体不仅解决了当前问题，更重要的是，它通过与专家的互动，捕获了宝贵的、未被文档化的“隐性知识”

3.2.整体架构设计

在制造业环境中，我们的智能体系统需要处理多个关键场景：

• 设备状态监控与预测性维护
• 生产质量实时分析与异常处理
• 供应链协调与库存优化
• 工艺参数优化与调整建议

3.3.能力集成解析

3.3.1.关键技术一：Memory 模块

根据AWS Bedrock AgentCore官方文档，Memory服务提供了标准化的API来管理短期和长期记忆。以下是在制造业场景中的具体实现方式：

安装依赖：

pip install bedrock-agentcore

短期记忆（** **Short-term Memory** **）

短期记忆用于维护当前会话的上下文信息，支持问题解决过程中的知识积累和经验更新：

长期记忆（Long-term Memory** **）

长期记忆是智能体实现“越用越聪明”的核心。它通过内置的多种策略（如会话摘要、语义事实提取），自动从短期记忆的“原始素材”中提炼出可供未来复用的“知识点”或“规则”，长期记忆支持跨会话的信息提取和存储，提供三种策略：

用户偏好策略（UserPreferenceMemoryStrategy）：基于行为模式识别的偏好学习

• 通过统计分析操作员的历史决策路径，识别个体化的问题解决模式
• 使用频率统计和序列模式挖掘技术记录操作偏好
• 基于用户画像模型提供个性化的操作建议

语义事实策略（ SemanticMemoryStrategy ）：基于知识图谱的事实存储与关联

• 采用实体-关系-属性三元组结构存储设备技术知识
• 通过语义相似度计算建立故障症状与解决方案的关联映射
• 使用增量学习机制动态更新知识库内容

会话摘要策略（ SummaryMemoryStrategy ）：基于抽取式和生成式结合的摘要生成

• 使用关键词提取和重要性评分算法识别会话中的核心信息
• 通过时间序列分析提取生产活动的关键事件节点
• 采用层次化摘要结构生成不同粒度的活动概览

通过查询经过此前短时记忆提取到的内容，可以看到，Memory 模块从中提取到了关键信息：

制造业Memory应用的主要特点：

标准化API：使用AWS官方SDK，提供稳定性和兼容性

自动化管理：减少手动管理向量存储和检索逻辑的工作量

多策略支持：支持不同类型的长期记忆提取策略

会话隔离：通过session_id和actor_id实现多用户、多会话的记忆隔离

企业级安全：集成AWS IAM和安全机制

这种基于AWS官方SDK的实现方式使制造业智能体的记忆管理符合企业级标准，并满足生产环境的实时性和可靠性要求。

3.3.2.关键技术二：AgentCore gateway

AgentCore Gateway提供了一个统一的接口，将现有的API和服务转换为智能体可用的工具。通过MCP（Model Context Protocol）协议，Gateway能够实现跨协议的统一访问，支持语义搜索和运行时发现功能。

3.3.2.1.Gateway设置与配置

基于实际的实现代码，以下是通过Gateway将一个已有的服务转换成 MCP 工具的的完整设置流程，其主要包含三个核心步骤：OAuth认证配置、Gateway创建和API目标集成。

• 初始化基础配置

首先需要初始化Gateway客户端和相关的AWS服务连接：

关键说明：

• GatewayClient：AgentCore提供的高级客户端，简化Gateway操作
• bedrock-agentcore-control：底层AWS服务客户端，用于直接管理Gateway资源
• 区域配置：建议使用支持AgentCore服务的区域
• OAuth 授权服务器创建

Gateway需要OAuth认证来保护API访问：

关键说明

：** **使用** **AWS Cognito** **作为** **OAuth** **提供商，自动处理用户池和应用客户端创建** **认证配置包含客户端** **ID** **、用户池信息等，需要保存供** **Agent** **使用** **每个** **Gateway** **都有独立的认证配置，确保安全隔离

• Gateway核心创建

创建MCP Gateway是整个流程的核心：

关键说明： MCP 协议：Model Context Protocol，AgentCore的核心通信协议 自动 IAM 角色：设置role_arn=None让系统自动创建具有适当权限的IAM角色 语义搜索：启用后Gateway可以理解API的语义含义，提供更智能的工具发现 权限传播：AWS IAM权限需要时间传播，等待30秒确保权限生效

• API目标集成

将目标API集成到Gateway中：

关键说明

：

• OpenAPI规范

：标准的** **API** **描述格式，** **Gateway** **通过它理解** **API** **的结构和功能

• 凭证配置

：支持多种认证方式（** **API Key** **、** **Bearer Token** **等）

• 目标类型

：** **openApiSchema** **表示基于** **OpenAPI** **规范的** **REST API** **集成

• 内联载荷

：直接在配置中包含** **API** **规范，适合小型** **API

• 配置保存与管理

保存Gateway** **配置供Agent** **使用，并提供管理功能：

关键说明

：

• Gateway URL

：** **Agent** **连接** **Gateway** **的** **MCP** **端点

• 客户端信息

：包含** **OAuth** **认证所需的客户端** **ID** **和密钥

• 配置文件

：** **Agent** **运行时加载此配置文件获取连接信息

• 完整设置流程

流程总结：

• 认证设置：创建OAuth服务器，建立安全访问机制
• Gateway创建：建立MCP通信端点，启用智能功能

API 集成：将制造业系统API转换为Agent工具 配置保存：为Agent运行准备连接信息

这种设计确保了制造业系统的安全性、可扩展性和易用性。

3.3.2.2.Agent运行和测试

制造业Agent的运行包含认证设置、模型配置、工具发现和交互式查询等核心环节。

• Agent初始化和配置加载
• 配置文件

：包含** **Gateway URL** **、认证信息和区域设置

• MCPClient

：与** **Gateway** **通信的核心客户端

• BedrockClient

：调用** **AWS Bedrock** **大语言模型的客户端

• OAuth 认证流程

Agent需要通过OAuth获取访问令牌才能连接Gateway：

关键说明：

• 客户端凭证流：使用OAuth 2.0客户端凭证流进行机器到机器认证
• 访问令牌：获取的令牌用于后续所有Gateway API调用
• Cognito集成：利用AWS Cognito提供的OAuth端点
• Bedrock 模型配置

配置用于理解和生成制造业相关内容的大语言模型： 关键说明： Claude 4 Sonnet：推荐的制造业场景模型，具备强大的推理和工具调用能力 区域一致性：确保Bedrock模型与Gateway在同一区域 模型选择：可根据成本和性能需求选择不同的Bedrock模型

• MCP 客户端连接

建立与** **Gateway** **的** **MCP** **协议连接：

关键说明

：

• WebSocket连接

：** **MCP** **使用** **WebSocket** **协议进行实时通信

• 认证头

：访问令牌通过** **Authorization** **头传递

• 连接状态

：需要检查连接状态确保通信正常

• 工具发现和管理

发现Gateway** **提供的制造业工具：** **关键说明：

• 动态发现：工具列表从Gateway动态获取，支持热更新
• 工具元数据：包含工具名称、描述、参数schema等信息
• 分页支持：大量工具时支持分页获取
• 业务查询处理

处理用户的制造业相关查询：

关键说明

：

• 领域专用提示：针对制造业场景优化的系统提示
• 工具上下文：将可用工具信息提供给模型
• 参数调优：低温度设置确保回答的准确性和一致性
• 交互式会话

提供用户友好的交互界面：

关键说明

：

• 命令支持：内置命令如查看工具列表、退出会话
• 错误处理：优雅处理用户输入错误和系统异常
• 会话状态：维护对话上下文和工具状态
• 完整代码运行流程

流程总结：

• 认证阶段：获取OAuth访问令牌
• 连接阶段：建立MCP客户端连接
• 发现阶段：获取可用的制造业工具
• 交互阶段：处理用户查询和工具调用
• 清理阶段：释放连接和资源

这种架构确保了制造业Agent的稳定性、可扩展性和用户体验。

4.基于南洋星宫的智能体工具管理和调用

5.总结

借助 AWS Bedrock AgentCore，我们构建的不再是传统的自动化工具，而是一个能够沉淀企业智慧、并自主解决问题的“数字劳动力”：

|业务维度 (Business Dimension)

|传统人工模式 (Traditional Manual Approach)

|AgentCore 赋能的智能体模式 (AgentCore-Powered Agent Approach)

|价值提升 (Value Improvement)

|

故障排查效率 (MTTR) |

2-8 小时，依赖资深专家经验和到场支持 |

5-15 分钟，智能体7×24小时在线，主动诊断并提供解决方案 |

平均解决时长缩短 >90%

|

知识传承与利用 |专家经验随个人流失，新员工上手周期

3-6 个月 |专家经验沉淀为可复用的数字资产，赋能全员

|

新员工上手时间缩短 ~75% ，降低核心人才流失风险

|

IT 资源投入 |

70% 用于系统集成与维护 |

70% 聚焦于业务流程优化与创新 |

颠覆性重塑 IT 价值，驱动业务创新

|

设备综合效率 (OEE) |维持基线水平，难以突破瓶颈

|通过大幅减少停机时间，持续优化生产节拍

|

预计可提升 OEE 5% – 15%

这些成果的背后，是 AgentCore 带来的四大核心商业价值：

知识资产化：首次将老师傅的“隐性经验”通过 Memory 服务，转化为可复用、可传承的数字资产，彻底解决核心人才流失带来的问题，实现表格中“知识传承”的巨大价值。 决策效率革命：将过去数小时甚至数天的故障排查时间，缩短到分钟级别，直接将表格中的MTTR降低超过90%，极大提升OEE（设备综合效率）。 释放创新潜力：通过 Gateway 服务无缝集成现有IT资产，保护了历史投资，同时让企业能将精力聚焦于工艺优化和产品创新，而非繁琐的系统集成工作，最终实现IT资源的价值反转。 企业级可靠性：背靠AWS成熟的云基础设施，提供了其他开源框架或自研方案难以比拟的安全性、稳定性与弹性，为以上所有价值的实现提供了坚实的保障，让AI在最核心的生产环节跑得安心。

随着Agentic AI技术的发展，智能体在制造业中的应用场景将逐步扩展。制造业企业可以考虑采用AWS Bedrock AgentCore等成熟的技术平台，结合自身业务需求，逐步构建和完善智能制造系统。

6.参考资料

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

---

亚马逊AWS官方博客

基于SeaTunnel迁移数据到Amazon Aurora DSQL

DSQL** **介绍

2024年12月，AWS推出了Aurora DSQL（Distributed SQL），这是一款具有主动-主动高可用性的全新无服务器、可跨区域的分布式 SQL 数据库，让您能够构建具有几乎无限的可扩展性、高可用性、无需管理基础设施并且始终可用的应用程序。

DSQL** **的核心特性

主动-主动高可用性：

Aurora DSQL可实现 99.99% 的单区域可用性和 99.999% 的多区域可用性。通过为每个集群提供完全托管的冗余区域端点，支持应用程序的高可用性。这意味着，即使在极少数情况下，DSQL在某个区域的节点处于中断，应用程序也可以继续以高度一致性的方式进行读取和写入。

无服务器基础设施：

您无需预置、修补或管理服务器，也不需要安装、维护或操作软件。 Aurora DSQL 可自动处理更新，例如次要版本升级、补丁和安全更新，从而减少维护停机时间，让您能够有时间专注于创新。

PostgreSQL ** **兼容版：

Aurora DSQL 提供易于使用的开发者体验，支持大多数常用的 PostgreSQL 查询和许多热门功能。这意味着它为所有支持的功能返回相同的查询结果，为大多数功能提供相同的行为，并支持常用的 PostgreSQL 驱动程序和工具，只需稍微更改配置。

分布式架构：

Aurora DSQL 内置容错功能，无单点故障，可确保系统内每个组件都受到保护，免受个别计算机或数据中心设施故障的影响。如果某个组件接近过载，会自动重新平衡工作负载以保持系统运行状况，并根据需要创建额外的副本，以确保 Quorum 无停机时间或数据丢失。Aurora DSQL 可自动自我修复，无需任何手动操作即可恢复组件，并具有高度一致性。

高度安全：

Aurora DSQL 可通过使用 Firecracker 微型虚拟机实现强大的工作负载隔离，从而实现最高级别的安全性。与 AWS Identity and Access Management（IAM）原生集成，以进行数据库身份验证和授权。所有客户数据都是私密的，且始终会受到静态和动态加密。

将数据迁移到 Aurora DSQL

由于Aurora DSQL的认证机制与IAM集成， 访问Aurora DSQL数据库需要通过IAM的身份来生成token 进行访问，而token 默认只有15分钟有效期，因此目前一些主流的数据同步工具暂不支持将其他数据库的数据迁移到Aurora DSQL，基于这种情况，本文作者基于数据同步工具SeaTunnel 开发了一个专门针对Aurora DSQL 的sink Connector，以满足从其他数据库迁移数据到Aurora DSQL需求。

SeaTunnel ** **介绍

SeaTunnel是一个非常易用、多模态、超高性能的分布式数据集成平台，专注于数据集成和数据同步，主要旨在解决数据集成领域的常见问题。

SeaTunnel 相关特性 丰富且可扩展的Connector： 目前，SeaTunnel 支持超过 100 个Connector且数量还在增加，像主流数据库MySQL 、Oracle、SQLServer、PostgreSQL等都已经提供了Connector支持。插件式设计让用户可以轻松开发自己的Connector并将其集成到SeaTunnel项目中。 批流集成：基于SeaTunnel Connector API开发的Connector完美兼容离线同步、实时同步、全量同步、增量同步等场景。 它们大大降低了管理数据集成任务的难度。 分布式快照：支持分布式快照算法，保证数据一致性。 多引擎支持：SeaTunnel默认使用SeaTunnel引擎（Zeta）进行数据同步。 SeaTunnel还支持使用Flink或Spark作为Connector的执行引擎，以适应企业现有的技术组件。 SeaTunnel 支持 Spark 和 Flink 的多个版本。 JDBC 复用、数据库日志多表解析：SeaTunnel支持多表或全库同步，解决了过度JDBC连接的问题； 支持多表或全库日志读取解析，解决了CDC多表同步场景下需要处理日志重复读取解析的问题。 高吞吐量、低延迟：SeaTunnel支持并行读写，提供稳定可靠、高吞吐量、低延迟的数据同步能力。 完善的实时监控：SeaTunnel支持数据同步过程中每一步的详细监控信息，让用户轻松了解同步任务读写的数据数量、数据大小、QPS等信息。

SeaTunnel ** **工作流程

图一 Seatunnel工作流图

SeaTunnel的工作流程如上图所示，用户配置作业信息并选择提交作业的执行引擎。Source Connector负责并行读取源端数据并将数据发送到下游Transform或直接发送到Sink，Sink将数据写入目的地。

从源码构建SeaTunnel

从源码构建成功后，所有的Connector插件和一些必要的依赖（例如：mysql驱动）都包含在二进制包中。您可以直接使用Connector插件，而无需单独安装它们。

使用Seatunnel同步MySQL数据到Aurora DSQL 配置示例

运行数据同步任务

将上面的配置保存为mysql-to-dsql.conf 文件(请注意需要将示例中的值替换为真实的参数)，存放在apache-seatunnel-${version} 的config 目录下，执行以下命令:

图二 数据同步日志信息

命令执行成功后，您可以通过新产生的日志观察任务执行情况，如果出现错误，也可以根据异常信息进行定位，比如数据库连接超时、表不存在情况。而正常情况下，数据会成功写入目标 Aurora DSQL，如上图所示。

总结

Aurora DSQL是一款高度安全、易扩展、无服务器基础设施的分布式数据库，它的认证方式与IAM身份结合，因此目前缺少合适的工具可以将数据同步到Aurora DSQL中，尤其是在实时数据同步方面。SeaTunnel 是一款非常优秀数据集成和数据同步工具，目前支持多种数据源的数据同步，并且基于SeaTunnel 也可以非常灵活地实现自定义的数据同步需求，比如全量同步/增量实时同步。基于这种灵活性，本文作者开发了一种专门针对于Aurora DSQL 的Sink Connector， 以满足对于Aurora DSQL 数据同步需求。

参考文档

Seatunnel 部署：https://seatunnel.apache.org/zh-CN/docs/start-v2/locally/deployment

开发新的SeaTunnel Connector：

https://github.com/apache/seatunnel/blob/dev/seatunnel-connectors-v2/README.zh.md

在Aurora DSQL 中生成身份验证令牌：https://docs.aws.amazon.com/aurora-dsql/latest/userguide/SECTION_authentication-token.html

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

---

亚马逊AWS官方博客

Blog — 通过ODCR和Prioritized Allocation Strategy 构建高效、经济的EMR集群（二）

在之前的 blog 中，我们介绍了在⿊五等促销季来临时，怎么使⽤ ODCR 来保留资源，并在 EMR 中如何使⽤这些资源。不过在有些场景中，仅靠 ODCR 并不能完全满⾜我们的需求，或者说配置会⾮常复杂，举例来说：

• 场景⼀：两个集群 A 和 B 都配置了 r7g.4xlarge 和 r7g.8xlarge，但我们希望集群 A 多使⽤ r7g.4xlarge，⽽集群 B 多使⽤r7g.8xlarge；
• 场景⼆：我们在⼀个集群内，同时配置了 r7g 和 r6g，但我们希望使⽤性价⽐更⾼的 r7g。

虽然 Targeted ODCR 通过指定特定的 ODCR 预留来控制资源的使⽤，但它仅⽀持设置“有”或“⽆”，不⽀持设定优先级。⽽之前的 EMR 中，Fleet 的 On-Demand 机型，只⽀持 lowest-price ⼀种 allocation strategy，所以在场景⼆中，总是会使⽤单价更低的 r6g ⽽不是性价⽐更⾼ r7g。 所幸，在 2024年，EMR 发布了⼀个新的特性，⽀持指定实例优先级，在 On-Demand allocation strategy 中称为 prioritized，在 Spot 中则是 capacity-optimized-prioritized。本篇Blog就重点介绍 Prioritized 新特性的使⽤场景和具体⽤法。

以前⾯提到的两个场景为例，我们来解释实例优先级的使⽤：

• 场景⼀：在集群 A 中，将 r7g.4xlarge 的优先级配置为更⾼（ priority 数值更⼩ ），则 集群 A 会优先使⽤ r7g.4xlarge。对应的，集群 B 中，需要将 r7g.8xlarge 的优先级配置为更⾼；
• 场景⼆：默认的 lowest-price 会优先单价更低的 r6g，因此需要切换到 prioritized allocation strategy，并且将 r7g 的优先级设为更⾼。

需要再次提醒的是，priority 数值更⼩代表着优先级更⾼，数值 0 代表最⾼优先级。另外，allocation strategy 仅对 Instance Fleet有效，在 Instance Group 中没有对应配置。

下⾯我们通过⼀个例⼦，来说明 prioritized allocation strategy 的使⽤。

如果是在 EMR 控制台上，创建集群时需要选择 Instance Fleet，并且勾选 “Apply allocation strategy”，在 Allocation strategy中，On-Demand 选择 Prioritized，Spot 选择 Capacity optimized prioritized。

给不同的实例类型赋予不同的 priority，下图中，r7a.48xlarge 的优先级最⾼，r7g.16xlarge 和 r7g.12xlarge 并列第⼆，最低的是r6g.16xlarge。

如果是 AWS CLI 中，则需要在 LaunchSpecifications 指定 AllocationStrategy，并且还要给每个实例赋予 Priority 数值。

如果是使⽤ SDK，则需要同时指定 Provisioning 和 Resizing 时的配置

每个机型则需要以 Double 类型指定优先级数值。

值得⼀提的是，Spot 机型是 capacity-optimized-prioritized，它先考虑容量，再尽量考虑实例优先级。以我们前⾯的控制台配置为例，实际启动集群时，可能 task node 会成功创建了 r7g.16xlarge spot 实例 1 个，r7a.48xlarge on-demand 实例 1 个。 r7a.48xlarge 资源紧张，因此 Spot 并没有从优先级最⾼的 r7a.48xlarge 创建实例，⽽是使⽤了次⼀级的 r7g.16xlarge。

综上所述，EMR 新增的 prioritized/capacity-optimized-prioritized allocation strategy 在机型选择⽅⾯提供了更多的可定制性，通过它，我们可以根据⾃⼰的实际需求，结合当前资源容量，控制在 Instance Fleet 中不同实例类型的搭配。另外，Allocation strategy 既可以单独使⽤，也可以和 ODCR 配合使⽤，可以在保证资源供应的同时，还能具有机型调配的灵活性。总⽽⾔之，对于需要在资源可⽤性和成本效益之间取得平衡，同时对特定实例类型有明确偏好的企业⽤户，特别是运⾏⼤规模数据处理⼯作负载且关注资源分配精确性的客户，prioritized/capacity-optimized-prioritized allocation strategy 会是您的最佳选择。

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

---

亚马逊AWS官方博客

使用Amazon Nova模型实现自动化视频高光剪辑

本方案旨在利用Amazon自研的Nova多模态理解类模型（Vision‑Language Model，简称VLM）和多模态嵌入模型（Multimodal Embedding Model，简称MME），实现

自动化的视频高光识别与剪辑**。输入视频文件，通过 **多模态模型理解**或 **结合语义摘要与嵌入检索**实现素材定位，识别高光片段，并合成剪辑。 **方案概览：

|方案

|概述

|纯 VLM

|使用视觉-语言模型（VLM）直接对完整视频进行理解，输出高光片段的开始和结束时间点。

|VLM + MME（视频嵌入/ 降低成本版：视频抽帧图片嵌入）

|首先用 VLM／LLM生成视频摘要或高光描述；将视频切片生成视频嵌入表示；然后将描述文本与视频嵌入匹配，定位高光片段。

文章概览：

• 模型介绍：Nova 多模态理解类模型（VLM）及多模态嵌入模型（MME）
• 视频高光剪辑的主要方法：

纯VLM:用Nova LLM直接进行视频理解，输出高光片段的开始和结束时间点

• 方案架构与案例代码
• Nova理解类模型输出视频精准时间戳（timestamp）的提示词工程技巧
• 效果优化：通过切片增加识别精准度

VLM+MME（video）：结合语义摘要与视频嵌入检索

• 方案架构与案例代码（

2.1 基础：高光压缩； 2.2 跨视频内容驱动的高光剪辑； 2.3 历史素材驱动的模板化高光生成）

• 成本与效果优化思路：片段聚类，初筛，去重
• 降本方案：

2.4 VLM+MME（image）: 视频抽帧，结合语义摘要与抽帧嵌入检索

• 方案架构与案例代码（
• 附加考虑：背景音乐，转场动画，字幕及其他效果自动化

总结与讨论：实际应用场景，方案特点和选型思路

• 可用性与定价

模型介绍

Amazon Web Services（AWS）推出的 Amazon Nova 自研模型系列，是一组基础模型（foundation models），覆盖文本、图像、视频、语音和智能代理等多模态输入与输出，旨在为企业构建生成式 AI 应用提供性能优越、成本更低、可定制性更强的选择。现已在 Amazon Bedrock 上提供。更多模型全系列信息：https://aws.amazon.com/nova/

本方案涉及两类Nova模型：理解类模型和多模态嵌入模型。

理解类模型（Nova LLM）

Amazon Nova Lite 和 Amazon Nova Pro 是 Amazon Nova理解类模型系列（Nova Micro/Lite/Pro/Premier）中两款高性价，低延迟的多模态模型，支持文本、图像、视频等多种格式，并输出文本响应。

Nova Lite：定位为 “极低成本” 的多模态理解模型，能够以极快的响应速度处理图像、视频和文本输入，生成文本输出。

Nova Pro：在精度、速度与成本之间取得平衡，是面向广泛任务的高能力多模态理解模型。

二者均支持 200 多种语言，并且可通过 Amazon Bedrock 进行定制、微调、结合检索增强生成（RAG）等，适合企业级应用。

在本文方案中，我们将使用Nova LLM的视频理解能力，输入视频，通过提示词工程，获得高光片段时间点的输出。

多模态嵌入模型（Nova MME）

Amazon Nova 多模态嵌入模型（Amazon Nova Multimodal Embeddings）是一款最先进的多模态嵌入模型，支持文本、文档、图像、视频和音频的统一嵌入模型，可实现高精度的跨模态检索。模型细节与使用方法可阅读博客。

在本文方案中，我们将使用Nova MME的视频嵌入生成能力，通过语义相似度检索片段嵌入，以此定位高光片段。

高光剪辑方案

1. 纯VLM：多模态模型识别高光

该方案作为视频高光剪辑的基础方案，主要使用Nova 理解类模型（如 Nova Lite/Pro等版本），利用其视觉–语言模型（VLM，Vision-Language Model）能力直接对视频输入进行理解，通过其内部的视觉编码、时序建模与语言理解能力，输出高光片段的“开始时间点”和“结束时间点”。

a. 方案架构与案例代码

纯VLM方案的核心思路是：直接让Nova模型读取整个视频，理解其内容后输出高光片段的时间戳（开始时间和结束时间），然后使用FFmpeg等工具按时间戳切分并拼接视频 。

应用案例1：足球比赛高光提取

以一段1分钟的足球比赛视频（视频来源）为例，我们使用Nova Lite模型自动识别进球等精彩时刻。原始视频包含完整的比赛片段，其中穿插了多个进球瞬间、精彩扑救和关键传球。通过纯VLM方案，模型能够自动定位这些高光时刻并生成浓缩版视频。

下图展示了处理前后的对比效果。左侧为原始1分钟视频，包含了大量的中场传球和跑位等常规画面；右侧为自动生成的高光视频，精准保留了4个进球瞬间，总时长压缩至约25秒，压缩比达到60%。有效提取了视频中最具观赏价值的片段。

1min 原始视频 25s 高光视频

识别准确度评估

为了量化评估模型的表现，我们使用IoU (Intersection over Union) 指标将模型输出与人工标注的Ground Truth进行对比。IoU衡量预测片段与真实片段的重叠程度，当IoU > 0.5时视为成功匹配。测试结果如下 ：

|Ground Truth片段

|模型识别片段

|IoU

|匹配状态

|02-09秒（Team 1 开场进球）

|04-09秒（Team 1 通过快速反击打入首球，进球者热烈庆祝）

|0.71

|匹配

|20-27秒（Team 2 扳平比分）

|20-27秒（Team 2 扳平比分，一名红衣球员带球突破防守队员后将球送入网窝，Team 2 球员疯狂庆祝）

|1

|完美匹配

|30-36秒（Team 2 反超进球）

|30-38秒（Team 2 反超比分，另一名红衣前锋得分，张开双臂庆祝，队友纷纷冲过来加入庆祝）

|0.75

|匹配

|53-57秒（Team 1 扳平进球）

|53-58秒（Team 1 再次扳平，通过定位球得分，球员们在角旗附近拥抱庆祝这一迟来的逆转）

|0.8

|匹配

从效果来看，模型实现了100%的召回率，不仅准确识别了所有进球时刻，还自动过滤掉了中场传球、球员跑位等非高光内容。生成的高光视频节奏紧凑，适合在社交媒体上快速分享，这正是自动化高光剪辑的核心价值所在。

核心代码实现** **应用案例2：小狗动画高光提取

为了验证纯VLM方案在不同视频类型上的泛化能力，我们进一步测试了一段1分钟的动画视频。这段视频的特点是大部分时间画面相对静态——一只橙色的小狗在蓝色大门前休息，而真正的高光时刻集中在三个动态片段：一只黄色的小狗出现捡球、另一只小狗从门内探出、以及黄色小狗追逐球的场景。下图展示了处理效果。左侧为原始60秒视频，右侧为自动生成的17秒高光视频。模型成功识别了所有三个动态时刻，并准确过滤掉了长时间的静态画面 。

1min 原始视频 17s 高光视频

识别准确度评估

为了量化评估模型的表现，我们同样使用IoU 指标将模型输出与人工标注的Ground Truth进行对比，测试结果如下：

|Ground Truth片段

|模型识别片段

|IoU

|匹配状态

|16-24秒（秋田犬捡球）

|16-23秒（一个蓝色的球滚入场景，一只黄色狗跑过来追逐着球。）

|0.88

|匹配

|26-32秒（小狗开门）

|26-32秒（一只小的白色和棕色相间的狗从蓝色门中出现，站在熟睡的橙色狗旁边，然后又消失回门内。）

|1

|完美匹配

|46-52秒（秋田犬追球）

|46-50秒（一只黄色的狗精力充沛地从右向左跑过院子，跑过了休息中的橙色狗。）

|0.67

|匹配

可以观察到，模型成功识别了所有3个真实高光片段，并且所有时间戳均准确且在有效范围内。特别值得注意的是，第二个片段（小狗开门）实现了完美匹配，说明模型对这类明确的动作转折点有很强的识别能力。即使在第一和第三个片段中存在1-2秒的时间偏差，时间重叠率仍然达到0.67-0.88的高水平，这对于实际应用已经完全足够。

综上，对比足球比赛和动画视频两个案例，我们可以看到纯VLM方案展现出良好的跨场景泛化能力，无论是真实拍摄的体育赛事，还是制作精良的动画内容，Nova Lite都能准确理解视频语义，识别出符合”动作精彩、戏剧性强、叙事价值高”等标准的高光时刻。这种泛化能力使得同一套技术方案可以应用于多种业务场景，从体育直播、游戏录像到教育视频、产品演示等，大幅降低了开发和维护成本。

b. 使用Nova理解类模型输出视频精准timestamp的提示词工程技巧

在将Amazon Nova模型应用于视频高光提取时，我们面临的核心挑战是如何让模型准确输出结构化的时间戳数据。基于对Nova Lite的系统性测试，发现模型在视频时间定位任务中的表现高度依赖于prompt的设计策略，基于大量测试经验和视频理解任务的标准prompt模板，可以总结出以下关键技巧：

采用分步骤的任务分解策略。参考视频密集描述（Dense Captioning）任务的prompt设计，将复杂的时间戳提取任务分解为清晰的步骤序列，引导模型建立系统化的分析流程：

这种结构化指引帮助模型建立”观察→定位→验证→输出”的工作流程，显著减少时间戳错误。

针对特定任务定制分析维度。参考视频标注（Video Tagging）任务的prompt设计，在高光提取时应明确定义分析的多个维度，帮助模型全面理解什么是”高光”：

明确定义输出格式并提供具体示例。在视频检索（Video Retrieval）和时间定位任务中，标准做法是明确指定时间戳的格式要求。我们建议同时提供格式说明和具体示例，对于需要更结构化的场景，使用JSON格式：

强调时间边界约束以防止幻觉。测试表明，模型在长视频中容易产生超出实际时长的时间戳。必须在prompt中明确视频的实际时长：

通过系统性地应用这些提示词工程技巧，我们能够显著提升Nova模型在视频时间戳识别任务中的表现。在实际应用中，我们还建议结合代码层面的后处理机制——例如验证时间戳是否在有效范围内、合并时间上相邻的片段等，这种通过结合prompt设计+工程化验证的组合策略能够构建更稳健的生产系统。

除了提示词优化，对于长视频场景，我们还可以从架构层面进一步提升处理效果，接下来我们将详细介绍这一优化方案。

c. 效果优化：通过切片增加识别精准度

在实际生产环境测试中，我们发现对于长视频场景，采用视频切片策略能够显著提升时间戳定位精度和高光识别准确率。该策略的核心思路是将长视频按固定时长切分成多个片段，对每个片段独立调用Nova模型进行并行分析，然后将识别结果映射回原视频的绝对时间轴。这种方法不仅显著提升了时间戳精度，还带来了意外的性能收益——通过并行处理多个片段，整体处理时间反而缩短了。

应用案例3：长视频足球比赛高光提取

以一段9分3秒的足球比赛视频为例（视频来源），我们将其切分为18个30秒片段和1个3秒片段，通过Amazon Nova Lite模型并行处理后，自动生成了包含所有进球时刻的高光视频。下图展示了原始视频与自动生成的高光视频对比：

切片策略处理流程图

9m3s 原视频 1m58s 高光视频

效果验证

为量化评估切片策略的效果，我们使用人工标注的Ground Truth进行对比测试。结果显示，切片策略在时间戳精度和召回率两个关键指标上均有显著提升：30秒切片策略成功识别了全部4个进球（召回率100%），时间戳精度提升至±1秒以内。

|进球事件

|Ground Truth

|原始策略 (未切分) 结果

|优化策略 (30秒切分)结果

|评价

|#1 Team 1 进球 (0:1)

|197-204秒

|190-200s (匹配，时间范围接近)

|195-208s (匹配，时间更精确)

|优化： 都能匹配，切分策略的时间覆盖更准确

|#2 Team 2 进球 (1:1)

|297-303秒

|290-300s (匹配，时间范围接近)

|300-305s (匹配，时间更精确)

|优化： 都能匹配，切分策略的时间覆盖更准确

|#3 Team 2 进球 (2:1)

|338-342秒

|未检测到 (漏检)

|334-344s (匹配)

|优化： 成功检测到，召回率提升

|#4 Team 1 进球 (2:2)

|373-383秒

|470-480s (时间错误)

|372-382s (匹配)

|优化： 成功检测并精确定位，纠正了原始策略的时间错误的不足

切片策略的另一个优势是通过并行处理提升了整体处理效率。需要注意的是，虽然召回率得到了显著提升，但由于每个片段独立分析，可能会产生较多冗余标记（本案例中输出了14个候选片段），建议在后处理阶段增加去重及筛选逻辑以优化最终输出。

总体而言，纯VLM方案的优势在于流程简洁、模块精简、实现路径短，非常适合快速原型开发和中短视频场景。然而，当面对超长视频，这一方案对模型能力和提示词工程的要求会显著提升。此外，对于需要从海量视频素材库中全局筛选最佳片段的场景，纯VLM方案难以提供跨视频的语义检索能力。

在接下来的章节中，我们将介绍：当VLM对高光片段的提取不是那么精准时，通过引入多模态嵌入模型（MME）在语义空间上进行相似度匹配，不仅能提升系统的容错能力，弥补VLM在精准性方面的部分不足，同时也提供了跨视频片段检索定位的可能性，实现更强大的视频高光剪辑能力。

2. VLM+MME：语义摘要+嵌入检索

该方案结合了两类技术：首先由 VLM（Nova理解类模型，如Nova Lite/Pro）对视频整体进行理解，生成高光要点或描述；其次，将视频切片（如每2-3秒一段，

*具体切片时长根据业务要求和检索颗粒度决定*）生成视频嵌入向量（通过多模态嵌入模型，Nova MME）——每个片段取得视觉／时序特征之后形成向量。然后系统将高光描述（文本）作为查询，与视频片段的嵌入向量进行 相似度匹配，从而精确定位那些“语义上与高光描述最接近”的片段。

a. 方案架构

该方案的需要视频切片、嵌入生成与匹配机制， 可用于跨视频的剪辑需求。基于嵌入向量的可复用性，提供从冷启动（2.1， 2.2）到基于素材累积（2.3）的方案进阶路径。如果成本敏感可以考虑（2.4）将视频抽帧，用图片向量检索。

2.1 基本方案：高光压缩

在不强调原始视频情节顺序的情况下，我们可以采用一种

高光压缩的方法，将视频内容提炼为精华片段。具体步骤如下： 视频内容总结：将视频输入到VLM模型（例如AWS的 Nova Lite/Pro 模型），生成对视频主要内容的摘要描述，并以要点（bullet points）的形式呈现。这一步让模型从全局上理解视频内容的重点。（也可以与方法 1. 纯VLM（ 用Nova VLM直接进行视频理解，输出高光片段的开始和结束时间点）方法结合，对VLM生成的高光点查漏补缺。）

• （可选）打重要性标签：每条摘要要点可以附加一个优先级标签（如重要程度1、2、3）以表示相对重要性（这一步需要在 system prompt 中明确高光片段的判定标准）。

视频切片与嵌入：将视频按时间顺序分割成短片段，如 2-3秒（ *具体切片时长根据业务要求和检索颗粒度决定*），并对每个片段生成向量嵌入表示（使用Nova MME，多模态嵌入模型，每个片段的嵌入向量都代表了该片段的语义内容）。 语义匹配选取高光片段：利用第一步中VLM生成的摘要要点作为查询，根据语义相似度在嵌入向量空间中检索最相关的影片片段。换言之，我们在嵌入向量库中查找与每条摘要要点语义最接近的若干片段。这些匹配上的片段即被视为视频的高光片段集合。由于摘要要点概括了视频的重要内容，检索出的片段也就对应了视频中最精彩或最重要的瞬间。

• （可选）初筛：如高光描述过多，可以根据高光点的优先级筛选需要匹配的文字。
• （可选）去重：若出现多个要点匹配到同一段视频（即某片段对多条要点都有高相似度），则根据要点的优先级决定该片段应归属哪个要点（确保重要的要点获得独特片段）

高光片段导出：将选定的高光片段按原视频中的时间顺序组合导出，形成一个压缩版的视频。如果不关注片段顺序，也可以按照相似度得分等权重来自由组合。但通常由于摘要要点源自原始视频顺序，此方法下导出的高光片段天然保持了原视频的大致顺序。

该基本方案不依赖任何外部素材库，流程简单直接。VLM提供语义摘要，嵌入向量提供精确检索，使模型能够“理解”视频内容并找到对应片段。此方法依赖第一步VLM的摘要质量和提示词工程，若VLM未能抓住真正的精彩之处，检索结果可能欠佳。

案例代码

使用Amazon Nova Lite进行视频理解与高光要点生成，Amazon Nova MME进行文本和视频片段的嵌入生成，开源音视频处理库FFmpeg进行视频处理，该流程的核心代码架构如下：

应用案例：小狗动画高光提取

1min 原始视频 14s 高光视频

该动画的大部分时间是一只橙色小狗在蓝色大门前睡觉，有3个主要的高光片段：

• 第16s到第24s：一只黄色小狗出现在画面中捡球
• 第26s到第32s：一只小的白色和棕色相间的小狗从门内探出
• 第46s到第52s：黄色小狗继续出现在画面中追逐球

按照架构设计进行第1步，将整个视频作为输入，使用VLM进行视频分析，提取高光要点以及优先级：

VLM 提取的高光要点包含7条，每条有对应优先级与描述，可以观察到视频的大部分高光情节被提取出且故事较为连贯。在语义匹配阶段，Nova MME进行多模态嵌入生成，能够捕捉到视频片段中的核心动作和场景特征，而不完全依赖于具体的身份识别。例如，当VLM描述中提到”黄色小狗追逐球”时，无论执行这个动作的是橙色小狗还是黄色小狗，由于”追逐球”这一动作在嵌入空间中产生相似的语义表示，相似度计算都能够匹配到包含此类动作的视频片段，从而实现准确的语义关联。这种语义层面的匹配机制使得系统具有一定的容错能力：即使文本描述在细节上存在偏差，只要核心的动作、场景或情感特征保持一致，相似度计算仍能找到正确的视频片段，保证了语义上的连贯性。最后拼接时根据视频片段的时间顺序拼接保证了时序上的连贯性。

接下来进行第2～4步的视频片段切分（2s为切分间隔），Nova MME嵌入生成以及语义匹配，每个要点匹配的视频片段结果如下表所示：

|选中片段

|时间范围

|相似度

|匹配的高光要点

|clip_0010_20s.mp4

|20-22s

|0.192

|黄色小狗追逐球的动作，展示了它的活泼和好奇心。

|clip_0011_22s.mp4

|22-24s

|0.241

|黄色小狗被一个蓝色的球吸引，并开始追逐。

|clip_0013_26s.mp4

|26-28s

|0.26

|视频开始时，展示了房子和橙色小狗在阶梯上睡觉的场景。

|clip_0014_28s.mp4

|28-30s

|0.202

|黄色小狗追逐球的过程中，展示了房子的细节和背景。

|clip_0015_30s.mp4

|30-32s

|0.193

|橙色小狗开始翻身并醒来。

|clip_0025_50s.mp4

|50-52s

|0.204

|黄色小狗最终放弃追逐。

|clip_0029_58s.mp4

|58-60s

|0.14

|视频结尾，展示了房子和花园的全景。

从实际结果看，尽管VLM在狗的品种识别上存在混淆，但最终选中的片段（20-24秒、26-32秒、50-52秒等）仍然准确覆盖了预期的高光时段，证明了这种基于语义匹配的方法在处理描述不精确问题上的鲁棒性。生成的高光视频中包含了提到的3个高光片段，且片段之间的衔接也较为自然。

2.2 跨视频内容驱动的高光剪辑

当高光剪辑场景有较高的自定义剧本需求，需要微调视频拼接顺序，以及需要基于大量视频媒体库优选片段的时候，我们可以对2.1方案生成的嵌入基于用户定义的剧本文字（可选：再用prompt增强）进行检索。

比如在媒体行业场景中，当剪辑需求不仅仅是“提取高光”，而是要按照品牌或用户定义的“剧本”来迈出叙事、结构和风格的步伐，并且拥有一个庞大的素材库时，我们便可以采用“用户输入的剪辑需求 + 跨视频检索”这一技术路径。具体来说，用户首先输入其剪辑意图，例如“先展示产品问世、再展示用户体验、最后展示品牌口号”，这一剧本会被系统转化为一系列描述性事件（如“产品亮相”、“用户微笑试用”、“品牌Logo出现”）。接着系统对整个素材库中的每条视频或片段生成嵌入向量，进而将用户的每一个事件描述作为检索查询，与库中各片段的嵌入进行相似度匹配。这样，系统不仅限于从单个视频选取高光，而是可以跨视频检索：比如，事件１可能匹配竟然是品牌拍摄片，事件２可能匹配直播片段，事件３来自宣传片。最后，按照用户剧本设定的顺序，将这些匹配出的来自不同视频的片段组合起来，形成一个结构化、连贯而富有品牌风格的高光剪辑。

2.3 历史素材驱动的模板化高光生成

视频嵌入技术展现了极高的可复用性。我们可以将历史上已经被剪辑为高光的片段——或被人工判断为“精彩时刻”的素材——系统地收集起来，形成一个样本库。样本库搭建可选择如AWS Opensearch Service（博客），AWS的partner向量数据库如Zilliz（partner marketplace link）。

对于库中每一个高光片段，我们不仅为其生成嵌入向量表示，还可按类别或风格进行标签（例如 “体育比赛”“游戏直播”“演讲访谈” 等），并为片段附加丰富的元数据，如所属视频类别、片段简介、精彩评分等。这一机制使得后续的新视频可以跨视频检索：在面对一条新拍摄视频时，系统首先对其进行分析（包括 VLM 摘要或粗分类），然后将其切分为2–3 秒的片段并生成嵌入向量。接下来，这些片段将与样本库中已有的高光嵌入进行相似度匹配——如果某个新视频片段在视觉或语义上与历史高光片段高度相似，就可将其标记为高光候选。同时，如果新视频所属类别明确（比如篮球比赛），系统还可参考该类别过去形成的“高光剧本”——例如典型进球、扣篮、关键三分、绝杀这一顺序——并在样本库选片中优先匹配这些典型事件。将匹配出的片段（可能来自不同原视频）按剧本顺序组合拼接，就能生成符合观众预期节奏、结构连贯的高光成片。

以下为流程图：

b. VLM+MME链路优化思路

在系统设计阶段，成本考量非常重要。如不需要为视频 embedding 支付持久化存储费用，仅需要考虑模型推理费用（即 Nova 或嵌入模型 MME 的运行费用）。如需储备历史素材库——需要存储 embedding，因此还要考虑存储和检索成本。除了存储外，还有一些

成本优化手段**，可以在整个流程中降低计算／存储／带宽等资源消耗。以下是几项建议： **视频压缩 + 再识别

可以先将原始视频做轻量压缩或降帧处理（降低分辨率、降低帧率）以减少计算／存储开销。利用压缩后的视频用VLM识别哪些片段可能是高光，然后在原始视频中按照排序结果选取对应高分片段，再拼接成最终剪辑。这样可以避免对高分辨率视频VLM理解/MME嵌入。

初筛过滤 + 再嵌入

在做精细的嵌入匹配之前，先做一个粗筛阶段以减少待处理片段数量，从而降低后续嵌入计算量。粗筛可通过几种方式实现：

靠 VLM 输出大致 timestamp：结合方法1，调用 VLM 先对视频做快速分析，输出可能的高光时间段（例如“00:12–00:16”、“04:30–04:35”），然后只对这些候选区段做切片 + 嵌入匹配。提升方法1的精度，同时无需对全部视频做嵌入处理。 靠去重：如果视频存在大量“平淡”“重复”的片段，可以先用帧差异规则做去重，删除重复内容，剩余片段即为“亮点候选”：如帧之间变化率、场景切换检测、视觉差异阈值做快速过滤，仅保留“变化大”的区段供后续处理。 靠前置逻辑：利用其他模态（如音频、运动检测）做预筛。比如音频音量变大、频率变化剧烈可能对应“高潮、高光”片段（如赛车轰鸣、演唱高潮）；或视觉中检测到快速运动／剪辑变化也可作为候选。这样可减少对视觉嵌入的遍历。

这种“粗 → 精”两级筛选方式能显著降低整体系统负载。

效果优化思路

切片粒度与高光时长弹性

实际场景中，高光时长并不固定（可能为 3 秒／5 秒／15 秒等），因此在切片设计时需要灵活。一个简明工程实现方式是：

先用最小细粒度切片（例如 1-2 秒）遍历全视频。对于每个高光描述（来自 VLM），在匹配出的片段基础上，可 合并相邻切片、或者根据优先级扩展时间段，以形成较长的高光片段。匹配逻辑可为：对于某一高光描述，找到所有相似度 ≥ 阈值（例如 0.5） 的细切片集合；然后合并这些相邻切片（时间上连续或相近）为一个完整高光区间，再按时间顺序拼接。

这样既保证了系统能够灵活应对不同长度的高光，又避免硬编码“高光必为3 秒”的限制。

2.4 VLM+MME（视频抽帧-图片嵌入）

此方案与方案 2 的流程类似，但区别在于“嵌入对象”从视频片段变为“抽帧图片”。也就是说：对视频抽取关键帧，对这些静态帧生成图片嵌入；同时由 VLM 生成高光描述文本；然后对图片嵌入与描述文本做匹配，从这些匹配结果推断高光的时间点。技术上这种方法降低了对完整视频切片和时序建模的依赖，使实现更轻量。

案例代码：** **应用案例：小猫草地玩耍高光提取

1min 原始视频 16s 高光视频

该视频的大部分时间是小猫在草地上张望，主要高光片段为：

• 在第21s到第28s：小猫有向前扑的动作
• 第37s到第43s：小猫回到原位坐下回头看向镜头

和2.1 基本方案类似，进行第1步将整个视频作为输入，使用VLM进行视频分析，提取高光要点以及优先级：

接下来进行的2～4步的处理，以1s为间隔对视频进行抽帧，对高光要点与抽帧后的图片进行嵌入生成与语义匹配，最后根据抽帧间隔与帧起始时间合并连续片段。最终提取出9个连续的高光片段（总时长16秒）如下表所示：

|片段序号

|时间范围

|时长

|相似度

|匹配要点

|优先级

|1

|4.0s-5.0s

|1.0s

|0.274

|A. 小猫在草地上坐下，观察周围环境，展示了它的好奇心和警觉性

|1

|2

|7.0s-9.0s

|2.0s

|0.278-0.280

|A. 小猫在草地上坐下，观察周围环境，展示了它的好奇心和警觉性

|1

|3

|23.0s-24.0s

|1.0s

|0.167

|B. 小猫抬头看向远处，表现出对环境的探索和兴趣

|2

|4

|25.0s-28.0s

|3.0s

|0.240-0.250

|C. 小猫发现地上的蛋壳，并开始尝试吃掉，展示了它的食欲和探索行为

|1

|5

|29.0s-30.0s

|1.0s

|0.247

|E. 小猫最终成功吃掉了蛋壳，并继续在草地上活动，展示了它的满足感

|1

|6

|31.0s-32.0s

|1.0s

|0.164

|B. 小猫抬头看向远处，表现出对环境的探索和兴趣

|2

|7

|40.0s-41.0s

|1.0s

|0.175-0.259

|C/E. 小猫发现蛋壳并尝试吃掉/成功吃掉蛋壳并继续活动

|1/2

|8

|43.0s-46.0s

|3.0s

|0.214-0.257

|D/E. 小猫尝试吃蛋壳时表现困惑/成功吃掉蛋壳并继续活动

|1/2

|9

|48.0s-51.0s

|3.0s

|0.273-0.276

|A. 小猫在草地上坐下，观察周围环境，展示了它的好奇心和警觉性

|1

从结果上看，高光视频短片包含了原视频中2个主要高光瞬间（扑抓动作和看向镜头），同时也整合了VLM分析中关于小猫“靠近、玩弄/咬住蛋壳”的高优先级动作片段（对应片段4、5、7、8），跳过了较长的静态张望部分同时保持了一定的动作连贯性。

总结：该方案优点是资源消耗更低、实现速度更快；但缺点在于抽帧可能丢失动作延续或动态效果，因此定位精度可能略逊于方案 2，适合快速试验或成本/资源受限的场景。

附加考虑：BGM，转场动画，字幕及其他自动化

背景音乐匹配：高光剪辑常配以恰当的背景音乐（BGM）增强观赏性。我们可以利用上述文本描述和嵌入技术来自动挑选BGM。例如，将高光片段的 文字描述（来自VLM总结的高光要点）输入音乐库的嵌入查询，寻找语义上契合的音乐片段。音乐库中每首背景音乐可事先标注情绪、风格或含有描述文本，按需检索。举例来说，如果高光描述提到“激动人心的绝杀时刻”，系统可能选择一首节奏紧凑、激昂的配乐与之对应。 视觉转场和特效：生成剪辑时还可考虑自动添加一些转场效果或字幕说明。例如，在片段衔接处插入快速淡入淡出或动感转场，以增强流畅度（这里可以用大模型基于提示词直接生成剪辑剧本和转场动画标签）； 增加字幕： 字幕可用各方案第一阶段的VLM输出的描述增加到对应的高光片段上，或进一步用LLM优化，在对应片段下方叠加字幕或标题，提示观众这个片段精彩之处（例如“最后三秒绝杀进球！”）。 迭代优化：在实际应用中，可以根据用户反馈或观看数据，不断优化高光选择规则和效果处理。例如统计哪些自动生成的高光片段留存率高，哪种BGM搭配更受欢迎，反过来调整VLM的提示词和相似度匹配的阈值，形成 反馈循环，逐步提高高光剪辑的质量。

总结与讨论：应用场景，方案特点和选型思路

综上所述，本方案提出了一套利用AI进行视频高光剪辑的思路：从基本的纯大语言模型识别高光节点，到语义摘要+嵌入检索实现跨素材的检索和剪辑，并提供了随着素材积累逐步提升的思路。

VLM 直接识别 vs 嵌入模型检索：

随着模型规模与多模态预训练技术的发展，现代 VLM （比如本文案例中使用的Nova理解类模型）擅长同时处理视觉内容、语义信息与时序结构。它们能够从整段视频中快速提取“哪些时刻是高光”“这些高光的起止时间在哪里”，因为它们在训练阶段已学习到“动作／事件 → 关键帧”与“视觉＋语言语义”之间的对应关系。在现实剪辑任务中，如果视频结构相对简单、动作明显、视觉变化突出，VLM 直接识别的路径可能几乎一步到位：模型读取视频，识别出“高光动作”或“精彩节点”，并直接标出时间戳。在这种场景下，少了切片、分割、索引、匹配等环节，流程更短、响应更快。

那么为什么我们在解决方案里引入嵌入模型？其价值主要体现在以下几个方面：第一，在素材库规模大、跨视频检索需求高的场景，嵌入模型使你能够为每个视频片段或帧生成可索引的向量，从而构建“素材库可复用＋检索加速”的结构。通过这种方式，无论未来你要处理多少条视频或多少次剪辑任务，都可以依赖已生成的向量库进行高效检索，而不是每次都让 VLM 全面扫描。第二，对于高度定制化剪辑需求（如品牌剧本、风格统一、跨视频片段拼接）来说，嵌入模型提供了更强的“匹配”能力：你可以用描述或事件提示作为查询，在向量空间中查找与之最相似的片段，再组合成成片。这种方法更适用于“从大量素材中选”“按照用户剧本拼接”这类复杂任务。

为方便产品或技术团队快速决策，下面是选型建议：

|方案

|简要描述

|特点

|选择策略／适用场景

|纯 VLM

|使用视觉-语言模型（VLM）直接对完整视频进行理解，输出高光片段的开始和结束时间点。

|流程最简；依赖模型对时序与视觉理解的能力强；实现快速。

|视频较短、结构简单、无需跨视频、资源有限、希望快速上线。（如视频长也可以分段处理）

|VLM + MME（视频嵌入/ 降低成本版：视频抽帧图片嵌入）

|首先用 VLM／LLM生成视频摘要或高光描述；将视频切片生成视频嵌入表示；然后将描述文本与视频嵌入匹配，定位高光片段。

|语义理解＋嵌入检索结合；全局检索，可控性较强。

|视频长度中等或偏长、跨视频检索，希望复用嵌入，定制化需求高

自动高光剪辑技术方案可用于制造业如相机云存剪辑， 媒资场景如明星高光，电视剧摘要等。在未来，我们期待这种自动化高光剪辑能够大幅减少人工剪辑耗时，实现“一键生成精彩瞬间”，为内容创作者和观众带来更高效的体验，为AWS客户产品带来创新和效益。

可用性与定价

Amazon Nova理解类模型和多模态嵌入模型现已在Amazon Bedrock上线，可用区域包括美国东部（弗吉尼亚北部）的亚马逊云科技区域。如需详细定价信息，请参阅Amazon Bedrock定价页面（Amazon Bedrock pricing page）。

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

---

亚马逊AWS官方博客

为AI Agent构建安全沙箱基础架构：在Amazon EKS上部署Kata Containers的最佳实践

随着AI Agent技术的快速发展，越来越多的企业开始在生产环境中部署智能代理系统。然而，AI Agent在执行任务时往往需要访问敏感资源执行代码或与外部系统交互，这带来了前所未有的安全挑战。本文将深入探讨为什么AI Agent需要沙箱环境，对比现有的沙箱解决方案（包括E2B等专业平台），以及如何在Amazon EKS上使用Kata Containers构建高性能、高安全性的容器沙箱基础架构，以服务大规模企业级的Agentic AI应用。

为什么AI Agent需要沙箱环境？

1. 安全隔离需求

AI Agent在执行任务时可能会：

• 执行用户提供的代码或脚本
• 访问敏感的API和数据源
• 与不可信的外部服务交互
• 处理恶意输入或攻击载荷

传统的容器隔离机制虽然提供了一定程度的隔离，但共享内核的特性使得容器逃逸攻击成为可能。AI Agent的动态性和复杂性进一步放大了这些安全风险。

2. 资源控制与多租户

在多租户环境中，不同的AI Agent可能属于不同的用户或组织。需要确保：

• 严格的资源隔离，防止资源争抢
• 网络隔离，防止横向移动攻击
• 数据隔离，保护敏感信息不被泄露

3. 合规性要求

许多行业（如金融、医疗、政府）对数据处理和系统安全有严格的合规要求。AI Agent处理敏感数据时，需要满足：

• 数据处理的可审计性
• 强制访问控制
• 加密和数据保护标准

现有沙箱环境方案对比

1. 传统容器技术

优势：

• 轻量级，启动速度快
• 资源利用率高
• 生态系统成熟

劣势：

• 共享内核，存在逃逸风险
• 隔离性相对较弱
• 不适合处理不可信代码
• 不提供e2e的沙箱方案

2. 虚拟机技术

优势：

• 强隔离性，独立内核
• 成熟的安全模型
• 完整的操作系统环境

劣势：

• 资源开销大
• 启动时间长
• 管理复杂度高
• 不提供e2e的沙箱方案

3. E2B (Code Interpreter) 沙箱平台

E2B是专门为AI Agent设计的代码执行沙箱服务，提供了开箱即用的解决方案：

优势： 专为AI 设计：针对LLM和AI Agent的代码执行需求优化 多语言支持：原生支持Python、JavaScript、R等多种编程语言 即开即用：无需复杂的基础设施配置 丰富的预装环境：包含常用的数据科学和机器学习库 实时协作：支持多用户实时代码执行和共享 云原生：基于云服务，自动扩展和管理 劣势： 供应商锁定：依赖第三方服务 数据主权：敏感数据需要传输到第三方平台 定制化限制：难以满足特殊的企业级定制需求 成本控制：按使用量计费，大规模使用成本可能较高 成本: 如果选择SaaS服务，成本较高

4. Kata Containers

Kata Containers结合了容器的便利性和虚拟机的安全性，在企业级AI Agent部署中具有独特优势：

优势： 强安全隔离：每个容器运行在独立的虚拟机中，提供VM级别的安全边界，消除容器逃逸风险 容器生态兼容：完全兼容现有的容器镜像和工具链，支持Kubernetes原生集成 企业级控制：完全控制数据和基础设施，可根据企业需求深度定制，满足各种行业合规要求 成本效益：相比传统VM更高的资源利用率，支持弹性伸缩，避免供应商锁定 劣势： 运维复杂度：相比传统容器需要更多的配置和管理 资源开销：比传统容器有一定的额外开销 学习成本：需要团队掌握相关的虚拟化和容器技术 不提供e2e 的沙箱：不提供e2e的沙箱方案，需要用户自己实现，只提供高度隔离的容器基础架构

沙箱方案详细对比

|特性

|传统容器

|虚拟机

|E2B平台

（SaaS）

|Kata Containers

|1

|

安全隔离 |中

|高

|高

|高

|2

|

启动速度 |极快

|慢

|快

|快

|3

|

资源开销 |低

|高

|低*

|中

|4

|

生态兼容性 |高

|中

|中

|高

|5

|

定制化能力 |高

|高

|低

|高

|6

|

运维复杂度 |低

|高

|极低

|中

|7

|

数据主权 |高

|高

|低

|高

|8

|

成本控制 |高

|中

|中

|高

|9

|

企业级特性 |中

|高

|中

|高

EKS上的两种Kata Containers部署方案

如果您综合评估后，认为Kata Container的方案适合自己，那么可以参考我们的实践构建起基础架构环境。基于我们的实践经验，我们采用了Firecracker作为Kata Containers的hypervisor，并提供了两种不同的EKS部署配置，分别适用于不同的场景和需求。完整的配置文件和部署脚本可以在我们的GitHub仓库中找到：eks-kata-containers。

Firecracker MicroVM技术优势

在我们的实现中，Kata Containers使用AWS Firecracker作为底层虚拟化技术。Firecracker是AWS专门为serverless和容器工作负载开发的开源虚拟化技术，具有以下显著优势：

1. 极速启动性能

毫秒级启动：Firecracker microVM可以在125毫秒内启动，相比传统虚拟机快数十倍 最小化启动开销：精简的虚拟化栈，去除了不必要的设备模拟 快速扩展：支持在单台主机上运行数千个microVM实例

2. 强安全隔离

硬件虚拟化：基于KVM，提供硬件级别的安全隔离 最小攻击面：精简的设备模型，只包含网络设备、块设备、串口和1-button键盘 内存安全：使用Rust语言开发，从语言层面避免内存安全漏洞

3. 资源效率

低内存占用：每个microVM的内存开销仅约5MB 高密度部署：在单台物理机上可以运行更多的隔离实例 精确资源控制：支持精细的CPU和内存资源分配

4. 企业级特性

生产验证：已在AWS Lambda和Fargate等服务中大规模使用 开源透明：完全开源，可审计和定制 活跃社区：AWS和社区持续维护和改进

方案一：基于EBS的Loop设备配置

为什么需要thinpool？

Kata Containers使用devmapper snapshotter来管理容器镜像和存储层，这需要一个device mapper thin pool作为底层存储。Thinpool提供了以下关键特性：

写时复制(COW)：多个容器可以共享相同的基础镜像层，只有在写入时才创建独立副本 快照功能：支持快速创建容器镜像快照，提高存储效率 动态分配：按需分配存储空间，避免预先分配大量存储 层级管理：支持容器镜像的分层存储架构

什么是Loop设备？

Loop设备是Linux内核提供的一种虚拟块设备，它可以将普通文件映射为块设备。在我们的方案中：

文件到设备的映射：将EBS卷上的大文件（如350GB的data文件）映射为块设备 灵活性：无需物理分区，可以在现有文件系统上创建虚拟块设备 兼容性：与标准块设备完全兼容，可以用于LVM、RAID等存储管理

这种方案使用EBS卷通过loop设备创建devmapper thinpool，结合Firecracker提供高安全性的容器运行环境：

适用场景：

• 开发和测试环境
• 成本敏感的部署
• 中等I/O性能要求的AI Agent工作负载

优势：** **成本效益**：可使用标准EC2实例，降低基础设施成本 **配置简单**：不依赖特定硬件配置，部署灵活 **Firecracker** **加速**：享受microVM的快速启动和强隔离特性 **存储灵活性**：可根据需求调整EBS卷大小 **考虑因素：

• I/O性能受EBS限制
• 需要处理loop设备的持久化和恢复

方案二：基于NVMe的RAID配置

RAID上的Thinpool架构

与方案一不同，这种方案直接在物理NVMe磁盘上构建存储架构，避免了loop设备的性能开销：

RAID 阵列：将多个NVMe磁盘组建成RAID5阵列，提供冗余保护和性能提升 LVM 管理：在RAID设备上创建LVM物理卷(PV)和卷组(VG)，实现灵活的存储管理 Thinpool 虚拟化：在卷组中创建thin pool逻辑卷，提供动态存储分配能力 直接访问：devmapper直接访问LVM thinpool，消除文件系统和loop设备的中间层

这种架构的优势在于：

原生性能：直接访问物理存储，无额外虚拟化开销 数据保护：RAID5提供单盘故障保护 扩展性：LVM支持动态扩展存储容量

这种方案使用实例本地NVMe磁盘组建RAID阵列，结合Firecracker提供极致性能的容器运行环境：

适用场景：

• 生产环境部署
• 高I/O性能要求的AI Agent
• 大规模并发容器执行
• 对存储延迟敏感的应用

优势：** **极致性能**：本地NVMe提供最高的I/O性能和最低延迟 **Firecracker** **优化**：microVM技术与高性能存储的完美结合 **数据保护**：RAID配置提供冗余和数据保护 **生产就绪**：适合大规模生产环境部署 **考虑因素：

• 成本较高，需要使用带NVMe的裸金属实例
• 配置复杂度相对较高
• 本地存储需要额外的备份策略

Firecracker在AI Agent场景中的特殊价值

对于AI Agent工作负载，Firecracker的特性带来了独特价值：

快速冷启动：AI Agent任务往往是事件驱动的，Firecracker的快速启动能力确保任务能够及时响应 安全代码执行：AI Agent经常需要执行用户提供的代码，Firecracker提供的强隔离确保安全性 资源弹性：可以根据AI任务的复杂度动态分配资源，提高整体资源利用率 多租户支持：在同一物理机上安全地运行多个用户的AI Agent，实现真正的多租户隔离

两种EKS部署方案的详细对比

|特性

|EKS+Kata+Firecracker (EBS)

|EKS+Kata+Firecracker (NVMe)

|1

|

实例类型 |m5.metal

|m5d.metal

|2

|

存储配置 |EBS gp3 (500GB)

|本地NVMe + EBS (200GB)

|3

|

部署复杂度 |中等

|中等

|4

|

初始成本 |中等

|高

|5

|

运营成本 |固定成本

|固定成本

|6

|

启动性能 |极快 (125ms)

|极快 (125ms)

|7

|

I/O 性能 |中等 (受EBS限制)

|极高 (本地NVMe)

|8

|

I/O 延迟 |较高

|极低

|9

|

安全隔离 |极高 (硬件级)

|极高 (硬件级)

|10

|

数据持久化 |自动 (EBS)

|需要备份策略

|11

|

数据控制 |高

|高

|12

|

定制化 |高

|高

|13

|

扩展性 |手动配置

|手动配置

|14

|

合规性 |完全控制

|完全控制

|15

|

适用规模 |中到大型

|大型企业

|16

|

推荐场景 |开发测试、成本敏感

|生产环境、高性能需求

部署实践与最佳实践

1. 准备工作

在开始部署之前，确保已安装以下必要工具：

2. 创建SSH密钥对

为了能够访问EKS节点进行调试和验证，需要创建SSH密钥：

3. 部署EKS集群

根据需求选择合适的配置文件部署集群：

注意：集群创建过程可能需要 15-20 分钟。

4. 配置kubectl

集群创建完成后，配置kubectl以连接到新创建的集群：

5. 安装Kata Containers

使用Helm安装kata-deploy，这将自动配置Kata Containers运行时：

6. 验证Kata Runtime安装

检查RuntimeClass是否创建成功：

如果安装成功，应该能看到

kata-fc RuntimeClass：

7. 部署测试应用

使用提供的Redis示例验证Kata Containers是否正常工作：

Redis Pod配置示例：

8. 验证部署结果

检查Pod状态和运行时配置：

在输出中应该能看到 RuntimeClassName: kata-fc，确认Pod确实使用了Kata Containers运行时。

9. 存储配置详解

EBS方案的devmapper配置

NVMe方案的devmapper配置

10. 监控和故障排除

常用故障排除命令

11. 清理资源

完成测试后，及时清理资源以避免不必要的费用：

12. 生产环境注意事项

实例选择：本示例使用metal/m5d.metal裸金属实例，适合运行Kata Containers 权限配置：确保AWS账户有足够的权限和配额创建这些资源 成本控制：裸金属实例费用较高，请及时删除测试资源 备份策略：对于NVMe方案，制定适当的数据备份策略 监控告警：配置适当的监控和告警机制

总结

在为AI Agent选择沙箱环境时，需要综合考虑安全性、性能、成本、合规性等多个因素。通过对比分析，我们可以看到：

EKS + Kata Containers + Firecracker (EBS)：适合中等规模的企业应用，平衡了成本和性能，享受microVM的快速启动优势 EKS + Kata Containers + Firecracker (NVMe)：适合大规模生产环境，提供最佳的性能和安全性，结合了Firecracker的极速启动和NVMe的高性能存储

Firecracker microVM技术的引入为AI Agent沙箱环境带来了革命性的改进，特别是在启动速度、安全隔离和资源效率方面。对于大多数企业而言，建议采用分阶段的方法：从简单的沙箱方案开始快速验证概念，然后根据业务发展和安全要求逐步迁移到基于Firecracker的Kata Containers环境。

随着AI Agent技术的不断发展，安全沙箱环境将变得越来越重要。Firecracker + Kata Containers的组合为企业提供了一个既安全又高效的解决方案，确保AI Agent能够在最优的环境中为业务创造价值。

*本文基于实际的EKS* *部署经验和对各种沙箱方案的深入调研编写，相关的配置文件和部署脚本可以在GitHub* *仓库 * *eks-kata-containers* *中找到。如果您在技术选型或实施过程中遇到问题，欢迎通过AWS Support* *或社区渠道寻求帮助。* *前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

---

亚马逊AWS官方博客

Kiro小应用开发：设计和实现隐私号码

去年笔者曾经设计过隐私号码、隐私邮箱、网址短链三个小应用，使用亚马逊云科技的Amazon Connect，DynamoDB，Amazon SES，Lambda，CloudFront等服务构建。在设计方案时，我查找了不少文档和网上资料，来选择合适的服务，完善架构。在将方案设计好后，由Claude协助完成Lambda代码（当时是Claude 3 Sonnet），并手动完成其它的服务的配置。方案使用上述的Serverless服务，有成本可控和运维压力小的优点，在某个电商客户部署后得到好评。

在Kiro推出后，其Specs模式令人印象深刻。需求分解，方案设计，甚至是应用部署，这些原来需要人来主导的工作，现在是否可以由Kiro来完成？这里我将使用Kiro来重新开发隐私号码项目，看看在Specs加持下能否将所有的工作都由Kiro来完成。

1.什么是虚拟号码？

虚拟号码使用单独创建的号码来代替真实号码，为用户提供一个额外的身份，能够有效的保护真实联系信息：

保护隐私：在不暴露个人真实[已去除[已去除推广语]语]的情况下与第三方沟通。 身份管理：为不同的身份或活动使用不同的[已去除[已去除推广语]语]。 安全性：降低个人信息被泄露或滥用的风险。

虚拟号码可以有不同的形态：

• 正常普通号码（与普通号码一样，运营商预留的专用号段）。当呼叫这个号码时，自动转接到绑定的真实号码。这种方式在网约车、外卖等场景有广泛的使用。因为号段资源是有限的，这种虚拟号码一般有时效限制，在服务完成后一段时间会解除该虚拟号码与真实号码的绑定。
• 指定号码呼叫+输入短号（分机号）。指定号码是正常普通号码。当呼叫指定号码后，会自动接通并收到输入短号/分机号的提示，输入短号后再转接到真实的号码。这种方式只需要少量的普通号码，通过生成不同的短号关联到不同的真实号码，能够持久的使用或根据需求自定义任意的有效时间。

在接下来的内容中，我将测试由Kiro来完成整个短号方案的需求分解、方案设计、开发、和部署。

2.体验Kiro SPEC模式的魅力

Kiro具体的介绍可以参考官网（https://kiro.dev/），另外推荐由社区整理的

Book of Kiro（https://kiro-community.github.io/book-of-kiro/）。

进入Kiro后，使用SPEC模式，输入如下需求：

Kiro开始方案的设计，生成需求文档requirements.md，针对需求完成设计文档design.md。在确认设计方案无误后，进一步的生成实施计划文档tasks.md。

图1 SPEC模式从创建规范需求开始

在生成这几个SPEC模式的文档时，需求的总结和方案的设计让我眼前一亮，输出的工作流程和mermaid流程图与原先我设计的方案思路完全一致，并额外有一些易用性和可维护性的增强：

• 考虑了通话记录存储、日志记录功能。方便查询通话统计和异常事件
• 设计了增/删/查/改API接口

原来方案在添加短号-真实号码的映射关系时，需要将映射记录手动导入到DynamoDB，删查改等功能也是直接到数据库中操作，只适合开发人员使用。而Kiro的设计更像一个完整的方便易用的生产系统，添加这些运维接口后，任务人员都可以通过Web界面直观的维护。相关的记录和日志功能，也为进一步拓展业务场景打下了基础。

Kiro设计文档比较完整的介绍了工作流程和架构，节选部分内容和加架构图如下：

图2 设计文档在design.md中的流程图

Kiro SPEC模式通过Requirement-Design-Task这个流程，利用AI将一句简短的模糊需求，变成一份结构清晰、条理清楚的规范文档。通过Requirements明确要做什么，通过Design规划如何实现，通过Implementation将整个项目分解为可执行的开发任务，指导LLM不偏离不失控。

在生成初始Design设计文档后，我添加了一个“支持CDK部署”需求，Kiro更新了需求文档和设计文档，之后转到实施计划阶段，生成开发任务

实施计划出炉后，Kiro最终的总结输出节选如下：

在进入任务执行前，我让Kiro 结合Specs三个文档（requirements.md, design.md, tasks.md），更新了Steering。

3.完善的上下文管理Steering

简单的理解Steering，就是每个Task执行时都会注入的上下文内容。统一的上下文，能够控制LLM在执行不同Task开发任务时始终遵循相同的模式、库和标准。

Streering文件可以自定义手动创建，在Kiro面板中Steering部分创建.md文件即可，使用标准的markdown语法编写。在本项目开发中，我让Kiro自己调用LLM，结合Specs文档来完善。它自动创建了三个文档，分别是：

• 产品概述 (product.md) – 定义产品的目的、目标用户、关键功能和业务目标。这帮助 Kiro 理解技术决策背后的”为什么”，并建议与您产品目标一致的解决方案。
• 技术栈 (tech.md) – 记录选择的框架、库、开发工具和技术约束。当 Kiro 建议实现方案时，它会遵从这些选择。
• 项目结构 (structure.md) – 概述文件组织、命名约定、导入模式和架构决策。

节选Kiro自己输出的Steering内容总结：

这三个.md文档，会在每个Task任务执行开始时注入到上下文中。

图3 Task执行时将Steering文档注入上下文

4.丝滑的开发任务执行

Kiro在这个项目的实施计划中分解了15个开发任务。这些开发任务的启动非常简单，在tasks.md文件中点击任务旁边的”Start task”按钮，或者直接在对话框输入“开始任务”即可。

这里我直接将所有任务的开始按钮一起点击了，Kiro会启动第1个任务，并排队后面的14个任务。整个代码开发持续了约三个小时，除任务1中需要安装一些依赖，授权创建一些工具运行外，基本实现了无人值守，由Kiro调用LLM自主完成了代码开发。

图4 Task任务列表示例（已完成状态）

5.自动纠错的方案部署

整个项目支持CDK一键部署到云。在开发完成后，直接本地运行CDK部署命令即可。而使用Kiro，可以让它来运行部署命令，由于是集成的IDE环境，Kiro可以监控部署过程，遇到错误时会自动定位问题，修复代码，再重试部署。

在项目部署中，遇到了部署使用的profile权限不足、部署区域不正确、部署失败再次部署时资源名冲突、Lambda函数没有自动关联到Amazon Connect实例、Contact Flow IVR流格式不对等问题，但基本都能快速定位原因并修复。

在此过程中，一个小技巧是通过提示词引导Kiro使用aws-documentation MCP Server来查询AWS文档，辅助做故障定位和原因分析。相关的AWS MCP Server可参考 https://awslabs.github.io/mcp/

图5 问题修复示例（开发-部署-问题定位-修复-部署的闭环）

6.总结

在虚拟号码开发的过程中，Kiro的表现可以用“惊艳”来形容。

• SPEC模式相较于之前的上下文管理更进一步，通过具体的需求分析-方案设计-执行计划这几步设计，从根本上给LLM的发挥提前指好了方向。并通过Steering上下文管理，以及本文没有具体提及的Agent Hooks，MCP支持等特性，将Agentic IDE带到了一个新的高度。SPEC模式的理念，极大的影响了其它Coding工具的演进，为AI Coding拓展了新的方向。
• 虚拟号码的方案，与原来笔者设计的方案高度一致，都使用了Serverless服务来构建，具有项目整体成本低、免运维的特点。Kiro的设计，在项目的完整性、易用性、可拓展性上更好，可以作为生产级应用直接部署。
• 相较于原来让LLM单纯编写代码的定位，Kiro在需求分解、方案设计、应用部署等原来依赖人工的环节能够有更大的发挥。当然这里并不是说Kiro能够完全代替人的作用，人和生成式AI的配合，就像是“设计师”和“施工队”：设计师绘画蓝图，说明作品的模样和具体的风格；施工队负责落实，完成细节设计并与设计师确认，再利用各类工具搭建完成。好的“设计师”，能够更好的发挥“施工队”的能力。

需要改进的地方：

• 会话Context的管理需要优化提升。在使用中会遇到当前会话Context过大的情况，特别是使用MCP 工具可能引入大量上下文内容。Kiro此时会自动总结压缩内容并启动新的会话，目前存在两个问题：
• 在我测试的时间，目前还不能直观的查看当前Context Token消耗情况，以及当前模型支持的Context大小（其中一些模型在Bedrock上已经提供1M Token版本，但Kiro是否使用未知）
• 在总结压缩内容并开启新会话后，对正在进行中的任务的延续性需要提升。目前开启新会话后，需要手动输入之前相关的内容，才能继续任务

图6 会话超出Context时自动总结并开启新会话

• 对于Amazon Connect Contact Flow这一类格式复杂，对专业性要求比较高的配置文件，对LLM来说很有挑战。在本项目中，Kiro在尝试多次失败后，提议到Connect控制台UI手动创建IVR流，不过它提供了详细的配置步骤和节点类型配置，并说明了如何导出IVR流配置文件到CDK项目中，方便后续直接部署。

图7 Contact Flow的下一步操作指南

7.参考资料

Book of Kiro （https://kiro-community.github.io/book-of-kiro/）

AWS MCP Servers （https://awslabs.github.io/mcp/）

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

---

亚马逊AWS官方博客

EMR和S3的跨区域应急备份恢复方案 之一：在存储成本与恢复时效之间取得平衡

序言

近年来，随着数据和算法对企业核心业务的影响日益加深，数据处理系统的可用性与韧性已成为保障业务连续性的关键要素。与此同时，多家云计算厂商在不同时间都曾出现过区域级别的服务中断事件。虽然这类故障发生概率不高，但一旦触发，往往会影响到依赖云上计算与存储的关键任务链路。

对于以批量数据处理和分析为核心的企业而言，即便计算集群（如 EMR 作业）可以在其他 Region 快速启动，如果底层 S3 数据无法在短时间内恢复访问，业务依然无法重新运转。这类风险促使越来越多的企业开始思考：

如何在成本可控的前提下，构建一套能够跨区域快速恢复的数据灾备体系。目标是在不牺牲成本效率的情况下，将区域性故障对业务的影响降到最低。

本文结合典型的电商数据处理场景，对 EMR 与 S3 的跨区域应急备份与恢复方案进行了系统分析与量化评估。通过比较多种主流方案在成本、恢复时效与可运维性方面的差异，提出了一种在“成本—时效”之间取得最优平衡的技术路径，旨在为构建更具韧性的数据基础设施提供可操作的参考。

应急故障恢复

1. 需求概述

在现代企业架构中，大数据系统已成为支撑核心业务运行和智能决策的基础组件。区域级故障的发生，不仅会导致大数据平台自身的不可用，更会对依赖其进行数据处理和分析的各类业务产生连锁反应。

其直接影响包括但不限于：CRM 活动邮件无法发送、广告投放策略被迫暂停、补货策略无法及时响应新品销售动态、各类经营与分析报表出现数据缺失等。此外，依托大数据平台的模型训练与更新任务也将被中断，进一步导致搜索推荐、个性化排序等智能化服务无法迭代优化，从而对业务增长和用户体验造成持续性影响。

随着数据量普遍达到 PB 级别，大数据系统的跨区域数据复制与恢复变得极为复杂和耗时。当云计算厂商出现区域级大规模故障时，由于 PB 级数据无法在短时间内完成跨区域同步，业务中断的损失会随故障持续时间线性增长。而在某些情况下，受制于区域间网络连通性问题，数据甚至可能暂时无法复制，导致业务恢复时间呈现“乘数效应”。此时，客户即便尝试通过跨区域切换，也难以在短时间内恢复核心大数据业务。造成这一问题的根本原因在于：大数据系统的数据多存储于对象存储（如 S3）中，而跨区域访问在区域级故障期间往往会受到网络瓶颈及服务依赖的多重限制。

因此，应对区域级极端故障的关键在于建立一套高可用、低成本、可快速恢复的数据灾备与恢复机制。该机制需确保在非故障区域内能够迅速启动 EMR 等数据处理服务，并以合理的存储成本与可控的恢复时间激活跨区域备份数据，使大数据处理业务能够在可接受的时间窗口内恢复正常运行。

综合考虑恢复时效性、数据安全性与成本控制，系统设计应满足以下核心要求：

• 数据完整性与一致性保障：跨区域备份数据应保持高可靠性，确保在恢复时具备完整性与一致性。
• 快速恢复能力：在区域级故障发生后，应能在 5 小时内 完成关键数据的恢复与任务重启，满足业务连续性要求。
• 成本优化设计：备份数据在日常状态下可作为冷数据存储，仅在应急情况下进行激活与检索，显著降低长期存储成本。

通过构建满足上述要求的跨区域灾备与恢复方案，企业可以在成本与恢复时效之间实现平衡，显著提升大数据系统的韧性与整体业务的持续可用性。

2. 架构示例

当前架构，正常运行时：

当前架构，启动跨Region应急恢复后：

实施备份方案后，正常运行时：

实施备份方案后，启动跨Region应急恢复后：

3. 数据现状

数系统采用实时与批量相结合的数据处理方式，整体数据规模维持在约 1PB。系统保留最近 6 个月的数据，形成滚动的数据窗口：每月新增约 100TB 增量数据，同时清理最早的一个月数据，以实现周期化管理和稳定的数据规模。

方案选型对比

1. AWS Backup跨区域存储

介绍

AWS Backup 特别适合需要集中化、自动化数据保护策略的企业环境，能够显著简化备份管理并确保合规性。

跨区域恢复

• 自动跨区域备份复制
• 灾难恢复测试
• RTO/RPO 优化
• 恢复验证
• 自动恢复测试
• 备份完整性验证

成本组成

• 跨区域数据传输费用

美国区域间：$0.02/GB

• 备份存储费用

热存储标准费率：$0.05/GB/月（美国西部）

冷存储标准费率：$0.01/GB/月（美国西部）

• 数据恢复费用

热存储恢复费率：$0.02/GB

速度：即时恢复

冷存储恢复费率：$0.03/GB

速度：3-5 小时恢复时间

成本估算示例

根据客户现状，全量数据1PB，每月增量数据100TB，数据管理周期6个月

1.跨区域数据传输费用

• 初始传输：400,000 GB × $0.02 = $8,000
• 每月增量传输：100,000 GB × $0.02 = $2,000

2.备份存储费用（目标区域 us-west-2）

• 月末数据量计算：
• 第1个月：400,000 GB + 100,000 GB = 500,000 GB
• 第2个月：400,000 GB + 200,000 GB = 600,000 GB
• 第3个月：400,000 GB + 300,000 GB = 700,000 GB
• 第4个月：400,000 GB + 400,000 GB = 800,000 GB
• 第5个月：400,000 GB + 500,000 GB = 900,000 GB
• 第6个月：400,000 GB + 600,000 GB = 1,000,000 GB
• 6个月存储数据量计算（按月累积）：
• 6个月总计：4,500,000 GB
• 平均每月：750,000 GB
• 平均每月存储费用：
• 热存储：750,000 GB × $0.05 = $37,500
• 冷存储：750,000 GB × $0.01 = $7,500

3.数据恢复费用

• 热存储恢复：1,000,000 GB × $0.02 = $20,000
• 冷存储恢复：1,000,000 GB × $0.03 = $30,000

4.总费用

• 热存储（即时恢复）：$8,000（初始化） + $2,000（增量传输） + $37,500（数据存储）+ $20.000（应急恢复）
• 冷存储（3-5小时）：$8,000（初始化） + $2,000（增量传输） + $7,500（数据存储） + $30,000（应急恢复）

总体评估

• 优点：自动将备份数据移至冷存储，重复数据删除，压缩优化
• 缺点：成本较高
• 推荐：⭐️⭐️（不推荐）

2. S3 Glacier Deep Archive 跨区域复制

介绍

适用场景：

• 7-10年长期归档
• 合规性数据保存
• 极少访问的数据
• 成本优先考虑

最小存储期限：180天

成本组成

• 跨区域数据传输费用

美国区域间：$0.02/GB

• 备份存储费用

存储标准费率：$0.00099/GB/月

• 数据恢复费用

标准检索：$0.0025/GB + $0.0004/1000请求

速度：12小时内

批量检索：$0.00025/GB + $0.0004/1000请求

速度：48小时内

成本估算示例

根据客户现状，全量数据1PB，每月增量数据100TB，数据管理周期6个月

1.跨区域数据传输费用

• 初始传输：400,000 GB × $0.02 = $8,000
• 每月增量传输：100,000 GB × $0.02 = $2,000

2.备份存储费用

• 月末数据量计算：
• 第1个月：400,000 GB + 100,000 GB = 500,000 GB
• 第2个月：400,000 GB + 200,000 GB = 600,000 GB
• 第3个月：400,000 GB + 300,000 GB = 700,000 GB
• 第4个月：400,000 GB + 400,000 GB = 800,000 GB
• 第5个月：400,000 GB + 500,000 GB = 900,000 GB
• 第6个月：400,000 GB + 600,000 GB = 1,000,000 GB
• 6个月存储数据量计算（按月累积）：
• 6个月总计：4,500,000 GB
• 平均每月：750,000 GB
• 平均每月存储费用：
• 750,000 GB × $0.00099 = $750

3.数据恢复费用

• 标准检索：1,000,000 GB × $0.0025 = $2,500
• 批量检索：1,000,000 GB × $0.00025 = $250

4.总费用

• 标准检索（12小时内）：$8,000（初始化） + $2,000（增量传输） + $750（数据存储）+ $2,500（应急恢复）
• 批量检索（48小时内）：$8,000（初始化） + $2,000（增量传输） + $750（数据存储）+ $250（应急恢复）

总体评估

• 优点：成本最低
• 缺点：数据恢复时间过长，无法满足应急要求
• 推荐：⭐️（不考虑）

3. S3 Glacier Flexible Retrieval 跨区域复制

介绍

适用场景：

• 1-5年中期归档
• 偶尔需要快速访问
• 备份和灾难恢复
• 平衡成本和访问速度

最小存储期限：90天

成本组成

• 跨区域数据传输费用

美国区域间：$0.02/GB

• 备份存储费用

存储标准费率：$0.004/GB/月

• 数据恢复费用

加急检索：$0.03/GB + $0.01/1000请求

速度：1-5分钟内

标准检索：$0.01/GB + $0.0004/1000请求

速度：3-5小时内

批量检索：$0.0025/GB + $0.0004/1000请求

速度：5-12小时内

成本估算示例

根据客户现状，全量数据1PB，每月增量数据100TB，数据管理周期6个月

1.跨区域数据传输费用

• 初始传输：400,000 GB × $0.02 = $8,000
• 每月增量传输：100,000 GB × $0.02 = $2,000

2.备份存储费用

• 月末数据量计算：
• 第1个月：400,000 GB + 100,000 GB = 500,000 GB
• 第2个月：400,000 GB + 200,000 GB = 600,000 GB
• 第3个月：400,000 GB + 300,000 GB = 700,000 GB
• 第4个月：400,000 GB + 400,000 GB = 800,000 GB
• 第5个月：400,000 GB + 500,000 GB = 900,000 GB
• 第6个月：400,000 GB + 600,000 GB = 1,000,000 GB
• 6个月存储数据量计算（按月累积）：
• 6个月总计：4,500,000 GB
• 平均每月：750,000 GB
• 平均每月存储费用：
• 750,000 GB × $0.004 = $3,000

3.数据恢复费用

• 加急检索：1,000,000 GB × $0.03 = $30,000
• 标准检索：1,000,000 GB × $0.01 = $10,000
• 批量检索：1,000,000 GB × $0.0025 = $2,500

4.总费用

• 加急检索（1-5分钟）：$8,000（初始化） + $2,000（增量传输） + $3,000（数据存储）+ $30,000（应急恢复）
• 标准检索（3-5小时）：$8,000（初始化） + $2,000（增量传输） + $3,000（数据存储）+ $10,000（应急恢复）
• 批量检索（5-12小时）：$8,000（初始化） + $2,000（增量传输） + $3,000（数据存储）+ $2,500（应急恢复）

总体评估

• 优点：成本较低
• 缺点：暂无
• 推荐：⭐️⭐️⭐️⭐️

4. 综合对比

根据客户现状，全量数据1PB，每月增量数据100TB，数据管理周期6个月

|A

|B

|C

|D

|E

|F

|G

|H

|1

|方式

|类型

|数据恢复时效

|初始化传输

|增量传输(每月)

|数据存储(每月)

|应急恢复(1PB)

|建议

|2

|AWS Backup

|热存储

|即时恢复

|$8,000

|$2,000

|$37,500

|$20,000

|不考虑，成本太高

|3

|冷存储

|3-5小时

|$8,000

|$2,000

|$7,500

|$30,000

|不考虑，成本高

|4

|Deep Archive

|标准检索

|12小时内

|$8,000

|$2,000

|$750

|$2,500

|不考虑，数据恢复时效性不满足

|5

|批量检索

|48小时内

|$8,000

|$2,000

|$750

|$250

|不考虑，数据恢复时效性不满足

|6

|Flexible Retrieval

|加急检索

|1-5分钟

|$8,000

|$2,000

|$3,000

|$30,000

|应急快速恢复

|7

|标准检索

|3-5小时

|$8,000

|$2,000

|$3,000

|$10,000

|时效性要求不高，又有成本要求时考虑

|8

|批量检索

|5-12小时

|$8,000

|$2,000

|$3,000

|$2,500

|不考虑，数据恢复时效性不满足

|9

|S3标准存储

|即时恢复

|$8,000

|$2,000

|$16,500

|$0

• 首先，根据数据恢复的时效性要求，使用S3 Glacier Deep Archive进行数据存储，无法在较短的时间内完成数据恢复，不符合本次方案的基本需求，该方式被放弃；
• 其次，使用AWS Backup热存储，存储费用高达05 GB/月，比S3标准存储0.022 GB/月还要高出一倍以上，比Flexible Retrieval存储价格高出十倍以上，因此该方式被放弃；
• 第三，使用AWS Backup冷存储，对比恢复时间相同的Flexible Retrieval标准检索存储，存储成本高出一倍以上，恢复成本高出两倍，也不符合方案的成本最低要求，该方式不建议使用；
• 第四，整体看在恢复时效性和成本上最能满足要求的是S3 Glacier Flexible Retrieval，整体成本较低，也可以满足数据恢复的基本要求，同时提供了加急检索和标准检索两种方式，可以根据实际情况进行选择。

方案实施过程

S3 Glacier Flexible Retrieval 跨区域复制实施步骤

1. 准备工作

启用源桶版本控制：

aws s3api put-bucket-versioning \

–bucket source-bucket \

–versioning-configuration Status=Enabled

创建目标桶：

aws s3 mb s3://target-bucket —region us-west-2

aws s3api put-bucket-versioning \

–bucket target-bucket \

–versioning-configuration Status=Enabled

2. 创建IAM角色

创建信任策略文件（trust-policy.json）：

{

“Version”: “2012-10-17”,

“Statement”: [{

“Effect”: “Allow”,

“Principal”: {“Service”: “s3.amazonaws.com”},

“Action”: “sts:AssumeRole”

}]

}

创建权限策略文件（replication-policy.json）：

{

“Version”: “2012-10-17”,

“Statement”: [

{

“Effect”: “Allow”,

“Action”: [

“s3:GetObjectVersionForReplication”,

“s3:GetObjectVersionAcl”

],

“Resource”: “arn:aws:s3:::source-bucket/*”

},

{

“Effect”: “Allow”,

“Action”: [

“s3:ListBucket”

],

“Resource”: “arn:aws:s3:::source-bucket”

},

{

“Effect”: “Allow”,

“Action”: [

“s3:ReplicateObject”,

“s3:ReplicateDelete”

],

“Resource”: “arn:aws:s3:::target-bucket/*”

}

]

}

创建IAM角色：

aws iam create-role \

–role-name s3-replication-role \

–assume-role-policy-document file://trust-policy.json

aws iam put-role-policy \

–role-name s3-replication-role \

–policy-name s3-replication-policy \

–policy-document file://replication-policy.json

3. 配置跨Region复制

创建复制配置文件（replication-config.json）：

{

“Role”: “arn:aws:iam::YOUR-ACCOUNT-ID:role/s3-replication-role”,

“Rules”: [{

“ID”: “GlacierBackupRule”,

“Status”: “Enabled”,

“Filter”: {“Prefix”: “”},

“Destination”: {

“Bucket”: “arn:aws:s3:::target-bucket”,

“StorageClass”: “GLACIER”

}

}]

}

应用复制配置：

aws s3api put-bucket-replication \

–bucket source-bucket \

–replication-configuration file://replication-config.json

4. 验证配置

检查复制状态：

aws s3api get-bucket-replication —bucket source-bucket

测试复制：

上传测试文件

aws s3 cp test-file.txt s3://source-bucket/

检查目标桶

aws s3 ls s3://target-bucket/

aws s3api head-object —bucket target-bucket —key test-file.txt

5. 监控和管理

查看复制指标：

aws s3api get-bucket-replication —bucket source-bucket

aws cloudwatch get-metric-statistics \

–namespace AWS/S3 \

–metric-name ReplicationLatency \

–dimensions Name=SourceBucket,Value=source-bucket

结语

在云计算环境中，区域级故障虽属低概率事件，但对依赖大数据处理与分析的企业而言，其业务影响往往是成倍放大的。通过本方案的系统评估与实践验证可以看出，采用 S3 Glacier Flexible Retrieval 跨区域复制能够在成本与时效之间取得最优平衡：既保证了PB级数据的跨区域备份完整性与可靠性，又在应急情况下实现了可控的恢复时效。结合合理的生命周期管理策略与自动化运维机制，企业能够在保持成本可控的前提下，显著提升大数据系统的韧性与业务连续性，为未来的不确定性建立更稳固的底层保障。

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

---

亚马逊AWS官方博客

使用Amazon CodePipeline 自动部署到 Amazon ECS: 构建高效、可靠的 CI/CD 流程

1. 概述

1.1 背景与目标

在当今快速迭代的软件开发周期中，“速度”和“稳定”是决定业务成败的两个关键因素。容器化技术（如 Docker）和编排服务（如 Amazon ECS）极大地简化了应用的打包和运行，但“如何安全、快速、可靠地将新版本的应用代码部署到生产环境”仍然是一个核心挑战。

许多团队仍然依赖手动或半自动化的脚本来执行部署。这些方法不仅耗时，而且极易出错：一个配置疏忽、一个错误的命令，都可能导致服务中断。这正是我们需要一个全自动 CI/CD (持续集成/持续交付) 流程的原因。

本文将重点介绍如何使用 AWS 托管的 CI/CD 服务套件（特别是 Amazon CodePipeline）与 Amazon ECS 相结合，实现从代码提交到生产部署的全流程自动化，特别是实现蓝/绿部署 (Blue/Green Deployment)，最大限度地提高发布的可靠性。

1.2 为什么选择 CodePipeline + ECS? 方案优势解读

将 Amazon CodePipeline 与 Amazon ECS 结合使用，不仅仅是“自动化”，更是构建了一个云原生的、弹性的、可观测的交付系统。

1.2.1 自动化与一致性（The “Why”）

消除人为错误: 流程中的每一步（构建、测试、部署）都由机器严格执行预定义的规范。这消除了“我本地可以, 上生产就不行”的典型问题，以及手动操作带来的疏忽（例如，忘记更新某个环境变量）。

标准化发布流程: 无论是开发环境、测试环境还是生产环境，都遵循同一套 CI/CD 流程。这保证了跨环境的一致性，使得在生产环境中发现的问题更容易在开发环境中复现。

1.2.2 快速迭代与价值交付（The Benefit）

缩短交付周期： 开发者只需 git push，剩下的事情交给 CodePipeline。从代码提交到功能上线的时间可以从几天缩短到几分钟。

聚焦核心业务： 开发团队可以从繁琐的部署工作中解放出来，专注于编写能为客户创造价值的代码，而不是维护复杂的部署脚本。

1.2.3 可靠性：蓝/绿部署（The “How-To-Be-Safe”）

零停机部署： 这是本方案的核心优势。通过与 Amazon CodeDeploy 集成，ECS 可以实现无缝的蓝/绿部署。CodeDeploy 会启动一个全新的、与当前生产环境（“蓝”环境）并行的“绿”环境，并将新版本的应用部署在“绿”环境中。

安全可控的流量切换： 一旦“绿”环境准备就绪并通过健康检查，CodeDeploy 会通过修改 Application Load Balancer (ALB) 的监听器规则，将生产流量（例如 10%、50% 乃至 100%）逐步切换到“绿”环境。

快速一键回滚： 如果在流量切换过程中发现任何问题（例如，新版本的错误率飙升），您可以在几秒钟内将流量切回仍然在运行的“蓝”环境（旧版本），实现近乎即时的回滚，将故障影响降至最低。

1.2.4 深度集成与安全性

原生集成： CodePipeline 无缝集成了 Amazon CodeCommit (代码仓库)、Amazon CodeBuild (构建服务)、Amazon ECR (容器镜像仓库) 和 Amazon ECS (运行环境)。无需管理和集成多个第三方工具。

精细的权限管控： 所有的操作都基于 IAM 角色和策略。您可以精确控制 CodeBuild 有权推送到哪个 ECR 仓库，CodePipeline 有权部署到哪个 ECS 集群，确保了整个流程的安全性。

合规与审计： 所有的 API 调用和操作都由 Amazon CloudTrail 记录，提供了完整的审计日志，满足合规性要求。

2. 方案架构概览

目标架构：

• Source (源)： 开发者将代码（包括 Dockerfile、yml 和 taskdef.json 模板）推送到 Amazon CodeCommit。
• Trigger (触发)： CodeCommit 的推送事件自动触发 Amazon CodePipeline。
• Build (构建)：
• CodePipeline 启动 Amazon CodeBuild 项目。
• CodeBuild 拉取源码，基于 Dockerfile 构建 Docker 镜像。
• CodeBuild 将新镜像推送到 Amazon ECR。
• CodeBuild 根据新镜像的 URI 更新 json 文件。
• CodeBuild 将更新后的 json 和 appspec.yml 作为构建产物输出。
• Deploy (部署)：
• CodePipeline 触发 Amazon CodeDeploy。
• CodeDeploy 读取yml 和 new-taskdef.json。
• CodeDeploy 在 Amazon ECS 集群上执行蓝/绿部署：
• 启动一个包含新任务定义的“绿”部署。
• 在 ALB 上配置测试监听器（可选），允许在切换前进行最后测试。
• 将生产流量从“蓝”环境（旧版本）切换到“绿”环境（新版本）。
• （可选）在一段时间后自动终止“蓝”环境。

3. 详细Demo: 一步步搭建ECS 蓝/绿部署管道

目标：搭建一个 CI/CD 管道，当 index.html 发生变化时，使用蓝/绿部署策略，自动将一个新的 Nginx 容器版本部署到 ECS Fargate 集群。

前提条件

• 一个 AWS 中国区账户（如 cn-north-1 或 cn-northwest-1）
• 具有管理员权限的 IAM 用户（或至少有 ECS, ECR, CodePipeline, CodeBuild, CodeDeploy, VPC, ALB, IAM 的完全访问权限）
• 本地安装并配置 Git

3.1 准备ECS运行环境 (VPC, ALB, ECS 集群)

3.1.1 创建VPC

• 为简单起见，您可以直接使用默认 VPC。
• 关键： 确保您的 VPC 至少有两个位于不同可用区 (AZ) 的公有子网（如果使用 Fargate 并需要拉取公网镜像）和私有子网（推荐用于运行任务）。本 Demo 为简单起见，我们假设使用公有子网，并为 Fargate 任务分配公有 IP。

3.1.2 创建ALB

• 导航到 EC2 控制台 > 负载均衡器 > 创建负载均衡器。
• 选择 “Application Load Balancer”。
• 网络映射： 选择您的 VPC 和至少两个可用区的公有子网。
• 安全组： 创建一个新的安全组，允许来自 0.0.0.0/0 的 HTTP (80) 流量。
• 监听器和路由：
• 创建一个监听器，协议 HTTP，端口 80。
• 关键： 为此监听器创建一个目标组 (Target Group)，命名为 tg-blue。
• 目标类型：IP (因为我们将使用 Fargate)。
• 协议 HTTP，端口 80。
• 健康检查：路径 /。
• 将监听器的默认操作设置为转发到 tg-blue
• 创建第二个目标组：
• 我们还需要一个用于“绿”部署的目标组。
• 重复上述步骤，创建第二个目标组，命名为 tg-green。创建一个监听器，协议HTTP，端口8080，关联到tg-green
• 创建 ALB。记下 ALB 的 DNS 名称。

3.2 创建ECR 镜像仓库

• 导航到 ECR 控制台。
• 创建仓库
• 记下仓库的 repositoryUri（例如：[account-id].dkr.ecr.cn-north-1.amazonaws.com.cn/）

3.3 (手动)部署“蓝”环境 (v1)

在设置管道之前，我们必须先有一个正在运行的“v1”版本（“蓝”环境）。

3.3.1创建初始 Task Definition (任务定义)：

• 在 ECS 控制台 > 任务定义 > 创建新任务定义。
• 选择 Fargate。
• 命名：my-app-task-def (CodeDeploy 会在此基础上创建新版本)。
• 任务角色：留空（或 ecsTaskExecutionRole）。
• 重要：CPU 架构设置成arm64
• 任务执行角色：选择（或创建）ecsTaskExecutionRole（允许 ECR 拉取镜像）。
• 任务大小：5 vCPU, 1 GB 内存。
• 容器定义：
• 点击 “添加容器”。
• 容器名称：my-app-container (**重要：**这个名字必须在后续步骤中保持一致)。
• 镜像：nginx:alpine (我们先用一个公开的镜像作为 v1，中国区可能有无法访问镜像库, 可以参考附加内容解决)。
• 端口映射：80 / tcp。
• 创建任务定义。它会被命名为 my-app-task-def:1。

3.3.2 创建ECS服务(service)

–

• ECS 服务 > 创建集群> my-app-cluster。
• 启动类型：FARGATE。
• 任务定义：my-app-task-def，版本 1。
• 服务名称：my-app-service。
• 负载均衡：
• 选择 “Application Load Balancer”。
• 选择您在步骤 1 中创建的 ALB。
• 容器： 选择 my-app-container:80。
• 生产监听器： 选择 HTTP: 80。
• 目标组 1 (Blue)： 选择 tg-blue。
• 目标组 2 (Green)： 选择 tg-green。
• 网络配置：
• 选择您的 VPC 和公有子网。
• 安全组：选择您为 ALB 创建的安全组。
• 自动分配公有 IP： 启用 (ENABLED)。
• 创建服务。

几分钟后，服务应变为 ACTIVE。访问您的 ALB DNS，您应该能看到 Nginx 的欢迎页面。我们的“蓝”环境 (v1) 现在已上线。

3.4 准备代码仓库和CI/CD配置文件

3.4.1创建 CodeCommit 仓库：

• 导航到 CodeCommit 控制台 > 创建存储库 > 命名为 my-ecs-app-repo。
• 在本地克隆该仓库：

git clone [your-repo-url]

• 进入新目录

cd my-ecs-app-repo

3.4.2在本地仓库中创建以下文件：

• 创建 index.html: (这是我们的 v2 版本)
• 创建 Dockerfile (适配中国区)： (使用的是ECR中的模版，具体操作查看附录)
• taskdef-template.json: (这是任务定义的模板，注意 image 字段的占位符)
• appspec.yml: (这是告诉 CodeDeploy 如何部署的文件)
• buildspec.yml: (这是告诉 CodeBuild 如何构建的文件)

3.4.3提交文件：

3.5 创建CodeBuild 项目

3.5.1导航到 CodeBuild 控制台 > 创建构建项目。

3.5.2项目名称：ecs-app-builder。

3.5.3源：

• 源提供程序：Amazon CodeCommit。
• 存储库：my-ecs-app-repo。
• 分支：main。

3.5.4环境：

• 镜像：托管镜像。
• 操作系统：Amazon Linux 2 (或 Ubuntu)， ARM64。
• 运行时：Standard。
• 关键： 勾选 “Privileged” (特权)，因为需要构建 Docker 镜像。

3.5.5服务角色：

• 选择 “新建服务角色”。
• 角色名称：codebuild-ecs-app-builder-role。

3.5.6环境变量 (重要)：

• AWS_ACCOUNT_ID: 您的账户 ID。
• ECR_REPO_NAME: my-hello-app (步骤 2 中创建的 ECR 仓库名)。

3.5.7 BuildSpec：

• 选择 “使用 buildspec 文件” (默认)。

3.5.8创建构建项目。

修改** ** CodeBuild ** **角色权限：

• 构建项目创建后，它会创建一个 IAM 角色。
• 导航到 IAM 控制台 > 角色 > 找到 codebuild-ecs-app-builder-role。
• 添加权限： 附加策略 AmazonEC2ContainerRegistryPowerUser。这将允许 CodeBuild 登录 ECR 并推送镜像。

3.6 创建CodePipeline

这是将所有组件串联起来的最后一步。

3.6.1 CodePipeline 控制台 > 创建流水线。

流水线名称：my-ecs-app-pipeline。

服务角色：新服务角色。

阶段** ** 1** **：** **Source (** **源** **)

• 源提供程序：Amazon CodeCommit。
• 存储库名称：my-ecs-app-repo。
• 分支名称：main。
• 检测选项：Amazon CloudWatch Events (推荐)。

阶段** ** 2** **：** **Build (** **构建** **)

• 构建提供程序：Amazon CodeBuild。
• 项目名称：ecs-app-builder (上一步创建的)。
• 构建类型：单个构建。

阶段** ** 3** **：** **Deploy (** **部署** **)

• 部署提供程序：Amazon ECS (Blue/Green)。
• 区域：(您的区域)。
• 应用程序名称： 选择由 ECS 自动创建的名称 (例如 AppECS-my-app-cluster-my-app-service)。
• 部署组名称： 选择由 ECS 自动创建的名称 (例如 DgpECS-my-app-cluster-my-app-service)。
• Amazon ECS 任务定义：
• 输入构件：BuildArtifact (或您在 Build 阶段的输出构件名)。
• 文件名：new-taskdef.json (这必须匹配yml 中 artifacts 的定义)。
• Amazon CodeDeploy AppSpec 文件：
• 输入构件：BuildArtifact。
• 文件名：appspec.yml。

查看并创建管道。

3.7 触发和验证部署 (v2)

创建管道后，它会自动从 CodeCommit 拉取最新代码 (v2) 并开始执行。

观察管道：

• Source: 变为绿色 (成功)。
• Build: 变为蓝色 (进行中)，然后变为绿色。您可以点击 “详细信息” 查看 CodeBuild 日志，确认 docker build 和 docker push 成功。
• Deploy: 变为蓝色 (进行中)。

切换到 CodeDeploy 控制台：

• 在 CodeDeploy > 部署 > 找到正在进行的部署。
• 您将看到蓝/绿部署的三个步骤：

–

• 步骤 1：部署开始。 CodeDeploy 正在拉取新任务定义，并在 tg-green 上启动新的 Fargate 任务。
• 步骤 2：流量重新路由。 此时，CodeDeploy 会等待（默认 5 分钟）。
• 步骤 3：终止原始任务。

–

验证 v2：

• 在“步骤 2”期间，立即访问您的 ALB DNS。您应该仍然看到 Nginx 的默认页面 (v1)。
• 等待 5 分钟（或您在 CodeDeploy 部署组中设置的等待时间）。
• CodeDeploy 会自动将 ALB 监听器的规则从 tg-blue 切换到 tg-green。
• 再次刷新 ALB DNS 页面。 您现在应该能看到：
• Hello World – v2.0 Deployed by Amazon CodePipeline!
• 部署成功！CodeDeploy 稍后会终止“蓝”环境 (v1) 的旧任务。

3.8 测试v3 (CI/CD 闭环)

3.8.1在本地，修改 index.html 文件：

3.8.2 提交并推送代码：

3.8.3 返回 CodePipeline 控制台。您会发现管道在几秒钟内被自动触发。

3.8.4重复步骤 7 的验证过程。几分钟后，您的 ALB DNS 将自动显示 “v3.0″。

4. 结语

在本文中，我们利用 Amazon CodePipeline、CodeBuild、CodeDeploy 和 Amazon ECS (Fargate) 搭建了一条从代码提交到生产环境的全自动 CI/CD 管道。

这套方案的核心价值在于，通过自动化的蓝/绿部署，我们实现了零停机、低风险的安全发布。这不仅彻底告别了复杂易错的手动部署，还提供了近乎即时的回滚能力，确保了生产环境的稳定。

开发团队最终得以从繁琐的运维工作中解放出来，真正专注于业务创新和价值交付。这套 AWS 原生集成的 CI/CD 流程，是实现快速、可靠迭代的坚实起点。

附加内容：

中国区无法访问nginx: alpine 解决方案：

Docker pull nginx:alpine

下载镜像到本地，然后上传到ECR：

配置修订版时使用：

.dkr.ecr.cn-north-1.amazonaws.com.cn/my-hello-app:v1

注意：ecsTaskExecutionRole 需要有AmazonECSTaskExecutionRolePolicy权限

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

---

亚马逊AWS官方博客

在Apache DataHub中整合Amazon Glue任务的数据血缘

1. 概述

Apache DataHub （下面简称DataHub）是一个开源的元数据平台，旨在解决现代数据生态系统中的元数据管理挑战。它最初由 LinkedIn 开发并开源，现已成为 Linux 基金会下的独立项目。DataHub 提供了一个集中式平台，用于组织、发现、理解和管理企业数据资产。

本文旨在简述如何将Amazon Glue中数据库元数据同步到DataHub中，同时将Glue任务中的数据血缘一起展现在DataHub中。

本文部分内容参考自Amazon Blog Deploy DataHub using AWS managed services and ingest metadata from AWS Glue and Amazon Redshift – Part 1 和 Deploy DataHub using AWS managed services and ingest metadata from AWS Glue and Amazon Redshift – Part 2

2. DataHub介绍

Apache DataHub是由Linkedin开源的，官方喊出的口号为：The Metadata Platform for the Modern Data Stack – 为现代数据栈而生的元数据平台。目的就是为了解决多种多样数据生态系统的元数据管理问题，它提供元数据检索、数据发现、数据监测和数据监管能力，帮助大家解决数据管理的复杂性。它采用基于推送的数据收集架构（当然也支持pull拉取的方式），能够持续收集变化的元数据。当前版本已经集成了大部分流行数据生态系统接入能力，包括但不限于：Kafka, Airflow, MySQL, SQL Server, Postgres, LDAP, Snowflake, Hive, BigQuery。

下图展示了 DataHub 架构，其中Metadata Service是摄入元数据的对应服务，也叫GMS。我们将通过调用API的方式将Glue的表信息插入到Metadata Service。

以下的展示过程中，图的左边是通过DataHub的Python SDK把Glue Data Catalog的现有数据库和表信息同步到DataHub的GMS服务器中，右边是通过Spark插件把Glue ETL任务运行时的血缘关系插入到GMS服务器中。

3. 准备工作

本部分将快速搭建一个DataHub测试环境。版本为1.2.0。

3.1. 创建EC2

首先，我们需要创建一个能够连接互联网的Amazon Linux 2023 EC2实例，最好能顺利连接GitHub和Docker Hub。

创建一个EC2 Role，拥有AWSGlueServiceRole或者更高的权限，然后分配给这个EC2。这样在EC2上运行Python脚本时就可以有足够权限来访问Glue。

3.2. 安装Docker和Python

在EC2上安装必要的软件环境：

3.3. 安装DataHub

安装DataHub及其依赖项：

下载docker-compose文件：

curl -SL https://raw.githubuserconten[已去除短链接]m/datahub-project/datahub/master/docker/quickstart/docker-compose.quickstart-profile.yml -o docker-compose.yml

修改docker-compose配置文件，启用GMS的认证模式，同时为OpenSearch增加内存（实验中经常遇到OpenSearch OOM问题）

Line 68:

METADATA_SERVICE_AUTH_ENABLED: ‘true’

Line 325:

memory: ‘[已去除电话]’

Line 328:

OPENSEARCH_JAVA_OPTS: -Xms1024m -Xmx1024m -Dlog4j2.formatMsgNoLookups=true

启动DataHub服务：

datahub docker quickstart –quickstart-compose-file docker-compose.yml

3.4. 设置DataHub

打开浏览器，访问http://:9002。

使用默认用户名和密码登录：datahub/datahub

进入Settings, 创建Access Token，记录下创建的Token。这个就是后续访问GMS所用的认证Token。

4. 摄入Glue元数据

4.1. 安装DataHub客户端Glue插件

pip3 install –upgrade ‘acryl-datahub[glue]’

4.2. 修改摄入脚本

创建文件glue_ingestion.py，可以从GitHub下载

然后修改AWS Region，GMS Server和Token。其中GMS Server的地址就是上述安装DataHub的服务器IP地址，端口是8000。

4.3. 运行摄入脚本

python3 glue_ingestion.py

顺利运行完成后，可以看到同步的Glue表的统计信息：

此时去DataHub Web界面上Discover里面可以看到Glue的信息：

5. 捕获数据血缘

上文Glue数据摄入后，只是每个表的单独信息，还没有表与表之间的血缘关系。接下来我们可以通过Glue任务中插入Spark Listener的设置来捕获数据血缘。

5.1. 准备数据

我们下载一个纽约出租车的一个Parquet文件来作为源表。https://www.nyc.gov/site/tlc/about/tlc-trip-record-data.page，选择2022年一月 Yellow Taxi Trip Records (PARQUET)

将下载到的parquet文件，上传到s3上: s3://{your_bucket}/trip-data下。

5.2. 创建数据库和表

在Glue中创建一个数据库nyx_taxi

然后到Athena界面，选择nyx_taxi数据库，然后执行以下语句，（修改bucket name）

5.3. 再次同步表信息到DataHub

再次执行3.3的步骤，同步新创建的库和表。

python3 glue_ingestion.py

5.4. 准备Glue任务

下载datahub-spark-lineage 的JAR文件，并放到S3上：s3://{your_bucket}/ externalJar/。记下完整路径：s3://{your_bucket}/externalJar/acryl-spark-lineage_2.12-0.2.19-rc2.jar。此JAR文件是读取Spark任务相关信息，然后同步到DataHub。

下载log4j.properties文件，并放到S3上： s3://{your_bucket}/externalJar/。记录下完整路径： s3://{your_bucket}/externalJar/log4j.properties。此文件用来打开DataHub插件的调试信息。

在Athena中执行以下语句来创建目标表：（修改bucket name）

5.5. 创建Glue任务

为了让DataHub插件能访问到部署在私有网络的DataHub，我们需要为Glue任务创建一个私网的Connection。

创建Glue Connection，选择Network类型，选择与DataHub同一个VPC中的私有子网，选择的安全组中Inbound要有允许安全组自身的规则：

下载Glue脚本的任务，这个任务是对源表执行一些基本数据转换，然后写入到目标表中。修改脚本中GMS_ENDPOINT和GMS_TOKEN。

然后设置Glue任务的细节：

选择Glue 3.0和Python 3。

在高级选项中做如下设置：

• 设置Network Connection为之前创建的Connection
• 添加JAR文件路径到Libraries中：s3://{your_bucket}/externalJar/acryl-spark-lineage_2.12-0.2.19-rc2.jar
• 添加Log4j配置文件路径：–conf spark.driver.extraJavaOptions=-Dlog4j.configuration=s3://{your_bucket}/externalJar/log4j.properties

该作业从着陆表（landing table）中读取数据作为Spark DataFrame，然后将数据插入到目标表中。这个JAR是一个轻量级Java代理，它监听Spark应用程序作业事件，并实时将元数据推送到DataHub。被读取和写入的数据集的血缘关系（lineage）被捕获。应用程序启动和结束、SQLExecution启动和结束等事件都会被捕获。这些信息可以在DataHub中的管道（DataJob）和任务（DataFlow）下查看。

5.6. 运行Glue任务

运行该任务。任务结束后，在DataHub的Pipeline中可以看到该任务和上下游的表。

从表信息中，可以看到字段级别的血缘关系。

以下是一个两表Join的例子，仅作为参考，具体步骤不再叙述。

6. 注意事项

• Glue Ingestion的任务需要定期运行，以保持Glue元数据与DataHub同步
• 可以通过设置参数来过滤Glue Ingestion中的数据库和表
• Glue任务需要设置Connection来连接VPC网络
• 不同Glue脚本中的app.name应设置为不同值，以避免血缘关系混乱

7. 总结

本文详细演示了如何将Glue元数据同步到DataHub中，并在Glue脚本任务中自动捕获数据血缘。通过这种方式，您可以在DataHub中全面了解数据流动和转换过程，提高数据治理能力。

同时，这个血缘关系的捕获，也可以适用在Amazon EMR的场景中。

8. 附录

AWS Blog 1: https://aws.amazon.com/blogs/big-data/part-1-deploy-datahub-using-aws-managed-services-and-ingest-metadata-from-aws-glue-and-amazon-redshift/

AWS Blog 2: https://aws.amazon.com/blogs/big-data/part-2-deploy-datahub-using-aws-managed-services-and-ingest-metadata-from-aws-glue-and-amazon-redshift/

Glue Ingestion.py: https://github.com/aws-samples/deploy-datahub-using-aws-managed-services-ingest-metadata/blob/main/aws-dataplatform-meta-data-ingestion/examples/code/glue_ingestion.py

NY Taix data: https://www.nyc.gov/site/tlc/about/tlc-trip-record-data.page

NY Taxi data: https://d37ci6vzurychx.cloudfront.net/trip-data/yellow_tripdata_2022-01.parquet

DataHub Spark Source plugin: https://repo1.maven.org/maven2/io/acryl/acryl-spark-lineage_2.12/0.2.19-rc2/acryl-spark-lineage_2.12-0.2.19-rc2.jar

Log4j.properties: https://github.com/aws-samples/deploy-datahub-using-aws-managed-services-ingest-metadata/blob/main/aws-dataplatform-meta-data-ingestion/examples/code/log4j.properties

Glue data ingestion.py: https://github.com/aws-samples/deploy-datahub-using-aws-managed-services-ingest-metadata/blob/main/aws-dataplatform-meta-data-ingestion/examples/code/glue_data_lineage.py

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

---

亚马逊AWS官方博客

从智能工厂到车联网:S3 Tables 双模式写入实战指南

引言

在 IoT 数据处理场景中，我们经常面临两种截然不同的数据写入需求：

智能工厂：1000+ 传感器每 5 分钟批量上传数据 车联网：10 万+ 车辆持续发送实时位置和状态

这两种场景带来了不同的技术挑战：

批量写入场景（智能工厂）：

• 数据量大但频率低，需要高效的批处理能力
• 需要保证数据完整性和事务一致性
• 要求灵活的 Schema 演化支持设备升级

流式写入场景（车联网）：

• 海量设备并发写入，峰值 QPS 可达数万
• 要求毫秒级延迟和近实时数据可用性
• 需要自动化的数据格式转换和分区管理

此外，对于IoT** **用户而言，还需要构建统一的数据分析平台，实现场景化的业务分析，这就要求：

• 两种数据源需要统一的查询接口
• 支持时间旅行和历史数据回溯
• 兼容 Athena、Spark 等多种分析引擎

如何用统一的存储方案优雅地处理这两种模式？本文将介绍基于 Amazon S3 Tables 的两种数据写入方案，充分利用 S3 Tables 作为 AWS 基于开放表存储服务的优势：

托管式 Iceberg 表：自动维护表元数据、快照与统计信息，无需手动运行 Iceberg catalog 或 rewrite manifests 自动优化：后台持续执行小文件合并、删除文件清理与索引重建，保持高查询性能并降低请求成本 成本优化：按使用量付费，无需预置资源，显著降低运营成本 安全保障：集成 AWS IAM，支持细粒度权限控制和数据加密 开放标准：基于 Apache Iceberg 格式，避免厂商锁定 企业级特性：天然支持 ACID 事务、Schema 演化和时间旅行 生态集成：与 Athena、Spark、EMR 等分析服务无缝集成

通过这些特性，实现统一的数据湖存储和查询，简化架构复杂度的同时保证数据一致性。

方案一:Lambda + PyIceberg 批量写入：IoT 设备通过 HTTPS 协议将批量数据发送到 API Gateway，触发 Lambda 函数执行。Lambda 函数使用 PyIceberg 库直接操作 S3 Tables，执行数据验证、转换和写入操作。PyIceberg 提供了完整的 Iceberg 表操作能力，包括 Schema 管理、事务控制和元数据更新。整个流程采用事件驱动架构，按实际调用次数计费，无需预置资源。Lambda 函数可以实现任意复杂的业务逻辑，如数据清洗、格式转换、质量检查等，并通过 Iceberg 的 ACID 事务保证数据一致性。 方案二:Kinesis Firehose 流式写入：IoT 设备通过 MQTT 或 HTTPS 协议连接到 AWS IoT Core，IoT Core 的规则引擎根据配置的规则将消息实时路由到 Kinesis Data Streams。Kinesis Data Streams 提供高吞吐的流式数据传输能力，支持海量设备并发写入。Kinesis Firehose 从 Data Streams 消费数据，自动进行批处理、压缩和格式转换（可选 Lambda 转换），然后以写入 S3 Tables。整个流程完全托管，自动扩展，无需管理服务器。Firehose 的缓冲机制（默认 60 秒或 5MB）在保证近实时性的同时，通过批量写入优化了成本和性能。

方案一：Lambda + PyIceberg 批量写入

核心组件

API Gateway：作为 HTTPS 入口，接收 IoT 设备的批量数据请求。提供 REST API 接口，支持请求验证、限流和监控。通过集成 Lambda 函数，将接收到的 JSON 数据以事件形式传递给后端处理逻辑。 Lambda 函数：核心数据处理引擎，使用 Python 运行时执行业务逻辑。通过 PyIceberg 库直接操作 Iceberg 表，实现数据验证、清洗、转换和写入。支持完全自定义的处理流程，包括复杂的业务规则、数据质量检查和 Schema 演化管理。Lambda 按调用次数和执行时间计费，无需预置资源。 PyIceberg：Python 实现的 Apache Iceberg 客户端库，通过 S3 Tables 提供的 RESTful Iceberg Catalog 接口访问和操作表。PyIceberg 连接到 S3 Tables 的 REST Catalog 端点，获取表的元数据信息，然后直接读写 S3 中的数据文件。这种架构下，S3 Tables 负责管理 Iceberg 元数据（表结构、快照、分区信息等），而 PyIceberg 负责执行数据操作（读取、写入、事务提交）。 S3 Tables：全托管的 Apache Iceberg 表，ACID 事务、列式 Parquet、自动合并小文件，秒级 Schema 演进与时间旅行查询，原生集成 Athena/Redshift 等分析引擎。

核心实践

Lambda 函数实现

下面的示例代码，pyiceberg 对接 S3 Tables 的 rest catalog api批量插入数据到 S3 Tables，核心实现包括

• 连接到 S3 Tables

*Catalog*

• 使用 PyArrow Schema 定义表结构
• 支持 Pandas DataFrame 数据插入

Lambda 配置

requirements.txt ： Lambda 设置： 内存：512 MB – 1024 MB 超时：60 秒 运行时：Python 3.12 IAM 权限：

API Gateway 配置

REST API 端点： 请求示例：

方案部署

方案二：Kinesis 流式写入 S3 Tables (Streaming Write with Kinesis)

核心组件

IoT Core：专为 IoT 设备设计的托管服务，负责管理海量设备的 MQTT 长连接（支持 10 万+ 设备并发）。提供设备认证、消息发布/订阅和规则引擎功能。规则引擎可以根据 SQL 语句过滤、转换消息，并将符合条件的数据实时路由到 Kinesis Data Streams，实现设备层与数据处理层的解耦。 Kinesis Data Streams (KDS)：高吞吐的实时数据流服务，常用作缓冲层接收 IoT Core 等源的数据。通过 Shard 机制水平扩展，每 Shard 提供 1 MB/s 写入和 2 MB/s 读取。支持“按需模式”（自动扩缩）与“预置模式”（手动指定 Shard）。数据默认免费保留 24 小时，开启“延长保留”后可保存 7 天，再启用“长期保留”最多可达 365 天（额外按月/GB 计费），为下游应用提供有序且可重放的数据源。 Kinesis Data Firehose：全托管、无服务器的流式 ETL 服务，可从 Kinesis Data Streams 或其他源消费数据，自动投递到 S3 Tables、Redshift、OpenSearch 等目标。内置智能缓冲（默认 1 MB 或 60 秒触发，可配置范围 1–128 MB / 60–900 秒）、批量写入、自动重试与错误日志。支持 SNAPPY/GZIP 压缩、JSON 转 Parquet/ORC 格式，并可调用 Lambda 进行自定义转换，无需管理任何底层基础设施。 S3 Tables：全托管的 Apache Iceberg 表，ACID 事务、列式 Parquet、自动合并小文件，秒级 Schema 演进与时间旅行查询，原生集成 Athena/Redshift 等分析引擎。

核心实践

1.创建表存储桶，命名空间和表

在控制台中导航到 Amazon S3。选择”表存储桶”，然后如果尚未启用与 AWS 分析服务的集成，请选择”启用集成”，如下图所示。此集成允许用户在 AWS Glue 数据目录和 AWS Lake Formation 中发现在此 AWS 区域和此账户中创建的所有表，并通过 AWS 服务（如 Firehose、Athena、Amazon Redshift 和 Amazon EMR）访问它们。

输入表存储桶名称

点击表存储桶名，进入存储桶

使用Athena创建表

输入命名空间名称

test_namespace

点击

创建命名空间

点击

使用Athena** **创建表， **如下，在Athena中点击运行创建示例表 **daily_sales

2.创建给Data Firehose用的IAM角色

创建一个 IAM 角色,授予 Firehose 权限以对默认 AWS Glue 数据目录中的表执行操作、在通用 S3 存储桶中备份流式传输期间失败的记录,以及与 Kinesis Data Stream 交互。此外,根据您的 Firehose 配置,您可以选择授予 Amazon CloudWatch 日志记录和 AWS Lambda 函数操作的额外权限。

首先IAM服务中首先创建一个策略，以JSON格式输入以下内容，其中ap-southeast-1（新加坡）改成你自己的区域，[已去除电话]改成你自己的12位AWS 账号ID（部分Resource暂时用*，等资源创建完成后可以修改策略内容以缩小权限范围），给策略取名，例如

FirehoseS3TablePolicy：

IAM服务中创建角色，可信任实体类型选择AWS服务，使用案例选择Firehose

附加刚才创建的策略，给策略取名，如

FirehoseS3TableRole，请记录这个角色,因为稍后需要使用它来授予 AWS Lake Formation 权限。

3.在Lake Formation中创建Resource link

Firehose要将数据流式传输到S3 table bucket中的表，需要在Lake Formation中创建指向表存储桶中命名空间的Resource link

在Shared database中选择上一步表存储桶中创建的name space

4.配置 AWS Lake Formation 权限

AWS Lake Formation 管理对表资源的访问。Lake Formation 使用自己的权限模型，可对数据目录资源进行细粒度访问控制。为了让 Firehose 将数据摄取到表存储桶中，您必须为向上一步中创建的 Resource link授予权限。

点击选择刚创建好的resource link，，然后选择”Grant”。在”授予权限”页面上，在”主体”下，选择”IAM 用户和角色”，然后选择上一步中创建的 IAM 角色。在此示例中，Firehose 角色名为

FirehoseS3TableRole。在”LF 标签或目录资源”下，选择”命名数据目录资源”。对于”目录”，选择您在集成表存储桶时创建的子目录。对于”数据库”，选择您刚创建的 resource link。对于”Resource Link permissions”，选择”Describe”。

授予

Describe权限

点击选择刚创建好的resource link，，然后选择”Grant on target”。在”授予权限”页面上，在”主体”下，选择”IAM 用户和角色”，然后选择上一步中创建的 IAM 角色。在此示例中，Firehose 角色名为

FirehoseS3TableRole。在”LF 标签或目录资源”下，选择”命名数据目录资源”。对于”目录”，选择您在集成表存储桶时创建的子目录。对于”数据库”，选择在 S3 table bucket 创建的namespace ，选择您在表存储桶中创建的表，对于”表权限”，选择”Super”，选择”授予”，授予目标表权限。

5.创建Kinesis Data Stream

要创建 Kinesis Data Streams流，请在控制台中打开 Amazon Kinesis → Data Streams, 并点击创建数据流。然后，为您的 数据 流 设定一个名称，如

test-stream，遵循界面中显示的命名约定，如下图所示：

点击

创建数据流 ，等待Data Stream创建成功：

6.创建Firehose 流

要创建 Firehose 流，请在控制台中打开 Firehose 并选择”

创建 Firehose 流“。选择 “ Amazon Kinesis Data Streams” 作为源，选择 Apache Iceberg Tables 作为目标。然后，为您的 Firehose 流选择一个名称，遵循界面中显示的命名约定，如下图所示：

要为您的表存储桶配置目标设置，您需要配置 Firehose 应写入的数据库和表名称。如果您希望 Firehose 流仅写入一个表，则可以配置”唯一键配置”部分。要配置此部分，请选择您在步骤 2 中创建的resource link（

s3tables_resource_link）作为数据库名称，并选择您在步骤 1 中创建的表（ daily_sales）作为表名称。如果 Firehose 无法传输到配置的表，它将传输到 S3ErrorOutputPrefix。

指定一个 Amazon S3 通用存储桶来存储无法传输到 S3 表存储桶的记录。

在 IAM 角色下，选择您之前为 Firehose 创建的用于访问 S3 表存储桶的角色

FirehoseS3TableRole，然后选择”创建 Firehose 流”来创建您的 Firehose 流，如下图所示

当流创建完成后，监控 Firehose 传输流状态，直到它变为”活动”状态，如下图所示：

7.使用 Kinesis Data Generator 发送流式数据

Kinesis Data Generator 是一个允许您向 Firehose 发送流式数据的应用程序。首先，为您的账户配置 configure Kinesis Data Generator。然后，将区域设置为与您的 Firehose 匹配，并选择在步骤 6 中创建的 Firehose 流。使用以下与步骤 1 中定义的表架构匹配的模板:

8. 使用 Athena 验证和查询数据

现在，您可以使用 Athena 查询 S3 表。要查询并验证从 Firehose 摄取的数据，可以在 Athena 中运行 SELECT 命令，如下图所示。只要数据持续从 Kinesis Data Generator 流式传输，您应该会看到此表中的行数不断增加，这确认了数据摄取成功。

方案选择

上文介绍了两种将 IoT 数据写入 S3 Tables 的方案，它们针对不同的数据特征和业务场景进行了优化：

方案一：Lambda + PyIceberg ** **批量写入

适用于定时批量采集场景，如智能工厂传感器每隔几分钟批量上传数据。该方案通过 API Gateway 接收 HTTPS 请求，Lambda 函数使用 PyIceberg 库直接操作 Iceberg 表，提供完全自定义的数据转换能力。优势在于实现灵活、成本可控，适合数据量较小（< 1GB/小时）且对延迟不敏感（5-15分钟可接受）的场景。

方案二：IoT Core + Kinesis Firehose ** **流式写入

专为高频实时数据流设计，如车联网场景中数万辆车持续发送位置数据。IoT Core 负责管理海量设备的 MQTT 连接，并通过规则引擎将消息路由到 Kinesis Data Streams，再由 Firehose 自动批量写入 S3 Tables。该方案完全托管、自动扩展，延迟低至 60 秒以内，适合大数据量（> 1GB/小时）和高并发场景。

对于同时运营多条业务线的企业（如既有工厂设备又有物流车队），可以采用混合架构。批量数据走方案一，流式数据走方案二，最终写入同一个 S3 Tables，实现统一的数据湖和查询层。这种方式在保证各业务线最优性能的同时，简化了下游分析架构。

选型决策建议

选择方案一的场景：

• 设备数量在 10000 以下
• 数据采集频率为分钟或小时级
• 需要复杂的数据转换和业务逻辑
• 对成本敏感，希望按实际使用量付费
• 可接受 5-15 分钟的数据延迟

选择方案二的场景：

• 设备数量超过 10000，甚至数十万
• 需要秒级或近实时的数据可用性
• 数据持续高频写入（> 1GB/小时）
• 希望使用完全托管服务，降低运维负担
• 需要自动扩展能力应对流量突发

选择混合方案的场景：

• 企业有多条业务线，数据特征差异大
• 既有批量历史数据导入，又有实时数据写入
• 需要统一的数据湖和查询接口
• 希望为不同业务选择最优技术方案

详细对比表

下表提供了两种方案在各个维度的详细对比，帮助您做出更精准的选择：

|A

|B

|C

|D

|1

|

对比维度 |

方案一：Lambda + PyIceberg |

方案二：IoT Core + Kinesis Firehose |

混合方案

|2

|数据频率

|低频（分钟/小时级）

|高频（秒级/毫秒级）

|混合频率

|3

|数据量

|< 1GB/小时

|> 1GB/小时

|不限

|4

|批次大小

|[已去除电话]0条/批

|单条或小批量

|按来源区分

|5

|数据延迟

|5-15分钟

|< 60秒

|按业务区分

|6

|典型场景

|智能工厂、定时采集

|车联网、实时监控

|多业务线并存

|7

|设备数量

|[已去除电话]0

|10000+

|不限

|8

|连接方式

|HTTPS REST API

|MQTT/HTTPS

|两者都支持

|9

|数据模式

|批量上传

|持续流式

|批量+流式

|10

|实现复杂度

|中等

|低

|中高

|11

|运维负担

|中等

|极低

|中等

|12

|扩展性

|手动调整

|自动扩展

|自动扩展

|13

|数据转换

|完全自定义（Python）

|Lambda转换

|两者都支持

|14

|Schema演化

|灵活

|需配置

|统一管理

|15

|固定成本

|无

|Kinesis Shard费用

|Kinesis Shard费用

|16

|变动成本

|API Gateway + Lambda

|Firehose数据处理

|两者叠加

|17

|存储成本

|S3 Tables统一计费

|S3 Tables统一计费

|S3 Tables统一计费

|18

|推荐场景1

|定时批量采集

|实时数据流

|多业务线

|19

|推荐场景2

|成本敏感

|海量设备

|不同数据源

|20

|推荐场景3

|需要复杂转换逻辑

|低延迟要求

|统一数据湖

|21

|不推荐场景1

|实时性要求高

|低频批量数据

|单一数据模式

|22

|不推荐场景2

|持续高频写入

|复杂业务逻辑

|简单场景

小结

本文介绍了两种将 IoT 数据写入 Amazon S3 Tables 的架构方案，它们针对不同的业务场景提供了最优解决方案：

方案一：Lambda + PyIceberg 提供了灵活可控的批量写入能力，适合智能工厂等定时采集场景。其核心优势在于完全自定义的数据处理逻辑和按需付费的成本模型，让您可以精确控制数据转换过程和事务边界。 方案二：IoT Core + Kinesis Firehose 提供了全托管的流式写入能力，专为车联网等实时场景设计。其核心优势在于零运维负担和自动扩展能力，可以轻松应对海量设备的并发写入，实现近实时的数据处理。

两种方案都基于

S3 Tables (Apache Iceberg) 构建统一的数据湖，提供 ACID 事务、Schema 演化和时间旅行等企业级特性。 特别值得关注的是，Amazon S3 Tables 最新推出的压缩成本优化功能 ，可将压缩成本降低达 90%，进一步提升了 IoT 数据存储的经济性。

您可以根据业务特点单独使用某一方案，也可以采用混合架构，让批量数据和流式数据汇聚到同一数据湖，简化下游分析架构。

选择 Lambda + PyIceberg 追求灵活性和成本优化，选择 Kinesis Firehose 追求实时性和零运维，或者组合使用实现最佳性价比。无论哪种选择，S3 Tables 都为您的 IoT 数据平台提供了坚实的存储基础。

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

---