📚 课程目录第3章迁移 landing zone 设计

3. 迁移 landing zone 设计

迁移到 AWS 时，真正决定项目能否长期稳定运行的，往往不是某个应用怎么搬，而是“地基”怎么打。这个地基就是 Landing Zone：一套可重复、可治理、可审计的多账户环境。它要回答四个问题：账户如何划分、身份如何统一、网络如何连通与隔离、安全与合规如何被持续强制。AWS 提供的核心工具是 Organizations（组织与策略）、Control Tower（自动化落地与护栏）、IAM（身份与权限）、VPC 与 Transit Gateway（网络拓扑），以及以 CloudTrail、Config、GuardDuty、Security Hub 为代表的安全基线服务。

一、多账户架构：先分账户，再谈网络

多账户不是把资源拆散，而是用账户作为最强的隔离边界。推荐按“职能 + 环境 + 业务域”组合划分。典型结构如下：

管理账户（Management）：只放 Organizations、账单、Control Tower 控制台，不放业务负载。
安全账户（Security）：集中存放 CloudTrail 日志、Config 聚合、GuardDuty 管理员、Security Hub 管理员。
日志归档账户（Log Archive）：接收各账户的访问日志与配置快照，设置不可变保留策略。
共享服务账户（Shared Services）：目录服务、DNS、CI/CD、镜像仓库等公共能力。
网络账户（Network）：Transit Gateway、集中出口 NAT、混合专线/DX 的落地点。
业务 OU：按生产、预发、开发分 OU，每个 OU 下再按业务域建账户。

Organizations 的 OU 是策略挂载点。把账户放进 OU，就等于继承了该 OU 的 Service Control Policy（SCP）。SCP 只做“最大权限上限”，不授予权限，因此它和 IAM 是“先收窄、再授权”的关系。例如给生产 OU 挂一条 SCP，禁止关闭 CloudTrail、禁止删除 Config 记录器、禁止在非批准区域创建资源：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRegionOutsideApproved",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["cn-north-1", "cn-northwest-1"]
        }
      }
    },
    {
      "Sid": "ProtectAudit",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "config:DeleteConfigurationRecorder",
        "config:StopConfigurationRecorder"
      ],
      "Resource": "*"
    }
  ]
}

Control Tower 的价值在于把上述账户创建、OU 组织、基线配置、日志集中、护栏部署自动化。它通过 Account Factory 创建新账户，自动套用 Landing Zone 基线，并在控制台给出合规状态。落地时建议先启用 Control Tower，再在其管理的 OU 下扩展业务账户，避免手工建号后无法纳管。

二、身份与访问管理：人、机、跨账户三条线

身份设计要区分三类主体：人（员工、运维）、机（应用、CI/CD）、跨账户角色。人的身份优先接入 IAM Identity Center（原 SSO），与外部 IdP（如 AD、Okta）做 SAML/SCIM 同步，按组分配权限集（Permission Set），再映射到各账户。这样员工离职只需在 IdP 禁用，所有账户访问同时失效。

机器身份不要用长期 Access Key。EC2、Lambda、ECS 用 IAM Role 附加；CI/CD 用 OIDC 联合身份换取临时凭证。跨账户访问统一用 sts:AssumeRole，并在信任策略里限定来源账户与外部 ID：

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::111122223333:root"},
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {"sts:ExternalId": "migration-pipeline-2024"}
    }
  }]
}

权限设计遵循最小权限：先用 IAM Access Analyzer 生成基于 CloudTrail 活动的策略建议，再人工收敛。对生产账户，禁止直接使用 root，root 只保留 MFA 与账单用途。

三、网络拓扑：集中出口与集中入口

多账户网络的核心是“集中连通、分区隔离”。推荐每个账户建自己的 VPC，业务子网按可用区划分，私网子网不配公网 IP。跨 VPC 流量统一经网络账户的 Transit Gateway（TGW）中转，而不是两两对等。TGW 上挂路由表，按 OU 或环境做分段：生产、开发、共享服务各自一个路由域，默认互不可达，需要时再显式加路由。

集中出口：所有账户的 0.0.0.0/0 指向 TGW，由网络账户的 NAT Gateway 统一出公网，便于做流量审计与固定出口 IP。集中入口：ALB/NLB 放在网络账户或共享服务账户，后端指向各业务账户的私网目标。混合云场景下，DX 或 VPN 终结在网络账户，通过 TGW 传播到各 VPC。IP 规划要提前做，建议按账户分配 /16，子网按 /20 或 /24 切分，避免后期重叠导致无法对等。

四、安全基线与合规治理

安全基线要“默认开启、集中管理、持续检测”。Control Tower 会自动部署一组强制护栏，但企业通常还要补充：

CloudTrail：组织级跟踪，所有账户日志投递到日志归档账户的 S3，开启日志文件校验与 MFA Delete。
AWS Config：开启记录器，用托管规则检查“S3 是否公开”“EBS 是否加密”“安全组是否开放 22 端口”，不合规触发 SSM 自动修复。
GuardDuty：安全账户作为管理员，成员账户全部启用，发现结果汇入 Security Hub。
Security Hub：启用 AWS Foundational Security Best Practices 与 CIS 标准，作为合规总览面板。
IAM Access Analyzer：识别对外公开的 S3、IAM 角色与 KMS 密钥。

治理上，把“策略即代码”落到流水线：SCP、Config 规则、Control Tower 定制模板都进 Git，经 CodePipeline 部署。任何新账户通过 Account Factory 创建后，自动加入对应 OU、继承 SCP、接入日志与安全服务，实现“开箱即合规”。

落地顺序建议：先启用 Organizations 与 Control Tower → 建安全/日志/网络/共享服务账户 → 规划 IP 与 TGW 分段 → 接入 IAM Identity Center → 补齐 Config、GuardDuty、Security Hub 基线 → 最后批量迁移业务账户。顺序颠倒会导致后期返工。

常见误区：把业务负载放进管理账户；用长期 Access Key 做跨账户访问；VPC 网段随意分配导致与本地重叠；只开 CloudTrail 不集中归档；SCP 写成 Allow 而非 Deny。这些都会在审计或扩容时暴露为高风险问题。

Landing Zone 不是一次性交付物，而是随组织演进的活体架构。迁移期间每新增一个业务域，都应回到 OU、SCP、TGW 路由表和基线清单中确认是否需要扩展，而不是临时开一个“例外账户”。只有把账户、身份、网络、安全四条线同时纳入治理，迁移后的云环境才具备可审计、可扩展、可复制的长期能力。