AWS 开发与云架构

要解决什么问题

在 AWS 上落地业务时，常见难点不是「会不会调某个 API」，而是如何把网络、身份、计算与数据拆成可重复部署的单元，并在环境之间保持一致。手写控制台配置容易漂移；缺少统一模式时，IAM 边界、VPC 分段、高可用与灾备往往事后补丁式补齐，评审和排障成本都会抬高。

技能如何工作

本技能面向基础设施自动化与云架构模式两条主线，为对话中的 AWS 开发提供结构化指引，而不是替代官方文档或你的组织规范。

• 自动化视角：强调用可版本化的定义描述资源与依赖，把变更收敛到可审查的流水线，减少「只在某个账号里改过」的隐性状态。
• 架构模式视角：围绕常见拓扑（如分层网络、无状态服务、托管数据层、最小权限访问）给出取舍说明，便于在需求早期对齐边界。
• 协作方式：当你描述目标环境、合规约束或现有栈时，技能会据此组织步骤、检查清单与反模式提醒，具体实现仍以源仓库与 AWS 官方最佳实践为准。

适用边界与注意点

• 技能提供模式与流程级指导，不保证覆盖某一垂直场景的全部细节（例如特定行业的合规模板）。
• 账号策略、配额、区域选择与成本模型因组织而异，输出应结合你方的安全基线与 FinOps 规则二次校验。
• 涉及生产变更时，务必在隔离环境验证，并保留回滚与变更记录；「更多信息请参阅源仓库」中的约束与示例优先级高于通用建议。