4. KMS请求速率与限制：了解默认配额、突发与节流机制
说到KMS的性能，我最常被问的就是：“为什么我的应用突然被限速了？” 说白了，KMS不是无底洞，它有明确的请求速率限制。如果不摸清这些限制，你的业务流量一来，可能直接就卡住了。
我记得刚接手一个高并发项目时，上线第一天KMS接口就报503。查了半天，原来是默认配额没调。从那以后，我每次做架构设计都会先问一句：KMS的配额是多少？
4.1 默认配额：AWS KMS的硬性天花板
每个AWS区域，每个AWS账户，KMS服务都有默认的请求速率配额。不同类型操作配额不同。加密、解密、生成数据密钥这些基础操作各有各的配额。
| 操作 | 默认配额（每秒请求数） | 备注 |
|---|---|---|
| Encrypt / Decrypt | 5,500（每个区域） | 共享配额，非针对单个CMK |
| GenerateDataKey | 5,500 | 不含明文密钥的版本 |
| GenerateDataKeyWithoutPlaintext | 5,500 | 同上 |
| ReEncrypt | 5,500 | 基于源和目标CMK分别计算 |
| 其他API（如CreateKey、ListKeys） | 较低（如50 QPS） | 管理类操作 |
这个表看着简单，但有个坑：这些配额是针对整个区域所有CMK的总和。你一个应用用10个CMK，每个CMK每秒只能分到几百次请求。如果你有一个热点CMK，其他CMK再一挤，它很容易撞墙。
4.2 突发机制：KMS如何应对短时峰值
你想想看，所有系统都要应对流量尖峰。KMS也不傻，它内置了突发能力。具体来说，KMS使用令牌桶算法，允许短时间内的请求速率超过稳态配额。桶的大小决定了你能突发的程度。
以Decrypt为例：默认配额5500 QPS，但突发桶可能允许你在一秒钟内发8000个请求，只要后续几秒内不再超。我遇到过某次电商秒杀活动，后端突然调用大量解密请求，峰值达到7000 QPS，持续了大概3秒，没有触发节流。这就是突发机制在起作用。
那么突发桶到底多大？AWS官方没有公布具体数字，但根据实测和文档片段，我的推测是：突发桶容量 ≈ 稳态配额 × 5秒。也就是你可以瞬间发出5倍速率的请求，但持续超过1秒就可能被节流。但注意，这因区域和账户历史行为而异。
4.3 节流机制：当你的请求被拒绝时
当你的请求速率超过配额+突发桶后，KMS会返回 ThrottlingException（HTTP 400）或 LimitExceededException。这时你的应用必须处理这个错误，然后重试。
节流不是一刀切。KMS的节流策略有几个特点：
- 按操作独立节流。 加密节流不影响解密配额，管理API和加密API互不影响。
- 按区域独立节流。 你在us-east-1被节流，us-west-2不受影响。
- 节流有冷却期。 一旦触发节流，后续请求会被快速拒绝，直到令牌桶重新累积。
- SDK自动重试。 AWS SDK内置了指数退避重试，默认最多3次。但我建议自己再加一层业务重试。
这里有一个我自己踩过的坑：用Lambda调用KMS解密，Lambda并发太高，瞬间打爆KMS配额。Lambda自动重试3次，但重试间隔很短（几十毫秒），结果所有重试又同时打上来，直接把KMS干成雪崩。后来我加了队列削峰，每次最多100个并发请求。
4.4 配额提升：如何申请更高限制
如果你的业务确实需要更高的KMS吞吐，可以申请提升配额。AWS支持中心提交工单，说明需要的QPS和理由。但需要注意：
- 提升配额不是立即可用的，通常需要1-2天审核。
- 提升对象是整个区域的配额，不是单个CMK。
- 提升后可能需要重启客户端或刷新SDK缓存。
我建议在项目上线前至少2周就评估好KMS配额，提前申请。因为一旦线上出问题再申请，时间会很紧张。
4.5 监控与告警：别等到被节流才发现
KMS的CloudWatch指标里有一个关键指标：ThrottledRequests。你必须在CloudWatch里为这个指标设置告警。另外，SuccessfulRequests 除以时间可以得到实际QPS，与配额对比能看出余量。
我习惯的做法：
- 在CloudWatch控制台创建ThrottledRequests告警，阈值设为0，连续1个周期就触发。
- 创建每月配额使用率仪表盘，显示每个操作的QPS与配额比例。
- 在应用层记录每次KMS调用延迟，如果延迟突然飙升（比如从10ms变成500ms），很可能是在重试了。
核心原则： 不要让应用直接依赖KMS进行高频数据加密。尽可能使用数据密钥缓存（Data Key Caching），让每次KMS调用产生一个本地缓存的CEK，后续加解密全部在内存中完成。这样可将KMS调用量降低几个数量级。
4.6 整体逻辑：一张图看懂请求速率与节流
4.7 实战指南：如何优雅地避免节流
讲了一大堆理论，最后给你几个实打实的做法：
- 缓存数据密钥。 这是最有效的。用KMS生成一次数据密钥，然后在内存中缓存几百秒，后续加解密直接用缓存的密钥。调用量直接从每秒几百次降到每分钟几次。
- 使用多区域CMK。 如果你的应用部署在多个区域，每个区域用不同的CMK。这样配额是独立计算的，总吞吐量线性增加。缺点是对跨区域访问有延迟成本。
- 实施客户端限速。 在应用层用令牌桶或漏桶算法，限制每秒发往KMS的请求数。比如设定上限为配额的70%。我给一个金融客户做过，用了Guava的RateLimiter，效果很好。
- 合理配置SDK重试。 AWS SDK默认重试3次，退避间隔从50ms开始指数增长。如果你的应用对延迟不敏感，可以把最大重试次数增加到5次，退避系数加大，减少瞬间重试压力。
- 开启CloudTrail日志分析。 通过CloudTrail可以还原每次请求的耗时和错误码。我用它定位过好几次因为KMS节流导致S3加密失败的案例。
总结一下，KMS的速率限制不像数据库连接池那样直观。它既有默认配额，又有突发能力，还有节流返回。你不需要记住所有数字，但一定要记住：把KMS当作密钥生成中心，而不是加解密主力。把高频操作转到本地缓存，你基本就不会碰到节流问题了。