AWS Lambda临时密钥存储与SSM调用限流问题解决方案咨询

云原生阿岚

2026-5-11

刚好遇到过类似的场景，给你梳理几个实用的解决方案，分三个部分来说：

解决SSM限流问题的直接方案

针对你遇到的ThrottlingException，可以从几个层面直接缓解：

调整Lambda与SQS的触发配置：SQS触发器会根据队列消息数自动调整Lambda并发数，如果批量处理的消息太多，会导致大量Lambda实例同时调用SSM。你可以尝试降低SQS的BatchSize（比如从默认的10改成2-5），或者给Lambda设置ReservedConcurrentExecutions，限制同时运行的实例数，减少SSM的请求峰值。
升级SSM参数到高级存储：SSM标准参数的默认API限额是4000次/秒，而高级参数可以达到10000次/秒，还能提交支持工单进一步提额。如果你的参数是敏感信息，高级存储还提供更严格的加密和访问控制。
Lambda内部本地缓存参数：利用Lambda执行环境复用的特性，把SSM参数缓存到全局变量里，不用每次处理消息都调用SSM。比如根据你获取的密钥过期时间来判断缓存是否有效，只有过期后才重新拉取：

import boto3
from datetime import datetime

# 全局缓存变量，会在执行环境复用期间保留
cached_api_key = None
cached_expiry = None
ssm = boto3.client('ssm')

def handler(event, context):
    global cached_api_key, cached_expiry
    
    # 检查缓存是否失效
    if not cached_api_key or datetime.now() >= cached_expiry:
        # 批量获取两个参数，减少API调用次数
        resp = ssm.get_parameters(
            Names=['/your/expiry-time', '/your/api-key'],
            WithDecryption=True
        )
        # 解析参数值
        for param in resp['Parameters']:
            if param['Name'] == '/your/expiry-time':
                cached_expiry = datetime.fromisoformat(param['Value'])
            else:
                cached_api_key = param['Value']
    
    # 用缓存的密钥处理消息
    for record in event['Records']:
        send_to_external_source(record, cached_api_key)

优化重试策略：修改boto3的重试配置，用自适应模式替代固定重试，避免短时间内重复请求加剧限流：

from botocore.config import Config

ssm_config = Config(
    retries={
        'max_attempts': 5,
        'mode': 'adaptive'
    }
)
ssm = boto3.client('ssm', config=ssm_config)

替代AWS SSM的服务/方式

如果SSM的限额始终满足不了你的并发需求，可以考虑这些替代方案：

AWS Secrets Manager：专门为敏感信息设计，默认API限额5000次/秒，还支持自动密钥轮换、Lambda缓存扩展（可以在执行环境中缓存密钥，减少API调用）。对于需要频繁更新的认证密钥，它比SSM更适合，而且集成Lambda的体验更好。
Amazon DynamoDB：自己搭建一个存储表来存密钥和过期时间，DynamoDB的读写吞吐量可以按需调整，还能开启TTL自动过期旧密钥。配合DynamoDB Accelerator（DAX）可以进一步提升读取性能，适合高并发场景。
Lambda环境变量+层：如果密钥更新频率很低（比如几个月一次），可以把密钥存为Lambda环境变量，或者打包到Lambda层里。但要注意，环境变量更新需要重新部署Lambda，而且虽然AWS会加密，但有权限的用户可以查看，适合非超敏感且低更新频率的场景。

Lambda之间缓存数据的方法

Lambda之间共享缓存主要有这些方式：

执行环境复用缓存：就是上面提到的全局变量缓存，免费且简单，但缓存有效期依赖AWS的执行环境回收策略（一般几分钟到几小时），适合短期、非关键的缓存。
Amazon ElastiCache：用Redis或Memcached搭建分布式缓存，多个Lambda实例可以共享缓存数据，缓存有效期完全可控，性能极高。适合需要跨函数、高并发的缓存场景，但需要额外的运维和成本。
Lambda缓存扩展：比如AWS官方的Secrets Manager扩展，或者第三方的Redis扩展，这些扩展会在Lambda执行环境中运行，提供持久化的本地缓存，甚至可以和分布式缓存联动，减少第三方服务的调用次数。
DynamoDB作为缓存层：和上面提到的替代方案类似，用DynamoDB存储缓存数据，加上TTL自动过期，多个Lambda可以通过读写DynamoDB共享缓存，适合需要持久化、可扩展的缓存场景。

内容的提问来源于stack exchange，提问作者prosto.vint