区域服务

可用区独立 (AZI) AWS 允许提供区域服务，例如 Amazon EC2 和 Amazon EBS。区域服务是一种能够指定资源部署到哪个可用区的服务。这些服务在一个区域内的每个可用区中独立运行，更重要的是，这些服务在每个可用区中也独立失效。这意味着一个可用区中的服务组件不依赖于其他可用区中的组件。我们可以这样做，因为区域服务具有区域数据平面。在某些情况下，例如在 EC2 中，该服务还包括用于区域对齐操作的区域控制平面，例如启动 EC2 实例。对于这些服务， AWS 还提供了区域控制平面终端节点，便于与服务进行交互。区域控制平面还提供区域范围的功能，并充当区域控制平面之上的聚合和路由层。如下图所示。

具有区域隔离控制平面和数据平面的分区服务

与单个数据中心相比，可用性区域使客户能够操作更高的可用性、容错性和可扩展性。当一个工作负载使用多个可用区时，可以更好地隔离和保护客户，使其免受影响单个可用区物理基础设施的问题。这可以帮助客户构建跨可用区域的冗余服务，如果架构正确，即使一个可用区出现故障，也能保持正常运行。客户可以利用 AZI 来创建高度可用且具有弹性的工作负载。在您的架构中实施 AZI 可以帮助您快速从孤立的可用区故障中恢复，因为您在一个可用区中的资源可以最大限度地减少或消除与其他可用区域中资源的交互。这有助于消除跨可用区的依赖关系，从而简化可用区的撤离。有关创建可用区疏散机制的更多详细信息，请参阅高级多可用区弹性模式。此外，您可以通过遵循一些与其自身服务相同的最佳实践 AWS 来进一步利用可用区，例如一次只能将更改部署到单个可用区，或者在可用区的更改失败时将该可用区从服务中删除。

静态稳定性也是多可用区架构的重要概念。对于多可用区架构，您应规划的故障模式之一是可用区的丢失，这可能会导致可用区的容量丢失。如果您没有预先配置足够的容量来应对可用区的丢失，则可能会导致您的剩余容量被当前负载所淹没。此外，你还需要依靠区域服务的控制平面来替换丢失的容量，这可能不如静态稳定的设计那么可靠。在这种情况下，预先配置足够的额外容量可以帮助您保持静态稳定，以防故障域（例如可用区）丢失，因为无需进行动态更改即可继续正常运行。

您可以根据工作负载的需求，选择使用部署在多个可用区的 EC2 实例的 auto scaling 组来动态扩展和缩小。对于在几分钟到几十分钟内逐渐发生的使用量变化，自动缩放效果很好。但是，启动新的 EC2 实例需要时间，尤其是在您的实例需要引导（例如安装代理、应用程序二进制文件或配置文件）的情况下。在此期间，您的剩余容量可能会被当前负载所淹没。此外，通过 auto Scaling 部署新实例依赖于 EC2 控制平面。这需要权衡取舍：为了保持静态稳定性，以应对单个可用区的损失，您需要在其他可用区中预配置足够的 EC2 实例来处理已从受损可用区转移的负载，而不是依赖 auto scaling 来配置新实例。但是，预先配置额外容量可能会产生额外费用。

例如，在正常操作期间，假设您的工作负载需要六个实例来为三个可用区的客户流量提供服务。为了在单个可用区出现故障时保持静态稳定，您将在每个可用区部署三个实例，总共部署九个实例。如果单个可用区域的实例出现故障，则还剩下六个实例，并且无需在故障期间预置和配置新实例即可继续为客户流量提供服务。实现 EC2 容量的静态稳定性需要额外的成本，因为在本例中，您运行的实例数量增加了 50%。并非所有可以预配置资源的服务都会产生额外费用，例如预配置 S3 存储桶或用户。您需要权衡实现静态稳定性与超出工作负载所需恢复时间的风险。

AWS Local Zones 和 Outposts 使特定 AWS 服务的数据平面更接近最终用户。这些服务的控制平面位于父区域。在您创建本地区域或 Outposts 子网的可用区上，您的本地区域或 Outposts 实例将依赖于区域服务（如 EC2 和 EBS）。它们还将依赖区域控制平面来提供区域服务，例如弹性负载平衡 (ELB)、安全组和亚马逊弹性 Kubernetes Ser vice (Amazon EKS) 托管的 Kubernetes 控制平面（如果你使用 EKS）。有关 Outposts 的更多信息，请参阅文档以及支持和维护常见问题解答。使用 Local Zones 或 Outposts 时实现静态稳定性，以帮助提高弹性，以控制飞机损伤或与父区域的网络连接中断。