wb-platform-engineering-lab/cloud-migration-lab-aws

# 云迁移实验室 — AWS       ## 从单体到云原生 ## 是什么让这个实验室与众不同 GKE 平台工程实验室从零开始构建一个平台。这个实验室模拟了一次 **真实的迁移** —— 应用程序已经存在、已经有用户、已经有约束，并且无法简单地重写。每个阶段都由真实的业务问题驱动，你使用为解决该问题而设计的 AWS 服务来解决问题。 你将通过需要使用它们的方式来学习 AWS 服务。 ## 我们从哪里开始：单体应用 OrderFlow 是一个基于 Node.js/Express 的应用程序，后端使用 PostgreSQL。所有内容都位于单个仓库和单个可部署单元中： ``` orderflow/ ├── src/ │ ├── routes/ │ │ ├── orders.js # Create, read, update orders │ │ ├── products.js # Product catalog │ │ ├── customers.js # Customer management │ │ └── auth.js # Session-based auth │ ├── models/ # Sequelize ORM models │ ├── services/ │ │ ├── email.js # Sends order confirmations via SMTP │ │ ├── inventory.js # Updates stock counts │ │ └── reports.js # Daily PDF reports (CPU-intensive) │ └── app.js # Express server ├── migrations/ # SQL schema migrations ├── public/ # Static assets (images, JS, CSS) ├── Dockerfile └── package.json ``` OrderFlow 所做的一切 —— 处理订单、认证用户、发送邮件、生成报告、提供图像 —— 都运行在这个单一进程中。一次崩溃会导致全部停止。一个缓慢的报告会阻塞所有 API 请求。一次部署会同时重启所有服务。 **迁移不是重写。它是一系列有针对性的提取和替换，一次解决一个问题。** ## 迁移策略 — 绞杀榕模式 我们不重写单体应用，而是使用 [绞杀榕模式](https://martinfowler.com/bliki/StranglerFigApplication.html)：逐步将流量从单体应用路由到新的云原生组件，每次只迁移一个能力，直到单体应用被退役。 ``` flowchart LR subgraph Start["Day 1 — Everything in the monolith"] M1["Node.js monolith\n- Orders API\n- Auth\n- Email\n- Reports\n- Static files\n- Sessions"] end subgraph End["End state — Cloud-native on AWS"] CF["CloudFront\n(static files)"] ALB["ALB"] ECS["ECS — Orders API\n(containerized core)"] LAMBDA["Lambda\n(email, reports)"] RDS["RDS PostgreSQL\n(managed, Multi-AZ)"] ELASTICACHE["ElastiCache\n(sessions)"] S3["S3\n(assets, reports)"] SQS["SQS\n(order events)"] COGNITO["Cognito\n(auth)"] end Start --> End ``` 每个阶段提取一个关注点并使用专门设计的 AWS 服务进行替换。单体会逐渐缩小，平台会逐渐成长。用户除了感觉更快之外不会注意到任何变化。 ## 阶段一览 | 阶段 | 标题 | 构建内容 | 引入的 AWS 服务 | |---|---|---|---| | 0 | 认识单体 | 本地容器化并运行 OrderFlow | Docker, docker-compose | | 1 | AWS 基础 | VPC、IAM、Terraform 状态存储 | VPC、IAM、S3（Terraform 状态）、EC2 | | 2 | 提升并转移 | 将单体应用迁移到 AWS，变更最小 | EC2、RDS、ElastiCache、ALB、Route 53 | | 3 | 容器化与 ECS | 用托管容器替换 EC2 实例 | ECS Fargate、ECR、ALB 目标组 | | 4 | CI/CD 流水线 | 自动化构建、测试和部署 | GitHub Actions、ECR、ECS 滚动部署 | | 5 | 提取静态资源 | 将文件和图片移出单体应用 | S3、CloudFront、预签名 URL | | 6 | 使用 SQS/SNS 实现异步 | 解耦订单事件与请求路径 | SQS、SNS、EventBridge | | 7 | 针对合适问题使用无服务器 | 用 Lambda 替换 CPU 密集型和事件驱动型代码 | Lambda、API Gateway、EventBridge Scheduler | | 8 | 将认证提取到 Cognito | 用基于令牌的认证替换会话认证 | Cognito 用户池、JWT、ALB 认证 | | 9 | EKS — 平台层 | 将核心 API 迁移到 Kubernetes 以支持团队规模 | EKS、Helm、ALB Ingress 控制器 | | 10 | 可观测性 | 所有组件的指标、日志和追踪 | CloudWatch、X-Ray、OpenTelemetry、Grafana | | 11 | 安全加固 | 最小权限、密钥管理、WAF、威胁检测 | Secrets Manager、IAM 策略、WAF、GuardDuty | | 12 | 多环境与结项项目 | 开发/预发布/生产环境的准生产级发布流水线 | AWS Organizations、Terraform 工作区、GitOps | | 13 | 数据平台与 AI | 分析数据湖、实时流处理、需求预测以及生成式 AI 订单助手 | Kinesis、Glue、Athena、QuickSight、Bedrock、Forecast | ## 先决条件 | 工具 | 用途 | |---|---| | `docker` + `docker compose` | 在阶段 0 本地运行单体应用 | | `aws` CLI v2 | 从终端与 AWS 交互 | | `terraform` 1.7+ | 将所有基础设施作为代码配置 | | `kubectl` | 从阶段 9 开始的 Kubernetes 命令行工具 | | `helm` | Kubernetes 包管理器 | | `node` 20 | 本地运行单体应用 | **AWS 账户要求：** - 已启用账单功能的 AWS 账户 - 具有 `AdministratorAccess` 权限的 IAM 用户或 SSO 配置文件（在阶段 11 中范围缩小） - 预估成本：运行资源时每天约 $3–15 — 始终在非工作时段运行 `terraform destroy` **无需事先具备 AWS 经验。** 每个阶段都会在你需要时引入所需服务，并说明其存在的理由。 ## 阶段说明 每个阶段都有独立的文件夹，包含完整的说明、架构图、挑战和成本分解。 | 阶段 | 文件夹 | |---|---| | 0 — 认识单体 | [phase-0-meet-the-monolith/](phase-0-meet-the-monolith/README.md) | | 1 — AWS 基础 | [phase-1-foundations/](phase-1-foundations/README.md) | | 2 — 提升并转移 | [phase-2-lift-and-shift/](phase-2-lift-and-shift/README.md) | | 3 — 容器化与 ECS | [phase-3-ecs/](phase-3-ecs/README.md) | | 4 — CI/CD 流水线 | [phase-4-cicd/](phase-4-cicd/README.md) | | 5 — 提取静态资源 | [phase-5-static-assets/](phase-5-static-assets/README.md) | | 6 — 使用 SQS/SNS 实现异步 | [phase-6-async/](phase-6-async/README.md) | | 7 — 无服务器 | [phase-7-serverless/](phase-7-serverless/README.md) | | 8 — 使用 Cognito 进行认证 | [phase-8-cognito/](phase-8-cognito/README.md) | | 9 — EKS：平台层 | [phase-9-eks/](phase-9-eks/README.md) | | 10 — 可观测性 | [phase-10-observability/](phase-10-observability/README.md) | | 11 — 安全加固 | [phase-11-security/](phase-11-security/README.md) | | 12 — 多环境与结项项目 | [phase-12-capstone/](phase-12-capstone/README.md) | | 13 — 数据平台与 AI | [phase-13-data-ai/](phase-13-data-ai/README.md) | ## AWS 认证路线图 本实验室为所有四项 AWS 关联及专业认证提供实践基础。按顺序尝试 — 每一项都建立在前一项的基础上。 | 认证 | 完成阶段 | 涵盖重点 | |---|---|---| | **AWS 解决方案架构师助理 (SAA-C03)** | 阶段 6 | VPC、EC2、RDS、S3、CloudFront、ECS、Lambda、IAM、Route 53、SQS/SNS | | **AWS 开发助理 (DVA-C02)** | 阶段 8 | CodePipeline、Lambda、X-Ray、DynamoDB、Cognito、API Gateway、ECS | | **AWS 系统运维助理 (SOA-C02)** | 阶段 10 | CloudWatch、Config、Systems Manager、Trusted Advisor、Cost Explorer | | **AWS 解决方案架构师专业 (SAP-C02)** | 阶段 12 | Organizations、Control Tower、多账户、成本优化、迁移策略 | ## 各阶段成本分解 所有价格均为 2026 年 AWS 按需费率（us-east-1`）。成本假设资源全天运行 — 结束时请务必销毁资源。 ### 资源定价参考 | 资源 | 规格 | $/小时 | $/天 | |---|---|---|---| | NAT 网关 | — | $0.045 | $1.08 | | EC2 | t3.small | $0.021 | $0.50 | | EC2 | t3.medium | $0.042 | $1.00 | | RDS PostgreSQL | db.t3.small 多可用区 | $0.068 | $1.63 | | RDS PostgreSQL | db.t3.micro 单可用区 | $0.017 | $0.41 | | ElastiCache Redis | cache.t3.micro | $0.017 | $0.41 | | ALB | — | $0.008 + LCU | ~$0.25 | | ECS Fargate | 0.5 vCPU / 1 GB × 2 个任务 | — | $1.19 | | EKS 控制平面 | — | $0.100 | $2.40 | | EC2 节点 | t3.medium × 2 | $0.042 | $2.00 | | CloudWatch 日志 | ~0.5 GB/天摄入 | — | ~$0.30 | | 托管 Grafana | 1 个活跃用户 | — | $0.30 | | GuardDuty | 小型账户（试用后） | — | ~$1.00 | | WAF Web ACL | — | — | $0.17 | | AWS Config | ~50 个资源 | — | ~$0.20 | ### 各阶段成本表格 | 阶段 | 新增资源 | 移除资源 | 每日净成本 | 累计每日成本 | |---|---|---|---|---| | **0** | 无 — 仅本地 Docker | — | $0 | $0 | | **1** | VPC、2 个 NAT 网关、S3 存储桶、DynamoDB 锁 | — | +$2.20 | **$2.20** | | **2** | 2 个 EC2 t3.small、RDS 多可用区、ElastiCache、ALB、Route 53 | — | +$3.90 | **$6.10** | | **3** | ECS Fargate ×2（0.5 vCPU/1 GB）、ECR | 移除 2 个 EC2 | +$0.20 | **$6.30** | | 4 | ECR 镜像存储（约 5 个镜像） | — | +$0.05 | **$6.35** | | 5 | S3 资源存储桶、CloudFront 分配 | — | +$0.05 | **$6.40** | | 6 | SQS ×3、SNS 主题、DLQ ×3 | — | ~$0（按量免费额度） | **$6.40** | | 7 | Lambda 函数、EventBridge Scheduler | — | ~$0（按量免费额度） | **$6.40** | | 8 | Cognito 用户池 | — | ~$0（MAU 5 万以内免费） | **$6.40** | | 9 | EKS 控制平面、2 个 t3.medium 节点 | 移除 ECS Fargate ×2 | +$3.21 | **$9.60** | | 10 | CloudWatch 日志、托管 Prometheus、托管 Grafana | — | +$0.70 | **$10.30** | | 11 | GuardDuty¹、Config、WAF、Security Hub、Inspector、Secrets Manager | — | +$1.65 | **$11.95** | | 12 | ×3 个环境（开发 + 预发布 + 生产）+ 共享服务 | — | +$22 | **~$34** | | 13 | Kinesis、Glue、Athena、QuickSight、Bedrock、Forecast（一次性训练） | — | +$2.20 | **~$36** | ¹ GuardDuty 有 **30 天免费试用**。阶段 11 期间试用期内每天约 $10.95，试用期后每天约 $11.95。 ### 阶段 12（多账户）成本明细 阶段 12 是成本显著上升的阶段。以下是每个账户的详细分解： | 账户 | 关键资源 | 每日成本 | |---|---|---| | **开发** | 1 个 NAT 网关、EKS、1 个 t3.small 节点、RDS 单可用区 | ~$5 | | **预发布** | 2 个 NAT 网关、EKS、2 个 t3.medium 节点、RDS 多可用区、ElastiCache | ~$10 | | **生产** | 2 个 NAT 网关、EKS、2 个 t3.medium 节点、RDS 多可用区、ElastiCache、WAF | ~$11 | | **共享**（审计 + 日志归档） | GuardDuty、Config、Security Hub、CloudTrail（3 个账户） | ~$5 | | **总计** | | **~$31–35/天** | ### 如果从不销毁的月度成本 这是如果你让所有资源整月运行的成本 — 用作设置账单警报的上限参考。 | 阶段 | 活跃资源 | 月度成本 | |---|---|---| | 1 | VPC + NAT 网关 | ~$66 | | 2 | + EC2、RDS、ElastiCache、ALB | ~$183 | | 3–8 | + ECS、S3、CloudFront、Lambda | ~$192 | | 9 | + EKS、节点（移除 ECS） | ~$288 | | 10 | + 可观测性堆栈 | ~$309 | | 11 | + 安全堆栈 | ~$358 | | 12 | 3 × 环境 | ~$1,000 | | 13 | + 数据湖、Bedrock、QuickSight | ~$1,065 | ### 成本控制检查清单 在开始阶段 1 之前设置以下内容： ``` # 创建账单提醒 - 在成本螺旋上升之前 aws budgets create-budget \ --account-id $(aws sts get-caller-identity --query Account --output text) \ --budget file://budget.json \ --notifications-with-subscribers file://notifications.json # 标记每个资源 - 使 Cost Explorer 有用 # 每个 Terraform 资源应包含： # tags = { Project = "orderflow", Phase = "2", Environment = "dev" } # 阶段完成后销毁 cd phase-X-*/terraform terraform destroy -auto-approve ``` **最昂贵的资源是：NAT 网关。不运行时应立即销毁 — 两个 NAT 网关每年花费 $1,620 什么也不做。始终在非工作时段销毁它们。** **最经济的多天方案：** 完成每个阶段后，仅保留 RDS 运行（使用最便宜的实例并创建最终快照），销毁其他所有内容。下次会话开始时从快照恢复。 ## 仓库结构 ``` cloud-migration-lab-aws/ ├── orderflow/ # The monolith — starting point │ ├── src/ │ ├── Dockerfile │ ├── docker-compose.yml │ └── README.md ├── phase-0-meet-the-monolith/ ├── phase-1-foundations/ │ └── terraform/ ├── phase-2-lift-and-shift/ │ └── terraform/ ├── phase-3-ecs/ │ └── terraform/ ├── phase-4-cicd/ │ └── .github/workflows/ ├── phase-5-static-assets/ ├── phase-6-async/ ├── phase-7-serverless/ ├── phase-8-cognito/ ├── phase-9-eks/ │ └── charts/ ├── phase-10-observability/ ├── phase-11-security/ ├── phase-12-capstone/ ├── phase-13-data-ai/ │ ├── terraform/ # Kinesis, Glue, Athena, Bedrock KB, Forecast │ ├── glue-jobs/ # PySpark ETL scripts │ ├── forecast/ # Dataset export scripts and predictor config │ └── assistant/ # /assistant/ask Lambda handler └── README.md ``` ## 与 GKE 实验室的对比 | | GKE 平台工程实验室 | AWS 云迁移实验室 | |---|---|---| | **起点** | 空仓库 | 现有单体应用 | | **云平台** | Google Cloud Platform | Amazon Web Services | | **主题** | 从零开始构建开发者平台 | 迁移并现代化真实应用 | | **学习模式** | 按阶段引入技术 | 按业务问题引入技术 | | **容器编排** | 从第一天起使用 GKE（Kubernetes） | 先使用 ECS，后在需要时使用 EKS | | **关键技能** | Kubernetes、Helm、ArgoCD、Terraform | AWS 服务广度、迁移模式、成本优化 | | **认证目标** | CKA、CKS | SAA、DVA、SOA、SAP |

标签：AWS, AWS Lab, CPU密集型, Docker, DPI, ECS, Express, GKE, GNU通用公共许可证, Hands-on Lab, IAM, MITM代理, Node.js, PDF报告, PostgreSQL, SMTP, Strangler Fig模式, Terraform, 云迁移, 单体应用迁移, 可扩展架构, 子域名突变, 存储, 安全最佳实践, 安全防御评估, 平台工程, 测试用例, 漏洞利用检测, 生产就绪架构, 网络, 网络安全研究, 自定义脚本, 落地区设计, 计算, 请求拦截, 迁移策略