AWS 服务配额为何存在 - 保护共享基础设施的多租户设计
解析 AWS 服务配额（原服务限制）不仅是简单的约束，而是在多租户环境中保护其他客户的设计，从嘈杂邻居问题、软限制与硬限制的区别、配额提升申请的内部机制进行说明。
服务配额的本质 - 保护其他客户的机制
AWS 服务配额（原称：服务限制）是每个账户可使用资源的上限。EC2 实例启动数、Lambda 并发执行数、S3 存储桶数、VPC 数等几乎所有资源都设有配额。这些配额的存在并非为了给用户带来不便。AWS 的基础设施是多租户的。物理服务器、网络、存储在多个客户之间共享。如果某个客户突然消耗大量资源，可能影响同一物理基础设施上的其他客户。这就是「嘈杂邻居」问题。服务配额通过限制每个账户的资源消耗上限，防止单一客户独占共享基础设施，保护所有客户的服务质量。
软限制与硬限制
配额分为两种类型。软限制（可调整配额）可通过 Service Quotas 控制台或向 AWS Support 申请来提升。EC2 按需实例的 vCPU 数（默认值因区域和实例系列而异）、Lambda 并发执行数（默认：1,000）、S3 存储桶数（默认：100）等属于软限制。硬限制（不可调整配额）无论如何都无法超越。例如，单个 AWS 账户的区域数上限、IAM 策略的最大大小（6,144 字节）、CloudFormation 堆栈的最大资源数（500）等。硬限制的存在是因为超越这些限制会影响服务本身的架构或其他客户的稳定性。
配额提升申请的内部机制
从 Service Quotas 控制台提交提升申请后会发生什么？部分配额会自动批准。S3 存储桶数的提升（100→1,000）等在申请后几分钟内自动批准。这些配额因为提升后对其他客户影响较小而实现了自动化。另一方面，EC2 vCPU 配额的大幅提升（如 1,000→10,000）需要 AWS 内部团队的审核。审核时会确认该区域是否有足够的物理容量、该账户的使用历史和支付记录、以及提升后对同一物理基础设施上其他客户的影响。审核通常在 24-48 小时内完成，但大幅提升可能需要更长时间。
默认配额为何设置得较低
新账户的默认配额被有意设置得较低。EC2 按需 vCPU 在新账户中每个实例系列约为 5-32 vCPU。这种较低的默认值有三个原因。第一，防止滥用。用被盗信用卡创建的账户大量启动 EC2 实例挖掘加密货币的滥用行为是 AWS 面临的持续课题。低默认配额限制了滥用的规模。第二，保护客户免受意外高额账单。配置错误导致的大量资源启动，在低配额下损失有限。第三，容量规划。如果所有新账户都能立即使用大量资源，AWS 的容量规划将变得极其困难。通过逐步提升配额，AWS 可以预测需求增长并提前准备容量。
配额的监控与自动化
Service Quotas 与 CloudWatch 集成，可以将配额使用率作为指标获取。例如，可以设置当 EC2 vCPU 配额使用率超过 80% 时触发 CloudWatch 告警并通过 SNS 通知。等到达到配额时已经太晚，因此提前监控并留有余量地提交提升申请非常重要。Trusted Advisor 也提供配额监控功能，在接近限制时发出警告。通过 AWS Config 规则可以持续监控配额使用率，在超过阈值时自动触发提升申请的工作流。Organizations 环境中，可以使用 Service Quotas 的组织级模板为所有成员账户统一设置配额，避免逐个账户手动申请的麻烦。 如需深入了解 AWS 的多租户设计和运维最佳实践，相关书籍 (Amazon) 也可供参考。