企业云治理概览
最后更新：2026 年 9 月 13 日
1. 本节要解决的问题
到目前为止，EKS、网络和安全文档都假设“一个集群、一个 VPC”，并在此基础上分别介绍各项功能。但在大型企业中，数十个团队和数百名工程师跨多个品牌、业务域和服务开展工作时，需要回答的问题就会变得不同。
- 应创建多少个 AWS 账户？
- 应共享 VPC，还是拆分 VPC？
- EKS 集群应按团队独享，还是由多个团队共享？
- 账户、VPC、EKS 这三层边界与数据边界是否必须一一对应？
本节讨论大型多账户、多 EKS 环境中的标准化决策。服务约束会根据链接的 AWS 文档进行核对；混合式设计、拆分标准和 PoC 阈值仍是需要组织内部验证的建议。本文不代表任何公司的私有审查结论，也不声称相关方案已在生产环境中取得成功。
2. 为什么应分别考虑账户、VPC、EKS 和数据边界
一种很常见的错误，是按团队或品牌创建账户，并自动为每个账户配套独立 VPC 和独立 EKS 集群，形成固定的一对一关系。这条规则虽然简单，但即使工作负载很小，也要承担整个集群的固定成本；每次组织调整还会变成基础设施迁移。
本节提出的替代做法是独立评估每一层边界。
| 边界 | 评估标准 |
|---|---|
| 账户 | 安全要求、服务配额、成本/归属、生命周期 |
| VPC | 网络策略、信任区、连通性要求 |
| EKS | 运行时故障影响范围、租户隔离要求、SLO |
| 数据 | 数据归属、法规边界、备份/恢复责任 |
这样便可以进行更细致的判断，例如“该工作负载不需要独立 VPC，但法规要求它使用专用账户”。这种方式也有成本：现在需要为每一层边界维护评估标准，而且例外情况可能越来越多。
3. 跨边界连接时应检查的服务约束
在独立决策时，仍必须考虑服务放置和授权约束。这些约束并不会自动规定唯一的组织结构。
- EKS 集群配置的子网必须属于同一个 VPC。两个独立集群可以使用同一个 VPC。是否使用独立 VPC，是对共享路由、DNS 和地址空间故障域作出的额外决策。
- Pod Identity 关联中的主 IAM 角色必须属于集群所在账户。目标角色功能采用“关联角色 → 目标角色”链式角色切换。其他方案包括针对 S3 等服务直接使用资源策略，以及通过 IRSA 直接联合到目标账户角色。并非每个跨账户请求都必须使用两个角色。
- 对于共享 VPC，应围绕创建集群的参与方账户设计 EKS 集群/节点 IAM 角色及相关安全组。这可能不同于拥有数据库或队列的工作负载账户。共享子网并不会转移资源所有权。
- 不同服务的数据边界并不相同。RDS 实例使用 VPC 子网；S3 存储桶不放置在子网中。共享 VPC 支持清单明确说明其中可能省略某些服务，因此仅凭清单未提及某服务，不能据此认定该服务不受支持（数据与安全边界）。
4. 优先共享与优先独立
决定独立评估各层边界后，下一个问题是：对于没有明确隔离理由的工作负载，应默认使用共享资源还是专用资源？
- 优先共享：先让小型工作负载使用共享账户/VPC/集群。开通更快、重复基础设施更少，但存在共享租户间资源争用带来的干扰，也可能逐渐积累无人负责的共享资源。
- 优先独立：当隔离需求不明确时，先评估专用边界。成本、所有权和故障影响范围更清楚，但固定成本会迅速增加。
实际可从优先共享的混合方案开始；确认存在法规要求、独立配额或强 SLO 需求后，再切换到专用资源。为了避免每次都重新争论这一判断，决策框架与 PoC 设计将在本节后续内容中介绍如何建立可复现的决策矩阵。
5. 稳定的工作负载 ID 与可变元数据
组织重组、品牌整合和团队更名仍会不断发生。如果账户或 VPC 边界直接绑定团队或品牌名称，每次重组都会演变为基础设施迁移。
建议为每个工作负载保留一个稳定的工作负载 ID，并将业务域、品牌、团队、CUJ（关键用户旅程）、环境、数据分类和 SLO 作为附加到该 ID 上的可变元数据来管理。重组时团队会变化，但业务域（业务能力）相对稳定，因此相较于团队，业务域更适合作为账户边界的依据。
6. 本节包含的内容
| 文档 | 内容 |
|---|---|
| Landing Zone、OU 与组织控制 | Control Tower 的基础依赖链、OU 设计、SCP/RCP/Tag Policy 的作用 |
| 账户结构与 IAM 边界 | 账户划分、人员身份与工作负载的 IAM、Kubernetes API 访问 |
| 多账户、多集群 EKS 架构 | 共享/专用集群、A/B EKS Runtime 冗余的实际条件 |
| 共享 VPC 与连接 | 共享 VPC 的实际配额瓶颈链，以及 TGW/PrivateLink/Lattice 的组合方式 |
| 数据与安全边界 | 跨账户备份/恢复约束、隔离 PII 数据层 |
| 决策框架与 PoC 设计 | 构建决策矩阵、容易忽略的决策因素、PoC 测量指标 |
每份文档都优先呈现经过验证的事实（“在什么条件下 AWS 服务确实会这样运行”），而非个人意见；仍需组织自行判断的部分也会明确标出。