all

课程/第一阶段-云计算基础/第01天-什么是云计算.md

@@ -0,0 +1,178 @@
+# 第1天：什么是云计算——从租房子说起
+
+## 今天你将学到什么
+
+今天是你 AWS 学习之旅的第一天。我们不急着碰任何技术工具，而是先搞清楚一个最基本的问题：**云计算到底是什么？它为什么会存在？**
+
+读完今天的内容，你会明白：
+- 云计算用大白话怎么解释
+- 它解决了什么痛点
+- 为什么全世界的公司都在"上云"
+
+---
+
+## 先讲一个故事
+
+2006 年，美国有一家小公司叫 Animoto，做的是自动把照片生成视频的服务。上线第三天，突然被一个科技博客推荐了，用户从 5 万人暴涨到 75 万人。
+
+如果他们自己买服务器，光是下单采购就要等 4-6 周，等服务器到货再装系统、部署应用，用户早就跑光了。
+
+但他们用了亚马逊刚推出的云服务（EC2），三天之内从 50 台虚拟服务器扩展到了 3500 台，平稳扛住了流量洪峰。等热度过去，他们又把多余的服务器"还"了回去，不用再为闲置的机器付钱。
+
+这就是云计算最直观的价值。
+
+---
+
+## 用租房子来理解云计算
+
+想象你刚到一个新城市工作，你需要一个住的地方。你有三个选择：
+
+### 选择一：自己买地盖房子（传统 IT）
+
+- 买地皮（买服务器硬件）
+- 请建筑队盖房子（搭建机房、布线、装空调）
+- 装修入住（安装操作系统、部署应用）
+- 自己修水管、换灯泡、交物业费（日常运维）
+
+**问题**：
+- 前期投入巨大（几十万甚至上百万）
+- 从决定到入住要好几个月
+- 如果你只住两年就换城市了，房子卖不卖得掉是个问题
+- 房子大小是固定的——来了 10 个朋友住不下，平时又空着好几间房
+
+### 选择二：租房子（云计算）
+
+- 打开手机 APP，选好户型和位置
+- 今天签约，明天入住
+- 住一个月付一个月的钱
+- 朋友来了可以临时加一间，走了就退掉
+- 水管坏了打电话给房东，不用自己修
+
+**这就是云计算的本质**：
+- 不用买硬件，按需租用
+- 几分钟就能用上
+- 用多少付多少
+- 需要更多随时加，不需要随时减
+- 底层维护别人负责
+
+---
+
+## 官方定义（了解即可）
+
+美国国家标准与技术研究院（NIST）的定义：
+
+> 云计算是一种模型，它能够通过网络以便捷、按需的方式访问一个共享的可配置计算资源池，这些资源可以快速供应和释放，只需最少的管理工作。
+
+翻译成人话：**通过网络，像用水用电一样使用计算机资源。**
+
+---
+
+## 云计算的五个特征
+
+用生活中的例子来理解：
+
+### 1. 按需自助服务
+
+就像自动售货机——你想要什么，自己按按钮就行，不需要找人帮忙。
+
+在 AWS 上，你想要一台服务器，点几下鼠标，2 分钟后就有了。不需要打电话给谁审批，不需要等采购流程。
+
+### 2. 广泛的网络访问
+
+就像自来水——只要有水龙头的地方就能用水。
+
+只要有网络，你就能从任何地方、任何设备访问你的云资源。在家用笔记本、在公司用台式机、在路上用手机，都行。
+
+### 3. 资源池化
+
+就像公寓楼——很多住户共享同一栋楼的地基、电梯、管道，但每户有自己独立的空间。
+
+云服务商的物理服务器被很多客户共享，但每个客户的数据和环境是隔离的，互不影响。
+
+### 4. 快速弹性
+
+就像橡皮筋——需要多长拉多长，松手就弹回去。
+
+双十一流量暴涨 10 倍？自动加服务器。活动结束流量回落？自动减掉。你不需要提前猜测需要多少资源。
+
+### 5. 可计量服务
+
+就像电表——用了多少度电，付多少钱。
+
+云计算按你实际使用的量计费：用了多少小时的服务器、存了多少 GB 的数据、传输了多少流量，精确到分钟甚至秒。
+
+---
+
+## 没有云计算之前，企业有多痛苦
+
+让我用一个真实场景来说明。
+
+假设你是一家电商公司的技术负责人，要上线一个新的促销系统：
+
+**第 1 步：评估容量**（2 周）
+你需要猜测未来 3 年的峰值流量。猜少了系统会崩，猜多了钱就浪费了。但谁能准确预测 3 年后的事呢？
+
+**第 2 步：采购审批**（2-4 周）
+写采购申请、找领导签字、走财务流程、比价、招标...
+
+**第 3 步：等待交付**（4-8 周）
+服务器厂商生产、发货、物流...
+
+**第 4 步：机房部署**（2-4 周）
+上架、布线、装系统、配网络、测试...
+
+**总计：3-5 个月**
+
+而你的竞争对手用云计算，从想法到上线只需要**几天**。
+
+---
+
+## 云计算的发展简史
+
+- **2002 年**：亚马逊内部开始把基础设施做成服务（因为他们自己的电商业务需要）
+- **2006 年**：AWS 正式对外推出 S3（存储）和 EC2（计算），云计算时代正式开启
+- **2008 年**：Google 推出 App Engine
+- **2010 年**：微软 Azure 正式商用
+- **2013 年**：Docker 容器技术发布，让应用打包和部署更简单
+- **2014 年**：AWS 推出 Lambda，"无服务器"计算诞生
+- **2020 年后**：疫情加速了全球企业上云的进程
+
+---
+
+## 为什么我们选择学 AWS
+
+全球有很多云服务商：AWS（亚马逊）、Azure（微软）、GCP（谷歌）、阿里云、腾讯云等。我们选 AWS 学习，原因是：
+
+**市场份额最大**：全球约 31% 的市场份额，意味着最多的工作机会。
+
+**服务最全**：200 多种服务，从计算、存储到人工智能、卫星通信，几乎覆盖所有场景。
+
+**学习资源最丰富**：官方文档质量高，社区活跃，中英文资料都很多。
+
+**认证体系完善**：AWS 认证是云计算领域最被认可的证书之一。
+
+**先学 AWS，再学其他云会很快**——因为核心概念是相通的，只是界面和名称不同。
+
+---
+
+## 今天的小测验（自我检查）
+
+1. 用你自己的话解释：什么是云计算？
+2. 云计算的"按需"和"弹性"分别是什么意思？
+3. 为什么说云计算像"租房子"而不是"买房子"？
+4. 在没有云计算的时代，企业上线一个新系统大概需要多久？
+
+如果你能回答这四个问题，今天的内容就掌握了。
+
+---
+
+## 延伸阅读
+
+- [AWS 官方：什么是云计算](https://aws.amazon.com/what-is-cloud-computing/)
+- [NIST 云计算定义（SP 800-145）](https://csrc.nist.gov/publications/detail/sp/800-145/final)
+
+---
+
+## 明天预告
+
+明天我们学习云计算的三种"套餐"：IaaS、PaaS、SaaS。用点外卖的例子，搞清楚"你管什么，云管什么"这个核心问题。

课程/第一阶段-云计算基础/第02天-三种服务模型.md

@@ -0,0 +1,222 @@
+# 第2天：IaaS、PaaS、SaaS——三种云服务套餐
+
+## 今天你将学到什么
+
+昨天我们知道了云计算是"租用计算资源"。但租也有不同的租法——就像你可以租一间毛坯房自己装修，也可以租一间精装房拎包入住。
+
+今天学完，你会明白：
+- 三种服务模型各自包含什么
+- 你和云服务商各自负责什么（这个非常重要）
+- 什么场景该选哪种模型
+
+---
+
+## 用吃饭来理解三种模型
+
+假设你想吃一顿饭，有这么几种方式：
+
+### 方式一：自己从头做（传统自建 IT）
+
+你需要：
+- 自己种菜养鸡（买硬件）
+- 自己砌灶台接水电（搭建机房）
+- 自己买锅碗瓢盆（安装操作系统和中间件）
+- 自己做菜（开发应用）
+- 自己洗碗收拾（日常运维）
+
+一切都是你的，一切也都要你操心。
+
+### 方式二：租一个厨房 = IaaS
+
+有人提供了一个设备齐全的厨房（燃气灶、冰箱、水电都通了），你只需要：
+- 自己买食材（安装操作系统和软件）
+- 自己做菜（部署应用）
+- 自己洗碗（运维）
+
+厨房坏了房东修，但做什么菜、怎么做，完全由你决定。
+
+### 方式三：去餐厅吃自助 = PaaS
+
+餐厅提供了食材、厨具、调料，甚至有半成品。你只需要：
+- 选择食材组合
+- 简单加工一下
+- 享用
+
+你不用管厨房怎么运转，专注于"做出好吃的菜"就行。
+
+### 方式四：点外卖 = SaaS
+
+打开手机，选好菜品，付款，等送到，打开盒子就吃。
+
+你什么都不用管，直接享受最终成果。但你也没法要求外卖店按你的独特口味来做。
+
+---
+
+## 正式定义
+
+### IaaS（Infrastructure as a Service）基础设施即服务
+
+云服务商提供最底层的东西：虚拟机、网络、存储。相当于给你一台"裸机"，上面装什么、跑什么，你自己决定。
+
+**AWS 上的 IaaS 代表**：
+- EC2 — 虚拟服务器（相当于一台远程电脑）
+- VPC — 虚拟网络（相当于你自己的局域网）
+- EBS — 虚拟硬盘
+
+**生活类比**：租了一间空房子，水电通了，但家具、装修、生活用品都要自己搞。
+
+**你需要负责**：
+- 选择和安装操作系统（Windows 还是 Linux）
+- 安装运行环境（Java、Python、Node.js 等）
+- 部署你的应用程序
+- 打安全补丁、做备份、监控运行状态
+
+**适合谁**：
+- 需要完全控制服务器环境的团队
+- 要运行特殊软件或特定操作系统版本的场景
+- 把现有系统原封不动搬到云上（叫"Lift and Shift"）
+
+---
+
+### PaaS（Platform as a Service）平台即服务
+
+云服务商不仅提供硬件，还帮你把运行环境都搭好了。你只需要把代码丢上去，它就能跑。
+
+**AWS 上的 PaaS 代表**：
+- Elastic Beanstalk — 你上传代码，它自动帮你配置服务器、负载均衡、自动扩展
+- RDS — 托管数据库，你不用装 MySQL，直接用
+- Lambda — 你只写一个函数，连服务器都不需要
+
+**生活类比**：住进了精装修的公寓，家具家电齐全，你只需要带上个人物品（你的代码）就能生活。
+
+**你需要负责**：
+- 写代码
+- 管理你的数据
+- 设置用户权限
+
+**不需要你管的**：
+- 操作系统更新
+- 服务器扩容
+- 硬件故障处理
+- 网络配置
+
+**适合谁**：
+- 想专注于写代码，不想管服务器的开发者
+- 快速上线原型或 MVP（最小可行产品）
+- 小团队，没有专职运维人员
+
+---
+
+### SaaS（Software as a Service）软件即服务
+
+云服务商提供完整的应用程序，你通过浏览器或 APP 直接使用。
+
+**日常生活中的 SaaS**（你可能天天在用）：
+- Gmail / Outlook — 邮箱
+- 微信 / Slack — 通讯
+- 腾讯文档 / Google Docs — 在线文档
+- Zoom — 视频会议
+- Notion — 笔记和项目管理
+
+**AWS 上的 SaaS 代表**：
+- Amazon WorkMail — 企业邮箱
+- Amazon Chime — 视频会议
+
+**生活类比**：住酒店。你什么都不用管，拎包入住，退房走人。但你不能改房间的装修风格。
+
+**你需要负责**：
+- 管理你的账号和数据内容
+- 就这些
+
+**适合谁**：
+- 标准化的需求（邮箱、文档、会议）
+- 不需要任何技术背景就能使用
+- 想要零运维
+
+---
+
+## 一张图看清责任边界
+
+这是 AWS 最重要的概念之一——**共享责任模型**。
+
+想象一栋楼有 8 层，从底到顶分别是：
+
+| 层级 | 自己建 | IaaS | PaaS | SaaS |
+|------|--------|------|------|------|
+| 8. 你的数据 | 你管 | 你管 | 你管 | 你管 |
+| 7. 你的应用程序 | 你管 | 你管 | 你管 | **云管** |
+| 6. 运行环境 | 你管 | 你管 | **云管** | **云管** |
+| 5. 操作系统 | 你管 | 你管 | **云管** | **云管** |
+| 4. 虚拟化层 | 你管 | **云管** | **云管** | **云管** |
+| 3. 服务器硬件 | 你管 | **云管** | **云管** | **云管** |
+| 2. 网络设备 | 你管 | **云管** | **云管** | **云管** |
+| 1. 物理机房 | 你管 | **云管** | **云管** | **云管** |
+
+**关键记忆点**：越往上（SaaS 方向），你操心的事越少，但灵活度也越低。
+
+AWS 官方的总结非常精辟：
+> **AWS 负责"云的安全"，你负责"云中的安全"。**
+
+意思是：机房不会着火、硬件不会被偷，这是 AWS 的责任。但你的数据库密码设成了 123456 被黑客攻破，那是你的责任。
+
+---
+
+## 真实场景：一个创业公司的选择
+
+小明要做一个在线教育网站，他的团队只有 3 个人。来看看不同阶段他会怎么选：
+
+**阶段一：验证想法（1-2 周）**
+- 用 WordPress（SaaS）快速搭建一个课程展示页面
+- 用腾讯文档（SaaS）管理课程内容
+- 成本：几乎为零
+
+**阶段二：开发 MVP（1-2 月）**
+- 用 Elastic Beanstalk（PaaS）部署后端 API
+- 用 RDS（PaaS）托管数据库
+- 用 S3 存储视频文件
+- 成本：每月几十美元
+- 好处：不用管服务器，专注写代码
+
+**阶段三：规模化（半年后）**
+- 用 EC2（IaaS）运行自定义的视频转码服务
+- 用 ECS（容器服务）部署微服务架构
+- 用 CloudFront（CDN）加速全球视频播放
+- 成本：每月几千美元
+- 原因：业务复杂了，需要更多控制权
+
+你看，**不是选一种就一直用一种**，实际项目中往往是混合使用。
+
+---
+
+## 常见误解澄清
+
+**误解 1："用了 PaaS/SaaS 就不需要技术人员了"**
+不对。PaaS 减少了运维工作，但你仍然需要人写代码、设计架构、处理业务逻辑。
+
+**误解 2："IaaS 最灵活所以最好"**
+灵活意味着你要管更多的事。如果你的团队只有 2 个开发者，没有运维，用 IaaS 反而会被运维工作拖垮。
+
+**误解 3："三种模型是互斥的"**
+不是。一个项目可以同时用 EC2（IaaS）跑核心服务，用 RDS（PaaS）管数据库，用 Gmail（SaaS）收发邮件。
+
+---
+
+## 今天的小测验
+
+1. 如果你想完全控制服务器的操作系统和配置，应该选哪种模型？
+2. 一个没有运维人员的 3 人创业团队，推荐用哪种模型起步？
+3. "共享责任模型"的核心意思是什么？
+4. 举一个你日常生活中使用的 SaaS 产品的例子。
+
+---
+
+## 延伸阅读
+
+- [AWS 共享责任模型](https://aws.amazon.com/compliance/shared-responsibility-model/)
+- [NIST 云计算参考架构](https://www.nist.gov/publications/nist-cloud-computing-reference-architecture)
+
+---
+
+## 明天预告
+
+明天我们聊"部署模型"：公有云、私有云、混合云。为什么有些公司不把所有东西都放到公有云上？银行的数据和你的个人博客，对云的需求有什么不同？

课程/第一阶段-云计算基础/第03天-公有云私有云混合云.md

@@ -0,0 +1,180 @@
+# 第3天：公有云、私有云、混合云——数据放哪里
+
+## 今天你将学到什么
+
+昨天我们学了云计算的三种"套餐"（IaaS/PaaS/SaaS）。今天换一个角度：这些云资源部署在哪里？谁能用？
+
+学完今天的内容，你会明白：
+- 三种部署模型的区别
+- 为什么不是所有公司都用公有云
+- 什么是混合云，为什么它是大多数企业的现实选择
+
+---
+
+## 用停车来理解部署模型
+
+### 公有云 = 公共停车场
+
+- 谁都能来停车
+- 按小时收费
+- 车位多，基本不用担心没位置
+- 停车场的安保、清洁、维护都是物业负责
+- 但你的车和别人的车停在同一个场地里（逻辑隔离，不是物理隔离）
+
+### 私有云 = 自家车库
+
+- 只有你自己能用
+- 前期投入大（要买地、建车库）
+- 完全由你控制（想装监控就装监控，想加锁就加锁）
+- 但车位有限，来了太多客人就停不下
+
+### 混合云 = 自家车库 + 公共停车场
+
+- 平时自己的车停车库
+- 来客人了或者过年车多了，溢出的车停公共停车场
+- 两边都用，灵活调配
+
+---
+
+## 公有云（Public Cloud）详解
+
+公有云是由云服务商（如 AWS、Azure、阿里云）拥有和运营的，通过互联网向所有人提供服务。
+
+**你可能会问：公有云安全吗？"公有"是不是意味着别人能看到我的数据？**
+
+答案是：**不会**。"公有"指的是服务对公众开放，不是数据对公众开放。就像公共停车场，虽然大家都能来停车，但你的车别人开不走（有锁）。AWS 通过虚拟化技术确保每个客户的数据完全隔离。
+
+**公有云的优势**：
+- 零前期投入——注册账号就能用，不用买任何硬件
+- 全球覆盖——AWS 在全球 30 多个地区有数据中心
+- 无限弹性——理论上你想用多少资源就有多少
+- 持续创新——云服务商每年推出几百个新功能
+
+**公有云的顾虑**：
+- 数据存在别人的机器上，某些行业法规不允许
+- 长期稳定运行的系统，成本可能比自建高
+- 依赖网络连接，断网就用不了
+
+**代表**：AWS、Microsoft Azure、Google Cloud、阿里云、腾讯云
+
+---
+
+## 私有云（Private Cloud）详解
+
+私有云是专属于一个组织的云基础设施。可以建在自己的机房里，也可以让第三方托管，但资源不与其他组织共享。
+
+**什么样的组织需要私有云？**
+
+举几个例子：
+
+**银行**：监管要求客户的金融数据必须存储在特定的物理位置，不能和其他公司的数据混在一起。
+
+**军事机构**：涉及国家安全的数据，绝对不能放在商业云服务商的服务器上。
+
+**大型工厂**：生产线的控制系统需要毫秒级响应，不能依赖互联网连接（万一断网，生产线就停了）。
+
+**私有云的优势**：
+- 完全控制数据的物理位置
+- 满足最严格的合规要求
+- 网络延迟最低（数据就在本地）
+- 可以针对特定需求深度定制
+
+**私有云的劣势**：
+- 前期投入巨大（买服务器、建机房、招运维团队）
+- 弹性有限（服务器就那么多，用完了就得再买）
+- 技术更新慢（新硬件采购周期长）
+- 需要专业的运维团队 7×24 小时值守
+
+**代表方案**：VMware vSphere、OpenStack、AWS Outposts（把 AWS 硬件放到你的机房）
+
+---
+
+## 混合云（Hybrid Cloud）详解
+
+混合云是公有云和私有云（或本地数据中心）的组合，数据和应用可以在两者之间流动。
+
+**这是目前大多数企业的真实选择。**
+
+为什么？因为现实世界不是非黑即白的：
+- 有些数据必须留在本地（合规要求）
+- 有些业务需要弹性扩展（促销活动）
+- 已经花了几个亿建的数据中心不可能一夜废弃
+
+**混合云的典型场景**：
+
+**场景一：核心在本地，分析在云上**
+银行的核心交易系统留在自己的数据中心（合规要求），但把交易数据的副本发到 AWS 上做大数据分析和 AI 模型训练（需要大量计算资源，临时用完就释放）。
+
+**场景二：平时在本地，高峰溢出到云上（Cloud Bursting）**
+一个电商网站平时用自己的服务器就够了，但双十一流量暴涨 10 倍，临时把多出来的流量导到 AWS 上处理，活动结束后释放。
+
+**场景三：开发在云上，生产在本地**
+开发和测试环境放在公有云上（灵活、便宜），但生产环境跑在自己的数据中心（安全、合规）。
+
+**AWS 提供的混合云方案**：
+- **AWS Outposts** — 把 AWS 的硬件和软件放到你的机房里，体验和公有云一样
+- **AWS Direct Connect** — 你的机房和 AWS 之间拉一根专线，不走公网
+- **AWS Storage Gateway** — 本地存储和 S3 无缝对接
+
+---
+
+## 还有一种：多云（Multi-Cloud）
+
+有些大企业同时使用多个公有云服务商。比如：
+- 主要业务在 AWS 上
+- AI/机器学习用 Google Cloud（因为 TensorFlow 生态好）
+- 办公系统用 Azure（因为和微软 Office 集成好）
+
+**为什么要多云？**
+- 避免被一家供应商"绑架"（万一涨价或服务中断呢）
+- 利用各家的优势服务
+- 满足不同地区的合规要求
+
+**多云的代价**：
+- 运维复杂度翻倍（每个云的操作方式都不一样）
+- 需要更多技术人才
+- 跨云数据传输有成本
+
+---
+
+## 怎么选？一张决策表
+
+| 你的情况 | 推荐选择 |
+|----------|----------|
+| 创业公司，预算有限，需要快速上线 | 公有云 |
+| 大企业，有严格的数据合规要求 | 混合云 |
+| 政府/军事，数据绝对不能外泄 | 私有云 |
+| 流量波动大，需要弹性 | 公有云或混合云 |
+| 已有大量本地基础设施投入 | 混合云（逐步迁移） |
+
+---
+
+## 真实案例
+
+**Netflix（全面公有云）**：
+Netflix 从 2008 年开始把所有服务迁移到 AWS，花了 7 年完成。他们的逻辑很简单："我们的核心竞争力是内容和推荐算法，不是运维数据中心。把运维交给 AWS，我们专注做好内容。"
+
+**某大型银行（混合云）**：
+核心银行系统（存款、转账）留在自己的数据中心，因为监管要求。但手机银行 APP 的前端、营销活动页面、数据分析平台都放在公有云上，因为这些需要快速迭代和弹性扩展。
+
+---
+
+## 今天的小测验
+
+1. "公有云"的"公有"是什么意思？是不是数据对所有人公开？
+2. 银行为什么不能把所有系统都放在公有云上？
+3. 什么是"Cloud Bursting"？举一个场景。
+4. 一个 5 人创业团队应该选公有云还是私有云？为什么？
+
+---
+
+## 延伸阅读
+
+- [AWS 混合云解决方案](https://aws.amazon.com/hybrid/)
+- [Netflix 迁移到 AWS 的故事](https://about.netflix.com/en/news/completing-the-netflix-cloud-migration)
+
+---
+
+## 明天预告
+
+明天我们进入 AWS 的物理世界：Region（区域）、可用区（AZ）、边缘节点。AWS 在全球建了这么多数据中心，它们是怎么组织的？你的数据到底存在哪里？这直接影响你的应用速度和可靠性。

课程/第一阶段-云计算基础/第04天-AWS全球基础设施.md

@@ -0,0 +1,184 @@
+# 第4天：AWS 全球基础设施——你的数据存在哪里
+
+## 今天你将学到什么
+
+今天我们来看 AWS 在全球的"地盘"是怎么布局的。这不是纯理论——它直接决定了：
+- 你的用户访问速度快不快
+- 你的系统能不能扛住灾难
+- 你的数据是否满足法律要求
+
+学完今天，你会明白 Region、可用区、边缘节点这三个概念，以及怎么选择它们。
+
+---
+
+## 先想一个问题
+
+假设你在北京开了一家网店，服务器放在北京。那么：
+- 北京的用户访问你的网站：很快（几十毫秒）
+- 上海的用户访问：还行（稍微慢一点）
+- 美国的用户访问：很慢（数据要跨越太平洋，几百毫秒）
+
+如果你想让全球用户都快，怎么办？**在全球多个地方都放服务器。**
+
+这就是 AWS 全球基础设施要解决的问题。
+
+---
+
+## 三层结构：Region → 可用区 → 边缘节点
+
+想象一个连锁酒店品牌：
+
+- **Region（区域）** = 酒店在不同城市的分店（北京店、上海店、东京店）
+- **可用区（AZ）** = 同一城市内的多个酒店大楼（北京朝阳店、北京海淀店）
+- **边缘节点（Edge Location）** = 散布在各处的快递柜（方便就近取件）
+
+---
+
+## Region（区域）
+
+Region 是 AWS 在全球某个地理位置的一组数据中心集群。
+
+截至 2024 年，AWS 在全球有 **33 个 Region**，分布在美洲、欧洲、亚太、中东、非洲。
+
+**Region 的命名规则**：`地区-方位-编号`
+
+举几个例子：
+| 代号 | 位置 | 常用场景 |
+|------|------|----------|
+| us-east-1 | 美国东部（弗吉尼亚） | AWS 最老最全的区域，新服务最先上线 |
+| ap-northeast-1 | 亚太（东京） | 服务日本和东亚用户 |
+| ap-southeast-1 | 亚太（新加坡） | 服务东南亚用户 |
+| eu-west-1 | 欧洲（爱尔兰） | 服务欧洲用户 |
+| cn-north-1 | 中国（北京） | 中国大陆用户（独立运营） |
+
+**每个 Region 是完全独立的**：
+- 数据不会自动从一个 Region 跑到另一个 Region
+- 你在东京创建的服务器，在弗吉尼亚是看不到的
+- 这是为了数据主权——你的数据留在你选择的地方
+
+### 选 Region 要考虑什么？
+
+**举个例子**：你要做一个面向中国用户的电商网站。
+
+| 考虑因素 | 分析 | 结论 |
+|----------|------|------|
+| 用户在哪 | 用户在中国 | 选中国区域或离中国近的（东京、新加坡） |
+| 法律要求 | 中国法律要求某些数据存储在境内 | 必须选 cn-north-1 或 cn-northwest-1 |
+| 服务可用性 | 某些新服务可能还没在中国区上线 | 需要确认你要用的服务是否可用 |
+| 价格 | 不同 Region 价格不同 | 弗吉尼亚最便宜，亚太和南美较贵 |
+
+**小贴士**：如果没有特殊要求，学习阶段建议用 `us-east-1`（弗吉尼亚），因为它服务最全、价格最低、教程最多。
+
+---
+
+## 可用区（Availability Zone，简称 AZ）
+
+每个 Region 里面有 **3 个或更多可用区**。每个可用区是一个或多个独立的数据中心。
+
+**为什么一个 Region 要有多个可用区？**
+
+用一个故事来解释：
+
+假设你开了一家面包店，所有的烤箱都在同一栋楼里。如果这栋楼停电了、着火了、或者被水淹了，你的整个生意就停了。
+
+但如果你在同一个城市的不同地方开了 3 家分店，每家都能独立运营。即使一家店出了问题，另外两家还能继续卖面包。
+
+**可用区就是这个道理**：
+
+- 每个 AZ 有独立的电力供应（不同的变电站）
+- 每个 AZ 有独立的网络连接
+- 每个 AZ 有独立的制冷系统
+- AZ 之间物理距离足够远（通常几十公里），避免同一场自然灾害同时影响多个 AZ
+- 但 AZ 之间通过高速专用光纤连接，延迟极低（< 2 毫秒）
+
+**这意味着什么？**
+
+如果你把应用部署在同一个 Region 的 2-3 个 AZ 中，即使一个数据中心完全瘫痪（火灾、地震、断电），你的服务依然正常运行。用户甚至感觉不到。
+
+**这就是 AWS 高可用架构的基石。**
+
+---
+
+## 边缘节点（Edge Location）
+
+AWS 在全球有 **600 多个边缘节点**，分布在各大城市。
+
+**边缘节点是干什么的？**
+
+还是用例子说明：
+
+你在东京有一台服务器，上面放着你网站的图片和视频。一个巴西的用户要看你的网站，数据要从东京传到巴西，跨越半个地球，需要 200-300 毫秒。
+
+但如果你把这些图片和视频提前"复制"一份到巴西的边缘节点，巴西用户直接从本地的边缘节点获取，只需要 10-20 毫秒。
+
+**边缘节点主要服务于**：
+- **CloudFront（CDN）**：缓存网站的静态内容（图片、视频、CSS、JS），让全球用户就近获取
+- **Route 53（DNS）**：就近解析域名，加快网站打开速度
+- **AWS WAF**：在边缘拦截恶意攻击，坏流量根本到不了你的服务器
+
+---
+
+## 三者的关系总结
+
+```
+全球
+├── Region: 美国东部 (us-east-1)
+│   ├── 可用区 A (us-east-1a) — 数据中心群 1
+│   ├── 可用区 B (us-east-1b) — 数据中心群 2
+│   ├── 可用区 C (us-east-1c) — 数据中心群 3
+│   └── ...更多 AZ
+├── Region: 亚太东京 (ap-northeast-1)
+│   ├── 可用区 A
+│   ├── 可用区 B
+│   └── 可用区 C
+├── ...更多 Region
+│
+└── 边缘节点（600+，遍布全球各大城市）
+    ├── 北京
+    ├── 上海
+    ├── 东京
+    ├── 纽约
+    ├── 伦敦
+    └── ...
+```
+
+**记住一个口诀**：
+- **用 AZ 实现高可用**（一个机房挂了，另一个顶上）
+- **用 Region 实现灾难恢复**（一个地区出大问题，切换到另一个地区）
+- **用边缘节点实现低延迟**（内容推到用户身边）
+
+---
+
+## 一个真实的故障案例
+
+2017 年 2 月 28 日，AWS 美国东部（us-east-1）的 S3 存储服务发生了大规模故障，持续约 4 小时。
+
+受影响的知名服务包括：Slack、Trello、Quora，甚至 AWS 自己的状态页面都挂了（因为状态页面也托管在 S3 上）。
+
+**教训**：
+- 即使是 AWS 自己的服务也会出故障
+- 不要把所有东西都放在一个 Region
+- 关键业务要考虑多 Region 部署
+- 你的架构要能容忍底层服务的故障
+
+---
+
+## 今天的小测验
+
+1. 如果你的用户主要在日本，应该选哪个 Region？
+2. 为什么一个 Region 要有多个可用区？用你自己的话解释。
+3. 边缘节点和 Region 有什么区别？它们各自解决什么问题？
+4. 如果你只把应用部署在一个可用区，会有什么风险？
+
+---
+
+## 延伸阅读
+
+- [AWS 全球基础设施地图（可交互）](https://aws.amazon.com/about-aws/global-infrastructure/)
+- [AWS 2017 年 S3 故障复盘报告](https://aws.amazon.com/message/41926/)
+
+---
+
+## 明天预告
+
+明天我们动手了！注册 AWS 账户、设置安全保护、配置账单告警。正式踏入 AWS 的大门。我会一步步带你操作，确保你不会踩坑（尤其是不会被意外扣费）。

课程/第一阶段-云计算基础/第05天-注册账户与安全配置.md

@@ -0,0 +1,226 @@
+# 第5天：注册 AWS 账户与安全配置
+
+## 今天你将学到什么
+
+今天我们正式动手！注册一个 AWS 账户，并做好最重要的安全配置。
+
+我会特别提醒你那些**新手最容易踩的坑**（尤其是被意外扣费的坑），确保你安全地开始学习之旅。
+
+---
+
+## 注册前的准备
+
+你需要准备以下东西：
+
+1. **一个邮箱**：建议用专门的邮箱（比如 Gmail），不要用公司邮箱
+2. **一张信用卡或借记卡**：Visa 或 MasterCard（国内的双币卡也行）
+   - AWS 会预扣 $1 美元验证卡片有效性，之后会退还
+   - 在免费额度内使用不会真正扣费
+3. **一个手机号**：用于接收验证码
+
+---
+
+## 注册步骤（一步步来）
+
+### 第一步：打开注册页面
+
+访问 https://aws.amazon.com/free/ ，点击"创建免费账户"。
+
+### 第二步：填写基本信息
+
+- 输入邮箱地址
+- 设置 AWS 账户名称（随便起，比如"我的学习账户"）
+- 验证邮箱（去邮箱收验证码）
+
+### 第三步：设置 Root 用户密码
+
+**这个密码非常重要！** Root 用户是你 AWS 账户的"超级管理员"，拥有最高权限，能做任何事情，包括删除整个账户。
+
+密码建议：
+- 至少 12 位
+- 包含大小写字母、数字、特殊符号
+- 不要和其他网站的密码相同
+- 建议用密码管理器（如 1Password、Bitwarden）保存
+
+### 第四步：填写联系信息
+
+- 选择"个人"账户类型（学习用途）
+- 填写姓名、地址、电话
+
+### 第五步：绑定支付方式
+
+- 输入信用卡/借记卡信息
+- 会预扣 $1 验证（几天后退还）
+- **别担心**：只要在免费额度内使用，不会真正扣费
+
+### 第六步：身份验证
+
+- 输入手机号
+- 接收并输入验证码
+
+### 第七步：选择支持计划
+
+选择 **Basic Support - Free**（免费基础支持）。
+
+其他付费计划是给企业用的，学习阶段完全不需要。
+
+### 完成！
+
+注册成功后，你会收到一封确认邮件。账户可能需要几分钟到几小时才能完全激活。
+
+---
+
+## 注册完成后的第一件事：保护 Root 账户
+
+Root 账户就像你家的万能钥匙——能开所有的门。如果被别人拿到了，后果不堪设想（有人用别人的 AWS 账户挖矿，一夜之间产生几万美元账单的案例真实存在）。
+
+### 必做操作一：启用 MFA（多因素认证）
+
+MFA 是什么？就是除了密码之外，再加一层验证。即使密码泄露了，没有第二层验证也登不进去。
+
+**就像银行卡取钱：光知道密码不够，还需要有实体卡。**
+
+操作步骤：
+1. 登录 AWS 控制台
+2. 点击右上角你的账户名 → "安全凭证"（Security credentials）
+3. 找到"多重身份验证（MFA）"→ "分配 MFA 设备"
+4. 选择"身份验证器应用"
+5. 手机下载一个 MFA 应用（推荐 Google Authenticator 或 Microsoft Authenticator）
+6. 用手机扫描屏幕上的二维码
+7. 输入手机上显示的两个连续验证码
+8. 完成！
+
+从此以后，每次登录 Root 账户都需要输入手机上的动态验证码。
+
+### 必做操作二：不要用 Root 账户做日常操作
+
+Root 账户只用于以下极少数场景：
+- 修改账户级别的设置
+- 查看和修改账单信息
+- 关闭 AWS 账户
+
+日常学习和工作，应该创建一个 IAM 用户（明天会详细讲）。
+
+**为什么？** 就像你不会拿着家里的万能钥匙出门——万一丢了，所有门都不安全了。你会配一把只能开自己房间门的钥匙日常使用。
+
+---
+
+## 必做操作三：设置账单告警
+
+这是**防止意外扣费**最重要的一步。
+
+AWS 的免费套餐（Free Tier）有额度限制。如果你不小心超出了，就会开始扣费。设置告警能让你在费用超出预期时第一时间收到通知。
+
+### 方法一：开启免费套餐使用告警
+
+1. 进入 Billing Dashboard（账单控制面板）
+2. 左侧菜单 → Billing preferences（账单首选项）
+3. 勾选 "Receive Free Tier Usage Alerts"（接收免费套餐使用告警）
+4. 填写你的邮箱
+5. 保存
+
+这样当你的免费额度快用完时，会收到邮件提醒。
+
+### 方法二：创建预算告警（更推荐）
+
+1. 在控制台搜索 "Budgets"（预算）
+2. 点击 "Create a budget"（创建预算）
+3. 选择 "Zero spend budget"（零支出预算）——只要产生任何费用就告警
+4. 或者选择 "Monthly cost budget"，设置阈值为 $5 或 $10
+5. 填写通知邮箱
+6. 创建完成
+
+**强烈建议设置 $5 的预算告警**。学习阶段正常使用不应该产生费用，如果收到告警说明有什么东西在意外计费。
+
+---
+
+## AWS 免费套餐（Free Tier）详解
+
+AWS 的免费套餐分三类，搞清楚它们很重要：
+
+### 第一类：12 个月免费
+
+注册后 12 个月内有效，过期后开始收费。
+
+| 服务 | 免费额度 | 超出后价格（参考） |
+|------|----------|-------------------|
+| EC2 | t2.micro 或 t3.micro，750 小时/月 | ~$0.01/小时 |
+| S3 | 5GB 存储，2万次 GET 请求 | $0.023/GB/月 |
+| RDS | db.t2.micro，750 小时/月 | ~$0.02/小时 |
+| CloudFront | 1TB 数据传输 | $0.085/GB |
+
+### 第二类：永久免费
+
+不管注册多久都免费，没有时间限制。
+
+| 服务 | 免费额度 |
+|------|----------|
+| Lambda | 每月 100 万次请求 + 40 万 GB-秒计算 |
+| DynamoDB | 25GB 存储 + 每月 2 亿次请求 |
+| SNS | 每月 100 万次推送 |
+| CloudWatch | 10 个自定义指标 + 10 个告警 |
+
+### 第三类：短期试用
+
+特定服务的限时试用，用完就没了。
+
+---
+
+## 新手最常踩的扣费坑
+
+我列出最常见的几个，请务必注意：
+
+**坑 1：EC2 实例忘记关**
+你启动了一台 EC2 实例做实验，做完后忘记停止或终止它。它会一直运行一直计费。
+→ **解决**：实验做完立刻停止或终止实例。
+
+**坑 2：Elastic IP 没绑定实例**
+Elastic IP（弹性 IP）绑定到运行中的实例是免费的，但如果你申请了一个 IP 却没有绑定到任何实例，AWS 会收费（约 $0.005/小时）。
+→ **解决**：不用的 Elastic IP 立刻释放。
+
+**坑 3：EBS 卷没删除**
+即使 EC2 实例停止了，它的磁盘（EBS 卷）仍然存在并计费。
+→ **解决**：终止实例时勾选"删除关联的 EBS 卷"。
+
+**坑 4：NAT Gateway 忘记删**
+NAT Gateway 按小时计费（约 $0.045/小时 ≈ $32/月），很多教程让你创建但没提醒你删除。
+→ **解决**：实验完成后立刻删除 NAT Gateway。
+
+**坑 5：在错误的 Region 创建了资源**
+你在东京 Region 创建了资源，但平时看的是弗吉尼亚 Region，以为什么都没有。资源在后台默默运行计费。
+→ **解决**：检查所有 Region 是否有遗留资源。
+
+---
+
+## 认识 AWS 管理控制台
+
+登录后你会看到 AWS 的主界面。几个关键区域：
+
+**顶部搜索栏**：最常用的功能。想找什么服务直接搜索，比翻菜单快 10 倍。
+
+**右上角 Region 选择器**：显示你当前操作的区域。**非常重要**——很多资源是区域级别的，切换区域后看到的资源完全不同。
+
+**服务菜单**：按类别列出所有 AWS 服务。刚开始你只需要关注 EC2、S3、IAM 这几个。
+
+---
+
+## 今天的小测验
+
+1. Root 账户的 MFA 为什么重要？不设会有什么风险？
+2. 为什么不建议用 Root 账户做日常操作？
+3. 列出两个新手最容易被意外扣费的场景。
+4. AWS 免费套餐的"12 个月免费"和"永久免费"有什么区别？
+
+---
+
+## 延伸阅读
+
+- [AWS Free Tier 完整列表](https://aws.amazon.com/free/)
+- [AWS 账户安全最佳实践](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+- [避免意外 AWS 账单](https://aws.amazon.com/getting-started/hands-on/control-your-costs-free-tier-budgets/)
+
+---
+
+## 明天预告
+
+明天学习 IAM（身份与访问管理）：创建你的第一个日常使用的 IAM 用户，理解"谁能做什么"这个 AWS 安全的核心问题。

课程/第一阶段-云计算基础/第06天-IAM入门.md

@@ -0,0 +1,194 @@
+# 第6天：IAM 入门——谁能做什么
+
+## 今天你将学到什么
+
+今天学习 AWS 中最重要的安全服务：IAM（Identity and Access Management，身份与访问管理）。
+
+它回答两个核心问题：
+- **你是谁？**（身份认证）
+- **你能做什么？**（权限授权）
+
+这是 AWS 安全的基石，后面学的所有服务都离不开它。
+
+---
+
+## 用公司来理解 IAM
+
+想象你新入职一家公司：
+
+- **你的工牌** = IAM 用户（证明你是谁）
+- **你所在的部门** = IAM 组（研发部、市场部、财务部）
+- **你的门禁权限** = IAM 策略（你能进哪些房间、用哪些设备）
+- **临时访客证** = IAM 角色（外来人员临时获得某些权限，离开后就失效）
+
+公司不会给每个人一把万能钥匙，而是根据岗位需要给不同的权限。IAM 做的就是这件事。
+
+---
+
+## 四个核心概念
+
+### 1. 用户（User）
+
+一个 IAM 用户代表一个具体的人或程序。
+
+**每个用户有自己的登录凭证**：
+- 用户名 + 密码（用于登录网页控制台）
+- Access Key ID + Secret Access Key（用于命令行和程序调用）
+
+**重要原则：一人一账号，绝不共享。**
+
+为什么？如果三个人共用一个账号，出了问题你根本不知道是谁干的。就像公司的门禁卡，每人一张才能追踪谁什么时候进了哪个房间。
+
+### 2. 组（Group）
+
+组是用户的集合，方便批量管理权限。
+
+**举个例子**：
+
+你公司有 10 个开发人员，他们都需要访问代码仓库和测试服务器。你可以：
+- 方法 A：给每个人单独设置权限（重复 10 次，累死）
+- 方法 B：创建一个"开发者"组，把权限给这个组，然后把 10 个人加进去（一次搞定）
+
+显然方法 B 更聪明。新人入职？加入组就自动有权限。离职？移出组就自动失去权限。
+
+**注意**：
+- 一个用户可以属于多个组（比如既在"开发者"组又在"项目A"组）
+- 组不能嵌套（组里面不能再包含组）
+
+### 3. 策略（Policy）
+
+策略是一份"权限清单"，用 JSON 格式写成，定义了"谁能对什么资源做什么操作"。
+
+**用大白话说就是**：
+
+"允许/拒绝 + 某人 + 对某个东西 + 做某个操作"
+
+比如：
+- "允许张三读取 S3 桶里的文件"
+- "拒绝所有人删除生产数据库"
+- "允许开发组启动和停止测试环境的 EC2 实例"
+
+AWS 预置了很多常用策略（叫"AWS 托管策略"），比如：
+- `AmazonS3ReadOnlyAccess` — 只能读 S3，不能写
+- `AmazonEC2FullAccess` — 对 EC2 有完全权限
+- `AdministratorAccess` — 对所有服务有完全权限（相当于万能钥匙）
+
+### 4. 角色（Role）
+
+角色是一个"临时身份"，不绑定特定的人。谁需要谁来"穿上"这个角色，用完就"脱下"。
+
+**为什么需要角色？**
+
+场景一：你的应用程序运行在 EC2 服务器上，需要读取 S3 里的文件。你不能给服务器一个"用户账号"（那样就有永久密码了，不安全）。正确做法是给服务器一个"角色"——它运行时自动获得临时权限，权限会自动过期和刷新。
+
+场景二：外部审计人员需要临时查看你的 AWS 资源。你不想给他创建永久账号。给他一个角色，审计完了角色权限就失效了。
+
+**角色的核心优势：没有永久密码，临时获取、自动过期，比用户账号安全得多。**
+
+---
+
+## 最小权限原则
+
+这是 IAM 最最最重要的设计原则：
+
+> **只给完成工作所需的最小权限，一分都不多给。**
+
+**为什么这么重要？**
+
+想象一下：如果公司每个人都有所有房间的钥匙——
+- 实习生不小心进了机房拔了网线，全公司断网
+- 保洁阿姨误删了财务系统的数据
+- 某个员工的钥匙丢了，所有房间都不安全了
+
+同样的道理：
+- 如果每个 IAM 用户都有 AdministratorAccess，一个误操作就可能删掉生产数据库
+- 如果某个用户的密码泄露了，攻击者能做的事情越少越好
+
+**实践方法**：
+- 新用户创建时零权限，需要什么再加什么
+- 定期检查：这个人还需要这些权限吗？
+- 用 AWS 的工具（Access Analyzer）发现从未使用过的权限，然后移除
+
+---
+
+## 动手：创建你的第一个 IAM 用户
+
+现在我们来创建一个日常使用的 IAM 用户，替代 Root 账户。
+
+### 步骤：
+
+1. 用 Root 账户登录 AWS 控制台
+2. 搜索并进入 "IAM" 服务
+3. 左侧菜单点击 "用户"（Users）→ "创建用户"（Create user）
+4. 用户名填写：`admin-daily`（或者你喜欢的名字）
+5. 勾选"提供用户对 AWS 管理控制台的访问权限"
+6. 设置密码
+7. 下一步：设置权限
+8. 选择"将用户添加到组"→ "创建组"
+9. 组名填写：`Administrators`
+10. 搜索并勾选 `AdministratorAccess` 策略
+11. 创建组，将用户加入
+12. 完成创建
+
+### 记录登录信息：
+
+创建完成后，你会看到一个专属的登录 URL：
+```
+https://你的账户ID.signin.aws.amazon.com/console
+```
+
+把这个 URL 收藏起来。以后用这个 URL + IAM 用户名密码登录，不再用 Root 账户。
+
+### 给 IAM 用户也启用 MFA
+
+和 Root 账户一样，IAM 用户也应该启用 MFA：
+1. 用 IAM 用户登录
+2. 右上角 → 安全凭证
+3. 分配 MFA 设备
+4. 扫码绑定
+
+---
+
+## IAM 的工作流程
+
+当你在 AWS 上做任何操作时，背后发生了什么：
+
+```
+你点击"创建 EC2 实例"
+    ↓
+AWS 检查：你是谁？（认证）
+    ↓
+AWS 检查：你有权限做这个操作吗？（授权）
+    ↓
+有权限 → 执行操作
+没权限 → 返回"Access Denied"错误
+```
+
+**授权的判断逻辑**：
+1. 默认：所有操作都被拒绝（除非有明确的"允许"）
+2. 如果找到了"允许"规则 → 允许
+3. 但如果同时存在"拒绝"规则 → 最终拒绝
+
+**记住：拒绝永远优先于允许。** 这是安全设计的基本原则。
+
+---
+
+## 今天的小测验
+
+1. IAM 用户和 IAM 角色有什么区别？各自适合什么场景？
+2. 为什么要用"组"来管理权限，而不是给每个用户单独设置？
+3. "最小权限原则"是什么意思？为什么重要？
+4. 你现在应该用什么账户做日常操作？Root 还是 IAM 用户？
+
+---
+
+## 延伸阅读
+
+- [IAM 最佳实践](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+- [IAM 入门教程](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started.html)
+
+---
+
+## 明天预告
+
+明天学习 AWS CLI（命令行工具）的安装和配置。虽然控制台（网页）很直观，但真正高效的 AWS 操作都是通过命令行完成的。学会 CLI，你的效率会提升 10 倍。

课程/第一阶段-云计算基础/第07天-AWS-CLI安装配置.md

@@ -0,0 +1,209 @@
+# 第7天：AWS CLI——用命令行操控云
+
+## 今天你将学到什么
+
+今天安装和配置 AWS CLI（命令行界面），学会用键盘代替鼠标来操作 AWS。
+
+你可能会问：有网页控制台了，为什么还要学命令行？
+
+---
+
+## 为什么要用命令行
+
+用一个生活例子来说明：
+
+假设你要给 100 个文件改名字。
+- 用鼠标：右键 → 重命名 → 输入新名字 → 回车。重复 100 次。
+- 用命令行：写一行命令，1 秒搞定 100 个。
+
+在 AWS 中也是一样：
+- 用控制台创建 1 台服务器：点点点，2 分钟搞定。
+- 用控制台创建 50 台配置相同的服务器：点到手抽筋。
+- 用命令行创建 50 台服务器：一条命令，10 秒搞定。
+
+**命令行的优势**：
+- **可重复**：命令可以保存成脚本，下次一键执行
+- **可自动化**：配合定时任务、CI/CD 流水线
+- **更快**：熟练后比点网页快得多
+- **可审计**：命令历史就是操作记录
+- **批量操作**：一条命令处理成百上千个资源
+
+---
+
+## 安装 AWS CLI
+
+AWS CLI 有 v1 和 v2 两个版本，我们装最新的 v2。
+
+### Windows 安装
+
+1. 下载安装包：https://awscli.amazonaws.com/AWSCLIV2.msi
+2. 双击运行，一路点"Next"
+3. 安装完成
+
+### macOS 安装
+
+1. 下载安装包：https://awscli.amazonaws.com/AWSCLIV2.pkg
+2. 双击运行，按提示安装
+
+或者用 Homebrew（如果你装了的话）：
+```
+brew install awscli
+```
+
+### Linux 安装
+
+```
+curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
+unzip awscliv2.zip
+sudo ./aws/install
+```
+
+### 验证安装成功
+
+打开终端（Windows 用 PowerShell 或 Git Bash），输入：
+```
+aws --version
+```
+
+看到类似 `aws-cli/2.x.x Python/3.x.x` 的输出就说明安装成功了。
+
+---
+
+## 配置 AWS CLI
+
+安装好了，但 CLI 还不知道"你是谁"。需要告诉它你的身份信息。
+
+### 第一步：创建 Access Key
+
+1. 用你的 IAM 用户登录 AWS 控制台
+2. 右上角点击你的用户名 → "安全凭证"
+3. 往下找到 "访问密钥"（Access keys）→ "创建访问密钥"
+4. 选择 "命令行界面 (CLI)"
+5. 确认并创建
+6. **重要**：记录下 Access Key ID 和 Secret Access Key
+
+**Secret Access Key 只显示这一次！** 关掉页面就再也看不到了。建议立刻复制保存到安全的地方（密码管理器）。
+
+### 第二步：运行配置命令
+
+在终端输入：
+```
+aws configure
+```
+
+它会依次问你四个问题：
+
+```
+AWS Access Key ID [None]: 输入你的 Access Key ID
+AWS Secret Access Key [None]: 输入你的 Secret Access Key
+Default region name [None]: ap-northeast-1
+Default output format [None]: json
+```
+
+**Region 怎么选**：
+- 如果你在中国，选 `ap-northeast-1`（东京）或 `ap-southeast-1`（新加坡），延迟较低
+- 如果纯学习不在意延迟，选 `us-east-1`（弗吉尼亚），服务最全、价格最低
+
+**输出格式**：
+- `json`：程序友好，信息最全（推荐）
+- `table`：人类友好，像表格一样展示
+- `text`：纯文本，适合脚本处理
+
+### 第三步：验证配置
+
+输入以下命令：
+```
+aws sts get-caller-identity
+```
+
+如果配置正确，会返回类似这样的信息：
+```json
+{
+    "UserId": "AIDAXXXXXXXXXXXXXXXXX",
+    "Account": "123456789012",
+    "Arn": "arn:aws:iam::123456789012:user/admin-daily"
+}
+```
+
+这说明 CLI 已经知道你是谁了，可以开始使用了。
+
+---
+
+## 试试几个基本命令
+
+AWS CLI 的命令格式非常统一：
+
+```
+aws <服务名> <操作> [参数]
+```
+
+### 列出你的 S3 桶
+
+```
+aws s3 ls
+```
+
+如果你还没创建过任何 S3 桶，会返回空结果（这是正常的）。
+
+### 查看你有哪些 EC2 实例
+
+```
+aws ec2 describe-instances
+```
+
+同样，如果没创建过，会返回空的列表。
+
+### 查看所有可用的 Region
+
+```
+aws ec2 describe-regions --output table
+```
+
+这会以表格形式列出所有 AWS Region，很直观。
+
+### 查看当前账户信息
+
+```
+aws iam get-user
+```
+
+返回你当前 IAM 用户的详细信息。
+
+---
+
+## 安全注意事项
+
+Access Key 就像你家的钥匙，泄露了别人就能进你家。以下几点务必注意：
+
+**绝对不要做的事**：
+- 把 Access Key 写在代码里然后提交到 GitHub（每天都有人因此被盗）
+- 把 Access Key 发在聊天群里或邮件里
+- 把 Access Key 存在桌面的 txt 文件里
+
+**应该做的事**：
+- 用密码管理器保存
+- 定期更换（比如每 90 天）
+- 不用的 Key 立刻删除
+- 在 EC2 服务器上用"角色"而不是 Access Key（后面会学到）
+
+---
+
+## 今天的小测验
+
+1. AWS CLI 的命令格式是什么？
+2. `aws configure` 需要输入哪四个信息？
+3. 为什么 Secret Access Key 只显示一次？
+4. 为什么不应该把 Access Key 放在代码里？
+
+---
+
+## 延伸阅读
+
+- [AWS CLI v2 安装指南](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
+- [AWS CLI 命令参考](https://docs.aws.amazon.com/cli/latest/reference/)
+
+---
+
+## 明天预告
+
+第一阶段完成！明天进入第二阶段"核心服务"，从最重要的 EC2 开始——启动你人生中第一台云服务器。我们会一步步操作，让你真正体验到"几分钟就有一台服务器"的感觉。

课程/第三阶段-安全与身份/第20天-IAM策略深入.md

@@ -0,0 +1,226 @@
+# 第20天：IAM 策略深入——精确控制权限
+
+## 今天你将学到什么
+
+第 6 天我们学了 IAM 的基本概念。今天深入学习 IAM 策略的编写——它是一份 JSON 格式的"权限清单"，精确定义"谁能对什么资源做什么操作"。
+
+---
+
+## 策略长什么样
+
+一个 IAM 策略就是一段 JSON 文本。别被 JSON 吓到，它的结构其实很简单：
+
+```json
+{
+  "Version": "2012-10-17",
+  "Statement": [
+    {
+      "Effect": "Allow",
+      "Action": "s3:GetObject",
+      "Resource": "arn:aws:s3:::my-photos/*"
+    }
+  ]
+}
+```
+
+翻译成人话：**允许从 my-photos 这个 S3 桶里下载文件。**
+
+---
+
+## 策略的四个核心要素
+
+每条策略声明（Statement）回答四个问题：
+
+### 1. Effect（效果）：允许还是拒绝？
+
+只有两个值：
+- `"Allow"` — 允许
+- `"Deny"` — 拒绝
+
+### 2. Action（操作）：能做什么？
+
+格式是 `服务名:操作名`，比如：
+- `s3:GetObject` — 从 S3 下载文件
+- `s3:PutObject` — 往 S3 上传文件
+- `ec2:StartInstances` — 启动 EC2 实例
+- `ec2:TerminateInstances` — 终止（销毁）EC2 实例
+- `rds:CreateDBInstance` — 创建 RDS 数据库
+
+**通配符**：
+- `s3:*` — S3 的所有操作
+- `ec2:Describe*` — EC2 所有以 Describe 开头的操作（都是只读查询）
+- `*` — 所有服务的所有操作（超级危险！）
+
+### 3. Resource（资源）：对什么东西？
+
+用 ARN（Amazon Resource Name）指定具体资源：
+
+```
+arn:aws:服务:区域:账户ID:资源
+```
+
+举例：
+- `arn:aws:s3:::my-photos/*` — my-photos 桶里的所有文件
+- `arn:aws:ec2:ap-northeast-1:123456789012:instance/i-abc123` — 东京区域的某台特定 EC2
+- `*` — 所有资源（谨慎使用！）
+
+### 4. Condition（条件）：在什么条件下？（可选）
+
+添加额外的限制条件，比如：
+- 只在工作时间允许
+- 只从公司 IP 地址允许
+- 必须使用 MFA 验证后才允许
+
+---
+
+## 用生活例子理解策略
+
+**例子 1：实习生的权限**
+
+"允许实习生查看所有 S3 桶的文件列表，但不能下载、上传或删除任何文件"
+
+```json
+{
+  "Version": "2012-10-17",
+  "Statement": [
+    {
+      "Effect": "Allow",
+      "Action": [
+        "s3:ListBucket",
+        "s3:ListAllMyBuckets"
+      ],
+      "Resource": "*"
+    }
+  ]
+}
+```
+
+就像给实习生一把只能看目录的权限——能看到有什么文件，但打不开。
+
+**例子 2：开发者的权限**
+
+"允许开发者对测试环境的 EC2 做任何操作，但不能碰生产环境"
+
+```json
+{
+  "Version": "2012-10-17",
+  "Statement": [
+    {
+      "Effect": "Allow",
+      "Action": "ec2:*",
+      "Resource": "*",
+      "Condition": {
+        "StringEquals": {
+          "ec2:ResourceTag/Environment": "test"
+        }
+      }
+    }
+  ]
+}
+```
+
+只有标签为 `Environment=test` 的 EC2 实例才能操作。生产环境的实例（`Environment=production`）碰不了。
+
+**例子 3：安全红线**
+
+"无论如何，任何人都不能删除生产数据库"
+
+```json
+{
+  "Version": "2012-10-17",
+  "Statement": [
+    {
+      "Effect": "Deny",
+      "Action": "rds:DeleteDBInstance",
+      "Resource": "arn:aws:rds:*:*:db:production-*"
+    }
+  ]
+}
+```
+
+即使某人有 AdministratorAccess，这条 Deny 规则也会阻止他删除生产数据库。**因为 Deny 永远优先于 Allow。**
+
+---
+
+## 策略评估逻辑
+
+当你在 AWS 上做一个操作时，系统怎么判断你有没有权限？
+
+```
+第一步：默认拒绝（什么权限都没有）
+    ↓
+第二步：查找所有适用的策略
+    ↓
+第三步：有没有显式的 Deny？
+    ├── 有 → 最终结果：拒绝（到此结束，Deny 最大）
+    └── 没有 ↓
+第四步：有没有显式的 Allow？
+    ├── 有 → 最终结果：允许
+    └── 没有 → 最终结果：拒绝（默认拒绝）
+```
+
+**记住三句话**：
+1. 默认所有操作都被拒绝
+2. 需要显式的 Allow 才能做事
+3. 任何地方有 Deny 就一定被拒绝（Deny 优先级最高）
+
+---
+
+## AWS 托管策略 vs 自定义策略
+
+**AWS 托管策略**：AWS 预先写好的常用策略，开箱即用。
+
+常用的有：
+| 策略名 | 权限范围 |
+|--------|----------|
+| AdministratorAccess | 所有服务所有操作（万能钥匙） |
+| PowerUserAccess | 除了 IAM 之外的所有权限 |
+| ReadOnlyAccess | 所有服务的只读权限 |
+| AmazonS3FullAccess | S3 的完全权限 |
+| AmazonS3ReadOnlyAccess | S3 的只读权限 |
+| AmazonEC2FullAccess | EC2 的完全权限 |
+
+**自定义策略**：你自己写的策略，可以精确到具体的资源和操作。
+
+**建议**：
+- 学习阶段用 AWS 托管策略（方便）
+- 生产环境写自定义策略（精确控制，最小权限）
+
+---
+
+## 常见错误和调试
+
+**错误信息**：`Access Denied`（访问被拒绝）
+
+**排查步骤**：
+1. 确认你用的是哪个 IAM 用户/角色
+2. 检查这个用户/角色附加了哪些策略
+3. 策略里有没有覆盖你要做的操作和资源
+4. 有没有 Deny 规则在阻止你
+
+**调试工具**：
+- IAM Policy Simulator：模拟测试策略效果，不用真的去执行操作
+- CloudTrail：查看被拒绝的 API 调用详情
+
+---
+
+## 今天的小测验
+
+1. 一个 IAM 策略的四个核心要素是什么？
+2. 如果一个用户同时有一条 Allow 规则和一条 Deny 规则针对同一个操作，最终结果是什么？
+3. `"Action": "s3:*"` 和 `"Action": "*"` 有什么区别？
+4. 为什么生产环境不建议用 `AdministratorAccess`？
+
+---
+
+## 延伸阅读
+
+- [IAM 策略参考文档](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html)
+- [IAM Policy Simulator](https://policysim.aws.amazon.com/)
+- [AWS 策略生成器](https://awspolicygen.s3.amazonaws.com/policygen.html)
+
+---
+
+## 明天预告
+
+明天学习 IAM 角色的高级用法：跨账户访问、服务角色、联合身份。理解企业环境中如何安全地管理多个账户和外部用户的访问。

课程/第三阶段-安全与身份/第21天-加密与密钥管理.md

@@ -0,0 +1,151 @@
+# 第21天：加密与密钥管理——保护你的数据
+
+## 今天你将学到什么
+
+今天学习如何保护数据安全：KMS（密钥管理）负责加密数据，Secrets Manager 负责管理密码和密钥。学完你会明白为什么"加密一切"是 AWS 的基本原则。
+
+---
+
+## 为什么需要加密
+
+**场景一**：你的数据库存储了用户的手机号和地址。如果有人偷走了数据库的硬盘（物理盗窃或黑客入侵），他们能直接读取所有用户信息。
+
+**加密后**：即使硬盘被偷，看到的也是一堆乱码。没有密钥就无法解读。
+
+**场景二**：你的应用配置文件里写着数据库密码 `password123`。如果代码仓库泄露了，黑客就能直接连上你的数据库。
+
+**用 Secrets Manager 后**：配置文件里只有一个引用 ID，真正的密码存在 AWS 的保险箱里，只有有权限的程序才能取出来。
+
+---
+
+## 加密的两种场景
+
+| 场景 | 含义 | 类比 |
+|------|------|------|
+| 静态加密 | 数据存在磁盘上时是加密的 | 保险箱里的文件是锁着的 |
+| 传输加密 | 数据在网络上传输时是加密的 | 快递包裹是密封的 |
+
+AWS 的大多数服务**默认启用**这两种加密。你几乎不需要额外操作。
+
+---
+
+## KMS（Key Management Service）
+
+KMS 是 AWS 的"密钥保险箱"——帮你创建、存储和管理加密密钥。
+
+### 工作原理（简化版）
+
+你不需要自己写加密算法。只需要告诉 AWS："帮我加密这段数据"，AWS 用 KMS 里的密钥帮你加密。解密时也一样。
+
+**类比**：KMS 就像银行的保险箱服务。你把贵重物品（数据）交给银行，银行帮你锁好（加密）。需要取的时候，验证你的身份后帮你打开（解密）。
+
+### 哪些 AWS 服务用 KMS 加密
+
+几乎所有存储数据的服务都支持 KMS：
+- S3：存储的文件自动加密
+- EBS：硬盘上的数据自动加密
+- RDS：数据库文件自动加密
+- DynamoDB：表数据自动加密
+- SQS：消息内容加密
+- Lambda：环境变量加密
+
+**你要做的**：创建资源时勾选"启用加密"（很多服务现在默认就是启用的）。
+
+### 密钥类型
+
+| 类型 | 谁管理 | 费用 | 适合 |
+|------|--------|------|------|
+| AWS 托管密钥 | AWS 自动管理 | 免费 | 大多数场景 |
+| 客户托管密钥 | 你自己管理 | $1/月/密钥 | 需要精细控制的场景 |
+
+学习阶段用 AWS 托管密钥就够了。
+
+---
+
+## Secrets Manager——密码的保险箱
+
+### 问题：密码放哪里？
+
+你的应用需要连接数据库，需要一个密码。这个密码放哪里？
+
+**错误做法**：
+- 写在代码里 → 代码泄露密码就泄露
+- 写在配置文件里 → 配置文件可能被误提交到 Git
+- 写在环境变量里 → 环境变量可能出现在日志中
+
+**正确做法**：放在 Secrets Manager 里。
+
+### 工作流程
+
+```
+1. 你把数据库密码存入 Secrets Manager
+2. 应用启动时，调用 Secrets Manager API 获取密码
+3. 用获取到的密码连接数据库
+4. 密码永远不会出现在代码或配置文件中
+```
+
+### Secrets Manager 的杀手锏：自动轮换
+
+**传统方式**：数据库密码设置后就不变了。如果泄露了，你可能很久才发现。
+
+**Secrets Manager 自动轮换**：
+- 每 30 天（你设置的周期）自动更换数据库密码
+- 自动在数据库中更新新密码
+- 应用下次获取时自动拿到新密码
+- 全程无需人工干预，无需重启应用
+
+**就像银行定期帮你换保险箱密码，而且自动通知所有需要知道的人。**
+
+---
+
+## 实际应用场景
+
+### 场景：Web 应用连接数据库
+
+**不安全的做法**：
+```
+数据库地址：mydb.xxx.rds.amazonaws.com
+用户名：admin
+密码：MyP@ssw0rd123  ← 写死在代码里
+```
+
+**安全的做法**：
+```
+数据库地址：mydb.xxx.rds.amazonaws.com
+用户名：从 Secrets Manager 获取
+密码：从 Secrets Manager 获取
+```
+
+应用运行时动态获取凭证，代码里看不到任何密码。
+
+---
+
+## 加密最佳实践
+
+1. **默认加密一切**：创建任何存储资源时都启用加密，成本几乎为零
+2. **不要硬编码密码**：所有密码、API 密钥都放 Secrets Manager
+3. **启用自动轮换**：密码定期更换，减少泄露风险
+4. **最小权限**：只有需要解密的服务才给 KMS 权限
+5. **审计**：通过 CloudTrail 监控谁在什么时候使用了密钥
+
+---
+
+## 今天的小测验
+
+1. "静态加密"和"传输加密"分别保护什么场景？
+2. 为什么不应该把数据库密码写在代码里？
+3. Secrets Manager 的"自动轮换"解决了什么问题？
+4. KMS 的作用是什么？用一句话概括。
+
+---
+
+## 延伸阅读
+
+- [KMS 开发者指南](https://docs.aws.amazon.com/kms/latest/developerguide/)
+- [Secrets Manager 用户指南](https://docs.aws.amazon.com/secretsmanager/latest/userguide/)
+
+---
+
+## 明天预告
+
+明天学习 AWS 的网络安全服务：WAF（Web 应用防火墙）和 Shield（DDoS 防护）——保护你的网站不被黑客攻击。

课程/第三阶段-安全与身份/第22天-WAF与Shield防御攻击.md

@@ -0,0 +1,156 @@
+# 第22天：WAF 与 Shield——防御网络攻击
+
+## 今天你将学到什么
+
+今天学习如何保护你的网站免受攻击。WAF 防御应用层攻击（SQL 注入、XSS），Shield 防御 DDoS 攻击（用海量流量压垮你的服务器）。
+
+---
+
+## 常见的网络攻击类型
+
+### 攻击一：SQL 注入
+
+**原理**：黑客在输入框里输入特殊的数据库命令，欺骗你的程序执行恶意操作。
+
+**举例**：登录页面的用户名输入框，黑客输入：
+```
+admin' OR '1'='1
+```
+如果你的程序没有防护，这可能让黑客绕过密码验证直接登录。
+
+### 攻击二：XSS（跨站脚本攻击）
+
+**原理**：黑客在网页中注入恶意脚本，当其他用户浏览这个页面时，脚本会在他们的浏览器中执行。
+
+**举例**：在评论区输入一段恶意代码，其他用户看到这条评论时，代码自动执行，偷走他们的登录信息。
+
+### 攻击三：DDoS（分布式拒绝服务攻击）
+
+**原理**：黑客控制成千上万台电脑（僵尸网络），同时向你的服务器发送海量请求，把服务器压垮。
+
+**类比**：想象有人雇了 10 万人同时打你公司的客服电话，正常客户永远打不进来。
+
+**真实案例**：2016 年，针对 DNS 服务商 Dyn 的 DDoS 攻击导致 Twitter、Netflix、GitHub 等大量网站瘫痪数小时。
+
+---
+
+## AWS WAF（Web Application Firewall）
+
+WAF 是"Web 应用防火墙"，检查每一个到达你网站的请求，阻止恶意请求。
+
+### WAF 放在哪里
+
+WAF 部署在流量入口处：
+```
+用户请求 → CloudFront / ALB → WAF 检查 → 通过 → 你的服务器
+                                        → 阻止 → 返回 403 错误
+```
+
+### WAF 能防什么
+
+| 攻击类型 | WAF 怎么防 |
+|----------|-----------|
+| SQL 注入 | 检测请求中的 SQL 关键字和特殊字符 |
+| XSS | 检测请求中的脚本标签和恶意代码 |
+| 恶意爬虫 | 识别非人类的访问模式 |
+| 暴力破解 | 限制同一 IP 的请求频率 |
+| 已知恶意 IP | 维护黑名单，直接拦截 |
+
+### AWS 托管规则（开箱即用）
+
+AWS 提供了预置的规则集，你不需要自己写规则：
+
+| 规则集 | 防护内容 |
+|--------|----------|
+| 核心规则集 | OWASP Top 10 常见攻击 |
+| SQL 注入规则 | 各种 SQL 注入变体 |
+| 已知恶意输入 | 已知的攻击模式 |
+| 机器人控制 | 恶意爬虫和自动化工具 |
+
+**使用方式**：在 WAF 控制台勾选你需要的规则集，几分钟就能启用防护。
+
+### 自定义规则
+
+你也可以写自己的规则：
+- 屏蔽特定国家的访问
+- 限制同一 IP 每分钟最多 100 次请求
+- 阻止请求体超过 10KB 的请求
+- 只允许特定的 IP 地址访问管理后台
+
+---
+
+## AWS Shield（DDoS 防护）
+
+### Shield Standard（免费，自动启用）
+
+- 所有 AWS 账户自动拥有
+- 防护常见的网络层 DDoS 攻击
+- 不需要任何配置
+- 覆盖：SYN Flood、UDP 反射、DNS 放大等
+
+**你什么都不用做，它已经在保护你了。**
+
+### Shield Advanced（付费，$3,000/月）
+
+- 更高级的 DDoS 防护
+- 24/7 专家团队支持（DDoS 响应团队）
+- 实时攻击可视化
+- **成本保护**：如果 DDoS 攻击导致你的 AWS 费用暴涨（比如 Auto Scaling 加了很多机器），AWS 帮你承担这部分费用
+
+**适合**：金融、电商、游戏等高价值目标。学习阶段不需要。
+
+---
+
+## GuardDuty——智能威胁检测
+
+GuardDuty 是 AWS 的"安全摄像头"，持续监控你的账户活动，发现异常行为。
+
+**它监控什么**：
+- 网络流量模式（有没有和恶意 IP 通信）
+- API 调用行为（有没有异常的操作）
+- DNS 查询（有没有连接恶意域名）
+
+**它能发现什么**：
+- 有人从异常的国家登录了你的账户
+- 某台 EC2 实例在挖矿（CPU 异常高 + 连接矿池地址）
+- 有人在尝试暴力破解你的 SSH 密码
+- S3 桶被异常大量下载（可能是数据泄露）
+
+**使用方式**：一键启用，不需要安装任何东西。GuardDuty 自动分析日志和流量，发现威胁后通知你。
+
+---
+
+## 安全服务选择指南
+
+| 我想防护... | 用什么服务 |
+|------------|-----------|
+| SQL 注入、XSS 等 Web 攻击 | WAF |
+| DDoS 攻击 | Shield（Standard 免费自动启用） |
+| 账户异常行为（被盗用、挖矿） | GuardDuty |
+| 软件漏洞 | Inspector |
+| S3 中的敏感数据泄露 | Macie |
+| 统一安全视图 | Security Hub |
+
+---
+
+## 今天的小测验
+
+1. SQL 注入攻击的原理是什么？WAF 怎么防护它？
+2. DDoS 攻击的目的是什么？它和普通黑客攻击有什么区别？
+3. Shield Standard 和 Shield Advanced 的区别是什么？学习阶段需要 Advanced 吗？
+4. GuardDuty 能发现哪些类型的安全威胁？
+
+---
+
+## 延伸阅读
+
+- [AWS WAF 开发者指南](https://docs.aws.amazon.com/waf/latest/developerguide/)
+- [AWS Shield 文档](https://docs.aws.amazon.com/waf/latest/developerguide/shield-chapter.html)
+- [GuardDuty 用户指南](https://docs.aws.amazon.com/guardduty/latest/ug/)
+- [OWASP Top 10 安全风险](https://owasp.org/www-project-top-ten/)
+
+---
+
+## 明天预告
+
+明天学习 CloudTrail——AWS 的"监控录像"，记录你账户中的每一个操作。谁在什么时候做了什么，一清二楚。这是安全审计和故障排查的基础。

课程/第三阶段-安全与身份/第23天-CloudTrail审计日志.md

@@ -0,0 +1,156 @@
+# 第23天：CloudTrail——谁在什么时候做了什么
+
+## 今天你将学到什么
+
+今天学习 CloudTrail——AWS 的"监控录像系统"。它记录你 AWS 账户中的每一个操作：谁在什么时间、从哪个 IP 地址、对什么资源做了什么操作、结果是成功还是失败。这是安全审计和故障排查的基础。
+
+---
+
+## 为什么需要审计日志
+
+### 场景一：安全事件调查
+
+周一早上你发现生产数据库被删除了。老板问："谁干的？"
+
+没有 CloudTrail：不知道。只能猜。
+
+有 CloudTrail：打开日志一查——周日凌晨 3:17，用户 `dev-zhang` 从 IP `203.x.x.x` 调用了 `rds:DeleteDBInstance`。进一步调查发现他的账号被盗了。
+
+### 场景二：故障排查
+
+你的应用突然无法访问 S3 桶了。什么时候开始的？谁改了权限？
+
+CloudTrail 告诉你：昨天下午 4:32，用户 `ops-li` 修改了桶策略，把 `Allow` 改成了 `Deny`。
+
+### 场景三：合规审计
+
+审计师问："过去 90 天内，谁访问过客户数据？有没有未授权的访问？"
+
+CloudTrail 可以提供完整的访问记录。
+
+**类比**：CloudTrail 就像银行的监控录像 + 操作流水。每一笔交易、每一次进出都有记录。出了问题可以回放查看。
+
+---
+
+## CloudTrail 记录什么
+
+### 每条记录包含的信息
+
+| 字段 | 含义 | 举例 |
+|------|------|------|
+| 时间 | 操作发生的精确时间 | 2024-01-15T03:17:42Z |
+| 用户身份 | 谁做的操作 | 用户 dev-zhang / 角色 lambda-role |
+| 源 IP | 从哪里发起的 | 203.0.113.50 |
+| 操作 | 做了什么 | DeleteDBInstance |
+| 资源 | 对什么东西操作 | arn:aws:rds:...:production-db |
+| 结果 | 成功还是失败 | 成功 / AccessDenied |
+| 请求参数 | 具体的操作细节 | DBInstanceIdentifier: production-db |
+
+### 三种事件类型
+
+| 类型 | 记录什么 | 举例 |
+|------|----------|------|
+| 管理事件 | 对 AWS 资源的管理操作 | 创建/删除 EC2、修改安全组、更改 IAM 策略 |
+| 数据事件 | 对数据的读写操作 | S3 对象的上传/下载、Lambda 函数的调用 |
+| 洞察事件 | 异常活动模式 | API 调用量突然暴增、异常的错误率 |
+
+**默认情况**：管理事件自动记录（免费保留 90 天）。数据事件需要手动开启（因为量太大）。
+
+---
+
+## 怎么使用 CloudTrail
+
+### 方式一：快速查看（Event History）
+
+打开 CloudTrail 控制台 → Event History，可以直接搜索最近 90 天的管理事件。
+
+**常用搜索方式**：
+- 按用户名搜索：看某个人做了什么
+- 按事件名搜索：看谁做了某个操作（比如搜 `DeleteBucket`）
+- 按资源名搜索：看某个资源被谁动过
+
+### 方式二：创建 Trail（长期保存）
+
+如果你需要保留超过 90 天的日志，或者需要记录数据事件，就创建一个 Trail：
+
+```
+CloudTrail → 创建 Trail → 选择保存到 S3 桶
+```
+
+日志会以 JSON 文件的形式存储在你指定的 S3 桶里。你可以保留多久就保留多久。
+
+### 方式三：配合其他服务
+
+- **CloudWatch Logs**：把 CloudTrail 日志发送到 CloudWatch，设置告警。比如"有人删除了安全组就立刻通知我"。
+- **Athena**：用 SQL 查询 S3 里的 CloudTrail 日志。适合大规模分析。
+- **EventBridge**：实时响应特定事件。比如"有人创建了 IAM 用户就自动触发审批流程"。
+
+---
+
+## 实际应用场景
+
+### 场景一：检测异常登录
+
+设置告警：如果有人从非公司 IP 地址登录 AWS 控制台，立刻发送通知。
+
+CloudTrail 记录每次控制台登录的源 IP。配合 CloudWatch 告警，可以实时检测异常登录。
+
+### 场景二：追踪资源变更
+
+"这个安全组的规则是谁改的？什么时候改的？改之前是什么样的？"
+
+在 CloudTrail 中搜索 `AuthorizeSecurityGroupIngress` 或 `RevokeSecurityGroupIngress` 事件，可以看到完整的变更历史。
+
+### 场景三：满足合规要求
+
+很多行业法规（如 PCI DSS、HIPAA、SOC 2）要求保留完整的操作审计日志。CloudTrail 天然满足这些要求。
+
+---
+
+## CloudTrail 最佳实践
+
+1. **所有区域都开启**：攻击者可能在你不常用的区域搞破坏。确保所有 AWS 区域都有 CloudTrail 记录。
+2. **日志文件完整性验证**：开启日志文件验证，防止有人篡改日志（删除自己的犯罪记录）。
+3. **日志桶加密**：存储日志的 S3 桶要加密，防止日志本身被泄露。
+4. **限制日志桶访问**：只有安全团队能访问日志桶，普通开发者不能删除或修改日志。
+5. **设置关键操作告警**：对高危操作（删除资源、修改 IAM、关闭 CloudTrail）设置实时告警。
+
+---
+
+## AWS Config——资源配置的"时光机"
+
+和 CloudTrail 经常一起提到的还有 AWS Config。它们的区别：
+
+| | CloudTrail | AWS Config |
+|--|-----------|------------|
+| 记录什么 | 谁做了什么操作（API 调用） | 资源的配置状态变化 |
+| 回答什么问题 | "谁在 3 点删了数据库？" | "这个安全组的规则上周是什么样的？" |
+| 类比 | 监控录像（记录动作） | 定期拍照（记录状态） |
+
+**Config 的独特价值**：
+- 记录资源配置的完整变更历史
+- 可以设置合规规则（比如"所有 S3 桶必须开启加密"）
+- 自动检测不合规的资源并通知你
+
+---
+
+## 今天的小测验
+
+1. CloudTrail 记录的一条事件包含哪些关键信息？
+2. 管理事件和数据事件的区别是什么？为什么数据事件默认不开启？
+3. 如果你想保留超过 90 天的审计日志，应该怎么做？
+4. CloudTrail 和 AWS Config 各自解决什么问题？
+
+---
+
+## 延伸阅读
+
+- [CloudTrail 用户指南](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)
+- [AWS Config 开发者指南](https://docs.aws.amazon.com/config/latest/developerguide/)
+- [CloudTrail 支持的服务列表](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html)
+
+---
+
+## 明天预告
+
+明天学习 VPC 安全进阶——网络 ACL、VPC Flow Logs、PrivateLink。深入理解如何在网络层面保护你的 AWS 资源。

课程/第三阶段-安全与身份/第24天-VPC安全进阶.md

@@ -0,0 +1,213 @@
+# 第24天：VPC 安全进阶——网络层面的防护
+
+## 今天你将学到什么
+
+第 14 天我们学了 VPC 的基础概念。今天深入学习 VPC 的安全功能：网络 ACL（访问控制列表）、VPC Flow Logs（流量日志）、VPC Endpoint（私有连接）。这些是在网络层面保护你资源的重要工具。
+
+---
+
+## 安全组 vs 网络 ACL
+
+第 14 天学过安全组（Security Group），今天加上网络 ACL（Network ACL），看看它们的区别。
+
+### 类比理解
+
+想象你住在一个小区里：
+
+- **网络 ACL** = 小区大门的保安。检查每一个进出小区的人，按照名单放行或拦截。
+- **安全组** = 你家的门锁。只有你允许的人才能进你家。
+
+两道防线，层层保护。
+
+### 详细对比
+
+| 特性 | 安全组 | 网络 ACL |
+|------|--------|----------|
+| 作用范围 | 实例级别（绑定到 EC2） | 子网级别（整个子网的流量） |
+| 规则类型 | 只有允许规则 | 有允许和拒绝规则 |
+| 状态 | 有状态（允许进就自动允许出） | 无状态（进和出要分别设置） |
+| 规则评估 | 所有规则一起评估 | 按编号顺序评估，匹配即停止 |
+| 默认行为 | 拒绝所有入站，允许所有出站 | 默认 ACL 允许所有流量 |
+
+### "有状态"和"无状态"是什么意思？
+
+**安全组（有状态）**：
+- 你允许了外部访问 80 端口（入站规则）
+- 服务器的响应会自动被允许出去（不需要额外设置出站规则）
+- 就像你邀请朋友来家里，他走的时候不需要再开一次门
+
+**网络 ACL（无状态）**：
+- 你允许了外部访问 80 端口（入站规则）
+- 还必须单独设置出站规则，允许响应流量出去
+- 就像小区保安，进来要查一次证件，出去还要再查一次
+
+### 网络 ACL 规则示例
+
+```
+入站规则：
+规则# | 类型    | 端口  | 来源        | 允许/拒绝
+100   | HTTP   | 80   | 0.0.0.0/0  | 允许
+110   | HTTPS  | 443  | 0.0.0.0/0  | 允许
+120   | SSH    | 22   | 10.0.0.0/16| 允许
+200   | 所有    | 所有  | 1.2.3.4/32 | 拒绝（封禁恶意IP）
+*     | 所有    | 所有  | 0.0.0.0/0  | 拒绝（默认拒绝）
+```
+
+规则按编号从小到大评估。规则 200 会拒绝来自 `1.2.3.4` 的所有流量，即使规则 100 允许了 HTTP。
+
+---
+
+## VPC Flow Logs——网络流量的"监控录像"
+
+### 是什么
+
+VPC Flow Logs 记录 VPC 中网络接口的流量信息。它不记录流量内容（不是抓包），而是记录"谁和谁通信了、用什么端口、多少数据、是否被允许"。
+
+**类比**：如果 CloudTrail 是记录"谁做了什么操作"，那 Flow Logs 就是记录"谁和谁通了电话、打了多久"。不记录通话内容，但记录通话记录。
+
+### 记录什么信息
+
+每条 Flow Log 记录包含：
+
+| 字段 | 含义 | 举例 |
+|------|------|------|
+| 源 IP | 流量从哪来 | 203.0.113.50 |
+| 目标 IP | 流量去哪里 | 10.0.1.25 |
+| 源端口 | 发送方端口 | 49152 |
+| 目标端口 | 接收方端口 | 443 |
+| 协议 | TCP/UDP/ICMP | TCP (6) |
+| 数据包数 | 传了多少包 | 15 |
+| 字节数 | 传了多少数据 | 3500 |
+| 动作 | 被允许还是拒绝 | ACCEPT / REJECT |
+
+### 能用来做什么
+
+**安全分析**：
+- 发现异常流量模式（某台服务器突然向外发送大量数据——可能是数据泄露）
+- 检测端口扫描（大量来自同一 IP 的 REJECT 记录）
+- 确认安全组规则是否生效
+
+**故障排查**：
+- "为什么我的应用连不上数据库？"——查 Flow Logs 看流量是否被 REJECT
+- "为什么响应这么慢？"——查看是否有大量重传
+
+**合规审计**：
+- 证明敏感数据没有流向未授权的网络
+- 记录所有跨 VPC 的通信
+
+### 在哪里开启
+
+Flow Logs 可以在三个级别开启：
+- **VPC 级别**：记录整个 VPC 的所有流量
+- **子网级别**：只记录某个子网的流量
+- **网络接口级别**：只记录某台 EC2 的流量
+
+日志可以发送到：CloudWatch Logs 或 S3。
+
+---
+
+## VPC Endpoint——不走公网的私有连接
+
+### 问题：EC2 访问 S3 要绕路
+
+默认情况下，私有子网的 EC2 要访问 S3，流量路径是：
+
+```
+EC2 → NAT Gateway → Internet Gateway → 公网 → S3
+```
+
+问题：
+- 流量走了公网（虽然加密了，但有些合规要求不允许）
+- 要付 NAT Gateway 的流量费
+- 延迟更高
+
+### 解决方案：VPC Endpoint
+
+VPC Endpoint 让你的 VPC 内部资源可以**直接**连接 AWS 服务，不经过公网。
+
+```
+EC2 → VPC Endpoint → S3（全程在 AWS 内部网络）
+```
+
+**类比**：就像公司内部有一条专用通道直达银行金库，不需要走大马路。更安全、更快、更便宜。
+
+### 两种 Endpoint 类型
+
+| 类型 | 适用服务 | 费用 | 原理 |
+|------|----------|------|------|
+| 网关端点 | S3、DynamoDB | 免费 | 在路由表中添加一条路由 |
+| 接口端点 | 其他大多数 AWS 服务 | 按小时 + 流量收费 | 在子网中创建一个网络接口 |
+
+**建议**：如果你的 EC2 需要频繁访问 S3 或 DynamoDB，一定要创建网关端点。免费且更安全。
+
+---
+
+## PrivateLink——安全地暴露服务
+
+### 场景
+
+你有一个内部 API 服务，想让其他 VPC（可能是其他团队或其他公司）安全地访问，但不想把它暴露到公网。
+
+### 传统方式（不安全）
+
+把服务放在公网 → 任何人都能尝试访问 → 需要复杂的防火墙规则
+
+### PrivateLink 方式
+
+```
+你的 VPC（服务提供方）
+    └── Network Load Balancer
+            ↓
+        PrivateLink
+            ↓
+其他 VPC（服务消费方）
+    └── VPC Endpoint（接口端点）
+```
+
+消费方通过 VPC Endpoint 访问你的服务，流量全程在 AWS 内部网络，不经过公网。
+
+**类比**：就像两栋大楼之间建了一条地下通道。住户可以安全地往来，不需要走外面的马路。
+
+---
+
+## 网络安全架构总结
+
+一个安全的 VPC 网络架构应该包含：
+
+```
+互联网
+  ↓
+网络 ACL（子网级别的第一道防线）
+  ↓
+安全组（实例级别的第二道防线）
+  ↓
+EC2 实例
+  ↓
+VPC Endpoint（访问 AWS 服务不走公网）
+```
+
+加上 VPC Flow Logs 记录所有流量，形成完整的网络安全体系。
+
+---
+
+## 今天的小测验
+
+1. 安全组和网络 ACL 的"有状态"和"无状态"分别是什么意思？
+2. VPC Flow Logs 记录什么信息？它能帮你解决什么问题？
+3. 为什么建议使用 VPC Endpoint 而不是通过公网访问 S3？
+4. PrivateLink 解决了什么问题？
+
+---
+
+## 延伸阅读
+
+- [网络 ACL 文档](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html)
+- [VPC Flow Logs](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)
+- [VPC Endpoints](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints.html)
+- [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/)
+
+---
+
+## 明天预告
+
+明天是第三阶段的收尾：安全架构综合实战。我们会把 IAM、加密、WAF、CloudTrail、VPC 安全这些知识串联起来，设计一个完整的安全防护体系。

课程/第三阶段-安全与身份/第25天-安全架构综合实战.md

@@ -0,0 +1,210 @@
+# 第25天：安全架构综合实战——构建完整的防护体系
+
+## 今天你将学到什么
+
+今天是第三阶段的收尾。我们把前面学到的所有安全知识串联起来，用一个完整的案例展示如何构建企业级的安全防护体系。
+
+---
+
+## 项目背景：一个在线医疗平台
+
+假设你要为一个在线医疗咨询平台设计安全架构：
+- 患者可以在线咨询医生
+- 存储患者的病历和个人信息（高度敏感数据）
+- 需要满足医疗行业的合规要求
+- 有管理后台供运营人员使用
+
+**安全要求**：
+- 患者数据必须加密存储和传输
+- 只有授权的医生能查看对应患者的病历
+- 所有操作必须有审计记录
+- 必须防御常见的 Web 攻击
+- 异常行为要实时告警
+
+---
+
+## 安全架构全景图
+
+```
+互联网用户
+    ↓
+Route 53 + CloudFront（HTTPS 强制加密传输）
+    ↓
+AWS WAF（防御 SQL 注入、XSS、恶意爬虫）
+    ↓
+ALB（仅允许 443 端口）
+    ↓
+┌─────────────────────────────────────────┐
+│  VPC                                     │
+│  ┌─────────────────────────────────┐    │
+│  │ 公有子网                         │    │
+│  │  - NAT Gateway                   │    │
+│  │  - 网络 ACL：严格限制            │    │
+│  └─────────────────────────────────┘    │
+│  ┌─────────────────────────────────┐    │
+│  │ 应用子网（私有）                  │    │
+│  │  - EC2 应用服务器                 │    │
+│  │  - 安全组：只允许 ALB 流量        │    │
+│  └─────────────────────────────────┘    │
+│  ┌─────────────────────────────────┐    │
+│  │ 数据子网（私有，最严格）           │    │
+│  │  - RDS（加密存储）                │    │
+│  │  - ElastiCache                   │    │
+│  │  - 安全组：只允许应用子网流量      │    │
+│  └─────────────────────────────────┘    │
+│                                          │
+│  VPC Endpoint → S3（病历文件，加密存储） │
+│  VPC Flow Logs → 记录所有网络流量       │
+└─────────────────────────────────────────┘
+    ↓
+CloudTrail（记录所有 API 操作）
+GuardDuty（智能威胁检测）
+Security Hub（统一安全视图）
+```
+
+---
+
+## 逐层安全设计
+
+### 第一层：传输安全
+
+**目标**：数据在网络上传输时不被窃听或篡改。
+
+| 措施 | 实现方式 |
+|------|----------|
+| 强制 HTTPS | CloudFront 配置：HTTP 自动重定向到 HTTPS |
+| TLS 证书 | ACM（AWS Certificate Manager）免费申请和管理证书 |
+| 最低 TLS 版本 | 设置为 TLS 1.2，禁用老旧的不安全协议 |
+
+### 第二层：边界防护
+
+**目标**：在流量到达应用之前，过滤掉恶意请求。
+
+| 措施 | 实现方式 |
+|------|----------|
+| Web 攻击防护 | WAF 启用核心规则集（SQL 注入、XSS） |
+| 频率限制 | WAF 规则：同一 IP 每分钟最多 100 次请求 |
+| 地域限制 | WAF 规则：只允许业务覆盖地区的访问 |
+| DDoS 防护 | Shield Standard（自动启用） |
+| 管理后台保护 | WAF 规则：管理后台只允许公司 IP 访问 |
+
+### 第三层：网络隔离
+
+**目标**：即使攻击者突破了边界，也无法横向移动到其他系统。
+
+| 措施 | 实现方式 |
+|------|----------|
+| 子网隔离 | 公有/应用/数据三层子网，层层隔离 |
+| 安全组最小化 | 每个组件只开放必要的端口和来源 |
+| 网络 ACL | 子网级别的额外防护，封禁已知恶意 IP |
+| 私有连接 | VPC Endpoint 访问 S3，不走公网 |
+| 流量监控 | VPC Flow Logs 记录所有网络通信 |
+
+### 第四层：身份与访问控制
+
+**目标**：确保只有正确的人和程序能访问正确的资源。
+
+| 措施 | 实现方式 |
+|------|----------|
+| 最小权限 | 每个 IAM 角色只有完成工作所需的最少权限 |
+| MFA 强制 | 所有人类用户必须启用 MFA |
+| 服务角色 | EC2 通过 IAM 角色访问其他服务，不使用长期密钥 |
+| 临时凭证 | 使用 STS 生成临时凭证，不使用永久 Access Key |
+| 条件限制 | 敏感操作要求 MFA + 公司 IP + 工作时间 |
+
+### 第五层：数据保护
+
+**目标**：即使数据被盗，攻击者也无法读取。
+
+| 措施 | 实现方式 |
+|------|----------|
+| 数据库加密 | RDS 启用 KMS 加密（静态加密） |
+| 文件加密 | S3 启用 SSE-KMS 加密 |
+| 密码管理 | 数据库密码存在 Secrets Manager，自动轮换 |
+| 字段级加密 | 特别敏感的字段（身份证号）在应用层额外加密 |
+| 备份加密 | 所有备份和快照都加密 |
+
+### 第六层：检测与响应
+
+**目标**：即使攻击发生了，也能快速发现并响应。
+
+| 措施 | 实现方式 |
+|------|----------|
+| 操作审计 | CloudTrail 记录所有 API 调用 |
+| 威胁检测 | GuardDuty 持续监控异常行为 |
+| 配置合规 | AWS Config 检测不合规的资源配置 |
+| 实时告警 | CloudWatch 告警 + SNS 通知安全团队 |
+| 统一视图 | Security Hub 汇总所有安全发现 |
+
+---
+
+## 安全事件响应流程
+
+当安全事件发生时：
+
+```
+1. 检测（GuardDuty 发现异常）
+   ↓
+2. 通知（SNS 发送告警给安全团队）
+   ↓
+3. 调查（CloudTrail 查看操作记录，Flow Logs 查看网络流量）
+   ↓
+4. 遏制（修改安全组切断攻击者访问，禁用被盗账号）
+   ↓
+5. 修复（修补漏洞，更换密钥，恢复数据）
+   ↓
+6. 复盘（分析根因，改进防护措施）
+```
+
+---
+
+## 安全服务速查表
+
+| 我想... | 用什么 |
+|---------|--------|
+| 控制谁能做什么 | IAM 策略 |
+| 加密存储的数据 | KMS |
+| 安全存储密码和密钥 | Secrets Manager |
+| 防御 Web 攻击 | WAF |
+| 防御 DDoS | Shield |
+| 检测账户异常行为 | GuardDuty |
+| 审计所有操作 | CloudTrail |
+| 检测配置不合规 | AWS Config |
+| 监控网络流量 | VPC Flow Logs |
+| 隔离网络资源 | VPC + 安全组 + 网络 ACL |
+| 统一安全管理 | Security Hub |
+
+---
+
+## 安全最佳实践清单
+
+1. **加密一切**：静态数据和传输数据都要加密
+2. **最小权限**：只给完成工作所需的最少权限
+3. **纵深防御**：多层防护，不依赖单一安全措施
+4. **审计一切**：所有操作都要有记录
+5. **自动化响应**：安全事件要能自动检测和通知
+6. **定期审查**：定期检查权限、规则、配置是否仍然合理
+7. **假设被攻破**：设计架构时假设任何一层都可能被突破
+
+---
+
+## 今天的小测验
+
+1. "纵深防御"是什么意思？为什么不能只依赖一层防护？
+2. 为什么数据库要放在私有子网而不是公有子网？
+3. 如果一个员工的 AWS 账号被盗，这个架构中哪些措施能帮助你发现和应对？
+4. 为什么要用 Secrets Manager 管理密码而不是写在配置文件里？
+
+---
+
+## 延伸阅读
+
+- [AWS 安全最佳实践](https://docs.aws.amazon.com/security/)
+- [AWS Well-Architected 安全支柱](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/)
+- [AWS Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/)
+
+---
+
+## 明天预告
+
+进入第四阶段：应用架构。明天学习容器技术——Docker 基础和 AWS ECS。了解为什么现代应用都在用容器，以及 AWS 如何帮你管理容器。

课程/第二阶段-核心服务/第08天-EC2入门.md

@@ -0,0 +1,186 @@
+# 第8天：EC2 入门——启动你的第一台云服务器
+
+## 今天你将学到什么
+
+今天是激动人心的一天——你将亲手启动人生中第一台云服务器。从点击"启动"到通过网络连接上它，整个过程不超过 5 分钟。
+
+---
+
+## EC2 是什么
+
+EC2 的全称是 Elastic Compute Cloud（弹性计算云）。说白了就是 AWS 提供的**虚拟电脑**。
+
+你可以把它想象成：你在网上"租"了一台电脑。这台电脑：
+- 放在 AWS 的数据中心里（不在你家）
+- 通过网络远程操作
+- 按使用时间收费（用一小时付一小时的钱）
+- 配置可以随时调整（觉得慢了可以升级，觉得浪费可以降级）
+
+**EC2 是 AWS 最基础、最重要的服务**，2006 年推出，至今仍是使用最广泛的服务。
+
+---
+
+## 启动一台 EC2 之前，你需要做 5 个选择
+
+就像买电脑要选配置一样，启动 EC2 也要做几个选择。别紧张，我一个个解释。
+
+### 选择 1：操作系统（AMI）
+
+AMI（Amazon Machine Image）就是操作系统的"安装盘"。
+
+常见选择：
+| AMI | 说明 | 适合 |
+|-----|------|------|
+| Amazon Linux 2023 | AWS 自己优化的 Linux | 学习首选，免费，和 AWS 集成最好 |
+| Ubuntu Server | 最流行的 Linux 发行版 | 社区资源丰富，教程多 |
+| Windows Server | 微软的服务器系统 | 需要运行 .NET 应用 |
+
+**学习建议**：选 Amazon Linux 2023，免费且轻量。
+
+### 选择 2：实例类型（配置）
+
+实例类型决定了这台"虚拟电脑"有多少 CPU 和内存。
+
+命名规则举例：`t3.micro`
+- `t3` = 系列名（t 系列是通用型，适合轻量工作）
+- `micro` = 大小（从小到大：nano → micro → small → medium → large → xlarge）
+
+**常见系列**：
+| 系列 | 特点 | 生活类比 |
+|------|------|----------|
+| t3/t4g | 通用型，适合轻量任务 | 家用轿车，日常代步够用 |
+| m5/m6i | 均衡型，CPU 和内存平衡 | SUV，什么都能干 |
+| c5/c6i | 计算型，CPU 强 | 跑车，速度快 |
+| r5/r6i | 内存型，内存大 | 大货车，装得多 |
+
+**学习阶段**：选 `t2.micro` 或 `t3.micro`，这是免费套餐包含的。
+
+### 选择 3：密钥对（登录凭证）
+
+密钥对是你远程登录服务器的"钥匙"。
+
+工作原理就像一把锁配一把钥匙：
+- 公钥（锁）→ 放在服务器上
+- 私钥（钥匙）→ 下载到你的电脑上
+
+**只有拿着私钥的人才能登录服务器。**
+
+创建密钥对时，私钥文件（.pem）只能下载一次。丢了就没了，只能重新创建。
+
+### 选择 4：网络和安全组
+
+**安全组**是 EC2 的"防火墙"，控制什么流量能进来、什么能出去。
+
+把安全组想象成你家的门禁系统：
+- 你可以设置"只允许快递员进入"（只开放特定端口）
+- 你可以设置"只允许我家人进入"（只允许特定 IP）
+- 默认是"谁都不让进"（所有入站流量被拒绝）
+
+**学习阶段的安全组配置**：
+| 类型 | 端口 | 来源 | 用途 |
+|------|------|------|------|
+| SSH | 22 | 你的 IP | 远程登录（Linux） |
+| RDP | 3389 | 你的 IP | 远程桌面（Windows） |
+| HTTP | 80 | 所有人 | 网站访问 |
+
+**安全提醒**：SSH 端口（22）绝对不要开放给"所有人"（0.0.0.0/0）。只允许你自己的 IP 地址。否则全世界的黑客都会来尝试登录你的服务器。
+
+### 选择 5：存储
+
+EC2 的"硬盘"叫 EBS（Elastic Block Store）。
+
+- 默认 8GB，学习够用
+- 类型选 gp3（通用 SSD），性价比最好
+- 可以后续扩容（但不能缩小）
+
+---
+
+## 动手：启动你的第一台实例
+
+1. 登录 AWS 控制台，搜索 "EC2"
+2. 点击 "启动实例"（Launch instance）
+3. **名称**：`my-first-server`
+4. **AMI**：Amazon Linux 2023（标有 Free tier eligible）
+5. **实例类型**：t2.micro（Free tier eligible）
+6. **密钥对**：点击"创建新密钥对"，命名为 `my-key`，下载 .pem 文件
+7. **网络设置**：勾选"允许来自我的 IP 的 SSH 流量"
+8. **存储**：默认 8GB gp3
+9. 点击 "启动实例"
+
+等待 1-2 分钟，实例状态变为 "Running"（运行中）。
+
+**恭喜！你的第一台云服务器已经在运行了。**
+
+---
+
+## 连接到你的服务器
+
+### 最简单的方式：EC2 Instance Connect（浏览器直连）
+
+1. 在 EC2 控制台选中你的实例
+2. 点击 "连接"（Connect）
+3. 选择 "EC2 Instance Connect" 标签
+4. 点击 "连接"
+
+浏览器会打开一个终端窗口，你已经在服务器里面了！
+
+试试输入：
+```
+whoami
+```
+会显示 `ec2-user`，这是你在服务器上的用户名。
+
+```
+uname -a
+```
+会显示服务器的操作系统信息。
+
+### 用终端 SSH 连接（更专业的方式）
+
+如果你用 Mac 或 Linux：
+```
+chmod 400 my-key.pem
+ssh -i my-key.pem ec2-user@你的公网IP
+```
+
+公网 IP 在 EC2 控制台的实例详情里可以找到。
+
+---
+
+## 实例的生命周期
+
+EC2 实例有几个状态，理解它们很重要（尤其是和计费相关）：
+
+| 状态 | 说明 | 是否计费 |
+|------|------|----------|
+| Running（运行中） | 正在运行 | 计费 |
+| Stopped（已停止） | 关机了，但"电脑"还在 | 不收计算费，但硬盘（EBS）仍收费 |
+| Terminated（已终止） | 彻底销毁，不可恢复 | 不计费 |
+
+**关键区别**：
+- **停止** = 关机。数据还在，下次可以重新开机。就像你的电脑关机了。
+- **终止** = 销毁。数据没了，实例消失了。就像你把电脑扔了。
+
+**学习完成后，记得停止或终止实例，避免持续计费！**
+
+---
+
+## 今天的小测验
+
+1. EC2 的 `t2.micro` 中，`t2` 和 `micro` 分别代表什么？
+2. 安全组的作用是什么？为什么 SSH 端口不能开放给所有人？
+3. "停止"和"终止"一台 EC2 实例有什么区别？
+4. 密钥对的私钥文件丢了怎么办？
+
+---
+
+## 延伸阅读
+
+- [EC2 实例类型完整列表](https://aws.amazon.com/ec2/instance-types/)
+- [EC2 入门教程](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html)
+
+---
+
+## 明天预告
+
+明天学习 EC2 的省钱秘籍：同样的服务器，不同的付费方式价格可以差 10 倍。按需、预留、Spot 实例各自适合什么场景？

课程/第二阶段-核心服务/第09天-EC2省钱策略.md

@@ -0,0 +1,173 @@
+# 第9天：EC2 省钱策略——同一台机器四种价格
+
+## 今天你将学到什么
+
+今天揭秘 AWS 的定价策略。同样配置的服务器，选对付费方式能省 60-90% 的钱。这不是理论——大公司每年靠这个省下数百万美元。
+
+---
+
+## 先理解一个核心概念
+
+AWS 的服务器硬件是一样的，但**付费方式**不同，价格天差地别。
+
+生活类比：同一间酒店房间——
+- 当天到前台订：全价 800 元/晚（按需）
+- 提前一年签约包房：400 元/晚（预留）
+- 凌晨 2 点在 APP 上抢尾房：80 元/晚（Spot）
+
+AWS 的逻辑完全一样。
+
+---
+
+## 四种购买方式
+
+### 1. 按需实例（On-Demand）— 最贵但最灵活
+
+**规则**：随时开，随时关，按秒计费，无任何承诺。
+
+**价格参考**（us-east-1，Linux）：
+- t3.micro：约 ¥0.07/小时
+- m5.large：约 ¥0.67/小时
+- c5.xlarge：约 ¥1.18/小时
+
+**适合场景**：
+- 刚开始学习和实验
+- 短期项目（跑几天就不用了）
+- 流量不可预测的新应用
+- 不确定需要多大配置，先试试
+
+**生活类比**：出差临时订酒店，贵但灵活。
+
+### 2. 预留实例 / Savings Plans — 承诺换折扣
+
+**规则**：承诺使用 1 年或 3 年，换取大幅折扣。
+
+**折扣幅度**：
+
+| 承诺方式 | 折扣 |
+|----------|------|
+| 1 年，不预付 | 约 36% |
+| 1 年，全预付 | 约 40% |
+| 3 年，不预付 | 约 50% |
+| 3 年，全预付 | 约 60% |
+
+**举个具体例子**：
+
+一台 m5.large 在 us-east-1：
+- 按需：$0.096/小时 × 24 × 365 = **$841/年**
+- 1 年预留（全预付）：**$505/年**（省 $336）
+- 3 年预留（全预付）：**$320/年**（省 $521）
+
+**适合场景**：
+- 7×24 小时运行的生产服务器
+- 数据库服务器（一直开着的）
+- 你确定未来 1-3 年都需要这台机器
+
+**生活类比**：和房东签长期租约，月租便宜很多。
+
+**Savings Plans（更灵活的替代方案）**：
+- 不锁定具体的实例类型，只承诺每小时花多少钱
+- 比如承诺"每小时至少花 $10"，换取折扣
+- 可以随时换实例类型、换 Region
+- 推荐新手用 Savings Plans 而不是传统预留实例
+
+### 3. Spot 实例 — 最便宜但随时可能被收回
+
+**规则**：使用 AWS 的闲置服务器，价格极低（按需的 10-30%），但 AWS 需要这些资源时会提前 2 分钟通知你，然后收回。
+
+**折扣幅度**：通常比按需便宜 60-90%。
+
+**举个例子**：
+- m5.large 按需：$0.096/小时
+- m5.large Spot：$0.03/小时（便宜 70%）
+
+**适合场景**：
+- 大数据分析（Hadoop/Spark 集群）
+- 机器学习模型训练
+- 视频转码、图片处理等批处理任务
+- CI/CD 构建（编译代码）
+- 任何"中断了可以重来"的任务
+
+**绝对不适合**：
+- 数据库（中断了数据可能丢失）
+- 在线服务的唯一实例（中断了用户就访问不了）
+- 任何不能容忍中断的关键服务
+
+**生活类比**：航空公司的"候补票"——便宜得多，但如果满员了你就上不了飞机。
+
+### 4. 专用主机（Dedicated Hosts）— 最贵
+
+**规则**：整台物理服务器只给你一个人用，不和别人共享。
+
+**适合场景**：
+- 法规要求物理隔离（某些金融、政府场景）
+- 使用按 CPU 核心数授权的商业软件（如 Oracle 数据库）
+
+学习阶段完全不需要关心这个选项。
+
+---
+
+## 聪明的组合策略
+
+成熟的公司不会只用一种方式，而是混合使用：
+
+```
+总计算需求
+├── 基线负载（70%）→ Savings Plans（稳定便宜）
+│   这部分是你确定一直需要的
+├── 可中断任务（20%）→ Spot 实例（超级便宜）
+│   大数据分析、批处理、训练模型
+└── 突发需求（10%）→ 按需实例（灵活应急）
+    临时的流量高峰、紧急项目
+```
+
+**真实案例**：某电商公司
+- 日常服务器用 Savings Plans：省 40%
+- 大促前临时加的服务器用按需：灵活
+- 后台数据分析用 Spot：省 70%
+- 综合下来比全用按需**省了 55%**
+
+---
+
+## 其他省钱技巧
+
+**选对实例类型**：
+- 很多人选了太大的实例，CPU 利用率常年只有 10-20%
+- 用 AWS Compute Optimizer 工具，它会分析你的使用情况并推荐合适的类型
+
+**选对 Region**：
+- 不同 Region 价格不同
+- us-east-1（弗吉尼亚）通常最便宜
+- 南美（圣保罗）比弗吉尼亚贵 40-50%
+
+**用 Graviton 实例**：
+- AWS 自研的 ARM 芯片
+- 比同配置的 Intel 实例便宜 20%，性能还更好
+- 实例类型带 `g` 的就是 Graviton（如 t4g、m6g、c6g）
+
+**开发测试环境下班关机**：
+- 用 AWS Instance Scheduler 自动定时开关机
+- 工作日 9:00 开机，18:00 关机 = 省 65% 的费用
+
+---
+
+## 今天的小测验
+
+1. 如果你有一台数据库服务器需要 7×24 运行 3 年，应该选哪种购买方式？
+2. Spot 实例为什么这么便宜？它的风险是什么？
+3. 一个机器学习训练任务（可以中断后重来）适合用什么实例？
+4. 为什么说"全用按需"是最贵的方案？
+
+---
+
+## 延伸阅读
+
+- [EC2 定价页面](https://aws.amazon.com/ec2/pricing/)
+- [Savings Plans 详解](https://aws.amazon.com/savingsplans/)
+- [Spot 实例最佳实践](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html)
+
+---
+
+## 明天预告
+
+明天学习 Auto Scaling 和负载均衡——让你的应用自动应对流量变化。流量来了自动加机器，流量走了自动减机器，再也不用半夜起来手动扩容了。

课程/第二阶段-核心服务/第10天-AutoScaling与负载均衡.md

@@ -0,0 +1,171 @@
+# 第10天：Auto Scaling 与负载均衡——自动应对流量洪峰
+
+## 今天你将学到什么
+
+今天学两个配合使用的服务：负载均衡器（ELB）和自动伸缩（Auto Scaling）。它们解决的问题是：**流量来了自动加机器，流量走了自动减机器，全程不需要人工干预。**
+
+---
+
+## 为什么需要这两个东西
+
+### 场景一：单台服务器的困境
+
+你开了一个网站，只有一台服务器。
+
+- 平时 100 人访问：没问题，服务器轻松应对
+- 突然上了热搜，10000 人同时涌入：服务器扛不住，网站崩了
+- 你手忙脚乱地加服务器，等你加好了，热度已经过了
+
+### 场景二：多台服务器的困境
+
+你学聪明了，一开始就部署了 10 台服务器。
+
+- 平时 100 人访问：9 台服务器在空转，白白烧钱
+- 突然 10000 人来了：可能还是不够
+- 你不知道该准备多少台才"刚好"
+
+**Auto Scaling + 负载均衡 = 完美解决方案**：
+- 负载均衡器：把用户请求均匀分配给多台服务器
+- Auto Scaling：根据流量自动增减服务器数量
+
+---
+
+## 负载均衡器（ELB）——流量的"交通警察"
+
+### 什么是负载均衡
+
+想象一个银行大厅有 5 个柜台窗口。门口有一个引导员（负载均衡器），他的工作是：
+- 看哪个窗口人少，就把新来的客户引导到那个窗口
+- 如果某个窗口的柜员去上厕所了（服务器故障），就不再往那个窗口引导人
+- 客户不需要自己选窗口，引导员帮你选最快的
+
+**负载均衡器做的就是这件事**：把用户的请求分发到多台健康的服务器上。
+
+### AWS 的三种负载均衡器
+
+| 类型 | 工作层级 | 适合场景 | 生活类比 |
+|------|----------|----------|----------|
+| ALB（应用负载均衡器） | HTTP/HTTPS 层 | 网站、API、微服务 | 餐厅领位员（根据你要吃什么引导到不同区域） |
+| NLB（网络负载均衡器） | TCP/UDP 层 | 游戏、IoT、超高性能 | 高速公路收费站（只管放行，不看车里装什么） |
+| GWLB（网关负载均衡器） | 网络层 | 防火墙、安全设备 | 安检通道 |
+
+**90% 的场景用 ALB 就够了。**
+
+### ALB 的智能路由
+
+ALB 不只是简单地"轮流分配"，它还能根据请求内容做智能路由：
+
+- 访问 `www.example.com/api/*` → 发到 API 服务器组
+- 访问 `www.example.com/images/*` → 发到图片服务器组
+- 访问 `admin.example.com` → 发到管理后台服务器
+
+### 健康检查
+
+ALB 会定期"问候"每台服务器："你还活着吗？"
+
+- 每隔 30 秒发一个请求到服务器的 `/health` 路径
+- 如果服务器连续几次没回应 → 标记为"不健康"
+- 不健康的服务器不再接收新的用户请求
+- 服务器恢复后，自动重新加入
+
+**用户完全感知不到某台服务器挂了**——因为 ALB 已经悄悄把流量切走了。
+
+---
+
+## Auto Scaling——自动增减服务器
+
+### 核心概念
+
+**启动模板**：新服务器的"配置清单"——用什么操作系统、什么实例类型、装什么软件。相当于"造机器的图纸"。
+
+**Auto Scaling 组（ASG）**：管理一群服务器，定义三个数字：
+- **最小值**（min）：保底数量，永远不会少于这个数。比如 2 台。
+- **期望值**（desired）：正常情况下的数量。比如 4 台。
+- **最大值**（max）：上限，防止无限扩展（防止账单爆炸）。比如 20 台。
+
+### 伸缩策略——什么时候加机器、什么时候减机器
+
+**策略一：目标跟踪（最简单，推荐新手用）**
+
+你只需要说："我希望所有服务器的平均 CPU 使用率保持在 50%。"
+
+然后 Auto Scaling 自动帮你：
+- CPU 超过 50% → 加机器
+- CPU 低于 50% → 减机器
+
+就像空调的恒温模式——你设定 25 度，空调自动调节制冷/制热。
+
+**策略二：计划伸缩（适合有规律的流量）**
+
+如果你知道流量的规律：
+- 每天早上 9 点流量开始上升 → 8:50 提前扩到 8 台
+- 每天晚上 10 点流量下降 → 22:00 缩回 3 台
+- 每周五下午流量特别大 → 周五 14:00 扩到 12 台
+
+就像定时开关灯——你知道什么时候需要，提前安排好。
+
+**策略三：步进伸缩（更精细的控制）**
+
+设置多个阈值：
+- CPU > 60% → 加 1 台
+- CPU > 80% → 加 3 台
+- CPU > 95% → 加 5 台（紧急！）
+- CPU < 30% → 减 1 台
+
+---
+
+## 两者配合的完整架构
+
+```
+用户访问你的网站
+        ↓
+    负载均衡器（ALB）
+    ┌───┼───┐
+    ↓   ↓   ↓
+  服务器A 服务器B 服务器C  ← Auto Scaling 管理
+  (AZ-a)  (AZ-b)  (AZ-c)     最小2台，最大10台
+```
+
+**工作流程**：
+1. 用户请求到达 ALB
+2. ALB 把请求分发给健康的服务器
+3. 如果流量增大，服务器 CPU 升高
+4. Auto Scaling 检测到 CPU 超标，自动启动新服务器
+5. 新服务器启动后，ALB 自动把它加入分发列表
+6. 流量下降后，Auto Scaling 自动关闭多余的服务器
+
+**全程无需人工干预。**
+
+---
+
+## 一个真实的例子
+
+某在线教育平台：
+- 工作日白天：5000 并发用户 → 需要 5 台服务器
+- 周末晚上直播课：50000 并发用户 → 需要 50 台服务器
+- 凌晨 3 点：100 并发用户 → 需要 2 台服务器
+
+如果固定 50 台服务器：每月费用约 $3,600
+用 Auto Scaling：每月费用约 $800（省了 78%）
+
+---
+
+## 今天的小测验
+
+1. 负载均衡器的作用是什么？用你自己的话解释。
+2. Auto Scaling 的"最小值、期望值、最大值"分别是什么意思？
+3. 如果你的网站流量每天早上 9 点开始增长，应该用什么伸缩策略？
+4. 为什么要设置"最大值"？不设会怎样？
+
+---
+
+## 延伸阅读
+
+- [ELB 产品介绍](https://aws.amazon.com/elasticloadbalancing/)
+- [Auto Scaling 用户指南](https://docs.aws.amazon.com/autoscaling/ec2/userguide/)
+
+---
+
+## 明天预告
+
+明天进入无服务器计算：AWS Lambda。不用管服务器，只写一个函数，AWS 帮你运行。按调用次数付费，不调用不花钱。

课程/第二阶段-核心服务/第11天-Lambda无服务器计算.md

@@ -0,0 +1,176 @@
+# 第11天：AWS Lambda——不用管服务器的计算
+
+## 今天你将学到什么
+
+今天学习一种全新的计算方式：无服务器（Serverless）。你不需要启动任何服务器，只需要写一段代码（函数），AWS 帮你运行。用一次付一次的钱，不用的时候一分钱不花。
+
+---
+
+## 什么是"无服务器"
+
+"无服务器"这个名字容易让人误解——当然还是有服务器的，只是**你不需要管理它**。
+
+**传统方式（EC2）**：
+你租了一台服务器 → 你要选配置、装系统、部署代码、打补丁、监控运行状态、处理故障...
+
+**无服务器方式（Lambda）**：
+你写了一段代码 → 上传到 AWS → 有人触发时 AWS 自动运行 → 运行完毕自动释放
+
+**生活类比**：
+
+- EC2 像是你**雇了一个全职员工**：不管有没有活干，你都要付工资。他生病了你还得找人替班。
+- Lambda 像是你**叫了一个兼职**：有活的时候叫他来干，干完就走，按小时付钱。没活的时候不花钱。
+
+---
+
+## Lambda 怎么工作
+
+Lambda 的执行单位是"函数"。一个函数就是一段代码，它的生命周期很简单：
+
+```
+某个事件发生 → 触发你的函数 → 函数执行 → 返回结果 → 结束
+```
+
+### 什么能触发 Lambda？
+
+几乎 AWS 生态中的任何事件都能触发 Lambda：
+
+| 触发源 | 场景举例 |
+|--------|----------|
+| 用户访问 API | 用户点击"提交订单"，触发处理订单的函数 |
+| 文件上传到 S3 | 用户上传了一张照片，自动触发压缩和生成缩略图 |
+| 数据库数据变化 | 用户修改了个人资料，自动触发同步到搜索引擎 |
+| 定时触发 | 每天凌晨 2 点自动生成报表 |
+| 消息队列 | 有新订单消息进入队列，触发发货通知 |
+
+### 一个具体的例子
+
+**场景**：用户上传头像，需要自动生成三种尺寸的缩略图。
+
+**传统做法**：
+- 启动一台 EC2 服务器
+- 安装图片处理软件
+- 写一个程序持续监听上传事件
+- 服务器 7×24 运行，即使没人上传也在空转
+
+**Lambda 做法**：
+- 写一个函数：接收图片 → 生成三种尺寸 → 保存回 S3
+- 配置触发器：S3 有新文件上传时触发
+- 完成！
+
+有人上传时函数自动运行，没人上传时什么都不发生（也不花钱）。
+
+---
+
+## Lambda 的计费方式
+
+Lambda 的计费精确到不可思议：
+
+**按两个维度收费**：
+1. **请求次数**：每调用一次函数算一次请求
+2. **执行时长**：函数运行了多长时间 × 分配了多少内存
+
+**免费额度（永久免费，不是 12 个月）**：
+- 每月 100 万次请求免费
+- 每月 40 万 GB-秒计算时间免费
+
+**这意味着什么？**
+
+假设你的函数：
+- 分配 128MB 内存
+- 每次执行 200 毫秒
+- 每月调用 100 万次
+
+计算：100万 × 0.2秒 × 0.125GB = 25,000 GB-秒
+
+这完全在免费额度内。**一分钱不花。**
+
+对于个人项目和小型应用，Lambda 几乎是免费的。
+
+---
+
+## Lambda 的限制
+
+Lambda 不是万能的，它有一些限制：
+
+| 限制 | 值 | 意味着什么 |
+|------|-----|-----------|
+| 最长运行时间 | 15 分钟 | 不能跑长时间任务 |
+| 最大内存 | 10GB | 不能处理超大数据集 |
+| 部署包大小 | 250MB（解压后） | 不能打包太多依赖 |
+| 并发数 | 1000（默认） | 同时最多 1000 个函数在跑 |
+
+---
+
+## Lambda 适合什么，不适合什么
+
+### 非常适合 Lambda 的场景
+
+- **API 后端**：用户请求来了处理一下返回结果（配合 API Gateway）
+- **文件处理**：图片压缩、视频转码、PDF 生成
+- **定时任务**：每天发报表、清理过期数据、健康检查
+- **事件响应**：用户注册后发欢迎邮件、订单创建后通知仓库
+- **数据转换**：从一个格式转成另一个格式
+
+### 不适合 Lambda 的场景
+
+- **长时间运行的任务**：超过 15 分钟的任务（比如训练机器学习模型）
+- **需要持续连接的服务**：WebSocket 服务器、游戏服务器
+- **高性能计算**：需要 GPU 或大量 CPU 的任务
+- **有状态的应用**：需要在内存中保持数据的服务
+
+---
+
+## Lambda vs EC2：什么时候用哪个
+
+| 我的需求是... | 选择 |
+|--------------|------|
+| 处理偶尔的事件（每天几百次到几万次） | Lambda |
+| 7×24 持续运行的服务 | EC2 |
+| 不想管任何服务器 | Lambda |
+| 需要完全控制运行环境 | EC2 |
+| 运行时间可能超过 15 分钟 | EC2 |
+| 流量极不稳定（有时 0，有时暴涨） | Lambda |
+| 稳定的高流量 | EC2（更便宜） |
+
+**很多项目是混合使用的**：
+- 主要的 Web 服务跑在 EC2/ECS 上
+- 后台的定时任务、文件处理用 Lambda
+- 这样既有稳定性，又有灵活性
+
+---
+
+## 冷启动问题
+
+Lambda 有一个需要了解的特性：**冷启动**。
+
+当你的函数一段时间没被调用，AWS 会回收它的运行环境。下次调用时需要重新准备环境，这个过程叫"冷启动"，会增加几百毫秒到几秒的延迟。
+
+**就像**：你叫了一个兼职，如果他正好在附近（热启动），马上就能开始干活。如果他在家（冷启动），需要先赶过来。
+
+**解决方案**：
+- 对于大多数场景，几百毫秒的冷启动完全可以接受
+- 如果对延迟要求极高，可以使用"预置并发"（Provisioned Concurrency）——提前准备好运行环境，但要额外付费
+
+---
+
+## 今天的小测验
+
+1. "无服务器"是不是真的没有服务器？这个名字的含义是什么？
+2. Lambda 的计费方式和 EC2 有什么本质区别？
+3. 举一个适合用 Lambda 的场景和一个不适合的场景。
+4. 什么是"冷启动"？它会造成什么影响？
+
+---
+
+## 延伸阅读
+
+- [Lambda 开发者指南](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+- [Serverless Land — 模式和示例](https://serverlessland.com/)
+- [Lambda 定价计算器](https://aws.amazon.com/lambda/pricing/)
+
+---
+
+## 明天预告
+
+明天进入存储领域：S3 对象存储。它是 AWS 最早的服务之一，也是用途最广的服务——从存网站图片到做大数据湖，几乎无处不在。

课程/第二阶段-核心服务/第12天-S3对象存储.md

@@ -0,0 +1,174 @@
+# 第12天：S3 对象存储——AWS 的万能仓库
+
+## 今天你将学到什么
+
+S3（Simple Storage Service）是 AWS 最早的服务（2006 年上线），也是用途最广的服务。从存一张图片到建一个数据湖，它几乎无处不在。
+
+今天学完你会明白：S3 是什么、怎么用、怎么省钱、怎么保护数据安全。
+
+---
+
+## S3 是什么
+
+S3 是一个**对象存储**服务。
+
+"对象存储"是什么意思？先和你熟悉的东西对比：
+
+| 存储类型 | 类比 | 特点 |
+|----------|------|------|
+| 块存储（EBS） | 电脑硬盘 | 挂载到一台电脑上，可以装操作系统 |
+| 文件存储（EFS） | 共享文件夹 | 多台电脑可以同时访问 |
+| 对象存储（S3） | 网盘/云盘 | 通过网络上传下载，无限容量 |
+
+**S3 的核心特点**：
+- **无限容量**：想存多少存多少，没有上限
+- **极高耐久性**：99.999999999%（11 个 9）的数据不丢失概率。意味着如果你存了 1000 万个文件，平均 1 万年才可能丢 1 个。
+- **通过网络访问**：用 URL 或 API 上传下载，不是挂载为磁盘
+- **按量付费**：存了多少 GB 付多少钱
+
+---
+
+## 核心概念
+
+### 桶（Bucket）
+
+桶是存放文件的"容器"，类似于你电脑上的一个顶级文件夹。
+
+**重要规则**：
+- 桶的名字**全球唯一**——全世界所有 AWS 用户共享一个命名空间。如果有人用了 `my-photos`，你就不能再用这个名字了。
+- 创建桶时要选择一个 Region，你的数据就存在那个 Region 里。
+- 一个 AWS 账户最多 100 个桶（可以申请增加）。
+
+**命名建议**：用有意义的前缀，比如 `公司名-项目名-用途`：
+- `mycompany-webapp-images`
+- `mycompany-logs-2024`
+
+### 对象（Object）
+
+对象就是你存进去的文件。每个对象由三部分组成：
+
+- **Key（键）**：文件的"路径名"，比如 `photos/2024/vacation/beach.jpg`
+- **Value（值）**：文件的实际内容（最大 5TB）
+- **Metadata（元数据）**：关于文件的附加信息（类型、大小、创建时间等）
+
+**注意**：虽然 Key 里有 `/`，看起来像文件夹结构，但 S3 实际上是**扁平的**——没有真正的文件夹。控制台显示的"文件夹"只是为了方便你浏览。
+
+---
+
+## S3 能用来做什么
+
+S3 的用途广得超乎想象：
+
+| 用途 | 说明 |
+|------|------|
+| 静态网站托管 | 把 HTML/CSS/JS 放在 S3 上，直接当网站用 |
+| 图片/视频存储 | APP 的用户头像、上传的视频 |
+| 备份 | 数据库备份、服务器快照 |
+| 日志存储 | 各种服务的运行日志 |
+| 大数据湖 | 集中存储所有原始数据，供分析使用 |
+| 软件分发 | 存放安装包、更新文件 |
+| 灾难恢复 | 跨 Region 复制关键数据 |
+
+---
+
+## 存储类别——同样的文件，不同的价格
+
+S3 有多种存储类别，核心逻辑是：**访问越频繁的数据越贵，访问越少的数据越便宜。**
+
+用仓库来类比：
+- 经常用的东西放在手边的架子上（贵，但拿取方便）
+- 偶尔用的东西放在仓库深处（便宜，但找起来费时间）
+- 几年不用的东西放在异地仓库（最便宜，但取回来要等很久）
+
+| 存储类别 | 适合什么数据 | 存储费用 | 取回速度 |
+|----------|-------------|----------|----------|
+| Standard（标准） | 经常访问的数据 | 最高 | 即时 |
+| Standard-IA（低频访问） | 每月访问一两次 | 较低 | 即时 |
+| Glacier Instant | 每季度访问一次 | 更低 | 即时 |
+| Glacier Flexible | 每年访问一两次 | 很低 | 分钟到小时 |
+| Glacier Deep Archive | 几年才访问一次 | 最低 | 12-48 小时 |
+| Intelligent-Tiering | 不确定访问频率 | 自动优化 | 即时 |
+
+**举个具体的价格对比**（us-east-1，存 1TB 数据一个月）：
+- Standard：$23/月
+- Standard-IA：$12.5/月
+- Glacier Deep Archive：$1/月
+
+差距巨大！所以把不常用的数据移到便宜的层级，能省很多钱。
+
+### Intelligent-Tiering（智能分层）
+
+如果你不确定数据的访问频率，选这个最省心：
+- S3 自动监控每个文件的访问频率
+- 30 天没访问 → 自动移到低频层
+- 90 天没访问 → 自动移到归档层
+- 再次访问时 → 自动移回高频层
+
+你不需要做任何事情，S3 帮你自动优化成本。
+
+---
+
+## 生命周期规则——自动管理数据
+
+你可以设置规则，让 S3 自动帮你管理数据的"一生"：
+
+**例子：日志文件的生命周期**
+```
+上传（Standard）
+    → 30 天后自动转为 Standard-IA（不常看了）
+    → 90 天后自动转为 Glacier（归档保存）
+    → 365 天后自动删除（不需要了）
+```
+
+设置一次，永远自动执行。不用你记着去手动清理。
+
+---
+
+## 数据安全
+
+### 默认私有
+
+S3 的数据**默认是私有的**——只有你自己能访问。别人既看不到也下载不了。
+
+### 加密
+
+- **传输加密**：数据在网络上传输时自动加密（HTTPS）
+- **存储加密**：数据存在磁盘上时也是加密的（默认启用）
+
+### 版本控制
+
+开启版本控制后，S3 会保留文件的所有历史版本：
+- 不小心覆盖了文件？可以恢复到之前的版本
+- 不小心删除了文件？可以找回来（删除只是加了个标记）
+
+**就像文档的"历史版本"功能**——你可以回到任何一个时间点的状态。
+
+### 防止公开访问
+
+AWS 提供了一个总开关叫 "Block Public Access"（阻止公开访问）：
+- 默认开启
+- 即使你不小心设置了公开权限，这个开关也会阻止
+- 除非你明确需要公开（比如托管静态网站），否则不要关闭它
+
+---
+
+## 今天的小测验
+
+1. S3 的"桶名全球唯一"是什么意思？
+2. 如果你有一批日志文件，前 7 天经常查看，之后很少看，1 年后可以删除，应该怎么设置生命周期规则？
+3. S3 Standard 和 Glacier Deep Archive 的价格差多少倍？各自适合什么数据？
+4. 为什么说 S3 没有真正的"文件夹"？
+
+---
+
+## 延伸阅读
+
+- [S3 用户指南](https://docs.aws.amazon.com/AmazonS3/latest/userguide/)
+- [S3 定价详情](https://aws.amazon.com/s3/pricing/)
+- [S3 安全最佳实践](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html)
+
+---
+
+## 明天预告
+
+明天学习 EBS 和 EFS——块存储和文件存储。搞清楚它们和 S3 的区别：什么时候用"硬盘"，什么时候用"共享文件夹"，什么时候用"网盘"。

课程/第二阶段-核心服务/第13天-EBS与EFS存储.md

@@ -0,0 +1,171 @@
+# 第13天：EBS 与 EFS——块存储和文件存储
+
+## 今天你将学到什么
+
+昨天学了 S3（对象存储），今天学另外两种存储：EBS（块存储）和 EFS（文件存储）。学完你就能搞清楚：什么时候用"硬盘"，什么时候用"共享文件夹"，什么时候用"网盘"。
+
+---
+
+## 三种存储的区别——用办公室来理解
+
+想象你在一个办公室工作：
+
+**EBS（块存储）= 你桌上的抽屉**
+- 只有你一个人能用（一个 EBS 卷通常只能挂载到一台 EC2）
+- 速度最快（就在手边）
+- 大小固定（抽屉就那么大，想换大的要买新的）
+- 电脑关机了抽屉还在（数据持久化）
+
+**EFS（文件存储）= 办公室的共享文件柜**
+- 所有人都能用（多台 EC2 可以同时访问）
+- 速度还行（要走几步路去文件柜）
+- 大小自动调整（文件多了自动加柜子，少了自动减）
+- 大家看到的是同一份文件
+
+**S3（对象存储）= 公司的云盘**
+- 通过网络访问（打开浏览器上传下载）
+- 容量无限
+- 不能直接当"硬盘"用（不能在上面安装软件或运行程序）
+- 适合存放不经常修改的文件
+
+---
+
+## EBS（Elastic Block Store）详解
+
+EBS 是 EC2 实例的"硬盘"。每台 EC2 至少需要一个 EBS 卷来存放操作系统。
+
+### EBS 的特点
+
+- **持久化**：即使 EC2 实例停止了，EBS 上的数据还在（就像电脑关机了硬盘数据不会丢）
+- **同一 AZ**：EBS 卷和 EC2 实例必须在同一个可用区
+- **可以扩容**：硬盘不够大了可以扩容（但不能缩小）
+- **可以做快照**：把当前状态"拍照"保存，以后可以从快照恢复
+
+### EBS 卷的类型
+
+就像买硬盘有 SSD 和机械硬盘之分：
+
+| 类型 | 名称 | 速度 | 价格 | 适合场景 |
+|------|------|------|------|----------|
+| gp3 | 通用 SSD | 快 | 中等 | **大多数场景首选** |
+| io2 | 高性能 SSD | 最快 | 贵 | 数据库、对速度要求极高的应用 |
+| st1 | 吞吐优化 HDD | 中等 | 便宜 | 大数据、日志处理（顺序读写多） |
+| sc1 | 冷存储 HDD | 慢 | 最便宜 | 很少访问的数据 |
+
+**学习阶段选 gp3 就对了**，性价比最好。
+
+### EBS 快照（Snapshot）
+
+快照就是给硬盘"拍照"——记录某一时刻的完整状态。
+
+**用途**：
+- **备份**：定期给数据库的硬盘拍快照，万一数据损坏可以恢复
+- **复制**：从快照创建新的 EBS 卷（可以跨可用区甚至跨 Region）
+- **创建 AMI**：把配置好的服务器做成模板，以后快速复制
+
+**快照是增量的**：第一次拍全量，之后只保存变化的部分。所以不会占用太多空间。
+
+### EBS 的限制
+
+- 通常只能挂载到**一台** EC2 实例（就像一块硬盘只能插在一台电脑上）
+- 必须和 EC2 在**同一个可用区**（不能跨 AZ 挂载）
+- 大小需要**预先指定**（虽然可以扩容，但不能缩小）
+
+---
+
+## EFS（Elastic File System）详解
+
+EFS 是一个共享文件系统，多台 EC2 可以同时读写同一个文件系统。
+
+### 什么时候需要 EFS
+
+**场景一：Web 服务器集群共享文件**
+
+你有 5 台 Web 服务器（通过 Auto Scaling 管理），它们都需要访问同一批用户上传的文件。
+
+- 用 EBS？每台服务器有自己的硬盘，文件不同步。用户上传到服务器 A 的文件，服务器 B 看不到。
+- 用 EFS？所有服务器挂载同一个文件系统，文件自动同步。用户上传一次，所有服务器都能看到。
+
+**场景二：容器共享数据**
+
+多个容器需要读写同一批配置文件或数据文件。
+
+**场景三：机器学习训练**
+
+多台训练机器需要读取同一个大型数据集。
+
+### EFS 的特点
+
+- **自动伸缩**：不需要预设容量。存了 1GB 就占 1GB 的空间，存了 1TB 就占 1TB。用多少算多少。
+- **多实例共享**：几百台 EC2 可以同时挂载同一个 EFS
+- **跨可用区**：数据自动在多个 AZ 间复制（高可用）
+- **标准文件系统接口**：对应用来说就像本地文件夹一样，不需要修改代码
+
+### EFS 的存储类别
+
+和 S3 类似，EFS 也有分层存储来省钱：
+
+| 类别 | 说明 | 价格 |
+|------|------|------|
+| Standard | 经常访问的文件 | $0.30/GB/月 |
+| Infrequent Access | 不常访问的文件 | $0.025/GB/月 |
+
+可以设置生命周期策略：30 天没访问的文件自动移到 IA 层，再次访问时自动移回来。
+
+### EFS vs EBS 对比
+
+| 特性 | EBS | EFS |
+|------|-----|-----|
+| 类比 | 个人硬盘 | 共享文件柜 |
+| 访问方式 | 一台 EC2 独占 | 多台 EC2 共享 |
+| 容量 | 预设大小 | 自动伸缩 |
+| 跨 AZ | 不支持 | 支持 |
+| 速度 | 更快（本地挂载） | 稍慢（网络文件系统） |
+| 价格 | 较便宜 | 较贵 |
+| 适合 | 数据库、操作系统盘 | 共享内容、容器存储 |
+
+---
+
+## 怎么选择存储类型
+
+遇到存储需求时，问自己这几个问题：
+
+```
+需要当"硬盘"用（装系统、跑数据库）？
+  → EBS
+
+需要多台机器共享同一批文件？
+  → EFS
+
+通过 API/URL 上传下载，不需要挂载为磁盘？
+  → S3
+
+需要 Windows 文件共享（SMB 协议）？
+  → FSx for Windows
+
+需要超高性能的并行文件系统（HPC/机器学习）？
+  → FSx for Lustre
+```
+
+---
+
+## 今天的小测验
+
+1. EBS 和 EFS 最大的区别是什么？
+2. 如果你有 3 台 Web 服务器需要访问同一批图片文件，应该用 EBS 还是 EFS？为什么？
+3. EBS 快照有什么用？它是全量备份还是增量备份？
+4. 为什么 EBS 不能跨可用区挂载？
+
+---
+
+## 延伸阅读
+
+- [EBS 卷类型对比](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html)
+- [EFS 用户指南](https://docs.aws.amazon.com/efs/latest/ug/)
+- [AWS 存储服务选择指南](https://aws.amazon.com/products/storage/)
+
+---
+
+## 明天预告
+
+明天进入数据库领域：RDS（关系型数据库服务）。让 AWS 帮你管理 MySQL、PostgreSQL，你再也不用半夜被叫起来修数据库了。

课程/第二阶段-核心服务/第14天-RDS托管数据库.md

@@ -0,0 +1,186 @@
+# 第14天：RDS——托管关系型数据库
+
+## 今天你将学到什么
+
+今天学习 RDS（Relational Database Service），AWS 的托管数据库服务。简单说就是：AWS 帮你装好数据库、帮你备份、帮你打补丁、帮你做高可用，你只管用。
+
+---
+
+## 为什么不自己装数据库
+
+你完全可以在 EC2 上自己安装 MySQL。但这意味着你要负责：
+
+| 你要做的事 | 频率 | 难度 |
+|-----------|------|------|
+| 安装数据库软件 | 一次 | 中 |
+| 配置参数调优 | 偶尔 | 高 |
+| 定期备份 | 每天 | 中 |
+| 测试备份能否恢复 | 每月 | 高 |
+| 打安全补丁 | 每月 | 中 |
+| 版本升级 | 每年 | 高 |
+| 配置主从复制（高可用） | 一次 | 很高 |
+| 主库挂了手动切换 | 紧急 | 很高 |
+| 磁盘快满了扩容 | 偶尔 | 中 |
+| 监控性能问题 | 持续 | 高 |
+
+**用 RDS 的话**：以上所有事情 AWS 帮你做。你只需要关心：
+- 数据库表怎么设计
+- SQL 查询怎么写
+- 应用怎么连接数据库
+
+**生活类比**：自己装数据库就像自己养一头奶牛（要喂草、挤奶、看病）。用 RDS 就像订牛奶（每天送到门口，你只管喝）。
+
+---
+
+## RDS 支持哪些数据库
+
+| 数据库引擎 | 特点 | 适合场景 |
+|-----------|------|----------|
+| MySQL | 最流行的开源数据库 | Web 应用、博客、电商 |
+| PostgreSQL | 功能最强的开源数据库 | 复杂查询、地理数据、JSON 数据 |
+| MariaDB | MySQL 的社区分支 | MySQL 的替代品 |
+| Oracle | 老牌商业数据库 | 传统企业应用 |
+| SQL Server | 微软的数据库 | .NET 应用 |
+| Aurora | AWS 自研，兼容 MySQL/PostgreSQL | **性能最好，推荐新项目使用** |
+
+**新手建议**：学习用 MySQL 或 PostgreSQL（免费、资料多）。正式项目推荐 Aurora（性能是普通 MySQL 的 5 倍）。
+
+---
+
+## RDS 帮你做了什么
+
+### 自动备份
+
+- 每天自动给数据库拍一次"快照"
+- 保留 1-35 天（你设置）
+- 支持**时间点恢复**：可以恢复到过去任意一秒的状态
+
+**举个例子**：今天下午 3 点有人误删了一张重要的表。你可以把数据库恢复到下午 2:59 的状态，数据就回来了。
+
+### 自动打补丁
+
+- 数据库软件有安全漏洞时，AWS 自动帮你更新
+- 在你指定的维护窗口执行（比如每周日凌晨 3 点）
+- 不需要你操心
+
+### 监控
+
+- 自动收集 CPU、内存、磁盘、连接数等指标
+- 可以设置告警（比如磁盘使用率超过 80% 就通知你）
+
+---
+
+## 高可用：Multi-AZ（多可用区部署）
+
+这是 RDS 最重要的功能之一。
+
+### 问题：数据库挂了怎么办？
+
+如果你的数据库只有一台，它所在的数据中心停电了、硬盘坏了、或者发生了任何故障，你的整个应用就瘫痪了。
+
+### 解决方案：Multi-AZ
+
+开启 Multi-AZ 后，AWS 会自动在另一个可用区创建一个**备用数据库**：
+
+```
+你的应用
+    ↓
+数据库连接地址（DNS）
+    ↓
+┌─────────────────────────────────┐
+│  可用区 A：主数据库（处理所有读写）│
+│  可用区 B：备用数据库（实时同步）  │
+└─────────────────────────────────┘
+```
+
+**工作原理**：
+1. 平时所有读写都走主数据库
+2. 主数据库的每一笔写入都实时同步到备用数据库
+3. 如果主数据库挂了，AWS 自动在 60-120 秒内切换到备用数据库
+4. 你的应用不需要改任何代码（因为连接地址没变，DNS 自动指向新的主库）
+
+**你的用户甚至感觉不到数据库切换了。**
+
+---
+
+## 只读副本（Read Replica）
+
+### 问题：数据库读取压力太大怎么办？
+
+很多应用是"读多写少"的——比如电商网站，浏览商品（读）的人远多于下单（写）的人。一台数据库扛不住这么多读取请求。
+
+### 解决方案：只读副本
+
+创建一个或多个"只读副本"，专门处理读取请求：
+
+```
+你的应用
+├── 写操作（下单、修改资料）→ 主数据库
+└── 读操作（浏览商品、查看订单）→ 只读副本 1 / 只读副本 2
+```
+
+**特点**：
+- 数据从主库异步复制到只读副本（有轻微延迟，通常几毫秒）
+- 最多可以创建 5 个只读副本（Aurora 可以 15 个）
+- 可以跨 Region 创建（让全球用户就近读取）
+
+### Multi-AZ vs 只读副本
+
+| | Multi-AZ | 只读副本 |
+|--|----------|----------|
+| 目的 | 高可用（防故障） | 性能扩展（分担读取压力） |
+| 能否读取 | 不能（纯备份） | 能（专门用来读） |
+| 数据同步 | 同步（实时） | 异步（有轻微延迟） |
+| 故障切换 | 自动 | 需要手动提升为主库 |
+| 跨 Region | 不支持 | 支持 |
+
+**两者可以同时使用**：Multi-AZ 保证不挂，只读副本保证不慢。
+
+---
+
+## Aurora：AWS 的王牌数据库
+
+Aurora 是 AWS 自己重新设计的数据库引擎，兼容 MySQL 和 PostgreSQL（意味着你的代码不用改），但性能和可靠性远超标准版本。
+
+**Aurora 的优势**：
+- 性能是标准 MySQL 的 **5 倍**
+- 存储自动增长（10GB 到 128TB），不需要预设
+- 数据自动复制 **6 份**，分布在 3 个可用区
+- 即使丢失 2 份数据仍可写入，丢失 3 份仍可读取
+
+**Aurora Serverless**：
+- 自动根据负载调整计算能力
+- 没有请求时可以缩到 0（不收计算费）
+- 适合流量不稳定的应用、开发测试环境
+
+---
+
+## 安全配置
+
+- **放在私有子网**：数据库不应该有公网 IP，只允许应用服务器访问
+- **安全组**：只开放数据库端口（MySQL 3306，PostgreSQL 5432）给应用服务器
+- **加密**：启用存储加密和传输加密
+- **不要用 Root 密码连接**：创建专用的数据库用户，给最小权限
+
+---
+
+## 今天的小测验
+
+1. 用 RDS 和自己在 EC2 上装数据库，最大的区别是什么？
+2. Multi-AZ 解决什么问题？只读副本解决什么问题？
+3. 为什么 Multi-AZ 的备用数据库不能用来读取数据？
+4. Aurora 相比普通 MySQL RDS 有什么优势？
+
+---
+
+## 延伸阅读
+
+- [RDS 用户指南](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/)
+- [Aurora 用户指南](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/)
+- [RDS 免费套餐详情](https://aws.amazon.com/rds/free/)
+
+---
+
+## 明天预告
+
+明天学习 DynamoDB——AWS 的 NoSQL 数据库。它和 RDS 完全不同：没有表结构、没有 SQL、但能处理每秒数百万次请求且延迟稳定在个位数毫秒。

课程/第二阶段-核心服务/第15天-DynamoDB数据库.md

@@ -0,0 +1,170 @@
+# 第15天：DynamoDB——NoSQL 数据库
+
+## 今天你将学到什么
+
+今天学习一种和 RDS 完全不同的数据库：DynamoDB。它是 AWS 的 NoSQL 数据库，专为超大规模和超低延迟设计。
+
+---
+
+## 先搞清楚：什么是 NoSQL
+
+**SQL 数据库（关系型，如 MySQL）**：
+- 数据存在"表"里，有固定的列（像 Excel 表格）
+- 用 SQL 语言查询
+- 擅长复杂查询（多表关联、聚合统计）
+- 扩展有上限（一台机器的 CPU/内存是有限的）
+
+**NoSQL 数据库（如 DynamoDB）**：
+- 数据结构灵活（每条记录可以有不同的字段）
+- 不用 SQL，用 API 查询
+- 查询方式受限（主要通过"键"来查）
+- 可以无限水平扩展（加机器就能扩容）
+
+**生活类比**：
+
+- SQL 数据库像**图书馆的目录卡片柜**：每张卡片格式统一（书名、作者、出版社、ISBN），可以按任意字段检索，但柜子大小有限。
+- NoSQL 数据库像**快递柜**：每个格子有一个编号（键），你用编号就能极快地取到东西。但你不能说"帮我找出所有重量超过 5 公斤的包裹"——它不支持这种查询。
+
+---
+
+## DynamoDB 的特点
+
+- **完全托管**：不需要装软件、不需要管服务器、不需要做备份
+- **无限扩展**：从每秒几个请求到每秒数百万个请求，自动扩展
+- **稳定延迟**：无论数据量是 1GB 还是 100TB，读写延迟都是个位数毫秒
+- **高可用**：数据自动复制到 3 个可用区
+- **按量付费**：可以选择按请求次数付费，不用不花钱
+
+---
+
+## 核心概念——用通讯录来理解
+
+想象你有一个手机通讯录：
+
+### 表（Table）
+
+通讯录本身就是一张"表"。
+
+### 项目（Item）
+
+通讯录里的每个联系人就是一个"项目"（相当于 SQL 里的一行）。
+
+### 属性（Attribute）
+
+每个联系人的信息（姓名、电话、地址）就是"属性"（相当于 SQL 里的列）。
+
+**但和 SQL 不同的是**：DynamoDB 的每个项目可以有不同的属性。
+
+比如：
+- 张三：{姓名, 手机, 邮箱, 公司}
+- 李四：{姓名, 手机, 微信号}（没有邮箱和公司）
+- 王五：{姓名, 座机, 地址, 生日}（没有手机）
+
+在 MySQL 里，你必须预先定义好所有列。在 DynamoDB 里，每条记录想有什么字段就有什么字段。
+
+### 主键（Primary Key）
+
+主键是查找数据的"入口"，是你必须定义的唯一结构。
+
+**两种主键类型**：
+
+**类型一：分区键（Partition Key）**
+- 单个属性作为主键
+- 必须唯一标识每个项目
+- 例：用户 ID、订单号
+
+**类型二：分区键 + 排序键（Partition Key + Sort Key）**
+- 两个属性组合作为主键
+- 分区键相同的项目存在一起，按排序键排序
+- 例：用户 ID（分区键）+ 订单时间（排序键）
+
+**举个例子**：电商的订单表
+
+| 用户ID（分区键） | 下单时间（排序键） | 商品 | 金额 |
+|-----------------|-------------------|------|------|
+| user-001 | 2024-01-15 10:30 | iPhone | 6999 |
+| user-001 | 2024-02-20 14:15 | 耳机 | 299 |
+| user-001 | 2024-03-05 09:00 | 充电器 | 89 |
+| user-002 | 2024-01-18 11:00 | iPad | 3999 |
+
+这样设计后，你可以高效地查询：
+- "user-001 的所有订单"（按分区键查）
+- "user-001 在 2024 年 2 月之后的订单"（分区键 + 排序键范围查询）
+
+但你**不能**高效地查询：
+- "所有金额超过 5000 的订单"（需要扫描全表，很慢）
+- "买了 iPhone 的所有用户"（金额和商品不是键）
+
+---
+
+## DynamoDB vs RDS：什么时候用哪个
+
+| 我的需求是... | 选择 |
+|--------------|------|
+| 需要复杂的多表关联查询 | RDS |
+| 需要事务（转账：A 减钱 B 加钱必须同时成功） | RDS（DynamoDB 也支持，但有限制） |
+| 需要灵活的 SQL 查询 | RDS |
+| 需要处理每秒数万甚至数百万次简单读写 | DynamoDB |
+| 数据结构不固定，经常变化 | DynamoDB |
+| 需要个位数毫秒的稳定延迟 | DynamoDB |
+| 不想管任何数据库运维 | DynamoDB |
+
+**典型选择**：
+- 用户信息、订单详情、财务数据 → RDS
+- 用户会话、购物车、游戏排行榜、IoT 设备数据、实时计数器 → DynamoDB
+
+**很多项目两者都用**：核心业务数据放 RDS，高并发的热点数据放 DynamoDB。
+
+---
+
+## DynamoDB 的计费模式
+
+### 按需模式（On-Demand）
+
+- 按实际读写次数付费
+- 不需要预估容量
+- 适合：流量不可预测、新应用、开发环境
+- 价格：约 $1.25/百万次写入，$0.25/百万次读取
+
+### 预置模式（Provisioned）
+
+- 预先设定每秒的读写能力
+- 可以配合 Auto Scaling 自动调整
+- 适合：流量稳定可预测的生产环境
+- 更便宜（大流量时）
+
+**学习阶段用按需模式**，不用的时候一分钱不花。
+
+---
+
+## DynamoDB 的设计思维转变
+
+如果你有 SQL 数据库的经验，用 DynamoDB 需要转变思维：
+
+**SQL 思维**：先设计好表结构（范式化），再想怎么查询。
+**DynamoDB 思维**：先想清楚要怎么查询，再设计表结构。
+
+这是因为 DynamoDB 的查询能力有限——你只能通过主键高效查询。所以必须先知道"我要查什么"，然后把主键设计成支持这种查询的方式。
+
+---
+
+## 今天的小测验
+
+1. DynamoDB 和 RDS 最本质的区别是什么？
+2. 为什么 DynamoDB 能做到"无论数据量多大，延迟都是个位数毫秒"？
+3. 如果你要存储一个游戏的实时排行榜（每秒更新几万次），应该用 RDS 还是 DynamoDB？
+4. DynamoDB 的"分区键 + 排序键"是什么意思？举一个例子。
+
+---
+
+## 延伸阅读
+
+- [DynamoDB 开发者指南](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/)
+- [DynamoDB 免费套餐](https://aws.amazon.com/dynamodb/pricing/)（永久免费 25GB + 每月 2 亿次请求）
+- [DynamoDB 设计最佳实践](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html)
+
+---
+
+## 明天预告
+
+明天学习 VPC（虚拟私有云）——AWS 的网络基础。理解子网、路由、网关这些概念，搞清楚你的服务器是怎么连上网的，以及怎么保护它们不被外界随意访问。

课程/第二阶段-核心服务/第16天-VPC虚拟私有云.md

@@ -0,0 +1,181 @@
+# 第16天：VPC——你的私有网络空间
+
+## 今天你将学到什么
+
+今天学习 VPC（Virtual Private Cloud，虚拟私有云）。这是 AWS 网络的基础——你的所有资源（EC2、RDS、Lambda 等）都运行在 VPC 里面。
+
+理解 VPC 就像理解你家的网络布局：哪些设备连外网，哪些只在内网通信，防火墙怎么设置。
+
+---
+
+## 用小区来理解 VPC
+
+想象你住在一个封闭式小区：
+
+- **VPC** = 整个小区（有围墙，和外面隔开）
+- **子网（Subnet）** = 小区里的不同楼栋（1 号楼、2 号楼...）
+- **Internet Gateway** = 小区大门（连接外面的世界）
+- **路由表** = 小区内的路标（告诉你去哪个方向）
+- **安全组** = 每户的门锁（控制谁能进你家）
+- **NAT Gateway** = 小区的快递柜（住户可以寄快递出去，但外面的人不能直接进来）
+
+---
+
+## 核心概念一：VPC 本身
+
+VPC 是你在 AWS 中划出的一块私有网络空间。
+
+**创建 VPC 时要做的第一件事**：选择 IP 地址范围（CIDR 块）。
+
+**什么是 CIDR？**
+
+CIDR 就是"这个网络里有多少个 IP 地址可以用"。
+
+常见选择：
+- `10.0.0.0/16` → 有 65,536 个 IP 地址（推荐，空间充足）
+- `10.0.0.0/24` → 只有 256 个 IP 地址（太小了）
+
+**简单记忆**：`/16` 表示很大的网络，`/24` 表示小网络。数字越小，网络越大。
+
+---
+
+## 核心概念二：子网（Subnet）
+
+子网是 VPC 内部的"分区"。每个子网位于一个特定的可用区（AZ）。
+
+### 公有子网 vs 私有子网
+
+这是 VPC 设计中最重要的概念：
+
+**公有子网**：能直接访问互联网（有路由到 Internet Gateway）
+- 放什么：负载均衡器、跳板机（Bastion Host）
+- 类比：小区临街的商铺，外面的人可以直接进来
+
+**私有子网**：不能直接被互联网访问
+- 放什么：应用服务器、数据库
+- 类比：小区内部的住宅楼，外面的人进不来
+
+**为什么要分公有和私有？**
+
+安全！你的数据库不需要被全世界访问，只需要被你的应用服务器访问。把它放在私有子网里，即使有人知道了它的 IP 地址，也连不上。
+
+### 典型的网络架构（三层）
+
+```
+互联网
+  ↓
+┌─────────────────── VPC ───────────────────┐
+│                                            │
+│  公有子网（面向互联网）                      │
+│  ├── 负载均衡器 ALB                         │
+│  └── NAT Gateway                           │
+│                                            │
+│  私有子网-应用层（不直接面向互联网）           │
+│  ├── 应用服务器 1                           │
+│  └── 应用服务器 2                           │
+│                                            │
+│  私有子网-数据层（最深处，最安全）             │
+│  ├── RDS 数据库                            │
+│  └── ElastiCache 缓存                      │
+│                                            │
+└────────────────────────────────────────────┘
+```
+
+**流量路径**：
+用户 → 互联网 → ALB（公有子网）→ 应用服务器（私有子网）→ 数据库（私有子网）
+
+外部用户只能接触到 ALB，永远接触不到数据库。层层保护。
+
+---
+
+## 核心概念三：Internet Gateway（互联网网关）
+
+Internet Gateway 是 VPC 连接互联网的"大门"。
+
+- 一个 VPC 只能有一个 Internet Gateway
+- 公有子网的路由表指向它
+- 没有它，VPC 里的任何东西都上不了网
+
+---
+
+## 核心概念四：NAT Gateway
+
+**问题**：私有子网里的服务器不能直接上网，但它需要下载软件更新、调用外部 API 怎么办？
+
+**解决方案**：NAT Gateway
+
+NAT Gateway 放在公有子网里，私有子网的流量通过它"转发"到互联网：
+- 私有子网的服务器可以**主动**访问互联网（下载更新、调用 API）
+- 但互联网上的人**不能**主动连接到私有子网的服务器
+
+**类比**：小区的快递柜。你可以往外寄快递（主动出去），但外面的人不能通过快递柜进入小区（不能主动进来）。
+
+**注意**：NAT Gateway 按小时收费（约 $0.045/小时 ≈ $32/月），学习时用完记得删除！
+
+---
+
+## 核心概念五：路由表（Route Table）
+
+路由表告诉网络流量"该往哪走"。每个子网关联一个路由表。
+
+**公有子网的路由表**：
+| 目标地址 | 下一跳 | 含义 |
+|----------|--------|------|
+| 10.0.0.0/16 | local | VPC 内部的流量，本地处理 |
+| 0.0.0.0/0 | Internet Gateway | 其他所有流量，走互联网网关 |
+
+**私有子网的路由表**：
+| 目标地址 | 下一跳 | 含义 |
+|----------|--------|------|
+| 10.0.0.0/16 | local | VPC 内部的流量，本地处理 |
+| 0.0.0.0/0 | NAT Gateway | 其他所有流量，走 NAT 网关 |
+
+`0.0.0.0/0` 表示"所有地址"——就是说"如果不知道往哪走，就走这条路"。
+
+---
+
+## 核心概念六：安全组（复习+深入）
+
+安全组我们在 EC2 那天学过，这里再深入一点。
+
+**安全组的一个强大特性：可以引用其他安全组**
+
+比如：
+- 应用服务器的安全组：允许来自"ALB 安全组"的流量
+- 数据库的安全组：允许来自"应用服务器安全组"的流量
+
+这样即使 IP 地址变了（Auto Scaling 加了新服务器），安全规则依然有效。因为你引用的是"身份"（安全组），不是具体的 IP。
+
+---
+
+## 默认 VPC vs 自定义 VPC
+
+AWS 每个 Region 都有一个"默认 VPC"，方便你快速上手。但生产环境应该创建自定义 VPC：
+
+| | 默认 VPC | 自定义 VPC |
+|--|---------|-----------|
+| 子网 | 全是公有子网 | 你自己设计公有/私有 |
+| 安全性 | 较低 | 你完全控制 |
+| 适合 | 学习、快速实验 | 正式项目 |
+
+---
+
+## 今天的小测验
+
+1. 公有子网和私有子网的区别是什么？数据库应该放在哪种子网里？
+2. NAT Gateway 的作用是什么？为什么私有子网需要它？
+3. 为什么安全组引用其他安全组比引用 IP 地址更好？
+4. 如果一个子网的路由表里没有指向 Internet Gateway 的路由，这个子网是公有还是私有？
+
+---
+
+## 延伸阅读
+
+- [VPC 用户指南](https://docs.aws.amazon.com/vpc/latest/userguide/)
+- [VPC 设计最佳实践](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html)
+
+---
+
+## 明天预告
+
+明天学习 Route 53（DNS 服务）和 CloudFront（CDN 加速）——让全球用户都能快速访问你的网站，并且实现智能的流量路由。

课程/第二阶段-核心服务/第17天-Route53与CloudFront.md

@@ -0,0 +1,147 @@
+# 第17天：Route 53 与 CloudFront——DNS 和全球加速
+
+## 今天你将学到什么
+
+今天学两个让你的网站"又快又稳"的服务：Route 53（DNS）负责把域名翻译成 IP 地址，CloudFront（CDN）负责把内容推到全球用户身边。
+
+---
+
+## Route 53：互联网的"电话簿"
+
+### DNS 是什么
+
+当你在浏览器输入 `www.taobao.com` 时，电脑其实不认识这个名字。它需要先查"电话簿"（DNS），找到这个名字对应的 IP 地址（比如 140.205.220.96），然后才能连接到服务器。
+
+**Route 53 就是 AWS 提供的 DNS 服务**——帮你管理域名和 IP 地址的对应关系。
+
+名字来源：DNS 使用的网络端口号是 53。
+
+### Route 53 能做什么
+
+**基本功能**：域名解析
+- `www.example.com` → `54.23.100.50`（你的服务器 IP）
+
+**高级功能**：智能路由（这才是 Route 53 的真正价值）
+
+### 路由策略——把用户导向最合适的服务器
+
+**简单路由**：一个域名对应一个 IP。最基本的用法。
+
+**加权路由**：按比例分配流量。
+- 例：90% 的流量到旧版本，10% 到新版本（用于灰度发布）
+
+**延迟路由**：把用户导向延迟最低的服务器。
+- 例：日本用户自动访问东京的服务器，美国用户自动访问弗吉尼亚的服务器
+
+**故障转移路由**：主站挂了自动切到备用站。
+- 例：主服务器在东京，如果东京挂了，自动切换到新加坡的备用服务器
+
+**地理位置路由**：根据用户所在国家/地区路由。
+- 例：中国用户访问中文站点，美国用户访问英文站点
+
+### 健康检查
+
+Route 53 会定期检查你的服务器是否正常：
+- 每 30 秒发一个请求到你的服务器
+- 如果连续几次没响应，标记为"不健康"
+- 自动把流量切到健康的服务器
+
+---
+
+## CloudFront：把内容推到用户身边
+
+### CDN 是什么
+
+CDN（Content Delivery Network，内容分发网络）的原理很简单：
+
+**没有 CDN**：
+- 你的服务器在东京
+- 巴西用户访问你的网站
+- 数据从东京传到巴西，跨越半个地球，需要 300 毫秒
+
+**有 CDN**：
+- 你的内容被"复制"到全球各地的节点
+- 巴西用户访问时，从巴西本地的节点获取
+- 只需要 20 毫秒
+
+**生活类比**：
+- 没有 CDN = 所有人都要去总部取货（远的人等很久）
+- 有 CDN = 在各个城市设了分仓，就近取货（大家都快）
+
+### CloudFront 的工作流程
+
+```
+用户（巴西）发起请求
+    ↓
+请求到达最近的边缘节点（圣保罗）
+    ↓
+边缘节点有缓存？
+├── 有 → 直接返回（超快，10-20ms）
+└── 没有 → 去源站（东京）取 → 缓存一份 → 返回给用户
+              下次其他巴西用户请求同样内容时，直接从缓存返回
+```
+
+### CloudFront 能加速什么
+
+| 内容类型 | 例子 | 缓存效果 |
+|----------|------|----------|
+| 静态文件 | 图片、CSS、JS、字体 | 非常好（内容不变，缓存命中率高） |
+| 视频 | 课程视频、直播回放 | 很好 |
+| API 响应 | 不经常变化的数据 | 一般（需要设置合理的缓存时间） |
+| 动态内容 | 用户个人数据 | 不缓存（每次都回源） |
+
+### CloudFront + S3：最经典的组合
+
+这是部署静态网站最便宜、最快的方案：
+
+1. 把网站文件（HTML/CSS/JS/图片）放在 S3 桶里
+2. 创建 CloudFront 分发，源设置为 S3 桶
+3. 用 Route 53 把域名指向 CloudFront
+4. 用 ACM（AWS Certificate Manager）申请免费的 HTTPS 证书
+
+**结果**：
+- 全球访问速度极快（600+ 个边缘节点）
+- 成本极低（S3 存储 + CloudFront 流量，每月可能只要几美元）
+- 自动 HTTPS
+- 能扛住巨大流量（CDN 天然就是分布式的）
+
+适合：个人博客、公司官网、单页应用（React/Vue）、文档站点
+
+---
+
+## Route 53 + CloudFront 配合使用
+
+一个全球化网站的典型架构：
+
+```
+用户输入 www.example.com
+    ↓
+Route 53 解析域名 → 返回 CloudFront 的地址
+    ↓
+用户请求到达最近的 CloudFront 边缘节点
+    ↓
+├── 静态内容（图片/JS/CSS）→ 边缘节点直接返回（缓存）
+└── 动态内容（API 请求）→ 转发到源站（ALB/EC2）
+```
+
+---
+
+## 今天的小测验
+
+1. DNS 的作用是什么？用你自己的话解释。
+2. Route 53 的"延迟路由"是什么意思？举一个使用场景。
+3. CDN 为什么能让网站变快？它的核心原理是什么？
+4. CloudFront + S3 的组合适合什么类型的网站？
+
+---
+
+## 延伸阅读
+
+- [Route 53 开发者指南](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/)
+- [CloudFront 开发者指南](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/)
+
+---
+
+## 明天预告
+
+明天学习 SQS 和 SNS——消息队列和通知服务。它们让系统的各个部分"松耦合"通信，是构建可靠分布式系统的基石。

课程/第二阶段-核心服务/第18天-SQS与SNS消息服务.md

@@ -0,0 +1,169 @@
+# 第18天：SQS 与 SNS——消息队列和通知服务
+
+## 今天你将学到什么
+
+今天学习两个让系统"松耦合"的服务：SQS（消息队列）和 SNS（通知服务）。它们解决的核心问题是：**让系统的各个部分不再紧密依赖，一个部分出问题不会拖垮整个系统。**
+
+---
+
+## 为什么需要消息队列——用餐厅来理解
+
+### 没有消息队列的世界（紧耦合）
+
+想象一个餐厅，流程是这样的：
+
+顾客点单 → 服务员站在厨房门口等 → 厨师做好菜 → 服务员端菜上桌 → 服务员回来接下一个顾客
+
+**问题**：
+- 服务员在等厨师做菜的时候什么都干不了（阻塞）
+- 如果厨师突然肚子疼去了厕所，服务员和顾客都得干等（一个环节故障影响全部）
+- 午餐高峰期 100 个人同时点单，厨房根本忙不过来（没有缓冲）
+
+### 有消息队列的世界（松耦合）
+
+改进后的流程：
+
+顾客点单 → 服务员把订单**贴在窗口**（消息队列）→ 服务员立刻回去服务下一个顾客
+
+厨师按自己的节奏从窗口**取订单**做菜 → 做好了放在出菜口 → 服务员来取
+
+**好处**：
+- 服务员不用等厨师（异步，不阻塞）
+- 厨师去厕所了？订单还贴在窗口，回来继续做（容错）
+- 高峰期订单堆在窗口，厨师按自己的速度做，不会崩溃（削峰）
+- 可以加更多厨师来加快速度（水平扩展）
+
+**这就是消息队列的价值。**
+
+---
+
+## SQS（Simple Queue Service）
+
+SQS 是 AWS 的消息队列服务——一个"订单窗口"。
+
+### 工作流程
+
+```
+生产者（发送消息的人）→ SQS 队列 → 消费者（处理消息的人）
+```
+
+**举个真实例子**：电商下单流程
+
+用户点击"提交订单"后，需要做很多事：
+1. 扣减库存
+2. 发送确认短信
+3. 生成物流单
+4. 更新用户积分
+5. 通知仓库备货
+
+**没有 SQS**：所有步骤串行执行。用户要等所有步骤完成才看到"下单成功"。任何一步失败，整个订单失败。
+
+**有 SQS**：
+- 订单创建成功后立刻返回"下单成功"给用户（用户不用等）
+- 同时把"有新订单"这个消息发到 SQS 队列
+- 库存服务、短信服务、物流服务各自从队列取消息处理
+- 某个服务暂时挂了？消息还在队列里，恢复后继续处理
+
+### SQS 的关键特性
+
+**消息保留**：消息最多保留 14 天。如果 14 天内没人处理，才会被删除。
+
+**可见性超时**：消费者取走一条消息后，这条消息对其他消费者"隐藏"一段时间。如果消费者处理成功就删除消息；如果处理失败（比如消费者崩溃了），超时后消息重新出现，可以被其他消费者重试。
+
+**死信队列**：如果一条消息反复处理失败（比如重试了 5 次都失败），自动转移到"死信队列"。你可以人工检查这些"问题消息"，避免它们阻塞正常处理。
+
+---
+
+## SNS（Simple Notification Service）
+
+SNS 是"发布/订阅"模式的通知服务——一条消息可以同时发给多个接收者。
+
+### SQS vs SNS 的区别
+
+**SQS = 点对点**（一条消息只被一个消费者处理）
+- 类比：快递柜。一个包裹只能被一个人取走。
+
+**SNS = 广播**（一条消息发给所有订阅者）
+- 类比：小区广播。一条通知所有住户都能听到。
+
+### SNS 的工作方式
+
+```
+发布者 → SNS 主题（Topic）→ 订阅者 A（邮箱）
+                           → 订阅者 B（短信）
+                           → 订阅者 C（SQS 队列）
+                           → 订阅者 D（Lambda 函数）
+                           → 订阅者 E（HTTP 接口）
+```
+
+**举个例子**：用户注册成功后
+
+```
+用户注册成功 → 发布"新用户注册"事件到 SNS
+    → 邮件服务收到 → 发送欢迎邮件
+    → 积分服务收到 → 赠送新人积分
+    → 推荐服务收到 → 生成个性化推荐
+    → 数据分析收到 → 记录注册统计
+```
+
+一个事件，多个服务各自处理自己关心的部分。互不影响。
+
+---
+
+## 经典组合：SNS + SQS（扇出模式）
+
+这是 AWS 最推荐的异步架构模式：
+
+```
+订单服务发布"新订单"事件
+    ↓
+SNS 主题（广播给所有订阅者）
+    ├── SQS 队列 A → 库存服务（扣减库存）
+    ├── SQS 队列 B → 通知服务（发短信/邮件）
+    ├── SQS 队列 C → 物流服务（生成运单）
+    └── SQS 队列 D → 积分服务（加积分）
+```
+
+**为什么中间要加 SQS，不直接用 SNS 推给各服务？**
+
+因为 SQS 提供了"缓冲"和"重试"：
+- 某个服务暂时挂了 → 消息在 SQS 里等着，恢复后继续处理
+- 某个服务处理慢 → 消息在 SQS 里排队，不会丢失
+- 流量突然暴涨 → SQS 帮你削峰，各服务按自己的速度消费
+
+---
+
+## 同步 vs 异步：什么时候用哪种
+
+| 场景 | 方式 | 原因 |
+|------|------|------|
+| 用户查询商品详情 | 同步 | 用户在等结果，必须立刻返回 |
+| 用户下单扣库存 | 同步 | 必须确认库存够才能下单 |
+| 下单后发确认短信 | 异步 | 短信晚几秒发不影响下单结果 |
+| 下单后更新推荐 | 异步 | 推荐更新慢一点无所谓 |
+| 上传图片后生成缩略图 | 异步 | 缩略图不需要立刻生成 |
+
+**判断标准**：用户是否在等这个结果？如果是，同步。如果不是，异步。
+
+---
+
+## 今天的小测验
+
+1. 消息队列解决的核心问题是什么？用你自己的话解释。
+2. SQS 和 SNS 的区别是什么？各自适合什么场景？
+3. 什么是"死信队列"？它解决什么问题？
+4. 为什么说"SNS + SQS"是最佳组合？
+
+---
+
+## 延伸阅读
+
+- [SQS 开发者指南](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/)
+- [SNS 开发者指南](https://docs.aws.amazon.com/sns/latest/dg/)
+- [AWS 消息传递模式](https://aws.amazon.com/messaging/)
+
+---
+
+## 明天预告
+
+明天是第二阶段的收尾：用一个完整的项目案例，把这 11 天学到的所有核心服务串联起来，看看它们在真实架构中是怎么配合工作的。

课程/第二阶段-核心服务/第19天-核心服务综合实战.md

@@ -0,0 +1,182 @@
+# 第19天：核心服务综合实战——设计一个完整的应用架构
+
+## 今天你将学到什么
+
+今天是第二阶段的收尾。我们用一个完整的项目案例，把前面学到的所有核心服务串联起来，看看它们在真实架构中是怎么配合工作的。
+
+---
+
+## 项目背景：设计一个外卖点餐平台
+
+假设你要做一个类似"美团外卖"的简化版平台：
+- 用户可以浏览餐厅和菜品
+- 用户可以下单、支付
+- 商家可以接单、更新订单状态
+- 用户可以实时查看订单进度
+- 需要支持全国用户访问
+
+---
+
+## 架构全景图
+
+```
+用户手机/电脑
+      ↓
+Route 53（域名解析）
+      ↓
+CloudFront（静态资源加速：图片、前端页面）
+      ↓
+ALB（负载均衡，分发到多台服务器）
+      ↓
+Auto Scaling Group（应用服务器，自动伸缩）
+      ↓
+├── ElastiCache Redis（缓存热门餐厅、菜品信息）
+├── Aurora MySQL（用户信息、订单数据、商家信息）
+├── DynamoDB（实时订单状态、骑手位置）
+├── S3（菜品图片、商家 Logo、用户头像）
+└── SQS + Lambda（异步处理：发通知、更新统计）
+```
+
+---
+
+## 每个服务的角色
+
+### Route 53 — 域名入口
+- 用户输入 `www.waimai.com`
+- Route 53 把域名解析到 CloudFront 的地址
+- 配置健康检查：如果主站挂了，自动切到备用站
+
+### CloudFront — 全球加速
+- 缓存静态资源：菜品图片、前端 JS/CSS、商家 Logo
+- 全国各地的用户都能快速加载页面
+- 减轻源站压力（图片请求不用每次都打到服务器）
+
+### ALB — 流量分发
+- 把用户请求均匀分配给多台应用服务器
+- 路径路由：`/api/orders/*` → 订单服务，`/api/restaurants/*` → 餐厅服务
+- 健康检查：某台服务器挂了自动剔除
+
+### Auto Scaling — 弹性伸缩
+- 午餐高峰（11:00-13:00）：自动扩展到 20 台服务器
+- 凌晨低谷（2:00-6:00）：自动缩减到 3 台服务器
+- 策略：CPU 使用率保持在 60%
+
+### ElastiCache Redis — 缓存加速
+- 缓存热门餐厅列表（避免每次都查数据库）
+- 缓存用户会话（登录状态）
+- 缓存菜品信息（菜品不会每秒都变）
+- 效果：响应时间从 50ms 降到 5ms
+
+### Aurora MySQL — 核心业务数据
+- 存储：用户信息、商家信息、菜品详情、订单记录、支付记录
+- Multi-AZ 部署：主库挂了自动切换到备库
+- 2 个只读副本：分担查询压力
+- 为什么选 Aurora：需要复杂查询（统计报表、搜索筛选）
+
+### DynamoDB — 实时数据
+- 存储：订单实时状态（待接单→制作中→配送中→已送达）
+- 存储：骑手实时位置（每 5 秒更新一次）
+- 为什么选 DynamoDB：更新频率极高、查询简单（按订单 ID 查）、需要毫秒级响应
+
+### S3 — 文件存储
+- 菜品图片（商家上传）
+- 用户头像
+- 商家营业执照扫描件
+- 配合 CloudFront 分发到全国
+
+### SQS + Lambda — 异步处理
+- 用户下单后 → 消息进入 SQS → Lambda 发送短信通知商家
+- 订单完成后 → 消息进入 SQS → Lambda 更新用户积分
+- 每日凌晨 → 定时触发 Lambda → 生成商家结算报表
+
+---
+
+## 网络设计
+
+```
+VPC (10.0.0.0/16)
+├── 公有子网 (面向互联网)
+│   ├── ALB
+│   └── NAT Gateway
+├── 应用子网 (私有)
+│   └── EC2 应用服务器 (Auto Scaling)
+└── 数据子网 (私有，最安全)
+    ├── Aurora MySQL
+    ├── ElastiCache Redis
+    └── (DynamoDB 和 S3 通过 VPC Endpoint 访问，不走公网)
+```
+
+**安全组规则**：
+- ALB：只允许 80/443 端口的外部流量
+- 应用服务器：只允许来自 ALB 的流量
+- 数据库：只允许来自应用服务器的流量
+- 层层隔离，外部用户永远接触不到数据库
+
+---
+
+## 一个请求的完整旅程
+
+用户打开 APP，浏览附近的餐厅：
+
+1. APP 请求 `api.waimai.com/restaurants?lat=39.9&lng=116.4`
+2. Route 53 解析域名 → CloudFront 地址
+3. CloudFront 发现这是 API 请求（不缓存）→ 转发到 ALB
+4. ALB 选择一台健康的应用服务器
+5. 应用服务器先查 Redis 缓存：有附近餐厅的数据吗？
+   - 有（缓存命中）→ 直接返回，耗时 5ms
+   - 没有（缓存未命中）→ 查 Aurora 数据库 → 结果写入 Redis → 返回
+6. 响应经过 ALB → CloudFront → 到达用户 APP
+
+整个过程：50-200ms。用户感觉"秒开"。
+
+---
+
+## 成本估算（月）
+
+| 服务 | 配置 | 月费估算 |
+|------|------|----------|
+| EC2 (Auto Scaling) | 3-20 台 t3.large | ¥2,000-5,000 |
+| Aurora | db.r6g.large + 2 只读副本 | ¥4,000 |
+| ElastiCache | 2 节点 cache.r6g.large | ¥3,000 |
+| DynamoDB | 按需模式 | ¥500-2,000 |
+| S3 | 500GB 图片 | ¥100 |
+| CloudFront | 2TB 流量 | ¥1,500 |
+| 其他 | ALB、NAT、Route53 | ¥1,000 |
+| **总计** | | **¥12,000-17,000/月** |
+
+对于一个日活几万用户的平台来说，这个成本是合理的。
+
+---
+
+## 关键设计决策总结
+
+| 决策 | 选择 | 原因 |
+|------|------|------|
+| 主数据库 | Aurora MySQL | 需要复杂查询、事务、报表 |
+| 实时数据 | DynamoDB | 高频更新、简单查询、毫秒响应 |
+| 缓存 | Redis | 减少数据库压力、加速响应 |
+| 文件存储 | S3 + CloudFront | 图片多、需要全国加速 |
+| 异步处理 | SQS + Lambda | 解耦、削峰、按需付费 |
+| 伸缩策略 | Auto Scaling | 应对午餐/晚餐高峰 |
+
+---
+
+## 今天的小测验
+
+1. 为什么这个架构同时用了 Aurora 和 DynamoDB 两种数据库？
+2. 如果不用 CloudFront，用户体验会有什么变化？
+3. 为什么"发通知"这个操作要用 SQS 异步处理，而不是下单时同步发送？
+4. 如果午餐高峰期流量突然暴涨 5 倍，这个架构的哪些部分会自动应对？
+
+---
+
+## 延伸阅读
+
+- [AWS 架构中心](https://aws.amazon.com/architecture/)
+- [AWS Well-Architected Labs](https://wellarchitectedlabs.com/)
+
+---
+
+## 明天预告
+
+进入第三阶段：安全与身份。明天深入学习 IAM 策略的编写——用精确的规则控制"谁能对什么资源做什么操作"。

课程/第五阶段-监控与运维/第33天-CloudWatch监控.md

@@ -0,0 +1,201 @@
+# 第33天：CloudWatch——监控一切
+
+## 今天你将学到什么
+
+今天学习 CloudWatch——AWS 的监控核心服务。它收集指标、展示仪表板、设置告警、收集日志。是你了解系统运行状态的"眼睛"。
+
+---
+
+## 为什么需要监控
+
+### 没有监控的世界
+
+- 用户打电话来："你们网站打不开了！"——你才知道出了问题
+- 数据库磁盘满了，应用崩溃——事后才发现
+- 月底账单暴涨——不知道是哪个服务在烧钱
+- 应用变慢了——不知道是哪个环节的问题
+
+### 有监控的世界
+
+- CPU 使用率超过 80%——自动告警，还没出问题就提前处理
+- 磁盘使用率达到 70%——自动扩容或清理
+- API 错误率突然上升——立刻通知开发团队
+- 响应时间变慢——精确定位到是数据库查询慢了
+
+**类比**：CloudWatch 就像汽车的仪表盘。没有仪表盘你也能开车，但你不知道油还剩多少、发动机温度是否正常、时速多少。有了仪表盘，一切尽在掌握。
+
+---
+
+## CloudWatch 的四大功能
+
+### 1. 指标（Metrics）——数字化的运行状态
+
+指标是一个随时间变化的数值。AWS 服务自动发送指标到 CloudWatch。
+
+**常见指标举例**：
+
+| 服务 | 指标 | 含义 |
+|------|------|------|
+| EC2 | CPUUtilization | CPU 使用率 |
+| EC2 | NetworkIn/Out | 网络流入/流出字节数 |
+| RDS | DatabaseConnections | 数据库连接数 |
+| RDS | FreeStorageSpace | 剩余磁盘空间 |
+| ALB | RequestCount | 请求总数 |
+| ALB | TargetResponseTime | 后端响应时间 |
+| Lambda | Invocations | 调用次数 |
+| Lambda | Errors | 错误次数 |
+| Lambda | Duration | 执行时间 |
+| SQS | ApproximateNumberOfMessages | 队列中的消息数 |
+
+**自定义指标**：你也可以发送自己的业务指标，比如"每分钟注册用户数"、"订单金额"等。
+
+### 2. 告警（Alarms）——自动预警
+
+当指标超过阈值时，自动触发动作。
+
+**告警的三种状态**：
+- OK：一切正常
+- ALARM：超过阈值，触发告警
+- INSUFFICIENT_DATA：数据不足，无法判断
+
+**告警可以触发的动作**：
+- 发送通知（SNS → 邮件/短信/Slack）
+- 自动扩展（Auto Scaling 加机器）
+- 执行 Lambda 函数（自动修复）
+- 停止/终止 EC2 实例
+
+**常见告警设置**：
+
+| 告警 | 条件 | 动作 |
+|------|------|------|
+| CPU 过高 | CPU > 80% 持续 5 分钟 | 通知 + Auto Scaling 扩展 |
+| 磁盘快满 | 剩余空间 < 20% | 通知运维团队 |
+| 错误率上升 | 5xx 错误 > 1% 持续 3 分钟 | 通知开发团队 |
+| 响应变慢 | P99 延迟 > 2 秒 | 通知 + 自动排查 |
+| 账单异常 | 预估月费 > 预算 | 通知管理层 |
+
+### 3. 日志（Logs）——详细的运行记录
+
+CloudWatch Logs 集中收集和存储所有日志。
+
+**日志来源**：
+- EC2 实例的应用日志（需要安装 CloudWatch Agent）
+- Lambda 函数的输出（自动发送）
+- ECS 容器的日志（配置日志驱动）
+- API Gateway 的访问日志
+- VPC Flow Logs
+
+**日志的组织结构**：
+```
+日志组（Log Group）：/app/order-service
+  └── 日志流（Log Stream）：instance-1/2024-01-15
+        └── 日志事件：[2024-01-15 10:30:15] ERROR: Database connection timeout
+```
+
+**Logs Insights**：用类 SQL 语法查询日志。
+
+比如查找最近 1 小时内所有错误：
+```
+fields @timestamp, @message
+| filter @message like /ERROR/
+| sort @timestamp desc
+| limit 50
+```
+
+### 4. 仪表板（Dashboards）——可视化大屏
+
+把多个指标和日志组合成一个可视化页面。
+
+**典型的运维仪表板包含**：
+- 请求量趋势图
+- 错误率曲线
+- 响应时间分布
+- CPU/内存使用率
+- 数据库连接数
+- 队列积压情况
+
+一眼就能看出系统整体健康状况。
+
+---
+
+## 实际监控方案
+
+### 一个 Web 应用的监控体系
+
+```
+第一层：基础设施监控
+├── EC2：CPU、内存、磁盘、网络
+├── RDS：连接数、查询延迟、磁盘空间
+├── ElastiCache：内存使用、命中率
+└── ALB：请求量、错误率、延迟
+
+第二层：应用监控
+├── API 响应时间（P50、P95、P99）
+├── API 错误率（4xx、5xx）
+├── 业务错误日志
+└── 依赖服务调用延迟
+
+第三层：业务监控
+├── 每分钟注册用户数
+├── 每分钟订单数
+├── 支付成功率
+└── 用户活跃度
+```
+
+### 告警分级
+
+| 级别 | 条件 | 响应 |
+|------|------|------|
+| P1 紧急 | 服务完全不可用 | 立刻通知所有人，5 分钟内响应 |
+| P2 严重 | 部分功能受影响 | 通知值班人员，30 分钟内响应 |
+| P3 警告 | 性能下降但可用 | 通知开发团队，当天处理 |
+| P4 信息 | 需要关注但不紧急 | 记录，下次迭代处理 |
+
+---
+
+## CloudWatch Agent
+
+默认情况下，CloudWatch 只能看到 EC2 的 CPU、网络、磁盘 IO 等外部指标。要看内存使用率、磁盘空间等内部指标，需要安装 CloudWatch Agent。
+
+**CloudWatch Agent 能收集**：
+- 内存使用率（默认看不到！）
+- 磁盘空间使用率
+- 应用日志文件
+- 自定义指标
+
+---
+
+## 成本注意事项
+
+| 功能 | 免费额度 | 超出后费用 |
+|------|----------|-----------|
+| 基本指标 | AWS 服务自带指标免费 | - |
+| 自定义指标 | 前 10 个免费 | $0.30/指标/月 |
+| 告警 | 前 10 个免费 | $0.10/告警/月 |
+| 日志存储 | 5GB 免费 | $0.50/GB/月 |
+| 仪表板 | 前 3 个免费 | $3/仪表板/月 |
+
+**建议**：学习阶段用免费额度完全够用。生产环境注意日志量，设置日志保留期限（比如保留 30 天）。
+
+---
+
+## 今天的小测验
+
+1. CloudWatch 的四大功能分别是什么？
+2. 什么是 CloudWatch 告警？它可以触发哪些动作？
+3. 为什么需要安装 CloudWatch Agent？它能收集什么默认看不到的指标？
+4. 如何设计一个合理的告警分级体系？
+
+---
+
+## 延伸阅读
+
+- [CloudWatch 用户指南](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/)
+- [CloudWatch Logs Insights 语法](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html)
+- [CloudWatch Agent 配置](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
+
+---
+
+## 明天预告
+
+明天学习成本管理——如何控制你的 AWS 账单。了解 AWS 的定价模型、省钱技巧，以及如何设置预算告警避免意外花费。

课程/第五阶段-监控与运维/第34天-成本管理.md

@@ -0,0 +1,215 @@
+# 第34天：成本管理——控制你的 AWS 账单
+
+## 今天你将学到什么
+
+今天学习如何管理和优化 AWS 成本。AWS 按使用量付费，用得好省钱，用不好可能收到天价账单。掌握成本管理是每个 AWS 用户的必修课。
+
+---
+
+## AWS 定价的基本原则
+
+### 三大定价原则
+
+1. **按使用量付费**：用多少付多少，不用不花钱
+2. **用得越多越便宜**：很多服务有阶梯定价
+3. **预付费更便宜**：承诺长期使用可以获得折扣
+
+### 什么东西要花钱
+
+| 类别 | 计费方式 | 举例 |
+|------|----------|------|
+| 计算 | 按运行时间 | EC2 每小时 $0.05 |
+| 存储 | 按存储量 | S3 每 GB 每月 $0.023 |
+| 网络 | 按传输量 | 数据传出每 GB $0.09 |
+| 请求 | 按请求次数 | API Gateway 每百万次 $3.50 |
+| 数据库 | 按实例时间 + 存储 | RDS 每小时 $0.10 + 存储费 |
+
+### 什么东西免费
+
+- 数据传入 AWS：免费（上传不花钱）
+- 同一可用区内的数据传输：免费
+- 很多服务的 Free Tier（12 个月免费额度）
+
+---
+
+## 常见的"账单惊吓"
+
+### 惊吓一：忘记关 EC2
+
+你创建了一台 EC2 做实验，用完忘记关了。一个月后发现账单多了 $50。
+
+**预防**：设置 Billing Alarm，超过预算立刻通知。
+
+### 惊吓二：NAT Gateway 流量费
+
+NAT Gateway 按流量收费（$0.045/GB）。如果你的应用通过 NAT Gateway 下载大量数据，费用会很高。
+
+**预防**：使用 VPC Endpoint 访问 S3/DynamoDB（免费），减少通过 NAT 的流量。
+
+### 惊吓三：EBS 快照堆积
+
+每次创建 EBS 快照都会占用存储空间。如果不清理旧快照，费用会持续增长。
+
+**预防**：设置快照生命周期策略，自动删除过期快照。
+
+### 惊吓四：闲置的 Elastic IP
+
+Elastic IP 绑定到运行中的 EC2 是免费的。但如果 EC2 停止了或 IP 没有绑定，每小时收 $0.005。
+
+**预防**：不用的 Elastic IP 及时释放。
+
+---
+
+## AWS 省钱策略
+
+### 策略一：选择合适的实例类型
+
+不要盲目选大实例。先用小实例，监控资源使用率，再决定是否升级。
+
+| 场景 | 推荐 | 原因 |
+|------|------|------|
+| 开发测试 | t3.micro / t3.small | 便宜，突发性能够用 |
+| 稳定负载 | m6i / c6i | 性价比高 |
+| 内存密集 | r6i | 内存大 |
+| 计算密集 | c6i | CPU 强 |
+
+### 策略二：使用预留实例 / Savings Plans
+
+如果你确定要长期使用某些资源，预付费可以省很多钱。
+
+| 方式 | 折扣 | 灵活性 | 适合 |
+|------|------|--------|------|
+| 按需（On-Demand） | 无折扣 | 最灵活 | 短期、不确定的负载 |
+| Savings Plans | 最多 72% | 中等 | 确定要用 1-3 年 |
+| 预留实例 | 最多 75% | 最低 | 确定实例类型和区域 |
+| Spot 实例 | 最多 90% | 可能被中断 | 可中断的任务 |
+
+### 策略三：使用 Spot 实例
+
+Spot 实例是 AWS 闲置的计算资源，价格只有按需的 10-30%。但 AWS 可能随时收回。
+
+**适合**：
+- 批处理任务（数据分析、视频转码）
+- CI/CD 构建
+- 测试环境
+- 可以容忍中断的工作负载
+
+**不适合**：
+- 生产环境的核心服务
+- 数据库
+- 不能中断的任务
+
+### 策略四：合理使用存储层级
+
+| S3 存储类 | 价格 | 适合 |
+|-----------|------|------|
+| Standard | $0.023/GB | 频繁访问的数据 |
+| Infrequent Access | $0.0125/GB | 偶尔访问（每月一次） |
+| Glacier | $0.004/GB | 归档（几个月访问一次） |
+| Glacier Deep Archive | $0.00099/GB | 长期归档（几年访问一次） |
+
+设置生命周期策略自动转移：
+```
+0-30 天：Standard
+30-90 天：Infrequent Access
+90 天以上：Glacier
+```
+
+### 策略五：关闭不用的资源
+
+听起来简单，但很多公司每月浪费 20-30% 的云费用在闲置资源上。
+
+**常见浪费**：
+- 开发环境晚上和周末不关
+- 测试完的资源忘记删除
+- 没有流量的负载均衡器
+- 没有挂载的 EBS 卷
+
+---
+
+## AWS 成本管理工具
+
+### Cost Explorer——费用分析
+
+可视化你的 AWS 花费：
+- 按服务查看：哪个服务花钱最多
+- 按时间查看：费用趋势是上升还是下降
+- 按标签查看：哪个项目/团队花钱最多
+- 预测未来费用
+
+### Budgets——预算告警
+
+设置预算上限，超过时自动通知：
+
+```
+月度预算：$100
+告警阈值：
+  - 达到 50%（$50）→ 发邮件提醒
+  - 达到 80%（$80）→ 发邮件 + 短信
+  - 达到 100%（$100）→ 紧急通知 + 可选自动操作
+```
+
+**强烈建议**：学习阶段一定要设置 Budget！设置 $10 或 $20 的月度预算，避免意外花费。
+
+### Trusted Advisor——优化建议
+
+AWS 的"理财顾问"，自动检查你的账户并给出建议：
+
+| 检查类别 | 举例 |
+|----------|------|
+| 成本优化 | "你有 3 台 EC2 CPU 使用率低于 10%，建议缩小实例" |
+| 性能 | "你的 EBS 卷 IOPS 经常达到上限，建议升级" |
+| 安全 | "你的 S3 桶是公开的，建议限制访问" |
+| 容错 | "你的 RDS 没有开启 Multi-AZ，建议开启" |
+
+### 资源标签（Tags）——费用归属
+
+给每个资源打标签，方便追踪费用归属：
+
+```
+标签示例：
+  Environment: production / staging / development
+  Team: backend / frontend / data
+  Project: order-system / user-portal
+```
+
+然后在 Cost Explorer 中按标签筛选，就能知道每个团队、每个项目花了多少钱。
+
+---
+
+## 成本优化清单
+
+| 优先级 | 措施 | 预期节省 |
+|--------|------|----------|
+| 高 | 关闭闲置资源 | 10-30% |
+| 高 | 合适的实例大小 | 10-20% |
+| 高 | Savings Plans / 预留实例 | 30-72% |
+| 中 | 使用 Spot 实例 | 60-90%（适用部分） |
+| 中 | S3 生命周期策略 | 存储费 50-90% |
+| 中 | VPC Endpoint 替代 NAT | 网络费 50%+ |
+| 低 | 选择合适的区域 | 5-15% |
+| 低 | 数据传输优化 | 视情况 |
+
+---
+
+## 今天的小测验
+
+1. AWS 的三大定价原则是什么？
+2. Spot 实例为什么这么便宜？什么场景适合用？
+3. 为什么学习阶段一定要设置 Budget？
+4. 列举三种常见的 AWS 费用浪费场景。
+
+---
+
+## 延伸阅读
+
+- [AWS 定价页面](https://aws.amazon.com/pricing/)
+- [AWS Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html)
+- [AWS Savings Plans](https://docs.aws.amazon.com/savingsplans/latest/userguide/)
+- [AWS 成本优化白皮书](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-laying-the-foundation/cost-optimization-laying-the-foundation.html)
+
+---
+
+## 明天预告
+
+明天学习 Well-Architected Framework——AWS 的架构设计最佳实践框架。了解如何从五个维度评估和改进你的架构。

课程/第五阶段-监控与运维/第35天-WellArchitected框架.md

@@ -0,0 +1,198 @@
+# 第35天：Well-Architected Framework——架构设计的五大支柱
+
+## 今天你将学到什么
+
+今天学习 AWS Well-Architected Framework——这是 AWS 总结的架构设计最佳实践框架。它从五个维度帮你评估和改进你的架构，是 AWS 认证考试的重点内容。
+
+---
+
+## 什么是 Well-Architected Framework
+
+AWS 的解决方案架构师们在帮助成千上万客户设计架构的过程中，总结出了一套通用的最佳实践。这就是 Well-Architected Framework。
+
+**类比**：就像建筑行业有建筑规范一样，云架构也有自己的"规范"。按照这个规范设计的架构，更安全、更可靠、更高效、更省钱。
+
+---
+
+## 六大支柱
+
+### 支柱一：卓越运营（Operational Excellence）
+
+**核心问题**：你的团队能不能高效地运行和改进系统？
+
+**关键实践**：
+
+| 实践 | 说明 | AWS 服务 |
+|------|------|----------|
+| 基础设施即代码 | 用代码管理基础设施，可重复、可审查 | CloudFormation / CDK |
+| 小批量变更 | 频繁小改动比偶尔大改动风险低 | CodePipeline / CodeDeploy |
+| 预演故障 | 定期模拟故障，验证恢复流程 | Fault Injection Simulator |
+| 自动化运维 | 减少手动操作，降低人为错误 | Systems Manager |
+| 从失败中学习 | 每次故障后做复盘，改进流程 | - |
+
+**一句话总结**：让运维工作自动化、可重复、持续改进。
+
+### 支柱二：安全性（Security）
+
+**核心问题**：你的数据和系统是否得到了充分保护？
+
+**关键实践**：
+
+| 实践 | 说明 | AWS 服务 |
+|------|------|----------|
+| 身份与访问管理 | 最小权限原则 | IAM |
+| 检测控制 | 持续监控异常行为 | GuardDuty / CloudTrail |
+| 基础设施保护 | 网络隔离、边界防护 | VPC / WAF / Shield |
+| 数据保护 | 加密一切 | KMS / Secrets Manager |
+| 事件响应 | 有预案，能快速响应 | Security Hub |
+
+**一句话总结**：假设会被攻击，层层防护，快速响应。
+
+### 支柱三：可靠性（Reliability）
+
+**核心问题**：系统能不能在故障发生时继续正常工作？
+
+**关键实践**：
+
+| 实践 | 说明 | AWS 服务 |
+|------|------|----------|
+| 自动恢复 | 故障自动检测和恢复 | Auto Scaling / ELB |
+| 多可用区部署 | 一个机房挂了另一个接管 | Multi-AZ RDS / ALB |
+| 水平扩展 | 加机器而不是换更大的机器 | Auto Scaling |
+| 备份与恢复 | 定期备份，验证恢复流程 | AWS Backup |
+| 限制爆炸半径 | 一个组件故障不影响全局 | 微服务 / 隔离 |
+
+**一句话总结**：假设一切都会坏，设计系统能自动恢复。
+
+### 支柱四：性能效率（Performance Efficiency）
+
+**核心问题**：你是否高效地使用了计算资源？
+
+**关键实践**：
+
+| 实践 | 说明 | AWS 服务 |
+|------|------|----------|
+| 选择合适的资源 | 不同负载用不同类型的资源 | EC2 实例类型选择 |
+| 全球化部署 | 让用户就近访问 | CloudFront / Global Accelerator |
+| 使用无服务器 | 不需要管理服务器 | Lambda / Fargate |
+| 持续实验 | 尝试新技术和新架构 | - |
+| 缓存 | 减少重复计算和查询 | ElastiCache / CloudFront |
+
+**一句话总结**：用对的工具做对的事，持续优化性能。
+
+### 支柱五：成本优化（Cost Optimization）
+
+**核心问题**：你是否在用最少的钱达到业务目标？
+
+**关键实践**：
+
+| 实践 | 说明 | AWS 服务 |
+|------|------|----------|
+| 了解花费 | 知道钱花在哪里 | Cost Explorer / Budgets |
+| 消除浪费 | 关闭闲置资源 | Trusted Advisor |
+| 合适的定价模型 | 预留、Spot、按需合理搭配 | Savings Plans |
+| 按需扩展 | 不过度预置资源 | Auto Scaling |
+| 托管服务 | 用托管服务替代自建 | RDS vs 自建数据库 |
+
+**一句话总结**：花该花的钱，不花冤枉钱。
+
+### 支柱六：可持续性（Sustainability）
+
+**核心问题**：你的架构是否环保节能？
+
+**关键实践**：
+
+| 实践 | 说明 |
+|------|------|
+| 选择高效区域 | 选择使用可再生能源的 AWS 区域 |
+| 最大化利用率 | 减少闲置资源 |
+| 使用托管服务 | 共享资源比独占更环保 |
+| 减少数据移动 | 数据就近处理 |
+
+---
+
+## 用一个例子串联五大支柱
+
+### 场景：一个电商网站的架构评估
+
+| 支柱 | 问题 | 改进建议 |
+|------|------|----------|
+| 卓越运营 | 部署靠手动 SSH | 改用 CodePipeline 自动化部署 |
+| 安全性 | 数据库密码写在代码里 | 改用 Secrets Manager |
+| 可靠性 | 单台 EC2，挂了就完了 | 改用 Auto Scaling + Multi-AZ |
+| 性能效率 | 每次都查数据库 | 加 ElastiCache 缓存热点数据 |
+| 成本优化 | 用了太大的实例 | 根据实际负载缩小实例类型 |
+
+---
+
+## Well-Architected Tool
+
+AWS 提供了一个免费的在线工具，帮你评估自己的架构：
+
+1. 在 AWS 控制台打开 Well-Architected Tool
+2. 创建一个"工作负载"
+3. 回答一系列问题（每个支柱约 10-15 个问题）
+4. 工具会生成报告，指出高风险项和改进建议
+
+**适合**：定期（比如每季度）对你的架构做一次"体检"。
+
+---
+
+## 高可用与灾难恢复
+
+### 高可用（High Availability）
+
+**目标**：系统尽可能少地停机。
+
+**衡量指标**：可用性百分比
+
+| 可用性 | 年停机时间 | 级别 |
+|--------|-----------|------|
+| 99%（两个 9） | 3.65 天 | 低 |
+| 99.9%（三个 9） | 8.76 小时 | 中 |
+| 99.99%（四个 9） | 52.6 分钟 | 高 |
+| 99.999%（五个 9） | 5.26 分钟 | 极高 |
+
+**实现方式**：
+- 多可用区部署（一个 AZ 挂了，另一个接管）
+- 负载均衡 + 健康检查
+- Auto Scaling 自动替换故障实例
+- 数据库 Multi-AZ 自动故障转移
+
+### 灾难恢复（Disaster Recovery）
+
+**目标**：当整个区域（Region）不可用时，能恢复服务。
+
+**四种策略**（从便宜到贵）：
+
+| 策略 | 恢复时间 | 成本 | 说明 |
+|------|----------|------|------|
+| 备份恢复 | 小时级 | 最低 | 定期备份到另一个区域，灾难时恢复 |
+| 灯塔模式 | 十分钟级 | 低 | 另一个区域有最小化的环境，灾难时扩展 |
+| 温备 | 分钟级 | 中 | 另一个区域有缩小版的完整环境 |
+| 热备（多活） | 秒级 | 最高 | 两个区域同时运行，实时同步 |
+
+**选择建议**：根据业务对停机的容忍度和预算来选择。大多数应用用"灯塔模式"就够了。
+
+---
+
+## 今天的小测验
+
+1. Well-Architected Framework 的五大支柱分别是什么？
+2. "可靠性"支柱的核心思想是什么？
+3. 四个 9（99.99%）的可用性意味着一年最多停机多久？
+4. 灾难恢复的四种策略各自的恢复时间和成本如何？
+
+---
+
+## 延伸阅读
+
+- [Well-Architected Framework 白皮书](https://docs.aws.amazon.com/wellarchitected/latest/framework/)
+- [Well-Architected Tool](https://aws.amazon.com/well-architected-tool/)
+- [AWS 灾难恢复白皮书](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+
+---
+
+## 明天预告
+
+明天是第五阶段的收尾：运维综合实战。我们会模拟一个生产环境的故障排查过程，把监控、日志、告警、恢复等知识串联起来。

课程/第五阶段-监控与运维/第36天-运维综合实战.md

@@ -0,0 +1,283 @@
+# 第36天：运维综合实战——故障排查与应急响应
+
+## 今天你将学到什么
+
+今天是第五阶段的收尾。我们通过模拟真实的生产故障场景，把监控、日志、告警、恢复等知识串联起来，学习如何系统化地排查和解决问题。
+
+---
+
+## 故障排查的基本方法论
+
+### OODA 循环
+
+军事领域的决策模型，同样适用于故障排查：
+
+```
+Observe（观察）→ Orient（定位）→ Decide（决策）→ Act（行动）
+     ↑                                              ↓
+     └──────────────── 循环 ←───────────────────────┘
+```
+
+1. **观察**：收集信息。看监控、看日志、看告警
+2. **定位**：分析问题在哪里。是网络？应用？数据库？
+3. **决策**：确定修复方案。重启？回滚？扩容？
+4. **行动**：执行修复。验证是否恢复
+
+---
+
+## 故障场景一：网站突然变慢
+
+### 用户反馈
+
+"网站加载要 10 秒以上，之前只要 1 秒。"
+
+### 排查过程
+
+**第一步：看 CloudWatch 仪表板**
+
+```
+发现：
+- ALB 的 TargetResponseTime 从 200ms 飙升到 8000ms
+- EC2 的 CPU 使用率正常（30%）
+- 内存使用率正常（50%）
+```
+
+CPU 和内存都正常，但响应很慢。问题不在计算资源。
+
+**第二步：看数据库指标**
+
+```
+发现：
+- RDS 的 DatabaseConnections 达到上限（100/100）
+- RDS 的 ReadLatency 从 5ms 飙升到 2000ms
+- 活跃查询数异常高
+```
+
+数据库连接数满了！新请求拿不到连接，只能等待。
+
+**第三步：看 CloudWatch Logs**
+
+在应用日志中搜索 "timeout" 或 "connection"：
+
+```
+[ERROR] Could not get database connection from pool: timeout after 5000ms
+[WARN] Slow query detected: SELECT * FROM orders WHERE status='pending' - 3500ms
+```
+
+找到了一个慢查询！
+
+**第四步：定位根因**
+
+查看最近的部署记录（CloudTrail）：
+
+```
+发现：2 小时前有一次部署，新代码中有一个查询没有加索引，
+导致全表扫描。随着数据量增长，查询越来越慢，最终拖垮了连接池。
+```
+
+### 修复方案
+
+```
+紧急修复（5 分钟内恢复）：
+1. 回滚到上一个版本（CodeDeploy 一键回滚）
+2. 验证响应时间恢复正常
+
+根本修复（之后处理）：
+1. 给 orders 表的 status 字段加索引
+2. 修复代码中的查询
+3. 加入慢查询监控告警
+4. 重新部署
+```
+
+---
+
+## 故障场景二：服务完全不可用
+
+### 告警触发
+
+CloudWatch 告警：ALB 的 HealthyHostCount = 0（没有健康的后端实例）
+
+### 排查过程
+
+**第一步：检查 EC2 实例状态**
+
+```
+发现：
+- Auto Scaling Group 中有 3 台实例
+- 所有实例状态都是 "running"
+- 但 ALB 健康检查全部失败
+```
+
+实例在运行，但应用不健康。
+
+**第二步：SSH 登录实例查看**
+
+```
+发现：
+- 应用进程在运行
+- 但磁盘空间 100% 满了
+- 应用无法写入日志文件，导致崩溃
+```
+
+**第三步：确认原因**
+
+```
+发现：
+- 昨天开启了 DEBUG 级别日志（为了排查另一个问题）
+- 忘记关闭了
+- DEBUG 日志量巨大，一晚上写满了 50GB 磁盘
+```
+
+### 修复方案
+
+```
+紧急修复：
+1. 清理旧日志文件，释放磁盘空间
+2. 将日志级别改回 INFO
+3. 重启应用
+4. 验证健康检查通过
+
+预防措施：
+1. 设置磁盘使用率告警（> 80% 就通知）
+2. 配置日志轮转（logrotate），自动清理旧日志
+3. 将日志发送到 CloudWatch Logs，不依赖本地磁盘
+4. 制定规范：DEBUG 日志只在开发环境开启
+```
+
+---
+
+## 故障场景三：费用异常暴涨
+
+### 告警触发
+
+Budget 告警：本月费用已达预算的 300%
+
+### 排查过程
+
+**第一步：Cost Explorer 分析**
+
+```
+发现：
+- EC2 费用暴涨 10 倍
+- 来自 us-east-1 区域
+- 实例类型：p3.8xlarge（GPU 实例，$12/小时）
+```
+
+你的团队从来不用 GPU 实例，也不在 us-east-1 工作。
+
+**第二步：CloudTrail 查看谁创建的**
+
+```
+发现：
+- 用户 "dev-intern" 的 Access Key 在凌晨 2 点从境外 IP 创建了 20 台 GPU 实例
+- 这些实例在挖矿
+```
+
+账号被盗了！
+
+### 修复方案
+
+```
+紧急修复：
+1. 立刻禁用 dev-intern 的 Access Key
+2. 终止所有异常的 EC2 实例
+3. 检查是否有其他异常资源
+
+安全加固：
+1. 所有用户强制启用 MFA
+2. 设置 IAM 策略限制可创建的实例类型
+3. 设置 Service Control Policy 限制可使用的区域
+4. 启用 GuardDuty 检测异常行为
+5. 联系 AWS Support 申请费用减免
+```
+
+---
+
+## 应急响应流程
+
+### 标准化的应急流程
+
+```
+1. 发现（Detection）
+   - 监控告警触发
+   - 用户报告问题
+   - 自动化检测发现异常
+
+2. 响应（Response）
+   - 确认问题严重程度
+   - 通知相关人员
+   - 组建应急小组
+
+3. 缓解（Mitigation）
+   - 执行紧急修复（回滚、扩容、切换）
+   - 目标：尽快恢复服务，不一定要找到根因
+
+4. 恢复（Recovery）
+   - 确认服务完全恢复
+   - 验证数据完整性
+   - 监控是否有复发
+
+5. 复盘（Post-mortem）
+   - 时间线：什么时候发生了什么
+   - 根因分析：为什么会发生
+   - 改进措施：怎么防止再次发生
+   - 不追责，重改进
+```
+
+### 应急工具箱
+
+| 场景 | 工具 | 操作 |
+|------|------|------|
+| 应用出错 | CodeDeploy | 一键回滚到上一版本 |
+| 流量暴涨 | Auto Scaling | 手动调高最大实例数 |
+| 数据库过载 | RDS | 添加只读副本分担压力 |
+| 安全事件 | IAM | 禁用被盗账号的凭证 |
+| 区域故障 | Route 53 | 切换 DNS 到备用区域 |
+
+---
+
+## 运维最佳实践总结
+
+### 事前准备
+
+1. **完善的监控**：关键指标都有监控和告警
+2. **自动化恢复**：能自动恢复的不要等人工
+3. **定期演练**：模拟故障，验证恢复流程
+4. **文档化**：常见问题的排查步骤写成 Runbook
+5. **备份验证**：定期验证备份能否成功恢复
+
+### 事中响应
+
+1. **先恢复，后排查**：用户体验优先
+2. **沟通透明**：及时通知相关方进展
+3. **记录时间线**：为复盘留下证据
+4. **避免二次故障**：修复操作要谨慎
+
+### 事后改进
+
+1. **无责复盘**：关注系统改进，不追究个人
+2. **改进措施落地**：每次复盘的改进项要有人跟进
+3. **分享经验**：让整个团队从故障中学习
+
+---
+
+## 今天的小测验
+
+1. 网站变慢时，排查的第一步应该看什么？
+2. 为什么说"先恢复，后排查"？
+3. 如果发现 AWS 账号被盗，应该立刻做什么？
+4. 故障复盘的目的是什么？为什么强调"无责"？
+
+---
+
+## 延伸阅读
+
+- [AWS 故障排查指南](https://docs.aws.amazon.com/systems-manager/latest/userguide/troubleshooting.html)
+- [AWS Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/)
+- [AWS Fault Injection Simulator](https://docs.aws.amazon.com/fis/latest/userguide/)
+
+---
+
+## 明天预告
+
+进入第六阶段：进阶与认证。明天开始学习 AWS 认证考试的准备策略，以及如何系统化地复习前面学到的所有知识。

课程/第六阶段-进阶与认证/第37天-AWS认证体系.md

@@ -0,0 +1,226 @@
+# 第37天：AWS 认证体系——你的云计算通行证
+
+## 今天你将学到什么
+
+今天了解 AWS 认证体系，帮你规划认证路径。AWS 认证是全球认可的云计算能力证明，对求职和职业发展很有帮助。
+
+---
+
+## AWS 认证全景
+
+### 认证级别
+
+```
+                    ┌─────────────────┐
+                    │   专业级别       │
+                    │  Professional   │
+                    └────────┬────────┘
+                             │
+              ┌──────────────┼──────────────┐
+              │              │              │
+     ┌────────┴───┐  ┌──────┴─────┐  ┌────┴────────┐
+     │ 助理级别    │  │ 助理级别    │  │ 助理级别     │
+     │ Solutions  │  │ Developer  │  │ SysOps      │
+     │ Architect  │  │ Associate  │  │ Administrator│
+     └────────────┘  └────────────┘  └─────────────┘
+                             │
+                    ┌────────┴────────┐
+                    │   基础级别       │
+                    │ Cloud           │
+                    │ Practitioner    │
+                    └─────────────────┘
+```
+
+### 各认证详解
+
+| 认证 | 级别 | 适合谁 | 考试时间 | 题目数 | 通过分 |
+|------|------|--------|----------|--------|--------|
+| Cloud Practitioner | 基础 | 所有人 | 90 分钟 | 65 题 | 700/1000 |
+| Solutions Architect Associate | 助理 | 架构师、开发者 | 130 分钟 | 65 题 | 720/1000 |
+| Developer Associate | 助理 | 开发者 | 130 分钟 | 65 题 | 720/1000 |
+| SysOps Administrator Associate | 助理 | 运维工程师 | 130 分钟 | 65 题 | 720/1000 |
+| Solutions Architect Professional | 专业 | 资深架构师 | 180 分钟 | 75 题 | 750/1000 |
+
+---
+
+## 推荐的认证路径
+
+### 路径一：从零开始
+
+```
+Cloud Practitioner（2-4 周准备）
+    ↓
+Solutions Architect Associate（6-8 周准备）
+    ↓
+根据职业方向选择下一个
+```
+
+### 路径二：有开发经验
+
+```
+Solutions Architect Associate（4-6 周准备）
+    ↓
+Developer Associate（3-4 周准备，很多知识重叠）
+    ↓
+Solutions Architect Professional（8-12 周准备）
+```
+
+### 各认证的侧重点
+
+| 认证 | 侧重 |
+|------|------|
+| Cloud Practitioner | AWS 服务概览、定价、基本架构概念 |
+| Solutions Architect Associate | 架构设计、服务选择、高可用、成本优化 |
+| Developer Associate | 开发工具、CI/CD、无服务器、SDK 使用 |
+| SysOps Administrator | 监控、自动化、安全、故障排查 |
+| Solutions Architect Professional | 复杂架构、迁移策略、多账户、混合云 |
+
+---
+
+## Cloud Practitioner 考试重点
+
+这是最适合入门的认证，考察的是广度而非深度。
+
+### 考试范围
+
+| 领域 | 占比 | 内容 |
+|------|------|------|
+| 云概念 | 24% | 云计算优势、AWS 全球基础设施 |
+| 安全与合规 | 30% | IAM、共享责任模型、安全服务 |
+| 云技术 | 34% | 核心服务（计算、存储、网络、数据库） |
+| 计费与定价 | 12% | 定价模型、成本管理工具 |
+
+### 必须掌握的概念
+
+**云计算优势**：
+- 将资本支出转为运营支出
+- 规模经济效益
+- 无需猜测容量
+- 提高速度和敏捷性
+- 不再花钱运维数据中心
+- 数分钟内全球部署
+
+**共享责任模型**：
+```
+AWS 负责：云的安全（物理设施、网络、虚拟化层）
+你负责：云中的安全（数据、应用、IAM、操作系统补丁）
+```
+
+**核心服务对应关系**：
+| 需求 | 服务 |
+|------|------|
+| 运行服务器 | EC2 |
+| 无服务器计算 | Lambda |
+| 对象存储 | S3 |
+| 关系型数据库 | RDS / Aurora |
+| NoSQL 数据库 | DynamoDB |
+| 内容分发 | CloudFront |
+| DNS | Route 53 |
+| 监控 | CloudWatch |
+| 审计 | CloudTrail |
+
+---
+
+## Solutions Architect Associate 考试重点
+
+这是含金量最高的助理级认证，也是最受欢迎的 AWS 认证。
+
+### 考试范围
+
+| 领域 | 占比 | 内容 |
+|------|------|------|
+| 安全架构设计 | 30% | IAM、加密、网络安全 |
+| 弹性架构设计 | 26% | 高可用、容错、解耦 |
+| 高性能架构 | 24% | 计算、存储、数据库、网络优化 |
+| 成本优化架构 | 20% | 定价模型、存储优化、计算优化 |
+
+### 高频考点
+
+**架构设计题型**：给你一个场景，问你选什么服务、怎么设计。
+
+常见场景：
+- "需要高可用的 Web 应用" → Multi-AZ + ALB + Auto Scaling
+- "需要处理突发流量" → Auto Scaling + SQS 削峰
+- "需要全球低延迟" → CloudFront + 多区域部署
+- "需要松耦合" → SQS / SNS / EventBridge
+- "需要无服务器" → Lambda + API Gateway + DynamoDB
+- "需要数据加密" → KMS + S3 SSE + RDS 加密
+
+---
+
+## 备考策略
+
+### 学习资源
+
+| 资源 | 类型 | 费用 | 推荐度 |
+|------|------|------|--------|
+| AWS Skill Builder | 官方课程 | 免费/付费 | 必看 |
+| AWS 官方文档 | 文档 | 免费 | 参考 |
+| AWS 白皮书 | 深度文档 | 免费 | 重要 |
+| 模拟考试 | 练习题 | 付费 | 必做 |
+| 动手实验 | 实践 | Free Tier | 强烈推荐 |
+
+### 备考时间表（以 SAA 为例）
+
+| 周次 | 内容 |
+|------|------|
+| 第 1-2 周 | 学习核心服务（计算、存储、数据库、网络） |
+| 第 3-4 周 | 学习安全、监控、应用集成 |
+| 第 5-6 周 | 学习架构设计模式、做练习题 |
+| 第 7-8 周 | 模拟考试、查漏补缺、重点复习薄弱项 |
+
+### 考试技巧
+
+1. **排除法**：很多题目可以先排除明显错误的选项
+2. **关键词**：注意题目中的关键词
+   - "最经济" → 选最便宜的方案
+   - "最少运维" → 选托管服务或无服务器
+   - "最高可用" → 选多 AZ、多区域
+   - "最安全" → 选加密、最小权限
+3. **时间管理**：130 分钟 65 题，平均 2 分钟一题。不确定的先标记，最后回来看
+4. **动手实践**：光看书不够，一定要在 AWS 上动手操作
+
+---
+
+## 认证的价值
+
+### 对求职
+
+- 很多公司的 JD 明确要求或优先 AWS 认证
+- 证明你有系统化的云计算知识
+- 全球认可，跨国公司尤其看重
+
+### 对职业发展
+
+- 系统化学习的过程本身就很有价值
+- 帮你建立完整的知识体系
+- AWS 认证持有者社区和活动
+
+### 对薪资
+
+- 有认证的云工程师平均薪资比无认证高 15-25%
+- 高级认证（Professional、Specialty）溢价更高
+
+---
+
+## 今天的小测验
+
+1. AWS 认证分为哪几个级别？各适合什么人？
+2. 对于初学者，推荐的认证路径是什么？
+3. Solutions Architect Associate 考试的四个领域是什么？
+4. "共享责任模型"中，AWS 和用户各负责什么？
+
+---
+
+## 延伸阅读
+
+- [AWS 认证官网](https://aws.amazon.com/certification/)
+- [AWS Skill Builder](https://skillbuilder.aws/)
+- [AWS 白皮书列表](https://aws.amazon.com/whitepapers/)
+- [AWS 认证考试指南](https://aws.amazon.com/certification/certification-prep/)
+
+---
+
+## 明天预告
+
+明天进行全面的知识复习——用思维导图的方式串联所有学过的知识点，帮你建立完整的 AWS 知识体系。

课程/第六阶段-进阶与认证/第38天-知识体系总复习.md

@@ -0,0 +1,280 @@
+# 第38天：知识体系总复习——串联所有知识点
+
+## 今天你将学到什么
+
+今天用结构化的方式回顾过去 37 天学到的所有内容，帮你建立完整的 AWS 知识地图。这不是简单的重复，而是从更高的视角看各个服务之间的关系。
+
+---
+
+## AWS 服务全景图
+
+### 按功能分类
+
+```
+计算
+├── EC2（虚拟服务器）
+├── Lambda（无服务器函数）
+├── ECS / EKS（容器）
+└── Fargate（无服务器容器）
+
+存储
+├── S3（对象存储）
+├── EBS（块存储，EC2 硬盘）
+├── EFS（文件存储，共享）
+└── S3 Glacier（归档）
+
+数据库
+├── RDS / Aurora（关系型）
+├── DynamoDB（NoSQL）
+└── ElastiCache（缓存）
+
+网络
+├── VPC（虚拟网络）
+├── ALB / NLB（负载均衡）
+├── Route 53（DNS）
+├── CloudFront（CDN）
+└── VPC Endpoint / PrivateLink
+
+安全
+├── IAM（身份与访问）
+├── KMS（加密密钥）
+├── Secrets Manager（密码管理）
+├── WAF / Shield（Web 防护）
+├── GuardDuty（威胁检测）
+└── CloudTrail（审计日志）
+
+应用集成
+├── SQS（消息队列）
+├── SNS（通知服务）
+├── EventBridge（事件总线）
+├── Step Functions（工作流）
+└── API Gateway（API 管理）
+
+开发工具
+├── CodePipeline（CI/CD 流水线）
+├── CodeBuild（构建）
+├── CodeDeploy（部署）
+└── CloudFormation（基础设施即代码）
+
+监控与管理
+├── CloudWatch（监控、日志、告警）
+├── AWS Config（配置合规）
+├── Trusted Advisor（优化建议）
+└── Cost Explorer / Budgets（成本管理）
+```
+
+---
+
+## 核心架构模式
+
+### 模式一：经典 Web 应用
+
+```
+Route 53 → CloudFront → ALB → Auto Scaling (EC2) → RDS Multi-AZ
+```
+
+**适合**：传统 Web 应用、需要完全控制的场景
+
+### 模式二：无服务器应用
+
+```
+Route 53 → CloudFront → API Gateway → Lambda → DynamoDB
+```
+
+**适合**：API 后端、事件驱动、流量不稳定的应用
+
+### 模式三：容器化微服务
+
+```
+Route 53 → ALB → ECS Fargate (多个服务) → Aurora + DynamoDB + Redis
+                                         → SQS/SNS (异步通信)
+```
+
+**适合**：中大型应用、需要独立部署和扩展的微服务
+
+### 模式四：事件驱动架构
+
+```
+事件源 → EventBridge → Lambda / Step Functions → 各种目标服务
+```
+
+**适合**：松耦合系统、异步处理、复杂业务流程
+
+---
+
+## 服务选择决策树
+
+### 计算服务怎么选
+
+```
+需要运行代码？
+├── 运行时间 < 15 分钟？
+│   ├── 是 → Lambda
+│   └── 否 ↓
+├── 需要容器？
+│   ├── 是 → 想管服务器吗？
+│   │        ├── 不想 → Fargate
+│   │        └── 想要控制 → ECS on EC2
+│   └── 否 ↓
+└── 需要虚拟机 → EC2
+```
+
+### 数据库怎么选
+
+```
+需要存储数据？
+├── 需要复杂查询（JOIN、事务）？
+│   ├── 是 → RDS / Aurora
+│   └── 否 ↓
+├── 键值查询、高频读写？
+│   ├── 是 → DynamoDB
+│   └── 否 ↓
+├── 需要缓存加速？
+│   ├── 是 → ElastiCache (Redis)
+│   └── 否 ↓
+└── 全文搜索？ → OpenSearch
+```
+
+### 存储怎么选
+
+```
+需要存储文件？
+├── 文件需要被多台服务器共享？
+│   ├── 是 → EFS
+│   └── 否 ↓
+├── 通过 HTTP 访问（图片、视频、备份）？
+│   ├── 是 → S3
+│   └── 否 ↓
+├── EC2 的硬盘？
+│   └── 是 → EBS
+└── 归档（很少访问）？ → S3 Glacier
+```
+
+### 消息服务怎么选
+
+```
+需要服务间通信？
+├── 一条消息只需要一个消费者处理？
+│   ├── 是 → SQS
+│   └── 否 ↓
+├── 一条消息需要多个消费者同时收到？
+│   ├── 是 → SNS（配合 SQS 做扇出）
+│   └── 否 ↓
+└── 需要基于事件内容路由到不同目标？
+    └── 是 → EventBridge
+```
+
+---
+
+## 关键概念速查
+
+### 高可用相关
+
+| 概念 | 含义 | 实现 |
+|------|------|------|
+| Multi-AZ | 跨可用区部署 | RDS Multi-AZ、ALB 跨 AZ |
+| Auto Scaling | 自动增减实例 | EC2 Auto Scaling Group |
+| 负载均衡 | 流量分发 | ALB / NLB |
+| 健康检查 | 自动发现故障 | ALB / Route 53 健康检查 |
+| 故障转移 | 自动切换到备用 | RDS 故障转移、Route 53 故障转移路由 |
+
+### 安全相关
+
+| 概念 | 含义 | 实现 |
+|------|------|------|
+| 最小权限 | 只给必要的权限 | IAM 策略精确控制 |
+| 纵深防御 | 多层防护 | WAF + 安全组 + 网络 ACL |
+| 加密一切 | 数据加密存储和传输 | KMS + HTTPS |
+| 审计追踪 | 记录所有操作 | CloudTrail |
+| 密码管理 | 不硬编码密码 | Secrets Manager |
+
+### 成本相关
+
+| 概念 | 含义 | 实现 |
+|------|------|------|
+| 按需付费 | 用多少付多少 | 默认定价模式 |
+| 预留折扣 | 承诺使用换折扣 | Savings Plans / Reserved Instances |
+| Spot 实例 | 用闲置资源省钱 | 可中断的工作负载 |
+| 自动扩缩 | 不过度预置 | Auto Scaling |
+| 存储分层 | 不同访问频率用不同存储 | S3 生命周期策略 |
+
+---
+
+## 常见场景与解决方案
+
+| 场景 | 解决方案 |
+|------|----------|
+| 网站需要全球快速访问 | CloudFront + S3（静态）/ ALB（动态） |
+| 应用需要处理突发流量 | Auto Scaling + SQS 削峰 |
+| 数据库读取压力大 | ElastiCache 缓存 + Aurora 只读副本 |
+| 需要定时执行任务 | EventBridge 定时规则 + Lambda |
+| 文件上传后需要处理 | S3 事件通知 → Lambda |
+| 多个服务需要协调 | Step Functions 编排 |
+| 需要实时通知用户 | SNS + 移动推送 / WebSocket |
+| 需要搜索功能 | OpenSearch |
+| 需要用户认证 | Cognito |
+| 需要 API 管理 | API Gateway |
+
+---
+
+## 架构设计原则总结
+
+### 十大原则
+
+1. **为故障设计**：假设一切都会坏，设计自动恢复机制
+2. **解耦组件**：用消息队列和事件让服务松耦合
+3. **弹性伸缩**：根据负载自动调整资源
+4. **安全优先**：加密一切、最小权限、纵深防御
+5. **自动化一切**：基础设施即代码、CI/CD、自动化运维
+6. **使用托管服务**：能用托管的就不自建
+7. **缓存加速**：在各层添加缓存减少延迟
+8. **异步处理**：不需要立即结果的操作异步执行
+9. **监控一切**：没有监控就是盲人开车
+10. **持续优化**：定期审查架构和成本
+
+---
+
+## 学习路径回顾
+
+```
+第一阶段（第 1-7 天）：基础概念
+  云计算 → AWS 账户 → IAM → CLI
+
+第二阶段（第 8-19 天）：核心服务
+  EC2 → Lambda → S3 → 数据库 → VPC → DNS/CDN → 消息服务
+
+第三阶段（第 20-25 天）：安全
+  IAM 策略 → 加密 → WAF/Shield → CloudTrail → VPC 安全
+
+第四阶段（第 26-32 天）：应用架构
+  容器 → ECS → CI/CD → Step Functions → API Gateway → 微服务
+
+第五阶段（第 33-36 天）：监控与运维
+  CloudWatch → 成本管理 → Well-Architected → 故障排查
+
+第六阶段（第 37-40 天）：进阶与认证
+  认证体系 → 知识总复习 → 实战项目 → 持续学习
+```
+
+---
+
+## 今天的小测验
+
+1. 如果要设计一个高可用的 Web 应用，至少需要哪些 AWS 服务？
+2. Lambda 和 EC2 各自适合什么场景？
+3. SQS、SNS、EventBridge 三者的区别是什么？
+4. 说出 Well-Architected Framework 的五大支柱。
+
+---
+
+## 延伸阅读
+
+- [AWS 服务概览](https://aws.amazon.com/products/)
+- [AWS 架构中心](https://aws.amazon.com/architecture/)
+- [AWS 解决方案库](https://aws.amazon.com/solutions/)
+
+---
+
+## 明天预告
+
+明天是实战项目日——从零开始设计并规划一个完整的云原生应用，综合运用所有学到的知识。

课程/第六阶段-进阶与认证/第39天-实战项目设计.md

@@ -0,0 +1,256 @@
+# 第39天：实战项目——从零设计一个云原生应用
+
+## 今天你将学到什么
+
+今天是综合实战日。我们从零开始设计一个完整的云原生应用——"智能笔记"平台，综合运用前面学到的所有知识。这个练习帮你把零散的知识点串联成完整的架构思维。
+
+---
+
+## 项目需求
+
+### 产品描述：智能笔记平台
+
+一个支持 AI 辅助的笔记应用：
+- 用户可以创建、编辑、组织笔记
+- 支持图片和文件附件
+- AI 功能：自动摘要、智能标签、相关笔记推荐
+- 支持笔记分享和协作
+- 支持全文搜索
+- 移动端和 Web 端
+
+### 非功能需求
+
+| 需求 | 目标 |
+|------|------|
+| 可用性 | 99.9%（月停机 < 44 分钟） |
+| 响应时间 | API P99 < 500ms |
+| 用户规模 | 初期 1 万用户，目标 100 万用户 |
+| 数据安全 | 所有数据加密，符合隐私法规 |
+| 成本 | 初期月费 < $500 |
+
+---
+
+## 架构设计过程
+
+### 第一步：识别核心功能模块
+
+```
+1. 用户管理（注册、登录、个人设置）
+2. 笔记 CRUD（创建、读取、更新、删除）
+3. 文件管理（上传、下载附件）
+4. AI 处理（摘要、标签、推荐）
+5. 搜索（全文搜索笔记内容）
+6. 分享与协作（分享链接、协作编辑）
+7. 通知（新分享、AI 处理完成）
+```
+
+### 第二步：选择技术方案
+
+| 模块 | 方案 | 原因 |
+|------|------|------|
+| 用户管理 | Cognito | 开箱即用，支持社交登录，免运维 |
+| 笔记 API | API Gateway + Lambda | 无服务器，按需付费，初期成本低 |
+| 笔记存储 | DynamoDB | 灵活 schema，毫秒响应，自动扩展 |
+| 文件存储 | S3 | 无限容量，便宜，配合 CloudFront 加速 |
+| AI 处理 | Lambda + SQS | 异步处理，不阻塞用户操作 |
+| 搜索 | OpenSearch Serverless | 全文搜索，无服务器模式省钱 |
+| 实时协作 | API Gateway WebSocket | 双向通信，按连接付费 |
+| 通知 | SNS + 移动推送 | 多渠道通知 |
+| 前端托管 | S3 + CloudFront | 全球加速，成本极低 |
+
+### 第三步：画架构图
+
+```
+用户（Web / 移动端）
+        ↓
+CloudFront
+├── 静态资源 → S3（前端代码）
+└── API 请求 → API Gateway
+                    ↓
+              ┌─── Cognito 认证
+              ↓
+        Lambda 函数层
+        ├── 笔记服务 → DynamoDB（笔记数据）
+        ├── 文件服务 → S3（附件）+ 预签名 URL
+        ├── 搜索服务 → OpenSearch
+        └── 分享服务 → DynamoDB（分享关系）
+
+异步处理层：
+  DynamoDB Stream → Lambda → SQS → AI 处理 Lambda
+                                        ↓
+                                  ├── 生成摘要（调用 AI API）
+                                  ├── 提取标签
+                                  └── 更新 DynamoDB + OpenSearch
+
+实时协作：
+  API Gateway WebSocket → Lambda → DynamoDB + 连接管理
+```
+
+---
+
+## 详细设计
+
+### 数据模型（DynamoDB）
+
+```
+笔记表（Notes）：
+  PK: USER#<userId>
+  SK: NOTE#<noteId>
+  属性：title, content, tags, summary, createdAt, updatedAt
+
+分享表（Shares）：
+  PK: NOTE#<noteId>
+  SK: SHARE#<shareId>
+  属性：sharedWith, permission, createdAt
+
+全局二级索引（GSI）：
+  GSI1: 按更新时间排序（获取最近编辑的笔记）
+  GSI2: 按标签查询（获取某个标签下的所有笔记）
+```
+
+### API 设计
+
+| 方法 | 路径 | 功能 |
+|------|------|------|
+| POST | /notes | 创建笔记 |
+| GET | /notes | 获取笔记列表 |
+| GET | /notes/{id} | 获取单个笔记 |
+| PUT | /notes/{id} | 更新笔记 |
+| DELETE | /notes/{id} | 删除笔记 |
+| POST | /notes/{id}/share | 分享笔记 |
+| GET | /search?q=keyword | 搜索笔记 |
+| POST | /upload | 获取文件上传 URL |
+
+### 安全设计
+
+```
+认证：Cognito JWT Token
+授权：Lambda 中验证用户只能访问自己的笔记
+传输加密：HTTPS（CloudFront 强制）
+存储加密：DynamoDB + S3 使用 KMS 加密
+密钥管理：API 密钥存在 Secrets Manager
+审计：CloudTrail 记录所有 API 调用
+```
+
+### AI 处理流程（Step Functions）
+
+```
+笔记保存触发
+    ↓
+DynamoDB Stream → Lambda（判断是否需要 AI 处理）
+    ↓
+Step Functions 工作流：
+    ↓
+并行执行：
+├── 生成摘要（Lambda → AI API）
+├── 提取关键词标签（Lambda → AI API）
+└── 计算相关笔记（Lambda → OpenSearch）
+    ↓
+合并结果
+    ↓
+更新 DynamoDB（写入摘要、标签、推荐）
+    ↓
+通知用户"AI 处理完成"（SNS → 推送）
+```
+
+---
+
+## 运维设计
+
+### 监控
+
+```
+CloudWatch Dashboard：
+├── API 指标：请求量、延迟、错误率
+├── Lambda：调用次数、执行时间、错误数
+├── DynamoDB：读写容量、延迟、节流次数
+└── 业务指标：活跃用户数、笔记创建数
+
+告警：
+├── API 错误率 > 1% → 通知开发团队
+├── Lambda 执行时间 > 5s → 通知
+├── DynamoDB 节流 > 0 → 自动扩容
+└── 月费用 > $400 → 通知
+```
+
+### CI/CD
+
+```
+GitHub → CodePipeline：
+  ├── 前端流水线：构建 → 部署到 S3 → 刷新 CloudFront 缓存
+  └── 后端流水线：测试 → 打包 → 部署 Lambda 函数（SAM/CDK）
+```
+
+---
+
+## 成本估算（初期 1 万用户）
+
+| 服务 | 用量估算 | 月费 |
+|------|----------|------|
+| Lambda | 500 万次调用 | $10 |
+| API Gateway | 500 万次请求 | $17 |
+| DynamoDB | 按需模式，5GB 数据 | $25 |
+| S3 | 50GB 文件 | $2 |
+| CloudFront | 100GB 流量 | $9 |
+| Cognito | 1 万用户 | $0（5 万内免费） |
+| OpenSearch Serverless | 最小配置 | $175 |
+| CloudWatch | 基本监控 | $10 |
+| 其他 | Secrets Manager、KMS | $5 |
+| **总计** | | **约 $253/月** |
+
+满足 < $500 的预算要求。随着用户增长，DynamoDB 和 Lambda 会自动扩展，费用线性增长。
+
+---
+
+## 扩展到 100 万用户
+
+当用户从 1 万增长到 100 万时，需要的调整：
+
+| 组件 | 调整 | 原因 |
+|------|------|------|
+| DynamoDB | 自动扩展（无需操作） | 按需模式自动处理 |
+| Lambda | 提高并发限制 | 默认 1000 并发可能不够 |
+| OpenSearch | 增加容量 | 搜索量增大 |
+| CloudFront | 无需调整 | 自动全球扩展 |
+| 缓存 | 添加 DAX 或 ElastiCache | 减少 DynamoDB 读取压力 |
+| API Gateway | 无需调整 | 自动扩展 |
+
+**无服务器架构的优势**：大部分组件自动扩展，不需要提前规划容量。
+
+---
+
+## 从这个项目中学到什么
+
+### 架构决策的思考过程
+
+1. **先确定需求**：功能需求 + 非功能需求
+2. **选择架构风格**：无服务器 vs 容器 vs 虚拟机
+3. **为每个模块选择服务**：根据特点匹配最合适的服务
+4. **设计数据模型**：根据访问模式选择数据库和表结构
+5. **设计安全方案**：认证、授权、加密、审计
+6. **设计运维方案**：监控、告警、CI/CD
+7. **估算成本**：确保在预算内
+8. **规划扩展**：考虑未来增长
+
+---
+
+## 今天的小测验
+
+1. 为什么这个项目选择无服务器架构而不是容器？
+2. AI 处理为什么要异步执行而不是同步？
+3. 为什么笔记数据用 DynamoDB 而不是 RDS？
+4. 如果搜索功能的成本太高，有什么替代方案？
+
+---
+
+## 延伸阅读
+
+- [AWS 无服务器应用示例](https://serverlessland.com/)
+- [DynamoDB 数据建模](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html)
+- [AWS SAM（Serverless Application Model）](https://docs.aws.amazon.com/serverless-application-model/)
+
+---
+
+## 明天预告
+
+明天是最后一天：持续学习指南。了解学完这个课程后如何继续深入学习，保持技术更新，以及 AWS 社区资源。

课程/第六阶段-进阶与认证/第40天-持续学习指南.md

@@ -0,0 +1,205 @@
+# 第40天：持续学习指南——毕业不是终点
+
+## 今天你将学到什么
+
+恭喜你完成了 40 天的 AWS 学习之旅！今天聊聊接下来怎么继续成长：如何保持技术更新、深入学习的方向、有用的社区资源。
+
+---
+
+## 你已经掌握了什么
+
+回顾一下这 40 天的收获：
+
+```
+✓ 云计算基础概念和 AWS 全球基础设施
+✓ IAM 身份与访问管理
+✓ 计算服务（EC2、Lambda、ECS）
+✓ 存储服务（S3、EBS、EFS）
+✓ 数据库服务（RDS、Aurora、DynamoDB、ElastiCache）
+✓ 网络服务（VPC、ALB、Route 53、CloudFront）
+✓ 安全服务（KMS、WAF、Shield、GuardDuty、CloudTrail）
+✓ 应用集成（SQS、SNS、EventBridge、Step Functions）
+✓ 容器与微服务（Docker、ECS、API Gateway）
+✓ CI/CD 与基础设施即代码
+✓ 监控与运维（CloudWatch、成本管理）
+✓ 架构设计原则（Well-Architected Framework）
+✓ 认证考试准备策略
+```
+
+这些知识覆盖了 AWS Solutions Architect Associate 考试约 80% 的内容。你已经有了扎实的基础。
+
+---
+
+## 接下来的学习方向
+
+### 方向一：考取认证
+
+如果你的目标是 AWS 认证：
+
+**Cloud Practitioner（2-4 周）**：
+- 你已经掌握了大部分内容
+- 重点复习：定价模型、共享责任模型、服务概览
+- 做 2-3 套模拟题就可以考试了
+
+**Solutions Architect Associate（4-6 周额外准备）**：
+- 深入学习：架构设计场景题
+- 重点：高可用设计、成本优化、安全最佳实践
+- 多做模拟题，熟悉题目风格
+
+### 方向二：深入某个领域
+
+| 方向 | 深入学习内容 | 适合 |
+|------|-------------|------|
+| 无服务器 | SAM、CDK、Lambda 高级用法、DynamoDB 高级建模 | 后端开发者 |
+| 容器与 K8s | EKS 深入、Helm、Service Mesh、GitOps | DevOps 工程师 |
+| 数据工程 | Kinesis、Glue、Athena、Redshift、Lake Formation | 数据工程师 |
+| 机器学习 | SageMaker、Bedrock、AI/ML 服务 | AI 工程师 |
+| 安全 | Security Specialty 认证、渗透测试、合规 | 安全工程师 |
+
+### 方向三：动手实践
+
+**最重要的建议：动手做项目。**
+
+看再多文档不如自己动手搭一个。推荐的练手项目：
+
+| 项目 | 涉及服务 | 难度 |
+|------|----------|------|
+| 个人博客（静态网站） | S3 + CloudFront + Route 53 | 入门 |
+| URL 短链接服务 | API Gateway + Lambda + DynamoDB | 初级 |
+| 图片处理服务 | S3 + Lambda + SQS | 初级 |
+| 聊天应用 | WebSocket API + Lambda + DynamoDB | 中级 |
+| 电商后端 | ECS + RDS + ElastiCache + SQS | 中级 |
+| 数据分析平台 | Kinesis + Lambda + S3 + Athena | 中高级 |
+
+---
+
+## 保持技术更新
+
+### AWS 更新速度
+
+AWS 每年发布数千个新功能和服务。保持更新很重要。
+
+### 推荐的信息源
+
+| 来源 | 内容 | 频率 |
+|------|------|------|
+| AWS 官方博客 | 新服务发布、最佳实践 | 每天 |
+| AWS re:Invent | 年度大会，重大发布 | 每年 11-12 月 |
+| AWS re:Post | 社区问答 | 随时 |
+| AWS This Week | 每周新闻摘要 | 每周 |
+| Last Week in AWS | 第三方周报，有趣且实用 | 每周 |
+
+### 值得关注的趋势（2024-2025）
+
+| 趋势 | 说明 |
+|------|------|
+| 生成式 AI | Bedrock、SageMaker、AI 集成到各服务 |
+| 无服务器优先 | 越来越多服务提供 Serverless 模式 |
+| 基础设施即代码 | CDK 越来越流行，取代 CloudFormation YAML |
+| 可观测性 | OpenTelemetry、CloudWatch 增强 |
+| 零信任安全 | Verified Access、更细粒度的访问控制 |
+
+---
+
+## 学习资源汇总
+
+### 免费资源
+
+| 资源 | 说明 |
+|------|------|
+| [AWS Free Tier](https://aws.amazon.com/free/) | 12 个月免费额度，动手实践 |
+| [AWS Skill Builder](https://skillbuilder.aws/) | 官方免费课程 |
+| [AWS Workshop](https://workshops.aws/) | 官方动手实验 |
+| [AWS 白皮书](https://aws.amazon.com/whitepapers/) | 深度技术文档 |
+| [AWS 官方文档](https://docs.aws.amazon.com/) | 最权威的参考 |
+| [AWS Samples (GitHub)](https://github.com/aws-samples) | 官方代码示例 |
+
+### 社区资源
+
+| 资源 | 说明 |
+|------|------|
+| AWS re:Post | 官方社区论坛 |
+| Stack Overflow | 技术问答 |
+| Reddit r/aws | 讨论和经验分享 |
+| AWS User Group | 本地用户组活动 |
+| AWS Community Builders | 社区贡献者计划 |
+
+### 实践平台
+
+| 平台 | 说明 |
+|------|------|
+| AWS Free Tier | 真实 AWS 环境 |
+| AWS Workshops | 引导式实验 |
+| Qwiklabs / Cloud Quest | 交互式学习 |
+| LocalStack | 本地模拟 AWS 服务（免费） |
+
+---
+
+## 给初学者的最终建议
+
+### 1. 不要试图学完所有服务
+
+AWS 有 200+ 个服务。没有人全部精通。掌握核心的 20-30 个服务就足够应对大多数场景。
+
+### 2. 理解概念比记住细节重要
+
+具体的配置参数可以查文档。但"什么时候用 SQS 什么时候用 SNS"这种架构判断力需要深入理解。
+
+### 3. 动手 > 看书
+
+看 10 遍文档不如自己搭一次。犯错是最好的学习方式（在 Free Tier 里犯错不花钱）。
+
+### 4. 从小项目开始
+
+不要一上来就设计百万用户的系统。先做一个能跑的小东西，再逐步优化和扩展。
+
+### 5. 加入社区
+
+一个人学习容易放弃。加入 AWS 用户组、参加线上/线下活动、和同行交流。
+
+### 6. 设置 Billing Alarm
+
+再说一次：一定要设置账单告警！避免意外花费。
+
+---
+
+## 学习路线图
+
+```
+现在（第 40 天）
+  ↓
+短期（1-2 个月）：
+  - 考取 Cloud Practitioner 认证
+  - 完成 1-2 个动手项目
+  - 开始准备 SAA 考试
+  ↓
+中期（3-6 个月）：
+  - 考取 Solutions Architect Associate
+  - 在工作中应用 AWS 知识
+  - 深入学习感兴趣的方向
+  ↓
+长期（6-12 个月）：
+  - 考取更高级认证或专业认证
+  - 参与开源项目或社区贡献
+  - 成为团队中的 AWS 专家
+```
+
+---
+
+## 结语
+
+40 天前你可能对云计算一无所知，现在你已经理解了 AWS 的核心服务和架构设计原则。这是一个很好的开始。
+
+云计算是一个快速发展的领域，保持好奇心和学习的习惯比任何具体的技术知识都重要。
+
+祝你在云计算的道路上越走越远！
+
+---
+
+## 延伸阅读
+
+- [AWS 认证官网](https://aws.amazon.com/certification/)
+- [AWS 架构中心](https://aws.amazon.com/architecture/)
+- [AWS Skill Builder](https://skillbuilder.aws/)
+- [Serverless Land](https://serverlessland.com/)
+- [AWS Well-Architected Labs](https://wellarchitectedlabs.com/)

课程/第四阶段-应用架构/第26天-Docker与容器基础.md

@@ -0,0 +1,189 @@
+# 第26天：Docker 与容器基础——为什么现代应用都在用容器
+
+## 今天你将学到什么
+
+今天学习容器技术的基础概念。容器是现代应用部署的主流方式，理解它能帮你明白 AWS 的 ECS、EKS、Fargate 等服务在做什么。
+
+---
+
+## 传统部署的痛点
+
+### "在我电脑上能跑啊！"
+
+每个开发者都经历过这个场景：
+
+- 开发者在自己电脑上写好代码，测试通过
+- 部署到服务器上，报错了
+- 原因：服务器的 Python 版本不一样 / 缺少某个库 / 配置文件路径不同
+
+**根本问题**：应用依赖的环境（操作系统、语言版本、库、配置）在不同机器上不一致。
+
+### 虚拟机能解决，但太重了
+
+虚拟机（VM）可以解决环境一致性问题——把整个操作系统打包。但是：
+
+- 一个虚拟机动辄几个 GB
+- 启动要几分钟
+- 每个虚拟机都运行一个完整的操作系统，浪费资源
+- 一台物理机上跑不了太多虚拟机
+
+---
+
+## 容器是什么
+
+### 类比理解
+
+**虚拟机** = 独栋别墅。每栋房子有自己的地基、水电系统、花园。独立但占地大、建造慢。
+
+**容器** = 集装箱公寓。共享地基和水电系统，每个集装箱内部是独立的生活空间。轻量、快速、可以密集排列。
+
+### 技术角度
+
+容器是一种轻量级的隔离环境：
+- 共享宿主机的操作系统内核（不需要自己的操作系统）
+- 有自己独立的文件系统、网络、进程空间
+- 启动只需要几秒钟
+- 镜像大小通常只有几十到几百 MB
+
+### 虚拟机 vs 容器
+
+| 特性 | 虚拟机 | 容器 |
+|------|--------|------|
+| 大小 | 几 GB | 几十~几百 MB |
+| 启动时间 | 几分钟 | 几秒 |
+| 资源占用 | 高（完整 OS） | 低（共享内核） |
+| 隔离性 | 强（硬件级别） | 较强（进程级别） |
+| 密度 | 一台机器跑几个~十几个 | 一台机器跑几十~上百个 |
+| 适合 | 需要不同操作系统、强隔离 | 同一操作系统上运行多个应用 |
+
+---
+
+## Docker——容器的事实标准
+
+Docker 是最流行的容器工具。它让你可以：
+
+1. **打包**：把应用和它的所有依赖打包成一个"镜像"（Image）
+2. **分发**：把镜像上传到仓库，任何人都能下载
+3. **运行**：在任何安装了 Docker 的机器上，用镜像启动容器
+
+### 核心概念
+
+| 概念 | 类比 | 说明 |
+|------|------|------|
+| 镜像（Image） | 菜谱 + 食材包 | 包含应用代码和所有依赖的只读模板 |
+| 容器（Container） | 做好的菜 | 镜像的运行实例，可以启动、停止、删除 |
+| Dockerfile | 菜谱 | 描述如何构建镜像的文本文件 |
+| 仓库（Registry） | 菜谱书店 | 存储和分发镜像的地方 |
+
+### Dockerfile 长什么样
+
+一个简单的 Python Web 应用的 Dockerfile：
+
+```
+FROM python:3.11          ← 基于 Python 3.11 的基础镜像
+COPY app.py /app/         ← 把你的代码复制进去
+COPY requirements.txt /app/
+RUN pip install -r /app/requirements.txt  ← 安装依赖
+EXPOSE 8080               ← 声明应用使用 8080 端口
+CMD ["python", "/app/app.py"]  ← 容器启动时运行的命令
+```
+
+**效果**：无论在谁的电脑上、在哪台服务器上，用这个 Dockerfile 构建出来的镜像，运行起来的环境都是一模一样的。
+
+### Docker 的工作流程
+
+```
+开发者电脑：
+  写代码 → 写 Dockerfile → 构建镜像 → 本地测试通过
+      ↓
+  推送镜像到仓库（Docker Hub / AWS ECR）
+      ↓
+服务器：
+  从仓库拉取镜像 → 启动容器 → 应用运行
+```
+
+---
+
+## 为什么容器这么受欢迎
+
+### 1. 环境一致性
+
+"在我电脑上能跑"的问题彻底解决。开发、测试、生产用的是同一个镜像。
+
+### 2. 快速部署
+
+传统部署：安装操作系统 → 安装运行时 → 安装依赖 → 部署代码 → 配置环境（可能要几小时）
+
+容器部署：拉取镜像 → 启动容器（几秒钟）
+
+### 3. 资源效率
+
+一台服务器上可以运行几十个容器，比虚拟机密度高得多。
+
+### 4. 微服务友好
+
+一个大应用可以拆分成多个小服务，每个服务一个容器，独立开发、独立部署、独立扩展。
+
+### 5. 易于扩展
+
+需要更多处理能力？多启动几个相同的容器就行。
+
+---
+
+## 容器在 AWS 上怎么跑
+
+AWS 提供了多种运行容器的方式：
+
+| 服务 | 定位 | 类比 |
+|------|------|------|
+| ECR | 镜像仓库 | 存放镜像的"仓库" |
+| ECS | 容器编排 | 管理容器的"调度员" |
+| EKS | Kubernetes 托管 | 用 Kubernetes 管理容器 |
+| Fargate | 无服务器容器 | 不用管服务器，直接跑容器 |
+
+### AWS ECR（Elastic Container Registry）
+
+ECR 是 AWS 的私有镜像仓库。就像 Docker Hub，但是：
+- 私有的（只有你的团队能访问）
+- 和 AWS 其他服务无缝集成
+- 自动扫描镜像中的安全漏洞
+
+---
+
+## 容器 vs 无服务器（Lambda）
+
+| 特性 | 容器（ECS/EKS） | Lambda |
+|------|-----------------|--------|
+| 运行时间 | 无限制 | 最长 15 分钟 |
+| 启动时间 | 几秒 | 毫秒~秒 |
+| 自定义程度 | 完全自定义环境 | 受限的运行时 |
+| 适合 | 长时间运行的服务、复杂应用 | 事件驱动、短时任务 |
+| 管理复杂度 | 中等 | 低 |
+| 成本模型 | 按容器运行时间 | 按调用次数和执行时间 |
+
+**选择建议**：
+- 简单的事件处理、API 后端 → Lambda
+- 复杂的长时间运行的应用、需要特定环境 → 容器
+
+---
+
+## 今天的小测验
+
+1. 容器和虚拟机的核心区别是什么？容器为什么更轻量？
+2. Docker 镜像和容器的关系是什么？用一个类比解释。
+3. Dockerfile 的作用是什么？
+4. 什么场景适合用容器，什么场景适合用 Lambda？
+
+---
+
+## 延伸阅读
+
+- [Docker 官方入门教程](https://docs.docker.com/get-started/)
+- [AWS 容器服务概览](https://aws.amazon.com/containers/)
+- [AWS ECR 用户指南](https://docs.aws.amazon.com/AmazonECR/latest/userguide/)
+
+---
+
+## 明天预告
+
+明天学习 AWS ECS（Elastic Container Service）——AWS 的容器编排服务。了解如何在 AWS 上运行和管理你的容器化应用。

课程/第四阶段-应用架构/第27天-ECS容器服务.md

@@ -0,0 +1,205 @@
+# 第27天：ECS——在 AWS 上运行容器
+
+## 今天你将学到什么
+
+昨天学了容器的基础概念，今天学习如何在 AWS 上运行容器。ECS（Elastic Container Service）是 AWS 自己的容器编排服务，帮你管理容器的部署、扩展和运维。
+
+---
+
+## 为什么需要容器编排
+
+### 一个容器很简单，一百个容器就复杂了
+
+在自己电脑上跑一个容器很简单。但在生产环境中：
+
+- 你可能有 50 个不同的服务，每个服务跑多个容器副本
+- 某个容器挂了，需要自动重启
+- 流量增加了，需要自动增加容器数量
+- 新版本发布了，需要滚动更新（不停机）
+- 容器之间需要互相通信
+- 需要把容器合理地分配到不同的服务器上
+
+**这就是容器编排要解决的问题。**
+
+**类比**：如果容器是一个个工人，容器编排就是工厂的管理系统——安排谁在哪个岗位工作、有人请假了自动找人顶替、订单多了自动加人。
+
+---
+
+## ECS 的核心概念
+
+### 四个关键概念
+
+| 概念 | 类比 | 说明 |
+|------|------|------|
+| 集群（Cluster） | 工厂 | 容器运行的环境，一组计算资源 |
+| 任务定义（Task Definition） | 岗位说明书 | 描述容器怎么运行（用什么镜像、多少 CPU/内存、端口等） |
+| 任务（Task） | 正在工作的工人 | 任务定义的运行实例，一个或多个容器 |
+| 服务（Service） | 部门 | 确保指定数量的任务持续运行，自动替换失败的任务 |
+
+### 它们之间的关系
+
+```
+集群（Cluster）
+  └── 服务（Service）："保持 3 个任务一直运行"
+        ├── 任务 1（运行中）
+        ├── 任务 2（运行中）
+        └── 任务 3（运行中）← 如果挂了，服务会自动启动新的
+```
+
+---
+
+## 两种运行模式
+
+### 模式一：EC2 启动类型
+
+你自己管理运行容器的 EC2 实例。
+
+```
+你的 ECS 集群
+  ├── EC2 实例 A（运行容器 1、容器 2）
+  ├── EC2 实例 B（运行容器 3、容器 4）
+  └── EC2 实例 C（运行容器 5）
+```
+
+**优点**：
+- 可以选择特定的实例类型（比如 GPU 实例）
+- 可以使用 Spot 实例省钱
+- 对底层有完全控制
+
+**缺点**：
+- 需要管理 EC2 实例（打补丁、监控、扩缩容）
+- 需要规划容量（实例太少容器放不下，太多浪费钱）
+
+### 模式二：Fargate 启动类型（推荐新手）
+
+AWS 帮你管理底层服务器，你只需要关心容器本身。
+
+```
+你的 ECS 集群
+  ├── 任务 1（Fargate 自动分配资源）
+  ├── 任务 2（Fargate 自动分配资源）
+  └── 任务 3（Fargate 自动分配资源）
+```
+
+**优点**：
+- 不需要管理任何服务器
+- 按容器实际使用的 CPU 和内存付费
+- 自动扩展，不需要规划容量
+
+**缺点**：
+- 单价比 EC2 稍贵
+- 不支持 GPU
+- 对底层没有控制权
+
+**类比**：
+- EC2 模式 = 自己买车。要自己加油、保养、找停车位，但完全自由。
+- Fargate 模式 = 打车。不用管车的事，告诉司机去哪就行，但每公里贵一点。
+
+---
+
+## 任务定义详解
+
+任务定义是一个 JSON 文件，描述容器怎么运行。关键配置项：
+
+| 配置项 | 说明 | 举例 |
+|--------|------|------|
+| 镜像 | 用哪个容器镜像 | 123456.dkr.ecr.region.amazonaws.com/my-app:v1.2 |
+| CPU | 分配多少 CPU | 256（0.25 vCPU）、512、1024、2048、4096 |
+| 内存 | 分配多少内存 | 512MB、1024MB、2048MB |
+| 端口映射 | 容器暴露哪个端口 | 容器端口 8080 → 主机端口 80 |
+| 环境变量 | 传给容器的配置 | DB_HOST=mydb.xxx.rds.amazonaws.com |
+| 日志配置 | 日志发送到哪里 | CloudWatch Logs |
+| IAM 角色 | 容器有什么 AWS 权限 | 可以读取 S3、写入 DynamoDB |
+
+---
+
+## ECS 服务与负载均衡
+
+### 服务的作用
+
+ECS 服务确保你指定数量的任务始终在运行：
+
+- 你说"保持 3 个任务运行"
+- 某个任务挂了 → 服务自动启动新的，保持 3 个
+- 你想扩展到 5 个 → 修改服务配置，自动启动 2 个新任务
+- 发布新版本 → 服务滚动更新，逐个替换旧任务
+
+### 配合 ALB 使用
+
+```
+用户请求 → ALB → ECS 服务（多个任务）
+                    ├── 任务 1（容器 A）
+                    ├── 任务 2（容器 A）
+                    └── 任务 3（容器 A）
+```
+
+ALB 自动发现 ECS 服务中的任务，把流量均匀分配。任务增减时 ALB 自动更新。
+
+---
+
+## ECS 自动扩展
+
+ECS 支持根据负载自动调整任务数量：
+
+| 扩展策略 | 触发条件 | 适合场景 |
+|----------|----------|----------|
+| 目标追踪 | CPU 使用率保持在 70% | 通用场景 |
+| 步进扩展 | CPU > 80% 加 2 个任务 | 需要精细控制 |
+| 定时扩展 | 每天 9:00 扩展到 10 个任务 | 可预测的流量模式 |
+
+---
+
+## 实际部署流程
+
+一个典型的 ECS 部署流程：
+
+```
+1. 开发者推送代码到 Git
+2. CI/CD 构建新的 Docker 镜像
+3. 镜像推送到 ECR
+4. 更新 ECS 任务定义（指向新镜像）
+5. ECS 服务执行滚动更新：
+   - 启动新版本的任务
+   - 等新任务健康检查通过
+   - 停止旧版本的任务
+   - 重复直到所有任务都是新版本
+6. 用户无感知，零停机
+```
+
+---
+
+## ECS vs EKS 怎么选
+
+| | ECS | EKS |
+|--|-----|-----|
+| 管理方 | AWS 自研 | Kubernetes（开源标准） |
+| 学习曲线 | 低 | 高 |
+| 灵活性 | 够用 | 非常灵活 |
+| 生态系统 | AWS 生态 | Kubernetes 庞大生态 |
+| 可移植性 | 锁定 AWS | 可迁移到其他云 |
+| 适合 | 中小团队、AWS 深度用户 | 大团队、多云策略、已有 K8s 经验 |
+
+**建议**：如果你没有 Kubernetes 经验，从 ECS + Fargate 开始。简单够用。
+
+---
+
+## 今天的小测验
+
+1. ECS 中"集群"、"任务定义"、"任务"、"服务"分别是什么？
+2. Fargate 和 EC2 启动类型的区别是什么？什么时候选哪个？
+3. ECS 服务如何实现零停机部署？
+4. 什么情况下应该选 ECS，什么情况下选 EKS？
+
+---
+
+## 延伸阅读
+
+- [ECS 开发者指南](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/)
+- [Fargate 用户指南](https://docs.aws.amazon.com/AmazonECS/latest/userguide/what-is-fargate.html)
+- [ECS 最佳实践](https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/)
+
+---
+
+## 明天预告
+
+明天学习 CI/CD——持续集成与持续部署。了解如何自动化你的代码从提交到上线的整个流程，让部署变得安全、快速、可重复。

课程/第四阶段-应用架构/第28天-CICD持续集成部署.md

@@ -0,0 +1,261 @@
+# 第28天：CI/CD——代码从提交到上线的自动化流水线
+
+## 今天你将学到什么
+
+今天学习 CI/CD（持续集成/持续部署）——让代码从开发者提交到最终上线的整个过程自动化。不再需要手动打包、手动上传、手动重启服务器。
+
+---
+
+## 为什么需要 CI/CD
+
+### 没有 CI/CD 的世界
+
+传统的部署流程：
+
+1. 开发者写完代码，在本地测试通过
+2. 把代码打包成压缩文件，通过 FTP 上传到服务器
+3. SSH 登录服务器，停止旧服务
+4. 解压新代码，安装依赖
+5. 启动新服务，祈祷不出问题
+6. 出问题了？手动回滚到上一个版本
+
+**问题**：
+- 容易出错（手动操作步骤多）
+- 速度慢（一次部署可能要半小时）
+- 不敢频繁部署（怕出问题）
+- 回滚困难（上一个版本在哪？）
+- 不同人部署方式不一样（"你是怎么部署的？"）
+
+### 有 CI/CD 的世界
+
+```
+开发者提交代码 → 自动测试 → 自动构建 → 自动部署 → 上线完成
+```
+
+整个过程自动化、可重复、可追溯。出问题一键回滚。
+
+**类比**：CI/CD 就像工厂的自动化生产线。原材料（代码）放上去，经过一道道自动化工序（测试、构建、部署），最终产出成品（上线的应用）。不需要工人在每个环节手动操作。
+
+---
+
+## CI 和 CD 分别是什么
+
+### CI（Continuous Integration）持续集成
+
+**核心思想**：开发者频繁地把代码合并到主分支，每次合并都自动运行测试。
+
+```
+开发者提交代码
+    ↓
+自动拉取代码
+    ↓
+自动运行测试（单元测试、集成测试）
+    ↓
+测试通过？
+  ├── 是 → 代码合并成功 ✓
+  └── 否 → 通知开发者修复 ✗
+```
+
+**好处**：
+- 问题早发现（提交后几分钟就知道有没有 bug）
+- 避免"集成地狱"（多人同时开发，最后合并时冲突一堆）
+
+### CD（Continuous Delivery / Deployment）持续交付/部署
+
+**持续交付**：代码随时可以部署到生产环境（但需要人工点击"部署"按钮）。
+
+**持续部署**：代码通过所有测试后自动部署到生产环境（全自动，无需人工干预）。
+
+```
+CI 通过
+  ↓
+自动构建（打包、生成镜像）
+  ↓
+自动部署到测试环境
+  ↓
+自动运行集成测试
+  ↓
+部署到生产环境（自动或手动审批）
+```
+
+---
+
+## AWS 的 CI/CD 服务
+
+AWS 提供了一套完整的 CI/CD 工具链：
+
+| 服务 | 作用 | 类比 |
+|------|------|------|
+| CodeCommit | 代码仓库 | 类似 GitHub（存放代码） |
+| CodeBuild | 构建服务 | 编译代码、运行测试、生成产物 |
+| CodeDeploy | 部署服务 | 把构建产物部署到服务器 |
+| CodePipeline | 流水线编排 | 把上面的步骤串联成自动化流程 |
+
+### CodePipeline——流水线的指挥官
+
+CodePipeline 把各个阶段串联起来：
+
+```
+源代码阶段          构建阶段           部署阶段
+(CodeCommit/       (CodeBuild)       (CodeDeploy/
+ GitHub)                              ECS/Lambda)
+    ↓                  ↓                  ↓
+代码变更触发 → 编译+测试+打包 → 部署到目标环境
+```
+
+你只需要定义流水线的各个阶段，CodePipeline 自动按顺序执行。
+
+### CodeBuild——构建工人
+
+CodeBuild 负责：
+- 拉取源代码
+- 安装依赖
+- 编译代码
+- 运行测试
+- 生成构建产物（JAR 包、Docker 镜像等）
+
+**特点**：按构建时间付费，不用维护构建服务器。
+
+### CodeDeploy——部署专家
+
+CodeDeploy 支持多种部署策略：
+
+| 策略 | 说明 | 风险 |
+|------|------|------|
+| 一次性部署 | 所有实例同时更新 | 高（全部失败就全挂） |
+| 滚动部署 | 分批更新，每批一部分实例 | 中（部分失败可以停止） |
+| 蓝绿部署 | 启动一套新环境，切换流量 | 低（随时可以切回旧环境） |
+| 金丝雀部署 | 先给 5% 用户用新版本，没问题再全量 | 最低 |
+
+---
+
+## 一个完整的 CI/CD 流程示例
+
+### 场景：Web 应用部署到 ECS
+
+```
+1. 开发者推送代码到 GitHub
+       ↓
+2. CodePipeline 检测到代码变更，触发流水线
+       ↓
+3. CodeBuild 阶段：
+   - 拉取代码
+   - 运行单元测试
+   - 构建 Docker 镜像
+   - 推送镜像到 ECR
+       ↓
+4. 部署到测试环境：
+   - 更新测试环境的 ECS 服务
+   - 运行集成测试
+   - 测试通过 ✓
+       ↓
+5. 人工审批（可选）：
+   - 团队负责人确认可以上线
+       ↓
+6. 部署到生产环境：
+   - ECS 滚动更新
+   - 新版本容器启动
+   - 健康检查通过
+   - 旧版本容器停止
+       ↓
+7. 部署完成，通知团队
+```
+
+整个过程从代码提交到上线，可能只需要 10-15 分钟。
+
+---
+
+## 部署策略详解
+
+### 蓝绿部署
+
+```
+当前状态：
+  用户 → ALB → 蓝色环境（v1.0，正在服务）
+              绿色环境（空闲）
+
+部署新版本：
+  用户 → ALB → 蓝色环境（v1.0，正在服务）
+              绿色环境（v2.0，部署中...）
+
+切换流量：
+  用户 → ALB → 绿色环境（v2.0，开始服务）
+              蓝色环境（v1.0，待命，随时可以切回）
+
+确认无误后：
+  销毁蓝色环境，释放资源
+```
+
+**优点**：切换瞬间完成，回滚也是瞬间（切回旧环境）。
+**缺点**：需要双倍资源（两套环境同时存在）。
+
+### 金丝雀部署
+
+```
+阶段 1：5% 流量到新版本
+  用户 → ALB → 95% → v1.0
+              → 5%  → v2.0  ← 观察有没有错误
+
+阶段 2：没问题，扩大到 25%
+  用户 → ALB → 75% → v1.0
+              → 25% → v2.0  ← 继续观察
+
+阶段 3：全量切换
+  用户 → ALB → 100% → v2.0 ✓
+```
+
+**优点**：风险最小，问题只影响少量用户。
+**缺点**：部署时间较长。
+
+---
+
+## 基础设施即代码（IaC）
+
+### 问题：手动创建资源不可重复
+
+你在控制台上点点点创建了一套环境。下次要创建一套一模一样的测试环境，你还记得每个配置项吗？
+
+### 解决方案：用代码定义基础设施
+
+**CloudFormation**：AWS 的 IaC 服务。用 YAML/JSON 文件描述你要创建的所有 AWS 资源。
+
+```
+一个 CloudFormation 模板可以定义：
+- 1 个 VPC + 子网 + 路由表
+- 1 个 ALB
+- 1 个 Auto Scaling Group + 启动模板
+- 1 个 RDS 数据库
+- 所有的安全组和 IAM 角色
+```
+
+**好处**：
+- 可重复：同一个模板可以创建多套一模一样的环境
+- 可版本控制：模板放在 Git 里，变更有记录
+- 可审查：基础设施变更和代码变更一样走 Code Review
+- 可销毁：一键删除整套环境，不留残余资源
+
+**类比**：CloudFormation 模板就像建筑图纸。有了图纸，可以在任何地方建出一模一样的房子。
+
+---
+
+## 今天的小测验
+
+1. CI 和 CD 分别解决什么问题？
+2. 蓝绿部署和金丝雀部署各自的优缺点是什么？
+3. 为什么说"基础设施即代码"很重要？它解决了什么问题？
+4. CodePipeline、CodeBuild、CodeDeploy 各自的职责是什么？
+
+---
+
+## 延伸阅读
+
+- [CodePipeline 用户指南](https://docs.aws.amazon.com/codepipeline/latest/userguide/)
+- [CodeBuild 用户指南](https://docs.aws.amazon.com/codebuild/latest/userguide/)
+- [CodeDeploy 用户指南](https://docs.aws.amazon.com/codedeploy/latest/userguide/)
+- [CloudFormation 用户指南](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/)
+
+---
+
+## 明天预告
+
+明天学习 Step Functions——AWS 的工作流编排服务。了解如何把多个 Lambda 函数和服务组合成复杂的业务流程，并处理错误和重试。

课程/第四阶段-应用架构/第29天-StepFunctions工作流.md

@@ -0,0 +1,235 @@
+# 第29天：Step Functions——编排复杂的业务流程
+
+## 今天你将学到什么
+
+今天学习 Step Functions——AWS 的工作流编排服务。当你的业务逻辑涉及多个步骤、需要处理分支和错误时，Step Functions 帮你把这些步骤组织成一个可视化的流程图。
+
+---
+
+## 为什么需要工作流编排
+
+### 场景：电商订单处理
+
+用户下单后，需要执行一系列步骤：
+
+```
+1. 验证库存是否充足
+2. 扣减库存
+3. 创建支付订单
+4. 等待用户支付（可能要等几分钟到几小时）
+5. 支付成功 → 通知仓库发货
+   支付失败 → 恢复库存
+6. 发货后更新订单状态
+7. 发送物流通知给用户
+```
+
+### 用 Lambda 硬编码的问题
+
+如果把这些逻辑全写在一个 Lambda 里：
+- 代码又长又复杂，难以维护
+- Lambda 最长只能运行 15 分钟（等待支付可能超时）
+- 某一步失败了，重试逻辑很难写
+- 看不到流程执行到哪一步了
+
+### Step Functions 的解决方案
+
+把每一步拆成独立的 Lambda 函数，用 Step Functions 编排它们：
+
+```
+开始 → 验证库存 → 扣减库存 → 创建支付 → 等待支付
+                                            ↓
+                              ┌─── 支付成功 ───┐
+                              ↓               ↓
+                          恢复库存         通知发货
+                              ↓               ↓
+                          订单取消         发送通知
+                              ↓               ↓
+                            结束             结束
+```
+
+每一步清晰可见，错误处理和重试由 Step Functions 自动管理。
+
+---
+
+## Step Functions 的核心概念
+
+### 状态机（State Machine）
+
+Step Functions 的工作流叫"状态机"。它定义了一系列"状态"（步骤）以及状态之间的转换关系。
+
+**类比**：状态机就像一个流程图。每个方框是一个步骤，箭头表示下一步去哪里。
+
+### 状态类型
+
+| 状态类型 | 作用 | 举例 |
+|----------|------|------|
+| Task | 执行一个任务 | 调用 Lambda、发送 SQS 消息 |
+| Choice | 条件分支 | 如果库存 > 0 走 A 路径，否则走 B 路径 |
+| Wait | 等待一段时间 | 等待 30 秒后继续 |
+| Parallel | 并行执行多个分支 | 同时发邮件和发短信 |
+| Map | 对列表中每个元素执行操作 | 对订单中的每件商品检查库存 |
+| Pass | 传递数据（不做操作） | 转换数据格式 |
+| Succeed | 标记成功结束 | 流程正常完成 |
+| Fail | 标记失败结束 | 流程异常终止 |
+
+---
+
+## 实际应用场景
+
+### 场景一：用户注册流程
+
+```
+开始
+  ↓
+验证邮箱格式（Task）
+  ↓
+检查邮箱是否已注册（Task）
+  ↓
+邮箱已注册？（Choice）
+  ├── 是 → 返回错误"邮箱已存在"（Fail）
+  └── 否 ↓
+创建用户账号（Task）
+  ↓
+并行执行（Parallel）：
+  ├── 发送欢迎邮件（Task）
+  ├── 赠送新人优惠券（Task）
+  └── 初始化用户偏好设置（Task）
+  ↓
+注册完成（Succeed）
+```
+
+### 场景二：视频处理流水线
+
+用户上传一个视频后：
+
+```
+开始
+  ↓
+获取视频元信息（Task）
+  ↓
+并行处理（Parallel）：
+  ├── 转码为 1080p（Task）
+  ├── 转码为 720p（Task）
+  ├── 转码为 480p（Task）
+  └── 生成缩略图（Task）
+  ↓
+所有转码完成
+  ↓
+更新数据库（Task）
+  ↓
+通知用户"视频处理完成"（Task）
+  ↓
+结束
+```
+
+### 场景三：审批流程
+
+```
+员工提交报销申请
+  ↓
+金额 > 5000？（Choice）
+  ├── 是 → 需要总监审批（Task + Wait）
+  │         ↓
+  │       审批结果？（Choice）
+  │         ├── 通过 → 财务打款
+  │         └── 拒绝 → 通知员工
+  └── 否 → 经理审批（Task + Wait）
+            ↓
+          审批结果？（Choice）
+            ├── 通过 → 财务打款
+            └── 拒绝 → 通知员工
+```
+
+---
+
+## Step Functions 的优势
+
+### 1. 可视化
+
+在 AWS 控制台可以看到流程图，实时显示每一步的执行状态（绿色=成功，红色=失败，蓝色=执行中）。
+
+### 2. 内置错误处理
+
+不需要自己写 try-catch。Step Functions 支持：
+- **重试（Retry）**：某一步失败了，自动重试 3 次，每次间隔递增
+- **捕获（Catch）**：重试都失败了，走备用路径（比如通知人工处理）
+
+### 3. 长时间运行
+
+Step Functions 的工作流可以运行长达一年。适合需要等待人工审批、等待外部事件的场景。
+
+### 4. 审计追踪
+
+每次执行的每一步都有详细记录：输入、输出、耗时、错误信息。方便排查问题。
+
+---
+
+## Step Functions vs 直接用代码编排
+
+| | Step Functions | 代码编排 |
+|--|---------------|----------|
+| 可视化 | 有流程图 | 看代码 |
+| 错误处理 | 声明式配置 | 手写 try-catch |
+| 长时间等待 | 原生支持 | 需要额外机制 |
+| 并行执行 | 声明式 | 手动管理线程/Promise |
+| 执行历史 | 自动记录 | 需要自己记日志 |
+| 适合 | 多步骤、有分支、需要等待 | 简单线性流程 |
+
+**建议**：如果你的流程超过 3 步、有条件分支、或需要等待外部事件，考虑用 Step Functions。
+
+---
+
+## EventBridge——事件驱动架构
+
+和 Step Functions 经常配合使用的还有 EventBridge（事件总线）。
+
+### 什么是事件驱动
+
+传统方式：服务 A 完成工作后，主动调用服务 B、服务 C、服务 D。
+
+事件驱动：服务 A 完成工作后，发布一个"事件"。对这个事件感兴趣的服务自己来响应。
+
+```
+传统方式：
+  订单服务 → 调用库存服务
+           → 调用通知服务
+           → 调用积分服务
+  （订单服务需要知道所有下游服务）
+
+事件驱动：
+  订单服务 → 发布"订单创建"事件到 EventBridge
+  EventBridge → 库存服务（自动触发）
+             → 通知服务（自动触发）
+             → 积分服务（自动触发）
+  （订单服务不需要知道谁在监听）
+```
+
+### EventBridge 的能力
+
+- 接收来自 AWS 服务的事件（EC2 状态变化、S3 文件上传等）
+- 接收来自你自己应用的自定义事件
+- 根据规则把事件路由到不同的目标（Lambda、SQS、Step Functions 等）
+- 支持定时触发（类似 cron）
+
+---
+
+## 今天的小测验
+
+1. Step Functions 解决了什么问题？什么场景适合用它？
+2. Step Functions 中的 Choice 状态和 Parallel 状态分别做什么？
+3. Step Functions 的错误处理机制（Retry 和 Catch）有什么好处？
+4. 事件驱动架构和传统的直接调用有什么区别？
+
+---
+
+## 延伸阅读
+
+- [Step Functions 开发者指南](https://docs.aws.amazon.com/step-functions/latest/dg/)
+- [EventBridge 用户指南](https://docs.aws.amazon.com/eventbridge/latest/userguide/)
+- [Step Functions 工作流示例](https://docs.aws.amazon.com/step-functions/latest/dg/create-sample-projects.html)
+
+---
+
+## 明天预告
+
+明天学习 API Gateway——如何为你的后端服务创建统一的 API 入口，管理 API 的版本、认证、限流和监控。

课程/第四阶段-应用架构/第30天-APIGateway.md

@@ -0,0 +1,229 @@
+# 第30天：API Gateway——统一的 API 入口
+
+## 今天你将学到什么
+
+今天学习 API Gateway——AWS 的 API 管理服务。它是你后端服务的"大门"，负责接收客户端请求、验证身份、限制流量、路由到正确的后端服务。
+
+---
+
+## 为什么需要 API Gateway
+
+### 没有 API Gateway 的问题
+
+假设你有一个微服务架构，有多个后端服务：
+
+```
+手机 APP 直接调用：
+  → 用户服务（端口 8001）
+  → 订单服务（端口 8002）
+  → 商品服务（端口 8003）
+  → 支付服务（端口 8004）
+```
+
+**问题**：
+- 客户端需要知道每个服务的地址（耦合）
+- 每个服务都要自己实现认证、限流、日志（重复）
+- 服务地址变了，所有客户端都要更新
+- 没有统一的监控和管理
+
+### 有 API Gateway 的世界
+
+```
+手机 APP → API Gateway（统一入口）
+              ├── /users/*  → 用户服务
+              ├── /orders/* → 订单服务
+              ├── /products/* → 商品服务
+              └── /payments/* → 支付服务
+```
+
+**类比**：API Gateway 就像酒店的前台。客人（客户端）不需要知道每个部门（后端服务）在哪里，只需要告诉前台需要什么，前台帮你转接到正确的部门。前台还负责验证你的身份（房卡）、记录你的请求。
+
+---
+
+## API Gateway 能做什么
+
+| 功能 | 说明 | 好处 |
+|------|------|------|
+| 请求路由 | 根据 URL 路径转发到不同后端 | 客户端只需要一个地址 |
+| 身份认证 | 验证 API 密钥、JWT Token、IAM 签名 | 后端不用重复实现认证 |
+| 请求限流 | 限制每秒请求数，防止滥用 | 保护后端不被压垮 |
+| 请求转换 | 修改请求/响应的格式 | 适配不同客户端需求 |
+| 缓存 | 缓存 API 响应 | 减少后端压力，加速响应 |
+| CORS | 处理跨域请求 | 前端可以直接调用 API |
+| API 版本管理 | 支持 v1、v2 等多个版本共存 | 平滑升级，不影响老用户 |
+| 监控 | 请求量、延迟、错误率 | 了解 API 使用情况 |
+
+---
+
+## AWS API Gateway 的三种类型
+
+| 类型 | 适合场景 | 特点 |
+|------|----------|------|
+| REST API | 功能最全的 RESTful API | 支持所有功能，价格稍高 |
+| HTTP API | 简单的 HTTP 代理 | 功能较少但便宜 70%，延迟更低 |
+| WebSocket API | 实时双向通信 | 聊天、实时通知、游戏 |
+
+**选择建议**：
+- 大多数场景用 HTTP API（便宜、快）
+- 需要请求转换、缓存、API 密钥计划等高级功能用 REST API
+- 需要实时推送用 WebSocket API
+
+---
+
+## API Gateway + Lambda：无服务器 API
+
+最经典的组合：API Gateway 接收请求，Lambda 处理逻辑。
+
+```
+客户端 → API Gateway → Lambda 函数 → DynamoDB
+                                    → S3
+                                    → 其他服务
+```
+
+**优势**：
+- 完全无服务器，不需要管理任何机器
+- 按请求付费，没有请求就不花钱
+- 自动扩展，能应对突发流量
+
+**适合**：
+- 中小型 API
+- 流量不稳定的应用
+- 快速原型开发
+
+---
+
+## 认证与授权
+
+API Gateway 支持多种认证方式：
+
+### 方式一：API 密钥
+
+最简单的方式。给每个客户端分配一个 API Key。
+
+```
+客户端请求头：x-api-key: abc123xyz
+```
+
+适合：内部服务间调用、简单的第三方集成。
+
+### 方式二：Cognito 用户池
+
+AWS 的用户管理服务。用户登录后获得 JWT Token，API Gateway 自动验证。
+
+```
+用户登录 → Cognito 返回 Token → 客户端带着 Token 请求 API → API Gateway 验证 Token
+```
+
+适合：面向终端用户的应用（APP、网站）。
+
+### 方式三：Lambda 授权器
+
+自定义认证逻辑。API Gateway 收到请求后，先调用一个 Lambda 函数验证身份。
+
+```
+客户端请求 → API Gateway → Lambda 授权器（验证 Token）
+                              ├── 验证通过 → 转发到后端
+                              └── 验证失败 → 返回 401
+```
+
+适合：需要自定义认证逻辑（比如验证自己系统的 Token）。
+
+---
+
+## 限流与配额
+
+### 为什么要限流
+
+- 防止恶意用户刷接口
+- 防止 bug 导致的无限循环调用
+- 保护后端服务不被压垮
+- 公平分配资源给所有用户
+
+### API Gateway 的限流机制
+
+| 级别 | 说明 | 举例 |
+|------|------|------|
+| 账户级别 | 整个账户的默认限制 | 10,000 请求/秒 |
+| API 级别 | 单个 API 的限制 | 5,000 请求/秒 |
+| 方法级别 | 单个接口的限制 | /login 限制 100 请求/秒 |
+| 客户端级别 | 单个 API Key 的限制 | 每个客户端 1,000 请求/秒 |
+
+### 使用计划（Usage Plan）
+
+可以为不同的客户端设置不同的配额：
+
+```
+免费用户：每天 1,000 次调用，每秒最多 10 次
+付费用户：每天 100,000 次调用，每秒最多 100 次
+企业用户：无限调用，每秒最多 1,000 次
+```
+
+---
+
+## API 版本管理
+
+### 为什么需要版本
+
+你的 API 已经有很多客户端在用了。现在要改接口格式，但不能让老客户端突然不能用。
+
+### 实现方式
+
+**方式一：URL 路径版本**
+```
+https://api.example.com/v1/users  ← 老版本
+https://api.example.com/v2/users  ← 新版本
+```
+
+**方式二：阶段（Stage）**
+
+API Gateway 支持多个"阶段"，每个阶段是一个独立的部署：
+```
+https://api.example.com/dev/users   ← 开发环境
+https://api.example.com/test/users  ← 测试环境
+https://api.example.com/prod/users  ← 生产环境
+```
+
+---
+
+## 实际架构示例
+
+### 一个完整的无服务器后端
+
+```
+移动 APP / Web 前端
+        ↓
+  CloudFront（缓存静态资源）
+        ↓
+  API Gateway（API 入口）
+    ├── GET /products → Lambda → DynamoDB（查询商品）
+    ├── POST /orders → Lambda → DynamoDB + SQS（创建订单）
+    ├── GET /users/me → Lambda → RDS（查询用户信息）
+    └── POST /upload → Lambda → S3（上传文件）
+        ↓
+  Cognito（用户认证）
+```
+
+**成本**：如果每天 10 万次 API 调用，月费大约只有几美元。
+
+---
+
+## 今天的小测验
+
+1. API Gateway 解决了什么问题？没有它会怎样？
+2. REST API 和 HTTP API 的区别是什么？怎么选？
+3. API Gateway 支持哪些认证方式？各自适合什么场景？
+4. 为什么需要 API 限流？可以在哪些级别设置限流？
+
+---
+
+## 延伸阅读
+
+- [API Gateway 开发者指南](https://docs.aws.amazon.com/apigateway/latest/developerguide/)
+- [API Gateway REST API vs HTTP API](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-vs-rest.html)
+- [使用 Cognito 保护 API](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html)
+
+---
+
+## 明天预告
+
+明天学习微服务架构——如何把一个大应用拆分成多个小服务，以及 AWS 上实现微服务的最佳实践。

课程/第四阶段-应用架构/第31天-微服务架构.md

@@ -0,0 +1,238 @@
+# 第31天：微服务架构——把大象拆成蚂蚁
+
+## 今天你将学到什么
+
+今天学习微服务架构的核心思想和 AWS 上的实现方式。理解为什么大公司都在从"一个大应用"转向"多个小服务"，以及这样做的好处和挑战。
+
+---
+
+## 单体架构 vs 微服务架构
+
+### 单体架构（Monolith）
+
+所有功能都在一个应用里：
+
+```
+一个大应用：
+├── 用户管理
+├── 商品管理
+├── 订单处理
+├── 支付处理
+├── 库存管理
+├── 通知服务
+└── 数据分析
+```
+
+**类比**：一家什么都卖的大超市。所有商品在一栋楼里，一个收银系统，一个仓库。
+
+**优点**：
+- 开发简单（一个代码库，一个部署）
+- 本地调试方便
+- 数据一致性容易保证
+
+**缺点**：
+- 代码越来越大，新人要几周才能理解
+- 改一个小功能要重新部署整个应用
+- 一个模块的 bug 可能拖垮整个系统
+- 不同模块不能独立扩展（订单模块需要 10 台服务器，但用户模块只需要 2 台）
+- 技术栈被锁定（整个应用必须用同一种语言）
+
+### 微服务架构（Microservices）
+
+每个功能是一个独立的小服务：
+
+```
+用户服务（Python）──┐
+商品服务（Java）────┤
+订单服务（Go）──────┼── 通过 API 互相通信
+支付服务（Node.js）─┤
+库存服务（Java）────┤
+通知服务（Python）──┘
+```
+
+**类比**：一条商业街上的多家专卖店。鞋店只卖鞋，面包店只卖面包。每家店独立经营，互不影响。鞋店装修不影响面包店营业。
+
+**优点**：
+- 每个服务小而专注，容易理解和维护
+- 独立部署（改了订单服务只需要重新部署订单服务）
+- 独立扩展（订单服务压力大就多加几个实例）
+- 技术自由（每个服务可以用最适合的语言和框架）
+- 故障隔离（支付服务挂了，用户还能浏览商品）
+
+**缺点**：
+- 系统复杂度增加（服务间通信、数据一致性）
+- 运维难度增加（几十个服务要监控）
+- 调试困难（一个请求可能经过 5 个服务）
+- 网络延迟（服务间调用比函数调用慢）
+
+---
+
+## 什么时候该用微服务
+
+### 不要一开始就用微服务
+
+**马丁·福勒（微服务概念的推广者）说过**："几乎所有成功的微服务架构，都是从一个变得太大的单体应用演化而来的。"
+
+### 判断标准
+
+| 情况 | 建议 |
+|------|------|
+| 团队 < 5 人 | 单体架构 |
+| 应用刚起步 | 单体架构 |
+| 团队 > 20 人 | 考虑微服务 |
+| 不同模块需要不同扩展策略 | 考虑微服务 |
+| 部署频率需要很高 | 考虑微服务 |
+| 单体已经大到难以维护 | 考虑微服务 |
+
+---
+
+## 微服务在 AWS 上的实现
+
+### 服务运行方式
+
+| 方式 | 适合 | AWS 服务 |
+|------|------|----------|
+| 容器 | 长时间运行的服务 | ECS / EKS + Fargate |
+| 无服务器 | 事件驱动、轻量服务 | Lambda + API Gateway |
+| 虚拟机 | 遗留应用、特殊需求 | EC2 + Auto Scaling |
+
+### 服务间通信
+
+| 方式 | 适合 | AWS 服务 |
+|------|------|----------|
+| 同步调用（HTTP/gRPC） | 需要立即得到结果 | ALB / API Gateway / App Mesh |
+| 异步消息 | 不需要立即结果 | SQS / SNS / EventBridge |
+| 事件流 | 实时数据流处理 | Kinesis / MSK（Kafka） |
+
+### 服务发现
+
+微服务之间怎么找到对方？
+
+**传统方式**：把每个服务的地址写在配置文件里。服务地址变了就要改配置。
+
+**服务发现**：服务启动时自动注册自己的地址，其他服务通过名字查找。
+
+```
+订单服务想调用用户服务：
+  → 问服务发现："用户服务在哪？"
+  → 服务发现回答："10.0.1.25:8080 和 10.0.1.26:8080"
+  → 订单服务选一个调用
+```
+
+AWS 提供 **Cloud Map** 服务做服务发现。ECS 服务可以自动注册到 Cloud Map。
+
+---
+
+## 微服务的数据管理
+
+### 每个服务拥有自己的数据库
+
+这是微服务的核心原则之一：
+
+```
+❌ 错误：所有服务共享一个数据库
+  用户服务 ─┐
+  订单服务 ─┼── 同一个 MySQL 数据库
+  商品服务 ─┘
+  （一个服务改了表结构，其他服务可能崩溃）
+
+✓ 正确：每个服务有自己的数据库
+  用户服务 → 用户数据库（RDS）
+  订单服务 → 订单数据库（DynamoDB）
+  商品服务 → 商品数据库（RDS）
+  （互不影响，可以选择最适合的数据库类型）
+```
+
+### 数据一致性挑战
+
+当一个操作涉及多个服务时，如何保证数据一致？
+
+**举例**：用户下单需要同时扣库存和创建订单。
+
+**解决方案：Saga 模式**
+
+```
+1. 订单服务：创建订单（状态=待确认）
+2. 库存服务：扣减库存
+   - 成功 → 订单服务：确认订单
+   - 失败 → 订单服务：取消订单（补偿操作）
+```
+
+每一步都有对应的"补偿操作"。如果某一步失败，执行前面所有步骤的补偿操作来回滚。
+
+Step Functions 非常适合实现 Saga 模式。
+
+---
+
+## 微服务的可观测性
+
+当一个请求经过 5 个服务时，出了问题怎么排查？
+
+### 分布式追踪（AWS X-Ray）
+
+X-Ray 可以追踪一个请求在多个服务间的完整路径：
+
+```
+用户请求 → API Gateway (5ms) → 订单服务 (20ms) → 库存服务 (15ms)
+                                                → 支付服务 (200ms) ← 瓶颈在这里！
+                              → 通知服务 (10ms)
+```
+
+一眼就能看出哪个服务慢了、哪里出了错。
+
+### 集中日志（CloudWatch Logs）
+
+所有服务的日志发送到 CloudWatch Logs，统一查看和搜索。
+
+### 统一监控（CloudWatch）
+
+所有服务的指标（CPU、内存、请求量、错误率）在一个仪表板上展示。
+
+---
+
+## 微服务架构示例：电商平台
+
+```
+客户端
+  ↓
+API Gateway（统一入口）
+  ├── /users → 用户服务（ECS Fargate）→ Aurora
+  ├── /products → 商品服务（ECS Fargate）→ DynamoDB
+  ├── /orders → 订单服务（ECS Fargate）→ Aurora
+  ├── /payments → 支付服务（Lambda）→ 外部支付网关
+  └── /notifications → 通知服务（Lambda）→ SES/SNS
+
+服务间通信：
+  订单服务 → SNS "订单创建" 事件
+    → SQS → 库存服务（扣库存）
+    → SQS → 通知服务（发通知）
+    → SQS → 分析服务（记录数据）
+
+服务发现：Cloud Map
+分布式追踪：X-Ray
+日志：CloudWatch Logs
+监控：CloudWatch Dashboard
+```
+
+---
+
+## 今天的小测验
+
+1. 单体架构和微服务架构各自的优缺点是什么？
+2. 什么时候应该从单体转向微服务？
+3. 微服务之间的同步通信和异步通信各自适合什么场景？
+4. 为什么每个微服务应该有自己的数据库？这带来了什么挑战？
+
+---
+
+## 延伸阅读
+
+- [AWS 微服务架构指南](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+- [AWS X-Ray 开发者指南](https://docs.aws.amazon.com/xray/latest/devguide/)
+- [AWS Cloud Map](https://docs.aws.amazon.com/cloud-map/latest/dg/)
+
+---
+
+## 明天预告
+
+明天是第四阶段的收尾：应用架构综合实战。我们会设计一个完整的微服务应用架构，把容器、CI/CD、API Gateway、Step Functions 等知识串联起来。

课程/第四阶段-应用架构/第32天-应用架构综合实战.md

@@ -0,0 +1,247 @@
+# 第32天：应用架构综合实战——设计一个 SaaS 平台
+
+## 今天你将学到什么
+
+今天是第四阶段的收尾。我们用一个完整的 SaaS（软件即服务）平台案例，把容器、CI/CD、API Gateway、Step Functions、微服务等知识串联起来。
+
+---
+
+## 项目背景：在线协作文档平台
+
+假设你要做一个类似"腾讯文档"的简化版平台：
+- 用户可以创建、编辑、分享文档
+- 支持多人实时协作编辑
+- 支持文档导出为 PDF
+- 有团队管理和权限控制
+- 需要支持百万级用户
+
+---
+
+## 整体架构
+
+```
+Web 前端 / 移动端
+        ↓
+CloudFront（静态资源 + API 加速）
+        ↓
+API Gateway（REST API 入口）
+        ↓
+┌─────────────────────────────────────────────────┐
+│  ECS Fargate 集群                                │
+│                                                   │
+│  ┌──────────┐  ┌──────────┐  ┌──────────┐      │
+│  │ 用户服务  │  │ 文档服务  │  │ 团队服务  │      │
+│  └──────────┘  └──────────┘  └──────────┘      │
+│  ┌──────────┐  ┌──────────┐                     │
+│  │ 权限服务  │  │ 搜索服务  │                     │
+│  └──────────┘  └──────────┘                     │
+└─────────────────────────────────────────────────┘
+        ↓
+┌─────────────────────────────────────────────────┐
+│  数据层                                           │
+│  Aurora（用户、团队、权限）                         │
+│  DynamoDB（文档内容、版本历史）                     │
+│  ElastiCache Redis（会话、协作状态）               │
+│  S3（文档附件、导出的 PDF）                        │
+│  OpenSearch（全文搜索）                           │
+└─────────────────────────────────────────────────┘
+
+异步处理：
+  EventBridge → Step Functions → Lambda
+  （文档导出、通知发送、数据分析）
+
+实时协作：
+  API Gateway WebSocket → Lambda → DynamoDB + Redis
+```
+
+---
+
+## 各服务职责
+
+### 用户服务
+- 注册、登录、个人信息管理
+- 集成 Cognito 做身份认证
+- 数据库：Aurora（用户表）
+
+### 文档服务
+- 创建、读取、更新、删除文档
+- 管理文档版本历史
+- 数据库：DynamoDB（文档内容，支持高频读写）
+
+### 团队服务
+- 创建团队、邀请成员、管理角色
+- 数据库：Aurora（团队和成员关系）
+
+### 权限服务
+- 判断用户对某个文档有没有权限
+- 缓存：Redis（权限判断需要极快响应）
+
+### 搜索服务
+- 全文搜索文档内容和标题
+- 引擎：OpenSearch（Elasticsearch 托管版）
+
+---
+
+## 关键流程设计
+
+### 流程一：用户编辑文档
+
+```
+1. 用户打开文档
+   → API Gateway → 权限服务（检查权限）→ 文档服务（获取内容）
+   
+2. 用户编辑
+   → WebSocket 连接 → Lambda → DynamoDB（保存变更）
+                             → Redis（广播给其他协作者）
+
+3. 自动保存
+   → 每 5 秒将变更批量写入 DynamoDB
+   → 保留版本历史（最近 100 个版本）
+```
+
+### 流程二：文档导出 PDF（Step Functions）
+
+```
+用户点击"导出 PDF"
+    ↓
+API Gateway → Lambda（创建导出任务）→ 返回任务 ID 给用户
+    ↓
+Step Functions 工作流启动：
+    ↓
+获取文档内容（Task）
+    ↓
+渲染为 PDF（Task，可能需要 30 秒）
+    ↓
+上传到 S3（Task）
+    ↓
+生成下载链接（Task）
+    ↓
+通知用户"PDF 已就绪"（Task → SNS → 推送通知）
+```
+
+为什么用 Step Functions？因为 PDF 渲染可能需要较长时间，不适合让用户同步等待。
+
+### 流程三：新用户注册
+
+```
+用户注册
+    ↓
+Cognito 创建用户
+    ↓
+EventBridge 发布"用户注册"事件
+    ↓
+├── Lambda：创建默认工作空间
+├── Lambda：发送欢迎邮件（SES）
+├── Lambda：创建示例文档
+└── Lambda：记录注册统计
+```
+
+---
+
+## CI/CD 流水线
+
+```
+开发者推送代码（GitHub）
+    ↓
+CodePipeline 触发
+    ↓
+CodeBuild：
+  - 运行单元测试
+  - 构建 Docker 镜像
+  - 推送到 ECR
+  - 运行安全扫描
+    ↓
+部署到 Staging 环境：
+  - 更新 ECS 服务
+  - 运行集成测试
+  - 运行 E2E 测试
+    ↓
+人工审批（团队负责人确认）
+    ↓
+部署到 Production：
+  - ECS 蓝绿部署
+  - 金丝雀发布（5% → 25% → 100%）
+  - 自动回滚（如果错误率上升）
+```
+
+每个微服务有自己独立的流水线，可以独立部署。
+
+---
+
+## 扩展性设计
+
+| 组件 | 扩展方式 | 触发条件 |
+|------|----------|----------|
+| ECS 服务 | 自动扩展任务数 | CPU > 70% 或请求队列增长 |
+| DynamoDB | 自动扩展读写容量 | 使用率 > 70% |
+| Aurora | 增加只读副本 | 读取延迟 > 100ms |
+| Redis | 增加分片 | 内存使用 > 80% |
+| Lambda | 自动（无需配置） | 并发请求增加 |
+
+---
+
+## 成本优化策略
+
+| 策略 | 节省 | 实现方式 |
+|------|------|----------|
+| Fargate Spot | 最多 70% | 非关键服务使用 Spot 容量 |
+| DynamoDB 按需模式 | 避免过度预置 | 流量不稳定的表用按需模式 |
+| S3 生命周期 | 存储费用 | 30 天前的版本转到低频存储 |
+| CloudFront 缓存 | 减少源站请求 | 静态资源缓存 24 小时 |
+| Reserved Capacity | 最多 60% | Aurora 和 Redis 用预留实例 |
+
+---
+
+## 监控与告警
+
+```
+CloudWatch Dashboard（统一视图）：
+├── 业务指标：活跃用户数、文档创建数、API 调用量
+├── 性能指标：API 延迟 P99、错误率、数据库连接数
+├── 资源指标：CPU、内存、磁盘使用率
+└── 成本指标：每日花费、各服务占比
+
+告警规则：
+├── API 错误率 > 1% → 通知开发团队（Slack）
+├── P99 延迟 > 2s → 通知运维团队
+├── 数据库连接数 > 80% → 自动扩展 + 通知
+└── 月度成本超预算 20% → 通知管理层
+```
+
+---
+
+## 架构决策总结
+
+| 决策 | 选择 | 原因 |
+|------|------|------|
+| 服务运行 | ECS Fargate | 不想管服务器，按需付费 |
+| API 入口 | API Gateway | 统一认证、限流、监控 |
+| 实时协作 | WebSocket + Redis | 低延迟双向通信 |
+| 文档存储 | DynamoDB | 高频读写、灵活 schema |
+| 用户数据 | Aurora | 关系型数据、复杂查询 |
+| 异步处理 | EventBridge + Step Functions | 解耦、可视化、错误处理 |
+| 搜索 | OpenSearch | 全文搜索、模糊匹配 |
+| 部署 | 蓝绿 + 金丝雀 | 零停机、低风险 |
+
+---
+
+## 今天的小测验
+
+1. 为什么文档内容用 DynamoDB 而不是 Aurora？
+2. 文档导出 PDF 为什么用 Step Functions 而不是同步处理？
+3. 这个架构中，哪些部分可以独立扩展？
+4. 如果某个微服务出了 bug，对其他服务有什么影响？
+
+---
+
+## 延伸阅读
+
+- [AWS SaaS 架构指南](https://docs.aws.amazon.com/whitepapers/latest/saas-architecture-fundamentals/saas-architecture-fundamentals.html)
+- [AWS 无服务器应用模型](https://docs.aws.amazon.com/serverless-application-model/)
+- [AWS 架构中心](https://aws.amazon.com/architecture/)
+
+---
+
+## 明天预告
+
+进入第五阶段：监控与运维。明天学习 CloudWatch——AWS 的监控核心。了解如何监控你的应用和基础设施，设置告警，在问题发生前就发现它。