极点宏观｜Financial Cloud Cloud · AWS 考试
AWS DevOps Certified Professional
| 文章 |
|---|
| 01 AWS Solutions Architect Professional SAP-C02 讲义 |
| 02 AWS DevOps Certified Professional DOP-C02 讲义 |
面向政府技术顾问、公益与教育主管、数据与安全负责人、心理健康服务网络及大型机构决策者的演讲内容稿。
亚马逊 Aurora 全球数据库
存储级跨区域复制提供非常低的 RPO 和快速托管故障转移，以实现低 RTO。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：存储级跨区域复制提供非常低的 RPO 和快速托管故障转移，以实现低 RTO。
● 场景匹配：存储级跨区域复制提供非常低的 RPO 和快速托管故障转移，以实现低 RTO。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 异步复制可提高 RPO，但与专门构建的全局复制相比，提升和追赶会提高 RTO。
● 自动恢复，但 RPO 取决于快照频率，而 RTO 包括完整恢复时间。
● 多AZ备用数据库仅限于单个Region，不能跨Region放置。
工作流：亚马逊极光全球数据库。
AWS CodeDeploy 蓝/绿，60 分钟蓝色终止
EC2/Auto Scaling 的 CodeDeploy 蓝/绿会在准备就绪时交换 ALB 目标组，并支持在指定的等待时间后终止原始队列。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：EC2/Auto Scaling 的 CodeDeploy 蓝/绿会在准备就绪时交换 ALB 目标组，并支持在指定的等待时间后终止原始队列。
● 场景匹配：EC2/Auto Scaling 的 CodeDeploy 蓝/绿会在准备就绪时交换 ALB 目标组，并支持在指定的等待时间后终止原始队列。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● CloudFormation 和 Route 53 可以创建资源并更新 DNS，但本身不能管理蓝/绿流量转移和定时旧队列终止。
● 实例刷新执行就地滚动更新，并且不会创建单独的绿色队列或安排旧队列的切换后终止。
● Elastic Beanstalk 可以交换环境，但不提供先前环境的自动 60 分钟停用功能。
工作流：AWS CodeDeploy 蓝色/绿色，带有 60 分钟蓝色终止。
仅在初始化完成并指向后更新部署以创建 /health-ready.php
在部署结束时创建确定性就绪端点可确保目标仅在应用程序实际就绪时才变得正常。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：在部署结束时创建确定性就绪端点可确保目标仅在应用程序实际就绪时才变得正常。
● 场景匹配：在部署结束时创建确定性就绪端点可确保目标仅在应用程序时才变得正常。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 更改状态代码和延长计时器并不能保证应用程序已准备就绪，并且仍然可以将不稳定的目标标记为健康。
● 增加更多的时间和检查会延迟部署，但无法将运行状况与真正的应用程序准备情况可靠地关联起来。
● Route 53 运行状况检查在 DNS 级别运行，不控制 ALB 目标注册或每个目标的准备情况。
工作流：仅在初始化完成后更新部署以创建 /health-ready.php 并将 ALB 运行状况检查指向该路径。
实例配置文件并从 AWS Secrets Manager 检索凭证
实例配置文件提供临时凭证，Secrets Manager 安全地存储和轮换数据库密码。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：实例配置文件提供临时凭证，Secrets Manager 安全地存储和轮换数据库密码。
● 场景匹配：实例配置文件提供临时凭证，Secrets Manager 安全地存储和轮换数据库密码。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● S3 不是秘密存储，缺乏内置的秘密轮换，并且与专用服务相比增加了暴露风险。
● 在图像中嵌入秘密会使旋转变得复杂，并使图像中的秘密激增。
● 实例上的静态密钥风险很高，并且 Parameter Store 不提供 RDS 密码的本机轮换。
工作流：使用实例配置文件并从 AWS Secrets Manager 检索凭证。
具有自动备份和删除保护功能的 Amazon RDS + AWS Elastic Beanstalk
提供具有自动备份功能的托管关系数据库，并防止意外删除。 Node.js 托管平台，集成了 Application Load Balancer 和 Auto Scaling 以减少运营工作。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：提供具有自动备份功能的托管关系数据库，并防止意外删除。
● 场景匹配：提供具有自动备份功能的托管关系数据库，并防止意外删除。 Node.js 托管平台，集成了 Application Load Balancer 和 Auto Scaling 以减少运营工作。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 与完全托管的 PaaS 相比，Kubernetes 增加了集群、入口和扩展的运营开销。
● DynamoDB是NoSQL，不能满足关系数据库的要求。
● 仍然需要服务器管理、修补和容量调整，这增加了运营负担。
工作流：具有自动备份和删除保护功能的 Amazon RDS → 具有 ALB 和 Auto Scaling 功能的 AWS Elastic Beanstalk。
在第二个区域中使用 ALB 和 Auto Scaling 将计算放置在附近
在另一个区域运行计算可以减少附近用户的延迟并提高区域弹性。基于延迟的路由将客户端定向到延迟最低的健康端点并支持故障转移。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：在另一个区域运行计算可以减少附近用户的延迟并提高区域弹性。
● 场景匹配：在另一个区域运行计算可以减少附近用户的延迟并提高区域弹性。基于延迟的路由引导客户端。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● CloudFront 主要帮助缓存静态内容，不解决动态写入延迟或多区域可用性问题。
● DynamoDB 不支持临时跨区域复制；全局表是受支持的方法。
● 对于单个区域源，这可以改善边缘到区域的路径，但不提供本地写入或多区域弹性。
工作流：在第二个区域中部署 ALB 和 Auto Scaling，将计算置于用户附近 → 使用 Route 53 基于延迟的路由和运行状况检查将用户发送到最近的区域 ALB → 在第二个区域中启用具有副本的 DynamoDB 全局表。
将应用程序日志和 CloudTrail 提取到 CloudWatch Logs 中；使用 CloudWatch 查询
将两个数据集发送到 CloudWatch Logs 允许 CloudWatch Logs Insights 一起查询它们。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：将两个数据集发送到 CloudWatch Logs 允许 CloudWatch Logs Insights 一起查询它们。
● 场景匹配：将两个数据集发送到 CloudWatch Logs 允许 CloudWatch Logs Insights 一起查询它们。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● CloudWatch Logs Insights 无法查询 S3 数据。
● CloudTrail Lake 用于 CloudTrail 事件数据，不会摄取任意应用程序日志。
● CloudWatch 代理不会将日志直接发送到 S3。
工作流：将应用程序日志和 CloudTrail 提取到 CloudWatch Logs → 使用 CloudWatch Logs Insights 进行查询。
通过 aws:SecureTransport 阻止非 TLS、设置默认 SSE-S3 并使用 S3 跨区域复制
这会强制执行 HTTPS，使用无需 KMS 限制即可扩展的 SSE-S3，并复制到第二个区域。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这会强制执行 HTTPS，使用无需 KMS 限制即可扩展的 SSE-S3，并复制到第二个区域。
● 场景匹配：这会强制执行 HTTPS，使用无需 KMS 限制即可扩展的 SSE-S3，并复制到第二个区域。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 强制执行 HTTPS 并设置 CRR，但 SSE-KMS 引入了 AWS KMS 每秒请求限制，这可能会成为非常高的 PUT 速率的瓶颈。
● 多区域接入点不复制数据；如果没有配置复制，这不能满足跨区域持久性，并且 SSE-KMS 仍然可以进行限制。
● RTC 不会删除 KMS TPS 限制，并且不会在存储桶级别强制实施 TLS。
工作流：通过 aws:SecureTransport 阻止非 TLS → 设置默认 SSE-S3，并使用 S3 跨区域复制。
使用 Amazon Kinesis Data Streams 提取流，使用 Amazon Managed Service
Kinesis Data Streams 与 Apache Flink 提供可扩展的实时处理，Firehose 到 S3 的成本较低，Glue 加 Athena 支持无服务器临时分析。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Kinesis Data Streams 与 Apache Flink 提供可扩展的实时处理，Firehose 到 S3 成本较低，而 Glue。
● 场景匹配：Kinesis Data Streams 与 Apache Flink 提供可扩展的实时处理，Firehose 到 S3 成本较低，而 Glue。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 与专门构建的流媒体服务相比，EventBridge 并未针对持续高吞吐量点击流摄取进行优化。
● 在大型 EC2 实例上运行 EMR 会显着增加成本，并且在管道中插入 SQS 对于实时来说是不必要的。
● SQS 并非专为高吞吐量流式点击流而设计，实例存储是短暂的，不适合分析存储。
工作流：使用 Amazon Kinesis Data Streams 提取流 → 使用 Amazon Managed Service for Apache Flink Studio 进行实时会话化，让 AWS Lambda 将聚合转发到 Amazon Kinesis Data Firehose、登陆数据。
将 CostCenterId=9421 的 EBS TagSpecifications 添加到启动模板
在创建时自动启动模板 TagSpecifications 标记 EBS 卷。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：在创建时自动启动模板 TagSpecifications 标记 EBS 卷。
● 场景匹配：在创建时自动启动模板 TagSpecifications 标记 EBS 卷。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● ASG 标签传播适用于 EC2 实例，而不是附加的 EBS 卷。
● 标签在创建后应用，并增加不必要的操作开销。
● 强制执行，但不会自动标记，并且可能会破坏服务创建的卷。
工作流：将 CostCenterId=9421 的 EBS TagSpecifications 添加到启动模板。
降低 MinSuccessfulInstancesPercent 以防止在少数实例失败时完全回滚 +
如果只有少数实例无法启动或发出信号，则降低成功阈值可以让堆栈继续运行。关闭信号有助于识别是否有信号。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：如果只有少数实例无法启动或发出信号，则降低成功阈值可以让堆栈继续运行。
● 场景匹配：如果只有少数实例无法启动，则降低成功阈值可以让堆栈继续运行。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 暂停这些重要进程会停止实例替换和注册，从而导致部署停滞。
● 更换整个组会增加风险并隐藏根本原因，而不是诊断滚动更新故障。
● 切换机制不能解决 CloudFormation 特定的停顿问题，也不能直接减少不必要的回滚。
工作流：降低 MinSuccessfulInstancesPercent 以防止在少数实例失败时完全回滚 → 禁用 WaitOnResourceSignals 以进行滚动更新 → 在推出期间暂停 HealthCheck、ReplaceUnhealthy、AZRebalance、AlarmNotification 和 ScheduledActions。
Amazon DynamoDB 并启用跨越五个选定区域的全局表
DynamoDB 全局表提供多区域、多活动复制，因此每个区域都可以执行在全球范围内复制的低延迟本地读取和写入。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：DynamoDB 全局表提供多区域、多活动复制，因此每个区域都可以执行在全球范围内复制的低延迟本地读取和写入。
● 场景匹配：DynamoDB 全局表提供多区域、多活动复制，因此每个区域都可以执行低延迟本地读取和写入。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● ElastiCache 复制组的范围仅限于单个区域，即使使用全局数据存储，也不支持跨区域的多活动写入，因此它们无法在每个区域提供低延迟写入。
● 跨区域只读副本是只读的，所有写入都必须转到主区域，这会增加该区域之外的用户的写入延迟。
● Aurora Global Database 支持单主写 Region 跨 Region 读副本，无法满足多 Region 主动写入的需求。
工作流：使用 Amazon DynamoDB 并启用跨越五个选定区域的全局表。
具有所需实例的现有启动模板的新版本
这会更新用于所有未来启动的定义，以便新实例可以使用新实例类型进行扩展。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这会更新用于所有未来启动的定义，以便新实例可以使用新实例类型进行扩展。
● 场景匹配：这会更新用于所有未来启动的定义，以便新实例可以使用新实例类型进行扩展。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 实例刷新不会更改实例类型，除非首先更新其引用的启动模板或配置。
● 为启动模板配置的组无法同时切换到启动配置，并且启动配置是旧版的。
● 覆盖适用于混合实例类型，并且不会在不重新配置组的情况下强制所有实例使用单一新类型。
工作流：使用所需的实例类型创建现有启动模板的新版本，并更新 Auto Scaling 组以引用该版本。
绿色 Auto Scaling 组上的滚动更新即将推出
这首先准备绿色环境，然后立即执行 ALB 切换，以实现一次性切换，而不会出现 DNS 传播延迟。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这首先准备绿色环境，然后立即执行 ALB 切换，以实现一次性切换。
● 场景匹配：这首先准备绿色环境，然后立即执行 ALB 切换，以实现一次性切换。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 将焦点转移到蓝色组并提出无法直接针对 ALB 目标组的 DNS 更改。
● 在新版本完全部署和验证之前将实时流量路由到绿色，从而面临中断的风险。
● 对于单个 ALB，无需更改 Route 53 别名，并且无法选择特定目标组。
工作流：在绿色 Auto Scaling 组上运行滚动更新以推出新版本，→ 使用 AWS CLI 将 ALB 侦听器移至绿色目标组。
Amazon Inspector 可自动评估应用程序的暴露情况、漏洞和偏差
Inspector 提供所需的自动化漏洞评估，ALB 加上多可用区自动扩展设计提供高可用性，Aurora 具有弹性，并且别名记录。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Inspector 提供所需的自动化漏洞评估，ALB 加上多可用区自动扩展设计提供高可用性，Aurora。
● 场景匹配：Inspector 提供所需的自动化漏洞评估，ALB 加上多可用区自动扩展设计提供高可用性，Aurora。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Macie 专注于敏感数据发现，非别名 A 记录无法针对 ALB，因此它不会。
● GuardDuty 是威胁检测而不是应用程序漏洞评估，并且 CNAME 不能在区域顶点使用。
工作流：使用 Amazon Inspector 自动评估应用程序的暴露情况、漏洞以及与 AWS 最佳实践的偏差 → 在应用程序负载后面运行分布在三个可用区的 EC2 Auto Scaling 组。
发布新的 Lambda 版本并公开新的 API 网关阶段
两个阶段都通过别名调用一个 Lambda，而旧阶段使用映射模板添加静态字段，从而保留单个后端和长期的。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：两个阶段都通过别名调用一个 Lambda，而旧阶段则使用 .
● 场景匹配：两个阶段都通过别名调用一个 Lambda，而旧阶段则使用 a 添加静态字段。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 创建两个 Lambda 函数并引入代理逻辑，增加了维护量，违反了仅管理一个函数的要求。
● 缓存和阶段变量不会可靠地改变请求主体，并且删除遗留路径可能会破坏旧客户端。
工作流：发布新的 Lambda 版本并公开一个名为 prod-v2 的新 API 网关阶段，该阶段与 prod-v1 一起调用相同的 Lambda 别名 → 在 prod-v1 上添加一个请求映射模板。
允许复制 IAM 角色的目标存储桶策略的语句
对于跨账户 S3 复制，目标存储桶必须信任源账户的复制角色来写入和管理对象所有权或 ACL。 S3 使用角色。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：对于跨账户 S3 复制，目标存储桶必须信任源账户的复制角色才能进行写入和管理。
● 场景匹配：对于跨账户 S3 复制，目标存储桶必须信任源账户的复制角色才能进行写入和管理。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 创建自定义复制管道而不是启用本机 S3 复制，因此它不满足要求。
● S3 在用于复制的源帐户中承担角色，而不是在目标帐户中，因此创建该角色。
工作流：向目标存储桶策略添加语句，允许源账户中的复制 IAM 角色写入对象并设置对象所有权 → 在源中创建 IAM 角色。
AWS 服务目录
发布经过审查的 CloudFormation 产品，其中包含约束和所需标签，以便在配置时进行预防性控制。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：发布经过审查的 CloudFormation 产品，其中包含约束和所需标签，以便在配置时进行预防性控制。
● 场景匹配：发布经过审查的 CloudFormation 产品，其中包含约束和所需标签，以便在配置时进行预防性控制。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● SCP 和标签策略可以限制或验证标签，但不提供经过审查的架构的精选目录。
● 创建资源后的检测合规性，而不是预防性供应控制。
● 模板策略即代码在管道中很有用，但不提供自助服务目录或块临时配置。
工作流：AWS 服务目录。
任务定义中的 awslogs；向 EC2 授予 CloudWatch Logs 权限
这是最简单的支持方法；在 EC2 启动类型上，awslogs 使用容器实例 IAM 角色写入 CloudWatch Logs。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这是最简单的支持方法；在 EC2 启动类型上，awslogs 使用容器实例 IAM 角色写入 CloudWatch Logs。
● 场景匹配：这是最简单的支持方法；在 EC2 启动类型上，awslogs 使用容器实例 IAM 角色写入 CloudWatch Logs。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 可行，但引入了额外的配置和组件，因此它不是最简单的选择。
● 在 EC2 上，awslogs 驱动程序不使用任务角色；它使用实例配置文件凭据。
● 可以工作，但比使用本机 awslogs 日志驱动程序操作更繁重。
工作流：在任务定义中使用 awslogs → 向 EC2 实例配置文件授予 CloudWatch Logs 权限。
单个存储库，通过 PR 进行开发->主要，提交时进行 CodeBuild，CodeDeploy 蓝/绿
带有流量转移的蓝/绿通过在环境之间翻转流量提供近乎零的停机时间和非常快速的回滚。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：带有流量转移的蓝/绿通过在环境之间翻转流量提供近乎零的停机时间和非常快速的回滚。
● 场景匹配：带有流量转移的蓝/绿通过在环境之间翻转流量提供近乎零的停机时间和非常快速的回滚。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 就地滚动可能会导致部分中断，并且回滚需要在整个队列中重新部署旧版本，这会比较慢。
● 与单存储库方法相比，多个存储库会增加协调开销，但不会提高回滚速度或可用性。
● 与立即蓝/绿流量切换相比，滚动更新会减少容量并使回滚速度变慢。
工作流：单个存储库，通过 PR 进行开发->主要，提交时进行 CodeBuild，通过流量转移进行 CodeDeploy 蓝/绿。
新版本的一次性部署策略
一次性同时更新所有实例，以实现最快的部署，并且在暂存阶段可以接受短暂的停机时间。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：一次性同时更新所有实例，以实现最快的部署，并且在暂存阶段可以接受短暂的停机时间。
● 场景匹配：一次性同时更新所有实例，以实现最快的部署，并且在暂存阶段可以接受短暂的停机时间。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 滚动更新分批进行，这会减慢整体部署速度并暂时降低容量。
● 蓝/绿需要运行重复的环境，这会增加成本并增加交换之前的配置时间。
● 不可变会为每个版本启动新实例，这更安全，但速度较慢，并且会产生额外成本。
工作流：新版本的一次性部署策略。
仅当 DB 可达时，健康端点才返回 200；设置ALB健康检查
公开一个应用程序运行状况 URL，用于测试数据库连接并在无法访问时返回非 200，以便 ALB 将目标标记为运行状况不佳。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：公开一个应用程序运行状况 URL，用于测试数据库连接并在无法访问时返回非 200，以便 ALB 将目标标记为运行状况不佳。
● 场景匹配：公开一个应用程序运行状况 URL，用于测试数据库连接并在无法访问时返回非 200，以便 ALB 将目标标记为运行状况不佳。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 在 DNS 级别运行，无法删除单个 ALB 目标。
● 检查实例/系统的运行状况，而不是应用程序或数据库的可访问性。
● ALB 运行状况检查评估 HTTP 状态代码和超时，而不是响应负载。
工作流：仅当数据库可访问时，运行状况端点才返回 200 → 将 ALB 运行状况检查设置为该路径。
CloudTrail 具有用于删除表到 SNS 的 EventBridge 规则
CloudTrail 记录 API 调用，EventBridge 通过 CloudTrail 事件匹配 AWS API 调用，以低成本向 SNS 发送即时通知。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudTrail 记录 API 调用，EventBridge 通过 CloudTrail 事件匹配 AWS API 调用，以低成本向 SNS 发送即时通知。
● 场景匹配：CloudTrail 记录 API 调用，EventBridge 通过 CloudTrail 事件匹配 AWS API 调用，以低成本向 SNS 发送即时通知。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 可行，但需要将 CloudTrail 交付到 CloudWatch Logs 并使用指标筛选器和警报，从而增加成本和潜在的延迟。
● 配置规则定期评估，不适用于近实时 API 调用检测。
● 流捕获项目级别的更改，并且不会发出像DeleteTable这样的管理API事件。
工作流：CloudTrail 具有用于删除表到 SNS 的 EventBridge 规则。
用于调用 AWS Step Functions 的 Amazon EventBridge 计划规则，该规则会启动
这会编排一个临时实例仅用于扫描 AMI，从而最大限度地降低成本和影响，同时确保每日 CVE 覆盖率。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这会编排一个临时实例仅用于扫描 AMI，从而最大限度地降低成本和影响，同时确保日常扫描。
● 场景匹配：这会编排一个临时实例仅用于扫描 AMI，从而最大限度地降低成本和影响，同时确保日常扫描。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Amazon Inspector 无法直接通过 ID 评估 AMI，并且需要 EC2 实例作为评估目标。
● 对于单个黄金 AMI 来说，重复扫描每个实例是多余的，会增加成本，并可能造成不必要的影响。
● Amazon Inspector 不接受 AMI ID 作为直接目标，并且无法扫描没有 AMI ID 的图像。
工作流：配置 Amazon EventBridge 计划规则以调用 AWS Step Functions，该规则从强化的 AMI 启动一个短期 EC2 实例，将其标记为 VulnScan：是，运行 Amazon Inspector 评估模板。
EC2_INSTANCE_LAUNCH_ERROR 的 EC2 Auto Scaling SNS 通知
内置 Auto Scaling 通知将启动失败事件直接发布到 SNS 以立即发出警报。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：内置 Auto Scaling 通知将启动失败事件直接发布到 SNS 以立即发出警报。
● 场景匹配：内置 Auto Scaling 通知将启动失败事件直接发布到 SNS 以立即发出警报。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 状态检查警报会在实例运行后触发，而不是在启动尝试失败时触发。
● 仅捕获来自 RunInstances 的 API 错误，并且可能会错过不作为 API 错误出现的 Auto Scaling 启动失败。
● 可能会滞后并表明容量不足，而不是具体失败的发射尝试。
工作流：为 EC2_INSTANCE_LAUNCH_ERROR 启用 EC2 Auto Scaling SNS 通知。
用于调用 Lambda 发布的 CodeDeploy 状态更改事件的 EventBridge 规则
EventBridge 对准确的部署状态更改做出反应，Lambda 发送 Slack 消息，CodeDeploy 处理失败时的本机自动回滚。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：EventBridge 对准确的部署状态更改做出反应，Lambda 发送 Slack 消息，CodeDeploy 处理失败时的本机自动回滚。
● 场景匹配：EventBridge 对准确的部署状态更改做出反应，Lambda 发送 Slack 消息，CodeDeploy 处理失败时的本机自动回滚。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 通知 Slack，但依赖自定义回滚逻辑，而不是 CodeDeploy 的本机自动回滚。
● 指标警报是间接的并且可能滞后；它们不直接利用状态更改事件，并且仍然需要正确的回滚配置。
● 管道通知并非特定于 CodeDeploy 状态更改，需要手动回滚脚本。
工作流：为 CodeDeploy 状态更改事件创建一条 EventBridge 规则，调用 Lambda 发布到 Slack，并启用 CodeDeploy 在失败时自动回滚。
Amazon ElastiCache for Redis（共享会话存储）
提供具有微秒延迟的内存中共享会话存储，并将会话与 EC2 生命周期解耦。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：提供具有微秒级延迟的内存中共享会话存储，并将会话与 EC2 生命周期解耦。
● 场景匹配：提供具有微秒延迟的内存中共享会话存储，并将会话与 EC2 生命周期解耦。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 内存中Redis具有跨可用区的持久性；通常，延迟比 ElastiCache for Redis 稍高，对于最低延迟会话读取而言并非最佳选择。
● 将用户与实例绑定，但更换或缩容实例时会话会丢失，持久化仍然失败。
● 持久且可扩展，但按请求会话查找的延迟比内存缓存解决方案更高。
工作流：Amazon ElastiCache for Redis（共享会话存储）。
限制对公司 AWS 账户的读取的存储桶策略以及
限定范围的存储桶策略加上删除 AuthenticatedUsers 预设 ACL，可确保只有经过批准的主体才能访问对象并消除广泛的访问。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：限定范围的存储桶策略加上删除 AuthenticatedUsers 预设 ACL，可确保只有经过批准的主体才能访问对象并消除广泛的访问。
● 场景匹配：范围存储桶策略加上删除 AuthenticatedUsers 预设 ACL 可确保只有经过批准的主体才能访问对象。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 静态加密不会改变对象权限，因此具有当前读取权限的任何人仍然能够访问数据。
● 公开这些对象将授予全球匿名访问权限并显着降低安全性。
● 添加 CloudFront 不会否定 S3 ACL，因此除非更正 ACL 和策略，否则任何 AWS 账户都可以读取对象。
工作流：创建一个存储桶策略，限制对公司 AWS 账户的读取，并从上传步骤中删除经过身份验证的读取 ACL。
将 Lambda 验证连接到 AppSpec.yaml 中的 AfterAllowTestTraffic 生命周期挂钩，以便进行测试
AfterAllowTestTraffic 旨在使用测试流量验证替换任务集，从而在任何生产切换之前实现安全回滚。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：AfterAllowTestTraffic 旨在使用测试流量验证替换任务集，从而在任何生产切换之前实现安全回滚。
● 场景匹配：AfterAllowTestTraffic 旨在使用测试流量验证替换任务集，从而在任何生产切换之前实现安全回滚。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● BeforeAllowTraffic 在测试验证之后运行应该已经完成，因此它不是执行初始验证测试的正确位置。
● AfterAllowTraffic 在生产流量路由到新任务集之后发生，这对于预生产验证来说为时已晚。
● AfterInstall 发生在测试侦听器将流量发送到新任务集之前，因此此处无法使用测试流量进行验证。
工作流：将 Lambda 验证连接到 AppSpec.yaml 中的 AfterAllowTestTraffic 生命周期挂钩，以便针对测试侦听器运行测试并可以触发自动回滚。
组织范围内的 AWS Config 规则，用于默认评估 EBS 加密，以及
这样可以以最小的开销在整个组织中集中部署和强制执行合规性检查，并保护控制免遭篡改。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这样可以以最小的开销在整个组织中集中部署和强制执行合规性检查，并保护控制免遭篡改。
● 场景匹配：这样可以以最小的开销在整个组织中集中部署和强制执行合规性检查，并保护控制免遭篡改。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 阻止一些新的不合规启动，但不评估现有卷或提供跨账户的持续合规性报告。
● 操作繁重，需要自定义代码、调度以及每个帐户的部署和维护。
● 可以工作，但效率低于组织级 AWS Config 规则，并且仍然需要额外的防护措施来防止 Config 被禁用。
工作流：创建组织范围内的 AWS Config 规则以默认评估 EBS 加密，并附加 SCP 以防止禁用或删除任何账户中的 AWS Config。
具有 ALB/Auto Scaling 功能的 AWS Elastic Beanstalk、外部 Amazon RDS MySQL 多可用区、日志
提供具有快速回滚功能的托管滚动或不可变部署，解耦共享生产数据库，并使用 CloudWatch Logs 和 Logs Insights 进行集中式、近乎实时的搜索。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：提供具有快速回滚功能的托管滚动或不可变部署，解耦共享生产数据库，并使用 CloudWatch Logs 和 Logs Insights 进行集中式、近乎实时的搜索。
● 场景匹配：提供具有快速回滚功能的托管滚动或不可变部署，解耦共享生产数据库，并使用 CloudWatch Logs 和 Logs Insights 进行集中式、近乎实时的搜索。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 与更简单的托管应用程序部署和基于 CloudWatch 的日志记录相比，可行，但操作复杂性和成本更高。
● 数据库缺乏多可用区，需要更多自定义部署和回滚编排。
● 将数据库生命周期与应用程序环境耦合起来，这对于共享数据库和回滚来说是有风险的。
工作流：具有 ALB/Auto Scaling 功能的 AWS Elastic Beanstalk、外部 Amazon RDS MySQL 多可用区，将日志记录到 CloudWatch Logs 并保留 90 天。
AWS CodePipeline 与 CodeBuild 和 CodeDeploy 使用 CodeDeployDefault.LambdaLinear10PercentEvery2Minutes
将托管 CI/CD 与自动化测试和受控线性流量转移以及通过 CloudWatch 警报的内置回滚相结合。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：将托管 CI/CD 与自动化测试和受控线性流量转移以及通过 CloudWatch 警报的内置回滚相结合。
● 场景匹配：将托管 CI/CD 与自动化测试和受控线性流量转移以及通过 CloudWatch 警报的内置回滚相结合。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● SAM 通过 CodeDeploy 支持金丝雀/线性部署，但 CLI 驱动的流程并不是具有自动化测试和触发器的完全托管管道。
● 自定义编排增加了无差别的工作，并且缺乏本机回滚和部署安全功能。
● 一次性立即转移 100% 的流量，不满足逐步转移的要求。
工作流：AWS CodePipeline 与 CodeBuild 和 CodeDeploy 使用 CodeDeployDefault.LambdaLinear10PercentEvery2Minutes。
aws.health AWS_RISK_CREDENTIALS_EXPOSED 的 EventBridge 规则到 Step Functions
在 EventBridge 中匹配 AWS_RISK_CREDENTIALS_EXPOSED 的 aws.health 事件，并使用 Step Functions 和 Lambda 协调删除、调查和通知。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：在 EventBridge 中匹配 AWS_RISK_CREDENTIALS_EXPOSED 的 aws.health 事件，并使用 Step Functions 和 Lambda 协调删除、调查和通知。
● 场景匹配：在 EventBridge 中匹配 AWS_RISK_CREDENTIALS_EXPOSED 的 aws.health 事件，并使用 Step Functions 和 Lambda 协调删除、调查和通知。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 这些服务不会检测公共 IAM 密钥暴露事件，也不会发出用于此工作流程的 AWS Health 事件。
● AWS Config 评估资源配置，并且不会显示 AWS 运行状况事件，例如暴露的凭证。
● Detective 支持调查，但不会生成或路由 AWS Health 暴露凭证事件以进行修复。
工作流：aws.health AWS_RISK_CREDENTIALS_EXPOSED 的 EventBridge 规则到 Step Functions。
BeforeAllowTraffic 生命周期挂钩
Lambda 的预流量挂钩，可以在转移流量之前等待数据库迁移或种子数据完成。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Lambda 的预流量挂钩，可以在转移流量之前等待数据库迁移或种子数据完成。
● 场景匹配：Lambda 的预流量挂钩，可以在转移流量之前等待数据库迁移或种子数据完成。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 在流量已经转移后运行，因此它无法阻止因不完整的数据库更改而导致的错误。
● Canary 本身并不能验证数据库准备情况，并且如果更改未完成，也不会阻止转变。
● CodeDeploy 中的 Lambda 不支持生命周期事件。
工作流：BeforeAllowTraffic 生命周期挂钩。
使用 SourceDBInstanceIdentifier 的 CloudFormation 只读副本，等待它捕获
升级只读副本并升级它可以在源继续提供流量的同时提供较短的切换窗口。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：升级只读副本并升级它可以在源继续提供流量的同时提供较短的切换窗口。
● 场景匹配：升级只读副本并升级它可以在源继续提供流量的同时提供较短的切换窗口。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 通过 CloudFormation 更改实时实例上的 EngineVersion 可能会触发替换或破坏性就地升级，从而增加停机时间。
● DBEngineVersion 不是有效的 AWS::RDS::DBInstance 属性，因此此更改将无法通过验证。
● 虽然 DMS 可以减少停机时间，但它为可以使用 RDS 只读副本处理的同引擎主要升级增加了不必要的复杂性。
工作流：使用 SourceDBInstanceIdentifier 通过 CloudFormation 创建只读副本，等待其赶上 → 将副本的 EngineVersion 更新为 8.0 → 升级它，→ 将应用程序指向升级的实例。
75% CPU 时的目标跟踪加上计划操作设置最小值 6
目标跟踪保持利用率设定点，而计划的操作则调整已知峰值和低谷的基线容量，以提高效率和可用性。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：目标跟踪保持利用率设定点，而计划的操作则调整已知峰值和低谷的基线容量，以提高效率和可用性。
● 场景匹配：目标跟踪保持利用率设定点，而计划的操作则调整已知峰值和低谷的基线容量，以提高效率和可用性。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 可以降低成本，但存在中断风险，并且无法维持利用率目标或处理可预测的基线。
● 预测所需容量有助于计时，但不会使平均 CPU 接近目标或直接调整基线最小值。
● 带外终止实例很脆弱，Auto Scaling 组将取代它们；这不能正确管理基线容量。
工作流：75% CPU 时的目标跟踪 → 预定操作设置在高峰时最少为 6，非高峰时最少为 3。
每 30 次调用一次 AWS Lambda 函数的 Amazon EventBridge 规则
调用 Lambda 的计划 EventBridge 规则可以将 EC2 与 SSM 托管清单进行比较，并针对未覆盖的实例发送警报。 Systems Manager Inventory 本身收集软件包。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：调用 Lambda 的计划 EventBridge 规则可以将 EC2 与 SSM 托管清单进行比较，并针对未发现的情况发送警报。
● 场景匹配：调用 Lambda 的计划 EventBridge 规则可以将 EC2 与 SSM 托管清单进行比较，并针对未发现的情况发送警报。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Run Command 只能定位已托管的实例，因此无法找到非托管实例。
● Inspector 重点关注漏洞发现和覆盖范围，而不是生成通用软件清单或检测未托管的实例。
● 与使用内置清单相比，工作量更大且特定于操作系统，并且本质上不会检测非托管实例。
工作流：创建一条 Amazon EventBridge 规则，每 30 分钟调用一次 AWS Lambda 函数，以将 EC2 实例与 Systems Manager 托管实例进行比较，并就差异发出通知 → 安装 SSM 代理。
具有每个任务重试功能的 AWS Step Functions
提供无服务器状态编排、内置重试和捕获器，以及仅重新运行失败步骤的能力。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：提供无服务器状态编排、内置重试和捕获器，以及仅重新运行失败步骤的能力。
● 场景匹配：提供无服务器状态编排、内置重试和捕获器，以及仅重新运行失败步骤的能力。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 较旧的工作流服务需要决策者和工作人员，导致比无服务器状态机更高的操作复杂性。
● 解耦阶段，但需要自定义状态管理和编排逻辑，增加了运营负担。
● 与无服务器编排器相比，管理 DAG，但会增加环境和工作人员管理开销。
工作流：具有按任务重试功能的 AWS Step Functions。
CloudWatch 代理 procstat 以及触发 Systems Manager Run 的 CloudWatch 警报
Procstat 会发出每个进程的指标，并且警报可以调用 SSM Run Command 仅重新启动失败的进程，而不影响 Auto Scaling 容量。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Procstat 会发出每个进程的指标，并且警报可以调用 SSM Run Command 仅重新启动失败的进程，而不影响 Auto Scaling 容量。
● 场景匹配：Procstat 会发出每个进程的指标，并且警报可以调用 SSM Run Command 仅重新启动失败的进程，而不影响 Auto Scaling 容量。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 终止并替换实例，从而减慢恢复速度并不必要地减少容量。
● 自动恢复响应系统状态检查失败，而不是单个进程崩溃，并重新启动整个实例。
● 通过待机循环实例会减少容量并重新启动整个实例，而不仅仅是失败的进程。
工作流：将 CloudWatch 代理 procstat 与 CloudWatch 警报结合使用，触发 Systems Manager Run Command 来重新启动工作线程。
用于 EBS 加密的 AWS Config 托管规则，并通过 EventBridge 过滤到 SNS
托管规则持续评估 EBS 卷加密，EventBridge 将该规则的 NON_COMPLIANT 事件过滤到 SNS，以获取 AWS Config 中的目标警报和可审计历史记录。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：托管规则持续评估 EBS 卷加密，EventBridge 将该规则的 NON_COMPLIANT 事件过滤到 SNS，以获取 AWS Config 中的目标警报和可审核历史记录。
● 场景匹配：托管规则持续评估 EBS 卷加密，EventBridge 会将该规则的 NON_COMPLIANT 事件过滤到 SNS。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Security Hub 聚合了来自 AWS Config 等来源的发现结果，并增加了设置和成本，使其对于单一控制来说不那么直接。
● 默认加密会阻止新的未加密卷，但不会检测现有未加密资源或发出警报，并且不提供有针对性的通知。
● AWS Config 的 SNS 传输通道会发出广泛的通知，并且无法隔离单个规则，从而导致出现嘈杂、无针对性的警报。
工作流：用于 EBS 加密的 AWS Config 托管规则，并通过 EventBridge 过滤到 SNS。
使用 AWS Systems Manager Patch Manager 定义补丁基准并使用
Systems Manager Patch Manager 通过基线自动进行修补，而 AWS Config 管理规则（例如按 ID 批准的amis-by-id 检查 AMI 合规性），并且警报可以通知检测到的偏差。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Systems Manager Patch Manager 通过基线自动进行修补，同时 AWS Config 管理规则，例如按 ID 批准的amis 检查 AMI。
● 场景匹配：Systems Manager Patch Manager 通过基线自动进行修补，而 AWS Config 则管理规则，例如按 ID 批准的amis 检查 AMI。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● GuardDuty 专注于威胁检测，不会评估补丁级别或验证批准的 AMI 使用情况，因此它会这样做。
● 拒绝使用 IAM 启动会阻止开发人员使用未经批准的 AMI，这与允许这些启动的要求相冲突。
工作流：使用 AWS Systems Manager Patch Manager 定义补丁基准，并使用 AWS Config 托管规则根据批准的 AMI 列表评估实例，并针对任何不合规资源发出 CloudWatch 警报。
将成功或失败从 Lambda 发送到 CloudFormation ResponseURL
自定义资源必须将结果发送到预签名的 ResponseURL，以便 CloudFormation 可以转换堆栈状态。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：自定义资源必须将结果发送到预签名的 ResponseURL，以便 CloudFormation 可以转换堆栈状态。
● 场景匹配：自定义资源必须将结果发送到预签名的 ResponseURL，以便 CloudFormation 可以转换堆栈状态。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 权限并不表示自定义资源已完成，也不需要完成堆栈操作。
● 正常的 Lambda 退出不会通知 CloudFormation；它仍然等待自定义资源响应。
● 等待条件和 cfn-signal 适用于 WaitCondition 或 EC2 CreationPolicy，而不适用于自定义资源。
工作流：将成功或失败从 Lambda 发送到 CloudFormation ResponseURL。
用于 EC2 Auto Scaling 启动和终止事件的 Amazon EventBridge 规则
EventBridge 可以匹配 Auto Scaling 生命周期事件并调用 Systems Manager Run Command 以近乎实时地对托管批处理实例执行更新。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：EventBridge 可以匹配 Auto Scaling 生命周期事件并调用 Systems Manager Run Command 来执行更新。
● 场景匹配：EventBridge 可以匹配 Auto Scaling 生命周期事件并调用 Systems Manager Run Command 来执行更新。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 依赖持续轮询和自定义代码，效率低下且不是事件驱动的。
● AWS Config 专注于配置合规性，可能会引入延迟，使其不适合近乎实时的 Auto Scaling 生命周期反应。
● Auto Scaling 生命周期事件是通过 EventBridge 而不是 CloudWatch Logs 传递的，并且与使用 SSM 相比，使用 Lambda SSH 访问 EC2 很脆弱。
工作流：为 EC2 Auto Scaling 启动和终止事件创建 Amazon EventBridge 规则，以 AWS Systems Manager Run Command 更新批处理实例配置。
API Gateway 阶段上的金丝雀版本服务 v2，部署
API Gateway 阶段金丝雀原生地将一定比例的请求拆分到金丝雀部署，并在 CloudWatch 中公开详细指标。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：API Gateway 阶段金丝雀原生地将一定比例的请求拆分到金丝雀部署并公开详细的指标。
● 场景匹配：API Gateway 阶段金丝雀原生地将一定比例的请求拆分到金丝雀部署并公开详细的指标。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Lambda 别名不控制新路径的 API Gateway 路由，并且 OpenSearch 不是本机指标。
● Route 53 权重在 DNS 上运行，不能针对单个 API 路径，CloudTrail 不适合该路径。
● 别名金丝雀会影响 Lambda 版本，但不会为新路由提供 API Gateway 阶段级流量转移。
工作流：在服务 v2 的 API 网关阶段启用金丝雀版本 → 将更新的 API 部署到该阶段，将一小部分流量引导到金丝雀部署，并监控 CloudWatch 指标。
每个帐户和区域中的标签编辑器可查找并批量标记现有的
标签编辑器可以发现和批量应用标签，帮助修复当前未标记的资源。使用 aws:RequestTag 或 aws:TagKeys 条件的 SCP 可以阻止省略强制标签的 Create* 操作。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：标签编辑器可以发现和批量应用标签，帮助修复当前未标记的资源。
● 场景匹配：标签编辑器可以发现和批量应用标签，帮助修复当前未标记的资源。使用 aws:RequestTag 的 SCP。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 成本分配标签仅在标签存在后才影响成本报告；它们不应用标签或阻止资源创建。
● 成本类别对支出进行分组，但既不标记资源也不强制执行标记要求。
● 标签策略对标签进行标准化和报告，但不会阻止不合规的资源创建或自动应用标签。
工作流：在每个账户和区域中使用标签编辑器查找并批量标记现有资源 → 在组织根目录应用 SCP，拒绝创建没有所需标签的资源。
Amazon Route 53 基于延迟的路由，具有运行状况检查功能，可引导用户访问
基于延迟的路由将客户端发送到跨区域的延迟最低、运行状况良好的终端节点。在欧洲创建区域 ALB 和 Auto Scaling 容量使计算更接近欧洲。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：基于延迟的路由将客户端发送到跨区域的延迟最低、运行状况良好的终端节点。
● 场景匹配：基于延迟的路由将客户端发送到跨区域的延迟最低、运行状况良好的终端节点。创建区域 ALB 和 Auto Scaling。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● CloudFront 可以帮助缓存静态内容，但它无法解决远程区域或提供的写入延迟问题。
● DynamoDB 不提供通用的跨区域复制；全局表是受支持的方法。
● ALB 和目标组是区域资源，无法注册其他区域的实例。
工作流：配置 Amazon Route 53 基于延迟的路由并进行运行状况检查，以将用户引导至最近的 ALB → 在 eu-west-3 中部署新的应用程序负载均衡器和 Auto Scaling 组并进行配置。
具有约束的 AWS Service Catalog
启用版本化产品和启动约束以强制执行标签并控制产品的可用位置。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：启用版本化产品和启动约束以强制执行标签并控制产品的可用位置。
● 场景匹配：启用版本化产品和启动约束以强制执行标签并控制产品的可用位置。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 通过规则提供侦探治理，但无法阻止不合规的启动或提供版本化模板。
● 可以限制区域和使用标签条件，但缺乏版本化产品管理和自助服务目录。
● 协调跨账户和区域的堆栈部署，但不强制执行强制标签或模板版本控制。
工作流：具有约束的 AWS Service Catalog。
BeforeAllowTraffic 钩子，为 live-v3 阶段调用验证器 Lambda
在轮班前运行并允许进行门控，直到 API 响应。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：在轮班前运行并允许进行门控，直到 API 响应。
● 场景匹配：在轮班前运行并允许进行门控，直到 API 响应。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 警报可以触发回滚，但不会阻止 Lambda 部署的预流量阶段。
● 较早进行测试，但未与 CodeDeploy 的预流量门集成。
● 在流量转移后运行，因此无法防止不健康的切换。
工作流：BeforeAllowTraffic 挂钩，为 live-v3 阶段调用验证器 Lambda。
在账户 A 中，创建客户管理的 AWS KMS 密钥，该密钥允许
账户 B 中的管道操作必须能够读取和解密账户 A 中存储的工件，这需要 KMS 权限和 S3。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：账户 B 中的管道操作必须能够读取和解密账户 A 中存储的工件。
● 场景匹配：账户 B 中的管道操作必须能够读取和解密账户 A 中存储的工件。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● CloudFormation 执行角色必须存在于创建资源的目标账户中，而不是存在于源账户中。
● 将信任指向错误的方向，并且不会为管道提供帐户 B 中的角色。
● SCP 设置了权限护栏，无法授予跨账户操作所需的权限或信任关系。
工作流：在账户 A 中 → 创建一个客户管理的 AWS KMS 密钥，允许账户 A 中的 CodePipeline 服务角色和账户 B 中的委托人使用该密钥，并创建一个 S3。
AWS App2Container 用于发现 Java 工作负载，并将其容器化以用于 Amazon ECS
App2Container 清点 Java 应用程序、构建容器映像和任务定义，并可以引导 CodeBuild 和 CodeDeploy 管道。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：App2Container 清点 Java 应用程序、构建容器映像和任务定义，并可以引导 CodeBuild 和 CodeDeploy 管道。
● 场景匹配：App2Container 清点 Java 应用程序、构建容器映像和任务定义，并可以引导 CodeBuild 和 CodeDeploy 管道。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Proton 组织和部署标准化基础设施模板，但不会重构或容器化现有应用程序。
● 应用程序迁移服务可以提升和转移虚拟机，而无需将应用程序转换为容器或生成以容器为中心的 CI/CD。
● Copilot 简化了新容器应用程序的部署，但不分析现有虚拟机或迁移旧工作负载。
工作流：使用 AWS App2Container 发现 Java 工作负载，将其容器化以用于 Amazon ECS，并使用 CodeBuild 和 CodeDeploy 让 A2C 搭建 CI/CD 管道。
实例变为 InService 后立即将其置于 Standby 状态
备用会将实例从流量和扩展活动中移除，同时将其保留在组中，从而允许无限的时间进行故障排除。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：备用会将实例从流量和扩展活动中移除，同时将其保留在组中，从而允许无限的时间进行故障排除。
● 场景匹配：备用会将实例从流量和扩展活动中删除，同时将其保留在组中，从而允许无限的时间进行故障排除。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 阻止新实例启动，但不隔离或保留未通过运行状况检查的特定实例。
● 终止保护会阻止手动终止，但 Auto Scaling 组仍然可以在运行状况检查失败时终止实例。
● 终止钩子是有时间限制的，并且仅在终止期间触发，这不提供开放式的服务中调试窗口。
工作流：实例变为 InService 后立即将其置于 Standby 状态。
亚马逊 GuardDuty
GuardDuty 是一项托管威胁检测服务，可分析 CloudTrail 事件、VPC 流日志和 DNS 日志，以识别受损实例和加密货币挖掘等恶意活动。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：GuardDuty 是一项托管威胁检测服务，可分析 CloudTrail 事件、VPC 流日志和 DNS 日志，以识别受损实例和加密货币挖掘等恶意活动。
● 场景匹配：GuardDuty 是一项托管威胁检测服务，可分析 CloudTrail 事件、VPC 流日志和 DNS 日志，以识别受损实例和加密货币挖掘等恶意活动。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Macie 专注于发现和保护 Amazon S3 中的敏感数据，不会检测受损的 EC2 实例或账户级威胁。
● Inspector 对工作负载执行自动漏洞和暴露评估，但不提供来自 CloudTrail、VPC 流日志和 DNS 数据的持续威胁检测。
● VPC 流日志仅捕获网络流量元数据，需要外部分析，不提供内置威胁情报或异常检测。
工作流：亚马逊 GuardDuty。
AWS WAF 通过 S3 目标记录到 Kinesis Data Firehose
配置 AWS WAF 以登录到 Kinesis Data Firehose 可提供详细的每个请求 JSON 记录，这些记录可以持久存储在 S3 中以供分析和保留。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：配置 AWS WAF 以登录到 Kinesis Data Firehose 可提供详细的每个请求 JSON 记录，这些记录可以持久存储在 S3 中以供分析和保留。
● 场景匹配：配置 AWS WAF 以登录到 Kinesis Data Firehose 可提供详细的每个请求 JSON 记录，这些记录可以持久存储在 S3 中以供分析和保留。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● CloudWatch 指标显示计数器和速率，而不是具有匹配规则详细信息的每个请求日志记录。
● AWS WAF 直接写入 Kinesis Data Firehose；不需要 Kinesis Data Streams 流。
● ALB 访问日志是单独的，不包含 AWS WAF 规则评估详细信息或匹配的规则。
工作流：使用 S3 目标启用 AWS WAF 日志记录到 Kinesis Data Firehose。
具有委派管理员的 GuardDuty 组织；通过 EventBridge 将结果路由到 S3
GuardDuty 通过委派管理员支持组织范围内的启用，并将结果发布到 EventBridge，EventBridge 可以通过 Firehose 传送到 S3。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：GuardDuty 通过委派管理员支持组织范围内的启用，并将结果发布到 EventBridge，EventBridge 可以通过 Firehose 传送到 S3。
● 场景匹配：GuardDuty 通过委派管理员支持组织范围内的启用，并将结果发布到 EventBridge，EventBridge 可以通过 Firehose 传送到 S3。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Inspector 重点关注漏洞/暴露，而不是通过 EC2 攻击的日志分析进行托管威胁检测。
● Security Hub 聚合并规范化发现结果，但本身不执行 EC2 威胁检测。
● 缺乏集中式组织管理，并且 Kinesis Data Streams 在没有自定义使用者的情况下不会写入 S3。
工作流：通过委派管理启用 GuardDuty 组织→通过 Kinesis Data Firehose 将结果通过 EventBridge 路由到 S3。
一个在运行时读取 CODEBUILD_SOURCE_VERSION 环境变量的 buildspec.yml
这使用指示源版本或分支的内置变量，从而实现简单且可扩展的工件命名。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这使用指示源版本或分支的内置变量，从而实现简单且可扩展的工件命名。
● 场景匹配：这使用指示源版本或分支的内置变量，从而实现简单且可扩展的工件命名。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 引入不必要的组件和后处理，而不是使用构建期间可用的上下文。
● 导致项目过度蔓延并需要每个分支进行手动管理，这不是最简单的解决方案。
● 许多管道增加了显着的操作开销，并且对于基本的基于分支的命名来说是不必要的。
工作流：创建一个在运行时读取 CODEBUILD_SOURCE_VERSION 环境变量的 buildspec.yml 并在工件名称中引用它。
启动适用于 S3 的 Amazon CloudFront 并部署 DynamoDB Accelerator
CloudFront 在边缘位置缓存 S3 对象，DAX 为 DynamoDB 读取提供内存缓存，从而减少重复读取延迟。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudFront 在边缘位置缓存 S3 对象，DAX 为 DynamoDB 读取提供内存缓存，从而减少重复读取延迟。
● 场景匹配：CloudFront 在边缘位置缓存 S3 对象，DAX 为 DynamoDB 读取提供内存缓存，从而减少重复读取延迟。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 传输加速可加快上传到 S3 的速度，并且增加 RCU 不会缓存重复读取或提供全局边缘缓存。
● Lambda@Edge 不是大规模缓存，全局表复制数据但不会减少重复读取负载。
● Redis 本身并不缓存 DynamoDB API 读取，MediaStore 的目标是媒体工作流程而不是一般的 S3 静态资产。
工作流：设置适用于 S3 的 Amazon CloudFront 并部署 DynamoDB Accelerator。
每个逻辑组件的模块化 CloudFormation 模板并通过输出共享所需的值
这种方法干净地解耦堆栈并使用跨堆栈引用来实现可靠的价值共享和重用。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这种方法干净地解耦堆栈并使用跨堆栈引用来实现可靠的价值共享和重用。
● 场景匹配：这种方法干净地解耦堆栈并使用跨堆栈引用来实现可靠的价值共享和重用。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 将应用程序迁移工具与基础设施即代码混合在一起，并保持脆弱的整体，这对于频繁的更改来说并不理想。
● 嵌套堆栈是有效的，但保持紧密的生命周期耦合，并且缺乏干净的堆栈间重用所需的显式导出输出。
● 在 DynamoDB 中存储输出并不是用于连接堆栈的 CloudFormation 最佳实践，并且会绕过本机输出和导入机制。
工作流：每个逻辑组件创建模块化 CloudFormation 模板，并通过 Export 和 Fn::ImportValue 的输出共享所需的值，模板版本在 GitHub 中。
Amazon FSx for NetApp ONTAP 与 SnapMirror 跨区域复制
在同一文件系统上提供多协议 SMB 和 NFS，以及高效的增量 SnapMirror 复制，非常适合试点灾难恢复。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：在同一文件系统上提供多协议 SMB 和 NFS，以及高效的增量 SnapMirror 复制，非常适合试点灾难恢复。
● 场景匹配：在同一文件系统上提供多协议 SMB 和 NFS，以及高效的增量 SnapMirror 复制，非常适合试点灾难恢复。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Lustre 不支持 SMB，并且 AWS Backup 副本是定期的，而不是近乎连续的。
● 仅支持SMB；没有NFS和DFSR不是存储级别的、近乎连续的跨Region复制。
● 将协议拆分到两个后端并使用批量同步，而不是单个多协议存储或近乎连续的复制。
工作流：Amazon FSx for NetApp ONTAP 与 SnapMirror 跨区域复制。
具有跨区域操作和每区域工件存储桶的单个 CodePipeline
CodePipeline 支持跨区域操作，并在每个区域创建单独的工件存储，满足数据驻留。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CodePipeline 支持跨区域操作，并在每个区域创建单独的工件存储，满足数据驻留。
● 场景匹配：CodePipeline 支持跨区域操作，并在每个区域创建单独的工件存储，满足数据驻留。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 有效，但会增加不必要的运营开销；单个管道可以更有效地协调跨区域操作。
● 对于多区域基础设施配置很有用，但不适用于 CodePipeline 中的 CI/CD 编排或工件驻留。
● 将工件集中在一个存储桶中违反了将工件保留在各自区域内的要求。
工作流：具有跨区域操作和每个区域工件存储桶的单个 CodePipeline。
AWS Step Functions 编排 AWS Lambda 任务，由 Amazon EventBridge 触发
这提供了无服务器编排，具有用于多区域回退的重试和条件分支、用于审计的本机执行历史记录、计划运行以及发送最终结果的干净方式。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这提供了无服务器编排，具有用于多区域回退的重试和条件分支、用于审核和计划的本机执行历史记录。
● 场景匹配：这提供了无服务器编排，具有用于多区域回退的重试和条件分支、用于审核和计划的本机执行历史记录。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 将所有逻辑集中在一个 Lambda 中，超时时间为 15 分钟，并依赖于不进行跟踪的 AWS Config。
● 该方法引入了单点故障和操作开销，并且缺乏托管重试和状态编排。
● 与简单的日常备份工作流程相比，MWAA 虽然功能强大，但操作起来较繁重，而且效率较低。
工作流：AWS Step Functions 编排 AWS Lambda 任务，由 Amazon EventBridge 触发，并通过 Amazon SNS 发出通知。
非空S3桶；将 Lambda 支持的自定义资源添加到空对象并
CloudFormation 无法删除非空存储桶，因此自定义资源必须在删除事件期间删除所有对象、版本和删除标记。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudFormation 无法删除非空存储桶，因此自定义资源必须在删除事件期间删除所有对象、版本和删除标记。
● 场景匹配：CloudFormation 无法删除非空存储桶，因此自定义资源必须在删除事件期间删除所有对象、版本和删除标记。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● DeletionPolicy 控制资源的保留或删除，但不清除存储桶内容。
● 堆栈策略限制更新，而不限制堆栈删除，并且不会解决存储桶删除失败的问题。
● 等待条件不能解决存储桶必须为空才能删除的约束。
工作流：非空 S3 存储桶 → 将 Lambda 支持的自定义资源添加到删除堆栈上的空对象和版本。
用于 EC2 漏洞和暴露扫描的 Amazon Inspector，安装 CloudWatch Agent
Amazon Inspector 持续检测 EC2 上的 CVE 和意外网络可达性，而 CloudWatch Logs 会聚合实例登录日志，而 CloudTrail 则提供 API 活动审核功能。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Amazon Inspector 持续检测 EC2 上的 CVE 和意外网络可达性，而 CloudWatch Logs 则聚合实例登录日志。
● 场景匹配：Amazon Inspector 持续检测 EC2 上的 CVE 和意外网络可达性，而 CloudWatch Logs 则聚合实例登录日志。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● GuardDuty 提供威胁检测和异常警报，但不执行主机漏洞扫描或收集操作系统登录信息。
● SSM 代理和自动化支持修补工作流程，但它们不是漏洞管理扫描器，并且不进行评估。
● ECR 扫描评估容器映像，而不评估 EC2 主机操作系统或其登录活动。
工作流：部署 Amazon Inspector 进行 EC2 漏洞和暴露扫描 → 安装 CloudWatch 代理以将登录日志转发到 CloudWatch Logs，并将 CloudTrail 事件发送到 CloudWatch Logs 进行集中审核。
使用 AWS Health API 在 CodePipeline 中进行 Lambda 预检查以阻止运行
实施健康感知门，当区域发生活动事件时，该门会快速失败或暂停，从而防止运行中停顿和浪费成本。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：实施健康感知门，当区域发生活动事件时，该门会快速失败或暂停，从而防止运行中停顿和浪费成本。
● 场景匹配：实施健康感知门，当区域发生活动事件时，该门会快速失败或暂停，从而防止运行中停顿和浪费成本。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 稍后重试，但不会在活跃的区域事件期间阻止启动，因此运行仍可能在部署过程中失败。
● 降低切换风险，但无法避免在区域卫生事件期间启动并增加成本。
● 在正在进行的区域事件期间重复重试会浪费时间并且不太可能成功。
工作流：使用 AWS Health API 在 CodePipeline 中进行 Lambda 预检查，以阻止活动区域事件期间的运行。
CloudWatch Logs 订阅过滤器，将匹配的日志事件发送到
这会将 CloudWatch Logs 连接到 Lambda 进行标记，并使用 EventBridge 计划在所需的时间窗口内自动终止标记的实例。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这会将 CloudWatch Logs 连接到 Lambda 进行标记，并使用 EventBridge 计划自动终止标记的实例。
● 场景匹配：这会将 CloudWatch Logs 连接到 Lambda 进行标记，并使用 EventBridge 计划自动终止标记的实例。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● CloudTrail 记录 AWS API 调用，而不是操作系统级 SSH 或 RDP 登录，因此不会检测手动登录。
● CloudWatch Logs 订阅无法以 Step Functions 为目标，并且每日节奏存在错过 12 小时终止要求的风险。
● AWS Config 评估配置状态，并且不会提取实例操作系统日志或运行时登录事件，因此它不能。
工作流：创建一个 CloudWatch Logs 订阅过滤器，将匹配的日志事件发送到 AWS Lambda 函数，标记生成登录条目的实例，并使用 Amazon EventBridge 计划规则。
标记任何具有端口 22 的安全组的 AWS Config 规则
AWS Config 规则可以评估端口 22 上 0.0.0.0/0 的安全组并向 Amazon SNS 发布合规性通知。使用 EventBridge 和 Lambda 进行轮询。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：AWS Config 规则可以评估端口 22 上 0.0.0.0/0 的安全组并向其发布合规性通知。
● 场景匹配：AWS Config 规则可以评估端口 22 上 0.0.0.0/0 的安全组并向其发布合规性通知。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● AWS Config 修复旨在使用 Systems Manager Automation Runbook，而不是直接 Lambda 调用，因此并非如此。
● Security Hub 不会获取 Trusted Advisor 发现结果，也不会在本机自动修复它们，因此它无法实现。
工作流：创建一条 AWS Config 规则，标记端口 22 对 0.0.0.0/0 打开的任何安全组，并在不合规时向 SNS 主题发送通知 → 安排 Amazon EventBridge 规则。
AWS Health 通过 EventBridge 调用 Lambda 到 Slack
AWS Health 发布特定于账户的计划更改事件，EventBridge 可以将这些事件路由到 Lambda，然后将其发布到 Slack。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：AWS Health 发布特定于账户的计划更改事件，EventBridge 可以将这些事件路由到 Lambda，然后将其发布到 Slack。
● 场景匹配：AWS Health 发布特定于账户的计划更改事件，EventBridge 可以将这些事件路由到 Lambda，然后将其发布到 Slack。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 实例状态检查显示运行状况问题，但不提供 AWS Health 计划维护或停用事件。
● Config 和 Trusted Advisor 评估配置和最佳实践，而不是 AWS 计划的维护通知。
● EC2 状态更改事件不包括 AWS Health 计划维护或停用。
工作流：AWS Health 通过 EventBridge 向 Slack 调用 Lambda。
将管理事件传送到 CloudWatch Logs 日志的 CloudTrail 跟踪
CloudTrail 记录 S3 控制平面 API 调用，当流式传输到 CloudWatch Logs 时，可以按指标进行过滤并发出警报以立即收到通知。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudTrail 记录 S3 控制平面 API 调用，当流式传输到 CloudWatch Logs 时，可以通过以下方式进行过滤。
● 场景匹配：CloudTrail 记录 S3 控制平面 API 调用，并且在流式传输到 CloudWatch Logs 时，可以通过以下方式进行过滤。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● S3服务器访问日志记录请求访问详细信息，而不是控制平面策略更改，并且不适合检测策略更新。
● S3 事件通知不会针对策略更改（例如 PutBucketPolicy 或 DeleteBucketPolicy）发出事件。
● EventBridge 不会直接过滤 CloudWatch Logs 组内容，因此此设置不会检测日志中的策略更改。
工作流：创建将管理事件传送到 CloudWatch Logs 日志组的 CloudTrail 跟踪 → 为 PutBucketPolicy 和 DeleteBucketPolicy 添加指标筛选器，并配置 CloudWatch 警报以在匹配时进行通知。
Amazon RDS 上使用 SQL Server 的无状态 EC2 Auto Scaling；使用运动
Kinesis Data Firehose 提供对 S3 的托管、近乎实时的交付，并可以通过 S3 临时存储桶加载 Redshift，从而满足无状态和低延迟的要求。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Kinesis Data Firehose 提供对 S3 的托管、近乎实时的交付，并可以通过 S3 临时存储桶加载 Redshift。
● 场景匹配：Kinesis Data Firehose 提供对 S3 的托管、近乎实时的交付，并可以通过 S3 临时存储桶加载 Redshift。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Glue 爬虫仅创建元数据，不会将流数据加载到 Redshift 中； MSK 仍然需要额外的 ETL 和暂存，从而增加了复杂性和延迟。
● EventBridge 不直接传送到 S3 或 Redshift，也不是为高吞吐量点击流摄取而设计的。
● Kinesis Data Streams 本身并不下沉到 S3 或 Redshift；它需要 Firehose、Lambda 或自定义应用程序等使用者。
工作流：在 Amazon RDS 上使用 SQL Server 进行无状态 EC2 Auto Scaling → 使用 Kinesis Data Firehose 到 S3，使用另一个 Firehose 到 Redshift。
初始轮换替换了密码，同时应用程序保留了缓存值
启用轮换会更改数据库密码并创建新的 AWSCURRENT 值。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：启用轮换会更改数据库密码并创建新的 AWSCURRENT 值。
● 场景匹配：启用轮换会更改数据库密码并创建新的 AWSCURRENT 值。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● KMS 拒绝通常也会阻止轮换之前的秘密检索。
● 如果存在其他网络路径，则 VPC 终端节点是可选的。
● 当省略 VersionStage 时，GetSecretValue 默认返回 AWSCURRENT。
工作流：初始轮换替换了密码，同时应用程序保留了缓存值。
使用 AWS Elastic Beanstalk 使用负载平衡、自动扩展的 Node.js 环境以及
Elastic Beanstalk 支持零停机部署策略和简单回滚，并且外部托管 RDS 允许共享数据库，并避免在环境终止时删除数据库。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Elastic Beanstalk 支持零停机部署策略和简单回滚，并且外部托管 RDS 允许共享数据库和。
● 场景匹配：Elastic Beanstalk 支持零停机部署策略和简单回滚，并且外部托管 RDS 允许共享数据库和。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 虽然 ECS 可以扩展和处理滚动更新，但轻松回滚通常需要额外的工具，例如 CodeDeploy 或自定义工具。
● 将 RDS 附加到 Beanstalk 环境会将其生命周期与应用程序耦合起来，并且存在环境拆卸时被删除的风险。
● EBS快照是一种备份机制，而不是应用程序部署回滚策略，并且不保证零停机发布。
工作流：使用负载平衡、自动扩展的 Node.js 环境进行 AWS Elastic Beanstalk 部署，并在 Beanstalk 环境外部创建 Amazon RDS MySQL 实例。
CloudWatch 代理到 CloudWatch Logs、Firehose 到 S3、使用 Athena 进行查询
统一代理支持混合收集，S3 提供低成本存储，Athena 提供最少操作的无服务器查询。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：统一代理支持混合收集，S3 提供低成本存储，Athena 提供最少操作的无服务器查询。
● 场景匹配：统一代理支持混合收集，S3 提供低成本存储，Athena 提供最少操作的无服务器查询。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 直接在 CloudWatch Logs 中查询是可行的，但对于审计式用例来说，长期保留和查询成本更高。
● 适用于搜索和仪表板，但需要管理容量，并且通常比 S3 加 Athena 的审计成本更高。
● 重点关注使用 OCSF 的安全源，不适用于从混合服务器收集一般操作系统或应用程序日志。
工作流：CloudWatch 代理到 CloudWatch Logs，Firehose 到 S3 → 使用 Athena 查询。
AWS CloudFormation StackSets 具有委派管理员，可将相同的堆栈部署到
StackSets 本身支持中央管理员自动、一致的多区域部署，同时保持每个区域的堆栈隔离。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：StackSets 本身支持中央管理员自动、一致的多区域部署，同时保持每个区域的堆栈隔离。
● 场景匹配：StackSets 本身支持中央管理员自动、一致的多区域部署，同时保持每个区域的堆栈隔离。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 可以跨区域编排步骤，但不是统一多区域基础设施配置的最直接机制。
● 更改集预览单个堆栈的更新，并且不会协调部署到多个区域。
● 可能，但更复杂，并且缺乏像 StackSets 这样的原生队列式多区域堆栈管理。
工作流：AWS CloudFormation StackSets 具有委派管理员，可将相同的堆栈部署到目标区域。
Amazon EventBridge 规则将 S3 对象 PUT 到目标 ECS RunTask 和
这是最直接的事件驱动设置，使用 EventBridge 和 CloudTrail 数据事件来启动任务并使用 Lambda 来停止任务。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这是最直接的事件驱动设置，使用 EventBridge 和 CloudTrail 数据事件来启动任务并使用 Lambda 来停止任务。
● 场景匹配：这是最直接的事件驱动设置，使用 EventBridge 和 CloudTrail 数据事件来启动任务和 a。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 添加不必要的间接和警报并不是响应单个 S3 对象事件的最直接方式。
● 容量提供者管理计算容量，而不是事件驱动的所需任务数量的扩展，使得这种方法过于复杂且不一致。
● 虽然对于排队批处理工作负载来说功能强大，但这对于 S3 事件触发器来说并不是最简单的，并且引入了额外的编排组件。
工作流：为 S3 对象 PUT 创建 Amazon EventBridge 规则以定位 ECS RunTask，并为 S3 对象 DELETE 创建 Amazon EventBridge 规则以调用对所有正在运行的任务调用 StopTask 的 Lambda。
AWS SAM 具有 CodeDeploy 流量转移、流量前和流量后挂钩以及 CloudWatch
SAM 的 DeploymentPreference 与 CodeDeploy 集成，以金丝雀或线性转移 Lambda 别名流量、运行验证挂钩并触发 CloudWatch 警报自动回滚以实现快速检测。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：SAM 的 DeploymentPreference 与 CodeDeploy 集成，以金丝雀或线性转移 Lambda 别名流量、运行验证挂钩和触发器。
● 场景匹配：SAM 的 DeploymentPreference 与 CodeDeploy 集成，以金丝雀或线性转移 Lambda 别名流量、运行验证挂钩和触发器。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● AppConfig 可以切换运行时行为，但它不会发布 Lambda 版本、转移别名流量或根据错误自动回滚部署。
● 更改集预览基础设施更改，但不提供 Lambda 金丝雀流量转移或生命周期测试，因此检测和回滚仍然缓慢且手动。
● CloudFormation 更改集没有针对 Lambda 的流量前或流量后测试挂钩，因此 CloudFormation 单独不支持此功能。
工作流：AWS SAM 具有 CodeDeploy 流量转移、流量前和流量后挂钩以及 CloudWatch 警报回滚。
S3 存储桶位于两个相距至少 700 英里的独立 AWS 区域
这是正确的，因为它使用不同的区域来满足距离要求，通过存储桶策略强制传输中加密，使用 SSE-S3 进行静态加密。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这是正确的，因为它使用不同的区域来满足距离要求，通过 a 强制传输中加密。
● 场景匹配：这是正确的，因为它使用不同的区域来满足距离要求，通过 a 强制传输中加密。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 不正确，因为 S3 是区域服务，可用区之间的距离不是 700 英里，而 Transfer Acceleration 也不是。
● 不正确，因为 IAM 角色无法强制执行仅 TLS 访问；必须使用存储桶策略来要求 HTTPS。
工作流：在相距至少 700 英里的两个独立 AWS 区域中创建 S3 存储桶，使用存储桶策略强制实施仅 HTTPS 访问，要求所有对象使用 SSE-S3，并启用 S3 跨区域复制。
使用 CodeDeploy 部署 API Gateway 和 Lambda 的 AWS 无服务器应用程序模型
SAM 将 Lambda 别名与 CodeDeploy 集成，通过自动回滚和最少的配置转移一小部分流量。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：SAM 将 Lambda 别名与 CodeDeploy 集成，通过自动回滚和最少的配置转移一小部分流量。
● 场景匹配：SAM 将 Lambda 别名与 CodeDeploy 集成，通过自动回滚和最少的配置转移一小部分流量。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 蓝/绿交换整个环境，而不是为 Lambda 流量转移到小用户群提供内置的、基于百分比的金丝雀。
● Route 53 故障转移是基于针对主要/次要场景的运行状况检查，并非针对渐进式金丝雀流量转移而设计。
● AppConfig 管理配置公开而不是代码部署，并且与内置 SAM 金丝雀相比引入了额外的组件。
工作流：通过将 DeploymentPreference 设置为 Canary5Percent5Minutes，使用 AWS 无服务器应用程序模型通过 CodeDeploy canary 部署 API Gateway 和 Lambda。
用于触发调用 Storage Gateway 的 Lambda 的夜间 EventBridge 计划
计划 RefreshCache 会更新文件网关的缓存清单，以便隔夜直接添加到 S3 的对象会在早上出现在共享中。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：计划 RefreshCache 会更新文件网关的缓存清单，以便隔夜直接添加到 S3 的对象会在早上出现在共享中。
● 场景匹配：计划 RefreshCache 会更新文件网关的缓存清单，以便隔夜直接添加到 S3 的对象出现在。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 更改用于在 S3 中加载文件的协议不会导致文件网关更新其缓存的目录列表或元数据。
● RefreshCache 仅受文件网关共享支持，卷网关不会公开此操作的文件语义。
● Storage Gateway 无法订阅 SQS 或 S3 事件以使其缓存失效，因此此集成不存在。
工作流：配置夜间 EventBridge 计划以触发调用 Storage Gateway RefreshCache 进行共享的 Lambda。
具有 HTTP 侦听器和基于路径的 Lambda 目标路由的应用程序负载均衡器
ALB 支持 HTTP 侦听器、基于路径的规则和 Lambda 目标组。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：ALB 支持 HTTP 侦听器、基于路径的规则和 Lambda 目标组。
● 场景匹配：ALB 支持 HTTP 侦听器、基于路径的规则和 Lambda 目标组。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● NLB 是第 4 层，不提供 HTTP 路径规则或 Lambda 目标。
● API Gateway 可以将路径路由到 Lambda，但其公共端点使用 HTTPS 而不是普通的 HTTP 侦听器。
● 函数 URL 映射到一个函数并使用 HTTPS。
工作流：具有 HTTP 侦听器和基于路径的 Lambda 目标组路由的应用程序负载均衡器。
Elastic Beanstalk 不可变更新
启动单独的临时 Auto Scaling 组，在运行状况检查后转移流量，保留 CNAME，并在失败时丢弃新组。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：启动单独的临时 Auto Scaling 组，在运行状况检查后转移流量，保留 CNAME，并在失败时丢弃新组。
● 场景匹配：启动单独的临时 Auto Scaling 组，在运行状况检查后转移流量，保留 CNAME，并在失败时丢弃新组。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 需要交换环境 CNAME，这涉及 DNS 更改。
● 批量更新现有实例，可以减少部署过程中的容量。
● 添加容量，但仍执行就地更新，并且不完全隔离新版本。
工作流：Elastic Beanstalk 不可变更新。
通过 AWS Organizations 实现 CloudWatch 跨账户可观察性
CloudWatch 与组织和 OAM 的跨账户可观察性为指标、日志和跟踪提供了一个监控账户。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudWatch 与组织和 OAM 的跨账户可观察性为指标、日志和跟踪提供了一个监控账户。
● 场景匹配：CloudWatch 与组织和 OAM 的跨账户可观察性为指标、日志和跟踪提供了一个监控账户。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 可行，但每个帐户必须手动链接。
● OpenSearch 可以集中日志，但它并不是所有 CloudWatch 指标、日志和 X-Ray 跟踪的本机统一视图。
● 指标流涵盖指标，而不是完整的日志和跟踪工作流程。
工作流：通过 AWS Organizations 实现 CloudWatch 跨账户可观察性。
AWS VM Import/Export 将本地 VMware 映像导入为 EC2
VM Import/Export 支持将 VMware 映像往返至 EC2，并将之前导入的实例导出回 vSphere 兼容格式以进行奇偶校验测试。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：VM Import/Export 支持将 VMware 映像往返至 EC2，并将之前导入的实例导出回 vSphere 兼容格式。
● 场景匹配：VM Import/Export 支持将 VMware 映像往返至 EC2，并将之前导入的实例导出回 vSphere 兼容格式。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Outposts 可以工作，但会在现有 VMware 中进行简单的迁移前映像验证，带来不必要的成本和运营开销。
● 不同的 Linux 发行版具有不同的内核、存储库和库，因此结果将无法准确反映 Amazon Linux 2 的行为。
工作流：使用 AWS VM Import/Export 将本地 VMware 映像作为 EC2 AMI 导入→在 EC2 上验证，→将导入的实例作为 VMware 兼容的 OVA 导出到 Amazon S3 并加载。
EC2 多可用区 ASG + ALB、Aurora 多写入器集群、Amazon Inspector
提供多可用区应用程序扩展、可写入可扩展且高度可用的数据库，以及使用 Inspector 进行持续漏洞评估。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：提供多可用区应用程序扩展、可写入可扩展且高度可用的数据库，以及使用 Inspector 进行持续漏洞评估。
● 场景匹配：提供多可用区应用程序扩展、可写入可扩展且高度可用的数据库，以及使用 Inspector 进行持续漏洞评估。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Macie发现S3中的敏感数据，不进行漏洞扫描； Aurora Global Database 不提供多写入器扩展。
● Security Hub 汇总发现结果，而不是扫描仪； RDS PostgreSQL 有一个写入器，并且不扩展写入。
● GuardDuty是威胁检测，不是漏洞扫描；单个写入器无法扩展写入。
工作流：EC2 多可用区 ASG + ALB、Aurora 多写入器集群、Amazon Inspector。
CloudWatch 代理将应用程序日志流式传输到 CloudWatch Logs + ASG 终止生命周期
代理将应用程序日志持续从实例推送到持久的集中式日志存储并保留。终止生命周期挂钩可以触发自动化，在实例关闭之前收集日志并将其上传到 S3。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：代理将应用程序日志持续从实例推送到持久的集中式日志存储并保留。
● 场景匹配：代理将应用程序日志持续从实例推送到持久的集中式日志存储并保留。终止生命周期。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 流日志捕获网络流量元数据，而不是应用程序或系统日志。
● ALB 访问日志记录负载均衡器处的请求元数据，而不是实例级应用程序日志。
● 手动检索在规模上并不可靠，并且可能会错过快速终止的实例。
工作流：CloudWatch 代理将应用程序日志流式传输到 CloudWatch Logs → ASG 终止生命周期挂钩，使用 EventBridge + Lambda + SSM Run Command 到 S3。
ALB 目标组运行状况检查配置不正确
错误的运行状况检查路径、端口或成功代码会导致新目标无法正常运行，从而导致AllowTraffic 失败且没有 CodeDeploy 日志错误。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：错误的运行状况检查路径、端口或成功代码会导致新目标无法正常运行，从而导致AllowTraffic 失败且没有 CodeDeploy 日志错误。
● 场景匹配：错误的运行状况检查路径、端口或成功代码会导致新目标无法正常运行，从而导致AllowTraffic 失败且没有 CodeDeploy 日志错误。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 如果在部署过程中删除实例，CodeDeploy 无法完成转换，AllowTraffic 阶段可能会失败。
● 先前版本中的挂钩脚本错误可能会破坏部署，但它们会在日志中显示，而不仅仅是在AllowTraffic 中。
● WAF 会过滤客户端请求，并且不会阻止 ALB 到目标的运行状况探测，因此不会导致静默的 AllowTraffic 故障。
工作流：ALB 目标组运行状况检查配置不正确。
实例配置文件 IAM 角色权限/信任 + 存储桶策略主体/条件
如果实例角色缺少 s3:GetObject 或信任/策略已损坏，S3 将返回 403 AccessDenied。限制性存储桶策略（主要限制、aws:SourceVpce 或 s3:prefix 等条件）可能会拒绝角色并导致 AccessDenied。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：如果实例角色缺少 s3:GetObject 或信任/策略已损坏，S3 将返回 403 AccessDenied。
● 场景匹配：如果实例角色缺少 s3:GetObject 或信任/策略已损坏，S3 将返回 403 AccessDenied。一个限制性的桶。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 阻止公共访问针对公共 ACL 和存储桶策略，不会阻止授权角色对私有对象的访问。
● 对象锁定强制保留/保留，并且不会阻止具有权限的主体的读取。
● 仅在使用 S3 VPC 端点时相关；否则，它不会影响授权，也不是典型的根本原因。
工作流：实例配置文件 IAM 角色权限/信任 → 存储桶策略主体/条件。
具有适用于 MySQL 多可用区且不可变的外部 Amazon RDS 的 Elastic Beanstalk
不可变更新以满负荷启动新的 Auto Scaling 组，允许在运行状况检查失败时快速回滚，并在限制时避免部分滚动更新问题。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：不可变更新会满负荷启动新的 Auto Scaling 组，在运行状况检查失败时允许快速回滚，并避免部分滚动更新问题，同时限制部署窗口的额外成本。
● 场景匹配：不可变更新会以满负荷启动新的 Auto Scaling 组，如果运行状况检查失败，则允许快速回滚。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 实现零停机和回滚，但切换后保留旧环境并不是最具成本效益的选择。
● 不满足在 Elastic Beanstalk 上托管应用程序的要求，并且会增加重新架构开销。
● 仍然可能导致部分应用更新并将数据库生命周期与环境耦合，不建议在生产中这样做。
工作流：具有外部 Amazon RDS 的 Elastic Beanstalk，用于 MySQL 多可用区和不可变部署。
API Gateway 金丝雀版本将 10% 发送到并行 ALB/EC2 后端
API网关金丝雀发布原生按权重分割流量，并允许通过调整金丝雀权重进行即时回滚。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：API网关金丝雀发布原生按权重分割流量，并允许通过调整金丝雀权重进行即时回滚。
● 场景匹配：API网关金丝雀发布原生按权重分割流量，并允许通过调整金丝雀权重进行即时回滚。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 蓝/绿有效，但添加了部署工具和配置，并且不利用 API Gateway 的本机流量转移。
● DNS 加权引入了 TTL 延迟，并且需要重复的域/堆栈，使得回滚和控制不太精确。
● API Gateway 无法直接对 ALB 目标组进行加权；流量分割是通过 API Gateway canary 在阶段级别完成的。
工作流：API Gateway 金丝雀版本将 10% 发送到并行 ALB/EC2 后端。
没有对 CodeDeploy 终端节点的出站访问 + 缺少 IAM 实例配置文件
如果没有到 CodeDeploy 公共端点或 VPC 端点的出口，代理将无法通信，并且事件将被标记为已跳过。如果实例配置文件没有授予获取修订和报告状态的访问权限，代理就无法运行生命周期步骤。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：如果没有到 CodeDeploy 公共端点或 VPC 端点的出口，代理将无法通信，并且事件将被标记为已跳过。
● 场景匹配：如果没有到 CodeDeploy 公共端点或 VPC 端点的出口，代理将无法通信，并且事件将被标记为已跳过。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 部署在实例配置文件和 CodeDeploy 服务角色下运行，而不是在启动用户下运行。
● CodeDeploy 支持两种定位方法，这不会导致生命周期事件被跳过。
● 缺少可选挂钩可能会显示这些挂钩已跳过，但仍可以安装修订版本，并且并非所有事件都会被跳过。
工作流：没有对 CodeDeploy 端点的出站访问 → 实例上缺少 IAM 实例配置文件。
使用 Lambda 的 Kinesis Data Firehose 从网络防火墙转换为 S3
Network Firewall 可以直接交付到 Firehose，后者支持内联 Lambda 转换和近乎实时的 S3 交付。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：网络防火墙可以直接交付到 Firehose，后者支持内联 Lambda 转换和近乎实时的 S3 交付。
● 场景匹配：Network Firewall 可以直接交付到 Firehose，后者支持内联 Lambda 转换和近乎实时的 S3 交付。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 网络防火墙本身并不发布到 Kinesis Data Streams，这会添加自定义组件。
● 在对象写入 S3 之后运行，而不是在交付之前内联。
● 需要将日志路由到 CloudWatch 并构建自定义管道，这会增加运营开销。
工作流：具有 Lambda 的 Kinesis Data Firehose 从网络防火墙转换为 S3。
在 AWS Step Functions 中对工作流程建模并运行每个阶段
Step Functions 提供托管编排、按任务重试和状态管理，以最小的操作开销仅重新处理失败的步骤。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Step Functions 提供托管编排、按任务重试和状态管理，以最小的操作开销仅重新处理失败的步骤。
● 场景匹配：Step Functions 提供托管编排、按任务重试和状态管理，以最小的操作开销仅重新处理失败的步骤。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 设计解耦了各个阶段，但需要自定义编排和状态跟踪，从而增加了操作复杂性。
● Airflow 可以编排任务，但与无服务器方法相比，管理 MWAA 环境和 EC2 工作人员会增加运营负担。
● 单一的 Lambda 使得很难仅重试失败的步骤，并在出现错误时强制完全重新执行。
工作流：在 AWS Step Functions 中对工作流程进行建模，并将每个阶段作为单独的任务运行，通过重试调用 AWS Lambda。
使用 IRSA 和附加的 EBS CSI 驱动程序的 IAM 角色
EBS CSI 控制器需要具有 EC2 权限的 IRSA 绑定 IAM 角色才能创建和管理 gp3 卷，从而解决 UnauthorizedOperation 问题。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：EBS CSI 控制器需要具有 EC2 权限的 IRSA 绑定 IAM 角色才能创建和管理 gp3 卷，从而解决 UnauthorizedOperation 问题。
● 场景匹配：EBS CSI 控制器需要具有 EC2 权限的 IRSA 绑定 IAM 角色才能创建和管理 gp3 卷。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 仅修改 Kubernetes RBAC，不授予 EBS CSI 驱动程序所需的 EC2 权限。
● 避免预配置，但无法解决底层 IAM 授权问题并降低灵活性。
● Pod 不会自动使用节点 IAM 角色，并且 EBS CSI 控制器设计为承担 IRSA 角色，因此这不是正确或推荐的修复方法。
工作流：使用 IRSA 为 EBS CSI 驱动程序配置 IAM 角色并将其附加到附加组件，以便它可以调用所需的 EC2 API。
授予 Systems Manager 访问权限的 IAM 实例配置文件 + 使用接口 VPC
实例需要 IAM 角色（例如 AmazonSSMManagedInstanceCore）来授权 SSM 操作，而无需访问密钥。这些 PrivateLink 终端节点将 Session Manager 流量保留在 AWS 网络内。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：实例需要 IAM 角色（例如 AmazonSSMManagedInstanceCore）来授权 SSM 操作，而无需访问密钥。
● 场景匹配：实例需要 IAM 角色（例如 AmazonSSMManagedInstanceCore）来授权 SSM 操作，而无需访问密钥。这些 PrivateLink 终端节点将 Session Manager 流量保留在 AWS 网络内。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 网关端点仅支持 S3 和 DynamoDB，不支持 Systems Manager。
● 会话管理器不需要入站 SSH，并且打开端口 22 会增加风险。
● 使用实例配置文件时，实例上的长期访问密钥不安全且不必要。
工作流：附加授予 Systems Manager 访问权限的 IAM 实例配置文件 → 使用 SSM、SSMMessages 和 EC2Messages 的接口 VPC 终端节点。
CloudFront 字段级加密，需要 HTTPS 来源，并使用长 max-age
字段级加密可保护边缘的指定字段，HTTPS 可确保传输安全，长 max-age 可增加缓存驻留时间以提高命中率。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：字段级加密可保护边缘的指定字段，HTTPS 可确保传输安全，长 max-age 可增加缓存驻留时间以提高命中率。
● 场景匹配：字段级加密可保护边缘的指定字段，HTTPS 可确保传输安全，长 max-age 可增加缓存驻留时间以提高命中率。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● WAF可以过滤请求，但不会加密敏感字段；较长的 TTL 有助于缓存，但无助于 PCI 现场保护。
● 签名 URL 控制访问而不是加密表单字段；较长的 max-age 有助于缓存，但无助于 PCI 加密。
● OAI 限制 S3 源访问，并根据标头分段缓存；两者都不提供字段级加密。
工作流：启用 CloudFront 字段级加密，要求使用 HTTPS 进行来源，并使用较长的 max-age。
将事件负载发布到 Amazon SNS 主题，订阅 AWS Lambda
SNS to Lambda 提供本机事件驱动处理，DynamoDB 是无服务器键值存储，非常适合按事件写入。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：SNS to Lambda 提供本机事件驱动处理，DynamoDB 是无服务器键值存储，非常适合按事件写入。
● 场景匹配：SNS to Lambda 提供本机事件驱动处理，DynamoDB 是无服务器键值存储，非常适合按事件写入。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Athena 是一项查询服务，而不是用于每个事件处理的通用计算运行时，并且 EventBridge 对于简单的 S3 到计算工作流程来说是不必要的。
● ElastiCache 是在托管实例上运行的内存缓存，而不是无服务器持久键值数据库。
● RDS是一个关系数据库，既不是无服务器也不是键值存储，不满足规定的要求。
工作流：将事件负载发布到 Amazon SNS 主题 → 订阅 AWS Lambda 函数来处理每条消息，并将输出保存到名为 EventStore 的 Amazon DynamoDB 表中。
S3存储桶不为空，CloudFormation无法删除它；使用
CloudFormation 无法删除非空 S3 存储桶，因此在删除事件期间删除所有对象、版本和删除标记的自定义资源是正确的。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudFormation 无法删除非空 S3 存储桶，因此删除所有对象、版本和删除的自定义资源。
● 场景匹配：CloudFormation 无法删除非空 S3 存储桶，因此删除所有对象、版本和删除的自定义资源。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 堆栈策略限制对受保护资源的更新，并且不会阻止堆栈删除，因此这不能解释失败。
● S3 存储桶的 CloudFormation 中没有“Delete: Force”属性，因此此设置无法解决该问题。
● WaitCondition 不适用于 Lambda，也不会解决实际阻止删除的非空存储桶约束。
工作流：S3 存储桶不为空，CloudFormation 无法删除它 → 使用 Lambda 支持的自定义资源在堆栈删除时清除存储桶。
生命周期挂钩到每个 Auto Scaling 组并配置 Amazon EventBridge
生命周期挂钩发出事件，EventBridge 可以使用实例详细信息和令牌将这些事件路由到 Lambda，从而在启动和终止时实现可靠的更新。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：生命周期挂钩发出事件，EventBridge 可以使用实例详细信息和令牌将这些事件路由到 Lambda，从而实现可靠。
● 场景匹配：生命周期挂钩发出事件，EventBridge 可以使用实例详细信息和令牌将这些事件路由到 Lambda，从而实现可靠。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 聚合指标的警报不与各个生命周期事件绑定，并且不提供每个实例的上下文或生命周期令牌。
● 实例脚本很脆弱，并且可能无法在终止时运行，这使得它们对于权威清单更新来说不可靠。
● Lambda 无法配置为直接生命周期挂钩通知目标；您必须使用 EventBridge、SNS 或 SQS。
工作流：向每个 Auto Scaling 组添加生命周期挂钩，并配置 Amazon EventBridge 规则以在启动时调用 AWS Lambda 函数并终止操作以更新 InfraInventoryV2。
具有托管跨区域故障转移和 Route 53 运行状况检查的 Aurora 全球数据库
Aurora Global Database 专为低延迟跨区域复制和托管故障转移而构建。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Aurora Global Database 专为低延迟跨区域复制和托管故障转移而构建。
● 场景匹配：Aurora Global Database 专为低延迟跨区域复制和托管故障转移而构建。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 可以工作，但升级和 DNS 更改需要自定义编排。
● 多可用区仅在一个区域内有效。
● 快照复制和恢复在技术上是可行的，但速度很慢。
工作流：具有托管跨区域故障转移和 Route 53 运行状况检查的 Aurora 全球数据库。
AWS Trusted Advisor 与商业或企业支持计划集成
这利用了 Trusted Advisor Low Utilization EC2 检查和 EventBridge，以进行按标签过滤的事件驱动修复。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这利用了 Trusted Advisor 低利用率 EC2 检查和 EventBridge，以进行按标签过滤的事件驱动修复。
● 场景匹配：这利用了 Trusted Advisor 低利用率 EC2 检查和 EventBridge，以进行按标签过滤的事件驱动修复。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 选项基于 EC2 使用的标签和指标构建仪表板和事件驱动的操作。
● 依赖 Compute Optimizer 建议并尝试使用 EventBridge 和 Lambda 自动关闭。
● 建议使用基于 Lambda 的修复将自定义数据收集管道引入 DynamoDB 和 QuickSight。
工作流：将 AWS Trusted Advisor 与与 Amazon EventBridge 集成的商业或企业支持计划结合使用，并调用 AWS Lambda 来筛选标签并自动终止持续低利用率的 EC2 实例。
EventBridge 用于运行在文件共享上调用 RefreshCache 的 Lambda
计划的 EventBridge 规则可以在上传完成后和上午 9 点之前调用 Lambda 来调用 RefreshCache。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：计划的 EventBridge 规则可以在上传完成后和上午 9 点之前调用 Lambda 来调用 RefreshCache。
● 场景匹配：计划的 EventBridge 规则可以在上传完成后和上午 9 点之前调用 Lambda 来调用 RefreshCache。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 更改上传服务不会刷新文件网关缓存。
● 文件网关不为直接 S3 写入提供内置自动刷新设置。
● S3 无法直接使 Storage Gateway 刷新。
工作流：使用 EventBridge 运行 Lambda，在上午 9 点之前对文件共享调用 RefreshCache。
订阅 AWS Health 事件并触发调用的 EventBridge 规则
这可以协调按需实例更换以避免备用成本，并提供跨可用区 Aurora 故障转移以实现高可用性。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这可以协调按需实例更换以避免备用成本，并提供跨可用区 Aurora 故障转移以实现高可用性。
● 场景匹配：这可以协调按需实例更换以避免备用成本，并提供跨可用区 Aurora 故障转移以实现高可用性。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 保持热备份并使数据库成为单点故障，同时产生持续的计算成本。
● EC2 自动恢复和配置修复无法解决 EFA 和实例存储约束以及单个 Aurora。
● 许可会阻止使用 Auto Scaling，并且此方法不能确保与 EFA 和实例存储要求的兼容性。
工作流：订阅 AWS Health 事件并触发 EventBridge 规则，该规则会在发生故障时调用 Lambda 函数在另一个可用区中创建替换 EC2 实例，并配置具有一个可升级的跨可用区 Aurora 副本的 Aurora 集群。
与 AWS Health EC2 事件匹配并发布的 Amazon EventBridge 规则
EventBridge 本身接收 AWS Health 事件，从而允许即时的规则到 SNS 模式，快速提供 EC2 维护和停用通知。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：EventBridge 本身接收 AWS Health 事件，从而允许即时的规则到 SNS 模式，快速提供 EC2 维护和停用通知。
● 场景匹配：EventBridge 本身接收 AWS Health 事件，允许立即进行规则到 SNS 模式，从而快速提供 EC2 维护和停用。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 发送广泛的账户通信，包括账单和安全通知，既不针对 AWS Health 事件，也不是最安全的方法。
● 默认情况下，AWS Health 事件不会出现在 CloudWatch Logs 中，因此这需要额外的提取步骤，并且不是最快的路径。
● 尽管它可以中继运行状况通知，但它需要部署和配置解决方案，这比简单的 EventBridge-to-SNS 规则慢。
工作流：创建与 AWS Health EC2 事件匹配的 Amazon EventBridge 规则，并将其发布到分析团队订阅的 SNS 主题。
S3网站存储桶仍然包含对象和版本；更新 Lambda
CloudFormation 只能删除空的 S3 存储桶，因此自定义资源应通过递归删除所有对象、版本和删除标记来处理删除请求。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudFormation 只能删除空的 S3 存储桶，因此自定义资源应递归处理删除请求。
● 场景匹配：CloudFormation 只能删除空的 S3 存储桶，因此自定义资源应递归处理删除请求。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 假定对象锁定正在阻止删除，但未指出这一点，也不是 CloudFormation S3 删除失败的常见原因。
● 静态网站托管设置不会阻止 CloudFormation 删除空的 S3 存储桶。
● ForceDelete 不是有效的 CloudFormation DeletionPolicy 值，并且对于 S3 存储桶不存在。
工作流：S3 网站存储桶仍然包含对象和版本 → 更新 Lambda 自定义资源以在删除事件时清空存储桶，以便 CloudFormation 可以将其删除。
在适用于 Go 平台的 AWS Elastic Beanstalk 上，上传应用程序包
Elastic Beanstalk 支持 Go，并通过环境克隆和 CNAME 交换提供托管蓝/绿服务，且运营开销极低。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Elastic Beanstalk 支持 Go，并通过环境克隆和 CNAME 交换提供托管蓝/绿服务，且运营开销极低。
● 场景匹配：Elastic Beanstalk 支持 Go，并通过环境克隆和 CNAME 交换提供托管蓝/绿服务，且运营开销极低。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 该方法替换了现有的实例，并且本身并不保留两个并行环境来控制流量转移。
● App Runner 简化了部署，但不提供具有并行堆栈和流量交换语义的环境级蓝/绿。
● CodeArtifact 是一个包存储库，不适用于托管应用程序包或编排蓝/绿环境。
工作流：在 Go 平台的 AWS Elastic Beanstalk 上部署，将应用程序包上传到 Amazon S3，并使用 Elastic Beanstalk 环境交换进行蓝/绿部署。
AWS Secrets Manager 通过 ECS 容器密钥使用 KMS，启用轮换
Secrets Manager 是一种专用的密钥服务，具有 KMS 加密、本机自动轮换、环境变量 ECS 集成，并支持最大 64 KB 的密钥大小。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Secrets Manager 是一种专用的密钥服务，具有 KMS 加密、本机自动轮换、环境变量 ECS 集成，并支持最大 64 KB 的密钥大小。
● 场景匹配：Secrets Manager 是一个专用的秘密服务，具有 KMS 加密、本机自动轮换、环境变量 ECS 集成。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Parameter Store 缺乏本机自动轮换，并且高级参数限制为约 8 KB，因此即使使用自定义轮换，它也不适合 20 KB 的机密。
● AppConfig 用于应用程序配置，不用作具有本机轮换或 ECS 秘密注入的专用秘密存储。
● S3 不是秘密存储，不提供本机自动轮换或 ECS 秘密注入机制。
工作流：AWS Secrets Manager 通过 ECS 容器密钥使用 KMS，启用轮换。
Jenkins 作为跨多个可用区的多主机安装并使用 AWS
这为 Jenkins master 提供了 HA，并通过 CodeBuild 提供了弹性、按使用付费的构建执行。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这为 Jenkins master 提供了 HA，并通过 CodeBuild 提供了弹性、按使用付费的构建执行。
● 场景匹配：这为 Jenkins master 提供了 HA，并通过 CodeBuild 提供了弹性、按使用付费的构建执行。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 保持在 EC2 代理上构建，但单可用区控制平面不具有容错能力。
● 尽管实现了 HA，但与托管构建相比，维护 EC2 代理队列会增加成本和运营开销。
● 卸载构建有助于弹性，但将主节点放置在单个可用区中会破坏可用性。
工作流：将 Jenkins 作为跨多个可用区的多主安装运行，并使用 Jenkins 的 AWS CodeBuild 插件，以便在 CodeBuild 中执行构建。
Cognito Post Authentication 触发器调用通过 Amazon 发送电子邮件的 Lambda
身份验证后触发器在成功登录后立即运行，并且可以调用 Lambda 通过 SES 以最小的开销发送电子邮件。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：身份验证后触发器在成功登录后立即运行，并且可以调用 Lambda 通过 SES 以最小的开销发送电子邮件。
● 场景匹配：身份验证后触发器在成功登录后立即运行，并且可以调用 Lambda 通过 SES 以最小的开销发送电子邮件。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Cognito 用户池最终用户登录不会作为 CloudTrail 事件发出，因此这是不可靠且间接的。
● 添加客户端逻辑和额外服务，而不是使用 Cognito 的本机触发器，从而增加了复杂性。
● 自定义消息用于验证/MFA/忘记密码流程，不适用于身份验证后登录。
工作流：使用 Cognito 后身份验证触发器调用通过 Amazon SES 发送电子邮件的 Lambda。
使用 EC2 Image Builder 重建自定义 AMI 以包含当前的
这在没有互联网的情况下通过 VPC 端点使用 SSM 会话管理器，授予正确的实例权限，并通过 S3 和 SNS 提供可审核的日志和通知。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这在没有互联网的情况下通过 VPC 终端节点使用 SSM 会话管理器，授予正确的实例权限，并提供可审核的功能。
● 场景匹配：这在没有互联网的情况下通过 VPC 终端节点使用 SSM 会话管理器，授予正确的实例权限，并提供可审核的功能。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 引入了与隔离要求相冲突的互联网出口和堡垒模式，并添加了不必要的组件。
● SCP 无法授予权限，并且 AWS Config 无法附加 SCP，因此这不会启用所需的访问路径。
● EC2 Instance Connect 依赖于 SSH 网络路径，本身并不提供集中式会话日志记录和访问控制。
工作流：使用 EC2 Image Builder 重建自定义 AMI 以包含当前的 SSM 代理 → 将 AmazonSSMManagedInstanceCore 实例配置文件附加到 Auto Scaling 组 → 使用 Systems Manager 会话管理器。
CodePipeline 阶段并行运行每个 Lambda 函数的操作
对同一阶段中的多个操作使用相同的 runOrder 可以同时运行它们，这最直接地减少了总管道持续时间。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：对同一阶段中的多个操作使用相同的 runOrder 可以同时运行它们，这最直接地减少了总管道持续时间。
● 场景匹配：对同一阶段中的多个操作使用相同的 runOrder 可以同时运行它们，这最直接地减少了总管道持续时间。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 扩大计算规模可能会缩短单个构建时间，但不会消除跨操作的顺序瓶颈。
● 构建图强制执行依赖性排序，并且不会跨多个函数并行化独立的 CodePipeline 操作。
● 将构建放在 VPC 中并使用专用主机本身并不会提高管道速度，并且会增加网络开销。
工作流：将 CodePipeline 阶段配置为通过分配相同的 runOrder 并行运行每个 Lambda 函数的操作。
组织根部拒绝资源创建的服务控制策略
SCP 可以阻止不包含强制标签的创建操作，强制合规性并防止未来出现无标签资源。标签编辑器允许批量发现和应用。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：SCP 可以阻止不包含强制标签的创建操作，从而强制执行合规性并防止未来出现无标签。
● 场景匹配：SCP 可以阻止不包含强制标签的创建操作，强制执行合规性并防止未来出现无标签。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 打开成本分配标签有助于在标签存在后进行报告，但既不能修复未标记的资源，也不能阻止无标签创建。
● 成本类别可以对成本进行分组，但它们不应用或强制执行资源标签，因此无法修复未标记的情况。
工作流：在组织根附加一个服务控制策略，该策略在缺少所需标签时拒绝资源创建 → 使用每个账户和区域中的 AWS 资源组标签编辑器进行查找。
云形成； CodeDeploy 蓝/绿 (Lambda)；弹性豆茎不可变
Lambda 的蓝/绿提供流量转移和即时回滚，Beanstalk Immutable 创建并行队列以实现零停机和安全切换。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Lambda 的蓝/绿提供流量转移和即时回滚，Beanstalk Immutable 创建并行队列以实现零停机和安全切换。
● 场景匹配：Lambda 的蓝/绿提供流量转移和即时回滚，Beanstalk Immutable 创建并行队列以实现零停机和安全切换。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 就地加滚动可以保持容量，但缺乏环境隔离和原子回滚，存在停机和快速失败门控的风险。
● 一次性同时替换实例，导致短暂中断，无法满足零停机要求。
● Canary 可以帮助 Lambda，但 Beanstalk Rolling 可以就地更新，并且可以在故障期间减少容量或增加爆炸半径。
工作流：CloudFormation → CodeDeploy 蓝/绿 (Lambda) → Elastic Beanstalk 不可变。
SSM 代理和 Systems Manager 维护窗口 + AWS-RunPatchBaseline SSM 文档
通过维护窗口安装 SSM 代理并安排补丁任务可轻松提供自动化、受控且可审核的补丁。通过补丁管理器运行，通过集中审核将批准的基线应用于整个机群的 Windows 和 Linux。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：通过维护窗口安装 SSM 代理并安排补丁任务可轻松提供自动化、受控且可审核的补丁。
● 场景匹配：安装 SSM 代理并通过维护窗口安排修补任务可提供自动化、受控且可审核的修补。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 跨主机和发行版分散，增加了运营开销并且缺乏集中编排。
● 检查员识别漏洞但不应用补丁；修复需要补丁管理器。
● 仅针对 Windows，不适合 Windows/Linux 混合环境。
工作流：SSM 代理和 Systems Manager 维护窗口 → AWS-RunPatchBaseline SSM 文档。
目标 EC2 实例缺少授予权限的 IAM 实例配置文件
如果没有允许检索修订和报告状态等操作的实例配置文件，CodeDeploy 代理将无法运行挂钩，并且事件将被标记为已跳过。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：如果没有允许检索修订和报告状态等操作的实例配置文件，则 CodeDeploy 代理。
● 场景匹配：如果没有允许检索修订和报告状态等操作的实例配置文件，则 CodeDeploy 代理。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● CodeDeploy 在运行时使用服务角色和实例配置文件，因此启动用户的权限不会导致。
● CodeDeploy 支持基于标签和 Auto Scaling 组定位，因此单独使用标签并不是跳过的原因。
工作流：目标 EC2 实例缺少授予 CodeDeploy 代理所需访问权限的 IAM 实例配置文件 → EC2 实例无法到达 CodeDeploy 公共端点，因为它们没有出口路径。
具有 CloudFormation SSM 参数类型和计划的 SSM 参数存储 UpdateStack
CloudFormation 在更新时解析 SSM 参数类型，因此计划更新会将所有堆栈滚动到最新的 AMI，而无需在每个周期进行模板编辑。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudFormation 在更新时解析 SSM 参数类型，因此计划更新会将所有堆栈滚动到最新的 AMI，而无需在每个周期进行模板编辑。
● 场景匹配：CloudFormation 在更新时解析 SSM 参数类型，因此计划更新会将所有堆栈滚动到最新的 AMI，而无需在每个周期进行模板编辑。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 需要每个堆栈的特定参数名称，当模板不同时，该名称会中断。
● 动态引用仅在创建或更新时解析，而不是自动解析。
● 当 CloudFormation 可以直接解析 SSM 参数时，重写模板很脆弱且不必要。
工作流：将 SSM Parameter Store 与 CloudFormation SSM 参数类型结合使用，并每 15 天安排一次 UpdateStack。
使用重用分区键的 LSI 构建新表
LSI 共享分区键、允许备用排序键并支持强一致性读取，但必须在创建表时定义。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：LSI 共享分区键、允许备用排序键并支持强一致性读取，但必须在创建表时定义。
● 场景匹配：LSI 共享分区键、允许备用排序键并支持强一致性读取，但必须在创建表时定义。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● GSI 不支持强一致性读取。
● 您无法将 LSI 添加到现有表中；它必须与表一起创建。
● DAX 提供最终一致性读取的缓存，而不是强一致性。
工作流：使用LSI构建新表，重用分区键并添加新的排序键→迁移数据。
使用 CloudFormation 在不同区域预配置堆栈，创建跨区域
跨区域 RDS 只读副本加上 S3 CRR 可提供较低的 RPO，并且通过提升副本进行预配置可最大限度地减少 RTO。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：跨区域 RDS 只读副本加上 S3 CRR 可提供低 RPO 以及通过提升副本进行预配置。
● 场景匹配：跨区域 RDS 只读副本加上 S3 CRR 可提供低 RPO 以及通过提升副本进行预配置。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 多可用区备实例不能分布在不同地域，因此该设计不支持跨地域容灾。
● 跨区域快照副本和 Glacier 检索会增加 RPO 和 RTO，使其不适合实现最低的数据丢失和。
● ALB 是区域性的，无法路由到另一个区域，并且多可用区本身并不能防止区域故障。
工作流：使用 CloudFormation 在不同区域预配置堆栈 → 创建跨区域 RDS 只读副本 → 启用到目标存储桶的 S3 跨区域复制，并在预扩展 Auto Scaling 组的同时在故障转移期间提升副本。
AWS Storage Gateway 文件网关位于本地，具有 MAM 读写媒体
文件网关提供由 S3 支持的 SMB 或 NFS，从而能够以最少的更改和较低的操作开销在 S3 对象上启用 Rekognition。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：文件网关提供由 S3 支持的 SMB 或 NFS，从而能够以最少的更改和较低的操作开销在 S3 对象上启用 Rekognition。
● 场景匹配：文件网关提供由 S3 支持的 SMB 或 NFS，只需进行最少的更改即可在 S3 对象上启用 Rekognition。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 引入了流式传输管道，该管道增加了复杂性，并且自然不适合磁带上基于冷文件的存档。
● 需要构建和操作自定义基础设施和软件，这会增加持续的管理工作。
● 虚拟磁带存档到 S3 Glacier 存储类，无法直接访问以进行实时 Rekognition 处理。
工作流：在本地部署 AWS Storage Gateway 文件网关，让 MAM 通过网关读取和写入媒体，以便文件到达 Amazon S3，并使用 AWS Lambda 调用 Amazon Rekognition 以对 S3 中的人脸建立索引并更新 MAM 目录。
使用 AWS Step Functions 构建工作流程，将 Amazon API Gateway 与
直接 API 网关到 Step Functions 支持长时间运行的编排，并在使用 Cognito 进行扩展和身份验证的同时保持设计简单。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：直接 API 网关到 Step Functions 支持长时间运行的编排，并在使用 Cognito 进行扩展和身份验证的同时保持设计简单。
● 场景匹配：直接 API 网关到 Step Functions 支持长时间运行的编排，并在扩展和身份验证的同时保持设计简单。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 失败是因为 Lambda 无法运行数小时，并且即使通过 API Gateway 调用也会在 15 分钟后超时。
● 添加 Lambda 作为跃点会增加复杂性和潜在的限制点，但与本机 API 网关到 Step Functions 的集成相比没有任何优势。
● 不适合公共消费者 API，并且仍然违反 Lambda 对于多小时工作流程的 15 分钟最大执行时间。
工作流：使用 AWS Step Functions 构建工作流程 → 使用 Amazon API Gateway 与 Step Functions 直接服务集成，并使用 Amazon Cognito 保护 API。
启用 CodeDeploy 自动回滚的 EC2 Max CPU 上的 CloudWatch 警报
将 EC2 CPUUtilization（最大值）上的 CloudWatch 警报附加到 CodeDeploy 部署组并启用自动回滚，以便在转移期间发生违规会触发回滚。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：将 EC2 CPUUtilization（最大值）上的 CloudWatch 警报附加到 CodeDeploy 部署组并启用自动回滚，以便在转移期间发生违规会触发回滚。
● 场景匹配：将 EC2 CPUUtilization（最大值）上的 CloudWatch 警报附加到 CodeDeploy 部署组并启用自动回滚，以便在转移期间发生违规会触发回滚。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● ALB错误报警可以触发回滚，但这并不能解决基于EC2 CPU要求较高的回滚问题。
● 扩展策略和运行状况检查不会根据 CPU 阈值触发 CodeDeploy 回滚。
● 生命周期挂钩不适用于实时流量回滚情况；使用 CodeDeploy 警报在转移过程中自动回滚。
工作流：EC2 Max CPU 上的 CloudWatch 警报，启用了 CodeDeploy 自动回滚。
具有 20% 加权流量的 Lambda 别名 + API Gateway 阶段金丝雀
Lambda 别名支持路由配置，以在两个版本之间转移一定比例的流量并允许即时回滚。 API Gateway 金丝雀设置允许您将一定比例的流量发送到金丝雀并快速升级或恢复。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Lambda 别名支持路由配置，以在两个版本之间转移一定比例的流量并允许即时回滚。
● 场景匹配：Lambda 别名支持路由配置，以在两个版本之间转移一定比例的流量并允许即时回滚。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 根据健康状况在主备之间进行故障转移路由切换；它不能进行百分比分割。
● NLB 不提供跨目标组的加权路由，以通过 API 网关进行精确的金丝雀分割。
● AppConfig 管理功能标志，但不会在网关处路由 API 流量或强制执行请求级别的百分比拆分。
工作流：具有 20% 加权流量的 Lambda 别名 → API Gateway 阶段金丝雀为 20%。
Kinesis Data Firehose 的 CloudWatch Logs 订阅传送到 S3 +
CloudWatch Logs 可以流式传输到 Kinesis Data Firehose，后者可靠地传送到 S3。生命周期转换可在 90 天后最大限度地降低成本，并且到期后将强制保留 10 年。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudWatch Logs 可以流式传输到 Kinesis Data Firehose，后者可靠地传送到 S3。
● 场景匹配：CloudWatch Logs 可以流式传输到 Kinesis Data Firehose，后者可靠地传送到 S3。生命周期转换可在 90 天后最大限度地降低成本，并且到期后将强制保留 10 年。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● DataSync 不是 CloudWatch Logs 订阅支持的目标。
● 导出是需要编排的批处理作业，而不是连续流式处理。
● 保留仅控制 CloudWatch Logs 中的日志删除，不会存档到 S3。
工作流：将 CloudWatch Logs 订阅设置为 Kinesis Data Firehose 并交付到 S3 → 添加 S3 生命周期规则：在 90 天后过渡到 S3 Glacier Deep Archive，在 3,650 天后到期。
CloudTrail iam 的 EventBridge 规则：CreateUser 事件 + Lambda 用于删除登录配置文件
将通过 CloudTrail 进行的 AWS API 调用与 eventSource iam.amazonaws.com 和 eventName CreateUser 相匹配，以快速检测新的 IAM 用户。使用DeleteLoginProfile和UpdateAccessKey来中和控制台和。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：将通过 CloudTrail 进行的 AWS API 调用与 eventSource iam.amazonaws.com 和 eventName CreateUser 相匹配，以快速检测新的 IAM 用户。
● 场景匹配：将通过 CloudTrail 进行的 AWS API 调用与 eventSource iam.amazonaws.com 和 eventName CreateUser 相匹配，以快速检测新的 IAM 用户。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 配置用于配置合规性，可能不会在用户创建时提供立即的、事件驱动的修复。
● GetLoginProfile 仅涵盖控制台密码配置文件，并错过了没有控制台密码创建的用户。
● 阻止用户创建，而不是在创建后禁用凭据，并且不提供警报。
工作流：CloudTrail iam 的 EventBridge 规则：CreateUser 事件 → Lambda 删除登录配置文件并停用新用户的访问密钥 → 来自安全订阅的 EventBridge 的 SNS 主题目标。
使用一个 Lambda 进行读取并通过 Amazon SNS 扇出事件
单个消费者避免了分片争用，SNS 为许多处理器提供了可扩展的扇出。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：单个消费者避免了分片争用，SNS 为许多处理器提供了可扩展的扇出。
● 场景匹配：单个消费者避免了分片争用，SNS 为许多处理器提供了可扩展的扇出。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 增加每个分片的并发性，但不会消除分片读取器的限制，并且可能会加剧多个消费者之间的争用。
● DAX 可加快表读取速度，并且不会改变 DynamoDB 流的使用方式。
● DynamoDB Streams 不是本机 EventBridge 规则源，多个规则仍会竞争相同的分片。
工作流：使用一个 Lambda 进行读取并通过 Amazon SNS 扇出事件。
AWS Config 托管 S3 规则，并使用 Systems Manager 自动修复
AWS Config 根据托管规则持续评估 S3 存储桶，并可以调用 Systems Manager Automation 自动修复不合规的存储桶。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：AWS Config 根据托管规则持续评估 S3 存储桶，并可以调用 Systems Manager Automation 自动修复不合规的存储桶。
● 场景匹配：AWS Config 根据托管规则持续评估 S3 存储桶，并可以调用 Systems Manager Automation 自动修复不合规的存储桶。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 可以对 API 调用做出反应，但维护起来很复杂，以事件为中心而不是以配置合规性为中心，并且不提供跨所有资源的本机合规性评估。
● SCP 和阻止公共访问可以阻止某些操作，但无法自动启用加密、日志记录和版本控制或修复现有存储桶。
● Trusted Advisor 不提供此要求所需的精细的每个存储桶合规性检查和本机自动修复。
工作流：使用 Systems Manager Automation Runbook 为 S3 配置 AWS Config 托管规则并进行自动修复。
AutomationAssumeRole 授予 Systems Manager Automation 的 IAM 角色并授予 iam:PassRole
SSM Automation 必须承担执行修复的角色，并且发起者需要 iam:PassRole 权限。此托管 SSM 自动化 Runbook 打开不合规存储桶的服务器访问日志记录。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：SSM Automation 必须承担执行修复的角色，并且发起者需要 iam:PassRole 权限。
● 场景匹配：SSM Automation 必须承担执行修复的角色，并且发起者需要 iam:PassRole 权限。此托管 SSM 自动化 Runbook 打开不合规存储桶的服务器访问日志记录。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Security Hub 会汇总结果并确定其优先级，但不会更改资源配置。
● 可能但不必要，因为托管修复操作手册已经存在并且是首选。
● SCP 可以限制或允许 API，但无法自动启用现有存储桶上的日志记录。
工作流：将 AutomationAssumeRole 设置为 Systems Manager Automation 的 IAM 角色并授予 iam:PassRole → 使用 AWS-ConfigureS3BucketLogging 配置 AWS Config 自动修复以启用 s3-bucket-logging-enabled。
数据中心和 VPC 之间的 AWS 站点到站点 VPN +
Site-to-Site VPN使用IPsec对本地网络和VPC之间的流量进行加密，满足加密要求。 Fargate 消除了管理服务器的需要。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Site-to-Site VPN使用IPsec对本地网络和VPC之间的流量进行加密，满足加密要求。
● 场景匹配：Site-to-Site VPN使用IPsec对本地网络和VPC之间的流量进行加密，满足加密要求。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 增加了运营负担，因为您必须自行修补、扩展和管理 EC2 主机。
● NLB不提供HTTPS监听，添加负载均衡器无法满足跨网络加密要求。
● 默认情况下，Direct Connect 不加密流量，因此它本身不满足加密连接的要求。
工作流：在数据中心和 VPC 之间配置 AWS 站点到站点 VPN → 在专用 VPC 中使用 Fargate 启动类型在 Amazon ECS 上运行工作负载。
使用 Lambda 的 AWS Glue 作业运行事件的 EventBridge 规则
EventBridge 将 Glue 作业事件路由到 Lambda，其中代码可以检查尝试和状态详细信息，并仅将最后一次尝试失败的情况发布到 SNS。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：EventBridge 将 Glue 作业事件路由到 Lambda，代码可以在其中检查尝试和状态详细信息并发布到。
● 场景匹配：EventBridge 将 Glue 作业事件路由到 Lambda，代码可以在其中检查尝试和状态详细信息并发布到。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 根据模式将事件直接发送到 SNS，但 EventBridge 事件模式无法评估尝试计数或条件。
● 个人健康仪表板显示帐户和服务健康事件，而不是每个作业的 Glue 重试结果，因此不会。
● Step Functions 可以处理此问题，但需要重新设计编排，并且当 EventBridge 加 Lambda 可以过滤 Glue 时就没有必要了。
工作流：使用 Lambda 目标为 AWS Glue 作业运行事件配置 EventBridge 规则，该目标检查失败的最终尝试的事件详细信息 → 发布到 SNS。
EventBridge (AWS Health) 触发 Step Functions 来编排 IAM、CloudTrail 和 SNS
这通过 EventBridge 和 Step Functions 使用 AWS Health 事件来实现可靠、可审计的警报编排、活动收集和密钥禁用。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这通过 EventBridge 和 Step Functions 使用 AWS Health 事件来实现可靠、可审计的警报编排、活动收集和密钥禁用。
● 场景匹配：这通过 EventBridge 和 Step Functions 使用 AWS Health 事件来实现可靠、可审计的警报编排、活动收集和密钥禁用。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 与 Step Functions 相比，单个 Lambda 可以执行操作，但缺乏强大的编排、重试和用于审计的可视化执行历史记录。
● AWS_RISK_CREDENTIALS_EXPOSED 源自 AWS Health，而不是 CloudTrail，因此该规则永远不会匹配。
● GuardDuty 不会发出 AWS Health 泄露凭证事件，并且此路径不提供所需的端到端编排或活动报告。
工作流：EventBridge (AWS Health) 触发 Step Functions 来编排 IAM、CloudTrail 和 SNS。
漂移检测不评估自定义资源 + 规则调用 DetectStackDrift
CloudFormation 偏差检测不包括自定义资源，这些资源不会检查偏差。托管规则依赖于 DetectStackDrift，并且在 API 错误或限制时默认为 NON_COMPLIANT，这解释了 IN_SYNC 控制台状态不匹配的情况。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudFormation 偏差检测不包括自定义资源，这些资源不会检查偏差。
● 场景匹配：CloudFormation 偏差检测不包括自定义资源，这些资源不会检查偏差。托管规则依赖于 DetectStackDrift，并且在 API 错误或限制时默认为 NON_COMPLIANT，这解释了 IN_SYNC 控制台状态不匹配的情况。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 更改集预览建议的更改，并且不检测带外漂移。
● 权限问题通常会产生显式访问错误，而不是将托管规则默认为 NON_COMPLIANT。
● 无论指定多少个属性，自定义资源都不支持偏差检测。
工作流：偏差检测不会评估自定义资源 → 该规则调用 DetectStackDrift 并将 API 限制或故障视为 NON_COMPLIANT。
将 90 秒聚合计数发布为 CloudWatch 自定义指标；使用 CloudWatch 警报
将聚合计数作为自定义指标发送可实现简单、低成本的警报和即时 SNS 通知。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：将聚合计数作为自定义指标发送可实现简单、低成本的警报和即时 SNS 通知。
● 场景匹配：将聚合计数作为自定义指标发送可实现简单、低成本的警报和即时 SNS 通知。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● CloudWatch 警报评估指标，而不是 EventBridge 事件，因此无法在没有指标的情况下直接驱动警报。
● 与本机 CloudWatch 自定义指标和警报相比，引入了额外的组件和成本。
● 可行，但与直接自定义指标相比，增加了日志摄取、过滤器管理和额外成本。
工作流：将 90 秒聚合计数发布为 CloudWatch 自定义指标 → 将 CloudWatch 警报与 SNS 结合使用。
配置新的加密 EBS 卷，将其附加到实例，然后迁移
创建卷时必须应用 EBS 加密，因此创建新的加密卷并移动数据可实现静态加密。复印和。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：创建卷时必须应用 EBS 加密，因此创建新的加密卷并移动。
● 场景匹配：创建卷时必须应用 EBS 加密，因此创建新的加密卷并移动。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 默认 EBS 加密仅影响新卷和快照，而不影响现有资源。
● 您无法直接加密现有快照或追溯地将附加卷更改为加密。
● TLS 保护传输中的数据，并且不在卷上提供静态加密。
工作流：配置一个新的加密 EBS 卷 → 将其附加到实例，迁移数据，并停用旧的未加密卷 → 复制该卷的未加密快照 → 加密复制的快照，并从中创建一个新卷。
使用存储桶策略删除公共访问权限并授予 CodeBuild 服务
这会强制执行最低权限并使用 CodeBuild 服务角色作为临时凭证，从而消除公共访问并避免静态密钥。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这会强制执行最低权限并使用 CodeBuild 服务角色作为临时凭证，从而消除公共访问并避免静态密钥。
● 场景匹配：这会强制执行最低权限并使用 CodeBuild 服务角色作为临时凭证，从而消除公共访问并避免静态密钥。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Amazon S3 不支持基本身份验证，并且此方法偏离了 AWS 推荐的 IAM 和存储桶策略控制。
● 在构建中嵌入静态凭据会增加暴露风险，并且安全性低于使用具有临时凭据的角色。
● 角色权限过高，无法弥合审计所标记的公共访问差距。
工作流：使用存储桶策略删除公共访问并授予 CodeBuild 服务角色最低权限 S3 权限，→ 在构建中使用 AWS CLI 来检索对象。
使用应用程序负载均衡器和 Auto 建立并行堆栈
Route 53 中的加权别名记录让您可以从新 ALB 的一小部分开始，然后逐渐增加，从而为 EC2/ASG 提供真正的金丝雀。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Route 53 中的加权别名记录让您可以从新 ALB 的一小部分开始。
● 场景匹配：Route 53 中的加权别名记录让您可以从新 ALB 的一小部分开始。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● API Gateway 私有集成支持网络负载均衡器，而不是应用程序负载均衡器，并且面向 API 而不是。
● 基于延迟的路由通过测量的延迟来选择端点，并且不提供金丝雀所需的显式百分比控制。
工作流：使用运行新版本的应用程序负载均衡器和 Auto Scaling 组建立并行堆栈，→ 使用 Route 53 加权别名记录来拆分并逐步转移流量。
Amazon Inspector for EC2 加 CloudWatch 代理将登录日志发送到 CloudWatch
检查员持续扫描 EC2 的 CVE 和暴露情况； CloudWatch Agent 将操作系统登录日志集中在 CloudWatch Logs 中，其中保留期可以设置为 30 天，并且。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：检查员持续扫描 EC2 的 CVE 和暴露情况； CloudWatch Agent 将操作系统登录日志集中在 CloudWatch Logs 中，其中保留期可以设置为 30 天，CloudTrail 还提供帐户活动审核功能。
● 场景匹配：检查员持续扫描 EC2 的 CVE 和暴露情况； CloudWatch Agent 将操作系统登录日志集中在 CloudWatch Logs 中。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Security Hub 会聚合其他服务的发现结果并确定其优先级，但不会执行主机漏洞扫描或收集操作系统登录日志。
● GuardDuty 检测威胁和异常，但不执行 EC2 主机漏洞扫描或捕获操作系统登录事件。
● ECR 扫描容器映像，而不扫描 EC2 操作系统或其登录活动。
工作流：Amazon Inspector for EC2 → CloudWatch 代理将登录日志传送到 CloudWatch Logs，并将 CloudTrail 传送到相同的日志。
具有版本加权流量的 Lambda 别名
Lambda 别名路由支持版本之间的加权流量，从而在单个 API 网关阶段后面实现金丝雀或线性部署。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Lambda 别名路由支持版本之间的加权流量，从而在单个 API 网关阶段后面实现金丝雀或线性部署。
● 场景匹配：Lambda 别名路由支持版本之间的加权流量，从而在单个 API 网关阶段后面实现金丝雀或线性部署。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● API Gateway 金丝雀在阶段级别工作，通常需要单独的阶段，而不是在一个阶段内进行版本级别的流量转移。
● 跨端点拆分 DNS，需要部署多个 API；它不会在一个阶段后面的 Lambda 版本之间分割流量。
● AppConfig 的目标是配置和功能标志，而不是 Lambda 调用的代码版本流量转移。
工作流：配置具有版本加权流量的 Lambda 别名。
.ebextensions container_commands 与 Leader_only: true
容器命令支持leader_only，并在部署应用程序之前在leader上运行一次。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：容器命令支持leader_only，并在部署应用程序之前在leader上运行一次。
● 场景匹配：容器命令支持leader_only，并在部署应用程序之前在leader上运行一次。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 跨实例运行命令，缺乏 Elastic Beanstalk 领导者选举，存在并行执行的风险。
● 命令块不支持leader_only，因此它将在所有实例上运行。
● 预部署挂钩在每个实例上运行，除非您实现自己的锁定；不是内置的单次运行机制。
工作流：.ebextensions container_commands 与leader_only: true。
使用跨区域 RDS 在次要区域实施指示灯
这可以通过持续复制满足分钟级的 RPO，并通过在故障转移之前保持大部分计算关闭来最大限度地降低稳态成本。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这可以通过持续复制满足分钟级的 RPO，并通过在故障转移之前保持大部分计算关闭来最大限度地降低稳态成本。
● 场景匹配：这可以通过持续复制满足分钟级的 RPO，并通过保持大部分计算关闭来最大限度地降低稳态成本。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 缩短恢复时间，但保持始终在线的环境，这比实现小时级 RTO 目标所需的成本更高。
● 实现出色的 RTO/RPO，但考虑到成本限制和工时级别的 RTO，这是最昂贵且不必要的。
● 由于快照复制和还原时间的原因，通常无法满足 20 分钟的 RPO，并且可能超过 4 小时的 RTO。
工作流：在辅助区域中使用跨区域 RDS PostgreSQL 只读副本、准备启动的最小应用程序堆栈实施试点 → 用于故障转移的 Route 53 运行状况检查，并在灾难期间将副本提升为主副本。
ACM ALB 证书； CloudFront 自定义域上 us-east-1 中的 ACM 证书
CloudFront 需要 us-east-1 中的自定义域证书，通过查看器协议策略强制查看器 HTTPS，并通过源协议策略强制执行源 HTTPS。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudFront 需要 us-east-1 中的自定义域证书，通过查看器协议策略强制查看器 HTTPS，并通过源协议策略强制执行源 HTTPS。
● 场景匹配：CloudFront 需要 us-east-1 中的自定义域证书，通过查看器协议策略强制查看器 HTTPS，并通过源协议策略强制执行源 HTTPS。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 自签名 ALB 证书不受 CloudFront 信任，并且会破坏源 HTTPS 验证。
● Match Viewer 允许来自查看器的 HTTP，因此 HTTPS 不是端到端强制执行的。
● CloudFront 自定义域证书必须位于 us-east-1 中，而不是 ALB 的区域中。
工作流：ALB 上的 ACM 证书 → CloudFront 自定义域上 us-east-1 中的 ACM 证书 → 仅查看器 HTTPS → 源 HTTPS。
一个 EC2 Auto Scaling 生命周期挂钩，用于将实例移动到终止状态
Terminate:Wait 生命周期挂钩会暂停终止，以便您可以在实例最终终止之前连接到实例并进行调试。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Terminate:Wait 生命周期挂钩会暂停终止，以便您可以在实例最终终止之前连接到实例并进行调试。
● 场景匹配：Terminate:Wait 生命周期挂钩会暂停终止，以便您可以在实例最终终止之前连接到实例并进行调试。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 暂停 AZRebalance 仅会停止跨可用区的重新平衡，并不会阻止基于运行状况检查的终止事件。
● 实例缩减保护会阻止缩减，但不会阻止由失败的运行状况检查或实例替换逻辑驱动的终止。
● 快照或 AMI 不会捕获内存中状态，并且在实例终止时可能不完整，这限制了实时调试。
工作流：添加 EC2 Auto Scaling 生命周期挂钩，将实例从进入 Termination 状态移至 Terminate:Wait 状态，以允许故障排除访问。
CloudWatch Logs 订阅 Lambda 标签实例； EventBridge 每 30 分钟触发一次
端到端自动化，可对日志事件做出反应并定期终止标记的实例，无需人工干预。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：端到端自动化，可对日志事件做出反应并定期终止标记的实例，无需人工干预。
● 场景匹配：端到端自动化，可对日志事件做出反应并定期终止标记的实例，无需人工干预。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● EC2 警报操作需要将每个实例警报与实例指标相关联，并且对于动态实例的日志派生指标来说不实用或不可靠。
● 涉及通知后的手动步骤，因此它不是完全自动化的。
● CloudWatch Logs 订阅无法直接传送到 Step Functions，因此此连接无效并会引入不必要的延迟。
工作流：CloudWatch Logs 对 Lambda 标记实例的订阅 → EventBridge 每 30 分钟就会触发 Lambda 终止标记的实例。
AWS CloudTrail 跟踪并为 AWS 添加 Amazon EventBridge 规则
它使用 CloudTrail 记录 API 调用，并使用 EventBridge 以低成本向 SNS 提供近乎实时的通知。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：它使用 CloudTrail 记录 API 调用，并使用 EventBridge 以低成本向 SNS 提供近乎实时的通知。
● 场景匹配：它使用 CloudTrail 记录 API 调用，并使用 EventBridge 向 SNS 传送近乎实时的通知。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● CloudTrail 事件选择器仅控制记录的内容，并不原生触发函数，因此如果您必须在交付后解析日志，这会增加复杂性和延迟。
● DynamoDB Streams 捕获项目级别的更改，而不是像 DeleteTable 这样的管理操作，因此它们不会可靠地通知表删除。
● AWS Config 评估不适用于近乎实时的 API 审核，并且会引入额外的 Lambda 和评估成本。
工作流：创建 AWS CloudTrail 跟踪并通过 CloudTrail 为 AWS API 调用添加 Amazon EventBridge 规则，该规则与 DeleteTable 匹配并定位 Amazon SNS。
终止：等待 EventBridge 调用 SSM Automation 的生命周期挂钩来刷新日志，然后
Terminate:Wait 挂钩会暂停缩减，触发自动化以刷新 CloudWatch 代理，并完成挂钩，以便在终止之前捕获日志。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Terminate:Wait 挂钩会暂停缩减，触发自动化以刷新 CloudWatch 代理，并完成挂钩，以便在终止之前捕获日志。
● 场景匹配：Terminate:Wait 挂钩会暂停缩减，触发自动化以刷新 CloudWatch 代理，并完成挂钩，以便在终止之前捕获日志。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Pending：等待适用于实例启动期间，而不是缩容或终止期间，因此不会延迟终止以收集日志。
● 连续流有帮助，但突然终止可能会阻止最终刷新，并且仍然会丢失日志。
● 订阅过滤器会移动 CloudWatch 中已有的日志；它们不会捕获代理上传日志之前丢失的日志。
工作流：终止：等待 EventBridge 生命周期挂钩调用 SSM 自动化来刷新日志，→ 完成。
在 AWS CloudFormation 中的堆栈上调用ContinueUpdateRollback + 手动修复资源
ContinueUpdateRollback 指示 CloudFormation 在解决阻塞问题后继续回滚。修复带外更改或丢失的依赖项可以使回滚在您继续时完成。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：ContinueUpdateRollback 指示 CloudFormation 在解决阻塞问题后继续回滚。
● 场景匹配：ContinueUpdateRollback 指示 CloudFormation 在解决阻塞问题后继续回滚。修复带外更改或丢失的依赖项可以使回滚在您继续时完成。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 重用以前的模板不会推进已失败的回滚，也不会解决 UPDATE_ROLLBACK_FAILED 状态。
● StackSet 跨账户和区域管理堆栈，并不是修复单个堆栈回滚故障的机制。
● 偏差检测报告配置差异，但不会清除 UPDATE_ROLLBACK_FAILED 条件。
工作流：在 AWS CloudFormation 中对堆栈调用ContinueUpdateRollback → 手动修复资源，使它们与堆栈的最后一个良好状态匹配。
将密钥存储在使用 KMS 加密的 AWS Secrets Manager 中，通过以下方式授予访问权限
Secrets Manager 是一种专用的密钥服务，支持自动轮换、通过容器密钥进行 ECS 集成、KMS 加密和更大的密钥大小。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Secrets Manager 是一种专用的密钥服务，支持自动轮换、通过容器密钥集成 ECS、KMS 加密。
● 场景匹配：Secrets Manager 是一种专用的密钥服务，支持自动轮换、通过容器密钥集成 ECS、KMS 加密。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 具有 SSE-KMS 和生命周期规则的 S3 不提供本机秘密轮换或 ECS 秘密注入，并且不是专用的秘密存储。
● Parameter Store 缺乏内置的自动秘密轮换，并且具有不满足更大秘密值的大小限制。
● KMS 管理加密密钥，而不是存储和轮换应用程序机密以供 ECS 任务检索。
工作流：将密钥存储在使用 KMS 加密的 AWS Secrets Manager 中→通过 ECS 任务执行角色授予访问权限，并在启用了自动轮换的环境变量的容器定义中引用密钥 ARN。
适用于 DynamoDB 的 DAX 和带有 CloudFront 的前端 S3
DAX 为 DynamoDB 读取提供与 API 兼容的内存缓存，并在边缘 CloudFront 缓存 S3，以减少延迟和成本。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：DAX 为 DynamoDB 读取提供与 API 兼容的内存缓存，并在边缘 CloudFront 缓存 S3，以减少延迟和成本。
● 场景匹配：DAX 为 DynamoDB 读取提供与 API 兼容的内存缓存，并在边缘 CloudFront 缓存 S3，以减少延迟和成本。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Redis 可以缓存读取，但与 DynamoDB 的 API 不兼容，并且会增加操作开销； CloudFront 对 S3 有帮助。
● API 网关缓存要求 API 位于 API 网关上，并且传输加速可加快上传速度，而不是用于读取的边缘缓存。
● CloudFront over ALB 不缓存 DynamoDB 结果，按需容量仅调整吞吐量，而不调整读取缓存。
工作流：使用 CloudFront 为 DynamoDB 和前端 S3 启用 DAX。
CloudTrail 日志文件完整性验证
使用加密摘要和签名来验证真实性并保留日志文件的有序序列。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：使用加密摘要和签名来验证真实性并保留日志文件的有序序列。
● 场景匹配：使用加密摘要和签名来验证真实性并保留日志文件的有序序列。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 提供 WORM 不变性，但不证明 CloudTrail 日志来源或事件排序。
● 加密和版本化对象，但不提供加密监管链或排序。
● 强制执行保留策略，但不验证日志的生成者或其序列。
工作流：CloudTrail 日志文件完整性验证。
自动缩放滚动更新
此 UpdatePolicy 对 Auto Scaling 组执行滚动更新，并支持 MinInstancesInService 和 MaxBatchSize 以在实例替换期间保留容量。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：此 UpdatePolicy 对 Auto Scaling 组执行滚动更新，并支持 MinInstancesInService 和 MaxBatchSize 以在实例替换期间保留容量。
● 场景匹配：此 UpdatePolicy 对 Auto Scaling 组执行滚动更新，并支持 MinInstancesInService 和 MaxBatchSize 以在实例替换期间保留容量。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● UpdatePolicy 可以替换整个 Auto Scaling 组或所有实例，并且不适合通过受控批量部署来维护服务中的容量。
● 是部署服务，而不是用于在模板中的 Auto Scaling 组资源内编排滚动更新的 CloudFormation UpdatePolicy。
● 不是有效的 CloudFormation UpdatePolicy，因此不能用于管理模板中的 Auto Scaling 组更新。
工作流：自动缩放滚动更新。
将流的数据保留时间增加到 72 小时 + 运行 KCL
延长保留时间可以让积压的消费者有更多时间在记录过期之前赶上。仅当以下情况时，基于滞后的 KCL 工作人员扩展才直接增加处理能力。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：延长保留时间可以让积压的消费者有更多时间在记录过期之前赶上。
● 场景匹配：延长保留时间可以让积压的消费者有更多时间在记录过期之前赶上。基于 KCL 工人的扩展。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 添加分片会增加生产者吞吐量和潜在并行性，但无法解决单个配置不足的消费者主机和添加问题。
● 迁移到 Lambda 需要进行架构更改，并且并不能从本质上解决消费者延迟的根本原因。
● 切换到 SQS 是一个重大的重新设计，它会丢失分片语义，并且不是最小更改的可靠性修复。
工作流：将流的数据保留时间增加到 72 小时 → 在 EC2 实例的 Auto Scaling 组中运行 KCL 应用程序，并根据 MillisBehindLatest CloudWatch 指标进行扩展。
具有 S3 共享和 Lambda 触发的 Rekognition 的 AWS Storage Gateway 文件网关
提供由 S3 支持的 NFS/SMB，以最大限度地减少工作流程更改，并可以通过 Lambda 对新的 S3 对象调用 Rekognition。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：提供由 S3 支持的 NFS/SMB，以最大限度地减少工作流程更改，并且可以通过 Lambda 对新的 S3 对象调用 Rekognition。
● 场景匹配：提供由 S3 支持的 NFS/SMB，以最大限度地减少工作流程更改，并可以通过 Lambda 对新的 S3 对象调用 Rekognition。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 专为实时或近实时流而不是批量文件存档而设计，并增加了不必要的管道复杂性。
● Rekognition 无法直接分析 Glacier 类中的对象；恢复和补液会增加开销。
● 需要构建和操作自定义计算和软件，增加持续的管理工作。
工作流：具有 S3 共享和 Lambda 触发的 Rekognition 的 AWS Storage Gateway 文件网关。
用于无服务器应用程序的 AWS SAM 模板并通过 AWS 进行部署
这通过内置警报和自动回滚执行小金丝雀转变，以最大限度地减少缺陷的影响。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这通过内置警报和自动回滚执行小金丝雀转变，以最大限度地减少缺陷的影响。
● 场景匹配：这通过内置警报和自动回滚执行小金丝雀转变，以最大限度地减少缺陷的影响。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 实现加权流量转移，但缺乏专用部署策略中的集成运行状况检查和自动回滚。
● AllAtOnce 立即转移 100% 的流量，在故障期间最大限度地扩大影响范围。
● AppConfig 管理配置和功能标志，但不执行 Lambda 版本流量转移或代码回滚。
工作流：对无服务器应用程序使用 AWS SAM 模板，并使用 Canary5Percent15Minutes 部署类型通过 AWS CodeDeploy 进行部署。
AWS Step Functions 从每个基准 AMI 启动 EC2 实例
这会协调实例启动、安装所需的代理、通过标签确定目标范围，并使用 EventBridge 进行可靠的调度。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这会协调实例启动、安装所需的代理、通过标签确定目标范围，并使用 EventBridge 进行可靠的调度。
● 场景匹配：这会协调实例启动、安装所需的代理、通过标签确定目标范围，并使用 EventBridge 进行可靠的调度。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 使用 CloudWatch Alarms 进行调度并忽略确保 Inspector 代理存在，因此不适合。
● 缺乏基于标记的范围并滥用事件总线而不是预定的 EventBridge 规则。
● Patch Manager 评估托管实例的补丁合规性，而不是对 AMI 派生实例执行 Amazon Inspector CVE 评估。
工作流：使用 AWS Step Functions 从适用于 Linux 和 Windows 的每个基准 AMI 启动 EC2 实例 → 安装 Amazon Inspector 代理 → 应用跟踪标签 → 调用 Inspector。
post_build 命令将镜像推送到 ECR
post_build 仅在先前阶段成功时运行，因此推送仅在成功构建时发生。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：post_build 仅在先前阶段成功时运行，因此推送仅在成功构建时发生。
● 场景匹配：post_build 仅在先前阶段成功时运行，因此推送仅在成功构建时发生。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 无论成功还是失败，finally 序列都会运行，即使构建失败也可以推送。
● 管道编排不会改变构建规范阶段的行为；仅成功推送应在 buildspec.yml 中控制。
● Pre_build 在构建完成之前运行，即使稍后构建失败，也会面临推送风险。
工作流：使用 post_build 命令将映像推送到 ECR。
具有两个目标群体的单一 ALB；部署到空闲组并翻转
通过在 ALB 层交换流量，从切换路径中删除 DNS，从而简化并降低成本。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：通过在 ALB 层交换流量，从切换路径中删除 DNS，从而简化并降低成本。
● 场景匹配：通过在 ALB 层交换流量，从切换路径中删除 DNS，从而简化并降低成本。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 仍然依赖 DNS，因此固定或忽略更新的客户端可能会继续使用旧的 ALB。
● 与单一 ALB 方法相比，避免了 DNS 传播问题，但增加了成本和复杂性。
● 较短的 TTL 无助于缓存或固定超出 TTL 的 DNS 响应的客户端。
工作流：具有两个目标组的单个 ALB → 部署到空闲组并将侦听器翻转到新组。
跟踪上的 CloudTrail 日志文件完整性验证，以便 CloudTrail 提供签名的
CloudTrail 的日志文件完整性验证是创建签名摘要文件的最省力的原生方法，可对日志文件进行防篡改验证。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudTrail 的日志文件完整性验证是创建防篡改的签名摘要文件的最省力的原生方法。
● 场景匹配：CloudTrail 的日志文件完整性验证是创建防篡改的签名摘要文件的最省力的原生方法。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● S3 不提供 CloudTrail 日志完整性验证，因为该功能是在 CloudTrail 中配置的，并且更改 IAM 权限不会启用验证。
● 状态管理器无法直接切换 CloudTrail 日志文件完整性验证，因为该设置是在 CloudTrail 本身内或通过其 API 启用的。
● AWS Audit Manager 可帮助管理合规性证据，但不提供 CloudTrail 日志文件的加密完整性验证。
工作流：在跟踪上启用 CloudTrail 日志文件完整性验证，以便 CloudTrail 提供签名的摘要文件，您可以使用它来验证所提供的日志文件。
具有 KMS 加密项目的 AWS CodeBuild
使用 AWS KMS 工件加密进行完全托管的构建，从而减少基础设施管理。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：使用 AWS KMS 工件加密进行完全托管的构建，从而减少基础设施管理。
● 场景匹配：使用 AWS KMS 工件加密进行完全托管的构建，从而减少基础设施管理。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 加密静态对象，但保留自我管理的 Jenkins 和相关的操作开销。
● 保护实例和块存储，但不确保工件加密，并且仍然需要实例管理。
● 将 Jenkins 移至容器，但仍保持自我管理； SSE-S3 进行加密，但操作负担仍然存在。
工作流：将 AWS CodeBuild 与 KMS 加密的项目结合使用。
源管道角色可以在目标账户中使用的角色
跨账户操作需要目标账户中具有受源账户的 CodePipeline 服务角色信任的 IAM 角色。 CodePipeline 工件存储桶必须进行版本控制并且是跨账户的。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：跨账户操作需要目标账户中具有受源账户的 CodePipeline 服务角色信任的 IAM 角色。
● 场景匹配：跨账户操作需要目标账户中具有受源账户的 CodePipeline 服务角色信任的 IAM 角色。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● S3存储桶无法通过AWS RAM共享；访问通过 IAM 角色和存储桶策略进行管理。
● 除非跨区域，否则不需要多区域密钥；仅跨帐户不需要它们。
● 承担的角色必须驻留在目标账户中；将其放入源帐户会反转信任方向。
工作流：在源管道角色可以通过 sts:AssumeRole 承担的目标帐户中配置一个角色 → 在工件存储桶上启用版本控制，并使用客户管理的工件 KMS 密钥。
AWS Config 通过 SSM 自动化修复和 SNS + EventBridge 计划批准了amis-id
持续评估 EC2 AMI 合规性，并可以通过停止或终止和通知来自动修复，而不会阻止启动。比较 AMI 和修复的侦探性定期检查可保持管道畅通并最大限度地减少中断。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：持续评估 EC2 AMI 合规性，并可以通过停止或终止和通知来自动修复，而不会阻止启动。
● 场景匹配：持续评估 EC2 AMI 合规性，并可以通过停止或终止和通知来自动修复，而不会阻止启动。一个。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 预防性权限策略将阻止未经批准的 AMI 并扰乱暂存和 CI 工作流程。
● 组织范围内的预防性控制，将停止实验性 AMI 并干扰开发人员工作流程。
● Trusted Advisor 不提供 AMI 白名单检查或自动修复，因此无法强制执行此要求。
工作流：AWS Config 通过 SSM 自动化修复和 SNS 批准了 amis-id → EventBridge 安排 15 分钟调用 Lambda 来终止不合规的 EC2 并发出通知。
一个 AWS Config 规则，其配置更改触发器的范围为
更改触发的 AWS Config 规则近乎实时地进行评估，并可以通过 Lambda 调用 SSM 自动化来自动修复偏差。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：更改触发的 AWS Config 规则近乎实时地进行评估，并可以通过 Lambda 调用 SSM 自动化。
● 场景匹配：更改触发的 AWS Config 规则近乎实时地进行评估，并可以通过 Lambda 调用 SSM 自动化。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 计划扫描会带来长达 20 分钟的延迟，并且需要自定义策略解析，这比扫描要慢。
● 定期规则以固定的时间间隔运行，不会近乎实时地检测变化。
● 虽然可能，但这种方法需要复杂的事件模式并且缺乏资源状态评估，从而使其不太可靠。
工作流：使用范围为 S3 存储桶和联合角色的配置更改触发器配置 AWS Config 规则，并通过 Lambda 调用 AWS Systems Manager Automation Runbook 以恢复批准的设置。
CodeBuild 执行测试，在 CodePipeline 中插入手动批准操作
这使用了 CodePipeline 的内置手动审批操作以及可选的 SNS 警报，这是在生产前强制实施人工控制的最简单且成本最低的方法。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这使用 CodePipeline 的内置手动批准操作和可选的 SNS 警报，这是最简单且成本最低的方法。
● 场景匹配：这使用 CodePipeline 的内置手动批准操作和可选的 SNS 警报，这是最简单且成本最低的方法。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 与本机 CodeBuild 相比，使用 Step Functions 进行测试会增加额外的复杂性和成本，并且没有必要。
● 当本机手动审批操作已经解决了问题时，自定义操作和工作人员会引入开发和运营开销。
工作流：使用 CodeBuild 执行测试，在生产 CodeDeploy 阶段之前在 CodePipeline 中插入手动审批操作，并向审批者发送 SNS 通知，→ 审批后继续进行生产部署。
采用具有 KCL 的 DynamoDB Streams Kinesis Adapter 并卸载繁重的聚合
带有 KCL 的 Kinesis Adapter 通过检查点提供协调、可扩展的分片消耗，Flink 可以有效处理有状态聚合。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：带有 KCL 的 Kinesis Adapter 通过检查点提供协调、可扩展的分片消耗，Flink 可以有效处理有状态聚合。
● 场景匹配：带有 KCL 的 Kinesis Adapter 通过检查点提供协调、可扩展的分片消耗，Flink 可以有效处理有状态聚合。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● DynamoDB Streams 不支持增强型扇出，并且添加使用者不会绕过每个分片的读取限制。
● 调整 Lambda 和表容量并不能克服共享分片吞吐量限制或多消费者争用。
● 增加了成本和复杂性，并且 AWS Glue 流本身并不消耗 DynamoDB 流。
工作流：采用具有 KCL 的 DynamoDB Streams Kinesis 适配器，并将繁重的聚合卸载到 Amazon Managed Service for Apache Flink。
ALB 目标组运行状况检查配置错误
不正确的路径、端口或成功代码会导致新目标运行状况不佳，因此即使 CodeDeploy 日志没有显示直接错误，AllowTraffic 也无法完成。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：不正确的路径、端口或成功代码会导致新目标运行状况不佳，因此即使 CodeDeploy 日志没有显示直接错误，AllowTraffic 也无法完成。
● 场景匹配：不正确的路径、端口或成功代码会导致新目标运行状况不佳，因此即使 CodeDeploy 日志没有显示直接错误，AllowTraffic 也无法完成。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● WAF 评估客户端请求，并且不会干扰 ALB 到目标的运行状况探测。
● 缩减可能会破坏部署，但它通常表现为实例或生命周期事件故障，而不仅仅是静默的AllowTraffic 故障。
● 缺少权限会导致部署日志中出现显式 IAM 错误，而不是在AllowTraffic 中出现安静的故障。
工作流：ALB 目标组运行状况检查配置错误。
用于侦听 Trusted Advisor 检查状态更新的 Amazon EventBridge 规则
EventBridge 可以过滤 Trusted Advisor 状态更改事件并将其转发到 SNS 以获取即时通知。预定的 Lambda 可以查询 Trusted Advisor 并发布可操作的结果。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：EventBridge 可以过滤 Trusted Advisor 状态更改事件并将其转发到 SNS 以获取即时通知。
● 场景匹配：EventBridge 可以过滤 Trusted Advisor 状态更改事件并将其转发到 SNS 以获取即时通知。预定的 Lambda。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 内置的 Trusted Advisor 通知每周发送一次，但频率不足以快速控制成本。
● EventBridge 不为 Trusted Advisor 提供一键式自动通知，并且需要明确的规则和目标。
● EventBridge 本身并不针对 SES，因此电子邮件警报应通过 SNS 或 Lambda 路由。
工作流：创建一个 Amazon EventBridge 规则，用于侦听 Trusted Advisor 检查状态更新并将匹配项路由到 Amazon SNS 主题以获取电子邮件警报 → 每天安排一个 AWS Lambda 函数。
对源实施 HTTPS 并启用 CloudFront 字段级加密，并具有
字段级加密可保护 CloudFront 中的特定字段，而 HTTPS 可保护传输安全，而较长的 max-age 可以使对象在边缘缓存中保留更长时间，以提高命中率。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：字段级加密可保护 CloudFront 中的特定字段，而 HTTPS 可保护传输安全，长最长期限可将对象保持在边缘。
● 场景匹配：字段级加密可保护 CloudFront 中的特定字段，而 HTTPS 可保护传输安全，长最长期限可将对象保持在边缘。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 签名 URL 限制谁可以访问内容，但它们不会加密敏感表单字段或满足字段级保护。
● 源访问身份可保护 S3 源的安全，并且请求标头的变化通常会分段缓存条目，但这两种方法都不是。
● KMS 提供静态加密，Origin Shield 优化源获取，但这些不会加密字段。
工作流：对源实施 HTTPS 并启用 CloudFront 字段级加密，并让源发送具有最长安全值的 Cache-Control max-age。
Auto Scaling 组中无状态 EC2 上的站点并移动
Kinesis Data Firehose 向 S3 提供托管、近乎实时的交付，并可以通过 S3 临时存储桶加载 Redshift，从而与规模和分析保持一致。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Kinesis Data Firehose 向 S3 提供托管、近乎实时的交付，并可以通过 S3 加载 Redshift。
● 场景匹配：Kinesis Data Firehose 向 S3 提供托管、近乎实时的交付，并可以通过 S3 加载 Redshift。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Kinesis Data Streams 本身并不传输到 S3 或 Redshift，需要消费者或 Firehose 进行接收。
● Athena 是基于 S3 的查询服务，不用于将流数据提取或加载到 S3 中。
工作流：在 Auto Scaling 组中的无状态 EC2 上运行站点，并将 SQL Server 移动到 Amazon RDS → 使用 Amazon Kinesis Data Firehose 将点击事件传送到 Amazon S3。
为 ECS 部署定义 AppSpec 挂钩并使用 AfterAllowTestTraffic 事件
这使用了 CodeDeploy 生命周期钩子，旨在在流量之前验证绿色环境，并利用钩子失败来自动回滚。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这使用了 CodeDeploy 生命周期挂钩，旨在在流量之前验证绿色环境并利用挂钩失败。
● 场景匹配：这使用了 CodeDeploy 生命周期挂钩，旨在在流量之前验证绿色环境并利用挂钩失败。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 使用 CodeBuild 将测试置于单独的 CodePipeline 阶段，并通过调用 CLI 中止部署。
● 仅在生产流量已转移后运行测试，然后尝试通过 CLI 取消部署。
● 在 CodeDeploy 生命周期之外运行测试，并依赖单独的 CLI 调用来取消部署。
工作流：为 ECS 部署定义 AppSpec 挂钩，并使用 AfterAllowTestTraffic 事件调用运行测试的 AWS Lambda 函数 → 如果任何测试失败，则从函数返回错误以触发回滚。
用于 S3 静态内容的 Amazon CloudFront 发行版并引入 DynamoDB
CloudFront 全局缓存 S3 资产，DAX 提供与 API 兼容的内存缓存，以吸收具有微秒延迟的重复 DynamoDB 读取。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudFront 全局缓存 S3 资产，DAX 提供与 API 兼容的内存缓存，以吸收具有微秒延迟的重复 DynamoDB 读取。
● 场景匹配：CloudFront 全局缓存 S3 资产，DAX 提供与 API 兼容的内存缓存，以吸收具有微秒延迟的重复 DynamoDB 读取。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Lambda@Edge 无意大规模缓存静态文件，全局表也无法消除应用层的重复读取压力。
● MediaStore 的目标是媒体工作流程和扩展 Redis 不会直接解决重复的 DynamoDB 读取或为 S3 对象提供全局 CDN。
● MediaPackage 专为视频打包而构建，Memcached 增加了复杂性，而没有 DAX 提供的 DynamoDB 感知缓存。
工作流：为 S3 静态内容创建 Amazon CloudFront 分配，并引入 DynamoDB Accelerator 以卸载重复读取。
API Gateway阶段金丝雀，设置10%流量，在CloudWatch中监控
API Gateway 阶段金丝雀原生地分割指定百分比的请求，并在 CloudWatch 中公开单独的金丝雀指标。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：API Gateway 阶段金丝雀原生地分割指定百分比的请求，并在 CloudWatch 中公开单独的金丝雀指标。
● 场景匹配：API Gateway 阶段金丝雀原生地拆分指定百分比的请求，并在 CloudWatch 中公开单独的金丝雀指标。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Lambda 别名权重会改变 Lambda 版本，而不是 API Gateway 阶段部署。
● Route 53 在 DNS 或域级别工作，而不是在一个 API 路径上工作，并且客户端缓存使精确百分比不太可靠。
● 使用计划应用配额和限制。
工作流：启用 API Gateway 阶段金丝雀 → 设置 10% 流量 → 在 CloudWatch 中监控。
将失败消息发送到 DLQ 的重新驱动策略
重新驱动策略将超过 maxReceiveCount 的消息移至死信队列进行分析。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：重新驱动策略将超过 maxReceiveCount 的消息移至死信队列进行分析。
● 场景匹配：重新驱动策略将超过 maxReceiveCount 的消息移至死信队列进行分析。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● FIFO 排序无助于捕获或检查失败的消息。
● 较长的保留时间可以使消息保持更长的时间，但不能隔离故障以进行检查。
● 长轮询可以减少空接收和成本，但不会捕获失败的消息。
工作流：启用重新驱动策略以将失败的消息发送到 DLQ。
AWS Config 自定义规则组织范围内具有聚合器 + SSM 自动化构建
组织范围内的自定义规则检查 AMI ID，聚合器提供集中的合规性可见性。集中共享最新的 AMI 并取消共享前一个 AMI 会阻止旧 AMI 的新启动。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：组织范围内的自定义规则检查 AMI ID，聚合器提供集中的合规性可见性。
● 场景匹配：组织范围内的自定义规则检查 AMI ID，聚合器提供集中的合规性可见性。集中分享最新动态。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● SCP 只能强制从经批准的 AMI 启动，但不提供集中合规性视图。
● 复制会导致过时的 AMI 激增，并且不会阻止旧副本的新启动。
● 去中心化的 AMI 创建会增加偏差，并使旧 AMI 的报废和合规性报告变得更加复杂。
工作流：使用聚合器在组织范围内使用 AWS Config 自定义规则 → SSM Automation 集中构建 AMI → 与组织共享新 AMI 并取消共享旧 AMI。
将流保留时间增加到 96 小时 + 在一个
延长保留时间可以让积压的消费者有更多的时间在记录过期之前进行处理，并且只需进行最小的操作更改。由于 KCL 管理分片租赁，因此根据延迟扩展 KCL 工作线程可以以最少的代码更改提高消费者容量。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：延长保留时间可以让积压的消费者有更多时间在记录过期之前进行处理，并且只需进行最少的操作更改。
● 场景匹配：延长保留时间可以让积压的消费者有更多的时间在记录过期之前进行处理，并且只需进行最小的操作更改。缩放。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 增强型扇出增加了每个消费者的吞吐量，但无法修复单主机瓶颈，并且需要消费者进行更改。
● 更多分片可以提高生产者的吞吐量和潜在的并行性，但不能解决单个消费者供应不足的问题。
● 需要更大的架构更改，并且不是解决当前滞后问题的最小路径。
工作流：将流保留时间增加到 96 小时 → 在 Auto Scaling 组中运行 KCL 工作线程并在 MillisBehindLatest 上进行扩展。
启动堆栈的ContinueUpdateRollback +修复资源问题以匹配
在纠正阻塞问题后，ContinueUpdateRollback 会恢复失败的回滚，以便 CloudFormation 可以将堆栈恢复到稳定状态。手动更正带外更改或依赖性问题可以使回滚在继续时成功。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：在纠正阻塞问题后，ContinueUpdateRollback 会恢复失败的回滚，以便 CloudFormation 可以将堆栈恢复到稳定状态。
● 场景匹配：在您更正阻塞问题后，ContinueUpdateRollback 会恢复失败的回滚，以便 CloudFormation 可以将堆栈返回到 a.
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 漂移检测仅报告实际资源与模板之间的差异；它不会更改堆栈状态或解决回滚失败。
● 更改集预览建议的更新；它们不能解决陷入 UPDATE_ROLLBACK_FAILED 的堆栈。
● 当堆栈处于 UPDATE_ROLLBACK_FAILED 状态时，更新将被阻止，并且重用旧模板不会推进回滚。
工作流：为堆栈启动ContinueUpdateRollback → 修复资源问题以匹配上次成功的堆栈状态。
亚马逊内存数据库
MemoryDB 是一个兼容 Redis 的持久主数据库，具有多可用区复制和强写后读一致性。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：MemoryDB 是一个兼容 Redis 的持久主数据库，具有多可用区复制和强写后读一致性。
● 场景匹配：MemoryDB 是一个兼容 Redis 的持久主数据库，具有多可用区复制和强写后读一致性。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● DAX 是 DynamoDB 的缓存，而不是独立的与 Redis 兼容的持久数据库。
● Memcached 没有针对主数据库的持久性或本机复制模型。
● ElastiCache for Redis 主要设计为缓存，尽管它支持复制和持久性选项。
工作流：亚马逊内存数据库。
使用 Systems Manager 将本地服务器注册到 AWS Systems Manager
混合激活将本地计算机注册为托管实例，以便补丁管理器可以与 EC2 一起定位和修补它们。实例配置文件授予 SSM 代理权限。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：混合激活将本地计算机注册为托管实例，以便补丁管理器可以与 EC2 一起定位和修补它们。
● 场景匹配：混合激活将本地计算机注册为托管实例，以便补丁管理器可以与 EC2 一起定位和修补它们。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 服务器上的长期访问密钥不安全，并且不是将本地实例加入 AWS 系统的受支持方法。
● EventBridge 可以触发工作流程，但修补计划最好通过 Systems Manager Maintenance Windows 和 Patch Manager 来实施。
工作流：使用 Systems Manager 混合激活向 AWS Systems Manager 注册本地服务器 → 将 IAM 实例配置文件附加到允许 AWS Systems Manager 管理它们的 EC2 实例。
具有按 id 批准的 amis 的 AWS Config
此托管规则根据认可的 AMI ID 列表评估 EC2 实例，并可以将合规性更改推送到 SNS。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：此托管规则根据认可的 AMI ID 列表评估 EC2 实例，并可以将合规性更改推送到 SNS。
● 场景匹配：此托管规则根据认可的 AMI ID 列表评估 EC2 实例，并可以将合规性更改推送到 SNS。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Inspector 专注于漏洞和暴露评估，而不是根据允许列表验证实例 AMI ID。
● 这些预防性控制措施将阻止启动未经批准的 AMI，这违反了非阻止要求。
● Security Hub 汇总发现结果，但本身并不评估 AMI 许可名单；它依赖于 Config 等集成源。
工作流：AWS Config 具有按 ID 批准的amis。
AWS CloudFormation StackSets 通过中央管理员帐户推出相同的服务
StackSets 本身支持通过管理员帐户进行一致、自动化的多区域部署，同时保持每个区域的堆栈隔离。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：StackSets 本身支持通过管理员帐户进行一致、自动化的多区域部署，同时保持每个区域的堆栈隔离。
● 场景匹配：StackSets 本身支持通过管理员帐户进行一致、自动化的多区域部署，同时保持每个区域的堆栈隔离。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 更改集预览对单个堆栈的更新，并非旨在跨多个区域协调部署。
● 虽然 CodePipeline 可以协调跨区域的操作，但与 StackSet 相比，它并不是一致提供相同区域基础设施的最直接机制。
● AWS CLI 仅支持单个 --region 标志，并且不提供用于并行多区域堆栈创建的 --regions 参数。
工作流：从中央管理员账户使用 AWS CloudFormation StackSets 将相同的堆栈部署到选定区域。
运行 SSM Automation Runbook 的 AWS Health 停用事件的 EventBridge 规则
AWS Health 精确发出停用事件，SSM Automation 通过护栏和日志记录可靠地编排停止/启动工作流程。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：AWS Health 精确发出停用事件，SSM Automation 通过护栏和日志记录可靠地编排停止/启动工作流程。
● 场景匹配：AWS Health 精确发出停用事件，SSM Automation 通过护栏和日志记录可靠地编排停止/启动工作流程。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 自动恢复解决受损的系统状态检查问题，而不是计划的停用，并且不会安排停止然后启动的顺序。
● 可以工作，但需要自定义代码，并且缺乏 SSM Automation 的内置控件、运行手册和操作安全性。
● ASG 对健康问题做出反应，不会主动处理计划的停用或保证同一实例的停止/启动。
工作流：运行 SSM Automation Runbook 来停止 → 启动实例的 AWS Health 停用事件的 EventBridge 规则。
存储桶的 CloudTrail S3 数据事件、存储在 S3 中以及查询
CloudTrail 数据事件捕获对象级 API 调用；存储在 S3 中并使用 Athena 进行查询可提供低成本的按需搜索。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudTrail 数据事件捕获对象级 API 调用；存储在 S3 中并使用 Athena 进行查询可提供低成本的按需搜索。
● 场景匹配：CloudTrail 数据事件捕获对象级 API 调用；存储在 S3 中并使用 Athena 进行查询可提供低成本的按需搜索。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● EventBridge 不会直接接收 S3 对象级 API 事件，除非 CloudTrail 将它们作为数据事件发出。
● S3 访问日志缺乏完整的 API 审核详细信息，并且运行 OpenSearch 会增加持续成本。
● 管理事件不包括 S3 数据事件，因此会错过对象级操作。
工作流：为存储桶打开 CloudTrail S3 数据事件 → 存储在 S3 中，并使用 Athena 进行查询。
托管 AWS Systems Manager 的 VPC 中的接口 VPC 终端节点
接口 VPC 终端节点将会话管理器流量保留在 AWS 专用网络路径上。 SSM 代理需要具有与 Systems Manager 通信权限的实例角色。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：接口 VPC 终端节点将会话管理器流量保留在 AWS 专用网络路径上。
● 场景匹配：接口 VPC 终端节点将会话管理器流量保留在 AWS 专用网络路径上。 SSM 代理需要一个。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Session Manager 不使用 SSH，因此没有必要打开端口 22，并且会降低安全性。
● NAT 网关提供出站 Internet 访问，但不启用专用入站会话管理器连接。
● 客户端 VPN 是可选的，并且不能确保会话管理器在没有必要终端节点的情况下使用私有 VPC 路径。
工作流：在托管实例的 VPC 中为 AWS Systems Manager 创建接口 VPC 终端节点 → 将 IAM 实例配置文件附加到授予 Systems Manager 权限的 EC2 实例。
更新现有模板以设置 DeletionPolicy 对每个资源保留、删除
保留可确保资源通过堆栈删除得以保留，从而允许您将它们导入到新命名的堆栈中，然后恢复模板设置。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：保留可确保资源通过堆栈删除得以保留，从而允许您将它们导入到新命名的堆栈中。
● 场景匹配：保留可确保资源通过堆栈删除得以保留，从而允许您将它们导入到新命名的堆栈中。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 快照会备份然后删除EBS卷，这会阻止导入原始卷并违反。
● 挂钩验证或阻止操作，但不保留资源或处理将现有资源导入到新堆栈中。
● DependsOn 仅命令堆栈内的资源创建，不便于重命名或导入现有资源。
工作流：更新现有模板以在每个资源上设置 DeletionPolicy Retain，删除堆栈以便保留资源 → 使用新名称创建新堆栈，导入保留的 S3。
NLB 使用 SSE-S3 访问 S3 日志，允许 Delivery.logs.amazonaws.com 写入，并且
这是 AWS 推荐的配置：NLB 访问日志到 S3，使用 SSE-S3 进行静态加密，允许日志记录主体写入的存储桶策略以及最低权限。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这是 AWS 推荐的配置：NLB 访问日志到 S3，使用 SSE-S3 静态加密、允许日志记录主体写入的存储桶策略以及团队的最低权限读取访问权限。
● 场景匹配：这是 AWS 推荐的配置：NLB 访问日志到 S3，使用 SSE-S3（存储桶策略）进行静态加密。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● NLB 访问日志不会直接传送到 CloudWatch Logs；它们仅传送到 Amazon S3。
● NLB 访问日志需要 SSE-S3 来传递；使用 SSE-KMS 需要复杂的密钥策略，并且不是标准支持的路径。
● VPC 流日志捕获 ENI 级别的流量，而不是 NLB 访问日志或每个连接负载均衡器详细信息。
工作流：使用 SSE-S3 启用 NLB 访问日志到 S3 → 允许 Delivery.logs.amazonaws.com 写入，并授予团队通过 IAM 读取。
在源账户中，使用以下命令创建 AMI 的加密副本
您必须使用客户管理的密钥进行加密，并允许目标账户在共享 AMI 之前在该密钥上创建授权。自动缩放。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：您必须使用客户管理的密钥进行加密，并允许目标帐户在其上创建授权。
● 场景匹配：您必须使用客户管理的密钥进行加密，并允许目标帐户在其上创建授权。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 使用 AWS 托管 KMS 密钥加密的 AMI 无法跨账户共享，因此跨账户启动失败。
● 启动权限不会授予使用加密 EBS 快照的 KMS 密钥的权限，因此实例会授予使用权限。
工作流：在源账户中 → 使用客户管理的 KMS 密钥创建 AMI 的加密副本 → 更新该密钥策略以让目标账户创建授权并共享。
默认情况下，CodeDeploy 会删除最新部署安装的文件和
CodeDeploy 会清除上次部署中的文件，并在回滚期间重新应用早期版本，因此选择“保留内容”会保留不属于其中的文件。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CodeDeploy 会清除上次部署中的文件，并在回滚期间重新应用早期版本，因此选择“保留”。
● 场景匹配：CodeDeploy 会清除上次部署中的文件，并在回滚期间重新应用早期版本，因此选择“保留”。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 错误地假设 CodeDeploy 保留任意文件，而 Overwrite 保留意外文件，但事实并非如此。
● 部署失败只是强制失败，并不能确保在回滚期间保留手动文件。
● 错误地描述了清理步骤，并且覆盖不能保证非修订文件在回滚后能够幸存。
工作流：默认情况下，CodeDeploy 会删除最新部署安装的文件，并且回滚会干净地重新部署以前的修订版 → 使用保留内容，以便保留手动添加的文件。
CloudWatch 代理将操作系统身份验证日志发送到 CloudWatch Logs；公制过滤器
CloudWatch 代理流式传输 auth.log 或 /var/log/secure，指标筛选器检测登录模式，警报通知 SNS。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudWatch 代理流式传输 auth.log 或 /var/log/secure，指标筛选器检测登录模式，警报通知 SNS。
● 场景匹配：CloudWatch 代理流式传输 auth.log 或 /var/log/secure，指标筛选器检测登录模式，警报通知 SNS。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● GuardDuty 报告可疑行为，而不是每次成功的操作系统登录。
● CloudTrail 记录 AWS 控制平面 API 调用，而不是实例内操作系统身份验证。
● 计划上传和自定义解析可以工作，但会引入延迟、脚本、存储事件和维护。
工作流：使用 CloudWatch 代理将操作系统身份验证日志发送到 CloudWatch Logs → 指标过滤器 + SNS 警报。
ALB 的 Amazon Route 53 ARC 区域转移
ARC 区域转移会暂时为 ALB 疏散一个可用区，而无需更改基础设施，仅将请求转向健康的可用区。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：ARC 区域转移会暂时为 ALB 疏散一个可用区，而无需更改基础设施，仅将请求转向健康的可用区。
● 场景匹配：ARC 区域转移会暂时为 ALB 疏散一个可用区，而无需更改基础设施，仅将请求转向健康的可用区。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 替换不健康的实例，但继续通过受损的可用区路由流量，因此它不会隔离该区域。
● 可以工作，但需要修改负载均衡器配置或堆栈，这不是要求的最小操作更改。
● 需要额外的 ALB 端点，并且无法解决隔离一个 ALB 后面的单个 AZ 的问题，从而增加了不必要的复杂性。
工作流：ALB 的 Amazon Route 53 ARC 区域转移。
作为 Elastic Beanstalk 环境中即将推出的部署策略，是不可变的
不可变更新会与新版本启动并行 Auto Scaling 组，保持旧队列服务流量，并通过终止新版本来实现快速回滚。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：不可变更新与新版本启动并行 Auto Scaling 组，保持旧队列服务流量。
● 场景匹配：不可变更新与新版本启动并行 Auto Scaling 组，保持旧队列服务流量。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 蓝/绿切换期望数据库与环境管理的 RDS 解耦；保持紧密耦合可能会导致数据丢失并使切换变得复杂。
● 使用额外批次进行滚动仍会就地更新，并且可能会在部署中失败，因此回滚仍然很慢且操作复杂。
● 一次性同时替换所有实例，这会增加停机风险，并且无法提供更安全的回滚路径。
工作流：将 Immutable 配置为 Elastic Beanstalk 环境中即将发布的版本的部署策略。
托管实例上的 Systems Manager 库存并同步到 S3 + EventBridge
SSM Inventory 从托管实例收集包元数据，资源数据同步将其导出到 S3 进行报告。计划规则可以将 EC2 实例与 SSM 托管实例进行比较，并通知未覆盖的主机。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：SSM Inventory 从托管实例收集包元数据，资源数据同步将其导出到 S3 进行报告。
● 场景匹配：SSM Inventory 从托管实例收集包元数据，资源数据同步将其导出到 S3 进行报告。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Inspector 重点关注漏洞发现和覆盖范围，而不是完整的操作系统包清单或 SSM 管理差距。
● Config 不收集操作系统软件包列表，并且其本身无法检测 SSM 管理覆盖范围差距。
● Run Command 仅针对已托管实例，无法发现非托管实例。
工作流：在托管实例上启用 Systems Manager Inventory 并同步到 S3 → EventBridge 计划每 45 分钟调用 Lambda 来区分 EC2 与 SSM 托管和警报。
账户 Y 中的 Lambda 执行角色有权使用
Lambda 执行角色必须包含通过访问点挂载和访问 EFS 所需的 VPC 和 elasticfilesystem 权限。您需要通过以下方式进行网络可达性。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Lambda 执行角色必须包含挂载和访问 EFS 所需的 VPC 和弹性文件系统权限。
● 场景匹配：Lambda 执行角色必须包含挂载和访问 EFS 所需的 VPC 和弹性文件系统权限。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● EFS 不支持 PrivateLink，因此您无法跨账户通过 PrivateLink 挂载 EFS。
● EFS 不是 AWS RAM 中的可共享资源类型，因此无法直接共享给 Lambda this。
● SCP 设置了权限护栏，但不授予访问权限，因此仍然需要资源和 IAM 策略。
工作流：在账户 Y 中配置 Lambda 执行角色，使其有权使用 VPC 并挂载 EFS 访问点 → 在账户 X 和账户中的 VPC 之间建立 VPC 对等互连。
AWS Systems Manager Parameter Store 与 CloudFormation 参数可解析最新的
这使用 CloudFormation 对 SSM Parameter Store 的支持在创建或更新时动态解析 AMI ID。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这使用 CloudFormation 对 SSM Parameter Store 的支持在创建或更新时动态解析 AMI ID。
● 场景匹配：这使用 CloudFormation 对 SSM Parameter Store 的支持在创建或更新时动态解析 AMI ID。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 建议在 CloudFormation 部署期间依靠 AWS Service Catalog 获取 AMI ID。
● 建议使用状态管理器作为参数源，即使它是为强制实例状态和合规性而设计的。
● 引入自定义自动化来修改模板，而不是使用 CloudFormation 的本机参数解析。
工作流：将 AWS Systems Manager Parameter Store 与 CloudFormation 参数结合使用来解析最新的 AMI ID 并在推出新映像时运行堆栈更新。
具有匹配标签的 IAM ABAC
基于属性的访问控制评估主体和资源标签，因此无需策略编辑即可覆盖新标记的资源。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：基于属性的访问控制评估主体和资源标签，因此无需策略编辑即可覆盖新标记的资源。
● 场景匹配：基于属性的访问控制评估主体和资源标签，因此无需策略编辑即可覆盖新标记的资源。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 权限边界设置最大权限范围，并且不授予访问权限或自动包含新资源。
● 通配符资源扩大了访问范围并违反了最低特权，而不是提供有针对性的自动覆盖。
● SCP 定义帐户护栏，无法授予资源访问权限或消除身份策略更新的需要。
工作流：具有匹配标签的 IAM ABAC。
允许 TCP 6379 上的应用程序层安全组的入站流量
确保端口 6379 上的安全组规则正确，允许应用层建立与 Redis 服务端点的连接。 Fargate 任务需要任务 ENI。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：确保端口 6379 上的安全组规则正确，允许应用程序层建立与 的连接。
● 场景匹配：确保端口 6379 上的安全组规则正确，允许应用程序层建立与 的连接。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 虽然很重要，但该错误指向注册表身份验证的网络可访问性，而不是缺少 IAM 权限。
● 添加 Secrets Manager 端点并不能解决错误指示的 ECR 注册表身份验证拉取失败问题。
● 当配置了正确的 VPC 终端节点或 NAT 时，Fargate 任务可以完全在私有子网中运行，无需公共 IP。
工作流：允许从 Redis 子网 CIDR 到 TCP 6379 上的应用程序层安全组的入站流量 → 使用专用 ENI 启用 awsvpc 任务网络并添加 ecr.api VPC 终端节点。
EventBridge CodePipeline 状态更改事件调用 Systems Manager Automation 来启动/停止 EC2 和
与管道生命周期相关的事件驱动的自动化可以可靠地启动和停止 EC2 和 RDS，而无需重新设计。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：与管道生命周期相关的事件驱动的自动化可以可靠地启动和停止 EC2 和 RDS，而无需重新设计。
● 场景匹配：与管道生命周期相关的事件驱动的自动化可以可靠地启动和停止 EC2 和 RDS，而无需重新设计。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 在构建步骤中添加自定义脚本，可能会因失败而错过关闭，并增加操作负担。
● 基于时间的调度存在在没有测试发生和缺少临时管道运行时运行的风险。
● 不必要的架构更改和增加的复杂性不能直接解决事件驱动的需求。
工作流：EventBridge CodePipeline 状态更改事件调用 Systems Manager Automation 来启动/停止 EC2 和 RDS。
一次性部署
同时部署到所有实例，以最快的速度推出并缩短停机时间。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：同时部署到所有实例，以最快的速度推出并缩短停机时间。
● 场景匹配：同时部署到所有实例，以最快的速度推出并缩短停机时间。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 运行重复的环境，增加交换流量之前的成本和时间。
● 分批部署以保留容量，这比一次性部署要慢。
● 创建新的车队以确保安全和回滚，但速度较慢且成本较高。
工作流：一次性部署。
外部 Lambda 扩展，用于发出 X 射线段和子段，启用主动
这提供了针对每个请求分段和子分段的完整分布式跟踪、通过 X-Ray Insights 的异常检测以及使用 EventBridge 和 CloudWatch 的近实时通知。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这提供了带有每个请求段和子段的完整分布式跟踪、通过 X-Ray Insights 的异常检测以及近实时通知。
● 场景匹配：这提供了带有每个请求段和子段的完整分布式跟踪、通过 X-Ray Insights 的异常检测以及近实时通知。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 当 X-Ray 组可以跨功能关联跟踪时，合并功能是不必要的，并且会降低模块化和重用性。
● 与外部扩展相比，内部扩展在进程内运行，不太适合可靠地缓冲和导出遥测数据。
● CloudWatch Logs Insights 分析日志而不是跟踪数据，因此它无法显示跟踪级别的异常和因果关系。
工作流：使用外部 Lambda 扩展发出 X-Ray 分段和子分段 → 启用主动跟踪 → 授予 X-Ray 权限 → 为每个工作流程定义 X-Ray 组 → 启用 X-Ray 洞察和路由。
CloudFront 源访问控制并将 S3 存储桶策略锁定到
OAC 对源请求进行签名，并使用仅允许该分发的存储桶策略来阻止直接 S3 访问。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：OAC 对源请求进行签名，并使用仅允许该分发的存储桶策略来阻止直接 S3 访问。
● 场景匹配：OAC 对源请求进行签名，并使用仅允许该分发的存储桶策略来阻止直接 S3 访问。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 签名 URL 授权 CloudFront 请求，但其本身不会在没有限制性存储桶策略的情况下阻止直接 S3 URL 访问。
● 阻止公共 ACL 和策略，但不能确保 CloudFront 是唯一的读取器或停止经过身份验证的直接 S3 访问。
● 基于引用者的控制对于强制执行仅限 CloudFront 的访问来说并不安全或不可靠，并且可能会被欺骗。
工作流：配置 CloudFront 源访问控制并将 S3 存储桶策略锁定到分配。
激活 DynamoDB Accelerator 并将 CloudFront 放在 S3 源前面
DAX 为 DynamoDB 读取提供内存中、API 兼容的缓存，CloudFront 在边缘位置缓存 S3 内容，以减少延迟和出口成本。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：DAX 为 DynamoDB 读取提供内存中、API 兼容的缓存，CloudFront 在边缘位置缓存 S3 内容，以减少延迟和出口成本。
● 场景匹配：DAX 为 DynamoDB 读取提供内存中、API 兼容的缓存，CloudFront 在边缘位置缓存 S3 内容以减少读取量。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 虽然 Redis 可以放置在 DynamoDB 前面，但它不是原生集成的，对于这种读取密集型模式，通常比 DAX 花费更多的操作工作量。
● API 位于 ALB 而不是 API 网关后面，S3 传输加速可加快上传速度，而不是缓存读取以提高成本和延迟。
● Memcached 不直接集成缓存 S3 对象，因此它不会加速或降低静态 S3 内容交付的成本。
工作流：激活 DynamoDB Accelerator 并将 CloudFront 放在 S3 源前面。
在审核账户中，设置 Amazon Kinesis Data Streams 流
跨账户 CloudWatch Logs 订阅仅支持 Kinesis Data Streams，Lambda 可以将数据集中转换并索引到 OpenSearch 中。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：跨账户 CloudWatch Logs 订阅仅支持 Kinesis Data Streams，并且 Lambda 可以转换和索引数据。
● 场景匹配：跨账户 CloudWatch Logs 订阅仅支持 Kinesis Data Streams，并且 Lambda 可以转换和索引数据。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● CloudWatch Logs 跨账户订阅无法定位 Firehose，因此它不提供受支持的跨账户传送路径。
● CloudWatch Logs 订阅筛选器不支持 SQS 作为目标，因此不支持此集成。
● CloudWatch Logs 跨账户订阅无法直接传送到 Lambda，因此不支持此方法。
工作流：在审核账户中 → 使用 AWS Lambda 使用者设置 Amazon Kinesis Data Streams 流，将记录索引到 Amazon OpenSearch Service 域中，并配置 CloudWatch Logs 订阅。
AWS Config 具有列出允许的 AMI ID 的roved-amis-by id 托管规则，以及
AWS Config 为 AMI 允许列表提供侦探性合规性检查，而不会阻止启动，并且可以将合规性状态更改推送到 SNS。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：AWS Config 为 AMI 允许列表提供侦探性合规性检查，而不会阻止启动，并且可以将合规性状态更改推送到 SNS。
● 场景匹配：AWS Config 为 AMI 允许列表提供侦探性合规性检查，而不会阻止启动，并且可以推送合规性状态更改。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Amazon Inspector 专注于漏洞和暴露评估，而不是根据批准的列表验证实例 AMI ID。
● SCP 和 IAM 策略是预防性控制措施，可阻止发布团队启动违反要求的未经批准的 AMI。
● Trusted Advisor 不提供检查来验证 EC2 实例是否是从特定批准的 AMI 列表启动的。
工作流：使用列出允许的 AMI ID 的roved-amis-id 托管规则配置 AWS Config，并将 AWS Config 合规性更改通知发送到两个团队订阅的 Amazon SNS 主题。
AWS Systems Manager 运行命令进行实例更改而不是 SSH 或
Run Command 可在托管实例上安全地执行命令，而无需分发 SSH 密钥。依赖 CodeBuild 服务角色将静态凭证替换为短期角色凭证。范围。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Run Command 可在托管实例上安全地执行命令，而无需分发 SSH 密钥。
● 场景匹配：Run Command 可在托管实例上安全地执行命令，而无需分发 SSH 密钥。依赖 CodeBuild 服务角色。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 在 S3 中存储凭证（即使是加密的）也会扩大暴露范围，并且不是推荐的构建秘密管理模式。
● Secrets Manager 不使用 SecureString 类型；这是特定于参数存储的。
● 仍然依赖 SSH 和密钥处理，而不是使用 SSM 本机控件。
工作流：使用 AWS Systems Manager Run Command 进行实例更改，而不是使用 S3 存储的密钥进行 SSH 或 scp → 为 CodeBuild IAM 角色授予最低权限，并从构建规范中删除 AWS 密钥 →。
Lambda 目标发布到 CodePipeline Pipeline 的 Slack webhook + EventBridge 规则
使用 Lambda 函数作为 EventBridge 目标来调用 Slack 传入 Webhook。使用管道执行状态更改模式匹配管道级故障事件。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：使用 Lambda 函数作为 EventBridge 目标来调用 Slack 传入 Webhook。
● 场景匹配：使用 Lambda 函数作为 EventBridge 目标来调用 Slack 传入 Webhook。使用管道执行状态更改模式匹配管道级故障事件。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● EventBridge 没有本机 Slack 目标，因此它无法直接传递到 Slack。
● Slack 不会轮询 SQS，因此不会将消息传递到 Slack。
● 捕获单个操作失败，而不是整体管道执行失败。
工作流：Lambda 目标发布到 Slack webhook → CodePipeline 管道执行的 EventBridge 规则失败。
AWS Health EC2 事件到 SNS 的 EventBridge 规则
EventBridge 本身接收 AWS Health 事件，从而实现快速的规则到 SNS 交付模式。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：EventBridge 本身接收 AWS Health 事件，从而实现快速的规则到 SNS 交付模式。
● 场景匹配：EventBridge 本身接收 AWS Health 事件，从而实现快速的规则到 SNS 交付模式。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 可行，但需要部署和配置解决方案，这比创建简单规则要慢。
● 状态检查不会通知 AWS Health 的计划维护或停用。
● 默认情况下，AWS Health 事件不在 CloudWatch Logs 中，从而增加了不必要的设置。
工作流：AWS Health EC2 事件到 SNS 的 EventBridge 规则。
EventBridge 用于运行调用文件共享 RefreshCache API 的 Lambda
调用 RefreshCache 会更新文件网关目录，以便新的 S3 对象出现在 SMB/NFS 共享上。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：调用 RefreshCache 会更新文件网关目录，以便新的 S3 对象出现在 SMB/NFS 共享上。
● 场景匹配：调用 RefreshCache 会更新文件网关目录，以便新的 S3 对象出现在 SMB/NFS 共享上。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● DataSync 会移动数据，但不会刷新文件网关的目录缓存或列表。
● 打开文件时刷新元数据，但不更新新创建对象的目录列表。
● 复制会在存储桶之间复制对象，并且不会触发文件网关缓存刷新。
工作流：使用 EventBridge 运行调用文件共享 RefreshCache API 的 Lambda。
将 buildspec.yml 包含在 Maven 构建、测试和打包命令中 + 创建一个
CodeBuild 使用 buildspec.yml 来运行 Maven 阶段并定义工件。 CodeBuild 与 GitHub 集成以提取源代码并生成工件。 GitHub Webhook 可以在推送事件上自动启动 CodeBuild。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CodeBuild 使用 buildspec.yml 来运行 Maven 阶段并定义工件。
● 场景匹配：CodeBuild 使用 buildspec.yml 来运行 Maven 阶段并定义工件。 CodeBuild 与 GitHub 集成以提取源代码并生成工件。 GitHub Webhook 可以在推送事件上自动启动 CodeBuild。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 没有构建阶段的 CodePipeline 无法编译或测试代码。
● 管理 EC2 上的构建会增加开销，并且不提供本机 CI 触发器。
● CodeDeploy 处理部署，而不是编译或测试源代码。
工作流：将 buildspec.yml 包含在 Maven 构建、测试和打包命令中 → 使用 GitHub 作为源创建 AWS CodeBuild 项目 → 启用 GitHub Webhook 触发器以进行推送。
从 S3 对象更新触发 Lambda 以解析 CSV 并
仅当列表发生更改时才会发生事件驱动的更新，从而在网络层强制实施 IP 允许列表的同时，最大限度地降低成本和运营成本。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：仅当列表发生更改时才会发生事件驱动的更新，从而在网络层强制实施 IP 允许列表的同时，最大限度地降低成本和运营成本。
● 场景匹配：仅当列表发生更改时才会发生事件驱动的更新，从而在网络层强制实施 IP 允许列表的同时，最大限度地降低成本和运营成本。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 功能上可行，但与安全组相比增加了经常性 WAF 成本和额外组件。
● 轮询比仅在文件更改时做出反应成本更高、更复杂。
● Direct Connect 会带来巨大的成本，并且对于简单的公共入口允许列表来说是不必要的。
工作流：从 S3 对象更新触发 Lambda 以解析 CSV 并将 ALB 安全组入口仅同步到列出的代理 IP。
应用程序负载均衡器上的访问日志记录
ALB 访问日志通过 request_processing_time、target_processing_time 和 response_processing_time 字段记录每个请求，以进行精确的延迟分析。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：ALB 访问日志通过 request_processing_time、target_processing_time 和 response_processing_time 字段记录每个请求，以进行精确的延迟分析。
● 场景匹配：ALB 访问日志通过 request_processing_time、target_processing_time 和 response_processing_time 字段记录每个请求，以进行精确的延迟分析。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● CloudWatch 代理从实例收集主机级指标和日志，并且不会公开每个请求的 ALB 延迟详细信息。
● CloudTrail 捕获控制平面 API 调用，而不是流经应用程序负载均衡器的数据平面请求计时。
● CloudWatch 提供聚合的 ALB 指标，并且不包括每个请求的处理故障，除非您发布自定义指标。
工作流：在 Application Load Balancer 上启用访问日志记录。
具有针对 OU 的服务管理权限的 CloudFormation StackSets
与组织集成，自动部署到目标 OU 中的新账户，并在账户离开时删除堆栈实例，非常适合部署 CloudTrail 和 IAM 角色。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：与组织集成，自动部署到目标 OU 中的新账户，并在账户离开时删除堆栈实例，非常适合部署 CloudTrail 和 IAM 角色。
● 场景匹配：与组织集成，自动部署到目标 OU 中的新账户，并在账户离开时删除堆栈实例，非常适合部署 CloudTrail 和 IAM 角色。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 自定义自动化需要复杂的跨帐户权限，并且在帐户离开时不会自行清理。
● 基线帐户，但采用起来比较困难，并且本质上不会推出自定义 IAM 角色，也不会在无需额外工具的情况下清理即将离开的帐户。
● SCP 强制执行权限边界，但无法创建 CloudTrail 跟踪或 IAM 角色。
工作流：具有针对 OU 的服务管理权限的 CloudFormation StackSets。
具有 Fargate 启动类型的 ECS + 基于 IPsec 的站点到站点 VPN
Fargate 消除了容器的服务器和集群管理，从而最大限度地减少了运营开销。站点到站点 VPN 在本地网络和 VPC 之间提供加密的 IPsec 隧道。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Fargate 消除了容器的服务器和集群管理，从而最大限度地减少了运营开销。
● 场景匹配：Fargate 消除了容器的服务器和集群管理，从而最大限度地减少了运营开销。站点到站点 VPN 在本地网络和 VPC 之间提供加密的 IPsec 隧道。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● PrivateLink 在 AWS 内私下公开服务，但不是从本地到 VPC 的通用网络连接。
● Direct Connect 默认情况下不对流量进行加密，因此它本身不满足加密要求。
● 在自我管理的 EC2 节点上运行 EKS 会增加节点生命周期和修补的运营负担。
工作流：具有 Fargate 启动类型的 ECS → 基于 IPsec 的站点到站点 VPN。
在 CodePipeline 中定义自定义操作类型并在本地运行关联的操作
具有本地作业工作人员轮询作业的 CodePipeline 自定义操作是长时间运行的本地任务和返回状态的受支持模式。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：具有本地作业工作人员轮询作业的 CodePipeline 自定义操作是长期运行的受支持模式。
● 场景匹配：具有本地作业工作人员轮询作业的 CodePipeline 自定义操作是长期运行的受支持模式。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Lambda 每次调用时间限制为 15 分钟，不适合 90 分钟的本地扫描。
● 公开服务并使用公共 S3 存储桶是不安全的，并且 CodePipeline 不会轮询 S3 存储桶以获取结果。
● Step Functions 不直接运行本地工具，仍然需要合适的计算运行时，从而导致核心集成挑战尚未解决。
工作流：在 CodePipeline 中定义自定义操作类型并运行关联的本地作业工作线程来轮询 CodePipeline、在源阶段之后执行扫描程序并报告状态。
通过 AWS CodeStar Connections 将代码库链接到 GitHub，使用 AWS CodeBuild
Elastic Beanstalk 上的蓝/绿与外部多可用区 RDS 和 CNAME 交换可实现零停机发布和快速回滚。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Elastic Beanstalk 上的蓝/绿与外部多可用区 RDS 和 CNAME 交换可实现零停机发布和快速回滚。
● 场景匹配：Elastic Beanstalk 上的蓝/绿与外部多可用区 RDS 和 CNAME 交换可实现零停机发布和快速回滚。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Elastic Beanstalk 上的就地更新可以短暂消除部署期间的容量和停机风险。
● 此处使用 ECR 加上 CodeDeploy 与测试自动化不匹配，并且仍然依赖于就地样式更新。
● 为每个环境配置单独的 RDS 实例会使蓝/绿的数据一致性变得复杂，并且不是推荐的解耦数据库模式。
工作流：通过 AWS CodeStar Connections 将代码库链接到 GitHub → 使用 AWS CodeBuild 进行自动化单元和功能测试，建立连接到共享外部 Amazon RDS 的两个 Elastic Beanstalk 环境。
适用于 EC2/本地的 AWS CodeDeploy 蓝/绿，具有 ALB 和 75 分钟终止时间
启动并行队列，支持验证后流量转移，并可以在配置的等待时间后自动终止原始实例。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：启动并行队列，支持验证后流量转移，并可以在配置的等待时间后自动终止原始实例。
● 场景匹配：启动并行队列，支持验证后流量转移，并可以在配置的等待时间后自动终止原始实例。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 缺乏本机编排、运行状况跟踪和定时终止控制的自定义方法。
● 就地更新现有机队，不会创建单独的绿色环境或定时退役。
● 执行就地更改，无需完整的蓝/绿环境或自动终止旧队列。
工作流：适用于 EC2/本地的 AWS CodeDeploy 蓝/绿，具有 ALB 和 75 分钟终止等待。
具有外部 RDS 多可用区的不可变部署
满负荷创建新的 Auto Scaling 组，仅在运行状况检查通过后转移流量，并在部署期间以临时额外成本实现快速回滚。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：满负荷创建新的 Auto Scaling 组，仅在运行状况检查通过后转移流量，并在部署期间以临时额外成本实现快速回滚。
● 场景匹配：满负荷创建新的 Auto Scaling 组，仅在运行状况检查通过后转移流量，并在部署期间以临时额外成本实现快速回滚。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 零停机和回滚是可能的，但运行并行环境并将其保持为备用会增加成本。
● 仍然可以保留部分更新的实例，并将数据库生命周期与环境耦合，这对于生产来说是不鼓励的。
● 替换到位的实例，存在停机风险，并且在出现问题时没有安全的回滚路径。
工作流：具有外部 RDS 多可用区的不可变部署。
DynamoDB Streams Kinesis 适配器与 Kinesis 客户端库可扩展
Kinesis Adapter 能够以最少的操作实现高度可扩展、协调的 DynamoDB Streams 消耗，并与 Flink 良好集成以进行实时分析。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Kinesis Adapter 可通过最少的操作实现 DynamoDB Streams 的高度可扩展、协调的消费，并与 DynamoDB 流良好集成。
● 场景匹配：Kinesis Adapter 可通过最少的操作实现 DynamoDB Streams 的高度可扩展、协调的消费，并与 DynamoDB 流良好集成。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 索引和容量更改转向同步查询，并不能解决流消费者节流问题，同时会增加成本和运营负担。
● 运行 ECS 和 Glue 会增加复杂性和成本，而且 Glue 不是 DynamoDB Streams 的本机使用者。
● 调整 Lambda 和表容量不会消除共享分片限制，这些限制会在多个使用者读取同一流时导致限制。
工作流：将 DynamoDB Streams Kinesis 适配器与 Kinesis 客户端库结合使用，跨分片扩展消耗，并将复杂聚合卸载到 Amazon Managed Service for Apache Flink Studio。
适用于 Redis 的 Amazon MemoryDB
这是一个兼容Redis的、持久的内存数据库，支持多AZ持久化、强一致性、大规模集群。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这是一个兼容Redis的、持久的内存数据库，支持多AZ持久化、强一致性、大规模集群。
● 场景匹配：这是一个兼容Redis的、持久的内存数据库，支持多AZ持久化、强一致性、大规模集群。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 是一种高性能缓存，旨在提高速度和读取扩展，但它并不旨在用作持久的多可用区主数据库。
● 是指标和日志的可视化和仪表板服务，而不是数据库或数据存储。
● 是内存缓存，没有持久性或复制功能，因此不适合持久存储需求。
工作流：适用于 Redis 的 Amazon MemoryDB。
回滚重新应用最后一次成功的修订并清除不在其中的文件
回滚恢复之前的修订版本并删除未跟踪的文件； RETAIN 在部署期间保留现有文件。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：回滚恢复之前的修订版本并删除未跟踪的文件； RETAIN 在部署期间保留现有文件。
● 场景匹配：回滚恢复之前的修订版本并删除未跟踪的文件； RETAIN 在部署期间保留现有文件。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 蓝色/绿色替换实例，并且不保留旧队列上的手动状态。
● 默认情况下，CodeDeploy 不保留任意文件，并且 OVERWRITE 不保护非修订文件。
● 自动回滚控制何时发生回滚，而不是如何保留或删除文件。
工作流：回滚重新应用上次成功的修订并清除不在其中的文件 → 将 fileExistsBehavior 设置为 RETAIN。
亚马逊 GuardDuty
托管威胁检测，可分析 CloudTrail、VPC 流日志和 DNS 日志以识别可疑活动。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：托管威胁检测，可分析 CloudTrail、VPC 流日志和 DNS 日志以识别可疑活动。
● 场景匹配：托管威胁检测，可分析 CloudTrail、VPC 流日志和 DNS 日志以识别可疑活动。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 进行脆弱性和暴露评估；无法从 CloudTrail/VPC/DNS 进行持续威胁检测。
● 专注于 S3 的敏感数据发现和保护，而不是威胁检测。
● 支持安全调查结果的调查；不执行初始连续检测。
工作流：亚马逊 GuardDuty。
使用 Amazon Athena S3 服务器访问日志记录和分析日志
S3 访问日志记录每个请求的对象详细信息，Athena 无服务器且廉价地查询它们以实现快速排名。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：S3 访问日志记录每个请求的对象详细信息，Athena 无服务器且廉价地查询它们以实现快速排名。
● 场景匹配：S3 访问日志记录每个请求的对象详细信息，Athena 无服务器且廉价地查询它们以实现快速排名。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 提供存储桶或前缀级别的聚合指标并定期更新，这对于每个对象的即时排名来说并不理想。
● 提供对象级 API 日志记录，但规模化成本高昂，因此在进行大容量分析时，其经济性低于访问日志。
● 需要配置并支付 Redshift 集群费用，这对于临时的每个对象访问分析来说太过分了。
工作流：打开 S3 服务器访问日志记录并使用 Amazon Athena 分析日志。
AppSpec 文件中的 BeforeAllowTraffic 挂钩用于检查并等待
BeforeAllowTraffic 是 Lambda 预流量挂钩，可以阻止转移，直到架构和数据更改完全传播。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：BeforeAllowTraffic 是 Lambda 预流量挂钩，可以阻止转移，直到架构和数据更改完全传播。
● 场景匹配：BeforeAllowTraffic 是 Lambda 预流量挂钩，可以阻止转移，直到架构和数据更改完全传播。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 对于 Lambda，AfterAllowTestTraffic 不是受支持的生命周期事件，并且不会在轮班之前控制生产流量。
● AfterAllowTraffic 仅在流量已转移后运行，因此它无法阻止临时错误窗口。
● BeforeInstall 不是 CodeDeploy 中 Lambda 部署的生命周期挂钩，并且不会在此部署类型中执行。
工作流：在 AppSpec 文件中添加 BeforeAllowTraffic 挂钩，用于在将流量转移到新的 Lambda 版本之前检查并等待所需的数据库更新。
CloudTrail 并通过以下方式为 AWS API 调用创建 Amazon EventBridge 规则
EventBridge可以匹配CloudTrail管理事件（例如DeleteTable），并以最低的成本和近乎实时的交付直接将其路由到SNS。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：EventBridge可以匹配CloudTrail管理事件（例如DeleteTable），并以最小的成本将它们直接路由到SNS。
● 场景匹配：EventBridge可以匹配CloudTrail管理事件（例如DeleteTable），并以最小的成本将它们直接路由到SNS。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 将 CloudTrail 引入 CloudWatch Logs 并使用指标进行过滤会增加持续的日志引入和 Lambda 成本，从而使其成为可能。
● DynamoDB Streams 捕获项目级突变，而不是像 DeleteTable 这样的表级管理调用，因此永远不会检测到表删除。
● AWS Config 专注于配置状态，需要自定义规则，可能存在评估滞后和额外成本。
工作流：启用 CloudTrail 并通过 CloudTrail 为 AWS API 调用创建 Amazon EventBridge 规则，该规则与 dynamodb DeleteTable 匹配并定位 SNS 主题。
用于所有账户中 EBS 卷加密的 AWS Config 托管规则
这使用了跨账户和跨区域聚合的本机配置合规性，最大限度地减少了自定义代码和持续操作，同时提供实时检测和集中报告。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这使用了跨账户和跨区域聚合的本机配置合规性，在提供的同时最大限度地减少了自定义代码和正在进行的操作。
● 场景匹配：这使用了跨账户和跨区域聚合的本机配置合规性，在提供的同时最大限度地减少了自定义代码和正在进行的操作。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 依赖于自定义日志解析和事件关联，这会增加运营开销，并且全面合规性的可靠性较低。
● 需要 SSM 代理、自定义合规性项目以及未针对组织中的 EBS 加密检查进行优化的其他设置。
● 虽然可行，但与使用组织范围的配置聚合器相比，为所有账户和区域维护 StackSet 会增加管理开销。
工作流：为所有账户中的 EBS 卷加密创建 AWS Config 托管规则，并使用 AWS Config 组织聚合器聚合结果，将结果导出到 Amazon S3 并通过 Amazon 发送通知。
Trusted Advisor 使用 EventBridge 到 Lambda 的利用率较低，从而启动了 SSM Automation
Trusted Advisor 向 EventBridge 发出检查项更改事件，从而通过审批门启用对 SSM 自动化 Runbook 的轻量级触发器。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Trusted Advisor 向 EventBridge 发出检查项更改事件，从而通过审批门启用对 SSM 自动化 Runbook 的轻量级触发器。
● 场景匹配：Trusted Advisor 向 EventBridge 发出检查项更改事件，从而通过审批门启用对 SSM 自动化 Runbook 的轻量级触发器。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 构建自定义轮询和状态管理，这比使用托管事件更费力。
● Trusted Advisor 不会将每次检查通知发布到 SNS 以实现直接自动化。
● Compute Optimizer 提供建议，但不会为自动终止工作流发出可操作事件。
工作流：Trusted Advisor 与 EventBridge 到 Lambda 的利用率较低，这会启动 SSM 自动化并手动批准终止。
将数据库凭证保存在由 AWS KMS 加密的 AWS Secrets Manager 中，允许
Secrets Manager 专为具有本机轮换的密钥生命周期而设计，并直接与 ECS 集成，以将密钥作为环境变量注入。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Secrets Manager 专为具有本机轮换的密钥生命周期而设计，并直接与 ECS 集成以注入密钥。
● 场景匹配：Secrets Manager 专为具有本机轮换的密钥生命周期而设计，并直接与 ECS 集成以注入密钥。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 确保检索安全，但 Parameter Store 不是专用的机密服务，并且缺乏内置轮换，因此您必须构建。
● AppConfig 的目标是应用程序配置而不是机密，并且不为数据库凭据提供本机机密轮换。
● Docker Secrets 与 Docker Swarm 绑定，不是受支持或集成的秘密传递机制。
工作流：将数据库凭证保存在由 AWS KMS 加密的 AWS Secrets Manager 中 → 允许 ECS 任务执行角色读取它们，并通过任务定义机密映射将它们注入到容器中。
具有源 aws.health 和事件代码 AWS_RISK_CREDENTIALS_EXPOSED 的 Amazon EventBridge 规则
AWS Health 发出 AWS_RISK_CREDENTIALS_EXPOSED 事件，EventBridge 可以使用源 aws.health 来匹配这些事件，并且 Step Functions 可以编排密钥删除、调查和通知。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：AWS Health 会发出 AWS_RISK_CREDENTIALS_EXPOSED 事件，EventBridge 可以使用源 aws.health 来匹配这些事件，而 Step Functions 也可以。
● 场景匹配：AWS Health 会发出 AWS_RISK_CREDENTIALS_EXPOSED 事件，EventBridge 可以使用源 aws.health 来匹配这些事件，而 Step Functions 也可以。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● AWS Config 不会评估或显示 AWS Health 事件，例如 AWS_RISK_CREDENTIALS_EXPOSED，因此它无法检测泄漏的访问。
● GuardDuty 和 Macie 不会监控公开的 AWS 访问密钥托管的公共代码，因此它们不会发出。
工作流：使用源 aws.health 和事件代码 AWS_RISK_CREDENTIALS_EXPOSED 创建 Amazon EventBridge 规则，以启动运行三个 Lambda 函数的 AWS Step Functions 状态机，以删除公开的访问密钥、收集。
两个 CloudFormation StackSet，一个用于启用 CloudTrail，另一个用于启用 AWS
这会在每个账户和区域中一致地应用 CloudTrail 和 AWS Config，通过聚合器集中合规性，并使用 EventBridge 自动发出警报。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这会在每个账户和区域中一致地应用 CloudTrail 和 AWS Config，并通过聚合器集中合规性。
● 场景匹配：这会在每个账户和区域中一致地应用 CloudTrail 和 AWS Config，并通过聚合器集中合规性。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 引入了可能不需要的新治理框架，并且不能直接确保立即执行多区域 CloudTrail。
● 仅在单个账户中启用 AWS Config 会错过每个账户的资源评估，并且不能保证跨账户的合规性检查。
● Amazon SQS 提供队列而不是主题，因此这种设计滥用了服务并且不是正确的事件处理。
工作流：创建两个 CloudFormation StackSet，一个用于启用 CloudTrail，另一个用于启用 AWS Config，并使用检查 CloudTrail 的规则、定位所有账户和所有区域 → 设置 AWS。
在 Web 服务中实现一个就绪端点，用于验证与
自定义就绪端点允许 ALB 仅当端到端依赖项可访问时才将 Web 任务标记为正常。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：自定义就绪端点允许 ALB 仅当端到端依赖项可访问时才将 Web 任务标记为正常。
● 场景匹配：自定义就绪端点允许 ALB 仅当端到端依赖项可访问时才将 Web 任务标记为正常。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Route 53 检查和 Application Auto Scaling 不会验证跨层连接，并且无法终止或替换 RDS 实例。
● RDS 实例无法注册为 ALB 目标，并且 TCP 检查不会验证应用程序级依赖关系。
● ALB 无法使用 CloudWatch 警报状态来设置目标运行状况，并且这些指标无法确认依赖项的可达性。
工作流：在 Web 服务中实现就绪端点，用于验证与后端 ECS 服务和 RDS 数据库的连接，并将目标组运行状况检查设置为该路径。
AWS CodeDeploy 具有 Auto Scaling、OneAtATime、CloudWatch CPU 警报为 95%、自动
CodeDeploy 支持一次性部署，并与 CloudWatch 警报集成，以在指标违规时触发自动回滚。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CodeDeploy 支持一次性部署，并与 CloudWatch 警报集成，以在指标违规时触发自动回滚。
● 场景匹配：CodeDeploy 支持一次性部署，并与 CloudWatch 警报集成，以在指标违规时触发自动回滚。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Elastic Beanstalk 可以执行滚动更新并使用运行状况检查，但它本身不会基于单个实例的 CPU CloudWatch 警报进行回滚。
● 实例刷新可以逐渐进行，但不支持由 CloudWatch CPU 警报直接驱动的自动回滚。
● 方法很复杂，并且缺乏针对每个实例部署的本机、基于指标的自动回滚。
工作流：AWS CodeDeploy 具有 Auto Scaling、OneAtATime、95% 的 CloudWatch CPU 警报、自动回滚。
使用 aws:elbv2:listener:default 重定向的 option_settings 提交 .ebextensions/alb.config
将重定向规则放置在 .ebextensions option_settings 中，让 Beanstalk 在管道驱动的部署期间应用 ALB 侦听器配置。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：将重定向规则放置在 .ebextensions option_settings 中，让 Beanstalk 在管道驱动的部署期间应用 ALB 侦听器配置。
● 场景匹配：将重定向规则放置在 .ebextensions option_settings 中，让 Beanstalk 在管道驱动的部署期间应用 ALB 侦听器配置。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Elastic Beanstalk 管理 ALB；带外 CloudFormation 更改很脆弱，可能会被 Beanstalk 更新覆盖。
● 需要直接环境权限并绕过管道，不满足约束。
● 命令式实例脚本会产生偏差，并且不是管理 Beanstalk ALB 侦听器规则的推荐或可靠方法。
工作流：使用 aws:elbv2:listener:default 重定向的 option_settings 提交 .ebextensions/alb.config。
VPC 端点：ECR API、ECR DKR 和 S3 + 修复任务
ECR 身份验证和图像层需要 ECR API 和 DKR 接口端点以及用于私有拉取的 S3 网关端点。执行角色必须允许所需的 ECR（以及机密/KMS，如果使用）操作来获取令牌和拉取映像。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：ECR 身份验证和图像层需要 ECR API 和 DKR 接口端点以及用于私有拉取的 S3 网关端点。
● 场景匹配：ECR 身份验证和图像层需要 ECR API 和 DKR 接口端点以及 S3 网关端点。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 公共 IP 恢复互联网出口，但违反私有/无 NAT 约束，并且如果使用 VPC 终端节点则不需要。
● 仅有秘密访问是不够的；如果没有 ECR 和 S3 端点，注册表身份验证和层下载仍然会失败。
● Fargate 默认情况下已使用 awsvpc；这不解决注册表/身份验证连接问题。
工作流：创建 VPC 终端节点：ECR API、ECR DKR 和 S3 → 修复 ECR 和 Secrets Manager 的任务执行 IAM 角色权限。
定义基于 AWS WAF 速率和 IP 集的规则以阻止滥用模式
将 AWS WAF 规则与严格的 NACL 分层有助于尽早阻止恶意请求并减少网络边缘不必要的暴露。 Shield Advanced 与 CloudFront 提供增强功能。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：将 AWS WAF 规则与严格的 NACL 分层有助于尽早阻止恶意请求并减少不必要的暴露。
● 场景匹配：将 AWS WAF 规则与严格的 NACL 分层有助于尽早阻止恶意请求并减少不必要的暴露。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 专注于实例管理和容量扩展，吸收流量而不是缩小或提供 DDoS 攻击面。
● 这些行动可以改善治理和恢复能力，但不会直接减轻或减少 DDoS 攻击的范围。
工作流：定义基于 AWS WAF 速率和 IP 集的规则，以阻止滥用模式和已知的不良来源，并将 VPC 网络 ACL 限制为仅所需的端口和 CIDR → 启用 AWS Shield Advanced。
标准队列上的重新驱动策略，用于将失败的消息路由到
重新驱动策略将重复失败的消息发送到死信队列，您可以在其中检查有效负载并进行调试。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：重新驱动策略将重复失败的消息发送到死信队列，您可以在其中检查有效负载并进行调试。
● 场景匹配：重新驱动策略将重复失败的消息发送到死信队列，您可以在其中检查有效负载并进行调试。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 长轮询可减少空接收和 API 成本，但不会隔离失败的消息以进行检查。
● FIFO 排序不能解决处理失败问题，切换队列类型无助于分析不良负载。
● 传递延迟只会推迟初始消息可见性，无助于捕获失败的消息以进行分析。
工作流：在标准队列上配置重新驱动策略，以将失败的消息路由到死信队列。
CloudTrail UpdateStage 上的 EventBridge 规则； Lambda 使用 GetSdk 到 S3
UpdateStage 捕获阶段更改，包括回滚； Lambda 可以调用 GetSdk 并将工件发布到 S3。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：UpdateStage 捕获阶段更改，包括回滚； Lambda 可以调用 GetSdk 并将工件发布到 S3。
● 场景匹配：UpdateStage 捕获阶段更改，包括回滚； Lambda 可以调用 GetSdk 并将工件发布到 S3。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 仅在管道执行期间运行，可能会错过手动或带外阶段回滚。
● 对于重用先前部署的回滚，不会发出 CreateDeployment，因此 SDK 不会更新。
● 存储库推送不能可靠地反映 API Gateway 中的阶段回滚或直接阶段更新。
工作流：CloudTrail UpdateStage 上的 EventBridge 规则 → Lambda 使用 GetSdk 到 S3。
带有 EventBridge 计划的 AWS Step Functions 从每个 AMI 启动
协调每个 AMI 的临时实例，确保 Inspector 准备就绪，按标签确定范围，并使用 EventBridge 进行定期计划。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：协调每个 AMI 的临时实例，确保 Inspector 准备就绪，按标签确定范围，并使用 EventBridge 进行定期计划。
● 场景匹配：协调每个 AMI 的临时实例，确保 Inspector 准备就绪，按标签确定范围，并使用 EventBridge 进行定期计划。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 使用 CloudWatch Alarms 而不是 EventBridge 计划，并忽略确保 Inspector 已启用或代理存在。
● Image Builder 可以运行图像测试，但不执行 Amazon Inspector CVE 评估。
● 缺乏基于标签的范围界定，并且不使用预定的 EventBridge 规则来实现可靠的节奏。
工作流：AWS Step Functions 具有 EventBridge 计划从每个 AMI 启动，确保通过 SSM 启用 Inspector、标记并运行标记范围的评估。
调用 AWS Lambda 函数来调用的 Amazon EventBridge 计划
计划 RefreshCache 会更新文件网关的缓存目录列表，以便新添加的 S3 对象通过 SMB 或 NFS 共享可见。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：计划 RefreshCache 会更新文件网关的缓存目录列表，以便新添加的 S3 对象通过 SMB 或 NFS 共享可见。
● 场景匹配：计划 RefreshCache 会更新文件网关的缓存目录列表，以便新添加的 S3 对象可以通过.
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● S3 复制仅在 S3 存储桶之间移动对象，不会更新或通知文件网关刷新其目录缓存。
● DataSync 执行批量传输，但不会刷新文件网关的列表，并为简单的缓存可见性增加了不必要的复杂性。
● Volume Gateway 提供块存储，而不是文件共享，并且 S3 事件通知无法直接指示 Storage Gateway 刷新文件共享列表。
工作流：创建一个 Amazon EventBridge 计划，该计划调用 AWS Lambda 函数来调用文件共享的 RefreshCache。
AWS CloudFormation StackSets 具有来自管理账户的服务托管权限以进行部署
与组织集成的 StackSet 可以自动配置并可选择删除每个帐户的资源，并且只需最少的持续管理。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：与组织集成的 StackSet 可以自动配置并可选择删除每个帐户的资源，并且只需最少的持续管理。
● 场景匹配：与组织集成的 StackSet 可以自动配置并可选择删除每个帐户的资源，并且只需最少的持续管理。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 可以为新账户建立基线，但在现有组织中采用起来比较困难，并且本身不处理自定义 IAM。
● 引入具有复杂跨帐户权限的自定义粘合代码，并且在删除帐户时缺乏本机自动清理功能。
● 组织跟踪集中日志记录，但在所有账户之间共享 IAM 角色不是自动的，但仍然需要。
工作流：使用 AWS CloudFormation StackSets 和管理账户的服务托管权限来部署 CloudTrail 跟踪和所需的 IAM 角色来定位 OU，从而实现自动部署到新账户以及在账户关闭或离开时自动删除堆栈实例。
蓝绿，快照和删除保护，新EB使用现有RDS，删除
将数据库与 EB 生命周期解耦、保护数据并在终止前清除安全组引用。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：将数据库与 EB 生命周期解耦、保护数据并在终止前清除安全组引用。
● 场景匹配：将数据库与 EB 生命周期解耦、保护数据并在终止前清除安全组引用。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 跳过安全组清理可能会留下依赖关系，并存在意外删除或阻止拆卸的风险。
● 仍然将DB和EB耦合起来，增加不必要的迁移步骤，而不是直接解耦。
● Elastic Beanstalk 不提供本机 Canary，这会忽略 EB 和 RDS 之间的 SG 依赖关系。
工作流：蓝绿，快照和删除保护，新EB使用现有RDS→从DB SG中删除旧的env SG，→终止。
CloudWatch Logs 目标与 Kinesis Data Firehose 传送到 S3
使用订阅到写入 S3 的中央账户中的 Kinesis Data Firehose 的跨账户 CloudWatch Logs 目标，从而最大程度地减少配置和扩展需求。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：使用订阅到写入 S3 的中央账户中的 Kinesis Data Firehose 的跨账户 CloudWatch Logs 目标，从而最大程度地减少配置和扩展需求。
● 场景匹配：使用订阅到写入 S3 的中央账户中的 Kinesis Data Firehose 的跨账户 CloudWatch Logs 目标，从而最大程度地减少配置和扩展需求。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 添加 Kinesis Data Streams 分片配置和扩展，从而增加运营开销。
● 批量导出是按日志组进行的，需要计划和维护，并且不能接近实时，也不能轻松地跨多个帐户进行扩展。
● 需要管理 OpenSearch 容量和索引，对于长期归档来说不是最低要求。
工作流：CloudWatch Logs 目标通过 Kinesis Data Firehose 传送到 S3。
每天调用 AWS Lambda 函数的 Amazon EventBridge 计划规则
使用 Lambda 的预定 EventBridge 规则可以通过标签跟踪首次出现的日期，并在分离 21 天后可靠地强制删除。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：使用 Lambda 的预定 EventBridge 规则可以通过标签跟踪首次出现的日期，并可靠地强制执行 21 点之后的删除。
● 场景匹配：使用 Lambda 的计划 EventBridge 规则可以通过标签跟踪首次出现的日期，并可靠地强制执行 21 点之后的删除。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Trusted Advisor 可以突出显示未充分利用或未连接的卷，但它不提供 21 天的分离年龄信号或本机信号。
● Config 会标记配置状态，但不会编排每个资源的 21 天计时器，从而导致每个卷的单独延迟规则效率低下。
● DLM 管理快照和 AMI 生命周期，而不是根据分离期限删除孤立的 EBS 卷。
工作流：创建一个 Amazon EventBridge 计划规则，每天调用 AWS Lambda 函数，用当前日期标记新发现的分离卷，并删除标签显示的任何分离卷。
EventBridge 计划触发 Step Functions 从
按计划从 AMI 启动临时实例，允许 Inspector 评估其 CVE，然后终止以最大程度地降低成本和影响。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：按计划从 AMI 启动临时实例，允许 Inspector 评估其 CVE，然后终止以最大程度地降低成本和影响。
● 场景匹配：按计划从 AMI 启动临时实例，允许 Inspector 评估它的 CVE，以及。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 补丁管理器评估实例补丁合规性，而不是 AMI 工件，并且重复扫描整个队列成本高昂且不必要。
● Amazon Inspector 无法通过 ID 扫描 AMI；它评估正在运行的 EC2 实例或容器映像。
● 短节奏重建工作量很大，并且不能直接验证新发布的 CVE 的现有黄金 AMI。
工作流：EventBridge 计划触发 Step Functions 从 AMI 启动短暂的 EC2，让 Amazon Inspector 扫描它，→ 终止。
Amazon GuardDuty 组织范围内具有委派管理员；通过 EventBridge 将发现结果路由至
GuardDuty 通过委派管理员支持 AWS Organizations 进行集中检测，EventBridge 可以通过 Firehose 将检测结果传送到 S3。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：GuardDuty 通过委派管理员支持 AWS Organizations 进行集中检测，EventBridge 可以通过 Firehose 将检测结果传送到 S3。
● 场景匹配：GuardDuty 通过委派管理员支持 AWS Organizations 进行集中检测，EventBridge 可以通过 Firehose 将检测结果传送到 S3。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Security Hub 聚合来自其他服务的发现，但本身并不检测 SSH 暴力或恶意软件等威胁。
● 仅在管理员帐户中运行 GuardDuty 不会生成成员帐户的结果，并且会增加不必要的管道复杂性。
● Inspector 专注于漏洞和软件库存评估，而不是检测 SSH 暴力等网络或帐户威胁。
工作流：通过委派管理员在组织范围内启用 Amazon GuardDuty → 通过 EventBridge 将结果路由到 Kinesis Data Firehose 到 S3。
AppSpec 生命周期挂钩（例如 BeforeAllowTraffic）的 Lambda 验证函数可以运行
流量前 AppSpec 挂钩允许测试流量验证，并且可以在检查失败时使部署失败以触发回滚。部署组警报可能会导致部署失败、发送 SNS 通知。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：流量前 AppSpec 挂钩允许测试流量验证，并且可以在检查失败时使部署失败以触发回滚。
● 场景匹配：流量前 AppSpec 挂钩允许测试流量验证，并且可以在检查失败时使部署失败以触发回滚。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● CloudWatch Alarms 不接受直接来自 Lambda 的任意通过或失败负载，因此这无法可靠地驱动回滚。
● 仅在流量变化后进行验证可能会影响用户，并且不符合上线前测试的要求。
工作流：将 Lambda 验证函数附加到 AppSpec 生命周期挂钩（例如 BeforeAllowTraffic），以针对测试流量运行并在失败时回滚 → 将 CloudWatch 警报与 CodeDeploy 部署组关联并发出通知。
将批准的架构打包为 AWS CloudFormation 模板并将其作为产品发布
服务目录允许用户仅提供带有强制参数和标签的经过审查的产品，从而提供预防性治理。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：服务目录允许用户仅提供带有强制参数和标签的经过审查的产品，从而提供预防性治理。
● 场景匹配：服务目录允许用户仅提供带有强制参数和标签的经过审查的产品，从而提供预防性治理。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 创建后提供检测控制，并且不会阻止启动不合规资源。
● IAM 策略不支持审批工作流，SNS 无法强制执行预先创建的审批门。
● 直接 CloudFormation 访问无法可靠地限制创建哪些模板或资源，从而削弱了合规性执行。
工作流：将批准的架构打包为 AWS CloudFormation 模板，并将其作为具有所需标签的 AWS Service Catalog 中的产品发布，→ 允许初学者仅启动 Service Catalog 产品并拒绝对其他服务的写入访问。
具有用于合并的开发分支的单个 GitHub 或 GitLab 存储库
单存储库分支策略加上提交时的 CodeBuild 和 CodeDeploy 蓝/绿可提供近乎零的停机时间，并通过在环境之间转移流量来实现快速、安全的回滚。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：单存储库分支策略加上提交时的 CodeBuild 和 CodeDeploy 蓝/绿可提供接近零的停机时间，并实现快速、安全。
● 场景匹配：单存储库分支策略加上提交时的 CodeBuild 和 CodeDeploy 蓝/绿可提供接近零的停机时间，并实现快速、安全。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 与单个共享相比，每个开发人员使用多个存储库会增加不必要的协调和复杂性，而不会改善回滚或正常运行时间。
● Amazon ECR 是一个容器映像注册表，不适合托管应用程序源代码。
工作流：使用单个 GitHub 或 GitLab 存储库与开发分支进行合并 → 在每次提交到该分支时触发 AWS CodeBuild，将请求拉入主分支，然后部署到生产环境。
使用 Lambda@Edge 将函数与 CloudFront 分配关联
Lambda@Edge 在 CloudFront 边缘位置针对查看器和源事件运行您的代码，从而实现基于用户代理的选择，并具有全局低延迟。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Lambda@Edge 在 CloudFront 边缘位置针对查看器和源事件运行您的代码，从而实现基于用户代理的选择，并具有全局低延迟。
● 场景匹配：Lambda@Edge 在 CloudFront 边缘位置针对查看器和源事件运行您的代码，从而实现基于用户代理的选择。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 边缘优化的 API 通过 CloudFront 路由到区域终端节点，并且不会在边缘执行代码，因此 CDN 层的延迟和每个请求的自定义都受到限制。
● CloudFront Functions 专为轻量级标头或 URL 重写而设计，无法运行现有 Lambda 代码或执行动态图像选择通常需要的较繁重的逻辑。
● CloudFront 需要 HTTP 源，例如 S3、应用程序负载均衡器或自定义服务器，而 Lambda 不是有效的源类型。
工作流：使用 Lambda@Edge 将函数与 CloudFront 分配相关联。
Route 53 地理邻近路由偏向跨四个区域的 ALB
按邻近程度进行路由，并支持偏差，以将更多或更少的流量转移到选定的区域，以满足不均匀的需求。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：按邻近程度进行路由，并支持偏差，以将更多或更少的流量转移到选定的区域，以满足不均匀的需求。
● 场景匹配：按邻近程度进行路由，并支持偏差，以将更多或更少的流量转移到选定的区域，以满足不均匀的需求。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 提供最低延迟的路由，但缺乏对流量偏向或远离区域的控制。
● 按用户位置进行路由，但不提供跨区域流量整形的偏差控制。
● 返回简单负载和运行状况的多个记录，但不提供区域偏差或每用户延迟优化。
工作流：Route 53 地理位置邻近路由偏向跨四个区域的 ALB。
在调用验证 Lambda 的 AppSpec 中定义 BeforeAllowTraffic 挂钩
BeforeAllowTraffic 在流量转移之前运行，旨在阻止转移，直到验证 Lambda 发出就绪信号。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：BeforeAllowTraffic 在流量转移之前运行，旨在阻止转移，直到验证 Lambda 发出就绪信号。
● 场景匹配：BeforeAllowTraffic 在流量转移之前运行，旨在阻止转移，直到验证 Lambda 发出就绪信号。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● AfterAllowTraffic 仅在流量已转移后运行，因此它无法控制流量前的准备情况。
● CloudWatch 警报可以在轮班期间或轮班后触发回滚，但不会为 Lambda 部署提供流量前准备就绪门。
● ValidateService 不是 Lambda 计算平台挂钩，也不充当 Lambda 部署的预流量门。
工作流：在 AppSpec 中定义一个 BeforeAllowTraffic 挂钩，该挂钩调用验证 Lambda，仅当 live-v2 API Gateway 阶段响应请求时，该验证 Lambda 才会返回 Succeeded。
Amazon CloudFront 源故障转移，具有主要和次要源
CloudFront 源故障转移可以在特定 5xx 响应（例如 504）上自动切换到辅助源，以低成本提高可用性。 Lambda@Edge 的执行接近。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudFront 源故障转移可以在特定 5xx 响应（例如 504）上自动切换到辅助源，从而改进。
● 场景匹配：CloudFront 源故障转移可以在特定 5xx 响应（例如 504）上自动切换到辅助源，从而改进。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 虽然这可以减少延迟，但跨区域操作和同步的成本昂贵且复杂。
● 较长的 TTL 有助于静态内容，但不会加速动态登录流程或防止 504 错误。
● Global Accelerator 可以减少网络路径延迟，但会增加成本，并且无法解决源 504 或繁重的身份验证处理问题。
工作流：使用登录终端节点的主源和辅助源配置 Amazon CloudFront 源故障转移 → 将身份验证逻辑移至 Lambda@Edge，以便它在距离查看器最近的边缘位置运行。
针对 EC2 CreateSnapshot 的 EventBridge 计划
直接在固定时间为特定卷 ID 安排 EC2 CreateSnapshot API，无需额外代码或服务。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：直接在固定时间为特定卷 ID 安排 EC2 CreateSnapshot API，无需额外代码或服务。
● 场景匹配：直接在固定时间为特定卷 ID 安排 EC2 CreateSnapshot API，无需额外代码或服务。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 通过策略（通常基于标签）自动执行 EBS 快照计划和保留，这比单个计划的 API 调用增加了更多设置。
● 提供带有计划和保管库的集中备份，但配置比单个计划规则更繁重。
● 添加额外的 Systems Manager 步骤和对 SSM 代理的依赖关系，这对于直接快照调用是不必要的。
工作流：针对 EC2 CreateSnapshot 的 EventBridge 计划。
读取器并切换到集群写入器和读取器端点
添加读取器可实现故障转移，并使用集群写入器和读取器端点允许写入进行故障转移并以最小的中断继续读取。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：添加读取器可实现故障转移，并使用集群写入器和读取器端点允许写入进行故障转移并以最小的中断继续读取。
● 场景匹配：添加读取器可实现故障转移，使用集群写入器和读取器端点可实现写入故障转移。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● RDS Proxy 会池化连接，但无法防止在维护期间重新启动单个写入器实例时断开连接。
● Serverless v2 有助于扩展，但不能消除维护期间的引擎重启或自行提供读/写拆分。
● 自定义端点用于对实例进行分组，对于基本的读/写分割是不必要的，这是由默认集群和读取器端点处理的。
工作流：添加读取器并切换到集群写入器和读取器端点。
将当前 AMI ID 写入 SSM Parameter Store 并引用
将 AMI ID 存储在 Parameter Store 中并使用动态参考解析它可以解耦团队，并确保堆栈在部署时获取最新批准的映像。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：将 AMI ID 存储在 Parameter Store 中并使用动态参考解析它可以解耦团队，并确保堆栈在部署时获取最新批准的映像。
● 场景匹配：将 AMI ID 存储在 Parameter Store 中并使用动态引用解析它可以解耦团队并确保。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 如果没有自定义资源或外部逻辑，CloudFormation 无法通过标签本地解析 AMI，这使得这种情况变得脆弱。
● 使用 S3 工件和跨堆栈导出会增加操作开销，并且缺乏一流的安全参数检索机制。
● 如果没有更新，服务目录和启动模板不会自动解析 CloudFormation 的最新 AMI，这会增加耦合性。
工作流：将当前 AMI ID 写入 SSM Parameter Store 并通过 CloudFormation SSM 动态引用引用它。
部署后 CodePipeline 阶段，触发 Lambda 导出 SDK
在部署完成时自动执行导出和缓存刷新，确保客户获得最新的 SDK。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：在部署完成时自动执行导出和缓存刷新，确保客户获得最新的 SDK。
● 场景匹配：在部署完成时自动执行导出和缓存刷新，确保客户获得最新的 SDK。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 与部署相关，但不会使 CloudFront 失效，因此客户端可能会收到缓存的 SDK，但不会立即收到最新的 SDK。
● 短 TTL 可以减少陈旧性，但不能保证部署后立即保持新鲜度并增加原始负载。
● S3没有缓存失效API；必须使用 CloudFront 失效来刷新内容。
工作流：添加部署后 CodePipeline 阶段，该阶段触发 Lambda 从 API Gateway 导出 SDK、上传到 S3 并创建 CloudFront 失效。
在所有 EC2 和本地服务器上安装 AWS Systems Manager 代理
补丁管理器提供具有基线、组和维护窗口的集中式混合补丁，以大规模自动化一致的操作系统和应用程序更新。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：补丁管理器提供具有基线、组和维护窗口的集中式混合补丁，以大规模自动化一致的操作系统和应用程序更新。
● 场景匹配：补丁管理器提供具有基线、组和维护窗口的集中式混合补丁，以大规模自动化一致的操作系统和应用程序更新。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 该方法是手动的，依赖于存储的凭据，缺乏托管补丁基准、计划和内置合规性报告。
● Inspector 会发现漏洞并确定发现的优先级，但不执行操作系统补丁编排或维护窗口调度。
● 自定义脚本增加了运营负担，容易出错，并且缺乏集中治理和标准化合规性控制。
工作流：在所有 EC2 和本地服务器上安装 AWS Systems Manager 代理 → 将 Patch Manager 与补丁基准和补丁组结合使用，并在维护时段内安排更新。
亚马逊麦西
这会发现 S3 中的敏感数据并对其进行分类，并提出潜在的公众暴露或对 PII 的异常访问的调查结果。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这会发现 S3 中的敏感数据并对其进行分类，并提出潜在的公众暴露或对 PII 的异常访问的调查结果。
● 场景匹配：这会发现 S3 中的敏感数据并对其进行分类，并提出潜在的公众暴露或对 PII 的异常访问的调查结果。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 检测恶意或异常行为并包括 S3 保护，但它不会根据 S3 中的合规性需求对 PII 暴露进行分类或评估。
● 聚合其他安全服务的发现并确定其优先级，并且无法直接发现 PII 或自行评估 S3 数据暴露。
● 重点关注计算和容器资源的漏洞评估，而不是 S3 数据分类或 PII 监控。
工作流：亚马逊麦西。
控制台副本使用多部分；校验和是由部分校验和聚合而成，而不是全部
大型控制台副本通常使用多部分，产生与单部分整体对象校验和不同的部分校验和。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：大型控制台副本通常使用多部分，产生与单部分整体对象校验和不同的部分校验和。
● 场景匹配：大型控制台副本通常使用多部分，产生与单部分整体对象校验和不同的部分校验和。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 服务器端加密不会以这种方式改变校验和语义；对于 SSE-S3 或 SSE-KMS，校验和不是通过密文计算的。
● S3校验和字段独立于ETag；校验和不是从 ETag 值派生的。
● 不存在使有效的单部分校验和无效的通用阈值；不匹配不是由于原始校验和不正确造成的。
工作流：控制台副本使用多部分 → 校验和是从部分校验和聚合而成，而不是整个对象。
用于经过身份验证的用户和来宾用户的 Amazon Cognito 身份池，请使用
Cognito 身份池将社交或 OIDC 身份代理到映射到 IAM 角色的 STS 临时凭证中，从而实现对 S3 和 DynamoDB 的安全直接访问。 AssumeRoleWithWebIdentity 交换。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Cognito 身份池将社交或 OIDC 身份代理到映射到 IAM 角色的 STS 临时凭证中，从而实现安全。
● 场景匹配：Cognito 身份池将社交或 OIDC 身份代理到映射到 IAM 角色的 STS 临时凭证中，从而实现安全。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● SAML 适用于 SAML 2.0 企业身份提供商，不是社交或 OIDC 登录的正确机制。
● 在移动应用程序中嵌入长期访问密钥是不安全的，并且违反了需要临时凭据的最佳实践。
工作流：为经过身份验证的用户和来宾用户创建 Amazon Cognito 身份池 → 使用 React Native AWS SDK 检索临时 AWS 凭证，并分配范围为 S3 和 DynamoDB 的 IAM 角色。
EventBridge规则：S3 PUT -> ECS RunTask； S3 删除 -> Lambda StopTask
EventBridge 可以为每个 S3 上传使用 RunTask 启动临时 Fargate 任务，从而避免持续运行的服务。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：EventBridge 可以为每个 S3 上传使用 RunTask 启动临时 Fargate 任务，从而避免持续运行的服务。
● 场景匹配：EventBridge 可以为每个 S3 上传使用 RunTask 启动临时 Fargate 任务，从而避免持续运行的服务。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● CloudWatch 警报基于阈值，CloudTrail 是每个对象处理的间接来源。
● SQS 可用于缓冲，但 ECS 服务仍然是更持久的操作模型。
● 容量提供程序控制 ECS 获取容量的方式，而不是控制各个 Fargate 任务启动或停止的时间。
工作流：EventBridge 规则：S3 PUT -> ECS RunTask → S3 DELETE -> Lambda StopTask。
用于发出自定义指标的 CloudWatch Logs 指标过滤器，构建
指标过滤器将匹配的日志事件转换为可以报警并路由到 SNS 的指标，这是日志衍生的最直接和可扩展的方法。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：指标过滤器将匹配的日志事件转换为可以发出警报并路由到 SNS 的指标。
● 场景匹配：指标过滤器将匹配的日志事件转换为可以发出警报并路由到 SNS 的指标。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● X-Ray 专注于跟踪和服务映射，而不是从应用程序日志中计算日志行错误的发生次数，所以它确实如此。
● 在应用程序中嵌入错误计数和 SetAlarmState 在多个实例中很脆弱，并且会滥用 CloudWatch 警报，从而导致这种情况。
● 指标过滤器会生成指标，但如果不先创建相应的 CloudWatch 指标，则无法直接定位警报。
工作流：创建 CloudWatch Logs 指标过滤器以发出自定义指标，通过 10 分钟的评估针对该指标构建 CloudWatch 警报，并通过 SNS 电子邮件发送通知。
具有响应标头策略的 CloudFront
将响应标头策略附加到分发，以在查看器响应中注入安全标头，而无需自定义代码。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：将响应标头策略附加到分发，以在查看器响应中注入安全标头，而无需自定义代码。
● 场景匹配：将响应标头策略附加到分发，以在查看器响应中注入安全标头，而无需自定义代码。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 它们根据请求将标头从 CloudFront 发送到源，并且不会在查看器响应上设置标头。
● 存储桶策略控制访问，不能修改 HTTP 响应标头。
● 可能，但与使用本机响应标头策略相比会增加代码和操作开销。
工作流：具有响应标头策略的 CloudFront。
AWS Transit Gateway 用于 VPC 之间的传递连接并管理网络访问
Transit Gateway 本身支持可扩展的传递路由，Firewall Manager 为跨账户和 VPC 的网络控制提供集中策略实施。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Transit Gateway 本身支持可扩展的传递路由，Firewall Manager 为跨账户和 VPC 的网络控制提供集中策略实施。
● 场景匹配：Transit Gateway 本身支持可扩展的传递路由，防火墙管理器为跨网络控制提供集中策略实施。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● VPC 对等互连不具有传递性，AWS WAF 专注于第 7 层 Web 流量，而不是跨 VPC 的集中式网络访问控制。
● PrivateLink 支持专用服务访问而不是全网状路由，Security Hub 会聚合结果但不强制实施网络策略。
● AWS Site-to-Site VPN 专为本地到 AWS 连接而设计，构建许多 VPC 到 VPC 隧道操作复杂且效率低下。
工作流：使用 AWS Transit Gateway 在 VPC 之间实现传递连接，并通过 AWS Firewall Manager 集中管理网络访问策略。
用于获取最新 AMI 的 CloudFormation 自定义资源 (Lambda)
在堆栈创建/更新时解析 AMI ID，无需编辑模板。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：在堆栈创建/更新时解析 AMI ID，无需编辑模板。
● 场景匹配：在堆栈创建/更新时解析 AMI ID，无需编辑模板。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 仅适用于供应商发布的 AMI，不适用于自定义应用程序映像。
● 增加了不必要的调度、模板改动和成本。
● 无法更改已用于启动实例的 AMI。
工作流：用于获取最新 AMI 的 CloudFormation 自定义资源 (Lambda)。
具有自定义规则和 Lambda 的 AWS Config
持续记录 EC2 和专用主机关系，并通过自定义规则和内置合规性摘要评估合规性。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：持续记录 EC2 和专用主机关系，并通过自定义规则和内置合规性摘要评估合规性。
● 场景匹配：持续记录 EC2 和专用主机关系，并通过自定义规则和内置合规性摘要评估合规性。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 跟踪和强制执行许可证，但不评估 EC2 专用主机放置的合规性。
● 可能，但维护成本高且由事件驱动，对于持续的配置合规性报告来说并不理想。
● 重点关注补丁和配置基线，而不是专用主机放置验证。
工作流：具有自定义规则和 Lambda 的 AWS Config。
将 AMI 复制到每个区域并存储每个区域的 Lambda
复制每个区域的 AMI 并记录区域特定的 AMI ID 以进行编程查找。提供一致、可重复的工作流程来修补、强化和烘焙 AMI。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：复制每个区域的 AMI 并记录区域特定的 AMI ID 以供编程查找。
● 场景匹配：复制每个区域的 AMI 并记录区域特定的 AMI ID 以进行编程查找。提供一致的、可重复的。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 处理备份和快照，但不会创建或注册用于启动的 AMI。
● 配置实例状态，但不构建或复制 AMI。
● 复制字符串不会分发 AMI； AMI ID 是区域范围的并且需要 AMI 副本。
工作流：创建一个 Lambda，将 AMI 复制到每个区域，并将每个 AMI ID 存储在 Parameter Store 中的公用密钥下 → 编写 AWS Systems Manager Automation Runbook 以构建和强化 AMI。
应用程序负载均衡器上未启用附加可用区
ALB 必须显式启用每个可用区，以便它在该区域中创建一个负载均衡器节点并可以在那里路由流量。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：ALB 必须显式启用每个可用区，以便在该区域中创建负载均衡器节点。
● 场景匹配：ALB 必须显式启用每个可用区，以便在该区域中创建负载均衡器节点。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 禁用跨区域负载平衡会影响跨区域的分布，但不会阻止路由到在 ALB 上启用的可用区。
● Auto Scaling 组正在那里启动实例，这意味着子网存在；问题更有可能是 ALB 未启用该区域。
● 失败的运行状况检查将标记目标运行状况不佳，但扩展到新区域后流量为零的症状最常见表明 ALB 区域从未启用。
工作流：Application Load Balancer 上未启用附加可用区。
AWS::EC2::Volume 的 AWS Config 必需标签，具有 SSM 自动化修复以添加 BackupInterval=15d
持续评估 EBS 卷并自动将缺失的标签添加到不合规资源。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：持续评估 EBS 卷并自动将缺失的标签添加到不合规资源。
● 场景匹配：持续评估 EBS 卷并自动将缺失的标签添加到不合规资源。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 阻止未标记的创建，但不会自动标记现有资源或修复标记漂移。
● 标签策略有助于标准化和报告，但不会在 API 上强制执行或自动修复。
● 仅处理创建时事件，不会修复现有或以后未标记的卷。
工作流：使用 SSM 自动化修复为 AWS::EC2::Volume 配置 AWS Config 必需标签以添加 BackupInterval=15d。
AWS Elastic Beanstalk 上具有负载均衡和 Auto Scaling 功能的应用程序
Elastic Beanstalk 提供了一个托管 Node.js 平台，其中集成了应用程序负载均衡器和 Auto Scaling，从而减轻了运营负担。 RDS 是一种托管关系数据库服务，并且。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Elastic Beanstalk 提供了一个托管 Node.js 平台，其中集成了应用程序负载均衡器和 Auto Scaling，从而减轻了运营负担。
● 场景匹配：Elastic Beanstalk 提供了一个托管 Node.js 平台，其中集成了应用程序负载均衡器和 Auto Scaling，从而减轻了运营负担。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Approach 不提供托管 Web 应用程序平台或为有状态 Web 服务提供适当的负载平衡，并且对于 Lambda 来说是不必要的。
● 仍然需要管理服务器、修补和容量详细信息，这与最小化操作的目标相冲突。
● DynamoDB 是一种 NoSQL 服务，不满足托管关系数据库的要求。
工作流：在 AWS Elastic Beanstalk 上部署应用程序，并启用负载均衡和 Auto Scaling → 在 VPC 中配置独立的 Amazon RDS 实例，并启用自动备份和删除保护。
用于评估公共 S3 存储桶策略的自定义 AWS Config 规则
这使用 AWS Config 持续评估存储桶 ACL 和策略，并在存储桶不合规时通过 SNS 发出通知。 EventBridge 与 Trusted Advisor 检查集成。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这使用 AWS Config 持续评估存储桶 ACL 和策略，并在存储桶出现时通过 SNS 通知。
● 场景匹配：这使用 AWS Config 持续评估存储桶 ACL 和策略，并在存储桶出现时通过 SNS 通知。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Amazon Inspector 不会评估 S3 存储桶策略，因此不会识别或修复公共存储桶。
● 帐户级别阻止公共访问将禁用预期的公共存储桶，这违反了保持某些存储桶公开的要求。
● 与 EventBridge 事件相比，使用 Lambda 轮询 Trusted Advisor 是不必要的，而且速度较慢，而且摘要电子邮件不是实时的。
工作流：配置自定义 AWS Config 规则，用于评估公共访问的 S3 存储桶策略并向 Amazon SNS 主题发布不合规通知 → 使用 Amazon EventBridge 捕获 Trusted Advisor S3。
检查 VPC 流日志是否存在 REJECT；确认 SG 允许出站 HTTPS
带有 REJECT 条目的流日志直接显示被阻止的流量，并验证 TCP 443 的出站 SG 规则，以解决迁移到 HTTPS 后可能出现的出口问题。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：带有 REJECT 条目的流日志直接显示被阻止的流量，并验证 TCP 443 的出站 SG 规则，以解决迁移到 HTTPS 后可能出现的出口问题。
● 场景匹配：带有 REJECT 条目的流日志直接显示阻止的流量并验证 TCP 443 目标的出站 SG 规则。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 应用程序日志可能不会显示网络出口拒绝，默认 NACL 通常允许所有情况；这不太适合精确定位网络块。
● 实例发起连接，因此实例上的入口规则不是问题； ACCEPT 条目不会突出显示拒绝。
● 分析 VPC 资源之间的路径，不测试外部 Internet 端点的可达性或诊断 SG 出口拒绝。
工作流：检查 VPC 流日志是否存在 REJECT → 确认 SG 允许出站 HTTPS。
PR 上的 CodeGuru Reviewer Secrets Detector 并在 AWS 中存储数据库凭证
CodeGuru Reviewer 检测 PR 中的硬编码机密，并可以通过状态检查阻止合并，而 Secrets Manager 提供托管凭证轮换。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CodeGuru Reviewer 检测 PR 中的硬编码机密，并可以通过状态检查阻止合并，而 Secrets Manager 提供托管凭证轮换。
● 场景匹配：CodeGuru Reviewer 检测 PR 中的硬编码机密，并可以通过状态检查阻止合并，而 Secrets Manager 提供托管凭证轮换。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Macie 分析 S3 数据，而不是 GitHub PR，并且环境变量不提供 PR 阻止或自动轮换。
● CodeGuru Profiler 用于性能分析，而 Parameter Store 缺乏本机自动轮换和 PR 门控。
● 构建时检查不会强制执行 PR 时秘密阻止，并且 Parameter Store 不会处理自动轮换。
工作流：在 PR 上使用 CodeGuru Reviewer Secrets Detector 并将数据库凭证存储在 AWS Secrets Manager 中，并轮换更新代码以获取密钥。
在每个实例上安装带有 procstat 插件的 Amazon CloudWatch 代理
Procstat 提供近乎实时的进程指标，调用 Systems Manager Run Command 的 CloudWatch 警报只会快速重新启动失败的进程，而不会影响 Auto Scaling 容量。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Procstat 提供近乎实时的进程指标，调用 Systems Manager Run Command 的 CloudWatch 警报仅重新启动失败的进程。
● 场景匹配：Procstat 提供近乎实时的进程指标，调用 Systems Manager Run Command 的 CloudWatch 警报仅重新启动失败的进程。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 通过待机和重新启动来循环实例的速度很慢，会影响循环期间的容量，并且会重新启动整个实例。
● 将实例标记为“不健康”会触发终止和替换，与仅重新启动实例相比，这会更慢并且会暂时减少容量。
工作流：在每个实例上安装带有 procstat 插件的 Amazon CloudWatch 代理以发布每个进程的指标，并使用 CloudWatch 警报调用 AWS Systems Manager Run Command 来重新启动工作线程。
一个 Amazon EventBridge 规则，用于筛选设置了complianceType 的受限 ssh 评估
这只针对受限 ssh 规则中的相关 NON_COMPLIANT 事件，并使用输入转换器在发送到 SNS 之前包含所需的标识符。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这只针对受限 ssh 规则中的相关 NON_COMPLIANT 事件，并使用输入转换器来包含。
● 场景匹配：这只针对受限 ssh 规则中的相关 NON_COMPLIANT 事件，并使用输入转换器来包含。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 效率低下，并且依赖于 SNS 主题级过滤策略，由于配置了消息过滤，因此不支持该策略。
● 过于宽泛，并且再次错误地假设在 SNS 主题级别而不是订阅上进行过滤。
● ERROR 表示规则评估问题，而不是安全组不合规，因此不满足警报要求。
工作流：创建一个 Amazon EventBridge 规则，用于过滤受限 ssh 评估，并将complianceType 设置为 NON_COMPLIANT → 添加输入转换器以包含安全组名称和 ID，然后发布到。
构建一个包含生产、QA 和沙箱阶段的 CodePipeline，并进行配置
CloudFormation 操作参数覆盖和映射允许一个可重用模板，而每个阶段都会传递自己的环境参数。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudFormation 操作参数覆盖和映射允许一个可重用模板，而每个阶段都会传递自己的环境参数。
● 场景匹配：CloudFormation 操作参数覆盖和映射允许一个可重用模板，而每个阶段都会传递自己的环境参数。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 将模板与管道状态紧密耦合，与本机参数化相比，增加了不必要的操作复杂性。
● 创建实例后修改 UserData 很脆弱，并且不利于 CloudFormation 的声明性模型。
● 仍然依赖于手动协调，并且不利用 CodePipeline 自动提供环境值。
工作流：构建包含生产、QA 和沙箱阶段的 CodePipeline，并使用参数覆盖配置 CloudFormation 操作 → 使用 CloudFormation 映射和 EC2 UserData 设置特定于环境的值。
将 JSON 文件放入启用版本控制的 S3 存储桶中，并
S3 版本控制提供审核和回滚，而 EventBridge 和 Lambda 使用托管服务实现自动化、可扩展且无需重新启动的刷新。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：S3 版本控制提供审核和回滚，而 EventBridge 和 Lambda 使用托管功能实现自动化、可扩展且无需重新启动的刷新。
● 场景匹配：S3 版本控制提供审核和回滚，而 EventBridge 和 Lambda 使用托管功能实现自动化、可扩展且无需重新启动的刷新。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 该方法需要重建映像并重新启动任务，这会阻止动态更新并增加操作难度。
● 尽管支持版本控制，但 Parameter Store 具有每个参数的大小限制，并且成本高昂且难以大规模管理。
● Secrets Manager 针对敏感凭证进行了优化，但一般配置集规模不大且不断增长，因此不太适合。
工作流：将 JSON 文件放入启用版本控制的 S3 存储桶中，并使用 Amazon EventBridge 按计划调用 AWS Lambda 函数，该函数根据需要刷新正在运行的 ECS 任务内的配置。
CloudWatch 与 AWS Organizations 的跨账户可观察性，用于指定中央操作账户
这本身就统一了跨帐户的指标、日志和跟踪，并自动包含新的组织帐户。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这本身就统一了跨帐户的指标、日志和跟踪，并自动包含新的组织帐户。
● 场景匹配：这本身就统一了跨帐户的指标、日志和跟踪，并自动包含新的组织帐户。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 提供跨账户可见性，但需要手动连接，并且不会自动注册新创建的组织账户。
● 仅流式传输指标，不包括日志或 X 射线跟踪，也不自动加入新帐户。
● EventBridge 无法直接交付到 S3，并且此设计不会聚合 X-Ray 跟踪或自动加入新帐户。
工作流：将 CloudWatch 跨账户可观察性与 AWS Organizations 结合使用，将中央操作账户指定为监控账户并链接所有组织账户。
Secrets Manager 在启用轮换后立即执行初始轮换，使
打开轮换后，Secrets Manager 会触发初始轮换，如果应用程序未更新以获取凭证，则可能会使之前使用的凭证失效。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：打开轮换后，Secrets Manager 会触发初始轮换，这可能会使之前使用的凭证失效。
● 场景匹配：打开轮换后，Secrets Manager 会触发初始轮换，这可能会使之前使用的凭证失效。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 默认情况下，当未指定版本时，Secrets Manager 将返回 AWSCURRENT 版本，因此通常会忽略版本。
● 获取密码值需要secretsmanager:GetSecretValue，如果GetSecretValue存在，单独缺少DescribeSecret不会阻止检索密码。
● 如果初始版本有效并且网络没有更改，则不太可能丢失 VPC 端点，而且 Secrets Manager 也不会丢失。
工作流：Secrets Manager 在启用轮换后立即执行初始轮换，使旧密码失效，同时应用程序仍使用过时的凭据。
AWS Application Discovery Service 通过将无代理 Discovery Connector (OVA) 部署到
Application Discovery Service 为 vCenter 管理的虚拟机提供无代理收集，并通过代理增强 EC2，而 Migration Hub 提供只需最少设置的内置仪表板。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Application Discovery Service 为 vCenter 管理的虚拟机提供无代理收集，并通过代理增强 EC2，而 Migration Hub 提供只需最少设置的内置仪表板。
● 场景匹配：Application Discovery Service 为 vCenter 管理的虚拟机提供无代理收集，并通过代理和迁移中心增强 EC2。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 可以工作，但需要在每台服务器上部署和管理代理，这对于这种规模来说是一项巨大的工作。
● AWS Config 跟踪 AWS 资源配置，并且不会收集本地 VMware VM 的主机级操作系统、MAC 或 IP 详细信息。
● 与托管发现工具相比，自定义摄取需要大量的工程、部署和维护。
工作流：通过将无代理 Discovery Connector (OVA) 部署到 VMware vCenter 并在 EC2 实例上安装 Discovery Agent 来使用 AWS Application Discovery Service → 在 AWS Migration Hub 中可视化。
lambda.amazonaws.com 作为 IAM 角色中的可信委托人
Lambda 执行角色必须信任 lambda.amazonaws.com，以便服务可以代入该角色并运行函数来转发日志。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Lambda 执行角色必须信任 lambda.amazonaws.com，以便服务可以代入该角色并运行函数来转发日志。
● 场景匹配：Lambda 执行角色必须信任 lambda.amazonaws.com，以便服务可以代入该角色并运行。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 使用logs.amazonaws.com 作为可信委托人是不正确的，因为Lambda 执行角色必须信任lambda.amazonaws.com，而不是CloudWatch Logs。
● 导出任务是面向批处理的，并且不会修复损坏的 OpenSearch 实时订阅过滤器。
● 您无法将 IAM 策略附加到 OpenSearch 域，并且此策略属于 Lambda 函数以启用 VPC 网络。
工作流：将 lambda.amazonaws.com 添加为 IAM 角色中的可信委托人，该角色由从 CloudWatch Logs 订阅创建的 Lambda 函数使用。
appspec.yml 中 ValidateService 挂钩中的健康检查并启用自动回滚
ValidateService 在服务启动并接收流量后运行；此处失败会触发 CodeDeploy 自动回滚。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：ValidateService 在服务启动并接收流量后运行；此处失败会触发 CodeDeploy 自动回滚。
● 场景匹配：ValidateService 在服务启动并接收流量后运行；此处失败会触发 CodeDeploy 自动回滚。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● ALB 运行状况本身不会指示 CodeDeploy 回滚，除非与失败的生命周期挂钩或警报相关。
● 警报可以回滚部署，但这并不能回答哪个生命周期挂钩应该运行运行时运行状况检查。
● 重复本机 CodeDeploy 回滚并增加不必要的复杂性。
工作流：在 appspec.yml 中的 ValidateService 挂钩中运行运行状况检查，并在失败时启用自动回滚。
重新解决重叠的 CIDR，部署与共享的集中式 AWS Transit Gateway
重新编号消除了重叠，AWS Transit Gateway 通过私有、可路由路径为多账户 VPC 连接提供可扩展的中心辐射型连接。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：重新编号消除了重叠，AWS Transit Gateway 为多账户 VPC 与私有连接提供了可扩展的中心辐射型连接。
● 场景匹配：重新编号消除了重叠，AWS Transit Gateway 为多账户 VPC 与私有连接提供了可扩展的中心辐射型连接。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● PrivateLink 保持流量私有，但由于每个服务、每个 VPC 端点而导致大规模操作变得繁重，并且不提供。
● 对等网格无法扩展（N×(N−1)/2 链路），并且无法连接具有重叠 CIDR 的 VPC。
● 服务网格管理服务到服务的流量策略，但仍然需要底层网络连接，并且不能解决多 VPC 路由问题。
工作流：重新解决重叠的 CIDR → 部署与 AWS RAM 共享的集中式 AWS Transit Gateway → 连接每个 VPC 并通过附件添加到其 CIDR 的路由，并使用用于私有 HTTPS 的内部 NLB 前端服务。
CloudWatch Logs 指标筛选器到自定义指标、CloudWatch 警报（15 分钟）
指标过滤器将匹配的日志行转换为 CloudWatch 警报可以在 15 分钟内评估并通过 SNS 电子邮件通知的指标。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：指标过滤器将匹配的日志行转换为 CloudWatch 警报可以在 15 分钟内评估并通过 SNS 电子邮件通知的指标。
● 场景匹配：指标过滤器将匹配的日志行转换为 CloudWatch 警报可以在 15 分钟内评估的指标。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 自定义 Lambda 计数器是可能的，但会增加窗口的操作开销和状态管理，这对于此用例来说是不必要的。
● X-Ray 用于跟踪和延迟分析，而不是用于计算日志错误发生次数和来自 CloudWatch Logs 的警报。
● 在应用程序中嵌入警报逻辑在跨实例时很脆弱，并且会误用 CloudWatch 警报；它效率低下或可扩展。
工作流：CloudWatch Logs 指标过滤器为自定义指标、CloudWatch 警报（15 分钟）和 SNS 电子邮件。
针对 CodeDeploy 部署 + LambdaCanary10Percent10Minutes 的 Lambda 错误的 CloudWatch 警报
CodeDeploy 可以监控 CloudWatch 警报，并在超出阈值时自动停止和回滚。将 10% 的流量路由到新版本 10 分钟，然后转移其余流量。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CodeDeploy 可以监控 CloudWatch 警报，并在超出阈值时自动停止和回滚。
● 场景匹配：CodeDeploy 可以监控 CloudWatch 警报，并在超出阈值时自动停止和回滚。将 10% 的流量路由到新版本 10 分钟，然后转移其余流量。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 所有流量都会立即转移，没有金丝雀窗口。
● API Gateway 金丝雀不与 CodeDeploy 集成以进行 Lambda 回滚，并且仅影响 API Gateway 流量。
● 以重复增量的方式转移流量，而不是单一的两步金丝雀。
工作流：将 Lambda 错误的 CloudWatch 警报附加到 CodeDeploy 部署 → LambdaCanary10Percent10Minutes。
目标账户：来自源的管道角色信任的 IAM 角色；允许
在信任源账户管道角色的目标中创建一个跨账户 IAM 角色，以便 CodePipeline 可以代入该角色。目标帐户中需要 CloudFormation。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：在目标中创建一个跨账户 IAM 角色，该角色信任源账户的管道角色，以便 CodePipeline 可以。
● 场景匹配：在目标中创建一个跨账户 IAM 角色，该角色信任源账户的管道角色，以便 CodePipeline 可以。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● AWS RAM 不支持跨账户共享 CodePipeline 项目的 S3 存储桶或 KMS 密钥。
● CloudFormation 执行角色必须存在于创建资源的目标账户中。
● SCP 设置了护栏，无法为跨账户操作授予权限或建立信任。
工作流：目标账户：来自源的管道角色信任的 IAM 角色 → 允许 AssumeRole → 目标账户：堆栈的 CloudFormation 执行角色 → 管道使用该角色 → 源账户：KMS。
确保 Lambda 函数将成功或失败结果发布到
自定义资源提供程序必须将响应放入预签名的 ResponseURL，以便 CloudFormation 可以转换堆栈状态。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：自定义资源提供程序必须将响应放入预签名的 ResponseURL，以便 CloudFormation 可以转换堆栈状态。
● 场景匹配：自定义资源提供程序必须将响应放入预签名的 ResponseURL，以便 CloudFormation 可以转换堆栈状态。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 干净的 Lambda 退出并不向 CloudFormation 发出信号；自定义资源需要对所提供的 URL 进行显式响应。
● UpdateStack 权限与完成自定义资源信号无关，因此此处不需要。
● 虽然创建连接器可能需要此权限，但如果没有自定义资源响应，它无法解析挂起的堆栈状态。
工作流：确保 Lambda 函数将成功或失败结果发布到预签名的 CloudFormation 响应 URL。
控制台对大对象使用了多部分副本并生成
对于超过 16 MB 的对象的控制台操作，S3 通常执行多部分复制并计算校验和的校验和，而不是单部分校验和。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：对于超过 16 MB 的对象的控制台操作，S3 通常执行多部分复制并计算校验和的校验和，而不是单部分校验和。
● 场景匹配：对于超过 16 MB 的对象的控制台操作，S3 通常执行分段复制并计算校验和的校验和。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 错误是因为在此上下文中控制台触发的多部分行为阈值不是 64 MB，并且单部分上传提供整个对象校验和。
● S3 不会仅仅因为元数据被编辑而更改校验和算法。
● 服务器端加密不会以这种方式改变对象校验和的语义，并且不会考虑这种差异。
工作流：控制台对大对象使用了多部分副本，并生成了一个新的校验和，该校验和聚合了部分校验和，而不是表示完整对象校验和。
AWS 计算优化器 EC2 建议
使用历史指标的机器学习来推荐最佳的 EC2 实例类型和大小。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：使用历史指标的机器学习来推荐最佳的 EC2 实例类型和大小。
● 场景匹配：使用历史指标的机器学习来推荐最佳的 EC2 实例类型和大小。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 通过阈值启用监控和自动化，但不提供跨实例类型的 ML 驱动的规模调整。
● 提供以成本为中心的规模调整建议，但不如 Compute Optimizer 全面。
● 提供常规检查，包括空闲资源，但不提供基于 ML 的详细调整。
工作流：AWS 计算优化器 EC2 建议。
应用程序端口的 Auto Scaling 组中的 ELB 运行状况检查
ASG ELB 运行状况检查可确保扩展决策遵循负载均衡器对正确端口和路径的真实应用程序探测。目标群体健康检查必须进行探测。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：ASG ELB 运行状况检查可确保扩展决策遵循负载均衡器对正确端口和路径的真实应用程序探测。
● 场景匹配：ASG ELB 运行状况检查可确保扩展决策遵循负载均衡器在正确端口上的真实应用程序探测。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 切换到 IP 目标并不能修复由于运行状况检查或侦听器到目标配置不一致而导致的可达性。
● ALB仅支持HTTP或HTTPS监听； TCP 用于 NLB。
● 如果健康检查已经成功，安全组津贴就足够了；问题在于运行状况检查配置或映射，而不是 SG。
工作流：在 Auto Scaling 组中对应用程序的端口和路径使用 ELB 运行状况检查 → 将目标组运行状况检查设置为应用程序的自定义端口和运行状况端点。
AWS WAF IP 集白名单，其中包括开发团队的公共 IP
WAF 中的 IP 设置允许列表仅允许来自被阻止区域的批准源地址到达应用程序，而其他流量将被过滤。 WAF 地理区域。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：WAF 中的 IP 设置允许列表仅允许来自被阻止区域的批准源地址到达应用程序。
● 场景匹配：WAF 中的 IP 设置允许列表仅允许来自被阻止区域的批准源地址到达应用程序。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 提高 DDoS 抵御能力，但不实施基于国家/地区的阻止或团队的允许名单。
● ALB 侦听器规则无法评估国家/地区信息，并且地理匹配由 AWS WAF 或 CloudFront 强制执行，而不是由 AWS WAF 或 CloudFront 强制执行。
● NACL 是无国籍的，仅在 IP 地址和端口上运行，因此它们不能按国家/地区进行阻止。
工作流：使用包含开发团队的公共 IP 地址的 AWS WAF IP 集白名单 → 使用 AWS WAF 地理匹配规则阻止来自指定国家/地区的请求。
在重新平衡期间，EC2 Auto Scaling 可能会短暂超过组最大值
重新平衡会在终止其他实例之前启动替换实例，这些实例可以暂时超过 MaxSize 最多 10% 或一个实例以维持可用性。缩小时，自动缩放。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：重新平衡会在终止其他替换之前启动替换，这可能会暂时超出 MaxSize 最多 10% 或一个实例。
● 场景匹配：重新平衡会在终止其他替换之前启动替换，这可能会暂时超过 MaxSize 最多 10% 或一个实例。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Auto Scaling 优先考虑跨可用区的平衡而不是实例年龄，因此基于年龄的终止本身不会导致可用区。
● 默认终止策略会在考虑计费时间之前评估可用区重新平衡，因此不会优先删除实例。
工作流：在重新平衡期间，EC2 Auto Scaling 可能会暂时超出组最大值最多 10% 或增加一个实例，以避免影响 → 使用混合实例策略 → 缩减。
适用于 AWS Health EC2 停用计划事件的 Amazon EventBridge 规则
AWS Health 会发出计划的停用事件，EventBridge 可以精确定位该事件，从而允许 SSM Automation 编排将实例移至所需的停止/启动。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：AWS Health 会发出计划的停用事件，EventBridge 可以精确定位该事件，从而允许 SSM Automation 进行编排。
● 场景匹配：AWS Health 会发出计划的停用事件，EventBridge 可以精确定位该事件，从而允许 SSM Automation 进行编排。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Auto Scaling 替换会对运行状况故障做出反应，不会根据计划主动停止和启动实例。
● EC2 状态更改事件并不表示计划的停用，并且会触发许多不相关的停止，从而产生噪音和范围错误。
● 自动恢复解决的是受损实例而不是计划的停用问题，并且 CloudWatch 警报操作无法按时间安排在非工作时间执行。
工作流：为 AWS Health EC2 停用计划事件配置 Amazon EventBridge 规则，该规则调用 AWS Systems Manager Automation Runbook 来停止 → 启动受影响的实例。
Spot 队列的目标跟踪策略保持约 60% 的平均 CPU 利用率
应用程序 Auto Scaling 目标跟踪可调整 Spot 队列容量，以使 CPU 保持在目标附近。计划操作在特定时间设置预配置并发，以实现可预测的模式。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：应用程序 Auto Scaling 目标跟踪可调整 Spot 队列容量，以使 CPU 保持在目标附近。
● 场景匹配：应用程序 Auto Scaling 目标跟踪可调整 Spot 队列容量，以使 CPU 保持在目标附近。预定的行动已设定。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 预测扩展适用于 EC2 Auto Scaling 组，而不是 Spot 队列，并且不直接控制队列 CPU 利用率。
● 通过目标跟踪，Application Auto Scaling 可以自动创建和管理 CloudWatch 警报。
● Lambda 不支持使用 Application Auto Scaling 进行步进扩展；请改用带有计划或目标跟踪的预配置并发。
工作流：Spot 队列的目标跟踪策略是维持约 60% 的平均 CPU → 计划在周中高峰期间对别名配置并发的 Lambda 扩展。
CloudWatch 代理将 /var/log/secure 或 auth.log 转发到 CloudWatch Logs，创建
指标过滤器将匹配的日志行转换为可发出警报的指标，从而为登录事件提供近乎实时的 SNS 通知。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：指标过滤器将匹配的日志行转换为可以发出警报的指标，从而实现近乎实时的 SNS 通知。
● 场景匹配：指标过滤器将匹配的日志行转换为可以发出警报的指标，从而实现近乎实时的 SNS 通知。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● CloudTrail 专注于 AWS API 活动，不能保证 60 秒内交付，因此不适合。
● 订阅过滤器将匹配的事件转发到目的地，但本身不会创建用于警报的指标或警报。
● GuardDuty 生成威胁发现和异常情况，而不是近乎实时地对每次成功的主机登录发出警报。
工作流：部署 CloudWatch 代理以将 /var/log/secure 或 auth.log 转发到 CloudWatch Logs → 为成功登录模式创建指标筛选器，并触发 SNS 警报以向安全团队发出警报。
AWS Config cloudtrail-enabled 或 cloudtrail-security-trail-enabled 以及 EventBridge 触发的修复
Config 持续评估和记录合规性，并可以通过 EventBridge 到 Lambda 或 SSM 触发修复。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Config 持续评估和记录合规性，并可以通过 EventBridge 到 Lambda 或 SSM 触发修复。
● 场景匹配：Config 持续评估和记录合规性，并可以通过 EventBridge 到 Lambda 或 SSM 触发修复。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 定期轮询可能会错过更改，并且不提供连续的合规历史记录。
● SCP 会阻止操作，但不确保 CloudTrail 已启用、提供合规性历史记录或执行补救。
● Security Hub 检测并汇总结果，但不会自动修复或维护每条规则的配置历史记录。
工作流：AWS Config cloudtrail-enabled 或 cloudtrail-security-trail-enabled 以及 EventBridge 触发的修复。
亚马逊麦西
在 S3 中执行自动敏感数据发现，并生成潜在暴露的结果，例如公共或跨账户访问。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：在 S3 中执行自动敏感数据发现，并生成潜在暴露的结果，例如公共或跨账户访问。
● 场景匹配：在 S3 中执行自动敏感数据发现，并生成潜在暴露的结果，例如公共或跨账户访问。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 汇总其他服务和框架的发现；不检查 S3 对象内容或对 PII 进行分类。
● 分析公共和跨账户访问的资源策略，但不对 PII 数据进行分类或扫描。
● 使用 CloudTrail、VPC 流日志和 DNS 日志进行威胁检测；不适用于 S3 PII 分类。
工作流：亚马逊麦西.
CloudFront 分配的 AWS WAF Web ACL + 部署 CloudFront
在流量到达源头之前，为常见的 Web 漏洞提供边缘检查和缓解措施。 CloudFront 减少了全局延迟，与 HTTPS 的 ACM 集成，并受益于 AWS Shield Standard。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：在流量到达源头之前，为常见的 Web 漏洞提供边缘检查和缓解措施。
● 场景匹配：在流量到达源头之前，为常见的 Web 漏洞提供边缘检查和缓解措施。 CloudFront 减少了全局延迟。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 提高全局性能和 L3/L4 DDoS 弹性，但不提供边缘 WAF 检查或缓存。
● 在区域 ALB 处确保安全，但缺乏边缘检查，并且不会改善全局延迟。
● CloudFront 无法直接使用 Auto Scaling 组作为源；使用 ALB 或实例端点。
工作流：将 AWS WAF Web ACL 附加到 CloudFront 分配 → 在 ALB 前面部署 CloudFront 并使用 ACM 作为自定义域 TLS。
明确拒绝所有主体的 iam:CreateUser 的组织 SCP，除非 aws:username
对 CreateUser 进行明确拒绝以及仅允许列出的用户名的条件的 SCP 是一种预防性的组织范围控制。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：对 CreateUser 进行明确拒绝并设置仅允许列出的用户名的条件的 SCP 是一种预防性的组织范围控制。
● 场景匹配：对 CreateUser 进行明确拒绝以及仅允许列出的用户名的条件的 SCP 是一种预防性的组织范围控制。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 是反应性的，并在事后尝试清理，而不是阻止组织边界处的 CreateUser 调用。
● CreateLoginProfile 控制现有用户的密码，并且不会阻止 IAM 用户的创建。
● 权限边界必须附加到每个主体，不能限制根用户，并且不是有效的组织范围的预防控制。
工作流：附加一个组织 SCP，明确拒绝所有委托人的 iam:CreateUser，除非 aws:username 通过使用 StringNotLike 条件与已批准的例外列表匹配。
Kinesis Data Streams + Apache Flink 托管服务 + Firehose
这将专用流媒体与无服务器交付到 S3 以及用于即席分析的低成本元存储和查询层结合在一起。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这将专用流媒体与无服务器交付到 S3 以及用于即席分析的低成本元存储和查询层结合在一起。
● 场景匹配：这将专用流媒体与无服务器交付到 S3 以及用于即席分析的低成本元存储和查询层结合在一起。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● EventBridge 并不适合持续的高吞吐量流，并且会带来不必要的成本和点击流限制。
● EC2 上的 EMR 增加了运营和计算成本，并且 SQS 并非专为实时流摄取而设计。
● 对于此用例来说，可行，但通常比 Kinesis 更高的运营开销和成本。
工作流：Kinesis Data Streams + Apache Flink 托管服务 + Firehose 到 S3 + Glue + Athena。
IAM 权限不足，无法进行更新 + 在 CloudFormation 外部更改资源
缺少权限可能会在更新或回滚期间阻止资源更改，从而导致 UPDATE_ROLLBACK_FAILED。带外更改会产生偏差，从而阻止 CloudFormation 在回滚期间恢复资源。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：缺少权限可能会在更新或回滚期间阻止资源更改，从而导致 UPDATE_ROLLBACK_FAILED。
● 场景匹配：缺少权限可能会在更新或回滚期间阻止资源更改，从而导致 UPDATE_ROLLBACK_FAILED。带外更改会产生偏差，从而阻止 CloudFormation 在回滚期间恢复资源。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 回滚触发器是可选的，它们的缺失不会导致回滚失败。
● CloudFormation 使用区域公共 API；接口端点不是必需的，并且其不可用不会导致此状态。
● 变更集是可选的规划工具，不使用变更集本身不会导致回滚失败。
工作流：IAM 权限不足，无法进行更新 → 资源在 CloudFormation 外部发生更改。
阶段中操作的运行顺序相同
阶段中共享相同 runOrder 的操作并行运行，从而缩短总体管道时间。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：阶段中共享相同 runOrder 的操作并行运行，从而缩短总体管道时间。
● 场景匹配：阶段中共享相同 runOrder 的操作并行运行，从而缩短总体管道时间。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 构建批次会并行化 CodeBuild 作业，但不会并行化不同的 CodePipeline 操作或单独功能的部署。
● 当 CodePipeline 支持本机并行操作时，外部编排会增加复杂性。
● 缓存可以加快构建速度，但不会使连续的 CodePipeline 操作同时运行。
工作流：为阶段中的操作设置相同的 runOrder。
安排 Lambda 刷新 AWS Trusted Advisor 服务配额检查
Trusted Advisor 提供内置服务配额检查并与 EventBridge 集成，从而可以使用最少的代码实现简单的通知。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Trusted Advisor 提供内置服务配额检查并与 EventBridge 集成，从而可以使用最少的代码实现简单的通知。
● 场景匹配：Trusted Advisor 提供内置服务配额检查并与 EventBridge 集成，从而可以使用最少的代码实现简单的通知。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 需要大量的自定义编码来对每个服务的限制和使用进行建模，这并不是最简单的工作。
● 自定义配置规则仍然需要定制逻辑来发现和评估配额，从而增加了复杂性。
● AWS Health 不提供服务配额监控，并且将 Health 刷新与 Trusted Advisor 事件混合使用是无效的。
工作流：安排 Lambda 使用 EventBridge 刷新 AWS Trusted Advisor 服务配额检查，并添加另一个与 Trusted Advisor 限制事件匹配的 EventBridge 规则并发布到运营经理订阅的 SNS 主题。
Lambda AppSpec 中的 BeforeAllowTraffic 挂钩
运行预流量检查并阻止别名转移，直到确认准备就绪为止。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：运行预流量检查并阻止别名转移，直到确认准备就绪为止。
● 场景匹配：运行预流量检查并阻止别名转移，直到确认准备就绪为止。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 减少冷启动，但不会控制流量或确保依赖项已准备就绪。
● 限制爆炸半径，但在检查完成之前仍会转移一些流量。
● 在流量已经转移后执行，因此它无法防止初始错误。
工作流：在 Lambda AppSpec 中使用 BeforeAllowTraffic 挂钩。
S3 事件通知配置已从存储桶中删除 +
如果存储桶通知配置被删除，S3 将停止向 Lambda 函数发送事件。如果函数资源策略中没有正确的允许语句，S3 将无法调用 Lambda 函数。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：如果存储桶通知配置被删除，S3 将停止向 Lambda 函数发送事件。
● 场景匹配：如果存储桶通知配置被删除，S3 将停止向 Lambda 函数发送事件。没有正确的。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 打开默认加密不会干扰 S3 事件通知或 Lambda 触发器。
● 对象锁定会影响对象保留和删除行为，但不会阻止事件通知。
● S3 使用函数的基于资源的策略调用 Lambda，因此调用不需要执行角色。
工作流：S3 事件通知配置已从存储桶中删除 → 允许 s3.amazonaws.com 调用它的 Lambda 函数基于资源的策略已被删除。
位于相距至少 900 英里的不同区域的两个 S3 存储桶；桶
这通过存储桶策略强制执行 HTTPS，使用 SSE-S3 进行静态加密，并跨区域使用 CRR。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这通过存储桶策略强制执行 HTTPS，使用 SSE-S3 进行静态加密，并跨区域使用 CRR。
● 场景匹配：这通过存储桶策略强制执行 HTTPS，使用 SSE-S3 进行静态加密，并跨区域使用 CRR。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 未配置复制，因此不会在区域之间复制对象。
● 多区域接入点不复制数据，但仍需要 S3 复制规则。
● IAM 角色无法强制执行 TLS；必须使用 aws:SecureTransport 通过 S3 存储桶策略强制执行仅限 HTTPS。
工作流：两个 S3 存储桶位于相距至少 900 英里的不同区域 → 存储桶策略强制使用 HTTPS → 需要 SSE-S3 → 启用 S3 跨区域复制。
带有加权路由的 Lambda 别名，用于在函数版本之间分配流量
Lambda 别名路由配置支持两个版本之间的加权流量，从而使用相同的 API 端点实现受控金丝雀和升级。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Lambda 别名路由配置支持两个版本之间的加权流量，从而使用相同的 API 端点实现受控金丝雀和升级。
● 场景匹配：Lambda 别名路由配置支持两个版本之间的加权流量，从而能够使用受控金丝雀和升级。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 跨端点拆分 DNS，但需要单独的 API 部署，并且不控制单个别名后面的 Lambda 版本之间的流量。
● Lambda 不支持 $LATEST 的滚动更新，并且 CodeDeploy 通过别名管理版本流量转移，而不是就地更新 $LATEST。
● API Gateway 金丝雀在阶段级别运行，通常需要重复的阶段，这会增加开销，并且不会直接在 Lambda 版本之间转移流量。
工作流：使用加权路由配置 Lambda 别名，以在函数版本之间分配流量。
具有 SQS 和 S3 对象键的 Elastic Beanstalk 工作线程； Worker 中的 cron.yaml
将繁重的工作与 Web 层分离，通过传递 S3 指针来遵守 SQS 大小限制，并在支持的情况下使用 cron.yaml。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：将繁重的工作与 Web 层分离，通过传递 S3 指针来遵守 SQS 大小限制，并在支持的情况下使用 cron.yaml。
● 场景匹配：将繁重的工作与 Web 层分离，通过传递 S3 指针来遵守 SQS 大小限制，并在支持的情况下使用 cron.yaml。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 大型、受 CPU 限制的解析可能会超出 Lambda 时间和内存限制，并且对于长时间运行的工作负载来说不太可控。
● 可行，但会增加迁移复杂性，并且当 Beanstalk 工作层已经提供所需模式时是不必要的。
● Cron.yaml 是一个工作层功能；在 Web 层上运行它不受支持且不可靠。
工作流：具有 SQS 和 S3 对象键的 Elastic Beanstalk 工作线程 → 电子邮件工作线程中的 cron.yaml。
使用 Export/ImportValue 和单独的版本控制对每个域进行解耦堆栈
具有跨堆栈导出/导入功能的独立域堆栈可遵循最佳实践实现独立部署和安全依赖管理。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：具有跨堆栈导出/导入功能的独立域堆栈可遵循最佳实践实现独立部署和安全依赖管理。
● 场景匹配：具有跨堆栈导出/导入功能的独立域堆栈可遵循最佳实践实现独立部署和安全依赖管理。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 嵌套堆栈耦合生命周期；父级更新增加了协调性和爆炸半径。
● StackSets 的目标是多账户/区域部署，但仍然集中节奏，并且没有简化细粒度的堆栈间依赖关系。
● 整体式架构耦合了所有资源，增加了爆炸半径，并阻止了独立的发布。
工作流：使用 Export/ImportValue 和单独的版本控制来解耦每个域的堆栈。
EventBridge 规则和 Lambda 通过支持 API 刷新 Trusted Advisor
安排更新 Trusted Advisor 检查并将结果发送到 SNS 可提供及时的警报。托管或自定义 AWS Config 规则可以检测开放的 SSH。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：安排更新 Trusted Advisor 检查并将结果发送到 SNS 可提供及时的警报。
● 场景匹配：安排更新 Trusted Advisor 检查并将结果发送到 SNS 可提供及时的警报。托管或。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● AWS Config 本机修复使用 AWS Systems Manager Automation Runbook，而不是直接 Lambda 调用。
● GuardDuty 检测威胁，而不是安全组中的配置偏差，并且不会自动修复 SG 规则。
● Security Hub 不会获取 Trusted Advisor 结果，也不会本机触发基于 TA 的修复。
工作流：EventBridge 规则和 Lambda 每 10 分钟通过支持 API 刷新 Trusted Advisor 并发布到 SNS → AWS Config 规则标记端口 22 对 0.0.0.0/0 打开的 SG 并发出通知。
发布新版本并将别名权重设置为 20%
加权别名本身会在版本之间转移一定比例的流量，并允许即时回滚而无需客户端更改。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：加权别名本身会在版本之间转移一定比例的流量，并允许即时回滚而无需客户端更改。
● 场景匹配：加权别名本身会在版本之间转移一定比例的流量，并允许即时回滚而无需客户端更改。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 添加API网关并需要客户端/API更改；直接 Lambda 别名流量转移不需要。
● 有效，但引入了额外的设置和管理；对于这个简单的加权转变来说，这并不是最低的运营开销。
● Route 53 对 DNS 流量进行加权，不能对直接 Lambda 调用进行加权。
工作流：发布新版本，并将新版本的别名权重设置为 20%。
使用 CloudFront 和 AWS WAF Web ACL 的 S3 静态托管
S3 提供无服务器静态托管，CloudFront 在全球范围内加速，AWS WAF 可以缓解常见的 Web 漏洞。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：S3 提供无服务器静态托管，CloudFront 在全球范围内加速，AWS WAF 可以缓解常见的 Web 漏洞。
● 场景匹配：S3 提供无服务器静态托管，CloudFront 在全球范围内加速，AWS WAF 可以缓解常见的 Web 漏洞。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 为静态资产引入不必要的计算，GuardDuty 可以检测威胁，但不会阻止 Web 攻击。
● 提供 CDN 和静态托管，但缺乏用于常见 Web 漏洞缓解的 AWS WAF； Shield Standard 仅专注于 DDoS。
● 不是无服务器，静态站点交付不需要 Redis，并且 Shield Advanced 的目标是 DDoS 而不是一般的 Web 攻击。
工作流：使用 CloudFront 和 AWS WAF Web ACL 的 S3 静态托管。
Amazon EFS 复制到跨区域目标
本机 EFS 复制异步维护另一个区域中的副本，无需 VPC 连接，支持低 RPO 和快速故障转移。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：本机 EFS 复制异步维护另一个区域中的副本，无需 VPC 连接，支持低 RPO 和快速故障转移。
● 场景匹配：本机 EFS 复制异步维护另一个区域中的副本，无需 VPC 连接，支持低 RPO 和快速故障转移。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● DataSync 需要到两个位置的网络连接，并且通常通过已建立的网络路径运行计划的或连续的任务。
● 备份提供必须恢复的时间点副本，从而导致更高的 RPO 和 RTO，而不是热备用。
● 对象复制和基于 Lambda 的副本不支持文件系统，会增加复杂性和延迟，从而破坏 RPO/RTO 和 POSIX 保真度。
工作流：启用 Amazon EFS 复制到跨区域目标。
Route 53 基于延迟的路由到带有运行状况检查的区域 API 网关；区域内
基于延迟的路由将客户端发送到最低延迟的端点，并且运行状况检查支持自动故障转移； DynamoDB 全局表支持主动-主动数据。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：基于延迟的路由将客户端发送到最低延迟的端点，并且运行状况检查支持自动故障转移； DynamoDB 全局表支持主动-主动数据。
● 场景匹配：基于延迟的路由将客户端发送到最低延迟的端点，并且运行状况检查支持自动故障转移； DynamoDB 全局表支持主动-主动数据。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 地理定位根据用户位置进行路由，而不是测量延迟，因此它可能不会选择最快的区域。
● CloudFront 可以缓存并提高 TLS/边缘覆盖范围，但单个源不提供多区域延迟控制。
● 故障转移是主动-被动的，以实现弹性，而不是将请求分发到最低延迟的区域。
工作流：通过运行状况检查将基于延迟的 Route 53 路由到区域 API 网关 → 区域内 Lambda → DynamoDB 全局表。
VPC 中 Systems Manager、SSMMessages 和 EC2Messages 的接口 VPC 终端节点
接口 VPC 终端节点将 Session Manager 流量保留在 AWS 专用网络上，从而无需遍历 Internet 即可实现专用连接。通过 IAM 实例配置文件授予权限。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：接口 VPC 终端节点将 Session Manager 流量保留在 AWS 专用网络上，从而无需遍历 Internet 即可实现专用连接。
● 场景匹配：接口 VPC 终端节点将 Session Manager 流量保留在 AWS 专用网络上，从而无需遍历即可实现专用连接。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 将长期访问密钥放在实例上是不安全的，并且不是授予 Systems Manager 权限的推荐方法。
● 会话管理器不需要打开 SSH 入站端口，因此允许 TCP 22 是不必要的，并且会削弱安全性。
● 私有会话管理器连接不需要 VPN，因为 PrivateLink VPC 终端节点在 AWS 内处理此问题。
工作流：在 VPC 中为 Systems Manager、SSMMessages 和 EC2Messages 创建接口 VPC 终端节点 → 将具有所需 Systems Manager 权限的 IAM 策略附加到实例的 IAM 角色或实例配置文件。
ALB 背后的并行环境具有新的构建和配置
API Gateway 金丝雀版本允许将一小部分流量路由到新后端，并使回滚像调整或禁用金丝雀一样简单。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：API Gateway 金丝雀版本允许将一小部分流量路由到新后端并进行回滚。
● 场景匹配：API Gateway 金丝雀版本允许将一小部分流量路由到新后端并进行回滚。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 虽然 CodeDeploy 蓝/绿可以减少中断并实现回滚，但它引入了额外的工具、代理和配置，但事实并非如此。
● 翻转 DNS 别名会导致一次性切换，从而影响所有用户，并且不会提供逐步部署。
● API Gateway 无法对 ALB 目标组之间的流量进行加权； API 层的加权流量分割已完成。
工作流：使用新版本在 ALB 后面创建并行环境，并配置 API Gateway 金丝雀版本以向其发送一小部分请求。
所有日志组上的订阅过滤器以流式传输到 Amazon Data Firehose
这使用对 Amazon Data Firehose 的本机 CloudWatch Logs 订阅来近乎实时地传送到 S3，并通过 EventBridge 自动附加新日志组。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这使用 Amazon Data Firehose 的本机 CloudWatch Logs 订阅来近乎实时地交付到 S3 并实现自动化。
● 场景匹配：这使用 Amazon Data Firehose 的本机 CloudWatch Logs 订阅来近乎实时地交付到 S3 并实现自动化。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● CloudWatch Logs 导出是批量、按日志组、有时间限制的作业，并且不会自动覆盖新创建的组或。
● DataSync 不与 CloudWatch Logs 作为源集成，并且适用于文件和对象存储端点。
工作流：在所有日志组上配置订阅筛选器以流式传输到 Amazon Data Firehose，并使用 EventBridge 规则将传输流设置为写入审核账户中的 S3 存储桶。
Lambda 角色权限和 EFS 接入点挂载 + VPC 对等互连
Lambda 需要 VPC 和 elasticfilesystem 权限并通过访问点安装。提供网络可访问性和文件系统策略，允许其他帐户安装和写入。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Lambda 需要 VPC 和 elasticfilesystem 权限并通过访问点安装。
● 场景匹配：Lambda 需要 VPC 和 elasticfilesystem 权限并通过访问点安装。提供网络可访问性和文件系统策略，允许其他帐户安装和写入。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● EFS 不支持 PrivateLink。
● 仅靠网络是不够的；仍然需要 EFS 资源策略。
● SCP 是护栏，不授予对资源的访问权限。
工作流：Lambda 角色权限和 EFS 访问点挂载 → VPC 对等 → EFS 文件系统策略。
Auto Scaling 组背后的应用程序负载均衡器 + Amazon CloudFront
提供到 EC2 目标的第 7 层主机和基于路径的路由，并根据需求经济高效地进行扩展。缓存靠近用户的内容并运行边缘逻辑，以按路径或设备定制行为或源选择，从而减少延迟和源负载。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：提供到 EC2 目标的第 7 层主机和基于路径的路由，并根据需求经济高效地进行扩展。
● 场景匹配：提供到 EC2 目标的第 7 层主机和基于路径的路由，并根据需求经济高效地进行扩展。缓存内容关闭。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 使用任播提高可用性和路由性能，但它不提供基于路径的路由或缓存并增加成本。
● 在 DNS 层运行，用于域、地理位置和基于延迟的决策，而不是按请求的 URL 路径路由。
● 在第 4 层工作，无法检查 HTTP 路径以进行基于内容的路由。
工作流：Auto Scaling 组后面的应用程序负载均衡器 → Amazon CloudFront 和 Lambda@Edge。
构建一个从特定的 GitHub Webhook 触发的 AWS CodePipeline
这遵循 CI/CD 最佳实践，使用 EventBridge 处理管道事件，使用 SNS 处理电子邮件通知，同时通过手动批准来控制 S3 暂存。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这遵循 CI/CD 最佳实践，在门控时使用 EventBridge 进行管道事件，使用 SNS 进行电子邮件通知。
● 场景匹配：这遵循 CI/CD 最佳实践，在门控时使用 EventBridge 进行管道事件，使用 SNS 进行电子邮件通知。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 正确使用EventBridge，但依赖SES进行事件通知，这不如SNS更适合直接、可扩展。
● CloudTrail 捕获 API 审核日志，并非专为实时管道阶段更改检测而设计。
● CloudWatch Logs 需要自定义解析，并且不是 CodePipeline 状态转换的事件源。
工作流：构建一个从特定分支上的 GitHub Webhook 触发的 AWS CodePipeline，其中包含安全扫描、单元和功能测试阶段以及将工件推送到 Amazon 之前的手动批准步骤。
用于会话的 Amazon ElastiCache for Redis（多可用区）
托管、内存中、多可用区 Redis 提供低延迟、共享会话存储，并具有跨实例更改的自动故障转移功能。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：托管、内存中、多可用区 Redis 提供低延迟、共享会话存储，并具有跨实例更改的自动故障转移功能。
● 场景匹配：托管、内存中、多可用区 Redis 提供低延迟、共享会话存储，并具有跨实例更改的自动故障转移功能。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 粘性将客户端绑定到特定实例，并且无法在实例替换后继续存在，从而损害负载分配和可扩展性。
● DynamoDB 可以保留会话，但延迟比内存缓存更高，并且对于频繁的会话读/写效率较低。
● 关系数据库会增加临时会话数据的延迟和开销，并且未针对会话缓存模式进行优化。
工作流：使用 Amazon ElastiCache for Redis (多可用区) 进行会话。
为目录提供 Aurora 全球数据库；将其他表保留在 Aurora 区域
Aurora Global Database 提供低延迟全局读取和快速跨区域复制，同时保留关系模型并最大限度地减少代码更改。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Aurora Global Database 提供低延迟全局读取和快速跨区域复制，同时保留关系模型并最大限度地减少代码更改。
● 场景匹配：Aurora Global Database 提供低延迟全局读取和快速跨区域复制，同时保留关系模型并最大限度地减少代码更改。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 混合 NoSQL 和 SQL 会增加 API 和数据模型更改，从而增加重构工作量。
● 用 NoSQL 替换关系模型需要大量的重新设计和代码更改。
● 全局复制所有表，而不仅仅是目录，这与保留帐户和 view_history 区域冲突。
工作流：为目录配置 Aurora 全局数据库 → 将其他表保留在 Aurora 中。
为 Amazon Aurora MySQL 预置目录的跨区域只读副本
Aurora MySQL 与 MySQL 兼容，可实现最少的代码更改，支持跨区域只读副本以实现低延迟目录读取，并且单独的每区域集群可保留订单数据以确保合规性。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Aurora MySQL 与 MySQL 兼容，可实现最少的代码更改，支持跨区域只读副本以实现低延迟目录读取，并且是独立的。
● 场景匹配：Aurora MySQL 与 MySQL 兼容，可实现最少的代码更改，支持跨区域只读副本以实现低延迟目录读取，并且是独立的。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 需要从关系模型迁移到 NoSQL 键值存储，这通常需要大量的架构和代码。
● 虽然可行且相关，但与 Aurora 的全局读取相比，这会带来更高的副本延迟和更多的操作开销。
● 全局表将跨区域复制订单数据，这违反了在每个区域内保留订单的要求。
工作流：为 Amazon Aurora MySQL 预置目录的跨区域只读副本，并为每个区域中的订单数据预置独立的 Aurora 集群。
具有 Git 存储库作为编排源的 AWS CodePipeline
CodePipeline 提供端到端编排、阶段级可见性，并与自动故障处理和回滚集成。 CodeDeploy 中的 BeforeInstall 挂钩是清除缓存的正确位置。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CodePipeline 提供端到端编排、阶段级可见性，并与自动故障处理和回滚集成。
● 场景匹配：CodePipeline 提供端到端编排、阶段级可见性，并与自动故障处理和回滚集成。 BeforeInstall 挂钩。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Systems Manager 不是用于应用程序部署的主要 AWS 服务，并且缺少 CodeDeploy 生命周期挂钩和本机回滚。
● EventBridge 加上 Lambda 可以构建工件，但不提供完整的管道编排、批准或部署跟踪。
● EC2 用户数据仅在首次启动时运行，无法可靠地处理重复的部署步骤或托管回滚。
工作流：使用 Git 存储库创建 AWS CodePipeline 作为编排构建和部署阶段的源 → 将缓存清除脚本添加到部署的 AppSpec BeforeInstall 生命周期挂钩 →。
在所有本地服务器和 EC2 实例上安装统一的 CloudWatch 代理
这样可以以最少的操作集中混合日志收集，使用低成本的 S3 存储，并通过 Athena 实现无服务器分析。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这样可以以最少的操作集中混合日志收集，使用低成本的 S3 存储，并通过 Athena 实现无服务器分析。
● 场景匹配：这样可以以最少的操作集中混合日志收集，使用低成本的 S3 存储，并通过 Athena 实现无服务器分析。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 缺少本地服务器，依赖于无法扩展的手动导出，并会通过 EMR 产生运营开销。
● 与托管的无服务器替代方案相比，自托管存储和 ELK 增加了成本和工作量。
● 虽然可行，但与审计式查询的 S3 加 Athena 相比，配置和运行 OpenSearch 会增加成本和管理。
工作流：在所有本地服务器和 EC2 实例上安装统一的 CloudWatch 代理，以将日志发送到 CloudWatch Logs → 将日志组订阅到 Kinesis Data Firehose，传送到中央 Amazon。
登录源的 CloudFront 源故障转移 + Lambda@Edge 身份验证
配置辅助源自动在 5xx（包括 504）上提供服务，以低成本提高可用性。在用户附近执行身份验证逻辑，以减少往返并减少源上的负载。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：配置辅助源自动在 5xx（包括 504）上提供服务，以低成本提高可用性。
● 场景匹配：配置辅助源自动在 5xx（包括 504）上提供服务，以低成本提高可用性。在用户附近执行身份验证逻辑，以减少往返并减少源上的负载。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 改进了网络路径，但增加了成本，并且在身份验证时无法解析原始 5xx。
● 多区域部署可减少延迟，但对于身份验证状态而言既复杂又昂贵。
● 优化静态内容的缓存命中，但不会加速动态登录或防止 504。
工作流：登录源的 CloudFront 源故障转移 → 边缘的 Lambda@Edge 身份验证。
一个新的 DynamoDB 表，其中包含 DocTitle 上的本地二级索引
本地二级索引共享分区键并提供备用排序键以支持强一致性读取，但它们必须使用.
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：本地二级索引共享分区键并提供备用排序键以支持强一致性读取，但它们必须与表一起创建，因此需要迁移。
● 场景匹配：本地二级索引共享分区键并提供备用排序键并支持强一致性。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 您无法将本地二级索引添加到现有表，因为必须在创建表时定义 LSI。
● 全球二级索引不支持要求强制要求的强一致性读取。
● 基于流的复制是异步的，无法保证最新更新所需的即时强一致性。
工作流：创建一个新的 DynamoDB 表，其中包含带有新排序键的 DocTitle 上的本地二级索引，→ 迁移现有数据。
VM 导入/导出：将 VMware VM 导入 AMI，在 EC2 上验证，导出为
支持将 VMware 虚拟机导入为 AMI，并将之前导入的实例导出为 OVA 以进行 vSphere 测试。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：支持将 VMware 虚拟机导入为 AMI，并将之前导入的实例导出为 OVA 以进行 vSphere 测试。
● 场景匹配：支持将 VMware 虚拟机导入为 AMI，并将之前导入的实例导出为 OVA 以进行 vSphere 测试。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 在 AWS 上构建和测试 AMI，但不会将映像导出回 VMware 以进行本地奇偶校验。
● AWS 不为 Amazon Linux 2 提供裸机 ISO，这并不反映 EC2 行为。
● 在本地部署 AWS 硬件，但成本高昂且对于简单的映像验证来说是不必要的，并且不提供虚拟机往返。
工作流：VM 导入/导出：将 VMware VM 导入 AMI → 在 EC2 上验证，作为 OVA 导出到 vSphere。
CloudWatch 代理 -> CloudWatch 日志； Kinesis Data Firehose 的跨账户订阅 ->
这将所有日志流式传输到单个低成本 S3 数据湖中，并具有跨帐户和本地的无服务器丰富和即席 SQL。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这将所有日志流式传输到单个低成本 S3 数据湖中，并具有跨帐户和本地的无服务器丰富和即席 SQL。
● 场景匹配：这将所有日志流式传输到单个低成本 S3 数据湖中，并具有跨帐户和本地的无服务器丰富和即席 SQL。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Kinesis Data Analytics 需要流式输入，并且无法直接查询 S3 中的静态数据。
● 按帐户存储数据并防止出现单一、集中的分析位置。
● OpenSearch 不是成本最低的长期存储，并且不通过 Athena 提供基于 S3 的即席 SQL 查询。
工作流：CloudWatch 代理 -> CloudWatch Logs → Kinesis Data Firehose 的跨账户订阅 -> 中央 S3（日志记录账户）→ Lambda 标记 → 使用 Athena 查询。
使用 Lambda 进行 AppSpec AfterAllowTestTraffic
用于在启用测试流量后运行验证，允许在生产切换之前回滚。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：用于在启用测试流量后运行验证，允许在生产切换之前回滚。
● 场景匹配：用于在启用测试流量后运行验证，允许在生产切换之前回滚。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 在路由任何测试流量之前运行，因此无法使用测试侦听器进行验证。
● 事件会改变测试流量，但发生在验证运行之前。
● 在测试验证应该已经完成之后、生产流量转移之前发生。
工作流：使用 Lambda 的 AppSpec AfterAllowTestTraffic。
使用生命周期挂钩自动缩放暖池
温池保留预先初始化的实例以实现快速横向扩展，并且生命周期挂钩 InService，直到应用程序准备就绪。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：温池保留预先初始化的实例以实现快速横向扩展，并且生命周期挂钩 InService，直到应用程序准备就绪。
● 场景匹配：温池保留预先初始化的实例以实现快速横向扩展，并且生命周期挂钩 InService，直到应用程序准备就绪。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 提前预扩展会过度配置容量并增加成本，而无法解决就绪门控问题。
● 计划操作可以在已知时间增加容量，但不能确保实例仅在应用程序引导完成后提供流量。
● 维持额外的始终在线容量成本高昂，并且会增加运营开销。
工作流：使用生命周期挂钩自动缩放暖池。
使用每 120 秒聚合一次的统计数据集发布自定义 CloudWatch 指标
统计集每 120 秒将许多 10 秒样本汇总到一次 PutMetricData 调用中，从而以更低的成本实现标准分辨率警报。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：统计集每 120 秒将许多 10 秒样本汇总到一次 PutMetricData 调用中，从而以更低的成本实现标准分辨率警报。
● 场景匹配：统计集每 120 秒将许多 10 秒样本汇总到一次 PutMetricData 调用中，从而以更低的成本实现标准分辨率警报。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 在外部运行金丝雀并增加成本；它不直接使用实例的探测输出来进行低成本聚合。
● 高分辨率指标和频繁发布会增加成本，并且在 2 分钟粒度可以接受时是不必要的。
● 可能，但与直接发布聚合的自定义指标相比，会增加日志摄取和过滤成本以及复杂性。
工作流：使用每 120 秒聚合一次的统计数据集发布自定义 CloudWatch 指标。
AWS Elastic Beanstalk（负载均衡、自动扩展）与 Amazon RDS for MySQL
Elastic Beanstalk 支持滚动和蓝/绿部署，并且可以轻松回滚，并且可以共享外部 RDS 并与应用程序生命周期解耦。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Elastic Beanstalk 支持滚动和蓝/绿部署，并且可以轻松回滚，并且可以共享外部 RDS 并与应用程序生命周期解耦。
● 场景匹配：Elastic Beanstalk 支持滚动和蓝/绿部署，并且可以轻松回滚，并且可以共享外部 RDS 并与应用程序生命周期解耦。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 支持滚动更新，但简化的回滚通常需要额外的部署工具和协调。
● 提供零停机和回滚，但比托管 PaaS 增加了更多操作复杂性。
● 将数据库生命周期与应用程序环境耦合起来，并在环境拆除期间面临删除风险；分享更难。
工作流：AWS Elastic Beanstalk（负载均衡、自动扩展）以及在环境外部创建的 Amazon RDS for MySQL。
在 EBS 支持的 Amazon EC2 上重新托管 Oracle RAC 数据库，安装 SSM
支持在 EC2 上运行 RAC，补丁管理器可自动进行操作系统修补，DLM 通过最少的设置提供计划的 EBS 快照。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：支持在 EC2 上运行 RAC，补丁管理器可自动进行操作系统修补，DLM 提供计划的 EBS 快照。
● 场景匹配：支持在 EC2 上运行 RAC，补丁管理器可自动进行操作系统修补，DLM 提供计划的 EBS 快照。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Aurora 不支持 Oracle RAC，因此即使它自动执行备份和修补，也不能满足迁移要求。
● 使用 Lambda 进行快照比 DLM 更重，并且 CodeDeploy/CodePipeline 是 CI/CD 工具而不是补丁自动化服务。
● RDS for Oracle 不支持 Oracle RAC，因此该选项无法满足 RAC 迁移需求。
工作流：在 EBS 支持的 Amazon EC2 上重新托管 Oracle RAC 数据库 → 安装 SSM 代理 → 使用 AWS Systems Manager Patch Manager 获取操作系统补丁，并配置 Amazon Data Lifecycle Manager 来安排 EBS 快照。
UpdatePolicy：AutoScalingReplacingUpdate 且 WillReplace true
WillReplace true 的替换更新会在旧组旁边创建一个新的 Auto Scaling 组，保留容量并允许在需要时立即回滚。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：WillReplace true 的替换更新会在旧组旁边创建一个新的 Auto Scaling 组，保留容量并允许在需要时立即回滚。
● 场景匹配：WillReplace true 的替换更新会在旧组旁边创建一个新的 Auto Scaling 组，保留容量并允许在需要时立即回滚。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 滚动更新批量替换实例，这会减少可用容量，并且不提供即时回滚到前一组的功能。
● CodeDeploy 蓝/绿是一种部署策略，而不是 Auto Scaling 组的 CloudFormation UpdatePolicy。
● WillReplace false 使用滚动或就地行为，并且不会创建并行组来保留完整容量或启用即时回滚。
工作流：UpdatePolicy：AutoScalingReplacingUpdate 且 WillReplace 为 true。
具有环境交换功能的 Elastic Beanstalk
Elastic Beanstalk 通过克隆环境并执行托管流量重定向的 CNAME 交换来支持蓝/绿。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Elastic Beanstalk 通过克隆环境并执行托管流量重定向的 CNAME 交换来支持蓝/绿。
● 场景匹配：Elastic Beanstalk 通过克隆环境并执行托管流量重定向的 CNAME 交换来支持蓝/绿。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 实例刷新执行滚动替换，不会维护两个并行环境以进行流量转移。
● ECS 滚动更新会替换现有的任务，并且在没有额外工具的情况下本身不提供并行环境流量交换。
● App Runner 简化了部署，但不提供具有并行堆栈和受控流量交换的环境级蓝/绿。
工作流：具有环境交换功能的 Elastic Beanstalk。
CodeBuild 中的单元和功能测试以及失败时的块升级 +
CodeBuild 可以执行自动化测试套件，如果测试未通过，则管道门将失败。通过手动批准的分阶段部署可以进行实际验证，并防止错误的版本进入生产环境。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CodeBuild 可以执行自动化测试套件，如果测试未通过，则管道门将失败。
● 场景匹配：CodeBuild 可以执行自动化测试套件，如果测试未通过，则管道门将失败。通过手动批准的分阶段部署可以进行实际验证并防止错误的版本进入生产环境。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● GuardDuty 用于威胁检测，并不验证应用程序功能。
● Inspector 重点关注漏洞和暴露，而不是功能正确性。
● AWS Config 评估资源配置合规性，而不是应用程序功能行为。
工作流：在 CodeBuild 中运行单元和功能测试，并在失败时阻止升级 → 使用 CodeDeploy 部署到某个阶段 → 添加手动审批门 → 部署到生产环境。
CloudWatch 指标流式传输到 Kinesis Data Firehose，传送到 S3，并使用以下命令进行查询
指标流本身通过 Firehose 将指标传送到 S3，无需自定义代码，从而实现持久的多年存储、Athena 查询和 QuickSight 仪表板。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：指标流本身通过 Firehose 将指标传送到 S3，无需自定义代码，从而实现持久的多年存储、Athena 查询和 QuickSight 仪表板。
● 场景匹配：指标流本身通过 Firehose 将指标传送到 S3，无需自定义代码，从而实现持久的多年存储、Athena 查询和 QuickSight 仪表板。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 需要自定义代码、调度和维护，这比本机流解决方案需要更多工作量。
● CloudWatch 指标最多保留 15 个月左右，不满足 10 年的要求。
● CloudWatch 仪表板无法从 S3 读取数据，因此无法从导出的文件构建仪表板。
工作流：使用 CloudWatch 指标流将 Kinesis Data Firehose 传送到 S3 → 使用 Athena 进行查询，并在 QuickSight 中进行可视化。
适用于 Prometheus 的 Amazon Managed Service 以及 Amazon Managed Grafana
Amazon Managed Service for Prometheus 通过远程写入从 EKS、ECS 和本地 Kubernetes 获取 Prometheus 指标，Amazon Managed Grafana 提供托管仪表板、查询和警报。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Amazon Managed Service for Prometheus 通过远程写入从 EKS、ECS 和本地 Kubernetes 获取 Prometheus 指标，Amazon Managed Grafana 提供托管仪表板、查询和警报。
● 场景匹配：Amazon Managed Service for Prometheus 通过远程写入从 EKS、ECS 和本地 Kubernetes 获取 Prometheus 指标。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● CloudWatch 代理和 Athena/QuickSight 不是 Prometheus 原生的，并且不提供跨集群的内聚 Prometheus 抓取和远程写入后端。
● SSM 代理不会抓取 Prometheus 指标，并且 Amazon Managed Service for Prometheus 也不是可视化工具。
● 适用于 CloudWatch 中的 EKS/ECS 指标，但它不是 Prometheus 远程写入后端，并且不能跨环境统一本机 Prometheus 指标。
工作流：Prometheus 的 Amazon 托管服务 → Amazon 托管的 Grafana。
ACM 向 ALB 上的 HTTPS 侦听器颁发的证书以进行卸载
将证书放在 ALB 上会终止负载均衡器上的 TLS，从而保护客户端连接，同时从实例中卸载加密。可以附加AWS WAF。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：将证书放在 ALB 上会终止负载均衡器上的 TLS，从而在卸载加密的同时保护客户端连接。
● 场景匹配：将证书放在 ALB 上会终止负载均衡器上的 TLS，从而在卸载加密的同时保护客户端连接。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 在每个实例上终止 TLS 会消耗主机上的 CPU，并且与避免影响实例性能的要求相冲突。
● EBS 加密可保护卷上的静态数据，并且不会加密传输中的网络流量。
● Shield Advanced 主要缓解 DDoS 攻击，并非旨在过滤 SQL 注入或 XSS 等常见应用程序层攻击。
工作流：将 ACM 颁发的证书附加到 ALB 上的 HTTPS 侦听器以卸载 TLS → 使用托管规则创建 AWS WAF Web ACL 并将其关联到 ALB。
CloudTrail sts 上的 EventBridge 规则：角色的 AssumeRole，调用 Lambda 到 SNS
通过 CloudTrail 事件筛选具有角色 ARN 的 sts:AssumeRole 的 AWS API 调用，并触发 Lambda 发布到 SNS 以获取即时警报。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：通过 CloudTrail 事件筛选具有角色 ARN 的 sts:AssumeRole 的 AWS API 调用，并触发 Lambda 发布到 SNS 以获取即时警报。
● 场景匹配：通过 CloudTrail 事件筛选具有角色 ARN 的 sts:AssumeRole 的 AWS API 调用，并触发 Lambda 发布到 SNS 以获取即时警报。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● CloudTrail Insights 检测异常，而不是给定角色的每个特定 sts:AssumeRole 事件。
● 控制台登录事件不会捕获 STS 角色假设，因此会错过许多角色使用。
● CloudTrail Lake 依赖于计划查询，并且对于每个事件的警报来说不是实时的。
工作流：CloudTrail sts 上的 EventBridge 规则：角色的 AssumeRole → 调用 Lambda 到 SNS。
与 AWS Health 中的 AWS_RISK_CREDENTIALS_EXPOSED 匹配的 Amazon EventBridge 规则并启动
AWS Health 发出暴露事件，Step Functions 跨 IAM、CloudTrail 和通知提供可审核、可靠的编排。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：AWS Health 发出暴露事件，Step Functions 跨 IAM、CloudTrail 和通知提供可审核、可靠的编排。
● 场景匹配：AWS Health 发出暴露事件，Step Functions 跨 IAM、CloudTrail 和通知提供可审核、可靠的编排。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 将规则指向 CloudTrail，但暴露警报是由 AWS Health 生成的，因此事件模式也会如此。
● 单个 Lambda 可以执行操作，但它缺乏本机长时间运行的编排、重试和详细的有状态执行历史记录。
● Security Hub 不会发起 AWS_RISK_CREDENTIALS_EXPOSED 事件，并且单独的 SSM Runbook 不会解决特定的 AWS。
工作流：创建与 AWS Health 中的 AWS_RISK_CREDENTIALS_EXPOSED 匹配的 Amazon EventBridge 规则，并启动协调 IAM、CloudTrail 和 Amazon SNS 的 AWS Step Functions 状态机。
发布新版本并更新现有的 prod 别名以进行路由
加权别名可实现金丝雀发布和快速回滚，而无需修改 EC2 应用程序。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：加权别名可实现金丝雀发布和快速回滚，而无需修改 EC2 应用程序。
● 场景匹配：加权别名可实现金丝雀发布和快速回滚，而无需修改 EC2 应用程序。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 引入新组件并需要客户端更改，这对于直接 Lambda 金丝雀发布来说是不必要的。
● Route 53 无法对本机 Lambda 调用进行加权，这种方法增加了可避免的操作复杂性。
● 层是依赖包和别名路由到函数版本，而不是层。
工作流：发布新版本并更新现有的产品别名，将 15% 的流量路由到新版本，将 85% 的流量路由到当前版本。
在 AWS Service Catalog 中发布经过审核的 CloudFormation 产品
服务目录允许您提供由批准的模板支持的版本化产品，并应用约束来强制执行参数、标签和区域分发。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：服务目录允许您提供由批准的模板支持的版本化产品，并应用约束来强制执行参数、标签和区域分发。
● 场景匹配：服务目录允许您提供由批准的模板支持的版本化产品，并应用约束来强制执行参数、标签和区域分发。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● StackSets 协调跨帐户和区域的部署，但本质上并不强制执行强制标签或限制开发人员可以启动堆栈的位置。
● Trusted Advisor 提供最佳实践检查，但无法阻止或管理 CloudFormation 使用、标签策略或区域限制。
● 偏差检测是一种部署后检查，无法从一开始就阻止创建不合策略的资源。
工作流：在 AWS Service Catalog 中发布经过审查的 CloudFormation 产品。
Amazon DynamoDB 全局表
DynamoDB 全局表提供多区域、多主动复制，因此每个区域都可以执行本地低延迟读取和写入，并在全球范围内复制数据。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：DynamoDB 全局表提供多区域、多主动复制，因此每个区域都可以执行本地低延迟读取和写入，并在全球范围内复制数据。
● 场景匹配：DynamoDB 全局表提供多区域、多主动复制，因此每个区域都可以执行本地低延迟读取和写入，并在全球范围内复制数据。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● DAX 是 DynamoDB 的内存缓存，可改善区域内的读取延迟，但不提供多区域、多活动写入或复制。
● Aurora Global Database 使用单个写入区域和跨区域读取副本，因此它不是多活写入。
● RDS跨Region只读副本是只读的；所有写入都转到单个主要区域，从而增加其他地方的写入延迟。
工作流：Amazon DynamoDB 全局表。
具有complianceType NON_COMPLIANT 的restricted-ssh 的EventBridge 规则，使用输入转换器
EventBridge 可以匹配准确的配置规则和合规性状态，然后格式化 SNS 事件中已存在的字段。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：EventBridge 可以匹配准确的配置规则和合规性状态，然后格式化 SNS 事件中已存在的字段。
● 场景匹配：EventBridge 可以匹配准确的配置规则和合规性状态，然后格式化 SNS 事件中已存在的字段。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 事件模式太宽泛，SNS 过滤是在订阅上配置的，而不是在主题级别上配置的。
● 在技术上是可行的，如果需要外部查找数据，可能需要，但问题只需要事件字段格式。
● 向下游发送合规和不合规事件并依赖于后续过滤。
工作流：使用complianceType NON_COMPLIANT 为restricted-ssh 创建EventBridge 规则 → 使用输入转换器添加组名称和ID，然后发布到SNS。
与 CRITICAL 匹配的 CloudWatch Logs 指标过滤器，发出自定义指标
CloudWatch Logs 指标过滤器将匹配的日志行转换为自定义指标，CloudWatch 警报可以通过 SNS 监控并通知团队。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudWatch Logs 指标过滤器将匹配的日志行转换为自定义指标，CloudWatch 警报可以实现这一点。
● 场景匹配：CloudWatch Logs 指标过滤器将匹配的日志行转换为自定义指标，CloudWatch 警报可以实现这一点。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Transit Gateway 流日志捕获中转网关的 IP 流信息，而不是防火墙设备的日志条目。
● 如果没有订阅过滤器或指标等中介，EventBridge 不会直接检查原始 CloudWatch Logs 内容。
工作流：创建与 CRITICAL 匹配的 CloudWatch Logs 指标过滤器 → 发出自定义指标，并配置 CloudWatch 警报以发布到安全团队订阅的 Amazon SNS 主题。
AWS CodePipeline 通过 Amazon EventBridge 触发的 AWS Systems Manager Automation Runbook
它使用托管服务来自动创建 AMI 并以最小的成本和开销集中存储标识符。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：它使用托管服务来自动创建 AMI 并以最小的成本和开销集中存储标识符。
● 场景匹配：它使用托管服务来自动创建 AMI 并以最小的成本和开销集中存储标识符。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 通过在 EC2 上运行 Jenkins 并维护 DynamoDB 进行简单查找，增加了成本和管理开销。
● 当本机 AMI 自动化可用时，OVF 处理和 EC2 构建主机会增加不必要的复杂性。
● 该方法有许多移动部件，并将元数据存储在 S3 中，而不是为配置值设计的参数存储。
工作流：使用 AWS CodePipeline 通过 Amazon EventBridge 触发的 AWS Systems Manager Automation Runbook 来烘焙 AMI 并将 AMI ID 发布到 Systems Manager Parameter Store。
具有跨区域 RDS 只读副本、最小应用程序的另一个区域的指示灯
异步 RDS 复制支持分钟级 RPO，并保持大部分计算关闭，从而最大限度地降低成本，同时满足小时级 RTO。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：异步 RDS 复制支持分钟级 RPO，并且保持大部分计算关闭可最大限度地降低成本，同时满足小时级 RTO。
● 场景匹配：异步 RDS 复制支持分钟级 RPO，并保持大部分计算关闭，从而最大限度地降低成本，同时满足小时级 RTO。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 快照复制和完整环境重建通常会错过 15 分钟的 RPO，并且可能会超过 3 小时的 RTO。
● 满足 RTO，但成本超出规定的预算限制所需。
● 可以防止可用区故障，但不能防止区域灾难，并且不满足跨区域灾难恢复要求。
工作流：在另一个区域中使用跨区域 RDS 只读副本、最小应用程序堆栈进行试点 → Route 53 故障转移，并在发生灾难时提升副本。
直接针对 EBS 创建快照的 Amazon EventBridge 计划规则
EventBridge可以按计划调用内置的EBS创建快照目标，提供最直接、最小配置的解决方案。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：EventBridge可以按计划调用内置的EBS创建快照目标，提供最直接、最小配置的解决方案。
● 场景匹配：EventBridge可以按计划调用内置的EBS创建快照目标，提供最直接、最小配置的解决方案。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 该方法有效，但添加了额外的 Systems Manager 步骤，而不是使用本机 EventBridge EBS 目标。
● AWS Backup 可以做到这一点，但需要额外的构造，例如备份计划和保管库，这比单个 EventBridge 规则更繁重。
● 添加代码、打包和 IAM 权限管理，使其比直接的 EventBridge EBS 目标更加复杂。
工作流：创建一个 Amazon EventBridge 计划规则，该规则直接针对在 UTC 凌晨 1:00 为指定卷 ID 创建快照。
Inspector，跨 ALB、Aurora、Route 53 后面四个可用区的 EC2 Auto Scaling
Inspector 提供持续的漏洞和暴露扫描；多可用区 ALB 加上别名顶点记录可提供 HA 和正确的根域映射。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Inspector 提供持续的漏洞和暴露扫描；多可用区 ALB 加上别名顶点记录可提供 HA 和正确的根域映射。
● 场景匹配：Inspector 提供持续的漏洞和暴露扫描；多可用区 ALB 加上别名顶点记录可提供 HA 和正确的根域映射。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● GuardDuty 是威胁检测，而不是漏洞扫描，并且 CNAME 不能在 ALB 的区域顶端使用。
● Security Hub 汇总并关联发现结果，但不执行漏洞扫描。
● Macie 专注于敏感数据发现，非别名 A 记录无法针对顶点的 ALB。
工作流：Inspector、EC2 Auto Scaling 跨 ALB、Aurora 后面的四个可用区 → ALB 的 Route 53 别名顶点。
CodePipeline 阶段通过分配来同时运行每个函数的操作
对一个阶段中的多个操作使用相同的 runOrder 可以使它们并行运行，从而减少总管道挂钟时间。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：对一个阶段中的多个操作使用相同的 runOrder 可以使它们并行运行，从而减少总管道挂钟时间。
● 场景匹配：对一个阶段中的多个操作使用相同的 runOrder 可以使它们并行运行，从而减少总管道挂钟时间。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Docker 层缓存可以加速容器映像重建，但不会使连续的 CodePipeline 操作并行执行。
● 较大的构建实例可能会加快单个构建的速度，但管道仍然跨函数串行完成。
● 尽管本机并行操作已经解决了问题，但在 CodePipeline 之外增加了额外的编排复杂性。
工作流：通过分配相同的 runOrder 值，将 CodePipeline 阶段配置为同时运行每个函数的操作。
组织 SCP 拒绝 iam:CreateUser，但通过 aws:PrincipalArn 条件批准的委托人除外
在 iam:CreateUser 上明确拒绝且仅允许列出的调用者 ARN 的 SCP 会强制实施预防性的组织范围控制。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：在 iam:CreateUser 上明确拒绝且仅允许列出的调用者 ARN 的 SCP 会强制实施预防性的组织范围控制。
● 场景匹配：在 iam:CreateUser 上明确拒绝且仅允许列出的调用者 ARN 的 SCP 会强制实施预防性的组织范围控制。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 本地 IAM 策略可由账户管理员修改，不限制根用户，并且不能保证作为组织范围的预防控制。
● 是反应性的，无法阻止 CreateUser API 调用成功。
● CreateLoginProfile 管理控制台密码，并且不会阻止创建 IAM 用户。
工作流：组织 SCP 拒绝 iam:CreateUser，但通过 aws:PrincipalArn 条件批准的委托人除外。
Elastic Beanstalk 中的不可变更新
使用新版本启动并行 Auto Scaling 组，保持现有实例服务，并在运行状况不佳时通过终止新组来实现快速回滚。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：使用新版本启动并行 Auto Scaling 组，保持现有实例服务，并在运行状况不佳时通过终止新组来实现快速回滚。
● 场景匹配：使用新版本启动并行 Auto Scaling 组，保持现有实例服务，并在运行状况不佳时通过终止新组来实现快速回滚。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 仍然是就地更新，可能会在推出过程中失败，并且不会立即回滚到健康的并行队列。
● 蓝/绿通常需要对数据库进行解耦；将 RDS 保持连接到环境会使切换变得复杂或受阻。
● 并非 Elastic Beanstalk 部署策略和就地更新缺乏用于快速回滚的并行队列。
工作流：Elastic Beanstalk 中的不可变更新。
一个终止生命周期钩子，用于将实例放置在 Terminate:Wait 中，创建一个 EventBridge
将 Terminate:Wait 与 EventBridge 和 SSM Automation 结合使用可确保在实例最终终止之前控制延迟将日志刷新到 CloudWatch Logs。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：将 Terminate:Wait 与 EventBridge 和 SSM Automation 结合使用可确保在将日志刷新到 CloudWatch Logs 之前控制延迟。
● 场景匹配：将 Terminate:Wait 与 EventBridge 和 SSM Automation 结合使用可确保在将日志刷新到 CloudWatch Logs 之前控制延迟。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 可以流式传输日志，但不保证在由运行状况检查触发立即终止之前最终刷新日志，因此日志。
● Pending:Wait 适用于启动事件，而不是缩减或终止，因此这并不能解决终止计时问题。
● 删除实例后终止成功会触发，因此从实例中检索日志为时已晚。
工作流：添加终止生命周期挂钩以将实例置于 Terminate:Wait → 为 EC2 实例终止生命周期操作创建 EventBridge 规则 → 附加 Systems Manager Automation 文档以触发 CloudWatch。
RDS 的秘密管理器； EC2 实例配置文件读取机密并调用 DynamoDB
在 Secrets Manager 中存储并可选择轮换 RDS 凭证，并授予 EC2 角色读取密钥并通过 IAM 访问 DynamoDB 的权限。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：在 Secrets Manager 中存储并可选择轮换 RDS 凭证，并授予 EC2 角色读取密钥并通过 IAM 访问 DynamoDB 的权限。
● 场景匹配：在 Secrets Manager 中存储并可选择轮换 RDS 凭证，并授予 EC2 角色读取密钥并通过 IAM 访问 DynamoDB 的权限。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● DynamoDB 使用 IAM，而不是类似数据库的凭证，因此存储不存在的 DynamoDB 凭证是不正确的。
● Parameter Store 缺乏 RDS 的本机轮换，并且 DynamoDB 应通过 IAM 访问而不存储凭证。
● 用户数据中的硬编码机密是不安全的，并且用户数据可以被检索；请改用托管机密服务。
工作流：使用 RDS 的 Secrets Manager → EC2 实例配置文件读取密钥并调用 DynamoDB。
具有区域副本的 DynamoDB 全局表
提供本机多区域、多写入器复制，具有自动传播和冲突解决功能，可实现低延迟本地读取和写入。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：提供本机多区域、多写入器复制，具有自动传播和冲突解决功能，可实现低延迟本地读取和写入。
● 场景匹配：提供本机多区域、多写入器复制，具有自动传播和冲突解决功能，可实现低延迟本地读取和写入。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Aurora 全球数据库主要是跨区域的单一作者；跨区域写入流到主区域，并且不启用真正的多区域多写入器。
● 是具有异步跨区域复制和单个主区域的缓存，而不是持久的多写入器数据存储。
● 通过流和 Lambda 进行的 DIY 复制非常复杂，大规模时很脆弱，并且缺乏内置的冲突解决方案。
工作流：具有区域副本的 DynamoDB 全局表。
跨账户 CloudWatch Logs 目标将 Kinesis Data Firehose 传输至 Amazon S3
跨账户 CloudWatch Logs 订阅可以传送到 Firehose，后者写入 S3 以实现集中、安全、低成本的归档。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：跨账户 CloudWatch Logs 订阅可以传送到 Firehose，后者写入 S3 以实现集中、安全、低成本的归档。
● 场景匹配：跨账户 CloudWatch Logs 订阅可以传送到 Firehose，后者写入 S3 以实现集中、安全、低成本的归档。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 导出任务是周期性的并且不接近实时，并且它们不提供连续的跨账户流。
● Redshift 用于分析，归档成本高昂，不适用于廉价的长期日志存储。
● 与 S3 相比，Lambda 到 EFS 增加了复杂性，并且 EFS 并未针对低成本归档进行优化。
工作流：跨账户 CloudWatch Logs 目标将 Kinesis Data Firehose 传送到 Amazon S3。
主要区域和灾难恢复中适用于 NetApp ONTAP 的 Amazon FSx
FSx for NetApp ONTAP 在同一平台上支持 SMB 和 NFS，并使用 SnapMirror 进行高效、增量跨区域复制，非常适合试点灾难恢复。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：FSx for NetApp ONTAP 在同一平台上支持 SMB 和 NFS，并使用 SnapMirror 提高效率。
● 场景匹配：FSx for NetApp ONTAP 在同一平台上支持 SMB 和 NFS，并使用 SnapMirror 来提高效率。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 将 SMB 和 NFS 拆分到两个不同的文件系统上，并依赖于批量副本，该副本不提供.
● FSx for Lustre 不支持 SMB，并且 AWS Backup 提供定期副本，而不是高效的近乎连续的跨区域复制。
● Amazon S3 是没有本机 SMB 或 NFS 挂载的对象存储，尝试挂载它会引入兼容性。
工作流：在主区域和 DR 区域中部署 Amazon FSx for NetApp ONTAP 并配置 SnapMirror 以进行跨区域复制。
Lambda 支持的 CloudFormation 自定义资源，用于解析最新的 AMI ID 和
Lambda 支持的自定义资源仅在堆栈创建或更新期间运行，以动态获取最新的 AMI，并且具有成本效益。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Lambda 支持的自定义资源仅在堆栈创建或更新期间运行，以动态获取最新的 AMI，并且具有成本效益。
● 场景匹配：Lambda 支持的自定义资源仅在堆栈创建或更新期间运行，以动态获取最新的 AMI，并且具有成本效益。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 在没有任何变化的情况下引入频繁的计划执行和模板搅拌，增加了不必要的成本和复杂性。
● Cfn-init 在启动后在实例上运行，并且无法更改已用于创建实例的 AMI。
● 保持实例运行以进行定期检查是不必要的，并且会增加成本和运营开销。
工作流：使用 Lambda 支持的 CloudFormation 自定义资源来解析最新的 AMI ID 并将其传递到启动模板中。
具有 ALB + 托管规则的 AWS WAF Web ACL
AWS WAF 检查 ALB 上的 HTTP(S) 请求并阻止 SQLi 和 XSS 等模式。使用 ACM 证书在 ALB 处终止 TLS 可保护客户端并减轻实例的加密负担。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：AWS WAF 检查 ALB 上的 HTTP(S) 请求并阻止 SQLi 和 XSS 等模式。
● 场景匹配：AWS WAF 检查 ALB 上的 HTTP(S) 请求并阻止 SQLi 和 XSS 等模式。终止 TLS。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 在实例上终止 TLS 会增加 CPU 开销，并且违反了避免主机处理的要求。
● 网络防火墙在 VPC 层运行，不是 ALB L7 Web 漏洞利用过滤的主要控制。
● Shield Advanced 专注于 DDoS 缓解，而不是应用程序层漏洞利用过滤。
工作流：将具有托管规则的 AWS WAF Web ACL 附加到 ALB → 在 ALB HTTPS 侦听器上使用 ACM 证书进行 TLS 卸载。
用于 Auto Scaling 实例启动和终止调用的 EventBridge 规则
EventBridge 可以在 Auto Scaling 事件上调用 Lambda； Lambda 可以修改 S3 内容并将详细信息记录到 CloudWatch Logs 中以供搜索。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：EventBridge 可以在 Auto Scaling 事件上调用 Lambda； Lambda 可以修改 S3 内容并将详细信息记录到 CloudWatch Logs 中以供搜索。
● 场景匹配：EventBridge 可以在 Auto Scaling 事件上调用 Lambda； Lambda 可以修改 S3 内容并将详细信息记录到 CloudWatch。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 记录事件但不实时更新S3页面并依赖于手动或计划导出。
● S3 不是 EventBridge 支持的直接目标，因此您无法以这种方式更新页面。
● 不是事件驱动并引入延迟；如果没有额外的工具，S3 本身是无法进行搜索的。
工作流：使用 EventBridge 规则进行 Auto Scaling 实例启动和终止以调用 Lambda → Lambda 更新 S3 页面并将事件写入 CloudWatch Logs。
外部 Lambda 扩展发射 X 射线段/子段、主动跟踪、X 射线组和见解
使用 Telemetry API 的外部扩展可以发射 X 射线片段/子片段； X-Ray Insights 检测异常，EventBridge/CloudWatch 提供快速通知。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：使用 Telemetry API 的外部扩展可以发射 X 射线片段/子片段； X-Ray Insights 检测异常情况，EventBridge/CloudWatch 提供快速通知。
● 场景匹配：使用 Telemetry API 的外部扩展可以发射 X 射线片段/子片段； X-Ray Insights 检测异常，EventBridge/CloudWatch 提供快速通知。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 内部扩展对于导出遥测数据不太可靠，并且 CloudWatch Logs Insights 不提供跟踪级别的异常检测。
● ADOT 和 ServiceLens 不会取代用于跟踪异常检测的 X-Ray Insights，并且 Contributor Insights 分析日志模式，而不是跟踪异常。
● 折叠函数会消除跨函数的可见性，当 X-Ray 可以跨多个函数关联分布式跟踪时，折叠函数是不必要的。
工作流：外部 Lambda 扩展发出 X-Ray 分段/子分段、主动跟踪、X-Ray 组和见解、通过 EventBridge 和 CloudWatch 发出警报。
通过 sts:AssumeRole 在集群帐户中承担部署角色，授予 EKS
这使得 CodeBuild 角色能够承担具有 EKS 权限的跨账户角色，并通过 aws-auth （或访问条目）在 Kubernetes 中授权该角色。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这使得 CodeBuild 角色能够承担具有 EKS 权限的跨账户角色，并授权该角色。
● 场景匹配：这使得 CodeBuild 角色能够承担具有 EKS 权限的跨账户角色，并授权该角色。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● IRSA 适用于集群中运行的 pod，不适用于 CodeBuild；仍然需要跨账户访问和Kubernetes授权。
● 信任关系必须位于所承担的集群帐户中的目标角色上，而不是 DevOps 角色上。
● CodeBuild 不通过 Web 身份承担角色，EKS 访问仍然需要通过 aws-auth 或访问条目进行授权。
工作流：通过 sts:AssumeRole 在集群账户中承担部署角色 → 授予 EKS 权限，并在 aws-auth 中映射该角色。
用于调用 AWS 的 CodePipeline 状态更改的 Amazon EventBridge 规则
这将管道事件与自动化 Runbook 联系起来，该 Runbook 以编程方式管理计算和数据库资源，而无需更改架构。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这将管道事件与自动化 Runbook 联系起来，该 Runbook 以编程方式管理计算和数据库资源，而无需更改架构。
● 场景匹配：这将管道事件与自动化运行手册联系起来，该运行手册以编程方式管理计算和数据库资源而无需更改。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 更改定价模型并依赖于手动脚本，并且预留实例对于不频繁使用而言效率低下。
● 引入了架构更改，但仍然缺乏来自 CodePipeline 的直接事件驱动触发器。
● 基于时间而不是事件驱动，并且可以在没有正在执行管道测试或错过临时运行时运行。
工作流：为 CodePipeline 状态更改配置 Amazon EventBridge 规则，该规则调用 AWS Systems Manager Automation Runbook 在测试开始和结束时启动和停止 EC2 实例和 RDS 数据库实例。
存储桶策略拒绝或忽略所需的访问+ IAM 角色
限制性或不正确的存储桶策略（包括显式拒绝或未满足的条件）将返回 403 Access Denied。缺少权限、权限边界或 SCP 拒绝可能会导致 S3 返回 403 访问被拒绝。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：限制性或不正确的存储桶策略（包括显式拒绝或未满足的条件）将返回 403 Access Denied。
● 场景匹配：限制性或不正确的存储桶策略（包括显式拒绝或未满足的条件）将返回 403 Access Denied。丢失的。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 网络出口阻塞通常会导致超时或连接错误，而不是来自 S3 的授权 403。
● S3 默认加密对于授权调用者来说是透明的，并且本身不会阻止访问。
● 阻止公共访问会限制公共访问，但不会阻止授权 IAM 角色的访问。
工作流：存储桶策略拒绝或忽略所需的访问 → 实例的 IAM 角色缺少 s3:GetObject 或被阻止。
授予 SSM 访问权限的实例的 IAM 角色 + 添加 SSM 接口
SSM 代理需要一个允许其调用 Systems Manager API 的实例配置文件。为 ssm、ssmmessages 和 ec2messages 创建接口终端节点以保持 AWS PrivateLink 上的流量。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：SSM 代理需要一个允许其调用 Systems Manager API 的实例配置文件。
● 场景匹配：SSM 代理需要一个允许其调用 Systems Manager API 的实例配置文件。为 ssm、ssmmessages 和 ec2messages 创建接口终端节点以保持 AWS PrivateLink 上的流量。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 客户端 VPN 与保持 Session Manager 流量私有无关，并且不会取代对 VPC 终端节点的需求。
● Systems Manager 使用接口 VPC 终端节点，而不是网关终端节点。
● NAT 网关启用互联网出口，这违反了要求。
工作流：将 IAM 角色附加到授予 SSM 访问权限的实例 → 在 VPC 中添加 SSM 接口 VPC 终端节点。
使用 CloudWatch 代理转发身份验证日志，添加 CloudWatch Logs 指标过滤器
指标过滤器将匹配的日志行转换为指标，使 CloudWatch 警报能够提供近乎实时的 SNS 通知。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：指标过滤器将匹配的日志行转换为指标，使 CloudWatch 警报能够提供近乎实时的 SNS 通知。
● 场景匹配：指标过滤器将匹配的日志行转换为指标，使 CloudWatch 警报能够提供近乎实时的 SNS 通知。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 可以近乎实时地工作，但与本机指标过滤器和警报相比，增加了自定义代码和操作开销。
● CloudTrail 记录 AWS API 活动，而不是操作系统级别的主机登录，并且管道延迟可能会超过目标窗口。
● ConsoleLogin 表示 AWS 账户登录事件，而不是 EC2 主机上的 Linux 或 Windows 登录。
工作流：使用 CloudWatch 代理转发身份验证日志 → 为成功登录添加 CloudWatch Logs 指标筛选器，并向 SNS 触发 CloudWatch 警报。
使用 EventBridge 到 SNS + AWS Config 组织的 AWS CloudTrail 组织跟踪
组织级跟踪记录组织 API 调用，EventBridge 可以将匹配事件路由到 SNS 以获得近实时警报。跨帐户聚合配置数据，并可以评估规则以针对整个组织中检测到的更改发出警报。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：组织级跟踪记录组织 API 调用，EventBridge 可以将匹配事件路由到 SNS 以获得近实时警报。
● 场景匹配：组织级跟踪记录组织 API 调用，EventBridge 可以将匹配事件路由到 SNS 以获得近实时警报。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 这些汇总和调查安全结果，而不是 AWS Organizations 成员资格或账户更改事件。
● 控制塔管理登陆区域，但不是组织成员资格变更警报的权威或综合来源。
● 对于威胁检测和日志分析很有用，但不针对精确的 AWS Organizations 更改事件。
工作流：使用 EventBridge 到 SNS 的 AWS CloudTrail 组织跟踪 → AWS Config 组织聚合器，其中包含到 SNS 或 EventBridge 的规则。
在ECS服务中，将平台版本设置为最新并选择
对于使用最新的服务，强制新部署会将任务重新启动到最新支持的 Fargate 平台版本上。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：对于使用最新的服务，强制新部署会将任务重新启动到最新支持的 Fargate 平台版本上。
● 场景匹配：对于使用最新的服务，强制新部署会将任务重新启动到最新支持的 Fargate 平台版本上。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Fargate 平台版本不是任务定义的一部分，无法通过任务定义 ARN 指定。
● ECS 不提供 Fargate 平台版本的自动升级开关。
● 虽然可能，但与强制新部署相比，创建新服务和蓝/绿转变是不必要的复杂性。
工作流：在 ECS 服务中 → 将平台版本设置为最新，然后选择强制新部署以在较新的运行时上重新启动任务。
CAPABILITY_IAM 或 CAPABILITY_NAMED_IAM 到 CodePipeline 中的 CloudFormation 操作
CloudFormation 需要显式确认才能创建或修改 IAM 资源，否则会引发 InsufficientCapabilityException。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudFormation 需要显式确认才能创建或修改 IAM 资源，否则会引发 InsufficientCapabilityException。
● 场景匹配：CloudFormation 需要显式确认才能创建或修改 IAM 资源，否则会引发 InsufficientCapabilityException。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 循环依赖会导致依赖循环错误，而不是 InsufficientCapabilityException。
● PassRole 修复了传递角色时的 AccessDenied，但不满足所需的 IAM 功能确认。
● 更广泛的权限不会绕过承认 CloudFormation 中 IAM 功能的需要。
工作流：将 CAPABILITY_IAM 或 CAPABILITY_NAMED_IAM 添加到 CodePipeline 中的 CloudFormation 操作。
单个阶段中的操作具有相同的 runOrder 来运行它们
同一阶段内共享相同 runOrder 的操作同时执行，从而减少总体持续时间。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：同一阶段内共享相同 runOrder 的操作同时执行，从而减少总体持续时间。
● 场景匹配：同一阶段内共享相同 runOrder 的操作同时执行，从而减少总体持续时间。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 协调相关构建，但不会使单独的 CodePipeline 操作同时运行。
● 可能会加快单个构建的速度，但会使顺序管道成为瓶颈。
● 增加了复杂性和外部协调器，但没有提高 CodePipeline 操作并行性。
工作流：为单个阶段中的操作设置相同的 runOrder 以并行运行它们。
为 VPC 中的 Systems Manager 调配接口 VPC 终端节点以保持
接口 VPC 终端节点无需使用 Internet 即可实现与 Systems Manager API 和数据通道的专用连接。实例需要授予 Systems Manager 的 IAM 实例配置文件。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：接口 VPC 终端节点无需使用 Internet 即可实现与 Systems Manager API 和数据通道的专用连接。
● 场景匹配：接口 VPC 终端节点无需使用 Internet 即可实现与 Systems Manager API 和数据通道的专用连接。实例。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 堡垒主机仍然依赖 SSH 和密钥对，并且不强制执行私有会话管理器访问。
● EC2 API 端点不提供会话管理器所需的私有数据通道。
● 会话管理器不需要打开 SSH 端口 22，因为它在没有入站端口的情况下运行。
工作流：在 VPC 中为 Systems Manager 配置接口 VPC 终端节点，以保持 Session Manager 流量的私有性 → 将 IAM 实例配置文件与包含 AmazonSSMManagedInstanceCore 等权限的每个实例关联。
SSM Automation 黄金 AMI + 用户数据读取环境标签 + 参数
SSM Automation 支持黄金 AMI 工作流程来预烘焙软件，引导程序可以读取环境标签来加载设置，并且带有 KMS 的 Parameter Store SecureString 可以保护机密。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：SSM Automation 支持黄金 AMI 工作流程来预烘焙软件，引导程序可以读取环境标签来加载设置，并且带有 KMS 的 Parameter Store SecureString 可以保护机密。
● 场景匹配：SSM Automation 支持黄金 AMI 工作流程来预烘焙软件，引导程序可以读取环境标签来加载。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Session Manager 不会创建或烘焙 AMI，并且从用户数据添加 Lambda 会增加复杂性，而不会缩短启动时间。
● 补丁管理器的目标是操作系统补丁而不是应用程序烘焙，AppConfig 用于配置标志，而不是秘密存储。
● 通过 cfn-init 在首次启动时安装会增加启动时间，并且不会利用预烘焙的 AMI 来缩短启动持续时间。
工作流：SSM Automation 黄金 AMI + 用户数据读取环境标签 + 参数存储 SecureString。
CloudFormation 嵌套堆栈，具有重新附加指定 ENI 的单实例 Auto Scaling 组
此模式通过 ENI 重用提供自我修复、稳定的私有 IP，并使用 IaC 提供最少的自定义代码。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：此模式通过 ENI 重用提供自我修复、稳定的私有 IP，并使用 IaC 提供最少的自定义代码。
● 场景匹配：此模式通过 ENI 重用提供自我修复、稳定的私有 IP，并使用 IaC 提供最少的自定义代码。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 是临时性的且操作繁重，缺乏内置的自我修复和可重复性。
● Beanstalk 抽象实例，并且不提供确定性的 ENI 重用或每个节点的固定主机名。
● 可能，但与更简单的本机 CloudFormation 模式相比，增加了自定义逻辑和维护开销。
工作流：CloudFormation 嵌套堆栈与单实例 Auto Scaling 组，可重新附加指定的 ENI 并在启动时设置主机名。
存储桶的 AWS CloudTrail 数据事件，将日志存储在 Amazon 中
CloudTrail 数据事件捕获 S3 对象级 API 调用并将其存储在 S3 中，Athena 提供低成本的按需搜索。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudTrail 数据事件捕获 S3 对象级 API 调用并将其存储在 S3 中，Athena 提供低成本的按需搜索。
● 场景匹配：CloudTrail 数据事件捕获 S3 对象级 API 调用并将其存储在 S3 中，Athena 提供低成本的按需搜索。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 运行 OpenSearch 域会增加持续成本，并且 S3 访问日志并不是 API 级审核的最精确来源。
● EventBridge 不会接收 S3 对象级 API 事件，除非将 CloudTrail 配置为发出这些事件。
● S3 本身无法将对象级 API 日志直接推送到 CloudWatch Logs。
工作流：为存储桶启用 AWS CloudTrail 数据事件 → 将日志存储在 Amazon S3 中，并使用 Amazon Athena 临时查询它们。
具有映射到两个 ASG 的两个目标组的单个 ALB
在单个 ALB 上切换目标组可将 DNS 从转换路径中删除，减少组件和成本，并实现快速蓝/绿转换。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：在单个 ALB 上切换目标组可从转换路径中删除 DNS，减少组件和成本，并且。
● 场景匹配：在单个 ALB 上切换目标组可从转换路径中删除 DNS，减少组件和成本，并且。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 可以使用静态任播 IP 来掩盖 DNS 问题，但与简化现有方案相比，它会增加成本和复杂性。
● 减少 TTL 并不能修复忽略或固定 DNS 响应的客户端，并且仍会导致调用。
● 实例级代理增加了运营开销和复杂性，同时创建了难以管理的脆弱流量路径。
工作流：使用单个 ALB，将两个目标组映射到两个 ASG → 部署到空闲 ASG，→ 将 ALB 侦听器规则翻转到新目标组，同时保留。
EventBridge 规则触发 Lambda 提升副本并更新 Systems Manager
EventBridge 检测 RDS 或 Aurora 故障事件，Lambda 自动升级并更新客户端在重新连接时读取的中央端点值。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：EventBridge 检测 RDS 或 Aurora 故障事件，Lambda 自动升级并更新客户端在重新连接时读取的中央端点值。
● 场景匹配：EventBridge 检测 RDS 或 Aurora 故障事件，Lambda 自动升级并更新客户端在重新连接时读取的中央端点值。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 全局数据库可以切换写入区域，但不会自动检测故障或更新客户端端点；你仍然需要编排。
● DNS 故障转移无法促进副本和 Aurora 终端节点在提升时发生更改，因此仅靠 DNS 是不够的。
● RDS Proxy 是区域性的，不处理跨区域升级或端点切换。
工作流：EventBridge 规则触发 Lambda 提升副本并更新 Systems Manager Parameter Store。
部署过程中发生横向扩展；使用上次成功修订启动的新实例
当 Auto Scaling 组在部署期间添加实例时，它们会使用最近成功的修订进行初始化，从而导致即使部署成功完成，也会出现混合队列。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：当 Auto Scaling 组在部署期间添加实例时，它们会使用最近成功的修订进行初始化，从而导致即使部署成功完成，也会出现混合队列。
● 场景匹配：当 Auto Scaling 组在部署期间添加实例时，它们会使用最近成功的实例进行初始化。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 过时的启动模板会影响实例的启动方式，但 CodeDeploy 仍会更新目标实例或使部署失败。
● 缺少 IAM 权限将导致部署失败，而混合版本则不会成功。
● 最少的健康主机控制批量可用性，但成功的部署仍会更新所有目标实例。
工作流：部署期间发生横向扩展 → 使用上次成功修订启动的新实例。
na.example.com 和 eu.example.com 的 Apex 延迟别名；每个子域都使用故障转移
延迟决定Region；每个区域的故障转移在中断时交换到其他 ALB。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：延迟决定Region；每个区域的故障转移在中断时交换到其他 ALB。
● 场景匹配：延迟决定Region；每个区域的故障转移在中断时交换到其他 ALB。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 返回多条健康记录；没有延迟感知，也没有区域故障转移协调。
● 反转所需的分层；不会在延迟下提供按区域的故障转移。
● 删除不健康的目标，但缺乏明确的跨区域故障转移分支，并且可能会错过一些区域故障模式。
工作流：na.example.com 和 eu.example.com 的 Apex 延迟别名 → 每个子域都使用区域内 ALB 主区域和其他区域作为辅助区域的故障转移。
AWS CodeDeploy 具有用于 Auto Scaling 的蓝绿色部署组
CodeDeploy 蓝绿支持将流量转移到新队列，并在可配置的等待时间（例如 90 分钟）后自动终止原始队列。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CodeDeploy 蓝绿支持将流量转移到新队列，并在 a 后自动终止原始队列。
● 场景匹配：CodeDeploy 蓝绿支持将流量转移到新队列，并在 a 后自动终止原始队列。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● CloudFormation 不支持 ALB 等资源的基于时间的保留或删除策略，并且这不会进行编排。
● Elastic Beanstalk 应用程序版本生命周期适用于最短期限（以天为单位）的版本，并且不会安排环境终止。
● 依赖于自定义编排和计时器，而不是使用本机定时终止功能，这使其更加复杂。
工作流：将 AWS CodeDeploy 与 Auto Scaling 组的蓝绿色部署组结合使用，并将 BlueInstanceTerminationOption 操作设置为 TERMINATE，并将终止等待时间设置为 90。
AWS CloudFormation 用于管理 Lambda 版本和 API Gateway 阶段金丝雀
CloudFormation 可以管理 0.15 流量百分比的 API Gateway 阶段 CanarySetting 以及相关的 Lambda 部署配置。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudFormation 可以管理具有 0.15 流量百分比的 API Gateway 阶段 CanarySetting 以及相关的 Lambda 部署配置。
● 场景匹配：CloudFormation 可以管理 0.15 流量百分比的 API Gateway 阶段 CanarySetting 以及相关的 Lambda 部署配置。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● CodeDeploy 可以转移 Lambda 别名流量，但 API Gateway 金丝雀配置保持独立。
● Route 53 加权路由在 DNS 终端节点级别工作，并受缓存和 TTL 的影响。
● 使用计划控制 API 密钥配额和限制。
工作流：使用 AWS CloudFormation 管理 Lambda 版本和 API Gateway 阶段金丝雀，费用为 15%，→ 提升。
使用 CloudFormation 预配置第二个区域，使用跨区域 RDS 只读副本，启用
跨区域只读副本和 S3 CRR 可最大限度地降低 RPO，并且预先配置基础设施的热容量可实现快速升级和低 RTO。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：跨区域只读副本和 S3 CRR 可最大限度地降低 RPO，并且预先配置基础设施的热容量可实现快速升级和低 RTO。
● 场景匹配：跨区域只读副本和 S3 CRR 可最大限度地降低 RPO，并且预先配置基础设施的热容量可实现快速升级和低 RTO。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 由于手动恢复和检索延迟，不频繁的快照副本和 Glacier 检索会增加 RPO 和 RTO。
● 在没有跨区域数据库复制的情况下进行计算故障转移不会在次要区域中留下最新的数据库。
● RDS 多可用区仅限于单个区域，无法跨区域进行故障转移。
工作流：使用 CloudFormation 预配置第二个区域 → 使用跨区域 RDS 只读副本 → 启用 S3 CRR、热 ASG → 进行故障转移升级。
v1 和 v2 阶段具有一个 Lambda 别名； v1 映射注入 "color":"none"
两个阶段都通过别名调用单个 Lambda，而旧阶段使用映射模板来默认该字段以实现向后兼容性。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：两个阶段都通过别名调用单个 Lambda，而旧阶段使用映射模板来默认该字段以实现向后兼容性。
● 场景匹配：两个阶段都通过别名调用单个 Lambda，而旧阶段使用映射模板来默认该字段以实现向后兼容性。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 引入两个 Lambda 函数和代理逻辑，违反了单后端目标并增加了运营开销。
● Lambda 授权者无法修改请求正文；它们仅提供身份验证上下文。
● 模型和验证器验证形状和类型，但不会变异或将字段注入到有效负载中。
工作流：将 v1 和 v2 阶段与一个 Lambda 别名结合使用 → v1 映射注入“color”:“none”。
每个逻辑域维护单独的模板并按其部署每个堆栈
这遵循 CloudFormation 最佳实践，通过解耦团队、启用独立部署以及使用导出/导入来实现安全的跨堆栈引用。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这遵循 CloudFormation 最佳实践，通过解耦团队、启用独立部署以及使用导出/导入来实现安全的跨堆栈引用。
● 场景匹配：这遵循 CloudFormation 最佳实践，通过解耦团队、启用独立部署以及使用导出/导入来实现安全的跨堆栈引用。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 跨团队的发布紧密结合，因为任何更改都会强制父堆栈更新，从而增加爆炸半径和协调开销。
● 整体模板将所有组件耦合在一起，扩大故障爆炸半径，并阻止尚未做好准备的团队。
● AWS Proton 标准化了服务和环境模板，但并未用显式跨堆栈引用取代解耦的 CloudFormation 堆栈的需要。
工作流：每个逻辑域维护单独的模板，并在每个堆栈准备就绪时进行部署，通过跨堆栈导出和导入共享值，并在版本控制中独立管理每个模板。
AWS Config S3 托管规则与 Systems Manager Automation 修复
根据托管规则持续评估 S3 存储桶，并通过 SSM 自动化运行手册自动修复偏差。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：根据托管规则持续评估 S3 存储桶，并通过 SSM 自动化运行手册自动修复偏差。
● 场景匹配：根据托管规则持续评估 S3 存储桶，并通过 SSM 自动化运行手册自动修复偏差。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 阻止某些操作并阻止公共访问，但无法启用加密、日志记录或版本控制或修复现有存储桶。
● 咨询检查缺乏细粒度、连续的每个存储桶合规性，并且不提供本机自动修复。
● 自定义事件驱动逻辑可以对 API 调用做出反应，但很复杂，不以配置合规性为中心，并且会错过持续评估。
工作流：AWS Config S3 通过 Systems Manager Automation 修复托管规则。
引用当前版本和新版本的单个 AWS Lambda 别名
Lambda 别名支持路由配置，以加权最多两个已发布版本之间的流量并允许快速回滚。 API Gateway 金丝雀设置本身支持加权流量。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Lambda 别名支持路由配置，以加权最多两个已发布版本之间的流量并允许快速回滚。
● 场景匹配：Lambda 别名支持路由配置，以对最多两个已发布版本之间的流量进行加权并允许快速回滚。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 网络负载均衡器不支持跨目标组的加权路由，因此您无法分割 15% 的流量。
● 故障转移路由是基于运行状况的主要和次要行为，而不是基于百分比的流量分割。
● Application Load Balancer 中没有内置 Canary 路由选项。
工作流：使用引用当前版本和新版本的单个 AWS Lambda 别名 → 将 15% 的流量转移到新版本，并在证明稳定后路由 100% → 启用。
AWS CloudTrail 将事件发送到 Amazon CloudWatch Logs，部署 CloudWatch
将 CloudTrail 事件和实例日志都放置在 CloudWatch Logs 中，使 CloudWatch Logs Insights 能够在一处跨多个日志组进行查询。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：将 CloudTrail 事件和实例日志都放置在 CloudWatch Logs 中，使 CloudWatch Logs Insights 能够跨多个进行查询。
● 场景匹配：将 CloudTrail 事件和实例日志都放入 CloudWatch Logs 中，使 CloudWatch Logs Insights 能够跨多个进行查询。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● CloudWatch 代理无法将日志直接发送到 Amazon S3，因此不支持端到端管道。
● CloudTrail 本身并不传送到 Kinesis Data Streams，CloudWatch 代理也不发布到 Kinesis Data。
● Athena 可以查询 S3 对象，但无法直接查询 CloudWatch Logs，这会阻止跨两者的单个查询接口。
工作流：配置 AWS CloudTrail 以将事件发送到 Amazon CloudWatch Logs → 在 EC2 上部署 CloudWatch 代理以将应用程序日志推送到 CloudWatch Logs，并在两者之间运行 CloudWatch Logs Insights 查询。
在没有 RDS 的不同 AWS 区域中的应用程序层，创建一个
具有克隆应用程序层和 Route 53 故障转移的跨区域只读副本可提供满足 10 分钟 RPO 和 90 分钟 RTO 的热备用。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：具有克隆应用程序层和 Route 53 故障转移的跨区域只读副本可提供热备用。
● 场景匹配：具有克隆应用程序层和 Route 53 故障转移的跨区域只读副本可提供热备用。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● RDS 多可用区仅限于单个区域，因此不支持将备用数据库放置在另一个区域中。
● 额外的可用区不能防止区域中断，因此不满足地理隔离的要求。
工作流：在不使用 RDS 的不同 AWS 区域中部署应用程序层 → 创建跨区域 RDS MySQL 只读副本，将 DR 应用程序指向本地副本，并使用 Route 53 故障转移。
API 网关阶段的 WAF Web ACL 具有托管 SQLi 规则；追踪
使用 AWS Managed Rules for SQLi 直接保护 API Gateway，并使用 AWS Config 记录配置更改。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：使用 AWS Managed Rules for SQLi 直接保护 API Gateway，并使用 AWS Config 记录配置更改。
● 场景匹配：使用 AWS Managed Rules for SQLi 直接保护 API Gateway，并使用 AWS Config 记录配置更改。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Shield 针对 DDoS，与 AWS Config 相比，CloudTrail 并不适合搜索配置历史记录。
● 增加成本和复杂性； NACL 不适用于不在您的 VPC 中的 API Gateway。
● 限制不会阻止 SQL 注入，并且 CloudWatch Logs 不提供配置更改历史记录。
工作流：API 网关阶段上的 WAF Web ACL 具有托管 SQLi 规则 → 通过 AWS Config 进行跟踪。
AWS CodeDeploy 与 Auto Scaling 组的蓝/绿部署组
CodeDeploy 蓝/绿创建具有相同容量的单独队列，在准备就绪时切换 ALB 目标组，并可以安排在指定时间后终止原始队列。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CodeDeploy 蓝/绿创建具有相同容量的单独队列，在准备就绪时切换 ALB 目标组，并且可以进行调度。
● 场景匹配：CodeDeploy 蓝/绿创建具有相同容量的单独队列，在准备就绪时切换 ALB 目标组，并且可以进行调度。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Elastic Beanstalk 应用程序版本生命周期规则管理存储的版本，而不是定时环境终止，并且不会在本机强制执行。
● CloudFormation 保留策略适用于堆栈删除，不会编排蓝/绿容量重复、流量转移或定时实例。
工作流：将 AWS CodeDeploy 与 Auto Scaling 组的蓝/绿部署组结合使用，并设置 BlueInstanceTerminationOption 以在流量转移后 90 分钟终止蓝色实例。
AWS 弹性灾难恢复 (DRS)
持续复制到另一个区域的暂存区域，并实现快速故障转移和故障回复。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：持续复制到另一个区域的暂存区域，并实现快速故障转移和故障恢复。
● 场景匹配：持续复制到另一个区域的暂存区域，并实现快速故障转移和故障回复。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 提供时间点备份，而不是连续复制或自动故障恢复。
● 控制和协调故障转移路由，但不复制 EC2 数据。
● 适合迁移；与 DRS 相比，持续 DR 和故障恢复的简化程度较低。
工作流：AWS 弹性灾难恢复 (DRS)。
30%批次滚动部署
在同一环境中批量更新实例，保留 DNS 并避免新资源，同时保持容量可用。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：在同一环境中批量更新实例，保留 DNS 并避免新资源，同时保持容量可用。
● 场景匹配：在同一环境中批量更新实例，保留 DNS 并避免新资源，同时保持容量可用。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 创建一个单独的环境，然后交换流量，从而添加新资源。
● 同时更新所有实例，导致停机。
● 临时启动额外的容量实例，创建额外的资源。
工作流：滚动部署 30% 批次。
Amazon Macie 和通过 EventBridge 的路线结果和 CloudTrail S3 数据事件
Macie 会自动发现 S3 中的 PII，EventBridge 还可以处理 CloudTrail S3 数据事件，以最少的工程量发出访问警报。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Macie 会自动发现 S3 中的 PII，EventBridge 还可以处理 CloudTrail S3 数据事件，以最少的工程量发出访问警报。
● 场景匹配：Macie 会自动发现 S3 中的 PII，EventBridge 还可以处理 CloudTrail S3 数据事件，以最少的工程量发出访问警报。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● GuardDuty 检测可疑或异常的 S3 活动，但不会扫描对象内容中的 PII。
● Security Hub 汇总结果，但不会发现 S3 中的 PII；它需要另一个像 Macie 这样的服务来进行内容分类。
● 自定义管道会增加工程开销，并且 Comprehend 是以文本为中心的，而不是托管的 S3 范围的 PII 发现解决方案。
工作流：启用 Amazon Macie 并通过 EventBridge 路由结果和 CloudTrail S3 数据事件。
Amazon Macie 用于目标存储桶，并将结果路由到 EventBridge
Macie 自动发现 S3 中的 PII 并对其进行分类，并与 EventBridge 集成，以最少的工程量发出警报。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Macie 自动发现 S3 中的 PII 并对其进行分类，并与 EventBridge 集成，以最少的工程量发出警报。
● 场景匹配：Macie 自动发现 S3 中的 PII 并对其进行分类，并与 EventBridge 集成，以最少的工程量发出警报。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 存储桶策略无法检查对象内容来识别 PII，因此它们无法检测新存储的敏感数据或发出警报。
● GuardDuty 专注于威胁和异常检测，而不是发现对象内容中的 PII 或对其进行分类。
● 与托管服务相比，自定义 Lambda 和 SageMaker 管道会显着增加开发和维护开销。
工作流：为目标存储桶启用 Amazon Macie，并将结果路由到 EventBridge 以获取通知。
Lambda AppSpec 中的 BeforeAllowTraffic 挂钩运行检查并等待
BeforeAllowTraffic 允许您控制轮班，以便新版本仅在先决任务（例如架构更改或预热）完成后接收请求。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：BeforeAllowTraffic 允许您控制轮班，以便新版本仅在先决任务（例如架构更改或预热）完成后接收请求。
● 场景匹配：BeforeAllowTraffic 允许您控制班次，以便新版本仅在先决任务之后接收请求，例如。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 预置并发可以解决冷启动问题，但不能确保数据库准备就绪或部署后数据更改完成。
● AfterAllowTraffic 在流量已转移后运行，这对于防止切换期间的初始错误来说为时已晚。
● ValidateService 确认部署状态，并且不为 Lambda 部署提供预流量门控机制。
工作流：在 Lambda AppSpec 中添加 BeforeAllowTraffic 挂钩，以在转移流量之前运行检查并等待所需的数据库更新。
CodePipeline 状态和批准事件的 EventBridge 规则，路由到 SNS，然后
EventBridge 本机发出 CodePipeline 事件，SNS 提供扇出和重试，Lambda 转换 Webhook 的有效负载。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：EventBridge 本机发出 CodePipeline 事件，SNS 提供扇出和重试，Lambda 转换 Webhook 的有效负载。
● 场景匹配：EventBridge 本机发出 CodePipeline 事件，SNS 提供扇出和重试，Lambda 转换 Webhook 的有效负载。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● CloudTrail 捕获 API 调用，并且可能会延迟，丢失一些非 API 状态转换，无法满足近乎实时的需求。
● AWS Config 评估资源配置合规性，并且不会发出 CodePipeline 执行或批准事件。
● CodeStar 通知以 SNS 为目标，但直接 Webhook 订阅需要 SNS 确认和大多数聊天 Webhook 所缺乏的特定格式，并且不提供任何转换。
工作流：将 EventBridge 规则用于 CodePipeline 状态和批准事件 → 路由到 SNS，→ Lambda 发布到 Webhook。
Amazon GuardDuty 跨所有组织账户，以安全账户作为
GuardDuty 提供多帐户威胁检测，并可以通过 EventBridge 将检测结果集中路由到 Firehose，以便传送到 S3。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：GuardDuty 提供多帐户威胁检测，并可以通过 EventBridge 将检测结果集中路由到 Firehose，以便传送到 S3。
● 场景匹配：GuardDuty 提供多帐户威胁检测，并可以通过 EventBridge 将检测结果集中路由到 Firehose，以便传送到 S3。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Macie 专注于 S3 中的敏感数据发现，不检测 SSH 暴力或恶意软件等威胁。
● 仅在管理员帐户中运行 GuardDuty 不会为成员帐户创建结果，并且此管道会增加不必要的结果。
● Security Hub 会汇总发现的结果并确定其优先级，但不会在没有检测器的情况下本地检测 SSH 暴力破解等威胁。
工作流：使用安全账户作为委派管理员在所有组织账户中启用 Amazon GuardDuty，并将 GuardDuty 结果从 Amazon EventBridge 路由到写入 S3 存储桶的 Amazon Kinesis Data Firehose。
Lambda 函数策略不再允许 s3.amazonaws.com 调用 + Bucket 通知
S3 要求该功能具有基于资源的权限，该权限允许 s3.amazonaws.com 主体将存储桶作为源；没有它，调用就会停止。如果桶的事件。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：S3 要求该功能具有基于资源的权限，该权限允许 s3.amazonaws.com 主体将存储桶作为源；没有它，调用就会停止。
● 场景匹配：S3 需要对函数的基于资源的权限，以允许 s3.amazonaws.com 主体将存储桶作为源。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 生命周期转换发生在对象创建之后，并且不会阻止初始 PutObject 事件或其通知。
● SSE-S3 或 SSE-KMS 不会禁用对象创建的事件的事件通知。
● 来自 S3 的调用取决于函数的基于资源的策略，而不是执行角色；缺少执行角色权限将导致运行时错误，而不是停止调用。
工作流：Lambda 函数策略不再允许 s3.amazonaws.com 调用 → 发送给 Lambda 的存储桶通知已删除。
AWS CodeDeploy 与 Amazon EC2 Auto Scaling，配置 CloudWatch 警报
CodeDeploy 支持一次性部署，并与 CloudWatch 警报集成，以便在 CPU 等指标突破阈值时自动回滚。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CodeDeploy 支持一次性部署，并与 CloudWatch 警报集成，以在出现诸如以下情况时自动回滚。
● 场景匹配：CodeDeploy 支持一次性部署，并与 CloudWatch 警报集成，以在出现诸如以下情况时自动回滚。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Elastic Beanstalk 滚动更新依赖于环境运行状况，不支持基于 CPU 的 CloudWatch 警报驱动回滚。
● 过于复杂，并且缺乏在部署期间与 CloudWatch CPU 警报相关的本机、基于指标的自动回滚。
● AppConfig 管理配置标志，但不执行 EC2 应用程序代码部署或与 ASG 协调逐实例部署。
工作流：将 AWS CodeDeploy 与 Amazon EC2 Auto Scaling 结合使用 → 配置 CPU 利用率的 CloudWatch 警报，选择 CodeDeployDefault.OneAtATime 部署配置，并在触发警报时启用自动回滚。
将 AWS::RDS::DBInstance 中的 EngineVersion 更改为目标 MySQL 主要版本，配置
创建用于切换的只读副本，然后通过 CloudFormation 更新 EngineVersion 可最大限度地减少停机时间，因为就地多可用区升级否则会使部署脱机。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：创建用于切换的只读副本，然后通过 CloudFormation 更新 EngineVersion 可最大限度地减少停机时间，因为就地多可用区。
● 场景匹配：创建用于切换的只读副本，然后通过 CloudFormation 更新 EngineVersion 可最大限度地减少停机时间，因为就地多可用区。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 只自动进行次要升级，不执行主要引擎版本升级，因此不会实现。
● 是一个有效的迁移工具，但它不是现有 RDS 实例的 CloudFormation 驱动的就地升级策略。
● DBEngineVersion 不是 AWS::RDS::DBInstance 的有效 CloudFormation 属性，并且在创建副本之前进行升级会增加停机风险。
工作流：将 AWS::RDS::DBInstance 中的 EngineVersion 设置为目标 MySQL 主要版本，首先在单独的堆栈中配置类似的只读副本，→ 执行更新堆栈以应用更改。
Amazon Inspector 与 CloudWatch Logs 代理
Inspector 持续检测软件漏洞和网络暴露，而 CloudWatch 代理将来宾身份验证日志发送到集中式 CloudWatch Logs。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Inspector 持续检测软件漏洞和网络暴露，而 CloudWatch 代理将来宾身份验证日志发送到集中式 CloudWatch Logs。
● 场景匹配：Inspector 持续检测软件漏洞和网络暴露，而 CloudWatch 代理将来宾身份验证日志发送到集中式 CloudWatch Logs。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 补丁管理器测量并应用补丁，而不是执行完整的连续漏洞检测。
● Security Hub 汇总调查结果，CloudTrail 记录 AWS API 活动。
● GuardDuty 检测可疑活动，Detective 支持调查。
工作流：Amazon Inspector 与 CloudWatch Logs 代理。
CodeDeploy 蓝/绿，带有 ALB 和 ASG；健康宿主最少 60%；清理在
CodeDeploy 蓝/绿在 ALB 后面启动了替换队列，支持用于预流量清理的生命周期挂钩，强制执行 60% 最低健康主机，并且可以终止原始实例。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CodeDeploy 蓝/绿在 ALB 后面启动了替换队列，支持用于预流量清理的生命周期挂钩，强制执行最低 60% 的要求。
● 场景匹配：CodeDeploy 蓝/绿在 ALB 后面启动了替换队列，支持用于预流量清理的生命周期挂钩，强制执行最低 60% 的要求。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Beanstalk 可以交换环境，但缺乏用于流量前清理和细粒度旧队列终止控制的 CodeDeploy 生命周期挂钩。
● 实例刷新不提供用于流量前清理的 CodeDeploy 生命周期挂钩，并且不根据需要管理蓝/绿终止行为。
● 就地更新不会预先配置新队列，并且AllowTraffic 事件不可编写脚本进行清理。
工作流：使用 ALB 和 ASG 的 CodeDeploy 蓝/绿 → 最小健康主机 60% → 在 BeforeAllowTraffic 中清理 → 终止原始主机。
主要区域中以 GitHub 作为源的单个 CodePipeline
跨区域操作允许一个管道协调跨区域的构建和部署，而 CodePipeline 则管理满足数据驻留的每个区域工件存储桶。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：跨区域操作让一个管道可以跨区域编排构建和部署，而 CodePipeline 则管理每个区域的工件存储桶。
● 场景匹配：跨区域操作让一个管道可以跨区域编排构建和部署，而 CodePipeline 则管理每个区域的工件存储桶。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 运行和维护多个区域管道会增加操作复杂性，并且当单个管道可以协调多区域操作时，这是不必要的。
● 服务侧重于游戏服务器托管和扩展，而不是 CI/CD 编排或工件驻留。
● 将工件集中到一个存储桶中可以打破将工件和数据保留在各自区域内的要求。
工作流：在主区域中以 GitHub 作为源创建单个 CodePipeline → 启用跨区域操作，以便 CodeBuild 和 CodeDeploy 在辅助区域中运行，并允许 CodePipeline 在每个区域中创建默认工件存储桶。
传送到 S3 的 Kinesis Data Firehose 的 CloudWatch Logs 订阅
订阅过滤器将容器日志从 CloudWatch Logs 流式传输到 Firehose，Firehose 以近乎实时的延迟缓冲并写入 S3。 awslogs 驱动程序集中容器日志。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：订阅过滤器将容器日志从 CloudWatch Logs 流式传输到 Firehose，Firehose 会缓冲并写入 S3。
● 场景匹配：订阅过滤器将容器日志从 CloudWatch Logs 流式传输到 Firehose，Firehose 会缓冲并写入 S3。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● ALB访问日志无法传递到CloudWatch Logs；他们只写入S3。
● CloudTrail 不会捕获 ALB 访问日志或 ECS 容器 stdout/stderr，因此无法满足此要求。
● CloudWatch Logs 导出任务是面向批量的，不适合近实时流式传输到 S3。
工作流：创建 Kinesis Data Firehose 的 CloudWatch Logs 订阅以传送到 S3 → 使用 ECS 任务定义中的 awslogs 日志驱动程序将 stdout/stderr 发送到 CloudWatch Logs 并确保 IAM。
阻止公共访问并使用权限最低的 CodeBuild 角色来获取
删除公共访问权限并授予 CodeBuild 服务角色最小的 S3 权限，以便构建使用临时角色凭据。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：删除公共访问权限并授予 CodeBuild 服务角色最小的 S3 权限，以便构建使用临时角色凭据。
● 场景匹配：删除公共访问权限并授予 CodeBuild 服务角色最小的 S3 权限，以便构建使用临时角色凭据。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 网络控制不会删除公共访问，也不会强制执行 IAM 身份验证。
● 静态凭证会增加暴露风险，并违反最低权限和凭证轮换最佳实践。
● 过度特权的权限和持续的公共访问不符合安全要求。
工作流：阻止公共访问并使用权限最低的 CodeBuild 角色来获取对象。
具有负载均衡和 Auto Scaling 功能的 AWS Elastic Beanstalk，配置 Amazon
这提供了托管部署和回滚，保持生产级共享数据库的独立性，并以较低的开销集中可搜索日志。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这提供了托管部署和回滚，保持生产级共享数据库的独立性，并以较低的开销集中可搜索日志。
● 场景匹配：这提供了托管部署和回滚，保持生产级共享数据库的独立性，并以较低的开销集中可搜索日志。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 纯粹为了保留日志而管理和循环 OpenSearch 域会增加大量运营开销。
● 将数据库放置在 Beanstalk 环境中会将其生命周期与应用程序联系起来，并且对于共享的生产数据库来说存在风险。
● 数据库缺乏多可用区，需要更多自定义部署编排和回滚管理。
工作流：将 AWS Elastic Beanstalk 与负载均衡和 Auto Scaling 结合使用，配置与 Beanstalk 环境分离的 Amazon RDS MySQL 多可用区实例，并将应用程序日志流式传输到 Amazon CloudWatch Logs，并保留 120 天。
使用自定义的 EC2 实例和专用主机的 AWS Config 记录
AWS Config 记录实例与专用主机之间的关系，自定义规则提供低开销、持续的合规性评估和报告。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：AWS Config 记录实例与专用主机之间的关系，自定义规则提供低开销、持续的合规性评估和报告。
● 场景匹配：AWS Config 记录实例和专用主机之间的关系，自定义规则提供低开销、持续的合规性评估和。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 依赖于用于补丁和配置状态的 Systems Manager 合规性功能，并且本身不验证专用主机放置。
● 服务有助于跟踪和强制执行许可证使用情况，但不会评估或报告专用主机上的 EC2 实例放置情况。
● 是可能的，但与本机配置合规性服务相比，会创建复杂的、高维护性的日志处理管道。
工作流：使用自定义 AWS Config 规则打开 EC2 实例和专用主机的 AWS Config 记录，该规则调用 Lambda 来评估主机放置并标记不合规实例，→ 使用 AWS Config 合规性报告。
向 CodeDeploy 部署组发送有关 ALB TargetResponseTime 的 CloudWatch 警报
ALB 将 TargetResponseTime 直接发布到 CloudWatch，CodeDeploy 可以监控附加的警报。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：ALB 将 TargetResponseTime 直接发布到 CloudWatch，CodeDeploy 可以监控附加的警报。
● 场景匹配：ALB 将 TargetResponseTime 直接发布到 CloudWatch，CodeDeploy 可以监控附加的警报。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 访问日志批量到达，需要解析代码。
● 目标运行状况检查检测可用性，而不是响应延迟阈值。
● X-Ray 可以分析延迟，但需要仪器和采样。
工作流：将 ALB TargetResponseTime 上的 CloudWatch 警报附加到 CodeDeploy 部署组，以便在违规时自动停止。
应用 DeletionPolicy：快照到 AWS::EC2::Volume + 使用 DeletionPolicy：保留在 AWS::RDS::DBInstance 上
这指示 CloudFormation 在随堆栈一起删除卷时创建 EBS 快照。 Retain 确保 CloudFormation 在堆栈删除或替换期间不会删除数据库实例，从而保留数据。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这指示 CloudFormation 在随堆栈一起删除卷时创建 EBS 快照。
● 场景匹配：这指示 CloudFormation 在随堆栈一起删除卷时创建 EBS 快照。保留保证。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 堆栈策略可以阻止更新，但不会创建 EBS 快照或在替换期间专门保留数据。
● 终止保护仅阻止堆栈删除，不会影响替换行为或快照。
● AWS Backup 独立于 CloudFormation，并且不满足使用 CFN 设置来保留删除或替换数据的要求。
工作流：将 DeletionPolicy: 快照应用到 AWS::EC2::Volume → 在 AWS::RDS::DBInstance 上使用 DeletionPolicy: Retain。
具有预构建自定义 AMI 的 Elastic Beanstalk
预烘焙依赖项以最短的启动时间，同时 Elastic Beanstalk 提供多可用区、ALB 和运行状况管理。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：预烘焙依赖项以最短的启动时间，同时 Elastic Beanstalk 提供多可用区、ALB 和运行状况管理。
● 场景匹配：预烘焙依赖项以最短的启动时间，同时 Elastic Beanstalk 提供多可用区、ALB 和运行状况管理。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 仍然在启动时执行繁重的引导，使实例预热缓慢。
● 现货容量是可中断的，并且不能解决缓慢的引导问题。
● 需要重新构建容器，并且不使用 EC2 AMI 来解决实例配置速度慢的问题。
工作流：具有预构建自定义 AMI 的 Elastic Beanstalk。
将实例移至 Standby 状态
备用将实例从流量和扩展中移除，同时保持其运行以进行开放式调试。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：备用将实例从流量和扩展中移除，同时保持其运行以进行开放式调试。
● 场景匹配：备用将实例从流量和扩展中移除，同时保持其运行以进行开放式调试。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 暂停新的启动，但不隔离特定实例或停止运行状况检查替换。
● 仅适用于终止期间且有时间限制，不适用于正在进行的服务中故障排除。
● 防止缩减事件，但不会停止基于运行状况检查的替换或从流量中删除。
工作流：将实例移至 Standby 状态。
SNS 主题、每条消息 Lambda、DynamoDB 表 foo
SNS 会针对每条发布的消息触发 Lambda，而 DynamoDB 是完全托管的无服务器键值数据库。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：SNS 会针对每条已发布的消息触发 Lambda，而 DynamoDB 是完全托管的无服务器键值数据库。
● 场景匹配：SNS 会针对每条发布的消息触发 Lambda，而 DynamoDB 是完全托管的无服务器键值数据库。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Athena 对静态数据运行查询，不适用于按事件计算；这为立即处理增加了不必要的间接。
● Timestream是一个时间序列数据库，而不是所需的通用键值存储。
● ElastiCache 是内存缓存，而不是用于持久性的无服务器持久键值数据库。
工作流：SNS 主题，每条消息 Lambda，DynamoDB 表 foo。
具有分区键 instanceId 和排序键 eventTime + 的 DynamoDB 表
通过使用基于时间的排序键的 instanceId 进行分区，可以为每个实例按日期进行高效的点查找和范围查询。 S3 事件通知本机调用 Lambda。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：通过使用基于时间的排序键的实例 ID 进行分区，可以实现按日期进行高效的点查找和范围查询。
● 场景匹配：通过使用基于时间的排序键的实例 ID 进行分区，可以实现按日期进行高效的点查找和范围查询。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 添加不必要的跃点，更适合连续日志流，而不是终止时的一次性消耗。
● 使用时间作为分区键会按时间戳分段数据，并使以实例为中心的查询和日期范围效率低下。
● 需要 CloudTrail 数据事件并增加复杂性，而本机 S3 事件通知更简单且专门构建。
工作流：使用分区键 instanceId 和排序键 eventTime 创建 DynamoDB 表 → 配置 S3 PUT 事件通知以触发将对象元数据写入 DynamoDB 的 Lambda 函数 → 使用。
Amazon FSx for Lustre 链接到 S3，具有承担的角色和安全性
FSx for Lustre 与 S3 集成，因此对象显示为文件，并且通过 IAM 角色和 VPC 安全组控制跨帐户的访问。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：FSx for Lustre 与 S3 集成，因此对象显示为文件，并且通过 IAM 角色和 VPC 安全组控制跨帐户的访问。
● 场景匹配：FSx for Lustre 与 S3 集成，因此对象显示为文件，并通过控制跨帐户的访问。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● EFS 不将 S3 对象呈现为文件；生命周期转换仅影响 EFS 存储类。
● ONTAP 不会将 S3 存储桶公开为 NFS 文件命名空间，并且 NFS 客户端不会使用 IAM 访问密钥进行身份验证。
● Mountpoint 为 S3 提供文件 API，但不是共享 POSIX 文件系统，并且缺乏 HPC 的完整文件系统语义。
工作流：Amazon FSx for Lustre 链接到 S3，并具有可承担的角色和安全组。
post_build 阶段，其中包含推送 Docker 映像的命令部分
post_build 中的命令仅在早期阶段成功后运行，确保推送仅在成功构建时发生。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：post_build 中的命令仅在早期阶段成功后运行，确保推送仅在成功构建时发生。
● 场景匹配：post_build 中的命令仅在早期阶段成功后运行，确保推送仅在成功构建时发生。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 无论成功还是失败，finally 序列都会运行，因此即使构建失败它也可以推送。
● install阶段是准备环境，会在构建完成之前推送，不符合要求。
● CodePipeline 可以编排各个阶段，但它本身并不能确保仅在成功时才从构建作业中进行推送，而无需适当配置构建规范。
工作流：添加 post_build 阶段，其中包含推送 Docker 映像的命令部分。
Amazon EventBridge 通过 CloudTrail 事件模式进行 AWS API 调用
EventBridge 可以过滤针对特定角色的 sts:AssumeRole 的 CloudTrail 事件，并立即调用 Lambda 将通知发布到 SNS。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：EventBridge 可以过滤针对特定角色的 sts:AssumeRole 的 CloudTrail 事件，并立即调用 Lambda 发布通知。
● 场景匹配：EventBridge 可以过滤针对特定角色的 sts:AssumeRole 的 CloudTrail 事件，并立即调用 Lambda 发布通知。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● CloudTrail Insights 会显示异常活动模式，并且不会针对每个特定 sts:AssumeRole 事件发出确定性警报。
● GuardDuty 检测威胁和异常，无法针对特定 IAM 的确切假设发出警报。
● 控制台登录事件不会捕获 STS 角色假设事件，因此这会错过正常登录的用户。
工作流：通过 CloudTrail 事件模式将 Amazon EventBridge 与 AWS API 调用结合使用，该事件模式筛选 AdminElevate 角色上的 sts:AssumeRole 并调用 AWS Lambda 将消息发送到 Amazon SNS 主题。
用于调用 Lambda 来检查最终尝试的 Glue 作业运行事件的 EventBridge 规则
Lambda 可以检查事件详细信息（状态、尝试、运行 ID），并仅在上次重试失败时发布到 SNS。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Lambda 可以检查事件详细信息（状态、尝试、运行 ID），并仅在上次重试失败时发布到 SNS。
● 场景匹配：Lambda 可以检查事件详细信息（状态、尝试、运行 ID），并仅在上次重试失败时发布到 SNS。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● EventBridge 模式无法评估尝试计数，因此它无法仅隔离最终重试失败。
● 当过滤可以通过 EventBridge 和 Lambda 完成时，可能但不必要地复杂。
● 指标不会区分最终重试和早期失败，因此任何失败都会触发警报。
工作流：Glue 作业运行事件的 EventBridge 规则调用 Lambda 以检查最终尝试失败并发布到 SNS。
具有不同标签的单独补丁组，映射到批准的基线，以及
使用补丁组和偏移维护时段进行分区会错开补丁和重新启动，同时强制执行基线。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：使用补丁组和偏移维护时段进行分区会错开补丁和重新启动，同时强制执行基线。
● 场景匹配：使用补丁组和偏移维护时段进行分区会错开补丁和重新启动，同时强制执行基线。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 单个补丁组和窗口可能会导致许多实例同时重新启动，从而降低可用性。
● 使用 Run Command 进行事件编排缺乏维护窗口速率控制和适当的补丁目标。
● 以 100% 并发运行会导致同时修补和重新启动。
工作流：创建具有不同标签的单独补丁组 → 映射到批准的基线，并安排两个运行 AWS-RunPatchBaseline 的不重叠的维护时段。
将 RDS 数据库凭证存储在 AWS Secrets Manager 中并附加
Secrets Manager 安全地存储和轮换 RDS 密码，而实例角色提供对密钥和 DynamoDB 的基于 IAM 的访问。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Secrets Manager 安全地存储和轮换 RDS 密码，而实例角色则提供对两者的基于 IAM 的访问。
● 场景匹配：Secrets Manager 安全地存储和轮换 RDS 密码，而实例角色则提供对两者的基于 IAM 的访问。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● DynamoDB 不使用数据库样式凭证，应通过 IAM 访问，因此存储不存在的凭证不会增加任何价值。
● 对于 EC2 工作负载来说，长期有效的 IAM 用户密钥是不必要的并且存在风险，EC2 工作负载应使用来自实例角色的短期凭证。
● 虽然 SecureString 已加密，但由于本机轮换，Secrets Manager 是 RDS 的首选，并且应使用 IAM 而不是存储的机密来访问 DynamoDB。
工作流：将 RDS 数据库凭证存储在 AWS Secrets Manager 中，并附加可以读取该密钥并调用 DynamoDB API 的 EC2 实例配置文件。
在专用主机上启动 EC2 实例并标记应用程序，然后使用
专用主机提供主机级控制和物理套接字的可见性，AWS Config 自定义规则可以持续标记不合规资源以获取合规性视图。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：专用主机提供主机级控制和物理套接字的可见性，AWS Config 自定义规则可以持续标记。
● 场景匹配：专用主机提供主机级控制和物理套接字的可见性，AWS Config 自定义规则可以持续标记。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 建议正确使用 AWS Config，但预留实例只是计费折扣，不满足基于套接字的许可。
● 专用实例提供单租户隔离，但不公开或控制每插槽许可所需的物理插槽库存。
● 服务目录管理配置目录和约束，但不是持续配置合规性监控的正确工具。
工作流：在专用主机上启动 EC2 实例并标记应用程序，→ 使用 AWS Config 自定义规则和 Lambda 函数来验证实例是否以所需的启动模式运行。
具有 vCenter Discovery Connector 和 EC2 代理的应用程序发现服务；查看
vCenter VM 的无代理收集和 EC2 的代理，具有内置的 Migration Hub 仪表板和最少的设置。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：vCenter 虚拟机的无代理收集和 EC2 的代理，具有内置的 Migration Hub 仪表板和最少的设置。
● 场景匹配：vCenter VM 的无代理收集和 EC2 的代理，具有内置的 Migration Hub 仪表板和最少的设置。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● AWS Config 跟踪 AWS 资源，并且不会清点本地 VMware VM 或主机级 MAC/IP 详细信息。
● 需要在每台机器上部署和管理SSM代理并构建报告管道，这比较费力。
● 重点关注受支持的 AWS 资源的漏洞发现，不会清点本地虚拟机或 MAC/IP 属性。
工作流：具有 vCenter Discovery Connector 和 EC2 代理的应用程序发现服务 → 在 Migration Hub 中查看。
AWS Config 必需标签，带有聚合器馈送 QuickSight
AWS Config 托管规则评估跨账户和区域的标签合规性；聚合器集中报告和仪表板的结果。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：AWS Config 托管规则评估跨账户和区域的标签合规性；聚合器集中报告和仪表板的结果。
● 场景匹配：AWS Config 托管规则评估跨账户和区域的标签合规性；聚合器集中报告和仪表板的结果。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 资源浏览器可帮助查找资源，但不会执行基于规则的连续标签合规性评估。
● 标签策略指导标准化并显示覆盖范围，但不会强制执行或持续评估适合仪表板的资源级别合规性。
● CloudTrail 记录 API 活动，而不是当前资源标签合规性状态。
工作流：AWS Config 需要标签，并通过聚合器提供 QuickSight。
具有目标跟踪 CPU 的 Auto Scaling 组，并在 3 年后安排
将针对不可预测的激增的动态扩展与针对可预测的非工作时间的预定合理规模相结合，从而提高成本和弹性。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：将针对不可预测的激增的动态扩展与针对可预测的非工作时间的预定合理规模相结合，从而提高成本和弹性。
● 场景匹配：将针对不可预测的激增的动态扩展与针对可预测的非工作时间的预定合理规模相结合，从而提高成本和弹性。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 通过承诺降低计算成本，但不增加弹性、运行状况检查或扩展/扩展行为。
● 仅基于时间的控制；没有基于健康的替代或对突然峰值的自动响应。
● 容量更便宜，但会受到中断，并且本身不会为不可预测的突发情况设置扩展策略。
工作流：创建一个具有目标跟踪 CPU 的 Auto Scaling 组，并安排在下班后至少 3 小时和工作日前 6 小时。
设置了 ALB 运行状况检查路径的 Web 服务中的就绪端点
公开测试后端和 RDS 可访问性的端点； ALB 运行状况检查使用此路径将目标标记为健康。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：公开测试后端和 RDS 可访问性的端点； ALB 运行状况检查使用此路径将目标标记为健康。
● 场景匹配：公开测试后端和 RDS 可访问性的端点； ALB 运行状况检查使用此路径将目标标记为健康。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 不驱动 ALB 目标运行状况，也不验证跨层连接。
● ECS 健康检查会影响任务生命周期，但 ALB 仍然使用自己的健康检查，并且默认情况下不会验证依赖项。
● ALB 无法使用 CloudWatch 警报状态来设置目标运行状况，并且这些指标不能证明依赖关系连接。
工作流：Web 服务中的就绪端点，并设置了 ALB 运行状况检查路径。
AWS Shield Advanced、Amazon CloudFront 前端，并强制执行最低权限安全
Shield Advanced 添加了托管 DDoS 保护，CloudFront 减少了源暴露，而最低权限 SG 则限制了攻击路径。 WAF 会过滤滥用模式和已知来源。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Shield Advanced 添加了托管 DDoS 保护，CloudFront 减少了源暴露，而最低权限 SG 则限制了攻击路径。
● 场景匹配：Shield Advanced 添加了托管 DDoS 保护，CloudFront 减少了源暴露，而最低权限 SG 则限制了攻击路径。 WAF。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 这些是治理和弹性措施，而不是有针对性的 DDoS 保护或边缘层缓解措施。
● DNS 故障转移可以重新路由，但不会阻止容量或应用层 DDoS，也不会屏蔽源头。
● 扩展容量试图吸收流量，而不是减少攻击面或提供专用的 DDoS 保护。
工作流：启用 AWS Shield Advanced → 使用 Amazon CloudFront 前端，并强制执行最低权限安全组 → 在边缘配置 AWS WAF 基于速率的规则和 IP 集，并将 VPC 网络 ACL 收紧到所需的端口和 CIDR。
Lambda AppSpec 中等待步骤的 BeforeAllowTraffic 挂钩
BeforeAllowTraffic 在别名转移之前执行，让您可以阻止流量，直到 Step Functions 执行完成。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：BeforeAllowTraffic 在别名转移之前执行，让您可以阻止流量，直到 Step Functions 执行完成。
● 场景匹配：BeforeAllowTraffic 在别名转移之前执行，让您可以阻止流量，直到 Step Functions 执行完成。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 在工作流程完成之前，金丝雀仍然会将一些流量转移到新版本，这违反了要求。
● 在 CodeDeploy 外部触发别名更改会绕过部署生命周期控制，并且不会与部署状态集成。
● AfterAllowTraffic 仅在别名已转移后运行，因此新版本将过早收到生产流量。
工作流：在 Lambda AppSpec 中使用 BeforeAllowTraffic 挂钩等待 Step Functions 运行完成。
在容器实例上重新启动 ECS 代理
重新启动 ECS 代理会清除陈旧状态并强制拉取新映像，从而修复旧映像的零星重复使用问题。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：重新启动 ECS 代理会清除陈旧状态并强制拉取新映像，从而修复旧映像的零星重复使用问题。
● 场景匹配：重新启动 ECS 代理会清除陈旧状态并强制拉取新映像，从而修复旧映像的零星重复使用问题。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 更改注册表不会解决 ECS 容器实例上的缓存映像或代理状态。
● 摘要可防止标记漂移，但不能解决间歇性代理缓存或拉取故障。
● 部署编排不会修复代理重复使用 EC2 主机上本地缓存的映像的问题。
工作流：在容器实例上重新启动 ECS 代理。
Amazon GuardDuty 并通过 EventBridge 将结果发送到 SNS
GuardDuty 检测 EC2 泄露行为，并与 EventBridge 和 SNS 集成以发出电子邮件警报。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：GuardDuty 检测 EC2 泄露行为，并与 EventBridge 和 SNS 集成以发出电子邮件警报。
● 场景匹配：GuardDuty 检测 EC2 泄露行为，并与 EventBridge 和 SNS 集成以发出电子邮件警报。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 表面 API 异常，但错过了 EC2 妥协的网络和运行时指标。
● Inspector 专注于漏洞扫描，而不是实时妥协检测。
● 侦探协助调查和可视化，而不是主要的检测和警报。
工作流：打开 Amazon GuardDuty 并通过 EventBridge 将结果发送到 SNS。
CloudTrail 到 CloudWatch Logs； PutBucketPolicy/DeleteBucketPolicy 上的指标过滤器；云监控报警
CloudTrail 捕获 S3 控制平面 API 调用；这些事件的指标过滤器可以立即发出 CloudWatch 警报。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudTrail 捕获 S3 控制平面 API 调用；这些事件的指标过滤器可以立即发出 CloudWatch 警报。
● 场景匹配：CloudTrail 捕获 S3 控制平面 API 调用；这些事件的指标过滤器可以立即发出 CloudWatch 警报。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● S3 事件通知不会发出 PutBucketPolicy 或 DeleteBucketPolicy 等策略更改事件。
● 服务器访问日志跟踪对象级请求，不包括存储桶策略更改。
● 检查公共读取暴露情况，而不是所有存储桶策略更新或更改。
工作流：CloudTrail 到 CloudWatch Logs → PutBucketPolicy/DeleteBucketPolicy 上的指标过滤器 → CloudWatch 警报。
保持平台版本为最新并选择强制新部署
强制新部署会替换任务，以便它们在当前最新的 Fargate 平台上启动。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：强制新部署会替换任务，以便它们在当前最新的 Fargate 平台上启动。
● 场景匹配：强制新部署会替换任务，以便它们在当前最新的 Fargate 平台上启动。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 可以工作，但对于简单地迁移到最新的 Fargate 运行时来说是不必要的复杂性。
● 平台版本未在任务定义中定义，无法在那里设置。
● 在部署取代任务之前，任务不会切换平台。
工作流：保持平台版本为最新并选择强制新部署。
引入单个流消费者 Lambda，将每条记录重新发布到 Amazon
每个分片只有一个消费者，可以防止读取器争用，并且 SNS 提供可扩展的扇出，因此多个 Lambda 可以处理相同的事件，而无需额外的分片读取器。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：每个分片只有一个消费者，可以防止读取器争用，并且 SNS 提供可扩展的扇出，以便多个 Lambda 可以进行处理。
● 场景匹配：每个分片只有一个消费者，可以防止读取器争用，并且 SNS 提供可扩展的扇出，以便多个 Lambda 可以进行处理。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● DAX 可加速表读取，并且不会改变 DynamoDB 流的使用方式，因此它不会解决流上的限制问题。
● RCU 影响表读取吞吐量，而不是 DynamoDB Streams 读取器限制，因此这不会解决流使用者限制问题。
● 并行化增加了单个消费者的并发性，但不会绕过每个分片读取器的限制，并且可能会加剧多个消费者之间的争用。
工作流：引入单个流使用者 Lambda，它将每条记录重新发布到 Amazon SNS 主题，并让现有和未来的 Lambda 订阅该主题。
Amazon FSx for Lustre 链接到 S3 存储桶，启用跨账户
FSx for Lustre 通过数据存储库与 S3 集成，因此对象显示为文件，并且通过假定的 IAM 角色适当地处理跨账户访问。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：FSx for Lustre 通过数据存储库与 S3 集成，因此对象显示为文件和跨账户访问。
● 场景匹配：FSx for Lustre 通过数据存储库与 S3 集成，因此对象显示为文件和跨账户访问。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● FSx for NetApp ONTAP 本身并不公开 S3 对象，因为文件和 FSx 服务不支持。
● FSx for Windows File Server 针对 SMB/NTFS 工作负载，不提供基于文件的 S3 对象视图。
● FSx for OpenZFS 不会将 S3 对象显示为本机文件命名空间，因此它无法基于 S3 文件。
工作流：部署链接到 S3 存储桶的 Amazon FSx for Lustre → 使用基于身份的策略启用跨账户可承担的 IAM 角色，并使用安全组来管理文件系统访问。
具有 EC2 Spot 实例的 Amazon Elastic 文件系统
这将托管、共享 POSIX 文件系统与低成本可中断计算相结合，并支持基于检查点的重启。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这将托管、共享 POSIX 文件系统与低成本可中断计算相结合，并支持基于检查点的重启。
● 场景匹配：这将托管、共享 POSIX 文件系统与低成本可中断计算相结合，并支持基于检查点的重启。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 提供共享文件系统，但使用按需实例并不能最大限度地降低可中断工作负载的计算成本。
● EBS 卷附加到各个实例，而不是并发共享文件系统，并且预留实例未针对中断容忍成本节省进行优化。
● S3 是对象存储，而不是 POSIX 可安装的共享文件系统，并且按需实例会增加容忍中断的工作负载的成本。
工作流：具有 EC2 Spot 实例的 Amazon Elastic 文件系统。
具有跨账户 IAM 角色和基于标签的 TerminateInstances 条件的 AWS Organizations
在共享帐户中使用 OU 和每团队角色，应用具有资源和主体标签的 ABAC 将 TerminateInstances 限制为拥有的实例。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：在共享帐户中使用 OU 和每团队角色，应用具有资源和主体标签的 ABAC 将 TerminateInstances 限制为拥有的实例。
● 场景匹配：在共享帐户中使用 OU 和每团队角色，应用具有资源和主体标签的 ABAC 将 TerminateInstances 限制为拥有的实例。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 添加全局保护和批准，但不强制跨帐户进行基于所有者的授权。
● SCP 提供护栏，无法授予细粒度的所有者特定权限；他们仍然需要 IAM 策略执行。
● 这些提供可见性和治理，但不强制执行每个资源的终止授权。
工作流：具有跨账户 IAM 角色和基于标签的 TerminateInstances 条件的 AWS 组织。
公有子网中具有弹性 IP 的 NAT 网关
公有子网中具有弹性 IP 的 NAT 网关使私有子网中的实例能够访问 Internet，但无法从 Internet 访问。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：公有子网中具有弹性 IP 的 NAT 网关允许私有子网中的实例进行访问。
● 场景匹配：公有子网中具有弹性 IP 的 NAT 网关允许私有子网中的实例进行访问。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 客户网关用于站点到站点 VPN，并且 ALB 无法路由到它，因此这不会。
● Internet 网关没有可列入白名单的 IP，并且私有子网无法路由到没有公共 IP 的 IGW。
● VPC 终端节点私下连接到受支持的 AWS 服务，而不是任意 Internet 主机，并且编写 EIP 脚本不会修复私网问题。
工作流：使用弹性 IP 在公有子网中创建 NAT 网关，并更新私有子网路由表以将 Internet 绑定流量发送到 NAT 网关。
来自一个 GitHub 存储库的两条 CodePipelines 使用 env 分支，自动分段
它使用两条管道，保留一个源存储库，自动部署暂存，并在生产前放置一个手动门。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：它使用两个管道，保留一个源存储库，自动部署暂存，并在生产之前放置一个手动门。
● 场景匹配：它使用两条管道，保留一个源存储库，自动部署暂存，并在生产前放置一个手动门。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 使用一条管道并自动部署生产。
● 单独的管道是可行的，但分段中的手动批准会阻止自动部署。
● 生产没有人工审批，没有把好关键的安全控制。
工作流：来自一个 GitHub 存储库的两个 CodePipelines 使用 env 分支，自动推送，生产具有手动批准 → 通过 CloudFormation 部署。
添加到负载均衡器
防止新启动的实例附加到 ALB 目标组，从而阻止它们接收客户端流量。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：防止新启动的实例附加到 ALB 目标组，从而阻止它们接收客户端流量。
● 场景匹配：防止新启动的实例附加到 ALB 目标组，从而阻止它们接收客户端流量。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 跨可用区重新平衡容量，但不控制 ALB 目标注册。
● 停止替换不健康实例，但不停止新实例的 ALB 注册。
● 完全阻止新实例启动，而不是阻止流向它们的流量。
工作流：添加到负载均衡器。
DynamoDB：分区键instanceId，排序键eventTime + S3 PutObject事件
instanceId 作为分区键，eventTime 作为排序键，支持直接按实例查找和日期范围查询。 S3上传事件可以立即调用Lambda。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：instanceId 作为分区键，eventTime 作为排序键，支持直接按实例查找和日期范围查询。
● 场景匹配：instanceId 作为分区键，eventTime 作为排序键，支持直接按实例查找和日期范围查询。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● S3 库存是定期的，不是即时的。
● 该链可以进行设计，但 CloudWatch Logs 和 Firehose 会为一次性日志消耗添加不必要的跃点。
● 使用时间作为分区键与实例 ID 的主查询不匹配，并且可能会创建不均匀或热时间分区。
工作流：DynamoDB：分区键 instanceId、排序键 eventTime → S3 PutObject 事件到 Lambda 将元数据写入 DynamoDB → ASG 终止生命周期挂钩调用 Lambda 运行 SSM Run Command 并将日志复制到 S3。
具有 SAML IdP 的 Amazon Cognito 用户池以及 Cognito 身份池
用户池提供品牌注册/登录和 SAML 联合，身份池则用令牌交换短期 AWS 凭证。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：用户池提供品牌注册/登录和 SAML 联合，身份池则用令牌交换短期 AWS 凭证。
● 场景匹配：用户池提供品牌注册/登录和 SAML 联合，身份池则用令牌交换短期 AWS 凭证。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● ALB 身份验证可以控制访问权限，但不提供完整的注册/登录 UI 或为客户端交换 AWS 凭证的令牌。
● Lambda 授权方不执行 SAML Web 登录流程或提供面向用户的注册体验。
● AssumeRoleWithWebIdentity 适用于 OIDC； SAML 需要 AssumeRoleWithSAML，并且不提供内置注册/登录 UI。
工作流：具有 SAML IdP 的 Amazon Cognito 用户池 → 用于临时 AWS 凭证的 Cognito 身份池。
CodePipeline 自定义操作，带有本地工作人员轮询工作和
长时间运行的外部任务支持使用作业工作者的自定义操作；它安全地轮询、在本地执行并向 CodePipeline 报告状态。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：长时间运行的外部任务支持使用作业工作者的自定义操作；它安全地轮询、在本地执行并向 CodePipeline 报告状态。
● 场景匹配：长时间运行的外部任务支持使用作业工作者的自定义操作；它可以安全地进行轮询。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Step Functions 编排工作流程，但不运行本地工具；您仍然需要持久的工作人员和回调集成。
● Lambda 的最大持续时间为 15 分钟，无法容纳约 120 分钟的扫描。
● CodePipeline 没有本机运行命令操作；它需要额外的编排和轮询，使其不太适合可靠的工作状态报告。
工作流：CodePipeline 自定义操作，由本地作业人员轮询作业并发布结果。
关于 EC2 实例最大 CPU 指标的 Amazon CloudWatch 警报以及
CodeDeploy 可以监控 CloudWatch 警报，并在流量转移期间 EC2 CPU 警报中断时自动回滚部署。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CodeDeploy 可以监控 CloudWatch 警报，并在流量转移期间 EC2 CPU 警报失效时自动回滚部署。
● 场景匹配：CodeDeploy 可以监控 CloudWatch 警报，并在 EC2 CPU 警报发生时自动回滚部署。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Auto Scaling 策略可以增加容量，但不会根据 CPU 阈值触发 CodeDeploy 回滚。
● CodeDeploy 回滚集成可与 CloudWatch 警报配合使用，并且 ALB 不会公开 CPU 指标。
● ValidateService 在流量转移到 ALB 之后之前运行，因此它无法评估实时负载下的 CPU，也不是预期的回滚机制。
工作流：针对 EC2 实例的最大 CPU 指标创建 Amazon CloudWatch 警报，并使用该警报在 CodeDeploy 部署组中启用自动回滚。
Amazon Route 53 基于延迟的路由，并对区域 API 网关进行运行状况检查
基于延迟的路由将客户端定向到延迟最低的 API 端点，同时运行状况检查支持故障转移，DynamoDB 全局表提供多区域、主动-主动数据访问。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：基于延迟的路由将客户端定向到延迟最低的 API 端点，同时运行状况检查支持故障转移，DynamoDB 全局表提供多区域、主动-主动数据访问。
● 场景匹配：基于延迟的路由将客户端定向到延迟最低的 API 端点，同时运行状况检查启用故障转移和 DynamoDB 全局表。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 地理位置路由根据用户的地理来源而不是最低延迟路径发送用户，因此它不会针对跨区域的最小延迟进行优化。
● Global Accelerator 和 ALB 增加了复杂性，并且不能直接为 API Gateway 提供最佳的多区域、按请求延迟控制。
● 故障转移路由优先考虑主动-被动弹性，而不是跨多个区域分配流量以实现最低延迟。
工作流：使用 Amazon Route 53 基于延迟的路由，通过区域内 Lambda 和 DynamoDB 全局表对区域 API 网关终端节点进行运行状况检查。
使用 AWS Athena + 启用访问日志来分析日志
Athena 是无服务器且按查询付费的，非常适合偶尔分析 S3 中存储的日志。 ALB访问日志记录将详细的请求记录写入S3中。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Athena 是无服务器且按查询付费的，非常适合偶尔分析 S3 中存储的日志。
● 场景匹配：Athena 是无服务器且按查询付费的，非常适合偶尔分析 S3 中存储的日志。 ALB 访问。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 目标组不支持访问日志，这些日志仅在负载均衡器本身上可用。
● CloudWatch Logs 代理旨在连续流式传输到 CloudWatch Logs，不适合一次性。
● 与无服务器查询服务相比，EMR 通常会因零星工作负载而产生更高的成本和开销。
工作流：使用 AWS Athena 分析日志 → 在应用程序负载均衡器上启用访问日志 → 创建终止生命周期挂钩并通过 EventBridge 触发 Lambda 运行 SSM Run Command 将应用程序日志复制到 S3。
UpdatePolicy AutoScalingRollingUpdate 与 MinInstancesInService
此 CloudFormation UpdatePolicy 执行 Auto Scaling 组的滚动更新，同时确保最少数量的实例保持在服务状态。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：此 CloudFormation UpdatePolicy 执行 Auto Scaling 组的滚动更新，同时确保最少数量的实例保持在服务状态。
● 场景匹配：此 CloudFormation UpdatePolicy 执行 Auto Scaling 组的滚动更新，同时确保最少数量的实例保持在服务状态。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● UpdateReplacePolicy 管理替换时的保留/快照行为，并且不支持 Auto Scaling 组的 MinSuccessfulInstancesPercent 或 MaxBatchSize 等滚动更新控件。
● 更改集仅预览更改，不控制更新期间的滚动行为或最小服务容量。
● 触发 Auto Scaling 组的全面替换，而不是受控滚动更新，从而存在服务中断的风险。
工作流：使用 MinInstancesInService 配置 UpdatePolicy AutoScalingRollingUpdate。
ASG 的 CodeDeploy 蓝/绿，BlueInstanceTerminationOption=TERMINATE 且终止WaitTimeInMinutes=120
EC2/Auto Scaling 的 CodeDeploy 蓝/绿支持流量转移和原始实例的定时终止。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：EC2/Auto Scaling 的 CodeDeploy 蓝/绿支持流量转移和原始实例的定时终止。
● 场景匹配：EC2/Auto Scaling 的 CodeDeploy 蓝/绿支持流量转移和原始实例的定时终止。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Elastic Beanstalk 可以交换 URL，但应用程序版本生命周期不会在几分钟内安排环境终止。
● 是自定义编排，缺乏原始队列的本机定时终止设置。
● ECS 蓝/绿适用于 ECS 服务和任务，而不适用于 EC2 Auto Scaling 组。
工作流：ASG 的 CodeDeploy 蓝/绿，BlueInstanceTerminationOption=TERMINATE 且 TerminationWaitTimeInMinutes=120。
Amazon Inspector 对 EC2 实例进行持续漏洞扫描并安装
Amazon Inspector 可自动执行漏洞检测，CloudWatch 代理可集中操作系统日志（例如身份验证和安全日志）以进行审核。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Amazon Inspector 可自动执行漏洞检测，CloudWatch 代理可集中操作系统日志，例如身份验证和安全日志。
● 场景匹配：Amazon Inspector 可自动执行漏洞检测，CloudWatch 代理可集中操作系统日志，例如身份验证和安全日志。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Security Hub 聚合发现结果，CloudTrail 记录 API 操作，但 CloudTrail 不会捕获来宾操作系统登录活动。
● GuardDuty 检测威胁而不是软件漏洞，X-Ray 跟踪应用程序而不是收集操作系统登录日志。
● 补丁管理器评估并应用补丁，而不是执行完整的漏洞扫描，KCL 用于使用 Kinesis Data。
工作流：使用 Amazon Inspector 对 EC2 实例进行持续漏洞扫描，并安装 Amazon CloudWatch 代理以将系统日志（包括登录事件）流式传输到 Amazon CloudWatch Logs。
Auto Scaling 组设置为 MinSize=1 的 CloudFormation 子模板
这提供了自我修复，通过重用 ENI 保留静态私有 IP，并通过嵌套的 CloudFormation 堆栈使用最少的自定义代码来扩展模式。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这提供了自我修复，通过重用 ENI 保留静态私有 IP，并使用最少的自定义代码扩展模式。
● 场景匹配：这提供了自我修复，通过重用 ENI 保留静态私有 IP，并使用最少的自定义代码扩展模式。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Beanstalk 抽象实例详细信息，并且不会以最小的工作量本地管理静态 ENI 附件和确定性的每个实例主机名。
● 依赖手动或临时执行以及自定义逻辑进行恢复，这不是最省力的，也不是完全自动化的。
● 与更简单的方案相比，增加了复杂性，并且本质上不能保证替换过程中持久的 ENI 连接或静态主机名。
工作流：创建一个 CloudFormation 子模板，其中 Auto Scaling 组设置为 MinSize=1 和 MaxSize=1，该子模板附加指定的 ENI 并在启动时设置主机名， → 使用 a.
使用跨账户角色进行自我管理权限的 CloudFormation StackSets
支持通过在源账户中创建管理员角色并在每个目标账户中创建执行角色来部署到外部账户，而无需 AWS Organizations。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：支持通过在源账户中创建管理员角色并在每个目标账户中创建执行角色来部署到外部账户，而无需 AWS Organizations。
● 场景匹配：支持通过在源账户中创建管理员角色并在每个目标账户中创建执行角色来部署到外部账户，而无需 AWS Organizations。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 需要在共享组织下的 Control Tower 登陆区域中注册帐户，这在此处是不允许的。
● 可能，但与 StackSet 相比增加了重要的设置和持续操作，并且不是最直接的选择。
● 要求目标账户位于同一 AWS 组织中并启用可信访问，但这是不允许的。
工作流：CloudFormation StackSets 具有使用跨账户角色的自我管理权限。
修改应用程序运行状况端点，仅在可以时返回200
ALB 目标运行状况由 HTTP 状态代码确定，因此通过端点显示数据库可访问性可确保没有数据库连接的实例被标记为运行状况不佳并被删除。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：ALB 目标运行状况由 HTTP 状态代码确定，因此通过端点显示数据库可访问性可确保实例。
● 场景匹配：ALB 目标运行状况由 HTTP 状态代码确定，因此通过端点显示数据库可访问性可确保实例。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● ALB 目标组运行状况检查评估状态代码和超时，而不是响应正文，因此不支持负载内容的正则表达式匹配。
● Route 53 运行状况检查在 DNS 级别运行，无法选择 ALB 目标组后面的单个实例。
● 金丝雀改进了监控，但不影响 ALB 路由决策，因此用户仍然会被发送到不健康的目标。
工作流：修改应用程序运行状况端点，使其仅在可以到达数据库时返回 200，并配置 ALB 运行状况检查以调用该路径。
附加到 EC2 实例的 IAM 实例配置文件角色配置错误
如果实例角色在对象上缺少 s3:GetObject 或者具有不正确的信任或权限策略，S3 将返回 AccessDenied。限制主体的限制性资源策略。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：如果实例角色在对象上缺少 s3:GetObject 或者具有不正确的信任或权限策略，S3 将返回。
● 场景匹配：如果实例角色在对象上缺少 s3:GetObject 或者具有不正确的信任或权限策略，S3 将返回。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 阻止公共访问会阻止公共 ACL 和存储桶策略，但不会阻止授权 IAM 角色的访问。
● 对象锁定强制保留和合法保留，但不会阻止具有权限的主体读取，因此事实如此。
● 当权限正确时，静态服务器端加密不会更改读取的授权结果，因此不会。
工作流：附加到 EC2 实例的 IAM 实例配置文件角色配置错误 → S3 存储桶策略拒绝来自实例身份的请求。
生命周期挂钩到 Auto Scaling 组并启用热池
温池使预初始化的实例保持就绪状态，并且生命周期挂钩协调就绪情况，因此仅在实例运行状况良好时才发送流量。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：温池使预初始化的实例保持就绪状态，并且生命周期挂钩协调就绪情况，因此仅在实例运行状况良好时才发送流量。
● 场景匹配：温池使预初始化的实例保持就绪状态，并且生命周期挂钩协调就绪情况，因此仅在实例运行状况良好时才发送流量。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 备用用于故障排除和维护，而不是在流量高峰期间快速横向扩展。
● 手动扩展会增加运营负担，并带来过度配置和更高成本的风险。
● 通过过度配置进行预扩展会增加成本并浪费事件窗口之外的容量。
工作流：将生命周期挂钩添加到 Auto Scaling 组并启用温池以实现更快的横向扩展。
ALB 尚未启用该可用区
ALB 要求每个可用区显式启用子网；否则，那里不存在负载均衡器节点，并且不会路由任何请求。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：ALB 要求每个可用区显式启用子网；否则，那里不存在负载均衡器节点，并且不会路由任何请求。
● 场景匹配：ALB 要求每个可用区显式启用子网；否则，不存在负载均衡器节点。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 如果实例位于错误的目标组中，它们将不会收到流量；然而，如果 ASG 使用一个目标组，则通常不会将其隔离到单个新区域。
● 禁用跨区域会影响流量在已启用区域之间的平衡方式，但不会停止路由到已启用区域。
● 不健康的目标不会收到请求，但这将显示为运行状况检查失败，而不是可用区启用问题。
工作流：ALB 尚未启用该可用区。
eu-central-1 中的跨区域 Aurora 只读副本，将 RDS 事件通知配置为
来自 RDS 的事件驱动通知与自动升级和 DNS 故障转移相结合，最大限度地减少 RTO 并减少停机时间。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：来自 RDS 的事件驱动通知与自动升级和 DNS 故障转移相结合，最大限度地减少 RTO 并减少停机时间。
● 场景匹配：来自 RDS 的事件驱动通知与自动升级和 DNS 故障转移相结合，最大限度地减少 RTO 并减少停机时间。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 依赖于人工干预和临时 S3 页面，这会延长检测和恢复时间并增加停机时间。
● 计划轮询会引入长达间隔的检测滞后，从而延迟故障转移并增加停机时间。
● 从快照恢复可能需要数小时，并且比复制产生更高的 RTO 和 RPO，因此它无法最大限度地减少停机时间。
工作流：在 eu-central-1 中创建跨区域 Aurora 只读副本 → 将 RDS 事件通知配置到 SNS 主题 → 订阅在故障时提升副本的 Lambda 函数，并更新 Route 53 以将流量引导至辅助区域。
最低权限的 CloudFormation 执行角色，附加到堆栈，并允许 iam:PassRole
委托给最小范围的执行角色并授予 iam:PassRole 让 CloudFormation 承担创建资源的角色，同时遵守最小权限。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：委托给最小范围的执行角色并授予 iam:PassRole 让 CloudFormation 承担创建资源的角色，同时遵守最小权限。
● 场景匹配：委托给最小范围的执行角色并授予 iam:PassRole 让 CloudFormation 承担创建资源的角色，同时遵守最小权限。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 如果没有 iam:PassRole，CloudFormation 就无法承担执行角色并代表用户执行操作。
● 功能确认 IAM 更改，但不授予权限或允许传递角色。
● 堆栈策略控制堆栈资源的更新和保护；他们不授予调用者权限。
工作流：创建一个最低权限的 CloudFormation 执行角色 → 附加到堆栈，并允许 iam:PassRole。
Amazon EC2 Auto Scaling 将通知发送到 Amazon SNS 主题
每当 Auto Scaling 组记录失败的实例启动事件时，这都会直接向团队发出警报。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：每当 Auto Scaling 组记录失败的实例启动事件时，这都会直接向团队发出警报。
● 场景匹配：每当 Auto Scaling 组记录失败的实例启动事件时，这都会直接向团队发出警报。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 在实例运行后检测问题，并且不会在启动尝试失败时发出通知。
● 重点关注 EC2 API 错误，并可能会错过不作为 RunInstances 错误出现的 Auto Scaling 启动失败。
● 状态检查表明正在运行的实例存在问题，而不是启动过程中的故障。
工作流：配置 Amazon EC2 Auto Scaling 以将 EC2_INSTANCE_LAUNCH_ERROR 事件的通知发送到 Amazon SNS 主题。
AWS Compute Optimizer 用于分析历史利用率并遵循其调整规模建议
Compute Optimizer 分析历史指标并应用机器学习来建议最佳实例类型和大小，以提高利用率和成本效率。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Compute Optimizer 分析历史指标并应用机器学习来建议最佳实例类型和大小，以提高利用率和成本效率。
● 场景匹配：Compute Optimizer 分析历史指标并应用机器学习来建议最佳实例类型和大小，以实现更好的效果。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 添加监控和自动化，但不提供基于 ML 的规模调整建议，并且依赖于脆弱的阈值规则。
● Control Tower 和 Image Builder 解决治理和 AMI 管道问题，而不是工作负载调整或利用率优化。
● Trusted Advisor 提供基本检查，可能需要更高的支持级别，但它在详细调整规模方面不如 Compute Optimizer 全面。
工作流：使用 AWS Compute Optimizer 分析历史利用率并遵循其规模调整建议来调整 EC2 实例系列和大小。
将 SUCCESS 或 FAILED 负载从提供商发送到 CloudFormation
CloudFormation 等待提供商将 JSON 响应放入预签名的 ResponseURL，如果没有它，操作将继续进行。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudFormation 等待提供商将 JSON 响应放入预签名的 ResponseURL，如果没有它，操作将继续进行。
● 场景匹配：CloudFormation 等待提供商将 JSON 响应放入预签名的 ResponseURL，如果没有它，操作将继续进行。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● CloudFormation 会忽略自定义资源的 Lambda 返回值，并要求将响应发送到其 ResponseURL。
● 选择 AWS::CloudFormation::CustomResource 或 Custom:: 类型是有效的，但如果没有提供商响应，其本身不会完成堆栈。
● EventBridge 事件不满足明确需要对 ResponseURL 进行响应的 CloudFormation 自定义资源完成。
工作流：将 SUCCESS 或 FAILED 负载从提供商发送到 CloudFormation ResponseURL 预签名的 S3 URL。
每个实例的环境标签，使用 AWS 创建强化的 AMI
Systems Manager Automation 支持黄金 AMI 工作流程以缩短启动时间，而具有 KMS 加密功能的 Parameter Store SecureString 可以安全地向同一 AMI 提供环境机密。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Systems Manager Automation 支持黄金 AMI 工作流程以缩短启动时间，同时支持具有 KMS 加密的 Parameter Store SecureString。
● 场景匹配：Systems Manager Automation 支持黄金 AMI 工作流程以缩短启动时间，同时支持具有 KMS 加密的 Parameter Store SecureString。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Session Manager 提供交互式托管 shell 访问，而不是 AMI 创建功能，并从用户数据添加 Lambda。
● 补丁管理器的目标是操作系统补丁而不是应用程序烘焙，AppConfig 是为动态配置而不是存储机密而设计的。
工作流：向每个实例添加环境标签 → 使用 AWS Systems Manager Automation Runbook 创建强化的 AMI → 使用用户数据引导脚本读取标签并加载设置。
配置只读副本，将副本升级到目标主要版本
创建和升级只读副本，然后升级它并切换流量，最大限度地减少停机时间，并且可以使用 CloudFormation 进行编排。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：创建和升级只读副本，然后升级它并切换流量，最大限度地减少停机时间，并且可以使用 CloudFormation 进行编排。
● 场景匹配：创建和升级只读副本，然后升级它并切换流量，最大限度地减少停机时间，并且可以使用 CloudFormation 进行编排。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● AutoMinorVersionUpgrade 仅适用于次要版本更新，无法执行主要版本升级。
● DMS 可以最大限度地减少停机时间，但会增加迁移复杂性，并且不是现有实例的 CloudFormation 驱动的就地升级。
● 即使使用多可用区，就地主要版本升级也会导致停机，这并不是最小的。
工作流：配置只读副本，将副本升级到目标主要版本→升级它，→切换。
Elastic Beanstalk 使用不可变环境更新
这会在同一负载均衡器后面启动一个单独的临时 Auto Scaling 组，保留 CNAME，并在出现故障时丢弃新组。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这会在同一负载均衡器后面启动一个单独的临时 Auto Scaling 组，保留 CNAME，并在出现故障时丢弃新组。
● 场景匹配：这会在同一负载均衡器后面启动一个单独的临时 Auto Scaling 组，保留 CNAME，并在出现故障时丢弃新组。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 通过添加批次来维持容量，但仍更新就地队列，因此故障可能会影响当前实例，并且回滚速度较慢。
● 需要在环境之间进行 DNS CNAME 交换，这违反了避免任何 DNS 更改的要求。
● 批量更新实例，减少容量并可能影响部署期间的可用性。
工作流：配置 Elastic Beanstalk 以使用不可变环境更新。
CloudWatch 代理将应用程序日志推送到 CloudWatch Logs 并设置
两个数据源都位于 CloudWatch Logs 中，这使得 CloudWatch Logs Insights 可以一起查询它们。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：两个数据源都位于 CloudWatch Logs 中，这使得 CloudWatch Logs Insights 可以一起查询它们。
● 场景匹配：两个数据源都位于 CloudWatch Logs 中，这使得 CloudWatch Logs Insights 可以一起查询它们。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● CloudWatch Logs Insights 只能查询 CloudWatch Logs 中的数据，因此使用 S3 拆分目标会妨碍统一查询。
● 即使 Athena 可以查询 S3 数据，CloudWatch 代理本身也不会将日志直接发送到 S3。
● SQS 不是持久日志存储或查询服务，代理和 CloudTrail 都不支持 SQS 作为日志记录目标。
工作流：配置 CloudWatch 代理以将应用程序日志推送到 CloudWatch Logs，并设置 CloudTrail 将 API 事件传送到 CloudWatch Logs 日志组，→ 使用 CloudWatch Logs Insights 进行分析。
S3 服务器访问日志记录并查询日志文件
S3 服务器访问日志包含详细的请求记录，Athena 允许您以最少的设置进行无服务器分析。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：S3 服务器访问日志包含详细的请求记录，Athena 允许您以最少的设置进行无服务器分析。
● 场景匹配：S3 服务器访问日志包含详细的请求记录，Athena 允许您以最少的设置进行无服务器分析。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 有效，但引入了更多的摄取和数据仓库设置和维护工作。
● 虽然可能，但此管道更加复杂，并且对于大容量数据事件来说成本高昂。
● S3 事件通知不会发出 GET/read 事件，因此您无法通过这种方式捕获访问请求。
工作流：打开 S3 服务器访问日志记录，并使用外部表通过 Amazon Athena 查询日志文件，以获取每个对象的访问指标。
S3 服务器访问日志记录并将 Amazon Athena 与外部表结合使用
S3 访问日志包含每个请求的对象详细信息，Athena 可以使用 SQL 无服务器地查询它们，从而快速、低成本地洞察最常访问的对象。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：S3 访问日志包含每个请求的对象详细信息，Athena 可以使用 SQL 无服务器地查询它们，从而快速交付。
● 场景匹配：S3 访问日志包含每个请求的对象详细信息，Athena 可以使用 SQL 无服务器地查询它们，从而快速交付。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● S3 Storage Lens 提供聚合指标，但不提供对特定视频进行排名所需的每个对象请求的详细信息。
● Redshift Spectrum 需要 Redshift 集群，这会增加成本和设置时间，使其对于简单、临时的情况来说过于昂贵。
● 构建 Lambda 加 Firehose 加 OpenSearch 管道会增加操作复杂性和持续成本，而这对于批处理方式来说是不必要的。
工作流：启用 S3 服务器访问日志记录并将 Amazon Athena 与外部表结合使用来查询日志文件并识别热门 GET 和下载。
注册 CloudFormation StackSets 的委派管理员并使用服务管理权限 +
借助组织可信访问、服务管理的 StackSet 和委派管理，可以以较低的开销实现多账户、多区域部署。所有功能都需要启用可信访问，以便 CloudFormation StackSets 可以跨成员账户管理角色。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：借助组织可信访问、服务管理的 StackSet 和委派管理，可以以较低的开销实现多帐户、多区域部署。
● 场景匹配：借助组织可信访问、服务管理的 StackSet 和委派管理，可以以较低的开销实现多账户、多区域部署。所有功能。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Control Tower 不是跨多个账户和区域任意 CloudFormation 部署的通用机制。
● 合并计费模式不支持服务管理的 StackSet 所需的可信访问。
● 自我管理权限需要在每个帐户中创建和维护角色，从而增加了运营开销。
工作流：注册 CloudFormation StackSets 的委派管理员并使用服务托管权限 → 启用 AWS Organizations 中的所有功能。
具有 CodeCommit 源触发器的 AWS CodePipeline，添加 AWS CodeBuild
这提供了一个端到端的托管 CI/CD 管道，具有自动化测试和受控线性流量转移的 Lambda 以及回滚支持。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这提供了一个端到端的托管 CI/CD 管道，具有自动化测试和受控线性流量转移的 Lambda 以及回滚支持。
● 场景匹配：这为 Lambda plus 提供了一个端到端托管 CI/CD 管道，具有自动化测试和受控线性流量转移功能。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 依赖于自定义编排和手动流量管理，而不是具有内置回滚的托管部署策略。
● 造成无差异的繁重工作，缺乏托管 CI/CD 服务提供的标准化部署控制和自动回滚。
● 违反了增量流量转移的要求，因为所有流量都会立即转移到新版本。
工作流：使用 CodeCommit 源触发器创建 AWS CodePipeline → 添加 AWS CodeBuild 以进行自动化测试，并使用 AWS CodeDeploy 通过预定义的 CodeDeployDefault.LambdaLinear10PercentEvery1Minute 配置更新 Lambda 函数。
保持平均水平的 Spot 队列目标跟踪扩展策略
目标跟踪会自动调整容量，以使队列的平均 CPU 接近指定目标，并且可以通过 IaC 进行管理。预定的行动是理想的选择。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：目标跟踪会自动调整容量，以将机群的平均 CPU 保持在指定目标附近。
● 场景匹配：目标跟踪会自动调整容量，以将机群的平均 CPU 保持在指定目标附近。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 基于时间的方法无法随着需求的变化维持 CPU 利用率目标，因此它不满足动态 55。
● Application Auto Scaling 不支持 Lambda 的步进扩展，因此这不适用于该服务。
工作流：使用 CLI、SDK 或 CloudFormation 为 Spot 队列创建目标跟踪扩展策略，使平均 CPU 利用率接近 55% → 在 Application Auto Scaling 中使用计划扩展。
CodeDeploy AppSpec BeforeInstall 中的缓存清除 + AWS CodeBuild 中的构建和
在安装新版本之前，使用 BeforeInstall 生命周期挂钩清除每个实例上的缓存。 CodeBuild 生成工件，CodeDeploy 推出到 EC2。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：在安装新版本之前，使用 BeforeInstall 生命周期挂钩清除每个实例上的缓存。
● 场景匹配：在安装新版本之前，使用 BeforeInstall 生命周期挂钩清除每个实例上的缓存。 CodeBuild 生成。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 可以自动化构建，但缺乏完整的管道编排、阶段跟踪和本机回滚。
● 一般工作流服务，没有本机 CI/CD 管道功能、UI 或集成部署回滚（如 CodePipeline/CodeDeploy）。
● 管理应用程序环境，但不提供详细的多阶段管道可见性或每个部署的细粒度缓存清除挂钩。
工作流：安装前在 CodeDeploy AppSpec 中清除缓存 → 在 AWS CodeBuild 中构建并使用 AWS CodeDeploy 进行部署 → AWS CodePipeline 以及 Git 源进行编排。
对敏感 CloudFormation 参数进行 NoEcho + 将 Secrets Manager 与 CloudFormation 动态结合使用
NoEcho 用星号屏蔽参数值，以便它们不会出现在事件、控制台视图或描述 API 中。动态引用在部署时解析，无需在模板、堆栈事件或元数据中保留纯文本。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：NoEcho 用星号屏蔽参数值，以便它们不会出现在事件、控制台视图或描述 API 中。
● 场景匹配：NoEcho 用星号屏蔽参数值，以便它们不会出现在事件、控制台视图或描述 API 中。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 对静态模板进行加密不会阻止纯文本值显示在堆栈事件或 API 输出中。
● 自定义资源返回数据和日志可以在事件和 CloudWatch Logs 中显示秘密值。
● SSM 参数类型可以解析为可能出现在事件中的纯文本值，除非与 NoEcho 或动态引用结合使用。
工作流：在敏感的 CloudFormation 参数上设置 NoEcho → 将 Secrets Manager 与 CloudFormation 动态引用结合使用。
带有标签和 AWS Config 自定义规则 (Lambda) 的 EC2 专用主机
专用主机公开主机/套接字库存和放置控制；自定义 AWS Config 规则可以持续检测并显示不合规的启动。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：专用主机公开主机/套接字库存和放置控制；自定义 AWS Config 规则可以持续检测并显示不合规的启动。
● 场景匹配：专用主机公开主机/套接字库存和放置控制；自定义 AWS Config 规则可以持续检测并显示不合规的启动。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● SCP 限制 API 和标签策略验证标签格式，但它们无法强制执行专用主机租赁或执行连续配置合规性检查。
● 专用实例提供单租户隔离，但缺乏每插槽许可所需的主机/套接字可见性和控制。
● 服务目录限制配置，但不提供持续的偏差检测和合规性监控。
工作流：带有标签和 AWS Config 自定义规则 (Lambda) 的 EC2 专用主机。
CloudFormation 对 AMI ID 的 SSM 参数存储的动态引用
CloudFormation 可以在部署时解析 SSM Parameter Store 值，包括 AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudFormation 可以在部署时解析 SSM Parameter Store 值，包括 AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>。
● 场景匹配：CloudFormation 可以在部署时解析 SSM Parameter Store 值，包括 AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 是一种重写模板并增加不必要的复杂性和维护的自定义方法。
● CloudFormation 不会直接从 Image Builder 中提取最新的 AMI，而无需发布到 SSM 或使用自定义资源。
● Service Catalog 不会使 CloudFormation 模板自行自动解析最新的 AMI ID。
工作流：CloudFormation 对 AMI ID 的 SSM 参数存储的动态引用。
Auto Scaling 组实例上的 Elastic Load Balancing 运行状况检查
当为 Auto Scaling 组启用 ELB 运行状况检查时，被 ALB 标记为不健康的实例将被标记为不健康并自动替换。 CloudWatch 没有。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：当为 Auto Scaling 组启用 ELB 运行状况检查时，ALB 会标记为运行状况不佳的实例。
● 场景匹配：当为 Auto Scaling 组启用 ELB 运行状况检查时，ALB 会标记为运行状况不佳的实例。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● CPU 扩展不会修复故障实例或提供内存使用警报，因此它无法解决该问题。
● 基于状态检查的 EC2 自动恢复解决底层主机或操作系统问题，而不是应用程序内存泄漏。
工作流：对 Auto Scaling 组启用 Elastic Load Balancing 运行状况检查，以便终止和替换未通过 ALB 目标组检查的实例 → 在 Auto Scaling 上安装和配置 CloudWatch 代理。
将依赖项镜像到 Amazon S3，将 IAM 角色附加到
在 S3 中托管依赖项并使用网关 VPC 终端节点可将流量保留在没有公共 Internet 路径的 AWS 网络上，并使用最低权限的 IAM 访问。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：在 S3 中托管依赖项并使用网关 VPC 端点可以保持 AWS 网络上的流量。
● 场景匹配：在 S3 中托管依赖项并使用网关 VPC 端点可以保持 AWS 网络上的流量。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● NAT 网关仍然启用出站 Internet 访问，这违反了阻止任何 Internet 连接的要求。
● 仅出口 Internet 网关仅支持 IPv6，但仍允许出站 Internet 流量，这不能满足无 Internet 要求。
● 临时将出站地址列入白名单仍然需要 Internet 出口，并会带来操作风险，因为 AWS Config 仅监控而不强制执行修复。
工作流：将依赖项镜像到 Amazon S3 → 将 IAM 角色附加到实例，并通过 S3 网关 VPC 终端节点访问存储桶。
具有 CodeDeploy 蓝/绿部署的应用程序负载均衡器，将 Auto
这首先启动替换队列，通过自动修复在可用区之间实现负载平衡，转移至少一半的流量，在注册之前进行清理，并终止旧的。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这首先启动替换车队，通过自动修复在可用区之间实现负载平衡，转移至少一半的流量。
● 场景匹配：这首先启动替换车队，通过自动修复在可用区之间实现负载平衡，转移至少一半的流量。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 执行就地更新，使用有风险的一次性配置，并尝试在保留的 BlockTraffic 事件中运行脚本。
● 实例刷新无法运行 CodeDeploy 生命周期挂钩来进行流量前清理，并且不提供蓝/绿终止控制。
工作流：将应用程序负载均衡器与 CodeDeploy 蓝/绿部署结合使用，将 Auto Scaling 组和目标组关联到部署组 → 创建至少包含 50% 健康主机的自定义配置。
CodePipeline 中的 Lambda 门调用 AWS Health API
在活跃的区域事件期间，健康意识预检查会快速失败，以防止运行中停顿和不必要的成本。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：在活跃的区域事件期间，健康意识预检查会快速失败，以防止运行中停顿和不必要的成本。
● 场景匹配：在活跃的区域事件期间，健康意识预检查会快速失败，以防止运行中停顿和不必要的成本。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 在正在进行的区域健康事件期间，自动重试可能会反复失败，浪费时间和资源，而不是预防问题。
● 依赖手动调度会带来延迟，并且无法涵盖计划外事件或不断变化的健康事件。
● 蓝绿色降低了切换风险，但增加了成本，并且不能防止管道在区域卫生事件期间发生故障。
工作流：在 CodePipeline 中添加 Lambda 门，该门调用目标区域的 AWS Health API，并在活动事件可能影响部署时提前停止运行。
在管道中，添加 AWS CodeDeploy 操作以推出
具有手动批准操作的门控 STAGE 部署可实现手动验证并阻止错误版本的升级。 CodeBuild 可以运行自动化单元和功能测试。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：具有手动批准操作的门控 STAGE 部署可实现手动验证并阻止错误版本的升级。
● 场景匹配：具有手动批准操作的门控 STAGE 部署可实现手动验证并阻止错误版本的升级。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● GuardDuty 用于威胁检测，没有运行时行为分析包或功能测试功能，因此它会。
● Macie 专注于敏感数据发现和分类，而不是应用程序功能或部署验证。
● Amazon Inspector 评估漏洞和暴露情况，而不是功能正确性，并且运行时行为分析不用于应用程序。
工作流：在管道中 → 添加 AWS CodeDeploy 操作以将最新版本推出到 STAGE 环境，插入用于 QA 验证的手动批准步骤， → 添加 CodeDeploy 操作。
具有 CodeDeploy 金丝雀移位、挂钩和 CloudWatch 警报回滚的 AWS SAM
SAM DeploymentPreference 集成 CodeDeploy 以转移 Lambda 别名流量、运行前/后流量挂钩以及在发生警报时自动回滚。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：SAM DeploymentPreference 集成 CodeDeploy 以转移 Lambda 别名流量、运行前/后流量挂钩以及在发生警报时自动回滚。
● 场景匹配：SAM DeploymentPreference 集成 CodeDeploy 以转移 Lambda 别名流量、运行前/后流量挂钩以及在发生警报时自动回滚。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 更改集预览更新和堆栈可以回滚，但没有 Lambda 别名流量转移或生命周期验证挂钩。
● AppConfig 会切换配置，但不会发布 Lambda 版本、转移别名流量或根据 Lambda 错误自动回滚。
● API Gateway 金丝雀目标是阶段配置，而不是 Lambda 版本部署或 Lambda 代码回滚。
工作流：AWS SAM 具有 CodeDeploy 金丝雀转移、挂钩和 CloudWatch 警报回滚。
Auto Scaling 生命周期与 EventBridge 挂钩以触发 Lambda 并更新表
生命周期挂钩发出每个实例的事件和令牌，EventBridge 可以可靠地路由到 Lambda 以启动和终止更新。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：生命周期挂钩发出每个实例的事件和令牌，EventBridge 可以可靠地路由到 Lambda 以启动和终止更新。
● 场景匹配：生命周期挂钩发出每个实例的事件和令牌，EventBridge 可以可靠地路由到 Lambda 以启动和终止更新。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 脚本可能不会在终止或失败期间执行，从而导致更新不可靠。
● DesiredCapacity 是一个聚合指标，不提供每个实例的生命周期上下文。
● CloudTrail 交付可能会滞后并且缺乏生命周期令牌，从而存在更新延迟或错过的风险。
工作流：Auto Scaling 生命周期与 EventBridge 挂钩以触发 Lambda 并更新表 foo。
AWS SAM 与 CodeDeploy Canary10Percent10Minutes
SAM 将 Lambda 别名与 CodeDeploy、CloudWatch 警报、金丝雀转移和自动回滚集成。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：SAM 将 Lambda 别名与 CodeDeploy、CloudWatch 警报、金丝雀转移和自动回滚集成。
● 场景匹配：SAM 将 Lambda 别名与 CodeDeploy、CloudWatch 警报、金丝雀转移和自动回滚集成。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 加权别名在技术上是可行的，但 CloudFormation 本身并不能提供相同的内置运行状况监控和自动回滚工作流程。
● 支持增量部署，但每一步移动50%会暴露过多的流量。
● AppConfig 控制配置或功能公开，而不是 Lambda 代码版本流量转移。
工作流：AWS SAM 与 CodeDeploy Canary10Percent10Minutes。
NLB 访问 S3 存储桶的日志，打开 SSE-S3，允许 Delivery.logs.amazonaws.com
这遵循 AWS 指导，使用 S3 作为目标，授予所需的服务主体写入权限，静态加密并限制对的读取访问。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这遵循 AWS 指导，使用 S3 作为目标，授予所需的服务主体写入权限，并进行加密。
● 场景匹配：这遵循 AWS 指导，使用 S3 作为目标，授予所需的服务主体写入权限，并进行加密。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 允许服务写入，但不授予团队读取访问权限，并且可能还需要 KMS 密钥策略更新。
● NLB 访问日志不会传送到 CloudWatch Logs，并且仅支持传送到 S3。
● 保护交付和存储，但无法向平台团队提供读取日志的权限。
工作流：启用对 S3 存储桶的 NLB 访问日志 → 打开 SSE-S3 → 允许 Delivery.logs.amazonaws.com 通过存储桶策略进行写入，并使用 IAM 授予平台团队读取访问权限。
具有 Lambda 转换的 Kinesis Data Firehose，使用 Kinesis Agent 传送日志
Firehose 可以调用 Lambda 来标准化运行中的记录并直接写入 S3，并以每 GB 定价和最少的操作。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Firehose 可以调用 Lambda 来标准化运行中的记录并直接写入 S3，并以每 GB 定价和最少的操作。
● 场景匹配：Firehose 可以调用 Lambda 来标准化运行中的记录并直接写入 S3，并以每 GB 定价和最少的操作。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 胶水流作业持续运行，会产生 DPU 小时成本加上数据流成本，通常高于简单进行中转换的托管交付流。
● Spectrum 在查询时工作，通常需要 Redshift 集群和外部表，这会增加成本并且不执行摄取时间标准化。
● 对象 Lambda 在检索时进行转换，而不是在摄取期间进行转换，并且不会将标准化数据保留回 S3。
工作流：将 Kinesis Data Firehose 与 Lambda 转换结合使用，通过 Kinesis Agent 传送日志并传送到 S3。
Jenkins 精通多个可用区；通过以下方式在 AWS CodeBuild 中运行构建
多可用区控制器加上 CodeBuild 以最少的操作提供高可用性和弹性、按构建付费的执行。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：多可用区控制器加上 CodeBuild 以最少的操作提供高可用性和弹性、按构建付费的执行。
● 场景匹配：多可用区控制器加上 CodeBuild 以最少的操作提供高可用性和弹性、按构建付费的执行。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 可以是 HA，但您仍然可以操作和扩展代理节点，与托管构建相比会增加成本和工作量。
● 单可用区控制平面存在单点故障且可用性不高。
● 实现了 HA，但管理和扩展 EC2 代理会增加开销，并且成本效益可能较低。
工作流：Jenkins 跨多个可用区 → 通过 Jenkins 插件在 AWS CodeBuild 中运行构建。
更新 Auto Scaling 启动模板以包含 EBS 卷的 TagSpecifications
启动模板中的标记规范确保 EBS 卷在创建时由服务标记，无需额外的自动化。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：启动模板中的标记规范确保 EBS 卷在创建时由服务标记，无需额外的自动化。
● 场景匹配：启动模板中的标记规范确保 EBS 卷在创建时由服务标记，无需额外的自动化。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 有效，但在创建后而不是在启动时增加了操作复杂性和标签。
● 来自 Auto Scaling 组的标签传播仅适用于 EC2 实例，不适用于附加的 EBS 卷。
● AWS Config 会评估合规性，但无法阻止卷创建事件。
工作流：更新 Auto Scaling 启动模板以包含具有所需成本中心标签的 EBS 卷的标签规范。
具有强化 AMI 的 Auto Scaling 组，应用目标跟踪
这将针对不可预测的激增的动态扩展与针对可预测时间段的预定正确规模相结合，从而提高了成本效率和可靠性。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这将针对不可预测的激增的动态扩展与针对可预测期间的预定正确规模相结合，从而提高了成本效率。
● 场景匹配：这将针对不可预测的激增的动态扩展与针对可预测期间的预定正确规模相结合，从而提高了成本效率。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 提供基于时间的启动和停止，但缺乏弹性和基于健康的恢复，因此在不可预测的情况下无法提高可靠性。
● 减少计算成本承诺，但不会添加自动扩展或运行状况驱动的替换来处理可变需求。
● 预定容量对于突发的全球需求来说缺乏灵活性，并且仍然依赖于脚本；此外，计划实例已停用。
工作流：使用强化的 AMI 创建 Auto Scaling 组 → 对平均 CPU 应用目标跟踪，并添加计划操作以将最小值设置为下班后 4 次和工作日前 8 次。
上传后，读取对象ETag并与本地进行比较
对于没有特殊加密的单部分上传，ETag 等于对象的 MD5，并且可以与本地计算的摘要进行比较。设置Content-MD5使得。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：对于没有特殊加密的单部分上传，ETag等于对象的MD5，可以进行比较。
● 场景匹配：对于没有特殊加密的单部分上传，ETag等于Object的MD5，可以进行比较。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● S3 不会根据有效负载验证用户元数据，因此元数据哈希不会强制完整性。
● 客户端不向 S3 提供 MD5 尾随校验和；对于其他校验和算法，尾随校验和由 SDK 管理，而不是。
● 版本 ID 是对象版本的标识符，与内容校验和无关。
工作流：上传后，读取对象 ETag 并将其与本地计算的有效负载 MD5 进行比较 → 在 PutObject 上的 Content-MD5 标头中提供 MD5 值并执行操作。
EventBridge 目标：用于分离 AD 并创建 AMI + 的 SSM 自动化运行手册
EventBridge 可以触发 Systems Manager Automation Runbook 来执行终止前任务。生命周期挂钩会在 Terminate:Wait 中暂停终止，并发出 EventBridge 可以路由到自动化的事件。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：EventBridge 可以触发 Systems Manager Automation Runbook 来执行终止前任务。
● 场景匹配：EventBridge 可以触发 Systems Manager Automation Runbook 来执行终止前任务。生命周期挂钩会暂停终止。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● SNS 终止通知不会暂停终止，因此清理可以竞争或跳过，无需生命周期等待。
● Image Builder 通过管道创建黄金 AMI，其设计目的不是在缩减时运行每个实例的清理。
● 维护时段是按计划安排的，与 Auto Scaling 缩减事件或生命周期暂停无关。
工作流：EventBridge 目标：SSM 自动化运行手册，用于使用 EventBridge 规则分离 AD 并创建 AMI → Auto Scaling 生命周期挂钩（终止：等待）。
规则目标为调用 Slack 的 AWS Lambda 函数
Lambda 可以安全地转换 EventBridge 事件并将其转发到 Slack，而 EventBridge 本身并不支持 Slack。该模式捕获管道执行级别的故障，这正是所需要的。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Lambda 可以安全地转换 EventBridge 事件并将其转发到 Slack，而 EventBridge 本身并不支持 Slack。
● 场景匹配：Lambda 可以安全地转换 EventBridge 事件并将其转发到 Slack，而 EventBridge 本身并不支持 Slack。这个图案。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 匹配单个操作失败而不是端到端管道失败，因此它不符合要求。
● EventBridge 不提供本机 Slack 目标，因此不支持此配置。
● 电子邮件订阅不会将消息发送到指定的目的地 Slack。
工作流：将规则目标设置为 AWS Lambda 函数，该函数为 #platform-eng 通道调用 Slack 传入 Webhook → 配置与状态为 FAILED 的 CodePipeline Pipeline 执行状态更改事件匹配的 Amazon EventBridge 规则。
使用 CloudFormation 管理 Lambda 版本/别名并使用 API Gateway 阶段金丝雀
Lambda 别名支持版本之间的加权流量，并且 API Gateway 阶段金丝雀可以在升级前移动一小部分；两者均通过 CloudFormation 进行本地管理。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Lambda 别名支持版本之间的加权流量，并且 API Gateway 阶段金丝雀可以在升级前移动一小部分；两者均通过 CloudFormation 进行本地管理。
● 场景匹配：Lambda 别名支持版本之间的加权流量，并且 API Gateway 阶段金丝雀可以在之前移动一小部分。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● AppConfig 控制配置和功能切换，但不会路由 HTTP 流量或在 API Gateway 或 Lambda 上执行基于百分比的流量转移。
● Route 53 故障转移是二元主动-被动的，而不是基于百分比的金丝雀； CDK 是一个 IaC 工具，不会更改路由行为。
● 一次性和简单的路由可以立即移动 100% 的用户，提供无限制的暴露阶段。
工作流：使用 CloudFormation 管理 Lambda 版本/别名并使用 API Gateway 阶段金丝雀。
将 EC2 队列放置在多可用区 Auto Scaling 组中
此设计为应用程序提供容错扩展，为数据库提供高性能多主 Aurora，并使用 Amazon Inspector 进行持续漏洞评估。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：此设计为应用程序提供容错扩展，为数据库提供高性能多主 Aurora 以及持续的漏洞评估。
● 场景匹配：此设计为应用程序提供容错扩展，为数据库提供高性能多主 Aurora 以及持续的漏洞评估。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 提高应用程序和数据库的弹性，但 Macie 专注于 Amazon S3 中的敏感数据发现，并不提供。
● RDS for PostgreSQL 不提供真正的多主配置，因此这不符合规定的高可用性。
● GuardDuty 是一种威胁检测服务，用于分析遥测而不是执行主机和程序包漏洞扫描。
工作流：将 EC2 队列放置在应用程序负载均衡器后面的多可用区 Auto Scaling 组中 → 将 Amazon Aurora 与多主写入器结合使用以实现更高的吞吐量和高可用性，并启用 Amazon Inspector 进行持续的漏洞扫描。
用于目录的 Aurora MySQL 全球数据库； PII 和订单的区域本地 Aurora
这保留了关系模型，通过 Aurora Global Database 提供单一全局目录，并将受监管的数据存储在区域本地 Aurora 集群中。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这保留了关系模型，通过 Aurora Global Database 提供单一全局目录，并将受监管的数据存储在区域本地 Aurora 集群中。
● 场景匹配：这保留了关系模型，通过 Aurora Global Database 提供单一全局目录，并将受监管的数据存储在区域本地 Aurora 集群中。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Redshift 的目标是分析，而不是 OLTP，将其与 DynamoDB 混合需要进行重大重构。
● 从 Aurora MySQL 迁移到 DynamoDB 显着改变了数据模型和查询。
● S3 不是事务型关系存储，不满足目录的 OLTP 要求。
工作流：用于目录的 Aurora MySQL 全局数据库 → 用于 PII 和订单的区域本地 Aurora。
Auto Scaling 组使用 ELB 运行状况检查来验证
使用 ELB 运行状况检查可确保 ASG 根据正确端口和路径上的真实应用程序运行状况探测来替换实例。目标群体健康检查。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：使用 ELB 运行状况检查可确保 ASG 根据正确端口和路径上的真实应用程序运行状况探测来替换实例。
● 场景匹配：使用 ELB 运行状况检查可确保 ASG 根据实际应用程序运行状况探测来替换实例。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 当运行状况检查配置错误时，切换到 IP 目标并不能解决应用程序的可达性问题。
● ALB 仅支持 HTTP 或 HTTPS 侦听器，不支持 TCP。
● 此处无需迁移到 NLB，并且会删除有助于验证应用程序端点的 HTTP 级路径检查。
工作流：配置 Auto Scaling 组以使用 ELB 运行状况检查来验证自定义端口和路径上的服务 → 更新目标组运行状况检查以探测应用程序的自定义端口和特定运行状况端点。
与 Auto Scaling 实例启动和终止匹配的 Amazon EventBridge 规则
这会将事件扩展至 Lambda 以实时更新 S3 页面，并将可搜索日志存储在 CloudWatch Logs 中。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这会将事件扩展至 Lambda 以实时更新 S3 页面并存储可搜索日志。
● 场景匹配：这会将事件扩展至 Lambda 以实时更新 S3 页面并存储可搜索日志。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 捕获事件，但依赖于手动或计划导出，并且不会自动更新 S3 网页。
● Amazon S3 不是 EventBridge 规则支持的直接目标，因此无法通过这种方式更新页面。
● CloudTrail 记录 API 活动，但不更新 S3 网页，并且不适合近实时操作。
工作流：使用与 Auto Scaling 实例启动和终止事件匹配的 Amazon EventBridge 规则来调用 AWS Lambda 函数 → 该函数更新 S3 状态页面并将事件记录写入 Amazon CloudWatch Logs。
用于目录表和保留帐户的 Amazon Aurora 全球数据库
Aurora Global Database 为目录提供低延迟全局读取和快速跨区域复制，同时保留 SQL 并最大限度地减少区域表的代码更改。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Aurora Global Database 为目录提供低延迟全局读取和快速跨区域复制，同时保留 SQL 并最大限度地减少区域表的代码更改。
● 场景匹配：Aurora Global Database 为目录提供低延迟全局读取和快速跨区域复制，同时保留 SQL 并最大限度地减少区域表的代码更改。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 混合 SQL 和 NoSQL，并强制更改目录部分的查询和驱动程序，从而增加重构工作。
● 将所有表迁移到 DynamoDB 会用 NoSQL 替换关系模型和 SQL，需要对应用程序进行重大重写。
● Aurora 和 DynamoDB 的组合引入了两种数据模型和 API，这增加了复杂性和代码更改。
工作流：使用 Amazon Aurora 全球数据库作为目录表，并在 Amazon Aurora 中保留账户和 view_history。
AWS Systems Manager Patch Manager 中特定于环境的补丁基准，按以下方式标记实例
这利用带有补丁组和每个环境基线的补丁管理器来首先针对非生产，并以最少的配置实施不同的策略。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这利用带有补丁组和每个环境基线的补丁管理器来首先针对非生产，并以最少的配置实施不同的策略。
● 场景匹配：这利用带有补丁组和每个环境基线的补丁管理器来首先针对非生产并实施不同的策略。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 依赖于自定义脚本和手动基线逻辑，与使用补丁管理器相比，增加了操作工作量。
● 仅通过操作系统进行标记无法将生产与非生产隔离，从而存在对生产进行意外修补的风险。
● 维护窗口提供了计划，但仍然需要自定义补丁选择和目标逻辑，而无需补丁管理器基线。
工作流：在 AWS Systems Manager Patch Manager 中创建特定于环境的补丁基准，按环境、业务部门和操作系统标记实例，将它们组织到补丁组中，并将相应的基准应用于每个组。
预装应用程序的 Golden AMI；通过用户数据运行时配置
预烘焙应用程序消除了大部分引导时间，同时用户数据在引导时注入特定于环境的设置。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：预烘焙应用程序可以消除大部分引导时间，同时用户数据会在引导时注入特定于环境的设置。
● 场景匹配：预烘焙应用程序消除了大部分引导时间，同时用户数据在引导时注入特定于环境的设置。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 仍然在每个实例上执行冗长的安装，并且不会消除 27 分钟的安装时间。
● 烘焙易失性缓存数据会使图像在整个队列中变得陈旧且不一致。
● 编排 Lambda 来预加载实例本地缓存很脆弱，并且仍然会与频繁更改的数据耦合。
工作流：预装应用程序的 Golden AMI → 通过用户数据进行运行时配置。
Amazon Aurora MySQL 具有目录的跨区域只读副本；单独的极光集群
Aurora MySQL 与 MySQL 兼容，可实现最小的更改，支持跨区域副本以实现低延迟读取，并且按区域集群保持订单驻留。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Aurora MySQL 与 MySQL 兼容，可实现最小的更改，支持跨区域副本以实现低延迟读取，并且按区域集群保持订单驻留。
● 场景匹配：Aurora MySQL 与 MySQL 兼容，可实现最小的更改，支持跨区域副本以实现低延迟读取，并且按区域集群保持订单驻留。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 从关系型 MySQL 切换到 NoSQL 将需要对架构和代码进行重大更改，而不是最大限度地减少更改。
● 是关系型且兼容的，但在全局读取扩展方面通常比 Aurora 具有更高的副本滞后和更多的操作开销。
● 全球数据库会将订单复制到多个区域，从而违反了在原始区域保留订单数据的需要。
工作流：Amazon Aurora MySQL 具有用于目录的跨区域只读副本→每个区域有单独的 Aurora 集群用于订单。
CloudWatch Logs 订阅过滤器调用 AWS Lambda 函数来
这通过实时响应日志并定期终止标记的实例来提供端到端自动化，无需手动步骤或额外的服务器。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这通过实时响应日志并定期终止标记的实例（无需手动）来提供端到端自动化。
● 场景匹配：这通过实时响应日志并定期终止标记的实例（无需手动）来提供端到端自动化。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 在 SNS 通知后依赖人工干预，这不是完全自动化的。
● CloudWatch Alarms 无法直接发布到 SQS，并且对于此用例来说无需维护工作队列。
● CloudWatch Logs 订阅无法直接将事件传递到 Step Functions，从而使此设计无效。
工作流：创建一个 CloudWatch Logs 订阅筛选器，该筛选器调用 AWS Lambda 函数，以便在检测到 SSH 登录时使用 MARK_FOR_TERMINATION 标记源实例，并使用 Amazon EventBridge 计划规则。
将 AMI ID 放入 AWS Systems Manager Parameter Store 并使用
CloudFormation 可以在堆栈更新时直接解析 SSM 参数存储值，从而使简单的计划 UpdateStack 能够将环境滚动到最新的 AMI，而无需模板编辑。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudFormation 可以在堆栈更新时直接解析 SSM 参数存储值，从而实现简单的计划 UpdateStack 滚动。
● 场景匹配：CloudFormation 可以在堆栈更新时直接解析 SSM 参数存储值，从而实现简单的计划 UpdateStack 滚动。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 该方法需要在每个周期解析和修改每个模板，这是脆弱的并且无法扩展。
● CloudFormation 无法本机解析来自 AWS AppConfig 的参数，因此堆栈不会自动使用该值。
● 传递原始字符串参数需要知道每个模板的参数名称，当模板不一致时，这是难以管理的。
工作流：将 AMI ID 放入 AWS Systems Manager Parameter Store 中，并在 CloudFormation 中使用 SSM 参数类型，以便在更新时解析该值 → 触发计划的 EventBridge 规则。
AWS 开发运营工程决策模式
涵盖500个技术场景的讲座材料。每节课都会评估技术可行性、需求契合度、场景契合度、工程常识、被拒绝的替代方案以及实际工作流程。
在每个实例上安装并配置统一的 CloudWatch 代理以进行流式传输
统一的 CloudWatch 代理本机从 Linux 和 Windows 收集日志和其他指标，并直接与 CloudWatch Logs Insights 集成，以最大限度地减少运营开销。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：统一的 CloudWatch 代理本机从 Linux 和 Windows 收集日志和其他指标并直接集成。
● 场景匹配：统一的 CloudWatch 代理本机从 Linux 和 Windows 收集日志和其他指标并直接集成。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● SSM 代理用于 Systems Manager 操作，不是推荐的代理或本机代理，用于将日志传送到 CloudWatch Logs。
● 与 CloudWatch Agent 和 CloudWatch Logs Insights 相比，可以工作，但引入了额外的移动部件和设置，因此这不是最省力的路径。
● Amazon Inspector 专注于漏洞和暴露评估，而不是收集和分析系统和应用程序日志。
工作流：在每个实例上安装并配置统一的 CloudWatch 代理，以将日志流式传输到 CloudWatch Logs，→ 使用 CloudWatch Logs Insights 进行查询。
为 AWS X-Ray 守护程序构建映像，并将其推送到 ECR
将 X-Ray 守护程序作为 sidecar 容器运行并在任务定义中公开 UDP 2000 是从 ECS 任务收集跟踪的正确模式。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：将 X-Ray 守护程序作为 sidecar 容器运行并在任务定义中公开 UDP 2000 是。
● 场景匹配：将 X-Ray 守护程序作为 sidecar 容器运行并在任务定义中公开 UDP 2000 是。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Approach 在映像中放置 Elastic Beanstalk 特定的配置文件并调整端口，但不建议这样做。
● CloudTrail 记录 AWS API 活动，不用于应用程序级分布式跟踪或测量请求路径延迟。
工作流：为 AWS X-Ray 守护程序构建映像，将其推送到 ECR → 将其作为 ECS 任务中的 sidecar 运行，并通过任务定义端口映射打开 UDP 2000。
AWS CloudTrail 组织跟踪 + 带有组织聚合器的 AWS Config
CloudTrail 提供跨所有区域的组织范围管理事件审核日志，了解谁在何时做了什么。 Config 记录配置更改并根据规则对其进行评估，并使用聚合器实现集中多帐户合规性。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudTrail 提供跨所有区域的组织范围管理事件审核日志，了解谁在何时做了什么。
● 场景匹配：CloudTrail 提供跨所有区域的组织范围管理事件审核日志，了解谁在何时做了什么。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 审计管理器将控制映射到框架并收集证据，但不执行持续的配置评估。
● EventBridge 和 Lambda 可以自动进行修复，但这不是持续配置评估和审核的主要服务。
● Security Hub 聚合来自多个服务的安全结果，但不跟踪或评估详细的资源配置偏差。
工作流：AWS CloudTrail 组织跟踪 → AWS Config 与组织聚合器。
嵌套的 CloudFormation 模板，定义 Auto Scaling 组，最小值
每个代理的一个实例 ASG 通过标签重新附加正确的 EBS 卷来保留状态，同时提供基于运行状况的替换。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：每个代理的一个实例 ASG 通过标签重新附加正确的 EBS 卷来保留状态，同时提供基于运行状况的服务。
● 场景匹配：每个代理的一个实例 ASG 通过标签重新附加正确的 EBS 卷来保留状态，同时提供基于运行状况的服务。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● CloudFormation 不会自动重新创建在堆栈更新之外终止的实例，因此附件和恢复会自动重新创建。
● 单个 ASG 可以在没有匹配的预配置卷的情况下重新平衡到可用区，并且 EBS 卷无法跨可用区移动。
● 漂移检测是提供信息的，不能保证 EBS 卷的自动重新创建或有状态重新附加。
工作流：使用嵌套的 CloudFormation 模板，该模板定义一个 Auto Scaling 组（最小和最大为 1）以及一个标记为与该组匹配的 EBS 卷，包括用于附加的引导脚本。
在本地 Windows 服务器上安装 SSM 代理，使用激活码/ID 注册，以便
本地服务器必须通过混合激活进行注册，然后使用补丁管理器进行修补。需要 STS AssumeRole 信任的单个 SSM 服务角色。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：本地服务器必须通过混合激活进行注册，然后使用补丁管理器进行修补。
● 场景匹配：本地服务器必须通过混合激活进行注册，然后使用补丁管理器进行修补。单个 SSM 服务。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 快速设置并不能消除对本地服务器的混合激活和服务角色的需求。
● 混合实例带有 mi- 前缀，补丁管理器是修补的主要服务。
● Systems Manager 对本地服务器的管理不是无代理的；需要 SSM 代理和混合激活。
工作流：在本地 Windows 服务器上安装 SSM 代理 → 使用激活码/ID 注册，以便它们显示为 mi- 实例， → 通过补丁管理器进行补丁 → 为 Systems Manager 创建一个 IAM 角色（假设。
具有基于角色的 S3 和 DynamoDB 访问 + STS 的 Amazon Cognito 身份池
身份池联合登录并返回映射到最低权限 IAM 角色的 STS 临时凭证。将 OIDC 令牌交换为临时角色凭证，授予对 S3 和 DynamoDB 的范围访问权限。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：身份池联合登录并返回映射到最低权限 IAM 角色的 STS 临时凭证。
● 场景匹配：身份池联合登录并返回映射到最低权限 IAM 角色的 STS 临时凭证。兑换 OIDC 代币。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Directory Service 适用于企业目录，不会将社交或 OIDC 身份代理为公共移动应用程序的 AWS 凭证。
● 用户池处理身份验证，但其令牌无法在没有身份池或 STS 的情况下直接调用 AWS 服务。
● SAML 针对企业 IdP，并不适合典型的社交或 OIDC 移动登录。
工作流：具有基于角色的 S3 和 DynamoDB 访问的 Amazon Cognito 身份池 → STS AssumeRoleWithWebIdentity 与 OIDC 提供商。
在 PutObject 中发送 Content-MD5，仅在成功时继续 + 比较
提供 Content-MD5 使 S3 验证 MD5 服务器端并拒绝不匹配。对于单部分、未加密的上传，ETag 等于对象 MD5，从而可以进行验证。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：提供 Content-MD5 使 S3 验证 MD5 服务器端并拒绝不匹配。
● 场景匹配：提供 Content-MD5 使 S3 验证 MD5 服务器端并拒绝不匹配。对于单部分、未加密的上传，ETag 等于对象 MD5，从而可以进行验证。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 用户元数据未针对有效负载进行验证，因此 200 响应并不能确认完整性。
● 版本 ID 是标识符，而不是内容校验和。
● 多部分 ETag 不是完整对象的 MD5，不能用于 MD5 验证。
工作流：在 PutObject 中发送 Content-MD5，仅在成功时才继续 → 上传后将对象 ETag 与本地计算的 MD5 进行比较。
Lambda AppSpec 中的 BeforeAllowTraffic 生命周期挂钩等待
BeforeAllowTraffic 在别名转移之前运行，允许您阻止流量，直到 Step Functions 执行和 Fargate 任务完全完成。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：BeforeAllowTraffic 在别名转移之前运行，允许您阻止流量，直到 Step Functions 执行和 Fargate 任务完全完成。
● 场景匹配：BeforeAllowTraffic 在别名转移之前运行，允许您阻止流量，直到 Step Functions 执行和 Fargate。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● AfterAllowTraffic 仅在别名移动后运行，因此新版本已经在处理请求，这违反了要求。
● 在工作流运行时，金丝雀仍然会将部分流量路由到新版本，从而在重组完成之前冒着失败的风险。
● 不支持用于推进 Lambda 部署的 Step Functions-to-CodeDeploy 信号； CodeDeploy 通过钩子控制生命周期。
工作流：在 Lambda AppSpec 中添加 BeforeAllowTraffic 生命周期挂钩，等待 Step Functions 执行完成。
资源在 CloudFormation 外部发生更改且模板未更新
带外更改会产生偏差，从而阻止 CloudFormation 在回滚期间将资源恢复到之前的配置。缺少权限可能会阻止 CloudFormation 修改或恢复。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：带外更改会产生偏差，从而阻止 CloudFormation 在回滚期间将资源恢复到之前的配置。
● 场景匹配：带外更改会产生偏差，从而阻止 CloudFormation 在回滚期间将资源恢复到之前的配置。丢失的。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● CloudFormation 使用区域服务 API，不需要接口 VPC 终端节点来更新 VPC 资源，因此终端节点中断不太可能导致此回滚状态。
● 变更集是可选的规划工具，它们的缺失本身不会导致回滚失败。
● AWS Config 不是 CloudFormation 更新或回滚的先决条件，缺少它也不会产生 UPDATE_ROLLBACK_FAILED。
工作流：资源在 CloudFormation 外部发生更改，并且模板未更新 → 运行更新的 IAM 用户或角色缺少一些必需的权限。
使用多可用区环境的 AWS Elastic Beanstalk 应用程序
预构建的自定义 AMI 大大缩短了实例启动时间，而 Elastic Beanstalk 提供弹性多可用区扩展和托管负载平衡。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：预构建的自定义 AMI 大大缩短了实例启动时间，而 Elastic Beanstalk 提供弹性多可用区扩展和托管。
● 场景匹配：预构建的自定义 AMI 大大缩短了实例启动时间，而 Elastic Beanstalk 提供弹性多可用区扩展和托管。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 减少服务器管理，但需要容器化应用程序并重新架构，这可能不会立即缩短配置时间。
● 在启动时安装依赖项仍然会导致较长的预热时间，并且无法解决实例配置缓慢的问题。
● 现货产能可能会中断，固定目标产能缺乏弹性，从而损害弹性和可用性。
工作流：使用负载均衡器后面的多可用区环境通过 AWS Elastic Beanstalk 部署应用程序，并从 AWS Systems Manager Automation 构建的包含所有内容的自定义 AMI 启动实例。
将 CloudWatch 指标流上传到 Kinesis Data Firehose 传输流
Firehose 的指标流无需自定义代码即可将指标传送至 S3，从而能够以最少的工作量实现 Athena 查询的持久多年存储并在 QuickSight 中可视化。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Firehose 的指标流无需自定义代码即可将指标传送至 S3，从而实现 Athena 查询的持久多年存储。
● 场景匹配：Firehose 的指标流无需自定义代码即可将指标传送至 S3，从而实现 Athena 查询的持久多年存储。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 该方法有效，但需要自定义代码、调度、权限和持续维护，因此它不是最省力的选项。
● CloudWatch 指标不提供延长保留设置，因此此提案无法满足多年保留或合规性需求。
● CloudWatch 仪表板无法使用 S3 中存储的数据，因此此设计无法根据导出的指标生成仪表板。
工作流：将 CloudWatch 指标流设置为 Kinesis Data Firehose 传输流，该传输流将所有指标存储在 Amazon S3 中，使用 Athena 分析范围，并创建 QuickSight 控制面板。
具有别名目标的故障转移路由和评估目标运行状况 + Route 53
当主数据库运行状况不佳时，具有别名记录和评估目标运行状况的故障转移策略会返回辅助数据库。非别名记录需要运行状况检查和网络白名单，以便 Route 53 可以评估运行状况。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：当主数据库运行状况不佳时，具有别名记录和评估目标运行状况的故障转移策略会返回辅助数据库。
● 场景匹配：当主数据库运行状况不佳时，具有别名记录和评估目标运行状况的故障转移策略会返回辅助数据库。非别名记录需要运行状况检查和网络白名单，以便 Route 53 可以评估运行状况。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 提高可用性/性能，但不配置 Route 53 DNS 故障转移。
● 自定义自动化是不必要的，因为 Route 53 本身会处理故障转移。
● 返回多个健康答案，但不强制执行主到辅助故障转移。
工作流：使用别名目标进行故障转移路由并评估目标运行状况 → 针对非别名记录的 Route 53 运行状况检查 → 允许运行状况检查器 IP。
AWS-RunPatchBaseline SSM 文档，用于在整个队列中强制执行已批准的补丁基准
AWS-RunPatchBaseline 与 Patch Manager 配合使用，将基准应用于 Windows 和 Linux，从而提供集中、可审核的修补。 SSM 代理加上维护窗口可实现受控、可审核和。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：AWS-RunPatchBaseline 与 Patch Manager 配合使用，将基准应用于 Windows 和 Linux，从而提供集中、可审核的修补。
● 场景匹配：AWS-RunPatchBaseline 与 Patch Manager 配合使用，将基准应用于 Windows 和 Linux，从而提供集中、可审核的修补。 SSM。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● CloudFormation 不提供自动操作系统修补功能，因此尽管 AWS Config 提供了，但仍无法满足要求。
● 虽然可行，但在混合机群中构建和操作主机级工作流程是一项艰巨的任务，并且与实际情况不符。
● AWS-ApplyPatchBaseline 仅针对 Windows，因此不满足 Windows 和 Linux 混合要求。
工作流：使用 AWS-RunPatchBaseline SSM 文档在整个队列中强制执行已批准的补丁基准 → 在每个实例上安装 AWS Systems Manager 代理 → 验证暂存中的补丁， → 安排修补程序。
复制源中的 AMI，使用源 CMK 加密，允许目标
您必须使用客户管理的密钥进行加密，并允许目标帐户（通过密钥策略）在共享之前创建授权。 Auto Scaling 需要拨款。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：您必须使用客户管理的密钥进行加密并允许目标帐户（通过密钥策略）创建。
● 场景匹配：您必须使用客户管理的密钥进行加密并允许目标帐户（通过密钥策略）创建。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● AWS RAM 不共享 AMI 或重新加密它们； AMI 共享使用 EC2 启动权限和快照/KMS 访问。
● 使用 AWS 托管 KMS 密钥加密的 AMI 无法在启动时跨账户共享。
● EBS 默认加密不提供加密 AMI 所需的源 CMK 的跨账户权限。
工作流：复制源中的 AMI → 使用源 CMK 加密 → 允许目标在密钥上创建授权，→ 共享 AMI → 在目标中 → 创建 KMS 授权。
具有 SSM 代理和维护时段的 AWS Systems Manager 补丁管理器
提供带有基线、补丁组、维护时段和合规性报告的集中式混合补丁。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：提供带有基线、补丁组、维护时段和合规性报告的集中式混合补丁。
● 场景匹配：提供带有基线、补丁组、维护时段和合规性报告的集中式混合补丁。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 查找漏洞并确定其优先级，但不安排补丁部署或维护时段。
● 启用临时命令执行，但缺乏托管补丁基准、补丁组、计划和合规性视图。
● 跟踪配置和一致性，但不执行补丁编排。
工作流：具有 SSM 代理和维护时段的 AWS Systems Manager 补丁管理器。
使用激活在本地 Windows 服务器上安装 SSM 代理
这是正确的，因为混合节点必须通过激活注册才能显示为托管实例，而补丁管理器是操作系统的正确工具。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这是正确的，因为混合节点必须通过激活进行注册才能显示为托管实例。
● 场景匹配：这是正确的，因为混合节点必须通过激活进行注册才能显示为托管实例。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 不正确，因为混合激活需要 STS AssumeRole 信任的单个 Systems Manager 服务角色，而不是多个角色。
● 不正确，因为混合托管实例显示时带有 mi- 前缀，并且状态管理器不是主要修补程序。
工作流：使用激活码和 ID 在本地 Windows 服务器上安装 SSM 代理 → 注册它们，以便它们在控制台中显示为 mi- 前缀，并应用更新。
在服务器上安装 Amazon Kinesis Agent 以将日志发送到
Kinesis Data Firehose 可以调用 Lambda 进行动态转换，而 Kinesis Agent 则传送日志，从而为 S3 中的标准化数据提供低成本、无服务器的路径。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Kinesis Data Firehose 可以调用 Lambda 进行动态转换，而 Kinesis Agent 则传送日志，从而提供低成本、无服务器的服务。
● 场景匹配：Kinesis Data Firehose 可以调用 Lambda 进行动态转换，而 Kinesis Agent 则传送日志，从而提供低成本、无服务器的服务。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● QuickSight 用于可视化和临时分析，而不是用于在登陆 S3 之前进行低成本日志摄取或转换。
● Redshift Spectrum 需要 Redshift 集群和外部表，这增加了应在摄取前处理的任务的成本和复杂性。
● OpenSearch 引入了持续的集群成本，旨在用于搜索和分析，而不是经济的 pre-S3 规范化。
工作流：在服务器上安装 Amazon Kinesis Agent 以将日志发送到 Amazon Kinesis Data Firehose 传输流并启用 Lambda 转换以在写入 S3 之前进行规范化。
使用混合激活+附加到 Systems Manager 注册本地服务器
混合激活将本地主机注册为托管实例，以便 Patch Manager 可以定位它们。实例配置文件授予 SSM 代理注册和运行的权限。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：混合激活将本地主机注册为托管实例，以便 Patch Manager 可以定位它们。
● 场景匹配：混合激活将本地主机注册为托管实例，以便 Patch Manager 可以定位它们。实例配置文件给出。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● EventBridge 可以触发任务，但 Systems Manager 中的维护时段是限制修补时间范围的本机方法。
● Inspector识别漏洞但不直接进行修补；修复使用 SSM 补丁管理器。
● 服务器上的长期密钥不安全，并且不是 SSM 支持的加入方法。
工作流：使用混合激活向 Systems Manager 注册本地服务器 → 将 IAM 实例配置文件附加到 EC2 以进行 Systems Manager 访问 → 配置非工作时间的 Systems Manager 维护时段。
用于在终止中暂停的 EC2 Auto Scaling 生命周期挂钩：等待调试
终止生命周期挂钩将实例移至 Terminate:Wait，在继续终止之前给予连接、检查和发送心跳的时间。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：终止生命周期挂钩将实例移至 Terminate:Wait，在继续终止之前给予连接、检查和发送心跳的时间。
● 场景匹配：终止生命周期挂钩将实例移至 Terminate:Wait，在继续终止之前给予连接、检查和发送心跳的时间。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 仅停止可用区重新平衡，不会阻止基于运行状况检查的终止。
● 启动后延迟初始运行状况检查，但一旦实例被标记为不运行状况，则不会暂停终止。
● 实例保护会阻止缩减，但不会因运行状况检查失败而停止替换。
工作流：添加 EC2 Auto Scaling 生命周期挂钩以在终止：等待调试中暂停。
将成功或失败的 JSON 放入 CloudFormation ResponseURL
CloudFormation 要求提供商将响应发送到预签名的 ResponseURL 以完成操作。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudFormation 要求提供商将响应发送到预签名的 ResponseURL 以完成操作。
● 场景匹配：CloudFormation 要求提供商将响应发送到预签名的 ResponseURL 以完成操作。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 声明资源类型，但不向 CloudFormation 发出完成信号。
● CloudFormation 忽略 Lambda 返回值并等待 ResponseURL 回调。
● WaitCondition 是一种不同的模式，并且不完成自定义资源生命周期。
工作流：将成功或失败的 JSON 放入 CloudFormation ResponseURL。
Route 53 加权别名将一小部分且不断增长的百分比发送至
加权记录让您可以从较小的权重开始，然后增加权重以逐渐转移流量，而无需停机。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：加权记录让您可以从较小的权重开始，然后增加权重以逐渐转移流量，而无需停机。
● 场景匹配：加权记录让您可以从较小的权重开始，然后增加权重以逐渐转移流量，而无需停机。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 基于延迟的路由选择延迟最低的端点，并且不能进行固定百分比分割。
● 就地更新批量替换实例，不提供用户级百分比路由。
● Canary 配置仅适用于 Lambda，不适用于 ALB 后面的 EC2 Auto Scaling。
工作流：使用 Route 53 加权别名将较小且不断增长的百分比发送到第二个 ALB。
读取 CodeDeploy 中的 DEPLOYMENT_GROUP_NAME 环境变量的单个脚本，以及
DEPLOYMENT_GROUP_NAME 是一个内置变量，在 BeforeInstall 中运行脚本可以让您尽早配置日志记录，而无需额外的工具或每组脚本。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：DEPLOYMENT_GROUP_NAME 是一个内置变量，在 BeforeInstall 中运行脚本可以让您尽早配置日志记录，而无需额外操作。
● 场景匹配：DEPLOYMENT_GROUP_NAME 是一个内置变量，在 BeforeInstall 中运行脚本可以让您尽早配置日志记录，而无需额外操作。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 使用组 ID 并在 ApplicationStart 上运行是生命周期的后期，与流程早期的简单内置选项相比，这增加了复杂性。
● 在部署期间管理标签和运行 CLI 调用会增加凭证和操作开销，并且发生的时间会晚于必要的时间。
● CodeDeploy 挂钩脚本不支持任意自定义环境变量，并且依赖 ValidateService 并不是最佳时机。
工作流：使用单个脚本读取 CodeDeploy 中的 DEPLOYMENT_GROUP_NAME 环境变量，并在 BeforeInstall 挂钩中调用它来设置每个组的 NGINX 日志记录。
将 VPC 重新编号为不重叠、使用 AWS Transit Gateway、通过内部公开服务
重新寻址消除了重叠，Transit Gateway 提供可扩展的中心辐射型路由；内部 NLB 保持 HTTPS 私有。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：重新寻址消除了重叠，Transit Gateway 提供可扩展的中心辐射型路由；内部 NLB 保持 HTTPS 私有。
● 场景匹配：重新寻址消除了重叠，Transit Gateway 提供可扩展的中心辐射型路由；内部 NLB 保持 HTTPS 私有。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 对等网格无法进行操作扩展，并且无法连接具有重叠 CIDR 的 VPC。
● 云 WAN 仍然需要非重叠的路由域来实现端到端的可达性，并且本身无法修复重叠的 CIDR。
● PrivateLink 是私有的，可与重叠的 CIDR 配合使用，但需要每个服务、每个 VPC 端点，并且缺乏传递路由，从而阻碍了扩展。
工作流：将 VPC 重新编号为不重叠 → 使用 AWS Transit Gateway，通过内部 NLB 公开服务。
支持 AWS Config cloudtrail（45 分钟定期），EventBridge 触发 Lambda 调用 StartLogging
定期合规性检查可检测独立于 CloudTrail 交付的已禁用日志记录，并且 Lambda 会立即重新启用日志记录。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：定期合规性检查可检测独立于 CloudTrail 交付的已禁用日志记录，并且 Lambda 会立即重新启用日志记录。
● 场景匹配：定期合规性检查可检测独立于 CloudTrail 交付的已禁用日志记录，并且 Lambda 会立即重新启用日志记录。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 轮询并针对DeleteTrail而不是StopLogging，导致延迟并且不直接恢复日志记录。
● 防止将来禁用，但如果日志记录已经停止，则不会重新打开日志记录。
● 该规则会定期评估，而不是根据配置更改进行评估，并且默认情况下不会自动修复。
工作流：支持 AWS Config cloudtrail（45 分钟定期），EventBridge 触发 Lambda 调用 StartLogging。
CloudFormation 堆栈，用于创建 CodePipeline 来构建强化的 AMI 和
具有动态引用的 Parameter Store 为堆栈提供了一种可扩展、解耦且安全的方式，以便在部署时使用最新批准的 AMI。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：具有动态引用的参数存储为堆栈提供了一种可扩展、解耦且安全的方式来使用最新的参数。
● 场景匹配：具有动态引用的参数存储为堆栈提供了一种可扩展、解耦且安全的方式来使用最新的参数。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 依赖于 S3 工件和跨堆栈管道，这会增加操作开销并且不如参数查找直接。
● 如果没有自定义逻辑，CloudFormation 无法通过标签本地解析 AMI，这对于自动化、帐户范围的消费来说很脆弱。
● 职责紧密结合并减慢交付速度，因为应用程序更新将依赖于安全管理的堆栈。
工作流：使用创建 CodePipeline 的 CloudFormation 堆栈来构建强化的 AMI 并将当前 AMI ID 写入 AWS Systems Manager Parameter Store，并让平台团队解析该参数。
Elastic Beanstalk 蓝/绿，带外部 RDS 多可用区； CodeStar 连接 + CodeBuild
具有 CNAME 交换和共享外部多可用区 RDS 的 Elastic Beanstalk 上的蓝/绿可提供零停机切换和快速回滚。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：具有 CNAME 交换和共享外部多可用区 RDS 的 Elastic Beanstalk 上的蓝/绿可提供零停机切换和快速回滚。
● 场景匹配：具有 CNAME 交换和共享外部多可用区 RDS 的 Elastic Beanstalk 上的蓝/绿可提供零停机切换和快速回滚。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 即使使用多可用区 RDS，就地更新也可以在部署期间暂时减少容量和风险停机时间。
● 滚动更新仍可能会造成短暂的服务影响，并且此路径需要比快速迁移所需的更多的重新架构。
● 每个环境的单独数据库使有状态应用程序的数据一致性和切换变得复杂。
工作流：Elastic Beanstalk 蓝/绿，具有外部 RDS 多可用区 → CodeStar 连接 + CodeBuild。
启动 Auto Scaling 组的生命周期挂钩并完成它
启动生命周期挂钩会将实例暂停为 Pending:Wait，以便您可以完成引导，然后在准备就绪时允许注册。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：启动生命周期挂钩会将实例暂停为 Pending:Wait，以便您可以完成引导，然后在准备就绪时允许注册。
● 场景匹配：启动生命周期挂钩会将实例暂停在 Pending:Wait 状态，以便您可以完成引导程序，然后在准备就绪时允许注册。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 慢启动会在注册后计量流量，并且不会阻止目标过早注册。
● 更改运行状况检查阈值会改变目标被视为健康的速度，但不会限制初始注册。
● 宽限期仅延迟 Auto Scaling 运行状况评估和终止，并不控制负载均衡器注册。
工作流：将启动生命周期挂钩添加到 Auto Scaling 组，并仅在引导进程发出成功信号后完成。
更新策略：AutoScalingRollingUpdate
使用 MinInstancesInService 和 MaxBatchSize 启用 Auto Scaling 组的滚动更新。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：使用 MinInstancesInService 和 MaxBatchSize 启用 Auto Scaling 组的滚动更新。
● 场景匹配：使用 MinInstancesInService 和 MaxBatchSize 启用 Auto Scaling 组的滚动更新。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 一种资源属性，用于控制替换时的保留/删除行为，而不是滚动更新。
● 可以替换所有实例或整个组，而不是进行受控滚动批次。
● 部署服务，而不是用于 ASG 滚动更新的 CloudFormation UpdatePolicy。
工作流：更新策略：AutoScalingRollingUpdate。
使用 EC2 Image Builder 使用最新的 SSM 代理烘焙 AMI；附加 AmazonSSMManagedInstanceCore
无需互联网即可提供 SSM 会话管理器访问，授予所需的实例权限，并提供带有 SNS 通知的可审核 S3 日志。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：无需互联网即可提供 SSM 会话管理器访问，授予所需的实例权限，并提供带有 SNS 通知的可审核 S3 日志。
● 场景匹配：无需互联网即可提供 SSM 会话管理器访问，授予所需的实例权限，并通过 SNS 提供可审核的 S3 日志。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 需要 SSH 网络路径，并且不提供本机集中式会话管理器访问控制或隔离子网中的登录。
● SCP 不授予权限，并且 AWS Config 无法附加 SCP，从而导致所需的 SSM 访问路径无法解析。
● 检测API调用，但不建立SSM连接，确保代理/权限，或捕获会话日志，因此它是不完整的。
工作流：使用 EC2 Image Builder 使用最新的 SSM 代理烘焙 AMI → 附加 AmazonSSMManagedInstanceCore → 通过 VPC 终端节点使用会话管理器 → 记录到 S3 → 来自 S3 事件的 SNS。
将读取器数据库实例连接到 Aurora 集群并切换应用程序
添加读取器并使用集群和读取器端点可实现自动故障转移，并最大程度地减少维护期间读取流量的中断。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：添加读取器并使用集群和读取器端点可实现自动故障转移，并最大程度地减少维护期间读取流量的中断。
● 场景匹配：添加读取器并使用集群和读取器端点可实现自动故障转移并最大限度地减少读取中断。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● RDS Proxy 可帮助管理连接，但无法消除维护期间单个写入器重新启动造成的停机时间。
● Aurora 不提供用于启用具有特殊实例终端节点的多可用区的切换，因此此方法不适用。
● 自定义端点旨在按属性进行分组，而不是简单的读/写分割，并为此需求增加了不必要的复杂性。
工作流：将读取器数据库实例添加到 Aurora 集群，并将应用程序切换为使用集群写入器端点进行写入，使用读取器端点进行读取。
将 MySQL 数据库迁移到为多可用区配置的 Amazon RDS for MySQL
RDS 多可用区提供跨可用区的同步备用和自动故障转移，以实现高可用性和容错能力。具有 ECS 服务的 Fargate 和 ALB 提供多可用区。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：RDS 多可用区提供跨可用区的同步备用和自动故障转移，以实现高可用性和容错能力。
● 场景匹配：RDS 多可用区提供跨可用区的同步备用和自动故障转移，以实现高可用性和容错能力。法尔盖特。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 虽然高度可用，但这会增加管理开销，并且与无服务器容器相比，容器工作负载的成本效益通常较低。
● DynamoDB 是一项 NoSQL 服务，并非关系型 MySQL 数据库的直接替代品。
● 只读副本是异步的，不提供 HA 自动故障转移，因此不适合作为主 HA。
工作流：将 MySQL 数据库迁移到配置为多可用区故障转移的 Amazon RDS for MySQL → 使用与应用程序负载均衡器集成的 ECS 服务在 AWS Fargate 上运行容器。
将原始 TLS 证书替换为公共 CA 签名的证书并安装
CloudFront 要求原始证书有效、未过期、命名正确并链接到受信任的公共 CA；更新并安装完整的中间链即可解决。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudFront 要求原始证书有效、未过期、命名正确并链接到受信任的公共 CA。
● 场景匹配：CloudFront 要求原始证书有效、未过期、命名正确并链接到受信任的公共 CA。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 调整最低 TLS 版本不会修复过期或不完整的原始证书链，也不会解决由证书验证失败导致的 502。
● 过期的面向查看者的证书会导致客户端 TLS 错误，而不是带有 X-Cache 的 502：来自 CloudFront 的错误，该错误指示源获取/验证问题。
● ACM 公共证书无法导出以安装在非 AWS 服务器上，因此这对于外部源来说不是可行的补救措施。
工作流：将原始 TLS 证书替换为公共 CA 签名证书并安装完整链。
ALB 访问日志
访问日志包括每个请求的request_processing_time、target_processing_time和response_processing_time。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：访问日志包括每个请求的request_processing_time、target_processing_time和response_processing_time。
● 场景匹配：访问日志包括每个请求的request_processing_time、target_processing_time和response_processing_time。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 仅聚合指标，而不是每个请求的时间。
● 通常需要代码检测，并且本身不提供 ALB 每个请求计时字段。
● 收集主机级别的指标和日志，而不是 ALB 每个请求的延迟详细信息。
工作流：打开 ALB 访问日志。
ALB TargetResponseTime 指标上的 CloudWatch 警报并将其附加到
当关联的 CloudWatch 警报在 ALB 延迟上转换为 ALARM 时，CodeDeploy 可以停止部署，从而提供最快的内置检测。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：当关联的 CloudWatch 警报在 ALB 延迟上转换为 ALARM 时，CodeDeploy 可以停止部署，从而提供最快的内置检测。
● 场景匹配：当关联的 CloudWatch 警报在 ALB 延迟上转换为 ALARM 时，CodeDeploy 可以停止部署，从而提供。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● ALB 已经发出 1 分钟指标，并且不支持详细监控，因此这不会提供更快的信号，也不会提供自动停止的特殊集成。
● 访问日志的传递有延迟，并且需要解析，与本机指标相比，这会延迟检测。
● X-Ray 需要仪器和分析，并且不能直接为部署提供最快的自动停止。
工作流：针对 ALB TargetResponseTime 指标创建 CloudWatch 警报，并将其附加到 CodeDeploy 部署组，以便在发生违规时自动停止部署。
CodeDeploy AfterAllowTestTraffic 挂钩调用 Lambda；挂钩自动回滚失败
AfterAllowTestTraffic 在测试侦听器将测试流量路由到绿色任务集之后但在生产流量转移之前运行。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：AfterAllowTestTraffic 在测试侦听器将测试流量路由到绿色任务集之后但在生产流量转移之前运行。
● 场景匹配：AfterAllowTestTraffic 在测试侦听器将测试流量路由到绿色任务集之后但在生产流量转移之前运行。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● CodeBuild 可以运行测试，但它位于 CodeDeploy 生命周期之外。
● AfterAllowTraffic 在生产流量移动后运行。
● CloudWatch 警报可以回滚部署，但它们不会针对测试侦听器运行所需的冒烟测试。
工作流：CodeDeploy AfterAllowTestTraffic 挂钩调用 Lambda → 使挂钩无法自动回滚。
统一的 CloudWatch 代理将日志和指标发送到 CloudWatch Logs
CloudWatch 代理原生收集 Linux 和 Windows 上的日志和其他指标，并通过最少的设置即可使用 Logs Insights 进行直接分析。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudWatch 代理原生收集 Linux 和 Windows 上的日志和其他指标，并通过最少的设置即可使用 Logs Insights 进行直接分析。
● 场景匹配：CloudWatch 代理原生收集 Linux 和 Windows 上的日志和其他指标，并通过最少的设置即可使用 Logs Insights 进行直接分析。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 功能齐全，但添加了额外的服务和配置，而不是 EC2 日志和指标的最小工作路径。
● 可能，但需要管理额外的组件和域，与 CloudWatch Logs Insights 相比，增加了运营开销。
● SSM Agent 不是本机日志收集代理；它用于 Systems Manager 操作，而不是日志传送。
工作流：使用统一的 CloudWatch 代理将日志和指标发送到 CloudWatch Logs，→ 使用 CloudWatch Logs Insights 进行查询。
EC2 和本地主机上的 CloudWatch 代理以流式传输到 CloudWatch
这将所有日志汇集到一个低成本的 S3 数据湖中，并跨账户和本地进行大规模的无服务器处理和即席 SQL。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这会将所有日志汇集到一个具有无服务器处理和即席 SQL 的低成本 S3 数据湖中。
● 场景匹配：这会将所有日志汇集到一个具有无服务器处理和即席 SQL 的低成本 S3 数据湖中。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 按账户分割数据，并使跨账户分析和治理变得复杂，而不是集中化。
● Kinesis Data Analytics 适用于流输入（例如 Kinesis Data Streams 或 Firehose），无法直接查询数据。
● 在本地保留日志可以防止出现以 AWS 为中心的单一聚合点，并且对于长期多账户而言通常更加复杂且成本更高。
工作流：使用 EC2 和本地主机上的 CloudWatch 代理流式传输到 CloudWatch Logs → 将日志组订阅到 Kinesis Data Firehose，该日志组会传送到 a 中的集中式 S3 存储桶。
将具有 AWS WAF IP 集的开发 IP 列入白名单 + AWS WAF
创建 IP 集并在阻止规则之前放置允许规则，以便开发人员 IP 绕过地理阻止。使用地理匹配语句在 WAF 层阻止来自选定国家/地区的请求。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：创建 IP 集并在阻止规则之前放置允许规则，以便开发人员 IP 绕过地理阻止。
● 场景匹配：创建 IP 集并在阻止规则之前放置允许规则，以便开发人员 IP 绕过地理阻止。使用地理匹配语句在 WAF 层阻止来自选定国家/地区的请求。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 增强 DDoS 防护，但不实施国家/地区屏蔽或允许名单。
● ALB监听器规则缺乏地理条件；使用 AWS WAF 进行基于地理的过滤。
● 影响 DNS 响应，不是按国家/地区阻止请求的可靠安全控制。
工作流：将具有 AWS WAF IP 集的开发 IP 列入白名单 → AWS WAF 地理匹配规则以阻止这些国家/地区。
在 EC2 容器实例上重新启动 Amazon ECS 代理
重新启动 ECS 代理可以解决代理无法提取更新的标签并重复使用缓存的映像，从而导致旧映像偶尔启动的情况。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：重新启动 ECS 代理可以解决代理无法提取更新的标签并重复使用缓存的映像，从而导致旧映像偶尔启动的情况。
● 场景匹配：重新启动 ECS 代理可以解决代理无法拉取更新的标签并重复使用的情况。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 如果代理运行状况不佳，移动注册表并不能解决 ECS 主机上旧本地映像的间歇性重用问题。
● 虽然摘要确保了不变性，但所描述的问题是间歇性的，并且指向代理状态问题而不是标记可变性。
● 如果代理运行状况不佳或重用本地缓存的图像，则使用可变的最新标签并不能保证拉取。
工作流：在 EC2 容器实例上重新启动 Amazon ECS 代理。
CloudTrail 到 CloudWatch Logs； EC2 通过 CloudWatch Agent 将日志记录到 CloudWatch Logs
这两个数据集都驻留在 CloudWatch Logs 中，从而可以使用 Logs Insights 进行跨日志组查询。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这两个数据集都驻留在 CloudWatch Logs 中，从而可以使用 Logs Insights 进行跨日志组查询。
● 场景匹配：这两个数据集都驻留在 CloudWatch Logs 中，从而可以使用 Logs Insights 进行跨日志组查询。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● CloudWatch Agent 不会直接将日志发送到 S3；它发布到 CloudWatch Logs。
● CloudTrail Lake 存储 CloudTrail 风格的事件，不适用于任意应用程序日志摄取。
● Athena 无法直接查询 CloudWatch Logs；您需要先将日志导出到 S3。
工作流：CloudTrail 到 CloudWatch Logs → EC2 通过 CloudWatch Agent 将日志记录到 CloudWatch Logs → 使用 CloudWatch Logs Insights 进行查询。
在 AWS Organizations 中指定 Firewall Manager 管理员账户并创建 AWS
AWS Firewall Manager 集中实施组织范围内的 WAF 策略，以跨账户和区域匹配资源，并使用 AWS Config 进行资源发现。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：AWS Firewall Manager 使用 AWS Config 集中实施组织范围内的 WAF 策略，以匹配跨账户和区域的资源。
● 场景匹配：AWS Firewall Manager 使用 AWS Config 集中实施组织范围内的 WAF 策略，以匹配跨账户和区域的资源。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● AWS Config 可以检测并触发修复操作，但它不是集中式、基于策略的 WAF 的专用服务。
● CloudFormation StackSets 可以推出模板，但不会持续发现 WAF 并将其自动附加到新创建的资源。
● GuardDuty 是一项威胁检测服务，不提供跨帐户的主动、基于策略的 WAF Web ACL 附件。
工作流：在 AWS Organizations 中指定 Firewall Manager 管理员账户，并创建 AWS Firewall Manager 策略，自动将 WAF Web ACL 与所有面向互联网的 ALB 和 API 网关 API 关联。
使用 AWS CloudFormation 定义和发布无服务器应用程序版本并部署
此预设执行金丝雀操作，在 10 分钟内转移 20% 的流量，然后再路由其余流量，以满足小子集和烘焙的要求。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：此预设执行金丝雀操作，在 10 分钟内转移 20% 的流量，然后再路由其余流量，以满足小子集和烘焙的要求。
● 场景匹配：此预设执行金丝雀操作，在 10 分钟内转移 20% 的流量，然后再路由其余流量，以满足小子集和烘焙的要求。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 一次性立即转移 100% 的流量，这不提供有限的金丝雀暴露或烘烤时间。
● 手动审批门不会路由一小部分流量进行验证；一旦获得批准，它仍然会推送给所有用户。
● AppConfig 管理配置和功能标志，但不会在 CodeDeploy 驱动的部署中执行 Lambda 别名流量转移。
工作流：使用 AWS CloudFormation 定义和发布无服务器应用程序版本，并使用 CodeDeployDefault.LambdaCanary20Percent10Minutes 通过 AWS CodeDeploy 部署 Lambda 更新。
EC2 实例状态更改通知事件和目标的 Amazon EventBridge 规则
EventBridge 发出 EC2 状态更改事件，这些事件可以发送到 SNS，以在所有实例状态转换中立即发出通知。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：EventBridge 发出 EC2 状态更改事件，这些事件可以发送到 SNS，以在所有实例状态转换中立即发出通知。
● 场景匹配：EventBridge 发出 EC2 状态更改事件，这些事件可以发送到 SNS，以在所有实例状态转换中立即发出通知。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 操作通过尝试实例恢复来针对与硬件相关的故障，并且不会通知每个状态转换。
● AWS Health 重点关注影响账户和服务的事件，而不是例行的 EC2 启动、停止或终止转换。
● 通过重新启动解决实例级运行状况问题，并且不会针对所有可能的状态更改提供警报。
工作流：为 EC2 实例状态更改通知事件创建 Amazon EventBridge 规则并定位 Amazon SNS 主题。
为跨区域的目录构建 Amazon Aurora MySQL 全局数据库
留在 Aurora 上可以最大限度地减少代码更改，同时通过 Aurora 全球数据库提供单一全局目录，并确保受监管的数据保留在本地 Aurora 中的每个区域。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：留在 Aurora 可以最大限度地减少代码更改，同时通过 Aurora 全球数据库提供单一全局目录并确保。
● 场景匹配：留在 Aurora 上可以最大限度地减少代码更改，同时通过 Aurora 全球数据库提供单一全局目录并确保。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 将目录和受监管数据切换到 DynamoDB 需要将应用程序从关系 SQL 重构为 NoSQL，因此。
● Redshift 是一个针对分析而不是 OLTP 工作负载进行优化的数据仓库，将其与 DynamoDB 搭配使用会增加负担。
● 将 PII 放置在全局 DynamoDB 表上违反了数据驻留要求并不必要地混合了引擎，从而增加了重构工作量。
工作流：为具有跨区域读取器的目录构建 Amazon Aurora MySQL 全局数据库，并为 PII 和订单运行区域本地 Aurora MySQL 集群。
关于 Lambda 指标的 CloudWatch 警报并将其与 CodeDeploy 关联
CodeDeploy 与 CloudWatch 警报集成，可在超出错误阈值时自动停止并回滚部署。此金丝雀策略将 10% 的流量发送到新版本 5 分钟，然后转移其余流量，以满足要求。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CodeDeploy 与 CloudWatch 警报集成，可在超出错误阈值时自动停止并回滚部署。
● 场景匹配：CodeDeploy 与 CloudWatch 警报集成，可在超出错误阈值时自动停止并回滚部署。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 立即转移 100% 的流量，并且不提供金丝雀窗口。
● EventBridge 规则可以观察事件，但 CodeDeploy 不会使用 EventBridge 规则来触发自动回滚。
● 线性部署以重复增量的方式移动流量，而不是两步金丝雀转移。
工作流：针对 Lambda 指标创建 CloudWatch 警报并将其与 CodeDeploy 部署关联 → 选择 LambdaCanary10Percent5Minutes 的部署配置。
使用 AWS CloudFormation StackSets 的 AWS Config 自定义规则来检查实例
具有聚合器的组织范围内的 AWS Config 自定义规则为 AMI 使用情况提供集中的合规性可见性。集中和共享 AMI 让您可以取消共享旧的 AMI。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：具有聚合器的组织范围内的 AWS Config 自定义规则为 AMI 使用情况提供集中的合规性可见性。
● 场景匹配：具有聚合器的组织范围内的 AWS Config 自定义规则为 AMI 使用情况提供集中的合规性可见性。集中和。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 在每个账户中构建 AMI 会增加偏差，并使整个组织中较旧的 AMI 难以淘汰。
● 复制 AMI 会导致过时版本激增，并且不会阻止从其他账户中已存在的旧副本启动。
● 服务目录有助于配置模式，但不会阻止用户直接启动旧版 AMI 或在整个队列范围内提供服务。
工作流：使用 AWS CloudFormation StackSets 部署 AWS Config 自定义规则，以根据批准的列表检查实例 AMI ID，并在管理账户 → 的 AWS Config 聚合器中聚合结果。
在混合实例中，缩减在 AZ 之前选择购买选项，导致短暂的 AZ
缩减首先选择要删除的 Spot 或 On-Demand，然后在该选项中应用可用区平衡，这可能会暂时使可用区不平衡。 Auto Scaling 在重新平衡期间终止之前启动替换，这可能会短暂超过 MaxSize。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：缩减首先选择要删除的 Spot 或 On-Demand，然后在该选项中应用可用区平衡，这可能会暂时使可用区不平衡。
● 场景匹配：缩减首先选择要删除的“现货”或“按需”，然后在该选项中应用可用区平衡，这可以暂时实现。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 错误的;重新平衡功能可以在终止之前启动并暂时超过 MaxSize。
● 可用区重新平衡是在计费时间之前评估的，因此计费对齐并不能解释选择较小的可用区。
● MaxSize 是为了扩展活动而强制执行的；冷却时间不允许超过 MaxSize。
工作流：在混合实例中 → 缩减在 AZ 之前选择购买选项，导致短暂的 AZ 偏差 → 重新平衡可以暂时超过 MaxSize 最多 10% 或一个实例以维持可用性。
将依赖项镜像到 S3 并通过 S3 网关 VPC 端点获取
具有网关 VPC 终端节点的 S3 将流量保留在 AWS 网络上，并使用 IAM 在没有公共 Internet 的情况下进行最低权限访问。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：具有网关 VPC 终端节点的 S3 将流量保留在 AWS 网络上，并使用 IAM 在没有公共 Internet 的情况下进行最低权限访问。
● 场景匹配：具有网关 VPC 终端节点的 S3 将流量保留在 AWS 网络上，并使用 IAM 在没有公共 Internet 的情况下进行最低权限访问。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 仅支持 IPv6，但仍允许出站 Internet 流量，违反了无 Internet 要求。
● NAT 网关支持 Internet 出口，这打破了隔离要求。
● 公共操作系统存储库没有 VPC 端点；除非私下镜像，否则它们需要互联网访问。
工作流：将依赖项镜像到 S3 并使用实例角色通过 S3 网关 VPC 终端节点获取。
Systems Manager 补丁管理器加上 AWS Config 通过 ID 批准并带有警报
补丁管理器可自动执行操作系统更新，并且按 ID 批准的 amis 规则持续评估 AMI 合规性，从而在不阻止启动的情况下启用警报。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：补丁管理器可自动执行操作系统更新，并且按 ID 批准的 amis 规则持续评估 AMI 合规性，从而在不阻止启动的情况下启用警报。
● 场景匹配：补丁管理器可自动执行操作系统更新，并且按 ID 批准的 amis 规则持续评估 AMI 合规性，从而在不阻止启动的情况下启用警报。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Security Hub 会汇总结果，但不会自动修补操作系统或根据自定义批准的 AMI 列表评估实例。
● GuardDuty 检测威胁，而不是补丁状态或 AMI 允许列表。
● 拒绝策略会阻止从未经批准的 AMI 启动，这与允许启动且仅发出警报的要求相冲突。
工作流：Systems Manager 补丁管理器 → AWS Config 通过 ID 批准并带有警报。
AWS Personal Health Dashboard 与 Amazon EventBridge 相匹配 AWS Health 事件
AWS Health 发布特定于账户的计划更改事件，EventBridge 可以通过最少的设置将这些事件路由到 Lambda 以获取 Slack 通知。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：AWS Health 发布特定于账户的计划更改事件，EventBridge 可以通过最少的设置将这些事件路由到 Lambda 以获取 Slack 通知。
● 场景匹配：AWS Health 发布特定于账户的计划更改事件，EventBridge 可以通过最少的设置将这些事件路由到 Lambda 以获取 Slack 通知。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 状态检查警报检测实例运行状况问题，但不会跨服务捕获特定于账户的 AWS 计划维护事件。
● Config 和 Trusted Advisor 专注于配置和最佳实践检查，而不是发送 AWS 计划的维护通知。
● CloudTrail 记录 API 活动，而不是 AWS 发起的维护，并且支持 API 轮询不是基于推送或综合的解决方案。
工作流：将 AWS Personal Health Dashboard 与 Amazon EventBridge 结合使用来匹配 AWS Health 事件并触发将这些事件中继到 Slack 的 Lambda 函数。
具有 Lambda 转换的 Amazon Kinesis Data Firehose 传输流，设置
网络防火墙可以将日志直接发送到 Kinesis Data Firehose，后者支持内联 Lambda 转换以及可靠的近实时传送到 S3。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：网络防火墙可以将日志直接发送到 Kinesis Data Firehose，后者支持内联 Lambda 转换和可靠的近。
● 场景匹配：网络防火墙可以将日志直接发送到 Kinesis Data Firehose，后者支持内联 Lambda 转换和可靠的近。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 在日志已存储在 S3 中后执行批处理，这不符合在数据进入存储桶之前转换数据的要求。
● 日志写入 S3 后仍对其进行处理，并引入递归和操作复杂性。
● 网络防火墙本身并不发布到 Kinesis Data Streams，因此这将需要不受支持的路由或额外的组件。
工作流：使用 Lambda 转换创建 Amazon Kinesis Data Firehose 传输流 → 将目标设置为当前 S3 存储桶，并更新网络防火墙以将日志发布到流。
.ebextensions/db-migration.config，其中包含用于迁移的 container_commands 块并设置leader_only
这是正确的，因为container_commands 支持leader_only 并在部署应用程序之前在leader 实例上运行一次。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这是正确的，因为container_commands 支持leader_only 并在部署应用程序之前在leader 实例上运行一次。
● 场景匹配：这是正确的，因为container_commands 支持leader_only 并在部署应用程序之前在leader 实例上运行一次。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 不正确，因为命令块在每个实例上执行并且不支持leader_only。
● 不正确，因为它不与 Elastic Beanstalk 领导者选举集成，并且仍然可以触发并行运行。
● 不正确，因为 lock_mode 不是 Elastic Beanstalk 容器命令的有效属性。
工作流：添加带有用于迁移的 container_commands 块的 .ebextensions/db-migration.config 并设置leader_only: true。
GuardDuty 委派管理员并拥有成员账户； EventBridge 过滤器 Impact:IAMUser/AnomalousBehavior 来调用
GuardDuty 集中检测跨账户的发现结果并将其发布到 EventBridge，其中规则可以匹配 Impact:IAMUser/AnomalousBehavior 并触发 Lambda 调用映射 API 并发送。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：GuardDuty 集中检测跨账户的发现结果并将其发布到 EventBridge，其中规则可以匹配 Impact:IAMUser/AnomalousBehavior 和触发器。
● 场景匹配：GuardDuty 集中检测跨账户的发现结果并将其发布到 EventBridge，其中规则可以匹配 Impact:IAMUser/AnomalousBehavior 和触发器。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● CloudTrail Insights 检测到异常 API 活动，但它不会发出此处针对的 GuardDuty 发现类型。
● SNS 无法对 GuardDuty 的路由结果进行模式匹配；必须使用EventBridge来过滤和调用Lambda。
● Detective 分析数据并获取 GuardDuty 结果，但不会生成触发所需的 IAM 异常行为结果。
工作流：使用 GuardDuty 委派管理员与成员账户 → EventBridge 筛选器 Impact:IAMUser/AnomalousBehavior 来调用 Lambda 进行查找和通知。
每个构建的新 S3 对象密钥 + 更改为
更改 S3Key 可确保 CloudFormation 检测到更改并更新功能代码。更改 S3Bucket 也会强制更新并刷新代码，尽管它很严厉。指定 S3ObjectVersion 使 CloudFormation 选择准确的工件版本并重新部署。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：更改 S3Key 可确保 CloudFormation 检测到更改并更新功能代码。
● 场景匹配：更改 S3Key 可确保 CloudFormation 检测到更改并更新功能代码。更改 S3Bucket 也会强制更新。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● SAM 不会更改 CloudFormation 检测 S3Bucket/S3Key 的 Lambda 代码更改的方式。
● 等待不会更改 CloudFormation 属性，因此不会发生代码更新。
● 如果没有更改 S3Key 或 S3ObjectVersion，CloudFormation 可能不会更新功能代码。
工作流：为每个构建使用新的 S3 对象密钥→每次部署更改为新的 S3 存储桶名称→启用 S3 版本控制并引用 S3ObjectVersion。
仅出口互联网网关并将 ::/0 路由到它
仅出口 Internet 网关通过 ::/0 路由启用来自私有子网的仅出站 IPv6。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：仅出口 Internet 网关通过 ::/0 路由启用来自私有子网的仅出站 IPv6。
● 场景匹配：仅出口 Internet 网关通过 ::/0 路由启用来自私有子网的仅出站 IPv6。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● NAT 网关用于 IPv4 出口和 NAT64（v6 到 v4），而不是 IPv6 到 IPv6 路由。
● NAT 实例仅处理 IPv4，而不处理 IPv6。
● 允许入站 IPv6 并有效地使子网公开，而不仅仅是出口。
工作流：添加仅出口 Internet 网关并将 ::/0 路由到它。
预配置并发并使用 Application Auto Scaling 对其进行扩展
预配置并发使执行环境保持初始化，并且可以扩展以满足可预测的需求。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：预配置并发使执行环境保持初始化，并且可以扩展以满足可预测的需求。
● 场景匹配：预配置并发使执行环境保持初始化，并且可以扩展以满足可预测的需求。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 更多内存可以减少初始化和运行时间，但不能防止突发流量下的冷启动。
● 预留并发限制并隔离容量，但不会保持环境温暖以避免冷启动。
● SnapStart 仅针对受支持的 Java 运行时减少冷启动，并不是适用于所有功能的通用解决方案。
工作流：使用预配置的并发并通过 Application Auto Scaling 对其进行扩展。
CloudTrail管理事件并添加EventBridge规则过滤dynamodb DeleteTable到
EventBridge可以匹配DeleteTable的CloudTrail管理事件并直接路由到SNS，以近乎实时的交付和最低的成本。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：EventBridge可以匹配DeleteTable的CloudTrail管理事件并直接路由到SNS，以近乎实时的交付和最低的成本。
● 场景匹配：EventBridge可以匹配DeleteTable的CloudTrail管理事件并直接路由到SNS，以近乎实时的交付和最低的成本。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Config 评估资源状态可能会出现延迟并增加成本，这对于即时 API 调用警报来说并不理想。
● DynamoDB 不会为删除表等管理 API 调用发出本机服务事件；这些是通过 CloudTrail 呈现的。
● 与从 CloudTrail 直接进行 EventBridge 路由相比，提取日志会增加持续成本和复杂性。
工作流：启用CloudTrail管理事件并添加EventBridge规则过滤dynamodb DeleteTable到SNS。
使用 IAM 角色（实例配置文件）启动 EC2 实例并检索
使用实例配置文件提供临时凭证，Secrets Manager 可以安全地存储和轮换数据库密码。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：使用实例配置文件提供临时凭证，Secrets Manager 可以安全地存储和轮换数据库密码。
● 场景匹配：使用实例配置文件提供临时凭证，Secrets Manager 可以安全地存储和轮换数据库密码。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 即使使用 Parameter Store，实例上的长期访问密钥也会增加凭证泄露的风险。
● 在 AMI 中嵌入机密会导致分配和轮换挑战，并且不是最佳实践。
● 用户数据并非用于存储秘密，而且 Base64 不是加密的，因此不安全。
工作流：使用 IAM 角色（实例配置文件）启动 EC2 实例并从 AWS Secrets Manager 检索数据库凭证。
StatusCheckFailed_System 指标上的 Amazon CloudWatch 警报可触发 EC2
系统状态检查的 CloudWatch 警报可以调用 EC2 恢复操作，该操作将实例迁移到新硬件以修复主机电源或。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：系统状态检查的 CloudWatch 警报可以调用 EC2 恢复操作，从而迁移实例。
● 场景匹配：系统状态检查的 CloudWatch 警报可以调用 EC2 恢复操作，从而迁移实例。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 大小为 1 的 ASG 可以替换不健康的实例，但它会启动一个新实例而不是恢复同一实例，并且可能不会自动保留配置或数据附件。
● 实例状态检查和重新启动操作可以解决操作系统级别的问题，但不能修复主机级别的电源或网络问题。
● 频繁的快照可以保护数据，但不会自动恢复正在运行的实例或最大限度地减少主机故障期间的停机时间。
工作流：在 StatusCheckFailed_System 指标上配置 Amazon CloudWatch 警报以触发 EC2 恢复操作。
为 Systems Manager 连接 VPC 终端节点 + 附加 IAM 实例配置文件
ssm、ec2messages 和 ssmmessages 的接口端点使会话管理器控制和数据通道保持私有。实例需要此角色，以便 SSM 代理可以注册和建立会话。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：ssm、ec2messages 和 ssmmessages 的接口端点使会话管理器控制和数据通道保持私有。
● 场景匹配：ssm、ec2messages 和 ssmmessages 的接口端点使会话管理器控制和数据通道保持私有。实例需要此角色，以便 SSM 代理可以注册和建立会话。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 堡垒依赖于 SSH 和密钥，并且不强制执行私有会话管理器访问。
● 通过互联网使用公共 SSM 端点，违反了仅限私有的要求。
● EC2 API 端点不提供会话管理器所需的私有数据通道。
工作流：为 Systems Manager 创建接口 VPC 终端节点 → 将 IAM 实例配置文件附加到 AmazonSSMManagedInstanceCore。
CodePipeline 中的部署后阶段，调用 AWS Lambda 函数来
将自动化与部署事件联系起来可确保 SDK 得到发布，并且缓存在每次发布后立即主动刷新。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：将自动化与部署事件联系起来可确保 SDK 得到发布，并且缓存在每次发布后立即主动刷新。
● 场景匹配：将自动化与部署事件联系起来可确保 SDK 的发布以及缓存的主动刷新。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 轮询计时器效率低下，并且在未发生部署时可能会导致不必要的导出和失效。
● S3 不提供使 CloudFront 缓存失效的 API，因此不会刷新分配。
● 短 TTL 仍然可以提供过时的内容并增加源负载，无法满足每次部署后立即保持新鲜度的要求。
工作流：在 CodePipeline 中添加一个部署后阶段，该阶段调用 AWS Lambda 函数以从 API Gateway 导出开发工具包，将其上传到 S3 源，并为开发工具包路径创建 CloudFront 失效。
所有对象的源存储桶上的 S3 复制规则 +
复制是在源存储桶上配置的，并且应针对所需的前缀或所有对象。目标存储桶必须信任源账户的复制角色。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：复制是在源存储桶上配置的，并且应针对所需的前缀或所有对象。
● 场景匹配：复制是在源存储桶上配置的，并且应针对所需的前缀或所有对象。目的地。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● S3 承担源帐户中的角色；不需要目标帐户角色。
● 目标端未配置复制；它仅在源存储桶上定义。
● 角色的附加策略通常授予源访问权限；标准复制不需要更改源存储桶策略。
工作流：在源存储桶上为所有对象创建 S3 复制规则 → 配置目标存储桶策略以允许源复制角色写入并设置所有权 → 创建一个。
Lambda@Edge
在 CloudFront 边缘位置针对查看器/源事件执行代码，以实现基于低延迟用户代理的路由。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：在 CloudFront 边缘位置针对查看器/源事件执行代码，以实现基于低延迟用户代理的路由。
● 场景匹配：在 CloudFront 边缘位置针对查看器/源事件执行代码，以实现基于低延迟用户代理的路由。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 改进了到区域端点的网络路径，但不在边缘执行自定义代码或执行基于用户代理的逻辑。
● 适合轻量级标头/URL mods，但不适合较重的 Lambda 逻辑或动态图像选择。
● 通过 CloudFront 路由至区域 API；您的代码仍然在区域内运行，而不是在边缘。
工作流：Lambda@Edge。
DeletionPolicy：AWS::EC2::Volume 资源上的快照，用于捕获堆栈删除时的 EBS 快照
将 DeletionPolicy 设置为 EBS 卷上的快照会指示 CloudFormation 在删除堆栈或资源时拍摄该卷的快照。使用删除策略保留。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：将 DeletionPolicy 设置为 EBS 卷上的快照会指示 CloudFormation 在以下情况下拍摄该卷的快照。
● 场景匹配：将 DeletionPolicy 设置为 EBS 卷上的快照会指示 CloudFormation 在以下情况下拍摄该卷的快照。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 终止或删除保护不会创建 EBS 快照，也不能可靠地防止更新中替换驱动的数据丢失。
● CloudFormation 不支持将单个资源属性设置为只读，因此这无法防止更改或数据丢失。
● 堆栈策略会阻止合法更新，但仍然无法解决对 EBS 卷进行快照的需求。
工作流：在 AWS::EC2::Volume 资源上配置 DeletionPolicy: Snapshot 以捕获堆栈删除时的 EBS 快照 → 在 AWS::RDS::DBInstance 上设置 DeletionPolicy: Retain，以便替换和删除不会删除数据库。
一个阶段，测试操作共享相同的 runOrder
具有相同 runOrder 的同一阶段中的操作并行执行，从而减少总运行时间。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：具有相同 runOrder 的同一阶段中的操作并行执行，从而减少总运行时间。
● 场景匹配：具有相同 runOrder 的同一阶段中的操作并行执行，从而减少总运行时间。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 当操作配置为一个接一个地运行时，服务并发限制不会更改 CodePipeline 排序。
● 当测试受网络限制时，扩展 CPU 或内存没有帮助。
● 阶段按顺序执行，runOrder 仅控制单个阶段内的操作顺序。
工作流：使用一个阶段，测试操作共享相同的 runOrder。
AWS CloudFormation 用于管理 Lambda 函数版本并配置 API Gateway 阶段
CloudFormation 支持 Lambda 版本和 API Gateway 阶段金丝雀设置，从而实现受控百分比流量转移并轻松推广新版本。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudFormation 支持 Lambda 版本和 API Gateway 阶段金丝雀设置，从而实现受控百分比流量转移和轻松升级。
● 场景匹配：CloudFormation 支持 Lambda 版本和 API Gateway 阶段金丝雀设置，从而实现受控百分比流量转移和轻松升级。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 将 SAM 与基于 DNS 的流量转移相结合，这不适合单个 API 网关端点上的细粒度金丝雀。
● 故障转移路由仅在运行状况检查失败后才会移动 100% 的流量，并且不支持渐进式、基于百分比的转移。
● CodeDeploy 可以管理 Lambda 别名流量转移，但不协调 API Gateway 阶段或资源更新。
工作流：使用 AWS CloudFormation 管理 Lambda 函数版本并配置 API Gateway 阶段金丝雀设置 → 更新堆栈以推出新代码并在验证后进行升级。
Amazon EFS 与 EC2 Spot 实例配对
EFS 为许多实例提供托管、共享的 POSIX 文件系统，而 Spot 则最大限度地降低了中断容忍工作负载的成本。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：EFS 为许多实例提供托管、共享的 POSIX 文件系统，而 Spot 则最大限度地降低了中断容忍工作负载的成本。
● 场景匹配：EFS 为许多实例提供托管、共享的 POSIX 文件系统，而 Spot 则最大限度地降低了中断容忍工作负载的成本。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 提供共享文件系统，但按需会增加成本，并且 Lustre 针对 HPC 而不是一般检查点批处理作业进行了优化。
● 编排作业，但不提供共享 POSIX 文件系统并使用成本较高的计算。
● 多重附加不是集群共享文件系统，跨实例并发使用时存在数据损坏的风险。
工作流：Amazon EFS 与 EC2 Spot 实例配对。
用于 CodeDeploy 部署状态更改的 Amazon EventBridge 规则，该规则调用
EventBridge 直接捕获 CodeDeploy 状态更改事件，并与用于 Slack 通知和本机故障回滚的 Lambda 一起完全满足要求。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：EventBridge 直接捕获 CodeDeploy 状态更改事件，并与 Lambda 一起用于 Slack 通知和失败时的本机回滚。
● 场景匹配：EventBridge 直接捕获 CodeDeploy 状态更改事件，并与 Lambda 一起用于 Slack 通知和失败时的本机回滚。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 该方法依赖于审核日志和手动 API 调用，而不是对实时部署状态事件和本机自动回滚做出反应。
● 虽然警报可以发出通知，但它使用指标而不是直接的状态更改事件，并增加了比基于事件的检测不太精确的间接方式。
● 添加不必要的组件和自定义回滚逻辑，而不是使用 CodeDeploy 内置的基于部署失败事件的自动回滚。
工作流：为 CodeDeploy 部署状态更改设置 Amazon EventBridge 规则，该规则调用 Lambda 函数来通知 Slack，并在部署失败时启用 CodeDeploy 回滚。
AWS Config 用于捕获配置更改、向 Amazon 提供快照和历史记录
AWS Config 根据规则持续记录和评估资源配置并提供合规状态，导出到 S3 使 QuickSight 仪表板能够实现组织范围内的可见性。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：AWS Config 根据规则持续记录和评估资源配置并提供合规状态，并导出到 S3。
● 场景匹配：AWS Config 根据规则持续记录和评估资源配置并提供合规状态，并导出到 S3。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Amazon Inspector 重点关注 EC2 和 ECR 漏洞以及网络暴露结果，而不是全面的资源配置合规性或。
● Trusted Advisor 提供账户级最佳实践检查和成本/安全建议，但不评估资源配置规则或。
● Systems Manager 合规性以托管实例的补丁和 SSM 配置基准为目标，不提供广泛的 AWS 资源。
工作流：启用 AWS Config 来捕获配置更改 → 将快照和历史记录传送到 Amazon S3，并在 Amazon QuickSight 中构建近乎实时的合规性视觉效果。
故障转移路由策略并创建指向
具有别名目标的故障转移路由和评估目标运行状况使 Route 53 能够在主目标运行状况不佳时返回辅助目标。需要进行健康检查。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：具有别名目标的故障转移路由和评估目标运行状况使 Route 53 能够在何时返回辅助目标。
● 场景匹配：具有别名目标的故障转移路由和评估目标运行状况使 Route 53 能够在何时返回辅助目标。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 添加自定义自动化，但对于 Route 53 DNS 故障转移来说不是必需的，该故障转移由路由策略和本地处理。
● 加权路由会分配负载，并且不会在主节点变得不健康时自动进行故障转移。
工作流：使用故障转移路由策略并创建指向应用程序资源的别名记录，从而为两个活动端点上的非别名端点启用评估目标运行状况 → 配置 Route 53 运行状况检查。
EBS 默认加密的 AWS Config 组织规则加上 SCP
可与组织级 AWS Config 和中央聚合器配合使用。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：可与组织级 AWS Config 和中央聚合器配合使用。
● 场景匹配：可与组织级 AWS Config 和中央聚合器配合使用。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 从技术上讲，它会阻止一些新的未加密的发布，但它不会评估现有资源或提供一个集中的合规性视图。
● 从技术上讲是可行的，但 StackSets 添加了每个帐户的部署和维护。
● Security Hub 可以集中发现结果，但它不强制实施 EBS 默认加密，而是依赖于 AWS Config 等底层控制。
工作流：使用 AWS Config 组织规则进行 EBS 默认加密 → SCP 来阻止禁用 Config。
Bucket仍然有对象/版本；使自定义资源清空存储桶
S3 要求删除前存储桶为空。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：S3 要求删除前存储桶为空。
● 场景匹配：S3 要求删除前存储桶为空。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 对象锁定从技术上可以阻止删除，但这是一种特殊情况，保留的对象在保留到期之前可能无法删除。
● 权限可能会导致失败，但单独授予删除权限并不会清空存储桶。
● 静态网站配置不会阻止删除空存储桶。
工作流：存储桶仍然有对象/版本 → 使自定义资源在删除时清空存储桶。
Auto Scaling 生命周期挂钩，用于将实例置于 Terminate:Wait 并创建
Terminate:Wait 中的生命周期挂钩会暂停终止，EventBridge 可以对该事件做出反应，以便您可以在完成生命周期操作之前运行清理操作。系统经理。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Terminate:Wait 中的生命周期挂钩会暂停终止，EventBridge 可以对该事件作出反应，以便您可以运行。
● 场景匹配：Terminate:Wait 中的生命周期挂钩会暂停终止，EventBridge 可以对该事件作出反应，以便您可以运行。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 维护时段适用于计划操作，不是事件驱动的，也不能暂停 Auto Scaling 终止工作流程。
● Terminate:Pending 不是有效的 Auto Scaling 生命周期状态，因此无法使用此挂钩。
● EC2 Image Builder 未设计为在 Auto Scaling 缩减事件中终止之前运行按实例、事件驱动的清理。
工作流：配置 Auto Scaling 生命周期挂钩以将实例置于 Terminate:Wait 中，并创建 Amazon EventBridge 规则来监控 Termination:Wait 事件 → 创建 AWS Systems Manager Automation Runbook 并进行配置。
AWS Config 托管和自定义规则，具有更改触发和定期评估
AWS Config 持续记录资源状态并根据规则对其进行评估，为配置合规性和变更审核提供权威服务。 CloudTrail 提供审计跟踪。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：AWS Config 持续记录资源状态并根据规则对其进行评估，为配置合规性提供权威服务。
● 场景匹配：AWS Config 持续记录资源状态并根据规则对其进行评估，为配置合规性提供权威服务。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 强调通过 EventBridge 和 Lambda 进行自动修复，当目标是持续评估和审核时则不需要这样做。
● 收集 SDK 日志与控制台无关，并且错过了完整的治理覆盖范围，使其对于组织范围的配置评估和合规性来说不可靠。
工作流：将 AWS Config 托管和自定义规则与更改触发和定期评估结合使用，并通过跨账户的聚合器集中合规性结果 → 在 AWS CloudTrail 中为所有人启用组织跟踪。
将凭证存储在 AWS Secrets Manager 中并在模板中解析它们
动态引用在部署时获取机密，因此明文值不会嵌入到模板或堆栈元数据中。 NoEcho 掩蔽参数值。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：动态引用在部署时获取机密，因此纯文本值不会嵌入到模板或堆栈元数据中。
● 场景匹配：动态引用在部署时获取机密，因此明文值不会嵌入到模板中。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 对静态模板进行加密不会阻止秘密值出现在堆栈事件或Describe* API 输出中。
● 标签不能用于解析 CloudFormation 中的安全字符串，也不能提供安全参数检索。
● CloudTrail 改进了审核，但不能防止秘密值在堆栈操作期间暴露。
工作流：将凭证存储在 AWS Secrets Manager 中，并使用 CloudFormation 动态引用在模板中解析它们 → 在敏感的 CloudFormation 参数上配置 NoEcho，以隐藏堆栈输出和事件中的值。
EventBridge 调度规则调用 Lambda，标记首次出现并在 30 后删除
计划的 EventBridge 规则运行 Lambda，通过标签跟踪首次分离的情况，并删除分离时间超过 30 天的卷。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：计划的 EventBridge 规则运行 Lambda，通过标签跟踪首次分离的情况，并删除分离时间超过 30 天的卷。
● 场景匹配：计划的 EventBridge 规则运行 Lambda，通过标签跟踪首次分离的情况，并删除分离时间超过 30 天的卷。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Trusted Advisor 可以列出未附加的卷，但不会跟踪 30 天的分离期限或直接触发自动化。
● 配置标记未附加的卷，但不管理每个卷的 30 天计时器；建立可靠的延迟/补救流程是脆弱的。
● 没有针对 EBS 分离期限的本机 CloudWatch 指标，因此您无法在分离 30 天时发出警报。
工作流：EventBridge 计划规则调用 Lambda，标记首次出现并在 30 天后删除。
当 aws:SecureTransport 等于 false 时拒绝任何请求的存储桶策略，请使用
当 aws:SecureTransport 为 false 时拒绝会强制执行 HTTPS、SSE-S3 在没有 KMS 配额的情况下进行扩展，并且 CRR 满足跨大陆 DR 要求。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：当 aws:SecureTransport 为 false 时拒绝会强制执行 HTTPS、SSE-S3 在没有 KMS 配额的情况下进行扩展，并且 CRR 满足跨大陆 DR 要求。
● 场景匹配：当 aws:SecureTransport 为 false 时拒绝会强制执行 HTTPS、SSE-S3 在没有 KMS 配额的情况下进行扩展，并且 CRR 满足跨大陆 DR。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 当 aws:SecureTransport 为 true 时，将通过拒绝来阻止 HTTPS 流量，这违反了传输中加密要求。
● 在强制执行 HTTPS 的同时，SSE-KMS 可以以非常高的放置速率（例如每秒 15000 个对象）引入 KMS 请求限制。
● CloudFront 不会跨区域复制 S3 数据，并且 SSE-KMS 在非常高的摄取量下仍然会出现瓶颈，因此这不能满足 DR 或性能需求。
工作流：添加存储桶策略，当 aws:SecureTransport 等于 false 时拒绝任何请求 → 使用 SSE-S3 进行默认加密，并配置 S3 跨区域复制。
CloudWatch Logs 订阅筛选器将 Kinesis Data Firehose（跨账户）传送到 S3
使用订阅过滤器流式传输到 Firehose 以实现近乎实时的 S3 传输； CreateLogGroup 上的 EventBridge 规则调用 Lambda 来为新组调用 PutSubscriptionFilter。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：使用订阅过滤器流式传输到 Firehose 以实现近乎实时的 S3 传输； CreateLogGroup 上的 EventBridge 规则调用 Lambda 来为新组调用 PutSubscriptionFilter。
● 场景匹配：使用订阅过滤器流式传输到 Firehose 以实现近乎实时的 S3 传输； CreateLogGroup 调用上的 EventBridge 规则。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● CloudTrail 将 API 活动记录到 S3，与流式传输 CloudWatch Logs 日志组数据无关。
● 导出是批量的，每个日志组都有时间限制，并且不会自动覆盖新组或提供持续交付。
● 虽然可能，但与 Firehose 相比，这增加了扩展和运营开销，并且不是最少工作量的组织范围模式。
工作流：CloudWatch Logs 订阅筛选器将 Kinesis Data Firehose（跨账户）传送到 S3，并通过 CreateLogGroup 上的 EventBridge + Lambda 自动附加。
仅出口互联网网关并在私有中添加 ::/0 路由
当路由表向其发送 ::/0 时，仅出口 Internet 网关将启用来自私有子网的仅出站 IPv6 流量。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：当路由表向其发送 ::/0 时，仅出口 Internet 网关将启用来自私有子网的仅出站 IPv6 流量。
● 场景匹配：当路由表向其发送 ::/0 时，仅出口 Internet 网关将启用来自私有子网的仅出站 IPv6 流量。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● NAT 实例和 0.0.0.0/0 路由仅寻址 IPv4 出口，不提供 IPv6 连接。
● 0.0.0.0/0 路由仅支持 IPv4，并且不启用私有子网的 IPv6 出口。
● NAT 网关不提供 IPv6 到 IPv6 出口，并且无法成为 IPv6 ::/0 路由的目标。
工作流：创建仅出口 Internet 网关，并在私有子网路由表中添加 ::/0 路由。
CodePipeline 中 CloudFormation 部署操作的 CAPABILITY_IAM 或 CAPABILITY_NAMED_IAM
这确认堆栈将创建或修改 IAM 资源，从而解决从 CodePipeline 运行时 CloudFormation 中的 InsufficientCapabilityException。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这确认堆栈将创建或修改 IAM 资源，从而解决从 CodePipeline 运行时 CloudFormation 中的 InsufficientCapabilityException。
● 场景匹配：这确认堆栈将创建或修改 IAM 资源，从而解决从 CodePipeline 运行时 CloudFormation 中的 InsufficientCapabilityException。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● S3 服务配额与 CloudFormation InsufficientCapabilityException 错误无关，该错误与确认某些资源类型的功能有关，而不是存储限制。
● 向管道角色授予更广泛的权限并不能解决在 CloudFormation 操作中显式确认 IAM 相关功能的要求。
● 循环依赖会产生不同的 CloudFormation 错误，而不是 InsufficientCapabilityException，这是特定于缺少功能确认的错误。
工作流：在 CodePipeline 中的 CloudFormation 部署操作上启用 CAPABILITY_IAM 或 CAPABILITY_NAMED_IAM。
阻止 S3 公共访问并向 CodeBuild 服务角色授予最低权限
使用 S3 阻止公共访问和存储桶/IAM 策略，仅允许 CodeBuild 角色读取所需的对象。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：使用 S3 阻止公共访问和存储桶/IAM 策略，仅允许 CodeBuild 角色读取所需的对象。
● 场景匹配：使用 S3 阻止公共访问和存储桶/IAM 策略，仅允许 CodeBuild 角色读取所需的对象。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 预签名 URL 是临时的，但仍然是不记名令牌，与基于角色的访问相比，会增加编排的复杂性。
● 环境变量中的长期静态凭证风险很高，并且不符合最佳实践；更喜欢短暂的角色凭证。
● 过于广泛的权限违反了最小权限并增加了爆炸半径。
工作流：阻止 S3 公共访问并向 CodeBuild 服务角色授予最低权限。
AWS Elastic Disaster Recovery 将 EC2 数据复制到跨区域暂存
AWS Elastic Disaster Recovery 持续复制到另一个区域的低成本暂存区域，并支持快速故障转移和故障恢复，只需最少的操作工作量。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：AWS Elastic Disaster Recovery 持续复制到另一个区域的低成本暂存区域，并支持快速故障转移和故障恢复，只需最少的操作工作量。
● 场景匹配：AWS Elastic Disaster Recovery 持续复制到另一个区域的低成本暂存区域并支持快速故障转移。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Resilience Hub 评估和跟踪弹性，但不复制 EC2 数据或提供本机故障转移/故障恢复自动化。
● 备份提供时间点快照而不是连续复制，故障注入模拟器用于混沌实验，而不是自动恢复。
● 应用程序迁移服务旨在用于迁移，与 AWS Elastic Disaster Recovery 相比，不建议使用用于简化、持续灾难恢复且具有快速故障恢复功能的服务。
工作流：使用 AWS Elastic Disaster Recovery 通过其代理将 EC2 数据复制到跨区域暂存区域子网。
将 GitHub 存储库与带有 Secrets Detector 的 Amazon CodeGuru Reviewer 关联起来
CodeGuru Reviewer Secrets Detector 在 PR 期间显示硬编码的秘密，可用于强制预防，而 Secrets Manager 可以安全地存储和自动轮换凭证。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CodeGuru Reviewer Secrets Detector 在 PR 期间显示硬编码的秘密，可用于强制预防，而 Secrets.
● 场景匹配：CodeGuru Reviewer Secrets Detector 在 PR 期间显示硬编码的秘密，可用于强制预防，而 Secrets.
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Macie 分析 Amazon S3 中的数据而不是 GitHub 中的源代码，并且环境变量不提供自动。
● CodeGuru Profiler 专注于性能分析而不是秘密检测，而 Parameter Store 缺乏本机自动轮换和 PR。
工作流：将 GitHub 存储库与带有 Secrets Detector 的 Amazon CodeGuru Reviewer 关联以进行拉取请求扫描，将数据库凭证迁移到启用轮换的 AWS Secrets Manager，并更新 SAM 和 Python 代码。
将凭证存储在 AWS Secrets Manager 中，授予 Lambda 角色 GetSecretValue
AWS Secrets Manager 旨在通过 IAM 控制的访问来存储密钥，并支持包括 Amazon RDS 在内的许多数据库的自动轮换。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：AWS Secrets Manager 旨在通过 IAM 控制的访问来存储密钥，并支持包括 Amazon RDS 在内的许多数据库的自动轮换。
● 场景匹配：AWS Secrets Manager 旨在通过 IAM 控制的访问来存储密钥，并支持许多数据库的自动轮换。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 保护检索，但缺乏数据库的本机凭证轮换，因此它不能像 Secrets Manager 那样完全满足轮换要求。
● AWS KMS 管理加密密钥而不是应用程序机密，因此它不适合存储和轮换数据库密码。
● AWS CloudHSM 提供硬件支持的密钥管理和加密操作，而不是数据库凭证的秘密存储或轮换。
工作流：将凭证存储在 AWS Secrets Manager 中 → 在秘密 ARN 上授予 Lambda 角色 GetSecretValue，并启用自动轮换。
具有每阶段参数覆盖的 CodePipeline CloudFormation 操作；使用参数和映射
每阶段参数会覆盖部署时传递的环境值，并且 CloudFormation 参数/映射保留一个可重用模板。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：每阶段参数会覆盖部署时传递的环境值，并且 CloudFormation 参数/映射保留一个可重用模板。
● 场景匹配：每阶段参数会覆盖部署时传递的环境值，并且 CloudFormation 参数/映射保留一个可重用模板。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 动态引用本身并不能传达管道中的环境上下文；您仍然需要特定于阶段的参数化。
● 将模板与管道内部耦合，增加了不必要的复杂性。
● 发布后的突变很脆弱，会破坏 CloudFormation 的声明性模型。
工作流：具有每阶段参数覆盖的 CodePipeline CloudFormation 操作 → 使用参数和映射。
Amazon API Gateway 直接集成到受 Amazon 保护的 AWS Step Functions
直接 API 网关到 Step Functions 使设计保持简单，支持长期运行的标准工作流程、扩展并使用 Cognito 进行身份验证。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：直接 API 网关到 Step Functions 使设计保持简单，支持长期运行的标准工作流程、扩展并使用 Cognito 进行身份验证。
● 场景匹配：直接 API 网关到 Step Functions 使设计保持简单，支持长期运行的标准工作流程、扩展并使用 Cognito 进行身份验证。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Lambda 有 15 分钟的执行限制，因此即使在 API Gateway 的前面，它也无法处理数小时的工作流程。
● 可以运行长任务，但这不是公共 API 最简单的方法，并且引入了容器/ALB 管理和扩展复杂性。
● 将 Lambda 添加为跃点会增加延迟、成本和潜在的限制，但与本机直接集成相比没有任何好处。
工作流：Amazon API Gateway 直接集成到由 Amazon Cognito 保护的 AWS Step Functions。
为 ALB 请求或导入 ACM 证书，关联 ACM
此配置在 CloudFront 和 ALB 上提供受信任的证书，并在查看器和源连接上强制执行 HTTPS。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：此配置在 CloudFront 和 ALB 上提供受信任的证书，并在查看器和源上强制执行 HTTPS。
● 场景匹配：此配置在 CloudFront 和 ALB 上提供受信任的证书，并在查看器和源上强制执行 HTTPS。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 对于原始 HTTPS，ALB 上的自签名证书不受 CloudFront 信任，并且不满足端到端加密。
● Match Viewer 允许来自查看器的 HTTP，并且可以将 HTTP 转发到源，因此 HTTPS 不是端到端强制执行的。
● CloudFront 无法使用存储在 S3 中的证书，默认证书不支持自定义 CNAME 和 HTTP 。
工作流：为 ALB 请求或导入 ACM 证书，将 us-east-1 中的 ACM 证书与 CloudFront 分配的自定义域关联 → 将查看器协议策略设置为仅 HTTPS，并将源配置为使用 HTTPS。
具有一致性包和聚合器的 AWS Config
持续记录和评估资源配置，聚合多账户合规性，并使用一致性包进行标准化策略报告。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：持续记录和评估资源配置，聚合多账户合规性，并使用一致性包进行标准化策略报告。
● 场景匹配：持续记录和评估资源配置，聚合多账户合规性，并使用一致性包进行标准化策略报告。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 聚合安全调查结果和标准，但依赖其他服务（例如 AWS Config）进行配置评估，并且不是近实时资源配置合规性的主要引擎。
● 重点关注 EC2 和 ECR 的漏洞和暴露评估，而不是跨 AWS 的广泛资源配置合规性。
● 以托管实例的补丁和 SSM 配置基准为目标，而不是组织范围内的 AWS 资源配置合规性。
工作流：具有一致性包和聚合器的 AWS Config。
带有版本控制的 S3 + EventBridge 计划 + Lambda 来刷新任务
S3 为 JSON 提供持久版本化存储，并具有审核和回滚功能，并且带有 Lambda 的 EventBridge 可以触发正在运行的任务的就地配置重新加载。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：S3 为 JSON 提供持久版本化存储，并具有审核和回滚功能，并且带有 Lambda 的 EventBridge 可以触发正在运行的任务的就地配置重新加载。
● 场景匹配：S3 为 JSON 提供持久版本化存储，并具有审核和回滚功能，并且带有 Lambda 的 EventBridge 可以触发正在运行的任务的就地配置重新加载。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Secrets Manager 用于凭证和轮换秘密；它成本高昂且不适合大型、不断增长的通用配置集。
● EFS 允许共享文件而无需重新启动，但缺乏内置版本控制和回滚审核历史记录。
● 高级层会增加成本，并且每个参数的大小限制对于许多文件来说变得很麻烦； API 限制和层次结构管理会大规模增加开销。
工作流：带有版本控制的 S3 + EventBridge 计划 + Lambda 来刷新任务。
AWS 数据库迁移服务 (DMS)
支持从 RDS Oracle 和 PostgreSQL 到 Amazon Redshift 的持续、高度可用的 CDC。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：支持从 RDS Oracle 和 PostgreSQL 到 Amazon Redshift 的持续、高度可用的 CDC。
● 场景匹配：支持从 RDS Oracle 和 PostgreSQL 到 Amazon Redshift 的持续、高度可用的 CDC。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 主要是批量ETL；不适用于将 CDC 连续复制到 Amazon Redshift 中。
● 摄取流事件，但缺乏从 RDS 到 Redshift 的本机 CDC。
● 零 ETL 当前针对 Aurora 源，而不是 RDS Oracle 或标准 RDS PostgreSQL。
工作流：AWS 数据库迁移服务 (DMS)。
在同一 S3 中使用新对象密钥上传每个版本
更改 S3Key 会强制 CloudFormation 检测新工件并更新 Lambda 代码。提供 S3ObjectVersion 可确保 CloudFormation 识别准确的工件版本和更新。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：更改 S3Key 会强制 CloudFormation 检测新工件并更新 Lambda 代码。
● 场景匹配：更改 S3Key 会强制 CloudFormation 检测新工件并更新 Lambda 代码。提供 S3ObjectVersion 确保。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 需要重新设计模板和部署流程，并且不直接解决 CloudFormation 对 Lambda 代码的更改检测。
● 等待不会导致 CloudFormation 重新部署，因为它仍然看到与 S3 相同的存储桶和密钥。
● 虽然 CodeDeploy 可以部署 Lambda，但切换工具并不能快速解决 CloudFormation 未检测到更改的 S3 的问题。
工作流：在同一 S3 存储桶中使用新对象密钥上传每个版本 → 为工件存储桶打开 S3 版本控制，并在 CloudFormation 中引用 S3ObjectVersion → 推送包。
跨两个区域的 Amazon Aurora 全球数据库并推广辅助数据库
Aurora Global Database 使用低延迟存储级复制和受控升级，轻松满足规定的 RPO 和 RTO。具有运行状况检查的故障转移路由会自动转移流量。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Aurora Global Database 使用低延迟存储级复制和受控升级，轻松满足规定的 RPO 和 RTO。
● 场景匹配：Aurora Global Database 使用低延迟存储级复制和受控升级，轻松满足规定的 RPO 和 RTO。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 该方法依赖于 DMS，并增加了延迟和复杂的切换，可能会危及 12 分钟的 RTO。
● 基于延迟的路由优化性能而不是灾难恢复，并且不会强制执行明确的主到辅助故障转移状态。
● Aurora多主不支持跨多个Region，因此无法提供跨Region的双活。
工作流：配置跨两个区域的 Amazon Aurora 全局数据库，并在主区域发生故障时提升辅助数据库的读/写 → 在两个区域中部署 Web 层并使用 Amazon Route。
采用基于属性的访问控制，使用带有标签匹配的主体和资源标签
ABAC 策略评估匹配的标签，以便自动覆盖新标记的资源，而无需更新策略本身。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：ABAC 策略评估匹配的标签，以便自动覆盖新标记的资源，而无需更新策略本身。
● 场景匹配：ABAC 策略评估匹配的标签，以便自动覆盖新标记的资源，而无需更新策略本身。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 需要对每个资源添加新策略，这并不能消除持续的维护负担。
● SCP 设置最大权限护栏，无法授予对资源的访问权限或消除策略更新。
● 权限边界仅定义允许的最大权限，并不授予对新资源的访问权限。
工作流：采用基于属性的访问控制，使用带有标签匹配策略的主体和资源标签。
为该函数配置并发并使用以下命令配置 Application Auto Scaling
预置并发使执行环境保持初始化和准备就绪，消除冷启动延迟，并允许您扩展容量以匹配可预测的峰值。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：预置并发使执行环境保持初始化和准备就绪，消除冷启动延迟，并允许您扩展容量以匹配可预测的峰值。
● 场景匹配：预置并发使执行环境保持初始化和准备就绪，消除冷启动延迟并允许您扩展容量。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 保留并发限制了函数可以达到的并发调用数量并隔离容量，但它不会预先初始化执行环境以避免冷启动。
● 更多内存可以减少初始化和运行时持续时间，但无法可靠地消除突发流量模式期间的冷启动。
● 增加临时存储可提供更大的临时磁盘空间，但不会影响函数初始化延迟或冷启动。
工作流：为该功能启用预配置并发，并配置 Application Auto Scaling，配置最少 2 个、最多 120 个预配置实例。
AWS Trusted Advisor 低利用率 EC2 通过 EventBridge 使用 Lambda 检查
Trusted Advisor 跨账户显示低利用率 EC2（商业/企业支持），EventBridge 捕获检查项目更改，Lambda 可以过滤标签并采取操作。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Trusted Advisor 跨账户显示低利用率 EC2（商业/企业支持），EventBridge 捕获检查项目更改，Lambda 可以过滤标签并采取操作。
● 场景匹配：Trusted Advisor 跨账户显示低利用率 EC2（商业/企业支持），EventBridge 捕获检查项更改，Lambda 可以进行过滤。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 使用 CloudWatch 利用率指标和 EventBridge 触发 Lambda 修复，但缺乏专门针对低利用率 EC2 的本机跨账户成本优化信号。
● 监控支出异常，而不是资源利用率水平，因此它不能可靠地定位持续低利用率的 EC2 实例。
● Compute Optimizer 提供建议，但它不是自动关闭的事件源，也不是为低利用率的直接自动修复而设计的。
工作流：AWS Trusted Advisor 低利用率 EC2 通过 EventBridge 检查，并使用按标签过滤的 Lambda 修复。
两个区域中的 Web 层通过 Amazon Route 53 故障转移到
两个区域 Web 层加上 Route 53 故障转移提供了有效的跨区域流量路径。 Aurora全球数据库持续复制到第二Region，支持快速升级。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：两个区域 Web 层加上 Route 53 故障转移提供了有效的跨区域流量路径。
● 场景匹配：两个区域 Web 层加上 Route 53 故障转移提供了有效的跨区域流量路径。 Aurora全球数据库持续复制到第二Region，支持快速升级。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● DMS 可以复制数据，但切换需要更多协调，并且可能存在滞后。
● 多可用区可防止一个区域内的可用区故障。
● 延迟路由选择最快的端点，而不是确定的主到辅助灾难恢复路径。
工作流：在两个区域中运行 Web 层，并通过 Amazon Route 53 故障转移到正常的 ALB → 跨两个区域使用 Amazon Aurora Global Database 并在故障期间提升辅助数据库。
具有预演应用程序和 Route 53 故障转移的跨区域 RDS MySQL 只读副本
跨区域只读副本加上热应用程序层和 Route 53 故障转移只需最少的更改即可满足 15 分钟的 RPO 和 120 分钟的 RTO。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：跨区域只读副本加上热应用程序层和 Route 53 故障转移只需最少的更改即可满足 15 分钟的 RPO 和 120 分钟的 RTO。
● 场景匹配：跨区域只读副本加上热应用程序层和 Route 53 故障转移只需最少的更改即可满足 15 分钟的 RPO 和 120 分钟的 RTO。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 提供强大的跨区域灾难恢复，但需要引擎迁移和配置更改。
● 多AZ仅限于单个Region，不能跨Region；延迟路由不是 DR。
● 可行，但增加了复杂性和手动步骤；与使用本机只读副本相比，RTO 可能更长并且变化更大。
工作流：具有预演应用程序和 Route 53 故障转移的跨区域 RDS MySQL 只读副本。
安装CloudWatch代理以将内存指标和警报发布到SNS +
CloudWatch 默认不收集内存；代理发布内存指标，并通过 SNS 发出警报通知。启用 ELB 运行状况检查后，Auto.
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudWatch 默认不收集内存；代理发布内存指标，并通过 SNS 发出警报通知。
● 场景匹配：CloudWatch 默认不收集内存；代理发布内存指标，并通过警报发出通知。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 自动恢复可解决底层主机或虚拟机管理程序问题，并且不会根据 ALB 目标组运行状况替换实例。
● CPU 扩展会添加或删除任务，但不会替换不健康的 EC2 实例或提供内存警报。
● 根据内存利用率扩展任务会更改任务计数，但不会替换发生故障的 EC2 实例或生成操作系统内存警报。
工作流：安装 CloudWatch 代理以将内存指标和警报发布到 SNS → 使用 ALB 目标组将 ASG 健康检查类型设置为 ELB。
与 CodePipeline 管道执行状态更改匹配的 Amazon EventBridge 规则以及
EventBridge 是 CodePipeline 状态和审批事件支持的事件总线，SNS 提供扇出和重试，Lambda 可以转换并发布到 Webhook。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：EventBridge 是 CodePipeline 状态和批准事件支持的事件总线，SNS 提供扇出和重试等。
● 场景匹配：EventBridge 是 CodePipeline 状态和批准事件支持的事件总线，SNS 提供扇出和重试等。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● AWS Config 评估资源配置合规性，并且本身不会检测 CodePipeline 执行状态更改事件。
● CloudTrail 记录 API 调用而不是所有服务发出的执行状态更改，并且依赖它会错过非 API 状态转换。
● CodePipeline 事件不会作为 CloudWatch Logs 发出，并且日志订阅筛选器无法定位 SNS。
工作流：创建与 CodePipeline 管道执行状态更改和需要手动批准事件匹配的 Amazon EventBridge 规则 → 将它们路由到 Amazon SNS 主题，并拥有 AWS Lambda 订阅。
停止使用任何 ACL 并仅允许通过严格范围的读取
最佳实践是避免 ACL 并使用针对特定主体的存储桶策略强制执行最低权限访问。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：最佳实践是避免 ACL 并使用针对特定主体的存储桶策略强制执行最低权限访问。
● 场景匹配：最佳实践是避免 ACL 并使用针对特定主体的存储桶策略强制执行最低权限访问。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 静态加密不会更改对象权限或被授权者。
● 阻止公共访问涵盖匿名/公共访问，而不是 AuthenticatedUsers 组。
● 端点策略仅影响通过该端点的流量，不会覆盖对象 ACL 或 Internet 访问。
工作流：停止使用任何 ACL，并仅允许通过范围严格的 S3 存储桶策略对选定帐户进行读取。
通过订阅将 CloudWatch Logs 发送到 Lambda；将实例标记为
CloudWatch Logs 订阅过滤器可以在匹配的登录事件上调用 Lambda；标记和计划的 EventBridge 规则可在所需的窗口内延迟终止。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudWatch Logs 订阅过滤器可以在匹配的登录事件上调用 Lambda；标记和计划的 EventBridge 规则。
● 场景匹配：CloudWatch Logs 订阅过滤器可以在匹配的登录事件上调用 Lambda；标记和计划的 EventBridge 规则。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● CloudTrail 记录 AWS API 活动，而不是系统日志中发现的操作系统级 SSH/RDP 登录，因此它不会检测所需的事件。
● ConsoleLogin 与 AWS 管理控制台登录相关，并不表示 EC2 实例上的操作系统级别登录。
● CloudWatch Logs 订阅不直接针对 Step Functions，每日计划可能会超过 10 小时的要求。
工作流：通过订阅将 CloudWatch Logs 发送到 Lambda → 在登录时标记实例 → 使用 EventBridge 计划调用 Lambda 在 10 小时内终止标记的实例。
每个目标区域中的 API Gateway API 并使用 Amazon Route 53
基于延迟的路由将客户端引导至最近的区域 API，而 DynamoDB 全局表则通过复制实现多区域、低延迟数据访问。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：基于延迟的路由将客户端引导至最近的区域 API，而 DynamoDB 全局表则支持多区域、低延迟的数据访问。
● 场景匹配：基于延迟的路由将客户端引导至最近的区域 API，而 DynamoDB 全局表则支持多区域、低延迟的数据访问。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 减少了 API 边缘的一些网络延迟，但将计算保留在一个区域中并且不提供。
● 故障转移路由是主动-被动的，不会为所有用户提供低延迟，因为只有主区域提供服务。
● 仅运行状况检查不会路由到最低延迟端点和区域本地表碎片数据，这会破坏单个。
工作流：在每个目标区域中创建 API Gateway API，并使用 Amazon Route 53 基于延迟的路由和运行状况检查 → 将每个 API 与同一区域 Lambda 函数集成并访问 DynamoDB 全局表。
构建一个 Step Functions 工作流程，调用两个 Lambda 函数来获取
通过 Step Functions 和 Lambda 自动执行快照、跨区域复制和恢复，减少了 RTO 的手动工作量，并使用频繁的计划快照来收紧 RPO。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：通过 Step Functions 和 Lambda 自动执行快照、跨区域复制和恢复，减少了 RTO 和使用的手动工作量。
● 场景匹配：通过 Step Functions 和 Lambda 自动执行快照、跨区域复制和恢复，减少了 RTO 和使用的手动工作量。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● RDS 不支持通过实例生命周期事件调度快照创建，以及使用 0% 的 CPU 作为故障转移。
● Trusted Advisor 不会发出 AWS 启动的 RDS 事件通知，并且与无服务器相比，ECS 增加了不必要的操作开销。
● RDS 多可用区故障转移仅限于单个区域，无法将备用区域放置在另一个区域。
工作流：构建一个 Step Functions 工作流程，调用两个 Lambda 函数来拍摄 RDS 快照 → 将它们复制到 ap-northeast-1，并在备份区域中自动恢复 → 计划每 30 分钟生成一次快照。
AWS CloudTrail 将日志传送到 Amazon S3 并使用 CloudTrail 日志
CloudTrail 日志文件完整性验证使用加密摘要和签名来证明日志没有被更改或删除，并保留事件顺序。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudTrail 日志文件完整性验证使用加密摘要和签名来证明日志没有被更改或删除，并保留事件顺序。
● 场景匹配：CloudTrail 日志文件完整性验证使用加密摘要和签名来证明没有日志被更改或删除。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● S3 对象锁提供不变性，但不能以加密方式证明 CloudTrail 日志来源或事件排序，并且 AWS Config 不会捕获所有 API 调用。
● Glacier Vault Lock 强制保留 WORM，但不验证 CloudTrail 是否生成了文件或其序列是否完整。
● CloudWatch Logs 可以针对模式发出警报，但不提供日志文件或排序的加密完整性验证。
工作流：配置 AWS CloudTrail 以将日志传送到 Amazon S3 并使用 CloudTrail 日志文件完整性验证来验证真实性和顺序。
buildspec.yml 中的 CODEBUILD_SOURCE_VERSION 用于命名工件
这使用一个内置变量来解析分支构建的源分支，从而实现简单且可扩展的工件命名。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这使用一个内置变量来解析分支构建的源分支，从而实现简单且可扩展的工件命名。
● 场景匹配：这使用一个内置变量来解析分支构建的源分支，从而实现简单且可扩展的工件命名。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 生成提交 SHA，而不是分支名称，因此它不满足基于分支的命名要求。
● 产生大量的管理开销，并且不能随着分支机构的变化而很好地扩展。
● 与在构建期间使用环境变量相比，增加了不必要的组件和复杂性。
工作流：在 buildspec.yml 中使用 CODEBUILD_SOURCE_VERSION 来命名工件。
AWS CodeDeploy 与 CodeDeployDefault.LambdaCanary10Percent5Minutes 用于 Lambda 别名流量转移
使用预定义的金丝雀配置转移一小部分流量以进行定时烘焙，然后在运行状况良好时完成。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：使用预定义的金丝雀配置转移一小部分流量以进行定时烘焙，然后在运行状况良好时完成。
● 场景匹配：使用预定义的金丝雀配置转移一小部分流量以进行定时烘焙，然后在运行状况良好时完成。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 手动门在全面推出之前不提供自动金丝雀流量转移或定时烘焙。
● 立即转移 100% 的流量，不提供有限的曝光或烘烤时间。
● API Gateway 金丝雀的目标是 API 阶段配置，而不是部署管道中的 Lambda 版本别名转移。
工作流：AWS CodeDeploy 与 CodeDeployDefault.LambdaCanary10Percent5Minutes 用于 Lambda 别名流量转移。
支持 cloudtrail 的 AWS Config 托管规则，定期评估 30 分钟，并且
该解决方案可检测独立于 CloudTrail 事件交付的时间表的不合规情况，并通过 StartLogging 自动重新启用日志记录，从而减少停机时间。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：该解决方案可检测独立于 CloudTrail 事件交付的时间表的不合规情况，并通过 StartLogging 自动重新启用日志记录，从而减少停机时间。
● 场景匹配：该解决方案可检测独立于 CloudTrail 事件交付的时间表的不合规情况，并通过 StartLogging 自动重新启用日志记录，从而减少停机时间。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 仅向操作员发出警报，并且仍然需要手动操作来恢复日志记录，从而增加了潜在的停机时间。
● 专注于DeleteTrail/CreateTrail对于恢复日志记录来说是不正确的，与对合规性状态做出反应相比，轮询会增加延迟。
● 启用 cloudtrail 的规则仅支持定期评估，默认情况下不会自动修复。
工作流：部署支持 cloudtrail 的 AWS Config 托管规则，并进行 30 分钟的定期评估，并使用 AWS Config 合规性更改的 EventBridge 规则来调用 Lambda 函数，该函数在受影响的跟踪上调用 StartLogging。
中央账户中的 CloudWatch Logs 目标并订阅 Kinesis
这使用跨账户 CloudWatch Logs 订阅 Firehose 流，该流传输到 S3，从而提供安全、集中且近乎无服务器的存储目标。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这使用跨账户 CloudWatch Logs 订阅 Firehose 流，该流传输到 S3，从而提供安全、集中且近乎无服务器的存储目标。
● 场景匹配：这使用跨账户 CloudWatch Logs 订阅传输到 S3 的 Firehose 流，从而提供安全性。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 添加了额外的 Kinesis Data Streams 层，该层需要分片配置和扩展，这与最低配置要求相冲突。
● OpenSearch 服务需要配置和管理容量，这不满足最低配置存储要求。
● Amazon Redshift 需要配置和操作数据仓库集群，这与低配置甚至无存储配置不相符。
工作流：在中央账户中配置 CloudWatch Logs 目标并订阅直接写入 Amazon S3 存储桶的 Kinesis Data Firehose 传输流。
Amazon Managed Service for Prometheus 用于收集指标和 Amazon Managed
Amazon Managed Service for Prometheus 集中提取来自 EKS、ECS 和本地集群的 Prometheus 指标，Amazon Managed Grafana 提供托管仪表板、查询和警报。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Amazon Managed Service for Prometheus 集中提取来自 EKS、ECS 和本地集群的 Prometheus 指标，Amazon Managed Grafana 提供托管仪表板、查询和警报。
● 场景匹配：Amazon Managed Service for Prometheus 集中提取来自 EKS、ECS、本地集群和 Amazon Managed 的 Prometheus 指标。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Stack 不是 Prometheus 原生的，并且不提供跨 EKS、ECS 和本地 Kubernetes 的时间序列指标的内聚抓取和聚合。
● Systems Manager 代理不会从容器中抓取 Prometheus 指标，并且 Amazon Managed Service for Prometheus 也不是可视化工具。
● AWS AppConfig 管理应用程序配置而不是指标，OpenSearch 主要用于日志和搜索，而不是 Prometheus 时间序列指标。
工作流：Amazon Managed Service for Prometheus 用于收集指标，Amazon Managed Grafana 用于可视化和分析。
在日志归档账户中创建跨账户 CloudWatch Logs 目标并附加
CloudWatch Logs 跨账户订阅可以传送到 Kinesis Data Firehose，S3 通过生命周期策略提供安全、集中且经济高效的归档。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CloudWatch Logs 跨账户订阅可以传送到 Kinesis Data Firehose，S3 提供安全、集中且经济高效的归档。
● 场景匹配：CloudWatch Logs 跨账户订阅可以传送到 Kinesis Data Firehose，S3 提供安全、集中且经济高效的归档。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Amazon EFS 不是 Kinesis Data Firehose 支持的目标，并且未针对低成本归档存储进行优化。
● 与直接传送到 S3 进行存档相比，使用 Lambda 写入 EFS 会增加复杂性和成本。
● Amazon Redshift 专为分析而设计，而不是廉价的长期日志归档，并且对于此用例而言成本高昂。
工作流：在日志归档账户中设置跨账户 CloudWatch Logs 目标，并附加来自每个成员账户的订阅筛选器 → 将目标连接到 Amazon Kinesis Data Firehose 传输流。
具有 Lambda@Edge 的 Amazon CloudFront + 具有 EC2 Auto Scaling 的应用程序负载均衡器
在边缘缓存内容，并允许边缘位置的自定义逻辑按路径或设备定制行为，从而减少延迟和源负载。提供到 EC2 目标的第 7 层主机和基于路径的路由，并根据需求经济高效地进行扩展。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：在边缘缓存内容，并允许边缘位置的自定义逻辑按路径或设备定制行为，从而减少延迟和源负载。
● 场景匹配：在边缘缓存内容并允许边缘位置的自定义逻辑通过路径或定制行为。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 提高可用性和路由性能，但缺乏缓存和每个请求路径逻辑，并增加成本。
● 执行基于 DNS 的决策，例如地理位置或延迟，但无法评估每个请求的 HTTP 路径。
● 提供 API 前门功能，但对于需要边缘缓存的 EC2 托管 Web 应用程序来说不需要，并且在没有路径感知缓存的情况下会增加成本。
工作流：具有 Lambda@Edge 的 Amazon CloudFront → 具有 EC2 Auto Scaling 的应用程序负载均衡器。
S3 存储桶策略未授予所需的权限 + 有
限制性或不正确的存储桶策略可能会拒绝 s3:GetObject 请求并导致 403 访问被拒绝。如果角色缺乏 s3:GetObject 权限、具有无效的信任关系或应用显式拒绝，S3 将返回 403 访问被拒绝。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：限制性或不正确的存储桶策略可能会拒绝 s3:GetObject 请求并导致 403 访问被拒绝。
● 场景匹配：限制性或不正确的存储桶策略可能会拒绝 s3:GetObject 请求并导致 403 访问被拒绝。如果。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● S3 默认加密本身不会阻止访问，因为 S3 会透明地为授权主体解密对象。
● 阻止出口通常会导致连接错误或超时，而不是 S3 403 访问被拒绝授权失败。
● 版本控制改变了对象版本的存储和检索方式，而不是调用者是否有权访问它们。
工作流：S3 存储桶策略未授予所需的权限 → 实例配置文件 IAM 角色配置错误。
在 CloudFormation 中构建只读副本、对其进行升级、升级和切换客户端
在主服务器提供流量时升级副本，然后升级副本，可以在最短的停机时间内实现短暂的切换。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：在主服务器提供流量时升级副本，然后升级副本，可以在最短的停机时间内实现短暂的切换。
● 场景匹配：在主服务器提供流量时升级副本，然后升级副本，可以在最短的停机时间内实现短暂的切换。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 直接在主服务器上更新 EngineVersion 可能会导致主要升级期间出现中断。
● 快照恢复和端点更改需要更长的切换和手动步骤，增加了停机风险。
● DMS 可以工作，但会为同引擎主要升级增加不必要的复杂性，而本机 RDS 方法就足够了。
工作流：在 CloudFormation 中构建只读副本，对其进行升级 → 升级，然后切换客户端。
StatusCheckFailed_System 上的 CloudWatch 警报调用 EC2 恢复
自动恢复会在系统状态检查失败时将实例迁移到新硬件，并保留 EBS 卷和实例属性。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：自动恢复会在系统状态检查失败时将实例迁移到新硬件，并保留 EBS 卷和实例属性。
● 场景匹配：自动恢复会在系统状态检查失败时将实例迁移到新硬件，并保留 EBS 卷和实例属性。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 将实例替换为新实例，而不是迁移同一实例，并且不会自动保留现有的 EBS 附件或属性。
● 重新启动可以解决操作系统级别的问题，但不能修复主机级别的电源或网络故障。
● 仅系统状态检查支持恢复操作，实例状态检查不支持恢复操作。
工作流：在 StatusCheckFailed_System 上配置 CloudWatch 警报以调用 EC2 恢复。
用于将登录事件发送到 AWS 的 CloudWatch Logs 订阅过滤器
这将创建一个从日志检测到标记和计划终止的自动化管道，满足 45 分钟的要求。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这将创建一个从日志检测到标记和计划终止的自动化管道，满足 45 分钟的要求。
● 场景匹配：这将创建一个从日志检测到标记和计划终止的自动化管道，满足 45 分钟的要求。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 为简单的事件到操作工作流程引入了不必要的编排，并增加了复杂性，但没有带来任何好处。
● 取决于人为干预，并且不保证在执行窗口内终止。
● CloudWatch 警报无法直接调用 Lambda，需要 SNS 或其他间接方式，因此如上所述，这种方法不适合。
工作流：使用 CloudWatch Logs 订阅筛选器将登录事件发送到 AWS Lambda 函数，该函数将隔离标签应用于源 EC2 实例，并将 Amazon EventBridge 计划配置为每 45 分钟运行一次，以调用另一个 Lambda 来终止具有该标签的所有实例。
Amazon GuardDuty 适用于具有委派管理员的整个组织，捕获 GuardDuty
GuardDuty 通过委派管理员支持组织范围内的聚合，并将结果发送到 EventBridge，EventBridge 可以路由到 Firehose 以传送到 S3。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：GuardDuty 通过委派管理员支持组织范围内的聚合，并将结果发送到 EventBridge，EventBridge 可以路由到 Firehose。
● 场景匹配：GuardDuty 通过委派管理员支持组织范围内的聚合，并将结果发送到 EventBridge，EventBridge 可以路由到 Firehose。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Inspector 专注于漏洞和网络暴露评估，而不是从 EC2 攻击日志中进行持续威胁检测。
● Macie 主要发现 S3 中的敏感数据并对其进行分类，并非旨在检测 EC2 攻击模式。
● 如果没有使用者，Kinesis Data Streams 本身不会交付到 S3，并且此设置缺少集中式组织管理员模型。
工作流：通过委派管理员为整个组织启用 Amazon GuardDuty → 通过管理员账户中的 EventBridge 规则捕获 GuardDuty 结果，并使用 Kinesis Data Firehose 将它们传送到 S3 存储桶。
使用 Amazon Kinesis Data Firehose 的 CloudWatch Logs 订阅筛选器
Kinesis Data Firehose 是 CloudWatch Logs 订阅受支持的目标，并将日志持续流式传输到 S3 以实现自动化。之后过渡到 S3 Glacier Deep Archive。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Kinesis Data Firehose 是 CloudWatch Logs 订阅的受支持目标，并将日志持续流式传输到 S3 中。
● 场景匹配：Kinesis Data Firehose 是 CloudWatch Logs 订阅受支持的目标，并将日志持续流式传输到 S3 中。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● CloudWatch Logs 订阅筛选器不支持 AWS DataSync 作为传输目标，因此此配对无效。
● 导出任务是需要编排的批量操作，并且不像流订阅那样自动化或连续。
工作流：创建使用 Amazon Kinesis Data Firehose 将所有日志传送到 S3 存储桶的 CloudWatch Logs 订阅筛选器 → 配置将日志对象转换到 S3 的 S3 生命周期规则。
S3 存储桶和联合角色调用的 AWS Config 更改触发规则
更改触发的 AWS Config 规则近乎实时地进行评估，并可以调用 SSM 自动化进行自动修复。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：更改触发的 AWS Config 规则近乎实时地进行评估，并可以调用 SSM 自动化进行自动修复。
● 场景匹配：更改触发的 AWS Config 规则近乎实时地进行评估，并可以调用 SSM 自动化进行自动修复。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 定期计划会引入延迟并依赖于自定义扫描，因此它不是接近实时的。
● 漂移检测不是事件驱动的，覆盖范围有限，并且不会立即针对访问更改。
● API 事件模式可能很脆弱，并且缺乏资源状态评估，从而导致偏差检测不太可靠。
工作流：S3 存储桶和联合角色的 AWS Config 更改触发规则通过 Lambda 调用 SSM 自动化进行回滚。
调用 API Gateway GetSdk 来获取客户端的 Lambda 函数
UpdateStage 在阶段更新（包括回滚）时触发，允许 Lambda 持续通过 GetSdk 拉取 SDK 并将其发布到 S3。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：UpdateStage 在阶段更新（包括回滚）时触发，允许 Lambda 持续通过 GetSdk 拉取 SDK 并将其发布到 S3。
● 场景匹配：UpdateStage 会触发阶段更新（包括回滚），从而允许 Lambda 持续通过 GetSdk 拉取 SDK 并发布它们。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 仅在管道执行内运行，可能会错过管道外部发生的回滚或阶段更改。
● CreateDeployment 在阶段回滚期间不会发出，因此在这些情况下将跳过 SDK 更新。
● CodePipeline 本身不支持仅在失败时运行的操作，并且这不会处理手动或自动回滚。
工作流：使用调用 API Gateway GetSdk 的 Lambda 函数来获取客户端 SDK 并将其上传到 S3，并从与 API Gateway UpdateStage 事件匹配的 EventBridge 规则调用它。
DeletionPolicy 保留所有资源、删除堆栈、创建新堆栈
这会在删除期间保留资源，并使用资源导入将它们置于新的堆栈名称下。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这会在删除期间保留资源，并使用资源导入将它们置于新的堆栈名称下。
● 场景匹配：这会在删除期间保留资源，并使用资源导入将它们置于新的堆栈名称下。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 挂钩验证或阻止操作，但无法保留现有资源或将现有资源导入到新堆栈中。
● 堆栈名称是不可变的，更改集不支持重命名。
● 快照会导致原始卷被删除，从而违反了不删除要求并阻止了该资源的导入。
工作流：对所有资源设置DeletionPolicy Retain，删除堆栈→创建新堆栈，导入现有资源，→删除Retain。
EC2 实例状态更改通知 SNS 的 EventBridge 规则
EventBridge 本身会发出 EC2 状态更改事件，并可以将它们路由到 SNS，以在所有转换中发出实时警报。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：EventBridge 本身会发出 EC2 状态更改事件，并可以将它们路由到 SNS，以在所有转换中发出实时警报。
● 场景匹配：EventBridge 本身会发出 EC2 状态更改事件，并可以将它们路由到 SNS，以在所有转换中发出实时警报。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● AWS Health 专注于账户或服务级别问题，不会发出每个实例的状态更改事件。
● 状态检查检测运行状况问题和恢复操作，但不会在每次启动、停止或终止状态更改时发出通知。
● CloudTrail 用于审核日志和 S3 传输，并不为所有实例状态转换提供及时、全面的通知。
工作流：用于向 SNS 发出 EC2 实例状态更改通知的 EventBridge 规则。
为暂存和生产构建两个 AWS CodePipeline 管道，使用单个
这一设计支持自动暂存发布，引入了生产审批门，并通过一个存储库和分支保持源代码管理简单。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：该设计支持自动暂存发布，引入了生产审批门，并保持源代码管理简单。
● 场景匹配：该设计支持自动暂存发布，引入了生产审批门，并保持源代码管理简单。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 多个存储库增加了不必要的复杂性，并且还通过强制批准来违反自动分段部署的要求。
● 与生产中手动批准的要求相矛盾，并且不必要地将源拆分到多个存储库。
● 无法提供单独的环境管道，并忽略了生产所需的手动批准。
工作流：为暂存和生产构建两个 AWS CodePipeline 管道→使用具有单独环境分支的单个 GitHub 存储库→在分支提交上触发→通过 AWS CloudFormation 进行部署，并且仅在生产管道中需要手动批准。
EventBridge 健康事件 + Lambda 在发生故障时重新创建 EC2；极光与
事件驱动的实例替换可避免热备用成本，并且 Aurora 副本可实现自动跨可用区故障转移。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：事件驱动的实例替换可避免热备用成本，并且 Aurora 副本可实现自动跨可用区故障转移。
● 场景匹配：事件驱动的实例替换可避免热备用成本，并且 Aurora 副本可实现自动跨可用区故障转移。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● DRS 专注于 EBS 支持的复制并增加了持续的复制成本，并且单实例 Aurora 缺乏自动跨可用区故障转移。
● 许可禁止 Auto Scaling，这不能保证 EFA 和实例存储处理。
● 维持付费备用状态并将数据库作为单点故障。
工作流：EventBridge 运行状况事件 + Lambda 在发生故障时重新创建 EC2 → Aurora 具有一个跨可用区副本。
绿色滚动更新，然后更改 ALB 侦听器默认操作
这会准备绿色并在负载均衡器上执行即时切换，而无需 DNS 传播。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这会准备绿色并在负载均衡器上执行即时切换，而无需 DNS 传播。
● 场景匹配：这会准备绿色并在负载均衡器上执行即时切换，而无需 DNS 传播。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 在准备就绪之前将流量路由至绿色，从而存在停机风险。
● Route 53 无法为目标组设置别名，并且 DNS TTL 延迟会阻止立即切换。
● 加权 DNS 仍然依赖于 TTL，并且使用单个 ALB 无法直接定位单独的目标组。
工作流：通过滚动更新部署绿色，→ 将 ALB 侦听器默认操作更改为绿色目标组。
滚动更新期间，暂停 HealthCheck、ReplaceUnhealthy、AZRebalance、AlarmNotification 和 ScheduledActions +
暂停这些进程可以防止意外的 Auto Scaling 操作与 CloudFormation 的滚动更新步骤发生冲突。调整阈值可防止 CloudFormation 回滚整个堆栈。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：暂停这些进程可以防止意外的 Auto Scaling 操作与 CloudFormation 的滚动更新步骤发生冲突。
● 场景匹配：暂停这些进程可以防止意外的 Auto Scaling 操作与 CloudFormation 的滚动更新步骤发生冲突。调整阈值。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 替换整个组不是一个以故障排除为重点的步骤，并且可能隐藏滚动更新失败的根本原因。
● 这些进程是 ELB 集成的滚动更新所必需的，暂停它们会停止进度并破坏部署。
● 启用成功信号可能会由于信号超时而延长或阻止更新，这在诊断推出停滞时会适得其反。
工作流：在滚动更新期间 → 暂停 HealthCheck、ReplaceUnhealthy、AZRebalance、AlarmNotification 和 ScheduledActions → 在 AutoScalingRollingUpdate 策略中设置 MinSuccessfulInstancesPercent，以避免在一小部分实例失败时发生全堆栈回滚 →。
具有必需标签规则的 AWS Config，通过 Amazon SNS 将评估发布到
AWS Config 提供资源清单和标签合规性评估，可以对这些评估进行流式传输和存储，以用于 QuickSight 中的报告和仪表板。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：AWS Config 提供资源清单和标签合规性评估，可以对这些评估进行流式传输和存储，以用于 QuickSight 中的报告和仪表板。
● 场景匹配：AWS Config 提供资源清单和标签合规性评估，可以对其进行流式传输和存储以用于报告和仪表板。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● CloudTrail 捕获 API 活动日志，而不是评估当前资源标签合规性，因此它不适合合规性仪表板。
● 服务目录侧重于策划的产品组合，不提供跨所有资源的帐户范围标签合规性评估。
● 资源浏览器有助于发现资源，但不提供合规性仪表板所需的基于规则的合规性检查或持续评估。
工作流：使用必需标签规则配置 AWS Config → 通过 Amazon SNS 将评估发布到 AWS Lambda 函数，该函数将结果写入 Amazon S3，并在 Amazon QuickSight 中进行可视化。
名为 na.shopwidget.net 的子域，具有故障转移路由，将 us-west-2 ALB 设置为
在每个子域下通过区域特定的故障转移在顶点堆叠延迟，通过自动跨区域故障转移提供最低延迟的路由。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：在每个子域下通过区域特定的故障转移在顶点堆叠延迟，通过自动跨区域故障转移提供最低延迟的路由。
● 场景匹配：在每个子域下通过区域特定的故障转移在顶点堆叠延迟，通过自动跨区域故障转移提供最低延迟的路由。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 多值路由返回多个健康记录，并且不保证最低延迟选择或协调的区域故障转移行为。
● 通过将延迟放在子域级别并将故障转移放在顶点来反转所需的分层，但事实并非如此。
● 加权和地理位置路由不能确保区域之间的最低延迟或自动故障转移。
工作流：使用故障转移路由创建名为 na.shopwidget.net 的子域，将 us-west-2 ALB 设置为主要，将 eu-central-1 ALB 设置为辅助 → 创建具有故障转移路由的 eu.shopwidget.net，将 eu-central-1 ALB 设置为主要。
启用轮换的 AWS Secrets Manager
专门构建的秘密存储，具有 IAM 访问控制和 RDS 的托管轮换工作流程。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：专门构建的秘密存储，具有 IAM 访问控制和 RDS 的托管轮换工作流程。
● 场景匹配：专门构建的秘密存储，具有 IAM 访问控制和 RDS 的托管轮换工作流程。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 安全存储和检索，但 RDS 没有原生自动轮换；需要自定义旋转逻辑。
● 通过使用短期令牌消除密码，但不满足需要轮换数据库密码的策略。
● 管理加密密钥，而不是应用程序机密；无法存储或轮换数据库凭据。
工作流：启用轮换的 AWS Secrets Manager。
EC2 与 SSM 补丁管理器和适用于 EBS 的 Amazon 数据生命周期管理器
SSM 补丁管理器可自动执行操作系统修补，DLM 可保留并安排 EBS 快照，从而最大限度地减少工作量。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：SSM 补丁管理器可自动执行操作系统修补，DLM 可保留并安排 EBS 快照，从而最大限度地减少工作量。
● 场景匹配：SSM 补丁管理器可自动执行操作系统修补，DLM 可保留并安排 EBS 快照，从而最大限度地减少工作量。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● RDS for Oracle 不支持 Oracle RAC，因此无法托管 RAC 部署。
● 与本机补丁自动化和 DLM 相比，更重并且滥用 CI/CD 工具进行补丁。
● Aurora 不是 Oracle，也不支持 Oracle RAC，因此它不是此工作负载的可行目标。
工作流：EC2 带有用于 EBS 快照的 SSM 补丁管理器和 Amazon 数据生命周期管理器。
在 Amazon S3 中托管静态网站，通过 Amazon CloudFront 分发，以及
S3 提供无服务器静态托管，CloudFront 加速全球交付，AWS WAF 帮助防范常见的 Web 漏洞。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：S3 提供无服务器静态托管，CloudFront 加速全球交付，AWS WAF 帮助防范常见的 Web 漏洞。
● 场景匹配：S3 提供无服务器静态托管，CloudFront 加速全球交付，AWS WAF 帮助防范常见的 Web 漏洞。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 为静态站点引入不必要的计算，GuardDuty 可以检测威胁，但不会阻止边缘的 Web 攻击。
● EC2 不是无服务器，Redis 不会加速向用户交付静态资产，Shield 专注于 DDoS 而不是一般的 Web 漏洞利用缓解。
● Fargate 是无服务器的，但对于静态内容来说是不必要的，Redis 不用于服务静态网站资产，这缺乏所需的全局 CDN 加速。
工作流：在 Amazon S3 中托管静态网站，通过 Amazon CloudFront 进行分发，并应用 AWS WAF Web ACL。
针对 Systems Manager Run Command 的 EC2 Auto Scaling 事件的 EventBridge 规则
使用本机 Auto Scaling 启动/终止事件在批处理实例上触发立即运行命令以刷新文件。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：使用本机 Auto Scaling 启动/终止事件在批处理实例上触发立即运行命令以刷新文件。
● 场景匹配：使用本机 Auto Scaling 启动/终止事件在批处理实例上触发立即运行命令以刷新文件。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 依赖频繁的 API 轮询和自定义代码，效率低下并且可能会错过快速更改。
● AWS Config 用于配置合规性，并未针对近实时扩展反应进行优化。
● 生命周期挂钩和 SNS 通知本身不会更新批处理实例并增加操作开销。
工作流：针对 Systems Manager Run Command 的 EC2 Auto Scaling 事件的 EventBridge 规则。
将 Jenkins 构建工作负载迁移到 AWS CodeBuild 并启用加密
CodeBuild 是一项完全托管的服务，支持 KMS 支持的工件加密，并且无需管理 EC2 主机。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CodeBuild 是一项完全托管的服务，支持 KMS 支持的工件加密，并且无需管理 EC2 主机。
● 场景匹配：CodeBuild 是一项完全托管的服务，支持 KMS 支持的工件加密，并且无需管理 EC2 主机。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 存储桶加密可以保护 S3 中的对象，但这需要 Jenkins 进行管理，并且不能保证工件在上传前进行加密。
● 修补和 EBS 加密可以保护实例和磁盘，但不能直接确保工件加密，并且仍然会留下大量的运营开销。
● ACM 颁发 TLS 证书以确保传输过程中的安全性，并且不为构建工件提供静态加密。
工作流：将 Jenkins 构建工作负载迁移到 AWS CodeBuild 并为构建工件启用加密。
AWS Systems Manager 运行命令以在
Run Command 允许您在托管实例上安全地执行临时配置，而无需分发或存储 SSH 密钥。使用 CodeBuild IAM 角色消除了这种需要。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Run Command 允许您在托管实例上安全地执行临时配置，而无需分发或存储 SSH 密钥。
● 场景匹配：Run Command 允许您在托管实例上安全地执行临时配置，而无需分发或存储 SSH 密钥。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 将凭证保存在 S3 中，即使是加密的，也会增加暴露程度，并且不是推荐的构建秘密管理方法。
● Secrets Manager 不使用 SecureString 类型，因此尽管 Secrets Manager 本身可以使用 SecureString 类型，但这种措辞是不正确的。
工作流：使用 AWS Systems Manager Run Command 在实例上应用一次性配置，而不是使用 Amazon S3 中的密钥应用 ssh 和 scp → 授予 CodeBuild 服务角色最低权限。
具有每个环境基线和补丁组的补丁管理器；按 env 标记和
使用补丁管理器基线和由标签映射的补丁组来应用不同的规则和序列环境。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：使用补丁管理器基线和由标签映射的补丁组来应用不同的规则和序列环境。
● 场景匹配：使用补丁管理器基线和由标签映射的补丁组来应用不同的规则和序列环境。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 需要自定义脚本和手动补丁选择，增加了工作量和风险。
● 黄金 AMI 替换在操作上更加繁重，并且不直接强制执行每个环境的补丁规则。
● 提供计划，但不提供审批规则和每个环境的基线，无需补丁管理器。
工作流：具有每个环境基线和补丁组的补丁管理器 → 按环境和操作系统进行标记。
每个区域中的区域 API 网关，具有基于 Route 53 延迟的本地路由
基于延迟的路由将客户端发送到延迟最低的区域 API，全局表提供多区域数据复制。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：基于延迟的路由将客户端发送到延迟最低的区域 API，全局表提供多区域数据复制。
● 场景匹配：基于延迟的路由将客户端发送到延迟最低的区域 API，全局表提供多区域数据复制。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 边缘优化减少了边缘到区域的延迟，但将计算保留在一个区域中，因此它不是主动-主动多区域。
● 故障转移是主动-被动的，因此只有一个区域以稳定状态提供流量。
● Global Accelerator 不支持 API Gateway 作为端点，这种设计将不起作用。
工作流：每个区域中的区域 API 网关，具有基于 Route 53 延迟的路由、本地 Lambda、DynamoDB 全局表。
访问应用程序负载均衡器上的日志记录并将目标配置为
ALB访问日志将详细的请求日志直接写入S3，满足负载均衡器日志收集的要求。使用 awslogs 驱动程序集中容器 STDOUT/STDERR。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：ALB访问日志将详细的请求日志直接写入S3，满足收集负载均衡器的要求。
● 场景匹配：ALB访问日志将详细的请求日志直接写入S3，满足收集负载均衡器的要求。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Amazon Macie 专注于敏感数据发现和分类，而不是低延迟日志摄取或分析。
● CloudWatch 详细监控提供更高分辨率的指标，而不是请求级访问日志或传输到 S3。
● CloudWatch Logs 导出任务是批量操作，不适用于近实时流式传输到 S3，因此不适合。
工作流：在应用程序负载均衡器上启用访问日志记录并将目标配置为指定的 S3 存储桶 → 在 ECS 任务定义中使用 awslogs 日志驱动程序 → 安装 CloudWatch Logs。
带 KMS 的参数存储 SecureString；使用实例角色和 CodeDeploy 本地注册
SecureString 使用 KMS 进行静态加密，TLS 提供传输中加密，实例角色（EC2 配置文件和通过 CodeDeploy 注册进行本地部署）允许运行时检索。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：SecureString 使用 KMS 进行静态加密，TLS 提供传输中加密，以及实例角色（EC2 配置文件和.
● 场景匹配：SecureString 使用 KMS 进行静态加密，TLS 提供传输中加密，以及实例角色（EC2 配置文件和.
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 在部署工件中嵌入机密违反了避免将凭证存储在代码或包中的要求，并且存在暴露风险。
● CodeDeploy 服务角色不会将机密推送到实例中；应用程序应使用附加角色在运行时检索机密。
● 您不能将独立策略附加到服务器；您必须使用角色（EC2 和本地注册的实例配置文件）进行最低权限访问。
工作流：带有 KMS 的 Parameter Store SecureString → 使用实例角色和 CodeDeploy 本地注册 → 应用程序在运行时获取。
指定防火墙管理器管理员并应用组织级 WAF 策略来自动附加
防火墙管理器集中实施组织范围内的 WAF 策略，并自动将其应用于跨账户和区域的匹配资源。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：防火墙管理器集中实施组织范围内的 WAF 策略，并自动将其应用于跨账户和区域的匹配资源。
● 场景匹配：防火墙管理器集中实施组织范围内的 WAF 策略，并自动将其应用于跨账户和区域的匹配资源。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Config 可以根据规则进行检测和修复，但它不是跨账户和区域的 WAF 专用的、连续的、组织范围的策略引擎。
● StackSets 可以推出模板，但不会持续发现和自动附加新创建的资源的 WAF 或强制执行持续的策略。
● SCP 限制权限，但无法附加或强制执行 WAF 关联等资源配置。
工作流：指定防火墙管理器管理员并应用组织级 WAF 策略，将 Web ACL 自动附加到每个区域中的所有公共 ALB 和 API 网关。
Auto Scaling 生命周期挂钩实例终止并使用 Amazon
通过使用 EventBridge 和 Lambda 调用 SSM Run Command 的终止生命周期挂钩，您可以在关闭之前可靠地检索实例日志并将其持久存储在 S3 中。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：通过使用 EventBridge 和 Lambda 调用 SSM Run Command 的终止生命周期挂钩，您可以可靠地检索实例日志。
● 场景匹配：通过 EventBridge 和 Lambda 调用 SSM Run Command 的终止生命周期挂钩，您可以可靠地检索实例日志。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● VPC 流日志记录网络流量元数据而不是应用程序或系统日志，因此它们不会捕获。
● 运行状况检查设置不解决收集或保存实例日志的问题，并且没有证据表明它们配置错误。
工作流：在实例终止时配置 Auto Scaling 生命周期挂钩，并使用 Amazon EventBridge 规则触发运行 AWS Systems Manager Run Command 的 AWS Lambda 函数来提取应用程序日志。
用于在 Amazon ElastiCache for Redis 中保留会话状态的应用程序
ElastiCache (Redis) 是一种内存中的共享会话存储，可提供微秒级延迟并在实例替换后仍能正常运行。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：ElastiCache (Redis) 是一种内存中的共享会话存储，可提供微秒级延迟并在实例替换后仍能正常运行。
● 场景匹配：ElastiCache (Redis) 是一种内存中的共享会话存储，可提供微秒级延迟并在实例替换后仍能正常运行。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 粘性将用户与单个实例联系在一起，并且本地存储在缩减或替换时会丢失，因此会话仍然会中断。
● DynamoDB 提供共享、持久的存储，但对于每个请求会话查找来说，其延迟高于内存缓存。
● S3 很耐用，但对于 Web 流量期间频繁的会话读写而言，请求延迟太高。
工作流：配置应用程序以在 Amazon ElastiCache for Redis 集群中保留会话状态。
CloudWatch Logs 指标过滤器以及发送到 SNS 的 CloudWatch 警报
指标过滤器与“CRITICAL”日志行匹配，CloudWatch 警报在指标上触发，并且 SNS 发送电子邮件。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：指标过滤器与“CRITICAL”日志行匹配，CloudWatch 警报在指标上触发，并且 SNS 发送电子邮件。
● 场景匹配：指标过滤器与“CRITICAL”日志行匹配，CloudWatch 警报在指标上触发，并且 SNS 发送电子邮件。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● Firewall Manager 强制执行安全策略，但不会生成任意 CloudWatch Logs 严重性的警报。
● Logs Insights 不会直接将结果实时发送到 SNS，也不适用于每行警报。
● Synthetics 测试端点和 API，而不是 CloudWatch Logs 的内容。
工作流：CloudWatch Logs 指标筛选器以及发送到 SNS 的 CloudWatch 警报。
AWS SAM 与 CodeDeploy canary (DeploymentPreference Canary10Percent10Minutes)
SAM 将 Lambda 别名与 CodeDeploy 集成，以最少的配置实现自动化金丝雀和回滚。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：SAM 将 Lambda 别名与 CodeDeploy 集成，以最少的配置实现自动化金丝雀和回滚。
● 场景匹配：SAM 将 Lambda 别名与 CodeDeploy 集成，以最少的配置实现自动化金丝雀和回滚。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 处理配置推出，而不是 Lambda 版本流量转移或部署回滚。
● 交换整个环境，并且缺乏内置的基于百分比的 Lambda 流量转移。
● 转移 API 阶段流量，但不管理 Lambda 版本部署或自动回滚。
工作流：AWS SAM 与 CodeDeploy canary (DeploymentPreference Canary10Percent10Minutes)。
部署期间发生 Auto Scaling 横向扩展事件，因此新的
当部署中期发生横向扩展时，新实例将使用最近成功的修订进行初始化，即使部署成功完成，也会导致混合队列。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：当部署中期发生横向扩展时，新实例将使用最近成功的修订进行初始化，即使部署成功完成，也会导致混合队列。
● 场景匹配：当部署中期发生横向扩展时，新实例将使用最近成功的修订进行初始化，从而导致混合。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● CloudWatch 警报不会导致 CodeDeploy 报告成功，同时将某些实例保留在旧版本上。
● 如果 IAM 对修订版本的访问被阻止，CodeDeploy 会将部署标记为失败而不是成功。
● 过时的模板会影响启动设置，但 CodeDeploy 仍会更新目标实例，因此这并不能解释混合版本的成功部署。
工作流：部署期间发生了 Auto Scaling 横向扩展事件，因此新实例使用上次成功部署的修订版本启动。
适用于具有 ALB 的 EC2/本地的 AWS CodeDeploy Blue/Green，将原始实例设置为
CodeDeploy Blue/Green 在负载均衡器后面提供替换队列，支持验证后的流量转移，并可以在配置的等待后自动终止原始实例。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CodeDeploy Blue/Green 在负载均衡器后面提供替换队列，支持验证后的流量转移，并且可以自动进行。
● 场景匹配：CodeDeploy Blue/Green 在负载均衡器后面提供替换队列，支持验证后的流量转移，并且可以自动进行。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 滚动更新会在同一环境中批量替换实例，并且不会为其配置完全独立的队列。
● 就地滚动更新修改现有机队，而不是创建完整的绿色环境，并且缺乏内置功能。
● 自定义方法可以工作，但缺乏 CodeDeploy 为蓝/绿提供的本机编排、状态跟踪和回滚安全性。
工作流：使用适用于 EC2/本地的 AWS CodeDeploy Blue/Green 和 ALB → 将原始实例设置为在 90 分钟等待期后终止。
用于 Trusted Advisor 更新并发送到 SNS + 的 EventBridge 规则
EventBridge 可以匹配 Trusted Advisor 事件并路由到 SNS 以获取即时通知。定期 Lambda 可以查询 TA 调查结果并向 SNS 订阅者推送警报。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：EventBridge 可以匹配 Trusted Advisor 事件并路由到 SNS 以获取即时通知。
● 场景匹配：EventBridge 可以匹配 Trusted Advisor 事件并路由到 SNS 以获取即时通知。可以定期进行 Lambda 查询。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 每周摘要会延迟，不适合即时警报。
● EventBridge 本身并不针对 SES；使用 SNS 或 Lambda 进行电子邮件传送。
● AWS Health 不会发出 Trusted Advisor 检查更改事件。
工作流：为 Trusted Advisor 更新创建 EventBridge 规则并发送到 SNS → 每 30 分钟安排一次 Lambda 来调用 Trusted Advisor API 并发布到 SNS → 每小时运行一次 Lambda 将 TA 结果写入 CloudWatch Logs → 添加指标过滤器和警报以进行通知。
具有托管加密卷规则的 AWS Config 组织聚合器；集中结果和 SNS
使用 AWS Config 管理合规性和组织范围内的聚合，以实现最少的操作和近乎实时的检测。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：使用 AWS Config 管理合规性和组织范围内的聚合，以实现最少的操作和近乎实时的检测。
● 场景匹配：使用 AWS Config 管理合规性和组织范围内的聚合，以实现最少的操作和近乎实时的检测。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 是具有事件关联的自定义日志解析，并且工作量很大，而不是本机合规性解决方案。
● 可行，但与组织级聚合相比，跨多个账户和区域管理 StackSet 会增加运营开销。
● Security Hub 依赖 AWS Config 进行这些检查，本身不提供托管规则或组织范围的 Config 聚合。
工作流：具有托管加密卷规则的 AWS Config 组织聚合器 → 集中结果和 SNS。
具有启用 cloudtrail 或 cloudtrail-security-trail 的托管规则和 EventBridge 的 AWS Config
AWS Config 持续评估合规性，提供评估的审计跟踪，并且通过 EventBridge 触发的 Lambda 可以在 CloudTrail 禁用时自动修复。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：AWS Config 持续评估合规性，提供评估的审计跟踪，并且通过 EventBridge 触发的 Lambda 可以自动修复。
● 场景匹配：AWS Config 持续评估合规性，提供评估的审计跟踪，并且通过 EventBridge 触发的 Lambda 可以自动修复。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 基于组的拒绝可以被角色或根用户绕过，并且计划轮询不能提供持续的合规性。
● 定期 Lambda 检查缺乏配置合规性历史记录，与事件驱动的合规性评估相比，可能会错过或延迟检测。
● SCP 可以阻止某些操作，但不能确保 CloudTrail 最初启用，也不能创建合规性。
工作流：将 AWS Config 与启用了 cloudtrail 或启用了 cloudtrail-security-trail 的托管规则以及 EventBridge 规则结合使用，该规则会触发对不合规评估的 Lambda 修复，以重新打开 CloudTrail 并记录更改。
自定义 CloudWatch 指标并发布汇总统计数据集
发布统计数据集将许多样本聚合到每分钟一次 PutMetricData 调用中，以较低的成本提供 1 分钟的粒度。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：发布统计数据集将许多样本聚合到每分钟一次 PutMetricData 调用中，以较低的成本提供 1 分钟的粒度。
● 场景匹配：发布统计数据集将许多样本聚合到每分钟一次 PutMetricData 调用中，提供 1 分钟粒度。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 默认指标不接受自定义应用程序数据，并且维度不会创建新指标，因此这不会捕获脚本输出。
● 合成可以运行金丝雀，但不利用 EC2 脚本输出，并且当 1 分钟粒度足够时，通常比聚合自定义指标的成本更高。
● 高分辨率和频繁发布会增加成本，并且当仅需要 1 分钟粒度时是不必要的。
工作流：创建自定义 CloudWatch 指标并发布汇总 5 秒结果的统计数据集，每 60 秒发送一次更新。
Amazon EventBridge 每小时触发一次 AWS Lambda 函数进行枚举
这种检测控制可以按计划识别并修复偏差，同时保持启动畅通无阻，从而最大限度地减少对 CI/CD 的影响。 AWS Config 持续评估 AMI 合规性并进行配对。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这种检测控制可以按计划识别并修复偏差，同时保持启动畅通无阻，从而最大限度地减少对 CI/CD 的影响。
● 场景匹配：这种检测控制可以按计划识别并修复偏差，同时保持启动畅通无阻，从而最大限度地减少对 CI/CD 的影响。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● Amazon Inspector 专注于漏洞和暴露评估，不会可靠地执行或检测 AMI 许可名单以确保合规性。
● SCP 是一种预防性控制措施，可以阻止未经批准的 AMI 的启动，并可能扰乱或减慢进程。
工作流：使用 Amazon EventBridge 每小时触发一个 AWS Lambda 函数，以枚举暂存和生产 VPC 中正在运行的 EC2 实例，将其 AMI ID 与批准的列表进行比较 → 发布。
CodeDeploy 预流量挂钩，用于运行 Lambda 验证并使部署失败
CodeDeploy 生命周期事件 BeforeAllowTraffic 可以调用验证 Lambda，失败则中止并回滚。部署组警报可以停止部署、发送 SNS 通知等。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：CodeDeploy 生命周期事件 BeforeAllowTraffic 可以调用验证 Lambda，失败则中止并回滚。
● 场景匹配：CodeDeploy 生命周期事件 BeforeAllowTraffic 可以调用验证 Lambda，失败则中止并回滚。部署组警报。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● CloudWatch 警报评估指标，而不是直接从 Lambda 发送的任意负载。
● 班后验证不满足实时流量之前测试的要求。
● AppConfig 验证器适用于配置部署，而不适用于通过 CodeDeploy 的 Lambda 代码部署。
工作流：使用 CodeDeploy 预流量钩子运行 Lambda 验证并在出现错误时使部署失败 → 将 CloudWatch 警报附加到部署组，以便警报违规通知 SNS 并触发回滚 → 在部署期间运行验证并驱动部署组 CloudWatch 警报从检查中停止并回滚。
EC2 复制工作人员在 us-east-2 中使用 Auto Scaling 持续推送增量
使用 S3 作为跨区域传输可避免 VPC 对等互连，并且具有扩展指标的基于 EC2 的连续复制可维持热 EFS 以实现低 RPO 和 RTO。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：使用 S3 作为跨区域传输可以避免 VPC 对等互连，并且可以维持具有扩展指标的基于 EC2 的连续复制。
● 场景匹配：使用 S3 作为跨区域传输可以避免 VPC 对等互连，并且可以维持具有扩展指标的基于 EC2 的连续复制。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 引入计划的 30 分钟间隔，以防止热复制并提高 RPO。
● 您无法跨 AWS 区域或从非对等 VPC 挂载 EFS 文件系统，因此请直接跨区域挂载。
● DataSync 需要对两个位置进行网络访问，并且通常按计划运行，因此它无法满足无连接约束。
工作流：在 us-east-2 中运行具有 Auto Scaling 的 EC2 复制工作线程，使用自定义积压指标进行扩展，不断将增量推送到 ap-northeast-1 中的 S3 存储桶，并运行第二个复制队列。
使用 Lambda 任务和 SNS 通知将 EventBridge 安排到 Step Functions
通过重试和选择分支提供状态编排，用于区域回退、执行历史记录、调度和通过 SNS 发送电子邮件。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：通过重试和选择分支提供状态编排，用于区域回退、执行历史记录、调度和通过 SNS 发送电子邮件。
● 场景匹配：通过重试和选择分支提供状态编排，用于区域回退、执行历史记录、调度和通过 SNS 发送电子邮件。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 强大的 DAG 编排，但操作繁重，对于简单的夜间备份工作流程来说是不必要的。
● 支持计划的 EBS 备份和带通知的跨区域副本，但不提供每次运行的条件多区域回退逻辑。
● 单个 Lambda 存在超时和复杂错误处理的风险，并且 AWS Config 不是执行审计跟踪。
工作流：EventBridge 通过 Lambda 任务和 SNS 通知安排到 Step Functions。
具有输出 Export 和 Fn::ImportValue 的模块化堆栈
通过导出的输出和 Fn::ImportValue 进行跨堆栈引用可解耦生命周期，同时可靠地共享值。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：通过导出的输出和 Fn::ImportValue 进行跨堆栈引用可解耦生命周期，同时可靠地共享值。
● 场景匹配：通过导出的输出和 Fn::ImportValue 进行跨堆栈引用可解耦生命周期，同时可靠地共享值。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 嵌套堆栈共享生命周期并依赖参数，这使组件紧密耦合并限制独立更新。
● StackSets 的目标是多账户或多区域部署，而不是堆栈间价值共享，并且仍然通过参数耦合堆栈。
● 外部化状态并绕过本机跨堆栈连接，增加了复杂性并削弱了更改跟踪。
工作流：具有输出 Export 和 Fn::ImportValue 的模块化堆栈。
从数据库堆栈导出输出并将其导入应用程序
跨堆栈导出和 Fn::ImportValue 允许应用程序堆栈消耗数据库资源，同时保持堆栈和更改集独立。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：跨堆栈导出和 Fn::ImportValue 允许应用程序堆栈消耗数据库资源，同时保持堆栈和更改集独立。
● 场景匹配：跨堆栈导出和 Fn::ImportValue 允许应用程序堆栈消耗数据库资源，同时保持堆栈和更改集独立。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● StackSet 旨在管理跨多个账户和区域的堆栈，而不是用于单个账户和区域内的跨堆栈引用。
● 嵌套堆栈将资源绑定到一个父堆栈中，其中更改集在整个层次结构中级联，从而减少了团队之间的独立性。
● Parameter Store 不会创建 CloudFormation 管理的依赖项或更改堆栈之间的集可见性，从而存在 CloudFormation 外部漂移和耦合的风险。
工作流：从数据库堆栈导出输出并使用 Fn::ImportValue 将其导入应用程序堆栈。
Systems Manager Automation 通过 AWSSupport-ExecuteEC2Rescue 以及 EventBridge aws.trustedadvisor 运行 EC2Rescue
离线执行 EC2Rescue 以修复 Windows 网络/RDP 问题并通过 EventBridge 显示 Trusted Advisor 事件。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：离线执行 EC2Rescue 以修复 Windows 网络/RDP 问题并通过 EventBridge 显示 Trusted Advisor 事件。
● 场景匹配：离线执行 EC2Rescue 以修复 Windows 网络/RDP 问题并通过 EventBridge 显示 Trusted Advisor 事件。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 处理硬件或虚拟机管理程序问题，而不是操作系统级别的错误配置（例如 RDP 或防火墙）。
● 依赖实例连接，缺乏针对 Windows 网络问题的有针对性的离线操作系统修复。
● 替换实例而不是修复实例，并且不解决 Trusted Advisor 事件集成问题。
工作流：Systems Manager Automation 通过 AWSSupport-ExecuteEC2Rescue 运行 EC2Rescue，→ EventBridge aws.trustedadvisor。
一个 SSM 服务角色和一个混合激活（限制 400），然后
具有一种服务角色和激活限制的大规模混合激活允许许多服务器通过代码/ID 注册并显示为管理不当的实例。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：具有一种服务角色和激活限制的大规模混合激活允许许多服务器通过代码/ID 注册并显示为管理不当的实例。
● 场景匹配：通过一种服务角色和激活限制进行大规模混合激活，允许许多服务器通过进行注册。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 快速设置无法替代本地的混合激活，并且 EC2 实例配置文件仅适用于 EC2。
● 每个主机的角色和激活是不必要的，本地托管实例使用 mi- 前缀，而不是 i-。
● IAM 用户和长期密钥不用于混合注册；需要激活。
工作流：使用一个 SSM 服务角色和一个混合激活（限制 400），→ 安装 SSM 代理并使用激活代码/ID 注册每个角色 → 它们显示为 mi-。
为“CRITICAL”定义 CloudWatch Logs 指标过滤器，发出自定义指标
指标过滤器将匹配的日志行转换为警报可以通过 SNS 进行监视和通知的指标，且操作工作量较低。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：指标过滤器将匹配的日志行转换为警报可以通过 SNS 进行监视和通知的指标，且操作工作量较低。
● 场景匹配：指标过滤器将匹配的日志行转换为警报可以通过 SNS 进行监视和通知的指标，且操作工作量较少。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 可能，但会增加代码、扩展和维护；这不是基本字符串匹配警报的最简单路径。
● Transit Gateway 流日志是 IP 流记录，不包括第三方防火墙严重性详细信息（例如“CRITICAL”）。
● EventBridge 本身并不检查 CloudWatch Logs 内容；它需要订阅或度量中介。
工作流：为“CRITICAL”定义 CloudWatch Logs 指标过滤器 → 发出自定义指标，并使用 CloudWatch 警报通知 SNS 主题。
ASG 启动生命周期挂钩并仅在准备就绪后完成
在启动期间暂停 Pending:Wait 中的实例，以便仅在通过 CompleteLifecycleAction 发出就绪信号后才进行注册。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：在启动期间暂停 Pending:Wait 中的实例，以便仅在通过 CompleteLifecycleAction 发出就绪信号后才进行注册。
● 场景匹配：在启动期间暂停 Pending:Wait 中的实例，以便仅在通过 CompleteLifecycleAction 发出就绪信号后才进行注册。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 当目标被认为是健康的时进行调整，但不会阻止目标组的初始注册。
● 注册后计量流量；它不会阻止初始注册。
● 控制缩减期间的连接耗尽，而不是横向扩展时的注册。
工作流：添加 ASG 启动生命周期挂钩，并仅在准备就绪后完成。
Trusted Advisor 低利用率检查并创建 Amazon EventBridge 规则
这使用 Trusted Advisor 事件与 EventBridge 和 SSM Automation 来添加人工审批门，同时最大限度地减少自定义代码和编排。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：这使用 Trusted Advisor 事件与 EventBridge 和 SSM Automation 来添加人工审批门，同时最小化。
● 场景匹配：这使用 Trusted Advisor 事件与 EventBridge 和 SSM Automation 来添加人工审批门，同时最小化。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● 需要自定义轮询、状态处理和流处理，与来自 Trusted Advisor 的托管信号相比，这需要付出很大的努力。
● Trusted Advisor 不会向 SNS 发出每次检查通知，因此此集成不是受支持的反应路径。
● 聚合警报无法精确定位特定的空闲实例，并且每个实例的警报管理起来成本高昂且复杂。
工作流：启用 Trusted Advisor 低利用率检查并为该检查的状态更改创建 Amazon EventBridge 规则 → 定位通过手册调用 SSM Automation Runbook 的 Lambda 函数。
将实例的每分钟收费和退款汇总计数发送至
通过警报和 SNS 将单个自定义指标发布到 CloudWatch 可以提供满足要求的简单、自动化且低成本的解决方案。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：通过警报和 SNS 将单个自定义指标发布到 CloudWatch 提供了一种简单、自动化且低成本的方式。
● 场景匹配：通过警报和 SNS 将单个自定义指标发布到 CloudWatch 提供了一种简单、自动化且低成本的方式。
● 工程常识：首选自定义故障点最少的托管路径。
应排除的备选方案
● EventBridge 不会提取或存储 CloudWatch 自定义指标，因此无法直接生成警报指标。
● 可以可视化数据，但与使用本机 CloudWatch 自定义指标和警报相比，操作繁重且成本更高。
● 虽然可行，但与单个 CloudWatch 自定义指标和警报相比，采用 AMP 和 Grafana 会增加复杂性和成本。
工作流：将实例的每分钟收费和退款汇总计数作为自定义指标发送到 Amazon CloudWatch → 使用 Amazon SNS 通知创建 CloudWatch 警报，并使用 AWS 控制台获取图表。
.ebextensions/alb.config 包含一个 option_settings 部分，该部分定义了 aws:elbv2:listener:default 和依赖的规则
Beanstalk 在部署期间应用此声明性配置，确保通过管道一致地管理 ALB 重定向。
决策方法：
● 技术可行性：原生 AWS 服务支持所需的工作流程和集成。
● 需求匹配：Beanstalk 在部署期间应用此声明性配置，确保通过管道一致地管理 ALB 重定向。
● 场景匹配：Beanstalk 在部署期间应用此声明性配置，确保通过管道一致地管理 ALB 重定向。
● 工程常识：首选满足规定的成本、时间安排、安全性和操作约束且故障点很少的托管路径。
应排除的备选方案
● 依赖命令式实例脚本和带外 API 调用，这种方法很脆弱，不推荐用于管理 Beanstalk ALB 侦听器规则。
● 该方法需要直接环境权限并绕过场景明确限制的管道。
● CodePipeline 本身不使用 EB CLI 编排部署，因此不支持此集成。
工作流：添加带有 option_settings 部分的 .ebextensions/alb.config，该部分定义 aws:elbv2:listener:default 的规则，并依赖 CodePipeline 来部署更改。