手册

在不使用自定义脚本的情况下，为失败的 ECS Fargate 部署实现自动回滚。

→在 ECS 服务上启用带回滚功能的 ECS 部署熔断器。

原因: ECS 原生功能，如果新任务未能稳定运行，则会自动回滚。与自定义 CodeBuild 轮询或复杂的 CodeDeploy 设置相比，操作开销最小。

参考↗

部署到主区域，通过自动化测试进行验证，然后并行部署到其他区域。

→使用一个包含顺序阶段的 CodePipeline：（1）部署区域 A，（2）运行验证的 CodeBuild 测试阶段，（3）并行部署区域 B 和 C 的阶段。

原因: CodeBuild 作为自动化、程序化的关口。与使用 Step Functions 编排多个管道相比，单个管道更简单。

CodeDeploy 生命周期挂钩中长时间运行的验证脚本导致过早部署成功。

→在 `AppSpec.yml` 文件中，增加特定生命周期挂钩脚本的 `timeout` 属性。

原因: 超时在 AppSpec 文件中按挂钩配置，而不是在部署组级别配置。这确保了验证脚本有足够的时间完成。

加速由于每次运行都重新下载依赖项和镜像层而导致缓慢的 CodeBuild Docker 镜像构建。

→在 CodeBuild 项目配置中，启用 `LOCAL_DOCKER_LAYER_CACHE` 并为依赖项目录（例如 `.m2`、`node_modules`）配置 S3 缓存。

原因: 直接解决这两个导致速度缓慢的根源。Docker 层缓存重用未更改的镜像层；S3 缓存重用已下载的应用程序依赖项。

为 Lambda 函数实现金丝雀部署，并进行自动化、基于指标的回滚。

→使用带有 `DeploymentPreference`（例如，类型 `Canary10Percent5Minutes`）的 AWS SAM。添加一个基于 `Errors` 指标的 CloudWatch 告警作为回滚触发器。

原因: SAM 原生集成 CodeDeploy for Lambda，无需自定义脚本即可自动化别名流量切换、监控和回滚。

参考↗

配置账户 A 中的 CodePipeline 的 IAM，以将资源部署到账户 B。

→管道角色（账户 A）承担一个操作角色（账户 B）。账户 B 中的操作角色信任管道角色并具有部署权限。账户 A 中的 S3 Artifact 存储桶和 KMS 密钥必须具有授予账户 B 中的操作角色访问权限的资源策略。

原因: 这是标准、安全的跨账户访问模式：用于操作的角色承担，用于数据访问的基于资源的策略。

为 EKS 实施 GitOps 工作流，使集群状态自动并持续地与 Git 存储库保持一致。

→在 EKS 集群中部署 GitOps 控制器（例如 Flux、ArgoCD）。将其配置为监控 Git 存储库并应用/协调更改。

原因: 这是标准的“拉取式”GitOps 模式。集群内控制器处理持续协调和漂移检测，这是 GitOps 的核心原则。

允许中央工具账户中的 CodeBuild 项目将 Kubernetes 清单部署到独立工作负载账户中的 EKS 集群。

→在每个工作负载账户中，创建一个由 CodeBuild 角色信任的跨账户 IAM 角色。将此新角色映射到 EKS 集群 `aws-auth` ConfigMap 中的 Kubernetes RBAC 组。CodeBuild 脚本在运行 `kubectl` 之前承担该角色。

原因: 这是跨账户 EKS 访问的标准安全模式。它通过为此目的创建专用受信任角色来遵循最小权限原则。

执行复杂 RDS PostgreSQL 或 MySQL 架构迁移，实现零或接近零停机。

→使用 Amazon RDS 蓝/绿部署功能。创建一个同步的预演（绿）环境，对其应用架构更改，然后切换以将其提升为生产环境。

原因: 这是专为安全、零停机 RDS 更新而构建的托管服务。它处理克隆、同步和快速（< 1 分钟）切换，并内置了安全防护措施。

将单页应用程序 (SPA) 的新版本部署到 S3/CloudFront，并确保用户立即收到新版本，同时最大程度地减少缓存失效成本。

