AWS 学习预备知识¶

本章目标：让零基础学员先理解传统项目的部署方式，再理解云计算与 AWS 的价值，从而为后续学习 EC2、S3、RDS、VPC 奠定基础。

传统 Web 项目是如何部署的？¶

在云计算出现之前，一个项目从开发到上线需要企业自己搭建服务器与机房。（理解云计算的起点）

传统部署需要的硬件设备¶

企业通常需要购买以下设备：

服务器主机（机架式服务器）
CPU、内存、硬盘等硬件资源
企业级交换机、防火墙
UPS 不断电系统
监控系统、消防系统
机房温控设备（空调）

这些都需要高额的前期投资。

自建机房的日常维护¶

保持机房恒温、湿度可控
网络专线维护与带宽管理
防火墙策略设置与硬件维护
硬盘损坏、服务器宕机需人工更换
服务器固件、安全补丁全部手动维护

项目上线流程（传统方式）¶

开发 → 打包（jar/war） → 上传服务器（FTP/SCP） → 手动重启服务 → 检查日志

特点：

操作繁琐
易出错
部署没有自动化

日常运维非常依赖人工¶

数据库备份需要运维人员手动执行
磁盘满了需要人工扩容
监控与报警系统需要人工搭建
服务器宕机时必须到机房抢修

传统部署模式成本高、风险大，这也是云计算出现的背景。

云计算如何改变这一切？¶

云计算让企业无需自建机房，无需购买实体服务器，而是租用云端的计算资源。

云计算的核心优势¶

按需付费：用多少付多少，无需提前购买硬件
自动扩缩容：访问量变大可自动新增服务器
稳定性更高：多可用区设计降低宕机风险
更快的部署速度：几分钟就能创建一台服务器
全球访问更快：CloudFront 的全球节点提供加速

传统部署 vs 云部署¶

对比项目	传统服务器	云计算（AWS）
成本	高	按使用量计费
扩容速度	慢，需要购买新设备	快速、自动化
部署复杂度	高，需要人工操作	自动化，高效率
全球访问速度	需要海外机房	CloudFront 全球加速
可靠性	容易宕机	多 AZ 高可用架构
运维成本	高	低，自动化程度高

云计算的三种服务模型¶

服务模式	说明	示例
IaaS	基础设施服务：服务器、网络	EC2、VPC、EBS
PaaS	平台服务：运行环境、部署环境	Elastic Beanstalk、RDS
SaaS	完整软件即服务	Gmail、Slack、Dropbox

在 AWS 学习中，我们会重点使用 IaaS + PaaS。

什么是云计算的服务模型？¶

云计算并不是单一形态，而是根据“云厂商替你处理多少工作”分为三个层次：

IaaS：基础设施即服务
PaaS：平台即服务
SaaS：软件即服务

层级越往上，云服务商帮你做的越多，你需要操心的越少。

IaaS（Infrastructure as a Service）——基础设施即服务¶

IaaS 是什么？¶

IaaS 提供最底层的云资源，包括：

虚拟机（服务器）
网络（VPC、子网、防火墙）
存储（硬盘、对象存储）
IP 地址、负载均衡等基础设施

本质上等同于： “把原来你自己机房里的服务器搬到云上，然后租给你用。”

IaaS 在 AWS 中的常见例子¶

EC2：云服务器
EBS：云硬盘
S3：对象存储
VPC：网络基础设施
ELB：负载均衡

IaaS 模式下你需要负责的内容¶

你负责：

安装系统（Linux/Windows 已预装，但其他软件需自己装）
安装运行环境（JDK、Node.js、Nginx、Python 等）
服务器安全组、防火墙配置
代码部署、日志处理、备份策略

云厂商负责：

机房、电力、空调、交换机
物理硬件维护与故障处理

总结一句话：
“硬件他们管，软件你自己搞。”

IaaS 适用场景¶

需要自由配置操作系统环境
希望完全掌控服务器
项目对运行环境要求复杂（特殊依赖、特定驱动）
团队有运维经验

PaaS（Platform as a Service）——平台即服务¶

PaaS 是什么？¶

PaaS 提供的是已经部署好运行环境的平台，你只需要：

上传代码
配置运行参数

无需关心：

操作系统补丁
Web 服务器安装
负载均衡与伸缩
服务器进程管理

本质上是：
“系统和环境他们帮你装好，你只管写代码。”

PaaS 在 AWS 中的典型例子¶

Elastic Beanstalk：上传代码即可部署
RDS：托管式数据库（无需安装 MySQL/PostgreSQL）
ECS Fargate：只需提供容器镜像，不需要管理服务器

