Ch 6 环境与多账号隔离设计¶

面包屑

项目第 0 年 · 架构设计期——环境隔离设计

本章你将学到¶

dev/qa/prod 三环境模型的设计与发布路径
账号级隔离与 region 隔离的策略
Landing Zone 模式 vs 单账号多环境的架构对比

6.1 dev/qa/prod 三环境模型与发布路径¶

三环境模型¶

代码从开发到生产，经过三个独立环境，每个环境的部署方式和数据策略各有不同：

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#edf5ff','primaryTextColor':'#161616','primaryBorderColor':'#0f62fe','lineColor':'#697077','secondaryColor':'#d9fbfb','tertiaryColor':'#f2f4f8','fontSize':'14px'}}}%%
flowchart TD
    CODE["<b>代码提交</b><br/>Feature 分支合并到 dev"]:::bpData
    CODE -->|"自动部署 · 开发者自由实验"| DEV["<b>DEV 开发环境</b><br/>脱敏样本数据<br/><i>频繁迭代 · 架构实验</i>"]:::bpProcess
    DEV -->|"手动触发 · 打 Tag 部署"| QA["<b>QA 测试环境</b><br/>类生产脱敏数据<br/><i>业务验收 · 集成测试</i>"]:::bpDecision
    QA -->|"审批后部署 · 仅运维可操作"| PROD["<b>PROD 生产环境</b><br/>真实业务数据<br/><i>正式运行 · 合规审计</i>"]:::bpSuccess

    classDef bpProcess  fill:#edf5ff,stroke:#0f62fe,stroke-width:2px,color:#161616
    classDef bpData     fill:#d9fbfb,stroke:#007d79,stroke-width:2px,color:#161616
    classDef bpDecision fill:#fcf4d6,stroke:#f1c21b,stroke-width:2px,color:#161616
    classDef bpSuccess  fill:#defbe6,stroke:#198038,stroke-width:2px,color:#161616

    linkStyle 0 stroke:#0f62fe,stroke-width:2px
    linkStyle 1 stroke:#f1c21b,stroke-width:2px
    linkStyle 2 stroke:#198038,stroke-width:2.5px

图 6-1 三环境模型

环境	用途	数据	谁能操作	部署方式
DEV	开发调试、架构实验	脱敏样本数据	开发者	feature 分支合并后自动部署
QA	业务验收、集成测试	类生产数据（脱敏）	QA + 开发	打 tag 手动触发
PROD	正式业务运行	真实生产数据	仅运维（审批）	tag + 审批后部署

表 6-1 三环境模型

三环境是数据平台的"标配"，但"标配"不是我选它的理由——企业征信的教训才是。当时那个项目只有两环境（dev+prod），没有独立的 QA。有一次开发在 dev 验证通过后直接发 prod，结果 prod 的数据量是 dev 的 50 倍，一个在 dev 跑 3 分钟的 ETL 在 prod 跑了 3 小时还没完，超时失败，阻塞了下游所有报表。那次事故让我意识到：dev 和 prod 的差异不只是"代码对不对"，还有"数据量级对不对"——没有 QA 做类生产量的性能验证，性能问题只能等 prod 爆了才发现。到 Aurora 我坚持要三环境，QA 的数据量故意做成"类生产"（脱敏后的真实规模），专门抓性能问题。这个决策第二年救过我们好几次——有些 ETL 在 dev（样本数据）跑得挺好的，到 QA（类生产量）才暴露倾斜和超时。

三环境的另一个设计点是"谁能操作"的权限阶梯：DEV 开发者自由、QA 开发+QA 协同、PROD 仅运维审批。这个阶梯不是官僚主义，是爆炸半径控制——DEV 炸了重建就行，PROD 炸了是生产事故。企业征信时我见过反例：开发者有 prod 写权限，"为了快速修个 bug"直接改了 prod 的 ETL，结果改错了，整条流水线停摆半天。从那以后我把"prod 权限收给运维"列为铁律——便捷和安全，在 prod 环境必须倒向安全。

