写点什么

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:001825

评论

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

阿里面试:100个高频Spring面试题,助你一臂之力

Java你猿哥

Java spring 面试 Spring Boot 面经

实用性好的云管平台有哪些?咨询电话多少?

行云管家

云计算 云资源 云管理

保姆级教程!玩转 ChunJun 详细指南

袋鼠云数栈

大数据 开源

接招吧!最强“高并发”系统设计 46 连问,分分钟秒杀一众面试者

做梦都在改BUG

Java 系统设计 高并发

从零开始自己动手写阻塞队列

Java你猿哥

Java 线程 阻塞队列 实战

中国音乐市场增长超28%,首次成为全球第五大市场

曲多多(嗨翻屋)版权音乐

知识产权 娱乐 音乐 版权 娱乐产业

修复SSH在 MacOS Ventura 系统上不能使用RSA签名的问题

互联网搬砖工作者

面试官:kafka分布式消息系统,你真的了解吗?

做梦都在改BUG

Java kafka 消息队列 消息系统 消息中间件

夺冠在即!2022 OceanBase数据库大赛12强集结

OceanBase 数据库

数据库 oceanbase

深入理解Spring注解机制:注解的搜索与处理机制

Java你猿哥

Java spring Spring Boot ssm Spring注解

二本4年Java经验,五面阿里艰苦经历(定薪45K),回馈一波心得体会

Java你猿哥

Java redis 面试 Spring Boot 面经

mysql-online-ddl是否需要rebuild

TiDB 社区干货传送门

Chaosd 模拟两地三中心集群的网络环境

TiDB 社区干货传送门

实践案例 管理与运维 故障排查/诊断 安装 & 部署

对tidb-lightning导入机制的一点点研究

TiDB 社区干货传送门

故障排查/诊断 TiDB 源码解读

从反脆弱角度说一说:技术系统高可用性策略

小小怪下士

Java 程序员 系统设计 后端 秒杀

Docker等容器技术如何与移动开发相结合

FinClip

Nautilus Chain主网上线在即空投规则公布,如何获得更多的空投?

西柚子

BGA焊接问题解析,华秋一文带你读懂

华秋电子

如何使用ShareSDK快速实现Android APP的社会化分享登录功能

MobTech袤博科技

【v6 认证】PCTA/PCTP/PCSD 我的备考经验

TiDB 社区干货传送门

社区活动 新版本/特性发布 TUG 话题探讨 6.x 实践

如何在树莓派上使用MQTT协议

EMQ映云科技

树莓派 物联网 IoT mqtt 企业号 3 月 PK 榜

Visio 绘图注释工具:VSDX Annotator 激活版

真大的脸盆

Mac Mac 软件 注释工具

TiCDC+Confluent同步数据到Oracle

TiDB 社区干货传送门

实践案例 集群管理 管理与运维 安装 & 部署 数据库架构设计

MobPush iOS SDK API

MobTech袤博科技

重磅消息!ChatGPT 联网,Milvus & Zilliz 正式嵌入用于向量检索!

Zilliz

非结构化数据 Milvus Zilliz 向量数据库 ChatGPT

可观测性之谷歌性能主管最新的有关LCP的文章

Yestodorrow

性能 可观测性 用户体验

SSO认证是什么意思?有哪些优势?

行云管家

SSO认证

多平台小程序一站式管理分享

FinClip

AutoCAD安装失败,提示错误“Error 112”和安装进度条倒退为0

互联网搬砖工作者

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