本文记录了一次真实的AI辅助开发过程：如何使用Kiro AI IDE从一个模糊的部署需求开始，通过人机协作，逐步设计出三层堆栈架构，并完成基于Amazon EMR Flink智能监控系统的Amazon CDK部署代码。

开发成果：

• 开发时间：从10小时缩短到1.5小时，效率提升6-7倍

• 代码质量：自动应用亚马逊云科技最佳实践

• 架构演进：从单堆栈到三层堆栈的优化过程

项目地址：

https://github.com/yangguangfu007/emr-flink-monitoring-agent

背景：什么是Amazon CDK和Kiro？

Amazon CDK简介

Amazon Cloud Development Kit（CDK）是使用编程语言定义云基础设施的框架：

• 使用Python、TypeScript等语言，而非JSON/YAML

• 代码复用和模块化

• IDE支持（代码补全、类型检查）

• 通过Amazon CloudFormation部署

Kiro简介

Kiro是亚马逊云科技推出的AI辅助开发工具：

• 理解自然语言需求，生成CDK代码

• 基于Spec文档驱动开发

• 理解亚马逊云科技服务依赖关系

• 通过对话迭代优化架构设计

起点：一个模糊的部署需求

初始需求

开发者只有一个简单的想法：

“我想把基于Amazon EMR Flink的监控系统部署到亚马逊云科技环境”

具体细节都不清楚：

• 用什么服务部署后端？Amazon ECS还是Amazon Lambda？

• 前端怎么托管？Amazon S3还是也用容器？

• 网络架构怎么设计？

• 安全组怎么配置？

第1步：与Kiro对话

用户：我想把Amazon EMR Flink监控系统部署到亚马逊云科技，后端是FastAPI，前端是React。你有什么建议？

Kiro：我理解你的需求。让我帮你分析一下：

后端部署选项：

• Amazon Fargate：推荐，无需管理服务器，按需付费

• Amazon Lambda：适合轻量级API，但有15分钟超时限制

• Amazon EC2：需要管理服务器，成本较高

前端部署选项：

• Amazon S3+Amazon CloudFront：推荐，静态托管，全球CDN

• Amazon Amplify Hosting：简单但灵活性较低

建议架构：

• 前端：Amazon CloudFront+Amazon S3

• 后端：Application Load Balancer（ALB）+Amazon Fargate

• 认证：Amazon Cognito User Pool

Kiro：我可以帮你用CDK实现这个架构。要不要先创建一个Spec文档？

第2步：创建Spec文档

根据Kiro的建议，用户创建了Spec文档来明确需求。

用户：帮我创建Spec文档结构。

Kiro帮用户在.kiro/specs/cloudfront-alb-ecs-deployment/创建了三个文档：

1.requirements.md：部署需求

2.design.md：架构设计

3.tasks.md：任务分解

使用Kiro开发CDK代码

第一版：单堆栈实现

用户：基于Spec，帮我实现CDK部署代码。

Kiro：开始实现…

Kiro生成了第一版代码，所有资源都在一个Stack中：

class FlinkMonitorStack(Stack):    def __init__(self, scope, id, **kwargs):        super().__init__(scope, id, **kwargs)                # VPC、子网、安全组        # Application Load Balancer(ALB)、Target Group        # Amazon ECS Cluster、AWS Fargate Service        # Amazon S3、Amazon CloudFront        # Amazon Cognito        # ... 所有资源都在这里

左右滑动查看完整示意

问题：代码超过500行，难以维护，部署时间长。

与Kiro探讨：如何优化架构？

用户：这个Stack太大了，有没有更好的组织方式？

Kiro：你说得对。我建议采用多堆栈架构：

方案一：按资源类型分离

• NetworkStack：VPC、子网、安全组

• ComputeStack：Amazon ECS、Amazon Fargate

• StorageStack：Amazon S3、Amazon CloudFront

• AuthStack：Amazon Cognito

方案二：按部署频率分离（推荐）

• InfrastructureStack：基础设施（很少变更）

• BackendStack：后端应用（经常更新）

• FrontendStack：前端应用（经常更新）

方案二的优势：

• 更新前端不影响后端

• 更新后端不影响基础设施

• 部署更快（只部署变更的堆栈）

• 职责清晰

Kiro：你觉得哪个方案更适合？

用户：方案二看起来更合理。但是堆栈之间怎么共享资源？

Kiro：通过Amazon CloudFormation Outputs和Fn.importValue：

# InfrastructureStack 导出CfnOutput(self, "VPCId",    value=vpc.vpc_id,    export_name="FlinkMonitor-VPC-Id")
# BackendStack 导入vpc_id = Fn.import_value("FlinkMonitor-VPC-Id")

左右滑动查看完整示意

这样可以实现堆栈间的松耦合。

三层堆栈架构

基于讨论，Kiro重构了代码为三层堆栈。

用户：请按照三层堆栈重构代码。

Kiro：正在重构…

1.InfrastructureStack：基础设施堆栈

Kiro生成了基础设施堆栈代码：

