2. AWS数据平台账号与网络规划
数据仓库不是一台孤立的数据库实例，而是一组需要长期运行、持续接入数据、被多个团队查询和治理的资源集合。如果一开始就把所有服务堆在同一个 AWS 账号、同一个 VPC、同一个大网段里，后面会遇到三个典型问题：权限边界模糊、网络爆炸半径过大、成本与配额无法按团队归集。因此本章的目标不是“把网络连通”，而是为数据仓库搭建一套可隔离、可审计、可扩展的基础环境。
一、多账号策略：先划边界，再谈连通
AWS 多账号的核心价值在于把“管理边界”和“故障边界”分开。对数据平台而言，推荐至少划分四类账号：管理账号（Organizations 根、SCP、账单）、共享服务账号（集中日志、镜像仓库、CI/CD 角色）、数据生产账号（Kinesis、DMS、Glue 抽取任务）、数据仓库账号（Redshift、Lake Formation、Athena、S3 数据湖）。如果存在多个业务域，可在数据生产账号下按业务再拆分子账号，但数据仓库账号通常保持集中，避免形成多个“小仓库”。
账号之间不靠 VPC Peering 全互联，而是通过 Transit Gateway 或 VPC 共享 建立受控连接。跨账号访问 S3、Glue Catalog、Redshift 时，优先使用 IAM Role + 资源策略，而不是长期 Access Key。一个常见的落地做法是：在数据仓库账号中创建 DataWarehouseReader、DataWarehouseETL、DataWarehouseAdmin 三个角色，生产账号通过 sts:AssumeRole 扮演对应角色，权限由 SCP 和 IAM Policy 双重约束。
redshift:CreateCluster，即使 IAM 允许也无法创建，从而保证仓库资源只出现在仓库账号。二、VPC 设计与子网划分：按“角色”而不是按“数量”切分
数据仓库 VPC 建议使用 10.20.0.0/16 这类独立私网段，避免与本地 IDC 或其他 VPC 冲突。子网划分不要平均切成几块，而应按“资源角色”划分，并预留足够增长空间。以下是一个可直接参考的示例规划（属于教学示例，实际需结合账号数量和 AZ 调整）：
| 子网名称 | CIDR | 可用区 | 承载资源 | 路由 |
|---|---|---|---|---|
| dw-private-a | 10.20.10.0/24 | ap-southeast-1a | Redshift 集群、Glue ENI | NAT GW |
| dw-private-b | 10.20.11.0/24 | ap-southeast-1b | Redshift 集群、Glue ENI | NAT GW |
| dw-endpoint-a | 10.20.20.0/24 | ap-southeast-1a | VPC Endpoint（S3、Glue、KMS） | 本地 |
| dw-endpoint-b | 10.20.21.0/24 | ap-southeast-1b | VPC Endpoint（S3、Glue、KMS） | 本地 |
| dw-public-a | 10.20.30.0/24 | ap-southeast-1a | NAT Gateway、堡垒机 | IGW |
关键点有三条。第一，Redshift 和 Glue 必须放在私有子网，且至少跨两个可用区，保证 AZ 故障时仍可访问。第二，S3、Glue、KMS、Secrets Manager 等高频服务应通过 Gateway Endpoint 或 Interface Endpoint 访问，避免数据流量绕行 NAT Gateway 产生额外费用和带宽瓶颈。第三，NAT Gateway 只放在一个公共子网即可，但生产环境建议每个 AZ 各放一个，避免单点。
三、安全组与网络 ACL：两层过滤，各司其职
安全组是有状态的实例级防火墙，网络 ACL 是无状态的子网级防火墙。数据仓库的典型配置是：安全组只放行必要端口，网络 ACL 作为兜底。以 Redshift 为例，集群端口默认 5439，只允许来自 Glue 安全组和 BI 查询安全组的入站流量；出站默认全放行，但可通过网络 ACL 限制到特定 CIDR。
# 示例：Redshift 安全组入站规则（教学示例）
Type Protocol Port Source
Redshift TCP 5439 sg-0glueetl（Glue 连接安全组）
Redshift TCP 5439 sg-0bi-query（BI 查询安全组）
SSH TCP 22 sg-0bastion（仅堡垒机，用于运维）
# 示例：网络 ACL 入站规则（无状态，需同时配置返回流量）
Rule 100 Allow TCP 5439 10.20.10.0/24
Rule 110 Allow TCP 5439 10.20.11.0/24
Rule 200 Allow TCP 1024-65535 10.20.0.0/16 # 返回流量
Rule * Deny All All 0.0.0.0/0这里最容易出错的是网络 ACL 的“无状态”特性：如果只放行入站 5439，却没有放行出站的高位端口，返回包会被丢弃，表现为连接超时。因此实际配置时，建议先保持网络 ACL 默认全放行，等安全组规则稳定后，再逐步收紧网络 ACL，并用 VPC Flow Logs 观察是否有拒绝记录。
四、把规划落到可执行的检查项
完成上述设计后，可以用一份简短的检查表确认基础环境是否就绪。以下字段可直接用于评审或交付前自检：
- 账号边界：数据仓库账号是否独立？SCP 是否禁止在非仓库账号创建 Redshift/Athena 工作组？
- 网段：VPC CIDR 是否与本地 IDC、其他 VPC 无重叠？是否预留至少一倍增长空间？
- 子网：Redshift 与 Glue 是否位于两个以上私有子网？是否配置了 S3 Gateway Endpoint？
- 路由：私有子网默认路由是否指向 NAT Gateway？公共子网是否只承载 NAT 与堡垒机？
- 安全组：5439 是否只对 Glue 与 BI 安全组开放？是否存在 0.0.0.0/0 的入站规则？
- 网络 ACL：是否放行了返回流量高位端口？是否已开启 VPC Flow Logs 并投递到共享日志账号？
- 跨账号：生产账号是否通过 AssumeRole 访问仓库？是否避免使用长期 Access Key？
这套规划的价值在于：当后续接入新的数据源、增加新的查询团队或迁移到多可用区时，不需要重新设计网络，只需在既有子网和安全组中增加规则或挂载点。数据仓库的基础环境一旦稳定，后续的建模、ETL 调度和权限治理才有可靠的落脚点。