→对资产文件名使用基于内容的哈希（例如 `app.a1b2c3d4.js`）。部署新资产后，仅使 CloudFront 分发中的 `index.html` 文件失效。

原因: 哈希文件名是唯一的，因此 CloudFront 将它们视为新对象并从源获取它们，绕过缓存。只有单个入口点文件 (`index.html`) 需要失效，这比通配符 (`/*`) 失效便宜得多。

为 AWS CDK 应用程序实施 CI/CD 管道，当管道自身的定义更改时，该管道会自动更新自身。

→使用 CDK Pipelines 构造 (`pipelines.CodePipeline`)。此构造默认创建一个包含 `SelfMutate` 阶段的管道。

原因: CDK Pipelines 是专为此模式构建的高级构造。`SelfMutate` 阶段确保管道在部署应用程序更改之前始终反映代码中的最新定义。

部署需要向后兼容数据库架构更改（例如，添加新列）的新应用程序版本，实现零停机。

→实施扩展和收缩（或并行更改）模式。首先，部署附加的、向后兼容的数据库架构更改。其次，部署使用新架构的新应用程序版本。旧版本和新版本的应用程序都可以与更新后的数据库共存。

原因: 这种模式将数据库和应用程序部署解耦，确保数据库状态始终与旧版本和新版本的应用程序兼容，从而实现零停机发布。

逐步向特定用户群推出新功能，并使用 A/B 测试衡量对业务指标（例如转化率）的影响。

→使用 Amazon CloudWatch Evidently。创建一个具有多种变体的功能，一个用于控制发布百分比的启动，以及一个用于衡量对已定义指标的统计影响的实验。

原因: Evidently 是专为功能标志和 A/B 实验而构建的服务，它不仅提供发布机制，还提供用于衡量影响的统计分析引擎。

在整个 AWS Organization 中，强制所有 EC2 实例在启动时使用强制性标签。

→使用服务控制策略 (SCP)，除非请求中包含所需的标签键，否则拒绝 `ec2:RunInstances`。

原因: 预防性控制措施，阻止创建不合规资源。适用于所有账户，且不能被本地 IAM 策略覆盖。

参考↗

在不中断的情况下，管理和轮换多个账户中应用程序使用的密钥（例如，数据库凭证）。

→使用 AWS Secrets Manager 并启用自动轮换。使用基于资源的密钥策略授予跨账户访问权限。

原因: Secrets Manager 支持零停机轮换策略（交替用户），并提供安全、原生的跨账户共享功能。

通过 Control Tower Account Factory 创建新账户后，自动部署基线安全资源。

→通过 EventBridge 使用 Control Tower 生命周期事件 `CreateManagedAccount` 触发一个部署 CloudFormation StackSet 的 Lambda 函数。或者，使用 Customizations for AWS Control Tower (CfCT)。

原因: 事件驱动自动化是在账户创建后，无需手动干预即可扩展 Control Tower 基线的标准、可扩展模式。

在没有互联网访问权限的私有子网中，启用 SSM Session Manager 访问 EC2 实例。

→在 VPC 中为 `ssm`、`ssmmessages` 和 `ec2messages` 服务创建 VPC 接口终端节点（由 PrivateLink 提供支持）。

原因: VPC 终端节点允许 SSM 代理完全在 AWS 网络内部与服务通信，提供了最安全的访问模式，无需 NAT 或互联网网关。

集中存储日志并进行长期保留，保护它们免受删除或修改，即使是管理员也不例外。

→将日志存储在启用 S3 Object Lock 合规模式的 S3 存储桶中。启用 CloudTrail 日志文件完整性验证。

原因: Object Lock（合规模式）提供 WORM 保护，即使是根账户也无法绕过。日志文件完整性验证提供了交付后篡改的加密检查。

为开发人员提供一种自助方式来预置预先批准的基础设施模式，而无需授予他们完整的 AWS 服务权限。

→使用 AWS Service Catalog。创建经批准的产品组合（由 CloudFormation 模板定义）。使用启动约束，让 Service Catalog 使用平台团队管理的特权 IAM 角色预置资源。

原因: Service Catalog 是专为创建精选 IT 服务目录而构建的 AWS 服务。启动约束是关键的治理功能，允许开发人员在没有底层权限的情况下预置复杂的基础设施。

