AWS 部署映射

架构要落地，每个能力都需要一个明确的基础设施落点。AIDC 默认使用 AWS 作为早期和中期的运行底座：AWS 负责计算、网络、存储、身份、密钥、日志和审计，Agent 底座负责工作流、沙箱与策略。本页给出能力到服务的逐项映射、部门隔离的网络拓扑、密钥与身份设计、分阶段部署清单和成本控制策略。

// 分工边界

AWS 提供云基础设施（计算、网络、存储、IAM / KMS / 审计），Agent 底座提供沙箱、策略、凭证注入与生命周期管理。两者组合，但不互相替代——云服务器只是运行环境，安全边界由两层共同构成。

能力 → AWS 服务映射

每个 Agent Cell 的能力都有推荐的 AWS 落点。隔离边界用账号、VPC 与 IAM 物理化，而不是靠应用层约定：

CapabilityAWS Candidate
Agent RuntimeECS/Fargate、EKS，短任务用 Lambda
Department File System每部门独立 EFS，或每部门独立 S3 prefix
SecretsAWS Secrets Manager、KMS
Network IsolationVPC、subnet、security group、private endpoint
EventingEventBridge、SQS、SNS
Logs & MetricsCloudWatch、OpenTelemetry collector
IdentityIAM Identity Center、IAM roles、session policies
Agent RuntimeECS / Fargate · EKS · Lambda

长驻 Agent 跑在 ECS/Fargate 或 EKS 上，按队列深度扩缩容；低频短任务用 Lambda 起短生命周期 worker，执行完即销毁。早期可以用 EC2 + Docker / Docker Compose 起步，成熟后迁移 ECS 或 EKS。需要沙箱边界的执行型 Agent，在运行时之上叠加 OpenShell / NemoHermes 一类 sandbox 层，文件、进程、网络、推理路由按策略受控。

Department File SystemEFS · S3 prefix

每个部门一个独立的 EFS（或 EFS Access Point），或一个独立的 S3 prefix——部门文件系统默认隔离是权限模型的第一条规则。共享工作区用 EFS，归档与对象存储用 S3 并开启 versioning 与 lifecycle policy，主机盘用 EBS。沙箱不挂载整个 EFS 根目录，每个 Agent 只获得任务必需的 workspace path。

SecretsSecrets Manager · KMS

所有敏感凭证进入 Secrets Manager 或 SSM Parameter Store，不直接写入 Agent 工作目录；KMS 按数据敏感级别拆分密钥边界。详细设计见下文"密钥与身份"。

Network IsolationVPC · subnet · SG · private endpoint

VPC 划定平台的网络边界，subnet 区分公网面与工作负载面，security group 按 Cell 收紧进出规则，private endpoint 让 S3、Secrets Manager、CloudWatch 等服务调用不出公网。详细拓扑见下文专节。

EventingEventBridge · SQS · SNS

Cell 之间的异步协作走事件总线：EventBridge 做企业事件路由，SQS 做任务队列（支持重试与死信队列），SNS 做扇出通知。幂等消费由消费端按事件 ID 去重保证。事件层的可靠性语义见 可靠性与降级。

Logs & MetricsCloudWatch · OpenTelemetry

应用日志与主机日志进入 CloudWatch Logs，指标走 CloudWatch Metrics 或 OpenTelemetry collector；AWS API 审计开 CloudTrail，关键 S3 bucket 开 data events，网络层开 VPC Flow Logs。沙箱与 gateway 日志同样汇入 CloudWatch，后续可接 OpenSearch 或 SIEM。这一层为 演化闭环 的 Observation 提供数据。

IdentityIAM Identity Center · IAM roles · session policies

人的身份走 IAM Identity Center（SSO），工作负载身份走 IAM role——每个 Cell、每类 Agent 一个独立 role，绝不共用高权限凭证；session policy 在临时会话上进一步收窄权限，实现"按任务临时授权"。EC2 role 初期只给 CloudWatch Logs 与 SSM Session Manager 所需权限，不给 AdministratorAccess。

部门隔离的网络拓扑

网络拓扑的目标是把"部门文件系统默认隔离"延伸到网络层：每个部门 Cell 有自己的子网与安全组，管理入口不暴露公网，服务调用走私有通道。

FIG. 01 — NETWORK TOPOLOGY 
AWS Account（环境级；敏感客户用独立账号）
└── VPC
    ├── public subnet            # 仅 NAT Gateway / 内部 ALB，无 Agent 负载
    ├── private subnet · mgmt    # 高权限管理面 · 独立 SG · VPN/SSM 入口
    ├── private subnet · cell A  # 部门 Cell A · 独立 SG · EFS access point
    ├── private subnet · cell B  # 部门 Cell B · 独立 SG · EFS access point
    └── VPC endpoints            # S3 · Secrets Manager · CloudWatch · ECR
部门隔离的网络拓扑：Agent 工作负载全部在私有子网，每个 Cell 一个安全组；公有子网只放 NAT 与内部入口，AWS 服务调用经 VPC endpoint 不出公网。

拓扑遵循以下规则：

密钥与身份

凭证泄露是 Agent 平台最典型的失败模式：Agent 读取本地凭证文件、读取 .env、把 token 发给外部 endpoint。密钥与身份设计的原则是——敏感凭证不落入 Agent 可读的位置，身份按最小权限切分。

Secrets Manager凭证托管

