はじめに
仮想のペルソナを通して、 Kiro に対する具体的なプロンプト入力例と、そこから導き出されたアーキテクチャの比較検討シミュレーションを共有したいと思いました。
SIer で AWS などのクラウドをバリバリ使っていない方こそ、Kiro を利用してクラウド移行を検討して欲しいと望んでいます。
ペルソナ
- 地方で観光ポータルサイトを運営するインフラ担当
- 長年、物理サーバーの運用を行ってきた
- 季節変動によるアクセス集中やハードウェア保守の限界から、AWS への移行を検討
検証の前提条件
- 既存のオンプレミス構成:
- FW アプライアンス、L2 スイッチによるネットワーク分離
- 物理ロードバランサ
- Web サーバー（Apache/PHP）×2台
- DB サーバー（MySQL Master/Slave）×2台
- 抱えている課題:
- スケーラビリティ: 繁忙期（GW・夏休み）のアクセス増に対応できない
- コスト効率: ピークに合わせてサーバーを購入しているため、閑散期の無駄が多い
- 学習コスト: AWS 固有の用語やベストプラクティスの習得に時間がかかる
この記事の結論（3行で）
忙しい方向けに、検証結果を先に共有します。
- 物理構成の単純な置き換えはNG: Kiro は「機材」の話には答えない（可能性がある）が、「仕様（要件）」には詳細に回答する。
- 生成されるドキュメントが優秀: 曖昧な要件から、要件定義書・設計書・実装タスクまで自動生成された。
- オンプレ知識は無駄じゃない: AWS 用語を知らなくても、的確な「要件」さえ伝えれば Kiro が翻訳してくれる。
Step 1: 物理構成の AWS マッピング（基本設計）
まずは既存のオンプレミス構成を、AWS 上のどのサービスに置き換えるべきかを Kiro に聞いてみました。あえてAWS の用語を使わず、物理機材の名称で聴いてみました。
しかしながら、サービス置き換えについては「設計上の制限」と回答がありませんでした。
ご質問ありがとうございます。申し訳ありませんが、ご質問の内容についてお答えできません。
私は AWS のインフラストラクチャ設計やクラウドアーキテクチャのコンサルティングについては、詳細な情報を提供することができません。これは私の設計上の制限です。
Step 2: 課題解決のための仕様変更（スケーラビリティ）
早くも検証終了かと思いましたが、想定してた Step である仕様変更を聞いてみました。
プロンプト：
課題: 観光シーズン（夏休み等）にアクセスが通常の5倍になり、現在の2台構成ではダウンする。
【要求仕様】
普段はコストを抑えるため最小構成（2台）としたい。
アクセス増検知時に、自動的にサーバー台数を拡張したい。
オンプレのように「ピークに合わせてあらかじめ10台購入しておく」ことは避けたい。
Kiro から下記の質問がありました。
- CPU使用率、メモリ使用率、リクエスト数など、どのメトリクスを監視しますか？
- 最大台数：何台までスケールアップしたいですか？
- アクセスが減った時、どのくらい待ってからサーバーを削減しますか？
- AWSのどのサービスを使いたいですか？（EC2 Auto Scaling、ECS、Lambda など）
- 現在のWebサーバーはどの言語/フレームワークですか？
すると、Kiro は下記の要件定義・設計・実装タスク（Requirements, Design, Task list）を作成してくれました。
要件定義
# 要件定義書：自動スケーリングシステム
## 概要
観光シーズンなどのアクセス増加に対応するため、EC2インスタンスの自動スケーリング機能を実装する。通常時は最小構成（2台）でコストを抑え、アクセス増加時に自動的にサーバー台数を拡張し、アクセス減少時に自動的に縮小する。
## 用語集
- **Auto Scaling Group (ASG)**: EC2インスタンスを自動管理するAWSサービス
- **CPU使用率**: インスタンスのプロセッサ使用率（パーセンテージ）
- **スケールアップ**: インスタンス数を増やす操作
- **スケールダウン**: インスタンス数を減らす操作
- **CloudWatch**: AWSの監視・ログサービス
- **スケーリングポリシー**: スケーリングを実行するルール
## 要件
### 要件1：最小・最大インスタンス数の管理
**ユーザーストーリー**: インフラ管理者として、コストと可用性のバランスを取りたいので、インスタンス数の上限と下限を設定したい。
#### 受け入れ基準
1. WHEN Auto Scaling Groupが起動されたとき、THE システムは最小2台のインスタンスを常に実行する
2. WHEN スケーリングが実行されるとき、THE システムは最大5台を超えてスケールアップしない
3. WHEN インスタンスが削除されるとき、THE システムは最小2台を下回らない
_要件: 1.1, 1.2, 1.3_
---
### 要件2：CPU使用率に基づくスケールアップ
**ユーザーストーリー**: インフラ管理者として、アクセス増加に自動対応したいので、CPU使用率が高い場合に自動的にサーバーを追加したい。
#### 受け入れ基準
1. WHEN CPU使用率が70%以上の状態が1分間続いたとき、THE システムはスケールアップポリシーをトリガーする
2. WHEN スケールアップポリシーがトリガーされたとき、THE システムは1台のインスタンスを追加する
3. WHEN 複数のスケールアップポリシーが同時にトリガーされたとき、THE システムは1回のスケーリング操作で対応する
_要件: 2.1, 2.2, 2.3_
---
### 要件3：CPU使用率に基づくスケールダウン
**ユーザーストーリー**: インフラ管理者として、アクセス減少時にコストを削減したいので、CPU使用率が低い場合に自動的にサーバーを削減したい。
#### 受け入れ基準
1. WHEN CPU使用率が低い状態（30%以下）が5分間続いたとき、THE システムはスケールダウンポリシーをトリガーする
2. WHEN スケールダウンポリシーがトリガーされたとき、THE システムは1台のインスタンスを削除する
3. WHEN スケールダウンが実行されるとき、THE システムは最小2台を下回らない
_要件: 3.1, 3.2, 3.3_
---
### 要件4：スケーリングイベントの監視と記録
**ユーザーストーリー**: インフラ管理者として、スケーリングの動作を追跡したいので、すべてのスケーリングイベントをログに記録したい。
#### 受け入れ基準
1. WHEN スケールアップが実行されたとき、THE システムはイベント（タイムスタンプ、アクション、新しいインスタンス数）をCloudWatchに記録する
2. WHEN スケールダウンが実行されたとき、THE システムはイベント（タイムスタンプ、アクション、新しいインスタンス数）をCloudWatchに記録する
3. WHEN スケーリングがトリガーされなかったとき、THE システムはメトリクスデータをCloudWatchに記録する
_要件: 4.1, 4.2, 4.3_
---
### 要件5：スケーリングアクションの冷却期間
**ユーザーストーリー**: インフラ管理者として、スケーリングの過度な変動を防ぎたいので、連続したスケーリングアクション間に待機時間を設定したい。
#### 受け入れ基準
1. WHEN スケールアップが実行されたとき、THE システムは次のスケールアップまで3分間待機する
2. WHEN スケールダウンが実行されたとき、THE システムは次のスケールダウンまで5分間待機する
3. WHEN 冷却期間中にスケーリングトリガーが発生したとき、THE システムはそのトリガーを無視する
_要件: 5.1, 5.2, 5.3_
---
### 要件6：ヘルスチェックと不健全なインスタンスの置き換え
**ユーザーストーリー**: インフラ管理者として、障害インスタンスを自動復旧したいので、不健全なインスタンスを自動的に置き換えたい。
#### 受け入れ基準
1. WHEN インスタンスがELBヘルスチェックに失敗したとき、THE システムはそのインスタンスを不健全とマークする
2. WHEN インスタンスが不健全とマークされたとき、THE システムはそのインスタンスを終了し、新しいインスタンスを起動する
3. WHEN 新しいインスタンスが起動されたとき、THE システムはそのインスタンスがヘルスチェックに合格するまで待機する
_要件: 6.1, 6.2, 6.3_
---
### 要件7：スケーリング設定の管理
**ユーザーストーリー**: インフラ管理者として、スケーリングルールを柔軟に調整したいので、スケーリングポリシーのパラメータを設定可能にしたい。
#### 受け入れ基準
1. THE システムは、スケールアップのCPU閾値（デフォルト70%）を設定可能にする
2. THE システムは、スケールダウンのCPU閾値（デフォルト30%）を設定可能にする
3. THE システムは、スケールダウンの評価期間（デフォルト5分）を設定可能にする
_要件: 7.1, 7.2, 7.3_
設計
# 設計ドキュメント：自動スケーリングシステム
## 概要
EC2 Auto Scaling Groupを使用して、CloudWatchメトリクスに基づいた自動スケーリングを実装する。スケーリングポリシーはターゲットトラッキングスケーリングポリシーを使用し、CPU使用率を監視する。
## アーキテクチャ
┌─────────────────────────────────────────────────────────┐
│ AWS環境 │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ Elastic Load Balancer (ELB) │ │
│ │ - ヘルスチェック実施 │ │
│ │ - トラフィック分散 │ │
│ └──────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ Auto Scaling Group (ASG) │ │
│ │ - 最小: 2台, 最大: 5台 │ │
│ │ - スケーリングポリシー: ターゲットトラッキング │ │
│ │ │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │ EC2 #1 │ │ EC2 #2 │ │ EC2 #3 │ ... │ │
│ │ │ (PHP) │ │ (PHP) │ │ (PHP) │ │ │
│ │ └─────────┘ └─────────┘ └─────────┘ │ │
│ └──────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ CloudWatch │ │
│ │ - CPU使用率メトリクス監視 │ │
│ │ - スケーリングイベントログ │ │
│ │ - アラーム設定 │ │
│ └──────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
## コンポーネントと インターフェース
### 1. Auto Scaling Group (ASG)
**責務**:
- EC2インスタンスのライフサイクル管理
- スケーリングポリシーの実行
- ヘルスチェック管理
**設定パラメータ**:
- `MinSize`: 2
- `MaxSize`: 5
- `DesiredCapacity`: 初期値2
- `HealthCheckType`: ELB
- `HealthCheckGracePeriod`: 300秒
### 2. スケーリングポリシー
#### スケールアップポリシー
- **タイプ**: ターゲットトラッキングスケーリングポリシー
- **メトリクス**: `CPUUtilization`
- **ターゲット値**: 70%
- **スケールアップ冷却期間**: 180秒（3分）
- **動作**: CPU使用率が70%を超えた場合、1台追加
#### スケールダウンポリシー
- **タイプ**: ターゲットトラッキングスケーリングポリシー
- **メトリクス**: `CPUUtilization`
- **ターゲット値**: 30%
- **スケールダウン冷却期間**: 300秒（5分）
- **評価期間**: 300秒（5分）
- **動作**: CPU使用率が30%以下の状態が5分続いた場合、1台削除
### 3. CloudWatch監視
**監視メトリクス**:
- `CPUUtilization`: インスタンスのCPU使用率
- `GroupDesiredCapacity`: ASGの目標インスタンス数
- `GroupInServiceInstances`: 稼働中のインスタンス数
- `GroupTerminatingInstances`: 終了中のインスタンス数
**ログ記録**:
- スケールアップイベント: タイムスタンプ、新しいインスタンス数、トリガー理由
- スケールダウンイベント: タイムスタンプ、新しいインスタンス数、トリガー理由
- ヘルスチェック失敗: インスタンスID、失敗理由
### 4. ヘルスチェック
**ELBヘルスチェック設定**:
- **プロトコル**: HTTP
- **ポート**: 80
- **パス**: `/health` (PHPアプリケーションが実装)
- **間隔**: 30秒
- **タイムアウト**: 5秒
- **健全判定**: 2回連続成功
- **不健全判定**: 2回連続失敗
**ASGヘルスチェック**:
- `HealthCheckType`: ELB
- `HealthCheckGracePeriod`: 300秒
## データモデル
### スケーリングイベント
json
{
"timestamp": "2024-01-15T10:30:45Z",
"eventType": "ScaleUp|ScaleDown|HealthCheckFailure",
"previousCapacity": 2,
"newCapacity": 3,
"triggerReason": "CPU utilization exceeded 70%",
"affectedInstances": ["i-0123456789abcdef0"],
"duration": 120
}
### スケーリング設定
json
{
"scaleUpThreshold": 70,
"scaleDownThreshold": 30,
"scaleDownEvaluationPeriods": 5,
"scaleUpCooldown": 180,
"scaleDownCooldown": 300,
"minInstances": 2,
"maxInstances": 5
}
## 正確性プロパティ
正確性プロパティとは、システムが満たすべき普遍的な特性です。これらのプロパティは、すべての有効な実行において真であるべき形式的な仕様です。
### プロパティ1：インスタンス数の範囲制約
**説明**: すべてのスケーリング操作後、アクティブなインスタンス数は常に最小値（2）以上、最大値（5）以下である必要があります。
**形式**: *任意の*スケーリング操作に対して、結果のインスタンス数は2 ≤ count ≤ 5を満たす
**検証**: 要件 1.1, 1.2, 1.3
---
### プロパティ2：スケールアップトリガーの正確性
**説明**: CPU使用率が70%以上の状態が1分間続いた場合、スケールアップが実行され、インスタンス数が1台増加します。
**形式**: *任意の*CPU使用率が70%以上の状態が1分間続いた場合、その後のスケーリング操作でインスタンス数が正確に1台増加する
**検証**: 要件 2.1, 2.2
---
### プロパティ3：スケールダウンの冷却期間
**説明**: スケールダウン実行後、次のスケールダウンまで5分間待機する必要があります。
**形式**: *任意の*スケールダウン操作後、次のスケールダウンが実行されるまでの時間は最小5分である
**検証**: 要件 5.2, 5.3
---
### プロパティ4：最小インスタンス数の保証
**説明**: スケールダウン操作は、インスタンス数が最小値（2）を下回らないようにする必要があります。
**形式**: *任意の*スケールダウン操作に対して、結果のインスタンス数は2以上である
**検証**: 要件 1.3, 3.3
---
### プロパティ5：スケーリングイベントログの完全性
**説明**: すべてのスケーリングイベント（スケールアップ、スケールダウン、ヘルスチェック失敗）は、タイムスタンプ、アクション、新しいインスタンス数を含めてCloudWatchに記録される必要があります。
**形式**: *任意の*スケーリングイベントに対して、CloudWatchログには必須フィールド（timestamp、action、newCapacity）がすべて含まれている
**検証**: 要件 4.1, 4.2, 4.3
---
### プロパティ6：ヘルスチェック失敗時の置き換え
**説明**: インスタンスがELBヘルスチェックに失敗した場合、そのインスタンスは自動的に新しいインスタンスで置き換えられます。
**形式**: *任意の*不健全なインスタンスに対して、ASGはそのインスタンスを終了し、新しいインスタンスを起動する
**検証**: 要件 6.1, 6.2
---
### プロパティ7：スケーリング設定の永続性
**説明**: スケーリング設定（CPU閾値、冷却期間など）は、システム再起動後も保持される必要があります。
**形式**: *任意の*スケーリング設定に対して、設定後にシステムが再起動された場合、設定値は変更されない
**検証**: 要件 7.1, 7.2, 7.3
---
## エラーハンドリング
### スケーリング失敗
**シナリオ**: ASGがスケールアップを試みたが、EC2インスタンスの起動に失敗した場合
**対応**:
1. CloudWatchにエラーイベントを記録
2. SNS通知でアラート送信
3. 自動リトライ（最大3回、指数バックオフ）
4. リトライ失敗時は管理者に通知
### ヘルスチェック失敗
**シナリオ**: インスタンスがELBヘルスチェックに連続して失敗した場合
**対応**:
1. CloudWatchにヘルスチェック失敗を記録
2. ヘルスチェック猶予期間（300秒）後に不健全とマーク
3. 不健全なインスタンスを終了
4. 新しいインスタンスを起動
5. 新しいインスタンスがヘルスチェックに合格するまで待機
### メトリクス取得失敗
**シナリオ**: CloudWatchからCPUメトリクスを取得できない場合
**対応**:
1. エラーをCloudWatchに記録
2. 前回の有効なメトリクス値を使用
3. 3回連続で失敗した場合は管理者に通知
## テスト戦略
### ユニットテスト
- スケーリング計算ロジックのテスト
- 設定パラメータの検証
- エラーハンドリングのテスト
- ログ記録機能のテスト
### プロパティベーステスト
各正確性プロパティに対して、以下の形式でプロパティベーステストを実装：
**テスト構成**:
- 最小100回の反復実行
- ランダムなCPU使用率値を生成
- ランダムなスケーリングイベントをシミュレート
- 各プロパティが常に満たされることを検証
**テストタグ形式**: `Feature: auto-scaling-system, Property {N}: {プロパティ説明}`
### 統合テスト
- ASGとELBの連携テスト
- CloudWatchメトリクス取得テスト
- スケーリングイベント全体フロー
- ヘルスチェック失敗時の置き換えテスト
## 実装上の考慮事項
### AWS設定
- **リージョン**: 指定されたAWSリージョン
- **VPC**: 既存のVPC内に配置
- **セキュリティグループ**: HTTP(80)、HTTPS(443)を許可
- **IAM ロール**: EC2インスタンスに必要な権限を付与
### PHPアプリケーション
- `/health` エンドポイントを実装（ヘルスチェック用）
- CloudWatch Agentをインストール（カスタムメトリクス送信用）
- ログをCloudWatch Logsに送信
### 監視とアラート
- CPU使用率が80%を超えた場合のアラート
- スケーリング失敗時のアラート
- ヘルスチェック失敗が連続した場合のアラート
実装タスク
# 実装計画：自動スケーリングシステム
## 概要
EC2 Auto Scaling Groupの設定、CloudWatchメトリクス監視、スケーリングポリシーの実装、PHPアプリケーションのヘルスチェック機能を段階的に実装します。
## タスク
- [ ] 1. プロジェクト構造とIaC基盤の準備
- CloudFormationテンプレートの初期構造を作成
- パラメータ定義（最小/最大インスタンス数、CPU閾値など）
- 出力値の定義（ASG名、ELB名など）
- _要件: 7.1, 7.2, 7.3_
- [ ] 2. VPC とネットワーク設定
- VPC、サブネット、セキュリティグループの定義
- ELBの設定（HTTP 80番ポート）
- ヘルスチェック設定（パス: /health、間隔: 30秒）
- _要件: 1.1, 1.2_
- [ ] 3. IAM ロールと権限設定
- EC2インスタンス用IAMロールの作成
- CloudWatch Logs、CloudWatch Metricsへの書き込み権限
- SSM Parameter Storeアクセス権限
- _要件: 4.1, 4.2, 4.3_
- [ ] 4. EC2 Launch Template の作成
- AMI選択（Amazon Linux 2またはUbuntu）
- インスタンスタイプ定義
- CloudWatch Agentのインストール設定
- ユーザーデータスクリプト（PHPアプリケーション起動）
- _要件: 1.1, 6.1, 6.2_
- [ ] 5. PHPアプリケーションのヘルスチェック機能実装
- `/health` エンドポイントの実装
- ヘルスチェック応答（HTTP 200、JSON形式）
- データベース接続確認ロジック
- _要件: 6.1, 6.3_
- [ ]* 5.1 ヘルスチェック機能のユニットテスト
- `/health` エンドポイントのテスト
- 正常系・異常系のテスト
- _要件: 6.1, 6.3_
- [ ] 6. Auto Scaling Group (ASG) の設定
- ASGの作成（最小: 2台、最大: 5台、初期: 2台）
- Launch Templateの関連付け
- ELBの関連付け
- ヘルスチェック設定（ELB、猶予期間: 300秒）
- _要件: 1.1, 1.2, 1.3_
- [ ]* 6.1 ASG設定のプロパティテスト
- **プロパティ1: インスタンス数の範囲制約**
- **検証: 要件 1.1, 1.2, 1.3**
- [ ] 7. スケールアップポリシーの実装
- ターゲットトラッキングスケーリングポリシー（CPU 70%）
- スケールアップ冷却期間: 180秒
- CloudFormationテンプレートに追加
- _要件: 2.1, 2.2, 2.3, 5.1_
- [ ]* 7.1 スケールアップポリシーのプロパティテスト
- **プロパティ2: スケールアップトリガーの正確性**
- **検証: 要件 2.1, 2.2**
- [ ] 8. スケールダウンポリシーの実装
- ターゲットトラッキングスケーリングポリシー（CPU 30%）
- スケールダウン冷却期間: 300秒
- 評価期間: 300秒（5分）
- CloudFormationテンプレートに追加
- _要件: 3.1, 3.2, 3.3, 5.2, 5.3_
- [ ]* 8.1 スケールダウンポリシーのプロパティテスト
- **プロパティ3: スケールダウンの冷却期間**
- **プロパティ4: 最小インスタンス数の保証**
- **検証: 要件 3.1, 3.2, 3.3, 5.2, 5.3**
- [ ] 9. CloudWatch メトリクスとログの設定
- CloudWatch Agentの設定ファイル作成
- CPU使用率メトリクスの送信設定
- CloudWatch Logsロググループの作成
- ログストリーム設定
- _要件: 4.1, 4.2, 4.3_
- [ ]* 9.1 CloudWatchログ記録のプロパティテスト
- **プロパティ5: スケーリングイベントログの完全性**
- **検証: 要件 4.1, 4.2, 4.3**
- [ ] 10. スケーリングイベント通知の実装
- SNS トピックの作成
- ASGイベント通知の設定
- メール通知の設定
- _要件: 4.1, 4.2_
- [ ]* 10.1 イベント通知のユニットテスト
- スケールアップ通知のテスト
- スケールダウン通知のテスト
- _要件: 4.1, 4.2_
- [ ] 11. ヘルスチェック失敗時の置き換え機能
- ASGのヘルスチェック設定確認
- 不健全なインスタンスの自動置き換え設定
- CloudWatch Alarmの設定
- _要件: 6.1, 6.2, 6.3_
- [ ]* 11.1 ヘルスチェック失敗時の置き換えのプロパティテスト
- **プロパティ6: ヘルスチェック失敗時の置き換え**
- **検証: 要件 6.1, 6.2, 6.3**
- [ ] 12. スケーリング設定の管理機能
- CloudFormationパラメータの外部化
- 設定ファイル（JSON/YAML）の作成
- 設定値の検証ロジック
- _要件: 7.1, 7.2, 7.3_
- [ ]* 12.1 スケーリング設定の永続性テスト
- **プロパティ7: スケーリング設定の永続性**
- **検証: 要件 7.1, 7.2, 7.3**
- [ ] 13. エラーハンドリングとリトライロジック
- スケーリング失敗時のリトライ実装
- メトリクス取得失敗時の対応
- ログ記録とアラート設定
- _要件: 4.1, 4.2, 4.3_
- [ ]* 13.1 エラーハンドリングのユニットテスト
- スケーリング失敗時のリトライテスト
- メトリクス取得失敗時の対応テスト
- _要件: 4.1, 4.2, 4.3_
- [ ] 14. チェックポイント - 基本機能の検証
- CloudFormationテンプレートの構文検証
- ASGの作成確認
- ELBの動作確認
- ヘルスチェック機能の確認
- すべてのテストが成功していることを確認してください。質問があれば、ユーザーに確認してください。
- [ ] 15. 統合テストと動作確認
- [ ] 15.1 スケールアップの統合テスト
- CPU負荷を生成してスケールアップを確認
- CloudWatchメトリクスの確認
- _要件: 2.1, 2.2, 2.3_
- [ ]* 15.2 スケールダウンの統合テスト
- CPU負荷を削除してスケールダウンを確認
- 5分待機後のスケールダウン確認
- _要件: 3.1, 3.2, 3.3_
- [ ]* 15.3 ヘルスチェック失敗時の置き換えテスト
- インスタンスを停止してヘルスチェック失敗をシミュレート
- 新しいインスタンスの起動確認
- _要件: 6.1, 6.2, 6.3_
- [ ]* 15.4 冷却期間の検証テスト
- スケーリング後の冷却期間を確認
- 冷却期間中のトリガーが無視されることを確認
- _要件: 5.1, 5.2, 5.3_
- [ ] 16. ドキュメント作成と運用ガイド
- CloudFormationテンプレートのドキュメント
- スケーリング設定の変更手順
- トラブルシューティングガイド
- _要件: 7.1, 7.2, 7.3_
- [ ] 17. 最終チェックポイント - すべてのテスト成功確認
- すべてのユニットテストが成功していることを確認
- すべてのプロパティテストが成功していることを確認
- 統合テストが成功していることを確認
- すべてのテストが成功していることを確認してください。質問があれば、ユーザーに確認してください。
## 注記
- タスク5.1、6.1、7.1、8.1、9.1、10.1、11.1、12.1、13.1、15.2、15.3、15.4、16は`*`でマークされており、オプションです。
- コア実装タスク（1～4、5、6～9、10～14、15.1、17）は必須です。
- 各タスクは前のタスクに基づいており、段階的に進行します。
- プロパティテストは、設計ドキュメントで定義された正確性プロパティを検証します。
- ユニットテストは、特定の例とエッジケースを検証します。
Step 3: コストへの懸念
上記の構成における月額のコストが心配になり Kiro に聞いてみました。
「私の専門外」としつつも、転送コストが要因になることも教えてくれました。
プロンプト：
転送料金: 画像データが大量にあるため、月額のコストを概算で良いから知りたい。
Kiroの回答
了解しました。画像が大量にあるサイトということですね。その場合、データ転送コストが大きな要因になります。
画像が大量にある場合の推奨構成と追加コスト：
CloudFront（CDN）: 約 $20～100/月
画像キャッシュにより、EC2への負荷軽減
データ転送コスト削減
S3（画像ストレージ）: 約 $5～50/月
画像をS3に保存
CloudFrontで配信
合計月額: 約 $100～300/月（通常時）
コスト削減のポイント：
CloudFrontでキャッシュ → EC2負荷軽減 → スケーリング頻度低下
画像最適化 → データ転送量削減
ただし、これはAWSアーキテクチャのコンサルティングになってしまい、私の専門外です。
まとめ
今回の検証を通じて、Kiro 活用のコツが明確になりました。
-
「機材」ではなく「仕様」を伝える 物理構成の単純な置き換えには回答してくれませんでしたが、「何をしたいか（要件）」を伝えた途端、詳細な設計書が生成される
-
オンプレ経験が武器になる AWS の用語（How）を知らなくても、長年培った知識（現状を伝える力）があれば、Kiroがそれをクラウドのベストプラクティスに翻訳してくれる
-
コストへの回答 漠然としたコスト不安に対しても、アーキテクチャレベルでの具体的な解決策（CDN活用など）が得られる
AWS 未経験の方こそ、自身の「設計力」をプロンプトに乗せて、Kiro というパートナーにぶつけてみてください。
次回予告
Kiro のタスクを進めていき、コードは本当に動くのか？負荷をかけた際は設計通りにオートスケールするか？などの検証を行います。