安全地为作为 ECS 任务运行的不同微服务提供唯一的密钥，确保每个服务只能访问自己的密钥。

→为每个服务创建单独的 AWS Secrets Manager 密钥。在 ECS 任务定义中，在容器定义的 `secrets` 属性中引用密钥 ARN。将任务执行 IAM 角色策略的范围限定为仅允许对该服务特定密钥 ARN 进行 `secretsmanager:GetSecretValue` 操作。

原因: 这在多个层面强制实施最小权限原则：密钥本身、IAM 策略和 ECS 任务定义。密钥在运行时安全注入。

允许 GitHub Actions 工作流安全地访问 AWS，而无需存储长期凭证。

→为 GitHub 配置一个 IAM OIDC 身份提供者。创建一个 IAM 角色，其信任策略将联合主体限制为特定的 GitHub 组织、存储库和分支。使用带有 OIDC 的 `aws-actions/configure-aws-credentials` 操作来承担该角色。

原因: OIDC 联合是最安全的方法，它提供作用于特定工作流运行的短期凭证，消除了长期凭证暴露的风险。

持续监控整个 AWS Organization 中的所有 IAM 策略，以识别与外部实体共享的资源并发出警报。

→在组织级别启用 IAM Access Analyzer，将组织定义为信任区域。使用 EventBridge 捕获新发现并触发通知。

原因: IAM Access Analyzer 专门用于使用自动化推理来查找外部共享资源。在组织级别运行它提供了持续、集中的视图，无需自定义脚本。

在单体或嵌套堆栈架构中，减少 CloudFormation 更新失败的影响范围。

→使用跨堆栈引用（CloudFormation Exports/Fn::ImportValue）将架构分解为独立的堆栈。

原因: 一个堆栈（例如数据库）中的故障不会触发其他成功更新的堆栈（例如网络）的回滚，从而隔离故障域。

集中管理跨账户补丁，并为生产和非生产环境设置不同的调度。

→使用 AWS Systems Manager Patch Manager，结合自定义补丁基线、每个环境独立的维护时段，以及 Systems Manager Explorer 进行集中式合规性报告。

原因: 原生支持所有要求：自定义补丁定义、通过维护时段灵活调度，以及通过 Explorer 实现跨账户可见性。

在执行 CloudFormation StackSet 更新之前，预览所有目标账户中的基础设施更改。

→在执行之前，为 StackSet 操作创建并审查一个 CloudFormation 变更集。

原因: 变更集是 CloudFormation 的原生机制，用于预览更新将执行的确切资源更改（添加、修改、删除）。

确保 CloudFormation 在继续堆栈创建之前，等待 EC2 实例的 UserData 脚本成功完成。

→在 EC2 实例资源中添加带有 `ResourceSignal` 的 `CreationPolicy`。在成功完成后，从 UserData 调用 `cfn-signal` 助手脚本。

原因: 这是 CloudFormation 用于与资源上的配置脚本协调的原生机制。如果在超时时间内未能发送信号，则会自动触发堆栈回滚。

检测手动进行的带外更改何时导致已部署资源与其 CloudFormation 模板定义不一致。

→定期对堆栈运行 CloudFormation 漂移检测。为了持续检测，使用 `cloudformation-stack-drift-detection-check` AWS Config 规则。

原因: 漂移检测是比较堆栈模板与其实际资源状态的原生功能。使用 Config 规则可以自动化此检查。

通过 CloudFormation 堆栈操作，保护有状态资源（例如 S3 存储桶或 RDS 数据库）免遭意外删除或替换。

→在资源上，设置 `DeletionPolicy: Retain`（对于 RDS 为 `Snapshot`）。在堆栈上，启用 `TerminationProtection`。应用 `StackPolicy`，拒绝关键资源上的 `Update:Replace` 和 `Update:Delete` 操作。

原因: 提供深度防御：终止保护可防止堆栈删除，删除策略可在堆栈删除时保留资源，堆栈策略可防止破坏性更新。

将 CloudFormation StackSet 从复杂的、自行管理的 IAM 角色模型迁移到 AWS Organization 的更简单的权限模型。

