第四阶段：CloudFront（CDN）与前端全球加速¶

本章学习目标：

理解为什么有了 S3 还需要 CloudFront

理解 CDN 的基本工作原理

掌握 CloudFront 与 S3 的关系

能为前端项目配置 CloudFront 加速

建立“性能 + 成本 + 架构”的整体认知

1. 为什么有了 S3 还需要 CloudFront？¶

在上一章中，我们已经完成了：

将前端页面部署到 S3
通过浏览器直接访问 S3 静态网站

功能上已经没有问题，但在真实使用中仍然存在明显不足。

1.1 S3 静态网站的天然局限¶

假设你的 S3 Bucket 位于 东京（ap-northeast-1）：

日本用户访问 → 速度快
欧洲 / 美国用户访问 → 延迟明显升高

原因是：

S3 是区域级服务，请求需要跨洲访问。

1.2 一个必须建立的认知¶

S3 解决的是“存在哪里”，
CloudFront 解决的是“访问快不快”。

2. 什么是 CloudFront？¶

CloudFront 是 AWS 提供的 CDN（Content Delivery Network）服务。

可以把它理解为：

一个分布在全球各地的高速缓存网络。

它的目标只有一个：

让用户从最近的节点访问内容

3. CDN 的工作原理（新手版）¶

CloudFront 的典型访问流程如下：

用户
 ↓
就近 Edge Location（边缘节点）
 ↓（无缓存时）
S3（源站）

访问过程说明¶

第一次访问：
- Edge 没有缓存
- CloudFront 向 S3 拉取资源
- 同时缓存在 Edge
后续访问：
- 直接从 Edge 返回
- 不再访问 S3

4. Edge Location 是什么？¶

Edge Location（边缘节点）是 CloudFront 的核心组成部分：

分布在全球各大城市
数量远多于 AWS Region
只负责缓存与分发内容

Region 与 Edge Location 的区别¶

对比项	Region	Edge Location
是否运行 EC2	是	否
是否存原始数据	是	否
是否面向用户	间接	直接
主要作用	计算 / 存储	内容加速

5. CloudFront 与 S3 的关系¶

CloudFront 本身 不保存原始数据，它依赖一个源站（Origin）。

在前端架构中：

CloudFront → S3

S3：源站（存放原始文件）
CloudFront：加速层（缓存 + 分发）

6. CloudFront 能解决哪些问题？¶

6.1 全球访问加速¶

用户访问最近的 Edge
延迟大幅降低

6.2 降低 S3 访问压力与成本¶

缓存命中后不再访问 S3
减少请求次数与流量费用

6.3 HTTPS 与域名支持¶

默认支持 HTTPS
可绑定自定义域名（进阶内容）

7. 实战：为 S3 前端项目配置 CloudFront¶

实战目标：
在不修改前端代码的前提下，实现全球加速访问。

7.1 创建 CloudFront Distribution¶

操作步骤：

AWS 控制台 → CloudFront
点击 Create Distribution
Origin domain：选择对应的 S3 Bucket
Viewer protocol policy：Redirect HTTP to HTTPS
其余配置保持默认
创建 Distribution

7.2 等待部署完成¶

状态：Deploying → Enabled
通常需要几分钟

7.3 使用 CloudFront 域名访问¶

CloudFront 会生成一个域名，例如：

https://d123456abcdef.cloudfront.net

通过该地址访问前端页面。

8. CloudFront 与 S3 Website Endpoint 对比¶

项目	S3 Website Endpoint	CloudFront
全球加速	❌	✅
HTTPS	❌	✅
缓存机制	❌	✅
自定义域名	❌	✅

📌 生产环境几乎都会使用 CloudFront。

9. CloudFront 缓存基础认知¶

9.1 为什么更新文件后没有立刻生效？¶

原因：

Edge 节点仍在使用旧缓存

解决思路（概念级）：

等缓存自动过期
或进行缓存刷新（Invalidation）

10. 当前完整前端架构总结¶

浏览器
 ↓
CloudFront（CDN）
 ↓
S3（前端资源）