代码类内容使class InfrastructureStack(Stack):    def __init__(self, scope, id, **kwargs):        super().__init__(scope, id, **kwargs)                # 网络资源        self._create_network_resources()                # 安全组        self._create_security_groups()                # 负载均衡        self._create_load_balancer()                # 前端基础设施        self._create_frontend_infrastructure()                # 认证服务        self._create_cognito()用

左右滑动查看完整示意

关键对话：Amazon ECS安全组

应该在哪里创建？

用户：Amazon ECS安全组应该在InfrastructureStack还是BackendStack？

Kiro：建议在InfrastructureStack中创建，原因如下：

• 安全组是基础设施，不依赖Amazon ECS服务

• 可以在部署后端前就配置Amazon EMR安全组

• 避免循环依赖

• 符合IaC最佳实践

实现：

• InfrastructureStack创建Amazon ECS安全组

• 导出安全组ID

• BackendStack导入并使用

2.BackendStack：后端应用堆栈

Kiro生成了后端堆栈代码：

class BackendStack(Stack):    def __init__(self, scope, id, **kwargs):        super().__init__(scope, id, **kwargs)                # 导入基础设施资源        vpc_id = Fn.import_value("FlinkMonitor-VPC-Id")        ecs_sg_id = Fn.import_value("FlinkMonitor-ECS-SecurityGroup")                # Amazon ECS Cluster        # Task Definition        # AWS Fargate Service

左右滑动查看完整示意

3.FrontendStack：前端应用堆栈

Kiro生成了前端堆栈代码：

class FrontendStack(Stack):    def __init__(self, scope, id, **kwargs):        super().__init__(scope, id, **kwargs)                # 导入 Amazon S3 和 Amazon CloudFront        bucket_name = Fn.import_value("FlinkMonitor-Frontend-Bucket")                # 构建前端        # 部署到 Amazon S3        # 失效 Amazon CloudFront 缓存

左右滑动查看完整示意

迭代优化：解决实际问题

在实际部署中遇到了一些问题，Kiro帮助逐一解决。

问题1：子网CIDR冲突

用户：部署失败，提示子网CIDR与EMR冲突。

Kiro：我来帮你计算可用的CIDR：

• 查询Amazon EMR集群的子网CIDR

• 找到Amazon VPC中未使用的CIDR范围

• 更新cdk.json配置

已生成脚本：scripts/calculate_subnet_cidr.py

问题2：Amazon EMR安全组配置时机

用户：什么时候配置Amazon EMR安全组？

Kiro：建议在BackendStack部署后、测试前配置：

步骤4.5：配置Amazon EMR安全组

• Amazon ECS安全组已在步骤1创建

• 不依赖Amazon ECS服务（只需要安全组ID）

• 避免循环依赖

已生成脚本：

scripts/configure_emr_security_group.sh

问题3：前端环境变量

用户：前端怎么获取Amazon Cognito和API地址？

Kiro：通过脚本自动生成.env文件：

• 从Amazon CloudFormation Outputs读取值

• 生成frontend/.env

• 前端构建时注入环境变量

已生成脚本：

scripts/generate_frontend_env.sh

最终架构：三层堆栈设计

经过与Kiro的多轮对话和迭代，最终形成了清晰的三层堆栈架构。

架构图

完整部署架构图如下所示。

三层堆栈架构图如下所示。

设计原则

1.职责分离：每个堆栈负责特定的资源类型

2.依赖清晰：后端和前端依赖基础设施

3.独立部署：可以单独更新某个堆栈

4.资源共享：通过Amazon CloudFormation输出共享资源

InfrastructureStack核心资源

网络资源

Amazon VPC集成：自动发现Amazon EMR集群所在的Amazon VPC

子网创建：

• 公有子网×2（跨2个AZ）：Application Load Balancer（ALB）+Amazon NAT Gateway

• 私有子网×2（跨2个AZ）：Amazon Fargate任务

路由表：

• 公有路由表→Amazon Internet Gateway

• 私有路由表×2→Amazon NAT Gateway（每个AZ一个）

安全资源

安全组：

• Application Load Balancer（ALB）安全组：允许HTTP/HTTPS入站

• Amazon ECS安全组：允许来自Application Load Balancer（ALB）的流量（端口8080）

Amazon IAM角色：

• Task Role：应用权限（Amazon Bedrock、Amazon EMR、Amazon EC2）

• Execution Role：Amazon ECS基础操作权限

负载均衡

Application Load Balancer（ALB）：

• 公网访问（internet-facing）

• 跨2个AZ部署

• HTTP监听器（端口80）

Target Group：

• 目标类型：IP（Amazon Fargate）

• 健康检查：/api/health端点

前端基础设施

Amazon S3Bucket：

• 私有访问（通过Amazon CloudFront OAC）

• 阻止所有公共访问

Amazon CloudFront Distribution：

• 全球CDN加速

• HTTPS强制重定向

• 路由规则：