→更新 StackSet 以使用服务管理的权限。

原因: 服务管理的权限利用 Organizations 信任访问，无需在每个目标账户中创建和管理 IAM 角色。它还支持自动部署到添加到目标 OU 的新账户。

CloudFormation 自定义资源需要管理一个耗时超过 15 分钟 Lambda 函数超时限制的任务。

→从自定义资源的 Lambda 函数触发 AWS Step Functions 状态机。状态机使用 Wait 状态或 Task Token 模式处理长时间运行的任务，并将响应发送回 CloudFormation 的 S3 预签名 URL。

原因: Step Functions 旨在编排长时间运行、多步骤的工作流，有效地绕过 Lambda 超时限制，同时保持与 CloudFormation 的集成。

集中强制执行一项策略（例如，所有 S3 存储桶必须启用版本控制），应用于整个 AWS CDK 应用程序，无论开发人员如何定义其资源。

→创建一个实现 `IAspect` 接口的 CDK Aspect。该 Aspect 遍历应用程序树中的所有构造，查找所有 S3 存储桶构造，并应用所需的配置，如果缺少则添加验证错误。

原因: Aspects 是 CDK 的官方模式，用于集中应用横切关注点和实施策略即代码验证，而无需修改单个构造。

防止自动化操作（如通过 SSM 维护时段进行的修补）在特定的、变化的时期（例如，季度财务停工期）运行。

→使用 SSM Change Calendar 定义将停工期标记为“关闭”的事件。将 Change Calendar 与维护时段关联。

原因: Change Calendar 作为自动化的一个门槛。它在“关闭”期间自动阻止执行，而无需手动更改维护时段计划，这使其在管理动态停工期方面非常高效。

集中管理自定义软件包（例如，监控代理）在 EC2 实例集群中的安装和版本控制。

→使用 SSM Distributor 打包软件。使用 SSM State Manager 创建关联，将 Distributor 包应用到所有目标实例。

原因: Distributor 管理软件包生命周期（包括版本）。State Manager 确保所需状态（例如，“已安装 1.2 版代理”）持续强制执行，自动修复漂移并配置新实例。

跨区域 Aurora 数据库和应用程序层的低 RPO (< 1 分钟) 和 RTO (< 5 分钟) 灾难恢复。

→使用 Aurora Global Database 实现亚秒级数据库复制。对于应用程序层，使用“暖备”模式，将 Auto Scaling 组的期望容量设置为 0，并通过故障转移自动化进行扩展。

原因: Aurora Global Database 提供亚秒级 RPO 和 < 1 分钟 RTO。暖备应用程序层具有成本效益，同时仍能满足快速 RTO。

减少启动/初始化时间较长的实例的 Auto Scaling 组扩展时间。

→创建预烘焙的“黄金 AMI”，其中已安装所有依赖项。在 Auto Scaling 组上配置一个预热池，以保持实例预初始化状态。

原因: 黄金 AMI 最小化了启动时间。预热池最小化了启动时间（启动与创建）。两者结合，显著减少了新实例准备好服务流量所需的时间。

ECS 服务扩展其任务计数，但由于底层 EC2 集群容量不足，无法放置新任务。

→通过将容量提供者与 EC2 Auto Scaling 组和 ECS 集群关联，启用 ECS Cluster Auto Scaling。

原因: 容量提供者将 ECS 服务扩展与 EC2 实例扩展链接起来。当任务由于集群资源不足而无法放置时，容量提供者会自动扩展 EC2 ASG。

根据 SQS 队列中的消息数量，动态扩展 EC2 工作实例群。

→使用基于自定义指标的目标跟踪 Auto Scaling 策略：`ApproximateNumberOfMessagesVisible` / `GroupInServiceInstances`（即，每个实例的积压）。

原因: 这是基于 SQS 扩展的推荐模式。它维持足够的工作器，在目标时间内处理积压，根据队列深度高效地进行扩展。

为有状态应用程序创建 EBS 卷的应用程序一致性（而非仅崩溃一致性）快照。

→使用带有备份计划的 AWS Backup。在计划中，使用 Systems Manager Run Command 执行快照前脚本以静默应用程序（或为 Windows 启用 VSS）。

