Amazon SAP-C02: 部署、自动化与 DevOps — 学习指南
属于 AWS Solutions Architect Professional SAP-C02 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.
基础设施即代码与环境管理
将基础设施即代码 (IaC) 视为环境的单一事实来源，将网络、IAM 和应用程序拓扑嵌入到可重用、版本化的构件中。选择 CloudFormation 以实现严格的声明式控制和与 AWS 的深度集成，当更高级别的构造和语言原生抽象能提高开发者生产力时，则使用 AWS Cloud Development Kit (CDK)；始终强制 CI 将 CDK 合成为模板，并将构件存储在加密且版本化的 S3 存储桶中。使用 CloudFormation StackSets 实现一致的跨账户、跨区域堆栈实例化，并在漂移指示配置熵时，启用漂移检测并结合通过 Systems Manager 进行的自动化修复。使用 EC2 Image Builder 或 Packer 制作黄金镜像，并通过自动化管道将 AMI 发布到各账户和区域；这支持不可变部署并减少启动后的配置漂移。谨慎使用 CloudFormation 变更集、终止保护和更新策略，以避免可能导致数据丢失的意外资源替换。常见的陷阱包括在模板中嵌入密钥、依赖会破坏漂移检测的随意手动更改，或授予过于宽泛的 CloudFormation 执行角色——应将执行角色限制为最小权限，并保留 CloudTrail 和 Config 历史记录以实现可审计性。权衡很直接：CDK 加速开发，但需要规范的 CI/CD 来避免运行时堆栈不同步；纯 CloudFormation 更为刻板，但可立即审计。
CI/CD 管道和部署策略
设计将构建、测试和部署阶段分离的管道，并实现自动化回滚决策。AWS CodePipeline、CodeBuild 和 CodeDeploy 为从源码到生产的流程提供了完全托管的路径，而第三方系统（GitHub Actions、Jenkins、GitLab）可与 AWS 服务集成，用于构件存储 (S3)、容器镜像仓库 (ECR) 和部署挂钩。对于运行时策略，有状态或有会话的服务应首选不可变部署或蓝/绿部署，以消除原地配置漂移；使用带有流量切换的金丝雀部署以实现增量式风险降低。对于 Lambda，使用别名和加权流量切换，并结合 CloudWatch 警报或 CodeDeploy 实现自动回滚。对于 ECS/EKS，将部署控制器（CodeDeploy、AWS App Mesh 或原生 Kubernetes 策略）与 ALB 目标组耗尽和生命周期挂钩相结合，以确保优雅停机。注意数据库模式变更：设计向后兼容的迁移，并使用功能标志 (AWS AppConfig) 或灰度发布，将代码发布与模式演进解耦。成本与速度的考量很重要：金丝雀部署会减慢发布速度但能最小化爆炸半径，而并行的蓝/绿部署在切换窗口期间会使基础设施成本加倍。始终将部署策略、健康检查和自动回滚融入管道，以避免在事件期间进行人工干预。
自动化、配置合规性和可观测性
卓越运营依赖于自动化修复、一致的配置和整体可观测性。AWS Systems Manager 提供用于配置的 Parameter Store、用于运行手册的自动化文档、用于基线维护的 Patch Manager，以及用于无堡垒机故障排查的 Session Manager。使用 EventBridge 作为中央事件总线以实现解耦的自动化——将 CloudTrail、Config 或应用程序事件路由到 Lambda 或 Step Functions 以进行编排式修复。使用 AWS Config 规则和 Config 聚合器来强制执行护栏以审计多个账户，并通过 Systems Manager 或 EventBridge 为不合规的资源实施自动化修复手册。在可观测性方面，使用 CloudWatch 指标和日志对服务进行埋点，启用 X-Ray 或 AWS Distro for OpenTelemetry 进行分布式追踪，并通过 CloudWatch Logs 订阅或 Kinesis Firehose 将日志集中到统一的 S3 数据湖和分析堆栈中。常见的陷阱包括导致成本激增的无限制日志保留、导致指标成本爆炸的高基数自定义指标、使追踪无用的缺失关联 ID，以及未在非生产环境中测试修复运行手册。权衡主要围绕遥测粒度与采集和存储成本展开；采样追踪和短期保留可以降低成本，但可能会掩盖罕见的关键故障。设计针对可操作信号的警报和仪表板，以保持运营开销的可管理性。
性能、有状态服务、安全性与跨区域注意事项
根据访问模式、延迟需求和一致性要求来选择有状态服务和存储服务。内存缓存提供亚毫秒级读取；ElastiCache (Redis) 支持有序集合，非常适合排行榜场景，并提供复制、持久化和 Global Datastore 功能以实现跨区域读取本地性。DynamoDB 非常适合大规模、持久化的存储，并可与 DAX 配合以加速读取，但 DAX 最适合可缓存的项目级访问，且存在最终一致性的权衡。对于基于文件的遗留应用，可考虑使用 Amazon FSx for NetApp ONTAP 或 Amazon EFS 结合 DataSync 以实现“直接迁移”(lift-and-shift) 的兼容性；对于需要 SMB/NFS 语义的场景，FSx 通常是风险最低的选项。加密和复制存在一些微妙的陷阱：AWS KMS 密钥是区域性的，在进行跨区域 S3 复制时必须按区域进行管理，或者也可以使用多区域密钥来简化访问模式；请谨慎处理密钥策略和跨账户授权。VPC 中的 Lambda 会因创建 ENI 而遭受冷启动问题——可通过使用 VPC 端点、减小部署包大小、配置预置并发，或将 Lambda 置于 VPC 之外并配合 RDS Proxy 来缓解。权衡成本与弹性：全局表和跨区域复制能改善 RTO/RPO，但会增加成本；预置并发能降低延迟，但会增加基础开销。在选择架构时，应考虑数据持久性需求、灾难恢复 (DR) 时间线以及每个账户的资源限制。
实践问题：用例场景
场景：SkyForge Games 公司在两个区域运营着一个现有的 AWS 环境，其中包含生产账户和预发布账户。当前的排行榜在 DynamoDB 中实现，并由通过 CodePipeline 部署的 Lambda API 提供服务；玩家期望微秒级的读取延迟，以及在频繁的功能发布期间接近零的停机时间。
挑战：在实现排行榜微秒级读取的同时，保持数据持久性，并构建一个安全的、自动化的 CI/CD 管道，以支持跨账户和跨区域的、可回滚的快速部署。
推荐方法：
- 在主区域为排行榜的热路径预置一个启用集群模式 (Cluster Mode Enabled) 的 ElastiCache for Redis 集群，在多个可用区 (AZ) 中设置副本并启用 Redis 持久化 (AOF)；在次要区域配置 Global Datastore 以实现读取本地性。
- 保持 DynamoDB 作为“事实来源”(source of truth)；使用 DynamoDB Streams + Lambda (或 Kinesis Data Streams) 来异步更新 Redis，确保最终一致性以及用于恢复的可重放性。
- 实施一个基于 CDK 的管道 (CDK Pipelines 或由 Git 触发的 CodePipeline)，该管道可以合成模板，将构建产物存入加密的 S3/ECR，并通过 CloudFormation StackSets 将基础设施部署到目标账户/区域；管道中应包含自动化的冒烟测试和审批门禁。
- 使用金丝雀/蓝绿部署策略来部署应用变更：使用加权 Lambda 别名或 ALB 目标组切换，并配合 CloudWatch 警报和自动回滚；使用 CloudWatch、X-Ray 和综合性金丝雀检查来进行检测。
基本原理：使用 Redis 实现真正的亚毫秒级读取，同时保留 DynamoDB 的持久性和可重放性；结合 CDK 和 StackSets 的 CI/CD 提供了跨多账户的一致、可审计的部署，而流量切换加上可观测性则使得安全的迭代发布和快速回滚成为可能。
练习这些题目 → · 在 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.
通过考试 →