CI事業部の石川優です。
Kiro CLI を使ったトラブルシューティングのハンズオンに参加したレポートです!
セッション概要
Learn how to troubleshoot large-scale AWS environments through an AI-first approach powered by Kiro CLI. We’ll begin with hands-on experience using Kiro CLI’s custom AI agents and Model Context Protocol (MCP) integration, demonstrating how AI transforms traditional problem-solving through contextual, automated diagnostics. The AI agents are also complemented with essential tools, including log and metrics analysis through Amazon CloudWatch, AWS Config, and AWS X-Ray. Choose your preferred domain- networking, containers, databases, or serverless/DevOps – and work on triaging real-world issues using Agentic AI and the best practices shared during the workshop. You must bring your laptop to participate.
従来の手法と最先端の生成AI技術を組み合わせて、大規模なAWS環境のトラブルシューティングを学ぶワークショップ。Amazon CloudWatch、AWS Config、AWS X-Rayを使用した実証済みのトラブルシューティング手法から始まり、Amazon Qがコンテキストに応じたAI駆動の診断を提供することで、トラブルシューティング体験を変革する方法を実践的に学習。
このハンズオン、予約時は、Troubleshooting in the cloud with Amazon Q という名前でしたが、先日の Amazon Q CLI が Kiro CLI に変わるという発表に合わせて名前も変わっていました。
内容
まず、ハンズオンに入る前に軽くクラウドのトラブルシューティングにどのような難しさがあって、それに対して Kiro CLI はどう使えるのかという説明がありました。

モダンなアプリケーションでは数十から数百のサービスの依存関係があります。

それに対して、AWS にはさまざまなオブザーバビリティサービスがあります。
ですが、それでもこの依存関係とオブザーバビリティサービスのアウトプットの相関を整理するのもまた一つの課題として存在します。

そこで Kiro CLI が使えるようです。
Kiro CLI では、コンテキストファイルやトラブルシューティングガイド、必要な専用ツールなど、コンテキストにアクセスするエージェントを設定できます。

ちなみに会場はこのような感じで、30分ぐらい説明があった後各自黙々とハンズオンをする感じでした。

どのサービスのハンズオンをやりたいか5個から選ぶ感じで、Kiro CLI のエージェントも5個用意されていました。
私は、普段あまり触らないECSにしてみました。

問題1
ハンズオンだと手元で日本語にできるのありがたい
![[FireShot Capture 206 – クラスターインフラストラクチャ – Elastic Container Service – us-east-1_ – [us-east-1.console.aws.amazon.com].png]]
ECSクラスターのキャパシティープロバイダーは「ASGCapProvider-containers-ecs-…」でEC2 Auto Scalingタイプ。コンテナインスタンス数は「(0) 情報」と表示され、インスタンスが登録されていないことが確認できます。

その EC2 Auto Scaling グループ「EcsASG」の希望するキャパシティは2になっていて、ECS に登録されていないのがおかしい状況です。

Kiro に協力をお願いする。

すると、サクサク問題を把握してくれました。
クラスターはアクティブだがregisteredContainerInstancesCountが0でコンテナインスタンスが登録されていない。Auto Scaling Groupを確認し、EcsASGで2つのインスタンスが稼働中であることを確認。

問題も一瞬で見つけてくれました。
- UserDataで「ECS_CLUSTER=’Empty’」と設定されており、正しいクラスター名「ECSWorkshopCluster」に修正する必要がある。
- IAMインスタンスプロファイルの権限も確認し、IAMロール「ECSEC2Role」に必要な「AmazonEC2ContainerServiceforEC2Role」ポリシーがアタッチされていないことを発見。
ハンズオンで用意されたエージェントは aws-api-mcp-server を使っているようですね。
Kiro CLI であればそもそも AWS アカウントにアクセスして操作もできるからいらないのかと思っていました。

そのまま修正をお願いしました。
- 新しいLaunch Templateバージョン2を作成し、Auto Scaling Groupを更新して最新バージョンを使用するように設定。
- 既存のインスタンスを新しい設定で置き換えるためにインスタンスリフレッシュを開始し、進行状況を確認。
ECSコンソールからも確認できました。

問題2 – ECSタスクが「コンテナをプルできません」というエラーで失敗しました

ECSタスクの停止エラーが確認できます。

こちらも Kiro CLIでのトラブルシューティング開始。
「us-east-1リージョンのECSクラスター『ECSWorkshopCluster』でECSタスクが『Cannot Pull Container Error』というエラーで失敗しました」とプロンプトを入力。

すぐに問題を見つけてくれました。
イメージ名が「public.ecr.aws/nginx/nginxlatest」となっており、コロン(:)が抜けている。正しくは「public.ecr.aws/nginx/nginx:latest」。タスク定義を確認後、修正もそのままやってくれています。
こういうタイプミスはしょうもないですが目視だと見落としやすいので、拾ってくれるのはありがたい。

