写点什么

Amazon CloudFront 常见错误配置及解决方法

  • 2019-11-20
  • 本文字数:4050 字

    阅读完需:约 13 分钟

Amazon CloudFront常见错误配置及解决方法

很多的用户在最初使用 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/


2019-11-20 08:001573

评论

发布
暂无评论
发现更多内容

Django笔记二十九之中间件介绍

Hunter熊

Python django 中间件 middleware

PoseiSwap缘何成DEX赛道新宠?POSE价值分析

股市老人

2023-05-15:对于某些非负整数 k ,如果交换 s1 中两个字母的位置恰好 k 次, 能够使结果字符串等于 s2 ,则认为字符串 s1 和 s2 的 相似度为 k。 给你两个字母异位词 s1

福大大架构师每日一题

Go 算法 rust 福大大

Java字节码 - ByteBuddy原理与使用(上)

骑牛上青山

Java JVM bytebuddy 字节码

MySQL 8.0不再担心被垃圾SQL搞爆内存

GreatSQL

MySQL MySQL 数据库 greatsql greatsql社区

23年最新Java岗常见面试题及答案(1000道),90% 的公司都会问到

Java你猿哥

Java MySQL zookeeper JVM java面试

骨灰级技术大牛左耳朵耗子(陈皓)突发心梗离世。

福大大架构师每日一题

福大大

在 Python 中如何使用并发模型编程

江湖十年

Python 并发编程 多线程 协程 多进程

面试官:断网了,还能 ping 通 127.0.0.1 吗?

Java你猿哥

Java 架构 ssm ping

volatile 关键字与计算机底层的一些杂谈

Java你猿哥

Java volatile JVM ssm java知识点

首个支持RWA交易的订单簿DEX-PoseiSwap,即将开启IEO

股市老人

首个支持RWA交易的订单簿DEX-PoseiSwap,即将开启IEO

西柚子

Nest.js JWT 验证授权管理

程序员海军

Node JWT nest

PoseiSwap缘何成DEX赛道新宠?POSE价值分析

西柚子

Java数据库项目之满汉楼

timerring

Java

百万年薪大佬甩出的SpringBoot趣味实战手册,GitHub标星81.6K

Java你猿哥

redis spring Spring Boot Spring MVC 消息队列对比

首个支持RWA交易的订单簿DEX-PoseiSwap,即将开启IEO

BlockChain先知

C语言编程-基本语法

梦笔生花

GitHub笔记疯抢竟崩溃!Redis完整开发实战居然包含大厂同款项目

Java你猿哥

Java redis ssm java面试 Redis 核心技术与实战

Makefile基础教程:从零开始学习

小万哥

程序员 面试 后端 C/C++ makefile

玩转Netty,从“Hello World”开始!

Java你猿哥

Java Netty ssm

古鱼、恐龙和大众,相逢在百度百科的“彩虹桥”

脑极体

百科

GitHub万赞,不愧是腾讯大牛总结的操作系统笔记,面面俱到太全了

Java你猿哥

Java 面试 多线程 ssm 线程与进程

Nautilus Chain 或成未来最好的链上隐私生态

鳄鱼视界

记录一次解决Maven依赖冲突的过程

做梦都在改BUG

Java maven

如何使用Go语言实现ISP原则

Jack

解密 Golang 哈希算法:深入了解 MD5、SHA-1 和 SHA-256

Java你猿哥

Java golang 算法 哈希算法 Go 语言

Java字节码 - ByteBuddy原理与使用(下)

骑牛上青山

Java bytebuddy 字节码

AIGC产业研究报告2023——语言生成篇

易观分析

智能 制造

Amazon CloudFront常见错误配置及解决方法_其他_亚马逊云科技 (Amazon Web Services)_InfoQ精选文章