如果你的资源已经在 S3、用户分布在全球，并且希望边缘节点能做请求级别的改写或鉴权，那么 CloudFront 进阶 配置是必经之路。CloudFront 与 S3 的联动看似简单，但要做到回源安全、命中率高、并能用 Lambda@Edge 注入业务逻辑，需要踩过几道关卡。本文将教你如何为 S3 静态站点配置一份生产可用的 CloudFront 分发，覆盖 OAC、缓存策略、Lambda@Edge 与监控告警，帮你解决”S3 桶被公开暴露、命中率却很低”这类问题。
一、CloudFront 适合的场景
CloudFront 与 BunnyCDN、KeyCDN 等通用 CDN 的本质差异，在于它紧密集成 AWS 生态：与 S3、ALB、API Gateway 直接打通，可用 Lambda@Edge 或 CloudFront Functions 写边缘逻辑，权限走 IAM。判断是否值得选它，三个维度参考：生态深度（后端是否已在 AWS）、边缘可编程（请求层改写、签名、A/B Test）、企业合规（IAM 权限、CloudTrail 审计）。
源站不在 AWS 时 CloudFront 仍可用，优势变为”全球节点 + AWS WAF 联动”。源站线路选择可参考 WordPress 香港主机选购指南 与 云服务器选购指南 中关于网络出口的章节。
二、用 OAC 锁定 S3 源站
很多团队初期把 S3 桶设为 public-read 让 CloudFront 直连。这种方式简单但留下安全隐患：S3 真实 URL 会被搜索引擎收录、爬虫直接绕过 CDN 拉取，CloudFront 上的 WAF 与缓存全部失效，源站还要额外承担直连流量与带宽费用。
正确做法是使用 OAC（Origin Access Control，源访问控制）：CloudFront 用 SigV4 签名访问 S3，S3 桶策略仅允许带正确签名的 CloudFront 请求。具体步骤是在控制台 Origins → Add Origin → 选 S3，勾选 “Origin access control settings” 并新建一个 OAC，再到 S3 桶 → Bucket Policy 粘贴 CloudFront 自动生成的策略，该策略要包含 Service: cloudfront.amazonaws.com 主体、Action: s3:GetObject、目标桶资源、以及 AWS:SourceArn 条件以避免共用桶被其他 Distribution 访问。
策略生效后，把 S3 桶整体设置回 Block all public access 状态，桶对外完全不可见。任何尝试直接访问 S3 URL 的请求都会被拒绝，所有访问必须经过 CloudFront，从而把 WAF、缓存、日志统一收敛到 CDN 层。如果业务还用到了 SSE-KMS 加密，OAC 角色还需要在 KMS 密钥策略里授予 kms:Decrypt 权限，否则会出现 403 同时缓存命中率不变的奇怪现象。
三、缓存策略与 Origin Request Policy
CloudFront 2026 版本把缓存配置拆成三层：Cache Policy（决定 cache key 字段）、Origin Request Policy（回源时透传哪些头与 Cookie）、Response Headers Policy（边缘注入响应头）。推荐组合：静态资源用 CachingOptimized + AllViewerExceptHostHeader + SecurityHeadersPolicy；API 接口用 CachingDisabled + AllViewerAndCloudFrontHeaders；HTML 入口自定义短 TTL（5 分钟），cache key 仅含 URL + Accept-Encoding。如果源站已启用本地缓存插件，可参考 WordPress W3 Total Cache 调优实战 关于 TTL 协作的章节；更多 WordPress 加速场景在 WordPress 分类 下查阅。
四、Lambda@Edge 实战：请求改写与鉴权
CloudFront 提供两种边缘函数：CloudFront Functions（仅 Viewer 阶段，毫秒级、JS 子集、成本极低）和 Lambda@Edge（四阶段全覆盖、完整 Node.js、可调用 AWS SDK）。简单字符串替换、Header 注入这类轻量逻辑用 CloudFront Functions 就够，需要访问 DynamoDB、KMS、Secrets Manager 这类外部资源时才用 Lambda@Edge。
典型的请求改写场景在 Origin Request 阶段处理：根据 cloudfront-viewer-country 头判断 viewer 国家，对来自特定区域的 /api/ 请求切换到对应的源站；同时把根路径请求补全为 /index.html，让 S3 静态站点能正确返回首页。后者对 S3 尤其重要，因为 S3 本身不会自动解析”目录索引”，没有这一步前台会拿到一个奇怪的 ListBucket 错误。
鉴权场景最常落在 Viewer Request 阶段，函数检查 Cookie 或 JWT 后决定是放行还是返回 401。这种鉴权前置可以在源站完全无感知的情况下阻挡 95% 以上的恶意请求。Lambda@Edge 部署后向全球节点传播大约需要 5 到 15 分钟，调试期间建议在 us-east-1 用 CloudWatch Logs 跟踪函数日志，注意 Logs 是按节点所在地区分别落地的，不在 us-east-1 不一定能看到。
五、监控、告警与成本控制
CloudFront 三个关键指标：CacheHitRate（建议 85% 以上，低于 70% 说明策略或源站头有问题）、OriginLatency（区分 First Byte 与 Total）、5xxErrorRate（超过 1% 应告警）。在 CloudWatch 中为每个指标创建 Alarm，触发后通过 SNS 推送到 Slack 或邮件。成本控制方面，CloudFront 按区域计费，AWS Africa、South America 区域显著贵于北美欧洲。如业务集中亚太，可把 Distribution 的 Price Class 设为 PriceClass_200，节省约 20% 流量费的同时仍能覆盖绝大多数核心用户群。账单上注意区分流量费、HTTPS 请求费、函数调用费三大类，函数调用费在 Lambda@Edge 启用后可能成为意外开销，建议为 Lambda@Edge 单独建一个成本标签。
六、故障排查清单
CloudFront 上线后高频问题与处理方向：S3 返回 403 时检查 OAC 关联、S3 桶策略 AWS:SourceArn 条件、SSE-KMS 权限；缓存命中率突降通常是新版本 Cache Policy 把 Cookie 加入 cache key 导致基数爆炸；Lambda@Edge 报 ResourceConflict 需先解除关联等版本传播完成（约 1 小时）再删除；特定区域延迟高可能是 PriceClass_200 不含该区域；国内访问慢可用 美国 VPS 部署教程 中的 MTR 命令定位瓶颈跳点。
七、与 WAF、Shield 联动
CloudFront 与 AWS WAF（Web Application Firewall，Web 应用防火墙）的深度集成是其他通用 CDN 难以匹敌的。建议至少启用三组规则：AWSManagedRulesCommonRuleSet、AWSManagedRulesKnownBadInputsRuleSet、AWSManagedRulesAmazonIpReputationList。AWS Shield Standard 自动包含在每个 Distribution 中，能抵御 L3/L4 层 DDoS。中小站点可不升级 Shield Advanced，但要把 WAF 速率限制（Rate-Based Rule）阈值压到 2000 请求每 5 分钟。
总结与建议
CloudFront 进阶 的关键是把”分发架构”与”边缘逻辑”分开管理：分发层用 OAC、Cache Policy 与 Response Headers Policy 完成静态资源的安全与命中率优化；边缘逻辑层用 CloudFront Functions 处理轻量改写、用 Lambda@Edge 处理需要 AWS SDK 的复杂任务。建议中型团队先把 S3 + OAC + 标准 Cache Policy 跑通，再逐步引入 Lambda@Edge 与 WAF 联动。如果你需要把 CloudFront 与已有 WordPress 站点组合，可以考虑先用它作为图片、字体、JS 的边缘层，HTML 仍由源站直接承担，迁移过程更平稳。整体来看，CloudFront 适合作为 AWS 生态内站点的默认 CDN，与 IAM、CloudWatch、WAF 的联动让运维与合规都更顺手。对正在评估迁移路径的团队，建议先把一个非核心的图片域名迁过来跑两周，确认账单结构与命中率达标后再扩展到主站点，整个过程通常能在一个迭代周期内完成。