使用 Kiro（以及 Amazon ECS Express Mode）构建数字徽章系统
Source: Dev.to
入门
我使用 Kiro 开发该应用。首先，我需要一种方法为部署到 Amazon ECS Express Mode 做好项目准备。
- 添加 ECS MCP Server – 当记忆模糊时，我通常会查阅文档，但现在我让 AI 编码工具来完成繁重的工作。我在 Kiro 会话中添加了 Amazon ECS MCP Server：
{
"mcpServers": {
"awslabs.ecs-mcp-server": {
"command": "uvx",
"args": ["--from", "awslabs-ecs-mcp-server", "ecs-mcp-server"]
}
}
}Application‑Readiness Evaluation
接下来，我向 Kiro 请求进行就绪检查：
Prompt: “Using the Amazon ECS MCP Server – provide me with a readiness check for deploying this application to Amazon ECS Express Mode.”
在信任了 MCP Server 工具后，Kiro 返回了一份简洁的报告。报告指出了需要更改的 三项发现。
Kiro 随后给了我一个 针对特定上下文的检查清单（IAM 策略、服务权限等），并生成了部署脚本。在审阅脚本时，我注意到一个潜在的问题：
该应用期望一个 BASE_URL（例如本地开发时的 127.0.0.1:5001）。在服务在 ECS Express 上运行之前，我不知道 DNS 名称。
我向 Kiro 请求指导：
Prompt: “I don’t know what to configure for
BASE_URLbecause I don’t have a DNS registered yet. Can you help?”
Kiro 更新了代码和部署脚本，使其能够动态处理。
部署到 Amazon ECS Express
我运行了生成的脚本。资源已被创建，服务已启动，但部署似乎卡住了。检查 CloudWatch 日志发现错误：
exec /bin/sh: exec format error问题出在哪里？我的 Mac 构建的是 基于 ARM 的容器镜像（aarch64）。脚本默认使用 amd64，导致格式不匹配。
我在 Dockerfile / 构建命令中将架构改为 aarch64。修正后，服务成功启动。
快速再次检查 API 文档，确认了此更改，部署终于成功。
要点
| 步骤 | 我学到的 |
|---|---|
| MCP 服务器集成 | 将 ECS MCP 服务器添加到 mcp.json，可让 Kiro 生成可直接部署的脚本和就绪报告。 |
| 就绪检查 | 生成的报告会提前显示缺失的 IAM 权限、环境变量以及架构不匹配。 |
| 动态配置 | 使用环境变量（例如 BASE_URL），可在运行时通过 ECS 任务定义或 AWS 参数存储解析。 |
| 架构意识 | 始终确保容器镜像的架构与目标运行时匹配（ARM 与 x86）。 |
| 迭代调试 | CloudWatch 日志对于捕获运行时错误（如 exec format error）非常宝贵。 |
使用 Amazon ECS Express 模式部署容器化应用现在对我来说是一个可重复的过程，这要归功于 Kiro 的 AI 辅助工作流。如果你正在构建类似的服务，试试 Strands Agent 和 ECS MCP 服务器——它们能为你省下大量手动工作。
Amazon ECS Express Mode – 我的体验
MCP 服务器目前能够捕获到此问题。
Amazon ECS Express Mode 在初始部署时使用 amd64 实例类型。Kiro 已经帮我处理了业务，更新了我的构建脚本以创建 amd64 镜像。
注意！ 与更了解情况的人员交流后，你 可以 在 Amazon ECS Express Mode 中使用 aarch64 实例。创建服务后，你可以修改任务定义文件（关键配置文件 –
task.json– 用于定义部署容器所需的内容），将其改为支持 AWS Graviton 实例类型。幕后实际上是由 AWS Fargate 在运行。
脚本并不完美
例如，在首次成功部署后，我第一次使用脚本更新应用时出现了以下错误：
An error occurred (InvalidParameterException) when calling the CreateExpressGatewayService operation:
Unable to Start a service that is still Draining.Kiro 能够快速调整部署脚本（原脚本每次都尝试创建相同的服务，而不是使用 update‑service 方法）。你可以查看所有代码——我在本文末尾分享了仓库链接。
我学到了什么？
-
Amazon ECS Express Mode 提供了有主见的默认设置，让您能够快速部署容器工作负载，但它仍然是 Amazon ECS。
- 您仍然可以访问传统 ECS 资源所拥有的全部功能。
- 部署后的任务（例如配置自定义域名和证书）非常简便——请参阅 advanced customization guide。
- 如有需要或想要进行更改，仍然可以编辑 task‑definition JSON 文件。
-
实例类型默认值 – 默认情况下，Express Mode 使用 amd64 而非 aarch64。
- 鉴于许多工作负载正迁移至 AWS Graviton，了解您可以通过服务创建 API 或在部署后更新集群来切换到 Graviton 实例是很有帮助的。
-
Amazon ECS MCP Server 超赞 – 它提供了我理解和使用 Express Mode 所需的一切，即使该功能当时仍然是新推出的。
结论
虽然 Kiro 在生成代码方面完成了大部分繁重工作，开发者仍然需要：
- 审查输出并发现漏洞。
- 通过提示提出正确的问题以获得明确的答案。
你的角色在交付可运行代码方面仍然至关重要。
我对 Amazon ECS Express Mode 的体验非常好——它让将应用部署到 AWS 变得简单且快速。结合 Kiro 和 Amazon ECS MCP Server，我现在拥有了一种新的默认方法来构建和部署应用。
资源
- 代码: 完整示例位于此 GitHub 仓库 – digital‑badge‑vending‑demo。
- 演示视频: 该过程的短视频可在此处观看。
- 文档: 查看 Amazon ECS Express Mode 文档。
- Kiro CLI: 免费入门 – 在此下载。
- Kiro CLI 研讨会: 对 Kiro 还不熟悉？请遵循 Kiro CLI 研讨会进行全面演练。
- 反馈: 如果本帖对您有帮助，请填写这份 30 秒的 反馈表单。我将永远感激。