如何开通 CloudFront 和 Route 53

Posted 2023-05-08

AWS CloudFront是一个用户用于加速静态或动态内容发布的内容发布服务，这里所谓的静态或动态内容主要包括媒体（图像或视频）文件、html、Java脚本程序、CSS文件以及其它。
作者：文:Ofir Nachmani 译:滕晓龙来源：TechTarget中国|2015-03-09 10:12
收藏
分享

AWS CloudFront可配合一些其他的服务一起使用，其中就包括了EC2和S3。遵循以下步骤可从一个S3存储段中设置一个CloudFront分布。
AWS CloudFront是一个用户用于加速静态或动态内容发布的内容发布服务，这里所谓的静态或动态内容主要包括媒体（图像或视频）文件、HTML、Java脚本程序、CSS文件以及其它。它的简洁用户界面可以帮助管理员设置CloudFront发布。但是，这一过程并不只是指向和点击那么简单。下面，就让我们来看看CloudFront的工作原理以及应当如何来部署它。
在CloudFront中，每一片的内容都被组织成为具有独特URL并可从网络被访问的发布。该服务可从边缘加速节点数据中心发布这一内容；目前，AWS在全球部署着52个边缘加速节点数据中心以供内容缓存使用。
AWS CloudFront支持两种形式的发布：流形式与下载方式。当一名用户使用CloudFront URL来请求静态内容时，该服务就会根据发出请求的IP以及缓存这一内容的数据中心的位置来找到距离这个IP最近的边缘加速节点数据中心。这样一来，所有来自于相同位置的请求就会减少延迟时间。
CloudFront可配合多个AWS服务使用，其中包括了简单存储服务（S3）、弹性计算云（EC2）、弹性负载平衡（ELB）以及Route 53。CloudFront的主要功能包括：
支持动态内容（减少未来请求的延迟时间）
支持自定义域名
设备检测（移动设备和网络设备）
支持Post/PUT以及其它的HTTP协议
自定义错误响应
支持cookies、查询字符串以及其它
链接一个CloudFront发布至S3
为了从一个S3建立一个CloudFront网络发布，你将需要一个S3存储和一个可公开访问的对象（如图1）。

图1 S3存储段以及一个可公开访问的对象
然后，可遵循以下步骤：
1. 转至CloudFront并创建一个网络发布

图2 选择初始域名存储段
2. 在初始域名栏位，选择存储段名称，并在限制存储段访问中选择“No”。这样做可以限制只能从CloudFront访问对象，所以就没有人可以从S3访问这个存储段了（如图2）。
3. 使用以下参数配置缓存设置：
路径模式：默认。针对特定对象应用缓存处理。如果选择了默认值（*），它就会把所有请求发送到选中的存储段中。
浏览器协议策略：HTTP 和 HTTPS。如果用户想要求CloudFront允许浏览器使用HTTP或HTTPS协议来访问用户的网络内容。
允许的HTTP方法：GET，HEAD。选择用户希望这一缓存操作所允许的HTTP方法列表。
转发头文件：None。如果用户希望根据请求中发送的头文件来缓存内容，那么就可以使用它。理想情况下，保持“None”项是可以提高性能的。
对象缓存：使用初始缓存头文件。当你的初始服务器将增加一个缓存控制头文件以便于控制对象被保存在CloudFront缓存中多长时间时，可选择这一选项。
转发cookies：无。如果用户希望CloudFront在它发送给初始服务器的请求中囊括所有的用户cookies，那么就可以指定“None”。否则，可指定你希望包含在内的cookies。选择“None”，就可配置CloudFront不要发送cookies。
转发请求字符串：不。为了根据URL中的请求字符串获得不同版本的对象；设置“Yes”选项以便于在发送给初始服务器的请求URL中包含请求字符串。
限制浏览器访问：No。在理想情况下，选择“yes”以提高安全性。选择“no”可让每个人都能够查看内容。限制浏览器访问意味着要求使用者为安全访问而创建一个签名的URL（如图3）。

图3 限制浏览器访问
4. 接下来，是设定发布设置
价格类别：使用所有的边缘加速节点数据中心。这一操作可以让用户自行选择愿意为CloudFront服务支付的最高价格。
CNAMEs：空白。这一操作可以允许用户为对象使用URL而不是CloudFront分配的域名。因此，用户可以指定一个自定义URL，而不是CloudFront发布。
SSL证书：默认CloudFront。这一项可以让管理员上传他们自己的证书。用户还可以保留其它的选项作为默认值，并创建发布（如图4）。

图4　默认的CloudFront设置。
一旦创建了发布，那么你将有一个CloudFront URL，例如："＂。然后，就可以使用这个URL来访问对象了。 参考技术A 您好：
CloudFront 和 Route 53 是AWS提供的DNS 和 CDN服务。
请注意：非美国信用卡注册的AWS账号，默认这 CloudFront 和 Route 53 是禁用的。需要发邮件人工激活这两个服务，才能正常使用。
1、这两个服务都是和您的域名强关联的，你必须有一个自己域名的邮箱。
例如：[e-mail]；必须使用这个邮箱发邮件给AWS，才能证明您是该域名的相关人员。邮件发送到这个邮箱：[e-mail]
2、通常AWS的反应速度很快，一般在24小时内都可以处理并回复。
3、登录AWS控制台，再次进入这两个服务，确认服务已经正常可用了。
您能注意到这个问题，证明您是这个时代的领导者，佩服！
祝您好运！

尝试实现 socket.io 通信时收到 GET 400。 Node.js、ELB、Route 53、CloudFront 和 s3

【中文标题】尝试实现 socket.io 通信时收到 GET 400。 Node.js、ELB、Route 53、CloudFront 和 s3

