多团队多项目场景下新型复杂AWS Account Structure设计咨询

现有架构适配性评估 #

你当前设计的5账户架构方向完全符合AWS多团队协作的核心原则，是合理的基础方案：

• 优势：做到了账户级资源隔离、账单集中管理、SSO统一身份、各团队业务独立管控，完美匹配多独立团队开发、统一门户对外服务的场景
• 可优化点：缺少多环境隔离、共享服务未统一收拢，可进一步调整降低运维风险、提升协作效率

核心问题解答 #

1. 代码仓库选型 #

优先选择各团队在自有账户下维护独立代码仓库，理由如下：

• 权限边界清晰：不同团队只能访问自身业务代码，避免误改其他团队业务逻辑
• 迭代互不影响：各团队可自行控制发布节奏、分支规则，无需和其他团队对齐迭代周期
• 运维责任明确：代码故障可直接定位到对应团队，不会出现权责不清的问题
  仅公共依赖组件（如通用工具库、公共组件包）可单独维护统一的公共仓库，供所有团队按需引用。

2. 应用部署位置选择 #

优先选择各团队将应用部署到自有账户，由中央门户从对应账户调用资源，理由如下：

• 故障隔离：单个团队的应用故障、资源超配不会影响其他团队业务，也不会导致中央账户整体不可用
• 成本核算清晰：每个团队的资源消耗直接对应自有账户账单，无需拆分中央账户的公共成本
• 迭代效率更高：团队可自行配置CI/CD流水线、资源配额，无需向中央团队提交资源申请、发布审核

推荐优化后的AWS账户结构 #

基于AWS Organizations最佳实践，推荐按组织单元（OU）分层设计账户结构：

顶层根账户 #

仅用于组织管理、账单合并、全局服务控制策略（SCP）下发、全局配额调整，禁止部署任何业务资源，根账户访问权限需严格管控，日常运维不直接使用根账户。

共享服务OU #

存放所有团队共用的公共服务账户，避免重复建设：

• 身份管理账户：部署AWS IAM Identity Center（原SSO），对接企业统一身份源，实现所有账户、所有环境的身份统一认证、权限细粒度分配
• 安全审计账户：集中收集所有账户的CloudTrail操作日志、Config配置审计日志、GuardDuty安全告警，统一完成合规检测、安全巡检
• 公共资源账户：部署全局WAF、CDN、公共DNS解析、中央门户/Dashboard、公共ECR镜像仓库等跨团队共用资源

团队业务OU #

每个独立团队对应一个子OU，每个子OU下至少配置3个完全隔离的独立账户：

• 开发环境账户：供团队日常开发调试使用，可放开更多权限，允许快速试错
• 测试环境账户：用于功能测试、集成测试、UAT测试，配置和生产环境保持一致
• 生产环境账户：部署对外提供服务的正式业务资源，权限严格管控
  每个团队在自有账户下可独立管理CodeCommit代码仓库、CodePipeline流水线、业务部署资源，仅需遵守顶层下发的统一安全规则即可。

内容的提问来源于stack exchange，提问作者siliconchris