DevOps知识中心
DevOps知识中心

处理和申请 AWS 服务限额提升的最佳实践

通过掌握 AWS 服务限额管理，防止应用程序限流并确保持续扩展。本指南详细介绍了使用 Service Quotas 控制台和 CloudWatch 告警主动监控软限额的最佳实践。了解提交高效提升请求的分步流程，重点是编写 AWS Support 所需的强大、数据驱动的理由，以加速审批并维护应用程序可用性。

32 浏览量

应对和请求提高 AWS 服务限制的最佳实践

AWS 服务限制（通常称为配额）是云环境中的关键组成部分。它们确保了运营效率，防止资源滥用，并保护用户免于意外产生巨额费用。然而，管理不善的限制可能导致应用程序限流、扩展失败和服务不可用。

本指南提供了专家策略，用于识别潜在的资源瓶颈，主动监控配额下的当前使用情况，并建立高效、简化的流程，以向 AWS Support 提交提高限制的请求。通过遵循这些最佳实践，工程团队可以保持高可用性，并支持持续增长，同时避免遇到意外障碍。

了解 AWS 服务配额

在发起任何请求之前，必须了解 AWS 限制的性质。这些限制通常根据资源（例如，EC2 实例的数量）、吞吐量（例如，IOPS）或每秒 API 请求数（RPS）进行分类。

软限制与硬限制

大多数配额分为以下两类之一：

  • 软限制（可调整配额）： 这是绝大多数的配额。它们是 AWS 为新账户设置的默认值，通常可以通过向 AWS Support 提交请求来提高，前提是有充分的业务理由。
  • 硬限制（不可调整配额）： 这些限制通常由物理基础设施约束、架构设计或安全要求决定。示例包括每个区域的最大 VPC 数量或特定资源的最大大小。硬限制通常无法提高。

提示： 始终首先检查 AWS Service Quotas 控制台。其中列出的限制通常是软限制，并且是提交请求的首选方式。

需要关注的常见限制

在高度可扩展的环境中，以下限制往往是最先达到，应密切监控：

  1. EC2 按需实例计数： 区域中所有 EC2 实例类型运行的 vCPU 总数。
  2. EBS 卷计数/大小： 对连接卷总数或累计大小的限制。
  3. VPC 资源： 对 VPC、Internet 网关、NAT 网关和弹性 IP (EIP) 数量的限制。
  4. API 限流限制： 针对 S3、DynamoDB 或 Lambda 调用速率等服务的每秒请求数 (RPS) 限制。

主动监控和预测

应对限流是昂贵且具有破坏性的。目标是主动预测限制突破，并确保其发生在影响生产之前。

1. 利用 Service Quotas 控制台

AWS Service Quotas 控制台是查看当前配额和跟踪许多服务利用率的唯一权威来源。它取代了跨各种服务控制台检查限制的需要。

可行步骤： 在 Service Quotas 控制台中定期审核对您的应用程序至关重要的服务（例如 Lambda、EC2、RDS）的配额。寻找利用率持续高于 50% 的服务。

2. 实施 CloudWatch 警报

对于关键限制，设置自动警报，以便在用量接近危险阈值时通知您的团队。

许多资源指标（例如 EC2 vCPU 使用量、Lambda 并发性）会发布到 CloudWatch。对于直接与 Service Quotas 集成的配额，您可以直接从 Quotas 控制台创建警报，通常将其设置为 80% 的利用率。

# 示例：为 Lambda 并发执行设置 80% 利用率警报
# (通常通过 Service Quotas 控制台集成或 CloudFormation 进行配置)

AlarmName: LambdaConcurrencyWarning
MetricName: ConcurrentExecutions
Namespace: AWS/Lambda
Statistic: Maximum
Period: 300
Threshold: [Current Limit * 0.80] 
ComparisonOperator: GreaterThanThreshold
EvaluationPeriods: 2
TreatMissingData: notBreaching

3. 预测和规划

使配额管理与开发里程碑和市场营销活动保持一致。如果计划进行重大的扩展活动或产品发布，请计算所需的最大容量，并至少提前两周提交提高限制的请求。