所有密钥进入 AWS Secrets Manager 或 SSM Parameter Store，敏感凭证不写入 Agent 工作目录，不以 .env 或凭证文件的形式挂进沙箱。模型 provider key 不直接暴露给 Agent 进程，而是经受控推理路由注入——Agent 只看到本地路由地址，真实凭证留在宿主 / gateway 侧。每个 integration 一个独立 token，使用短期、最小 scope 的凭证，轮换流程写入 runbook。

KMS加密边界

EBS、EFS、S3、Secrets 全部用 KMS CMK 加密，并按数据敏感级别拆分密钥边界：客户生产数据、公司战略材料、Agent 凭证各用独立 key，按客户或数据域授权。密钥隔离让"拿到存储不等于拿到数据"成立，也让单个客户的密钥可以独立撤销。

IAM Identity Center身份与会话

人的访问走 IAM Identity Center 统一 SSO，不发长期 access key；工作负载走 IAM role（EKS 上用 IRSA / Pod Identity），每个 Cell、每类任务一个独立 role，配 permission boundary 防止越权扩权；session policy 在会话级进一步收窄，支持"按项目、按客户、按任务临时授权"。

// 治理规则

创建或删除 IAM admin role、KMS key，开放公网入口、修改 security group 入站规则，以及把凭证写入非受控位置——这些动作 Agent 必须请求人类确认，不允许自动执行。权限分层的完整定义见 权限模型。

分阶段部署清单

部署不要一步到位做全企业平台。按以下阶段推进，每个阶段有明确的完成判据：

  1. 阶段 0 — 单账号 PoC

    目标：在一台 EC2 上跑通 Agent 底座，验证文件隔离、网络拦截、凭证保护与基础交付流程。

    • 单 AWS account，单 VPC，至少拆分 public / private subnet；工作负载放私有子网。
    • EC2 用 Ubuntu LTS，CPU PoC 选 m7i.large / m7i.xlarge，100GB gp3 起步；仅本地推理才用 GPU 实例。
    • Security group：入站 22 只允许管理员 IP，Agent API 与 dashboard 端口不开放公网，远程访问走 SSH tunnel 或 SSM port forwarding。
    • IAM role 只给 CloudWatch Logs / SSM 所需权限，不给 AdministratorAccess。
    • 所有密钥进入 Secrets Manager / SSM Parameter Store；CloudWatch 收集应用与主机日志。
    • 验收：文件隔离生效（Agent 读不到未声明路径）、未批准域名被拦截并留日志、凭证不可被 Agent 直读、snapshot 可创建可恢复。

  2. 阶段 1 — 受控团队试运行

    目标：2–5 个内部成员通过同一平台完成真实交付任务，策略进入版本控制。

    • 高权限管理面与员工执行面使用不同 IAM role，权限层清晰拆分；执行型任务不使用高权限环境。
    • 每个项目独立文件目录、日志组和访问策略；每个 sandbox 只承载一个业务用途，禁止共用高权限凭证。
    • 所有 policy YAML、gateway 配置、IaC 进入 Git，走 PR review；使用固定版本镜像与私有 registry。
    • 入口收敛到内部 ALB / VPN / SSO；日志进入 CloudWatch / OpenSearch。
    • 验收：能够恢复 sandbox、重建环境、撤销权限；交付操作有 checklist 与 handover 记录。

  3. 阶段 2 — 客户交付与生产化前评估

    目标：支持客户项目、敏感数据与正式交付，补齐生产化所需的治理项。

    • 客户数据与内部数据分离；敏感客户使用独立 AWS account、独立 VPC、独立 KMS key。
    • 客户生产数据不进入普通员工 sandbox；Agent 只读取任务必要的最小数据集。
    • 明确哪些任务允许 unattended agent；按任务类型定义文件策略与网络出口白名单；模型 provider 与数据分级绑定。
    • 凭证全部进入 Secrets Manager / workload identity；CloudTrail / CloudWatch / SIEM 审计闭环建立。
    • 验收：有 snapshot、restore、destroy 与事故撤权流程；备份与回滚演练通过；交接材料完整。

  4. 阶段 3 — 去中心化服务节点

    目标：形成多个自治服务节点，每个节点有自己的文件、Agent、权限和审计边界。

    • 按客户、部门或敏感数据域划分节点；每个节点独立 EFS / S3 prefix / IAM role / KMS key / log group。
    • 中央只保留目录、策略、审计摘要和跨节点任务路由——与六层架构的中央平面职责一致。
    • 验收：单节点故障不影响其他节点；节点可整体交接给客户或独立运营。形态详见 Service Node。

成本控制

成本失控是平台的已知风险，对策写进架构而不是事后砍预算：部门 Cell 按需扩缩容，低频任务走短生命周期 worker。

策略做法效果
按需扩缩容Cell 的 runtime worker 按队列深度伸缩（ECS/Fargate / EKS autoscaling），空闲时缩到最小副本计算成本跟随真实负载，而不是峰值容量
短生命周期 worker低频、偶发任务用 Lambda 或一次性 sandbox，执行完即销毁不为偶发任务长期占用计算资源
实例从小起步只调远程模型时用 m7i.large 级 CPU 实例 + 100GB gp3；GPU 实例（g5/g6）仅在确需本地推理时使用避免"为了以后"预置昂贵算力
存储生命周期S3 versioning 配 lifecycle policy，旧版本与归档自动转低成本存储层版本化的安全性不以无限存储为代价
环境可销毁sandbox 支持 snapshot / rebuild / destroy，闲置环境销毁而非挂起测试与 PoC 环境不产生长尾成本

成本与可靠性共用同一套机制：扩缩容、短生命周期 worker 与可销毁环境，既是降本手段，也是 可靠性与降级 中"复制与隔离"的实现方式。

相关阅读