AWS CloudFront不遵循TTL设置问题咨询

近期发现，无论CloudFront的最小、最大、默认TTL设置，还是源站响应头如何配置，CloudFront都会在1天后删除文件。有三个疑问：

• 是否可以覆写响应头，强制CloudFront遵循TTL值？
• 若无法实现，CloudFront在从CDN删除文件前实际采用的TTL是多少？
• 若确实无相关SLA，求推荐其他可靠的带SLA的CDN服务。

提供的响应头 #

请求1（缓存命中） #

Response Version - HTTP/2
access-control-allow-origin: *
age: 60847
alt-svc: h3=":443"; ma=86400
cache-control: max-age=2592000
content-encoding: gzip
content-type: text/css
date: Sun, 30 Jul 2023 09:57:24 GMT
expires: Tue, 29 Aug 2023 09:57:24 GMT
last-modified: Wed, 20 Jan 1988 04:20:42 GMT
server: nginx
vary: Accept-Encoding
via: 1.1 xxx.cloudfront.net (CloudFront)
x-amz-cf-id: XXX
x-amz-cf-pop: YVR50-C1
x-cache: Hit from cloudfront

请求2（缓存未命中） #

Response Version - HTTP/2
access-control-allow-origin: *
alt-svc: h3=":443"; ma=86400
cache-control: max-age=315360000
content-encoding: gzip
content-type: text/css
date: Sun, 06 Aug 2023 00:12:08 GMT
expires: Thu, 31 Dec 2037 23:55:55 GMT
last-modified: Wed, 20 Jan 1988 04:20:42 GMT
server: nginx
vary: Accept-Encoding
via: 1.1 xxx.cloudfront.net (CloudFront)
x-amz-cf-id: XXX
x-amz-cf-pop: YVR50-C1
x-cache: Miss from cloudfront

1. 能否覆写响应头强制CloudFront遵循TTL？ #

可以通过CloudFront的两种方式实现：

• 缓存策略（Cache Policy）：直接配置最小、最大、默认TTL，同时设置「源站请求头行为」为优先使用源站的Cache-Control/Expires头，或者完全忽略源站头，强制使用CloudFront配置的TTL值。若之前设置未生效，需检查缓存策略是否关联到对应行为路径，或源站是否返回no-cache/no-store等特殊指令（你的响应头中无此问题）。
• 自定义响应头策略：在CloudFront行为中添加自定义响应头，覆盖源站返回的Cache-Control和Expires值，确保CloudFront按指定TTL缓存。

2. CloudFront实际缓存TTL规则 #

文件1天后被删除大概率不是TTL到期，而是CloudFront的缓存淘汰机制：当节点缓存空间不足时，会主动淘汰访问频率低的文件，即使TTL未到期。

• 官方未承诺缓存内容会保留满TTL的SLA，仅当缓存空间充足且内容访问频繁时，才会保留至TTL到期。
• 从你提供的响应头看，请求1的age为60847秒（约16.9小时），缓存仍有效；请求2间隔约6天出现MISS，大概率是这段时间文件访问量低，被节点主动淘汰。

3. 带SLA的可靠CDN推荐 #

若需明确的缓存保留SLA，可考虑以下服务商：

• Cloudflare Enterprise：提供缓存保留SLA承诺，支持精细化TTL配置，缓存规则控制灵活。
• Akamai：企业级CDN，对缓存生命周期有明确服务条款，适合缓存稳定性要求高的场景。
• Fastly：支持精细缓存策略配置，提供SLA保障，适配动态内容和频繁更新的静态资源场景。

内容的提问来源于stack exchange，提问作者JM John