本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 可用區域
[https://aws.amazon.com/about-aws/global-infrastructure/regions_az/](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) (AZ) 是一或多個獨立資料中心，在AWS 區域. 可用區域的可用性、容錯能力和擴充能力，均較單一或多個資料中心的傳統基礎設施還高。
Amazon AppStream 2.0 只需要一個子網路即可在叢集中啟動。最佳做法是至少設定兩個可用區域，每個唯一可用區域一個子網路。若要最佳化叢集 auto 擴充，請使用兩個以上的可用區域。水平擴展具有在子網路中新增 IP 空間以促進成長的額外好處，本文件的下列子網路大小一節涵蓋。[https://aws.amazon.com/console/](https://aws.amazon.com/console/)僅提供在建立叢集期間指定的兩個子網路。使用 [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appstream/create-fleet.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appstream/create-fleet.html)(AWSCLI) 或允AWS CloudFormation許兩個以上的[https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-appstream-fleet-vpcconfig.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-appstream-fleet-vpcconfig.html)。
## 調整子網大小
將子網路專用於 AppStream 2.0 叢集，讓路由原則和網路存取控制清單具有彈性。堆疊可能會有不同的資源需求。例如， AppStream 2.0 堆棧可以具有隔離要求，以便分離規則集。當多個 Amazon AppStream 2.0 叢集使用相同的子網路時，請確保所有叢集的**最大容量**總和不超過可用 IP 地址的總數。
如果相同子網路中所有叢集的最大容量可能 (或已超過可用的 IP 位址總數)，請將叢集遷移至專用子網路。這可防止自動調整規模事件耗盡配置的 IP 空間。如果叢集的總容量超過指派子網路的配置 IP 空間，請使用 API 或 AWS CLI「*[更新叢集」來指派更](https://docs.aws.amazon.com/cli/latest/reference/appstream/update-fleet.html)*多子網路。如需詳細資訊，請參閱 [https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html)
最佳做法是擴展子網路的數量，相應地調整子網路大小，同時保留 VPC 中成長的容量。此外，請確保 AppStream 2.0 叢集上限不超過子網路配置的總 IP 空間。對於中的每個子網路AWS，在計算 [https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#vpc-sizing-ipv4](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#vpc-sizing-ipv4)個 IP 位址。使用兩個以上的子網路並水平擴展可提供數個好處，例如：
+ 可用區域故障提供更高的復原能力
+ 自動擴展叢集執行個體時，輸送量
+ 更有效地使用私有 IP 地址，避免 IP 燒錄
調整 Amazon AppStream 2.0 子網路的大小時，請考慮子網路的總數，以及尖峰使用率期間預期的峰值並行。這可以使用 (`InUseCapacity`) 加上叢集的預留容量 (`AvailableCapacity`) 進行監控。在 Amazon AppStream 2.0 中，已消耗執行個體和 available-to-be-consumed AppStream 2.0 叢集執行個體的總和都會加上標籤`ActualCapacity`。若要正確調整總 IP 空間的大小，請預測所需的`ActualCapacity`，然後除以子網路數目，減去一個指派給叢集的恢復子網路。
例如，如果預期尖峰時的叢集執行個體數目上限為 1000 個，而業務需求在一個可用區域故障中具有復原能力，則 3 個 x/23 子網路可滿足技術和業務需求。
+ /23 = 512 部主機 — 5 個保留 = 每個子網路 507 個叢集執行個體
+ 3 個子網路 — 1 個子網路 = 2 個子網路
+ 每個子網路 2 個子網路 x 507 個叢集執行個體 = 尖峰時有 1,014 個叢集執行個體
![\[顯示使用三個子網路與兩個子網路時減少容量的圖表。從 1,521 個叢集執行個體變更為 1,014 個叢集執行個體。\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/best-practices-for-deploying-amazon-appstream-2/images/subnet-sizing.png)
*子網路大小範例*
雖然 2 x /22 子網路也能滿足復原能力，但請考慮下列事項：
+ 而不是保留 1,536 個 IP 地址，而是使用兩個 AZ 會導致 2,048 個 IP 地址被保留，浪費可以使用其他功能的 IP 地址。
+ 如果一個 AZ 無法存取，向外擴充叢集執行個體的能力會受到 AZ 的輸送量的限制。這可以延長的持續時間`PendingCapacity`。
## 子網路由
最佳做法是為 AppStream 2.0 執行個體建立私有子網路，並透過集中式 VPC 路由至公用網際網路以取得輸出流量。 AppStream 2.0 工作階段串流的輸入流量是透過串流閘道透過 Amazon AppStream 2.0 服務處理：您不需要為此設定公有子網路。
## 區域內連接
對於加入至作用中目錄網域的 AppStream 2.0 叢集執行個體，請在每個AWS 區域共用服務 VPC 中設定作用中目錄網域控制站。活動目錄的來源可以是基於 [https://docs.aws.amazon.com/cli/latest/reference/appstream/create-fleet.html](https://docs.aws.amazon.com/cli/latest/reference/appstream/create-fleet.html) 的域控制器或 [https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html)。[https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html)雖然傳輸閘道可以解決大規模路由的複雜性，但在大多數設定中，VPC 對等互連的原因有很多：
+ VPC 對等互連是兩個 VPC 之間的直接連線 (無額外躍點)。
+ 無需每小時費用，只需支付可用區域之間的標準資料傳輸費率。
+ 頻寬沒有限制。
+ Support 存取 VPC 之間的安全群組。
如果 AppStream 2.0 執行個體連線到共用服務 VPC 中含有大型資料集的應用程式基礎結構和/或檔案伺服器，則尤其如此。透過最佳化這些通常存取資源的路徑，即使在透過傳輸閘道執行所有其他 VPC 和網際網路路由的設計中，VPC 對等連線也是最佳選擇。
## 出站互聯網流量
雖然直接路由至共用服務大部分是透過對等連線最佳化的，但 AppStream 2.0 的輸出流量可以透過[https://aws.amazon.com/blogs/networking-and-content-delivery/creating-a-single-internet-exit-point-from-multiple-vpcs-using-aws-transit-gateway/](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-a-single-internet-exit-point-from-multiple-vpcs-using-aws-transit-gateway/)設計。在多虛擬私人雲端設計中，擁有可控制所有傳出網際網路流量的專用 VPC 是一項標準作法。透過此組態，Transit Gateway 具有更大的彈性，並可控制附加至子網路的標準路由表格上的路由。此設計也支援傳遞路由，不需要額外的複雜性，並且不需要在每個 VPC 中使用冗餘網路位址轉譯 (NAT) 閘道或 NAT 執行個體。
將所有輸出網際網路流量集中到單一 VPC 後，NAT 閘道或 NAT 執行個體就是常見的設計選擇。若要判斷哪一種最適合您的組織，請檢視[https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-comparison.html](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-comparison.html)的管理指南。 [https://aws.amazon.com/network-firewall/](https://aws.amazon.com/network-firewall/) 可以透過在路由層級進行保護，並在 [https://en.wikipedia.org/wiki/OSI_model](https://en.wikipedia.org/wiki/OSI_model) 模型中提供第 3 層到第 7 層的無狀態和可設定狀態規則，從而將保護範圍擴展到安全群組和網路存取控制層級之外。如需詳細資訊，請參閱 [https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/)。如果您的組織選擇了執行進階功能 (例如 URL 篩選) 的協力廠商產品，請將服務部署到輸出網際網路 VPC 中。這可以取代 NAT 閘道或 NAT 執行個體。請遵循第三方廠商提供的準則。
## 現場部署
當需要與內部部署資源的連線時，特別是對於加入 Active Directory 的 AppStream 2.0 執行個體，請[https://aws.amazon.com/directconnect/resiliency-recommendation/](https://aws.amazon.com/directconnect/resiliency-recommendation/)。