Azure App Service 的可靠性
本文說明 Azure App Service 的可靠性支援，並涵蓋可用性區域的區域內復原能力，以及跨區域災害復原和商務持續性。 如需更多關於 Azure 可靠性準則的詳細概觀，請參閱 Azure 可靠性。
Azure App Service 是 HTTP 型服務，用來裝載 Web 應用程式、REST API 和行動後端；並為您的應用程式新增 Microsoft Azure 的功能，例如：
- 安全性
- 負載平衡
- 自動調整規模
- 自動化管理
若要探索 Azure App Service 如何支援應用程式工作負載的可靠性和復原功能，請參閱為何要使用 App Service？
可用性區域支援
Azure 可用性區域是每個 Azure 區域內至少三個實體獨立的資料中心群組。 每個區域內的資料中心都配備了獨立的電源、冷卻系統和網路基礎結構。 在本機區域失敗的案例中，可用性區域的設計在於，當一個區域受影響時，讓其餘兩個區域支援區域服務、容量和高可用性。
這類失敗的範圍可從軟體和硬體故障，擴及到如地震、淹水和火災的事件。 透過 Azure 服務的備援和邏輯隔離，實現對失敗的容錯。 如需深入了解 Azure 的可用性區域，請參閱區域和可用性區域。
已啟用 Azure 可用性區域的服務旨在提供正確程度的可靠性和彈性。 您可以透過兩種方式加以設定。 它們可以是區域備援，具有跨區域自動複寫功能，或者是區域性的，將執行個體釘選在特定區域。 兩種方法可以結合使用。 如需區域與區域備援架構的詳細資訊，請參閱使用可用性區域和區域的建議。
Azure App Service 可以跨可用性區域 (AZ) 進行部署，以協助您達到業務關鍵工作負載的復原和可靠性。 此架構稱也為區域備援。
將 App Service 設定為區域備援時，平台會自動將 Azure App Service 方案的執行個體散佈至所選區域中的三個區域。
使用區域備援部署進行散佈的執行個體，即使應用程式增加或減少數量，也會根據以下規則來確定：
- App Service 方案執行個體計數下限為三個。
- 如果您指定的容量大於三，而且執行個體數目可以使用三整除，則會平均分散執行個體。
- 任何超過 3*N 的執行個體計數則會散佈至其餘的一或兩個區域中。
可用性區域支援是 App Service 方案的屬性。 您可以使用 App Service 環境 v3，在受控多租用戶環境或專用環境上建立 App Service 方案。 若要深入了解 App Service 環境 v3，請參閱 App Service 環境 v3 概觀。
對於未設定為區域備援的應用程式服務，VM 執行個體不具備區域復原性，在該區域的任何一個區域出現中斷情形時，可能會出現停機的情況。
如需企業部署架構的相關資訊，請參閱使用 App Service 環境進行高度敏感性企業部署。
必要條件
啟用可用性區域的目前需求/限制如下：
支援 Windows 和 Linux。
只有較新的 App Service 使用量才支援可用性區域。 即使您使用其中一個支援的區域，如果資源群組不支援可用性區域，仍會收到錯誤。 若要確保工作負載落在支援可用性區域的戳記上，可能需要建立新的資源群組、App Service 方案和 App Service。
App Service 方案必須是下列其中一個支援可用性區域的方案：
- 在多租用戶環境中，使用 App Service 進階 v2 或進階 v3 方案。
- 在使用 App Service 環境 v3 的專用環境中，會與隔離式 v2 App Service 方案搭配使用。
對專用環境而言，您的 App Service 環境必須是 v3。
重要
App Service 環境 v2 和 v1 將於 2024 年 8 月 31 日淘汰。 App Service Environment v3 更易於使用，並且是在更強大的基礎結構上執行。 若要深入了解 App Service 環境 v3，請參閱 App Service 環境概觀。 如果您目前使用 App Service 環境 v2 或 v1，且想要升級至 v3，請遵循本文中的步驟來移轉至新版本。
強制要求執行個體的計數下限為三個區域。 如果您指定少於三個執行個體計數，則平台會在幕後強制執行此最小計數。
只有在建立新的 App Service 方案時，才能指定可用性區域。 預先存在的 App Service 方案無法改為使用可用性區域。
下列區域支援在多租用戶環境中執行的 Azure App Service：
- 澳大利亞東部
- 巴西南部
- 加拿大中部
- 印度中部
- 美國中部
- 東亞
- 美國東部
- 美國東部 2
- 法國中部
- 德國中西部
- 以色列中部
- 義大利北部
- 日本東部
- 南韓中部
- 墨西哥中部
- 北歐
- 挪威東部
- 波蘭中部
- 卡達中部
- 南非北部
- 美國中南部
- 東南亞
- 西班牙中部
- 瑞典中部
- 瑞士北部
- 阿拉伯聯合大公國北部
- 英國南部
- 西歐
- 美國西部 2
- 美國西部 3
- 由 21Vianet 營運的 Microsoft Azure - 中國北部 3
- Azure Government - US Gov 維吉尼亞州
若要查看哪些區域支援 App Service 環境 v3 的可用性區域，請參閱區域。
建立已啟用可用性區域的資源
部署多租用戶區域備援 App Service
若要使用 Azure CLI 來啟用可用性區域，請在建立 App Service 方案時納入 --zone-redundant 參數。 您也可以包含 --number-of-workers 參數來指定容量。 如果您未指定容量，平台預設為三。 容量應該根據工作負載需求來設定，但不得少於三。 選擇容量的良好規則是確保應用程式有足夠的執行個體，如此一來，遺失一個執行個體區域就有足夠的容量可處理預期的負載。
az appservice plan create --resource-group MyResourceGroup --name MyPlan --sku P1v2 --zone-redundant --number-of-workers 6
提示
若要決定執行個體容量，您可以使用下列計算：
由於平台會將 VM 分散到三個區域，因此您必須至少考慮一個區域的失敗，請將尖峰工作負載執行個體計數乘以區域/(zone-1) 或 3/2 的因素。 例如，如果您的一般尖峰工作負載需要四個執行個體，您應該佈建六個執行個體：(2/3 * 6 個執行個體) = 4 個執行個體。
使用專用環境來部署區域備援 App Service
若要了解如何在 v2 隔離式方案上建立 App Service 環境 v3，請參閱建立 App Service 環境。
疑難排解
| 錯誤訊息 | 描述 | 建議 |
|---|---|---|
| 資源群組 'RG-NAME' 無法使用區域備援。 請將 App Service 方案 'ASP-NAME' 部署到新的資源群組。 | 只有較新的 App Service 使用量才支援可用性區域。 即使您使用其中一個支援的區域，如果資源群組不支援可用性區域，仍會收到錯誤。 | 若要確保您的工作負載落在支援可用性區域的戳記上，請建立新的資源群組、App Service 方案和 App Service。 |
容錯
為因應可用性區域故障，您應該超量佈建服務的容量，以確保解決方案可以容許 1/3 的容量損失，並在整個區域的中斷期間繼續正常運作，而不會降低效能。 由於平台會將 VM 分散到三個區域，因此您必須至少考慮一個區域的失敗，請將尖峰工作負載執行個體計數乘以區域/(zone-1) 或 3/2 的因素。 例如，如果您的一般尖峰工作負載需要四個執行個體，您應該佈建六個執行個體：(2/3 * 6 個執行個體) = 4 個執行個體。
區域關閉體驗
流量會路由至所有可用的 App Service 執行個體。 在區域關閉的情況下，App Service 平台會偵測遺失的執行個體，並自動嘗試尋找新的取代執行個體，並視需要分散流量。 如果您已設定自動調整，而且其決定需要更多執行個體，則自動調整也會向 App Service 發出要求以新增更多執行個體。 請注意，自動調整行為與 App Service 平台行為無關，而且您的自動調整執行個體計數規格不需要是三的倍數。
注意
在區域關閉的案例中，其他執行個體的要求不一定會成功。 遺失執行個體的回填會以最佳方式進行。 建議的解決方案是如下一節所述，建立和設定 App Service 方案，以將遺失區域納入考量。
如果 App Service 方案具備已啟用的可用性區域，則即使相同區域中的其他區域出現中斷情形，在方案中部署的應用程式仍然可以繼續運行並提供流量。 不過，包括 App Service 方案調整、應用程式建立、應用程式設定和應用程式發佈的非執行階段行為，仍可能會受到其他可用性區域中斷的影響。 App Service 方案的區域備援只會確保已部署應用程式的持續運作時間。
當 App Service 平台將執行個體配置給區域備援 App Service 方案時，其會使用基礎 Azure 虛擬機器擴展集所提供的最佳工作區域平衡。 如果每個區域具有相同數目的 VM 或 +/- App Service 方案所使用所有其他區域中的一個 VM，則 App Service 方案將會「平衡」。
可用性區域移轉
您無法將現有的 App Service 執行個體或環境資源從非可用性區域支援移轉至可用性區域支援。 若要取得可用性區域的支援，您必須建立已啟用可用性區域的資源。
定價
對於使用 App Service Premium v2 或 Premium v3 方案的多租用戶環境，只要您在 App Service 方案中有三個以上的實例，就不需要額外的成本來啟用可用性區域。 系統會根據 App Service 方案 SKU、您指定的容量，以及您根據自動調整準則調整的任何執行個體向您收費。 如果您啟用可用性區域，但指定小於三的容量，則平台會強制執行三的最小執行個體計數，並向您收取這三個執行個體的費用。 App Service 環境 v3 對於可用性區域有不同的定價模式。 如需 App Service 環境 v3 的定價資訊，請參閱定價。
跨區域災害復原和商務持續性
災害復原 (DR)是指從重大影響事件中復原，例如自然災害或不成功的部署 (導致停機和資料遺失)。 無論原因為何，解決災害的最佳辦法是定義完善且經過測試的 DR 方案，以及主動支援 DR 的應用程式設計。 開始思考建立災害復原方案之前，請參閱設計災害復原策略的建議。
Microsoft 在災害復原方面採取共同責任模型。 在共同責任模型中，Microsoft 確保基準基礎結構和平台服務可供使用。 此時，許多 Azure 服務不會自動複寫資料，或從失敗區域回復為交叉複寫到另一個已啟用的區域。 您需要為這些服務制定適合工作負載的災害復原方案。 在 Azure 平台即服務 (PaaS) 供應項目上執行的多數服務，都有提供支援災害復原的功能和指導，您可以使用特定服務功能復原，制定災害復原方案。
本節說明將 Web 應用程式部署至 App Service 的一些常見策略。
在 App Service 中建立 Web 應用程式並在資源建立期間選擇 Azure 區域時，這是單一區域應用程式。 如果區域在災害期間變成無法使用，您的應用程式也會變成無法使用。 如果您使用多區域地理架構在次要 Azure 區域中建立相同的部署，應用程式就不容易遭受單一區域災害影響，這可保證商務持續性。 跨區域的任何資料複寫都可讓您復原上一次的應用程式狀態。
對 IT 而言，商務持續性計劃主要由復原時間目標 (RTO) 和恢復點目標 (RPO) 驅動。 如需 RTO 和 RPO 的詳細資訊，請參閱復原目標。
對區域災害來說，維護 RTO 周圍的 SLA 通常不切實際，您往往也會將災害復原策略設計成以 RPO 為主 (也就是專注於資料復原，而不是將中斷比例降至最低)。 但透過 Azure，為自動異地容錯移轉部署 App Service 不僅實用，甚至可以很直接。 這讓您更進一步地為應用程式進行防災處理，同時兼顧到 RTO 和 RPO。
視您所需的 RTO 和 RPO 計量而定，有三種災害復原架構常用於 App Service 多租用戶和 App Service 環境。 下表說明每個架構：
| 計量 | 主動-主動 | 主動-被動 | 被動/極非經常性存取 |
|---|---|---|---|
| 復原時間目標 (RTO) | 即時或秒 | 分鐘 | 小時 |
| 復原點目標 (RPO) | 即時或秒 | 分鐘 | 小時 |
| 成本 | $$$ | $$ | $ |
| 案例 | 關鍵任務應用程式 | 高優先順序應用程式 | 低優先順序應用程式 |
| 提供多區域使用者流量的能力 | Yes | 是/可能 | No |
| 程式碼部署 | 慣用 CI/CD 管線 | 慣用 CI/CD 管線 | 備份和還原 |
| 在停機期間建立新的 App Service 資源 | 非必要 | 非必要 | 必要 |
注意
應用程式很可能相依於 Azure 中的其他資料服務，例如 Azure SQL Database 和 Azure 儲存體帳戶。 建議您也為每個相依的 Azure 服務制定災害復原策略。 若為 SQL Database，請參閱 Azure SQL Database 的主動式異地複寫。 若為 Azure 儲存體，請參閱 Azure 儲存體備援。
多區域地理位置的災害復原
有多種方式可以「主動-主動」或「主動-被動」架構跨 Azure 區域複寫 Web 應用程式內容和組態，例如使用 App Service 備份與還原。 不過，備份與還原會建立時間點快照集，最終會導致跨區域發生 Web 應用程式版本控制的難題。 請參閱下表，以取得備份與還原指導和災害復原指導之間的比較：
備份和還原 vs. 災害復原
| 平台 | 備份和還原指導 | 災害復原指南 |
|---|---|---|
| App Service web 應用程式 (免費和共用定價層) |
如果您已將 Web 應用程式部署至免費或共用層，且需要存取這些 Web 應用程式的備份和還原功能，請調整為基本層或更高層級。 | 在區域性災害期間，將 App Service 資源帶回不同的 Azure 區域中。 如從全區域失敗復原一文中所述，從 2025 年 3 月 31 日起，在 Azure 區域中的災害期間，App Service 應用程式將不會處於災害復原模式。 我們建議您實作常用的災害復原技術，以防止在區域性災害期間發生停機和資料遺失。 |
| App Service web 應用程式 (基本、標準和進階定價層) |
在 Azure App Service 中，可進行隨選自訂備份或使用自動備份。 您可以藉由還原至新應用程式或位置，或是覆寫現有的應用程式以還原備份。 請參閱在 Azure App Service 中備份並還原應用程式，以取得更多資訊。 |
如需如何在區域性災害期間，將 App Service 資源在不同 Azure 區域中重新連線的最新指導，請參閱從全區域失敗中復原 - Azure App Service。 如從全區域失敗復原一文中所述，從 2025 年 3 月 31 日起，在 Azure 區域中的災害期間，App Service web 應用程式將不再處於災害復原模式。 我們鼓勵您實作常用的災害復原技術，以避免發生區域性災害時，Web 應用程式的功能或資料遺失。 |
| App Service 環境 (V2 和 V3) | 在 Azure App Service 環境中，可進行隨選自訂備份或利用自動備份。 自動備份可還原至相同的 App Service 環境內、而非在另一個 App Service 環境中的目標應用程式。 可以將自訂備份還原至另一個 App Service 環境中的目標應用程式，例如從 V2 App Service 環境還原至 V3 App Service 環境。 備份可以還原至與來源應用程式相同的 OS 平台目標應用程式。 請參閱在 Azure App Service 中備份並還原應用程式，以取得更多詳細資訊。 |
我們鼓勵您使用常用的災害復原技術，為部署到 App Service 環境的 Web 應用程式實作災害復原指導。 |
| Azure Functions： 專用方案 |
您在專用 (App Service) 方案中執行函式應用程式時，所需的函式應用程式內容會使用內建儲存體來維護。 在專用方案中，您可以進行隨選自訂備份或利用自動備份。 您可以藉由還原至新應用程式或位置，或是覆寫現有的應用程式以還原備份。 如需詳細資訊，請參閱在 Azure App Service 中備份和還原您的應用程式。 專用方案不會使用 Azure 檔案儲存體，但如果您使用 Azure 檔案儲存體連線錯誤設定了應用程式，則不支援備份。 |
有關如何在發生區域災害期間讓專用方案中的函式應用程式資源在不同的 Azure 區域中恢復連線的最新指導，請參閱從區域範圍內的失敗中復原 - Azure App Service。 如從全區域失敗復原一文中所述，從 2025 年 3 月 31 日起，在 Azure 區域中的災害期間，App Service 應用程式將不會處於災害復原模式。 您應該改為規劃函式應用程式的可靠性。 您也可以參閱專用方案中函式應用程式的常用災害復原技術。 |
| Azure Functions： 彈性取用、 取用和進階方案 |
在彈性取用方案、取用方案或進階方案中執行的函式應用程式無法使用 App Service 中的自訂或自動備份功能。 在這些動態調整方案中，函式應用程式內容會在 Azure 儲存體中維護。 使用 Azure 儲存體備援選項，以確保儲存體帳戶在中斷期間符合其可用性和持久性目標。 您也可以從 Azure 入口網站將現有函式應用程式專案下載為 .zip 檔案。 |
我們強烈建議您規劃函式應用的可靠性。 |
若要避免備份與還原方法的限制，請將 CI/CD 管線設定為將程式碼部署至兩個 Azure 區域。 請考慮使用 Azure Pipelines 或 GitHub Actions。 如需詳細資訊，請參閱持續部署至 Azure App Service。
中斷偵測、通知及管理
建議您為 Web 應用程式設定監視和警示，以在災害期間及時收到通知。 如需詳細資訊，請參閱 Application Insights 可用性測試。
若要在 Azure 中管理應用程式資源，請使用基礎結構即程式碼 (IaC) 機制。 在跨多個區域的複雜部署中，若要獨立管理區域，並以可靠的方式讓設定保持跨區域同步，需要可預測、可測試且可重複的流程。 請考慮 IaC 工具，例如 Azure Resource Manager 範本或 Terraform。
設定災害復原和中斷偵測
若要準備在多區域地理位置進行災害復原，可使用「主動-主動」或「主動-被動」架構。
主動-主動架構
在「主動-主動」災害復原架構中，相同的 Web 應用程式會部署在兩個不同的區域中，而 Azure Front Door 則用來將流量路由傳送至兩個使用中的區域。
使用此範例架構：
- 相同的 App Service 應用程式會部署在兩個不同的區域中，包括定價層和執行個體計數。
- 直接流入 App Service 應用程式的公用流量遭到封鎖。
- Azure Front Door 會用來將流量路由傳送至使用中的區域。
- 在災害期間，其中一個區域離線，而 Azure Front Door 會將流量專門路由傳送到仍維持連線的區域。 在這類異地容錯移轉期間，RTO 接近零。
- 應用程式檔案應部署至兩個採用 CI/CD 解決方案的 Web 應用程式。 這可確保 RPO 幾乎為零。
- 如果您的應用程式主動修改檔案系統，則最小化 RPO 的最佳方式是只寫入掛接的 Azure 儲存體共用，而不是直接寫入 Web 應用程式的 /home 內容共用。 然後，為掛接共用使用 Azure 儲存體備援功能 (GZRS 或 GRS)，其中的 RPO 約 15 分鐘。
在 App Service 中為 Web 應用程式建立「主動-主動」架構的步驟摘要如下：
在兩個不同的 Azure 區域中建立兩個 App Service 方案。 以相同方式設定兩個 App Service 方案。
建立 Web 應用程式的兩個執行個體，每個 App Service 方案中各有一個。
使用下列項目建立 Azure Front Door 設定檔：
- 端點。
- 兩個原點群組，每個群組的優先順序為 1。 優先順序相等時，則會告知 Azure Front Door 將流量平均路由傳送至這兩個區域 (因此兩者均為「主動-主動」)。
- 路由。
設定及配置所有其他後端 Azure 服務，例如資料庫、儲存體帳戶和驗證提供者。
使用持續部署，將程式碼部署至兩個 Web 應用程式。
教學課程：在 Azure App Service 中建立高可用性的多區域應用程式會示範如何設定主動-被動架構。 以最小的變更採取相同的步驟 (在 Azure Front Door 中將原點群組中兩個原點的優先順序設為「1」) 即可建立主動-主動結構。
主動-被動架構
在這個災害復原方法中，相同的 Web 應用程式會部署在兩個不同的區域中，而 Azure Front Door 則用來將流量路由傳送至其中一個區域 (使用中區域)。
使用此範例架構：
相同的 App Service 應用程式會部署在兩個不同區域。
直接流入 App Service 應用程式的公用流量遭到封鎖。
Azure Front Door 是用來將流量路由傳送至主要區域。
為了節省成本，次要 App Service 方案會設定為使用較少的執行個體和/或較低的定價層。 有三種可能的方法：
慣用：次要 App Service 方案使用與主要方案相同的定價層，且執行個體數目相同或更少。 此方法可確保這兩個 App Service 方案的功能和 VM 大小均等。 異地容錯移轉期間的 RTO 僅取決於擴增執行個體的時間。
次慣用：次要 App Service 方案使用相同的定價層型別 (例如 PremiumV3)，但 VM 大小較小且執行個體數也較少。 例如，主要區域可能位於 P3V3 層，而次要區域位於 P1V3 層。 此方法仍可確保兩個 App Service 方案的功能相等，但若次要區域變成使用中區域時，大小不相等的區域可能需要手動擴大。 異地容錯移轉期間的 RTO 取決於擴大和擴增執行個體的時間。
最少慣用：次要 App Service 方案的定價層不同於主要方案且執行個體數較少。 例如，主要區域可能位於 P3V3 層，而次要區域位於 S1 層。 請確定次要 App Service 方案提供應用程式執行所需的所有功能。 這兩者之間的功能可用性差異可能會造成 Web 應用程式復原延遲。 異地容錯移轉期間的 RTO 取決於擴大和擴增執行個體的時間。
如果使用中區域變成非使用中，會在次要區域上設定自動調整。 建議在主動和被動區域中建立類似的自動調整規則。
在災害發生期間，主要區域會變成非使用中，而次要區域會開始接收流量並變成使用中區域。
如果次要區域變成使用中，網路負載會觸發預先設定的自動調整規則，以擴增次要 Web 應用程式。
如果次要區域還沒有使用中區域執行所需的功能，則您可能需要手動擴大次要區域的定價層。 例如，自動調整需要標準層或更高層級。
如果主要區域再次處於使用中狀態，Azure Front Door 會自動將流量重新導回該區域，而架構會像以前一樣回到「主動-被動」模式。
應用程式檔案應部署至兩個採用 CI/CD 解決方案的 Web 應用程式。 這可確保 RPO 幾乎為零。
如果您的應用程式主動修改檔案系統，則最小化 RPO 的最佳方式是只寫入掛接的 Azure 儲存體共用，而不是直接寫入 Web 應用程式的 /home 內容共用。 然後，為掛接共用使用 Azure 儲存體備援功能 (GZRS 或 GRS)，其中的 RPO 約 15 分鐘。
在 App Service 中為 Web 應用程式建立「主動-被動」架構的步驟摘要如下：
- 在兩個不同的 Azure 區域中建立兩個 App Service 方案。 次要 App Service 方案可以使用先前所述的其中一種方法來佈建。
- 設定次要 App Service 方案的自動調整規則，以便在主要區域變成非使用中時，調整成與主要區域相同的執行個體計數。
- 建立 Web 應用程式的兩個執行個體，每個 App Service 方案中各有一個。
- 使用下列項目建立 Azure Front Door 設定檔：
- 端點。
- 原點群組在主要區域中的優先順序為 1。
- 第二個原點群組在次要區域中的優先順序為 2。 優先順序差異會告知 Azure Front Door 在連線時優先使用主要區域 (因此是「主動-被動」模式)。
- 路由。
- 僅限從 Azure Front Door 執行個體到 Web 應用程式的網路流量。
- 設定及配置所有其他後端 Azure 服務，例如資料庫、儲存體帳戶和驗證提供者。
- 使用持續部署，將程式碼部署至兩個 Web 應用程式。
教學課程：在 Azure App Service 中建立高可用性的多區域應用程式會示範如何設定主動-被動架構。
被動-極非經常性存取架構
使用「被動/極非經常性存取」架構，在位於另一個區域的 Azure 儲存體帳戶中建立和維護 Web 應用程式的一般備份。
使用此範例架構：
單一 Web 應用程式會部署到單一區域。
Web 應用程式會定期備份至相同區域中的 Azure 儲存體帳戶。
備份的跨區域複寫取決於 Azure 儲存體帳戶中的資料備援設定。 您應該盡可能將 Azure 儲存體帳戶設定為 GZRS。 GZRS 可以在一個區域中提供同步區域備援，並在次要區域中提供非同步備援。 如果無法使用 GZRS，請將帳戶設定為 GRS。 GZRS 和 GRS 的 RPO 大約 15 分鐘。
為了確保您可以在儲存體帳戶的主要區域無法使用時擷取備份，啟用次要區域的唯讀存取權 (分別設定儲存體帳戶 RA-GZRS 或 RA-GRS)。 如需有關設計應用程式以利用異地備援的詳細資訊，請參閱使用異地備援來設計高可用性應用程式。
在 Web 應用程式區域發生災害期間，您必須使用 Azure 儲存體帳戶中的備份 (最有可能的是使用讀取權存取次要區域)，手動部署所有必要的 App Service 相依資源。 RTO 可能是幾小時或幾天。
若要將 RTO 降到最低，強烈建議您建立完整的教戰守則，概述將 Web 應用程式備份還原至另一個 Azure 區域的所有必要步驟。
在 App Service 中為 Web 應用程式建立「被動-極非經常性存取」區域的步驟摘要如下：
使用與 Web 應用程式相同的區域，建立 Azure 儲存體帳戶。 選擇 [標準效能層級]，然後選取備援作為異地備援儲存體 (GRS) 或異地區域備援儲存體 (GZRS)。
啟用 RA-GRS 或 RA-GZRS (次要區域的讀取存取權)。
為 Web 應用程式設定自訂備份。 您可以決定如何設定 Web 應用程式備份的排程，例如每小時。
確認可以從儲存體帳戶的次要區域擷取 Web 應用程式備份檔。
提示
除了 Azure Front Door 之外，Azure 還提供其他負載平衡選項，例如 Azure 流量管理員。 如需各種選項的比較，請參閱負載平衡選項 - Azure 架構中心。
單一區域地理位置的災害復原
如果您的 Web 應用程式區域沒有 GZRS 或 GRS 儲存體，或您位於非區域配對的 Azure 區域中，則必須使用區域備援儲存體 (ZRS) 或本地備援儲存體 (LRS) 來建立類似的架構。 例如，您可以手動建立儲存體帳戶的次要區域，如下所示：
建立不含 GRS 和 GZRS 的「被動-極非經常性存取」區域的步驟摘要如下：
在 Web 應用程式的相同區域中，建立 Azure 儲存體帳戶。 選擇 [標準效能層級]，然後選取備援作為區域備援儲存體 (ZRS)。
為 Web 應用程式設定自訂備份。 您可以決定如何設定 Web 應用程式備份的排程，例如每小時。
確認可以從儲存體帳戶的次要區域擷取 Web 應用程式備份檔。
在不同的區域中建立第二個 Azure 儲存體帳戶。 選擇 [標準效能層級]，然後選取備援作為本地備援儲存體 (LRS)。
藉由使用 AzCopy 之類的工具，將自訂備份 (Zip、XML 和記錄檔) 從主要區域複寫到次要儲存體。 例如：
azcopy copy 'https://<source-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>' 'https://<destination-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>'您可以使用 Azure 自動化搭配 PowerShell 工作流程 Runbook，按排程執行複寫指令碼。 請確定複寫排程遵循與 Web 應用程式備份類似的排程。