📚 课程目录第2章 AWS平台工程的核心构建块

2. AWS平台工程的核心构建块

平台工程的目标不是把云服务堆在一起，而是把“账号治理、合规基线、自助交付、应用模板、基础设施即代码、持续交付”串成一条可复用的工具链。AWS在这条链路上提供了多个关键服务，它们各自解决不同层次的问题：Organizations负责组织与账号边界，Control Tower负责多账号治理与合规基线，Service Catalog负责受控产品目录，Proton负责面向开发者的应用交付抽象，CDK负责用编程语言定义基础设施，CodePipeline负责把变更自动推进到环境。理解它们之间的分工与衔接，比单独记住每个服务的功能更重要。

从治理底座到自助入口

AWS Organizations是整个平台的地基。它通过组织单元（OU）把账号分组，例如按“安全OU”“基础设施OU”“业务OU”“沙箱OU”划分，再通过服务控制策略（SCP）限制每个OU内账号的最大权限边界。SCP不是授权策略，而是权限上限：即使某个IAM角色拥有AdministratorAccess，只要SCP未允许某类操作，该操作仍会被拒绝。因此平台团队通常把“禁止关闭CloudTrail”“禁止使用未批准的Region”“禁止删除KMS密钥”等硬性约束放在SCP中，而不是依赖每个团队自觉遵守。

Control Tower在Organizations之上提供自动化治理。它通过Landing Zone把多账号环境初始化，自动创建日志归档账号、审计账号、安全工具账号，并部署Account Factory。Account Factory的价值在于：当业务团队申请一个新账号时，平台团队不需要手工创建账号、配置VPC、挂载日志桶、绑定SCP，而是通过一个受控模板完成。Control Tower还提供Guardrails，分为强制性和预防性两类：强制性Guardrail检测配置是否偏离，预防性Guardrail通过SCP直接阻止违规操作。这样，平台团队可以把合规要求前置到账号创建和变更入口，而不是事后审计。

Service Catalog与Proton：把“能做什么”变成“可申请什么”

Organizations和Control Tower解决了“边界”问题，但开发者仍然需要知道“我能申请什么、怎么申请”。Service Catalog就是受控产品目录。平台团队把经过审核的CloudFormation模板注册为产品，例如“标准VPC”“RDS MySQL实例”“ECS服务”“S3静态网站桶”，并绑定启动约束和模板约束。启动约束指定用哪个IAM角色去创建资源，模板约束则限制参数取值范围，比如只允许选择已批准的实例类型或子网。开发者登录Service Catalog后，看到的是产品列表，而不是几百个AWS服务。他们填写参数、提交申请，后台自动完成资源创建。这样既保留了自助速度，又确保资源符合平台标准。

Proton进一步把“应用交付”抽象成服务模板和环境模板。服务模板定义一类应用的标准形态，例如“基于Fargate的Web服务”，包含代码仓库、构建方式、部署目标、负载均衡、日志配置；环境模板定义一套环境，例如“开发环境”“预发环境”“生产环境”，包含VPC、集群、数据库、缓存等共享资源。开发者通过Proton选择服务模板和环境模板，填写少量参数，就能得到一条完整的CI/CD流水线和运行环境。Proton的价值在于把“应用”和“环境”解耦：应用团队只关心自己的服务，平台团队统一维护环境模板。当环境需要升级时，平台团队更新模板，所有使用该模板的服务可以按策略同步更新。

CDK与CodePipeline：从定义到交付的自动化链路

CDK是基础设施即代码的编程化实现。它允许用TypeScript、Python、Java等语言定义AWS资源，再合成CloudFormation模板。与直接写YAML相比，CDK的优势在于抽象和复用：平台团队可以编写L3 Construct，把“一个符合公司标准的Web服务”封装成一个类，内部包含ALB、ECS、Task Definition、IAM Role、CloudWatch Alarm、日志组等资源。业务团队只需实例化这个Construct并传入参数，例如：

const web = new CompanyWebService(this, 'OrdersApi', {
  cpu: 512,
  memory: 1024,
  desiredCount: 3,
  containerPort: 8080,
  healthCheckPath: '/health',
  environment: 'prod'
});

这段代码背后，CDK会生成对应的CloudFormation资源栈。平台团队可以在Construct内部强制启用删除保护、加密、日志保留、标签规范，业务团队无法绕过。这样，合规要求就从“文档规定”变成了“代码约束”。

CodePipeline负责把代码变更自动推进到环境。一个典型的流水线包含四个阶段：Source阶段从CodeCommit或GitHub拉取代码；Build阶段用CodeBuild执行单元测试、构建镜像、运行cdk synth生成模板；Test阶段部署到测试环境并运行集成测试；Deploy阶段通过CodeDeploy或CloudFormation部署到生产环境。平台团队可以在流水线中插入手动审批、变更集预览、回滚策略。例如，生产部署前先执行CloudFormation Change Set，人工确认变更内容后再执行，降低误删风险。

工具链的衔接关系与落地要点

这六个服务不是并列关系，而是有明确的层次和依赖。Organizations提供账号和组织结构，Control Tower在组织之上建立治理基线，Service Catalog和Proton提供自助入口，CDK提供基础设施定义能力，CodePipeline提供持续交付能力。实际落地时，平台团队通常按以下顺序推进：先建立Organizations和Control Tower，确保账号、日志、审计、SCP到位；再定义CDK Construct库，把常用架构模式封装成可复用组件；然后把CDK模板注册到Service Catalog，形成受控产品目录；接着用Proton封装应用和环境模板，降低开发者认知负担；最后用CodePipeline把代码提交到部署的路径自动化。

需要特别注意的是，SCP和Guardrails是“硬约束”，CDK和Service Catalog是“软约束”。硬约束防止最坏情况，软约束提升效率和一致性。两者缺一不可。如果只有硬约束，开发者会感到处处受限；如果只有软约束，违规资源仍可能被创建。平台工程的目标是让正确的事情容易做，让错误的事情难做，而不是单纯增加审批环节。

落地建议：先用Control Tower的Account Factory创建三个业务账号，分别对应开发、预发、生产；在CDK中编写一个基础Construct，统一设置标签、日志、加密和删除保护；将该Construct注册为Service Catalog产品，限制实例类型和子网范围；再用Proton创建服务模板，让开发者通过一条命令或一个页面完成服务初始化。

当这条工具链运转起来后，平台团队的角色从“手工开资源”转变为“维护模板和流水线”，业务团队从“等资源”转变为“自助申请”。这才是平台工程的核心价值：用标准化和自动化，把云的能力安全、快速地交付到开发者手中。