REL10-BP01 將工作負載部署到多個位置

跨多個可用區域或視需要跨 AWS 區域，分配工作負載資料和資源。這些位置可視需要多樣化。

中的服務設計基礎原則之一 AWS 是避免基礎實體基礎設施中的單一故障點。這樣一來，我們將能建置可使用多個可用區域且能應對單一區故障的軟體和系統。同樣地，可將系統建置為能應對單一運算節點、單一儲存磁碟區或資料庫的單一執行個體的故障。建置依賴備援元件的系統時，請務必確保元件獨立運作，在 的情況下 AWS 區域，則自主運作。具有冗餘元件的理論可用性計算，其優點只有在符合此條件時才有效。

可用區域 （AZs）

AWS 區域 由多個可得區域組成，這些區域旨在彼此獨立。每個可用區域與其他可用區域之間的實體距離較大，從而可避免因火災、洪水和龍捲風等環境危害導致相關的失敗情境。每個可用區域也都具有獨立的實體基礎設施：可用區域內部和外部的公用電源專用連接、獨立的備用電源、獨立的機械服務以及獨立的網路連線。這種設計將這些系統中的故障限制為僅限於影響 AZ 的系統故障。儘管地理位置分開，但可用區域位於相同的區域，允許高輸送量、低延遲的聯網。整個 AWS 區域 （所有可用區域，包含多個實體獨立資料中心） 可以視為工作負載的單一邏輯部署目標，包括同步複寫資料 （例如，資料庫之間） 的能力。這允許您在主動/主動或主動/待命組態中使用可用區域。

可用區域是獨立的，因此當將工作負載架構為使用多個區域時，可提高工作負載的可用性。某些 AWS 服務 （包括 Amazon EC2執行個體資料平面） 會部署為嚴格區域服務，這些服務已與其所在的可用區域共用命運。AZs 不過，另一個 中的 Amazon EC2執行個體不會受到影響並繼續運作。同樣，如果可用區域中的故障導致 Amazon Aurora 資料庫失敗，則未受影響的可用區域中的僅供讀取複本 Aurora 執行個體可自動升級為主要執行個體。另一方面，區域 AWS 服務 (例如 Amazon DynamoDB) 則在主動/主動組態中在內部使用多個可用區域，以實現該服務的可用性設計目標，而無需設定可用區域放置。

圖 9：跨三個可用區域部署的多層架構。請注意，Amazon S3 和 Amazon DynamoDB 一律自動採用異地同步備份策略。ELB也會部署到所有三個區域。

雖然 AWS 控制平面通常提供管理整個區域 （多個可用區域） 內資源的能力，但某些控制平面 （包括 Amazon EC2和 Amazon EBS） 能夠將結果篩選到單一可用區域。完成此操作後，僅在指定的可用區域中處理該請求，從而減少其他可用區域中的中斷風險。此 AWS CLI 範例說明僅從 us-east-2c 可用區域取得 Amazon EC2執行個體資訊：

 AWS ec2 describe-instances --filters Name=availability-zone,Values=us-east-2c
  

AWS 本地區域

AWS 本機區域的作用類似於其各自 AWS 區域 中的可用區域，因為它們可以被選取為區域 AWS 資源的置放位置，例如子網路和EC2執行個體。讓他們特別之處在於，它們不在關聯的 中 AWS 區域，但接近目前 AWS 區域 不存在的大型人口、產業和 IT 中心。然而，它們仍可在本機區域的本機工作負載與在 AWS 區域中執行的本機工作負載之間保持高頻寬、安全的連線。您應該使用 AWS Local Zones，針對低延遲要求部署離使用者更近的工作負載。

Amazon Global Edge Network

Amazon Global Edge Network 包含全球各城市的邊緣節點。Amazon CloudFront 使用此網路以較低的延遲將內容交付給最終使用者。 AWS Global Accelerator 可讓您在這些邊緣位置建立工作負載端點，以為接近使用者 AWS 的全球網路提供入門。Amazon API Gateway 允許使用 CloudFront 分佈進行邊緣最佳化的API端點，以透過最接近的邊緣位置促進用戶端存取。

AWS 區域

AWS 區域 因此， 設計為自主，為了使用多區域方法，您將為每個區域部署專用的服務複本。

在發生一次性大規模事件時，災難復原策略通常採用多區域方法來實現復原目標。如需這些策略的詳細資訊，請參閱災難復原 (DR) 計畫。然而，在這裡，我們專注於可用性，這試圖隨著時間的推移實現平均執行時間目標。對於高可用性目標，多區域架構通常設計為主動/主動，其中每個服務副本 (在其各自的區域中) 都處於活動狀態 (服務請求)。

AWS 為您提供跨區域操作服務的功能。例如，使用 Amazon Simple Storage Service （Amazon S3） 複寫、Amazon RDS Read Replicas （包括 Aurora Read Replicas） 和 Amazon DynamoDB Global Tables AWS 提供連續、非同步的資料複寫。透過連續複寫，您的資料版本幾乎可以在每個活動區域中立即使用。

使用 AWS CloudFormation，您可以定義您的基礎設施，並在 AWS 帳戶 和 之間持續部署 AWS 區域。透過單一操作，您可以在多個帳戶和區域之間建立、更新或刪除 AWS CloudFormation 堆疊， AWS CloudFormation StackSets 並擴展此功能。對於 Amazon EC2執行個體部署， AMI（Amazon Machine Image） 用於提供硬體組態和已安裝軟體等資訊。您可以實作 Amazon EC2 Image Builder 管道，建立AMIs所需的 ，並將其複製到作用中區域。這可確保這些 Golden AMIs 擁有在每個新區域中部署和擴展工作負載所需的一切。

若要路由流量，Amazon Route 53 和 AWS Global Accelerator 都允許定義政策，以決定哪些使用者前往哪個作用中區域端點。使用 Global Accelerator，您可以設定流量調節盤，以控制導向至每個應用程式端點的流量百分比。Route 53 支援此百分比方法，以及多個其他可用政策，包括地理位置鄰近政策和基於延遲的政策。Global Accelerator 會自動利用廣泛的 AWS 邊緣伺服器網路，盡快將流量加入 AWS 網路骨幹，進而降低請求延遲。

所有這些能力的運作都是為了維護每個地區的自主權。此方法的例外極少，包括提供全域邊緣交付 （例如 Amazon CloudFront 和 Amazon Route 53） 的服務，以及 AWS Identity and Access Management （IAM） 服務的控制平面。大多數服務完全在單一區域內運行。

內部部署資料中心

對於在內部部署資料中心中執行的工作負載， 會盡可能建構混合式體驗。 AWS Direct Connect 提供來自您內部部署的專用網路連線， AWS 讓您同時在兩者中執行。

另一個選項是使用 執行內部部署的 AWS 基礎設施和服務 AWS Outposts。 AWS Outposts 是完全受管的服務，可將 AWS 基礎設施、 AWS 服務、 APIs和工具擴展到您的資料中心。中 AWS 雲端 所使用的相同硬體基礎設施會安裝在您的資料中心。 AWS Outposts 然後連接至最近的 AWS 區域。然後，您可以使用 AWS Outposts 來支援低延遲或本機資料處理需求的工作負載。

未建立此最佳實務時的曝險等級：高

實作指引

資源

相關文件：

相關影片：