REL01-BP02 跨账户和地区管理服务配额 - AWS Well-Architected 框架

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

REL01-BP02 跨账户和地区管理服务配额

如果您目前使用多个账户或区域,请确保在运行生产工作负载的所有环境中都请求适当的配额。

期望结果:对于跨账户或区域的配置,或者具有使用区域或账户失效转移的韧性设计的配置,服务和应用程序不应受到服务配额耗尽的影响。

常见反模式:

  • 允许一个隔离区域内的资源利用率增加,但没有相关机制保持其他隔离区域中的容量。

  • 手动单独设置隔离区域中的所有配额。

  • 没有考虑到在非主要区域出现性能下降期间,韧性架构(如主动或被动)对未来配额需求的影响。

  • 没有定期评估配额,并且不在工作负载运行的每个区域和账户中进行必要更改。

  • 不利用配额请求模板在多个地区和账户中请求提高配额。

  • 不更新服务配额,因为错误地认为提高配额会像计算预留请求一样产生成本影响。

建立此最佳实践的好处:验证是否可以在区域服务不可用的情况下处理辅助区域或账户中的当前负载。这可以帮助降低在区域丢失期间发生的错误数量或性能下降水平。

在未建立这种最佳实践的情况下暴露的风险等级:

实施指导

每个账户的服务配额都可被跟踪。除非另有说明,否则每个配额都是 AWS 区域特定的。除生产环境以外,还要管理所有适用的非生产环境中的配额,避免妨碍测试与开发。保持高度韧性需要持续评测服务配额(无论是自动还是手动)。

由于使用主动/主动主动/被动 – 热主动/被动 – 冷以及主动/被动 – 指示灯方法实施设计,跨区域的工作负载越来越多,因此了解所有区域和账户配额级别至关重要。如果服务配额设置正确,过去的流量模式并不总是一个好的指标。

同样重要的是,服务配额名称限制并非对每个区域都始终相同。在一个区域,该值可能是 5,而在另一个区域,该值可能是 10。必须跨越所有相同的服务、账户和区域来管理这些配额,以便在负载状态下提供一致的韧性。

协调不同区域(主动区域或被动区域)之间的所有服务配额差异,并创建流程来持续协调这些差异。被动区域失效转移的测试计划很少扩展到能够满足峰值主动容量,这意味着 GameDay 演练或桌面演练可能无法发现区域之间的服务配额差异,因此也无法保持正确的限制。

服务配额偏差,即某一特定命名配额的服务配额限制在一个区域发生变更但未在所有区域发生变更的情况,这对于跟踪和评测非常重要。应考虑更改在有流量或可能有流量的区域的配额。

  • 根据您的服务要求、延迟、法规和灾难恢复(DR)要求选择相关账户和区域。

  • 确定跨所有相关账户、区域和可用区的服务配额。限制的范围具体到账户和区域。应对这些值进行比较,了解差异情况。

实施步骤

  • 审查可能已经超出风险使用水平的服务配额值。 AWS Trusted Advisor 会在超出 80% 和 90% 阈值时提供警报。

  • 审查任何被动区域(在主动/被动设计中)的服务配额值。验证在主区域发生故障时,负载能否在辅助区域成功运行。

  • 自动评测同一账户的不同区域之间是否发生了任何服务配额偏移,并采取相应的行动来更改限制。

  • 如果客户的组织单位(OU)以受支持的方式构建,则应更新服务配额模板,反映应该应用于多个区域和账户的任何配额的变化。

    • 创建模板并将区域与配额变化关联起来。

    • 审查所有现有的服务配额模板,看看是否需要进行任何更改(区域、限制和账户)。

资源

相关最佳实践:

相关文档:

相关视频:

相关服务: