99% 情境

這些工作負載對業務有幫助， 但只有在無法使用時 才會造成不便。這類工作負載可以是內部工具、內部知識管理或專案追蹤。或者，這些可以是實際面向客戶的工作負載，但由實驗性服務提供，且內含可視需要隱藏服務的功能切換。

可以在一個區域和一個可用區域中部署這些工作負載。

監控資源

我們將進行簡單的監控，以指示服務主頁是否返回 HTTP 200 OK 狀態。當出現問題時，我們的程序手冊將指出可使用來自執行個體的記錄來確定根本原因。

適應需求變更

我們將提供有關常見硬體故障、緊急軟體更新和其他破壞性更改的程序手冊。

實作變更

我們將使用 AWS CloudFormation 定義我們的 Infrastructure as Code，特別是在發生故障時加快重建速度。

我們將使用執行手冊手動執行軟體更新，並需要停機才能安裝和重啟服務。如果部署期間發生問題，請參閱執行手冊，了解如何回復到以前的版本。

錯誤的任何糾正措施都是透過營運和開發團隊的日誌分析來完成，而且會在排定修正的優先順序並完成修正之後部署糾正措施。

備份資料

我們將使用供應商或特定目的的備份解決方案，以使用執行手冊將加密的備份資料傳送到 Amazon S3。我們將透過使用執行手冊還原資料，並確保能夠定期使用資料來測試備份是否能正常工作。我們在 Amazon S3 物件上設定版本控制，並移除備份的刪除許可。我們將根據要求使用 Amazon S3 儲存貯體生命週期政策，來存檔或永久刪除。

彈性架構師

在一個區域和一個可用區域中部署工作負載。我們將應用程式 (包括資料庫) 部署到一個執行個體中。

測試彈性

新軟體的部署管道已排程好，並測試了一些單位，但大多數是對組裝工作負載的白箱/黑箱測試。

災難復原 (DR) 計畫

在故障期間，我們將等待故障完成，可以選擇透過執行手冊來使用 DNS 修改，進而將請求路由到靜態網站。此操作的復原時間取決於基礎設施的部署速度，以及資料庫還原到最新備份的速度。如果使用執行手冊的可用區域發生故障，則此部署可以位於相同的可用區域中，也可以位於不同的可用區域中。

可用性設計目標

假設我們部署到新的可用區域，並假設可以在 30 分鐘內還原資料庫，我們需要 30 分鐘的時間來理解並決定執行復原，在 10 分鐘內將整個堆疊部署到 AWS CloudFormation 中。這意味著從故障中復原大約需要 70 分鐘。假設每季度發生一次故障，我們估計全年的影響時間為 280 分鐘，即四小時 40 分鐘。

這表示可用性的上限為 99.9%。實際可用性還取決於實際故障率、故障持續時間以及每個故障實際復原的速度。對於這種架構，我們要求應用程式離線處理更新 (估計每年 24 小時：每次變更四小時，每年六次) 以及實際事件。因此，根據本白皮書前文有關應用程式可用性的資料表，我們發現我們的 可用性設計目標 是 99%。

總結

主題	實作
監控資源	僅現場運行狀態；沒有提醒。
適應需求變更	透過重新部署垂直擴展。
實作變更	用於部署和還原的執行手冊。
備份資料	用於備份和還原的執行手冊。
彈性架構師	完成重建；從備份還原。
測試彈性	完成重建；從備份還原。
災難復原 (DR) 計畫	加密的備份，如果需要，還原到其他可用區域。