REL01-BP02 跨多个账户和区域管理服务限额 - AWS Well-Architected Framework

REL01-BP02 跨多个账户和区域管理服务限额

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

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

常见反模式:

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

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

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

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

  • 不利用限额请求模板来请求提高多个区域和账户的限额。

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

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

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

实施指导

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

由于实施的设计采用主动/主动主动/被动 – 常用主动/被动 – 非常用主动/被动 – 指示灯方法,会有更多工作负载跨越区域,因此了解所有区域和账户限额水平至关重要。如果服务限额设置正确,过去的流量模式并不总是一个好的指标。

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

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

服务限额偏移对于跟踪和评估非常重要,它是指特定命名限额在一个区域而非所有区域发生更改的情况。应考虑更改在有流量或可能有流量的区域的限额。

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

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

实施步骤

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

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

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

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

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

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

资源

相关最佳实践:

相关文档:

相关视频:

相关服务: