用 Claude Code 搭建 AWS ECS 多服务开发环境：从 Terraform 模板到 CodePipeline

为一个包含多个 ECS 服务的 AWS 环境编写 Terraform、配置 CodePipeline、起草设计文档，是典型的「重复劳动 + 查资料」型工作：九个服务的配置结构高度相似，但每个服务的命名、标签、网络与负载均衡细节又各不相同。Claude Code 适合承担这类工作的初稿生成与资料整理，把工程师从逐行敲代码中解放出来，转而做审阅与决策。这篇教程讲的就是如何把 Claude Code 放进这样一条工作流里：先准备模板，再让 Claude Code 按模板批量产出，最后把设计理由留档。如果你还没安装，可以先看 Claude Code 的工具页了解基本形态。

需要说明的是，本文讨论的是一套工作方法，而不是某个固定版本的界面操作。Claude Code 的安装方式、可用模型、计费与配额会随时间变化，动手前请以官网当前信息为准。

这套方法适合谁

适合的场景有明确特征：基础设施即代码（IaC）已经选定 Terraform，云上资源以容器服务为主，服务数量在几个到十几个之间，且这些服务的配置存在大量可复用的共性。素材中的环境构成是：云平台为 AWS，容器编排用 ECS 并承载九个服务，计算层是三种规格的 EC2，入口层同时使用 ALB 与 NLB，持续交付走 AWS CodePipeline，基础设施全部用 Terraform 描述。

不适合的场景同样明确：如果只有一个服务、配置量很小，准备模板与写提示词的成本可能超过直接手写的成本；如果团队对 Terraform 的目录结构、模块划分还没有共识，让 Claude Code 先产出代码只会把分歧固化进代码里。换句话说，这套方法放大的是已有的规范，而不是替你建立规范。

准备工作

明确人机分工

在动手之前先把边界写下来，这是整套流程里最容易被跳过、却最影响结果的一步。素材采用的分工是：信息由 AI 收集，判断由人做，作业由 AI 执行。具体落到三条：

• 采用什么架构、什么设计，由人根据 AI 收集到的资料决定；
• 是否推进到下一步，由人判断之后再交给 AI；
• 代码、配置、文档初稿的产出交给 AI。

把这三条写在项目说明里，后续每次对话都以此为准，可以避免 Claude Code 在架构层面自作主张，也能避免人把本该自己拍板的事推给模型。

准备 Terraform 代码模板

模板是提速的核心。它不需要是一个完整的可运行模块，但必须把团队约定固化进去，至少包含以下几类内容：

• 命名规则：资源名、变量名、输出名的拼接方式，服务名在名称中的位置，环境前缀如何体现。
• 标签规范：必填标签的键名与取值来源，例如项目、环境、负责人、成本归属等字段如何填写。
• 通用写法：变量声明与校验的写法、输出值的组织方式、模块调用的参数顺序、provider 与 backend 的声明位置。
• 目录结构：每个服务对应哪个目录，共享资源放在哪里，环境之间如何隔离。

模板越具体，Claude Code 产出的代码形态越统一，后续审阅时也越容易发现偏差。素材里九个 ECS 服务、三种 EC2、ALB 与 NLB 的配置，都是在这个模板的基础上扩展出来的。

准备流水线流程图

CodePipeline 的阶段划分、源阶段与构建阶段的衔接、部署动作的顺序，用文字描述很容易产生歧义。更可靠的做法是先用 draw.io 画一张流程图，把「代码从哪来、经过哪些阶段、部署到哪里」画清楚，再把这张图交给 Claude Code，让它按图生成流水线配置。图比文字更能锁定意图，减少来回澄清。

确认访问与权限

Claude Code 需要在本地项目目录中读写文件，因此要确认它运行的位置就是 Terraform 代码所在的仓库根目录或其子目录。涉及 AWS 资源的实际操作（例如 plan、apply、查看流水线状态）仍由人执行，Claude Code 负责生成与修改代码，不代替你执行变更。凭证、密钥、账号信息不要写进提示词，也不要提交进仓库。

