View a markdown version of this page

可用區域 - 部署 Amazon WorkSpaces 應用程式的最佳實務
調整子網大小子網路由區域間連線傳出網際網路流量現場部署

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

可用區域

可用區域 (AZ) 是一個或多個離散的資料中心，在 中具有備援電源、聯網和連線能力 AWS 區域。可用區域的可用性、容錯能力和擴展能力，均較單一或多個資料中心的傳統基礎設施還高。

Amazon WorkSpaces 應用程式只需要一個子網路，機群才能啟動。最佳實務是設定至少兩個可用區域，每個唯一的可用區域一個子網路。若要最佳化機群自動擴展，請使用兩個以上的可用區域。水平擴展具有在子網路中新增 IP 空間以進行增長的額外優勢，如本文件的下列子網路大小一節所述。AWS 管理主控台只會在建立機群期間指定兩個子網路。使用 AWS Command Line Interface(AWS CLI) 或 AWS CloudFormation 允許兩個以上的子網路 IDs。

調整子網大小

專用於 WorkSpaces 應用程式機群的子網路，以允許路由政策和網路存取控制清單的彈性。Stacks 可能有個別的資源需求。例如，WorkSpaces Applications Stacks 可以有隔離需求來提供分隔規則集的方法。當多個 Amazon WorkSpaces 應用程式機群使用相同的子網路時，請確保所有機群的最大容量總和不超過可用的 IP 地址總數。

如果相同子網路中所有機群的最大容量可能或已超過可用的 IP 地址總數，請將機群遷移至專用子網路。這可防止自動擴展事件耗盡配置的 IP 空間。如果機群的總容量超過指派子網路的配置 IP 空間，請使用 API 或 AWS CLI「更新機群」來指派更多子網路。如需詳細資訊，請參閱 Amazon VPC 配額，以及如何增加配額。

最佳實務是擴展子網路數量，相應地調整子網路大小，同時保留在 VPC 中增長的容量。此外，請確保 WorkSpaces 應用程式機群上限不超過子網路配置的總 IP 空間。對於 中的每個子網路 AWS，在計算 IP 空間總量時，會保留五個 IP 地址。使用兩個以上的子網路並水平擴展可提供數種優點，例如：

  • 因可用區域故障而提高彈性

  • 自動擴展機群執行個體時的輸送量更高

  • 更有效率地使用私有 IP 地址，避免 IP 燒毀

調整 Amazon WorkSpaces 應用程式的子網路大小時，請考慮子網路總數，以及尖峰使用率期間的預期尖峰並行。這可以使用 (InUseCapacity) 加上機群的預留容量 (AvailableCapacity) 進行監控。在 Amazon WorkSpaces 應用程式中，耗用和available-to-be-consumed WorkSpaces 應用程式機群執行個體的總和會標記為 ActualCapacity。若要正確調整總 IP 空間的大小，請預測所需的 ActualCapacity，然後除以指派給機群的子網路數量，減去一個子網路的彈性。

例如，如果尖峰時的預期機群執行個體數量上限為 1000，且業務需求是在一個可用區域故障時具有彈性，則 3 x/23 子網路可滿足技術和業務需求。

  • /23 = 512 個主機 — 5 個預留 = 每個子網路 507 個機群執行個體

  • 3 個子網路 — 1 個子網路 = 2 個子網路

  • 2 個子網路 x 每個子網路 507 個機群執行個體 = 尖峰 1，014 個機群執行個體

顯示使用三個子網路與兩個子網路時容量減少的圖表。從 1，521 個機群執行個體變更為 1，014 個機群執行個體。

子網路大小範例

雖然 2 x /22 子網路也可以滿足彈性，但請考慮下列事項：

  • 而不是保留 1，536 個 IP 地址，使用兩個 AZs 會導致保留 2，048 個 IP 地址，浪費可能前往其他 函數的 IP 地址。

  • 如果無法存取一個 AZ，擴展機群執行個體的能力會受到 AZ 輸送量的限制。這可以延長 的持續時間PendingCapacity。

子網路由

最佳實務是為 WorkSpaces 應用程式執行個體建立私有子網路，並透過集中式 VPC 路由至公有網際網路以進行傳出流量。WorkSpaces 應用程式工作階段串流的傳入流量會透過 Amazon WorkSpaces 應用程式服務透過串流閘道處理：您不需要為此設定公有子網路。

區域間連線

對於加入 Active Directory 網域的 WorkSpaces 應用程式機群執行個體，請在每個執行個體的共用服務 VPC 中設定 Active Directory 網域控制器 AWS 區域。Active Directory 的來源可以是 Amazon EC2 型網域控制器或 AWS Microsoft Managed AD。共用服務和 WorkSpaces 應用程式 VPCs之間的路由可以透過 VPC 互連連線或傳輸閘道進行。雖然傳輸閘道可解決大規模路由的複雜性，但有許多原因使得 VPC 對等互連在大多數設定中較適合：

  • VPC 對等互連是兩個 VPCs之間的直接連線 （沒有額外的跳轉）。

  • 不收取每小時費用，僅收取可用區域之間的標準資料傳輸率。

  • 頻寬沒有限制。

  • 支援在 VPCs之間存取安全群組。

如果 WorkSpaces 應用程式執行個體連線到共用服務 VPC 中具有大型資料集的應用程式基礎設施和/或檔案伺服器，則尤其如此。透過最佳化這些常用資源的路徑，即使在透過傳輸閘道執行所有其他 VPC 和網際網路路由的設計中，還是偏好 VPC 互連連線。

傳出網際網路流量

雖然直接路由至共用服務主要是透過對等連線進行最佳化，但 WorkSpaces 應用程式的傳出流量可以透過使用 AWS Transit Gateway 從多個 VPCs建立單一網際網路結束點來設計。在多 VPC 設計中，標準實務是擁有控制所有傳出網際網路流量的專用 VPC。使用此組態，傳輸閘道具有更大的彈性，並控制連接至子網路之標準路由表的路由。此設計也支援無額外複雜性的傳輸路由，並不需要在每個 VPC 中使用備援網路位址轉譯 (NAT) 閘道或 NAT 執行個體。

一旦將所有傳出網際網路流量集中到單一 VPC 中，NAT 閘道或 NAT 執行個體是常見的設計選擇。若要判斷哪個最適合您的組織，請檢視管理指南來比較 NAT 閘道和 NAT 執行個體。AWS Network Firewall 可以在路由層級保護 ，並在 OSI 模型中提供從第 3 層到第 7 層的無狀態和有狀態規則，藉此將保護延伸到安全群組和網路存取控制層級之外。如需詳細資訊，請參閱 AWS Network Firewall 的部署模型。如果您的組織已選擇執行 URL 篩選等進階功能的第三方產品，請將服務部署到您的傳出網際網路 VPC。這可以取代 NAT 閘道或 NAT 執行個體。遵循第三方供應商提供的準則。

現場部署

當需要連線到內部部署資源時，特別是加入 Active Directory 的 WorkSpaces 應用程式執行個體，請透過 建立高彈性的連線 AWS Direct Connect。