PaaS 模式下你负责什么？¶

你负责：

写代码、上传代码
配少量环境变量
管理业务逻辑

云厂商负责：

自动扩容 / 缩容
配置运行环境
负载均衡
OS 更新、补丁、安全

一句话总结：
“你只管写代码，不管服务器。”

PaaS 适用场景¶

小团队、个人开发者（缺乏运维人员）
快速上线 Web 服务
不需要过高的环境自定义
想减少 DevOps 成本

SaaS（Software as a Service）——软件即服务¶

SaaS 是什么？¶

SaaS 提供已经做好的软件，你无需开发、不用部署：

打开网页
登录账号
直接使用

适用于：
“这类软件别人已经做得很好了，没必要自己造轮子。”

SaaS 常见示例（非 AWS 限定）¶

Gmail、Outlook（邮箱）
Slack、Teams（团队协作）
Salesforce（CRM）
Zoom、Google Meet（视频会议）
Notion、Confluence（知识库）

AWS 也提供 SaaS 化的产品¶

Amazon WorkMail（企业邮箱）
Amazon Chime（视频会议）

SaaS 模式下你负责什么？¶

你负责：

购买订阅
添加用户、设置权限
使用软件提供的功能

云厂商负责：

软件研发
运营与维护
安全、备份、监控

一句话总结：
“不用写代码，直接用成品软件。”

SaaS 适用场景¶

企业希望立即使用成熟系统
不愿或不需要投入开发资源
邮件系统、CRM、协作工具、工单系统等成熟领域

三者的直观类比¶

模型	类比	谁负责最多？	控制权
IaaS	自己买车开	用户	自由度最高
PaaS	坐出租车	云厂商负责驾驶	中等
SaaS	坐公交 / 高铁	云厂商全包	最低，但最省心

如何选择？¶

实际开发中常用组合：

服务器层：IaaS（EC2）或 PaaS（Beanstalk / Fargate）
数据库层：几乎全部选择 PaaS（RDS）
协作、邮件、工单等工具：优先 SaaS（减少开发成本）

全球基础架构¶

AWS 的基础设施采用分层设计：

全球 → 区域（Region）→ 可用区（AZ）→ 边缘节点（Edge）→ Local/Wavelength Zone

这种分层结构保证了：

高可用（High Availability）
高容错（Fault Tolerance）
低延迟（Low Latency）
全球覆盖（Global Reach）
弹性伸缩（Elasticity）

Region（区域）¶

AWS 在全球的独立地理位置

Region 是 AWS 在世界上部署的“地理区域”，每个 Region 都是一个完全独立的云环境。

示例：

ap-northeast-1（东京）
us-east-1（弗吉尼亚）
eu-central-1（法兰克福）

Region 的关键特性¶

1. 地理隔离¶

某个 Region 故障不会影响其他 Region。

例如：
东京区瘫痪不会影响北美区服务。

2. 数据法规要求（Data Sovereignty）¶

许多行业（金融/医疗/政府）要求数据必须存储在特定国家。

例如：

日本企业一般必须选东京区
欧洲企业需要选欧盟境内的 Region

3. 服务可用性不同¶

并非所有 AWS 服务在所有 Region 都能使用。

新服务通常先在 us-east-1 上线
在日本地区可能需要几个月后才开放

Availability Zone¶

（AZ，可用区）—— 高可用架构的核心

每个 Region 内包含多个 AZ（通常 3 个）。
每个 AZ 都是一个独立的数据中心集群，拥有：

独立的电力系统
独立的冷却系统
独立的网络线路
独立的物理安全措施

AZ 与 AZ 之间由高速低延迟链路连接。

AZ 的设计目的¶

1. 防止单点故障¶

一个 AZ 宕机不会导致整个 Region 宕机。

2. 支持高可用部署¶

常用做法：

EC2 放在多个 AZ
RDS 使用 Multi-AZ（主备切换）
ALB 自动将流量路由到健康 AZ

3. 支持容灾与负载均衡¶

可跨 AZ 构建多节点系统，提高可靠性。

Edge Location¶

（边缘节点）—— 全球 CDN 加速网络

Edge Location 是全球分布的“内容分发节点”。

用于：

静态资源加速
视频加速
API 加速
CloudFront CDN 缓存

Edge Location 的工作模式¶

用户访问时会自动连接最近的 Edge
Edge 若有缓存 → 直接返回（极快）
Edge 若无缓存 → 回源 S3/EC2，再缓存下来

Edge Location 的特点¶

全球数量远超 Region
提供极低延迟访问
不能运行 EC2（不是服务器）

简单理解： Edge Location 是 AWS 的全球高速缓存网络，提升全球访问速度。

