Kiro×AWS 架构：能在多大程度上满足 WA？尝试使用生成式 AI 进行云设计！

在设计 AWS 架构时，是否曾为如何才能正确评估而苦恼？众多服务相互交织，不知从何处着眼才好。（至少我经常迷失方向。）

本文首先整理了一个能帮助解决此类困惑的基本设计原则及评估方法——「AWS Well-Architected Framework（以下简称 WA）」，这是刚开始接触 AWS 时必定会遇到的。

这次，我们将更进一步，尝试使用生成式 AI 工具「Kiro」来构建是否符合 WA 的架构。让我们一同看看生成式 AI 到底能在多大程度上理解并应用 WA 原则到架构中吧！

接下来的内容不会深入探讨 WA 的一般设计原则或 6 大支柱的详细内容。WA 的官方文档非常完善，想了解详情的读者请前往：【官方文档】AWS Well-Architected 框架

本文的主要内容是「能否使用生成式 AI 工具来构建符合 WA 的架构？」。我将在实际使用 Kiro 的过程中分享我的体验，并结合工具特点，一同探讨它的潜力。

虽然说不会深入细节，但也许有人会好奇 WA 到底是什么，下面简单总结一下。

WA 提供了以下在云上设计高质量架构的一般设计原则。它们可作为普遍的设计指导。（部分内容为便于理解而使用了我个人的表述。）

• 无需容量预估的架构
  是否充分利用云的弹性，只在需要时使用所需资源。
• 能以生产规模进行测试的架构
  是否能轻松准备承受实际用户负载的测试环境，提前发现生产环境的问题。
• 能通过自动化进行实验
  是否将架构以代码方式管理，能够不断重复实验和改进。
• 架构能持续进化
  是否能够根据业务需求变化灵活更新系统。
• 能进行数据驱动的决策
  是否有机制不只依赖直觉和经验，而是基于数据来判断设计优劣。
• 通过游戏日（模拟故障日期）进行演练
  是否故意制造故障，以训练团队在万一发生时的应对方式。

在此基础上，WA 由六大“支柱”构成，用于评估架构。

1. 卓越的运营：聚焦高效的运营流程和持续改进。
2. 安全性：用于提升系统安全性的措施，包括数据保护、访问管理、事件响应等。
3. 可靠性：确保在故障发生时，服务仍能正常运行的能力。
4. 性能效率：根据变化的需求高效使用资源的理念。
5. 成本优化：关注以最低成本创造最大业务价值。
6. 可持续性：从长远角度设计，尽量减少对环境的影响。

如果把 3.1 和 3.2 用图示总结的话，大概是这样的：

此外，每个支柱下都存在若干“最佳实践”。详情请参阅 【官方文档】AWS Well-Architected 框架。

我们简单整理了 WA 的概要，但看到这些内容时，会有「知道它能作为 AWS 资源构建的指导，但该如何使用？又该如何进行评估呢？」的疑问。

于是我在调查过程中发现，有一个名为“AWS Well-Architected Tool”的服务，可以用来了解已构建的 AWS 架构满足 WA 的程度，于是实际试用了它。以下简单展示了使用时的要点。

【满足支柱最佳实践的检查】

【满足支柱最佳实践的改进建议】

【满足支柱最佳实践的改进方法】

这个工具的使用流程如上图顺序所示：

• 从针对六大支柱各自最佳实践设置的问题（选项）中，选择已构建的架构是否满足这些实践
• 工具会列出需要改进的项目
• 在“推荐的改进项目”中点击所需改进项的链接
• 按照“Implementation guidance”执行改进

并对六大支柱的最佳实践逐项重复上述流程，大致就是这样。

当然，不可能完全满足所有最佳实践（以问题数量计约有 300 道），因为可能会出现“想降低成本却又想保持高可用性”这样的权衡。因此需要根据当时架构的需求灵活地进行评估。

通过在此工具上评估已在 AWS 上构建的架构，可以明确“架构在多大程度上达到 WA 标准”以及“应改进哪些项目”。

但是，使用 WA Tool 时我感到在以下几点略显不足：

• 虽然可以列出架构的改进点，但评估和改进仍需手动完成（回答问题→进行改进）
• 点击选项的操作比较繁琐

于是我四处寻找减少这些繁琐操作的方法，发现有个叫“Kiro”的工具很受关注，于是我打算使用该工具来尝试：

• “让它构建一个符合 WA 的 AWS 架构”
• “让它检查所构建的架构是否真正符合 WA”

就这样开始了实验！