原因: AWS Backup 编排整个过程。在快照之前静默应用程序（将 I/O 缓冲区刷新到磁盘）可确保数据完整性和可恢复的应用程序状态。

确保当目标服务（例如 Lambda）暂时不可用或受到节流时，EventBridge 规则中的关键事件不会丢失。

→在 EventBridge 规则目标上，配置重试策略（例如，最长 24 小时）和使用 SQS 队列的死信队列 (DLQ)。

原因: 重试策略自动处理瞬时故障。DLQ 充当最终安全网，捕获耗尽所有重试的事件，以便以后可以重新处理它们，防止数据丢失。

针对特定日志模式触发实时警报，并在通知中包含上下文信息（例如，周围的日志行）。

→使用 CloudWatch Logs 订阅筛选器将匹配的日志事件流式传输到 Lambda 函数。Lambda 函数格式化并发送详细通知（例如，发送到 SNS 或 Chime）。

原因: 订阅筛选器提供实时事件流。Lambda 允许自定义逻辑来提取和格式化上下文，这是简单的指标筛选器无法做到的。

在分布式、基于微服务的应用程序中识别延迟瓶颈。

→在入口点（例如 API Gateway、ALB）和计算资源（例如 Lambda、ECS）上启用 AWS X-Ray 跟踪。使用 X-Ray SDK 进行下游调用。分析服务地图和跟踪。

原因: X-Ray 是专为分布式跟踪构建的 AWS 服务。服务地图可视化调用链，并突出显示具有高延迟和错误率的服务。

创建一个单一的高级别警报，代表多层应用程序的综合健康状况，以减少警报噪音。

→为每个层级创建单独的 CloudWatch 警报（例如，ALB 5xx 错误率、应用程序 CPU、RDS 连接数）。然后，使用带有 OR 逻辑的 CloudWatch 复合警报将它们组合起来。

原因: 复合警报旨在通过基于多个底层警报的状态创建一个单一的逻辑警报来减少警报噪音。

以经济高效的方式分析数 PB 的日志，执行复杂的 SQL 查询（包括连接），并将其保留多年。

→通过 Kinesis Data Firehose 将日志流式传输到 Amazon S3。使用 AWS Glue 对数据进行编目。使用 Amazon Athena 进行查询。使用 S3 生命周期策略将数据转换为 Glacier/Deep Archive 进行长期保留。

原因: 这是标准的无服务器数据湖架构。Athena 在 S3 数据上提供强大的 SQL 功能，S3/Glacier 提供最具成本效益的长期存储。

监控具有可预测周期性模式（例如，每日/每周峰值）的指标，并仅在模式出现真正偏差时触发警报。

→在指标上配置 CloudWatch 异常检测。创建一个警报，当指标值超出模型的预期范围时触发。

原因: 异常检测使用机器学习来学习指标的正常模式，创建适应周期的动态阈值带。这减少了可预测峰值导致的误报，并提高了信噪比。

无需安装和管理第三方工具，即可全面了解 EKS 或 ECS 上容器级 CPU、内存、磁盘和网络指标。

→为 EKS/ECS 集群启用 Amazon CloudWatch Container Insights。

原因: Container Insights 是一种完全托管的服务，可自动收集、聚合和可视化容器化工作负载的详细性能指标，以最小的操作开销提供深度可见性。

从最终用户的角度监控面向互联网的应用程序的可用性和性能，识别 ISP 级别和地理网络问题。

→为应用程序启用 Amazon CloudWatch Internet Monitor。

原因: Internet Monitor 利用 AWS 全球网络数据，提供对影响最终用户的互联网状况的可见性，帮助诊断 AWS 环境之外的问题。

通过收集页面加载时间、JavaScript 错误和其他客户端性能指标来衡量 Web 应用程序的真实用户体验。

→将 CloudWatch RUM (Real User Monitoring) JavaScript 片段集成到 Web 应用程序中。

原因: RUM 是一种托管服务，直接从用户浏览器收集客户端性能和错误数据，无需合成测试即可提供对真实用户体验的真正洞察。

从 AWS Lambda 函数发出具有高分辨率和维度的自定义应用程序指标，而不会增加直接 CloudWatch API 调用的延迟和成本。