发布路径¶

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#edf5ff','primaryTextColor':'#161616','primaryBorderColor':'#0f62fe','lineColor':'#697077','secondaryColor':'#d9fbfb','tertiaryColor':'#f2f4f8','fontSize':'14px'}}}%%
flowchart TD
    FB["<b>Feature Branch</b><br/>功能开发"]:::bpProcess
    FB -->|"PR + 代码审查<br/>合并到 dev"| DEV_DEPLOY["<b>DEV 环境</b><br/>开发者自由实验<br/><i>自动部署</i>"]:::bpProcess
    DEV_DEPLOY -->|"验证通过<br/>打 Tag 手动触发"| QA_DEPLOY["<b>QA 环境</b><br/>业务验收测试<br/><i>手动部署</i>"]:::bpDecision
    QA_DEPLOY -->|"UAT 验收通过"| APPROVE{"<b>生产审批</b><br/>仅运维可操作"}:::bpInfo
    APPROVE -->|"审批通过<br/>Tag 部署"| PROD_DEPLOY["<b>PROD 环境</b><br/>正式业务运行<br/><i>审批后部署</i>"]:::bpSuccess
    APPROVE -->|"驳回"| REJECT["<b>打回修正</b>"]:::bpError

classDef bpProcess  fill:#edf5ff,stroke:#0f62fe,stroke-width:2px,color:#161616
classDef bpDecision fill:#fcf4d6,stroke:#f1c21b,stroke-width:2px,color:#161616
classDef bpSuccess  fill:#defbe6,stroke:#198038,stroke-width:2px,color:#161616
classDef bpError    fill:#fff1f1,stroke:#da1e28,stroke-width:2px,color:#161616
classDef bpInfo     fill:#f6f2ff,stroke:#8a3ffc,stroke-width:2px,color:#161616

linkStyle 0 stroke:#0f62fe,stroke-width:2px
linkStyle 1 stroke:#f1c21b,stroke-width:2px
linkStyle 2 stroke:#f1c21b,stroke-width:2px
linkStyle 3 stroke:#198038,stroke-width:2.5px
linkStyle 4 stroke:#da1e28,stroke-width:2px

图 6-2 发布路径

这条发布路径适用于所有四类发布物： Terraform 资源、Glue 脚本、Lambda 代码、DynamoDB 配置（详见 Ch 28）。

这条路径里有一个我刻意设计的"减速带"——QA 到 PROD 之间的审批节点。一开始有人提议"QA 验收通过就自动发 PROD"，理由是加快交付。我反对了——QA 验的是"功能对不对"，但 PROD 部署还要确认"这个时间点发安不安全"（月底结账高峰期不该发变更）。审批节点不是为了卡，是为了让最后一个清醒的人看一眼——确认时机、回滚预案、无冲突变更。这个减速带第一年就救过一次：QA 通过了一个 ETL 变更，审批时运维发现它会和另一个正在进行的迁移冲突，推迟了一周，避免了 prod 双重变更互踩。

Trade-off

三环境是数据平台的"标配"，但环境的维护成本不低——每多一个环境，就多一份基础设施、多一份数据同步、多一份配置管理。有些团队用"两环境（dev+prod）"来降低成本，代价是测试覆盖不足，生产事故风险升高。对于医药这种强合规行业，三环境是底线——我在企业征信用两环境交过的学费（prod 性能爆炸），在 Aurora 用三环境的 QA 提前拦住了。环境的成本是钱，事故的成本是信誉+合规罚款——医药行业这笔账算得很清楚。

6.2 账号级隔离与 region 隔离（AWS China）¶

账号级隔离¶

每个环境使用独立的 AWS 账号，实现物理级隔离：

C4Deployment
    title AWS 三账号环境隔离 — Deployment Diagram

    Deployment_Node(dev, "DEV 开发账号", "AWS Account 123456789012", "开发者自由实验环境，数据为脱敏样本，feature 分支合并后自动部署"){
        ContainerDb(dev_s3, "S3 数据湖三层桶", "S3", "dev- 前缀 Landing/Raw/Enriched 桶，生命周期 30 天")
        ContainerDb(dev_rs, "Redshift 小规格集群", "Redshift ra3.xlplus", "单节点 DEV 专用，数据为脱敏样本")
        ContainerDb(dev_ddb, "DynamoDB 配置表", "DynamoDB", "dev- 前缀任务配置与状态表，按需容量")
        Container(dev_glue, "Glue ETL Jobs", "Glue 2.0/3.0", "DEV 环境 ETL 作业，开发端点用于调试")
        Container(dev_sf, "Step Functions 状态机", "SF Standard", "DEV 环境状态机，Express 类型用于快速迭代")
    }

    Deployment_Node(qa, "QA 测试账号", "AWS Account 210987654321", "业务验收测试环境，类生产脱敏数据，打 tag 手动触发部署"){
        ContainerDb(qa_s3, "S3 数据湖三层桶", "S3", "qa- 前缀桶，生命周期 90 天，数据量与生产接近")
        ContainerDb(qa_rs, "Redshift 中规格集群", "Redshift ra3.4xlarge", "2-4 节点 QA 专用，类生产数据量用于性能验收")
        ContainerDb(qa_ddb, "DynamoDB 配置表", "DynamoDB", "qa- 前缀任务配置与状态表")
        Container(qa_glue, "Glue ETL Jobs", "Glue 3.0", "QA 环境 ETL 作业，运行全量管道进行集成测试")
        Container(qa_sf, "Step Functions 状态机", "SF Standard", "QA 环境状态机，验证完整工作流")
    }

    Deployment_Node(prod, "PROD 生产账号", "AWS Account 345678901234", "正式生产环境，真实业务数据，审批后部署，含完整安全加固"){
        ContainerDb(prod_s3, "S3 数据湖三层桶", "S3", "prod- 前缀桶（SSE-KMS 加密 + 版本控制 + 跨区域复制 + 永久保留）")
        ContainerDb(prod_rs, "Redshift 生产集群", "Redshift ra3.4xlarge 24节点", "生产级集群，多 AZ 部署，快照策略每日+每小时，Serverless 128-256 RPU 备选")
        ContainerDb(prod_ddb, "DynamoDB 配置表", "DynamoDB", "prod- 前缀表（PITR 备份 + 自动伸缩 + 加密）")
        Container(prod_glue, "Glue ETL Jobs", "Glue 3.0", "PROD 环境 ETL 作业，DPU 自动调优，含完整的 DLQ 和重试策略")
        Container(prod_sf, "Step Functions 状态机", "SF Standard", "PROD 环境状态机，含 X-Ray 全链路追踪和 CloudWatch 告警")
    }

    Rel(dev_sf, dev_glue, "触发 DEV ETL 管道", "Step Functions → Glue API")
    Rel(qa_sf, qa_glue, "触发 QA ETL 管道", "Step Functions → Glue API")
    Rel(prod_sf, prod_glue, "触发 PROD ETL 管道", "Step Functions → Glue API")

    UpdateElementStyle(dev_s3, $bgColor="#d9fbfb", $fontColor="#161616", $borderColor="#007d79")
    UpdateElementStyle(dev_rs, $bgColor="#d9fbfb", $fontColor="#161616", $borderColor="#007d79")
    UpdateElementStyle(dev_ddb, $bgColor="#d9fbfb", $fontColor="#161616", $borderColor="#007d79")
    UpdateElementStyle(dev_glue, $bgColor="#edf5ff", $fontColor="#161616", $borderColor="#0f62fe")
    UpdateElementStyle(dev_sf, $bgColor="#edf5ff", $fontColor="#161616", $borderColor="#0f62fe")
    UpdateElementStyle(qa_s3, $bgColor="#d9fbfb", $fontColor="#161616", $borderColor="#007d79")
    UpdateElementStyle(qa_rs, $bgColor="#d9fbfb", $fontColor="#161616", $borderColor="#007d79")
    UpdateElementStyle(qa_ddb, $bgColor="#d9fbfb", $fontColor="#161616", $borderColor="#007d79")
    UpdateElementStyle(qa_glue, $bgColor="#edf5ff", $fontColor="#161616", $borderColor="#0f62fe")
    UpdateElementStyle(qa_sf, $bgColor="#edf5ff", $fontColor="#161616", $borderColor="#0f62fe")
    UpdateElementStyle(prod_s3, $bgColor="#d9fbfb", $fontColor="#161616", $borderColor="#007d79")
    UpdateElementStyle(prod_rs, $bgColor="#d9fbfb", $fontColor="#161616", $borderColor="#007d79")
    UpdateElementStyle(prod_ddb, $bgColor="#d9fbfb", $fontColor="#161616", $borderColor="#007d79")
    UpdateElementStyle(prod_glue, $bgColor="#edf5ff", $fontColor="#161616", $borderColor="#0f62fe")
    UpdateElementStyle(prod_sf, $bgColor="#edf5ff", $fontColor="#161616", $borderColor="#0f62fe")

    UpdateRelStyle(dev_sf, dev_glue, $textColor="#0f62fe", $lineColor="#0f62fe")
    UpdateRelStyle(qa_sf, qa_glue, $textColor="#0f62fe", $lineColor="#0f62fe")
    UpdateRelStyle(prod_sf, prod_glue, $textColor="#0f62fe", $lineColor="#0f62fe")

    UpdateLayoutConfig($c4ShapeInRow="5", $c4BoundaryInRow="3")