简单介绍一下“Kiro”，一句话概括就是“基于规范驱动的、能提供开发支持的生成式 AI IDE”。正如 AWS 官方博客「Introducing Kiro」所介绍的，只需使用日常自然语言下达指令，它就能完成需求定义、设计以及任务列表的创建，并根据任务列表自动生成产物。（此类工具正愈发增多…）

想了解更多，可查看「Introducing Kiro」或我们公司开发者网站上发布的以下文章，即可了解 Kiro 的特点和用法！

【参考文章】
用 Kiro 进行 AI 开发革命！？从零开始构建相册应用【第1部分：需求定义·设计·实施计划】

那么，马上动手使用 Kiro 来构建满足 WA 的 AWS 架构吧。以下是我使用 Kiro 时的环境：

• 环境：Windows 11、PowerShell
• Kiro(0.2.13)：已安装并使用 Windows 版。

※如果要在 WSL2 上使用，可参考这篇文章：在 Kiro 中连接到 WSL 的方法

此次，在构建“符合 WA 的 AWS 架构”时，我指示创建一个假设用于测试的“简易任务管理应用”所需的架构。

但本文不讨论 Kiro 构建“用于运行任务管理应用的符合 WA 的 AWS 架构”的过程及所有产物（需求文档、设计文档、任务列表、代码等）和应用程序的细节。（可通过上文提到的文章了解 Kiro 构建应用的详细过程。）

本文仅聚焦于“是否能够构建符合 WA 的 AWS 架构”，对 Kiro 的行为等仅做最小限度的介绍。

通过与 Kiro 的对话，生成了如下图所示的 AWS 架构（以 CloudFormation 模板形式）。

下面简单说明 CloudFormation 模板中定义的资源及架构：
【使用的资源】

计算

• Amazon EC2：应用服务器（Auto Scaling 组）
• Application Load Balancer (ALB)：负载均衡和 HTTPS 终端
• Auto Scaling：按需自动伸缩

网络

• Amazon VPC：私有网络环境
• 子网：划分为公共、私有及数据库子网
• NAT Gateway：私有子网的互联网访问
• Internet Gateway：公共子网的互联网连接

数据库

• Amazon RDS (PostgreSQL)：Multi-AZ 架构的托管数据库
• RDS Parameter Group：数据库设置优化
• RDS Subnet Group：数据库专用子网

安全

• AWS KMS：用于数据库加密的密钥管理
• Security Groups：网络级防火墙
• IAM Roles：基于最小权限原则的访问控制

监控与日志

• Amazon CloudWatch：指标监控与告警
• CloudWatch Logs：应用与系统日志
• CloudWatch Dashboard：集成监控仪表板
• Amazon SNS：告警通知

【关于架构】

高可用性设计

• Multi-AZ 架构：将资源分布在两个可用区
• 冗余：ALB、NAT Gateway、RDS 均支持 Multi-AZ
• 自动恢复：通过 Auto Scaling 组自动替换故障实例

安全设计

• 网络隔离：在 VPC 内分离公共/私有/数据库子网
• 加密：对 RDS、EBS、S3 的静态存储进行加密
• 访问控制：通过 IAM 角色和安全组实现最小权限访问
• HTTPS 通信：在 ALB 上进行 SSL/TLS 终止（证书另行配置）

大致就是这样。

# 指示
・想在 AWS 上构建 disire-app.md 中所述的应用程序。
・请尽量满足 well-arch.md 中定义的视角来定义架构。

# 条件
・无需满足 well-arch.md 中的所有视角。
・所创建的应用程序和架构应为最小配置。

上述指令中提到的“well-arch.md”是整理 WA 评估视角的文档。

# AWS Well-Architected 框架概览

## 1. 一般设计原则
设计和运维系统时重要的六大思路。

* **无需进行容量预测**：设计时应利用云的弹性，在需要时动态增减资源。
* **以与生产相同的规模进行测试**：轻松构建与生产环境等效的测试环境，以降低风险并节省成本进行验证。
* **通过自动化尝试各种架构**：将基础设施和配置以代码管理，并自动化，以快速且安全地尝试各种设计。
* **考虑持续进化的设计**：构建一个能持续改进、适应不断变化的业务和技术的灵活系统。
* **基于数据进行判断**：不要凭感觉，而是根据系统提供的具体数据（性能、成本等）来决定改进方案。
* **通过“游戏日”进行演练和改进**：定期进行模拟故障训练，以在实际问题发生时迅速响应。

---

## 2. 六大支柱与最佳实践
AWS Well-Architected 框架基于以下六大支柱来评估和改进系统质量。

### ① 运营卓越（Operational Excellence）
高效运行系统并持续改进的能力。

* **组织**：构建团队成员理解共同目标并协同工作的体系。
* **准备**：制定问题发生时的应对计划，并通过演练提升团队准备度。
* **运行**：优化日常运营，构建能快速应对问题的机制。
* **演进**：根据运营中获得的经验教训，持续改进系统和流程。

---

### ② 安全性（Security）
保护数据和系统免受威胁，并增强安全性的能力。

* **身份与访问管理**：通过严格的访问控制管理谁可以访问何种资源。
* **检测**：利用日志和指标持续监控可疑活动并快速检测。
* **基础设施保护**：对网络、服务器等基础设施进行多层保护。
* **数据保护**：通过数据分类、加密和备份保护重要信息。
* **事件响应**：在安全问题发生时，预先准备响应流程，将损失降到最低。
* **应用安全**：在应用开发的所有阶段嵌入安全措施。

---

### ③ 可靠性（Reliability）
系统能够持续按预期一致运行的能力。

* **基础设施**：适当管理服务配额，构建稳定的系统基础。
* **工作负载架构**：通过微服务等设计，使单个故障不影响整体系统。
* **变更管理**：自动化系统更改，将影响降到最低，并能快速回滚。
* **故障管理**：假设故障会发生，执行自动恢复和定期备份测试。

---

### ④ 性能效率（Performance Efficiency）
高效利用云资源，满足系统性能需求的能力。

* **架构选择**：为工作负载选择最佳资源和设计方法，最大化性能。
* **计算与硬件**：选择最适合应用特性的计算服务。
* **数据管理**：根据数据类型和访问模式选择高效的管理方式。
* **网络与内容分发**：利用网络配置和 CDN 提升响应速度。
* **流程与文化**：在团队中培养持续改进性能的文化。

---

### ⑤ 成本优化（Cost Optimization）
以最低成本运行系统，实现最大业务价值的能力。

* **实践云财务管理**：建立管理成本的团队和流程。
* **识别费用支出和使用情况**：清晰可视化成本，发现浪费。
* **高性价比资源**：根据定价模式（按需、预留等）选择最优资源。
* **根据需求管理资源供给**：按需求自动增减资源，消除浪费。
* **持续优化**：定期审视新技术和服务，改进成本效率。

---

### ⑥ 可持续性（Sustainability）
将能源消耗降到最低，并持续改善对环境的影响的能力。

* **区域选择**：根据环境影响选择服务提供区域。
* **按需调整**：仅在需要时运行资源，减少能耗。
* **软件与架构**：通过设计和编程降低功耗。
* **数据管理**：选择高效的数据存储方式，删除不必要的数据。
* **硬件与服务**：利用高效设备和托管服务。
* **流程与文化**：在团队中建立环保运维文化。

本文不涉及“desire-app.md”。大致来说，拟创建的任务管理应用基于 Flask 以及 HTML/CSS、JavaScript 实现。下面仅以图片展示其大致交互效果。

首页

添加任务

任务列表

根据6.2中所述的内容，已成功创建了用于运行符合 WA 的任务管理应用的 AWS 架构。下面整理为检查该架构“是否真正符合 WA 评估视角”而进行的操作。

1. 根据“well-arch.md”生成检查清单

   初始检查清单（点击展开）

   AWS Well-Architected Framework 检查清单
    1. 运营卓越（Operational Excellence）
    组织
    [ ] 构建团队成员理解共同目标并协同工作的体系
    [ ] 明确运营责任
    准备
    [ ] 制定问题发生时的应对计划
    [ ] 通过演练提升团队的准备度
    [ ] 实施 Infrastructure as Code
    [ ] 通过自动化进行设计试验
    运行
    ・・・
   

2. 因包含不在“well-arch.md”中记载的内容而进行修正
   <修正方向>

   • 不添加原文（“well-arch.md”）中不存在的项目
   • 避免评估范围混淆，不包含 CloudFormation 无法评估的组织与文化项目
   • 不基于“well-arch.md”，而是直接生成满足六大支柱各自最佳实践的问题列表
   • 如下示例
   问题列表示例（点击展开）

   （示例）成本优化
   
    - 高性价比资源
      - COST 5. 在选择服务时，如何评估成本？
        [ ] COST05-BP01 确定组织的成本需求
        [ ] COST05-BP02 分析工作负载的所有组件
        [ ] COST05-BP03 对各组件进行详细分析
        [ ] COST05-BP04 选择提供高成本效率许可的软件
        [ ] COST05-BP05 根据组织的优先级选择此工作负载的组件以优化成本
        [ ] COST05-BP06 对不同使用量执行时间序列成本分析
   