高效的服务限制提高请求流程

AWS 倾向于通过 Service Quotas 控制台提交提高限制的请求，因为这可以自动化路由并加快审批流程。

步骤 1：通过 Service Quotas 控制台提交（推荐）

  1. 导航到 AWS Service Quotas 控制台。
  2. 搜索特定服务（例如，'Amazon EC2'）。
  3. 单击相关配额（例如，'运行中的所有标准按需实例'）。
  4. 单击请求提高限制按钮。
  5. 指定所需的新限制和区域。
  6. 提供详细的理由（请参阅步骤 3）。

如果配额未在 Service Quotas 控制台中列出，则必须通过传统的 AWS Support Center，以“服务限制提高”的案例类型提交请求。

步骤 2：请求中应包含的关键信息

为避免与 AWS Support 之间来回沟通，请确保您的请求是全面的：

  • AWS 区域： 指定需要提高限制的确切区域（例如，us-east-1）。
  • 特定限制名称： 提供配额的精确名称（例如，运行中的 Fargate 任务数量）。
  • 当前限制： （可选，但有帮助）确认您正在达到的现有限制。
  • 请求的新限制： 说明您需要的确切最终数字（例如，从 100 增加到 500）。
  • 业务理由： 这是最关键的要素。

步骤 3：拟定强有力的业务理由

AWS 工程师需要具体的证据证明所请求的限制是必要、可持续且准确的。模糊的请求通常会被延迟或拒绝。

不要使用： “我们需要更多资源用于测试。”
应使用： “我们要求在 eu-west-1 区域增加 500 个 vCPU（总共 750 个），以适应计划于 2024 年第三季度推出的新应用。该应用使用 ECS Fargate，预计在高峰期每分钟处理 15,000 个请求，需要 100 个并发任务。我们根据详尽的负载测试结果计算了需求。”

理由组成部分 示例详情
使用案例 新应用发布、客户加入、季节性促销、数据库迁移。
计算依据 负载测试结果、预计流量增长 (RPS)、用户数量、并发要求。
时间线 何时需要该容量（例如，需要在 2024-11-01 前投入使用）。
持续时间 这是永久性增长还是暂时性高峰？

高级最佳实践和处理拒绝

避免限制的架构策略

有时，提高限制是正确的方法，但通常瓶颈表明架构效率低下。在请求极大提升之前，请考虑以下缓解技术：

  1. 实施指数退避和抖动 (Jitter)： 使用此模式重试失败的 API 调用（尤其适用于 S3 或 DynamoDB 限制），以防止服务过载并最大限度地减少限流影响。
  2. 优化批处理： 在支持的情况下（例如 DynamoDB BatchWriteItem），将多个单独的 API 调用整合为单个批处理操作。
  3. 利用缓存： 实施 ElastiCache 或 CloudFront 来减少到达后端服务的请求数量，从而降低触及 RPS 限制的可能性。

处理被拒绝的请求

如果 AWS 拒绝或大幅降低您请求的限制，通常意味着理由不充分，或者请求超出了安全参数。

拒绝后的行动计划：

  • 不要立即重新提交。 审查 AWS Support 提供的拒绝原因。
  • 完善理由： 提供更具体的数据点、内部指标和更清晰的计算方法。
  • 直接联系支持： 如果问题紧急或复杂，请回复支持案例，要求解释并提议安排通话来审查架构要求。

增加后的审查

限制提高后，请更新您的 CloudWatch 警报以反映新的 80% 阈值。仅仅获得提高限制并不是终点；持续监控可确保您将来不会意外触及新的限制。

总结

管理 AWS 服务限制是一项持续的运营任务，而非一次性设置。通过 Service Quotas 控制台和 CloudWatch 主动监控关键利用率指标，并为每个请求提供详细的、数据驱动的理由，工程团队可以确保无缝扩展能力。将提高服务限制的请求视为一项需要精确和远见的，而非官僚主义障碍的关键技术要求。