本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 雲端中的災難復原選項
您在 AWS 中可用的災難復原策略可以廣泛分為四種方法，從低成本和低複雜性的備份，到使用多個作用中區域更複雜的策略。主動/被動策略使用主動網站 （例如 AWS 區域） 來託管工作負載並提供流量。被動網站 （例如不同的 AWS 區域） 用於復原。在觸發容錯移轉事件之前，被動網站不會主動提供流量。
定期評估和測試災難復原策略至關重要，以便您可以放心地在必要時叫用災難復原策略。使用 [AWS Resilience Hub](https://aws.amazon.com/resilience-hub/) 持續驗證和追蹤 AWS 工作負載的彈性，包括您是否可能符合 RTO 和 RPO 目標。
![\[顯示災難復原策略和每個策略重點的圖表。\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/disaster-recovery-workloads-on-aws/images/disaster-recovery-strategies.png)
*圖 6 - 災難復原策略 *
對於在[架構良好](https://aws.amazon.com/architecture/well-architected/)、高可用性工作負載中中斷或遺失一個實體資料中心的災難事件，您可能只需要備份和還原方法來進行災難復原。如果您的災難定義超出了區域實體資料中心的中斷或遺失，或者如果您受到法規要求，則應考慮指示燈、暖待命或多站台主動/主動。
選擇您的策略以及實作策略的 AWS 資源時，請記住，在 AWS 中，我們通常會將*服務劃分為資料平面*和*控制平面*。資料平面負責提供即時服務，而控制平面則用於設定環境。為了達到最大的彈性，您應該僅使用資料平面操作做為容錯移轉操作的一部分。這是因為資料平面通常比控制平面具有更高的可用性設計目標。
## 備份和還原
備份和還原是緩解資料遺失或損毀的適當方法。此方法也可以透過將資料複寫到其他 AWS 區域來緩解區域災難，或減輕部署到單一可用區域的工作負載缺乏備援。除了資料之外，您還必須在復原區域中重新部署基礎設施、組態和應用程式程式碼。若要快速重新部署基礎設施而不發生錯誤，您應該一律使用基礎設施做為程式碼 (IaC) 來部署，例如 [AWS CloudFormation](https://aws.amazon.com/cloudformation)或 [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk)。如果沒有 IaC，在復原區域中還原工作負載可能會很複雜，這將導致復原時間增加，並可能超過您的 RTO。除了使用者資料之外，也請務必備份程式碼和組態，包括您用來建立 [Amazon EC2 執行個體的 Amazon Machine Image (AMIs)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html)。 Amazon EC2 您可以使用 [AWS CodePipeline](https://aws.amazon.com/codepipeline) 自動重新部署應用程式程式碼和組態。
![\[顯示備份和還原架構的架構圖\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/disaster-recovery-workloads-on-aws/images/backup-restore-architecture.png)
*圖 7 - 備份和還原架構 *
### AWS 服務
您的工作負載資料需要定期執行或持續執行的備份策略。執行備份的頻率將決定可實現的復原點 （應符合您的 RPO)。備份也應該提供將其還原至擷取時間點的方法。具有point-in-time復原的備份可透過下列服務和資源取得：
+ [Amazon Elastic Block Store (Amazon EBS) 快照](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
+ [Amazon DynamoDB 備份](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.html)
+ [Amazon RDS 快照](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_CommonTasks.BackupRestore.html)
+ [Amazon Aurora 資料庫快照](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_CreateSnapshotCluster.html)
+ [Amazon EFS 備份](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html) （使用 時 AWS Backup)
+ [Amazon Redshift 快照](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-snapshots.html)
+ [Amazon Neptune 快照](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-overview.html)
+ [Amazon DocumentDB](https://docs.aws.amazon.com/documentdb/latest/developerguide/backup_restore.html)
+ [ Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html)、[Amazon FSx for Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/using-backups-fsx.html)、[Amazon FSx for NetApp ONTAP](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/using-backups.html) 和 [Amazon FSx for OpenZFS ](https://docs.aws.amazon.com/fsx/latest/OpenZFSGuide/using-backups.html)
對於 Amazon Simple Storage Service (Amazon S3)，您可以使用 [Amazon S3 跨區域複寫 (CRR)](https://aws.amazon.com/s3/features/replication/) 以非同步方式持續將物件複製到 DR 區域中的 S3 儲存貯體，同時為存放的物件提供版本控制，以便選擇還原點。持續複寫資料的優點是備份資料的最短時間 （接近零），但可能無法防範災難事件，例如資料損毀或惡意攻擊 （例如未經授權的資料刪除） 以及point-in-time備份。持續複寫涵蓋在 [AWS Services for Pilot Light](#aws-services-1) 區段中。
[AWS Backup](https://aws.amazon.com/backup) 提供集中位置來設定、排程和監控下列 服務和資源的 AWS 備份功能：
+ [Amazon Elastic Block Store (Amazon EBS)](https://aws.amazon.com/ebs/) 磁碟區
+ [Amazon EC2 執行個體](https://aws.amazon.com/ec2/)
+ [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds/) 資料庫 （包括 [Amazon Aurora](https://aws.amazon.com/rds/aurora/) 資料庫）
+ [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 資料表
+ [Amazon Elastic File System (Amazon EFS)](https://aws.amazon.com/efs/) 檔案系統
+ [AWS Storage Gateway](https://aws.amazon.com/storagegateway/) 磁碟區
+ [Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html)、[Amazon FSx for Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/using-backups-fsx.html)、[Amazon FSx for NetApp ONTAP](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/using-backups.html) 和 [Amazon FSx for OpenZFS](https://docs.aws.amazon.com/fsx/latest/OpenZFSGuide/aws-backup-and-fsx.html)
AWS Backup 支援跨 區域複製備份，例如 至災難復原區域。
作為 Amazon S3 資料的額外災難復原策略，請啟用 [S3 物件版本控制](https://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html)。物件版本控制可在動作之前保留原始版本，以保護 S3 中的資料免於刪除或修改動作的後果。物件版本控制可有效緩解人為錯誤類型的災難。如果您使用 S3 複寫將資料備份到 DR 區域，則根據預設，當來源儲存貯體中刪除物件時，[Amazon S3 只會在來源儲存貯體中新增刪除標記](https://docs.aws.amazon.com/AmazonS3/latest/dev/delete-marker-replication.html)。此方法可保護 DR 區域中的資料，避免來源區域中的惡意刪除。
除了資料之外，您還必須備份必要的組態和基礎設施，以重新部署工作負載並滿足復原時間目標 (RTO)。 [AWS CloudFormation](https://aws.amazon.com/cloudformation)提供基礎設施即程式碼 (IaC)，並可讓您定義工作負載中的所有 AWS 資源，以便可靠地部署和重新部署到多個 AWS 帳戶和 AWS 區域。您可以將工作負載使用的 Amazon EC2 執行個體備份為 Amazon Machine Image (AMIs)。AMI 是從執行個體根磁碟區的快照，以及連接至執行個體的任何其他 EBS 磁碟區建立。您可以使用此 AMI 啟動 EC2 執行個體的還原版本。您可以在 區域內或跨區域[複製 AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/CopyingAMIs.html)。或者，您可以使用 [AWS Backup](https://aws.amazon.com/backup)將備份跨帳戶複製到其他 AWS 區域。跨帳戶備份功能有助於防止災難事件，包括內部威脅或帳戶入侵。 除了執行個體的個別 EBS 磁碟區之外， AWS Backup 還新增額外的 EC2 備份功能， AWS Backup 也會存放和追蹤下列中繼資料：執行個體類型、設定的虛擬私有雲端 (VPC)、安全群組、[IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)、監控組態和標籤。不過，只有在將 EC2 備份還原至相同的 AWS 區域時，才會使用此額外的中繼資料。
存放在災難復原區域中做為備份的任何資料都必須在容錯移轉時還原。 AWS Backup 提供還原功能，但目前未啟用排程或自動還原。您可以使用 AWS 開發套件來呼叫 APIs，實作自動還原至 DR 區域 AWS Backup。您可以將此設定為定期重複任務，或在每次備份完成時觸發還原。下圖顯示使用 [Amazon Simple Notification Service (Amazon SNS)](https://aws.amazon.com/sns/) 和 自動還原的範例[AWS Lambda](https://aws.amazon.com/lambda/)。實作排定的定期資料還原是個好主意，因為從備份還原的資料是控制平面操作。如果此操作在災難期間無法使用，您仍然可以從最近的備份建立可操作的資料存放區。
![\[顯示還原和測試備份工作流程的圖表。\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/disaster-recovery-workloads-on-aws/images/restore-test-backups.png)
*圖 8 - 還原和測試備份 *
**注意**
備份策略必須包括測試備份。如需詳細資訊，請參閱[測試災難復原](testing-disaster-recovery.md)一節。請參閱 [AWS Well-Architected Lab：測試資料的備份和還原](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)，以實際示範實作。
## 指示燈
使用*指示燈*方法，您可以將資料從一個區域複寫到另一個區域，並佈建核心工作負載基礎設施的副本。支援資料複寫和備份所需的資源 (例如資料庫和物件儲存) 始終處於開啟狀態。其他元素，例如應用程式伺服器，會載入應用程式碼和組態，但「關閉」並只在測試期間或調用災難復原容錯移轉時使用。在雲端中，您可以在不需要資源時彈性取消佈建資源，並在執行時佈建資源。「關閉」的最佳實務是不部署資源，然後視需要建立組態和功能來部署資源 (「開啟」)。與備份和還原方法不同，您的核心基礎設施一律可用，而且您隨時可以選擇透過開啟和擴展應用程式伺服器來快速佈建完整規模的生產環境。
![\[指示燈架構的參考架構圖\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/disaster-recovery-workloads-on-aws/images/pilot-light-architecture.png)
*圖 9 - 指示燈架構*
指示燈方法透過將作用中資源降至最低，將災難復原的持續成本降至最低，並在災難發生時簡化復原，因為核心基礎設施要求都已就緒。此復原選項會要求您變更部署方法。您需要對每個區域進行核心基礎設施變更，並將工作負載 （組態、程式碼） 變更同時部署到每個區域。您可以透過自動化部署並使用基礎設施做為程式碼 (IaC) 跨多個帳戶和區域部署基礎設施 （完整基礎設施部署至主要區域，以及縮減/關閉基礎設施部署至 DR 區域），來簡化此步驟。建議您在每個區域使用不同的 帳戶，以提供最高層級的資源和安全隔離 （如果遭入侵的登入資料也是您災難復原計畫的一部分）。
使用此方法，您還必須緩解資料災難。持續資料複寫可以保護您防範某些類型的災難，但它不能保護您防範資料損毀或破壞，除非您的策略也包括所存放資料的版本控制，或時間點復原的選項。您可以在災難區域中備份複寫的資料，以在相同區域中建立point-in-time備份。
### AWS 服務
除了使用[備份和還原](#backup-and-restore)區段中涵蓋的 AWS 服務來建立point-in-time備份之外，也請為您的指示燈策略考慮下列服務。
對於指示燈，持續資料複寫到 DR 區域中的即時資料庫和資料存放區是低 RPO 的最佳方法 （除了先前討論point-in-time備份之外使用時）。AWS 使用下列服務和資源，為資料提供持續、跨區域、非同步的資料複寫：
+ [Amazon Simple Storage Service (Amazon S3) 複寫](https://aws.amazon.com/s3/features/replication/)
+ [Amazon RDS 僅供讀取複本](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.XRgn.Cnsdr)
+ [Amazon Aurora 全域資料庫](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)
+ [Amazon DynamoDB 全域資料表](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
+ [Amazon DocumentDB 全域叢集](https://docs.aws.amazon.com/documentdb/latest/developerguide/global-clusters.html)
+ [Amazon ElastiCache (Redis OSS) 的全域資料存放區](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/Redis-Global-Datastore.html)
透過持續複寫，資料版本幾乎可在您的 DR 區域中立即使用。您可以使用 S[3 物件的 S3 複寫時間控制 (S3 RTC)](https://docs.aws.amazon.com/AmazonS3/latest/dev/replication-time-control.html) S3和 [Amazon Aurora 全域資料庫的管理功能](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-managing.html)等服務功能來監控實際的複寫時間。
當容錯移轉從災難復原區域執行讀取/寫入工作負載時，您必須提升 RDS 僅供讀取複本，才能成為主要執行個體。對於 [Aurora 以外的資料庫執行個體，程序](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Promote)需要幾分鐘才能完成，重新啟動是程序的一部分。對於使用 RDS 的跨區域複寫 (CRR) 和容錯移轉，使用 [Amazon Aurora 全域資料庫](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)提供數種優點。全球資料庫使用專用基礎設施，讓您的資料庫完全可供您的應用程式使用，並且可以複寫到一般延遲低於一秒的次要區域 (AWS 區域內的延遲遠低於 100 毫秒）。使用 Amazon Aurora 全域資料庫，如果您的主要區域發生效能降低或中斷，即使發生完整的區域中斷，您也可以提升其中一個次要區域在不到一分鐘內承擔讀取/寫入責任。您也可以設定 Aurora 來監控所有次要叢集的 RPO 延遲時間，以確保至少一個次要叢集保持在目標 RPO 時段內。
具有較少或較小資源的核心工作負載基礎設施的縮減版本，必須部署在您的 DR 區域中。使用 AWS CloudFormation，您可以定義基礎設施，並在 AWS 帳戶和 AWS 區域之間一致地部署。 AWS CloudFormation 使用預先定義的[虛擬參數](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/pseudo-parameter-reference.html)來識別部署的 AWS 帳戶和 AWS 區域。因此，您可以在 [ CloudFormation 範本中實作條件邏輯](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/conditions-section-structure.html)，以在 DR 區域中僅部署基礎設施的縮減規模版本。對於 EC2 執行個體部署，Amazon Machine Image (AMI) 會提供硬體組態和安裝的軟體等資訊。您可以實作[映像建置器](https://docs.aws.amazon.com/imagebuilder/latest/userguide/what-is-image-builder.html)管道，建立您需要AMIs，並將其複製到主要和備份區域。這有助於確保這些*黃金 AMIs* 擁有在發生災難事件時，在新區域中重新部署或擴展工作負載所需的一切。Amazon EC2 執行個體會部署在縮減規模的組態中 （相較於主要區域，執行個體較少）。若要橫向擴展基礎設施以支援生產流量，請參閱[「暖待命](#warm-standby)」一節中的 [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling)。
對於主動/被動組態，例如指示燈，所有流量最初都會進入主要區域，並在主要區域不再可用時切換到災難復原區域。此容錯移轉作業可以自動或手動啟動。根據運作狀態檢查或警示自動啟動容錯移轉時，應謹慎使用。即使使用此處討論的最佳實務，復原時間和復原點也會大於零，並導致可用性和資料的某些損失。如果您在不需要 （錯誤警示） 時容錯移轉，則會發生這些損失。因此通常使用手動啟動的容錯移轉。在此情況下，您仍應將容錯移轉的步驟自動化，讓手動啟動就像按下按鈕一樣簡易。
使用 AWS 服務時，有幾個流量管理選項需要考慮。
一種選擇是使用 [Amazon Route 53](https://aws.amazon.com/route53)。使用 Amazon Route 53，您可以將一或多個 AWS 區域中的多個 IP 端點與 Route 53 網域名稱建立關聯。然後，您可以將流量路由到該網域名稱下的適當端點。在容錯移轉時，您需要將流量切換到復原端點，並遠離主要端點。Amazon Route 53 運作狀態檢查會監控這些端點。使用這些運作狀態檢查，您可以設定自動啟動的 DNS 容錯移轉，以確保流量只會傳送到運作狀態良好的端點，這是在資料平面上進行的高度可靠操作。若要使用手動啟動的容錯移轉實作此項目，您可以使用 [Amazon Application Recovery Controller (ARC)](https://aws.amazon.com/route53/application-recovery-controller/)。使用 ARC，您可以建立 Route 53 運作狀態檢查，不實際檢查運作狀態，而是做為您可以完全控制的開啟/關閉開關。您可以使用 AWS CLI 或 AWS 開發套件，使用此高可用性的資料平面 API 來編寫容錯移轉指令碼。您的指令碼會切換這些切換 (Route 53 運作狀態檢查），告知 Route 53 將流量傳送至復原區域，而非主要區域。手動啟動容錯移轉的另一個選項是使用加權路由政策，並變更主要和復原區域的權重，以便所有流量流向復原區域。不過請注意，這是控制平面操作，因此不像使用 Amazon Application Recovery Controller (ARC) 的資料平面方法那樣有彈性。
另一個選項是使用 [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/)。使用 AnyCast IP，您可以將一或多個 AWS 區域中的多個端點與相同的靜態公有 IP 地址建立關聯。 AWS Global Accelerator 然後， 會將流量路由到與該地址相關聯的適當端點。[Global Accelerator 運作狀態檢查](https://docs.aws.amazon.com/global-accelerator/latest/dg/about-endpoint-groups-health-check-options.html)會監控端點。使用這些運作狀態檢查， 會 AWS Global Accelerator 檢查應用程式的運作狀態，並將使用者流量自動路由至運作狀態良好的應用程式端點。對於手動啟動的容錯移轉，您可以調整哪個端點使用流量撥號接收流量，但請注意這是控制平面操作。Global Accelerator 可降低應用程式端點的延遲，因為它利用廣泛的 AWS 邊緣網路，盡快將流量放置在 AWS 網路骨幹上。Global Accelerator 也可避免 DNS 系統 （例如 Route 53) 可能發生的快取問題。
[Amazon CloudFront](https://aws.amazon.com/cloudfront/) 提供原始伺服器容錯移轉，如果對主要端點的指定請求失敗，CloudFront 會將請求路由至次要端點。與之前描述的容錯移轉操作不同，所有後續請求仍然會移至主要端點，而且每個請求都會進行容錯移轉。
### AWS 彈性災難復原
[AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) (DRS) AWS 會使用基礎伺服器的區塊層級複寫，持續將伺服器託管的應用程式和伺服器託管資料庫從任何來源複寫至 。Elastic Disaster Recovery 可讓您使用 中的區域 AWS 雲端 作為內部部署或另一個雲端提供者及其環境上託管的工作負載的災難復原目標。如果 AWS 託管工作負載僅包含 EC2 上託管的應用程式和資料庫 （即不是 RDS)，則它也可以用於託管工作負載的災難復原。Elastic Disaster Recovery 使用指示燈策略，在用作預備區域的 [Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc/) 中維護資料副本和「關閉」資源。觸發容錯移轉事件時，暫存資源會用來自動在做為復原位置的目標 Amazon VPC 中建立完整容量部署。
![\[顯示 AWS Elastic Disaster Recovery 架構的架構圖。\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/disaster-recovery-workloads-on-aws/images/disaster-recovery-architecture.png)
*圖 10 - AWS 彈性災難復原架構*
## 暖待命
*暖待命*方法包括確保在另一個區域中有規模縮減但功能完整的生產環境副本。這種方法擴充了指示燈概念並減少了復原時間，因為您的工作負載始終在另一個區域中開啟。此方法也可讓您更輕鬆地執行測試或實作持續測試，以提高您對從災難復原能力的信心。
![\[顯示暖待命架構的架構圖。\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/disaster-recovery-workloads-on-aws/images/warm-standby-architecture.png)
*圖 11 - 暖待命架構 *
**注意：**[指示燈](#pilot-light)和[暖待命](#warm-standby)之間的差異有時很難理解。兩者都包含 DR 區域中的環境，其中包含主要區域資產的副本。差別在於，指示燈無法在未先採取其他動作的情況下處理請求，而暖待命可以立即處理流量 （容量降低）。指示燈方法需要您「開啟」伺服器，可能部署其他 （非核心） 基礎設施並向上擴展，而暖待命只需要您向上擴展 （所有項目都已部署並執行）。使用您的 RTO 和 RPO 需求，協助您選擇這些方法。
### AWS 服務
[備份和還原](#backup-and-restore)和[指示燈](#pilot-light)涵蓋的所有 AWS 服務也會在暖待命中用於資料備份、資料複寫、主動/被動流量路由，以及部署基礎設施，包括 EC2 執行個體。
[Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) 用於擴展 AWS 區域內的資源，包括 Amazon EC2 執行個體、Amazon ECS 任務、Amazon DynamoDB 輸送量和 Amazon Aurora 複本。[Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) 會在 AWS 區域內跨可用區域擴展 EC2 執行個體的部署，在該區域內提供彈性。使用 Auto Scaling 將 DR 區域擴展為完整的生產功能，作為指示燈或暖待命策略的一部分。例如，對於 EC2，增加 Auto Scaling 群組上*所需的容量*設定。您可以透過 手動調整此設定 AWS 管理主控台、透過 AWS 開發套件自動調整，或使用新的所需容量值重新部署 AWS CloudFormation 範本。您可以使用 AWS CloudFormation 參數，讓重新部署 CloudFormation 範本變得更容易。請確定 DR [區域中的服務配額](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)設定夠高，以免限制您擴展到生產容量。
由於 Auto Scaling 是一種控制平面活動，因此對它採取相依性將降低整體復原策略的彈性。這是權衡。您可以選擇佈建足夠的容量，讓復原區域可以處理部署的完整生產負載。此靜態穩定組態稱為*熱待命* （請參閱下一節）。或者，您可以選擇佈建較少的資源，其成本較低，但依賴 Auto Scaling。有些 DR 實作會部署足夠的資源來處理初始流量、確保低 RTO，然後依賴 Auto Scaling 來提升後續流量。
## 多站點主動/主動
您可以在多個區域中同時執行工作負載，做為*多站台主動/主動*或*熱待命主動/被動*策略的一部分。多站台作用中/作用中 （多站台作用中/作用中） 會為部署區域的所有流量提供服務，而熱待命只會為來自單一區域的流量提供服務，而其他區域則只會用於災難復原。透過多站台主動/主動方法，使用者可以在部署工作負載的任何區域中存取工作負載。這種方法是最複雜且成本最高的災難復原方法，但對於具有正確技術選擇和實作的大多數災難，它可以將復原時間縮短到接近零 （但是資料損毀可能需要依賴備份，這通常會導致非零的復原點）。熱待命使用主動/被動組態，其中只會將使用者導向單一區域，且 DR 區域不會接收流量。大多數客戶發現，如果他們要在第二個區域中站立一個完整的環境，則使用它是有意義的/有作用的。或者，如果您不想使用這兩個區域來處理使用者流量，則暖待命會提供更經濟且操作較不複雜的方法。
![\[顯示多站台主動/主動架構的架構圖 （將一個作用中路徑變更為非作用中以進行熱待命）\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/disaster-recovery-workloads-on-aws/images/multi-site-active-active-architecture.png)
*圖 12 - 多站台主動/主動架構 （將一個作用中路徑變更為非作用中以進行熱待命） *
使用多站台作用中/作用中時，由於工作負載正在多個區域中執行，因此在此案例中沒有容錯移轉等情況。在此情況下，災難復原測試會著重於工作負載對區域遺失的反應：流量是否從故障的區域路由出？ 其他 （區域） 是否可以處理所有流量？ 也需要測試資料災難。備份和復原仍然是必要的，應該定期測試。也應注意，涉及資料損毀、刪除或混淆的資料災難復原時間一律大於零，且復原點一律會在發現災難之前的某個時間點。如果需要多站台主動/主動 （或熱待命） 方法的額外複雜性和成本，以維持接近零的復原時間，則應採取額外的努力來維護安全性並防止人為錯誤，以減輕人為災難。
### AWS 服務
此處也使用[備份和還原](#backup-and-restore)、[指示燈](#pilot-light)和[暖待命](#warm-standby)涵蓋的所有 AWS 服務，進行point-in-time資料備份、資料複寫、主動/主動流量路由，以及部署和擴展基礎設施，包括 EC2 執行個體。
對於先前討論的主動/被動案例 （指示燈和暖待命），Amazon Route 53 和 AWS Global Accelerator 都可以用於將網路流量路由到作用中區域。對於此處的主動/主動策略，這兩個服務也啟用政策的定義，以決定哪些使用者前往哪個作用中區域端點。 AWS Global Accelerator 使用 設定[流量撥號以控制導向每個應用程式端點的流量百分比](https://docs.aws.amazon.com/global-accelerator/latest/dg/about-endpoint-groups-traffic-dial.html)。Amazon Route 53 支援此百分比方法，以及[多個其他可用的政策](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)，包括地理位置鄰近性和以延遲為基礎的政策。[Global Accelerator 會自動利用 AWS 邊緣伺服器的廣泛網路](https://docs.aws.amazon.com/global-accelerator/latest/dg/introduction-ip-ranges.html)，盡快將流量加入 AWS 網路骨幹，進而降低請求延遲。
使用此策略的非同步資料複寫可啟用近乎零的 RPO。[Amazon Aurora 全域資料庫](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)等 AWS 服務使用專用基礎設施，讓您的資料庫完全可供您的應用程式使用，並可複寫至最多五個次要區域，一般延遲不到一秒。使用主動/被動策略時，寫入只會發生在主要區域。主動/主動的差異在於設計如何處理與寫入每個主動區域的資料一致性。通常會設計要從最接近使用者的 區域提供的使用者讀取，稱為*本機讀取*。透過寫入，您有幾個選項：
+ *寫入全域*策略會將所有寫入路由至單一區域。如果該區域發生故障，則會提升另一個區域以接受寫入。[Aurora 全域資料庫](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)非常適合*全域寫入*，因為它支援跨區域與僅供讀取複本同步處理，而且您可以在一分鐘內提升其中一個次要區域承擔讀取/寫入責任。Aurora 也支援寫入轉送，可讓 Aurora 全域資料庫中的次要叢集將執行寫入操作的 SQL 陳述式轉送至主要叢集。
+ *寫入本機*策略路由寫入最接近的區域 （如同讀取）。[Amazon DynamoDB 全域資料表](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/globaltables.V2.html)可啟用此類策略，允許從部署全域資料表的每個區域進行讀取和寫入。Amazon DynamoDB 全域資料表使用*最後一個寫入器，可在並行更新之間取得*對帳。
+ *寫入分割*策略會根據分割區索引鍵 （例如使用者 ID) 將寫入指派給特定區域，以避免寫入衝突。雙向[設定的](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/) Amazon S3 複寫可用於此案例，目前支援兩個區域之間的複寫。實作此方法時，請務必在儲存貯體 A 和 B 上啟用[複本修改同步](https://docs.aws.amazon.com/AmazonS3/latest/dev/replication-for-metadata-changes.html)，以在複寫物件上複寫複本中繼資料變更，例如物件存取控制清單 (ACLs)、物件標籤或物件鎖定。您也可以設定是否要在作用中區域中的儲存貯體之間[複寫刪除標記](https://docs.aws.amazon.com/AmazonS3/latest/dev/delete-marker-replication.html)。除了複寫之外，您的策略還必須包含point-in-time備份，以防止資料損毀或損毀事件。
AWS CloudFormation 是一種強大的工具，可在多個 AWS 區域中的 AWS 帳戶之間強制執行持續部署的基礎設施。[AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) 可讓您透過單一操作，跨多個帳戶和區域建立、更新或刪除 CloudFormation 堆疊，藉此擴充此功能。雖然 AWS CloudFormation 使用 YAML 或 JSON 將基礎設施定義為程式碼，但 [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/)可讓您使用熟悉的程式設計語言將基礎設施定義為程式碼。您的程式碼會轉換為 CloudFormation，然後用於在 AWS 中部署資源。