后端仍然是：

浏览器
 ↓
Nginx
 ↓
Spring Boot（EC2）

这是一个标准的 前后端分离云架构。

11. 本章总结¶

S3 负责存储
CloudFront 负责加速
前端不再依赖服务器
性能与成本同时优化

理论补充：为什么前端页面不部署在 EC2，而部署在 S3？¶

在学习 AWS 的过程中，很多初学者都会有一个非常自然的疑问：

“既然我已经有 EC2 + Nginx 了，
为什么不直接把前端页面放在 EC2 上，而是要放到 S3 中？”

这是一个非常关键的问题，理解它，意味着你真正开始理解云架构的设计思想。

一、EC2 的定位：计算，而不是文件分发¶

EC2（Elastic Compute Cloud）的核心价值在于：

运行程序
执行业务逻辑
处理 API 请求
进行计算任务

也就是说：

EC2 是为“计算”而设计的服务。

虽然 EC2 也可以通过 Nginx 返回 HTML 页面，但这并不是它最擅长、也不是最合理的用途。

二、前端页面的本质：静态文件分发问题¶

前端项目（HTML / Vue / React）在构建完成后，本质上只是一些静态文件：

HTML
CSS
JavaScript
图片、字体等资源

这些文件的特点是：

不需要计算
不依赖 CPU
不需要内存
只需要被稳定、快速地下载

因此，前端页面本质上是一个：

“文件存储 + 文件分发”的问题，而不是计算问题。

三、把前端页面放在 EC2 上的缺点¶

如果将前端页面部署在 EC2 上，通常会带来以下问题：

1️⃣ 资源浪费¶

EC2 的 CPU / 内存被用于“发文件”
高价值的计算资源被低价值任务占用

2️⃣ 扩展性差¶

用户访问量上升 → 需要增加 EC2
增加 EC2 → 需要同步前端文件
运维复杂度和成本迅速上升

3️⃣ 稳定性受影响¶

EC2 宕机或重启 → 前端页面不可访问
后端服务异常 → 前端也被连带影响

📌 前端和后端被强行绑定在同一台服务器上，缺乏解耦。

四、S3 的定位：为静态资源而生¶

S3（Simple Storage Service）正是为这种场景设计的服务。

S3 的核心优势包括：

高可用（几乎不会宕机）
极高的数据持久性
支持超高并发访问
不需要管理服务器
成本低，按使用量付费

可以这样理解：

S3 是一个“专门用来存和发文件的云服务”。

五、S3 + CloudFront 是前端部署的最佳实践¶

在真实的生产环境中，前端几乎都会采用以下架构：

浏览器
  ↓
CloudFront（CDN）
  ↓
S3（静态文件）

这种架构的好处包括：

用户访问就近的 CDN 节点，速度更快
静态资源被缓存，减少源站压力
前端访问几乎不消耗 EC2 资源
系统整体稳定性更高

六、前后端解耦是现代 Web 架构的基础¶

当你将前端部署在 S3，将后端部署在 EC2 后，系统会自然形成三层结构：

前端：S3 + CloudFront
后端：EC2 + Nginx + Spring Boot
数据库：RDS

这种结构带来的好处是：

前端和后端可以独立部署、独立升级
前端访问量增加不会直接拖垮后端
系统更安全、更稳定
运维成本更低

七、一个直观的类比（帮助理解）¶

可以这样类比：

EC2 像是厨房里的厨师
S3 像是自助取餐柜

厨师（EC2）应该专心做菜（业务逻辑）
顾客（浏览器）从取餐柜（S3）直接取餐
没必要让厨师亲自端每一份餐点

八、小结（非常适合章节收尾）¶

前端页面本质上是静态文件分发问题，而 EC2 的核心价值在于计算和业务处理。
将前端页面部署在 S3，可以获得更高的稳定性、更低的成本和更好的扩展性。
因此，在现代云架构中，前端通常部署在 S3，而后端服务运行在 EC2 上，实现真正的前后端解耦。

下一阶段：RDS（数据库服务）
构建完整的三层云架构。