使用 agentic-awesome-skills 的 aws-cdk-development 技能构建 AWS CDK 云基础设施：命名规范、Lambda 开发与多层部署前校验实战

• AI 技能
• AI 插件
• 人工智能

导读

本指南以 AAS（agentic-awesome-skills）仓库中 aws-cdk-development 技能文档为核心，系统讲解如何使用该技能在 TypeScript/Python 下编写高质量 AWS CDK 基础设施代码。你将掌握三类可直接落地的能力：依托 AWS 文档 MCP 与 CDK 专用 MCP 的"先查证、后编码"工作流、资源命名与 Lambda 构造的使用原则，以及由 cdk-nag、构建测试与校验脚本构成的三层部署前质量门禁。

一、技能定位：一个面向 CDK 开发的 Agent 专家技能

aws-cdk-development 是 AAS 目录中以"云基础设施即代码"为目标的专项技能。在 数据目录 中，它被登记为：

• 分类：cloud
• 风险等级：critical（涉及创建、修改或部署云资源，属于高风险操作范畴）
• 标签：aws、cdk
• 触发词：aws、cdk、development、cloud、kit、building、infrastructure、typescript、python
• 来源：社区仓库zxkane/aws-skills，MIT 协议

同时，在 bundles.json 的core-dev开发技能包中，它与aws-mcp-setup、aws-serverless等技能一起被编排进核心开发套件，说明该技能是 AAS 中"云基础设施自动化"能力线的重要组成。其上层还有汇总性的 aws-skills 技能（涵盖 AWS 开发、基础设施自动化与云架构模式）。

该技能的适用场景非常聚焦，从文档原文看，主要包括：

• 创建新的 CDK stack 或 construct；
• 重构现有 CDK 基础设施；
• 在 CDK 中实现 Lambda 函数；
• 遵循 AWS CDK 最佳实践；
• 在部署前校验 CDK stack 配置；
• 核实 AWS 服务能力与区域可用性。

使用前提：只有当任务明确匹配上述上游来源与本地项目上下文时才应启用；对命令、生成代码、依赖、凭据与外部服务行为必须在使用前自行验证；示例不能替代针对具体环境的测试、安全评审，以及对破坏性或高成本操作的用户批准。

二、强制的事实核查机制：AWS 文档 MCP

aws-cdk-development 的核心设计之一是"先验证、后回答"：在回答任何 AWS 相关事实前，必须使用 MCP 工具（mcp__aws-mcp__*或mcp__*awsdocs*__*）核验 AWS 信息。

该技能声明依赖 aws-mcp-setup 技能（自动加载）。若 MCP 工具不可用，应引导用户先完成 aws-mcp-setup 的配置流程。按 aws-mcp-setup 的说明，AWS MCP 有两条可选路径：

检查工具是否可用的方法：运行/mcp命令列出活动 MCP 服务器，或检查.mcp.json（项目级）、~/.claude.json（用户级）等层级配置中是否包含aws-mcp、aws、awsdocs键。工具名出现mcp__aws-mcp__*或mcp__aws__*即表示 Full AWS MCP Server 已配置，出现mcp__*awsdocs*__aws___*则表示仅配置了文档 MCP。

为什么必须这样做：MCP 服务器能提供超出模型知识截止时间的最新 AWS 信息，包括新服务特性、区域可用性、配额限制与最新 API 规格，这正是基础设施代码最易因"过时知识"而出错的地方。

三、CDK 专属 MCP 的选型：从 cdk-mcp-server 到 aws-iac-mcp-server

文档特别指出一个重要的生态变化：AWS Labs 已用更广泛的awslabs.aws-iac-mcp-server取代了原先专用的 CDK MCP 服务器（awslabs.cdk-mcp-server）。前者在覆盖 CDK 的同时，也涵盖 CloudFormation 及其他 AWS 基础设施即代码工作流。

安装方式有两种：

• 随deploy-on-aws插件（来自awslabs/agent-plugins）一起分发；
• 直接用命令行注册：claude mcp add aws-iac uvx awslabs.aws-iac-mcp-server@latest。

