極點宏觀｜Financial Cloud Cloud · AWS 考試
AWS Solutions Architect Professional
| 文章 |
|---|
| 01 AWS Solutions Architect Professional SAP-C02 講義 |
| 02 AWS DevOps Certified Professional DOP-C02 講義 |
面向政府技術顧問、公益與教育主管、資料與安全負責人、心理健康服務網路及大型機構決策者的演講內容稿。
刪除堆疊後保留比賽資料
CloudFormation 刪除策略應保留儲存的物件並建立資料庫備份，同時消除持續的資料庫計算成本。
推薦配置
● 將 DeletionPolicy: Retain 應用到 S3 儲存桶。
● 將 DeletionPolicy: Snapshot 應用到 RDS 資源。
● 在刪除堆疊之前驗證策略更改。
設計理由
● 技術可行性：CloudFormation 保持儲存桶和物件完好無損，並在刪除資料庫之前建立最終的 RDS 快照。
● 需求匹配：競賽影象和可恢復的資料庫資料在堆疊終止後仍然存在。
● 場景匹配：應用程式不再處於活動狀態，因此實時資料庫不需要繼續執行。
● 工程常識：在構建重複複製工作流程之前，透過本機生命週期控制保留資料。
應排除的替代方案
● S3 不支援 Snapshot 作為刪除策略。
● 保留 RDS 會保留正在執行的例項及其費用。
● 刪除這兩個資源會破壞所需的資料。
● 跨區域複製可以建立另一個副本，但會新增未請求的儲存和操作。
工作流：更新模板→檢查變更→刪除堆疊→驗證保留桶→驗證RDS快照→單獨管理保留資產。
將 Route 53 DNS 查詢轉發到 Active Directory
VPC 工作負載可以使用 Amazon 提供的 DNS，同時將選定的 Active Directory 名稱轉發到域控制器。
推薦架構
● 建立 Route 53 解析器出站終端節點。
● 建立AD域的轉發規則，如private.aws.com。
● 將兩個域控制器 IP 地址配置為目標。
● 將規則與所需的 VPC 關聯。
設計理由
● 技術可行性：出站終端節點將匹配的查詢從 Route 53 解析程式傳送到 AD DNS 伺服器。
● 需求匹配：EC2 例項集中解析 AD 名稱，無需更改每個主機的 DNS。
● 場景匹配：只有一個私有域需要轉發。
● 工程常識：轉發最窄的名稱空間並提供多個 DNS 目標。
應排除的替代方案
● 每個客戶端的拆分 DNS 設定會造成高度管理和偏差。
● 入站解析器端點接受對 VPC 的查詢；它不會向外轉發 VPC 查詢。
● 另一個 DNS 伺服器上的條件轉發器不是此處所需的 Route 53 解析程式規則。
● 公共託管區域不應公開內部 AD 記錄。
工作流：EC2 查詢 → AmazonProvidedDNS → 轉發規則匹配 → 出站終端節點 → AD DNS 響應。
醫院應用程式的無狀態擴充套件
高度可用的醫院門戶應該擴充套件應用程式容量和資料庫讀取，而不將使用者狀態保留在各個伺服器上。
推薦架構
● 在跨可用區的 Auto Scaling 組中執行無狀態 Web 和應用程式層。
● 使用 Elastic Load Balancing 進行請求分發。
● 將共享會話狀態儲存在 Amazon ElastiCache 中。
● 將 Amazon RDS 與只讀副本結合使用以進行大量讀取的資料庫訪問。
● 使用 CloudWatch 監控容量和執行狀況。
設計理由
● 技術可行性：任何應用程式例項都可以服務請求，因為會話狀態是外部化的。
● 需求匹配：Auto Scaling 增加了容量，而只讀副本則減少了寫入器負載。
● 場景匹配：醫院資訊中心在發展過程中需要持續可用性和可預測的響應。
● 工程常識：可替換計算不得擁有唯一的使用者狀態。
應排除的替代方案
● 有狀態的應用程式伺服器使負載平衡和替換變得不可靠。
● RDS 多可用區提高了資料庫可用性，但不會擴充套件讀取吞吐量。
● 增加一個例項大小會建立更大的故障域。
● 每臺伺服器上的本地快取在替換過程中可能會出現分歧並消失。
工作流：請求→負載均衡器→無狀態例項→共享快取→寫入器或讀取副本。
在 EC2 上執行 Oracle RAC
當 Oracle RAC 必須保持自我管理時，請自動圍繞叢集進行基礎架構備份和作業系統修補。
推薦架構
● 在 Amazon EC2 上部署支援的 Oracle 叢集。
● 使用 Amazon Data Lifecycle Manager 進行計劃的 EBS 快照。
● 使用 Systems Manager Patch Manager 獲取已批准的作業系統補丁。
● 協調補丁波與叢集故障轉移和維護過程。
設計理由
● 技術可行性：DLM 自動化 EBS 快照策略，而補丁管理器則安裝和報告作業系統更新。
● 需求匹配：該設計保留了 RAC，同時減少了重複的備份和修補操作。
● 場景匹配：託管 RDS 不提供所需的 RAC 架構。
● 工程常識：雲自動化並不能消除了解資料庫仲裁和節點順序的需要。
應排除的替代方案
● RDS 多可用區提供託管可用性，但不是 Oracle RAC。
● AWS Backup 本身不會安裝作業系統補丁。
● 手動快照和補丁指令碼會增加錯過的計劃和不一致的節點。
● 用只讀副本替換 RAC 會改變可用性和寫入架構。
工作流：根據DLM策略進行快照→驗證恢復點→排空一個節點→打補丁並測試→繼續遍歷叢集節點。
用於本地和 Fargate 的一個 ECS 控制平面
當本地伺服器參與生產所使用的相同 ECS 操作模型時，混合容器操作最簡單。
推薦架構
● 使用 Amazon ECS Anywhere 將現有本地伺服器註冊為外部 ECS 例項。
● 透過 ECS 控制平面管理開發任務。
● 構建也可以在 AWS Fargate 上執行的任務定義和容器映像。
● 將經過驗證的工作負載從本地開發提升到區域 Fargate 生產。
設計理由
● 技術可行性：ECS Anywhere 將 ECS 排程和 API 擴充套件到客戶管理的伺服器。
● 需求匹配：團隊可以獲得一致的工具和簡單的工作負載遷移路徑，同時重複使用現有的資本裝置。
● 場景匹配：生產環境已使用 ECS Fargate，因此 ECS 是通用編排器。
● 工程常識：避免僅僅為了託管開發容器而引入 Kubernetes 或專用硬體。
應排除的替代方案
● EKS Anywhere 更改了編排平臺，並且不建立一個 ECS 叢集。
● AWS Outposts 需要額外的硬體投資，與節省成本的目標相沖突。
● Outposts 上的 ECS 不按請求的直接方式使用現有伺服器。
工作流：註冊外部例項→部署開發任務→測試映象和任務定義→釋出修訂版→在Fargate上執行。
在有限頻寬上批次 Redshift 遷移
60 TB 的初始傳輸無法滿足 50 Mbps 分配的 30 天期限，因此批次資料和持續更改應使用不同的路徑。
推薦架構
● 使用 AWS SCT 評估 Oracle 倉庫並準備與 Redshift 相容的提取和架構。
● 透過 AWS Snowball Edge 匯入作業匯出批次資料集。
● 將裝置匯入 Amazon S3。
● 將暫存資料載入到 Amazon Redshift 中。
● 使用 AWS DMS 複製持續的日常更改直至切換。
設計理由
● 技術可行性：Snowball 將初始資料集離線； DMS 透過網路承載小得多的變更流。
● 需求匹配：該方法可以在不消耗業務頻寬或購買永久高容量鏈路的情況下滿足截止日期。
● 場景匹配：日常變化很小，而初始倉庫卻非常大。
● 工程常識：將批次播種與增量同步分開。
應排除的替代方案
● 透過 RDS Oracle 暫存 60 TB 會增加成本，並且無法解決初始傳輸限制。
● 沒有可靠的持續複製的 Snowball 工作流程可能會丟失每日更新。
● 配置 Direct Connect 和自我管理的 Oracle RAC 成本高昂、速度緩慢，而且超出了遷移需求。
工作流：轉換→批次匯出→發貨→S3載入→DMS更改→協調→切換。
用於第三方白名單的穩定出站 IP
應用程式伺服器可以透過 NAT 閘道器共享一個可預測的出站公共地址。
推薦架構
● 在公有子網中建立 NAT 閘道器。
● 關聯彈性IP。
● 透過 NAT 閘道器路由專用應用程式子網。
● 將彈性 IP 提供給支付提供商以列入白名單。
設計理由
● 技術可行性：出站連線將轉換為 NAT 閘道器的彈性 IP。
● 需求匹配：提供商看到穩定的源地址，而伺服器保持私有。
● 場景匹配：該整合啟動從應用程式伺服器到第三方的連線。
● 工程常識：使用託管出口，而不是為每臺伺服器分配公共地址。
應排除的替代方案
● NAT 例項可以提供固定地址，但需要修補和故障轉移管理。
● ELB 處理入站流量，並不集中伺服器出口。
● Internet 閘道器不提供一個客戶控制的共享源 IP。
● 客戶閘道器是 VPN 端點，而不是正確的網際網路出口服務。
工作流：私有伺服器 → NAT 閘道器 → 彈性 IP 轉換 → 支付端點 → 白名單接受連線。
使用 CloudFront 和 ALB 的端到端 HTTPS
CloudFront 和 ALB 源需要受信任的證書和策略來在兩個連線上強制執行 HTTPS。
推薦架構
● 在 ACM 中為 ALB 匯入或請求受信任的證書。
● 將 CloudFront 檢視器協議策略配置為僅 HTTPS。
● 使用 CloudFront 自定義域支援的 ACM 或 IAM 證書。
● 將源協議設定為 HTTPS。
設計理由
● 技術可行性：CloudFront 驗證受信任的原始證書並提供受信任的檢視者證書。
● 需求匹配：傳輸鏈中的任何地方都不接受 HTTP。
● 場景匹配：零售應用程式在 ALB 之前使用 CloudFront。
● 工程常識：證書名稱必須與檢視者主機名和源主機名匹配。
應排除的替代方案
● CloudFront 不信任自簽名源證書。
● 無法從 S3 匯入檢視者證書。
● 當檢視器使用 HTTP 時，匹配檢視器允許 HTTP。
● 僅在 CloudFront 處終止 TLS 會使源連線不受保護。
工作流：HTTPS 檢視器 → CloudFront 證書 → HTTPS 源請求 → ALB 證書 → 應用程式。
服務多個 TLS 域
不同的客戶端功能和不相關的域需要與每個端點匹配的證書傳遞方法。
推薦架構
● 當舊客戶端不支援 SNI 時，請使用 CloudFront 專用 IP SSL。
● 為現代客戶端使用具有多個證書和 SNI 的應用程式負載均衡器 HTTPS 偵聽器。
設計理由
● 技術可行性：專用IP支援非SNI檢視器； ALB 從請求的主機名中選擇正確的證書。
● 需求匹配：單獨的證書可以保護共享託管端點上的不相關域。
● 場景匹配：一些使用者擁有舊版 TLS 客戶端，而應用程式域仍然不同。
● 工程常識：僅在客戶端相容性需要時才支付專用 IP 交付費用。
應排除的替代方案
● 一份 SAN 證書可以涵蓋已知名稱，但不能直接保留單獨的證書管理。
● Classic Load Balancer 不支援在一個偵聽器上使用多個 SNI 證書。
● 萬用字元證書涵蓋一個父域的子域，而不是不相關的域。
● 在每個後端安裝證書會增加輪換和暴露工作。
工作流：檢視器連線 → 端點確定 SNI 功能 → 專用 IP CloudFront 或 ALB 偵聽器提供匹配的證書。
使用流響應 DynamoDB 更改
當應用程式行為必須遵循每個新的 DynamoDB 專案時，請使用表的本機更改流。
推薦架構
● 使用所需的影象檢視啟用 DynamoDB Streams。
● 將 AWS Lambda 配置為事件源使用者。
● 以冪等方式處理新條目記錄。
● 監視迭代器壽命、錯誤、重試和死信處理。
設計理由
● 技術可行性：DynamoDB Streams 記錄專案更改，Lambda 透過託管事件源對映輪詢流。
● 需求匹配：每個表插入都可以觸發下游處理，操作工作量較低。
● 場景匹配：感興趣的事件是資料庫突變，而不是 ECS 應用程式日誌。
● 工程常識：在權威資料來源捕獲變化。
應排除的替代方案
● SNS 要求應用程式單獨釋出，並且可能會錯過其他生產者的寫入。
● Systems Manager 自動化適用於基礎設施操作，而不是變更資料捕獲。
● 遷移到 DocumentDB 無需更改資料庫。
● 計劃的表掃描會引入延遲和重複讀取。
工作流：DynamoDB 寫入 → 流記錄 → Lambda 批處理 → 冪等操作 → 檢查點和重試管理。
保護 RDS 免受閃購寫入的影響
突然的銷售可能會壓垮關聯式資料庫，除非對提交的內容進行持久緩衝並以受控的速率耗盡。
推薦架構
● 將銷售提交放入 Amazon SQS。
● 從佇列中呼叫 Lambda 消費者。
● 將併發限制在 RDS 可以維持的速率。
● 使用重試、冪等性和死信佇列。
設計理由
● 技術可行性：SQS 吸收突發，Lambda 非同步處理訊息。
● 需求匹配：保留客戶提交的內容，同時資料庫負載保持受控。
● 場景匹配：該事件是暫時的，並不能證明資料庫重新設計是合理的。
● 工程常識：持久佇列保護寫入；快取則不然。
應排除的替代方案
● 垂直擴充套件需要有計劃的更改，並且仍然將流量直接耦合到 RDS。
● Memcached 可能會逐出或丟失條目，並且不是持久的寫入佇列。
● 將 PostgreSQL 遷移到 DynamoDB 是一項重大範圍變更。
● 同步重試會放大過載。
工作流：客戶提交→訊息進入SQS→Lambda在併發限制內消費→事務寫入RDS→確認成功。
溫備容災
熱備份可保持生產環境的功能性但規模縮小的副本，為快速擴充套件做好準備。
推薦架構
● 在恢復區域保持減少的應用程式群。
● 保持同步的備用資料庫和當前應用程式工件。
● 持續監控複製和恢復執行狀況。
● 在災難期間，擴充套件備用環境並重定向流量。
設計理由
● 技術可行性：執行環境可以避免在事件發生期間構建每個元件。
● 需求匹配：熱備用平衡了恢復速度和持續成本。
● 場景匹配：業務需要比備份和恢復更快的恢復速度，但無法證明完整的雙活容量是合理的。
● 工程常識：恢復時間包括資料庫升級、容量擴充套件、依賴性驗證和 DNS 移動。
應排除的替代方案
● 完全重複的生產能力可以提供更快的恢復，但成本更高。
● 指示燈僅使核心元件保持執行，並且可能需要更長的時間來擴充套件和驗證。
● 備份和恢復的穩定成本最低，但恢復時間最長。
● 多可用區本身可以防止可用區故障，但不能防止區域災難。
工作流：持續複製→檢測災難→升級資料庫→擴充套件應用程式→驗證依賴關係→重定向流量→監控。
使用 S3 Sync 滿足週末遷移截止日期
提前一週允許大多數資料在最後一個週末之前移動，只留下更改的檔案進行切換。
推薦做法
● 在遷移前一週執行初始 S3 同步。
● 繼續正常的源操作。
● 在週五執行最終的增量同步。
● 驗證計數和校驗和。
● 將 EC2 應用程式指向已完成的 S3 資料集。
設計理由
● 技術可行性：S3 同步僅傳輸最後一次丟失或更改的物件。
● 需求匹配：1 TB 遷移獲得了進度裕度，可以在週日完成。
● 場景匹配：可以在源保持線上的情況下複製資料集。
● 工程常識：儘早播種並預留增量和驗證的中斷視窗。
應排除的替代方案
● 在週末複製完整的資料集幾乎沒有餘地。
● 閘道器快照工作流程為此檔案移動新增了不必要的步驟。
● 從週六開始，就有可能錯過最後期限。
● Snowball 訂購、運輸、匯入和恢復無法在一個週末內可靠地完成。
工作流：初始同步→源更改→最終增量同步→驗證→應用程式切換。
SSE-S3 如何保護物件
使用 S3 託管金鑰的 Amazon S3 伺服器端加密使用單獨的資料金鑰對每個物件進行加密。
加密模型
● S3 為每個物件生成唯一的資料金鑰。
● 該物件使用該資料金鑰進行加密。
● 資料金鑰在 S3 管理的根金鑰或主金鑰下進行加密。
● S3 定期輪換主金鑰材料並管理整個金鑰生命週期。
● 對於授權請求，解密是透明發生的。
設計理由
● 技術可行性：信封加密限制每個物件資料金鑰的範圍，同時集中保護這些金鑰。
● 需求匹配：資料靜態加密，無需客戶儲存或輪換加密金鑰。
● 場景匹配：要求是託管 S3 加密，而不是客戶控制的金鑰策略或審計分離。
● 工程常識：加密不會取代 IAM、儲存桶策略、版本控制或傳輸安全性。
應排除的錯誤假設
● 一個明文金鑰不會直接為每個物件重用。
● 客戶不下載 S3 主金鑰。
● SSE-S3與SSE-KMS不同，SSE-S3客戶可以控制KMS許可權並稽核金鑰使用。
● 伺服器端加密不會自動將公共儲存桶設為私有。
工作流：授權 PUT → S3 建立資料金鑰 → 加密物件 → 包裝金鑰 → 儲存密文 → 在授權 GET 上解密。
公共 S3 物件的實時警報
當使用公共讀取訪問許可權上傳物件時，合規性可以立即收到通知。
推薦架構
● 為 PutObject 啟用 CloudTrail S3 資料事件。
● 建立與公共讀取 ACL 請求匹配的 EventBridge 規則。
● 將匹配事件釋出到 SNS 主題。
設計理由
● 技術可行性：CloudTrail記錄物件級API引數，EventBridge過濾事件，SNS推送警報。
● 需求匹配：檢測是事件驅動的，而不是透過輪詢延遲的。
● 場景匹配：該風險發生在物件上傳過程中。
● 工程常識：針對與策略違規最接近的權威 API 事件發出警報。
應排除的替代方案
● 每小時輪詢會延遲響應。
● Systems Manager 自動化對於直接通知來說是不必要的。
● Lex 是對話式人工智慧。
● GuardDuty 和 Trusted Advisor 不會透過建議的工作流程識別此 ACL 事件。
● CDK 部署基礎設施，而不是執行時檢測器。
工作流：公開讀取 PUT → CloudTrail 資料事件 → EventBridge 匹配 → SNS 合規警報。
移動應用程式的臨時每使用者 S3 訪問
移動應用程式應該對使用者進行身份驗證並頒發短期的、限定範圍的 AWS 角色憑證以進行直接 S3 訪問。
推薦架構
● 透過應用程式的身份系統對使用者進行身份驗證。
● 將每個身份對映到 IAM 角色或範圍會話。
● 使用 AWS STS 頒發臨時憑證。
● 按使用者上下文限制 S3 字首和操作。
設計理由
● 技術可行性：移動 SDK 可以使用臨時 STS 憑證來簽署 S3 請求。
● 需求匹配：每個使用者只能訪問經過批准的物件，而無需共享一個永久金鑰。
● 場景匹配：分散式客戶端需要大規模的直接物件訪問。
● 工程常識：不受信任裝置上的憑證必須是短暫的且範圍狹窄。
應排除的替代方案
● 嵌入 IAM 使用者金鑰會向每個安裝公開相同的長期秘密。
● STS 不會頒發永久憑證，並且快取的會話會過期。
● 靜態手機鑰匙難以旋轉，無法安全隔離使用者。
● 公共儲存桶訪問刪除了使用者級別的授權。
工作流：使用者登入 → 身份驗證 → STS 角色會話 → 限定範圍的 S3 請求 → 憑證自動過期。
使用 S3 和 CloudFront 擴充套件每日分析報告
應從資料庫生成經常讀取的報告，然後將其用作持久的靜態工件，而不是重複查詢資料庫。
推薦架構
● 維護多可用區 Amazon RDS for MySQL 中的源資料。
● 在適當的情況下，將只讀副本用於報告生成工作負載。
● 在預定的批處理過程中生成報告。
● 將完成的報告儲存在 Amazon S3 中。
● 使用每日 TTL 透過 CloudFront 快取和分發它們。
設計理由
● 技術可行性：S3 持久儲存報告檔案，而 CloudFront 吸收數百萬個全域性讀取請求。
● 需求匹配：每日重新整理使快取過期與報告生成保持一致，並降低資料庫成本。
● 場景匹配：統計報告的閱讀次數遠多於其更改次數。
● 工程常識：計算一次，儲存一次，分發多次。
應排除的替代方案
● 每天重建和刪除 DynamoDB 表會增加不必要的操作。
● ElastiCache 不是持久的報告儲存。
● 直接從 RDS 提供數千萬個報表查詢的可擴充套件性較差且成本較高。
● 只讀副本可保護寫入者免受報告生成的影響，但不應成為公共報告交付層。
工作流：更新源資料 → 生成報告 → 寫入 S3 → 使快取失效或過期 → 透過 CloudFront 提供服務。
CloudFront HTTPS 和快取效率
自定義 CloudFront 域需要可信證書和快取指令，以將可重用物件保留在邊緣位置。
推薦架構
● 在 us-east-1 中為 CloudFront 主機名請求 ACM 證書。
● 將其附加到發行版中。
● 為安全的可快取物件設定一個長實用的 Cache-Control: max-age 。
設計理由
● 技術可行性：CloudFront 使用來自 us-east-1 的 ACM 證書；原始快取標頭影響邊緣保留。
● 需求匹配：託管 TLS 可保護自定義域，而較長的 TTL 可提高快取命中率並減少源流量。
● 場景匹配：內容可以被快取並且不需要每個請求處理。
● 工程常識：僅快取新鮮度和隱私允許重複使用的內容。
應排除的替代方案
● 在 S3 中儲存證書不會將其附加到 CloudFront 並建立私鑰處理。
● OpenSearch 不是 CDN 快取。
● Lambda@Edge 增加了成本和延遲，但沒有解決基本的證書和 TTL 要求。
● 非常短的 TTL 會強制產生不必要的源請求。
工作流：檢視器 HTTPS → CloudFront 驗證證書 → 邊緣檢查新鮮度 → 提供快取物件或請求源。
保留失敗的 Auto Scaling 例項以供診斷
自動修復可以消除診斷失敗部署所需的確切證據。
推薦流程
● 暫時暫停 Auto Scaling 組的 Terminate 程序。
● 允許不健康的例項保持可用。
● 透過 AWS Systems Manager 會話管理器進行連線。
● 檢查程序狀態、偵聽埠、依賴項、配置和本地日誌。
● 更正啟動模板、AMI 或應用程式包，然後恢復終止。
設計理由
● 技術可行性：暫停該程序會阻止 Auto Scaling 刪除不正常的例項，同時 Session Manager 會提供私有管理訪問許可權。
● 需求匹配：這是到達原始故障環境的最快途徑。
● 場景匹配：這些例項已具有 SSM 代理，並且不需要 SSH 公開。
● 工程常識：短暫暫停修復，收集證據，修復不可變的源頭，然後恢復正常癒合。
應排除的替代方案
● 單獨建立的測試例項可能無法重現確切的故障並增加設定時間。
● 更詳細的日誌記錄無法保留足夠長的例項以供檢查。
● EC2 終止保護不會阻止 Auto Scaling 終止其管理的例項。
工作流：暫停→檢查→重現→糾正→啟動替換→驗證執行狀況→恢復。
適用於 Python 和 TypeScript 團隊的 AWS CDK
AWS CDK 允許團隊使用熟悉的語言定義基礎設施，同時標準化 CloudFormation 上的部署。
推薦架構
● 使用 Python 和 TypeScript 構建 CDK 應用程式。
● 合成 CloudFormation 模板。
● 在 CodeBuild 中執行驗證和綜合。
● 透過 CodePipeline 協調推廣。
設計理由
● 技術可行性：CDK 支援這兩種語言並生成本機 CloudFormation 部署。
● 需求匹配：團隊在共享一個基礎設施工作流程的同時保留了他們的編碼技能。
● 場景匹配：現有的部署邏輯分為 Python 和 TypeScript。
● 工程常識：標準化部署引擎，而不強迫每個團隊使用一種程式語言。
應排除的替代方案
● 將指令碼手動重寫到模板中會增加不必要的轉換。
● EC2 使用者資料不是基礎設施配置引擎。
● OpsWorks 和 Chef 引入了不同的配置模型。
● 當 CDK 已經適合兩種語言時，第三方工具會新增依賴項。
工作流：編寫CDK→測試→綜合→檢查模板→透過管道部署。
透過 VPN 故障轉移直接連線
注重成本的混合設計可以使用一個專用主電路和一個網際網路 VPN 進行備份。
推薦架構
● 使用 Direct Connect 作為首選路徑。
● 建立託管站點到站點 VPN 作為冗餘連線。
● 配置路由首選項，使 Direct Connect 成為主要的。
● 測試退出和故障轉移行為。
設計理由
● 技術可行性：當 Direct Connect 路由消失時，動態路由會選擇 VPN。
● 需求匹配：主路徑是可預測的，而備份成本仍然低於第二專用電路。
● 場景匹配：該公司接受故障期間較低的備份效能。
● 工程常識：備份不得依賴於同一個發生故障的物理電路。
應排除的替代方案
● 一個 Direct Connect 會留下物理單點故障。
● VPN CloudHub 加入 VPN 站點，不提供專用的主路徑。
● 同一 Direct Connect 上承載的 VPN 在該電路上仍然失敗。
● 靜態路由可能會減慢自動故障轉移速度或使其複雜化。
工作流：正常流量使用專線 → 電路路由撤銷 → VPN 路由選擇 → 服務繼續。
使用 SQS 進行長時間執行的批處理
長時間的資料處理作業需要持久的佇列、彈性的工作執行緒和持久的輸出儲存。
推薦架構
● 將工作專案放入 Amazon SQS 中。
● 根據佇列長度擴充套件 EC2 工作執行緒。
● 將處理後的檔案儲存在 Amazon S3 中。
● 配置可見性超時、重試和死信佇列。
設計理由
● 技術可行性：SQS 將生產者解耦，Auto Scaling 跟蹤積壓工作，S3 將輸出儲存在工作人員之外。
● 需求匹配：該設計能夠經濟高效地處理可變的長作業。
● 場景匹配：處理可能會超出 Lambda 持續時間或資源限制。
● 工程常識：切勿依賴手動伺服器關閉來實現彈性。
應排除的替代方案
● Amazon MQ 和 EFS 可以工作，但會新增代理和檔案系統操作。
● 將 MQ 佇列與讀取 SQS 的 Lambda 使用者混合在一起是不一致的。
● Lambda 可能會超出執行時限制。
● 對於已完成的物件輸出，EFS 的操作不如 S3 簡單。
工作流：提交作業 → SQS → 工作佇列規模 → 處理 → 寫入 S3 結果 → 刪除訊息。
將應用程式日誌轉化為即時警報
操作警報需要集中日誌、可測量的錯誤訊號、閾值和通知操作。
推薦架構
● 在本地伺服器上安裝 CloudWatch 代理。
● 將應用程式日誌傳送到 CloudWatch Logs。
● 為相關錯誤模式建立指標過濾器。
● 針對生成的指標建立 CloudWatch 警報。
● 透過配置的警報動作通知運營團隊。
設計理由
● 技術可行性：指標過濾器將匹配的日誌條目轉換為警報可以評估的數字 CloudWatch 指標。
● 需求匹配：該設計會聚合日誌、自動分析並在超出閾值後立即發出警報。
● 場景匹配：該公司需要從應用程式錯誤中獲得可操作的見解，而不是一般的商業情報報告。
● 工程常識：對定義的服務症狀發出警報並保留底層日誌以供診斷。
應排除的替代方案
● Kinesis 代理和 QuickSight 新增了流媒體和視覺化元件，但沒有簡化警報。
● CloudWatch Events 不是日誌儲存目標。
● Athena 基於查詢，不會持續監視指標過濾器。
● Prometheus 的託管服務未作為通用日誌代理安裝，並且 Lambda 轉換新增了不必要的自定義程式碼。
工作流：日誌事件 → CloudWatch Logs → 指標過濾器 → 警報閾值 → 操作通知 → 調查。
一個 EC2 原型上的多個網路身份
單個原型例項可以透過單獨的 IP 身份公開元件，而無需跨越可用區。
推薦架構
● 將多個彈性網路介面附加到 EC2 例項。
● 為 ENI 分配不同的私有 IP 地址。
● 在需要公共靜態身份的地方關聯彈性 IP 地址。
● 將合適的安全組應用於每個介面。
設計理由
● 技術可行性：多個 ENI 提供單獨的網路身份，而例項保留在一個可用區中。
● 需求匹配：每個元件都可以繫結到一臺原型主機上自己的地址。
● 場景匹配：該設計是原型，因此可能不需要單獨的例項。
● 工程常識：獨立的IP標識並不等於故障隔離；生產可能仍然需要獨立主機。
應排除的替代方案
● 安全組會過濾流量，但不會建立額外的 IP 身份。
● NAT 提供地址轉換，而不是多個入站元件身份。
● 一個 ENI 無法連線到兩個可用區中的子網。
● EC2 例項不能跨可用區。
工作流：建立 ENI → 分配地址和安全組 → 附加到例項 → 繫結每個元件 → 測試路由。
OpsWorks 的藍/綠交付
單獨的 OpsWorks 堆疊提供隔離的藍色和綠色環境，用於驗證和快速回滾。
推薦架構
● 克隆當前 OpsWorks 堆疊。
● 將新的 Chef 和應用程式修訂版部署到綠色堆疊。
● 獨立驗證。
● 使用現有路由層轉移流量。
● 保留藍色以供回滾。
設計理由
● 技術可行性：獨立堆疊可防止更改服務例項。
● 需求匹配：該設計支援受控切換和快速恢復。
● 場景匹配：該應用程式已使用 OpsWorks 和 Chef。
● 工程常識：部署工具應與正在執行的平臺相匹配。
應排除的替代方案
● Elastic Beanstalk 滾動部署改變了平臺並修改了服務容量。
● CodePipeline 編排各個階段，但本身並不提供建議的 EC2 滾動策略。
● CodeBuild 構建和測試工件；不是引流部署服務。
● 就地 Chef 更新削弱了回滾。
工作流：克隆藍色 → 部署綠色 → 測試 → 轉移流量 → 監控 → 如果需要，返回藍色。
低成本照片處理和存檔
照片處理是非同步、並行的，並且可以容忍工作人員中斷，因此適合排隊的 Spot 容量。
推薦架構
● 將照片處理作業放置在 Amazon SQS 中。
● 根據佇列深度擴充套件 EC2 Spot 工作執行緒。
● 將活動輸入儲存在適當的線上物件類中。
● 當不再需要立即訪問時，將完成的照片存檔到 S3 Glacier。
設計理由
● 技術可行性：SQS 保留作業並允許其他工作人員在中斷後重試。
● 需求匹配：Spot 降低了計算成本，而 Glacier 則降低了長期歸檔成本。
● 場景匹配：工人們爭奪獨立攝影工作。
● 工程常識：將持久的輸入和輸出保留在一次性工人之外。
應排除的替代方案
● 將未處理的照片移至 Standard-IA 會在立即處理之前產生檢索費用。
● SNS 不提供持久的競爭消費者積壓或佇列深度擴充套件訊號。
● 手動終止工作執行緒比 Auto Scaling 弱。
● 對於很少檢索的長期成品檔案，Standard-IA 的經濟性不如 Glacier。
工作流：上傳→SQS作業→Spotworker→結果儲存→歸檔轉換→worker縮小規模。
可重複的高可用性問題跟蹤
生產問題跟蹤器需要可重複的基礎設施、彈性應用程式容量、持久的內容交付和託管資料庫故障轉移。
推薦架構
● 在 AWS CloudFormation 中定義環境。
● 跨可用區在 Auto Scaling 組中執行應用程式例項。
● 在例項之前放置彈性負載均衡器。
● 使用 CloudFront 獲取可快取內容。
● 在 RDS 多可用區上執行 OLTP 資料庫。
設計理由
● 技術可行性：CloudFormation 重現堆疊，Auto Scaling 取代不健康的計算，RDS 多可用區提供託管備用故障轉移。
● 需求匹配：該服務可擴充套件並保持可用，只需很少的手動恢復工作。
● 場景匹配：問題跟蹤是事務性的，需要關係型 OLTP 資料庫。
● 工程常識：保持應用程式例項無狀態並將持久狀態儲存在託管服務中。
應排除的替代方案
● 單個 EC2 例項或資料庫會建立故障點。
● 僅讀取副本不提供寫入器故障轉移。
● 在例項磁碟上託管持久上傳會使替換變得複雜。
● 手動基礎設施部署會導致配置漂移和恢復緩慢。
工作流：路由請求 → CloudFront 或負載均衡器 → Auto Scaling 例項 → RDS 主例項；故障時提升備用。
測試 CI/CD 中的 CloudFormation 更改
基礎設施更改應在 CloudFormation 執行之前進行測試和預覽。
推薦架構
● 從 GitHub 更改觸發 CodePipeline。
● 使用 CodeBuild 進行測試和模板驗證。
● 建立 CloudFormation 更改集。
● 使用 CloudFormation 操作檢視或自動執行批准的更改集。
設計理由
● 技術可行性：CodePipeline 協調源、構建和 CloudFormation 部署階段。
● 需求匹配：更改是可重複的，並且其資源影響在執行前可見。
● 場景匹配：源包含 CloudFormation 模板。
● 工程常識：擁有資源更改的服務應該執行它。
應排除的替代方案
● 正常模板部署不需要 Lambda 和 CodeArtifact。
● CodeArtifact 是一個包儲存庫，而不是自然的模板執行服務。
● CodeDeploy 部署應用程式修訂版，無法執行 CloudFormation 更改集。
● 不經過測試直接更新會削弱安全性。
工作流：GitHub 提交 → CodePipeline → CodeBuild 測試 → 更改集 → 批准 → CloudFormation 執行。
兩個基本的 EC2 IAM 角色策略
EC2 角色需要許可權策略和信任策略。
所需策略
● 附加授予所需 S3 物件操作的許可權策略。
● 配置角色信任策略，以便 EC2 服務主體可以代入該角色。
● 透過例項配置檔案附加角色。
設計理由
● 技術可行性：信任策略確定誰可以擔任該角色，許可權策略定義會話可以執行哪些操作。
● 需求匹配：Node.js 應用程式接收臨時 S3 訪問許可權。
● 場景匹配：EC2 是工作負載身份。
● 工程常識：信任和許可權回答不同的授權問題。
應排除的替代方案
● 可能還需要儲存桶策略，但它不會取代角色自己的許可權和信任鏈。
● 該應用程式不是 IAM 服務主體。
● EC2 承擔其例項角色；它並不首先承擔單獨的 S3 角色。
● 靜態 IAM 使用者金鑰是不必要的。
工作流：EC2 承擔角色 → 後設資料提供臨時憑證 → 角色許可權授權 S3 請求。
加速小檔案的雪球傳輸
數百萬個小檔案可能無法充分利用 Snowball 頻寬，因為每個檔案的加密和後設資料工作成為瓶頸。
推薦做法
● 對 Snowball Edge 裝置執行多個並行複製會話。
● 在工作人員之間分發源目錄。
● 保持每個worker的檔案列表獨立以避免重複寫入。
● 監控總吞吐量和裝置利用率。
● 驗證傳輸的檔案計數和校驗和。
設計理由
● 技術可行性：並行客戶端重疊每個檔案的處理並增加總吞吐量。
● 需求匹配：遷移可以更快地完成，無需更改資料集或購買其他傳輸方法。
● 場景匹配：問題是許多小檔案，而不是原始裝置容量不足。
● 工程常識：僅在源磁碟、網路、CPU 或裝置限制達到飽和之前增加併發性。
應排除的替代方案
● 將所有內容壓縮到一個存檔中會改變處理方式，並且可能需要額外的臨時空間和處理。
● 更快的 WAN 並不能改善裝置的本地複製瓶頸。
● 按順序複製檔案可以避免每個檔案的開銷問題。
● 無需重新格式化裝置，並且存在重新啟動工作的風險。
工作流：分割槽檔案列表→啟動並行複製工作→監視吞吐量→重試失敗→協調檔案計數→返回裝置。
從 EC2 安全訪問 DynamoDB
EC2 應用程式應透過例項配置檔案而不是嵌入式訪問金鑰來獲取臨時 DynamoDB 許可權。
推薦架構
● 建立受 EC2 服務信任的 IAM 角色。
● 為所需的 DynamoDB 表操作附加最低許可權策略。
● 將角色放置在例項配置檔案中。
● 使用該配置檔案啟動或更新應用程式例項。
● 讓 AWS 開發工具包自動檢索臨時憑證。
設計理由
● 技術可行性：EC2 透過例項後設資料服務向授權本地軟體公開輪換角色憑證。
● 需求匹配：應用程式訪問 DynamoDB 時無需在程式碼或配置中儲存靜態金鑰。
● 場景匹配：三層應用程式從其計算層執行 AWS API 呼叫。
● 工程常識：將許可權繫結到工作負載身份並將其範圍限制到確切的表和操作。
應排除的替代方案
● 硬編碼的 API 金鑰可能會洩漏並且需要手動輪換。
● IAM 使用者不能像角色一樣附加到 EC2 例項。
● 在此設計中，DynamoDB 資源策略並不是工作負載角色憑證的正常替代。
● 授予管理員訪問許可權違反了最低許可權。
工作流：EC2 使用配置檔案啟動 → SDK 獲取臨時憑證 → 簽署 DynamoDB 請求 → IAM 評估角色策略 → 憑證自動輪換。
透過備份和事務日誌進行經濟有效的恢復
恢復目標應確定備份頻率、事務日誌頻率和儲存層。
推薦架構
● 建立定期資料庫備份並將其儲存在 Amazon S3 中。
● 每五分鐘將事務日誌匯出到單獨的 S3 位置。
● 恢復期間恢復最新的備份和重播日誌。
● 使用 Amazon Macie 發現 S3 中儲存的敏感資料並對其進行分類。
設計理由
● 技術可行性：基礎備份加上頻繁的日誌可以重建靠近故障點的資料庫。
● 需求匹配：五分鐘的日誌適合 15 分鐘的 RPO，而 S3 檢索比歸檔儲存更適合支援三小時以內的恢復目標。
● 場景匹配：該應用程式使用 RDS MySQL 幷包含交付、交易和潛在的敏感資料。
● 工程常識：RPO控制資料採集頻率； RTO 控制檢索和恢復備份的速度。
應排除的替代方案
● AWS 託管的資料庫備份路徑不需要 Storage Gateway。
● 多可用區是高可用性，而不是單獨的災難恢復備份。
● AWS Shield 不會發現 PII。
● 冰川恢復可能會使短期恢復目標變得困難。
工作流：備份→捕獲日誌→安全儲存→檢測敏感物件→恢復基礎→重放日誌→驗證服務。
SCP 允許列表必須允許所有操作
根據 SCP 允許列表策略，必須在每個適用的組織級別允許某個操作，然後 IAM 許可權才能使用該操作。
關鍵行為
● SCP 定義成員帳戶主體的最大許可權。
● IAM 策略僅在該最大值內授予許可權。
● S3 儲存桶建立必須出現在從根到 OU 和帳戶的適用允許列表 SCP 中。
設計理由
● 技術可行性：有效許可權是 SCP 邊界和 IAM 授權的交集。
● 需求匹配：新增缺少的 S3 允許可以解決拒絕問題，而無需更改不相關的許可權。
● 場景匹配：IAM 身份已具有 S3 許可權，但 SCP 對其進行限制。
● 工程常識：解決從外護欄向內授權的問題。
應排除的替代方案
● IAM 允許無法覆蓋丟失的 SCP 允許。
● SCP 支援允許列表和拒絕列表策略。
● IAM 和 SCP 文件不必相同。
● 新增更多 IAM 策略無法擴充套件到 SCP 邊界之外。
工作流：請求 → 根 SCP → OU SCP → 賬戶 SCP → IAM 策略 → 資源策略和條件。
跨環境推廣作業系統補丁
關鍵補丁應在生產前經過開發和測試，並使用單獨的基線來保留每個環境的策略。
推薦架構
● 按環境和作業系統標記每個例項。
● 為開發、測試和生產建立單獨的 Systems Manager Patch Manager 基線。
● 使用這些標籤將例項對映到補丁組。
● 立即進行補丁開發和測試。
● 僅在驗證後才生產補丁。
設計理由
● 技術可行性：補丁組將標記的例項與批准的補丁基準相關聯。
● 需求匹配：特定於環境的控制可防止未經驗證的補丁進入生產。
● 場景匹配：每個環境都有不同的基線要求。
● 工程常識：在獲得穩定性證據後，應在日益關鍵的環境中推廣相同的工件。
應排除的替代方案
● 僅作業系統標籤無法區分生產和非生產佇列。
● 維護視窗控制時間，但不定義每個環境批准哪些補丁。
● 自定義 shell 指令碼和 Run Command 重複託管修補功能，並且需要持續維護。
工作流：標記→定義基線→補丁開發→驗證→補丁測試→驗證→批准生產基線→補丁生產→審查合規性。
在 CloudFront 快取查詢之前規範化查詢字串
當引數順序或字母大小寫不改變響應時，等效查詢字串應對映到一個快取鍵。
推薦架構
● 根據檢視者請求使用 Lambda@Edge。
● 規範批准的引數名稱、值、順序和大小寫。
● 將規範查詢字串轉發到 CloudFront 快取查詢。
● 保留合法更改內容的引數。
設計理由
● 技術可行性：檢視器請求邊緣程式碼在快取鍵評估之前執行，並且可以重寫請求。
● 需求匹配：更多語義相同的請求成為快取命中。
● 場景匹配：客戶端以不一致的形式傳送等效的查詢字串。
● 工程常識：規範化規則必須與應用程式語義相匹配。
應排除的替代方案
● 忽略所有查詢引數可能會提供不正確的內容。
● CloudFront 沒有簡單的通用的不區分大小寫的標準化開關。
● 源端標準化發生在快取未命中之後，因此不能有效地改進初始快取查詢。
● 轉發每個非標準化變體都會使快取碎片化。
工作流：檢視器請求 → Lambda@Edge 規範化 → CloudFront 計算快取金鑰 → 命中或原始獲取。
停止與 CloudFront 的 S3 熱連結
私有 S3 源訪問和過期的 CloudFront 簽名 URL 會阻止直接物件訪問並限制連結重用。
推薦架構
● 從 S3 儲存桶中刪除公共訪問許可權。
● 僅允許 CloudFront 源身份或源訪問控制。
● 要求籤名 URL 具有較短且適當的過期時間。
● 僅向授權使用者分發連結。
設計理由
● 技術可行性：使用者無法繞過 CloudFront，並且過期的簽名將停止以後的重用。
● 需求匹配：減少未經授權的盜鏈和直接 S3 下載。
● 場景匹配：內容透過 CloudFront 交付。
● 工程常識：檢視者授權和來源保護必須同時存在。
應排除的替代方案
● S3 沒有安全組。
● 阻止網站 IP 很脆弱，並且會影響合法使用者。
● Web 伺服器上的 EBS 會降低耐用性併產生瓶頸。
● 靜態 IP 拒絕列表無法可靠地識別每個盜鏈站點。
工作流：授權應用程式發出簽名 URL → 檢視器請求 CloudFront → 檢查簽名 → 讀取私有 S3 源 → URL 過期。
使用 CloudFront 立即解除安裝
與完整的應用程式和資料庫遷移相比，較短的準備視窗更有利於邊緣快取。
推薦架構
● 將 CloudFront 放置在本地網站之前。
● 快取靜態且安全可重用的內容。
● 調整促銷期間的 TTL。
● 在現有來源保留動態遊戲商店交易。
設計理由
● 技術可行性：CloudFront 可以使用本地站點作為源並吸收重複的全域性請求。
● 需求匹配：該解決方案以最少的應用程式更改快速減少源流量。
● 場景匹配：出售迫在眉睫，動態交易必須繼續進行。
● 工程常識：解決眼前的瓶頸，而不是開始冒險的全面遷移。
應排除的替代方案
● S3 靜態故障轉移無法保留動態事務。
● 混合 ALB 設計需要專用連線和重複的伺服器。
● 完整的虛擬機器和 Oracle 遷移對於時間線來說太大了。
● 銷售期間的資料庫轉換會帶來可避免的風險。
工作流：使用者 → CloudFront → 可快取內容的邊緣命中 → 僅在未命中或動態請求時進行本地源。
透過 Snowball 和 VPN Catch-Up 進行批次資料庫遷移
超過 50 Mbps 的 25 TB 初始資料庫傳輸需要離線批次移動，然後透過網路複製更改。
推薦架構
● 將初始資料庫資料集匯出到 Snowball。
● 將批次資料傳送並匯入到 AWS 中。
● 使用基於 VPN 的複製來處理運輸過程中生成的更改。
● 同步後切換到 Aurora。
設計理由
● 技術可行性：Snowball 處理大型種子，而較小的變更流則適合 VPN。
● 需求匹配：該設計減少了網路使用量和應用程式停機時間。
● 場景匹配：源在遷移過程中持續增長。
● 工程常識：將大量播種與正在進行的三角洲分開。
應排除的替代方案
● 透過 50 Mbps 傳送整個 25 TB 的時間太長。
● VM Import/Export 移動機器映像，而不是高效的實時資料庫工作流程。
● 在 Snowball 運輸週期中停止應用程式會導致過多的停機時間。
● 沒有追趕的批次匯入會丟失更改。
工作流：匯出種子 → 滾雪球運輸 → 載入目標 → 複製 VPN 增量 → 驗證 → 切換。
HPC 網路和並行儲存
緊密耦合的模擬需要低延遲的節點通訊、緊密的物理佈局和高吞吐量的共享檔案系統。
推薦架構
● 在支援的 EC2 例項上使用 Elastic Fabric Adapter。
● 將計算節點放置在一個可用區內的叢集置放群組中。
● 使用 Amazon FSx for Lustre 並行訪問數千個大型模擬檔案。
設計理由
● 技術可行性：EFA 支援 HPC 通訊，叢集佈局可最大限度地減少網路延遲，FSx for Lustre 提供並行檔案系統吞吐量。
● 需求匹配：組合設計加速了節點間通訊和共享資料訪問。
● 場景匹配：工作負載是緊密耦合的，而不是獨立的批處理。
● 工程常識：最佳化整個工作流程；快速計算網路無法彌補序列儲存。
應排除的替代方案
● RAID 0 EBS 是例項本地的，不是共享並行檔案系統。
● 跨可用區分佈節點會增加延遲。
● 多個 ENI 不會像 EFA 那樣聚合頻寬。
● 每個例項的磁碟使共享模擬資料和恢復變得複雜。
工作流：排程程式將節點放置在一起 → EFA 承載節點間流量 → FSx for Lustre 提供共享檔案 → 結果保留。
將 Web 健康狀況與資料庫健康狀況分開
Web 層健康檢查應該測試 Web 程序，而不會導致資料庫過載而觸發例項更換風暴。
推薦架構
● 將 ALB 目標健康檢查更改為簡單的靜態 HTTP 頁面。
● 新增 Amazon ElastiCache 以應對頻繁重複的資料庫查詢。
● 透過 Route 53 執行狀況檢查單獨監控依賴於資料庫的應用程式端點。
● 當端到端檢查失敗時提醒管理員。
設計理由
● 技術可行性：靜態執行狀況檢查驗證 Web 伺服器，而 ElastiCache 則減少重複的 RDS 讀取。
● 需求匹配：Auto Scaling 停止替換執行狀況良好的 Web 例項，資料庫可以處理更多流量。
● 場景匹配：RDS CPU 飽和而不是 Web 伺服器故障導致了超時。
● 工程常識：用於更換的執行狀況檢查應隔離被更換的元件。
應排除的替代方案
● 重新啟動過載的資料庫並不能解決持續的需求。
● 如所述，建議的 RDS MySQL 單讀取器端點無效。
● TCP 檢查僅證明埠接受連線，並且比簡單的 HTTP 頁面弱。
工作流：ALB 檢查靜態頁面 → Route 53 檢查完整事務 → 快取吸收讀取 → 警報報告資料庫路徑故障。
將 TLS 金鑰儲存在 CloudHSM 中
敏感的 TLS 私鑰應保留在硬體安全模組內，同時應用程式日誌保持永續性和訪問控制。
推薦架構
● 使用 TCP 負載平衡，以便 TLS 到達應用程式和 HSM 整合，而無需負載平衡器終止。
● 使用 AWS CloudHSM 進行私鑰操作。
● 部署 HSM 容量以實現可用性。
● 將加密日誌儲存在私有 S3 儲存桶中。
● 透過 IAM 和金鑰策略限制日誌解密。
設計理由
● 技術可行性：CloudHSM 執行加密操作而不匯出私鑰材料，並且 S3 提供持久的加密日誌記錄。
● 需求匹配：管理員不能隨意複製 TLS 金鑰，而授權使用者可以訪問日誌。
● 場景匹配：混合應用程式具有嚴格的金鑰保管和審計要求。
● 工程常識：金鑰儲存、TLS 執行和日誌儲存是獨立的安全問題。
應排除的替代方案
● 將金鑰上傳到網路伺服器使其可移動。
● 例項儲存日誌不持久。
● 單個 HSM 會產生可用性風險。
● 標準負載均衡器 TLS 解除安裝不滿足客戶控制的 HSM 託管要求。
工作流：客戶端 TLS → TCP 負載均衡器 → HSM 支援的操作 → 應用程式 → 加密的 S3 日誌 → 授權稽核訪問。
帶彈性豆莖的藍色/綠色版本
託管藍/綠版本保持當前環境可用，同時獨立驗證新版本。
推薦架構
● 克隆或建立第二個 Elastic Beanstalk 環境。
● 在那裡部署並測試新的應用程式版本。
● 驗證成功時交換環境 CNAME。
● 暫時保留舊環境以進行回滾。
設計理由
● 技術可行性：兩個環境同時執行，CNAME 交換會重定向使用者而無需重建 URL。
● 需求匹配：部署沒有計劃停機，回滾速度很快。
● 場景匹配：該應用程式已使用 Elastic Beanstalk。
● 工程常識：在流量移動之前驗證確切的生產工件。
應排除的替代方案
● 強制 Auto Scaling 替換缺乏乾淨的分階段環境和即時 URL 交換。
● Lightsail 和加權 DNS 引入了不相關的基礎設施。
● 立即替換所有例項會刪除受控驗證。
● 就地更新會增加回滾風險。
工作流：構建綠色 → 部署版本 → 測試 → 交換 CNAME → 監控 → 如果需要則交換回來 → 退出藍色。
啟用版本控制後瞭解 S3 版本 ID
在啟用 S3 版本控制之前建立的物件的行為與之後建立的版本不同。
關鍵行為
● 在版本控制之前存在的物件具有 null 版本 ID。
● 在版本控制後更新該物件會建立一個帶有生成的版本 ID 的新版本。
● 除非刪除，否則原始 null 版本仍然可用。
● 版本控制後從未更新的物件仍然只有原始 null 版本。
設計理由
● 技術可行性：S3 使用相同的金鑰維護早期的物件版本。
● 需求匹配：版本歷史記錄解釋了哪些配置檔案具有一個或兩個可檢索版本。
● 場景匹配：有些檔案在版本控制後進行了更新，而另一些則沒有。
● 工程常識：版本 ID 是不透明的識別符號，而不是按時間順序排列的序列號。
應排除的錯誤假設
● 啟用版本控制不會將生成的 ID 追溯分配給現有物件。
● 版本 ID 不可預測或連續。
● 更新舊物件不會替換其原始 null 版本；它新增了一個新版本。
● 未更改的預版本控制物件不會自動獲得第二個版本。
工作流：預版本控制物件→啟用版本控制→更新金鑰→保留空版本加上新生成的版本。
透過 PowerUserAccess 進行開發人員訪問
應用程式開發人員通常需要廣泛的服務建立許可權，但無法管理 IAM 或組織。
推薦控制
● 當 AWS 託管 PowerUserAccess 策略的範圍與開發角色匹配時，分配該策略。
● 為公司特定的護欄新增更窄的拒絕或許可權邊界。
● 與平臺或安全團隊一起進行 IAM 和組織管理。
設計理由
● 技術可行性：PowerUserAccess 允許使用大多數 AWS 服務，同時保留廣泛的身份管理。
● 需求匹配：開發人員無需完全帳戶控制即可構建和配置應用程式。
● 場景匹配：團隊需要開發自主權，而不是運營或安全管理。
● 工程常識：管理政策是起點；在生產使用之前檢查其當前許可權。
應排除的替代方案
● AdministratorAccess 不受限制且許可權過高。
● 將 AdministratorAccess 包裝在角色中不會減少其許可權。
● SystemAdministrator 面向運營管理，與應用程式開發不太一致。
● 授予臨時 IAM 許可權可以允許升級。
工作流：開發人員承擔角色 → 建立應用程式資源 → IAM 管理仍被拒絕 → CloudTrail 記錄操作。
監控 AWS Organizations 的更改
組織成員資格和政策變更需要權威的 API 歷史記錄和持續的合規性評估。
推薦架構
● 建立記錄 AWS Organizations 控制檯和 API 活動的 CloudTrail 跟蹤。
● 使用 EventBridge 規則來匹配敏感事件，例如帳戶邀請或策略更改。
● 透過 Amazon SNS 釋出警報。
● 在適用的情況下，使用 AWS Config 進行組織相關的合規性監控。
設計理由
● 技術可行性：CloudTrail 記錄誰執行了組織操作； EventBridge 對匹配事件做出反應； Config 評估配置合規性。
● 需求匹配：管理員及時收到通知並保留證據以供調查。
● 場景匹配：在未經批准的情況下新增了外部帳戶，因此身份、時間和 API 操作至關重要。
● 工程常識：儀表板不是審計源；首先收集事件，然後視覺化或發出警報。
應排除的替代方案
● Systems Manager 不提供權威的組織 API 歷史記錄。
● Inspector 評估工作負載漏洞，而不是帳戶成員身份更改。
● Control Tower 增加了治理，但不會取代 CloudTrail 證據。
● 除非已存在適當的事件源和規則，否則 CloudWatch 控制面板無法檢測更改。
工作流：組織操作 → CloudTrail 記錄 → EventBridge 匹配 → SNS 通知 → 配置評估 → 調查和修復。
CloudFront 的私有 S3 起源
CloudFront 應透過源身份讀取私有 S3 物件，同時直接公共 S3 訪問仍處於禁用狀態。
推薦架構
● 建立 CloudFront 源訪問身份。
● 配置 S3 源以使用它。
● 在儲存桶策略中授予OAI讀取許可權。
● 刪除公共 ACL 和其他直接訪問許可權。
設計理由
● 技術可行性：CloudFront 使用 OAI 簽署源請求，並且 S3 授權該身份。
● 需求匹配：使用者透過 CloudFront 接收物件，但無法繞過分發。
● 場景匹配：S3 是私有 CloudFront 源。
● 工程常識：檢視者授權和來源授權是單獨的控制。
應排除的替代方案
● 欄位級加密保護選定的請求欄位，而不是保護 S3 源訪問。
● TLS 證書不授權物件檢索。
● 簽名 URL 可以限制檢視者，但源保護仍然需要刪除直接 S3 許可權。
● 公共讀取訪問擊敗了私有源設計。
工作流：檢視器 → CloudFront → OAI 簽名請求 → S3 儲存桶策略 → 物件響應。
實時點選流處理
Web 點選流事件需要持續攝取和分析，而不是定期批次收集。
推薦架構
● 將點選事件釋出到 Amazon Kinesis Data Streams。
● 使用均勻分配流量的金鑰對記錄進行分割槽。
● 與流消費者近乎實時地處理事件。
● 將原始或聚合結果儲存到持久的分析儲存中。
設計理由
● 技術可行性：Kinesis 接受每個分片的有序記錄並支援多個低延遲消費者。
● 需求匹配：該平臺可以在會話處於活動狀態時評估使用者行為。
● 場景匹配：網站點選形成了具有突發量的連續事件流。
● 工程常識：保持攝取持久並與下游分析速度脫鉤。
應排除的替代方案
● Nightly S3 批處理作業不滿足實時要求。
● SQS 對於工作佇列很有用，但不提供相同的有序流和多消費者模型。
● 直接寫入倉庫和網站以獲取分析可用性。
● CloudTrail 記錄 AWS 賬戶活動，而不是應用程式點選流事件。
工作流：瀏覽器事件 → Kinesis 分割槽 → 流處理器 → 實時指標或操作 → 持久存檔和後續分析。
防止意外的公共 S3 訪問
S3 阻止公共訪問是對公共 ACL 和策略的直接預防性控制。
推薦架構
● 在所需的組織、賬戶、儲存桶或訪問點範圍內啟用阻止公共訪問。
● 保持儲存桶策略最小特權。
● 使用 AWS Config 或 Security Hub 進行額外的檢測和報告。
設計理由
● 技術可行性：S3 拒絕會建立阻塞公共訪問路徑的配置和請求。
● 需求匹配：使用者不會意外暴露受保護的儲存桶。
● 場景匹配：風險包括 ACL、儲存桶策略和訪問點。
● 工程常識：在構建自定義評估邏輯之前使用服務本機預防控制。
應排除的替代方案
● 私有固定 ACL 不涵蓋公共儲存桶策略或訪問點。
● AWS Config 在更改後檢測到不合規情況。
● SCP 可以拒絕 API，但無法完整評估每個生成的公共配置。
● 人工稽核緩慢且不一致。
工作流：使用者嘗試公共設定 → S3 阻止公共訪問評估 → 更改或請求被拒絕 → 監控記錄事件。
跨區域加密 Redshift 快照副本
KMS 加密的 Redshift 叢集需要目標金鑰授權，然後本機跨區域快照副本才能對其進行保護。
推薦架構
● 在目標區域中為目標 KMS 金鑰建立快照副本授權。
● 啟用 Redshift 跨區域快照複製。
● 設定適合恢復目標的保留。
● 測試在恢復區域中恢復快照。
設計理由
● 技術可行性：複製授權允許 Redshift 使用目標金鑰來加密複製的快照。
● 需求匹配：恢復快照不會丟失源區域。
● 場景匹配：倉庫採用KMS加密。
● 工程常識：在測試恢復許可權和時間之前，備份的存在是不夠的。
應排除的替代方案
● 自定義 Lambda 複製邏輯複製本機功能，並且可能會省略金鑰授權。
● 對於加密工作流程，在沒有 KMS 授權的情況下啟用複製會失敗。
● S3 跨區域複製不是 Redshift 快照複製機制。
● CloudFormation 無法從 S3 中的任意複製快照檔案恢復 Redshift。
工作流：Redshift快照→目標副本授予→加密的跨區域副本→保留→恢復恢復測試。
解除安裝 RDS 批次讀取併傳送完成警報
批處理報告應從副本中讀取並在處理完成時直接通知訂閱者。
推薦架構
● 新增 RDS 只讀副本。
● 將批次分析查詢定向到副本。
● 在多可用區主資料庫上保留 OLTP 寫入。
● 將完成結果釋出到 Amazon SNS 供本地儀表板訂閱者使用。
設計理由
● 技術可行性：只讀副本減少主讀負載，SNS 向訂閱者推送通知。
● 需求匹配：CRM 在批次工作期間保持響應，並且儀表板會及時收到完成通知。
● 場景匹配：工作負載是針對運算元據庫的大量讀取分析。
● 工程常識：高可用性和讀取擴充套件是不同的資料庫功能。
應排除的替代方案
● 對於這種狹隘的需求，Redshift 不應取代 CRM OLTP 資料庫。
● Redshift Spectrum 分析 S3 資料，而不是規定的 RDS 批次峰值。
● SQS 要求消費者進行輪詢，對於廣播通知來說不太直接。
● 在寫入器上執行分析可以保留瓶頸。
工作流：批次開始→查詢副本→報告完成→SNS釋出→儀表板收到通知。
私有 MySQL 複製到本地
本地只讀副本可以透過私有 VPN 上的本機外部複製來遵循 RDS MySQL。
推薦架構
● 建立專用 VPN 連線。
● 使用 mysqldump 為本地 MySQL 目標設定種子。
● 將 RDS 配置為外部複製源。
● 啟動本機 MySQL 複製並監控延遲。
設計理由
● 技術可行性：RDS 支援在受支援的配置下複製到外部 MySQL 相容目標。
● 需求匹配：本地資料庫保持最新狀態以供讀取。
● 場景匹配：需要連續複製，而不是每晚批次匯出。
● 工程常識：首先播種，然後從已知位置應用變更流。
應排除的替代方案
● EC2 中繼新增了不必要的複製躍點。
● 每晚資料管道匯出不是當前的只讀副本。
● 透過開放網際網路進行復制會增加曝光率。
● 重複完全匯出會浪費頻寬並延長延遲。
工作流：VPN → 初始轉儲 → 捕獲複製座標 → 啟動外部副本 → 監控和修復延遲。
緩衝 DynamoDB 寫入突發
當 DynamoDB 在突發期間進行限制時，持久佇列會保護請求，直到消費者可以以可接受的速率寫入。
推薦架構
● 將寫入請求放入 Amazon SQS。
● 使用受控消費者處理訊息。
● 使用批次寫入、重試、冪等性和死信處理。
● 當持續需求證明合理時擴充套件 DynamoDB 容量。
設計理由
● 技術可行性：SQS 在限制或擴充套件延遲期間保留訊息。
● 需求匹配：意外突發不會導致資料丟失。
● 場景匹配：寫入峰值是可變的，而不是永久的資料模型變化。
● 工程常識：容量和緩衝解決不同的問題並且可以相輔相成。
應排除的替代方案
● 單獨使用更多 WCU 並不能在突然爆發期間持久保護請求。
● 全域性表提供區域複製，而不是本地寫入緩衝。
● 附加表對資料模型和重試邏輯進行分段。
● 客戶端立即重試可能會加劇限制。
工作流：生產者 → SQS → 消費者批次 → DynamoDB → 重試受限制的專案 → DLQ 持續失敗。
虛擬機器線上遷移與離線遷移相結合
受限的遷移視窗可能需要對關鍵系統進行連續複製，並對非常大的資料集進行離線傳輸。
推薦架構
● 將 AWS Application Migration Service 用於需要同步和短停機時間切換的關鍵虛擬機器。
● 使用 AWS Snowball 處理無法及時透過可用網路移動的批次資料。
● 對於不需要連續複製的受支援的映像匯入情況，請使用 VM 匯入/匯出。
● 透過一個遷移計劃協調測試和最終切換。
設計理由
● 技術可行性：MGN 複製伺服器磁碟，Snowball 離線傳輸批次位元組，VM Import/Export 根據支援的格式建立 AWS 映像。
● 需求匹配：每個工作負載都使用與其大小和停機容忍度相匹配的遷移路徑。
● 場景匹配：該資產包含關鍵虛擬機器和大量資料。
● 工程常識：不要強制每個工作負載都透過一種傳輸方法。
應排除的替代方案
● 對於一次性遷移來說，配置新的 Direct Connect 可能會很慢且成本高昂。
● 重構每個應用程式都超出了遷移時間表。
● 頻寬有限的 SFTP 不適合非常大的資料集。
● 重複的完整影象匯入無法提供高效的持續同步。
工作流：對工作負載進行分類 → 複製關鍵虛擬機器 → 傳送批次資料 → 匯入剩餘映像 → 測試 → 切換。
透過 Route 53 故障轉移進行區域災難恢復
區域恢復設計需要獨立的應用程式堆疊和基於健康的流量控制。
推薦架構
● 在主要區域中部署 ALB 和 Auto Scaling 組。
● 在次要區域中維護恢復 ALB 和 Auto Scaling 組。
● 根據RPO複製或恢復所需資料。
● 配置 Route 53 故障轉移記錄和執行狀況檢查。
● 定期測試故障轉移和故障回覆。
設計理由
● 技術可行性：每個區域都可以獨立地提供流量，並且當主要終端節點執行狀況不佳時，Route 53 會更改 DNS 答案。
● 需求匹配：主要區域完全中斷後，應用程式仍然可用。
● 場景匹配：生產在一個區域執行，而另一區域需要災難恢復。
● 工程常識：僅當恢復中也存在資料、機密、證書和依賴項時，應用程式故障轉移才會成功。
應排除的替代方案
● 多可用區僅保護一個區域內部。
● 沒有輔助計算的一個全域性負載均衡器無法恢復工作負載。
● 手動 DNS 更改會增加 RTO。
● 沒有可部署應用程式環境的備份會延遲恢復。
工作流：執行狀況檢查失敗 → Route 53 返回輔助端點 → 恢復佇列規模 → 資料提升或恢復 → 使用者重新連線。
RDS 多可用區故障轉移和 DNS
應用程式應連線到 RDS 端點而不是資料庫例項 IP 地址。
故障轉移行為
● RDS 在另一個可用區中維護同步備用。
● 當主資料庫發生故障時，RDS 會提升備用資料庫。
● 資料庫端點的 CNAME 解析為新的主地址。
● DNS 和連線恢復後應用程式重新連線。
設計理由
● 技術可行性：RDS 控制託管部署的升級和 DNS 重新對映。
● 需求匹配：應用程式無需手動更改連線字串即可恢復。
● 場景匹配：該設計使用多可用區來實現資料庫可用性。
● 工程常識：連線池必須丟棄斷開的連線並再次解析端點。
應排除的錯誤假設
● 應用程式不應固定舊資料庫 IP。
● 多可用區備用例項不是正常的讀取擴充套件端點。
● Route 53 記錄不需要手動更改操作員即可進行標準 RDS 故障轉移。
● 恢復快照不是正常的多可用區故障轉移過程。
工作流：主要故障 → RDS 檢測到 → 備用提升 → 端點 DNS 更改 → 應用程式重試並重新連線。
防篡改多區域 API 稽核日誌記錄
合規性日誌記錄需要跨區域和全球服務的完整 API 歷史記錄，以及受保護的長期儲存。
推薦架構
● 建立 AWS CloudTrail 多區域跟蹤。
● 包括全域性服務事件，例如 IAM 活動。
● 將日誌傳送到專用的 Amazon S3 儲存桶。
● 使用 AWS KMS 加密日誌檔案。
● 使用最低許可權策略限制儲存桶和金鑰訪問。
● 在操作適當的情況下啟用版本控制和 MFA 刪除。
設計理由
● 技術可行性：CloudTrail 跨受支援的服務記錄控制檯、SDK、CLI 和 API 活動。
● 需求匹配：多區域覆蓋和全球事件提供所需的審計歷史記錄； S3 和 KMS 保護永續性和機密性。
● 場景匹配：EC2、S3、CloudFront 和 IAM 活動跨越區域和全球服務邊界。
● 工程常識：將審計證據與工作負載賬戶分開集中，並防止輕易刪除或更改。
應排除的替代方案
● 排除全域性服務事件會忽略所需的 IAM 活動。
● CloudWatch 不提供權威帳戶 API 歷史記錄的“跟蹤”資源。
● 單區域配置無法覆蓋所有應用程式區域中的活動。
工作流：API 呼叫 → CloudTrail 事件 → 加密的 S3 物件 → 受控稽核訪問 → 保留和完整性監控。
實時物聯網分析管道
寵物項圈遙測需要當前事件的流路徑和用於原始或聚合分析的單獨的持久儲存。
推薦架構
● 透過 Amazon Kinesis 攝取裝置事件。
● 近乎實時地處理或聚合記錄。
● 將持久輸出和聚合儲存在 Amazon S3 中。
● 將精選的分析資料載入到 Amazon Redshift 中以進行更深入的查詢。
設計理由
● 技術可行性：Kinesis 接受連續事件流，S3 提供持久物件儲存，Redshift 支援分析 SQL。
● 需求匹配：該管道支援大規模的及時監控和歷史分析。
● 場景匹配：物聯網裝置發出持續的遙測資料，而不是偶爾的交易記錄。
● 工程常識：將流攝取與倉庫查詢分開，這樣分析工作負載就不會阻止事件攝取。
應排除的替代方案
● 將每個裝置直接傳送到關係倉庫將攝取可用性與倉庫容量結合起來。
● 僅批次傳輸會延遲操作洞察力。
● 單獨使用 S3 儲存記錄，但不提供實時流處理。
● 將佇列視為完整的分析平臺仍然需要消費者、持久的分析儲存和查詢服務。
工作流：裝置事件 → Kinesis 流 → 實時處理 → S3 存檔和聚合 → Redshift 載入 → 分析。
緩衝最終一致的本地寫入
最終一致的 BASE 資料庫可以透過持久佇列非同步接收雲發起的寫入。
推薦架構
● 將寫入請求放入 Amazon SQS 中。
● 執行連線到本地資料庫的使用者。
● 對訊息進行冪等處理，持久化成功後才將其刪除。
● 配置重試和死信佇列。
設計理由
● 技術可行性：當資料庫或網路速度緩慢或不可用時，SQS 會持久緩衝訊息。
● 需求匹配：生產者保持響應並且資料庫非同步收斂。
● 場景匹配：不需要嚴格的立即一致性。
● 工程常識：僅在業務關鍵需要時保留排序；優先考慮永續性和冪等性。
應排除的替代方案
● EventBridge 本身不會複製任意資料庫寫入。
● Elastic Transcoder 與資料庫無關。
● S3DistCp 複製 S3 和 HDFS 資料，而不是應用程式事務。
● DynamoDB 加上 EMR 批處理作業會增加不必要的儲存和延遲。
工作流：應用程式提交寫入→SQS保留→消費者在本地寫入→確認成功→失敗的訊息重試或進入DLQ。
將靜態路徑路由到 S3 CloudFront 源
CloudFront 分配可以使用單獨的源來處理動態應用程式請求和靜態資產。
推薦架構
● 新增 S3 儲存桶作為第二個 CloudFront 源。
● 為靜態路徑模式建立快取行為。
● 將該行為路由到 S3。
● 將 ALB 保留為動態路徑的預設來源。
設計理由
● 技術可行性：CloudFront 快取行為從 URL 路徑模式中選擇源。
● 需求匹配：靜態資產停止返回應用程式源 404 錯誤並獲得邊緣快取。
● 場景匹配：一個域同時提供動態和靜態內容。
● 工程常識：在知道兩個源的 CDN 層執行源選擇。
應排除的替代方案
● Global Accelerator 不會透過 HTTP 路徑快取內容或路由。
● ALB 無法使用 S3 儲存桶作為目標。
● 標頭條件不會使 S3 成為 ALB 目標。
● 在應用程式例項上覆制靜態檔案會破壞 S3 源。
工作流：檢視器請求→CloudFront路徑匹配→靜態資產的S3源或動態內容的ALB。
本地站點的快速全域性解除安裝
CloudFront 可以使用現有的本地網站作為自定義源，並快速減少全球流量。
推薦架構
● 將本地站點配置為 CloudFront 自定義源。
● 快取靜態和安全可重用的動態 HTTP 響應。
● 調整快取行為和 TTL。
● 將不可快取的應用程式流量保留在源頭。
設計理由
● 技術可行性：CloudFront 從可透過 Internet 訪問的自定義源檢索內容並在全球範圍內提供快取的響應。
● 需求匹配：該解決方案在短時間內提高了規模，無需完全遷移。
● 場景匹配：當前應用程式必須保留在本地。
● 工程常識：首先解除安裝占主導地位的重複流量。
應排除的替代方案
● 顛倒靜態和動態服務角色會導致設計不可行。
● Transit Gateway 不提供公共 CDN 交付。
● App Runner 無法管理本地伺服器。
● 複製完整的基礎設施並轉移一半的流量速度更慢，成本也更高。
工作流：檢視器 → CloudFront → 邊緣命中或自定義源請求 → 本地應用程式。
稽核員對 AWS 活動的只讀訪問許可權
外部審計員需要可驗證的帳戶活動和受控的讀取訪問許可權，而不是管理許可權。
推薦架構
● 為所需的區域和服務啟用 AWS CloudTrail。
● 將跟蹤日誌儲存在受保護的 Amazon S3 儲存桶中。
● 建立專用 IAM 身份，對所需日誌和資源具有隻讀訪問許可權。
● 透過組織批准的安全流程提供憑據。
設計理由
● 技術可行性：CloudTrail 記錄控制檯、CLI、SDK 和 API 活動； IAM 控制稽核員可以檢查的內容。
● 需求匹配：稽核員收到的證據沒有修改權。
● 場景匹配：任務是賬戶審計，而不是運營管理。
● 工程常識：將審計身份與員工賬戶分開，並僅授予所需的證據。
應排除的替代方案
● AWS 不會獨立向外部審計員提供對客戶賬戶的訪問許可權。
● 透過電子郵件傳送日誌會造成重複、訪問控制薄弱以及可搜尋性差。
● SNS 通知報告事件，但不提供完整的歷史審計證據。
● 廣泛的角色或管理員許可權超出了稽核員的需要。
工作流：帳戶操作 → CloudTrail 日誌 → 受保護的 S3 儲存 → 只讀稽核員訪問 → 審查和證據收集。
從批准的 EC2 例項進行私有 S3 訪問
安全的 S3 訪問需要網路路徑限制和工作負載授權。
推薦架構
● 建立 S3 閘道器 VPC 終端節點。
● 將端點策略限制為所需的儲存桶。
● 將最低許可權的 IAM 角色附加到批准的 EC2 例項。
● 需要 S3 儲存桶策略中的端點和批准的主體。
設計理由
● 技術可行性：端點使 S3 流量保持私有，IAM 授予積極授權，並且儲存桶策略強制執行預期路徑。
● 需求匹配：只有Web Portal例項才能透過批准的VPC路由使用該儲存桶。
● 場景匹配：該應用程式在專用網路中的 EC2 上執行。
● 工程常識：網路位置不能替代工作負載身份。
應排除的替代方案
● NACL 無法識別單個 EC2 工作負載以進行 S3 授權。
● 儲存桶策略無法安全地將私有子網視為主體。
● 當端點路由改變觀察到的路徑時，SourceIp 是不可靠的。
● 每例項路由不授予 IAM 許可權。
工作流：EC2 角色簽署請求 → 閘道器端點策略 → 儲存桶策略路徑和主體檢查 → S3 操作。
擴容現有VPC CIDR
VPC 可以透過關聯輔助 IPv4 CIDR 塊來獲得地址空間。
推薦流程
● 選擇 VPC 規則允許的非重疊輔助 CIDR。
● 將其與現有 VPC 關聯。
● 從次要範圍建立新子網。
● 更新路由、安全規則、網路裝置和IP地址管理記錄。
設計理由
● 技術可行性：AWS 在一個 VPC 上支援多個關聯的 CIDR 塊。
● 需求匹配：該公司無需重建網路即可新增地址。
● 場景匹配：現有資源和連線應保留在同一 VPC 中。
● 工程常識：首先檢查與對等網路、傳輸網路、VPN 和本地網路的重疊。
應排除的替代方案
● 刪除子網不會更改主 VPC CIDR。
● 第二個 VPC 加上對等互連建立了單獨的網路和額外的路由操作。
● 主網段不需要更換。
● 重疊的次要範圍可能會破壞連線。
工作流：規劃地址空間 → 關聯輔助 CIDR → 建立子網 → 更新控制 → 遷移或啟動工作負載。
Redshift 區域災難恢復
Redshift 災難恢復使用複製到另一個區域的快照，而不是連續叢集複製。
推薦架構
● 啟用自動 Redshift 快照。
● 配置跨Region快照複製到恢復Region。
● 設定保留以滿足 24 小時 RPO。
● 測試在一小時 RTO 內恢復叢集。
設計理由
● 技術可行性：本機快照副本將可恢復的倉庫資料放置在源區域之外。
● 需求匹配：自動快照滿足資料丟失目標，區域副本可防止區域故障。
● 場景匹配：工作負載是 Redshift，而不是具有跨區域副本的事務資料庫。
● 工程常識：恢復時間必須包括叢集恢復和應用程式重新連線。
應排除的替代方案
● 在災難期間，手動快照複製開始得太晚。
● S3 跨區域複製不是 Redshift 叢集故障轉移機制。
● Redshift 這裡沒有連續的跨區域叢集複製設計。
● 除非啟用複製，否則自動快照將保留在源區域中。
工作流：自動快照→跨區域複製→災難→恢復叢集→驗證→重新連線分析。
用於 ECR 影象拉取的私有 Fargate 出口
私有子網中的 Fargate 任務需要出站路徑來檢索其容器映像，除非配置了所有必需的私有端點。
推薦架構
● 保持自動公共 IP 分配處於禁用狀態。
● 將 NAT 閘道器放置在公共子網中。
● 為公有子網提供一條到 Internet 閘道器的路由。
● 將私有子網出站流量路由到 NAT 閘道器。
● 透過網路控制允許所需的 HTTPS 流量。
設計理由
● 技術可行性：該任務使用其私有地址並透過 NAT 獲取出站連線以達到 ECR 依賴項。
● 需求匹配：容器啟動時不會將任務直接暴露給網際網路。
● 場景匹配：從 ECR 登錄檔端點拉取時發生報告的連線超時。
● 工程常識：公共出口基礎設施屬於公共子網；工作負載保持私有。
應排除的替代方案
● ECR 使用介面端點，而不是替代方案中描述的閘道器端點。
● Fargate 需要 awsvpc 網路並且無法切換到橋接模式。
● 私有子網中的 NAT 閘道器無法到達 Internet 閘道器。
● 啟用任務公共 IP 與私有設計衝突。
工作流：任務啟動→私有路由→NAT閘道器→ECR映象拉取→容器啟動。
使用 CHAP 保護 iSCSI 會話
Storage Gateway iSCSI 會話應在塊儲存公開之前對啟動器進行身份驗證。
推薦控制
● 為 iSCSI 目標配置質詢握手身份驗證協議。
● 將 CHAP 憑據安全地儲存在閘道器和批准的啟動器上。
● 限制對所需 iSCSI 埠和源系統的網路訪問。
● 透過受控維護輪換憑證。
設計理由
● 技術可行性：CHAP 透過質詢-響應交換對 iSCSI 啟動器進行身份驗證，而不直接傳送機密。
● 需求匹配：該控制降低了閘道器塊卷的未經授權的附加和重放風險。
● 場景匹配：該介面是iSCSI，因此保護應使用其支援的身份驗證機制。
● 工程常識：將協議認證與網路限制相結合；兩者都不能替代對方。
應排除的替代方案
● SMB 和 NFS 身份驗證設定不能保護 iSCSI 卷。
● HTTPS 保護管理或 API 流量，而不是 iSCSI 會話本身。
● S3 儲存桶策略不會對本地 iSCSI 啟動器進行身份驗證。
● 僅加密並不能證明哪個主機正在連線目標。
工作流：啟動器連線 → 閘道器發出質詢 → 啟動器使用共享金鑰進行響應 → 閘道器驗證 → iSCSI 會話開啟。
聯合員工對個人 S3 字首的訪問
目錄使用者可以接收僅限於匹配的個人 S3 字首的臨時憑證。
推薦架構
● 使用聯合代理對公司目錄使用者進行身份驗證。
● 將身份屬性對映到 IAM 角色會話。
● 使用 STS 獲取臨時憑證。
● 應用帶有將每個使用者對映到 S3 字首的變數的 IAM 策略。
設計理由
● 技術可行性：策略變數範圍來自聯合身份上下文的物件路徑。
● 需求匹配：員工使用現有憑證，無需重複的 IAM 使用者。
● 場景匹配：每個人都需要在一個儲存桶中擁有一個單獨的資料夾。
● 工程常識：保持身份驗證集中並動態授權資料路徑。
應排除的替代方案
● Amazon Connect 是一項聯絡中心服務。
● 將每個目錄身份映象到 IAM 會增加生命週期開銷。
● 每個員工的 IAM 使用者會建立重複的密碼或訪問金鑰。
● 靜態共享憑據無法隔離個人字首。
工作流：員工登入 → 代理驗證目錄 → STS 發出會話 → 策略變數選擇字首 → S3 請求。
使用 DynamoDB 全域性表進行多區域事務
全球市場需要本地區域讀寫以及區域之間的託管複製。
推薦架構
● 建立一個 DynamoDB 全域性表，其中包含所有所需區域中的副本。
● 將每個區域 API 定向到其本地副本。
● 讓 DynamoDB 跨所有副本表複製專案更改。
● 設計多區域寫入的事務金鑰和衝突行為。
設計理由
● 技術可行性：全域性表提供託管多活動複製和區域端點。
● 需求匹配：該設計降低了全球使用者的延遲，並避免了自定義複製基礎設施。
● 場景匹配：數以百萬計的市場使用者和多區域 API 需要水平可擴充套件的儲存。
● 工程常識：與構建重播系統相比，更喜歡資料庫的本機複製功能。
應排除的替代方案
● 所描述的 Aurora 多主架構不是有效的多區域主動-主動設計。
● 基於 Lambda 的重播複製了內建複製，並引入了排序、重試和衝突管理工作。
● Control Tower 管理 AWS 賬戶，並且不復制應用程式記錄。
● Amazon Connect 是一項聯絡中心服務，與資料庫複製無關。
工作流：API寫入本地副本→基於流的全域性複製→遠端副本更新→應用程式本地讀取→監控複製和衝突指標。
具有服務控制策略的中央帳戶護欄
多賬戶治理需要集中強制執行許可權邊界，而不是重複的賬戶級 IAM 策略。
推薦架構
● 使用 AWS Organizations 和組織單位組織部門賬戶。
● 將服務控制策略附加到適當的根、OU 或帳戶。
● 將工作負載 IAM 策略保留在每個賬戶內以獲取實際的許可權授予。
設計理由
● 技術可行性：SCP 定義成員帳戶中主體可用的最大許可權。
● 需求匹配：中央管理員可以允許或拒絕維護成本低的服務類別。
● 場景匹配：部門賬戶在繼承公司護欄的同時保持獨立管理。
● 工程常識：將組織範圍的邊界與本地角色許可權分開。
應排除的替代方案
● 每個賬戶內附加的 IAM 策略不會集中約束每個委託人或成員賬戶根使用者。
● 身份聯合解決身份驗證和員工訪問問題，而不是帳戶範圍的服務限制。
● 跨賬戶角色和每個資源的策略造成了高度複雜性和不完整的治理覆蓋範圍。
重要行為：SCP 不授予訪問許可權。僅當身份或資源策略允許並且沒有適用的 SCP 阻止請求時，請求才會成功。
工作流：群組帳戶 → 設計護欄 → 在有限的 OU 中進行測試 → 附加 SCP → 監控被拒絕的操作。
防止生產 EC2 終止
開發人員訪問許可權應允許正常工作，同時明確防止生產例項終止。
推薦控制
● 刪除開發人員角色的生產終止許可權。
● 當目標具有生產標籤時，為 ec2:TerminateInstances 新增顯式 IAM 拒絕。
● 保護標籤管理許可權，以便開發人員無法刪除控制標籤。
設計理由
● 技術可行性：顯式拒絕會覆蓋允許，並且資源標記條件會限制限制。
● 需求匹配：開發人員保留對非生產資源的安全操作。
● 場景匹配：主要風險是對生產例項的破壞性 API 訪問。
● 工程常識：最小特權比在不必要的廣泛許可上增加審批摩擦更強大。
應排除的替代方案
● PowerUserAccess 仍然允許許多刪除操作。
● 安全組影響網路流量，而不影響 EC2 API 授權。
● MFA 條件可能會減少事故，但仍允許終止。
● 如果使用者可以修改設定，則單獨的 EC2 終止保護並不是完整的 IAM 邊界。
工作流：開發人員呼叫終止 → IAM 評估角色和生產標籤 → 顯式拒絕阻止請求 → CloudTrail 記錄嘗試。
從 LDAP 到 IAM 角色的自定義聯合
自定義移動身份驗證解決方案可以在頒發臨時 AWS 角色憑證時保留 LDAP 作為憑證源。
支援的模式
● 構建自定義 OpenID Connect 提供商並使用 Cognito 身份池將經過身份驗證的身份對映到 IAM 角色。
● 或者構建一個與 SAML 相容的解決方案，根據 LDAP 進行身份驗證並將斷言傳送到 IAM SAML 身份提供商。
設計理由
● 技術可行性：OIDC或SAML建立聯盟； Cognito 或 IAM 交換臨時角色會話的可信身份資訊。
● 需求匹配：移動應用程式使用自定義身份驗證和 IAM 角色，無需儲存 AWS 訪問金鑰。
● 場景匹配：公司必須保留 LDAP 並滿足嚴格的安全控制。
● 工程常識：重用標準聯合協議，而不是發明令牌資料庫和授權引擎。
應排除的替代方案
● 與這種直接移動角色聯合流程相比，IAM Identity Center 更適合員工訪問門戶。
● 自定義 API 閘道器和 DynamoDB 令牌服務複製身份、會話和憑證功能。
● 僅與 Identity Center 結合使用的 OIDC 並不直接提供所請求的移動 IAM 角色工作流程。
工作流：使用者憑證 → LDAP 驗證 → OIDC 令牌或 SAML 斷言 → 角色對映 → 臨時 AWS 憑證。
經濟高效的 OpsWorks 層
相關應用程式元件可以共享一個 OpsWorks 堆疊，同時為不同的角色使用單獨的層。
推薦架構
● 將現有的客戶支援 Web 應用程式保留在一層中。
● 為影片聊天元件新增第二層。
● 在可行的情況下，使用一種自定義 Chef 配方來執行共享安裝或整合任務。
● 將例項和生命週期事件分配給適當的層。
設計理由
● 技術可行性：OpsWorks 層在堆疊中組織例項、配方、包和生命週期配置。
● 需求匹配：新元件保持獨立配置，無需複製整個堆疊。
● 場景匹配：Web 支援和影片聊天屬於同一個應用環境，但具有不同的伺服器角色。
● 工程常識：將運營角色（不是每個功能）分離到不同的基礎設施資產中。
應排除的替代方案
● 第二個完整堆疊會重複配置和管理成本。
● 在一層中混合兩種伺服器角色會減少對擴充套件和配方的控制。
● 每個相同依賴項的單獨配方會增加不必要的維護。
● 在功能釋出期間替換 OpsWorks 擴大了範圍。
工作流：更新堆疊→建立影片層→附加配方→啟動例項→驗證整合→獨立縮放每個層。
將 TLS 證書控制與開發人員分離
安全性可以控制私鑰，而開發人員可以透過在負載均衡器處終止 TLS 來管理應用程式伺服器。
推薦架構
● 將證書儲存在 AWS Certificate Manager 或支援的 AWS 證書儲存中。
● 限制安全團隊的證書許可權。
● 將證書附加到 ALB HTTPS 偵聽器。
● 讓私鑰材料遠離 EC2 例項。
設計理由
● 技術可行性：ALB 執行 TLS 終止，而不將私鑰分發給應用程式主機。
● 需求匹配：當開發人員操作 EC2 時，安全性保留證書生命週期控制。
● 場景匹配：團隊需要嚴格的職責分離。
● 工程常識：當開發人員擁有廣泛的伺服器管理許可權時，主機級檔案許可權會很弱。
應排除的替代方案
● 將證書儲存在 EC2 上會將其公開給特權主機使用者。
● 從 S3 檢索私鑰會破壞分離。
● 從 CloudHSM 複製金鑰會破壞 HSM 隔離。
● 應用程式所有者不應管理生產證書更新。
工作流：安全管理證書→ALB終止TLS→轉發的請求到達EC2而不暴露私鑰。
透過 Direct Connect 閘道器實現區域間專用連線
中央辦公室可以透過一個託管的 Direct Connect 架構訪問多個區域的 VPC。
推薦架構
● 使用 AWS Direct Connect 閘道器。
● 將虛擬專用閘道器附加到每個區域 VPC。
● 將專用虛擬介面連線到 Direct Connect 閘道器。
● 使用 BGP 公佈批准的路由。
設計理由
● 技術可行性：Direct Connect 閘道器將私有 VIF 連線與跨受支援區域的虛擬私有閘道器關聯起來。
● 需求匹配：流量使用具有可預測效能和集中管理的專用連線。
● 場景匹配：該辦公室需要對多個區域 VPC 進行私有訪問，而不僅僅是 VPC 到 VPC 的通訊。
● 工程常識：使用集線器服務而不是構建和維護點對點鏈路的完整網格。
應排除的替代方案
● 區域間 VPC 對等互連不會連線本地辦公室並建立許多成對關係。
● 公共 VIF 不是私有 VPC 字首的正確路徑。
● 鏈路聚合組可提高一個 Direct Connect 位置的容量或彈性，但不會取代專用 VIF 設計。
● 具有基於 Internet 的 VPN 的 Transit Gateway 不滿足專用路徑要求。
工作流：辦公室路由器 → Direct Connect → 私有 VIF → Direct Connect 閘道器 → 區域 VGW → VPC。
SCP 繼承和臨時帳戶加入
從組織根繼承的顯式拒絕不能被子組織單位上的允許策略覆蓋。
推薦架構
● 將生產限制從組織根移動到生產 OU。
● 建立具有配置 AWS Config 所需許可權的臨時 Onboarding OU。
● 安裝所需的控制元件後，將新帳戶置於入職中。
● 驗證後將帳戶移至生產。
設計理由
● 技術可行性：SCP評估尊重繼承的否認；將拒絕更改重新定位到適用的位置。
● 需求匹配：可以在不削弱現有生產帳戶的情況下配置入職帳戶。
● 場景匹配：這一例外情況是暫時的，並且僅限於一個新獲得的帳戶。
● 工程常識：將控制元件放置在符合其預期範圍的最窄級別。
應排除的替代方案
● 消除每個人的 root 限制會導致整個組織範圍內的暴露。
● 入職時允許 SCP 無法覆蓋根級顯式拒絕。
● 根允許列表可以發揮作用，但會在需要新服務時增加長期維護。
● 服務目錄不會覆蓋 SCP 評估。
工作流：建立 OU → 重新定位生產 SCP → 內建帳戶 → 配置配置規則 → 驗證合規性 → 將帳戶移至生產。
使用 StackSets 進行多賬戶部署
CloudFormation StackSets 跨賬戶和區域集中部署一致的基礎設施。
推薦架構
● 將 StackSets 與 AWS Organizations 整合。
● 定義一次所需的 CloudFormation 模板。
● 目標組織部門、客戶和區域。
● 使用受控許可權、容錯能力和部署順序。
設計理由
● 技術可行性：StackSets 在多個賬戶和區域中建立和更新堆疊例項。
● 需求匹配：中央團隊以較少的體力工作維持一致的資源。
● 場景匹配：部署範圍跨越整個組織。
● 工程常識：集中標準化，同時僅在必要時允許特定於賬戶的引數。
應排除的替代方案
● 巢狀堆疊提供模板模組化，但不協調組織範圍內的部署。
● 區域引數和 IAM 策略仍然需要單獨的堆疊操作。
● Control Tower 管理登陸區域，但不是直接的通用 StackSet 部署機制。
● 手動堆疊容易發生漂移。
工作流：更新模板 → 選擇目標 → 部署堆疊例項 → 監控故障 → 修復偏差。
使用時間點資料恢復交易平臺
嚴格的恢復計劃需要頻繁的可恢復性、受保護的備份以及故障區域之外的副本。
推薦架構
● 將 AWS Backup 與受支援資料庫的時間點恢復結合使用。
● 將應用程式備份和事務日誌儲存在 Amazon S3 中。
● 經常捕獲日誌足以滿足十分鐘的 RPO。
● 使用 S3 跨區域複製將恢復物件複製到另一個區域。
● 在兩小時 RTO 內測試恢復。
設計理由
● 技術可行性：PITR 可在選定時間附近恢復資料庫狀態，而複製備份可在區域故障中倖存下來。
● 需求匹配：頻繁的日誌可以限制資料丟失，預先定位的副本可以減少恢復延遲。
● 場景匹配：受監管的交易系統既需要運營恢復，也需要持久的證據。
● 工程常識：RPO決定捕獲頻率； RTO 決定恢復自動化和資料放置。
應排除的替代方案
● 多可用區可以防止可用區故障，但不是區域災難恢復。
● 每日快照無法滿足十分鐘的 RPO。
● 冰川修復可能會延遲短暫的 RTO。
● 僅保留在生產區域中的備份可能會因區域中斷而消失。
工作流：連續事務→PITR和頻繁日誌→跨區域複製→恢復→重放→驗證→重定向流量。
低成本可搜尋冰川檔案
大型資料集可以壓縮為更少的 Glacier 檔案，而可搜尋後設資料保留在 DynamoDB 中。
推薦架構
● 將每個資料集壓縮到一個存檔中。
● 將存檔儲存在 S3 Glacier 儲存中。
● 在 DynamoDB 中記錄檔名、後設資料和存檔識別符號。
● 搜尋 DynamoDB，然後使用存檔識別符號請求恢復。
設計理由
● 技術可行性：DynamoDB 提供線上後設資料查詢，而 Glacier 提供低成本檔案儲存。
● 需求匹配：存檔計數開銷下降，使用者可以在檢索之前找到資料集。
● 場景匹配：內容很少被訪問，但必須保持可發現性。
● 工程常識：歸檔儲存不是搜尋索引。
應排除的替代方案
● 無法透過檔案內的檔名直接查詢冰川庫。
● 僅儲存為 S3 物件的後設資料仍然需要可搜尋索引。
● 兩桶設計增加了複雜性，但沒有改善檔案發現。
● 將所有資料集儲存在線上 S3 儲存中的成本高於所需的 Glacier 方法。
工作流：壓縮資料集 → 存檔 → DynamoDB 中的索引後設資料 → 搜尋 → 按需檢索存檔。
集中出口檢查
超過 50 個帳戶應共享一個託管出站檢查路徑，而不是重複代理或防火牆組。
推薦架構
● 構建集中式出口VPC。
● 透過 Transit Gateway 連線工作負載 VPC。
● 透過 AWS 網路防火牆路由出站流量。
● 使用 NAT 閘道器作為 Internet 出口。
● 集中管理規則和路線。
設計理由
● 技術可行性：Transit Gateway 提供集線器路由，網路防火牆執行託管檢查，NAT 閘道器轉換出站流量。
● 需求匹配：該設計將策略管理擴充套件到多個賬戶，操作量較低。
● 場景匹配：所有帳戶都需要一致的出站過濾。
● 工程常識：透過檢查路徑保留對稱路由。
應排除的替代方案
● 每個帳戶中的代理佇列都會建立修補和擴充套件工作。
● 每個帳戶中的防火牆端點都會重複成本和策略。
● 中央 EC2 代理可以工作，但需要容量和軟體維護。
● 獨立的 NAT 路徑可以繞過集中檢查。
工作流：分支 VPC → 中轉閘道器 → 網路防火牆 → NAT 閘道器 → 網際網路 → 對稱返回路徑。
與 EFS 共享高通量資料
使用相同資料集的佇列應安裝一個共享檔案系統，而不是在每個例項上保留副本。
推薦架構
● 將資料集儲存在 Amazon EFS 上。
● 從所有應用程式例項安裝它。
● 當所需吞吐量超過檔案系統大小提供的大小時，請使用預配置吞吐量。
● 監控吞吐量利用率和客戶端效能。
設計理由
● 技術可行性：EFS 提供共享彈性檔案訪問，預配置吞吐量將效能與儲存容量分離。
● 需求匹配：資料重複消失，吞吐量變得可預測。
● 場景匹配：多個例項需要併發訪問相同的檔案。
● 工程常識：與吞吐量模式分開選擇效能模式。
應排除的替代方案
● 例項儲存是短暫的且不共享。
● 最大 I/O 提高了聚合規模，但增加了每個操作的延遲，並且可能不適合此工作負載。
● 過大的 gp2 卷只是為了獲得效能而浪費儲存空間。
● 單獨的 EBS 副本會產生同步和替換問題。
工作流：例項掛載EFS→全部讀取共享資料集→配置吞吐量服務負載→指標指導調優。
使用臨時 S3 憑證進行 LDAP 身份驗證
現有 LDAP 身份可以透過將使用者對映到 IAM 角色的聯合代理安全地訪問 S3。
推薦模式
● 讓應用程式根據 LDAP 對使用者進行身份驗證，將身份對映到 IAM 角色，然後呼叫 STS。
● 或者使用專用身份代理來執行 LDAP 驗證和角色對映。
● 返回授權 S3 操作的臨時 AWS 憑證。
設計理由
● 技術可行性：在受信任的應用程式或代理驗證使用者後，STS 提供短期角色憑據。
● 需求匹配：員工使用現有憑證，無需建立永久 IAM 使用者或嵌入 AWS 金鑰。
● 場景匹配：LDAP 仍然是企業身份源，而 S3 託管受保護的內容。
● 工程常識：將身份驗證與 AWS 授權分開並保持會話臨時。
應排除的替代方案
● 為每個 LDAP 員工建立一個 IAM 使用者會重複身份生命週期管理。
● Direct Connect 閘道器和中轉網路不執行身份驗證。
● S3 儲存桶策略無法驗證 LDAP 密碼。
● 應用程式中的長期訪問金鑰會增加曝光和輪換工作。
工作流：使用者登入 → LDAP 驗證 → 角色對映 → STS 臨時憑證 → 簽名的 S3 請求 → 過期。
低延遲 UDP 遊戲網路
UDP 遊戲流量需要第 4 層負載平衡器和子網控制，可以明確拒絕不需要的協議。
推薦架構
● 將網路負載均衡器與 UDP 偵聽器結合使用。
● 根據需要分配靜態彈性 IP 地址。
● 為 NLB 建立 Route 53 記錄。
● 使用 NACL 拒絕規則來限制不需要的非 UDP 流量。
設計理由
● 技術可行性：NLB支援UDP和高吞吐量低延遲傳輸； NACL 支援顯式拒絕。
● 需求匹配：該服務獲得穩定的定址和適合協議的擴充套件。
● 場景匹配：遊戲協議是UDP，而不是HTTP。
● 工程常識：選擇在所使用的協議層執行的安全和負載平衡控制。
應排除的替代方案
● CloudFront 專注於 HTTP 和 HTTPS 交付。
● AWS WAF 檢查 HTTP 負載，而不是 UDP。
● ALB 不支援 UDP 偵聽器。
● 安全組是僅允許的，不能明確表示拒絕。
工作流：玩家解析Route 53→NLB彈性IP→UDP監聽→健康的遊戲目標； NACL 拒絕不需要的流量。
減少資料庫讀取延遲
在考慮分片或引擎替換之前，重複的讀取流量應該由快取和資料庫副本吸收。
推薦架構
● 在所需的可用區中部署 ElastiCache。
● 快取頻繁請求的記錄和查詢結果。
● 新增 RDS 只讀副本並將只讀流量路由到它們。
設計理由
● 技術可行性：ElastiCache 提供記憶體中響應，副本分發資料庫讀取。
● 需求匹配：公告流量的延遲較低，應用程式更改有限。
● 場景匹配：此次釋出會造成讀取量激增。
● 工程常識：在增加資料庫大小之前刪除重複的工作。
應排除的替代方案
● 分片需要對程式碼和操作進行重大更改。
● 鍵空間遷移不必要地改變了資料模型。
● 更大的例項和更多的 IOPS 可以垂直擴充套件。
● CloudFront 支援靜態內容，但不能支援每個動態資料庫查詢。
● 沒有可用區恢復能力的快取節點可能會成為故障點。
工作流：應用程式檢查快取→命中返回→未命中讀取副本→更新快取→寫入保留在主伺服器上。
在 CloudFormation 中連線 SNS 和 SQS
基礎設施即程式碼應該使用資源引用而不是硬編碼識別符號來建立通知主題、佇列和訂閱。
推薦模板行為
● 定義 AWS::SNS::Topic 資源。
● 定義 AWS::SQS::Queue 資源。
● 使用協議 sqs 定義 SNS 訂閱。
● 使用 Fn::GetAtt 檢索訂閱終端節點的佇列 ARN。
● 允許SNS主題透過SQS佇列策略傳送訊息。
設計理由
● 技術可行性：SNS 釋出通知，SQS 為消費者持久緩衝通知。
● 需求匹配：CloudFormation 可跨環境重複建立關係。
● 場景匹配：佇列端點是在堆疊部署期間生成的。
● 工程常識：引用已部署的資源屬性，而不是手動複製 ARN。
應排除的替代方案
● 當需要 SQS ARN 時，佇列 URL 不是 SNS 訂閱終端節點。
● 僅建立主題和佇列不會訂閱它們。
● 忽略佇列策略可能會阻止 SNS 傳遞。
● 硬編碼的 ARN 會降低可移植性，並且可能會定位到錯誤的賬戶或區域。
工作流：部署主題→部署佇列→解析佇列ARN→建立訂閱→授權主題→測試訊息傳遞。
使用 DynamoDB 處理全域性半結構化資料
需要本地低延遲讀取和寫入的多區域應用程式可以使用具有託管區域計算的 DynamoDB 全域性表。
推薦架構
● 在區域 ALB 後面的每個區域中部署 Fargate 應用程式服務。
● 將半結構化記錄儲存在 DynamoDB 全域性表中。
● 使用 Global Accelerator 將使用者路由到附近健康的 ALB。
設計理由
● 技術可行性：全域性表提供多活複製； Fargate 取消了伺服器管理； Global Accelerator 提供健康感知的選播路由。
● 需求匹配：使用者以高可用性接收區域寫入和讀取。
● 場景匹配：資料是半結構化的並且在全球範圍內活躍。
● 工程常識：將資料庫的複製模型與應用程式的主動-主動行為保持一致。
應排除的替代方案
● Aurora 是關係型的，對於該資料模型來說不太自然。
● EC2 新增了伺服器操作。
● DocumentDB 在所描述的設計中是區域性的。
● S3 複製是非同步物件複製，而不是低延遲記錄訪問。
工作流：使用者 → 全域性加速器 → 區域 ALB → Fargate → 本地 DynamoDB 副本 → 全域性複製。
無伺服器 REST 會話服務
基於狀態的 REST API 可以使用託管請求處理、無伺服器邏輯和可擴充套件會話儲存。
推薦架構
● 使用 API Gateway 獲取 REST 資源、階段、API 金鑰和使用控制。
● 在 Lambda 中執行狀態轉換邏輯。
● 使用 Auto Scaling 將會話儲存在 DynamoDB 中。
設計理由
● 技術可行性：API Gateway 呼叫 Lambda，DynamoDB 提供低操作可擴充套件狀態。
● 需求匹配：該服務支援 REST API、測試階段和可變需求，無需伺服器管理。
● 場景匹配：現有介面是 REST 而不是 GraphQL。
● 工程常識：選擇與客戶端合同匹配的API服務。
應排除的替代方案
● EC2、NLB 和 Aurora 新增伺服器和資料庫操作。
● AppSync 公開 GraphQL 而不是所需的 REST 介面。
● ALB 可以呼叫 Lambda，但缺少 API Gateway 的直接 API 金鑰、使用計劃和階段工作流程。
● 固定的資料庫容量與可變的會話需求相沖突。
工作流：REST 請求 → API 閘道器授權和階段 → Lambda 邏輯 → DynamoDB 會話更新。
EC2 到 Aurora 的安全組引用
可以透過引用安全組而不是廣泛的 CIDR 範圍來將資料庫訪問限制為應用程式例項。
推薦規則
● 允許從 EC2 安全組到 Aurora 安全組的出站 TCP 3306。
● 允許 Aurora 安全組上來自 EC2 安全組的入站 TCP 3306。
● 刪除更廣泛的資料庫訪問規則。
設計理由
● 技術可行性：安全組是有狀態的，可以引用其他安全組。
● 需求匹配：只有經過批准的應用程式例項才能發起 MySQL 連線。
● 場景匹配：EC2 是客戶端，Aurora 是伺服器。
● 工程常識：授權工作負載身份組而不是更改例項 IP 地址。
應排除的替代方案
● 應用程式不需要其自己的安全組上的入站資料庫流量。
● Aurora 不會啟動應用程式資料庫會話。
● NACL CIDR 規則更廣泛且無國籍。
● 單獨的入站 NACL 忽略了返回路徑考慮因素並且缺乏安全組精度。
工作流：EC2 發起 3306 → 出站 SG 檢查 → Aurora 入站 SG 檢查 → 允許有狀態返回流量。
管理型智慧聯絡中心
自動呼叫處理需要持久的工作整合、語音理解、意圖識別和託管代理平臺。
推薦架構
● 使用 Amazon Connect 進行入站呼叫、路由和代理工作流程。
● 使用 Amazon Lex 進行語音識別和意圖檢測。
● 在必須非同步緩衝後端工作的情況下使用 Amazon SQS。
● 呼叫受控應用程式整合來執行業務操作。
設計理由
● 技術可行性：Connect 提供聯絡中心基礎設施，Lex 解釋呼叫者請求，SQS 解耦後端任務。
● 需求匹配：常見請求可以自動化並在必要時升級給代理。
● 場景匹配：工作負載是客戶呼叫，而不是純文字分析。
● 工程常識：將對話狀態與持久的業務工作分開。
應排除的替代方案
● Alexa for Business 不是客戶聯絡中心平臺。
● Kinesis 和 Comprehend 不提供呼叫語音識別和路由。
● Rekognition 分析影象和影片。
● Polly 發出語音，但無法檢測呼叫者的意圖。
工作流：呼叫者 → 連線流程 → Lex 意圖 → 業務整合或 SQS → 響應或代理轉移。
緩衝捐款激增
捐贈活動需要持久的突發吸收、彈性工作人員和可預測的可擴充套件寫入。
推薦架構
● 將捐贈請求放入 Amazon SQS 中。
● 根據佇列深度擴充套件 EC2 工作執行緒。
● 將已處理的捐贈儲存在 DynamoDB 中，併為活動預置吞吐量大小。
● 使用冪等性和死信處理。
設計理由
● 技術可行性：SQS 保護請求，Auto Scaling 新增使用者，DynamoDB 處理高寫入吞吐量。
● 需求匹配：突發流量不會使一條同步資料庫路徑超載。
● 場景匹配：該活動會建立臨時寫入突發。
● 工程常識：在執行較慢的處理之前持久地接受請求。
應排除的替代方案
● 沒有佇列的 DynamoDB 無法保護下游處理免受峰值影響。
● CloudFront 不緩衝捐贈寫入。
● 一個 RDS 例項保持垂直邊界。
● 專用的超大型 Oracle 主機成本高昂且操作繁重。
工作流：捐贈者提交 → SQS → 工作人員規模 → 驗證並寫入 DynamoDB → 確認並通知。
現代化 WebSphere、DB2 和 IBM MQ
託管平臺重組可以保留關鍵應用程式介面，同時減少資料庫和訊息代理操作。
推薦架構
● 使用 SCT 和 DMS 將 DB2 遷移到 Aurora。
● 在 ELB 後面的 EC2 Auto Scaling 上執行 WebSphere。
● 在相容性允許的情況下，將自我管理的 IBM MQ 基礎設施替換為 Amazon MQ。
設計理由
● 技術可行性：SCT 轉換架構，DMS 移動資料，EC2 保留 WebSphere，Amazon MQ 支援託管代理相容性。
● 需求匹配：在不重寫整個應用程式的情況下，可用性會提高，而操作會下降。
● 場景匹配：不同的層級需要不同的遷移策略。
● 工程常識：實現託管等價物的現代化，同時保留重寫成本高昂的協議。
應排除的替代方案
● 在 EC2 上自我管理 IBM MQ 可保留許可和操作。
● 重新託管每個 IBM 產品對雲的好處微乎其微。
● 用 SQS 替換 MQ 可能需要更改應用程式。
● 保持 DB2 自我管理會錯過託管資料庫的節省。
工作流：轉換架構 → 遷移資料 → 部署 WebSphere 佇列 → 配置 Amazon MQ → 測試 → 切換。
組織範圍內的 CloudTrail 日誌記錄
集中式組織跟蹤記錄成員帳戶的活動，無需為每種訪問方法建立單獨的跟蹤。
推薦架構
● 從管理賬戶建立 CloudTrail 組織跟蹤。
● 啟用對所有組織帳戶和所需區域的覆蓋。
● 將日誌傳送到專用的 S3 儲存桶。
● 加密稽核日誌並啟用強大的刪除保護，包括適當的 MFA 刪除。
設計理由
● 技術可行性：一項跟蹤記錄參與帳戶之間的控制檯、SDK、CLI 和 API 活動。
● 需求匹配：中央儲存提高了審計覆蓋範圍、完整性和管理。
● 場景匹配：該公司透過 AWS Organizations 管理多個賬戶。
● 工程常識：將審計證據與工作負載管理員分開。
應排除的替代方案
● 單一賬戶跟蹤不覆蓋整個組織。
● SNS 傳送通知不是稽核記錄。
● 區域路線可能會忽略其他區域的活動。
● 控制檯、SDK 和 CLI 的單獨路徑無需重複配置。
工作流：成員帳戶操作→組織跟蹤→加密的S3日誌→受控的稽核員訪問→保留監控。
擴充套件 Web 會話和 Aurora 讀取
有狀態 Web 應用程式需要第 7 層負載平衡、彈性計算和可擴充套件的資料庫讀取器。
推薦架構
● 在 ALB 後面的 Auto Scaling 組中執行 Web 例項。
● 僅當應用程式需要時才啟用粘性會話。
● 新增 Aurora 副本並使用 Aurora Auto Scaling 來獲取讀取容量。
● 保持寫入定向到寫入器端點。
設計理由
● 技術可行性：ALB支援HTTP路由和粘性； Aurora Auto Scaling 根據負載新增副本。
● 需求匹配：Web 需求和資料庫讀取獨立擴充套件。
● 場景匹配：會話是有狀態的並且讀取流量各不相同。
● 工程常識：Aurora Auto Scaling 擴充套件副本，而不是寫入器。
應排除的替代方案
● NLB 缺乏規定的第 7 層路由和粘性會話行為。
● Aurora Auto Scaling 不會擴充套件主資料庫。
● 僅擴充套件 EC2 會給資料庫帶來讀取壓力。
● 粘性會話會降低平衡效率，因此在可行的情況下最好使用外部會話儲存。
工作流：客戶端 → ALB 粘性路由 → Auto Scaling 例項 → 用於讀取的讀取器端點 → 用於更新的寫入器。
高峰負載期間經濟高效的可用性
多可用區應用程式應保持足夠的空間，以承受一個可用區的損失，同時將定價模型與負載穩定性相匹配。
推薦架構
● 跨所有可用區執行 Auto Scaling。
● 保持峰值條件下的恢復空間。
● 透過預留定價涵蓋穩定的使用情況。
● 使用可靠的按需容量來應對關鍵峰值，並使用可選的 Spot 來應對寬容的工作。
● 需求下降後縮小規模。
設計理由
● 技術可行性：當一個可用區發生故障時，Auto Scaling 會替換健康可用區中的容量。
● 需求匹配：該應用程式可以承受高峰流量，而無需永久過度配置每個區域。
● 場景匹配：故障期間的高利用率幾乎沒有剩餘容量。
● 工程常識：可用性計算必須使用故障後容量，而不是正常容量。
應排除的替代方案
● 修復了正常執行期間的容量過剩問題。
● 每個可用區的例項太少，無法吸收故障後的峰值流量。
● All-Spot 容量可能會在中斷期間消失。
● 單可用區 Auto Scaling 組的可用性不高。
工作流：覆蓋基線 → 峰值擴充套件開始 → AZ 失敗 → 健康的 AZ 擴充套件 → 負載重新分配 → 佇列稍後縮小。
透過 AppSync 訂閱進行實時評論
客戶端可以透過 WebSockets 上的 GraphQL 訂閱實時接收新評論。
推薦架構
● 透過 AWS AppSync 釋出評論突變。
● 定義與這些突變相關的 GraphQL 訂閱。
● 讓連線的客戶端接收推送的更新。
● 將評論儲存在現有的持久資料儲存中。
設計理由
● 技術可行性：AppSync 維護 WebSocket 連線並推送訂閱事件。
● 需求匹配：新評論出現，無需重複投票。
● 場景匹配：該應用程式需要實時客戶端更新。
● 工程常識：僅推送使用者有權接收的事件。
應排除的替代方案
● 每三秒輪詢一次會增加 API 和 Lambda 負載。
● 更多 Lambda 併發不會將資料推送到連線的客戶端。
● CloudFront 快取可以提供過時的評論，並且不是雙向實時通道。
● 單獨的資料庫寫入不會通知客戶端。
工作流：使用者釋出突變 → AppSync 授權並儲存 → 訂閱事件 → 連線的客戶端更新。
具有持久區域儲存的解耦處理
附加 EBS 的單個 EC2 伺服器無法獨立擴充套件以進行上傳和處理。獨立的物件儲存、工作佇列和工作人員容量。
推薦架構
● 將申請人文件和照片儲存在 Amazon S3 中。
● 啟用 S3 跨區域複製以保護區域資料。
● 將驗證任務放置在 Amazon SQS 上。
● 根據佇列深度擴充套件 EC2 工作執行緒例項。
● 使用 CloudFormation 在另一個區域複製基礎設施。
設計理由
● 技術可行性：S3 提供持久的可擴充套件物件儲存，SQS 緩衝工作，Auto Scaling 新增並行處理器。
● 需求匹配：上傳增長不再取決於一臺 EBS 卷，流量激增不會壓垮一臺伺服器。
● 場景匹配：檔案被接受後，驗證任務可以非同步處理。
● 工程常識：將攝取與處理分離，並將持久資料保留在工作例項之外。
應排除的替代方案
● SNS 是推送通知，而不是具有佇列深度擴充套件的持久工作積壓。
● 更大的預配置 IOPS EBS 改進了一個卷，但保留了例項附加儲存限制。
● EBS不提供共享的跨Region物件儲存。
● 從 SNS 通知數量進行擴充套件缺乏持久的重試和積壓語義。
工作流：上傳到 S3 → 排隊任務 → 工作規模 → 處理檔案 → 儲存結果 → 複製物件並根據需要恢復堆疊。
突發就緒電子商務架構
大型銷售需要彈性的網路容量、全球內容交付、可擴充套件的身份以及能夠吸收突然爆發的購買的結帳路徑。
推薦架構
● 將 Elastic Load Balancer 放置在 EC2 Auto Scaling 組之前。
● 透過 Amazon CloudFront 快取靜態資產。
● 使用 Amazon Cognito 進行客戶和社交登入。
● 在 Amazon SQS 中緩衝結帳請求。
● 將排隊購買處理到 Amazon DynamoDB 中。
設計理由
● 技術可行性：Auto Scaling 增加了 Web 容量，SQS 在高峰期間保留請求，DynamoDB 水平擴充套件事務記錄。
● 需求匹配：該設計可支援數百萬訪客，而不會導致結賬人員同步超載。
● 場景匹配：瀏覽流量和購買處理具有不同的突發模式。
● 工程常識：將接受與處理分離，這樣暫時的後端減速就不會丟失訂單。
應排除的替代方案
● 固定的 EC2 機群無法承受不可預測的銷售激增。
● 沒有緩衝的 RDS 可能會成為寫入瓶頸。
● 單獨的靜態 S3 託管無法執行動態結帳邏輯。
● IAM 使用者不是公共客戶的可擴充套件身份模型。
工作流：客戶 → CloudFront 或負載均衡器 → Cognito 會話 → SQS 中的結賬訊息 → 工作人員 → DynamoDB 訂單狀態。
組織範圍內所需的帶有 SCP 的標籤
當所需的標籤鍵或請求標籤丟失時，組織 SCP 可以拒絕資源建立。
推薦架構
● 定義所需的標籤鍵，例如成本中心和所有者。
● 將 SCP 條件與 aws:TagKeys 和請求標籤鍵一起使用。
● 將 SCP 連線到適當的 OU。
● 測試其建立 API 支援標記的服務。
設計理由
● 技術可行性：顯式拒絕會阻止成員帳戶之間的不合規建立。
● 需求匹配：未標記的資源不能消耗配額或產生未分配的成本。
● 場景匹配：執法必須集中。
● 工程常識：建立後標記或使用不同 API 的服務的帳戶。
應排除的替代方案
● AWS Config 在建立後檢測丟失的標籤。
● Systems Manager 不是組織範圍內的預防策略服務。
● 每個賬戶的 IAM 條件需要重複管理。
● 標籤策略標準化了值，但本身並不強制執行每個建立操作。
工作流：建立請求包含標籤 → SCP 評估鍵和值 → 合規請求繼續；缺少標籤被拒絕。
使用 CodeDeploy 安全混合部署
跨越 EC2 和本地伺服器的部署平臺需要不同的身份機制，但需要一個釋出工作流程。
推薦架構
● 將資料庫憑據作為 KMS 加密的 SecureString 引數儲存在 Systems Manager Parameter Store 中。
● 安裝所需的部署和管理代理。
● 為 EC2 例項提供包含引數和解密許可權的例項配置檔案。
● 使用適當的服務標識註冊本地例項。
● 對兩個目標環境使用 AWS CodeDeploy。
設計理由
● 技術可行性：CodeDeploy 支援 EC2 和註冊的本地例項； Parameter Store 提供加密的執行時配置。
● 需求匹配：憑證在靜態和傳輸過程中保持加密狀態，並且釋出始終自動化。
● 場景匹配：該應用程式在預留的 EC2 容量和現有的本地伺服器上執行。
● 工程常識：不要假裝本地伺服器可以接收 EC2 例項配置檔案。
應排除的替代方案
● Elastic Beanstalk 不會部署到任意本地伺服器。
● 將 Secrets Manager 儲存與 Parameter Store 許可權混合使用會不一致。
● 將 EC2 例項配置檔案策略附加到本地計算機並不是正確的身份模型。
工作流：儲存引數 → 分配目標身份 → 部署修訂版 → 在執行時檢索機密 → 驗證應用程式。
大型遊戲包全球交付
靜態 5 GB 遊戲包應使用持久物件儲存和全域性 CDN，而不是檔案傳輸伺服器。
推薦架構
● 將包儲存在 Amazon S3 中。
● 建立以 S3 作為源的 CloudFront 分配。
● 將 Route 53 用於公共領域。
● 配置快取和源保護。
設計理由
● 技術可行性：S3 持久儲存物件，CloudFront 透過邊緣位置擴充套件下載。
● 需求匹配：全球使用者只需最少的伺服器管理即可獲得較低延遲的交付。
● 場景匹配：該包是靜態的，並且對於每個下載者來說都是相同的。
● 工程常識：不要為全域性可快取的公共檔案執行 FTP 伺服器。
應排除的替代方案
● 請求者付款需要經過身份驗證的 AWS 請求者，不適合匿名網站下載。
● EC2 FTP、EFS 和 NLB 需要伺服器擴充套件和更高的操作。
● EBS 不會在 Auto Scaling 佇列中自動共享。
● ALB 不支援 FTP 流量。
工作流：使用者解析域 → CloudFront 邊緣 → 快取包或 S3 源獲取 → 下載。
跨網路和應用層的 DDoS 防護
防禦第 3 層、第 4 層和第 7 層攻擊需要互補的託管控制。
推薦架構
● 為受支援的公共資源啟用 AWS Shield Advanced 並增強 DDoS 響應。
● 將 AWS WAF Web ACL 應用於公共 HTTP 終端節點。
● 為檢測到的攻擊配置警報和響應聯絡人。
設計理由
● 技術可行性：Shield Advanced 可解決基礎設施層攻擊，而 WAF 可過濾惡意 HTTP 請求模式。
● 需求匹配：該組合涵蓋網路、傳輸和應用層，並支援攻擊通知。
● 場景匹配：公共加密貨幣平臺可能是容量攻擊和網路層攻擊的目標。
● 工程常識：沒有任何一個 Web 過濾器能夠阻止所有基礎設施氾濫，並且網路保護無法理解所有 HTTP 有效負載。
應排除的替代方案
● CloudFront 提高了彈性，但並不能單獨提供所需的完整保護和響應功能。
● AWS 網路防火牆控制 VPC 流量，但不是公共終端節點的主要託管 DDoS 服務。
● Amazon Fraud Detector 評估欺詐性業務活動，而不是網路攻擊。
● 僅擴充套件源會增加成本而不過濾惡意流量。
工作流：網際網路流量→遮蔽防護→邊緣或負載均衡器→WAF檢查→應用；警報觸發響應。
透過 IAM 身份中心進行集中勞動力訪問
大型多帳戶環境需要集中的許可權集以及與現有公司目錄的聯合。
推薦架構
● 使用 AWS Organizations 作為賬戶層次結構。
● 啟用 IAM 身份中心。
● 與企業 Active Directory 建立所需的信任或整合。
● 將使用者和組分配給跨帳戶的許可權集。
設計理由
● 技術可行性：Identity Center 建立集中管理的帳戶分配和聯合會話。
● 需求匹配：員工使用現有憑據，對數百個帳戶進行較低的管理。
● 場景匹配：該設計是員工 SSO，而不是客戶身份。
● 工程常識：集中身份和許可權分配，而不是逐個帳戶維護角色對映。
應排除的替代方案
● 自定義 AD FS 正規表示式和角色對映需要大量手動工作。
● AD Connector 可以代理身份驗證，但不能取代集中式多帳戶許可權集。
● 品牌定製門戶仍然需要整合和角色管理程式碼。
● 單獨的 IAM 使用者重複生命週期管理。
工作流：員工身份驗證→目錄信任→身份中心分配→臨時帳戶會話。
立即 IP 阻止和託管 DDoS 防護
在子網邊界阻止已知的惡意源，並針對更廣泛的 DDoS 攻擊使用專用保護。
推薦架構
● 將有問題的 CIDR 的顯式拒絕新增到相關網路 ACL。
● 使用 AWS Shield Advanced 對受支援的資源提供增強的 DDoS 保護。
設計理由
● 技術可行性：網路ACL是無狀態的，支援顯式拒絕規則； Shield Advanced 提供託管 DDoS 檢測和響應功能。
● 需求匹配：源頭立即被封鎖，環境獲得更廣泛的保護，免受常見基礎設施攻擊。
● 場景匹配：埠掃描針對 VPC 子網內的 EC2 資源。
● 工程常識：使用可以在流量到達主機之前拒絕流量的網路控制。
應排除的替代方案
● 安全組是僅允許的，不能表達顯式的源拒絕。
● Route 53 不是 IP 防火牆。
● Macie 發現敏感的 S3 資料，而不是 DDoS 流量。
● 主機防火牆需要針對每個例項進行更改，並且只有在流量消耗網路資源後才能到達。
● GuardDuty 和補丁管理器改進了檢測和衛生，但不提供所請求的立即阻止和 DDoS 保護。
工作流：識別 CIDR → 在 NACL 中拒絕 → 驗證影響 → 啟用託管保護 → 監控結果。
持久且可擴充套件的新聞釋出平臺
新聞網站應該在全球範圍內分發媒體、擴充套件資料庫讀取並將靜態資產保留在網路伺服器磁碟之外。
推薦架構
● 在 Amazon S3 中儲存影象、影片和靜態媒體。
● 透過 Amazon CloudFront 交付內容。
● 使用 Amazon RDS 多可用區實現資料庫高可用性。
● 為讀取量大的評論和文章查詢新增 RDS 只讀副本。
● 保持應用程式伺服器無狀態且可擴充套件。
設計理由
● 技術可行性：S3 和 CloudFront 擴充套件內容交付，而 RDS 多可用區和副本則分別解決可用性和讀取負載問題。
● 需求匹配：該設計經久耐用，具有全球響應能力，並支援流量增長。
● 場景匹配：新聞媒體是靜態內容，而評論和後設資料仍然相關。
● 工程常識：多可用區保護寫入者；讀取副本規模讀取。他們解決不同的問題。
應排除的替代方案
● EBS RAID 將介質耐用性和擴充套件性與各個伺服器聯絡起來。
● EFS 可以共享檔案，但與 S3 相比並不是最好的全域性內容源。
● Lambda 不會自動修復設計不當的有狀態 Web 層。
● Oracle RAC 在規定的需求之外增加了成本和操作複雜性。
工作流：將媒體釋出到 S3 → 透過 CloudFront 快取 → 將後設資料寫入主資料庫 → 提供從副本的讀取服務。
擴充套件讀取繁重的 Web 應用程式
讀取密集型應用程式可以在分片或垂直擴充套件之前透過資料庫副本、快取、靜態解除安裝和適當大小的計算進行改進。
推薦架構
● 新增 RDS 只讀副本。
● 使用多可用區 ElastiCache 處理重複的查詢結果。
● 將靜態媒體移至 CloudFront 後面。
● 使用 Compute Optimizer 調整 EC2 容量大小。
設計理由
● 技術可行性：副本解除安裝讀取，快取刪除重複查詢，CloudFront 減少源流量。
● 需求匹配：透過降低成本和減少應用程式更改來提高效能。
● 場景匹配：瓶頸在於高讀取量。
● 工程常識：在引入資料分割槽之前消除重複的工作。
應排除的替代方案
● 分片增加了主要的應用程式和操作複雜性。
● 預配置 IOPS 有助於儲存受限的工作負載，但可能無法解決重複查詢。
● 較大的資料庫例項僅提供垂直擴充套件。
● 僅擴充套件應用程式伺服器就可以保持 RDS 壓力不變。
工作流：檢視器靜態請求→CloudFront；動態請求 → 應用程式 → ElastiCache → 未命中時讀取副本 → 更新寫入器。
NLB 背後的 PrivateLink 流量控制
PrivateLink 客戶端連線到網路負載均衡器，因此後端控制必須考慮 NLB 到目標的網路路徑。
推薦控制
● 配置網路 ACL 以允許 NLB 子網和日誌記錄服務子網之間雙向所需的流量。
● 配置 EC2 目標安全組以允許來自 NLB 子網 IP 範圍的入站應用程式流量。
● 拒絕不必要的埠。
設計理由
● 技術可行性：NLB 接受端點服務連線並將其轉發到已註冊的目標。
● 需求匹配：僅預期的負載均衡器路徑到達日誌記錄例項。
● 場景匹配：消費者使用 PrivateLink，而不是直接連線到後端 EC2 地址。
● 工程常識：在選擇防火牆規則的源地址之前跟蹤完整的資料包路徑。
應排除的替代方案
● 客戶端 VPC CIDR 不一定是此架構中的目標觀察到的直接源。
● 所述模型中的網路負載均衡器不使用安全組作為主要過濾器。
● 允許所有私有地址範圍比要求的範圍更廣泛。
● 由於網路 ACL 是無狀態的，僅配置一個 NACL 方向會失敗。
工作流：介面端點 → 端點服務 → NLB 子網 → 目標子網 NACL → EC2 安全組 → 日誌服務。
經濟高效的直連備份
單個 Direct Connect 電路是一個故障點，但成本最低的備份不需要購買另一個專用電路。
推薦架構
● 建立從資料中心到每個 VPC 的 AWS Site-to-Site VPN 連線。
● 終止相應虛擬專用閘道器上的每個 VPN。
● 使用BGP釋出和選擇備份路由。
● 在正常操作期間首選直接連線，並在需要時不使用 VPN。
設計理由
● 技術可行性：動態路由可以撤銷專線路徑並選擇可用的VPN路由。
● 需求匹配：該解決方案以比其他 Direct Connect 連線更低的成本新增了混合連線冗餘。
● 場景匹配：十個 VPC 已依賴於一條託管電路。
● 工程常識：將備份成本和效能與緊急使用相匹配，而不是自動複製完整的主容量。
應排除的替代方案
● 每個 VPC 的 MPLS 成本高昂且配置緩慢。
● 第二個 Direct Connect 提供更強的專用冗餘，但成本更高。
● 透過新購買的第二個 Direct Connect 的 VPN 仍需支付另一條線路的費用。
工作流：構建 VPN → 配置 BGP 優先順序 → 測試路由撤銷 → 驗證每個 VPC → 監控隧道狀態。
現代化桌面應用程式和 MySQL
託管現代化可以流式傳輸桌面應用程式、將 MySQL 遷移到 Aurora 以及跨可用區託管支援 Web 服務。
推薦架構
● 使用 Amazon AppStream 2.0 進行集中管理的桌面應用程式流。
● 將 MySQL 遷移到 Amazon Aurora。
● 在 ALB 後面的多可用區 Auto Scaling 組中執行 Web 或應用程式服務。
設計理由
● 技術可行性：AppStream 流式傳輸應用程式，無需完整的桌面管理； Aurora 相容 MySQL； ALB 和 Auto Scaling 提供彈性託管。
● 需求匹配：該設計減少了基礎設施運營，同時提高了規模和可用性。
● 場景匹配：使用者需要應用程式而不是完整的持久桌面。
● 工程常識：選擇滿足訪問要求的最窄管理終端使用者服務。
應排除的替代方案
● WorkSpaces 提供完整的桌面，並且在僅需要應用程式時可能會增加成本。
● 自我管理的 MySQL 保留備份和故障轉移工作。
● CloudFront 不會加速互動式桌面協議。
● Redshift 不是 OLTP MySQL 的替代品。
● ElastiCache 無法交付桌面應用程式，DynamoDB 轉換需要進行重大重新設計。
工作流：使用者啟動流 → AppStream 會話 → 應用程式到達 ALB 服務 → Aurora 儲存關係資料。
使用臨時 AWS 憑證進行社交登入
移動應用程式可以用 OIDC 社交身份令牌交換臨時 AWS 許可權。
推薦架構
● 使用支援的社交身份提供商對使用者進行身份驗證。
● 致電 STS AssumeRoleWithWebIdentity。
● 將身份對映到 S3 和 DynamoDB 範圍內的 IAM 角色。
● 使用移動 SDK 中的臨時憑證。
設計理由
● 技術可行性：STS 驗證 Web 身份令牌並返回短期角色憑據。
● 需求匹配：該應用程式無需嵌入長期金鑰即可訪問 AWS 資源。
● 場景匹配：社交提供商使用 OIDC 風格的網路身份聯合。
● 工程常識：將移動裝置視為永久機密的不受信任位置。
應排除的替代方案
● 即使提到 Cognito，長期訪問和金鑰仍然不安全。
● AssumeRoleWithSAML 針對企業 SAML 聯盟。
● IAM 使用者的通用 AssumeRole 不會直接驗證社交令牌。
● 分發一把共享金鑰會妨礙安全的使用者隔離。
工作流：社交登入 → OIDC 令牌 → STS 角色交換 → 臨時憑證 → 範圍 S3 或 DynamoDB 請求。
月末 MySQL 讀取擴充套件
可預測的讀取峰值最好透過託管資料庫操作和臨時只讀副本來處理。
推薦架構
● 將自我管理的 MySQL 從 EC2 遷移到 Amazon RDS for MySQL。
● 在月底之前新增只讀副本。
● 將報告查詢路由到副本。
● 峰值後刪除不必要的副本。
設計理由
● 技術可行性：RDS 管理備份和維護，而副本則解除安裝寫入器的讀取操作。
● 需求匹配：在可預測的視窗期間，效能會得到提高，操作風險也會降低。
● 場景匹配：瓶頸在於讀取量大的月末處理。
● 工程常識：擴充套件查詢路徑而不是重複更改儲存硬體。
應排除的替代方案
● 快照和切換 EBS 型別速度慢且風險大。
● Lambda 無法透明地調整正在執行的 EC2 資料庫的大小。
● 垂直縮放仍然有限。
● ALB 預熱與資料庫讀取無關。
● 對於每個繁重的 I/O 工作負載，gp2 不會自動變得更快。
工作流：遷移到 RDS → 在峰值之前新增副本 → 路由讀取 → 監控滯後 → 之後刪除副本。
使用 AWS MGN 進行持續 VMware 遷移
物理或VMware伺服器可以透過連續的塊級複製和受控切換遷移到EC2。
推薦架構
● 在每臺源伺服器上安裝 AWS Replication Agent。
● 使用 AWS Application Migration Service 暫存資源。
● 持續複製磁碟更改。
● 啟動測試例項、驗證並啟動切換。
設計理由
● 技術可行性：代理傳送塊級更改，MGN 將複製的伺服器轉換為 EC2 啟動資源。
● 需求匹配：測試和最終同步可減少停機時間。
● 場景匹配：現有虛擬機器必須在不重新設計應用程式的情況下進行遷移。
● 工程常識：測試用於生產切換的相同複製流。
應排除的替代方案
● CloudFormation 會重建基礎架構，但不會複製 VM 磁碟。
● Direct Connect 和 Service Catalog 不執行 VM 轉換。
● SAM 部署無伺服器應用程式。
● ECS 託管容器，而不是匯入的虛擬機器。
工作流：安裝代理 → 複製到暫存 → 測試啟動 → 修復 → 最終同步 → 切換 → 停用源。
使用 Secrets Manager 輪換資料庫密碼
資料庫密碼應儲存在專用的秘密服務中，在執行時檢索並引用，而不會出現在模板中。
推薦架構
● 將 RDS 主密碼儲存在 AWS Secrets Manager 中。
● 使用批准的 KMS 金鑰對其進行加密。
● 在支援的情況下配置託管輪換。
● 讓應用程式透過 IAM 角色在執行時檢索金鑰。
● 對 MasterUserPassword 使用 CloudFormation 動態引用。
設計理由
● 技術可行性：動態引用在配置期間解析秘密，而無需在模板中嵌入明文。
● 需求匹配：密碼受到集中保護、訪問控制且可輪換。
● 場景匹配：基礎設施部署和應用程式連線都需要相同的憑證生命週期。
● 工程常識：切勿將資料庫密碼複製到使用者資料、源儲存庫或輸出中返回的模板引數中。
應排除的替代方案
● 普通 CloudFormation 引數可以透過處理和部署工作流程公開值。
● 普通的 Ref 不提供秘密輪換。
● 硬編碼的應用程式配置在輪換後會變得陳舊。
● 沒有所需旋轉工作流程的引數儲存對於此要求來說不太直接。
工作流：建立秘密→使用動態引用部署RDS→應用程式檢索秘密→旋轉→應用程式重新整理連線。
NGINX和MySQL高效遷移
透過建立彈性 Web 層並使用託管資料庫遷移路徑，小型互動式 Web 應用程式可以遷移到 AWS。
推薦架構
● 在兩個可用區中啟動 NGINX EC2 例項。
● 透過 S3 暫存位置複製應用程式檔案。
● 使用 AWS Database Migration Service 遷移 MySQL 資料。
● 將 Web 伺服器放置在彈性負載均衡器後面。
● 為負載均衡器建立 Route 53 別名記錄。
設計理由
● 技術可行性：EC2 保留現有的 NGINX 應用程式，DMS 移動資料庫記錄，負載均衡器分配流量。
● 需求匹配：該設計無需對應用程式進行重大重寫即可提高可用性。
● 場景匹配：源由一臺 NGINX 伺服器和一個 MySQL 資料庫組成。
● 工程常識：首先重新託管應用程式層，並透過穩定的負載平衡端點管理流量。
應排除的替代方案
● 動態應用程式不能簡單地作為 S3 靜態網站執行。
● Application Discovery Service 會清點工作負載，但不會遷移 Web 伺服器。
● 私有託管區域不為公共使用者提供服務。
● 多可用區資料庫不僅僅位於一個可用區。
工作流：構建兩個Web節點→複製檔案→遷移資料庫→驗證→放置在負載均衡器後面→切換Route 53。
更安全的自動化部署
低停機時間交付流程應該測試程式碼、預覽基礎設施效果並保留快速回滾路徑。
推薦架構
● 使用 CodeBuild 執行自動化非生產測試。
● 在基礎設施更新之前建立 CloudFormation 更改集。
● 對應用程式使用 CodeDeploy 藍/綠部署。
● 僅在驗證後轉移流量並回滾失敗的警報。
設計理由
● 技術可行性：CodeBuild 執行測試，更改集顯示計劃的資源更改，藍色/綠色保持舊環境可用。
● 需求匹配：該工作流程減少了停機時間和部署風險。
● 場景匹配：應用程式和基礎設施的更改都是透過 CI/CD 發生的。
● 工程常識：語法驗證是必要的，但不能證明執行時行為。
應排除的替代方案
● 單獨的模板驗證並不能測試應用程式或預覽所有影響。
● 手動例項測試緩慢且不一致。
● 幫助程式指令碼和手動 QA 不提供自動流量切換和回滾。
● 就地生產更新增加了爆炸半徑。
工作流：提交 → CodeBuild 測試 → 變更集審查 → 部署綠色 → 驗證 → 轉移流量 → 保留或刪除藍色。
現代化基於磁帶的媒體目錄
面向檔案的媒體系統可以將存檔內容移至 S3 並新增託管面部分析，而無需替換其現有介面。
推薦架構
● 在本地部署 Storage Gateway 檔案閘道器。
● 讓媒體資產系統透過檔案共享複製磁帶提取的檔案。
● 將檔案儲存在 Amazon S3 中。
● 透過 Lambda 呼叫 Amazon Rekognition。
● 將生成的後設資料寫回現有目錄。
設計理由
● 技術可行性：檔案閘道器保留檔案訪問許可權，而 Rekognition 則分析支援的 S3 媒體。
● 需求匹配：該設計最大限度地減少了中斷和持續的基礎設施管理。
● 場景匹配：來源是歷史磁帶檔案，而不是實時流。
● 工程常識：在現有 MAM 系統已經理解的介面後面引入雲服務。
應排除的替代方案
● Kinesis Video Streams 針對實時影片攝取進行了最佳化。
● 當 Rekognition 已提供該功能時，定製 SageMaker 計算機視覺培訓會增加工作量。
● SFTP 和自我管理的 EC2 Vision 軟體可建立修補、擴充套件和恢復工作。
● 替換 MAM 工作流程擴大了範圍。
工作流：提取磁帶檔案→檔案閘道器→S3→Lambda→Rekognition→後設資料返回到目錄。
經濟高效的一次性 EMR 叢集
一次性分析叢集應保護控制和資料節點，同時僅將可中斷容量用於可重新啟動的工作。
推薦架構
● 在按需例項上執行 EMR 主節點和核心節點。
● 在 Spot 例項上執行任務節點。
● 將持久的輸入和輸出儲存在一次性任務節點之外。
設計理由
● 技術可行性：主節點和核心節點維護叢集控制和HDFS資料；任務節點執行可重複的計算。
● 需求匹配：Spot 可以降低成本，而不會導致關鍵叢集狀態中斷。
● 場景匹配：叢集執行一次，因此長期承諾效率低下。
● 工程常識：僅在可以重試丟失的工作的情況下才使用廉價的可中斷容量。
應排除的替代方案
● 預留例項需要不適合一次執行的承諾。
● 只保留master仍然浪費承諾成本。
● Spot 主節點或核心節點可能會終止叢集或丟失 HDFS 資料。
● 按需任務節點錯過了最佳節省成本的機會。
工作流：啟動穩定的 master 和 core → 新增 Spot 任務佇列 → 處理資料 → 持久輸出 → 終止叢集。
基礎設施即程式碼與全球 CDN
可重複的基礎設施部署和全域性內容加速是 CloudFormation 和 CloudFront 滿足的不同需求。
推薦架構
● 在 AWS CloudFormation 中定義網路、計算、安全和託管服務。
● 將模板儲存在版本控制中並透過受控管道進行部署。
● 使用 Amazon CloudFront 作為可快取內容的全域性 CDN。
設計理由
● 技術可行性：CloudFormation 一致地建立和更新 AWS 資源； CloudFront 在邊緣位置快取內容。
● 需求匹配：當使用者接收較低延遲的內容時，環境變得可重複。
● 場景匹配：該解決方案需要全面的基礎設施自動化，而不僅僅是應用程式部署。
● 工程常識：監控、部署和內容交付不應混淆。
應排除的替代方案
● CloudWatch 觀察系統，但既不是基礎設施即程式碼，也不是 CDN。
● Elastic Beanstalk 管理應用程式平臺，但並不直接對整個環境進行全面建模。
● 手動控制檯部署會產生偏差。
● CDN 不會取代基礎設施配置。
工作流：提交模板→驗證→部署CloudFormation堆疊→釋出內容→CloudFront全域性快取和交付。
跨可用區經濟高效的峰值容量
多可用區 Web 層應將可預測的基本容量與容錯峰值容量分開。
推薦架構
● 保持預留例項覆蓋率以實現穩態使用。
● 利用多元化現貨容量應對臨時高峰。
● 將 Auto Scaling 容量放置在可用區中。
● 讓擴充套件策略替代可用區或 Spot 中斷期間損失的容量。
設計理由
● 技術可行性：無狀態 Web 伺服器可以在不保留本地會話狀態的情況下被替換。
● 需求匹配：Spot 降低了峰值成本，而 Auto Scaling 支援快速容量恢復。
● 場景匹配：該應用程式已經跨越了三個可用區，並且在高峰期間達到了非常高的利用率。
● 工程常識：不依賴於一個 Spot 池；例項型別和容量池多樣化。
應排除的替代方案
● 固定預留和按需容量有效，但可能會過度配置，並且不保證自動替換。
● 預留例項是一種定價承諾，而不是特殊的 Auto Scaling 容量型別。
● 在沒有 Auto Scaling 的情況下混合使用 Spot 和 On-Demand 無法提供快速恢復。
工作流：衡量基線 → 透過承諾覆蓋基線 → 使峰值池多樣化 → 跨可用區擴充套件 → 監控中斷和利用率。
HPC 控制器的低延遲佈局
與叢集計算節點頻繁通訊的控制器應共享現有的叢集置放群組。
推薦流程
● 如果需要，停止控制器例項。
● 將其移至計算佇列的叢集置放組中。
● 重新啟動並測量延遲和吞吐量。
設計理由
● 技術可行性：叢集置放組使受支援的例項保持物理上靠近，以實現低延遲網路。
● 需求匹配：無需重建整個叢集即可改善控制器到節點的通訊。
● 場景匹配：計算節點已使用正確的放置組。
● 工程常識：更改異常元件而不是破壞每個健康節點。
應排除的替代方案
● 彈性 IP 不會提高內部網路效能。
● 分散放置有意分隔例項並增加距離。
● ENA 未按照建議的方式作為單獨的介面卡連線。
● 重建每個計算例項會造成不必要的停機。
工作流：停止控制器→修改佈局→啟動→驗證網路效能→恢復工作負載。
CloudFront 的國家/地區級內容限制
當報告檔案必須在特定國家/地區不可用時，請在內容交付層強制實施地理位置。
推薦架構
● 透過 Amazon CloudFront 分發報告檔案。
● 啟用 CloudFront 地理限制。
● 配置禁止國家/地區的拒絕列表。
● 限制源訪問，以便使用者無法繞過 CloudFront。
設計理由
● 技術可行性：CloudFront 會評估檢視者所在的國家/地區，並根據配置的地理策略阻止或允許傳送。
● 需求匹配：相同的分佈提供低延遲的全球交付和國家級限制。
● 場景匹配：受保護的資源是交付給全球使用者的報告檔案。
● 工程常識：在內容交付位置應用控制並防止直接來源訪問。
應排除的替代方案
● Route 53 地理位置選擇端點，但不是對單個報告檔案的直接拒絕控制。
● 地理位置鄰近路由根據位置和偏差轉移流量；它不會阻止國家。
● 網路 ACL 國家/地區阻止需要維護較大的 IP 範圍，並且僅適用於子網邊界。
● Elastic Beanstalk 本身不提供地理內容限制。
工作流：檢視者請求 → CloudFront 確定國家/地區 → 允許或拒絕 → 從受保護的源檢索允許的內容 → 快取在允許的使用者附近。
無伺服器通話錄音處理
通話錄音應從昂貴的主儲存轉移到持久物件儲存、自動轉錄和基於生命週期的存檔。
推薦架構
● 將錄音儲存在 Amazon S3 中。
● 當新記錄到達時觸發 Lambda。
● 將音訊提交到 Amazon Transcribe。
● 將成績單和後設資料儲存在 S3 中。
● 在合適的情況下從 S3 託管輕量級搜尋或檢索門戶。
● 透過生命週期規則將舊錄音轉移到 S3 Glacier。
設計理由
● 技術可行性：S3 事件驅動無伺服器處理，Transcribe 將語音轉換為文字，生命週期策略自動歸檔。
● 需求匹配：該設計降低了運營和儲存成本，同時使錄音可搜尋。
● 場景匹配：每次上傳的呼叫都會進行處理，不需要始終線上的伺服器。
● 工程常識：保持原件、派生抄本和存檔生命週期的不同。
應排除的替代方案
● EC2 轉錄工作人員增加了容量和修補工作。
● 與生命週期策略相比，手動歸檔作業速度較慢且可靠性較低。
● 將所有錄音儲存在高階主動儲存中會浪費成本。
● 關聯式資料庫不是大型音訊物件的正確主儲存。
工作流：上傳錄音 → Lambda 觸發器 → 轉錄作業 → 轉錄到 S3 → 門戶訪問 → 生命週期存檔。
不可變的補丁、頻繁的部署和共享資料
可擴充套件的 EC2 佇列應從修補的映像啟動，自動部署應用程式修訂版，並掛載大型共享資料，而不是在啟動期間下載資料。
推薦架構
● 使用 Systems Manager 自動化來修補和烘焙新的 AMI。
● 更新 Auto Scaling 組並替換舊例項。
● 使用 AWS CodeDeploy 部署應用程式修訂版。
● 將 500 GB 靜態資料集儲存在 Amazon EFS 上並在啟動時掛載。
設計理由
● 技術可行性：黃金 AMI 建立一致的作業系統狀態，CodeDeploy 支援頻繁釋出，並且 EFS 可立即供多個例項訪問。
● 需求匹配：例項可以快速擴充套件，部署可以每天進行多次，並且補丁可以在規定的期限內完成。
● 場景匹配：資料集是共享的和靜態的，而計算例項是可替換的。
● 工程常識：不要在每次橫向擴充套件事件期間下載 500 GB。
應排除的替代方案
● 每晚部署作業無法支援每天多個版本。
● 就地修補可能會導致混合艦隊。
● 等待新供應商 AMI 並不能保證在 48 小時內安裝補丁。
● 大量 S3 下載導致使用者資料延遲啟動。
工作流：修補映像 → 測試 → 更新啟動模板 → 滾動佇列 → 掛載 EFS → 使用 CodeDeploy 部署程式碼。
對受邀組織帳戶的管理訪問許可權
加入 AWS Organizations 可以集中管理和計費，但管理訪問許可權仍然需要每個成員賬戶中的可信角色。
推薦架構
● 從組織管理帳戶邀請現有帳戶。
● 確保每個成員帳戶都具有 OrganizationAccountAccessRole 或同等管理角色。
● 信託批准的管理賬戶委託人。
● 使用 STS 角色假設進行管理。
設計理由
● 技術可行性：組織處理會員資格； IAM 角色信任授予實際的跨賬戶許可權。
● 需求匹配：中央管理員可以管理受邀帳戶，而無需重複的長期使用者。
● 場景匹配：這些帳戶在加入組織之前就已存在。
● 工程常識：帳戶成員資格和帳戶授權是單獨的控制平面。
應排除的替代方案
● 僅會員資格並不授予管理權。
● 邀請來自管理帳戶。
● 控制塔註冊增加了治理，但不應假定自動授予不受限制的訪問許可權。
● 共享根憑據是不安全且不必要的。
工作流：管理帳戶傳送邀請→成員接受→管理員承擔受信任的角色→臨時憑據管理帳戶。
DNS 分配或託管負載平衡
固定公共伺服器組可以使用 DNS 級多值響應，但應用程式負載均衡器是更強大的託管設計。
推薦選項
● 使用 Route 53 多值路由和執行狀況檢查來返回多個執行狀況良好的伺服器 IP。
● 當託管請求分發可用時，首選具有 Route 53 別名的 ALB。
設計理由
● 技術可行性：多值響應分配客戶選擇； ALB 主動平衡健康目標之間的請求。
● 需求匹配：兩者都提高了可用性和分發，而 ALB 則減少了伺服器地址管理。
● 場景匹配：該應用程式有多個 Web 伺服器為一個域提供服務。
● 工程常識：DNS 不是一個完整的負載均衡器，因為客戶端快取答案並獨立選擇地址。
應排除的替代方案
● NAT 提供出站轉換，而不提供入站負載平衡。
● 非別名記錄不太適合 AWS 負載均衡器，並且無法支援所有頂級域情況。
● CloudFront 無法使用任意私有 EC2 IP 地址作為公共源。
● 一條靜態 A 記錄會留下一個伺服器故障點。
工作流：DNS 返回健康的 ALB 別名或多值地址 → 客戶端連線 → 健康控制刪除失敗的目標。
NoSQL 應用程式的快速多區域恢復
區域災難恢復設計應該重現基礎設施，複製每種資料型別，並自動進行流量故障轉移和故障恢復。
推薦架構
● 使用 CloudFormation StackSets 在兩個區域中部署匹配的 Auto Scaling Web 和應用程式層。
● 為靜態內容啟用 S3 跨區域複製。
● 使用 DynamoDB 全域性表進行多區域 NoSQL 資料複製。
● 配置具有執行狀況檢查的 Route 53 故障轉移路由。
設計理由
● 技術可行性：StackSets 標準化區域基礎設施，S3 CRR 複製物件，全域性表複製 DynamoDB 記錄。
● 需求匹配：準備好的輔助站點可實現快速恢復，而 Route 53 可自動執行流量移動和返回。
● 場景匹配：資料庫要求明確為 NoSQL，這使得 DynamoDB 全域性表成為直接適合的選擇。
● 工程常識：恢復速度取決於預先配置的基礎設施和持續複製的資料。
應排除的替代方案
● Aurora 是關係型的，與規定的 NoSQL 層不匹配。
● Service Catalog 不會直接重現此工作流程的完整區域堆疊。
● 手動 DNS 更改會降低恢復和故障恢復速度。
● 定期備份到 S3 會留下較大的資料間隙，需要在使用前進行恢復。
工作流：部署兩個區域 → 複製 S3 和 DynamoDB → 執行狀況檢查主區域 → 故障轉移到輔助區域 → 恢復後故障恢復。
提高遊戲效能的分層快取
緩慢的遊戲資源載入和重複的動態查詢需要兩個不同的快取層。
推薦架構
● 透過 Amazon CloudFront 交付靜態遊戲資產。
● 在 Amazon ElastiCache 中快取經常訪問的動態資料。
● 將持久源資料儲存在現有的權威儲存中。
設計理由
● 技術可行性：CloudFront 快取全球玩家附近的物件； ElastiCache 在應用程式架構內提供低延遲記憶體訪問。
● 需求匹配：靜態下載時間和重複後端讀取時間均有所改善。
● 場景匹配：遊戲檔案和動態應用程式資料具有不同的訪問模式。
● 工程常識：在最接近其使用者的層快取內容。
應排除的替代方案
● DynamoDB 是一個持久資料庫，而不是直接的記憶體快取替代品。
● 使用 ElastiCache 進行靜態全域性檔案傳輸缺乏邊緣分佈。
● 使用 CloudFront 作為私有快速變化的後端記錄的主快取會顛倒正確的服務角色。
● 選擇不受支援或不合適的 ElastiCache 引擎會使看似合理的設計變得不可行。
工作流：靜態請求 → CloudFront 邊緣 → 未命中的來源；動態請求 → 應用程式 → ElastiCache → 資料庫丟失。
將外部 HSM 金鑰材料匯入 KMS
客戶生成的 HSM 金鑰材料可以匯入到來源為外部的 KMS 金鑰中。
推薦架構
● 建立具有 EXTERNAL 來源的 KMS 金鑰。
● 匯入由批准的本地 HSM 生成的金鑰材料。
● 配置需要使用該金鑰的 SSE-KMS 的 S3 儲存桶策略。
● 監控金鑰材料的過期和重新匯入要求。
設計理由
● 技術可行性：KMS 外部源金鑰接受匯入的金鑰材料並可以加密 S3 物件。
● 需求匹配：組織保留對原始金鑰生成過程的控制。
● 場景匹配：必須使用而不是替換現有的 HSM 生成的材料。
● 工程常識：丟失匯入的金鑰材料可能會導致密文無法恢復，因此請安全儲存。
應排除的替代方案
● Direct Connect 不匯入加密金鑰。
● AWS_KMS 原始金鑰無法覆蓋其託管金鑰材料。
● CloudHSM 自定義金鑰儲存建立一個新的 AWS HSM 支援的系統，而不是根據請求匯入現有金鑰。
● SSE-S3不使用客戶匯入的金鑰。
工作流：在 HSM 中生成材料 → 建立外部源 KMS 金鑰 → 安全匯入 → 在 S3 策略中強制執行金鑰。
使用 X-Ray 進行 Canary Lambda 部署
Lambda 版本可以首先公開一小部分流量，並透過下游服務跟蹤請求。
推薦架構
● 使用 CodeDeploy 金絲雀流量轉移。
● 將 10% 路由到新的 Lambda 版本，然後在五分鐘後（如果執行正常）轉移剩餘的 90%。
● 對函式和支援的下游呼叫啟用 AWS X-Ray 主動跟蹤。
● 附加觸發回滾的警報。
設計理由
● 技術可行性：Lambda 別名在版本之間劃分流量； CodeDeploy 控制轉變； X-Ray 記錄請求段。
● 需求匹配：該版本限制了爆炸半徑並提供端到端診斷。
● 場景匹配：所需的推出明確是兩步金絲雀暴露。
● 工程常識：部署安全需要受控的流量和可觀察的成功標準。
應排除的替代方案
● EC2 式滾動部署不實現 Lambda 別名百分比。
● 一次性部署消除了逐步驗證。
● 線性移位使用重複的相等增量而不是所請求的金絲雀模式。
● AWS Config 記錄配置但不跟蹤請求。
工作流：釋出版本 → 別名傳送 10% → 監控警報和跟蹤 → 移動 90% 或回滾。
可靠的 S3 預簽名 URL
預簽名 URL 僅當由授權 AWS 身份建立並在過期前使用時才有效。
推薦控制
● 為門戶提供有效的 IAM 角色以及所請求的 S3 操作的許可權。
● 生成具有足夠長的過期時間以供使用者工作流程使用的 URL。
● 保持儲存桶、金鑰、方法和標頭與簽名的請求一致。
設計理由
● 技術可行性：簽名者的憑據和許可權授權臨時請求。
● 需求匹配：使用者無需收到永久 AWS 憑證即可上傳或下載。
● 場景匹配：失敗是間歇性的，表明存在過期或簽名身份問題。
● 工程常識：時間限制應該可以降低風險，而不會在正常轉移期間過期。
應排除的替代方案
● S3 版本控制本質上不會使所定址操作的現有 URL 失效。
● 開發人員控制檯許可權與門戶的執行時身份是分開的。
● 僅靠 ACL 無法彌補簽名者憑據的缺失。
● 在大型傳輸開始或完成之前，非常短的到期時間可能會失敗。
工作流：門戶角色簽署請求→使用者接收URL→S3驗證簽名和時間→操作成功或過期。
按月分割槽的部落格儲存和私人傳送
基於時間的部落格內容可以使用一個分割槽儲存桶、自動化生命週期規則和私有 CloudFront 源。
推薦架構
● 將條目儲存在基於月份的 S3 字首下。
● 透過字首或標籤應用生命週期策略。
● 使用一個 CloudFront 發行版實現可擴充套件的交付。
● 將儲存桶限制為 CloudFront 源身份或等效的私有源控制。
設計理由
● 技術可行性：S3 字首組織物件，生命週期規則轉換物件，CloudFront 快取交付。
● 需求匹配：該設計減少了儲存和分發管理。
● 場景匹配：部落格條目具有基於時間的保留和訪問模式。
● 工程常識：邏輯分割槽不需要單獨的儲存桶或分佈。
應排除的替代方案
● 兩個發行版重複配置，但沒有改進生命週期管理。
● 最小 TTL 為零會阻止有用的快取。
● 轉發不必要的查詢字串會造成快取碎片。
● 在兩個儲存桶中複製每個條目可以使儲存和管理加倍，而無需恢復。
工作流：在每月字首下發布 → CloudFront 私下檢索 → 邊緣快取 → 生命週期轉換舊字首。
在 OpsWorks 中修補 Linux 例項
OpsWorks Linux 例項可以透過本機依賴項更新或受控替換來接收當前包。
推薦做法
● 執行 OpsWorks Update Dependencies 命令以獲取當前軟體包更新。
● 替換例項，以便設定和生命週期配方在新容量上安裝當前包。
● 逐波修補並驗證應用程式執行狀況。
設計理由
● 技術可行性：OpsWorks 整合了包更新命令和例項生命週期配置。
● 需求匹配：Linux 伺服器接收更新時服務容量風險較低。
● 場景匹配：該應用程式已使用 OpsWorks 堆疊。
● 工程常識：替換提供了更乾淨的狀態，而就地更新可以解決緊急包裹。
應排除的替代方案
● CloudFormation 不是現有 OpsWorks 例項的本機依賴項更新機制。
● 該命令不是等效的 Windows 補丁工作流程。
● 刪除整個堆疊會造成不必要的破壞。
● AWS WAF 過濾請求並且無法安裝作業系統更新。
工作流：選擇 Wave → 更新依賴項或替換例項 → 驗證 → 繼續 → 檢視版本。
在 CloudFormation 堆疊刪除期間保留資料
基礎設施刪除應消除持續的計算成本，同時透過資源適當的刪除策略保留資料。
推薦配置
● 將 RDS 資源設定為 DeletionPolicy: Snapshot。
● 將 S3 儲存桶設定為 DeletionPolicy: Retain。
● 僅在驗證策略更改後才刪除堆疊。
設計理由
● 技術可行性：CloudFormation 在刪除資料庫之前建立最終的 RDS 快照，並將 S3 儲存桶保留在堆疊刪除之外。
● 需求匹配：資料庫計算費用停止，而資料庫備份、影象和參賽者資料仍然可用。
● 場景匹配：應用程式已完成，需要儲存而不是繼續操作。
● 工程常識：在建立重複的儲存工作流之前使用本機生命週期行為。
應排除的替代方案
● 不支援 Snapshot 作為 S3 儲存桶的刪除策略。
● RDS 上的 Retain 保留實時資料庫及其持續成本，而不是僅建立備份。
● S3 複製可以保留第二個副本，但它會不必要地增加另一個儲存桶、複製配置、傳輸和儲存成本。
工作流：更新模板→稽核變更→刪除堆疊→驗證RDS快照→驗證保留桶→單獨管理保留資源。
大檔案的託管加密儲存
需要完全託管儲存、KMS 加密和僅 HTTPS 訪問的大型檔案適合 Amazon S3。
推薦架構
● 將檔案儲存在 S3 中。
● 將 SSE-KMS 與經批准的客戶管理金鑰結合使用。
● 新增儲存桶策略，拒絕不使用安全傳輸的請求。
● 應用最小許可權 IAM 和金鑰策略。
設計理由
● 技術可行性：S3 支援大型物件、託管永續性、KMS 加密和基於策略的 HTTPS 實施。
● 需求匹配：該設計取消了伺服器和卷管理。
● 場景匹配：資料由檔案而不是資料庫項組成。
● 工程常識：加密需要訪問控制和傳輸策略來形成完整的保護鏈。
應排除的替代方案
● EC2 和 EBS 保留伺服器和卷操作。
● 當不需要持續的混合訪問時，遷移後不需要檔案閘道器。
● SSE-S3 缺乏客戶管理的 KMS 控制。
● DynamoDB 不適合大檔案，需要應用程式級拆分。
工作流：授權的 HTTPS PUT → S3 使用 KMS 金鑰 → 儲存加密物件 → 策略拒絕不安全的 GET 或 PUT。
更快的全域性上傳到 S3
遠離 S3 區域的使用者可以使用 S3 傳輸加速透過附近的 AWS 邊緣站點進行上傳。
推薦架構
● 在目標儲存桶上啟用傳輸加速。
● 更新上傳客戶端以使用 s3-accelerate 端點。
● 從主要使用者位置測試效能。
● 保留大物件的分段上傳。
設計理由
● 技術可行性：加速端點在 AWS 邊緣站點接收資料，並透過 AWS 全球網路將其傳送到儲存桶區域。
● 需求匹配：歐洲藝術家無需移動或複製水桶即可實現更快的傳輸。
● 場景匹配：延遲是由到當前 S3 區域的長距離網際網路路徑引起的。
● 工程常識：驗證加速優勢，因為效能和成本取決於源位置和網路條件。
應排除的替代方案
● CloudFront 主要是為內容交付而設計的，並不是這裡的直接通用上傳加速器。
● 建立 EC2 上傳代理會增加擴充套件、故障和資料處理工作。
● S3 跨區域複製會在上傳後複製物件，並且不會加速初始傳輸。
● 更改儲存類別不會改善上傳網路延遲。
工作流：客戶端選擇加速端點→最近的邊緣接收上傳→AWS骨幹網傳輸物件→S3儲存它。
圍繞重疊的對等 VPC CIDR 進行路由
VPC 對等互連是非傳遞性的，使用靜態路由，並在路由重疊時應用最長字首匹配。
推薦路由
● 在VPC A中，將主機路由（例如10.0.0.77/32）新增到VPC B對等連線。
● 將更廣泛的 10.0.0.0/16 路由新增到 VPC C 對等連線。
● 在VPC B和VPC C中配置互通路由。
● 確保安全組和網路 ACL 允許流量。
設計理由
● 技術可行性：/32 路由比 /16 更具體，因此所需 VPC B 主機的流量遵循正確的對等連線。
● 需求匹配：儘管地址範圍重疊，但該設計仍到達兩個目的地。
● 場景匹配：在一個重疊的 VPC 中只需要特定的資料庫地址。
● 工程常識：對於有限的例外，優先考慮路由特異性，但避免在新設計中重疊 CIDR。
應排除的替代方案
● 對等互連不會動態交換路由。
● 網路 ACL 無法修復錯誤的路由決策。
● 到兩個對等點的廣泛重疊路由不明確，並且無法提供到兩個 CIDR 空間的完全連線。
工作流：目的地查詢→最長字首匹配→選擇對等連線→相互路由→安全評估。
大規模基於位置的移動警報
數百萬接收時間敏感的本地優惠的使用者需要持久的緩衝、可擴充套件的處理、快速查詢和移動推送交付。
推薦架構
● Amazon SQS 中的緩衝區工作。
● 根據佇列深度擴充套件 EC2 工作執行緒。
● 在 DynamoDB 中儲存商品和位置對映。
● 透過 Amazon SNS 移動推送傳送警報。
設計理由
● 技術可行性：SQS 吸收突發，工作人員非同步處理，DynamoDB 提供可擴充套件的查詢，SNS 提供平臺推送通知。
● 需求匹配：管道可以在所需的短時間間隔內傳送警報，而不會丟失突發流量。
● 場景匹配：超過200萬移動使用者可能會觸發不規則的通知需求。
● 工程常識：將報價選擇與通知傳遞分開，並將待處理的工作保留在佇列中。
應排除的替代方案
● AWS Device Farm 測試應用程式；它不提供生產推送通知。
● AWS AppSync 提供託管 GraphQL 和訂閱，但不是直接批次移動推送服務。
● 直接同步處理在突發需求時缺乏緩衝。
● Pinpoint 可以支援活動，但 SQS、worker、DynamoDB 和 SNS 鏈更直接地適合規定的事務工作流程。
工作流：位置事件 → SQS → 工作人員選擇 DynamoDB 產品 → SNS 推送 → 移動裝置。
使用 CloudTrail 進行稽核員訪問
稽核員需要權威的 API 歷史記錄以及專用的只讀身份來檢查日誌和資源。
推薦架構
● 跨所需區域和全球服務啟用 AWS CloudTrail。
● 將日誌傳送到受保護的 S3 儲存桶。
● 建立專用的只讀稽核員身份。
● 僅授予對所需日誌和資源後設資料的訪問許可權。
設計理由
● 技術可行性：CloudTrail 記錄賬戶活動，而 IAM 控制證據訪問。
● 需求匹配：稽核員可以在不改變生產資源的情況下檢查事件。
● 場景匹配：該請求是外部合規審查。
● 工程常識：通知不是證據；保留完整的日誌和受控的搜尋訪問。
應排除的替代方案
● 沒有 CloudTrail 的只讀角色會忽略所需的活動歷史記錄。
● SNS 傳送通知不是稽核記錄。
● 拒絕稽核員日誌訪問會阻止證據審查。
● AWS 不會獨立為第三方建立客戶賬戶許可權。
工作流：API 操作 → CloudTrail 事件 → 受保護的 S3 日誌 → 稽核員身份驗證 → 只讀審查。
將閘道器塊儲存恢復到 EBS
Storage Gateway 卷快照可以成為 EC2 恢復環境的本機 AWS 塊儲存。
推薦流程
● 選擇儲存閘道器快照。
● 將其恢復為 Amazon EBS 卷。
● 在所需的可用區中建立卷。
● 將其連線到 EC2 應用程式伺服器。
● 掛載並驗證檔案系統。
設計理由
● 技術可行性：閘道器快照與 EBS 快照和卷工作流程整合。
● 需求匹配：應用程式接收可連線的塊儲存，而不依賴於本地閘道器。
● 場景匹配：原始工作負載需要 iSCSI 樣式的塊卷。
● 工程常識：在考慮以後的現代化之前，在災難恢復期間保留儲存介面。
應排除的替代方案
● 直接連線到本地閘道器可保留混合依賴性。
● S3是物件儲存，不能直接替換已掛載的塊裝置。
● Storage Gateway 不會將卷直接轉換為 EFS。
● 手動複製檔案會增加恢復時間並可能會丟失後設資料。
工作流：閘道器快照 → EBS 卷 → EC2 附件 → 檔案系統檢查 → 應用程式啟動。
使用 CloudFormation 滾動 AMI 更新
Auto Scaling 組可以逐漸替換例項，同時保持最低的健康服務容量。
推薦配置
● 將啟動模板或啟動配置更新為新的 AMI。
● 在 CloudFormation 更新策略中定義 AutoScalingRollingUpdate。
● 配置批次大小、暫停時間和服務中的最小例項數。
● 在繼續每批之前監視健康狀況。
設計理由
● 技術可行性：CloudFormation 協調 Auto Scaling 組中的受控例項替換。
● 需求匹配：佇列接收新的 AMI，而無需同時更換每個例項。
● 場景匹配：該應用程式已使用 Auto Scaling，並且需要較短的停機時間。
● 工程常識：執行狀況檢查必須驗證應用程式準備情況，而不僅僅是例項啟動。
應排除的替代方案
● 更改集預覽更改，但不控制佇列替換。
● 完整的藍/綠堆疊可以工作，但會增加重複的基礎設施和 DNS 交換。
● DeletionPolicy 不定義滾動替換行為。
● 就地 AMI 更改無法修改已執行的例項。
工作流：更新模板→替換一批→等待執行狀況→繼續批次→完成或回滾。
適用於 Windows 和 Linux 的統一系統遙測
作業系統記憶體、磁碟和日誌資料需要客戶機內收集器，因為標準 EC2 指標不會公開每個請求的測量。
推薦架構
● 跨 Windows 和 Linux 例項安裝和配置統一的 Amazon CloudWatch 代理。
● 將系統日誌傳送到 CloudWatch Logs。
● 釋出來賓指標，例如記憶體和磁碟利用率。
● 使用 CloudWatch Logs Insights 分析聚合記錄。
● 將所需結果匯出到 Amazon S3。
設計理由
● 技術可行性：一個受支援的代理可以處理兩個作業系統並集中遙測。
● 需求匹配：該解決方案涵蓋 200 多個例項，只需最少的定製開發。
● 場景匹配：每月效能分析需要整個機隊範圍內的可搜尋資料，而不是單個主機檢查。
● 工程常識：集中標準化採集配置和查詢。
應排除的替代方案
● SSM 代理管理例項，但不是完整日誌和指標集的主要收集器。
● 流量映象捕獲網路資料包，而不是記憶體或磁碟使用情況。
● 自定義守護程序和 CDK 部署增加了不必要的維護。
● Amazon Inspector 評估漏洞，而儀表板不會取代日誌查詢。
工作流：定義代理配置 → 部署 → 驗證攝取 → 使用 Logs Insights 查詢 → 保留或匯出結果。
使用 NACL 阻止惡意源網路
網路 ACL 可以顯式拒絕來自子網邊界的已知攻擊 CIDR 範圍的流量。
推薦控制
● 為惡意源 CIDR 新增編號拒絕規則。
● 將規則放置在更廣泛的允許條目之前。
● 將其應用到受影響的公共子網。
● 保留所需的返回路徑規則，因為 NACL 是無狀態的。
設計理由
● 技術可行性：NACL 支援顯式允許和拒絕規則。
● 需求匹配：來自已識別來源的流量在到達例項之前會被阻止。
● 場景匹配：該門戶必須對其他使用者保持公開。
● 工程常識：將此視為立即遏制，而不是完整的 DDoS 保護。
應排除的替代方案
● 將整個門戶移動到私有子網會消除公共可用性，而無需其他入口設計。
● 路由表不按源 IP 進行過濾。
● 安全組僅允許，無法建立顯式拒絕。
● 主機防火牆需要按例項進行管理。
工作流：資料包進入子網 → NACL 評估最低匹配規則 → 敵對 CIDR 被拒絕 → 其他使用者繼續。
對私有 S3 內容的限時訪問
私人內容可以透過簽名暫時共享，而直接的匿名來源訪問仍然被阻止。
推薦模式
● 使用 S3 預簽名 URL 直接、限時訪問特定物件。
● 或者使用 CloudFront 簽名 URL 來獲取邊緣交付的私有內容。
● 對於 CloudFront，使用源訪問身份和限制性儲存桶策略保護 S3 源。
● 刪除公共 S3 許可權。
設計理由
● 技術可行性：簽名對過期和授權資源進行編碼； S3 或 CloudFront 在交付前對其進行驗證。
● 需求匹配：只有獲得批准的客戶端才能獲得臨時訪問許可權，而無需永久 AWS 憑證。
● 場景匹配：內容儲存在 S3 中，並可以透過 CloudFront 分發。
● 工程常識：在使用者實際訪問的交付層選擇簽名者。
應排除的替代方案
● 公共讀取 ACL 無法限制對一個客戶端的訪問。
● 共享 IAM 訪問金鑰會產生長期的憑證風險。
● OAI 本身保護來源，但不授權個人檢視者。
● 網路 ACL 不提供物件級時間限制。
工作流：應用程式授權客戶端 → 生成 S3 或 CloudFront 簽名 → 到期前的客戶端請求 → 服務驗證 → 交付物件。
使用 DynamoDB TTL 保留大量資料
具有固定 120 天保留期的高攝取工作負載需要可擴充套件寫入、低延遲讀取和自動專案過期。
推薦架構
● 使用均勻分佈的分割槽鍵將記錄儲存在 Amazon DynamoDB 中。
● 為每個專案新增過期時間戳屬性。
● 在該屬性上啟用 DynamoDB 生存時間。
● 根據流量可預測性選擇按需或預置容量。
設計理由
● 技術可行性：DynamoDB 水平擴充套件，TTL 會自動刪除過期專案，無需應用程式刪除作業。
● 需求匹配：該設計支援持久攝取、響應式訪問和低操作保留管理。
● 場景匹配：記錄具有統一的生命週期，不需要關係連線。
● 工程常識：在專案建立時對生命週期進行編碼，而不是稍後掃描表中的舊資料。
應排除的替代方案
● 關聯式資料庫為簡單的大容量鍵值流新增連線和擴充套件約束。
● 計劃刪除作業會消耗容量並需要檢查點、重試和維護。
● 無限期保留過期資料會增加儲存成本並違反保留意圖。
● 當活動需求包括低延遲記錄訪問時，歸檔物件儲存不太合適。
工作流：攝取專案 → 分配分割槽鍵和到期時間 → 提供低延遲查詢 → TTL 在 120 天后刪除資料。
現貨船隊成本最低的峰值容量
可預測的基線容量仍然可以透過預留來滿足，同時多樣化的 Spot 可以處理臨時的容錯峰值。
推薦架構
● 保持預留定價以滿足穩定的應用需求。
● 跨可用區啟動多元化的 Spot 佇列，以應對高峰流量。
● 使用 Auto Scaling 和中斷感知替換。
設計理由
● 技術可行性：多個 Spot 池可減少對單一容量源的依賴。
● 需求匹配：該設計提供最低成本的峰值容量。
● 場景匹配：工作負載可以替代中斷的峰值例項。
● 工程常識：切勿將預留例項視為可啟動的臨時容量。
應排除的替代方案
● 預留例項是計費承諾，而不是 Auto Scaling 佇列型別。
● Spot 加 On-Demand 提高了可靠性，但成本高於最低成本要求。
● 預留加按需可保留更高的峰值成本。
● One Spot 池會增加中斷和容量風險。
工作流：基線執行→峰值報警→多元化Spot上線→流量分配→中斷容量替換→機隊規模縮減。
使用 AWS MGN 進行連續虛擬機器複製
以最短的停機時間進行伺服器遷移需要連續的塊級複製，而不是重複的完整映像匯入。
推薦架構
● 在每臺源伺服器上安裝 AWS Application Migration Service 複製代理。
● 持續複製根資料卷和附加資料卷。
● 從複製狀態啟動測試例項。
● 驗證後執行最終切換。
設計理由
● 技術可行性：AWS MGN 複製完整的伺服器磁碟並啟動等效的 EC2 例項。
● 需求匹配：持續同步可保持切換狀態最新並減少停機時間。
● 場景匹配：TB 級根卷和資料卷屬於一個協調的遷移工作流程。
● 工程常識：測試將用於生產切換的相同複製流。
應排除的替代方案
● VM Import/Export 對於映像匯入很有用，但重複的完整匯入對於持續同步來說效率低下。
● 發現服務和遷移中心支援規劃和跟蹤，而不是塊複製。
● 當 MGN 可以複製資料卷快照時，單獨匯入資料卷快照會增加協調、附件和一致性風險。
工作流：安裝代理→複製→測試啟動→修復→最終同步→切換→驗證應用程式和資料。
在 ALB 上啟用可用區
應用程式負載均衡器僅將流量路由到為該負載均衡器啟用的可用區中的目標。
推薦流程
● 檢視哪些子網和可用區與 ALB 關聯。
● 從缺少的可用區新增合適的子網。
● 驗證目標例項是否已註冊且執行狀況良好。
● 確認路由表、安全組和網路 ACL 允許執行狀況檢查和應用程式路徑。
設計理由
● 技術可行性：關聯 AZ 為 ALB 提供了該區域的節點和網路路徑。
● 需求匹配：所有預期可用區中執行狀況良好的 Auto Scaling 例項都可以接收流量。
● 場景匹配：例項啟動成功，但有一個可用區未收到負載均衡請求。
● 工程常識：Auto Scaling 放置和負載均衡器區域啟用是單獨的配置。
應排除的替代方案
● 當 ALB 無法路由到可用區時，手動新增更多例項沒有幫助。
● Auto Scaling 不會自動關聯新的 ALB 子網。
● 跨區域負載均衡不會使禁用的可用區可供負載均衡器使用。
● 該問題無法透過更改 AWS 區域來解決。
工作流：ASG啟動目標→目標暫存器→ALB檢查啟用AZ→健康檢查成功→流量開始。
成本最佳化的內部容器和文件平臺
低成本的內部平臺應該使用可中斷的計算，並使用安全、承諾的資料庫定價來滿足穩定的需求，以及生命週期管理的物件儲存。
推薦架構
● 在 EC2 Spot 容量上執行 ECS 容器例項。
● 啟用 ECS Spot 例項耗盡。
● 對穩定的 Amazon RDS 資料庫層使用預留定價。
● 將文件儲存在加密的 Amazon S3 中。
● 三個月後將文件轉移到 S3 Glacier，並僅在所需的五年保留期後過期。
設計理由
● 技術可行性：ECS 在 Spot 中斷之前耗盡任務，而 S3 生命週期策略則自動執行儲存轉換。
● 需求匹配：該設計最大限度地降低了計算和儲存成本，同時將文件儲存五年。
● 場景匹配：檔案僅在前三個月內被頻繁訪問。
● 工程常識：將儲存類別與訪問期限保持一致，並避免自定義歸檔 cron 作業。
應排除的替代方案
● 對於可預測的長期執行使用，按需 ECS 和 RDS 成本更高。
● EFS 加上自定義複製指令碼新增了檔案系統和歸檔操作。
● EKS 在沒有明確需求的情況下新增了 Kubernetes 管理。
● RDS 無法在 Spot 例項上執行。
● 主機本地容器卷不是持久的文件儲存。
工作流：將活動文件儲存在 S3 中→作為授權→生命週期到 Glacier→保留五年→按策略過期。
使用 STS 進行範圍內的移動 S3 訪問
移動應用程式應在對使用者進行身份驗證後接收臨時憑據。
推薦架構
● 在應用程式身份系統中對使用者進行身份驗證。
● 將身份對映到 IAM 角色。
● 使用 STS 頒發臨時的、有範圍的憑證。
● 限制對使用者授權的 S3 物件的訪問。
設計理由
● 技術可行性：移動 SDK 可以使用可更新的 STS 會話簽署 S3 請求。
● 需求匹配：使用者無需永久嵌入 AWS 金鑰即可訪問其資料。
● 場景匹配：直接移動物件訪問需要每個使用者的隔離。
● 工程常識：將分散式客戶端視為不受信任的秘密儲存環境。
應排除的替代方案
● 長期 IAM 使用者金鑰可以提取並重複使用。
● STS 憑證是臨時的，不得將其視為永久嵌入的機密。
● 在 DynamoDB 中儲存使用者資訊本身並不會將身份對映到安全的 AWS 角色。
● 一份共享憑證無法隔離使用者。
工作流：使用者登入 → 角色對映 → STS 會話 → 範圍 S3 請求 → 憑證重新整理或過期。
基於佇列的媒體處理
可變的、長時間執行的媒體作業需要持久的緩衝和可擴充套件的工作人員，而不是同步處理。
推薦架構
● 在 Amazon SQS 中放置作業。
● 根據佇列深度擴充套件 EC2 工作執行緒。
● 將源媒體和處理後的媒體儲存在 Amazon S3 中。
● 將可見性超時設定為超出預期處理時間。
● 使用重試和死信佇列。
設計理由
● 技術可行性：SQS 將上傳與處理分離，Auto Scaling 跟蹤積壓，S3 提供持久的共享儲存。
● 需求匹配：該平臺以低成本處理可變工作，而不會導致失業。
● 場景匹配：媒體處理可能會超出較短的無伺服器執行視窗。
● 工程常識：工人是一次性的；訊息和媒體必須能夠承受工人的失敗。
應排除的替代方案
● Lambda 可能不適合長時間執行的作業。
● EBS 不是用於擴充套件佇列的共享持久輸出儲存。
● Amazon MQ 新增了此處不需要的代理相容性和管理。
● 將 MQ 與 SQS 觸發的設計混合使用在內部是不一致的。
工作流：上傳→SQS訊息→工人索賠→從S3處理→寫入結果→刪除訊息。
CloudFront WordPress 的可信 HTTPS
自定義 WordPress 域應將檢視者重定向到 HTTPS，併為兩個交付層使用受信任的 ACM 證書。
推薦架構
● 在 CloudFront 中配置 HTTP 到 HTTPS 重定向。
● 使用所需區域中 CloudFront 自定義域的 ACM 證書。
● 在其區域中的源終端節點上使用受信任的 ACM 證書。
● 強制執行從 CloudFront 到源的 HTTPS。
設計理由
● 技術可行性：ACM 與 CloudFront 和 AWS 負載均衡源整合。
● 需求匹配：檢視者和源流量透過託管續訂接收可信加密。
● 場景匹配：該網站使用自定義 WordPress 域。
● 工程常識：證書名稱必須與檢視器和源主機名匹配。
應排除的替代方案
● 自簽名證書不受公共瀏覽器或 CloudFront 源的信任。
● 第三方證書可以使用，但增加了購買和續訂操作。
● 預設 CloudFront 證書僅涵蓋 cloudfront.net，而不涵蓋自定義域。
工作流：HTTP 檢視器 → 重定向 → CloudFront TLS → HTTPS 源請求 → WordPress 響應。
React 應用程式的無伺服器交付
靜態單頁應用程式不需要始終線上的 Web 伺服器群。
推薦架構
● 在 Amazon S3 網站儲存桶中託管 React 構建。
● 透過受支援的 Web 身份提供商對使用者進行身份驗證。
● 使用 STS 將身份令牌交換為臨時 AWS 憑證。
● 授予對所需 S3 物件和 DynamoDB 專案的小範圍訪問許可權。
設計理由
● 技術可行性：瀏覽器可以從 S3 載入靜態 React 資產，並使用臨時憑證進行授權的 AWS API 呼叫。
● 需求匹配：該設計無需伺服器即可擴充套件，並將固定成本降至最低。
● 場景匹配：使用量沒有出現大幅增長，標題很小，並且 DynamoDB 已經與資料模式匹配。
● 工程常識：使用臨時憑證而不是嵌入式金鑰或自定義令牌服務。
應排除的替代方案
● NGINX、EC2、負載均衡器和 Auto Scaling 會增加靜態內容的成本。
● 單個令牌自動售貨機成為瓶頸和故障點。
● 自定義令牌服務加上 EC2 Web 佇列可複製託管功能。
工作流：登入 → 接收身份令牌 → 承擔網路身份角色 → 接收臨時憑證 → 訪問批准的資源。
使用 Redis 減少混合資料庫負載
動態門戶可以透過快取會話和頻繁重複的查詢結果來減少本地資料庫壓力。
推薦架構
● 部署適用於 Redis 的 Amazon ElastiCache。
● 快取會話狀態和合適的查詢結果。
● 配置複製以實現快取可用性和讀取擴充套件。
● 根據可接受的陳舊程度設定過期時間。
設計理由
● 技術可行性：Redis 提供低延遲記憶體讀取和適合會話的資料結構。
● 需求匹配：透過混合鏈路或到達資料庫的請求更少。
● 場景匹配：門戶和評論是動態的，因此完全靜態託管是不可行的。
● 工程常識：僅快取應用程式在驅逐後可以安全重建的資料。
應排除的替代方案
● S3靜態託管無法替代動態門戶和評論處理。
● 遷移到 Aurora 可能可行，但這是一個比快取更大的資料庫專案。
● 對於相容的資料庫移動來說，SCT 是不必要的。
● OpenSearch 是一個搜尋引擎，而不是評論和會話的事務儲存。
工作流：應用程式讀取快取→命中立即返回→錯過查詢資料庫→使用TTL快取的結果。
使用 EC2 角色輪換 S3 憑證
EC2 應用程式應從附加的 IAM 角色獲取短期 S3 憑證。
推薦架構
● 建立受 EC2 信任的 IAM 角色。
● 僅授予所需的儲存桶列表和物件上傳操作。
● 透過例項配置檔案附加角色。
● 讓 AWS 開發工具包從例項後設資料服務檢索憑證。
設計理由
● 技術可行性：該平臺自動提供和輪換臨時憑證。
● 需求匹配：該應用程式列出並上傳物件而不儲存機密。
● 場景匹配：工作負載在 EC2 上執行並呼叫 S3 API。
● 工程常識：授予所需的確切儲存桶級別和物件級別操作。
應排除的替代方案
● EC2 上的靜態訪問金鑰會造成長期暴露。
● 僅列表許可權無法上傳物件。
● 使用者資料不是安全的輪換憑證提供者。
● IAM 使用者無法附加到 EC2 例項，並且後設資料不會公開使用者憑證。
工作流：例項以角色啟動 → SDK 獲取臨時會話 → 簽署 S3 請求 → 憑證在過期前輪換。
為什麼 SCP 不限制服務相關角色
服務控制策略限制成員賬戶中委託人可用的許可權，但 AWS 服務相關角色不受 SCP 限制。
關鍵行為
● 服務相關角色由 AWS 服務預定義。
● 其信任關係允許該服務執行所需的操作。
● SCP 否認不限制透過服務相關角色執行的操作。
設計理由
● 技術可行性：即使賬戶委託人面臨 SCP 拒絕，ECS 也可以透過其服務相關角色繼續服務管理的操作。
● 需求匹配：此行為解釋了為什麼預期的限制不會影響觀察到的操作。
● 場景匹配：ECS 叢集使用為 AWS 服務整合建立的服務相關角色。
● 工程常識：在診斷策略評估之前，首先確定哪個委託人提出了請求。
應排除的錯誤解釋
● 資源不在組織的管轄範圍之外運作。
● 父允許不能覆蓋適用 SCP 路徑中其他位置的顯式拒絕。
● 預設 FullAWSAccess SCP 不會取消顯式拒絕。
● 編輯預設 SCP 不是服務相關角色行為的原因。
排查工作流：檢視 CloudTrail 主體 → 識別服務相關角色 → 對映適用的 SCP → 將服務操作與使用者或角色操作分開。
資源終止的業務單元控制
多帳戶結構應該使每個業務部門對自己的資源負責，而不向其他部門授予破壞性訪問許可權。
推薦架構
● 使用 AWS Organizations 將賬戶組織到業務部門 OU 中。
● 為批准的單位管理員建立跨賬戶 IAM 角色。
● 僅授予該單位擁有的資源和帳戶的資源級終止許可權。
● 使用信任策略來限制誰可以擔任每個角色。
設計理由
● 技術可行性：IAM 角色和資源許可權授權目標賬戶內的操作。
● 需求匹配：每個單位管理自己的資源，而帳戶邊界限制爆炸半徑。
● 場景匹配：所有權自然與單獨的帳戶或 OU 保持一致。
● 工程常識：使用 SCP 作為實際操作訪問的最大護欄和 IAM 角色。
應排除的替代方案
● SCP 不授予資源訪問許可權，也不能替換目標賬戶 IAM 許可權。
● 廣泛的組織範圍管理員角色違反了業務部門隔離。
● 服務相關角色允許 AWS 服務執行；他們不是人類的管理角色。
● 資源標籤本身並不授權終止，除非 IAM 條件明確使用它們。
工作流：管理員登入 → 承擔單位角色 → IAM 評估資源範圍 → 發生允許的終止 → CloudTrail 記錄操作。
僅允許透過 CloudFront 訪問 S3
私有 S3 源應信任 CloudFront，而不是匿名檢視者或發行版的公共 DNS 名稱。
推薦架構
● 建立 CloudFront 源訪問身份。
● 配置分配以使用 OAI 作為 S3 源。
● 更新 S3 儲存桶策略以僅向 OAI 授予物件讀取許可權。
● 刪除公共讀取 ACL 和公共儲存桶許可權。
設計理由
● 技術可行性：CloudFront 使用 OAI 身份對源請求進行簽名，S3 在儲存桶策略中評估該身份。
● 需求匹配：使用者透過 CloudFront 接收內容，但直接 S3 URL 失敗。
● 場景匹配：該儲存桶是一個源，而不是公共網站端點。
● 工程常識：授權發出源請求的服務身份。
應排除的替代方案
● CloudFront 分配 ID 不是用於 OAI 授權的 S3 委託人。
● 為 CloudFront 建立一般 IAM 使用者會引入不必要的手動憑據。
● 檢視者簽名的 URL 控制對 CloudFront 的訪問，但不會自動限制直接 S3 訪問。
● 公共儲存桶訪問破壞了源保護。
工作流：檢視器 → CloudFront 授權 → OAI 簽名的源請求 → S3 儲存桶策略 → 物件響應。
保護電子商務信任鏈
安全的公共訪問需要保護 DNS 解析和 HTTPS 路徑。
推薦架構
● 使用 Route 53 託管並註冊域。
● 為公共託管區域啟用 DNSSEC 簽名併發布所需的委派記錄。
● 從 AWS Certificate Manager 請求受信任的公共證書。
● 在應用程式負載均衡器處終止 HTTPS。
● 使用 SNI 配置 CloudFront 並將 HTTP 檢視器重定向到 HTTPS。
設計理由
● 技術可行性：DNSSEC 驗證簽名的 DNS 響應； ACM和ALB建立可信TLS； CloudFront 強制執行安全的檢視器連線。
● 需求匹配：該設計減少了 DNS 欺騙、HTTPS 欺騙和降級暴露。
● 場景匹配：它使用現有的 Fargate、ALB、CloudFront 和 Route 53 架構。
● 工程常識：使用本機託管控制元件而不是操作自定義 DNS 伺服器或證書程序。
應排除的替代方案
● 自託管 BIND 增加了修補、可用性和金鑰管理工作。
● 外部 DNSSEC 可以工作，但無需引入其他提供商。
● 匯入的證書可以工作，但當 ACM 可以頒發和續訂它們時，會新增續訂和部署操作。
工作流：簽署 DNS → 驗證委派 → 頒發證書 → 配置 ALB HTTPS → 強制執行 CloudFront HTTPS。
用於混合勞動力訪問的 SAML 聯合
員工可以透過基於標準的 SAML 聯合使用企業身份訪問 AWS。
推薦架構
● 為 SAML 2.0 配置企業身份提供商。
● 在 AWS 中建立相應的 SAML 提供商和 IAM 角色。
● 將使用者或組對映到批准的角色。
● 透過 AWS 聯合和 STS 終端節點交換臨時會話的 SAML 斷言。
設計理由
● 技術可行性：AWS 在頒發臨時憑證之前會驗證已簽名的斷言和角色對映。
● 需求匹配：使用者保留公司身份驗證並避免單獨的長期 IAM 密碼。
● 場景匹配：該公司運營著具有現有企業身份源的混合環境。
● 工程常識：在 IdP 處集中進行身份驗證，並將 AWS 授權保留在 IAM 角色中。
應排除的替代方案
● 建立 IAM 使用者會重複密碼生命週期和登出。
● Web 身份聯合針對的是消費者 OIDC 提供商，而不是此勞動力 SAML 場景。
● 如果沒有代理或聯合層，STS 無法單獨接受 LDAP。
● VPN 等網路連線不提供身份聯合。
工作流：使用者向 IdP 進行身份驗證 → 接收 SAML 斷言 → 選擇對映角色 → AWS 驗證斷言 → 臨時控制檯或 API 會話。
將 Kafka 事件移至 AWS
混合 Kafka 管道需要可靠的網路連線和對 AWS 流服務的受控攝取。
推薦架構
● 建立 AWS Direct Connect 以實現可預測的混合傳輸。
● 執行讀取本地 Kafka 主題的 EC2 使用者。
● 將使用的記錄釋出到 Amazon Kinesis 以供 AWS 處理。
● 僅將 API Gateway WebSocket API 與 Lambda 結合用於需要它們的面向客戶端的實時互動。
設計理由
● 技術可行性：Kafka 消費者保留源協議，Direct Connect 提供容量，Kinesis 支援可擴充套件的 AWS 消費者。
● 需求匹配：當事件可供 AWS 工作負載使用時，現有 Kafka 仍然可用。
● 場景匹配：該設計連線了本地流媒體和基於雲的實時應用程式。
● 工程常識：將後端流攝取與瀏覽器或移動 WebSocket 傳輸分開。
應排除的替代方案
● API Gateway 並不是 Kafka 代理的直接替代品。
● 如果沒有支援的連線和事件源設計，Lambda 無法連續輪詢任意 Kafka 端點。
● S3 批次傳輸失去實時行為。
● 僅 VPN 可能無法滿足所需的持續頻寬和可預測性。
工作流：Kafka 主題 → 透過 Direct Connect 的 EC2 消費者 → Kinesis 流 → 處理器 → 可選的 Lambda 和 WebSocket 更新。
具有例項配置檔案的 CloudFormation EC2 角色
CloudFormation 透過例項配置檔案將 IAM 角色附加到 EC2。
推薦架構
● 定義 EC2 信任的 IAM 角色。
● 將 DynamoDB 許可權附加到角色。
● 建立包含角色的 AWS::IAM::InstanceProfile。
● 引用 EC2 啟動配置中的例項配置檔案。
設計理由
● 技術可行性：EC2 透過附加的例項配置檔案接收臨時角色憑證。
● 需求匹配：應用程式無需長期金鑰即可訪問 DynamoDB。
● 場景匹配：基礎設施透過 CloudFormation 進行部署。
● 工程常識：切勿將秘密訪問金鑰作為堆疊引數或使用者資料傳遞。
應排除的替代方案
● 使用者訪問金鑰可能會透過部署工作流程洩漏。
● CloudFormation 不應建立 IAM 使用者金鑰並將其分發給例項。
● AWS::IAM::InstanceRoleName 不是所描述的有效 EC2 附加機制。
● 沒有例項配置檔案的角色不會附加到 EC2。
工作流：堆疊建立角色 → 例項配置檔案包含角色 → EC2 啟動 → SDK 檢索臨時憑證。
跨 AWS 賬戶的中央私有 DNS
共享服務賬戶可以擁有私有 DNS，而其他賬戶中的應用程式 VPC 則解析相同的內部名稱。
推薦架構
● 在共享服務帳戶中建立私有託管區域。
● 為已批准的應用程式 VPC 授權跨賬戶關聯。
● 將每個 VPC 與中央私有託管區域關聯。
● 集中維護記錄並啟用 VPC DNS 支援。
設計理由
● 技術可行性：Route 53 私有託管區域支援與其他 AWS 賬戶擁有的 VPC 關聯。
● 需求匹配：DNS 管理保持集中化，無需複製區域或執行自定義解析器。
● 場景匹配：多個帳戶需要一致的內部服務發現。
● 工程常識：對通用名稱使用一種事實來源，並僅委託關聯權。
應排除的替代方案
● 在每個帳戶中重新建立相同的私人區域可能會導致記錄不一致。
● 僅 VPC 對等互連不共享託管區域關聯。
● 公共託管區域公開內部命名，並且不提供僅限私有的解析。
● 自我管理的 DNS 伺服器新增了修補、可用性、轉發和擴充套件工作。
工作流：建立中心區→授權VPC→工作負載賬戶關聯→釋出記錄→測試解析→審計關聯。
減少 RDS 故障轉移時間
快速資料庫恢復需要有彈性的資料庫目標和應用程式連線管理。
推薦架構
● 使用 RDS Proxy 池連線並將應用程式路由到健康目標。
● 當需要更快的副本故障轉移時，遷移到 Aurora MySQL。
● 跨可用區部署 Aurora 副本。
● 測試客戶端重試行為。
設計理由
● 技術可行性：RDS Proxy 減少了連線流失，而 Aurora 副本提供了升級目標。
● 需求匹配：應用程式在寫入器發生故障後恢復得更快。
● 場景匹配：目標故障轉移低於標準 DNS 和重新連線行為。
● 工程常識：資料庫升級和客戶端重新連線都會導致中斷時間。
應排除的替代方案
● 最佳化寫入、最佳化讀取和快取可提高效能，而不是故障轉移。
● 標準只讀副本不提供自動寫入器故障轉移。
● Redis 在發生故障後不會建立可寫的關聯式資料庫。
● 較大的例項不會縮短故障轉移時間。
工作流：編寫器失敗 → Aurora 提升副本 → 代理路由池連線 → 應用程式重試 → 服務恢復。
CodeCommit 中的即時憑證掃描
推送程式碼時應檢測暴露的 IAM 訪問金鑰，然後立即包含。
推薦架構
● 配置 CodeCommit 推送事件以呼叫 AWS Lambda。
● 掃描新提交以獲取 IAM 訪問金鑰模式。
● 找到憑據後通知開發人員和安全團隊。
● 禁用公開的 IAM 金鑰並需要受控替換。
設計理由
● 技術可行性：CodeCommit 事件提供及時的呼叫，Lambda 可以檢查提交的內容並呼叫 IAM API。
● 需求匹配：事件驅動掃描的響應速度比日常檢查更快，並限制了曝光視窗。
● 場景匹配：安全問題源於原始碼提交。
● 工程常識：在生成或分發替換憑據之前包含洩露的憑據。
應排除的替代方案
● Amazon Macie 發現 S3 中的敏感資料，而不是 CodeCommit 儲存庫中的敏感資料。
● 每日 EC2 和 Systems Manager 掃描會延遲且操作量更大。
● 旋轉金鑰而不立即禁用暴露的金鑰會帶來主動風險。
● KMS儲存加密金鑰；它不是用於替換 IAM 憑證的儲存庫。
工作流：開發者推送→事件→Lambda掃描→查詢→禁用金鑰→通知所有者→從歷史記錄中刪除秘密→安全地釋出替換。
經濟高效的區域災難恢復工件
恢復可以透過持續複製資料庫並將重建工件複製到備份區域來避免熱備成本。
推薦架構
● 維護跨區域 Aurora 副本。
● 將 Web 和應用程式 AMI 或快照複製到恢復區域。
● 儲存重建無狀態層所需的模板和配置。
● 在災難期間提升副本並啟動計算。
設計理由
● 技術可行性：Aurora 複製可保持資料最新，而區域映像可實現快速伺服器重建。
● 需求匹配：該設計降低了穩定的計算成本，同時保留了實際恢復能力。
● 場景匹配：無狀態層可以重建；資料庫需要持續複製。
● 工程常識：恢復工件必須已存在於目標區域中。
應排除的替代方案
● AWS Backup 並不只是將 RDS 和 EBS 備份放入客戶 S3 儲存桶中，如所述。
● 恆定的五分鐘 Aurora 快照不是本機區域複製方法。
● 僅快照恢復會增加 RTO。
● 熱備速度更快，但成本高於要求。
工作流：複製 Aurora → 複製映象 → 宣佈災難 → 升級副本 → 啟動層 → 驗證 → 切換流量。
最小許可權跨賬戶 S3 和 KMS
跨賬戶訪問KMS加密物件需要金鑰、角色和儲存桶的授權。
推薦控制
● 將特定管理帳戶審閱者角色新增到 KMS 金鑰策略以進行解密。
● 授予審閱者角色身份許可權以進行 S3 讀取和 KMS 解密。
● 在 S3 儲存桶策略中允許審閱者角色或管理帳戶。
設計理由
● 技術可行性：S3 和 KMS 評估單獨的許可權鏈。
● 需求匹配：只有指定的審閱者才能讀取和解密物件。
● 場景匹配：物件由一個帳戶擁有並由另一個帳戶檢視。
● 工程常識：在每項政策中使用最窄的原則。
應排除的替代方案
● 信任營銷帳戶會導致錯誤的一方。
● 授予整個管理帳戶解密許可權比所需的範圍更廣泛。
● 完整的 S3 許可權超出了只讀需求。
● IAM 解密許可權無法覆蓋不信任該角色的 KMS 金鑰策略。
工作流：稽核者承擔角色 → S3 儲存桶授權讀取 → KMS 金鑰授權解密 → 返回物件。
將證書控制與應用程式操作分離
應用程式團隊可以管理 EC2 工作負載，而網路安全保留對生產 TLS 證書的獨家控制。
推薦架構
● 在 AWS Certificate Manager 中儲存和管理證書。
● 透過 IAM 策略將 ACM 證書操作限制為網路安全團隊。
● 終止彈性負載均衡器上的 SSL 或 TLS。
● 將證書材料保留在應用程式 EC2 例項之外。
● 讓 DevOps 僅管理其所需的應用程式和計算許可權。
設計理由
● 技術可行性：負載均衡器與 ACM 整合，無需將私鑰分發給伺服器。
● 需求匹配：當門戶提供 HTTPS 時，職責保持分離。
● 場景匹配：DevOps 擁有計算操作，網路安全擁有 X.509 證書生命週期。
● 工程常識：在服務和許可權邊界強制分離，而不是透過非正式程式。
應排除的替代方案
● 在 S3 中儲存證書會建立檢索和金鑰公開路徑。
● 在 EC2 上安裝證書使應用程式管理員可以訪問私有材料。
● SCP 是廣泛的組織護欄，並不是細粒度團隊證書訪問的常規工具。
● AWS Config 可以檢測更改，但不會授予或拒絕證書使用。
工作流：網路安全管理 ACM 證書 → 負載均衡器終止 TLS → DevOps 管理無需證書訪問的後端目標。
使用 AWS RAM 在組織範圍內共享
AWS Resource Access Manager 透過可信訪問與 AWS Organizations 整合，避免自定義跨賬戶自動化。
推薦架構
● 使用 enable-sharing-with-aws-organization 啟用與 AWS Organizations 的資源共享。
● 允許 AWS RAM 建立和使用其服務相關角色。
● 為組織帳戶或 OU 複製已建立的資源共享配置。
設計理由
● 技術可行性：可信訪問允許 RAM 使用 AWS 託管的整合跨組織帳戶進行操作。
● 需求匹配：與逐個帳戶的角色編排相比，本機機制的持續管理量較低。
● 場景匹配：任務是組織資源共享，而不是作業系統自動化。
● 工程常識：當託管服務整合已經實現了所需的信任關係時，首選託管服務整合。
應排除的替代方案
● 服務相關角色信任策略是服務控制的，不是正常的自定義點。
● 通用跨賬戶訪問不會啟用 RAM 和組織整合。
● SSM 代理、工作虛擬機器和自動化文件不參與 RAM 共享。
工作流：啟用可信訪問→驗證服務相關角色→定義資源共享→選擇主體→驗證訪問→稽核更改。
網路控制和配置歷史記錄
連線實施和資源更改歷史記錄是不同的控制，應使用不同的 AWS 服務。
推薦架構
● 將安全組用於有狀態例項級允許規則。
● 將網路 ACL 用於無狀態子網級允許和拒絕規則。
● 啟用 AWS Config 記錄資源配置和歷史更改。
● 需要合規性評估時，新增配置規則。
設計理由
● 技術可行性：安全組和 NACL 評估流量，而 Config 記錄支援的資源如何隨時間變化。
● 需求匹配：該設計提供受控的 EC2 通訊和可審計的安全配置歷史記錄。
● 場景匹配：調查需要當前的連線策略和以前的配置狀態。
● 工程常識：流量過濾器不會自動提供歷史治理證據。
應排除的替代方案
● CloudTrail 記錄 API 呼叫，但不是 Config 提供的完整規範化配置時間線。
● VPC 流日誌顯示接受和拒絕的流量，而不是完整的規則歷史記錄。
● Systems Manager 管理例項，但不會取代 VPC 網路控制。
● 路由表選擇路徑，不提供埠級策略。
工作流：資料包→路由→NACL→安全組→例項；配置更改 → AWS Config 歷史記錄和合規性。
控制預留例項折扣共享
預留例項共享是一項由 AWS Organizations 管理賬戶控制的賬單分配功能。
推薦流程
● 將業務部門保留在組織內部。
● 透過合併賬單首選項禁用相關成員帳戶或帳戶範圍的 RI 折扣共享。
● 在計劃的工作負載開始之前驗證如何應用折扣。
設計理由
● 技術可行性：管理賬戶控制是否在關聯賬戶之間共享符合條件的 RI 折扣。
● 需求匹配：採購業務部門保留預期的計費優勢。
● 場景匹配：無需更改工作負載、IAM 或賬戶所有權。
● 工程常識：透過計費設定而不是重組治理來解決狹隘的成本分配問題。
應排除的替代方案
● RI 折扣並非不可避免地共享；偏好可以改變。
● 會員帳戶沒有特殊的“私人 RI”設定。
● 從組織中刪除該帳戶會擾亂整合的計費、策略和集中管理。
運維說明：預留例項影響計費效益，而不是例項放置或技術能力。容量規劃和擴充套件仍然必須分開設計。
工作流：審查所有權 → 更改共享偏好 → 建立有效覆蓋範圍模型 → 監控計費分配。
緩衝線上考試提交
同時提交高峰需要持久排隊，而靜態考試資產則單獨處理。
推薦架構
● 將考試提交放入 SQS。
● 用受控的消費者來處理它們。
● 將影象和圖表儲存在 S3 中。
● 透過 CloudFront 交付靜態資產。
設計理由
● 技術可行性：SQS 吸收突發寫入，而 S3 和 CloudFront 則擴充套件只讀考試內容。
● 需求匹配：保留提交資料，無需過度配置固定寫入目標。
● 場景匹配：數千名候選人同時提交。
● 工程常識：靜態內容交付和寫入處理需要不同的擴充套件機制。
應排除的替代方案
● 固定的 10,000 WCU 可能過高或過低。
● CloudFront Functions 不託管影象。
● 100% 的利用率目標沒有留下任何空間。
● 較低的最大容量仍然會抑制突發。
● 遷移到 RDS 是一次重大的重新設計，只讀副本無助於寫入。
工作流：候選人從 CloudFront 載入資產 → 提交到佇列 → 消費者安全地保留結果。
發現 PII 並檢查 S3 訪問
敏感資料發現和物件訪問調查需要不同的服務。
推薦架構
● 使用 Amazon Macie 發現 S3 中的 PII 並對其進行分類。
● 為相關儲存桶啟用 CloudTrail 資料事件。
● 檢視最近的 GetObject 活動以及執行該活動的身份。
設計理由
● 技術可行性：Macie 分析物件內容和後設資料； CloudTrail 資料事件記錄物件級 API 活動。
● 需求匹配：團隊瞭解敏感資料存在的位置以及訪問者。
● 場景匹配：受保護的資訊儲存在S3中。
● 工程常識：分類並不能證明訪問，訪問日誌也不會自動識別 PII。
應排除的替代方案
● GuardDuty 檢測威脅，但不會對 S3 物件內的 PII 進行分類。
● Inspector 會掃描計算工作負載，但無法在儲存桶上安裝代理。
● Athena 查詢已知資料，但不會自動發現所有 PII。
● CloudWatch 不會獨立記錄 S3 物件 GET 呼叫。
工作流：Macie 掃描儲存桶 → 結果識別敏感物件 → CloudTrail 資料事件揭示最近的訪問 → 調查主體。
使用 SWF 進行長時間執行的人工工作流程
人工任務和批處理活動需要持久的工作流狀態、重試、歷史記錄和長期協調。
推薦架構
● 在 Amazon Simple Workflow Service 中對工作流程進行建模。
● 使用活動工作人員執行自動化任務。
● 將 Mechanical Turk HIT 建立和結果表示為工作流活動。
● 單獨儲存持久的業務輸出。
設計理由
● 技術可行性：SWF 保留工作流歷史記錄並協調長時間執行的活動和重試。
● 需求匹配：人類反應和批次進度仍然可追蹤。
● 場景匹配：Mechanical Turk 任務可能會花費不可預測的時間。
● 工程常識：不要將長時間執行的工作流狀態保留在計算記憶體中。
應排除的替代方案
● RDS 輪詢和 Lambda 工作執行緒需要自定義編排。
● AWS Config 是一項合規性服務。
● Amazon MQ 傳輸訊息，但不管理工作流程歷史記錄和人工任務狀態。
● 簡單的佇列並不能表達完整的流程。
工作流：啟動批處理 → 建立 HIT 活動 → 持久等待 → 收集結果 → 重試失敗 → 完成批處理。
流式基因組分析
連續的基因組資料需要流式攝取、可擴充套件處理和用於分析查詢的倉庫。
推薦架構
● 使用 Amazon Kinesis Data Streams 提取記錄。
● 使用流消費者進行近實時處理。
● 根據需要使用 Amazon EMR 進行大規模轉型。
● 將整理的分析結果載入到 Amazon Redshift 中。
設計理由
● 技術可行性：Kinesis 處理連續記錄，EMR 處理大型資料集，Redshift 支援分析 SQL。
● 需求匹配：該管道支援及時分析和持久的倉庫報告。
● 場景匹配：基因組測量持續到達，而不是偶爾發出 API 請求。
● 工程常識：將攝取與繁重的分析分開，這樣處理延遲就不會阻礙生產者。
應排除的替代方案
● API Gateway 和 SQS 新增了用於連續流式傳輸的間接訊息工作流程。
● Kinesis 不會簡單地透過新增 SQS 來分析現有 S3 物件。
● Firehose 提供資料，但不是活動 Kinesis 客戶端描述的完整處理鏈。
● QuickSight 可將結果視覺化，但不會取代倉庫處理。
工作流：資料生產者 → Kinesis → 消費者或 EMR → Redshift → 分析查詢。
近實時事件搜尋和儀表板
半結構化 JSON 事件需要可擴充套件的攝取、轉換、索引和儀表板視覺化。
推薦架構
● 使用 Kinesis Data Firehose 緩衝和傳送記錄。
● 需要時使用 Lambda 轉換事件。
● 在 Amazon OpenSearch Service 中對資料進行索引和視覺化。
設計理由
● 技術可行性：Firehose 管理交付，Lambda 重塑記錄，OpenSearch 提供可搜尋索引和儀表板。
● 需求匹配：該管道支援動態模式和近實時操作檢視。
● 場景匹配：工作負載是事件搜尋，而不是關係事務或圖遍歷。
● 工程常識：攝取服務應該緩衝臨時目標減速。
應排除的替代方案
● Aurora PostgreSQL 仍然是此事件模式的關係寫入瓶頸。
● QuickSight 對於操作近乎實時的事件儀表板來說不太直接。
● Neptune 是一個圖形資料庫。
● Kinesis Data Streams 和 Lambda 單獨省略了持久的可搜尋儲存和視覺化。
工作流：事件 → Firehose → Lambda 轉換 → OpenSearch 索引 → 儀表板查詢。
使用 AWS MGN 遷移物理伺服器
物理伺服器可以透過持續複製、測試和受控切換遷移到 EC2。
推薦架構
● 在每臺源伺服器上安裝 AWS Replication Agent。
● 配置 AWS Application Migration Service 暫存資源。
● 連續複製塊級更改。
● 啟動測試、修復並啟動切換。
設計理由
● 技術可行性：MGN 將複製的伺服器磁碟轉變為可啟動的 EC2 啟動資源。
● 需求匹配：測試和最終同步可減少遷移停機時間。
● 場景匹配：完整的物理伺服器工作負載必須移動，而不僅僅是檔案。
● 工程常識：在最終切換之前驗證網路、啟動和應用程式依賴性。
應排除的替代方案
● Application Discovery Service 會清點伺服器但不會遷移它們。
● DataSync 移動檔案並且不建立可啟動伺服器映像。
● Outposts 不提供這種複製到 AMI 的工作流程。
● 手動重建會造成配置漂移。
工作流：安裝代理→複製→啟動測試→驗證→最終同步→切換→停用源。
透過 URL 限制 EC2 出口
安全組和網路 ACL 過濾地址和埠，而不是完整的包儲存庫 URL。
推薦架構
● 部署帶有已批准更新 URL 允許列表的轉發代理。
● 透過代理路由 EC2 出站 Web 請求。
● 根據需要從工作負載子網中刪除直接預設 Internet 路由。
● 記錄代理請求並阻止每個未明確批准的目的地。
設計理由
● 技術可行性：應用層代理可以在根據策略轉發 HTTPS 或 HTTP 流量之前檢查主機名和 URL。
● 需求匹配：例項可以檢索已批准的軟體更新，而其他出站目的地仍然不可用。
● 場景匹配：該策略基於目標 URL，而不僅僅是基於 IP 或埠。
● 工程常識：在包含正在評估的資訊的協議層實施控制。
應排除的替代方案
● 安全組是僅允許的，不能按 URL 進行過濾。
● 網路 ACL 需要 IP 範圍，並且無法檢查 HTTP 路徑。
● NAT 閘道器提供出口轉換，但不提供目標 URL 策略。
● DNS 控制本身並不能阻止直接 IP 訪問或檢查 URL 路徑。
工作流：EC2 請求 → 代理 → URL 策略 → 批准的儲存庫 → 記錄的響應；被拒絕的目的地在代理處停止。
擴充套件大型且不斷增長的 MySQL 工作負載
持續增長的 16 TiB 資料庫和 24×7 應用程式需要託管儲存增長、資料庫可用性和彈性應用程式層。
推薦架構
● 在應用程式負載均衡器後面跨可用區的 EC2 Auto Scaling 組中執行應用程式。
● 透過預留定價涵蓋可預測的應用程式容量，並使用彈性容量來實現增長。
● 將 MySQL 遷移到 Amazon Aurora。
● 在另一個可用區中新增 Aurora 副本以實現可用性和讀取擴充套件。
設計理由
● 技術可行性：Aurora 提供分散式託管儲存、自動增長、副本和託管故障轉移。
● 需求匹配：該設計支援持續的資料集擴充套件，並且比自管理 MySQL 的運營工作量更低。
● 場景匹配：Ruby on Rails 應用程式仍然基於伺服器，並且可以水平擴充套件。
● 工程常識：選擇具有增長空間的資料庫，而不是重複擴充套件邏輯卷。
應排除的替代方案
● Lambda@Edge 並不是 Rails 處理層的一般替代品。
● 自我管理的源副本 MySQL 需要故障轉移、備份和卷工程。
● 手動 RDS 儲存會增加運營工作並減少增長空間。
● 預留例項可以降低成本，但其本身並不提供資料庫高可用性。
工作流：擴充套件應用程式層→遷移資料→驗證Aurora→新增副本→切換→監控儲存和查詢負載。
消除 NAT 例項下載超時
當 NAT 例項超時併傳送 TCP FIN 時，長補丁下載可能會失敗。
推薦架構
● 將 NAT 例項替換為 NAT 閘道器。
● 將 NAT 閘道器放置在具有彈性 IP 的公有子網中。
● 更新私有子網預設路由。
● 監視閘道器連線、錯誤和吞吐量。
設計理由
● 技術可行性：NAT 閘道器提供適合出站包下載的託管擴充套件和連線處理。
● 需求匹配：補丁下載變得更加可靠，無需維護 NAT 伺服器。
● 場景匹配：Internet 連線已存在，但 NAT 例項中斷了長流量。
● 工程常識：修復失敗的出口元件，而不是修復不相關的放置或 VPN 設定。
應排除的替代方案
● 工作 NAT 出口已經暗示了網際網路閘道器。
● 歸置組影響東西向 EC2 延遲，而不影響 Internet 補丁下載。
● 虛擬專用閘道器服務於 VPN 或 Direct Connect，而不是公共儲存庫。
● 增加 NAT 例項大小可以保留超時和管理風險。
工作流：私有例項 → 路由到 NAT 閘道器 → 網際網路閘道器 → 儲存庫 → 長下載透過 NAT 返回。
定期 AMI 漏洞評估
經批准的 AMI 管道應自動執行重複掃描、批准狀態和更換決策。
推薦架構
● 使用 Amazon Inspector 評估模板掃描目標 EC2 例項中的 CVE。
● 將批准的 AMI 識別符號儲存在 Systems Manager Parameter Store 中。
● 使用 EventBridge 啟動重複工作流程。
● 使用 Lambda 進行審批邏輯，使用 Systems Manager Automation 進行影象或佇列操作。
設計理由
● 技術可行性：Inspector 執行漏洞評估，而其他服務協調排程和修復。
● 需求匹配：該過程定期識別易受攻擊的影象並維護權威批准的列表。
● 場景匹配：該組織需要自動 CVE 掃描，而不僅僅是啟動稽核。
● 工程常識：單獨的檢測、批准決策和修復執行。
應排除的替代方案
● CloudTrail 記錄啟動但不掃描包中的 CVE。
● AWS Config 記錄合規性，但不是詳細的漏洞掃描程式。
● SSM 代理本身不執行評估。
● 手動稽核無法滿足重複的自動化要求。
工作流：EventBridge 計劃 → Inspector 掃描 → Lambda 評估結果 → 更新批准的引數 → SSM 自動化修復。
將源限制為 CloudFront
CloudFront 應該是動態 ALB 內容和靜態 S3 物件的唯一公共路徑。
推薦架構
● 配置 CloudFront 以將秘密自定義標頭新增到 ALB 源請求。
● 將 AWS WAF 連線到 ALB 並拒絕缺少標頭的請求。
● 為 S3 源建立源訪問身份。
● 更新 S3 儲存桶策略以允許從 OAI 進行只讀。
設計理由
● 技術可行性：自定義標頭檢查可區分 CloudFront 源請求，而 OAI 將請求籤名為私有 S3 內容。
● 需求匹配：在不更改公共 CloudFront 終端節點的情況下，直接 ALB 和 S3 訪問將被阻止。
● 場景匹配：一種發行版提供來自不同來源的動態和靜態路徑。
● 工程常識：使用該源型別支援的控制元件來保護每個源。
應排除的替代方案
● 與 OAI 的儲存桶策略相比，單獨的 S3 ACL 提供的控制更弱且集中度更低。
● 網路 ACL 無法可靠地允許將 CloudFront 源地址更改為應用程式身份。
● 僅附加到 CloudFront 的 WAF 會過濾檢視器，但不能證明 ALB 請求來自 CloudFront。
● Route 53 不阻止直接源訪問。
工作流：檢視器 → CloudFront → 自定義標頭 ALB 路徑或 OAI 簽名的 S3 路徑。
使用客戶端 VPN 進行私人員工訪問
個人員工可以透過經過身份驗證的 AWS 客戶端 VPN 連線訪問私有應用程式。
推薦架構
● 將應用程式伺服器保留在私有子網中。
● 使用證書或批准的身份驗證建立 AWS 客戶端 VPN 終端節點。
● 授權員工網路和應用程式路線。
● 應用安全組來限制可訪問的服務。
設計理由
● 技術可行性：客戶端 VPN 提供從單個裝置到 VPC 的加密遠端訪問。
● 需求匹配：該應用程式不公開，授權員工可以透過網際網路進行連線。
● 場景匹配：使用者是單個遠端員工，而不是整個分支機構網路。
● 工程常識：私有子網放置和使用者身份驗證解決了不同層的訪問控制。
應排除的替代方案
● Direct Connect 對於臨時個人訪問來說成本高昂。
● 站點到站點 VPN 連線網路，而不是漫遊使用者。
● 公共子網不必要地暴露伺服器。
● 單獨的公共負載均衡器不會限制員工的訪問。
工作流：員工身份驗證→加密客戶端VPN隧道→授權路由→應用安全組→私有伺服器。
使用 IAM 角色進行跨賬戶管理
合併計費不會授予成員帳戶管理訪問許可權。訪問許可權必須明確委派。
推薦架構
● 將管理員 IAM 身份保留在管理賬戶中。
● 在開發和測試賬戶中建立管理 IAM 角色。
● 配置每個角色的信任策略以允許批准的管理帳戶委託人代入該策略。
● 在每個目標帳戶中附加所需的管理許可權。
設計理由
● 技術可行性：當受信任的管理員擔任目標賬戶角色時，AWS STS 會頒發臨時憑證。
● 需求匹配：管理員使用一個家庭身份即可獲得受控訪問，而無需重複 IAM 使用者。
● 場景匹配：這些帳戶相互關聯以進行計費，但仍保持獨立的安全邊界。
● 工程常識：定義資源所在的許可權，並僅信任需要它們的中央身份。
應排除的替代方案
● 合併賬單更改付款聚合，而不是 IAM 授權。
● 僅在管理賬戶中建立的角色無法自動管理目標賬戶資源。
● 在每個賬戶中複製長期 IAM 使用者會增加憑證和登出工作。
● 資源策略本身不提供一般帳戶管理。
工作流：集中登入 → 請求 AssumeRole → 目標信任策略評估 → 接收臨時憑證 → 管理目標帳戶。
具有快取卷的可擴充套件混合塊儲存
需要 iSCSI 塊介面的應用程式可以使用小型本地快取，同時將資料集持久儲存在 AWS 中。
推薦架構
● 在快取卷模式下部署 AWS Storage Gateway Volume Gateway。
● 將 iSCSI 塊卷提供給本地伺服器。
● 將頻繁訪問的塊保留在本地快取儲存中。
● 透過託管閘道器服務將主卷資料儲存在 Amazon S3 中。
● 使用快照進行恢復和AWS端恢復。
設計理由
● 技術可行性：快取卷保留塊訪問，同時減少所需的本地儲存量。
● 需求匹配：該設計可擴充套件非常大的資料集並在本地維護頻繁的資料。
● 場景匹配：現有應用程式需要塊儲存而不是物件 API。
● 工程常識：保留應用程式所需的介面，同時將持久容量轉移到雲端儲存。
應排除的替代方案
● 儲存卷需要完整的主資料集保留在本地。
● 直接 S3 訪問是基於物件的，並且不提供 iSCSI 塊裝置。
● S3 Glacier 是歸檔物件儲存，無法安裝為活動塊卷。
● 檔案閘道器提供檔案協議，而不是所需的塊介面。
工作流：應用程式 I/O → iSCSI 卷 → 本地快取 → 閘道器管理的 S3 支援 → 需要時的快照。
保護高度可用的 Web 應用程式
生產 Web 應用程式需要彈性入口、私有管理、資料庫故障轉移、邊緣加速和 Web 過濾。
推薦架構
● 將 ALB 與 EC2 Auto Scaling 組結合使用。
● 透過 Systems Manager 會話管理器管理例項。
● 使用 RDS 多可用區。
● 新增 CloudFront 和 AWS WAF。
設計理由
● 技術可行性：ALB 和 Auto Scaling 分配流量，Session Manager 刪除入站 SSH，RDS 提供備用故障轉移，CloudFront 加上 WAF 改進交付和保護。
● 需求匹配：該設計透過託管服務解決可用性和安全性問題。
● 場景匹配：該工作負載是面向網際網路的 EC2 應用程式。
● 工程常識：安全管理不應引入另一個公共伺服器。
應排除的替代方案
● 直接 SSH 保留金鑰和埠暴露。
● 單可用區 RDS 仍然是資料庫故障點。
● 堡壘可以工作，但與會話管理器相比增加了操作。
● Shield Standard 本身並不提供完整的網頁過濾架構。
工作流：使用者 → CloudFront 和 WAF → ALB → EC2；管理員→會話管理器；資料 → 多可用區 RDS。
重新構建容器化應用程式平臺
低變化遷移保留了應用程式的現有邊界，同時用託管服務取代了自我管理的基礎設施。
推薦架構
● 將經過測試的 OpenJDK 容器映像儲存在 Amazon ECR 中。
● 在 Amazon ECS 上執行容器。
● 使用 AWS Database Migration Service 將 MySQL 遷移到 Amazon RDS。
設計理由
● 技術可行性：ECS 執行 Docker 工作負載，RDS 支援 MySQL，DMS 在有限中斷的情況下移動關係資料。
● 需求匹配：OpenJDK 取消了商業 Java 許可，同時託管計算和資料庫服務減少了操作。
● 場景匹配：該應用程式已經使用容器和 MySQL，因此平臺重構保留了這兩種模式。
● 工程常識：一次對一層進行現代化改造，而不是一起改變計算和資料模型。
應排除的替代方案
● EC2 重新託管可以工作，但保留伺服器和資料庫管理。
● 使用 DynamoDB 替換 MySQL 會更改關係行為和應用程式程式碼。
● 將容器轉換為 Lambda 是一種重構，而不是最小更改遷移。
工作流：構建 OpenJDK 映象 → 測試 → 推送到 ECR → 部署到 ECS → 使用 DMS 複製 MySQL → 驗證 → 切換。
託管對話式聯絡中心
可擴充套件的呼叫中心需要託管電話、語音理解、會話意圖處理以及與業務系統的安全整合。
推薦架構
● 使用 Amazon Connect 進行入站呼叫和聯絡流。
● 使用 Amazon Lex 進行自動語音識別和自然語言意圖處理。
● 呼叫AWS Lambda函式來查詢或更新業務應用程式。
● 透過聯絡流返回相關結果。
設計理由
● 技術可行性：Connect 處理聯絡中心路由，Lex 理解語音請求，Lambda 整合後端操作。
● 需求匹配：呼叫者無需代理即可完成常見任務，而服務無需呼叫中心基礎設施管理即可擴充套件。
● 場景匹配：密碼更改和餘額檢查是基於意圖的自助服務操作。
● 工程常識：將會話口譯與受控商業交易分開。
應排除的替代方案
● MediaConnect 傳輸專業影片流，並不是聯絡中心平臺。
● Polly 產生語音，但不執行語音識別或意圖檢測。
● 地面站支援衛星通訊。
● Comprehend 分析文字，但不提供 Lex 提供的互動式語音機器人工作流程。
工作流：來電 → Connect 流程 → Lex 識別意圖 → Lambda 驗證並執行操作 → Connect 將響應或路由返回給代理。
數千個 AWS 賬戶的集中出口
大型多帳戶環境需要可擴充套件的路由中心和集中的出站流量策略實施。
推薦架構
● 將分支 VPC 連線到 AWS Transit Gateway。
● 將批准的出站流量路由到集中出口或檢查 VPC。
● 根據檢查設計使用託管或防火牆 VPN 連線。
● 應用組織控制的路由和防火牆策略。
● 將允許的流量返回到適當的分支。
設計理由
● 技術可行性：Transit Gateway 提供中心輻射型路由，無需數千個成對對等關係。
● 需求匹配：安全團隊集中管理出口控制，而應用程式帳戶保留單獨的 VPC。
● 場景匹配：該設計必須能夠擴充套件到數千個帳戶。
● 工程常識：集中策略和檢查，而不是每個工作負載的應用程式架構。
應排除的替代方案
● VPC 對等互連會造成無法管理的連線和路由增長。
● 共享 VPC 並不適合每個獨立賬戶和路由邊界。
● 具有 EC2 裝置的自我管理傳輸 VPC 增加了修補和擴充套件工作。
● 每個帳戶中都有獨立的 NAT 和防火牆堆疊，重複成本和策略管理。
工作流：分支路由→中轉閘道器→集中檢查→批准的網際網路出口→透過集線器的返回路徑。
流量逐漸轉移的獨立合規性發布
新的合規性邊界應部署為並行環境，而不是強制到現有的生產堆疊中。
推薦架構
● 為相容的應用程式版本構建單獨的 OpsWorks 堆疊。
● 獨立驗證新環境。
● 使用 Route 53 加權路由向其傳送一小部分生產流量。
● 逐漸增加流量，保留原來的堆疊進行回滾。
設計理由
● 技術可行性：並行堆疊可以執行不同的版本，而 DNS 權重控制暴露。
● 需求匹配：逐步割接保護百萬使用者並支援快速回滾。
● 場景匹配：現有平臺已經使用 OpsWorks 和 EC2，因此該版本保持相同的操作模型。
● 工程常識：在驗證過程中隔離監管變化並減少影響範圍。
應排除的替代方案
● 就地升級暴露所有使用者並削弱回滾。
● 將所有流量傳送到新堆疊會立即刪除分階段驗證。
● 將 Lambda 引入 OpsWorks 版本會改變平臺，但沒有解決規定的隔離需求。
工作流：構建→合規性測試→功能測試→低流量權重→觀察→增加權重→驗收後淘汰舊堆疊。
透過 Direct Connect 進行加密 VPN 傳輸
Direct Connect 提供私有、可預測的傳輸，但預設情況下不加密流量。可以透過專用連線上承載的 AWS 站點到站點 VPN 進行分層加密。
推薦架構
● 在現有 Direct Connect 連線上建立公共虛擬介面。
● 透過該介面訪問公共 AWS VPN 終端節點。
● 建立到 VPC 的基於 BGP 的 Site-to-Site VPN。
● 透過加密隧道路由公司員工流量。
設計理由
● 技術可行性：公共 VIF 提供對 AWS 公共服務終端節點的訪問，包括 VPN 終止地址。
● 需求匹配：IPsec 對流量進行加密，同時底層路徑保留 Direct Connect 效能特徵。
● 場景匹配：員工已經從公司網路訪問私有 EC2 應用程式。
● 工程常識：向現有可靠路徑新增加密，而不是將流量移回公共網際網路。
應排除的替代方案
● 透過 Internet 路由的 VPN 會失去所請求的 Direct Connect 一致性。
● 私有 VIF 到達 VPC 私有地址，但不到達此模式所需的公共 VPN 終端節點。
● 膝上型電腦之間的 VPN 連線與現有的企業網路路由設計不匹配。
工作流：公司路由 → 客戶路由器 → IPsec 隧道 → Direct Connect 上的公共 VIF → AWS VPN 終端節點 → VPC。
安全的企業應用部署
複雜的應用程式需要完整的基礎設施定義、受控的流量移動和不可變的容量替換。
推薦架構
● 使用 CloudFormation 定義完整的堆疊。
● 使用 CodeDeploy 藍/綠來控制生產流量轉移。
● 在適用的情況下，使用 Elastic Beanstalk 不可變部署來實現託管應用程式容量。
● 監視執行狀況並保留回滾目標。
設計理由
● 技術可行性：CloudFormation 編排資源，而藍/綠和不可變部署避免了修改服務佇列。
● 需求匹配：釋出最大限度地減少停機時間和回滾風險。
● 場景匹配：該堆疊包括 DynamoDB、Lambda、OpenSearch 和 Beanstalk 資源。
● 工程常識：基礎設施和應用程式版本應該透過測試階段一起推廣。
應排除的替代方案
● SAM 針對無伺服器應用程式進行了最佳化，但並不是此混合堆疊的最佳完整模型。
● 就地部署會增加中斷和回滾風險。
● Lightsail 缺乏所需的企業編排。
● 手動切換會導致恢復不一致。
工作流：提交→構建和測試→更新堆疊→部署替換容量→轉移流量→監控或回滾。
無遮蔽高階的分層 DDoS 彈性
當優質 DDoS 響應服務超出預算時，網路彈性應結合邊緣吸收、過濾、負載分配、監控和彈性。
推薦架構
● 在適當的情況下使用 Amazon CloudFront 進行靜態和動態 Web 交付。
● 將應用程式負載均衡器放置在多個應用程式例項前面。
● 將 AWS WAF 規則應用於 CloudFront 或 ALB 以獲取應用程式層攻擊模式。
● 針對 CPU 和網路壓力建立 CloudWatch 警報。
● 當需求增加時自動擴充套件 EC2 佇列。
設計理由
● 技術可行性：邊緣容量吸收流量，WAF 過濾請求，ALB 分散負載，Auto Scaling 增加應用程式容量。
● 需求匹配：這些控制元件可提高可用性，而無需 Shield Advanced 成本。
● 場景匹配：受保護的工作負載是 EC2 託管的 Web 應用程式。
● 工程常識：沒有單一的控制可以處理每個 DDoS 層；使用補充防禦。
應排除的替代方案
● 預留例項是一種計費模型，不提供額外的效能。
● 附加 ENI 或增強網路無法識別惡意請求。
● S3 不是 POSIX 儲存，修補並不能緩解主動流量氾濫。
工作流：邊緣→WAF→ALB→目標→縮放和警報。
IAM 授權的 API 閘道器請求
AWS 委託人可以透過本機 IAM 授權和簽名版本 4 安全地呼叫 API Gateway。
推薦架構
● 設定API授權型別為AWS_IAM。
● 在所需的階段和方法上授予批准的使用者或角色 execute-api:Invoke。
● 使用 SigV4 簽署客戶端請求。
● 當需要請求跟蹤時啟用 X-Ray。
設計理由
● 技術可行性：API Gateway 根據 IAM 許可權驗證簽名的請求。
● 需求匹配：現有 IAM 身份無需另一個憑證資料庫即可接收受控 API 訪問。
● 場景匹配：呼叫者是 AWS 使用者或角色。
● 工程常識：切勿將秘密訪問金鑰傳輸給自定義授權者。
應排除的替代方案
● CORS 控制瀏覽器源行為，而不是身份驗證。
● 客戶端證書對選定後端整合的 API Gateway 進行身份驗證，而不是對公共 API 的呼叫者進行身份驗證。
● 手動金鑰驗證會重複 AWS 身份驗證並存在洩露機密的風險。
● API 金鑰用於識別使用計劃，並不是強大的授權機制。
工作流：客戶端簽署請求 → API Gateway 驗證 SigV4 → IAM 評估 execute-api:Invoke → 後端執行。
用於遷移發現和準備的工具
遷移規劃應結合投資組合跟蹤、依賴性發現和業務案例分析。
推薦工具
● 使用 AWS Migration Hub 跟蹤應用程式和遷移進度。
● 使用 AWS Application Discovery Service 收集伺服器配置、利用率和依賴項資料。
● 使用雲採用準備工具來評估組織準備情況並確定能力差距。
設計理由
● 技術可行性：Discovery Service 收集資產資料，Migration Hub 集中可見性，CART 構建準備情況評估。
● 需求匹配：它們共同支援工作負載移動開始之前的規劃。
● 場景匹配：組織需要對產品組合級別的理解，而不僅僅是一臺伺服器的傳輸。
● 工程常識：在對遷移浪潮進行排序之前發現依賴關係。
應排除的替代方案
● 應用程式遷移服務執行伺服器遷移，但不會取代組織準備情況評估。
● 資料庫遷移服務專注於資料庫資料移動。
● CloudFormation 部署基礎設施，但不發現本地資產。
● Cost Explorer 會分析採用後或採用期間的 AWS 支出，並不是主要的遷移發現工具。
工作流：評估準備情況→發現伺服器和依賴項→對應用程式進行分組→構建wave→跟蹤遷移中心的執行情況。
將 Active Directory 身份驗證擴充套件到 AWS
AWS 中的 Windows 工作負載可以透過託管目錄信任使用現有的企業憑證。
推薦架構
● 使用 AWS Directory Service 部署 AWS Managed Microsoft AD。
● 與本地 Microsoft Active Directory 建立所需的信任關係。
● 配置目錄之間的 DNS 和網路連線。
● 將 AWS 託管的 Windows 資源加入托管域並啟用所需的 SSO 體驗。
設計理由
● 技術可行性：目錄信任允許來自企業林或域的身份對受信任的 AWS 託管資源進行身份驗證。
● 需求匹配：員工保留現有的使用者名稱和密碼，同時管理 AWS 中的目錄基礎設施。
● 場景匹配：要求是 Windows 域擴充套件和單點登入，而不是消費者身份。
● 工程常識：使用託管相容目錄，而不是將密碼同步到應用程式資料庫中。
應排除的替代方案
● Amazon Cognito 以應用程式使用者為目標，不擴充套件 Windows 域。
● IAM 角色授權 AWS API 操作，但不提供域身份驗證。
● IAM Identity Center 可以聯合員工訪問，但不會替換域加入所需的 Windows 目錄。
● 自定義 LDAP 伺服器增加了可用性和修補工作。
工作流：使用者向公司 AD 進行身份驗證 → 評估信任 → AWS Managed Microsoft AD 授權訪問 → Windows 資源會話。
託管 PB 級批處理
大型並行影象工作負載需要託管作業排程、彈性低成本計算、持久物件儲存和臨時本地處理空間。
推薦架構
● 打包 AWS Batch 作業的處理可執行檔案。
● 使用具有 EC2 Spot 容量的託管計算環境。
● 將原始影象和處理後的影象儲存在單獨的 Amazon S3 位置。
● 使用作業佇列來安排數千個並行任務。
● 僅使用 EBS 卷作為臨時本地工作區。
設計理由
● 技術可行性：AWS Batch 提供計算和排程作業，而 S3 可擴充套件到 PB 級並具有高耐用性。
● 需求匹配：Spot 降低了計算成本，託管排程程式最大限度地減少了運營開銷。
● 場景匹配：作業是獨立、並行的，並且在大約一週內完成。
● 工程常識：將持久資料保留在一次性工作人員之外。
應排除的替代方案
● 自定義 SQS 和 Auto Scaling 工作執行緒平臺需要更多排程和佇列邏輯。
● 對於 10 PB 批次資料集，EFS 並不是最經濟的共享源。
● EKS 可以執行作業，但新增了 Kubernetes 管理。
● EMR 適用於受支援的大資料框架，而不是自動適用於需要為 Spark 重寫的現有可執行檔案。
工作流：上傳輸入 → 提交作業 → 批次排程 Spot 工作人員 → 階段到 EBS → 處理 → 將結果寫入 S3。
分層 Web DDoS 緩解
DDoS 彈性結合了減少暴露、邊緣容量、應用程式過濾和託管響應。
推薦架構
● 使用網路 ACL 和安全組限制不必要的埠。
● 將 CloudFront 放置在公共 Web 源之前。
● 使用 AWS WAF 阻止惡意 Web 模式。
● 當需要增強 DDoS 防護時啟用 Shield Advanced。
設計理由
● 技術可行性：網路控制減少攻擊面，CloudFront 吸收邊緣流量，WAF 過濾第 7 層請求，Shield 增加基礎設施保護。
● 需求匹配：這些控制涵蓋了互補的攻擊路徑。
● 場景匹配：工作負載是面向網際網路的 Web 應用程式。
● 工程常識：擴充套件有助於可用性，但不能取代過濾。
應排除的替代方案
● MFA、Config、Trusted Advisor 和 Fraud Detector 不會直接阻止 DDoS 流量。
● 較大的例項仍然可能被淹沒並增加攻擊成本。
● 會話管理器是一個管理工具。
● S3 版本控制和作業系統補丁可提高耐用性和衛生性，而不是主動緩解流量。
工作流：網際網路 → Shield 和 CloudFront → WAF → 允許的埠 → 負載均衡器和應用程式。
跨賬戶私人託管區關聯
Route 53 私有託管區域僅解析與該區域關聯的 VPC 的記錄。
推薦流程
● 在託管區域所有者賬戶中，授權與第二個賬戶中的應用程式 VPC 關聯。
● 在 VPC 所有者賬戶中，將 VPC 與私有託管區域關聯。
● 完成後刪除臨時關聯授權。
● 驗證VPC DNS支援並查詢資料庫CNAME。
設計理由
● 技術可行性：Route 53 透過先授權後關聯的方式支援跨賬戶私有託管區域關聯。
● 需求匹配：EC2 例項解析集中式私有資料庫名稱，無需複製 DNS 區域。
● 場景匹配：記錄正確，但應用VPC尚未連結到可用區。
● 工程常識：修復名稱解析範圍，而不是硬編碼更改資料庫地址。
應排除的替代方案
● VPC 對等互連不會自動將私有託管區域與另一個 VPC 關聯。
● 私有託管區域不能相互關聯以進行記錄複製。
● 使用 RDS IP 編輯 /etc/resolv.conf 很脆弱，因為地址可能會在故障轉移期間發生變化。
工作流：授權→關聯→解除授權→解析CNAME→連線RDS。
ECS 微服務的任務級安全性
容器安全性應在任務級別隔離網路訪問和 AWS 許可權，而不是共享主機級別的控制。
推薦架構
● 在 ECS 任務定義中使用 awsvpc 網路模式。
● 直接將安全組分配給 ECS 任務。
● 使用 IAM 任務角色訪問 AWS 服務。
● 僅向每個微服務授予其所需的操作和資源。
設計理由
● 技術可行性：每個任務都會接收一個彈性網路介面、私有 IP 地址和安全組控制。
● 需求匹配：任務角色和任務安全組實現網路和 API 訪問的最低許可權。
● 場景匹配：嚴格的安全策略需要容器級別的標準網路監控和控制。
● 工程常識：不要為每個容器授予其 EC2 主機的廣泛許可權。
應排除的替代方案
● 橋接模式在主機上應用安全組，而不是單個任務。
● EC2 例項角色可以向主機上的多個服務公開更廣泛的許可權。
● 將 IAM 憑證傳遞到容器中會產生長期的秘密風險。
● 遷移到 App Runner 不會證明環境變數中的憑據是合理的，並且會不必要地更改平臺。
工作流：定義任務角色→選擇awsvpc→附加任務安全組→部署→檢查流程和應用程式日誌→細化許可權。
使用外部 ID 進行供應商訪問
供應商應透過最低許可權的 IAM 角色和外部 ID 條件來訪問客戶資源。
推薦架構
● 在客戶帳戶中建立角色。
● 僅授予所需的操作和資源。
● 信任供應商的 AWS 賬戶或角色。
● 需要客戶特定的外部 ID。
● 讓供應商致電 STS 獲取臨時憑證。
設計理由
● 技術可行性：信任策略在角色承擔之前驗證供應商身份和外部 ID。
● 需求匹配：訪問許可權是臨時的、可撤銷的，並且可以防止代理跨客戶錯誤。
● 場景匹配：一個供應商應用程式為多個客戶提供服務。
● 工程常識：切勿與服務提供商共享個人或根訪問金鑰。
應排除的替代方案
● 長期 IAM 使用者金鑰會增加暴露和輪換工作。
● Amazon Connect 與第三方 API 授權無關。
● 個人訪問金鑰暴露了客戶自己的身份和許可權。
● 信任沒有外部 ID 的供應商會削弱客戶分離。
工作流：供應商使用外部 ID 請求角色 → IAM 信任評估 → STS 發出臨時會話 → 供應商執行範圍內的工作。
持久報紙搜尋和 OCR 現代化
數字報紙檔案需要持久的影象儲存、全球交付、可擴充套件的搜尋以及對即將到期的 OCR 軟體的託管替代品。
推薦架構
● 將掃描的 PNG 檔案儲存在 Amazon S3 中。
● 透過 Amazon CloudFront 交付影象。
● 在多可用區 Elastic Beanstalk 環境中執行 Web 應用程式。
● 使用 Amazon CloudSearch 為可搜尋內容編制索引。
● 使用 Amazon Textract 從掃描的報紙中提取文字。
設計理由
● 技術可行性：Textract 執行文件 OCR，CloudSearch 支援文字查詢，S3 加 CloudFront 提供持久的全域性內容交付。
● 需求匹配：託管服務減少了管理，同時支援可用性和增長。
● 場景匹配：存檔包含必須可搜尋的掃描文件。
● 工程常識：單獨的持久源影象、提取的文字、搜尋索引和網路交付。
應排除的替代方案
● Rekognition 不是用於文件文字提取的主要 OCR 服務。
● Glacier 與立即檢索衝突，並且不能解決 OCR。
● 自我管理的 EC2、EBS、NGINX 和搜尋軟體增加了操作和較弱的共享儲存擴充套件。
工作流：攝取掃描 → 儲存在 S3 中 → 使用 Textract 提取文字 → 索引結果 → 透過應用程式搜尋 → 透過 CloudFront 交付影象。
透過消除資料庫等待來降低無伺服器成本
在調整計算設定之前，應在延遲源處糾正由網路等待導致的較長 Lambda 持續時間。
推薦架構
● 將本地 MySQL 資料庫遷移到 Amazon RDS for MySQL。
● 使用多可用區實現資料庫可用性。
● 啟用 API 閘道器快取以實現安全、可重複的響應。
● 測量新的執行配置檔案後調整 Lambda 記憶體大小和超時。
● 使用 DynamoDB Auto Scaling 實現不可預測的增長。
設計理由
● 技術可行性：將 MySQL 移至靠近 Lambda 的位置可消除重複的混合延遲； API 快取減少了呼叫。
● 需求匹配：更短的執行時間和更少的呼叫直接降低了成本。
● 場景匹配：該應用程式已經實現了無伺服器擴充套件，因此用伺服器替換 Lambda 將顛倒工作設計。
● 工程常識：消除最佳化輔助資源之前 4.5 分鐘的等待。
應排除的替代方案
● Direct Connect 可以改善延遲，但對於單個工作負載來說成本高昂，並且保留了遠端依賴性。
● 將 Lambda 轉換為 EC2 增加了容量管理。
● CloudFront 快取不如 API Gateway 階段快取直接。
● DAX 或 ElastiCache 會增加成本，但沒有規定低延遲快取要求。
工作流：遷移資料庫→驗證→快取API→測量Lambda→調整→監控成本。
按佇列長度縮放影象分析
共享物件儲存、持久工作分配和基於待辦事項的擴充套件可以安全地減少影象處理時間。
推薦架構
● 將輸入和輸出檔案儲存在 Amazon S3 中。
● 在 Amazon SQS 中為每個影象放置一個處理任務。
● 使用 SQS 佇列深度指標擴充套件 EC2 工作執行緒。
● 使工作人員冪等並配置死信佇列。
設計理由
● 技術可行性：每個工作人員都可以訪問 S3，SQS 分配任務，Auto Scaling 遵循實際的積壓工作。
● 需求匹配：更多的工作人員在高峰期啟動，並在工作量下降時終止。
● 場景匹配：影象是獨立的並行任務。
● 工程常識：從待處理的工作進行擴充套件，而不是從可能已經使用的通知進行擴充套件。
應排除的替代方案
● EBS 附加到例項和可用區，而不是在動態佇列中共享。
● SNS 是一種通知服務，而不是持久的競爭消費者佇列。
● SNS 通知計數不是當前處理積壓的數量。
● 僅從 CPU 進行擴充套件可能反應太晚或忽略排隊的需求。
工作流：影象到 S3 → 任務到 SQS → 佇列增長 → 工作人員擴充套件 → 結果到 S3 → 佇列耗盡。
對未經授權的 IAM 使用者立即響應
建立新的 IAM 使用者時，CloudTrail 事件可以觸發自動審批和修復工作流程。
推薦架構
● 將 CloudTrail CreateUser 事件與 EventBridge 匹配。
● 呼叫 Step Functions 進行批准和修復。
● 未經批准時刪除或限制許可權。
● 透過 SNS 通知安全部門。
設計理由
● 技術可行性：CloudTrail 記錄 API，EventBridge 近乎實時地做出反應，Step Functions 協調操作。
● 需求匹配：未經授權的使用者會被快速遏制，並通知安全部門。
● 場景匹配：該控制元件專注於一個帳戶更改 API 事件。
● 工程常識：在修改身份之前保留事件詳細資訊。
應排除的替代方案
● 審計經理收集證據並不會立即採取補救措施。
● CloudTrail 記錄事件但不獨立過濾和通知。
● Fargate 新增了不必要的容器啟動和操作。
● 未經許可刪除的通知會使風險處於活動狀態。
工作流：建立使用者 → CloudTrail → EventBridge → Step Functions → 限制使用者 → SNS 警報。
彈性全球網路平臺
公共網路平臺需要全域性靜態交付、網路保護、彈性計算和託管關聯式資料庫。
推薦架構
● 將靜態內容儲存在 S3 中並透過 CloudFront 進行交付。
● 附加 AWS WAF 以應對常見應用程式攻擊。
● 在多可用區 Auto Scaling 組中執行 Web 伺服器。
● 使用 Aurora MySQL 來實現託管資料庫的可用性和規模。
設計理由
● 技術可行性：CloudFront 快取內容，WAF 過濾 HTTP 請求，Auto Scaling 替換故障伺服器，Aurora 提供託管關係儲存。
● 需求匹配：該設計同時提高了效能、安全性、可用性和操作。
● 場景匹配：靜態內容、網路計算和關係資料需要不同的服務。
● 工程常識：使用託管層而不是自我管理每個元件。
應排除的替代方案
● EC2 上的自我管理 MySQL 保留了資料庫操作並省略了邊緣保護。
● Global Accelerator 不是靜態內容快取。
● S3 Transfer Acceleration 加速上傳速度，而不是網站傳送速度。
● 標準 RDS 可以工作，但所選的 Aurora 設計更適合託管擴充套件和可用性。
工作流：使用者 → CloudFront 和 WAF → Auto Scaling Web 層 → Aurora MySQL。
針對緊急流量激增的邊緣解除安裝
當無法完全遷移時，請在不更改應用程式事務核心的情況下緩解主要流量路徑。
推薦架構
● 在本地保留動態網站和支付工作流程。
● 將 Amazon CloudFront 放置在高解析度影象和其他可快取資產的前面。
● 附加阻止常見 SQL 注入和跨站點指令碼模式的 AWS WAF 規則。
設計理由
● 技術可行性：CloudFront 可以使用現有站點作為源並快取使用者附近的靜態響應。
● 需求匹配：邊緣快取快速降低源頻寬和負載； WAF 新增了所請求的 Web 層保護。
● 場景匹配：大型靜態資產是直接的擴充套件壓力，而支付仍然是動態的。
● 工程常識：首先解決瓶頸，而不是匆忙開始全面遷移。
應排除的替代方案
● S3 靜態網站託管無法替代動態支付處理。
● 構建 EC2 映像、Auto Scaling、混合路由和 ALB 對於截止日期來說過於寬泛。
● 當邊緣服務滿足緊急需求時，完整的伺服器遷移會帶來時間和切換風險。
工作流：對可快取路徑進行分類 → 配置源和快取行為 → 附加 WAF → 測試支付 → 監控源解除安裝。
藉助 RDS 多可用區實現 Oracle 高可用性
需要自動故障轉移的託管 Oracle 資料庫應使用 Amazon RDS 多可用區部署。
推薦架構
● 在啟用多可用區的 Amazon RDS 上執行 Oracle。
● 透過 RDS 端點連線應用程式。
● 讓 RDS 在另一個可用區中保持同步備用。
● 測試應用程式在受控故障轉移期間的重新連線行為。
設計理由
● 技術可行性：RDS 檢測基礎設施故障、提升備用狀態並更新端點的 DNS 對映。
● 需求匹配：無需客戶管理的叢集和複製操作即可提高資料庫可用性。
● 場景匹配：網站需要連續性，而不僅僅是分析讀取擴充套件。
● 工程常識：在資料庫引擎和版本支援的情況下使用託管故障轉移。
應排除的替代方案
● RMAN 備份支援恢復，但不提供自動故障轉移。
● Oracle 只讀副本（如果可用）與同步多可用區備用資料庫不同。
● EC2 上的自我管理 Oracle RAC 增加了許可、叢集、儲存和修補的複雜性。
● 單個 RDS 例項仍然存在可用性風險。
工作流：應用程式使用端點→主故障→RDS提升備用→DNS更新→應用程式重新連線。
適用於對等 VPC 的單客戶端 VPN
員工可以透過一個集中管理的客戶端 VPN 終端節點進行連線，並訪問對等 VPC 中的應用程式。
推薦架構
● 在主 VPC 中部署客戶端 VPN 終端節點。
● 在員工裝置上安裝 VPN 客戶端。
● 新增遠端 VPC CIDR 的客戶端 VPN 授權和路由。
● 配置互惠 VPC 對等路由和安全規則。
設計理由
● 技術可行性：客戶端 VPN 終止遠端使用者會話，而 VPC 對等互連將流量傳輸到連線的應用程式 VPC。
● 需求匹配：一個端點可降低跨賬戶的成本和管理。
● 場景匹配：內部應用程式已駐留在對等 VPC 中。
● 工程常識：驗證 CIDR 不重疊並且對等互連是非傳遞的。
應排除的替代方案
● 每個帳戶一個客戶端 VPN 會重複管理。
● 客戶端軟體屬於員工裝置，而不是資料中心。
● 站點到站點 VPN 不會取代漫遊使用者的客戶端 VPN 終端節點。
● 缺少返回路線會中斷連線。
工作流：員工 → 客戶端 VPN → 主 VPC 路由 → 對等連線 → 應用程式 VPC → 返回路徑。
可擴充套件的移動照片和字幕平臺
期望有數百萬次瀏覽的消費者移動應用程式應該將身份驗證、小型結構化記錄、物件儲存和全域性交付分開。
推薦架構
● 使用 Amazon Cognito 進行使用者身份驗證和身份管理。
● 將字幕和使用者後設資料儲存在 Amazon DynamoDB 中。
● 將上傳的照片和靜態資源儲存在 Amazon S3 中。
● 透過 Amazon CloudFront 交付靜態內容。
設計理由
● 技術可行性：Cognito 支援移動登入，DynamoDB 擴充套件鍵值記錄，並且帶有 CloudFront 的 S3 處理大型物件流量。
● 需求匹配：所有元件都可以以較低的運營開銷進行擴充套件，並且沒有固定的伺服器群。
● 場景匹配：照片是物件，而簡短的標題是小的結構化專案。
● 工程常識：將每種資料型別與為其設計的服務相匹配。
應排除的替代方案
● RDS 是可行的，但增加了簡單字幕資料的容量規劃和資料庫操作。
● 直接移動訪問 RDS 是不合適的。
● 社交登入不需要本地 Active Directory 和自定義 LDAP 程式碼。
● SAML 不是普通消費者社交身份提供商的直接模式。
工作流：使用者登入→接收範圍身份→將照片上傳到S3→將標題寫入DynamoDB→檢視者透過CloudFront接收快取的資產。
異構資料庫遷移：Oracle 到 PostgreSQL
異構資料庫遷移有兩個不同的工作：轉換資料庫物件，然後移動和同步資料。
推薦架構
● 使用 AWS Schema Conversion Tool 評估和轉換 Oracle 架構和程式碼。
● 解決需要手動轉換的物件。
● 建立目標 Amazon RDS for PostgreSQL 資料庫。
● 使用 AWS Database Migration Service 進行滿負載和持續更改複製。
設計理由
● 技術可行性：SCT轉換結構不同的資料庫物件； DMS 在源引擎和目標引擎之間傳輸記錄。
● 需求匹配：該工作流程支援在有限的停機時間和專用工具的情況下進行遷移。
● 場景匹配：Oracle和PostgreSQL是不同的引擎，因此模式轉換必須先於資料切換。
● 工程常識：不要期望資料移動服務重新設計儲存過程或不相容的架構。
應排除的替代方案
● SAM 和 Lambda 是應用程式開發工具，而不是資料庫轉換服務。
● 伺服器遷移服務移動伺服器而不是轉換資料庫引擎。
● 僅DMS並不能完成異構模式和程式碼轉換。
● Data Pipeline、CodeCommit 和 Batch 可以支援自定義指令碼，但會新增不必要的工程。
工作流：評估 → 轉換架構 → 修復程式碼 → 建立目標 → 完全載入 → 複製更改 → 驗證 → 切換。
強制執行成本分配標籤
準確的成本報告需要糾正現有資源並防止未來建立無標籤的情況。
推薦架構
● 使用標籤編輯器將所需標籤新增到現有 RDS 和 DynamoDB 資源。
● 啟用這些鍵作為成本分配標籤。
● 使用帶有標籤條件的 SCP 可在缺少所需標籤時拒絕將來的資源建立。
設計理由
● 技術可行性：標籤編輯器執行批次更新，計費公開啟用的標籤，SCP 條件建立預防性護欄。
● 需求匹配：歷史資源變得可報告，並且新的漂移減少。
● 場景匹配：成本中心和專案後設資料在賬戶之間是強制性的。
● 工程常識：糾正過去並防止再次發生。
應排除的替代方案
● 啟用計費標籤不會建立丟失的資源標籤。
● Lambda 修復會新增自定義程式碼並在建立後執行操作。
● 僅標記當前資源並不會強制執行未來的行為。
● AWS Config 可以檢測丟失的標籤，但不會阻止建立。
工作流：庫存→批次標籤→啟用計費金鑰→應用SCP→測試批准和拒絕的供應。
感測器時間序列的 DynamoDB 鍵
每個感測器的時間序列查詢需要感測器的分割槽鍵和時間的有序排序鍵。
推薦設計
● 每週建立 DynamoDB 表以限制活動資料大小。
● 使用感測器 ID 作為分割槽鍵。
● 使用時間戳作為排序鍵。
● 查詢一個感測器的時間範圍條件。
設計理由
● 技術可行性：一個感測器的專案在邏輯上位於同一位置並按時間戳排序。
● 需求匹配：該應用程式有效地檢索感測器的最近測量值。
● 場景匹配：資料自然地按裝置和時間分組。
● 工程常識：確保感測器流量充分分佈以避免熱分割槽。
應排除的替代方案
● 將感測器和時間戳連線到一個分割槽鍵會使範圍查詢變得困難。
● 僅靠周表並不能修復糟糕的鍵設計。
● DynamoDB 的分割槽鍵是雜湊鍵；顛倒關鍵角色是不正確的。
● 一個全域性分割槽鍵建立一個熱分割槽。
工作流：選擇每週表→查詢感測器分割槽→應用時間戳範圍→返回有序測量。
在資源建立時應用標籤
治理標籤應在配置期間應用，而不是事後發現和修復。
推薦架構
● 透過 AWS Service Catalog 釋出批准的產品，以便預配置的資源繼承產品組合、產品和使用者後設資料。
● 在 CloudFormation 資源中定義所需的 Tags 屬性。
● 保護配置模板和標籤修改許可權。
設計理由
● 技術可行性：Service Catalog 和 CloudFormation 在建立資源時應用支援的標籤。
● 需求匹配：成本分配和所有權後設資料立即存在。
● 場景匹配：資源透過受管理的服務和基礎設施模板進行配置。
● 工程常識：儘可能防止後設資料丟失，然後對異常情況使用檢測控制。
應排除的替代方案
● Systems Manager Automation 在建立後新增標籤。
● AWS 生成的成本分配標籤並不涵蓋每個組織特定的要求。
● AWS Config 會檢測缺失的標籤，但不會在建立時新增它們。
● 手動標記不一致且難以稽核。
工作流：使用者選擇目錄產品或管道部署堆疊→應用標籤→建立資源→合規性驗證。
可搜尋的 50 TB 文件平臺
大型文件存檔需要持久的物件儲存、搜尋索引、動態應用程式託管和可重複的基礎設施。
推薦架構
● 在 AWS CloudFormation 中定義環境。
● 將 50 TB 文件集合儲存在 Amazon S3 中。
● 在 Amazon CloudSearch 中為可搜尋後設資料和文字建立索引。
● 在 Amazon EC2 上託管動態網站。
設計理由
● 技術可行性：S3 儲存大型物件集合，CloudSearch 處理查詢，EC2 執行動態應用程式邏輯。
● 需求匹配：該設計可擴充套件，同時避免文件二進位制檔案的大型關聯式資料庫。
● 場景匹配：使用者搜尋文件而不是處理實時流。
● 工程常識：將原始物件與可重建搜尋索引分開。
應排除的替代方案
● S3靜態網站託管無法替代動態應用。
● S3 不提供本機全文搜尋。
● 對於 50 TB 的文件物件，RDS 成本高昂且不必要。
● Kinesis 是一種流服務，而不是持久文件儲存或搜尋索引。
工作流：上傳文件→儲存在S3→提取並索引後設資料→查詢CloudSearch→檢索物件。
使用 AWS Config 監控批准的 AMI
AWS Config 可以根據批准的 AMI 列表評估正在執行的例項，並通知團隊有關不合規的情況。
推薦架構
● 配置 approved-amis-by-id 託管規則。
● 提供授權的 AMI ID。
● 透過 SNS 傳送違規通知。
● 透過批准的更換流程進行修復。
設計理由
● 技術可行性：Config 評估與執行的 EC2 例項關聯的 AMI。
● 需求匹配：該組織可以獲得持續的合規可見性，而不會阻止開發啟動。
● 場景匹配：關注的是影象審批，而不是軟體漏洞掃描。
● 工程常識：檢測不良影象和掃描影象中的 CVE 是不同的控制。
應排除的替代方案
● Inspector 掃描的是漏洞，而不是已批准的 AMI 列表中的成員資格。
● 預防性 SCP 和 IAM 限制可能會阻礙開發。
● CloudWatch 本身並不評估已批准的 AMI。
● Trusted Advisor 沒有直接批准的 AMI 合規性檢查。
工作流：記錄例項配置→配置規則評估AMI→不合規結果→SNS通知→替換。
託管 Windows 桌面和應用程式
託管虛擬桌面服務可以提供 Windows 訪問，同時減少伺服器維護和應用程式分發工作。
推薦架構
● 將 Amazon WorkSpaces 用於託管 Windows 桌面。
● 在適用的情況下，使用 Amazon WorkSpaces Application Manager 進行受控應用程式交付。
● 啟用自動 Windows 更新和定義的維護時段。
● 集中應用目錄、網路和訪問控制。
設計理由
● 技術可行性：WorkSpaces 管理桌面基礎設施，而 WAM 打包和分配應用程式。
● 需求匹配：使用者獲得管理程度較低的託管 Windows 環境。
● 場景匹配：需要的是安全的桌面訪問，而不是 Web 開發環境或堡壘主機。
● 工程常識：將桌面服務用於桌面，並將管理跳轉訪問保留為單獨的安全設計。
應排除的替代方案
● Lightsail 不是託管企業桌面解決方案，並且缺少所描述的作業系統升級工作流程。
● AppSync 是一項 GraphQL 服務。
● Cloud9 是一個開發環境，而不是一個強化的 Windows 桌面平臺。
● AppStream 流式傳輸應用程式，但不是堡壘主機。
工作流：使用者身份驗證 → WorkSpaces 會話啟動 → 交付分配的應用程式 → 維護期間應用更新。
PII 發現、儲存生命週期和資料庫可用性
照片共享服務需要單獨控制敏感物件發現、儲存成本最佳化和關聯式資料庫停機時間。
推薦架構
● 使用 Amazon Macie 發現 S3 中的 PII 並對其進行分類。
● 應用 S3 生命週期規則，在訪問下降時將舊照片轉換為 S3 Standard-IA。
● 配置 RDS 資料庫以進行多可用區部署。
設計理由
● 技術可行性：Macie 分析 S3 物件中的敏感資料，生命週期策略自動執行儲存轉換，RDS 多可用區提供託管備用故障轉移。
● 需求匹配：該平臺降低了儲存成本，提高了資料庫可用性，並獲得了 PII 暴露的可見性。
● 場景匹配：使用者照片駐留在 S3 中，而應用程式記錄仍然相關。
● 工程常識：使用不同的服務來實現資料分類、物件生命週期和資料庫高可用性。
應排除的替代方案
● Amazon Inspector 評估計算工作負載，並且不會對 S3 中的 PII 進行分類。
● 立即將每張新照片轉移到 Standard-IA 可能會產生檢索費用和最短持續時間費用。
● 當使用者仍期望常規照片訪問時，冰川不適合。
● Redshift 是一個分析倉庫，而不是事務資料庫的高可用性替代品。
● EBS 更改無法解決託管 RDS 停機問題。
工作流：上傳照片 → Macie 評估敏感內容 → 生命週期轉換老化物件 → RDS 在需要時自動故障轉移。
ECS Fargate 的託管秘密注入
容器憑據應在執行時從專用秘密儲存中檢索，而不是嵌入到影象或任務定義檔案中。
推薦架構
● 將資料庫憑證儲存在 AWS Secrets Manager 中。
● 使用 AWS KMS 加密金鑰。
● 配置託管憑證輪換。
● 僅授予 ECS 任務執行角色所需的 Secret 和 KMS 許可權。
● 在容器定義中引用秘密 ARN 以進行環境變數注入。
設計理由
● 技術可行性：ECS 可以在任務啟動期間解析機密並將其值注入到容器環境中。
● 需求匹配：Secrets Manager 提供專門的生命週期管理和輪換，只需最少的定製工作。
● 場景匹配：工作負載已在 Fargate 上執行，因此無需進行平臺遷移。
● 工程常識：將純文字排除在原始檔、S3 任務定義工件和容器映像之外。
應排除的替代方案
● Parameter Store SecureString 是可行的，但 Secrets Manager 更好地滿足顯式託管輪換要求。
● 遷移到 EKS 會增加 Kubernetes 管理，但不會改進此秘密工作流程。
● 對任務定義檔案內的憑據進行加密會產生手動暴露和分發風險。
工作流：建立秘密 → 配置輪換 → 授予角色 → 引用 ARN → 部署任務 → 測試輪換。
多區域 ALB 的區域 ACM 證書
Application Load Balancer 及其附加的 ACM 證書是區域資源。
推薦架構
● 在每個應用區域請求或匯入所需的證書。
● 驗證每個完全限定域名。
● 將區域證書附加到同一區域中的應用程式負載均衡器。
● 使用基礎設施即程式碼自動化證書和偵聽器部署。
設計理由
● 技術可行性：僅當 ACM 證書存在於 ALB 的區域中時，ALB 才能使用該證書。
● 需求匹配：每個區域 HTTPS 端點都會繼續提供受信任的證書。
● 場景匹配：該應用程式正在從一個區域擴充套件到多個獨立的區域堆疊。
● 工程常識：將區域依賴性複製在一起，而不是假設一種區域資源是全球性的。
應排除的替代方案
● 在一個區域中建立的證書無法附加到其他區域中的 ALB。
● AWS KMS 管理加密金鑰，但不頒發公共網站證書。
● 重複使用一個區域 ALB 證書並不提供區域獨立性。
工作流：定義 FQDN → 請求每個區域的 ACM 證書 → 完成 DNS 驗證 → 附加到區域 ALB 偵聽器 → 測試 TLS → 將使用者路由到區域端點。
具有直接連線的專用混合連線
從 VPC 到內部服務的私有、專用連線使用 Direct Connect 和支援 BGP 的客戶路由。
推薦架構
● 配置 AWS Direct Connect。
● 配置所需的私有虛擬介面和 VPC 連線架構。
● 使用支援 BGP 的本地路由器。
● 根據需要為 BGP 會話配置 MD5 身份驗證。
設計理由
● 技術可行性：Direct Connect 提供專用傳輸，BGP 動態交換路由。
● 需求匹配：該路徑避免了對公共網際網路頻寬的依賴。
● 場景匹配：內部服務需要穩定的私有混合連線。
● 工程常識：當連線對業務至關重要時，新增冗餘位置或 VPN 備份。
應排除的替代方案
● 網際網路閘道器加 VPN 是加密的，但不是專用頻寬。
● 中轉 VPC 仍然依賴 VPN 傳輸。
● 彈性 IP 是公共定址，而不是專用連線。
● 僅靜態路由無法滿足所需的 Direct Connect 路由會話。
工作流：本地路由器 → 透過 Direct Connect 的 BGP → 私有 VIF → AWS 閘道器 → VPC 路由。
透過 S3 REST API 使用 SSE-C
使用客戶提供的金鑰進行 S3 伺服器端加密要求客戶端在每個相關請求時傳送加密金鑰。
所需請求頭
● x-amz-server-side-encryption-customer-algorithm
● x-amz-server-side-encryption-customer-key
● x-amz-server-side-encryption-customer-key-MD5
● 建立和使用預簽名請求時包含所需的 SSE-C 資訊。
設計理由
● 技術可行性：S3 使用提供的金鑰來加密或解密物件，但不儲存金鑰。
● 需求匹配：當 S3 執行物件加密時，客戶保留金鑰保管權。
● 場景匹配：上傳和下載透過 REST API 而不僅僅是控制檯進行。
● 工程常識：丟失客戶金鑰會使物件無法恢復。
應排除的替代方案
● SSE-C 不僅限於 AWS 控制檯。
● WebSocket Secure 保護 WebSocket 傳輸，與 S3 加密無關。
● 僅 MD5 標頭是不夠的，因為 S3 還需要演算法和金鑰。
● 透過不受保護的連線傳送金鑰是不安全的；使用 HTTPS。
工作流：客戶端構建 HTTPS 請求 → 提供所有 SSE-C 標頭 → S3 驗證 MD5 → 加密或解密物件。
平滑智慧電錶寫入 DynamoDB
寫入吞吐量錯誤需要更多資料庫容量或緩衝區，以在寫入到達 DynamoDB 之前平滑突發。
推薦架構
● 增加或自動擴充套件 DynamoDB 寫入容量。
● 透過 Amazon Kinesis 攝取儀表事件。
● 讓 Lambda 使用者批次記錄並將其寫入 DynamoDB。
● 監視限制、迭代器壽命和消耗的容量。
設計理由
● 技術可行性：額外的容量消除了直接瓶頸； Kinesis 持久緩衝突發流量以控制消耗。
● 需求匹配：儀表事件繼續到達，不會立即發生寫入丟失。
● 場景匹配：裝置產生具有突發吞吐量的大容量流。
● 工程常識：擴充套件受限資源並將生產者與下游寫入速度分離。
應排除的替代方案
● 當處理已成功時，更多 Lambda 記憶體並不能解決 DynamoDB 限制問題。
● 除非業務需要並且會限制吞吐量，否則 FIFO 排序和重複資料刪除是不必要的。
● 減少裝置報告會改變產品行為，而不是修復攝取架構。
● 在沒有緩衝的情況下重試可能會加劇限制。
工作流：計量事件 → Kinesis 分片 → Lambda 批處理 → DynamoDB 寫入 → 根據觀察到的需求擴充套件容量。
發現用於遷移的伺服器 TCO
準確的遷移規模和總成本估算需要測量伺服器配置、利用率和依賴性資料。
推薦架構
● 部署 AWS Application Discovery Service 代理或無代理收集器。
● 收集 CPU、記憶體、網路、程序和連線資訊。
● 將相關伺服器分組到應用程式中。
● 使用收集的利用率來調整 AWS 目標並估算 TCO。
設計理由
● 技術可行性：發現服務收集遷移規劃所需的詳細資產資料。
● 需求匹配：建議基於觀察到的使用情況，而不是僅基於已安裝的硬體。
● 場景匹配：該組織仍在遷移前評估其資料中心。
● 工程常識：根據代表性的使用週期和已知的業務高峰來確定合適的規模。
應排除的替代方案
● Migration Hub 跟蹤進度，但不會獨立收集所有詳細的利用率資料。
● AWS SAM 構建無伺服器應用程式。
● AWS MGN 複製伺服器，並不是主要的發現和 TCO 服務。
● 手動電子表格很快就會變得陳舊，並且可能會丟失依賴項。
工作流：安裝收集器→觀察工作負載週期→檢查依賴關係→對應用程式進行分組→調整目標大小→估計遷移業務案例。
使用檔案閘道器進行低中斷媒體編目
大型本地媒體存檔可以採用雲物件儲存和託管面部識別，同時保留其現有的面向檔案的工作流程。
推薦架構
● 在本地部署 AWS Storage Gateway 檔案閘道器。
● 讓媒體資產管理系統透過熟悉的檔案介面寫入檔案。
● 將閘道器支援的物件儲存在 Amazon S3 中。
● 使用 AWS Lambda 呼叫 Amazon Rekognition 進行媒體分析。
● 將提取的後設資料返回到現有目錄系統。
設計理由
● 技術可行性：檔案閘道器公開 S3 支援的檔案協議，Rekognition 處理支援的 S3 媒體物件。
● 需求匹配：該工作流程最大限度地減少中斷和持續的基礎設施管理。
● 場景匹配：現有工具需要檔案，而長期方向是遷移到 AWS。
● 工程常識：先在現有介面整合，然後自動化雲端處理。
應排除的替代方案
● Kinesis Video Streams 的目標是實時影片，而不是歷史磁帶存檔。
● Rekognition 無法直接實時處理 Glacier 虛擬磁帶。
● Snowball 可以移動大量資料，但自我管理的 EC2 面部識別軟體增加了維護工作。
工作流：MAM 匯出檔案 → 檔案閘道器儲存在 S3 中 → 事件呼叫處理 → Rekognition 返回標籤或面孔 → 後設資料更新 MAM。
檢測和刪除未經批准的 AMI
敏捷的管道可以允許啟動，同時自動識別和修復從未經授權的映像構建的例項。
推薦模式
● 使用 AWS Config 檢測未經批准的 AMI ID，然後呼叫 Lambda 發出警報並終止不合規例項。
● 或者執行計劃的 Lambda，檢查例項 AMI ID、通知安全部門並終止未經授權的例項。
設計理由
● 技術可行性：EC2 公開源 AMI ID，Lambda 可以評估和終止例項。
● 需求匹配：CI/CD 不會被阻止，但未經授權的容量是短暫的。
● 場景匹配：該政策有利於偵查和糾正控制，而不是預防性否認。
● 工程常識：在終止前保留證據並保護批准的影象列表。
應排除的替代方案
● 手動審批會延遲交付。
● Amazon Inspector 會掃描漏洞，但不會決定 AMI 是否獲得批准。
● 預防性 IAM 限制與不停止啟動的要求相沖突。
● 沒有補救措施的通知會使不合規的工作負載繼續執行。
工作流：例項啟動 → AMI 評估 → 合規例項仍然存在；不合規例項將被記錄、發出警報並終止。
使用磁帶閘道器的虛擬磁帶檔案
現有的磁帶備份軟體可以遷移到雲支援的虛擬磁帶，而無需改變其操作模型。
推薦架構
● 部署 Storage Gateway 磁帶閘道器。
● 將虛擬磁帶庫呈現給現有的備份軟體。
● 將活動虛擬磁帶保留在 S3 支援的儲存中。
● 將磁帶彈出到虛擬磁帶架以進行 Glacier 級存檔。
設計理由
● 技術可行性：磁帶閘道器模擬磁帶庫並與常見備份應用程式整合。
● 需求匹配：該公司保留了當前的工作流程，同時減少了物理磁帶操作。
● 場景匹配：源程序已使用磁帶備份語義。
● 工程常識：選擇與備份軟體所需介面相匹配的閘道器型別。
應排除的替代方案
● 虛擬磁帶架是存檔位置，而不是通用的 S3 時間點備份。
● 儲存卷閘道器提供 iSCSI 塊卷，而不是磁帶模擬。
● 檔案閘道器公開檔案協議並且不模擬磁帶庫。
● 無需重寫備份應用程式。
工作流：備份寫入虛擬磁帶→儲存活動磁帶→彈出→歸檔到虛擬磁帶架→需要時檢索。
保護支付欄位並改進 CloudFront 快取
傳輸加密可保護連線，而欄位級加密可在選定的敏感值透過中間系統時對其進行保護。
推薦架構
● 要求從檢視器到 CloudFront 使用 HTTPS。
● 需要從 CloudFront 到源的 HTTPS。
● 使用批准的公鑰為信用卡欄位配置 CloudFront 欄位級加密。
● 為可以安全快取的內容設定適當的 Cache-Control 指令。
設計理由
● 技術可行性：CloudFront 在轉發選定的表單欄位之前對其進行加密，並且只有私鑰持有者才能解密它們。
● 需求匹配：卡資料在傳輸路徑中始終受到保護，而較長的安全 TTL 則可提高快取命中率。
● 場景匹配：該應用程式使用 CloudFront 並接受敏感付款資訊。
● 工程常識：切勿僅僅為了提高效能而快取個性化支付響應。
應排除的替代方案
● 簽名 URL 控制訪問，但不加密選定的付款欄位。
● 自定義 TLS 證書可保護連線，但不提供欄位級保護。
● 源訪問身份保護 S3 源，而不是支付屬性。
● 轉發不必要的 User-Agent 或 Host 變體會導致快取碎片並降低命中率。
工作流：HTTPS 請求 → CloudFront 加密敏感欄位 → 源處理受保護的值 → 僅快取批准的內容。
突發準備電視投票
實時投票平臺需要全球交付、公共身份驗證、持久突發緩衝和可擴充套件的投票儲存。
推薦架構
● 在 ALB 和 EC2 Auto Scaling 組之前使用 CloudFront。
● 使用 Amazon Cognito 對檢視者進行身份驗證。
● 將提交的投票放入 Amazon SQS 中。
● 將排隊投票處理到 DynamoDB 中。
設計理由
● 技術可行性：CloudFront 和 Auto Scaling 吸收觀看流量，SQS 緩衝投票峰值，DynamoDB 擴充套件寫入。
● 需求匹配：即使處理暫時滯後，選票也會被保留。
● 場景匹配：公眾觀眾會產生短暫、極端的寫入突發。
● 工程常識：將投票接受與計票脫鉤。
應排除的替代方案
● S3靜態託管無法執行動態投票服務。
● 通用 IAM 角色假設不是公共使用者身份驗證。
● SAML 針對的是勞動力聯盟，而不是觀眾。
● RDS 與突發寫入量保持緊密耦合。
● IAM 並不直接對數百萬公共使用者進行身份驗證。
工作流：檢視器 → CloudFront → Cognito → ALB 和應用程式 → SQS → 工作人員 → DynamoDB 結果。
重新構建託管應用程式和資料庫服務平臺
平臺重構改變了託管平臺，同時保留了應用程式的核心架構和行為。
推薦遷移方案
● 將關聯式資料庫移至 Amazon RDS。
● 透過 AWS Elastic Beanstalk 部署應用程式。
● 保留應用程式邏輯和資料庫語義。
● 用託管部署、擴充套件、備份和故障轉移功能取代伺服器管理。
設計理由
● 技術可行性：Elastic Beanstalk 執行受支援的應用程式堆疊，而 RDS 提供託管關係引擎。
● 需求匹配：該方法無需完全重新設計即可減少運營和成本。
● 場景匹配：該應用程式可以使用 AWS 管理的等效項，只需進行有限的程式碼更改。
● 工程常識：採用託管服務，直接替換現有層。
應排除的替代方案
● 重新託管會將伺服器複製到 EC2 並保留大部分作業系統和資料庫管理。
● 重構改變了應用程式架構和程式碼，超出了規定的需求。
● 重新購買會用不同的產品替換應用程式，並且可能無法保留所需的行為。
● 將這種方法稱為重新託管忽略了向託管平臺服務的運營轉變。
工作流：評估相容性 → 將資料庫遷移到 RDS → 將應用程式部署到 Elastic Beanstalk → 測試 → 切換 → 退役源系統。
透過承擔的角色進行第三方審計
外部審計師應獲得僅限於所需審計行動的臨時跨賬戶訪問許可權。
推薦架構
● 在稽核賬戶中建立跨賬戶 IAM 角色。
● 信任審計員控制的 AWS 委託人。
● 附加只讀、資源範圍的許可權。
● 需要 STS 角色承擔並記錄 CloudTrail 中的活動。
設計理由
● 技術可行性：STS 返回臨時憑證，而不在稽核帳戶中建立永久使用者。
● 需求匹配：訪問許可權是可撤銷的、可歸屬的和最低許可權的。
● 場景匹配：第三方需要臨時審查許可權。
● 工程常識：審計並不能證明不受限制的管理是合理的。
應排除的替代方案
● 完全訪問違反了最低許可權。
● 長期 IAM 使用者金鑰更難安全輪換和撤銷。
● 即使有限的 IAM 使用者金鑰仍然不如臨時角色會話。
● 共享現有員工憑證會破壞問責制。
工作流：稽核員在家庭帳戶中進行身份驗證 → 承擔稽核角色 → 審查證據 → CloudTrail 記錄會話 → 憑證過期。
使用 ACM 和 ALB 終止公共 HTTPS
Application Load Balancer 背後的公共網站可以使用受信任的 AWS Certificate Manager 證書來實現簡單、低成本的 HTTPS。
推薦架構
● 請求大學域的公共 ACM 證書。
● 完成 DNS 驗證。
● 將證書附加到 ALB HTTPS 偵聽器。
● 將 HTTP 請求重定向到 HTTPS。
● 根據設計要求將解密的流量轉發到應用程式目標。
設計理由
● 技術可行性：ALB 直接與 ACM 整合並執行 TLS 終止。
● 需求匹配：公共 ACM 證書受信任、受管理，並且不會增加證書費用。
● 場景匹配：學習系統已在 EC2 例項前面使用 ALB。
● 工程常識：除非明確需要端到端應用程式加密，否則在託管負載均衡器處終止 TLS。
應排除的替代方案
● 預設情況下，ACM 私有 CA 證書不受公開信任，並且會引入私有 CA 成本。
● 在每個 EC2 例項上安裝證書會增加續訂和部署工作。
● 自簽名證書會觸發瀏覽器信任失敗。
● 購買並手動輪換第三方證書是可行的，但操作效率較低。
工作流：請求證書 → 驗證域 → 配置 HTTPS 偵聽器 → 重定向 HTTP → 測試信任和續訂。
在死信隔離之前可靠的 SQS 重試
死信佇列應該隔離重複失敗的工作，而不是經歷一個瞬時處理錯誤的訊息。
推薦配置
● 使可見性超時時間比正常處理時間長。
● 將重新驅動策略 maxReceiveCount 從 1 增加到合理的重試值，例如 10。
● 繼續對死信佇列深度發出警報。
● 僅在正常重試次數耗盡後才調查訊息。
設計理由
● 技術可行性：當處理失敗或訊息未刪除時，SQS 會使其再次可見，直到達到接收閾值。
● 需求匹配：多次嘗試可以在不改變工人隊伍的情況下提高完成率。
● 場景匹配：影片通常會在 20 到 40 分鐘內完成，低於一小時的可見超時時間。
● 工程常識：區分暫時的工作故障和永久無效的輸入。
應排除的替代方案
● 維持更多空閒 EC2 容量並不能解決失敗的訊息處理問題。
● 將可見性延長至兩小時會延遲重試，即使正常處理已在一小時內完成。
● 交付延遲會推遲首次可用性，並且在消費者失敗後無濟於事。
工作流：接收 → 處理期間隱藏 → 成功時刪除 → 失敗時重試 → 在閾值後移至 DLQ → 提醒開發人員。
使用 Aurora 全球資料庫進行區域恢復
跨區域的低 RPO 和 RTO 需要持續複製的資料庫和基於健康狀況的流量移動。
推薦架構
● 將 Aurora Global Database 與主要區域和輔助叢集結合使用。
● 在兩個區域部署應用程式容量。
● 配置 Route 53 執行狀況檢查和故障轉移路由。
● 測試管理的區域推廣和應用程式重新連線。
設計理由
● 技術可行性：Aurora 以低延遲跨區域複製儲存更改，並支援二次升級。
● 需求匹配：與快照恢復相比，該設計減少了資料丟失和恢復時間。
● 場景匹配：該應用程式需要兩個區域的關聯式資料庫。
● 工程常識：資料庫恢復和應用程式流量故障轉移必須一起測試。
應排除的替代方案
● RDS 多可用區仍位於一個區域內。
● 標準的跨區域只讀副本可以工作，但 Aurora Global Database 更直接地實現快速區域恢復。
● 手動 EC2 快照恢復會增加操作和延遲。
● 沒有現成應用程式容量的備份會延長 RTO。
工作流：主服務寫入 → 全域性複製 → 執行狀況故障 → 升級輔助 → Route 53 將流量傳送到恢復區域。
具有目標執行狀況的主動-主動 DNS
公共使用者可以透過 Route 53 路由到最低延遲的健康區域端點。
推薦架構
● 為區域彈性負載均衡器建立基於延遲的別名記錄。
● 啟用 Evaluate Target Health。
● 保持兩個區域處於活動狀態並能夠處理請求。
● 監控應用程式和資料層的執行狀況。
設計理由
● 技術可行性：Route 53 選擇延遲較低的終端節點並從答案中刪除不健康的別名目標。
● 需求匹配：該設計支援主動-主動區域流量和自動端點回避。
● 場景匹配：公共應用程式在多個區域的負載均衡器後面執行。
● 工程常識：DNS 健康路由僅在每個區域具有完整的應用程式依賴性時才起作用。
應排除的替代方案
● 私有託管區域無法路由公共使用者。
● DNSSEC 保護 DNS 完整性，但不執行基於執行狀況的故障轉移。
● 禁用目標健康評估會削弱自動恢復。
● 中轉 VPC 連線網路且不路由公共客戶端。
工作流：DNS查詢→延遲和健康評估→區域ELB答案→客戶端連線→刪除不健康的目標。
透過預留併發保護 Lambda 容量
高容量複製功能應具有明確的併發邊界，因此它不能消耗所有區域 Lambda 容量。
推薦架構
● 配置複製功能的預留併發。
● 根據下游容量和所需吞吐量確定預留大小。
● 監控 Lambda Throttles、ConcurrentExecutions、持續時間和錯誤指標。
● 建立 CloudWatch 警報以進行持續限制。
設計理由
● 技術可行性：預留併發保證了函式的容量，並限制了其最大併發執行。
● 需求匹配：其他 Lambda 函式保留容量，同時複製負載保持受控。
● 場景匹配：一項功能可能會嚴重爆發並影響同一區域中不相關的工作負載。
● 工程常識：保護共享平臺容量和較慢的下游系統。
應排除的替代方案
● 增加函式超時不會限制併發性。
● SQS 可以緩衝事件，但本身不會強制執行函式的區域併發共享。
● 重試退避可減少重複失敗，但不能保證隔離容量耗盡。
● 預配置併發可提高啟動準備情況，但不是直接請求的最大併發邊界。
工作流：事件到達→併發分配檢查→限制內呼叫→節流過量→持續壓力報警→調整容量。
分階段進行 Windows 修補以延長正常執行時間
大型 Windows 機群應按受控波次進行修補，以便維護不會立即消除所有服務容量。
推薦架構
● 使用標籤將例項分為兩個補丁組。
● 將批准的補丁基準與每個組相關聯。
● 建立不重疊的 Systems Manager 維護時段。
● 在不同的開始時間針對每個組執行 AWS-RunPatchBaseline。
設計理由
● 技術可行性：補丁管理器識別、安裝和報告批准的補丁；維護視窗控制執行時間。
● 需求匹配：單獨的視窗可防止整個機隊同時重新啟動。
● 場景匹配：數百個生產例項需要可重複的自動化，而不是單獨的維護。
● 工程常識：保持一個服務組可用，同時對另一個服務組進行修補和驗證。
應排除的替代方案
● 一個補丁組和一個視窗可以一起重新啟動整個佇列。
● CloudWatch 排程加上自定義狀態管理器命令是可能的，但是間接的且操作繁重。
● 沒有分離視窗的設計無法控制破壞邊界。
工作流：標記 → 組 → 基線 → 安排 A 組 → 驗證 → 安排 B 組 → 審查合規性。
自動 RDS 密碼輪換
Secrets Manager 可以透過本機 CloudFormation 資源生成、儲存和輪換 RDS 密碼。
推薦架構
● 在 Secrets Manager 中建立資料庫機密。
● 讓 CloudFormation 將金鑰連線到 RDS。
● 定義每 90 天呼叫輪換 Lambda 的 RotationSchedule。
● 授予應用程式執行時檢索機密的許可權。
設計理由
● 技術可行性：Secrets Manager 協調密碼更新和秘密值更改。
● 需求匹配：輪換是自動的，並且密碼不會嵌入到模板中。
● 場景匹配：秘密是 RDS 資料庫憑證。
● 工程常識：應用程式必須在輪換後重新整理連線。
應排除的替代方案
● Parameter Store 沒有等效的本機資料庫 RotationSchedule 資源。
● KMS 金鑰輪換會輪換加密金鑰材料，而不是儲存的資料庫密碼。
● EventBridge 加上自定義程式碼會重複本機輪換並增加風險。
● 硬編碼憑證在輪換後就會變得陳舊。
工作流：生成金鑰 → 部署 RDS → 輪換計劃觸發 Lambda → 密碼更改 → 應用程式檢索當前值。
使用 Systems Manager 進行自動化 EC2 救援
可以透過專門構建的 Systems Manager Automation Runbook 診斷受損的 Windows 或 Linux EC2 例項。
推薦流程
● 透過 Systems Manager Automation 執行 AWSSupport-ExecuteEC2Rescue。
● 提供受損的例項和所需的許可權。
● 讓工作流程收集診斷資訊並應用支援的修復措施。
● 在將例項返回服務之前檢查輸出。
設計理由
● 技術可行性：EC2Rescue 自動執行常見訪問和啟動故障排除步驟。
● 需求匹配：恢復比手動修復更快、更一致。
● 場景匹配：問題是立即例項損害。
● 工程常識：在構建自定義修復自動化之前，請使用支援操作手冊。
應排除的替代方案
● AWS Config 和 State Manager 不提供此救援工作流程。
● 維護視窗計劃任務並且不需要立即修復。
● OpsWorks Chef Automate 新增了不相關的配置基礎設施。
● 會話管理器可以提供訪問許可權，但本身不會診斷和修復問題。
工作流：啟動自動化→根據需要建立幫助資源→診斷→修復→審查報告→驗證例項。
具有隻讀角色的中央審計員帳戶
外部審計訪問應使用專用審計賬戶的臨時跨賬戶角色。
推薦架構
● 建立專用稽核員 AWS 賬戶。
● 在每個目標帳戶中建立只讀角色。
● 信任審計賬戶經批准的委託人。
● 需要 STS 角色承擔並使用 CloudTrail 記錄活動。
設計理由
● 技術可行性：STS 頒發每個目標角色範圍內的臨時憑證。
● 需求匹配：稽核員透過可跟蹤會話獲得最低許可權的訪問許可權。
● 場景匹配：必須一致地審查多個帳戶。
● 工程常識：將稽核員身份、許可權和會話歷史記錄與操作使用者分開。
應排除的替代方案
● 長期 IAM 使用者金鑰會增加輪換和暴露風險。
● 在每個帳戶中建立目錄標識會增加不必要的管理。
● 共享現有員工密碼會破壞問責制。
● 一項廣泛的管理員角色超出了審計需求。
工作流：稽核員集中登入 → 承擔目標只讀角色 → 審查資源和日誌 → 會話過期。
滿足數百萬使用者偏好的安全儲存
每個使用者的小首選項是直接的鍵值工作負載，不應跨多個儲存系統拆分。
推薦架構
● 在 Amazon DynamoDB 中為每個使用者儲存一項。
● 透過網路身份聯合對社交使用者進行身份驗證。
● 使用STS臨時憑證。
● 應用 DynamoDB 細粒度訪問控制，以便每個使用者只能訪問允許的專案。
設計理由
● 技術可行性：DynamoDB 透過託管可用性和水平擴充套件來處理數百萬條小記錄。
● 需求匹配：該設計具有高可用性、經濟高效、可擴充套件的特點，並且避免了長期的移動憑證。
● 場景匹配：每個首選項記錄只有大約 4 KB，自然由使用者 ID 定址。
● 工程常識：在一個資料庫中保留一個小的原子記錄，除非第二個儲存服務解決了真正的限制。
應排除的替代方案
● RDS 只讀副本可以擴充套件讀取，但資料庫帳戶對於數百萬社交使用者來說並不是一個實用的身份模型。
● 公共應用程式伺服器加上 RDS 新增了伺服器和連線管理。
● 將每個微小的首選項物件儲存在 S3 中並將其指標儲存在 DynamoDB 中會使請求和複雜性增加一倍。
工作流：社交登入→身份令牌→STS角色會話→專案級授權→讀取或更新首選項。
無伺服器訂單和發貨工作流程
物流工作流程需要持久的訂單狀態、明確的流程編排和事件驅動的發貨更新。
推薦架構
● 在 Amazon DynamoDB 中儲存訂單和狀態。
● 使用 AWS Step Functions 對處理步驟進行建模。
● 呼叫 Lambda 函式進行驗證、狀態更改和外部服務呼叫。
● 當貨件掃描或遞送事件到達時觸發 Lambda 更新。
設計理由
● 技術可行性：Step Functions 管理狀態、重試、分支和服務整合； DynamoDB 提供可擴充套件的訂單記錄。
● 需求匹配：該工作流是無伺服器的、事件驅動的，並且運營開銷較低。
● 場景匹配：訂單經過定義的階段，發貨事件非同步更新其狀態。
● 工程常識：將持久的業務狀態儲存在資料庫中，將工作流程進度儲存在協調器中，而不是儲存在計算記憶體中。
應排除的替代方案
● AWS Batch 專為批次計算而設計，而不是互動式訂單狀態編排。
● EFS 是檔案儲存，並不對工作流程狀態進行建模。
● SQS 可以解耦步驟，但本身並不表示分支、重試和端到端狀態。
● 通知服務不會取代交易訂單儲存。
工作流：建立訂單 → 寫入 DynamoDB 專案 → 啟動狀態機 → 執行步驟 → 接收發貨事件 → Lambda 更新狀態。
安全的第三方跨賬戶訪問
第三方訪問應使用臨時角色憑據和外部 ID，以減少混淆代理風險。
推薦架構
● 在資源擁有賬戶中建立 IAM 角色。
● 僅授予所需的資源操作。
● 在角色信任策略中信任提供商的 AWS 賬戶。
● 需要客戶提供唯一的外部 ID。
● 讓提供商呼叫 STS AssumeRole。
設計理由
● 技術可行性：僅當可信主體和外部 ID 條件匹配時，STS 才會頒發臨時憑證。
● 需求匹配：如果沒有客戶建立的長期使用者，提供商將獲得有限的、可撤銷的訪問許可權。
● 場景匹配：外部組織管理多個客戶的資源。
● 工程常識：將許可權放入客戶帳戶中並需要客戶特定的信任訊號。
應排除的替代方案
● IAM 使用者建立長期憑證並難以退出。
● 僅信任提供者帳戶可能會將角色暴露於混亂的副場景中。
● 資源策略不提供一般的多服務管理。
● 透過 Secrets Manager 共享訪問金鑰不會將其轉換為臨時會話。
工作流：提供者使用外部 ID 請求角色 → 信任策略評估 → STS 返回臨時憑證 → 發生範圍內的操作。
在 API 閘道器阻止 SQL 注入
應在託管 API 入口點過濾注入攻擊，同時應記錄防火牆配置更改以供稽核。
推薦架構
● 將 AWS WAF Web ACL 與 Amazon API Gateway 關聯。
● 啟用檢測 SQL 注入模式的託管或自定義規則。
● 使用 AWS Config 記錄 Web ACL、規則和配置更改。
● 檢視 WAF 指標和阻止的請求日誌。
設計理由
● 技術可行性：AWS WAF 與 API Gateway 整合，並在後端呼叫之前檢查 HTTP 請求。
● 需求匹配：該解決方案可阻止已展示的攻擊模式，並以低成本提供歷史配置跟蹤。
● 場景匹配：該應用程式已使用 API Gateway 和 Lambda，因此不需要新的負載平衡層。
● 工程常識：阻止攻擊類別而不是觀察到的某一源 IP。
應排除的替代方案
● API 閘道器無法按照建議的方式放置在 ALB 後面。
● WAF 不直接附加到各個 Lambda 函式。
● 防火牆管理器集中策略管理，但不是所請求的配置歷史記錄器。
● VPC 網路 ACL 不會保護託管 API 閘道器終端節點免受 SQL 注入內容的影響。
工作流：請求→WAF檢查→API閘道器→Lambda→資料層；配置記錄策略更改。
補丁執行和批准的 AMI 監控
安全補丁和 AMI 合規性是單獨的控制：一個更改例項狀態，另一個檢測配置偏差。
推薦架構
● 使用 Systems Manager 補丁管理器基線定義已批准的 Windows 補丁。
● 跨託管例項安排或執行補丁操作。
● 使用 AWS Config 託管規則來評估正在執行的 EC2 例項是否使用批准的 AMI。
● 當檢測到不合規例項時傳送通知。
設計理由
● 技術可行性：補丁管理器安裝批准的更新； AWS Config 評估資源配置而不阻止啟動。
● 需求匹配：例項會收到最新的安全修復程式，並且開發人員在報告違規行為時仍可以自由啟動。
● 場景匹配：該組織希望對 AMI 選擇進行監控，而不是預防性拒絕。
● 工程常識：僅當阻塞可接受時才使用預防性控制措施；否則迅速檢測並通知。
應排除的替代方案
● GuardDuty 檢測可疑行為，而不是修補程式或批准的 AMI 合規性。
● IAM 拒絕會阻礙開發人員，違反操作要求。
● Shield Advanced 可防禦 DDoS 攻擊，並且不會修補作業系統或評估 AMI。
工作流：批准補丁 → 部署補丁 → 評估 AMI ID → 標記合規性 → 通知 → 透過受控更換流程進行修復。
使用 NAT 閘道器替換 NAT 例項
私有子網需要可靠的出站網際網路訪問，而無需維護自定義 NAT 伺服器群。
推薦架構
● 在公有子網中建立 NAT 閘道器。
● 關聯彈性IP地址。
● 確保公有子網路由到 Internet 閘道器。
● 將私有子網預設路由指向 NAT 閘道器。
● 當需要 AZ 獨立性時，每個可用區使用一個 NAT 閘道器。
設計理由
● 技術可行性：NAT 閘道器對出站連線和返回流量執行託管源轉換。
● 需求匹配：與 NAT 例項相比，它提供更高的可用性和頻寬，並且管理更少。
● 場景匹配：現有的 NAT 例項不可靠並且限制了吞吐量。
● 工程常識：保留沒有公共 IP 的私有工作負載，並將面向網際網路的出口放置在公共子網中。
應排除的替代方案
● 增加 NAT 例項大小可以保留修補和故障轉移責任。
● 私有子網中的 NAT 閘道器無法到達 Internet 閘道器。
● Internet 閘道器路由不會使私有地址例項可以直接透過 Internet 訪問。
● VPC 對等互連不提供網際網路出口。
工作流：私有例項 → 預設路由 → NAT 閘道器 → 網際網路閘道器 → 目的地 → 透過 NAT 返回。
邊緣裝置特定的靜態內容
靜態內容可以在全球範圍內交付，而邊緣邏輯則為每種裝置型別選擇適當的版本。
推薦架構
● 將靜態資產移動到 Amazon S3。
● 將儲存桶配置為 CloudFront 源。
● 使用 Lambda@Edge 檢查檢視器的 User-Agent 標頭。
● 重寫或路由請求到正確的裝置特定物件。
● 在邊緣快取所選響應。
設計理由
● 技術可行性：Lambda@Edge 在 CloudFront 請求處理期間執行，並且可以根據標頭更改請求的 URI。
● 需求匹配：在使用者附近選擇內容並進行快取，從而減少 EC2 負載和響應時間。
● 場景匹配：該應用程式為不同的裝置類別提供不同的靜態資源。
● 工程常識：將靜態路由決策移至內容交付層，而不是擴充套件通用伺服器。
應排除的替代方案
● 網路負載均衡器在第 4 層執行，無法檢查 User-Agent。
● Route 53 路由 DNS 查詢，無法評估 HTTP 標頭。
● 簡單的 CloudFront 快取行為無法在沒有邊緣邏輯的情況下對任意裝置標頭進行分類。
● 將所有靜態內容保留在 EC2 上可以保留原始負載問題。
工作流：請求 → 邊緣讀取標頭 → URI 重寫 → S3 物件 → 快取的裝置特定響應。
移動內容的託管 REST 後端
移動 REST 服務應使用託管身份驗證、無伺服器 API、可擴充套件後設資料儲存和直接物件上傳。
推薦架構
● 將 Amazon API Gateway 與 AWS Lambda 結合使用。
● 使用 Amazon Cognito 對使用者進行身份驗證。
● 將應用程式後設資料儲存在 DynamoDB 中。
● 將檔案儲存在 Amazon S3 中。
● 釋出預簽名的 S3 URL 以進行授權上傳和下載。
設計理由
● 技術可行性：API Gateway 呼叫 Lambda，Cognito 提供身份，DynamoDB 擴充套件記錄，預簽名 URL 提供限時物件訪問。
● 需求匹配：該設計無需管理伺服器或透過 Lambda 代理大型物件即可擴充套件。
● 場景匹配：REST 操作在使用者交換檔案時管理後設資料。
● 工程常識：在 S3 上保持大量有效負載傳輸，並使 API 功能專注於授權和業務邏輯。
應排除的替代方案
● EC2 Web 佇列增加了修補和擴充套件工作。
● 在 DynamoDB 中儲存大檔案既昂貴又不必要。
● 在移動應用程式中嵌入永久 AWS 金鑰是不安全的。
● 透過 Lambda 路由所有檔案位元組會增加延遲、成本和執行時限制。
工作流：使用者身份驗證 → API 授權請求 → Lambda 建立預簽名 URL → 客戶端將物件直接傳輸到 S3。
成本最佳化的分析和持續報告
可中斷分析和持續可用的報告具有不同的計算要求。
推薦架構
● 在基於 EC2 Spot 的 Auto Scaling 組上執行大型分析作業。
● 設計具有檢查點和重試支援的作業。
● 在 Amazon ECS Fargate 上執行持續報告服務。
● 獨立縮放每個元件。
設計理由
● 技術可行性：Spot 為可重新啟動的處理提供折扣計算，而 Fargate 則執行長期存在的容器，無需伺服器管理。
● 需求匹配：Spot 節省了大約 10,000 個分析計算小時，同時報告仍然持續可用。
● 場景匹配：分析是面向批次的，但報告服務於持續的使用者請求。
● 工程常識：不要對必須始終響應的元件使用可中斷容量。
應排除的替代方案
● 所有按需容量都是可行的，但對於容錯分析來說成本過高。
● 當分析需求變化且承諾不確定時，預留容量效率低下。
● 使用 Spot 進行報告服務可能會導致明顯的中斷。
● App Runner 可以託管 Web 服務，但它不會提高分析層的批次計算經濟性。
工作流：提交分析工作 → 擴充套件 Spot 工作人員 → 儲存結果 → 報告容器讀取結果 → Fargate 擴充套件服務需求。
基於位置的移動優惠
較短的交付視窗需要持久的位置緩衝、快速報價查詢、可擴充套件處理和託管移動推送。
推薦架構
● 在 SQS 中緩衝傳入位置。
● 根據待辦事項擴充套件 API 或工作例項。
● 在 DynamoDB 中儲存商品。
● 透過 SNS 移動推送傳送選定的優惠。
設計理由
● 技術可行性：SQS吸收突發，DynamoDB提供低延遲查詢，SNS達到移動推送服務。
● 需求匹配：可以在短時間內選擇並交付附近的報價。
● 場景匹配：數以百萬計的移動位置可能會不定期到達。
● 工程常識：將位置接收與推送傳送分開。
應排除的替代方案
● Kinesis 和 SES 不形成直接的移動推送工作流程。
● 直接連線到移動運營商並不是裝置 GPS 或平臺推送的工作方式。
● EC2 無法直接替代託管移動推送通道。
● 沒有佇列的同步處理存在丟棄事件的風險。
工作流：裝置位置 → SQS → 工作人員查詢 DynamoDB → SNS 移動推送 → 電話通知。
提供大型預測資料集
伺服器群共享的大型預測輸出可以使用 EFS、彈性查詢伺服器和短 CloudFront 快取。
推薦架構
● 將生成的 20 GB 預測儲存在 EFS 上。
● 在 ELB 後面的 Auto Scaling 組中執行查詢伺服器。
● 在 CloudFront 中快取響應 15 分鐘。
設計理由
● 技術可行性：EFS 為所有伺服器提供共享檔案訪問，Auto Scaling 處理併發，CloudFront 吸收重複查詢。
● 需求匹配：該設計支援 1,500 至 15,000 個併發使用者和頻繁的資料集替換。
● 場景匹配：每 15 分鐘更換一次大型預報。
● 工程常識：避免在索引獲得其成本之前對完全重新生成的資料建立索引。
應排除的替代方案
● OpenSearch 每 15 分鐘索引 10 億個點是昂貴的。
● 更改邊緣邏輯並不能修復低效的索引工作流程。
● 每次更新建立 10 億個 S3 物件會產生極大的物件和請求開銷。
● 一臺固定查詢伺服器無法安全地處理該範圍。
工作流：寫入 EFS 的預測 → 彈性伺服器對其進行查詢 → CloudFront 快取響應 15 分鐘。
兩區域關係應用程式彈性
讀取密集型應用程式可以使用一個高度可用的寫入器區域和輔助區域讀取器，同時保持應用程式層在兩個區域中處於活動狀態。
推薦架構
● 在兩個區域中部署 Auto Scaling 應用程式層。
● 使用 Amazon Aurora 全球資料庫。
● 將寫入保留在主區域中，並使用區域內端點進行讀取。
● 按地理位置路由使用者，並將經過執行狀況檢查的故障轉移配置到執行狀況良好的區域。
設計理由
● 技術可行性：Aurora 全球資料庫透過一名主要寫入者和區域讀取者跨區域複製關係資料。
● 需求匹配：區域應用程式群提供彈性，而資料庫保留關係語義。
● 場景匹配：北美和亞洲使用者受益於區域讀取和受控故障轉移。
● 工程常識：除非明確設計了衝突解決方案，否則應避免使用兩個獨立的可寫資料庫。
應排除的替代方案
● 獨立可寫的RDS MySQL資料庫並不能透過簡單的複製成為安全的雙活主。
● 多可用區可以防止可用區故障，而不是整個區域故障。
● 快照是恢復工件，而不是活動的區域讀取解決方案。
● 多值路由可能會返回多個健康端點，而不是實施預期的區域故障轉移策略。
工作流：寫入主 → 全域性複製 → 本地讀取 → 監控執行狀況 → 將流量故障轉移到倖存區域。
擴充套件受許可證限制的 EC2 應用程式
獲得網路介面身份許可的應用程式需要一個受控的可重用 ENI 池和集中分配的許可證檔案。
推薦架構
● 維護一個 ENI 池，以保留許可證繫結的身份。
● 將許可證檔案安全地儲存在 S3 中。
● 使用引導邏輯在橫向擴充套件期間分配一個未使用的 ENI 和許可證。
● 使用 Lambda 維護 Parameter Store 中的當前資料庫地址。
● 在例項引導期間檢索當前地址。
設計理由
● 技術可行性：ENI 在例項替換過程中保留網路身份，而引數儲存將更改的配置與映像分開。
● 需求匹配：機群可擴充套件，無需複製許可證或烘焙過時的資料庫地址。
● 場景匹配：許可與 ENI 身份相關聯。
● 工程常識：以原子方式協調分配，以便兩個例項無法申請同一個許可證。
應排除的替代方案
● 具有一個許可證的一個 AMI 無法安全擴充套件。
● 在啟動時解析 DNS 仍然會留下陳舊的本地地址。
● 將每個許可證烘焙到 AMI 中都有重複使用的風險。
● 地址更改後靜態資料庫 IP 會失敗。
工作流：橫向擴充套件 → 申請 ENI 和許可證 → 讀取引數儲存 → 配置應用程式 → 終止時釋放資產。
全球遊戲 API 的長期成本最佳化
可預測的多年應用程式可以將承諾的計算定價與靜態資產的邊緣交付結合起來。
推薦架構
● 在適當大小的 EC2 例項上執行 GraphQL API。
● 預期三年內穩定基線的購買保留定價。
● 將 API 佇列放置在合適的負載均衡器後面。
● 將靜態資產儲存在持久的原始儲存中，並透過 CloudFront 分發它們。
設計理由
● 技術可行性：EC2 支援現有的 API 執行時，CloudFront 提供來自全球邊緣位置的快取資產。
● 需求匹配：預留定價降低了長期基準成本，而邊緣快取則提高了全球響應能力。
● 場景匹配：服務預期壽命超過三年，核心需求穩定。
● 工程常識：僅提交可預測的基線並保持突發容量的靈活性。
應排除的替代方案
● 所有按需容量都忽略了較長的、可預測的服務壽命。
● 直接從 API 伺服器提供靜態檔案會浪費計算和頻寬。
● 僅現貨 API 容量存在客戶可見的中斷風險。
● 如果當前的 API 架構能夠滿足功能需求，則無需重新平臺化至不相關的服務。
工作流：客戶端 → 資產的 CloudFront → GraphQL 的負載均衡器 → 預留基線 EC2 → 根據需要擴充套件額外容量。
釋出 S3 靜態網站
S3 網站端點必須能夠讀取網站物件。 DNS 路由本身並不授予物件訪問許可權。
推薦配置
● 在正確命名的 S3 儲存桶上啟用靜態網站託管。
● 配置索引文件。
● 將 Route 53 別名記錄指向區域 S3 網站終端節點。
● 透過所需的儲存桶策略和公共訪問設定，允許對網站物件進行公共讀取訪問。
設計理由
● 技術可行性：當儲存桶授權允許匿名讀取時，網站端點將提供配置的索引物件。
● 需求匹配：訪問者可以透過自定義域檢索公共網站內容。
● 場景匹配：該網站有意公開並直接從 S3 網站端點託管。
● 工程常識：檢查完整的請求鏈：DNS 解析、端點選擇、儲存桶策略、公共訪問塊和物件存在。
應排除的替代方案
● 自定義錯誤文件是可選的，並且不控制索引的可用性。
● 配置索引文件時，訪問者不需要附加index.html。
● Route 53 傳播通常很快，等待並不能修復授權失敗。
工作流：解析域名→到達網站端點→評估儲存桶訪問→返回索引物件和引用的資產。
使用流量映象捕獲完整資料包
需要資料包有效負載的安全分析需要完整的資料包副本，而不是連線後設資料。
推薦架構
● 在選定的 EC2 彈性網路介面上啟用 VPC 流量映象。
● 將映象流量傳送到檢查裝置或支援的監控目標。
● 過濾會話以僅捕獲所需的協議和源。
設計理由
● 技術可行性：流量映象從 ENI 複製資料包標頭和有效負載。
● 需求匹配：分析師可以檢查完整的網路對話。
● 場景匹配：該要求涵蓋 HTTP 請求之外的例項網路流量。
● 工程常識：限制捕獲範圍，因為完整的資料包會消耗頻寬並且可能包含敏感資料。
應排除的替代方案
● VPC 流日誌包含地址、埠、操作和後設資料，而不是負載。
● ALB 訪問日誌包含請求後設資料而不是完整的資料包。
● AppFlow 不是資料包分析目標。
● WAF 日誌描述了檢查的 Web 請求，但不捕獲所有例項流量。
工作流：例項 ENI → 映象會話和過濾器 → 映象目標 → 資料包檢查 → 安全證據保留。
使用兩個快取層改善頁面負載
CloudFront 和 ElastiCache 解決不同的效能問題，可以一起使用。
推薦架構
● 在 CloudFront 中快取可重用的網站內容。
● 將會話和經常訪問的查詢結果儲存在 ElastiCache 中。
● 將 EC2 Auto Scaling 和 RDS 保留為權威的計算和資料層。
設計理由
● 技術可行性：CloudFront 減少了網路距離和源請求； ElastiCache 減少後端資料庫讀取。
● 需求匹配：無需部署第二個區域即可改善頁面響應。
● 場景匹配：該應用程式提供可快取的內容和動態會話或查詢。
● 工程常識：測量快取命中率並避免錯誤地快取個性化響應。
應排除的替代方案
● 狀態管理器配置例項，不會取代 Auto Scaling。
● 降低縮放觸發器會增加計算量，但不會消除重複工作。
● 第二個區域引入了成本和資料管理的複雜性。
● 資料庫擴充套件本身並不能改善全域性靜態交付。
工作流：檢視器 → CloudFront → 應用程式未命中 → ElastiCache → RDS 快取未命中。
將物聯網資料流式傳輸到分析倉庫
物聯網遙測需要託管流傳輸、持久保留、歸檔生命週期和轉型的倉庫分析。
推薦架構
● 使用 Kinesis Data Firehose 攝取記錄。
● 將原始資料傳送到 S3。
● 使用生命週期策略將舊資料存檔到 Glacier 類。
● 使用 EMR 處理資料並將整理的結果載入到 Redshift 中。
設計理由
● 技術可行性：Firehose 緩衝並傳輸流，S3 持久儲存流，EMR 和 Redshift 支援分析。
● 需求匹配：該管道處理連續事件和長期成本控制。
● 場景匹配：裝置發出持續的流。
● 工程常識：保留原始資料，以便可以重播轉換。
應排除的替代方案
● 直接 S3 攝取缺乏託管流緩衝區。
● Athena 不接受流事件或將它們儲存在 DynamoDB 中。
● DynamoDB 和 Data Pipeline 增加了寫入成本和計劃編排。
● Glacier 是存檔目標，而不是攝取層。
工作流：裝置流 → Firehose → S3 原始區域 → 生命週期存檔 → EMR 轉換 → Redshift 分析。
解決 CloudFormation 中的當前 AMI
CloudFormation 可以解析包含當前 AMI ID 的 AWS 管理的公共 Systems Manager 引數。
推薦架構
● 在模板中引用適當的公共 SSM AMI 引數。
● 在堆疊建立或更新期間解決它。
● 當車隊應該採用更新的映像時，有意執行 update-stack 。
● 使用受控滾動更新策略。
設計理由
● 技術可行性：CloudFormation 引數型別可以解析 Parameter Store 中的當前 AMI 識別符號。
● 需求匹配：模板避免硬編碼區域 AMI ID。
● 場景匹配：該組織希望透過有意的堆疊更新來獲得最新的 AWS 映像。
● 工程常識：最新並不意味著未經測試；在生產推出之前驗證影象。
應排除的替代方案
● 服務目錄分發產品，但本身並不解析每個最新的 AMI。
● AWS Config 評估合規性，不是 AMI 查詢服務。
● 狀態管理器維護例項配置，不是 CloudFormation AMI 引數源。
● 在堆疊更新之前，現有例項不會更改。
工作流：模板解析SSM引數→啟動模板更改→滾動堆疊更新→健康驗證。
改善邊緣的全域性登入延遲
透過在使用者附近執行適當的請求邏輯併為伺服器錯誤提供源故障轉移，可以提高全域性身份驗證效能。
推薦架構
● 使用 Lambda@Edge 進行與身份驗證相關的處理，該處理可以安全地在 CloudFront 邊緣站點執行。
● 配置具有主要源和輔助源的 CloudFront 源組。
● 當主伺服器返回選定的錯誤（包括相關閘道器故障）時進行故障轉移。
設計理由
● 技術可行性：Lambda@Edge 在 CloudFront 請求或響應事件期間執行；源故障轉移將符合條件的請求重定向到備份源。
● 需求匹配：該組合減少了與距離相關的登入延遲，並限制了 HTTP 504 失敗的影響，且成本低於完全全域性複製。
● 場景匹配：該應用程式已經是無伺服器的，併為全球使用者提供服務。
● 工程常識：僅移動合適的邊緣邏輯，並保留需要權威後端狀態的操作的起源。
應排除的替代方案
● 多個VPC和中轉VPC不會直接加速身份驗證。
● 完整的多區域應用程式部署可以工作，但成本更高。
● 增加快取 TTL 有助於靜態物件，而不是減慢動態登入處理速度，並且通常不應廣泛快取身份驗證響應。
工作流：檢視器請求→邊緣身份驗證步驟→主要來源→配置錯誤時自動故障轉移。
具有漸進式 Lambda 部署的無伺服器 CI/CD
無伺服器交付管道應該對應用程式進行建模、構建和測試工件、編排釋出以及安全地轉移生產流量。
推薦架構
● 使用 AWS SAM 定義 Lambda、API Gateway、DynamoDB 和相關許可權。
● 使用 CodeBuild 安裝依賴項、執行測試和打包工件。
● 使用 CodePipeline 協調原始碼、構建、批准和部署階段。
● 使用 CodeDeploy 部署首選項逐步進行 Lambda 流量轉移和回滾。
設計理由
● 技術可行性：SAM 轉換為 CloudFormation，而 CodeDeploy 可以使用 Lambda 別名進行金絲雀或線性部署。
● 需求匹配：該管道自動構建和釋出，同時限制生產影響。
● 場景匹配：新的架構完全是無伺服器的。
● 工程常識：將基礎架構和應用程式部署的版本保持在一起，並在失敗警報時自動回滾。
應排除的替代方案
● 無伺服器應用程式儲存庫分發可重用的應用程式，但不是完整的 CI/CD 管道。
● OpsWorks 不是 Lambda、API Gateway 和 DynamoDB 的天然配置服務。
● 構建程式碼或轉移 Lambda 別名流量不需要 Systems Manager Automation。
工作流：提交→構建和測試→打包→部署堆疊→轉移別名流量→監控→完成或回滾。
EC2 上的 Oracle RAC 備份
Oracle RAC 必須保留在 EC2 上，因為 Amazon RDS for Oracle 不提供 RAC。
推薦架構
● 在 EC2 上執行支援的 Oracle RAC 叢集。
● 將資料庫卷儲存在所需的 EBS 架構上。
● 使用 Amazon Data Lifecycle Manager 進行計劃的 EBS 快照。
● 協調崩潰一致或應用程式一致的備份過程。
設計理由
● 技術可行性：EC2 保留 RAC 控制，而 DLM 自動化可重複的快照策略。
● 需求匹配：該設計在不改變資料庫架構的情況下減少了備份管理。
● 場景匹配：RAC 相容性是強制性的。
● 工程常識：快照編排必須考慮所有叢集卷和資料庫的一致性。
應排除的替代方案
● RDS Oracle RAC 不是受支援的服務配置。
● RDS 多可用區不會將 RDS 轉變為 RAC。
● 手動 shell 快照很脆弱且難以稽核。
● 遷移到另一個引擎會擴大範圍，並可能會破壞應用程式相容性。
工作流：停頓或協調資料庫 → DLM 快照策略 → 驗證所有卷 → 測試恢復 → 按策略保留。
自動化混合補丁管理
混合資產可以對 EC2 和註冊的本地伺服器使用一個 Systems Manager 補丁工作流程。
推薦架構
● 在符合條件的伺服器上安裝並註冊 SSM 代理。
● 在 Systems Manager 補丁管理器中定義批准的補丁基準。
● 使用標籤或補丁組屬性對伺服器進行分組。
● 使用維護時段來安排 AWS-RunPatchBaseline。
● 集中審查補丁合規性。
設計理由
● 技術可行性：Systems Manager 透過代理管理 EC2 例項和混合啟用的伺服器。
● 需求匹配：基線和時間表保持同步和自動化，操作工作量很少。
● 場景匹配：該組織已經在本地和雲伺服器上維護補丁策略。
● 工程常識：在提高自動化頻率之前標準化政策和報告。
應排除的替代方案
● 單獨的 cron 指令碼會建立不同的補丁邏輯和報告。
● 重建每個伺服器映像不會直接修補長期存在的本地計算機。
● AWS Config 記錄配置但不安裝作業系統補丁。
● 手動控制檯修補無法擴充套件或證明一致性。
工作流：註冊伺服器→分配補丁組→評估基線→在維護時段執行→按配置重新啟動→報告合規性。
可擴充套件的媒體網站和成本審查
動態媒體站點應將持久媒體交付與彈性應用程式處理分開，並使用本機成本分析服務。
推薦架構
● 將媒體儲存在 S3 中並透過 CloudFront 傳送。
● 在 ELB 後面的 Auto Scaling 中執行動態 Web 伺服器。
● 使用 Cost Explorer 和 Trusted Advisor 來確定節省的成本。
設計理由
● 技術可行性：S3 和 CloudFront 擴充套件媒體交付，而 Auto Scaling 處理可變的伺服器端流量。
● 需求匹配：該設計提高了效能、彈性和成本可見性。
● 場景匹配：該應用程式包含靜態媒體和伺服器端邏輯。
● 工程常識：不要透過應用程式伺服器路由大量媒體。
應排除的替代方案
● CloudFront 無法直接使用 EFS 作為源。
● 當媒體移動到 S3 時，不需要儲存最佳化的 Web 例項。
● 合併賬單彙總費用，但不是成本分析工具。
● 完全靜態的 S3 站點無法執行伺服器端處理。
● 跨區域複製會增加不必要的成本。
工作流：靜態媒體 → CloudFront 和 S3；動態請求→ELB和Auto Scaling；成本 → 探索者和顧問。
為不常用的 Oracle 資料提供經濟高效的儲存
歷史資料庫資料量大、訪問頻率低且以吞吐量為導向，不需要高階 SSD 效能。
推薦架構
● 使用 AWS Database Migration Service 移動 Oracle 工作負載或資料。
● 當資料庫保留在 EC2 上時，將不經常訪問的歷史資料放置在 EBS sc1 冷 HDD 捲上。
● 驗證工作負載不需要啟動卷支援或高隨機 IOPS。
設計理由
● 技術可行性：DMS 遷移資料庫記錄，而 sc1 為大型連續工作負載提供低成本 HDD 儲存。
● 需求匹配：該設計最大限度地減少了冷歷史資料的儲存費用。
● 場景匹配：訪問不頻繁，吞吐量比低延遲隨機 I/O 更重要。
● 工程常識：根據實際訪問模式而不是最大可能的效能來選擇儲存。
應排除的替代方案
● 伺服器遷移服務移動伺服器而不是提供資料庫遷移工作流程。
● gp2 SSD 成本更高，並且針對通用隨機 I/O。
● st1 吞吐量最佳化 HDD 適合頻繁訪問的吞吐量工作負載，且成本高於 sc1。
● 對於冷歷史記錄，不需要配置 IOPS SSD。
工作流：評估 I/O → 使用 DMS 遷移 → 連線並格式化 sc1 → 驗證吞吐量 → 監控訪問模式。
具有 STS 憑證的 LDAP 聯合
LDAP 對企業使用者進行身份驗證，而 IAM 角色和 STS 則授權對 AWS 資源的臨時訪問。
推薦模式
● 讓應用程式根據 LDAP 驗證憑證、將使用者對映到 IAM 角色並呼叫 STS。
● 或者使用執行 LDAP 身份驗證並請求範圍內聯合憑據的自定義身份代理。
設計理由
● 技術可行性：在受信任的應用程式或代理驗證身份後，STS 會頒發臨時角色憑據。
● 需求匹配：使用者保留公司憑證，無需永久 IAM 使用者。
● 場景匹配：該應用程式已經依賴於 LDAP。
● 工程常識：將身份驗證與 AWS 授權分開並保持會話短暫。
應排除的替代方案
● STS 不直接驗證 LDAP 密碼。
● IAM 本身無法驗證公司 LDAP 使用者名稱和密碼。
● 長期訪問金鑰會重複身份生命週期並增加憑證暴露。
● 網路連線本身並不能提供聯合。
工作流：使用者登入 → LDAP 驗證 → 角色對映 → STS 請求 → 臨時憑證 → 簽名的 AWS 請求。
附屬賬戶的集中治理
一個 AWS 組織可以集中子公司賬單並透過組織單位應用服務限制。
推薦架構
● 將所有子公司置於一個 AWS 組織中。
● 根據治理需要將帳戶分組到 OU。
● 附加服務控制策略以定義最大服務和操作。
● 使用合併計費進行集中成本管理。
設計理由
● 技術可行性：SCP 限制成員帳戶許可權，而合併計費則彙總費用。
● 需求匹配：母公司集中管理服務邊界和成本。
● 場景匹配：子公司仍保留獨立的 AWS 賬戶。
● 工程常識：SCP 設定護欄；帳戶 IAM 仍授予實際許可權。
應排除的替代方案
● 單獨的合併計費不會施加服務限制。
● 一個帳戶不能屬於多個組織。
● 每個子公司都有一個獨立的組織，避免了單一的母公司治理層次結構。
● 服務配額限制數量，而不是允許哪些 API 或服務。
工作流：邀請賬戶 → 安排 OU → 附加 SCP → 配置賬戶 IAM → 審查綜合成本。
私有跨 VPC 連線和拒絕流量監控
同區域 VPC 可以透過對等互連進行私密通訊，而流日誌則記錄接受和拒絕的流量。
推薦架構
● 將每個部門 VPC 與中央應用程式 VPC 對等。
● 新增所需的路由和安全規則。
● 啟用 VPC 流日誌以捕獲拒絕的記錄和源地址。
● 將日誌傳送到 CloudWatch Logs。
● 使用日誌訂閱將記錄轉發到安全帳戶。
設計理由
● 技術可行性：對等互連透過 AWS 網路路由流量，無需公共 Internet；流日誌記錄網路介面流量決策。
● 需求匹配：該設計提供私人通訊和對被拒絕請求的可見性。
● 場景匹配：VPC 位於一個區域並需要訪問一項中央服務。
● 工程常識：在引入無法解決任何指定問題的加密裝置或外部電路之前，請使用直接 AWS 網路。
應排除的替代方案
● 單獨的 IPsec 隧道新增閘道器和路由操作。
● 第三方中轉 VPC 過多，AWS Config 不記錄資料包拒絕。
● Direct Connect 將外部網路連線到 AWS；它不是 VPC 到 VPC 服務。
工作流：部門VPC→對等路由→中心服務；被拒絕的流 → 流日誌 → CloudWatch → 安全訂閱。
跨賬戶資源策略和持續審計
當許可權直接附加到支援基於資源的策略的資源時，跨賬戶共享是最簡單的。
推薦架構
● 將批准的外部帳戶主體新增到 S3、KMS 和 OpenSearch 資源策略。
● 將操作、資源和條件限制到所需的訪問路徑。
● 使用 AWS Config 記錄配置更改並評估合規性。
設計理由
● 技術可行性：資源策略可以信任來自另一個 AWS 賬戶的委託人。
● 需求匹配：外部使用者保留其正常的身份許可權，不需要用此訪問模型的角色會話替換它們。
● 場景匹配：命名服務支援資源級策略控制。
● 工程常識：定義共享資源的共享邊界並不斷驗證。
應排除的替代方案
● 僅外部帳戶中的身份策略無法授權訪問其他帳戶的資源。
● SCP 定義組織護欄；他們不授予對個人共享資源的訪問許可權。
● 服務相關角色適用於 AWS 服務整合，而不是此使用者共享模式。
● Systems Manager 不是配置合規性記錄器。
工作流：識別主體→編寫最低許可權資源策略→測試訪問→使用配置記錄→對不合規情況發出警報。
託管影片門戶處理
影片門戶可以透過分離 Web 層、非同步分析和持久媒體儲存來減少操作。
推薦架構
● 在 ECS Fargate 上執行動態 Web 應用程式。
● 在 S3 中儲存影片和靜態內容。
● 將分析作業放置在 SQS 中。
● 使用 EC2 Spot 工作執行緒進行長時間處理。
● 使用 Amazon Rekognition 而不是自定義視覺軟體。
設計理由
● 技術可行性：Fargate 消除了 Web 伺服器管理，Spot 降低了員工成本，Rekognition 提供託管分析。
● 需求匹配：該設計降低了成本和運營開銷。
● 場景匹配：上傳處理是動態的，而分析是非同步的並且可能很長。
● 工程常識：將媒體保留在計算例項之外。
應排除的替代方案
● S3靜態託管無法執行上傳應用程式。
● Lambda 可能不適合長影片工作。
● EFS 和 EC2 Web 伺服器保留更多基礎設施管理。
● Elastic Beanstalk 仍然運營兩個層級的 EC2 佇列。
工作流：使用者上傳 → Fargate → S3 和 SQS → Spot 工作人員 → Rekognition → 儲存結果。
SAML 角色聯合故障排除
SAML 聯合流程取決於信任配置、有效斷言、正確的角色對映以及正確形成的 STS 請求。
驗證步驟
● 確認 IAM 角色信任策略命名正確的 SAML 提供商並允許 sts:AssumeRoleWithSAML。
● 檢查身份提供者是否將使用者或組對映到預期角色。
● 驗證 SAML 斷言包含所需的角色和提供者資訊。
● 確認 AssumeRoleWithSAML 呼叫包括角色 ARN、提供商 ARN 和斷言。
設計理由
● 技術可行性：僅當斷言和 IAM 信任關係一致時，STS 才會頒發臨時憑證。
● 需求匹配：這些檢查隔離整個聯合鏈中的故障。
● 場景匹配：企業身份提供商的身份驗證成功，但 AWS 角色訪問失敗。
● 工程常識：在調查不相關的網路服務之前先解決身份宣告和信任問題。
應排除的替代方案
● IAM 使用者策略不會修復 SAML 角色信任故障。
● VPC DNS 設定與 STS 聯合決策無關。
● 將使用者置於任意 AWS 組中不會更改外部 IdP 發出的宣告。
工作流：使用者 → IdP 身份驗證 → SAML 斷言 → STS 驗證 → 角色會話。
跨對等 VPC 的私有 DNS
內部應用程式需要專用網路可達性和專用名稱解析。
推薦架構
● 為內部域建立 Route 53 私有託管區域。
● 將所需的 VPC 與託管區域關聯。
● 為資料庫伺服器的私有IP地址建立一條A記錄。
● 根據需要啟用 enableDnsSupport 和 enableDnsHostnames。
● 維護資料庫流量的對等路由和安全規則。
設計理由
● 技術可行性：關聯的 VPC 可以透過 Amazon 提供的解析器解析私有託管區域記錄。
● 需求匹配：該名稱仍然無法透過公共 DNS 獲取。
● 場景匹配：現有 VPC 對等互連承載解析後的流量。
● 工程常識：內部服務應使用私有地址和穩定的 DNS 名稱，而不是公共端點。
應排除的替代方案
● 公共託管區域公開公開名稱。
● CNAME 記錄無法直接對映到 IP 地址。
● 彈性 IP 建立了不必要的公共定址路徑。
● 禁用 DNS 支援會阻止預期的解析。
工作流：關聯區域 → 啟用 DNS → 建立私有記錄 → 驗證路由 → 驗證安全組 → 測試每個 VPC 的解析和連線。
一次性 EMR 容量組合
一次性 300 TB 分析作業應在使用 Spot 執行可重新啟動任務的同時保護叢集控制和 HDFS。
推薦架構
● 對 EMR 主節點和核心節點使用按需例項。
● 對任務節點使用 Spot 例項。
● 將最終結果儲存到持久儲存中。
● 完成後終止叢集。
設計理由
● 技術可行性：主節點和核心節點維護叢集狀態和資料；任務節點可以在中斷後進行替換。
● 需求匹配：該設計降低了成本，且不會因控制節點中斷而導致整個工作面臨風險。
● 場景匹配：該叢集僅執行八小時並且不重複執行。
● 工程常識：不要為單次執行購買長期承諾。
應排除的替代方案
● 預留的主容量對於一次使用來說並不划算。
● Spot 主節點或核心節點可能會導致叢集故障和 HDFS 丟失。
● 預留的主節點和核心節點需要不必要的承諾。
● 所有按需容量都會錯過安全的任務節點節省。
工作流：啟動穩定的 master 和 core → 新增 Spot 任務節點 → 處理 300 TB → 儲存輸出 → 終止。
JBoss 和 Oracle 的快速災難恢復
在災難期間，與重新設計應用程式相比，現有備份專案可以更快地恢復到 AWS 中。
推薦架構
● 為 JBoss 應用程式和 Oracle 資料庫啟動 EC2 容量。
● 使用儲存在 Amazon S3 中的 RMAN 備份恢復 Oracle。
● 將 Storage Gateway 卷快照恢復為 Amazon EBS 卷。
● 將 EBS 卷附加到應用程式伺服器。
● 從準備好的模板重新建立網路和配置。
設計理由
● 技術可行性：RMAN 恢復 Oracle 資料，Storage Gateway 快照可以建立 EBS 卷以進行本機 EC2 塊訪問。
● 需求匹配：該設計利用現有的備份來實現更短的恢復時間。
● 場景匹配：源架構已使用 JBoss、Oracle 和 Storage Gateway。
● 工程常識：在事件發生前預先記錄恢復順序和依賴關係。
應排除的替代方案
● 讓應用程式依賴於本地閘道器會阻礙區域災難恢復。
● S3物件儲存無法直接替換所需的附加塊儲存卷。
● 在恢復期間將工作負載轉換為 EFS 會增加不受支援的轉換工作。
● 在中斷期間重構 Oracle 和 JBoss 會增加恢復時間。
工作流：宣佈災難→部署EC2→恢復Oracle→從快照建立EBS→附加→驗證→切換流量。
修補 EC2 和記錄合規性
緊急作業系統修復需要部署服務和單獨的合規性記錄器。
推薦架構
● 在 Systems Manager 補丁管理器中定義批准的補丁。
● 透過補丁組和維護時段來定位託管 EC2 例項。
● 及時執行補丁操作。
● 使用 AWS Config 記錄和評估合規性狀態。
設計理由
● 技術可行性：補丁管理器安裝更新；配置記錄資源和合規性歷史記錄。
● 需求匹配：正在執行的例項會收到修復，稽核員可以檢查佇列狀態。
● 場景匹配：該漏洞目前影響現有的 EC2 例項。
● 工程常識：新影象有助於未來的發射，但本身並不能修復當前的機隊。
應排除的替代方案
● 等待每週 AMI 更換可能太慢。
● 補丁部署不需要OpenSearch。
● 狀態管理器對於所需的狀態很有用，但補丁管理器是專門構建的。
● Control Tower 管理帳戶，但不修補作業系統。
工作流：批准補丁 → 目標佇列 → 安裝並重新啟動 → 報告狀態 → 配置記錄合規性 → 修復故障。
使用 Web 代理的基於 URL 的出口
當例項接受入站流量但只能從指定網站下載更新時，出站檢查必須獨立於入站訪問進行。
推薦架構
● 在出站路徑上放置託管或自我管理的 Web 代理。
● 配置顯式 URL 或域允許規則。
● 讓私有例項使用代理進行Web訪問。
● 刪除備用直接出口路徑。
● 分別保留入站負載均衡器和安全組規則。
設計理由
● 技術可行性：代理評估應用程式層目標並僅轉發合規請求。
● 需求匹配：入站服務可用性保持不變，而出站訪問受到嚴格控制。
● 場景匹配：包更新使用其底層 IP 地址可能更改的已知 URL。
● 工程常識：不要為 URL 標識的服務維護脆弱的 IP 允許列表。
應排除的替代方案
● NAT 閘道器不過濾網站。
● 安全組和 NACL 無法檢查請求的 URL。
● 刪除所有網際網路訪問會阻止所需的更新。
● 僅當批准的儲存庫是端點支援的 AWS 服務時，S3 或服務 VPC 端點才有幫助。
工作流：應用程式接收入站請求 → EC2 發起更新請求 → 代理檢查 URL → 批准的請求退出 → 所有其他出口被拒絕。
掃描文件的可搜尋存檔
掃描的存檔需要持久的物件儲存、提取的可搜尋後設資料和可擴充套件的 Web 訪問層。
推薦架構
● 將掃描的檔案儲存在 Amazon S3 中。
● 在 Amazon CloudSearch 中對提取的文字和後設資料建立索引。
● 在 AWS Elastic Beanstalk 中託管 Web 應用程式。
● 保持搜尋結果與權威 S3 物件的連結。
設計理由
● 技術可行性：S3 提供持久儲存，CloudSearch 支援託管索引和查詢，Elastic Beanstalk 管理應用程式部署和擴充套件。
● 需求匹配：使用者無需操作自定義搜尋叢集即可搜尋和檢索檔案。
● 場景匹配：源資料由掃描檔案而不是關係事務組成。
● 工程常識：將原始資料與派生搜尋索引分開儲存，以便可以安全地重建兩者。
應排除的替代方案
● 檔案伺服器單獨儲存文件，但不提供可擴充套件的全文搜尋。
● EC2 上的自我管理搜尋軟體增加了修補、擴充套件和恢復工作。
● 對於大型存檔來說，沒有適當索引的資料庫關鍵字欄位的擴充套件性很差。
● 物件儲存本身並不能使影象文字變得可搜尋。
工作流：上傳掃描件 → 透過現有 OCR 流程提取文字 → 索引後設資料 → 查詢 CloudSearch → 從 S3 檢索原始檔案。
三可用區 Web 和資料庫可用性
24×7 Web 應用程式需要跨三個可用區的彈性計算和託管資料庫故障轉移。
推薦架構
● 在三可用區 Auto Scaling 組中執行 EC2 例項。
● 將應用程式負載均衡器放置在佇列之前。
● 關聯式資料庫使用RDS多可用區。
設計理由
● 技術可行性：ALB 路由到健康目標，Auto Scaling 取代計算，RDS 促進同步備用。
● 需求匹配：例項和可用區故障不會建立單個服務故障點。
● 場景匹配：該應用程式需要事務資料庫可用性，而不僅僅是讀取擴充套件。
● 工程常識：每個服務層都必須消除自己的故障點。
應排除的替代方案
● 讀取副本可擴充套件讀取，但不會取代多可用區寫入器故障轉移。
● 沒有負載均衡器的設計無法安全地分配使用者流量。
● 即使 Web 層跨越可用區，一個資料庫例項仍然是一個故障點。
● 更多 Web 伺服器無法修復資料庫可用性。
工作流：使用者 → ALB → 健康的 EC2 目標 → RDS 寫入器；資料庫故障時提升備用。
為什麼 SCP 不授予許可權
服務控制策略定義成員帳戶中可用的最大許可權，但其本身不授予任何內容。
所需授權鏈
● 保留適用的 SCP 津貼。
● 將身份策略附加到授予所需 EC2 和 S3 操作的 IAM 使用者或角色。
● 評估資源策略和其他許可權邊界。
設計理由
● 技術可行性：有效訪問需要允許該操作的 SCP 邊界和 IAM 授權。
● 需求匹配：新增身份許可權可以在不削弱組織控制的情況下解決訪問問題。
● 場景匹配：該帳戶透過其 OU 繼承 SCP。
● 工程常識：護欄和補助金有不同的目的。
應排除的替代方案
● SCP 是有效的組織護欄，不應僅僅因為缺少訪問許可權而被替換。
● 帳戶自動繼承附加到父 OU 的 SCP。
● 會員帳戶 root 使用者也受到 SCP 的限制。
● 根目錄不應該用於正常的資源建立。
工作流：請求 → 檢查 SCP 最大值 → 檢查 IAM 授予 → 檢查資源策略和條件 → 允許或拒絕。
高可用的三層 Web 架構
高流量 Web 應用程式需要彈性應用程式容量、HTTP 感知負載均衡器以及具有高可用性的託管關聯式資料庫。
推薦架構
● 在跨多個可用區的 Auto Scaling 組中執行 EC2 例項。
● 將應用程式負載均衡器放置在 Web 層前面。
● 跨可用區使用 Amazon Aurora MySQL。
● 使用應用程式終端節點的 Route 53 別名記錄。
● 如果刪除基礎架構堆疊，請保留資料庫。
設計理由
● 技術可行性：Auto Scaling 和 ALB 分配大量 HTTP 工作負載； Aurora 提供託管可用性和可擴充套件儲存。
● 需求匹配：該架構可以處理高峰使用者，而無需支付第二個區域的費用。
● 場景匹配：現有的 .NET 應用程式和 MySQL 模型無需進行重大重新設計即可遷移。
● 工程常識：使用滿足規定可用性目標的最簡單的多可用區設計。
應排除的替代方案
● 全 Spot 應用程式層在中斷期間可能會損失太多容量。
● 對於正常的 HTTP 應用程式路由，網路負載均衡器不如 ALB 合適。
● 兩個區域應用程式和跨區域資料庫副本增加了不必要的成本和操作複雜性。
工作流：Route 53 → ALB → Auto Scaling Web 層 → Aurora writer 和副本。
區域預留例項折扣如何適用
區域預留例項折扣適用於與其屬性（包括可用區）匹配的正在執行的例項。
示例結果
● us-west-2a 中 r4.16xlarge 的預留與該可用區中的 DEV 例項匹配。
● 另一個可用區中的類似 UAT 例項與區域預留不匹配。
● 在合併計費下，當屬性匹配時，可以共享符合條件的折扣。
設計理由
● 技術可行性：計費評估例項系列、大小、平臺、租賃、區域和區域範圍。
● 需求匹配：組織可以識別哪個帳戶收到折扣。
● 場景匹配：賬戶在不同可用區執行相似的例項。
● 工程常識：預訂是計費結構；購買前驗證尺寸是否精確匹配。
應排除的替代方案
● 啟用共享時，折扣不限於購買者。
● 不同的可用區與可用區 RI 不匹配。
● 當只有一項工作負載匹配時，兩個賬戶都不能使用一項區域福利。
● 未使用的匹配預留不會手動附加到命名例項。
工作流：例項執行 → 匹配 RI 的綜合計費搜尋 → 匹配的 DEV 使用獲得折扣。
針對 Web 漏洞和 DDoS 的託管保護
公共應用需要應用層過濾和基礎設施層DDoS防護。
推薦架構
● 將 AWS WAF 連線到支援的 Web 終端節點。
● 使用託管或自定義規則進行 SQL 注入和常見攻擊。
● 啟用 AWS Shield Advanced 以增強 DDoS 保護和監控。
設計理由
● 技術可行性：WAF 檢查 HTTP 請求，而 Shield Advanced 則保護受支援的 AWS 邊緣和負載平衡資源。
● 需求匹配：該組合可解決網路漏洞和分散式攻擊。
● 場景匹配：該工作負載是面向網際網路的 AWS 應用程式。
● 工程常識：反應式 IP 阻止無法取代為分散式和不斷變化的源而設計的控制。
應排除的替代方案
● Direct Connect 和本地硬體 WAF 會增加成本，並且不能直接保護 AWS 公共邊緣。
● 一項 NACL 拒絕僅阻止已知地址，並且無法檢查 SQL 有效負載。
● 備用區域可以提高恢復能力，但不能阻止當前的惡意流量。
● 單獨擴充套件會增加攻擊成本而不過濾請求。
工作流：網際網路→遮蔽防護→WAF檢查→允許請求→申請；警報啟動響應。
託管文件 OCR 和實體提取
掃描的表單可以透過託管 OCR、文字分析和無伺服器工作流程編排進行處理。
推薦架構
● 使用 Step Functions 協調處理階段。
● 呼叫Lambda函式進行整合和轉換。
● 使用 Amazon Textract 進行文件 OCR 和結構提取。
● 使用 Amazon Comprehend 進行實體或文字分析。
● 根據需要將結構化結果儲存在 RDS 中，並將持久工件儲存在 S3 中。
設計理由
● 技術可行性：Textract 提取文件內容，Comprehend 分析文字，Step Functions 處理重試和排序。
● 需求匹配：該設計以較低的運營開銷實現處理自動化。
● 場景匹配：輸入是文件，而不是語音或一般照片。
● 工程常識：在培訓或操作自定義 OCR 系統之前，使用專門構建的託管服務。
應排除的替代方案
● 自定義 SageMaker 模型增加了培訓和維護。
● 重新識別和轉錄目標影象和語音，而不是結構化文件 OCR。
● EKS 上的自我管理 OCR 新增了叢集和軟體操作。
● 一個大的 Lambda 函式會削弱可觀察性和重試控制。
工作流：表單上傳→狀態機→Textract→理解→驗證→RDS或S3輸出。
日誌頻繁的區域恢復
兩小時的 RTO 和十分鐘的 RPO 需要災難恢復區域中已存在的恢復資料。
推薦架構
● 在 S3 中建立每小時應用程式或資料庫備份。
● 每五分鐘匯出一次事務日誌。
● 啟用到恢復區域的 S3 跨區域複製。
● 自動恢復和日誌重放。
設計理由
● 技術可行性：基礎備份加上頻繁的日誌可以重建故障時間附近的狀態。
● 需求匹配：五分鐘日誌捕獲適合 RPO，區域副本支援 RTO。
● 場景匹配：該要求涵蓋了完整的區域損失。
● 工程常識：備份頻率和備份位置解決不同的風險。
應排除的替代方案
● 區域 EBS 備份不提供另一個區域中的恢復資料。
● 冰川恢復可能會超過 RTO。
● 多可用區可以防止可用區故障，而不是區域災難。
● 未經測試的恢復自動化的備份仍可能錯過 RTO。
工作流：每小時備份→五分鐘日誌→跨區域複製→恢復基礎→重播日誌→驗證。
用於影象處理的臨時 S3 憑證
EC2 影象處理工作執行緒應使用 IAM 角色來訪問 S3，而不處理長期憑證。
推薦架構
● 建立一個 EC2 IAM 角色，該角色對所需的儲存桶和字首具有確切的讀寫許可權。
● 透過例項配置檔案附加角色。
● 讓應用程式 SDK 從例項後設資料服務檢索臨時憑證。
● 將帶水印的影象上傳到授權目的地。
設計理由
● 技術可行性：例項配置檔案憑證會自動輪換，並由標準 AWS 開發工具包憑證提供商使用。
● 需求匹配：工作人員無需嵌入訪問金鑰即可下載和上傳照片。
● 場景匹配：處理發生在與 S3 互動的 EC2 例項上。
● 工程常識：分別為源讀取和目標寫入劃分許可權範圍。
應排除的替代方案
● 硬編碼金鑰可能會洩漏到影象、日誌、AMI 或源儲存庫中。
● IAM 使用者無法直接附加到 EC2 例項。
● 公共儲存桶許可權不必要地公開了每個物件。
● 將憑證從移動客戶端傳遞給工作人員打破了信任邊界。
工作流：EC2接收作業→SDK獲取角色憑證→下載源→水印影象→上傳結果→憑證輪換。
刪除 VPN 站點和隧道故障點
站點到站點 VPN 彈性需要獨立的本地位置和冗餘隧道。
推薦架構
● 在第二個資料中心新增客戶閘道器。
● 使用兩個 AWS 託管隧道建立站點到站點 VPN 連線。
● 在支援的情況下使用動態路由。
● 測試一條隧道丟失和一個資料中心丟失。
設計理由
● 技術可行性：第二個客戶閘道器建立單獨的本地路徑，同時雙隧道可防止隧道端點故障。
● 需求匹配：連線可以解決站點和隧道問題。
● 場景匹配：目前單一資料中心是主要的故障域。
● 工程常識：冗餘不得共享受保護的元件。
應排除的替代方案
● VPC 不會按可用區附加單獨的虛擬專用閘道器。
● 第二個 VGW 並不是一個 VPC VPN 彈性的正常模型。
● NAT 閘道器提供出站 Internet 轉換，並且不是本地 VPN 端點。
● 終止於一個發生故障的客戶站點的兩條隧道不提供站點冗餘。
工作流：正常 BGP 路徑 → 隧道故障使用對等隧道 → 站點故障使用第二個客戶閘道器 → 路由收斂。
降低每日 DynamoDB 成本
可預測的每日吞吐量受益於預留容量，而歷史表資料可以移動到 S3 並刪除。
推薦架構
● 購買預留容量以實現可預測的預配置 DynamoDB 使用情況。
● 在需要現有模式的地方使用一張每日表格。
● 將完成的表匯出到 S3。
● 驗證後刪除舊的 DynamoDB 表。
設計理由
● 技術可行性：預留容量會降低可預測的吞吐量，S3 以較低的成本保留歷史資料。
● 需求匹配：該應用程式保留當前的低延遲資料，同時避免長期 DynamoDB 儲存費用。
● 場景匹配：生物識別資料按天分割槽，並且不會主動查詢較舊的資料。
● 工程常識：在刪除源表之前驗證匯出。
應排除的替代方案
● Redshift 不是低延遲運算元據庫。
● S3 One Zone-IA 不必要地降低了報告的彈性。
● ElastiCache 不是持久的主儲存。
● RDS 新增了固定的關係容量和管理，而無需關係要求。
工作流：使用日常表→匯出到S3→驗證物件→刪除表→保留當前配置容量。
低 CPU 時自動縮容
當 CloudWatch 指標低於安全閾值時，Auto Scaling 可以刪除多餘的 EC2 容量。
推薦架構
● 針對 CPU 處於或低於 15% 的情況建立 CloudWatch 警報。
● 將警報附加到 Auto Scaling 縮減策略。
● 配置冷卻或例項預熱行為。
● 保留最小容量和可用性限制。
設計理由
● 技術可行性：當滿足評估標準時，警報會直接呼叫伸縮策略。
● 需求匹配：不需要的例項會自動終止並降低成本。
● 場景匹配：容量應遵循測量的利用率，而不是固定的時間表。
● 工程常識：避免對一個簡短的低 CPU 樣本做出反應。
應排除的替代方案
● 手動電子郵件驅動的刪除速度很慢。
● 本機擴充套件操作不需要 Lambda 通知程式碼。
● 計劃的擴充套件遵循時間而不是實際需求。
● 終止 Auto Scaling 組外部的例項可能會破壞所需的容量管理。
工作流：CPU 保持低電平 → 警報進入 ALARM → 縮減策略減少所需容量 → Auto Scaling 安全終止。
三可用區應用程式和資料庫可用性
彈性 Web 平臺跨三個可用區分配計算，並使用具有寫入器可用性的資料庫設計。
推薦架構
● 在三可用區 Auto Scaling 組中執行 EC2 例項。
● 將應用程式負載均衡器放置在佇列之前。
● 使用支援所需寫入器可用性的 Aurora 架構。
● 建立 ALB 的 Route 53 別名。
設計理由
● 技術可行性：Auto Scaling 替換失敗的計算，ALB 僅路由到正常目標，Route 53 別名跟蹤負載均衡器端點。
● 需求匹配：該設計在例項或可用區故障時仍然可用。
● 場景匹配：該應用程式需要託管關係編寫器的彈性。
● 工程常識：避免不必要的可用區或不會改善規定的恢復目標的額外資料庫。
應排除的替代方案
● 通用 A 記錄不應硬編碼 ALB 地址。
● 沒有合適的故障轉移的資料庫編寫器仍然是一種風險。
● 四個可用區增加了複雜性，而沒有明確的需求。
● 額外的副本不會自動建立寫入器可用性。
工作流：Route 53 別名 → ALB → 正常的 Auto Scaling 目標 → 可用的 Aurora writer。
託管 CI/CD 測試、警報和功能開關
託管交付管道應該執行可重複的測試、警報故障並部署基礎設施定義的功能開關。
推薦架構
● 使用 CodePipeline 來編排階段。
● 使用 CodeBuild 進行測試和安全掃描。
● 使用 EventBridge 和 SNS 進行故障通知。
● 使用 AWS CDK 對功能開關和基礎設施進行建模。
設計理由
● 技術可行性：CDK 綜合部署模板，CodeBuild 執行任意測試命令，CodePipeline 協調升級。
● 需求匹配：工作流程是自動化的，並減少了伺服器管理。
● 場景匹配：構建包括自定義測試和基礎架構更改。
● 工程常識：使用部署程式碼保持功能配置的版本。
應排除的替代方案
● Lambda 並不是最好的通用完整構建環境。
● Amplify 外掛不提供通用基礎設施功能切換。
● Jenkins 可以工作，但增加了伺服器管理。
● 當 SNS 處理操作警報時，不需要 SES。
● CodeArtifact 儲存包但不執行所有測試和掃描。
工作流：提交 → CodePipeline → CodeBuild 測試 → CDK 部署 → EventBridge 和 SNS 報告失敗。
在 CloudFront 上實施 HTTPS
CloudFront 可以在其預設域上提供受信任的 HTTPS 並強制執行安全的檢視器連線。
推薦配置
● 使用分配的 cloudfront.net 主機名的預設 CloudFront 證書。
● 將檢視器協議策略設定為將 HTTP 重定向到 HTTPS 或僅 HTTPS。
● 當需要自定義域時，在 us-east-1 中使用 ACM。
設計理由
● 技術可行性：瀏覽器信任預設主機名的預設 CloudFront 證書，並且檢視器策略控制接受的協議。
● 需求匹配：使用者透過 HTTPS 訪問內容，支援機密性和安全索引。
● 場景匹配：直接要求可以使用預設的分發域。
● 工程常識：證書主機名覆蓋範圍必須與使用者訪問的 URL 匹配。
應排除的替代方案
● 自簽名證書不受公眾信任。
● 在 S3 中儲存證書不會建立瀏覽器信任。
● ELB 證書不會自動成為 CloudFront 檢視器證書。
● 假定的通用 ELB 預設證書無法保護應用程式的自定義主機名。
工作流：檢視器使用 HTTP 或 HTTPS → 策略重定向或接受 → TLS 在 CloudFront 終止 → 源請求遵循配置的協議。
區域 ALB 的全球選播入口點
多區域應用程式可以使用 AWS Global Accelerator 作為健康區域應用程式負載均衡器的一個公共入口點。
推薦架構
● 建立全球加速器。
● 為所需區域定義端點組。
● 將區域 ALB 註冊為端點。
● 在指向加速器的頂點域建立 Route 53 公共別名記錄。
設計理由
● 技術可行性：Global Accelerator 使用靜態任播 IP 地址並將使用者透過 AWS 網路路由到健康的終端節點。
● 需求匹配：該設計支援頂級域，改進全域性路由，並最大限度地減少 DNS 和故障轉移操作。
● 場景匹配：該應用程式已經擁有公共區域 ALB 和多區域資料服務。
● 工程常識：使用一個託管的全域性流量層，而不是手動維護區域 IP 對映。
應排除的替代方案
● Transit Gateway 用於專用網路路由，不能是公共應用程式端點。
● Route 53 解析器入站終端節點提供私有 DNS 查詢，而不是公共頂點路由。
● 區域頂端的公共 CNAME 不是合適的模型； Route 53 別名記錄解決了 apex 要求。
工作流：客戶端 → Global Accelerator 任播地址 → 基於健康狀況的區域端點組 → ALB → 應用程式。
IoT 檔案的事件驅動處理
每五分鐘到達的檔案應在到達時進行處理，而不是等待夜間輪詢作業。
推薦架構
● 將現有的 Python 處理邏輯轉換為 AWS Lambda 函式。
● 配置 S3 物件建立的事件通知以呼叫 Lambda。
● 處理每個上傳的檔案並將其值寫入 Amazon RDS。
● 僅在成功處理後才刪除或生命週期源物件。
設計理由
● 技術可行性：S3 可以直接為新物件呼叫 Lambda，並且 Lambda 可以使用正確的網路和憑據連線到資料庫。
● 需求匹配：資料上傳後不久即可使用，幾乎不需要基礎設施管理。
● 場景匹配：每日處理只需大約十分鐘，這表明每個單獨的檔案都足夠小，可以進行基於事件的執行。
● 工程常識：對於離散物件到達，更喜歡推送事件而不是一分鐘輪詢。
應排除的替代方案
● 更大的 EC2 佇列和頻繁的 cron 執行會浪費容量並需要協調。
● CloudTrail 資料事件加上 EventBridge 可以檢測上傳，但當本機 S3 通知足夠時會增加成本和延遲。
● 多個計劃規則會產生重複呼叫風險，而不會提高及時性。
工作流：裝置上傳→S3事件→Lambda處理→RDS寫入→成功處理和物件清理。
不可匯出的 TLS 金鑰和持久的安全日誌
敏感私鑰應保留在專用加密硬體內，而日誌應獨立於計算例項儲存。
推薦架構
● 使用 TCP 負載平衡，以便 TLS 操作到達應用程式層，而不會在負載平衡器處終止。
● 使用 AWS CloudHSM 進行私鑰操作。
● 跨兩個可用區部署 HSM 容量。
● 將加密的應用程式日誌傳送到私有 Amazon S3 儲存桶。
設計理由
● 技術可行性：CloudHSM 執行加密操作，無需匯出私鑰材料； S3 提供持久的加密儲存。
● 需求匹配：多可用區 HSM 部署支援可用性，IAM 加加密控制日誌訪問。
● 場景匹配：流量是可預測的，因此金鑰保管和永續性比激進的彈性更重要。
● 工程常識：切勿將敏感日誌儲存在臨時例項儲存上或將私鑰複製到 Web 伺服器上。
應排除的替代方案
● TLS 解除安裝可以工作，但例項儲存日誌不持久。
● 單個 HSM 位置會造成可用性差距。
● 從 S3 檢索金鑰使金鑰可移動並將其公開給伺服器程序。
工作流：TCP 直通 → HSM 支援的 TLS → 應用程式 → 加密的 S3 日誌記錄 → 授權稽核訪問。
替換脆弱的 NAT 例項
當兩個可用區應用程式中一半的出站請求失敗時，一個失敗的 NAT 路徑是一個強烈的架構訊號。
推薦架構
● 將 EC2 NAT 例項替換為託管 NAT 閘道器。
● 在每個活動可用區中部署一個 NAT 閘道器。
● 將每個私有子網路由到同一可用區中的 NAT 閘道器。
● 監控 NAT 指標和第三方 API 連線。
設計理由
● 技術可行性：NAT 閘道器在其可用區內為私有子網網際網路出口提供託管擴充套件和可用性。
● 需求匹配：無需維護 NAT 例項執行狀況或容量即可訪問地圖 API。
● 場景匹配：兩條 AZ 路徑上大約 50% 的成功表明一條出口路由已損壞。
● 工程常識：避免跨可用區依賴，並刪除存在託管等效裝置的自我管理網路裝置。
應排除的替代方案
● 擴大 NAT 例項可以解決吞吐量問題，但不能解決失敗的例項或路由問題。
● 責備提供商並不能解釋透過其他申請路徑取得的持續成功。
● 網路 ACL 錯誤是可能的，但 NAT 例項模式更直接地解釋了觀察到的拆分行為。
工作流：每個可用區建立 NAT 閘道器 → 更新私有路由 → 測試出站呼叫 → 停用 NAT 例項。
使用 FSx 實現 Lustre 爆發 HPC 儲存
每月 200 TB 的建模作業需要經濟耐用的儲存和臨時並行檔案系統來進行密集處理。
推薦架構
● 將源資料保留在 S3 智慧分層中。
● 為每月計算視窗建立 FSx for Lustre。
● 僅延遲載入所需的 S3 物件。
● 針對檔案系統執行平行計算。
● 匯出結果並隨後刪除臨時檔案系統。
設計理由
● 技術可行性：FSx for Lustre 與 S3 整合並提供高吞吐量並行檔案訪問。
● 需求匹配：智慧分層可降低閒置儲存成本，臨時 FSx 可避免長達一個月的檔案系統費用。
● 場景匹配：該作業每月執行時間較短，但需要極高的並行 I/O。
● 工程常識：將持久儲存與臨時效能儲存分開。
應排除的替代方案
● EBS Multi-Attach 具有可用區和例項限制，並且不是 200 TB 共享佇列檔案系統。
● 對於每月的批次計算來說，冰川檢索費用和恢復行為很差。
● EFS 可以適用於一般共享檔案，但不太適合這種並行建模爆發。
工作流：S3源→建立FSx→延遲載入→計算→匯出結果→刪除FSx。
並行照片後設資料編排
照片列表可以分佈在並行的無伺服器分支上，並在寫入最終後設資料之前加入。
推薦架構
● 使用 Step Functions 分散式處理照片列表。
● 並行呼叫專用 Lambda 函式。
● 跟蹤每個分支並處理重試。
● 所有必需的分支完成後合併結果。
設計理由
● 技術可行性：Step Functions 協調並行 Lambda 執行並保留工作流狀態。
● 需求匹配：處理規模同時產生一個協調的完成結果。
● 場景匹配：每張照片都需要多個獨立的後設資料操作。
● 工程常識：當下遊工作必須在完成之前加入時，請使用協調器。
應排除的替代方案
● 獨立的 SQS 觸發函式不會自動建立一個協調的聚合結果。
● 自定義列表函式加上佇列使編排不完整。
● Lambda 函式無法按照建議附加到 AWS Batch 計算環境。
● 一個序列 Lambda 會浪費並行性並面臨超時風險。
工作流：照片列表→分散式地圖→並行Lambda分支→重試失敗→連線結果→儲存組合後設資料。
多區域一網直達
Direct Connect 閘道器將一種私有連線設計擴充套件到多個 AWS 區域中的 VPC。
推薦架構
● 建立直連閘道器。
● 關聯區域虛擬專用閘道器。
● 將私有虛擬介面連線到閘道器。
● 透過 BGP 公佈批准的字首。
設計理由
● 技術可行性：Direct Connect 閘道器將私有 VIF 連線連結到跨受支援區域的 VGW。
● 需求匹配：資料中心透過集中式高頻寬專用連線到達兩個區域 VPC。
● 場景匹配：一個本地站點需要訪問東、西VPC。
● 工程常識：在購買重複電路之前使用一個集線器。
應排除的替代方案
● VPC 對等互連不連線本地資料中心。
● 通往東部區域的 VPN 不會自動到達西部 VPC。
● VPN 缺乏 Direct Connect 的可預測效能。
● 單獨的 Direct Connect 連線可以工作，但成本更高並且需要增加管理。
工作流：資料中心 → Direct Connect → 私有 VIF → Direct Connect 閘道器 → 區域 VGW → VPC。
受管理的自助服務 SageMaker 環境
資料科學家可以透過受控的自助服務目錄接收經過批准的機器學習環境。
推薦架構
● 在 CloudFormation 中定義 SageMaker 環境。
● 使用客戶控制的 KMS 金鑰加密所需的資源。
● 將批准的模板釋出為 AWS Service Catalog 產品。
● 僅公開允許使用者選擇的對映引數。
● 應用投資組合訪問控制和約束。
設計理由
● 技術可行性：服務目錄根據管理員定義的許可權和約束提供 CloudFormation 產品。
● 需求匹配：使用者無需廣泛的基礎設施許可權即可啟動標準化環境。
● 場景匹配：多個團隊需要具有治理和加密功能的可重複 SageMaker 工作區。
● 工程常識：將產品設計與產品消費分開。
應排除的替代方案
● 授予每個資料科學家管理員許可權會削弱治理。
● 基於票證的手動配置會產生可避免的延遲和不一致。
● 原始 CloudFormation 訪問可能允許未經批准的引數和資源更改。
● 自定義部署指令碼在 Service Catalog 已提供組合和約束的情況下新增了維護。
工作流：管理員建立模板 → 釋出目錄產品 → 授予產品組合訪問許可權 → 使用者選擇批准的引數 → 受控堆疊部署。
使用 WorkDocs 管理文件版本
協作文件服務需要託管使用者、版本、加密、API 和舊內容的恢復。
推薦架構
● 將文件儲存在 Amazon WorkDocs 中。
● 使用其託管版本歷史記錄和訪問控制。
● 透過 WorkDocs API 整合應用程式邏輯。
● 需要時將選定的舊版本恢復為當前文件。
設計理由
● 技術可行性：WorkDocs 提供面向文件的儲存、使用者、版本和託管加密。
● 需求匹配：該平臺避免了自定義版本和金鑰管理程式碼。
● 場景匹配：使用者協作處理文件而不是通用物件或共享檔案系統塊。
● 工程常識：當文件生命週期是核心要求時，使用文件管理服務。
應排除的替代方案
● S3 可以對物件進行版本控制，但分發客戶端主金鑰不安全且操作繁重。
● S3 訪問日誌不提供沒有版本控制的回滾。
● EFS 是一個檔案系統，而不是託管文件版本服務。
● IAM 無法按照建議為每個鎖定的 EFS 檔案分配不同的 KMS 金鑰。
工作流：使用者編輯 → WorkDocs 建立版本 → 應用程式列出歷史記錄 → 所選版本恢復為當前版本。
對 ERP 的私人遠端訪問
漫遊員工可以透過經過身份驗證的 SSL 客戶端 VPN 訪問私有 ERP 伺服器。
推薦架構
● 將 ERP 伺服器保留在私有子網中。
● 部署 AWS 客戶端 VPN 終端節點。
● 在授權裝置上安裝客戶端軟體。
● 配置身份認證、路由、限制性安全組。
設計理由
● 技術可行性：客戶端 VPN 建立加密的使用者到 VPC 隧道。
● 需求匹配：經理和分析師可以遠端連線，無需公開暴露 ERP 伺服器。
● 場景匹配：使用者在不斷變化的家庭或旅行網路中工作。
● 工程常識：網路到網路解決方案對於個人漫遊客戶端來說並不理想。
應排除的替代方案
● 站點到站點 VPN 連線固定網路，而不是單個員工。
● Direct Connect 直接為企業站點提供服務，而不是直接為漫遊使用者提供服務。
● 公共應用程式伺服器增加了曝光度。
● 公共 ELB 上的 HTTPS 會對流量進行加密，但不會單獨限制授權人員的訪問。
工作流：使用者認證→客戶端VPN隧道→授權VPC路由→ERP安全組→私有伺服器。
區域和全球服務的持久稽核日誌
可靠的安全審計跟蹤應覆蓋每個區域和全球服務，同時將日誌與正常工作負載訪問隔離。
推薦架構
● 建立一個多區域 AWS CloudTrail 跟蹤。
● 包括全域性服務事件，例如 IAM 活動。
● 將日誌傳送到專用的 Amazon S3 儲存桶。
● 在適當的情況下，使用限制性策略、版本控制、加密和 MFA 刪除來保護儲存桶。
設計理由
● 技術可行性：CloudTrail 記錄 EC2、RDS、IAM 和其他服務的管理活動。
● 需求匹配：S3 提供持久儲存，而訪問限制和刪除控制可保護機密性和完整性。
● 場景匹配：該賬戶使用跨多個區域的資源，並需要集中合規證據。
● 工程常識：將稽核日誌儲存在專用位置，管理員數量少於生產資源。
應排除的替代方案
● 忽略全域性事件的跟蹤會錯過 IAM 活動。
● 複用通用桶，主要依靠ACL，隔離性弱。
● 控制檯、SDK 和 CLI 不需要單獨的跟蹤，因為 CloudTrail 記錄所有三個通道。
● SNS 傳送通知不會取代日誌保護或驗證。
工作流：帳戶操作 → CloudTrail 事件 → 受保護的 S3 儲存 → 受控的稽核員訪問 → 保留監控。
透過請求者支付轉移 S3 檢索費用
當合作伙伴頻繁從另一家公司的 S3 儲存桶下載物件時，Requester Pays 可以向請求者分配請求和轉移費用。
推薦架構
● 在共享儲存桶上啟用 S3 請求者付款。
● 授予合作伙伴所需的物件許可權。
● 要求請求確認請求者的賬單。
● 監控訪問和成本分配。
設計理由
● 技術可行性：授權請求者包含 requester-pays 引數，併為符合條件的請求和資料傳輸付費。
● 需求匹配：初創公司保留一份權威副本，而媒體公司則為其消費付費。
● 場景匹配：頻繁的合作伙伴檢索（而不是儲存增長）正在推動成本。
● 工程常識：在複製整個資料集之前更改計費模型。
應排除的替代方案
● 同步到另一個儲存桶會重複儲存，並且需要持續的一致性管理。
● AWS Organizations 和 SCP 管理賬戶，但不轉移 S3 檢索費用。
● 僅跨賬戶許可權並不會讓請求者付費；必須明確啟用計費行為。
工作流：啟用請求者付款 → 更新合作伙伴請求流程 → 測試計費確認 → 觀察使用情況 → 保留內部工作流程的正常所有者訪問許可權。