操作步骤

第一步：把模板与规范交给 Claude Code

先让 Claude Code 读取模板文件，再提出生成请求。提示词里要明确三件事：参照哪个模板、生成哪些资源、遵循哪些约定。例如可以这样组织：

请先阅读以下文件，理解我们的 Terraform 写法约定：
- modules/service-template/main.tf
- modules/service-template/variables.tf
- docs/naming-convention.md
- docs/tagging-policy.md

然后按同样的结构，为以下服务生成 Terraform 配置：
- 服务名：order-api，容器端口 8080，需要 ALB 入口
- 服务名：payment-worker，无对外入口，仅内部调用

要求：
1. 命名与标签严格遵循上述文档；
2. 变量必须带 description 与 type；
3. 不要引入模板中未出现的 provider 或模块；
4. 生成后列出你不确定的地方，不要自行假设。

最后一条要求很关键。让模型主动暴露不确定点，比让它悄悄补全一个看似合理的默认值要安全得多。

第二步：分批生成，逐批审阅

九个服务不要一次性全部生成。按服务分组，每批两到三个，生成后立刻审阅，确认命名、标签、变量、依赖关系都符合预期，再进入下一批。这样做的原因是：如果模板理解有偏差，第一批就能发现，避免同样的错误复制九遍。

审阅时重点看这几处：

• 资源名是否与命名规则一致，有没有出现模板之外的命名风格；
• 标签是否齐全，取值是否来自正确的变量而不是硬编码；
• 服务之间的依赖是否显式声明，有没有依赖隐式顺序的写法；
• 网络与负载均衡配置是否与该服务的入口需求匹配。

发现问题时，不要直接手改完事，而是把问题反馈给 Claude Code，让它按同一规则修正全部相关文件。这样规则才是一致的，而不是只在你改过的那一处生效。

第三步：用流程图生成 CodePipeline 配置

把 draw.io 导出的图（或图的文件路径）交给 Claude Code，并说明每个阶段对应的 AWS 资源。提示词可以写成：

这是我们的 CI/CD 流程图：docs/pipeline-flow.drawio
请按图中的阶段顺序，生成 AWS CodePipeline 的 Terraform 配置。

约束：
- 源阶段使用代码仓库触发；
- 构建阶段产出容器镜像；
- 部署阶段按图中顺序更新 ECS 服务；
- 阶段名与图中保持一致，便于对照；
- 每个阶段完成后输出该阶段的作用说明。

生成之后，把配置里的阶段顺序与图逐一对照。图是判断依据，代码是产出，两者不一致时以图为准，让 Claude Code 调整代码。

第四步：起草设计文档

设计文档不要从空白页开始。让 Claude Code 基于已经生成的 Terraform 代码与流水线配置，先产出一份结构化的初稿，再由人补充与修正。初稿至少应覆盖：

• 整体架构：各服务职责、入口层如何分流、计算资源如何划分；
• 网络设计：子网划分、负载均衡器与服务的对应关系；
• 部署流程：流水线各阶段做什么、失败时如何回退；
• 关键取舍：为什么这样划分服务、为什么选择这种实例规格组合。

有初稿之后再改，比从零写要快得多。但要注意，初稿里的架构描述必须与代码一致，凡是代码里没有体现的内容，都要人补上或删掉。

第五步：让 Claude Code 记录设计背景

这是整套流程里最容易被忽略、事后最有用的一步。每当你和 Claude Code 讨论并确定了一个设计选择，就让它把「选了什么、为什么选、放弃了什么方案」写进一份决策记录文件。可以约定一个固定格式：

## 决策：ECS 服务按业务域拆分而非按技术层拆分

- 日期：
- 背景：九个服务之间存在调用关系，需要独立扩缩容
- 选择：按业务域拆分为独立 ECS 服务
- 放弃的方案：单体服务内多容器
- 影响：服务数量增加，但扩缩容与故障隔离更清晰

决策记录与代码放在同一个仓库里，随代码一起演进。后续任何人（包括几个月后的你自己）想知道某个设计为什么是这样，先查这份记录，而不是去翻聊天历史。