タスクが正常にRUNNING状態になり、コンテナイメージが正常にプルされ起動し、完了してくれました。
問題 3 – ECS サービス ロードバランサー要求のタイムアウト エラー
(写真撮り損ねました)
サンプルタスクのテストが完了したので、チームはインターネットに接続されたロードバランサを備えたECSサービスを、長期実行ステートレスアプリケーションに使用する計画を立てています。サービススケジューラは、指定されたスケジューリング戦略が確実に実行されるようにし、タスクが失敗した場合は再スケジュールします。例えば、サービスの必要回数を1に設定すると、タスクは常にこの回数を維持します。基盤となるインフラストラクチャに障害が発生した場合、サービススケジューラはタスクを再スケジュールします。

ECSサービスのイベント履歴画面を見るとターゲットの登録と登録解除を繰り返している。

ターゲットの ALB にアクセスすると「504 Gateway Time-out」エラーが表示されます。

ターゲットグループの状態確認画面。登録済みターゲット2つのうち、1つは「Draining」ステータスで「Target deregistration in progress」、もう1つは「Unhealthy」ステータスで「Request timed out」と表示。異常検知として「該当なし」と表示されている。

Kiro CLI にまたお願いします。
– 「us-east-1リージョンのECSクラスター『ECSWorkshopCluster』のECSサービスに対するロードバランサー要求のタイムアウトエラーが発生しました」とプロンプト入力。

ヘルスチェックの間隔とセキュリティグループに問題があることを見つけてくれました。
- HealthyThresholdCountが5で、HealthCheckIntervalSecondsが30秒のため、ターゲットがhealthyになるまで5 × 30 = 150秒かかる。
- コンテナインスタンスのセキュリティグループ(sg-0360a7db468299879)が、ロードバランサーのセキュリティグループ(sg-04918f25b79e2a9b2)からのトラフィックを許可していないことも判明。ロードバランサーのセキュリティグループからのトラフィックを許可するルールを追加するため「aws ec2 authorize-security-group-ingress」を実行。

修正もお願いし、ALB にもアクセスできるようになっていることが確認できます。

まとめ
5問全てできませんでしたが、普段あまり触っていない ECS のトラブルシューティングが簡単にできました。
原因の分析と修正まで勝手にやってくれた。
エージェントのプロンプトも見てみたのですが、特別凝ったものが書かれているわけでもなかったです。
おそらく、リソースや用途ごとにカスタムエージェントを作成するのが良いのかなと思いました。
おまけ:プロンプト含むエージェント設定ファイルは以下の通りとなっていました。
[ec2-user@ip-10-0-34-10 agents]$ cat ecs-agent.json
{
"$schema": "https://raw.githubusercontent.com/aws/amazon-q-developer-cli/refs/heads/main/schemas/agent-v1.json",
"name": "ecs-agent",
"description": "Agent for working on the ECS scenarios in the GenAI workshop",
"prompt": "You are an expert AWS ECS (Elastic Container Service) assistant specialized in helping with GenAI workshop scenarios. You have deep knowledge of ECS concepts including clusters, services, tasks, task definitions, container orchestration, and integration with other AWS services. You can help with ECS configuration, troubleshooting, best practices, and hands-on workshop exercises related to containerized AI/ML workloads.",
"mcpServers": {
"awslabs.aws-api-mcp-server": {
"type": "stdio",
"url": "",
"headers": {},
"oauthScopes": [
"openid",
"email",
"profile",
"offline_access"
],
"command": "uvx",
"args": [
"awslabs.aws-api-mcp-server@latest"
],
"env": {
"AWS_REGION": "us-east-1"
},
"timeout": 120000,
"disabled": false
},
"aws-knowledge-mcp-server": {
"type": "stdio",
"url": "",
"headers": {},
"oauthScopes": [
"openid",
"email",
"profile",
"offline_access"
],
"command": "uvx",
"args": [
"mcp-proxy",
"--transport",
"streamablehttp",
"https://knowledge-mcp.global.api.aws"
],
"timeout": 120000,
"disabled": false
}
},
"tools": [
"*"
],
"toolAliases": {},
"allowedTools": [],
"resources": [
"file://AmazonQ.md",
"file://AGENTS.md",
"file://README.md",
"file://.amazonq/rules/**/*.md",
"file:///home/ec2-user/.kiro/context-files/ecs/*.md"
],
"hooks": {},
"toolsSettings": {},
"useLegacyMcpJson": false,
"model": "claude-sonnet-4.5"
}[ec2-user@ip-10-0-34-10 agents]$