→通过将特殊结构的 JSON 写入标准输出，使用 CloudWatch 嵌入式指标格式 (EMF)。客户端库可以简化此过程。

原因: CloudWatch Logs 自动且异步地从 EMF 日志条目中提取指标，不会增加 Lambda 函数的额外延迟，并通过避免 PutMetricData API 调用来降低成本。

自动修复 AWS Config 检测到的未加密 EBS 卷，在此过程中确保数据一致性。

→使用 AWS Config 自动修复与 Systems Manager Automation 文档。运行手册将停止实例，创建卷的加密副本，交换卷，然后重新启动实例。

原因: SSM Automation 提供了一个健壮、多步、可审计的工作流。在创建加密副本之前停止实例对于确保数据一致的快照至关重要。

运行受控的混沌工程实验（例如，注入网络延迟），并带有自动停止条件以防止生产影响。

→使用带有实验模板的 AWS Fault Injection Simulator (FIS)。根据监控关键应用程序指标的 CloudWatch 告警定义停止条件。

原因: FIS 是专为混沌工程构建的 AWS 服务，提供安全防护措施（停止条件）和受控故障注入操作目录。

CloudFormation 堆栈卡在 `UPDATE_ROLLBACK_FAILED` 状态，因为在更新失败期间资源被删除或更改，从而阻止了干净的回滚。

→使用 `ContinueUpdateRollback` API 操作，在 `ResourcesToSkip` 参数中指定问题资源的逻辑 ID。

原因: 这是标准恢复过程，通过告诉 CloudFormation 忽略它无法再管理的资源来强制完成回滚，使堆栈返回到稳定状态。

在关键安全事件（例如根账户登录、IAM 策略更改或安全组修改）发生后的几分钟内收到通知。

→创建与特定 CloudTrail 管理事件模式匹配的 Amazon EventBridge 规则，并将它们路由到 SNS 主题以进行通知。

原因: EventBridge 几乎实时接收 CloudTrail 管理事件，与轮询或基于日志的方法相比，为事件驱动的安全警报提供了最低的延迟。

一个高流量的 Lambda 函数在扩展时遇到节流问题，并且耗尽了 RDS 数据库连接。

→请求增加 Lambda 并发执行限制。在 Lambda 函数和 RDS 数据库之间实施 Amazon RDS Proxy。

原因: 增加并发性解决了节流问题。RDS Proxy 对于无服务器应用程序至关重要，因为它池化并重用数据库连接，防止数据库被大量临时连接淹没。

实现区域间的自动化 DNS 故障转移，并为故障区域触发自动化恢复运行手册。

→使用 Route 53 故障转移路由和相关的健康检查。创建一个 EventBridge 规则，捕获 Route 53 健康检查状态更改事件并触发 Systems Manager Automation 运行手册。

原因: 此架构将自动化流量故障转移 (Route 53) 与事件驱动的自动化事件响应 (EventBridge + SSM Automation) 相结合，形成完整的弹性模式。

防止 RDS 数据库耗尽存储空间并导致应用程序中断。

→通过设置最大存储阈值来启用 RDS Storage Autoscaling。作为辅助控制，在 `FreeStorageSpace` 指标上创建 CloudWatch 警报。

原因: Storage Autoscaling 是一种主动的托管功能，可自动增加分配的存储。CloudWatch 警报提供了一个用于监控和警报的安全网。

由于消费者端的临时错误，需要重新处理一批事件。

→事先在事件总线上配置 EventBridge Archive。修复错误后，创建 Replay 以重新发送事件，这些事件来自事故发生的特定时间窗口。

原因: Archive and Replay 是 EventBridge 用于存储和重新处理历史事件的原生功能，对于从瞬时处理失败中恢复至关重要。

当关键警报触发时，自动化整个事件响应过程：创建事件、联系值班团队、开辟聊天通道并执行修复运行手册。

→创建 SSM Incident Manager 响应计划，定义所有参与和修复步骤。配置 CloudWatch 警报以将其作为操作触发此响应计划。

原因: 响应计划提供单一、协调的配置来编排事件响应的所有方面，减少手动工作并确保一致的程序。