何时使用该 CDK 专属 MCP：

• CDK construct 推荐与 API 查询；
• CDK 与 CloudFormation 最佳实践模式；
• 合成（synthesize）出的模板校验；
• 跨资源配置指导。

典型提问示例包括："API Gateway REST API 推荐用哪个 CDK construct？""如何配置 NodejsFunction 的 bundling 选项？""DynamoDB 自动扩缩容的 CDK construct 怎么选？"。结合上一节的 AWS 文档 MCP，二者形成互补：文档 MCP 负责"AWS 服务事实"，iac MCP 负责"CDK 编码细节"。

四、核心原则一：资源命名——让 CDK 自动生成名称

这是文档中标注为CRITICAL的规则：当 CDK construct 中的资源名称是可选项时，绝不显式指定名称。

为什么：CDK 自动生成名称（形如StackName-MyFunctionXXXXXX）能带来：

• 模式可复用：同一 construct/模式可在不冲突的情况下多次部署；
• 并行部署：多个 stack 可同时部署到同一区域；
• 共享逻辑更干净：共享模式代码可被多次初始化而无命名冲突；
• 栈隔离：每个 stack 自动获得唯一标识的资源。

对应的正确与错误写法如下：

// ❌ BAD - 显式命名会阻碍复用与并行部署 new lambda.Function(this, 'MyFunction', { functionName: 'my-lambda', // 避免这样写 // ... }); // ✅ GOOD - 让 CDK 生成唯一名称 new lambda.Function(this, 'MyFunction', { // 不指定 functionName - CDK 自动生成：StackName-MyFunctionXXXXXX // ... });

安全提示：对于 dev、staging、prod 等不同环境，应遵循 AWS 安全支柱最佳实践——使用独立的 AWS 账户而非依赖单账户内的资源命名差异。账户级隔离能提供更强的安全边界。

五、核心原则二：按运行时选择正确的 Lambda 构造

在 CDK 中实现 Lambda 时，应根据运行时选择对应的高级构造，让框架自动处理打包、依赖与转译，避免手工打包：

TypeScript / JavaScript：使用@aws-cdk/aws-lambda-nodejs的NodejsFunction：

