很多的用户在最初使用 CloudFront 做 Web 类内容分发的时候遇到无法调通的情况,本文总结了用户在配置过程中遇到的常见错误,内容涵盖了大部分用户遇到的情况。
错误一 源访问权限未放开
这种错误常见于用 S3 做源的情况, 引起这种错误的原因是 s3 的访问控制没有对 CloudFront 开放。从浏览器中返回的错误通常类似于下图:
更具体些,可分为以下两个场景:
场景 1. CloudFront 使用了 Restrict Bucket Access
在创建 distribution 的时候选择了 Restrict Bucket Access 为 yes, 但 Grant Read Permissions on Bucket, 选择的是”No, I Will Update Permissions”, 而用户事后却没有在 s3 的桶里更新 policy。如下图所示。
解决方法:
方法 1, 在 S3 中增加桶的策略,使该桶允许该 CloudFront 访问,以下是 policy 示例,其中标黄部分需要替换成用户自己的信息。
{
"Version": "2008-10-17",
"Id": "PolicyForCloudFrontPrivateContent",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::CloudFront:user/CloudFront Origin Access Identity E344H6KAFBMK0I"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::elastictcoutputthumb/*"
}
]
}
方法 2, 重新创建 distribution, 新建的 distribution 中 Grant Read Permissions on Bucket 选择 yes, Update bucket policy, 这样当 distribution 创建完成后,s3 桶的 policy 会被自动更新。
场景 2. 普通的 S3 回源
CloudFront 并未使用 Restrict Bucket Access, 这种情况下如果 s3 中的对象没有设置成可被公共访问,也会出现 Access Denied 的错误。
解决方法:
可以通过设置 s3 桶的 bucket policy 或者设置 s3 中对象的 Object ACL 来实现。 例如,通过 AWS 控制台设置存储桶的 bucket policy:
通过 AWS 控制台设置 S3 对象的 Object ACL:
注:如果想了解 S3 访问控制的详细内容,请参考:http://docs.aws.amazon.com/AmazonS3/latest/dev/s3-access-control.html
错误二 使用自定义域名但未在 CloudFront 中配置
用户有时不直接使用 CloudFront 的 distribution 产生的域名,而是使用了自定义的域名并用 CNAME 的方式指到 CloudFront 的域名, 例如使用 cdn.mydomain.com CNAME 到 d1cbzf61pdxxxx.CloudFront.net。此外,如果使用 Route53 作为 DNS, 也可以不采用 CNAME 的方式,而是采用 Alias 的方式。
CloudFront 规定当使用自定义域名并配置该域名使用 CNAME 或 Alias 的方式指向 CloudFront distribution 的域名的时候,需要在 CloudFront 相应的 distribution 中提供该自定义的域名,如果使用了多个自定义的域名,则提供多个自定义的域名。如果没有提供,就会出现类似下图的错误:
解决方法:
可以通过 AWS 控制台,对 distribution 中的 Alternate Domain Names(CNAMEs)进行设置:
错误三 访问路径错误
配置完 CloudFront 的 Behavior 后,用户有时不能给出正确的 url 来访问想要的资源。 出现访问错误, 如果是回源 s3, 返回的错误通常如下:
如果是回源的自定义网站,返回的错误根据网站的不同而不同,例如:返回”找不到相应的页面”等错误。
解决方法:
避免这种错误很简单,了解 CloudFront Behavior 的 url 与所访问的源站资源的对应方法,即可判别自己的 url 是否正确. 以下举例说明:
某 Behavior 如下,该 Behavior 对应的 origin ID 是 S3-hxybucket/Picture:
进入到 Origin 查看,可知 Origin Domain Name and Path 是 hxybucket.s3.amazonaws.com/Picture
如果通过 d1cbzf61pdxxxx.CloudFront.net/dog.jpg 访问的话, 对应的源站资源是 hxybucket.s3.amazonaws.com/Picture/dog.jpg
如果通过 d1cbzf61pdxxxx.CloudFront.net/jpg/dog.jpg 访问的话,对应的源站资源是 hxybucket.s3.amazonaws.com/Picture/jpg/dog.jpg
即: 将 CloudFront 域名后面的路径追加到 Origin Domain Name and Path (注意,除了 Domain Name 之外,还有 Path) 所对应的路径后面, 就是对应到源站的资源, 用户通过该路径即可判断所使用的 url 是否正确。
错误四 HTTP Method 设置不当
在创建 Behavior 的时候, allowed http methods 选项的默认值是 GET 和 HEAD, 有时用户会使用其他的 HTTP method, 例如 POST, 此时如果还是用默认值,就会出错,返回的错误通常如下:
“This distribution is not configured to allow the HTTP request method that was used for this request. The distribution supports only cachable requests.”
解决办法:
办法很简单,在 Behavior 中重新设定一下 Allowed HTTP Methods 选项,使其包含所用的 HTTP Method.
错误五 设置了 Restrict Viewer Access 却没有使用 Signed URL 或 Signed Cookie
在创建 Behavior 的时候,Restrict Viewer Access (Use Signed URLs or
Signed Cookies)选项的默认值是 No, 如果用户改成了 Yes, 此时该 Behavior 对应的资源必须使用 Signed URL 或者 Signed Cookie 的方式访问,如果使用普通的 Url 访问,返回的错误通常如下:
解决方法:
方法1.使用 signed url 或 signed Cookie 进行访问,具体参考:http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/PrivateContent.html
方法 2. 将 Restrict Viewer Access (Use Signed URLs or
Signed Cookies)的值改为 No。如图:
错误六 Object Caching 设置不当
虽然能够访问到源,但有时用户会反映使用了 CloudFront 并没有加速访问,有时甚至效果还不如未使用 CloudFront 时。 这很可能是由于 Object Caching 设置不当造成的。
解决方法:
Object Caching 有两个选项,分别是 Use Origin Cache Headers 和 Customize。默认选项是前者。但是,当默认选择了 Use Origin Cache Headers,而源的 HTTP header 中却没有 Cache-control 的头,那返回内容就不被缓存了。 因此,用户需谨慎选择,当源的返回值中没有 Cache-control 头的情况下,选择 Customize,Customize 中的 Default 值将会成为 TTL 时间(时间单位是秒)。
另外,如果源的返回值中存在 Cache-control,而 Object Caching 又选择了 Customize, 这种情况下返回的内容肯定会在 CloudFront 边缘节点中被缓存。但 CloudFront 会使用哪个值作为 TTL 呢? 这个在 CloudFront 文档中有详细的描述, 详见: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html
作者介绍:
韩小勇
亚马逊 AWS 解决方案架构师,负责基于 AWS 的云计算方案架构咨询和设计,实施和推广,在加入 AWS 之前,从事电信核心网系统上云的方案设计及标准化推广 。
本文转载自 AWS 技术博客。
原文链接:
https://amazonaws-china.com/cn/blogs/china/cloudfront-errors-solutions/
评论