用 AWS Service Catalog 实现 IT 治理 - 已批准产品的标准化与自助服务
将 IT 部门批准的 CloudFormation 模板编入目录，通过启动约束和模板约束安全地为终端用户提供自助服务。
Service Catalog 的角色
Service Catalog 是将 IT 部门批准的 AWS 资源配置作为最多 5,000 个产品的目录管理，让终端用户以自助方式配置的服务。如果终端用户自由创建 AWS 资源，会出现安全设置不当、成本管理困难、架构不统一等问题。Service Catalog 中，IT 部门将 CloudFormation 模板注册为产品，仅向终端用户提供已批准的配置。终端用户只需从目录选择产品并输入参数，即可配置标准化的资源。Terraform 模板也可注册为产品，能够活用现有的 IaC 资产。
组合与约束的设计
组合 (Portfolio) 是产品的集合，向 IAM 主体 (用户、组、角色) 授予访问权限。可设计如开发团队组合包含开发环境的 EC2 和 RDS，数据团队组合包含 Redshift 和 Glue。启动约束指定产品配置时使用的 IAM 角色，资源以约束指定的角色权限而非终端用户自身的 IAM 权限创建。这样无需给终端用户 CloudFormation 直接执行权限，仅允许通过目录创建资源。模板约束可限制 CloudFormation 参数的允许值，如将实例类型限制为仅 t3.micro 和 t3.small。设置 TagOptions 可在配置时强制附加成本分配标签和所有权标签，从而预防因标签遗漏导致的成本追踪困难。
多账户环境的活用
与 Organizations 集成，可将管理账户创建的组合共享给组织内所有账户或特定 OU。共享组合的产品可供各账户终端用户使用，在整个组织应用统一的架构模式。产品版本管理可分阶段推出模板更新。发布新版本后，已配置的产品不会自动更新，终端用户需明确执行版本升级。这可防止更新带来的意外影响。与 Control Tower 配合使用时，可自动保证 Service Catalog 的产品符合 Landing Zone 的防护栏。 要研究 Service Catalog 的运维设计，可参考相关书籍 (Amazon)。
设计最佳实践与陷阱
Service Catalog 设计中最重要的是产品粒度。将 EC2 + RDS + VPC 全部包含在 1 个产品中会降低灵活性，对只需要 EC2 的用户也会创建不必要的资源。反之，粒度过细会增加用户按正确顺序配置多个产品的负担。推荐的模式是将网络基础设施 (VPC、子网) 作为 1 个产品、计算 (EC2 + ALB) 作为 1 个产品、数据库 (RDS) 作为 1 个产品分离，通过 CloudFormation 跨栈引用连接。启动约束的 IAM 角色应按产品以最小权限创建，避免在所有产品中复用统一的管理员角色。使用共用角色意味着 1 个产品的漏洞可能波及所有资源的访问。此外，配置委托管理员账户进行组合共享可避免权限集中在管理账户。
Service Catalog 的费用与限制
Service Catalog 本身不产生额外费用。成本仅为配置的 AWS 资源 (EC2、RDS 等) 的使用费。但使用 AWS CloudFormation 的第三方资源类型时，按处理程序操作计费。通过 Organizations 共享组合也无额外费用，作为组织整体的治理基础设施导入成本低是其魅力。通过模板约束限制实例类型，也能抑制终端用户误创建高价资源的风险。限制方面，每个区域默认配额为 100 个组合，每个组合 150 个产品。大型组织可能需要申请配额提升。此外，已配置产品的更新作为 CloudFormation 堆栈更新执行，需注意变更集的兼容性。
与相关服务的比较
与 Service Catalog 目的相似的服务包括 AWS Proton 和 Control Tower。Proton 面向平台工程，通过环境模板和服务模板的双层结构实现微服务标准化。Service Catalog 适合通用资源的自助服务，而 Proton 专注于容器/无服务器应用部署管道。Control Tower 侧重于组织级账户治理 (防护栏、日志聚合、账户发放)，Service Catalog 侧重于单个资源配置的标准化。实际运维中，通常用 Control Tower 搭建账户基础，用 Service Catalog 标准化账户内的资源提供。
总结
Service Catalog 是兼顾 IT 治理和终端用户自助服务的服务。将已批准的架构模式编入目录，通过启动约束和模板约束强制安全配置。与 Organizations 集成可实现多账户环境的标准化，结合 Control Tower 可构建整个组织一致的治理体系。