Amazon SAP-C02: 组织复杂性与多账户策略 — 学习指南
属于 AWS Solutions Architect Professional SAP-C02 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.
多账户策略与账户发放
多账户策略始于明确的职责分离：安全与审计、共享网络、生产工作负载以及沙箱或开发者账户。通过 AWS Organizations 结合 AWS Control Tower 或自定义登陆区，可以从第一天起就强制执行这种分离。Control Tower 的账户工厂 (Account Factory) 提供了一种账户发放模式，可自动创建账户、基线 IAM 角色、VPC 模板和护栏，而基于 CloudFormation/CDK 和 Service Catalog 构建的自定义登陆区则为定制网络和治理提供了更大的灵活性。主要的权衡在于运维开销与爆炸半径的减小：更多的账户会增加管理层面（自动化、跨账户角色、账单可见性），但能限制领域泄露的风险并简化单个账户的合规性。网络选择——使用 AWS Resource Access Manager 进行 VPC 共享、Transit Gateway 中心辐射型架构或使用 VPC 对等连接的隔离 VPC——决定了成本和延迟的权衡。共享服务（DNS、NAT、Active Directory）通常位于网络账户或共享服务账户中；账户发放过程应自动将新账户连接到这些共享资源或预置委托的 VPC。规划配额和自动化：集中化基线构件的管道，这样账户规模的扩大就不会增加手动工作的负担。
治理：SCP、Control Tower 护栏和组织策略
在多账户 AWS 环境中，治理依赖于组织层面的策略执行和委托的运行时控制。服务控制策略 (SCP) 为跨账户允许的操作设定了上限；它们功能强大但毫不留情——在根 OU 上的拒绝规则甚至会阻止管理员创建服务相关角色或使用未被明确允许的服务。Control Tower 提供预构建的护栏（强制性、强烈建议、可选），这些护栏实现了常见的 SCP 和 Config 规则，但对于高级服务模式可能存在限制。设计决策的核心在于集中式治理与委托式治理的选择：严格的根级别拒绝列表可以最大化合规性，但会增加产品团队和自动化的阻力；而带有权限边界和 IAM 角色控制的宽松基线则能加快开发者的速度。日志和审计策略（组织级 CloudTrail、AWS Config 聚合器、Security Hub 和 GuardDuty 的委托管理员）必须从管理账户强制执行，以确保审计日志的不可变性。一种务实的方法是分层治理：使用组织 SCP 进行高影响力的限制，使用权限边界来限定开发者范围，并通过登陆区的 CI/CD 应用自动化护栏，以在无需手动门禁的情况下保持一致性。
安全边界：跨账户角色、KMS 和资源策略
跨账户访问是一种核心模式，必须以最小权限和强信任控制的原则来实施。常见的模式是通过在每个账户中设置 IAM 角色来委托访问，受信任的主体通过 STS 代入这些角色：用于 CICD 部署、监控 (CloudWatch/SSM) 和第三方集成的角色应在适当情况下要求 MFA，并为合作伙伴访问使用外部 ID (external ID)。S3、SQS 和 KMS 密钥上的基于资源的策略能够实现直接的跨账户访问，但 KMS 增加了复杂性：KMS 密钥策略必须明确允许信任账户的主体和服务，并且可能需要授权 (grant) 或带约束的授权来实现临时访问。在日志或安全账户中使用集中的 KMS 密钥可以简化集中式加密，但会产生运维耦合和潜在的可用性问题；每个账户使用自己的密钥可以减小爆炸半径，但会增加密钥轮换和授权管理的复杂性。常见的陷阱包括 SCP 无意中拒绝了 KMS 或服务相关角色的创建、存储桶策略与 SCP 冲突，以及忘记在收集器账户中为 Config/CloudTrail 添加委托角色。设计决策应权衡管理的简便性、最小权限原则以及跨账户访问的延迟。
集中式日志、计费和自动化模式
集中式日志和计费是企业实现可见性的核心。通过将组织级 CloudTrail 的跟踪日志交付到集中的安全或审计账户中的 S3 存储桶，可以确保事件捕获的防篡改性；并辅以 CloudWatch Logs 订阅筛选器将日志传输到 Kinesis Data Firehose 进行分析，同时使用聚合器将 Config 数据聚合到同一个账户。成本可见性需要在 Organizations 中实现整合账单，并集中交付 Cost Explorer、Budgets 和 Cost and Usage Reports；通过 Config 规则实施标签治理和自动化标签强制执行，可以提高成本分摊的准确性。可跨账户扩展的自动化模式通常使用一个共享的 CI/CD 管道或部署账户，该账户会代入跨账户部署角色；或者使用带有委托管理员的 CloudFormation StackSets 来进行大规模预置。使用 Systems Manager Automation 和 State Manager 进行跨账户的补丁和配置管理，但请记住，每个账户都必须授予必要的角色和 SSM 权限。需要在集中化和延迟之间进行权衡：集中聚合减少了重复存储并简化了分析，但会产生网络和可用性依赖；分布式日志记录会复制数据，但能隔离故障。根据合规性要求，规划保留策略、生命周期规则、用于灾难恢复 (DR) 的跨区域复制以及加密密钥管理。
实践问题：用例场景
场景：Contoso Media 在一个已启用 Organizations 和 Control Tower 的企业级 AWS 环境中运营。他们拥有一个管理账户、一个共享服务网络账户，以及 20 个成员账户，这些账户在两个区域中运行着生产、预发布和开发工作负载。
挑战：Contoso 需要快速启用 15 个新的项目账户，同时确保实现集中式日志记录、设置适当的 SCP 防护策略、通过 Transit Gateway 自动连接到共享服务账户的网络，并建立无需为每个账户手动设置 IAM 的部署管道。
推荐方法：
- 使用 Control Tower Account Factory 或自动化的 AWS Organizations API 工作流，通过一个基线 CloudFormation/CDK 模板来创建账户。该模板会将账户注册到 AWS Config，启用指向审计账户 S3 存储桶的组织级 CloudTrail，并应用所需的标签。
- 在 OU 级别附加 SCP，以强制执行高影响力的拒绝策略（例如，拒绝跨区域密钥删除和禁止使用未经许可的区域），同时保持开发权限 OU 的限制性较低；在广泛应用前，先在沙箱中验证 SCP。
- 在共享服务网络账户中配置 Transit Gateway，并为每个新账户的 Transit Gateway VPC 连接创建附件。此过程通过基础设施即代码 (IaC) 以及账户创建流程所代入的委托管理员或跨账户角色来自动化附件创建和路由传播。
- 在工具账户中预置一个集中的 CI/CD 部署管道，该管道使用由账户创建流程创建的跨账户 IAM 角色 (assume-role)；使用 CloudFormation StackSets（委托管理员）或跨账户的 CodePipeline 操作来进行初始基线预置和持续更新。
基本原理：通过基线构件自动化账户创建过程，可以在最小化手动步骤的同时强制执行治理；通过跨账户角色和 Transit Gateway 委托网络和部署任务，可以集中化共享服务，减小爆炸半径，并在不牺牲安全性或可审计性的前提下扩展账户启用流程。
练习这些题目 → · 在 ExamRoll.io 上限时练习 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通过考试 →