極點宏觀｜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 具有彈性，並且別名記錄。
決策方法：
● Technical viability: Native AWS services support the required workflow and integrations.
● 需求符合度：Inspector 提供所需的自動化漏洞評估，ALB 加上多可用區自動擴展設計提供高可用性，Aurora。
● 場景符合度：Inspector 提供所需的自動化漏洞評估，ALB 加上多可用區自動擴展設計提供高可用性，Aurora。
● Engineering sense: Prefer the managed path with the fewest custom failure points.
應排除的替代方案
● Macie 專注於敏感資料發現，非別名 A 記錄無法針對 ALB，因此它不會。
● GuardDuty 是威脅偵測而不是應用程式漏洞評估，且 CNAME 不能在區域頂端使用。
工作流程：使用 Amazon Inspector 自動評估應用程式的暴露情況、漏洞以及與 AWS 最佳實務的偏差 → 在應用程式負載後面執行分佈在三個可用區的 EC2 Auto Scaling 群組。
發布新的 Lambda 版本並公開新的 API 網關階段
兩個階段都透過別名呼叫一個 Lambda，而舊階段使用映射模板來新增靜態字段，從而保留單一後端和長期的。
決策方法：
● 技術可行性：原生 AWS 服務支援所需的工作流程和整合。
● 需求符合度：兩個階段都透過別名呼叫一個 Lambda，而舊階段則使用 a 新增靜態欄位。
● 場景符合度：兩個階段都透過別名呼叫一個 Lambda，而舊階段則使用 a 新增靜態欄位。
● 工程常識：首選自訂故障點最少的託管路徑。
應排除的替代方案
● Creates two Lambda functions and introduces proxy logic, increasing maintenance and violating the requirement to manage only one function.
● Caching and stage variables do not reliably mutate request bodies, and removing the legacy path risks breaking older clients.
Workflow: Publish a new Lambda version and expose a new API Gateway stage named prod-v2 that, along with prod-v1, invokes the same Lambda alias → on prod-v1 add a request mapping template that.
允許複製 IAM 角色的目標儲存桶策略的語句
對於跨帳戶 S3 複製，目標儲存桶必須信任來源帳戶的複製角色來寫入和管理物件所有權或 ACL。 S3 使用角色。
決策方法：
● Technical viability: Native AWS services support the required workflow and integrations.
● Requirement fit: For cross-account S3 Replication, the target bucket must trust the source account’s replication role to write and manage.
● Scene fit: For cross-account S3 Replication, the target bucket must trust the source account’s replication role to write and manage.
● Engineering sense: Prefer the managed path with the fewest custom failure points.
應排除的替代方案
● Creates a custom copy pipeline rather than enabling native S3 Replication, so it does not satisfy the requirement for.
● S3 assumes a role in the source account for replication, not in the destination account, so creating the role.
Workflow: Add statements to the destination bucket policy that allow the replication IAM role in the source account to write objects and set object ownership → Create an IAM role in the source.
AWS Service Catalog
Publishes vetted CloudFormation products with constraints and required tags for preventative control at provisioning time.
決策方法：
● Technical viability: Native AWS services support the required workflow and integrations.
● Requirement fit: Publishes vetted CloudFormation products with constraints and required tags for preventative control at provisioning time.
● Scene fit: Publishes vetted CloudFormation products with constraints and required tags for preventative control at provisioning time.
● Engineering sense: Prefer the managed path that satisfies the stated cost, timing, security, and operational constraints with few failure points.
應排除的替代方案
● SCPs and tag policies can restrict or validate tagging but do not provide a curated catalog of vetted architectures.
● Detective compliance after resources are created, not a preventative provisioning control.
● Template policy-as-code useful in pipelines but does not provide a self-service catalog or block ad hoc provisioning.
Workflow: AWS Service Catalog.
awslogs in the task definition; grant CloudWatch Logs permissions to the EC2
This is the simplest supported approach; on EC2 launch type, awslogs uses the container instance IAM role to write to CloudWatch Logs.
決策方法：
● Technical viability: Native AWS services support the required workflow and integrations.
● Requirement fit: This is the simplest supported approach; on EC2 launch type, awslogs uses the container instance IAM role to write to CloudWatch Logs.
● Scene fit: This is the simplest supported approach; on EC2 launch type, awslogs uses the container instance IAM role to write to CloudWatch Logs.
● Engineering sense: Prefer the managed path that satisfies the stated cost, timing, security, and operational constraints with few failure points.
應排除的替代方案
● Works but introduces extra configuration and components, so it is not the most straightforward option.
● On EC2, the awslogs driver does not use the task role; it uses the instance profile credentials.
● Can work but is operationally heavier than using the native awslogs log driver.
Workflow: Use awslogs in the task definition → grant CloudWatch Logs permissions to the EC2 instance profile.
Single repo with develop->main via PRs, CodeBuild on commit, CodeDeploy blue/green with
Blue/green with traffic shifting provides near-zero downtime and very fast rollback by flipping traffic between environments.
決策方法：
● Technical viability: Native AWS services support the required workflow and integrations.
● Requirement fit: Blue/green with traffic shifting provides near-zero downtime and very fast rollback by flipping traffic between environments.
● Scene fit: Blue/green with traffic shifting provides near-zero downtime and very fast rollback by flipping traffic between environments.
● Engineering sense: Prefer the managed path that satisfies the stated cost, timing, security, and operational constraints with few failure points.
應排除的替代方案
● In-place rolling can cause partial interruption and rollback requires redeploying the old version across the fleet, which is slower.
● Multiple repos add coordination overhead without improving rollback speed or availability versus a single-repo approach.
● Rolling updates can reduce capacity and make rollback slower compared to an immediate blue/green traffic switch.
Workflow: Single repo with develop->main via PRs, CodeBuild on commit, CodeDeploy blue/green with traffic shifting.
All at once deployment policy for new versions
All at once updates all instances simultaneously for the fastest deployment, with brief downtime acceptable in staging.
決策方法：
● Technical viability: Native AWS services support the required workflow and integrations.
● Requirement fit: All at once updates all instances simultaneously for the fastest deployment, with brief downtime acceptable in staging.
● Scene fit: All at once updates all instances simultaneously for the fastest deployment, with brief downtime acceptable in staging.
● Engineering sense: Prefer the managed path that satisfies the stated cost, timing, security, and operational constraints with few failure points.
應排除的替代方案
● Rolling updates proceed in batches, which slows the overall deployment and temporarily reduces capacity.
● Blue/green requires running a duplicate environment, increasing cost and adding provisioning time before the swap.
● Immutable spins up new instances for each release, which is safer but slower and incurs extra cost.
Workflow: All at once deployment policy for new versions.
Health endpoint returns 200 only if DB reachable; set ALB health check
Expose an app health URL that tests DB connectivity and returns non-200 when unreachable so the ALB marks the target unhealthy.
決策方法：
● Technical viability: Native AWS services support the required workflow and integrations.
● Requirement fit: Expose an app health URL that tests DB connectivity and returns non-200 when unreachable so the ALB marks the target unhealthy.
● Scene fit: Expose an app health URL that tests DB connectivity and returns non-200 when unreachable so the ALB marks the target unhealthy.
● Engineering sense: Prefer the managed path that satisfies the stated cost, timing, security, and operational constraints with few failure points.
應排除的替代方案
● Operates at DNS level and cannot remove individual ALB targets.
● Checks instance/system health, not application or database reachability.
● ALB health checks evaluate HTTP status codes and timeouts, not response payloads.
Workflow: Health endpoint returns 200 only if DB reachable → set ALB health check to that path.
CloudTrail with an EventBridge rule for DeleteTable to SNS
CloudTrail records the API call and EventBridge matches AWS API Call via CloudTrail events to send immediate notifications to SNS at low cost.
決策方法：
● Technical viability: Native AWS services support the required workflow and integrations.
● Requirement fit: CloudTrail records the API call and EventBridge matches AWS API Call via CloudTrail events to send immediate notifications to SNS at low cost.
● Scene fit: CloudTrail records the API call and EventBridge matches AWS API Call via CloudTrail events to send immediate notifications to SNS at low cost.
● Engineering sense: Prefer the managed path that satisfies the stated cost, timing, security, and operational constraints with few failure points.
應排除的替代方案
● Works but requires delivering CloudTrail to CloudWatch Logs and using metric filters and alarms, adding cost and potential delay.
● Config rules evaluate periodically and are not intended for near real-time API call detection.
● Streams capture item-level changes and do not emit admin API events like DeleteTable.
Workflow: CloudTrail with an EventBridge rule for DeleteTable to SNS.
an Amazon EventBridge scheduled rule to invoke AWS Step Functions, which launches
This orchestrates a single ephemeral instance just for scanning the AMI, minimizing cost and impact while ensuring daily CVE coverage.
決策方法：
● Technical viability: Native AWS services support the required workflow and integrations.
● Requirement fit: This orchestrates a single ephemeral instance just for scanning the AMI, minimizing cost and impact while ensuring daily.
● Scene fit: This orchestrates a single ephemeral instance just for scanning the AMI, minimizing cost and impact while ensuring daily.
● Engineering sense: Prefer the managed path with the fewest custom failure points.
應排除的替代方案
● Amazon Inspector cannot assess an AMI directly by ID and requires an EC2 instance as the target for evaluation.
● Scanning every instance repeatedly is redundant for a single golden AMI, drives up cost, and may cause unnecessary impact.
● Amazon Inspector does not accept an AMI ID as a direct target and cannot scan an image without an.
Workflow: Configure an Amazon EventBridge scheduled rule to invoke AWS Step Functions, which launches a short lived EC2 instance from the hardened AMI, tags it VulnScan: Yes, runs an Amazon Inspector assessment template.
EC2 Auto Scaling SNS notifications for EC2_INSTANCE_LAUNCH_ERROR
Built-in Auto Scaling notifications publish launch failure events directly to SNS for immediate alerts.
決策方法：
● Technical viability: Native AWS services support the required workflow and integrations.
● Requirement fit: Built-in Auto Scaling notifications publish launch failure events directly to SNS for immediate alerts.
● Scene fit: Built-in Auto Scaling notifications publish launch failure events directly to SNS for immediate alerts.
● Engineering sense: Prefer the managed path that satisfies the stated cost, timing, security, and operational constraints with few failure points.
應排除的替代方案
● Status check alarms fire after an instance is running, not when the launch attempt fails.
● Only captures API errors from RunInstances and can miss Auto Scaling launch failures that do not surface as API errors.
● May lag and indicates capacity shortfalls, not specifically failed launch attempts.
Workflow: Enable EC2 Auto Scaling SNS notifications for EC2_INSTANCE_LAUNCH_ERROR.
an EventBridge rule for CodeDeploy state-change events that invokes Lambda to post
EventBridge reacts to exact deployment state changes, Lambda sends Slack messages, and CodeDeploy handles native auto-rollback on failures.
決策方法：
● Technical viability: Native AWS services support the required workflow and integrations.
● Requirement fit: EventBridge reacts to exact deployment state changes, Lambda sends Slack messages, and CodeDeploy handles native auto-rollback on failures.
● Scene fit: EventBridge reacts to exact deployment state changes, Lambda sends Slack messages, and CodeDeploy handles native auto-rollback on failures.
● Engineering sense: Prefer the managed path that satisfies the stated cost, timing, security, and operational constraints with few failure points.
應排除的替代方案
● Notifies Slack but relies on custom rollback logic instead of CodeDeploy’s native automatic rollback.
● Metric alarms are indirect and can lag; they do not directly leverage state-change events and still require proper rollback configuration.
● Pipeline notifications are not specific to CodeDeploy state changes and require manual rollback scripting.
Workflow: Create an EventBridge rule for CodeDeploy state-change events that invokes Lambda to post to Slack, and enable CodeDeploy automatic rollback on failure.
Amazon ElastiCache for Redis (shared session store)
Provides an in-memory, shared session store with microsecond latency and decouples sessions from EC2 lifecycle.
決策方法：
● Technical viability: Native AWS services support the required workflow and integrations.
● Requirement fit: Provides an in-memory, shared session store with microsecond latency and decouples sessions from EC2 lifecycle.
● Scene fit: Provides an in-memory, shared session store with microsecond latency and decouples sessions from EC2 lifecycle.
● Engineering sense: Prefer the managed path that satisfies the stated cost, timing, security, and operational constraints with few failure points.
應排除的替代方案
● In-memory Redis with durability across AZs; typically slightly higher latency than ElastiCache for Redis, not optimal for lowest-latency session reads.
● Binds users to instances but sessions are lost when instances are replaced or scaled in, so persistence still fails.
● Durable and scalable but per-request session lookups have higher latency than in-memory cache solutions.
Workflow: Amazon ElastiCache for Redis (shared session store).
a bucket policy that limits reads to the company's AWS accounts and
A scoped bucket policy plus removing the AuthenticatedUsers canned ACL ensures only approved principals can access objects and eliminates broad access.
決策方法：
● Technical viability: Native AWS services support the required workflow and integrations.
● Requirement fit: A scoped bucket policy plus removing the AuthenticatedUsers canned ACL ensures only approved principals can access objects and eliminates broad access.
● Scene fit: A scoped bucket policy plus removing the AuthenticatedUsers canned ACL ensures only approved principals can access objects and.
● Engineering sense: Prefer the managed path with the fewest custom failure points.
應排除的替代方案
● Encryption at rest does not alter object permissions, so anyone with current read privileges would still be able to access the data.
● Making the objects public would grant worldwide anonymous access and significantly reduce security.
● Adding CloudFront does not negate the S3 ACL, so the objects would remain readable by any AWS account unless the ACL and policy are corrected.
Workflow: Create a bucket policy that limits reads to the company's AWS accounts and remove the authenticated-read ACL from the upload step.
Connect Lambda validation to the AfterAllowTestTraffic lifecycle hook in AppSpec.yaml so tests
AfterAllowTestTraffic is designed to validate the replacement task set using test traffic, enabling safe rollback before any production cutover.
決策方法：
● Technical viability: Native AWS services support the required workflow and integrations.
● Requirement fit: AfterAllowTestTraffic is designed to validate the replacement task set using test traffic, enabling safe rollback before any production cutover.
● Scene fit: AfterAllowTestTraffic is designed to validate the replacement task set using test traffic, enabling safe rollback before any production cutover.
● Engineering sense: Prefer the managed path that satisfies the stated cost, timing, security, and operational constraints with few failure points.
應排除的替代方案
● BeforeAllowTraffic runs after test validation should already be complete, so it is not the correct place to execute initial verification tests.
● AfterAllowTraffic occurs after production traffic is routed to the new task set, which is too late for pre-production validation.
● AfterInstall happens before the test listener sends traffic to the new task set, so validation using test traffic cannot occur here.
Workflow: Connect Lambda validation to the AfterAllowTestTraffic lifecycle hook in AppSpec.yaml so tests run against the test listener and can trigger automatic rollback.
an organization-wide AWS Config rule to evaluate EBS encryption by default and
This centrally deploys and enforces the compliance check across the organization with minimal overhead and protects the control from tampering.
決策方法：
● Technical viability: Native AWS services support the required workflow and integrations.
● Requirement fit: This centrally deploys and enforces the compliance check across the organization with minimal overhead and protects the control from tampering.
● Scene fit: This centrally deploys and enforces the compliance check across the organization with minimal overhead and protects the control from tampering.
● Engineering sense: Prefer the managed path that satisfies the stated cost, timing, security, and operational constraints with few failure points.
應排除的替代方案
● Prevents some new noncompliant launches but does not evaluate existing volumes or provide continuous compliance reporting across accounts.
● Is operationally heavy and requires custom code, scheduling, and per-account deployment and maintenance.
● Can work but is less efficient than organization-level AWS Config rules and still requires additional guardrails to prevent Config from being disabled.
Workflow: Create an organization-wide AWS Config rule to evaluate EBS encryption by default and attach an SCP that prevents disabling or deleting AWS Config in any account.
AWS Elastic Beanstalk with ALB/Auto Scaling, external Amazon RDS MySQL Multi-AZ, logs
Provides managed rolling or immutable deployments with quick rollback, decouples a shared production database, and uses CloudWatch Logs and Logs Insights for centralized, near-real-time search.
決策方法：
● Technical viability: Native AWS services support the required workflow and integrations.
● Requirement fit: Provides managed rolling or immutable deployments with quick rollback, decouples a shared production database, and uses CloudWatch Logs and Logs Insights for centralized, near-real-time search.
● Scene fit: Provides managed rolling or immutable deployments with quick rollback, decouples a shared production database, and uses CloudWatch Logs and Logs Insights for centralized, near-real-time search.
● Engineering sense: Prefer the managed path that satisfies the stated cost, timing, security, and operational constraints with few failure points.
應排除的替代方案
● Viable but higher operational complexity and cost compared to simpler managed app deployment and CloudWatch-based logging.
● Lacks Multi-AZ for the database and requires more custom deployment and rollback orchestration.
● Couples database lifecycle to the application environment, which is risky for shared databases and rollbacks.
Workflow: AWS Elastic Beanstalk with ALB/Auto Scaling, external Amazon RDS MySQL Multi-AZ, logs to CloudWatch Logs with 90-day retention.
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 服務支援所需的工作流程和整合。
● 需求符合度：Network Firewall 可以直接交付到 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 Low Utilization 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 流消耗，並且能夠很好地整合。
● 場景符合度：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。
AWS Step Functions 以及 EventBridge 計畫從每個 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 從以下位置啟動短暫的 EC2
按計劃從 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。
主要區域和災難復原中的 Amazon FSx for NetApp ONTAP
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 主題。
Glue 作業執行事件的 EventBridge 規則呼叫 Lambda 來檢查最終嘗試
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 虛擬機的無代理程式收集和 EC2 的代理，具有內建的 Migration Hub 儀表板和最少的設定。
決策方法：
● 技術可行性：原生 AWS 服務支援所需的工作流程和整合。
● 需求符合度：vCenter VM 的無代理收集和 EC2 的代理，具有內建的 Migration Hub 儀表板和最少的設定。
● 場景符合度：vCenter 虛擬機的無代理程式收集和 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 且終止WaitTimeInMinutes=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 程式碼回溯。
工作流程：具有 CodeDeploy 金絲雀轉移、掛鉤和 CloudWatch 警報回滾的 AWS SAM。
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 檔案系統並使用成本較高的運算。
● Multi-Attach 不是叢集共用檔案系統，跨實例並發使用時有資料損壞的風險。
工作流程：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 漏洞以及網路暴露結果，而不是全面的資源配置合規性或a。
● 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 註冊並顯示為 mi- 受管實例。
決策方法：
● 技術可行性：原生 AWS 服務支援所需的工作流程和整合。
● 需求符合度：具有一種服務角色和啟用限制的大規模混合啟用允許許多伺服器透過程式碼/ID 註冊並顯示為 mi- 受管實例。
● 場景符合度：以單一服務角色與啟用上限進行大規模混合啟用，可讓多台伺服器以啟用碼／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 來部署更改。