图 6-3 账号级隔离

账号级隔离的好处：

好处	说明
爆炸半径控制	DEV 里的误操作不会影响 PROD
权限天然隔离	开发者只有 DEV 账号权限，无法触碰 PROD
计费独立	各环境成本可独立核算
合规审计	PROD 账号的 CloudTrail 独立审计

表 6-2 账号级隔离

选账号级隔离而非 VPC/前缀隔离，是我和 Aurora 安全部门讨论后定的。安全部门诉求很直接："PROD 数据如果和 DEV 在同一个账号，开发者一次 IAM 误配就可能读到生产患者数据——这在 PIPL 下是重大合规事件。"账号级隔离从物理上杜绝这种可能：DEV 账号的 IAM 策略配得再错，也碰不到 PROD 账号的资源——因为它们是不同的 AWS 账号，权限完全独立。这种物理隔离的强度 VPC/前缀隔离做不到——后者只是逻辑隔离，一个 * 通配符就能穿透。

表里"爆炸半径控制"这一行是我在企业征信踩过的。当时用单账号多环境（前缀隔离），一个开发者在 DEV 里写 Terraform 时把 resource "aws_s3_bucket" 的前缀变量写错了——dev- 写成了 prod-，plan 时没仔细看，apply 直接把 PROD 桶配置覆盖了。那次事故花了两天恢复，让我对"前缀隔离"彻底不信了。到 Aurora 我坚持三账号——前缀是人写的，人会犯错；账号是物理边界，穿不透。代价是运维变复杂（管三个账号比管一个累），但和"一次误配炸 prod"的风险比，值。

Region 隔离¶

平台部署在 AWS China（cn-north-1），这是由光环新网/西云数据运营的独立区域，与全球 AWS 物理隔离，满足中国数据驻留要求。

Region 选择看似简单（中国区业务用中国 Region），但实际影响很深。项目第一周我做了决策矩阵：cn-north-1（北京）vs cn-northwest-1（宁夏）。北京延迟低（Aurora 总部在北京），但资源紧、价格略高；宁夏资源充裕、价格低，但到北京多 20-30ms。最后选北京作主区——因为数据平台的消费者（分析师、业务用户）大多在北京，查询对延迟敏感；ETL 是批量任务，对延迟不敏感。第二年用户涨到 300+ 时验证了这个判断——如果选宁夏，每个 BI 查询多 20ms，高峰期会堆成可感知的卡顿。

Region 隔离还有一个容易被忽视的约束：服务可用性子集。AWS China 的服务比 Global 滞后 6-18 个月，有些 AI 服务可能根本没有。这个约束前两年影响不大（S3/Redshift/Glue 都有），到第四年 Agentic BI 阶段成了大问题——Bedrock 的模型可用性得持续确认。选 Region 不光是选位置，更是选"服务可用性子集"——这个教训让我养成了"先查服务可用性再画架构图"的习惯。

引申