【英文标题】：Receiving GET 400 when trying to implement socket.io communication. Node.js, ELB, Route 53, CloudFront, and s3

【发布时间】：2021-01-05 21:26:36

【问题描述】：

注意**我可以通过使用 route-53 和弹性 beanstalk 环境将 cloudfront 从 server.com 域的图片中移除来使事情正常运行。仍然很高兴知道为什么云端会阻止这一点，但不是直接关注开发**

我正在使用 cloudfront 和路由 53 为来自 s3 存储桶的 node.js 静态 socket.io 客户端提供服务。我正在尝试让该客户端使用弹性 beanstalk 与 node.js Web 服务器通信。网络服务器使用路由 53 域和云端与亚马逊证书管理器生成的 ssl 连接。

使用 http 客户端并直接连接到 beanstalk 环境，我看到了所需的功能。但是，当我尝试使用收到的客户端和服务器迁移到 SSL/https 时：

(log from /var/log/nginx/error.log on elastic beanstalk instance)

"GET /socket.io/ HTTP/1.1" 400 51 "-" "Amazon CloudFront"

这是从静态 s3 https 域运行的客户端代码：

import ioClient from "socket.io-client";

const ENDPOINT = "https://server.com";
export const socket = ioClient(ENDPOINT);

这里是服务器端。 process.env.port 设置为 8080，我可以通过弹性 beanstalk 日志验证应用正在侦听 8080。

const express = require("express");
const http = require("http");
const socket_io = require("socket.io");

const index = require("./routes/index");
const app = express();
app.use(index);

const server = http.createServer(app);
const io = socket_io(server);

const port = process.env.port || 4001;
server.listen(port, () => console.log(`http server listing on port $port`));

在 ALB 内部，我在端口 443 上设置了一个 https 侦听器，并通过 Amazon Certificate Manager (ACM) ssl 认证。侦听器有一个将 443 https 映射到 http 上的 8080 的进程，我认为 ngnix 应该从那里充当我在 8080 上的 socket.io 侦听器的反向代理

监听器和处理器

在我的节点项目文件夹的根目录中，我有一个 .ebextensions 目录，其中有一个名为 01_files.config 的文件，其中包含以下内容：

files:
    "/etc/nginx/conf.d/websocketupgrade.conf" :
        mode: "000755"
        owner: root
        group: root
        content: |
             proxy_pass http://localhost:8080;
             proxy_set_header Upgrade $http_upgrade;
             proxy_set_header Connection "upgrade";
             proxy_http_version 1.1;
             proxy_set_header Host $host;

来自这篇帖子中的 cmets：socket.io handshake return error "Transport unknown" 我发现了以下 socket.io 错误代码

engine.io message type:

open =0
close =1
ping =2
pong =3
message =4
upgrade =5
noop =6
socket.io message type:

connect = 0
disconnect = 1
event = 2
ack = 3
error = 4
binary_event = 5
binary_ack = 6

所以，400 51 可能意味着“错误请求，升级断开连接。”

这是响应正文： "code":0,"message":"Transport unknown"

这是浏览器中客户端应用程序的错误：

polling-xhr.js:268 GET https://server.com/socket.io/?EIO=3&transport=polling&t=NIgQkyr 400

这看起来像是 xhr 传输层上的失败轮询请求

【参考方案1】：

从 AWS 支持收到此解决方案：

我已经与 CloudFront (CF) 专家讨论了您的案例，并且我已经 给你一些信息。

在与我的同事完成 CF 设置后，我们注意到 CF 不会将 HOST 标头转发到 Elastic Beanstalk (EB)。这 表示如果 CF 和 EB 之间的连接是通过 HTTPS 建立的， 它会失败。为了解决这个问题，我们必须看看 CF 政策。 我们注意到您正在使用缓存策略。在本政策中 有一个标题设置。在这里我建议你 指定主机设置。这样，它可以保护 HTTPS 连接 根据来源证明。

如果这不起作用，我可以提出其他建议。这 您看到的错误 (GET /socket.io/ HTTP/1.1" 400 51 "-" "Amazon CloudFront" "(redacted IP, redacted IP") 应该返回一个 “X-Amz-Cf-Id”ID 和一个值（类似于“X-Amz-Cf-Id: jkahDAKJSHDAjhAKSJDHasd==")。既然没有，我怀疑可能 websocket 请求参数出错了。为此我 建议查看我们的文档并确保 正在使用 CloudFront 所需的正确请求参数。你 可以在此处找到该文档的链接：[1]。

如果一切都失败了，我建议您向您的 CF 提出请求并 记录从响应头中返回的键值对 CF。它应该看起来像“X-Amz-Cf-Id： jkahDAKJSHDAjhAKSJDHasd==" （我提到的相同 ID 和值 较早）。这个值允许我们作为支持工程师拉 使用我们的工具的 CF 内部日志。这个值需要 在请求时记录。一旦你有了这个键值 对，然后您可以向 CloudFront 团队开具支持票证， 向他们提供错误详细信息以及键值对，以及 CF 工程师将非常乐意为您提供帮助。此外， 您甚至可以在新的案例中引用此案例（案例 ID = 7399701121） 案例，以便协助您的工程师了解更多背景信息。

总结一下，我的第一个建议是你转发主机 标题。二是使用请求所需的参数 云前。最后，如果您在那之后遇到另一个错误， 记录 CloudFront 为 错误。由于我不是 CloudFront 专家，我建议打开一个 新的 CloudFront 案例并在消息中提供该键值对。

我希望这些信息对您有用。如果你还有 有任何问题或疑虑，请随时与我们联系。

【讨论】：

嗨 Lucas，我​​们遇到了类似的问题。我们在 ec2 机器中有我们的套接字 io，而 s3 有我们的应用程序正在尝试建立连接。你能看看这里吗***.com/questions/66205150/…