Local Zone（本地区域）¶

更靠近用户的扩展区域

Local Zone 是 AWS 为某些城市提供的“本地化小区域”，用于：

提供比 Region 更近的计算资源
减少延迟
支持实时处理、渲染等高性能场景

Local Zone 特点¶

只有部分功能（EC2、EBS 等）
延迟极低
适用于：影视渲染、游戏服务器、实时应用

Wavelength Zone（运营商 5G 边缘区）¶

Wavelength 是 AWS 与 5G 运营商合作，将 AWS 服务部署到 移动网络核心网 中。

优势：

毫秒级超低延迟
专为 5G 终端设备设计
可用于自动驾驶 / XR / 实时监控等

适用场景：

物联网
移动边缘计算
高速实时应用

全球基础架构的整体结构（示意图）¶

World
 ├─ Region（区域）
 │     ├─ AZ1（可用区）
 │     ├─ AZ2（可用区）
 │     └─ AZ3（可用区）
 │
 ├─ Local Zones（本地区域）
 │
 └─ Edge Locations（边缘节点，用于 CDN 加速）

为什么 AWS 的基础架构是行业天花板？¶

1. 容错能力强¶

Region 之间独立
AZ 之间隔离
网络、电力多重冗余

2. 高可用性¶

多 AZ 部署
RDS 自动主备切换
ALB 健康检查自动路由

3. 全球加速¶

CloudFront 全球加速节点
Backbone 网络（AWS 自建高速骨干网）

4. 安全合规¶

严格的物理安全
合规认证（ISO、PCI、SOC）
数据隔离与加密

5. 高弹性¶

自动扩容系统（Auto Scaling）
Edge 缓存自动扩散

面试中的完美回答（简洁版）¶

AWS 全球基础架构由 Region、Availability Zone 和 Edge Location 组成。 Region 是独立的地理区域，提供完整的 AWS 服务；每个 Region 包含多个 AZ，AZ 之间物理隔离但高速互联，用于实现高可用与容灾。 Edge Location 则为 CloudFront 提供全球加速能力，提升用户访问速度。这种分布式结构使 AWS 在可靠性、性能和可用性方面达到全球领先水平。

VPC（Virtual Private Cloud）基础概念¶

你可以把 VPC 理解为你在 AWS 云上的“私人网络小区”。

里面可以建房子（服务器、数据库）
可以分区（子网）
可以设置门口和道路（IGW、路由表）
可以设置守卫（安全组、NACL）

没有 VPC，就无法使用 EC2、RDS 等核心服务。

子网（Subnet）¶

小区中的“分区”

VPC 是整个小区，子网就是小区里的不同区域。

公网子网（Public Subnet）¶

可以直接访问互联网
常用于放置 Web 服务器、负载均衡等

等同于小区中“开放的区域”。

私网子网（Private Subnet）¶

不能直接访问互联网
更安全
常用于数据库、缓存、内部服务

等同于小区中“封闭的居民区”。

路由表（Route Table）¶

小区的“道路指示牌”

路由表决定流量应该走向哪里。

例如：

local → 表示走 VPC 内部网络
0.0.0.0/0 → IGW → 表示去互联网

一个子网能否访问互联网，关键就在于路由表是否通过 IGW 指向公网。

Internet Gateway（IGW）¶

小区通往外网的“正门”

如果你希望：

EC2 可以访问互联网
互联网可以访问你的 EC2

那就要：

给子网绑定 IGW
在路由表添加 0.0.0.0/0 → IGW
并给 EC2 分配公有 IP

放在公网子网的服务器必须依赖 IGW 才能被外界访问。

NAT Gateway¶

小区内住户的“单向安全门”

私网子网不能访问互联网怎么办？

例如：

数据库需要下载补丁
后端服务器需要访问外部 API

这时候就需要 NAT Gateway。

NAT Gateway 的特点¶

私网服务器可以通过 NAT 访问互联网
互联网无法访问私网服务器（非常安全）

等同于：

小区的单向安全门：居民能出去，外人进不来。

安全组（Security Group）¶

房子的“门卫（白名单制）”

安全组是给 每台具体的服务器或数据库 配的“门卫”。

特点：

默认全部拒绝入站流量
你允许谁，谁才能进来
有状态（Stateful）
出去的请求，回来的流量自动允许

常见规则：

开 22 端口 → SSH 登录
开 80/443 → Web 服务
开 3306 → 后端服务连接数据库

安全组是 AWS 使用最频繁的安全配置。

NACL（网络访问控制列表）¶

小区外围大门的“岗哨（黑白名单）”