AWS China 不是 AWS Global 的"镜像"，而是一个独立的云——服务子集更小、账号体系独立、需要中国 ICP 备案。选择 AWS China 意味着某些全球区有的服务（如某些 AI 服务）可能不可用，需要在架构设计时提前确认服务可用性。我的做法是：每个新架构方案在画图前，先跑一遍 aws service-quotas 和 AWS China 服务列表对照——避免"画完图发现某个服务用不了"的尴尬。

6.3 引申：Landing Zone 模式 vs 单账号多环境¶

两种多环境架构对比¶

C4Deployment
    title 多账号 Landing Zone vs 单账号多环境 — Deployment Comparison

    Deployment_Node(org_a, "方案 A: 多账号 Landing Zone", "AWS Organizations + Control Tower", "物理级隔离：每个环境独立 AWS 账号。含 Organizations 层级、SCP 策略、集中审计日志——本书方案") {
        ContainerDb(a_dev_s3, "S3 数据湖 (DEV)", "S3", "dev- 前缀 Landing/Raw/Enriched 桶")
        Container(a_dev_rs, "Redshift (DEV)", "Redshift", "DEV 小规格集群——脱敏样本")
        ContainerDb(a_qa_s3, "S3 数据湖 (QA)", "S3", "qa- 前缀桶——类生产数据量")
        Container(a_qa_rs, "Redshift (QA)", "Redshift", "QA 中规格集群——性能验收")
        ContainerDb(a_prod_s3, "S3 数据湖 (PROD)", "S3", "prod- 前缀桶——SSE-KMS 加密+版本控制+永久保留")
        Container(a_prod_rs, "Redshift (PROD)", "Redshift", "PROD 24 节点 ra3.4xlarge 集群")
        Container(a_audit, "Audit 日志归档", "CloudTrail+S3", "跨账号集中审计日志——不可篡改")
        Container(a_shared, "Shared Services", "ECR+Secrets", "CI/CD Runner、镜像仓库、共享凭证")
    }

    Deployment_Node(single_b, "方案 B: 单账号多环境", "AWS Account", "逻辑隔离方案：VPC + 资源前缀区分环境。管理简单但爆炸半径大——适合小型团队/POC") {
        ContainerDb(b_dev_s3, "S3 数据湖 (DEV)", "S3", "dev- 前缀——同账号内命名隔离")
        ContainerDb(b_qa_s3, "S3 数据湖 (QA)", "S3", "qa- 前缀——同账号内命名隔离")
        ContainerDb(b_prod_s3, "S3 数据湖 (PROD)", "S3", "prod- 前缀——同账号内命名隔离")
    }

    UpdateElementStyle(a_dev_s3, $bgColor="#d9fbfb", $fontColor="#161616", $borderColor="#007d79")
    UpdateElementStyle(a_dev_rs, $bgColor="#edf5ff", $fontColor="#161616", $borderColor="#0f62fe")
    UpdateElementStyle(a_qa_s3, $bgColor="#d9fbfb", $fontColor="#161616", $borderColor="#007d79")
    UpdateElementStyle(a_qa_rs, $bgColor="#edf5ff", $fontColor="#161616", $borderColor="#0f62fe")
    UpdateElementStyle(a_prod_s3, $bgColor="#d9fbfb", $fontColor="#161616", $borderColor="#007d79")
    UpdateElementStyle(a_prod_rs, $bgColor="#edf5ff", $fontColor="#161616", $borderColor="#0f62fe")
    UpdateElementStyle(a_audit, $bgColor="#f6f2ff", $fontColor="#161616", $borderColor="#8a3ffc")
    UpdateElementStyle(a_shared, $bgColor="#f6f2ff", $fontColor="#161616", $borderColor="#8a3ffc")
    UpdateElementStyle(b_dev_s3, $bgColor="#f2f4f8", $fontColor="#161616", $borderColor="#697077")
    UpdateElementStyle(b_qa_s3, $bgColor="#f2f4f8", $fontColor="#161616", $borderColor="#697077")
    UpdateElementStyle(b_prod_s3, $bgColor="#f2f4f8", $fontColor="#161616", $borderColor="#697077")

    UpdateLayoutConfig($c4ShapeInRow="4", $c4BoundaryInRow="2")

图 6-4 两种多环境架构对比