一个完整示例

下面用一个最小场景把上述步骤串起来：为两个服务生成 Terraform 配置、接入流水线、留下决策记录。

场景：已有服务模板目录 modules/service-template/，已有命名与标签规范文档，需要新增 order-api（对外，走 ALB）与 payment-worker（内部，无入口）两个 ECS 服务。

第一步，读取模板并生成第一批：

请阅读 modules/service-template/ 下的全部文件，以及 docs/naming-convention.md、
docs/tagging-policy.md。

然后为 order-api 生成 Terraform 配置：
- 容器端口 8080
- 需要 ALB 入口，健康检查路径 /health
- 实例规格沿用模板中的默认值

输出到 services/order-api/ 目录，结构参照模板。
生成完成后，列出所有你不确定或需要我确认的点。

第二步，审阅并反馈：检查生成的资源名、标签、变量声明。若发现标签里缺少成本归属字段，不要手改，直接反馈：

services/order-api/ 下的资源缺少 tagging-policy.md 中要求的 cost-center 标签。
请按规范补全，并检查同一目录下其他资源是否也有同样问题。

第三步，生成第二个服务：

参照 services/order-api/ 的结构，为 payment-worker 生成配置：
- 无对外入口，不创建负载均衡相关资源
- 仅允许来自 order-api 所在安全组的入站流量
- 其余约定与 order-api 保持一致

第四步，生成流水线：把流程图交给 Claude Code，要求按图生成 CodePipeline 配置，阶段名与图一致，并逐个阶段说明作用。生成后对照图检查阶段顺序与部署目标。

第五步，写决策记录：把这一轮确定下来的关键选择写进 docs/decisions.md，例如「payment-worker 不暴露入口，仅接受来自 order-api 安全组的流量」，并写明这样做的原因（减少攻击面、调用关系单一）。

第六步，人工执行变更：在本地运行 Terraform 的格式化与校验命令，确认无误后由人执行 plan 与 apply。Claude Code 只负责产出代码，不代替人做变更决策。

terraform fmt -recursive
terraform validate
terraform plan -out=tfplan

审阅 plan 输出，确认新增资源与预期一致，再执行 apply。流水线配置生效后，观察一次完整的构建与部署，确认阶段顺序与图中一致。

注意事项

设计理由会随时间丢失

这套流程里最容易出问题的地方，不是代码写错，而是过一段时间之后想不起来「当初为什么这么设计」。把工作交给 AI 之后，人对细节的记忆会更模糊，因为代码不是自己一行行敲出来的。解决办法只有一个：在做出决定的当下，就让 Claude Code 把理由一起记录下来，而不是事后回忆。决策记录要写清背景、选择、放弃的方案与影响，只写结论没有价值。

模板质量决定产出质量

模板里的约定越含糊，Claude Code 自由发挥的空间越大，九个服务之间的差异就越多。反过来，模板越具体，产出越整齐，审阅成本越低。如果发现生成结果反复出现同类偏差，说明模板本身需要补充，而不是每次都靠提示词纠正。

不要让模型替你做架构判断

Claude Code 可以快速收集某个 AWS 服务的用法、参数含义、常见组合，但「这个系统应该怎么划分服务、怎么设计网络」属于需要结合业务与团队现状的判断，必须由人来做。把判断权交出去，短期看省事，长期会得到一个没人能解释清楚来龙去脉的架构。

分批生成，及时纠偏

一次性生成大量配置，错误会成倍复制。按服务分批、每批审阅，是控制风险的基本做法。审阅发现的问题要回到提示词层面统一修正，而不是逐个文件手改，否则规范会在代码里逐渐失真。

易变信息以官网为准

Claude Code 的安装方式、可用模型、计费方式与使用配额，以及 AWS 各服务的规格、区域可用性与定价，都会变化。本文不给出具体数字，涉及这些内容时请查阅官网当前信息。生成的基础设施代码在正式应用前，务必经过 plan 审阅与团队评审。