import { NodejsFunction } from 'aws-cdk-lib/aws-lambda-nodejs'; new NodejsFunction(this, 'MyFunction', { entry: 'lambda/handler.ts', handler: 'handler', // 自动处理打包、依赖与转译 });

Python：使用@aws-cdk/aws-lambda-python的PythonFunction（alpha 模块）：

import { PythonFunction } from '@aws-cdk/aws-lambda-python-alpha'; new PythonFunction(this, 'MyFunction', { entry: 'lambda', index: 'handler.py', handler: 'handler', // 自动处理依赖与打包 });

收益：自动打包与依赖管理、自动转译、无需手工打包、部署模式一致。

六、核心原则三：多层部署前校验策略

文档要求采用多层校验策略，对 CDK 代码质量进行综合检查，共三层：

第 1 层：IDE 实时反馈（推荐）

针对 TypeScript/JavaScript 项目，安装 cdk-nag 以获得合成期校验：

npm install --save-dev cdk-nag

在 CDK app 中启用：

import { Aspects } from 'aws-cdk-lib'; import { AwsSolutionsChecks } from 'cdk-nag'; const app = new App(); Aspects.of(app).add(new AwsSolutionsChecks());

• 可选增强：VS Code 用户可安装 CDK NAG Validator 扩展，在保存文件时获得更快的反馈。
• Python/Java/C#/Go 项目同样支持 cdk-nag（所有 CDK 语言均可用），提供一致的合成期校验。

第 2 层：合成期校验（必需）

1. 使用 cdk-nag 合成：cdk synth（cdk-nag 通过 Aspects 自动运行）。
2. 抑制合理例外：必须附文档化理由：

import { NagSuppressions } from 'cdk-nag'; // 说明 WHY 这个例外是必要的 NagSuppressions.addResourceSuppressions(resource, [ { id: 'AwsSolutions-L1', reason: 'Lambda@Edge requires specific runtime for CloudFront compatibility' } ]);

第 3 层：提交前安全网

1. 构建：确保编译成功：npm run build（或对应语言的构建命令）；
2. 测试：运行单元与集成测试：npm test（或 pytest、mvn test 等）；
3. 校验脚本：元层面的检查：./scripts/validate-stack.sh。

文档明确指出校验脚本聚焦于：语言检测、模板大小与资源数量分析、合成成功验证；详细的"反模式"检查已交由 cdk-nag 承担。需要说明的是，references/cdk-patterns.md与scripts/validate-stack.sh属于该技能上游分发目录中的配套文件，在当前镜像仓库中未包含其内容，读者若需这两个文件的具体实现，应以技能来源仓库（zxkane/aws-skills的 aws-iac 插件）为准。

七、完整开发工作流

文档给出了 8 步端到端流程，核心思路是"设计 → 查证 → 实现 → 校验 → 合成 → 评审 → 部署 → 验证"：

1. 设计：规划基础设施资源及其关系；
2. 验证 AWS 服务：使用 AWS 文档 MCP 确认服务可用性与特性——检查所有必需服务的区域可用性、服务限额与配额、最新 API 规格；
3. 实现：按最佳实践编写 CDK construct——使用 CDK MCP 服务器获取 construct 推荐，通过 MCP 工具查阅 CDK 最佳实践；
4. 校验：执行上文所述部署前检查；
5. 合成：生成 CloudFormation 模板；
6. 评审：检查合成出的模板是否正确；
7. 部署：部署到目标环境；
8. 验证：确认资源创建正确。

Stack 组织建议

• 复杂应用使用嵌套 stack；
• 将关注点分离到逻辑 construct 边界；
• 导出其他 stack 可能需要的值；
• 使用 CDK context 承载环境特定配置。

测试策略

• 对单个 construct 做单元测试；
• 对 stack 合成做集成测试；
• 对 CloudFormation 模板做快照测试；
• 校验资源属性与关系。

八、MCP 服务器使用最佳实践

综合文档中两处 MCP 使用场景，可归纳为五条原则：

1. 先验证：实现新特性前总是先查 AWS 文档 MCP；
2. 区域校验：检查目标部署区域的 AWS 服务可用性；
3. CDK 指导：用 CDK 专属 MCP 获取 construct 级建议；
4. 保持最新：MCP 服务器提供超出知识截止时间的最新信息；
5. 组合信源：同时结合技能模式与 MCP 服务器，获得全面指导。

典型"先查证"场景："Lambda 是否支持 Python 3.13 运行时""eu-south-2 是否有 DynamoDB""当前 Lambda 超时上限是多少""最新 S3 加密选项有哪些"。

九、CDK 模式参考与资源清单

技能文档在"Additional Resources"一节罗列了可继续深挖的资源：

• Validation Script：scripts/validate-stack.sh——部署前校验脚本（见第六节）；
• CDK Patterns：references/cdk-patterns.md——文档称其包含常见 CDK 模式与适用场景、需要避免的反模式、安全最佳实践、成本优化策略、性能考量；
• AWS Documentation MCP：用于获取最新 AWS 信息；
• CDK MCP Server：用于 CDK 专项指导。

十、GitHub Actions 集成要求

文档强调：当仓库中存在 GitHub Actions 工作流文件时，提交前必须确保.github/workflows/中定义的所有检查通过。这能防止 CI/CD 失败并维持代码质量标准——与上文的"提交前安全网"形成 CI 侧呼应。

结语

aws-cdk-development 技能的价值在于把 AWS CDK 开发中最容易踩坑的三件事固化成了可执行规则：用 MCP 先查证 AWS 事实、让 CDK 自动生成资源名、用三层门禁在部署前拦截质量问题。配合 aws-mcp-setup 的服务器配置，以及 AAS 数据目录 中的技能元数据，开发者可以在 Agent 工作流中稳定复现"设计 → 查证 → 实现 → 校验 → 部署"的闭环，把基础设施代码的质量门槛前移到写代码的那一刻。

• AI 技能
• AI 插件
• 人工智能