我在2026年对 Cloud Resume Challenge 的尝试
Source: Dev.to
目录
- 关于项目
- 开始前的建议
- 我花了多少时间
- 反思
- 项目架构
- Lambda 函数
- DynamoDB
- API 网关
- API 限流
- Git 仓库
- 更多内容即将推出
- 开发观察
- Terraform (IaC)
- 安全性
- Git 仓库列表
- 接下来是什么
关于项目
Cloud Resume Challenge 是一个旨在帮助有志成为云/DevOps 工程师的人在云领域起步的项目。该挑战强调真实的实践经验，最终目标是构建你真正会使用的东西——而不是玩具项目。
该项目本身是一个带有页面浏览计数器的简历网站。
你可以在官方站点以及此处了解更多，创作者在其中更详细地解释了该挑战的动机和目标。
在开始之前的建议
如果你的时间有限，想在动手前先得到一些实用的建议，这里有我的两点小建议：
- 跳过 HTML/CSS 部分 —— 在把项目写进简历之前，页面的外观并不是关键。真正有价值的在于云架构和实现。
- 先使用 Web 控制台，如果你对 AWS（或你选择的云服务商）不太熟悉，先不要直接跳到基础设施即代码（IaC）。这样可以更快上手，尽早得到可运行的演示。等以后转向 IaC 时，你会更清楚哪些配置是由控制台隐式处理的。
- 对每个主题投入的时间要保守。本项目涉及的内容很多，而且总有更深入的东西可以探索。重点在于理解整体架构，而不是在低层细节上卡住。
我花了多少时间
我是一名前端工程师，正在转向 DevOps。我在这个挑战上不到一周的时间里完成了网站上的所有要求。
说实话，实际花费的时间并没有太大意义。它取决于个人想要深入的程度以及方案的完整性。下面是我在各个部分大致花费时间的比例：
| 领域 | 大约占总时间的百分比 |
|---|---|
| HTML/CSS | 0–1 %（使用 Next.js 构建静态站点） |
| Web 控制台设置 | ~30 %（创建完整可用的演示，学习 API Gateway、Lambda 等） |
| IaC + CI/CD | 50–60 %（反复试验，隐藏的控制台配置） |
| 博客撰写 / 反思 | ~10 %（我认为最重要的部分） |
反思
剧透警告：如果您还没有完成挑战，请停止阅读，因为我即将揭示我的解决方案。
项目架构
域名 (janice-zhong.com) 解析到一个 CloudFront 分配，该分配指向一个启用了静态托管的 S3 存储桶。S3 存储桶提供网站内容，并调用 API Gateway，触发 Lambda 函数从 DynamoDB 读取和写入数据。
已配置两个 TLS 证书：
- 在 us‑east‑1 为 CloudFront 配置
- 在 ap‑south‑east‑2 为 API Gateways 配置
Lambda 函数
Lambda 是一种托管的计算服务，让您无需管理服务器即可在 AWS 上运行函数。重要要点：
- 幂等性 – 每个 Lambda 在多次调用时应产生相同的结果。
- 无状态性 – 并发调用会使用全新的环境；您应假设调用之间不会保留状态。
DynamoDB
项目级别的串行写入
我最初的错误是认为并发的 Lambda 函数在更新同一记录时会导致竞争条件。我最开始为每次页面访问插入一条新记录，然后统计记录总数。这很快就出现了问题，因为 Scan 操作是 O(n)，对于简单的页面浏览计数器来说效率低下。
我学到的: DynamoDB 默认提供 项目级别的串行写入，因此可以安全地对单个项目的计数器进行递增。
通过客户端重试防止写入被限流
DynamoDB 基于 RCU（读取容量单位） 和 WCU（写入容量单位） 运行。在按需模式下，你可以获得最高 4,000 次写入/秒。如果超过此限制，DynamoDB 会返回 ProvisionedThroughputExceededException。在客户端使用指数退避重试来处理该异常可以缓解限流。
API 网关
我会省略许多细节以保持本文简洁，但有一个值得强调的关键主题是 API 网关中的 throttling。
API 限流
（关于限流限制、突发容量以及如何配置使用计划的详细信息将在此处提供。）
Git 仓库
链接到仓库 (将 # 替换为实际的 URL)
更多内容即将推出
敬请期待更深入的探讨：
- CI/CD pipelines
- Monitoring & alerting
- Cost optimisation
所有标题、列表和链接已标准化，同时保留原始内容。
开发观察
在开发过程中，我注意到有大量的机器人流量访问我的 CloudFront 分配。这促使我在 API Gateway 中设置了限流。
API Gateway 限流
API Gateway 限流可以在三个层级应用：
| 层级 | 描述 |
|---|---|
| Account (default) | 全局默认设置，适用于整个账户 |
| Stage | 应用于特定的部署阶段 |
| Route | 细粒度的每个方法限制 |
我在 stage 层级应用了限流，并配置了：
- Burst: 50 → 突发：50
- Limit: 200 → 限制：200
如需更高级的基于 IP 的限流，可使用 AWS WAF。
Terraform (IaC)
远程状态 + 锁定
- 状态文件 绝不 应提交到版本控制，以避免凭证泄露和状态损坏。
- 最初我将状态存储在 S3 存储桶中，随后迁移到 HCP Terraform 以获得更好的管理。
始终固定版本
将 provider 和模块的版本固定，以防止上游更新导致意外的破坏性更改。
使用 HCP Terraform 实现自动化 Terraform（CI/CD）
- 与 GitHub Actions 相比，HCP Terraform 开箱即用提供审计日志和手动审批工作流，无需额外配置。
- 这显著降低了基于 Terraform 的 CI/CD 流水线的运维开销。
安全
OIDC
OpenID Connect (OIDC) 允许 GitHub Actions 工作流在您的 AWS 账户中承担 IAM 角色并获取短期凭证。
- 消除存储在 GitHub Secrets 中的长期访问密钥。
- 减少凭证轮换的运维负担。
TLS
TLS 对客户端和服务器之间的流量进行加密。
- 配置了两个 TLS 证书：
- us‑east‑1 – 用于 CloudFront
- ap‑south‑east‑2 – 用于 API 网关
添加人工验证流程
大量的机器人流量引发了对合法用户可能因限流而被阻止的担忧。提供两种方案：
| 选项 | 描述 | 成本 |
|---|---|---|
| CloudFront + AWS WAF | 原生 AWS 解决方案；包括一个托管的机器人控制规则组，可处理每月前 1 百万次网页请求并处理 CAPTCHA/挑战尝试。 | $10 / 月（按小时比例计费） |
| Cloudflare Turnstile | 免费替代方案，提供相同的人机验证功能。 | 免费 |
可以在此处找到 AWS WAF 方法的教程 here。
Git 仓库
- 前端:
- 基础设施即代码 (IaC):
接下来
我已经让基本工作流运行起来，接下来将很快着手 Cloud Resume Challenge 这本书，以实现可选的附加挑战。
敬请期待！