本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 可用区
[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 只需要一个子网即可启动实例集。最好是至少配置两个可用区，每个唯一可用区一个子网。要优化实例集自动扩缩，请使用两个以上的可用区。横向扩展的另一个好处是可以增加子网中的 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) (AWS CLI) 或 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 空间总量。在计算 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 地址流失
在调整 Amazon AppStream 2.0 的子网规模时，请考虑子网的总数以及利用率峰值期间的预计峰值并发量。可以使用 (`InUseCapacity`) 加上实例集的预留容量 (`AvailableCapacity`) 进行监控。在 Amazon AppStream 2.0 中，已使用和可使用的 AppStream 2.0 实例集实例的总和标记为 `ActualCapacity`。要正确调整总 IP 空间的大小，请预测所需的 `ActualCapacity`，然后除以分配给实例集的子网数量，减去一个子网以满足恢复需要。
例如，如果预计峰值时实例集实例的最大数量为 1000，并且业务要求是在一次可用区故障中保持恢复能力，则 3 个 x/23 子网可以满足技术和业务需求。
+ /23 = 512 台主机 — 5 个预留 = 每个子网 507 个实例集实例
+ 3 个子网 — 1 个子网 = 2 个子网
+ 2 个子网 x 每个子网 507 个实例集实例 = 峰值时为 1014 个实例集实例
![\[该图显示了使用三个子网与使用两个子网相比时减少的容量。总数从 1521 个实例集实例变为 1014 个实例集实例。\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/best-practices-for-deploying-amazon-appstream-2/images/subnet-sizing.png)
*子网大小调整示例*
虽然 2 个 /22 子网也能满足恢复的需求，但请考虑以下几点：
+ 使用两个可用区保留的不是 1536 个 IP 地址，而是保留了 2048 个 IP 地址，从而浪费了本来可以用于其他功能的 IP 地址。
+ 如果有一个可用区无法访问，则扩展实例集实例的能力将受到可用区吞吐量的限制。这可能延长 `PendingCapacity` 的持续时间。
## 子网路由
最佳实践是为 AppStream 2.0 实例创建私有子网，通过集中式 VPC 将出站流量路由到公共互联网。可通过 Amazon AppStream 2.0 服务凭借流式传输网关处理 AppStream 2.0 会话流式传输的入站流量：您无需为此配置公有子网。
## 区域内连接
对于加入 Active Directory 域的 AppStream 2.0 实例集实例，请在每个 AWS 区域 的共享服务 VPC 中配置 Active Directory 域控制器。Active Directory 的来源可以是基于 [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)。共享服务与 AppStream 2.0 VPC 之间的路由可以通过 [https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-basics.html](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-basics.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 之间的直接连接（无需额外跳跃）。
+ 不收取每小时费用，仅按可用区之间的标准数据传输费率收费。
+ 对带宽没有限制。
+ 支持在 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 设计中，标准做法是使用专用 VPC 来控制所有传出的互联网流量。通过这种配置，中转网关可以更灵活地控制通过连接到子网的标准路由表进行路由。该设计还支持传递路由，而不会增加复杂性，并且无需在每个 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/)。