3. 完成的“检查清单”

   检查清单（点击展开）

   # AWS Well-Architected 框架 检查清单
   ## CloudFormation 模板技术评估项目
   
   ---
   
   ## 运营卓越（Operational Excellence）
   
   ### 准备
   - OPS 4. 如何将可观测性（Observability）实现到工作负载中？
     - [ ] OPS04-BP01 确定关键绩效指标
     - [ ] OPS04-BP02 实现应用遥测
     - [ ] OPS04-BP04 实现依赖关系遥测
     - [ ] OPS04-BP05 实现分布式追踪
   
   - OPS 5. 如何减少缺陷、简化修复并改进生产环境流程？
     - [ ] OPS05-BP01 使用版本管理
     - [ ] ・・・
   

4. 评估情况

   实际评估情况（点击展开）

   ## 安全性
   
   ### 安全基础
   - SEC 1. 如何安全地运行工作负载？
     - [○] SEC01-BP01 使用独立账户分隔工作负载 - 实现 VPC 和子网隔离
     - [○] SEC01-BP06 自动化部署标准安全控制 - 安全组、IAM 角色自动化
   
   ### 身份与访问管理
   - SEC 2. 如何管理人机身份验证？
     - [○] SEC02-BP02 使用临时凭证 - 使用 IAM 角色和实例配置文件
     - [×] SEC02-BP03 安全存储并使用密钥 - 未使用 Secrets Manager（直接在参数中指定）
   
   …
   
   ## 综合评估
   
   | 支柱 | 评估 | 百分比 |
   |---|---|---|
   | 运营卓越 | 11/12 | 92% |
   | 安全性 | 12/14 | 86% |
   | 可靠性 | 18/19 | 95% |
   | 性能效率 | 10/10 | 100% |
   | 成本优化 | 10/15 | 67% |
   | 可持续性 | 10/10 | 100% |
   
   **综合评估：71/80 (89%)**
   
   ## 主要改进点
   
   ### 高优先级
   1. **SEC02-BP03** - 使用 AWS Secrets Manager 管理凭证
   2. **COST02-BP05** - 使用 AWS Budgets 控制成本
   3. **COST03-BP05** - 使用 Cost Explorer 监控成本
   
   ### 中优先级
   4. **OPS04-BP05** - 使用 AWS X-Ray 进行分布式追踪
   5. **SEC06-BP01** - 使用 Amazon Inspector 进行漏洞管理
   6. **REL01-BP04** - Service Quotas 监控
   
   ### 低优先级
   7. **COST07-BP02** - 优化区域选择
   8. **COST08-BP03** - 使用 CloudFront 实现 CDN
   

在6.3 中整理了让 Kiro 检查生成的 AWS 架构是否满足 WA 评估视角的流程。有些环节需要一定技巧，但总体上我感觉“通过生成式 AI 构建满足 WA 的 AWS 架构”是可行的。

相比在管理控制台上使用 AWS WA Tool，可省去手动检查工作，负担应该会大幅减少。

另外，虽然这次未进行，但若利用检查时报出的“改进点”来作为提示指令，就能轻松地自动改进 CloudFormation 模板。我觉得这一点也优于管理控制台上的 AWS WA Tool。

不过，由于仍需事先整理官方文档中的问题内容，以及在提示中设定条件等，这方面还存在一定难度，因此完全自动化似乎还需要攻克更多障碍。※官方文档中列出的满足最佳实践的问题内容整理，一定程度上也让生成式 AI 来执行了。

本文介绍了如何使用 AWS Well-Architected Framework 对架构进行评估，以及利用生成式 AI 工具“Kiro”进行架构生成和基于 WA 的评估。Kiro 能够理解 WA 的最佳实践并生成相应架构的事实，强烈暗示了生成式 AI 在未来云设计中的潜力。

不过，虽然本文未介绍任务管理应用的开发过程，但实际情况并非代码运行时毫无错误；在 WA 评估方面，Kiro 起初也会混入自己的评估，因此完全将一切交给 Kiro 还是比较困难的，使用者需要具备开发技能和对 AWS 的理解才能使用好它。

从这个角度看，Kiro 仅能作为支持设计过程（需求定义、设计、拆解构建任务）的工具，或如同导师般提供洞见；要完全托管从设计到开发与评估的全过程，它仍不够完善。

虽然它不够完善，但其性能已经足以提升设计过程及开发与评估的效率，因此正确理解其“使用方式”并加以利用，或许是目前的最佳折中方案。通过与生成式 AI 的适当对话，可以更快速地生成高质量的需求定义和架构，我也会不断跟进相关领域，保持学习。

今后，我将进一步探索如何更高效地构建“满足 WA 的通用 AWS 架构”以及如何对其进行运维！感谢您的阅读。