AWS云架构设计与部署：让 200+ AWS 服务的选择有章可循，部署一步到位
- 核心定位：这不是一个"帮你写代码"的技能，而是一个"帮你做架构决策"的技能——它用决策树、选择矩阵和成本数字，把 AWS 上百个服务的选择过程变得可复用。
- 覆盖范围：计算（Lambda / Fargate / ECS / EKS / EC2）、数据库（RDS / Aurora / DynamoDB / ElastiCache / Redshift）、存储（S3 / EBS / EFS / FSx）、网络（VPC / ALB / CloudFront）、安全（IAM / KMS / Secrets Manager）、IaC（CDK / Terraform / CloudFormation）全覆盖。
- 差异化亮点：包含大量可直接引用的成本数字（如 100 万次请求的 Serverless API 月成本约 15 美元），以及 2025 年的新能力（Lambda SnapStart、EventBridge Pipes、S3 Express One Zone、EKS 自动模式等）。
- 落地方式：技能内提供架构模式图、参考文档目录、CDK / Terraform / CloudFormation 示例工程与成本/审计/安全脚本，架构方案可以直接推进到实现层。
- 适合人群：正在做上云选型的架构师、想从 EC2 迁移到容器/Serverless 的后端工程师、需要做成本优化的技术负责人、准备架构评审的团队。
该技能叫什么？如何一键安装 AI 技能提升开发效率？
技能中文名：AWS云架构设计与部署技能Skill 技能英文名：deploying-on-aws 技能ID：13434
这个技能要解决的是一个非常具体的痛点：AWS 官方服务超过 200 个，同一个业务需求往往有三五种可选实现路径，而每条路径背后对应着完全不同的成本结构、运维负担和扩展能力。传统做法是在官方文档、架构博客、社区问答之间反复横跳，最后往往凭"团队熟悉什么"拍板，而不是凭"什么最合适"拍板。该技能把这些判断沉淀成一套固定的决策框架——先问执行时长、流量模式、数据模型、访问频率，再逐步收敛到具体服务和配置组合。
一键安装的思路与步骤
第一步：确认安装前提
- 你使用的 AI 客户端 / 编程助手需要支持"技能（Skill）"机制，能够加载外部技能包；
- 具备向本地或团队技能库写入的权限；
- 若希望让技能直接产出可部署代码，建议已准备好 AWS 账号与凭证环境（仅用于最终验证，技能的选型和设计环节不依赖账号）。
第二步：通过技能入口安装 在技能市场、技能仓库或团队内部技能中心的检索框中，输入技能ID 13434 或英文名 deploying-on-aws 定位到该技能，点击"安装 / 添加到我的技能"。具体的安装命令、仓库地址与客户端操作路径，以官方说明为准，不同客户端的入口名称可能略有差异。
第三步：验证是否生效 安装后新建一个会话，直接抛出一个典型问题，例如：
“我有一个请求量波动很大的 REST API 后端，团队只有两个人维护，应该选 Lambda 还是 Fargate？顺便估算一下 100 万次请求/月的成本。”
如果回答中出现了"执行时长 <15 分钟 → 评估 Lambda"这类决策流程、一张计算服务快速参考表（工作负载 / 首选 / 成本模型 / 关键优势），以及 API Gateway + Lambda + DynamoDB 约 15 美元/月的成本拆分，就说明技能已经正常加载并生效。
第四步：组合使用
该技能可与 infrastructure-as-code（多云 IaC）、kubernetes-operations（EKS 集群运维）、secret-management（密钥轮换）、building-ci-pipelines（CI/CD 流水线）、observability（可观测性）等技能搭配，形成"选型 → 编码 → 部署 → 运维"的完整闭环。
该技能的主要功能和特点
1. 计算服务的结构化决策树 技能内置了一条按"执行时长 → 是否事件驱动 → 是否容器化 → 是否有特殊需求"逐层收敛的判断流程：执行时长小于 15 分钟先评估 Lambda；容器化且需要 Kubernetes 生态走 EKS，否则走 ECS（Fargate 或 EC2）；需要 GPU、Windows 或 BYOL 许可则回到 EC2。配套的快速参考表直接给出"API 后端 = Lambda + API Gateway、微服务 = ECS on Fargate、Kubernetes 应用 = EKS"等结论。
2. 数据库按访问模式选型 以"访问模式 + 数据模型"二维矩阵给出首选方案：事务型关系数据选 Aurora，简单 CRUD 选 RDS PostgreSQL，键值查找与文档存储选 DynamoDB，缓存选 ElastiCache Redis，分析型选 Redshift 或 Athena，时间序列选 Timestream。还给出查询复杂度指引——简单键值用 DynamoDB，2~3 表连接用 Aurora/RDS，复杂分析用 Redshift 或 Athena 查询 S3。
3. 存储选型与真实成本对照 用决策树区分对象、块、共享文件三类数据，并给出 1TB/月的成本对照：S3 标准 23 美元、S3 标准-IA 12.5 美元、S3 Glacier 即时 4 美元、EBS gp3 80 美元、EFS 标准 300 美元。结论也很直白：80% 以上的存储需求用 S3，只有在确实需要共享文件访问时才上 EFS/FSx。
4. 可直接照搬的架构模式
- Serverless 模式一：客户端 → API Gateway（HTTP API）→ Lambda → DynamoDB / S3，含漏洞点定位与请求级成本估算；
- Serverless 模式二：S3 上传 → EventBridge 规则 → Lambda 处理 → DynamoDB 元数据 + SQS 下游任务，覆盖解耦、扇出、重试与死信队列；
- 容器模式：ALB → ECS Fargate → Aurora + ElastiCache；
- 数据流水线：S3 → EventBridge → Lambda → Kinesis Firehose → S3 数据湖 → Athena。
5. 网络与安全的标准骨架
给出 VPC 10.0.0.0/16 配三层子网（公共 / 私有 / 数据库）跨 3 个可用区部署的标准范式，ALB / NLB / GWLB 的选型表，以及 IAM 最小权限策略示例、S3 / EBS / RDS / DynamoDB 的静态与传输加密对照表。
6. Well-Architected 六大支柱落地指引 把运营卓越、安全、可靠性、性能效率、成本优化、可持续性六个支柱拆成可执行动作，例如可持续性支柱明确建议使用 Graviton 处理器（能耗降低约 60%、性能提升约 25%）。
7. 成本优化的定价模型对照 按需、Savings Plans（30~40%）、预留实例（30~60%）、Spot（60~90%）四档模型与实际节省比例对照，配合 S3 生命周期分层策略（标准 → 标准-IA → Glacier 即时 → 深度归档）给出完整的降本路径。
8. 从设计直达实现的工程资产 技能附带参考文档目录（计算、数据库、存储、网络、安全、Serverless 模式、容器模式、Well-Architected）、CDK / Terraform / CloudFormation 示例工程，以及成本估算、资源审计、安全检查三个实用脚本。
和普通通用 AI 对话相比强在哪：普通对话给出的往往是"可以用 Lambda，也可以用 EC2"这种两不靠的回答；该技能给的是有前置条件、有取舍标准、有成本数字、有对应实现示例的决策结论。
如何使用该技能？
第 1 步：用"业务约束"开题，而不是用"服务名"开题 不要问"Lambda 怎么用"，而要问"我要做一个日均 50 万请求、流量波动很大的图片处理服务，团队没有运维人手，怎么选"。技能内部的快速决策清单会依次追问八个关键维度：流量模式、数据模型、访问模式、延迟要求、扩展需求、运维开销、成本敏感度、合规要求。
第 2 步：拿到选型结论后，要求给出架构图和组件清单 示例输入：
“按上面的结论，帮我画一下这个 Serverless 图片处理服务的架构，列出每个组件的职责。”
预期输出会类似：
S3 上传 → EventBridge 规则 → Lambda（图片处理）→ DynamoDB（元数据）
↓
SQS（下游任务）
第 3 步：要求做成本估算 示例输入：
“按 100 万次请求/月估算一下这套架构的成本。” 预期输出会把 API Gateway（约 3.5 美元）、Lambda（约 3.5 美元）、DynamoDB（约 7.5 美元）逐项拆开，并横向对比 Fargate（约 35 美元以上）与 EC2（约 50 美元以上）。
第 4 步：要求落到 IaC 代码 示例输入：
“用 CDK 把这个架构搭出来，语言用 TypeScript。” 技能中给出的 CDK 快速开始路径为：安装 CDK CLI（
npm install -g aws-cdk）→ 初始化项目（cdk init app --language=typescript）→ 安装依赖 →cdk bootstrap一次性初始化 →cdk deploy部署。若偏好 Terraform，则对应terraform init→terraform plan→terraform apply三步流程。
第 5 步：做架构评审与优化 示例输入：
“这是一个已经上线的三层应用：EC2 + RDS + ELB，月成本偏高，帮我按 Well-Architected 六支柱做一次评审并给出优化项。” 预期输出会覆盖：正确调整实例规格、评估 Savings Plans 或预留实例、迁移到 Fargate / Aurora、开启 S3 生命周期策略、启用 GuardDuty 与最小权限 IAM、补充多可用区部署与备份策略。
第 6 步：使用配套脚本做验证
技能附带的 scripts/cost-estimate.sh（成本估算）、scripts/resource-audit.sh（资源审计）、scripts/security-check.sh（基础安全检查）可用于把方案落到实际账号前的自查环节。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 本技能（deploying-on-aws） | 面向 AI 助手的 AWS 架构决策框架与实现模式库 | 计算/数据库/存储选型决策树、Serverless 与容器架构模式、VPC 与安全范式、Well-Architected 六支柱、IaC 示例与成本脚本 | 通过技能市场按技能ID或英文名添加，安装后对话即用，无需额外账号 | 上云选型、架构设计、成本优化、架构评审 | 优势：结论明确且带成本数字，能直接产出 CDK/Terraform 代码；不足：需要所在客户端支持技能机制，深度定制仍需人工把关 |
| AWS Well-Architected Tool | AWS 官方的架构评审工具 | 按六大支柱逐项问答打分，生成风险清单与改进建议 | 需登录 AWS 控制台，免费使用 | 已成体系的架构做规范化评审 | 优势：官方权威、评估维度完整；不足：偏"事后评估"，不负责"事前选型"，不产出代码 |
| Amazon Q Developer | AWS 官方 AI 开发助手 | 代码补全、控制台操作问答、部分架构建议 | 需订阅并配置 IDE 或控制台插件 | 日常编码与控制台操作辅助 | 优势：与 AWS 深度集成、官方口径；不足：架构选型的结构化决策路径较弱，成本对照不如决策表直观 |
| 通用大模型对话（ChatGPT / Claude 等） | 通用问答 | 可回答任意 AWS 问题 | 打开即用，门槛最低 | 零散问题速查 | 优势：覆盖面广、上手零成本；不足：回答易"两头都说"，缺少固定决策框架与可复用的示例工程，成本数字可能过时 |
选型建议：需要"从 0 到 1 做决定"时优先用本技能；架构已经上线、要做规范化合规评审时用 Well-Architected Tool；日常编码辅助交给 Amazon Q Developer 或通用助手；本技能与后两者是互补而非替代关系。
该技能的典型应用场景与实际体验情况
场景一：两人小团队搭建第一个 Serverless 后端 角色是初创公司的全栈工程师，痛点是"没人懂运维，但又要扛住不稳定的推广流量"。使用方式是直接描述业务约束，让技能输出"API Gateway HTTP API + Lambda + DynamoDB 按需计费"的组合，并确认 100 万请求/月约 15 美元的成本可接受。 实际体验：上手几乎无门槛，回答不再是模糊的"都可以"，而是明确的"先评估 Lambda，超过 15 分钟执行时长才转向容器"。需要注意：按需计费的 DynamoDB 在极端突发下成本会波动，技能也提示了这一点，生产环境仍建议配置预算告警。
场景二：传统业务从 EC2 迁移到容器 角色是企业的后端负责人，现状是 EC2 + RDS 单体应用，月账单偏高且扩容靠手动。使用方式是让技能按"是否需要 Kubernetes 生态"分流——团队没有 K8s 经验，走 ECS on Fargate；再对照 2 vCPU / 4GB / 24 小时运行约 70 美元、ALB 约 20 美元、Aurora db.t3.medium 约 50 美元、合计约 140 美元/月的模型做预算。 实际体验：成本拆解非常实用，迁移路径清晰。注意点是迁移过程中数据库从 RDS 到 Aurora 的兼容性、以及 Fargate 冷启动对首屏延迟的影响，需要单独压测验证。
场景三：存量账号的成本优化专项
角色是技术负责人，痛点是"账单每月涨，但不知道钱花在哪"。使用方式是让技能按成本优化章节逐条排查：计算侧看 Compute Optimizer 推荐与 Savings Plans / 预留实例覆盖比例，存储侧配置 S3 生命周期（0~30 天标准 → 30~90 天标准-IA → 90~365 天 Glacier 即时 → 365 天以上深度归档），EBS 把 gp2 换成 gp3（约便宜 20% 且 IOPS 可配），并清理未使用的快照。
实际体验：条目具体、可执行性强，配合 scripts/resource-audit.sh 做盘点效率明显提升。注意：生命周期策略一旦生效不可逆地改变了存储类，建议先在测试桶上跑一轮。
场景四：架构评审会议的"陪练" 角色是解决方案架构师，需要在评审前自查漏洞。使用方式是让技能按 Well-Architected 六支柱逐项过一遍：可靠性看是否跨 3 个可用区、是否配置自动快照；安全看 IAM 是否最小权限、是否启用 GuardDuty 与 CloudTrail；性能看是否用了 CloudFront / ElastiCache 缓存。 实际体验：把评审从"凭经验"变成"对清单"，遗漏率显著下降。注意技能提供的是通用最佳实践，行业合规（如数据驻留要求）仍需结合具体法规判断。
该技能能为用户带来的价值
1. 把"选型焦虑"变成"流程作业" AWS 200 多个服务对一个中型项目来说，可选项通常也有几十种。技能用决策树把收敛路径固定下来，把原本需要几天的技术调研压缩成一次对话，团队不需要每个人都是 AWS 专家也能做出站得住脚的结论。
2. 用真实成本数字替代拍脑袋 技能内嵌了大量可直接引用的成本对照：1TB 存储用 S3 标准 23 美元 vs EFS 标准 300 美元，差距超过十倍；Serverless API 100 万请求约 15 美元 vs Fargate 约 35 美元、EC2 约 50 美元起。这类数字在方案讨论阶段就能避免方向性错误，长期看是最大的一笔省钱。
3. 降低 IaC 落地门槛 技能不只停在架构图，而是给出 CDK / Terraform / CloudFormation 三套示例工程与快速开始命令。对于还不熟悉 IaC 的团队，这相当于把"从架构到代码"的最后一公里铺平了，基础设施即代码的推行阻力明显降低。
4. 让架构评审有清单可依 Well-Architected 六支柱被拆解成一条条可勾选的动作项，评审从主观讨论变成逐项对照，遗漏风险大幅减少。
5. 长期价值：可复用的组织知识 虽然技能本身是通用最佳实践，但团队在使用过程中沉淀下来的选型结论、成本基线和评审清单，会逐步变成团队自己的架构规范——这是比单次方案更有价值的资产。
常见问题 FAQ
Q1：这个技能怎么安装？需要付费吗？ 在支持技能机制的 AI 客户端或技能市场中，用技能ID 13434 或英文名 deploying-on-aws 检索并添加即可。技能本身的定价、是否免费、以及所在平台的订阅政策，以官方说明为准。技能运行过程中不需要访问你的 AWS 账号，只有在你决定实际部署时才会用到账号凭证。
Q2：它会不会直接帮我把资源部署到 AWS 账号里？
不会。该技能的定位是"决策框架与实现模式"，输出的是选型建议、架构图、成本估算和 IaC 代码模板。真正的部署动作（如执行 cdk deploy 或 terraform apply）需要你在自己的环境中手动完成，这也是一层必要的安全边界。
Q3：我是 AWS 新手，用这个技能会不会看不懂？ 完全可以上手。技能的决策流程本身就是按"问问题 → 给结论"的方式组织的，不需要你先掌握全部服务知识。建议从"快速决策清单"的八个问题开始，逐步展开。不过涉及生产环境的最终方案，仍建议由有经验的工程师复核。
Q4：技能里的成本数字准吗？可以直接写进预算吗？ 技能中的成本数字（如 S3 标准 23 美元/TB、Fargate 约 70 美元/月、EKS 控制平面 73 美元/月等）是基于典型配置的估算参考，用于方案比较和方向判断非常有效。但实际账单会受区域、流量模式、数据传输费、折扣协议等因素影响，最终以 AWS 官方定价页与你的实际账单为准，正式预算建议留出余量。
Q5：它和 AWS Well-Architected Tool、Amazon Q Developer 怎么选？ 三者互补：本技能擅长"事前选型 + 出方案 + 出代码"，适合从 0 到 1 设计阶段；Well-Architected Tool 擅长"事后评审"，适合架构已上线后做规范化体检；Amazon Q Developer 擅长日常编码与控制台操作辅助。实际工作中常见的组合是：先用本技能定架构，落地后用 Well-Architected Tool 做复盘，日常编码交给开发助手。