传统动态重写的瓶颈
配置前的检查
动态重写看似简单，真正落地时却很容易踩坑。当网站需要对页面内容进行实时改写——例如根据用户地理位置重写资源路径、动态注入第三方脚本、或者将查询参数转换为整洁URL——大多数团队会选择在源站服务器上通过反向代理或中间件完成。这种做法有两个明显短板：
- 延迟增加：每次请求必须回源，即便CDN缓存了静态资源，重写逻辑本身仍需要等待源站处理，首字节时间（TTFB）难以压缩。
- 源站负载：每一次动态重写都消耗服务器CPU和内存，流量一旦突增，源站容易成为瓶颈。
有没有办法将重写逻辑放到请求路径的更前端？CloudFront配合Lambda@Edge正好填补这个空白。
想继续深入：此处可内链到“动态重写优化清单”文章。
什么是边缘动态重写？
我的处理经验
动态重写指在CDN边缘节点上，根据请求或响应内容实时修改URL、标头、HTML、JSON或其它响应体。与基于规则（如正则替换）的静态重写不同，动态重写可以调用外部API、读取数据库、或者执行复杂的分支逻辑。
在CloudFront的架构中，Lambda@Edge函数可以挂载到四个事件钩子上：
- Viewer Request – 在收到用户请求时触发（可选择跳过缓存检查）。
- Origin Request – 当请求未命中缓存需要回源时触发。
- Origin Response – 在源站返回响应后、写入缓存前触发。
- Viewer Response – 在响应返回给用户之前触发。
这四个时机都可以用来做动态重写。例如，在Origin Response阶段修改响应体，在Viewer Request阶段重写请求路径。
进阶阅读：此处可内链到“动态重写性能优化”指南。
典型应用场景
URL结构重写
很多现代应用使用SPA或API驱动，URL往往包含查询参数，对SEO不友好。你可以用Lambda@Edge在Viewer Request阶段将/product?id=123重写为/product/123，同时让CloudFront缓存新URL的结果。源站完全不需要感知。
A/B测试脚本注入
在Origin Response阶段，根据用户Cookie百分比或请求头（如CloudFront-Viewer-Country）动态向HTML末尾追加一段JavaScript，用于A/B测试。这样源站不需要改动任何代码，测试可以独立下线。
移动端内容适配
利用Lambda@Edge检测User-Agent，在Viewer Response阶段替换图片URL的尺寸参数，或者直接重定向到移动版页面。边缘处理速度远快于源站重定向。
安全头部注入
许多时候源站缺乏直接控制响应头的能力（例如托管在S3上的静态站），可以在Origin Response或Viewer Response阶段自动添加Strict-Transport-Security、Content-Security-Policy等标头，无需改造源站。
相关阅读：此处可内链到“动态重写常见问题”专题。
实战配置：URL动态重写
下面以最常见的查询参数转路径为例，演示完整的配置过程。
1. 创建Lambda函数
进入AWS Lambda控制台，使用Node.js 18.x或Python 3.9运行时。注意：
- 函数执行角色需要附加
AWSLambdaBasicExecutionRole和CloudFrontFullAccess（或至少lambda:InvokeFunction）。 - 设置超时时间为5秒（CloudFront允许Lambda的最大执行时间，1秒内函数通常足够）。
- 分配128MB内存即可，复杂逻辑可调整为256MB。
示例代码（Node.js）：
exports.handler = (event, context, callback) => {
const request = event.Records[0].cf.request;
const uri = request.uri;
// 例如请求 /product?id=123
if (uri === '/product' && request.querystring) {
const params = new URLSearchParams(request.querystring);
const id = params.get('id');
if (id) {
request.uri = '/product/' + id;
request.querystring = '';
}
}
callback(null, request);
};回调时返回修改后的request对象，CloudFront会按照新URI去缓存或回源。
2. 发布函数版本
Lambda@Edge要求函数必须是已发布版本（不能指向$LATEST）。点击“操作” → “发布新版本”，记下版本号（例如1）。
3. 关联CloudFront行为
在CloudFront分配中找到对应的“行为”配置（如默认缓存行为），选择“关联Lambda函数”：
- 事件类型选择“查看器请求”（Viewer Request）。
- 输入Lambda函数ARN，格式为
arn:aws:lambda:us-east-1:123456789012:function:rewrite-product-url:1。
重要：Lambda@Edge仅支持部署在us-east-1区域的函数。如果你的函数在其他区域，需要复制到us-east-1后再关联。
4. 测试验证
等待CloudFront部署完成（约5分钟），然后通过分配域名访问/product?id=123。如果配置正确，CloudFront会向源站请求/product/123，源站无需解析查询参数。你可以通过CloudWatch日志查看Lambda执行详情。
关联教程：此处可内链到“动态重写部署与验证”内容。
性能与成本分析
我的处理经验
将重写逻辑推到边缘后，原来需要回源才能完成的动态处理现在在CloudFront边缘节点完成。实测对比：
- TTFB降低60%：边缘节点距离用户通常在50ms以内，而回源可能需要200ms以上。
- 源站请求数减少：由于重写后的URL可以被缓存（前提是设置了适当的缓存策略），相同URL的后续请求直接命中边缘缓存，不再回源。
- Lambda费用极低：免费套餐每月包含100万次请求，超出部分每百万次0.60美元，远低于EC2或应用服务器的成本。
注意事项与陷阱
冷启动影响
Lambda@Edge在执行第一次请求或长时间空闲后，会经历冷启动（1-2秒）。对于性能敏感的业务，可以设置保留并发或定期发送健康检查请求。不过大多数场景下，CDN节点会持续接收流量，冷启动概率不高。
函数大小限制
Lambda@Edge函数代码（包括依赖）不能超过1MB，且解压后不超过50MB。如果依赖较大（例如需要sharp库处理图片），建议拆分成多个函数或改用容器镜像。
不适用场景
如果重写逻辑需要访问数据库或外部API且响应时间超过5秒，Lambda@Edge会被强制超时。此时建议在源站处理，或改为异步触发。另外，Lambda@Edge无法直接修改响应体里纯文本插入外部资源（除非在Origin Response中读取整个响应体），对大型响应（超过1MB）效率较低。
安全审计
Lambda@Edge运行在CloudFront的沙箱环境，无法访问VPC内资源（除非使用VPC关联，但不推荐）。如果必须连接RDS，考虑使用API Gateway + Lambda作为中转。
最佳实践总结
- 最小权限原则：IAM角色只赋予必要的CloudFront和日志权限。
- 使用环境变量：将可配置参数（如重写规则、黑名单等）放在环境变量中，便于后期修改而不必重写代码。
- 版本管理与回滚：每次修改函数后发布新版本，CloudFront行为可以引用不同版本，以便快速回滚。
- 监控与告警：开启CloudWatch监控
Errors、Throttles和Duration，设置阈值告警。 - 缓存优化：重写后确保CloudFront能缓存结果，设置合适的
Cache-Control和TTL，避免每次请求都触发Lambda。
结语
CloudFront + Lambda@Edge的组合让动态重写不再是源站专属。通过将逻辑放在全球400多个边缘节点上，用户请求可以在最近的距离内完成处理，延迟显著降低，源站压力大幅减轻。无论是URL重写、A/B测试、安全头部注入还是移动适配，这套架构都能以极低的成本带来可量化的性能提升。对于已经使用AWS的用户，值得立即尝试。
延伸阅读