我行我素123341. 选题定调：第一次大作业，为什么要咬咬牙上云
先说背景。我本科最后一年选了一门《云计算基础》的选修课，期末大作业要求是"使用云计算平台完成一个具备一定复杂度的应用，并提交架构设计文档"。当时身边同学的选择基本分两派：一派用虚拟机装几个服务糊弄过去，另一派老老实实做一个传统三层架构的Web应用，部署在学校机房的服务器上，通过公网IP访问就算完事。
我做了一个不同的决定：全程使用AWS（亚马逊云服务），从计算、存储、网络到数据库全部走云原生的路子。最后作业题目是"基于云平台的校园课程表查询与订阅系统"，拿了A，还被老师拿去给下一届当示例。这篇文章不是晒成绩，而是想把我从零到一的过程完完整整拆开，把那些文档里查不到、看了官方教程也容易踩的坑讲清楚。
先说一个真实感受：第一次接触云平台做项目，最难的其实不是写代码，而是建立一整套"云上思维"。你在课本上学到的IP、端口、数据库连接，到了云上全都要重新理解一遍，因为有安全组、VPC、IAM、托管服务这一层又一层的封装。但一旦把这些东西吃透，你会发现自己对"部署"这件事的理解，和以前完全不在一个维度上。
2. 做需求分析时就把"云资源"当变量设计
2.1 我的作业题目到底要做什么
题目是"校园课程表查询与订阅系统"，看起来很普通，但如果按照云原生的思路去设计需求，它会变成另外一个样子。
核心功能拆下来有三块：第一，用户可以查询指定院系、指定周次的课程表；第二，用户可以订阅某门课程的变动通知（比如调课、停课），系统通过邮件推送；第三，管理员可以后台更新课程信息。看起来就是个典型的CRUD项目，但如果往深了想，每一块都能对应到不同的云服务。
这里我提一个非常重要的建议：大作业的题目只是给你一个大致方向，具体做成什么样，完全取决于你自己。你可以做成一个简单的一台虚拟机搞定所有，也可以做成一个分布式、多服务协同的系统。老师不会要求你做到后者，但如果你想真正学到东西，就把这个普通题目当成一个真实上线的产品去设计。
我把需求进一步细化，得到了下面这张表，这张表也直接决定了我后续的选型：
| 功能模块 | 核心需求 | 对应的云原生方案 |
|---|---|---|
| 课程表查询 | 读多写少、响应要快 | Lambda + API Gateway + DynamoDB |
| 课程变动通知 | 异步任务、需要定时或触发 | SNS + Lambda 触发邮件 |
| 管理员后台 | 低频操作、有鉴权要求 | 单独的管理API + IAM权限控制 |
| 课程数据存储 | 结构灵活、字段可能变化 | DynamoDB（而非传统关系型数据库） |
| 前端页面 | 纯静态、低流量 | S3 静态网站托管 + CloudFront |
这个表我到现在回头看，最大的价值在于：它不是按照"技术栈"来组织的，而是按照"业务需求"来组织，每个业务诉求都映射到了一个云服务上。这就是云架构设计和传统软件设计最大的区别。
2.2 备课阶段必须先看的三份文档
如果你也是第一次接触云计算，我强烈建议不要一上来就打开控制台开始点鼠标，而是在动手前先把下面三类文档通读一遍：
第一是《AWS Well-Architected Framework》的白皮书，中文版和英文版都行，重点看运维卓越和安全性这两个支柱。第二是目标服务的FAQ页面，比如你要用DynamoDB就把DynamoDB的FAQ刷一遍，比看User Guide管用得多，因为FAQ里全是使用场景和限制。第三是整个项目的架构设计示例，AWS官方提供很多Reference Architecture图，找一个和你项目最接近的看图理解服务间的关系。
这里我想特别说一句：大作业的正确打开方式，不是"会用控制台"，而是"能画出架构图并且说出为什么"。老师看重的不是你把网站跑起来了，而是你能不能解释清楚"为什么用队列而不是直接用同步调用""为什么把静态资源放在对象存储而不是服务器本地"。这些决策过程，才是作业拿高分的关键。
3. 云平台选型和账号准备的一个月经验
3.1 为什么选了AWS而不是其他平台
这个问题几乎是所有人都要面对的第一道选择题。选型本身没有绝对的对错，但一定要看你自己的场景和目的。
先说结论：我最终选了AWS，核心原因有三条。第一，AWS的免费套餐（Free Tier）对学习非