维度	多账号 Landing Zone（方案 A）	单账号多环境（方案 B）
隔离强度	物理级（账号隔离）	逻辑级（VPC/命名前缀）
爆炸半径	最小	较大（一个 IAM 误配可能影响多环境）
运维复杂度	高（多账号管理）	低（一个账号管所有）
成本	略高（每账号有基线开销）	低
合规	强（审计独立）	弱
适合规模	中大型企业	小型团队/POC

表 6-3 两种多环境架构对比

方案 A（多账号 Landing Zone）和 B（单账号多环境）的选择，本质上是在"隔离强度"和"运维复杂度"之间做权衡。我选 A 有两个驱动力：一是医药合规（PIPL/GxP 要求 PROD 物理隔离），二是企业征信的前车之鉴（前缀隔离被一次 Terraform 误配穿透）。如果 Aurora 是小团队、数据量小、合规不极端，我会选 B——运维省事得多，一个账号管全部，不用跨账号配 role、同步配置。

但选 A 有一个我第一年低估的隐性成本——跨账号协作的摩擦。DEV 调试时读 PROD 样本数据做脱敏要跨账号 role 假设；CI/CD 部署到三个账号要三套 OIDC 凭证。这些"跨账号"配置第一天看起来"多写几行 Terraform"，长期维护成本不低。我的建议：选 A 就尽早把跨账号配置自动化——我们在 Ch 29 里专门解决了这个问题。别让跨账号摩擦变成"每次都手动配凭证"的痛。

AWS Control Tower¶

如果使用 AWS 的 Control Tower，可以自动化创建和管理 Landing Zone：

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#edf5ff','primaryTextColor':'#161616','primaryBorderColor':'#0f62fe','lineColor':'#697077','secondaryColor':'#d9fbfb','tertiaryColor':'#f2f4f8','fontSize':'14px'}}}%%
flowchart LR
    CT@{ icon: "logos:aws", form: "rounded", label: "AWS Control Tower", pos: "b", h: 44 } -->|自动| ORG@{ icon: "codicon:organization", form: "rounded", label: "Organizations 账号结构", pos: "b", h: 40 }
    CT -->|自动| GUARD@{ icon: "codicon:shield", form: "rounded", label: "Guardrails 合规护栏", pos: "b", h: 40 }
    CT -->|自动| ACCOUNT@{ icon: "codicon:package", form: "rounded", label: "账号工厂<br/>标准化创建新账号", pos: "b", h: 40 }
    CT -->|自动| AUDIT@{ icon: "codicon:history", form: "rounded", label: "审计日志集中归档", pos: "b", h: 40 }
classDef bpProcess  fill:#edf5ff,stroke:#0f62fe,stroke-width:2px,color:#161616
classDef bpInfo     fill:#f6f2ff,stroke:#8a3ffc,stroke-width:2px,color:#161616

class CT bpProcess
class ORG,GUARD,ACCOUNT,AUDIT bpInfo
linkStyle default stroke:#697077,stroke-width:2px

图 6-5 AWS Control Tower

关于 Control Tower，我要诚实交代一个项目的遗憾：Aurora 最初没有用 Control Tower，而是手工创建了三个账号。原因有二：一是项目启动时 Control Tower 在 AWS China 的支持还不完善；二是当时只有三个账号，觉得"手工创建就够了"。这个决策在前两年没问题，但到第二年后期账号开始增多（加了日志归档账号、共享服务账号、灾难恢复账号），手工管理的弊端就暴露了——每个新账号要手动配 SCP、手动接审计日志、手动设 IAM 基线，既慢又容易漏。

如果重来，我会在第一天就上 Control Tower——哪怕只有三个账号。因为 Control Tower 的价值不只是"自动创建账号"，更是"标准化账号基线"——Guardrails 护栏会强制每个账号满足合规要求（如"必须开 CloudTrail"、"禁止创建公开 S3 桶"），不用靠人记。自动化的价值在规模小时不明显，在规模大时是救命的——这条规律在账号管理上同样适用。到第三年我们补上了 Control Tower，但补的过程比"从第一天就用"痛苦得多——因为要给已有账号"补课"配 Guardrails，而那些账号已经跑着生产业务，改配置有风险。