• /*→Amazon S3（前端静态文件）

• /api/*→Application Load Balancer（ALB）（后端API）

认证服务

Amazon Cognito User Pool：

• 用户名+邮箱登录

• 密码策略（8位，大小写+数字）

Amazon Cognito User Pool Client：

• OAuth 2.0授权码流

• 回调URL：Amazon CloudFront+localhost

BackendStack核心资源

Amazon Fargate服务

Task Definition：

• CPU：1024（1 vCPU）

• 内存：2048 MB（2 GB）

• 架构：ARM64（成本优化）

• 容器镜像：从Amazon ECR拉取

• 环境变量：AWS_DEFAULT_REGION、EMR_CLUSTER_ID

• 健康检查：curl /api/health

Amazon Fargate Service：

• 期望任务数：1（可配置）

• 部署在私有子网

• 使用步骤1创建的Amazon ECS安全组

• 关联到Application Load Balancer（ALB）Target Group

• 部署配置：

• 最大百分比：200%

• 最小健康百分比：100%

• 启用断路器和自动回滚

Amazon CloudWatch Logs：

• 日志组：/ecs/flink-monitor

• 保留天数：7天

• 日志流前缀：ecs

FrontendStack核心资源

部署流程

1.检查构建目录：frontend/dist

2.上传到Amazon S3：使用BucketDeployment

3.Amazon CloudFront失效：自动失效缓存 (/*)

4.清理旧文件：prune=True

部署成果展示

Amazon CloudFormation堆栈

系统访问成功

监控仪表盘

架构优势

1.模块化

每个堆栈职责清晰

易于理解和维护

代码复用性高

2.独立部署

前端更新不影响后端

后端更新不影响基础设施

加快部署速度

3.安全隔离

基础设施变更需要明确操作

降低误操作风险

便于权限管理

4.成本优化

仅部署需要更新的堆栈

减少Amazon CloudFormation API调用

节省部署时间

基于Kiro的开发心得

Spec驱动开发的价值

传统方式：直接写代码，边写边想架构

Kiro方式：先写Spec，明确需求和设计，再生成代码

优势：

• 需求清晰，减少返工

• 设计文档自动生成

• 便于团队协作和Code Review

对话式架构演进

关键发现：最好的架构不是一次设计出来的，而是通过对话逐步优化的。

经验：

• 第一版：单堆栈（简单但难维护）

• 与Kiro讨论后：三层堆栈（模块化、可维护）

• 遇到问题时：Kiro提供多个方案，选择最适合的

AI辅助的最佳实践

Kiro自动应用的最佳实践：

• 安全组最小权限原则

• 跨AZ高可用部署

• 私有子网+Amazon NAT Gateway

• Amazon CloudFront OAC而非OAI

• Amazon ECS断路器和自动回滚

收获：不仅得到了代码，还学到了亚马逊云科技最佳实践。

效率提升的关键

时间对比：

• 传统开发：10小时（查文档、写代码、调试）

• Kiro辅助：1.5小时（对话、Review、微调）

效率提升的原因：

• 减少查文档时间：Kiro知道所有API

• 减少调试时间：生成的代码质量高

• 减少重构时间：架构设计合理

人机协作的模式

最佳实践：

• 人：提供需求、做决策、Review代码

• AI：生成代码、提供方案、应用最佳实践

不要：

• 完全依赖AI：需要理解生成的核心代码和流程

• 完全不用AI：错过效率提升机会

持续学习

意外收获：

• 学会了三层堆栈架构模式

• 理解了Amazon CloudFormation Outputs的用法

• 掌握了Amazon Fargate的最佳实践

• 了解了Amazon CloudFront的高级配置

建议：把Kiro当作学习工具，不仅要用它生成代码，还要理解为什么这样设计。

总结

通过Kiro AI辅助开发Amazon CDK部署架构，可以获得：

1.效率提升：开发时间从10小时缩短到5小时

2.架构优化：从单堆栈演进到三层堆栈

3.代码质量：自动应用亚马逊云科技最佳实践

4.知识积累：学习了云架构设计模式

核心体会：

• Kiro不是替代开发者，而是增强开发者

• 最好的架构来自人机协作

• Spec驱动开发提高了代码质量

• AI辅助让您专注于架构设计，而非重复劳动

下一步计划：

• 使用Kiro开发CI/CD流水线

• 探索Kiro在多环境部署中的应用

参考资源

项目地址：

https://github.com/yangguangfu007/emr-flink-monitoring-agent

Amazon CDK文档：

https://docs.aws.amazon.com/cdk/

Kiro AI文档：

https://kiro.dev/docs/

本篇作者

杨光富

亚马逊云科技解决方案架构师，专注于帮助客户构建和优化云端架构解决方案。曾任职知名互联网大厂，拥有多年大数据平台研发和架构设计经验。目前专注于AI+Data原生解决方案的架构设计与实施。

新用户注册海外区域账户，可获得最高200美元服务抵扣金，覆盖Amazon Bedrock生成式AI相关服务。“免费计划”账户类型，确保零花费，安心试用。

星标不迷路，开发更极速！

关注后记得星标「亚马逊云开发者」

听说，点完下面4个按钮

就不会碰到bug了！

点击阅读原文查看博客！获得更详细内容！