与安全组不同：

NACL 作用于“子网级别”
无状态（Stateless）
能允许，也能拒绝
需要配置入站 + 出站规则

常用于：

拦截恶意 IP
增加子网级别保护

但在真实项目中：

95% 的访问控制通过安全组完成，新手无需频繁操作 NACL。

最通俗易懂的 VPC 概念比喻总结¶

概念	小区类比	作用
VPC	整个小区	你在 AWS 上的私有网络
子网	小区区域	公共区（公网） vs 私密区（私网）
路由表	道路指示牌	指挥流量应该走到哪里
IGW	小区正门	进出互联网的主要通道
NAT	单向安全门	私密区可以出去，外人不能进来
安全组	房子门卫	控制谁能访问 EC2/RDS
NACL	小区外围岗哨	控制整个子网的进出流量

HTTP 与 Web 基础知识¶

请求与响应模型¶

浏览器向服务器发送 HTTP Request
服务器返回 HTTP Response

常见方法：

GET：查询
POST：提交
PUT：更新
DELETE：删除

一体式开发 vs 前后端分离¶

一体式架构（Monolithic）¶

前端和后端都放在同一服务器上。
适用于：Laravel、Django、Spring MVC

前后端分离部署¶

前端 Vue/React → S3 + CloudFront
后端 API（Spring Boot / Python）→ EC2 / Lambda / ECS

现代 Web 系统几乎全部采用分离式架构。

学习 AWS 需要掌握的基础技能¶

基本 Linux 命令（ls, cd, vi, yum, apt）
SSH 登录服务器
HTML/CSS/JavaScript 基础
API、JSON 的基本认知

本章小结¶

云计算解决了传统部署模式的所有核心痛点
AWS 是当前最主流的云平台，学习门槛低、收益高
Region → AZ → VPC → Subnet 构成 AWS 的核心结构
前后端分离架构最适合云部署
掌握基础 Linux 和 Web 常识会让学习 AWS 更顺畅

AWS 学习预备知识¶

传统 Web 项目是如何部署的？¶

传统部署需要的硬件设备¶

自建机房的日常维护¶

项目上线流程（传统方式）¶

日常运维非常依赖人工¶

云计算如何改变这一切？¶

云计算的核心优势¶

传统部署 vs 云部署¶

云计算的三种服务模型¶

什么是云计算的服务模型？¶

IaaS（Infrastructure as a Service）——基础设施即服务¶

IaaS 是什么？¶

IaaS 在 AWS 中的常见例子¶

IaaS 模式下你需要负责的内容¶

IaaS 适用场景¶

PaaS（Platform as a Service）——平台即服务¶

PaaS 是什么？¶

PaaS 在 AWS 中的典型例子¶

PaaS 模式下你负责什么？¶

PaaS 适用场景¶

SaaS（Software as a Service）——软件即服务¶

SaaS 是什么？¶

SaaS 常见示例（非 AWS 限定）¶

AWS 也提供 SaaS 化的产品¶

SaaS 模式下你负责什么？¶

SaaS 适用场景¶

三者的直观类比¶

如何选择？¶

全球基础架构¶

Region（区域）¶

Region 的关键特性¶

1. 地理隔离¶

2. 数据法规要求（Data Sovereignty）¶

3. 服务可用性不同¶

Availability Zone¶

AZ 的设计目的¶

1. 防止单点故障¶

2. 支持高可用部署¶

3. 支持容灾与负载均衡¶

Edge Location¶

Edge Location 的工作模式¶

Edge Location 的特点¶

Local Zone（本地区域）¶

Local Zone 特点¶

Wavelength Zone（运营商 5G 边缘区）¶

全球基础架构的整体结构（示意图）¶

为什么 AWS 的基础架构是行业天花板？¶

1. 容错能力强¶

2. 高可用性¶

3. 全球加速¶

4. 安全合规¶

5. 高弹性¶

面试中的完美回答（简洁版）¶

VPC（Virtual Private Cloud） 基础概念¶

子网（Subnet）¶

公网子网（Public Subnet）¶

私网子网（Private Subnet）¶

路由表（Route Table）¶

Internet Gateway（IGW）¶

NAT Gateway¶

NAT Gateway 的特点¶

安全组（Security Group）¶

NACL（网络访问控制列表）¶

最通俗易懂的 VPC 概念比喻总结¶

HTTP 与 Web 基础知识¶

请求与响应模型¶

一体式开发 vs 前后端分离¶

一体式架构（Monolithic）¶

前后端分离部署¶

学习 AWS 需要掌握的基础技能¶

本章小结¶

VPC（Virtual Private Cloud）基础概念¶