📚 课程目录第2章 AWS云原生平台参考架构设计

2. AWS云原生平台参考架构设计

在上一节中，我们明确了平台工程的核心目标是让应用团队以自助方式获得合规、安全、可观测的运行环境。本节将基于 AWS Well-Architected 框架，把这一目标落地为可执行的参考架构：多账户、多环境、多租户的组织方式，以及控制平面与数据平面分离的设计原则。

为什么必须多账户

AWS 账户是资源、权限、计费和配额的最强隔离边界。把生产、预发、开发、共享服务、日志归档、安全审计放在同一个账户里，会带来三个直接问题：IAM 策略复杂度随资源数量指数上升；一个误操作可能同时影响多个环境；配额与成本无法按团队或环境清晰归属。多账户不是管理负担，而是把复杂度前置到结构层，让后续治理有明确的落点。

推荐采用 AWS Organizations 作为账户治理根，配合组织单元（OU）做分层。一个可落地的初始结构如下：

Root：仅挂载服务控制策略（SCP），不直接放业务账户。
Security OU：Log Archive 账户集中接收全组织 CloudTrail、Config、VPC Flow Logs；Security Tooling 账户运行 GuardDuty、Security Hub、Inspector 的委派管理员。
Infrastructure OU：Network 账户持有 Transit Gateway、共享 VPC、Route 53 Resolver；Shared Services 账户承载 CI/CD、制品库、镜像仓库。
Workloads OU：按业务域或团队再分 Prod 与 NonProd 两个子 OU，每个应用团队拥有独立账户。

SCP 在这一层做“护栏”而非“授权”。例如在 Workloads OU 上禁止关闭 CloudTrail、禁止创建未加密的 EBS、禁止使用非批准区域。SCP 只做减法，真正的权限仍由各账户内 IAM 角色授予，这样既保证底线，又不牺牲团队自治。

多环境与多租户的落地方式

多环境有两种常见切法：按账户切和按命名空间切。对于强合规、强隔离的生产负载，推荐“每环境每账户”，即 dev、staging、prod 各自独立账户，通过同一套 IaC 流水线以不同参数部署。对于同一账户内的多租户（例如 SaaS 平台为多个客户提供服务），则用命名空间、标签和 IAM 条件键做逻辑隔离：为每个租户分配 tenant-id 标签，在 IAM 策略中用 aws:RequestTag/tenant-id 和 aws:ResourceTag/tenant-id 限制访问，并在数据层用行级安全或独立 schema 保证数据不串。

需要强调的是，多租户的隔离强度取决于数据敏感度。低敏感场景可用共享集群加标签隔离；高敏感场景应升级为每租户独立账户或独立 VPC，甚至独立 KMS 密钥。架构设计时先定隔离等级，再选实现手段，避免后期返工。

控制平面与数据平面分离

这是本节最核心的设计原则。控制平面负责“定义和编排”——账户工厂、IaC 流水线、策略即代码、服务目录、权限审批；数据平面负责“实际承载业务流量”——VPC、EKS 集群、RDS、S3、API Gateway 等。两者分离的价值在于：控制平面故障不会中断线上流量；数据平面扩容不需要改动治理逻辑；安全边界清晰，控制平面凭据泄露不会直接暴露业务数据。

具体实现上，控制平面通常放在 Shared Services 与 Security 账户，通过跨账户 IAM 角色 AssumeRole 操作各工作负载账户；数据平面则完全留在工作负载账户内，控制平面只下发模板和策略，不持有长期数据访问凭据。CI/CD 流水线使用 OIDC 联合身份短期凭据，避免长期 Access Key。

用 Well-Architected 六支柱校验架构

参考架构不是画完就结束，需要用 Well-Architected 框架逐项校验。卓越运营支柱关注 IaC 覆盖率、变更可回滚、运行手册是否随架构更新；安全支柱关注最小权限、SCP 护栏、KMS 密钥分层、跨账户访问是否全部走 AssumeRole；可靠性支柱关注多可用区、跨账户备份、故障域隔离；性能效率关注共享服务是否成为瓶颈；成本优化关注标签体系能否支撑按租户/环境分摊；可持续性关注资源利用率与闲置回收。建议把每个支柱的关键检查项写成 Config 规则或 Well-Architected 自定义 lens，纳入流水线门禁，而不是靠人工评审。

一个可执行的账户基线示例

下面给出新账户创建后应自动落地的基线配置片段，可作为 Account Factory 的模板输入。参数为示例值，实际使用时按组织规范调整。

Baseline:
  account_type: workload
  ou: Workloads/NonProd
  region_allowlist: [ap-northeast-1, ap-southeast-1]
  cloudtrail:
    org_trail: true
    log_archive_account: "111122223333"
    kms_key: "alias/org-trail-key"
  config:
    recorder: true
    delivery_bucket: "org-config-111122223333"
  guardrails:
    - deny_disable_cloudtrail
    - deny_unencrypted_ebs
    - deny_public_s3_acl
    - require_tenant_id_tag
  network:
    vpc_cidr: "10.20.0.0/16"
    attach_to_tgw: true
    tgw_id: "tgw-0abc123"
  iam:
    platform_admin_role: "arn:aws:iam::<account>:role/PlatformAdmin"
    trust_from: "arn:aws:iam::444455556666:role/ControlPlaneDeployer"

这份基线的关键点在于：CloudTrail 与 Config 的日志统一投递到 Log Archive 账户，工作负载账户即使被攻破也无法删除审计记录；网络通过 Transit Gateway 接入共享网络账户，避免每个账户重复建 VPC 对等连接；IAM 信任策略只允许控制平面账户的特定角色 AssumeRole，且该角色受 SCP 和权限边界双重约束。

设计检查：如果控制平面账户完全不可用，数据平面上的业务是否仍能继续运行？如果答案是“能”，说明分离原则落实到位；如果“不能”，说明控制平面承担了运行时职责，需要拆分。

常见误区与判断依据

第一个误区是把控制平面做成“超级账户”，所有业务账户的长期凭据都放在里面。正确做法是控制平面只持有可 AssumeRole 的角色 ARN，凭据有效期以小时计。第二个误区是多租户只靠标签，不做数据层隔离。判断依据是：如果租户 A 的 IAM 角色被误配，能否读到租户 B 的数据？能，则隔离不足。第三个误区是环境数量越多越好。实际上环境数量应与发布策略匹配，通常 dev、staging、prod 三层足够，过多环境会稀释治理投入。

落地顺序建议：先用 Organizations 和 Control Tower 建立账户骨架与 SCP 护栏，再搭建 Log Archive 与 Security Tooling 账户，然后建设 Network 与 Shared Services，最后接入第一个工作负载账户并跑通 CI/CD 到数据平面的完整链路。每完成一层，用 Well-Architected 对应支柱做一次快速校验，确保架构在扩展前是稳固的。