在CloudFront中更改"Origin Path"需要很长时间才能启动
Sla*_*mir 5 amazon-s3 amazon-web-services amazon-cloudfront
我们在S3中托管了一个静态站点,并随CloudFront一起提供.该网站有效,但推出更新需要很长时间 - 数小时或更长时间.具体而言,改变原点路径几乎不会像所希望的那样快速地反映在边缘位置上.
这是我们想要实现的目标......
我们的S3存储桶配置为托管网站.它存储同一站点的多个版本.每个git标签有一个子目录.例如:
/git-v1
/git-v2
/git-v3
..
目标是告诉CF开始按照Origin Path设置提供新版本的站点.我们不希望使旧对象无效,只需通过创建一个新目录并指向CF来继续推进该版本.CloudFront Distributions下的状态显示"Deployed"很长一段时间,但边缘位置继续忽略新的Origin Path.
任何关于如何使CF开始更快地服务新子目录的想法将不胜感激.
检查缓存后,该Origin Path设置将应用于请求...而不是之前.当URI中请求的对象不在缓存中时,将从Origin服务器请求该对象.此时,Origin Path被添加到传入请求路径之前,然后发送到原点.缓存基于传入的请求路径.¹
设置本身会在几秒钟内快速生效,但不会清除缓存.
如果这仅用于对根页面进行版本控制,则可以将原始路径留空,将默认根对象更改为新的根对象,然后使其无效/.或者,您可以继续做您正在做的事情,并/*在做出更改后失效.免费失效限制为每月1000次,但无效/*(或任何通配符)仅计为1次失效,无论通配符匹配多少个对象.
¹ 传入请求路径也指Lambda @ Edge Viewer请求触发器修改它后的路径(如果适用).
| 归档时间： |
|
| 查看次数： |
1637 次 |
| 最近记录： |