AWS公式MCPを入れたら、Kiro CLI の障害調査が別物になった

Thought for 1s...
    ╰ I need to investigate why the ALB `＊＊＊＊＊＊-＊＊-＊＊＊＊-test-alb` is returning 504 Gateway Timeout errors. Since the region isn't specified but the user appears to be Japanese, I'll start by
      checking ap-northeast-1 (Tokyo) and run parallel queries to locate the ALB and examine its configuration.
  ALBの状態を確認します。
● use_aws
    ╰ service_name=elbv2, operation_name=describe-load-balancers, region=ap-northeast-1, label=ALB情報の取得
● use_aws
    ╰ service_name=elbv2, operation_name=describe-target-groups, region=ap-northeast-1, label=ターゲットグループ一覧の取得
● Thought for 1s...
    ╰ ALBがアクティブなので、＊＊＊＊＊＊-＊＊-＊＊＊＊-test-tgターゲットグループのヘルスチェック状態を確認してから、ALBのアイドルタイムアウト設定、ターゲットグループの属性、リスナー設定、セキュリティグ
      ループを一通り見ておく必要がある。
● use_aws
    ╰ label=ターゲットヘルスの確認, operation_name=describe-target-health, region=ap-northeast-1, service_name=elbv2
● use_aws
    ╰ label=ALB属性の確認, operation_name=describe-load-balancer-attributes, region=ap-northeast-1, service_name=elbv2
● use_aws
    ╰ label=リスナーの確認, operation_name=describe-listeners, region=ap-northeast-1, service_name=elbv2
● use_aws
    ╰ label=ALB SGの確認, operation_name=describe-security-groups, region=ap-northeast-1, service_name=ec2
● Thought for 1s...
    ╰ ターゲット i-＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ が unhealthy になっていて、504 タイムアウトエラーが出ている。これはターゲットへの接続がタイムアウトしているということだから、EC2
      インスタンスの状態、セキュリティグループ、NACL を確認する必要がある。まずはインスタンスの詳細情報を取得しよう。
  ターゲットが unhealthy (Target.Timeout) でした。原因を絞り込みます。
● use_aws
    ╰ label=EC2インスタンスの確認, operation_name=describe-instances, region=ap-northeast-1, service_name=ec2
● use_aws
    ╰ label=インスタンスステータスの確認, operation_name=describe-instance-status, region=ap-northeast-1, service_name=ec2
● Thought for 2s...
    ╰ インスタンスは running で状態チェックも問題ない。次はセキュリティグループと NACL を確認する必要がある。EC2 のセキュリティグループ sg-＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
      のインバウンドルールと、サブネットの NACL を見ていく。ただし LaunchTime が 2026-08-03T07:36:18Z で、つまり JST では今日の 16:36、わずか 5 分前に起動または再起動されたばかりなので、Web
      サーバがまだ立ち上がっていない可能性もある。
● use_aws
    ╰ label=EC2 SGの確認, operation_name=describe-security-groups, region=ap-northeast-1, service_name=ec2
● use_aws
    ╰ label=NACLの確認, operation_name=describe-network-acls, region=ap-northeast-1, service_name=ec2
● Thought for 6s...
    ╰ NACLは完全にオープンだけど、セキュリティグループがport 80をプレフィックスリスト pl-＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
      からのみ許可していて、ALBのセキュリティグループ(sg-＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊)からは許可されていない。このプレフィックスリストの内容を確認する必要があるね。カスタム管理プレフィックスリストの可
      能性があるし、VPC CIDRが含まれているかどうかが重要。これが問題の原因である可能性が高い。

      ALBからのヘルスチェックがタイムアウトしてTarget.Timeoutになり、504エラーが発生している。ただ、以前は動いていたなら、Webサーバ(nginxやhttpd)が停止している可能性もある。インスタンスは5分
      前に起動したばかりだから、SSMでプロセスを確認できるかもしれない。まずはプレフィックスリストとVPC CIDRを確認するところから始めよう。
● use_aws
    ╰ label=プレフィックスリストのエントリ確認, operation_name=get-managed-prefix-list-entries, region=ap-northeast-1, service_name=ec2
● use_aws
    ╰ label=VPCの確認, operation_name=describe-vpcs, region=ap-northeast-1, service_name=ec2
● Thought for 10s...
    ╰ ほぼ原因が特定できた。EC2のセキュリティグループ(＊＊-＊＊＊＊-test-web-sg-01)のポート80インバウンドルールが、オフィスのグローバルIP4つ(プレフィックスリスト)のみを許可していて、ALBのプライベ
      ートIP(10.x.x.x)からのトラフィックが許可されていない。そのためALBからのヘルスチェックやリクエストがドロップされて、タイムアウトが発生し504エラーになっている。念のためヘルスチェックを確
      認してみよう。

      ログがS3に有効になっているか確認したいし、Webサーバが実際に起動しているかもSSM経由で確認したい。SSM
      Agentがオンラインなら、systemctlのステータス確認など読み取り専用コマンドなら安全に実行できる。ただSGが明らかな原因なので、まずそれを報告するのが優先だが、SGを修正してもWebサーバが落ち
      ていたら別の504/502エラーになる可能性があるから、事前に確認しておくと良い。CloudWatchメトリクスでUnHealthyHostCountを見て、いつからunhealthyになったかも確認しておこう。SSMのインスタン
      ス情報確認とCloudWatchメトリクスの確認を並行して進める。
● use_aws
    ╰ label=SSM管理状態の確認, operation_name=describe-instance-information, region=ap-northeast-1, service_name=ssm
● use_aws
    ╰ label=UnHealthyHostCountメトリクスの取得, operation_name=get-metric-statistics, region=ap-northeast-1, service_name=cloudwatch
● Thought for 1s...
    ╰ SSM Online の send-command を使って、httpd/nginx の稼働状況、ポート接続状況、ヘルスチェックエンドポイントの応答を確認する。読み取り専用の操作なので安全に実行できる。CloudWatch
      への結果送信は JSON 形式で再試行する。
● use_aws
    ╰ label=UnHealthyHostCountメトリクス再取得, operation_name=get-metric-statistics, region=ap-northeast-1, service_name=cloudwatch
● use_aws
    ╰ label=SSM経由でWebサーバ状態を確認, operation_name=send-command, region=ap-northeast-1, service_name=ssm
● Thought for 16s...
    ╰ 読み取り専用ロールではSSM SendCommandが実行できないので、別のアプローチが必要。メトリクスを見ると、07:30
      UTC時点のデータポイントしかなく、これはALBがターゲットの監視を開始した時点で、インスタンス起動後のデータ。07:36
      UTCのインスタンス起動前はデータが存在しないということになるが、07:30のデータポイントは07:30-07:45の期間を示しているので、タイミングを再確認する必要がある。

      実際のところ、インスタンスは今日16:36 JST（07:36
      UTC）に起動されたばかりで、起動直後からunhealthyの状態。原因はセキュリティグループでほぼ確定している。EC2のウェブSGで80番ポートのインバウンドがオフィスIPのみに制限されており、ALBのENI
      （10.x.x.x/16内）からの通信が許可されていない。このため、ALBからターゲットへの接続がドロップされ、ヘルスチェックはタイムアウト、リクエストは504エラーになる。504が返されるのは、すべての
      ターゲットがunhealthyの場合、ALBが全ターゲットへのルーティングを試みるため、接続がタイムアウトして504になるという動作と整合している。

      ALBのセキュリティグループも同様にオフィスIPのみに制限されているが、これは意図的なアクセス制限。ALBのアウトバウンドは全許可なので、ALB→EC2への通信は出ていくが、EC2側で入ってこない。Targ
      etConnectionErrorCountメトリクスを確認して、ALB→ターゲット間の接続失敗を裏付けたい。
● use_aws
    ╰ label=接続エラー数の取得, operation_name=get-metric-statistics, region=ap-northeast-1, service_name=cloudwatch
● use_aws
    ╰ label=ELB 5XX数の取得, operation_name=get-metric-statistics, region=ap-northeast-1, service_name=cloudwatch
    {
      "exit_status": "0",
    "stdout": "{\n    \"Label\": \"HTTPCode_ELB_5XX_Count\",\n    \"Datapoints\": [\n        {\n            \"Timestamp\": \"2026-08-03T07:40:00+00:00\",\n            \"Sum\": 2.0,\n
    \"Unit\": \"Count\"\n        }\n    ]\n}\n",
    ...+2 lines (ctrl+o to toggle)
● Thought for 10s...
    ╰ 確認が取れた。07:40 UTC (16:40 JST) の時点で TargetConnectionErrorCount と HTTPCode_ELB_5XX_Count
      がそれぞれ2で、ユーザーのアクセス2回が504エラーになっている。ALBからターゲットへの接続自体が失敗しているのはセキュリティグループでドロップされている証拠だ。もしアプリの応答が遅いだけな
      ら TargetResponseTime が増加して Target_5XX が発生するはずだが、ここは接続エラーが根本原因だ。

      原因は確定的：EC2側のセキュリティグループの80番インバウンドルールにALBのセキュリティグループ（またはVPC
      CIDR）が許可されていない。修正するにはALBのセキュリティグループをソースとして80番を許可する必要があるが、読み取り専用ロールなので実行はできない。

      ただし、Webサーバが実際に起動しているかは確認できていない。SSM権限がなく、80番へのアクセスもオフィスIP限定なので検証できない点を報告に明記する。
  原因が特定できました。

  結論

  EC2側のセキュリティグループが ALB からの通信を許可していないため、ALB → ターゲットのTCP接続が確立できず、504になっています。

  ターゲット i-＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ (＊＊＊＊＊＊-＊＊-＊＊＊＊-test-web01) にアタッチされている ＊＊-＊＊＊＊-test-web-sg-01 (sg-＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊) のインバウンドは、TCP/80 も TCP/22 もプレフィックスリスト
  pl-＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ のみを許可しています。中身は以下のグローバルIP 4件だけです。

  x.x.x.x/32, x.x.x.x/32, x.x.x.x/32, x.x.x.x/32

  ALB は VPC 内のENI（10.x.x.x/16）からターゲットへ接続するため、この許可元に該当せずパケットがドロップされます。ALB SG (sg-＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊) も VPC CIDR も許可対象に入っていません。

  裏付けとなる観測結果

  - ターゲットヘルス: unhealthy / Reason Target.Timeout / "Request timed out"
  - TargetConnectionErrorCount = 2、HTTPCode_ELB_5XX_Count = 2（ともに 16:40 JST）。TCP接続自体の失敗であり、アプリの応答遅延ではありません
  - インスタンスは running、システム/インスタンスの両ステータスチェックは passed、SSM Agent も Online（＝OSは生きている）
  - NACL は in/out ともに 0.0.0.0/0 allow なので無関係
  - ALB は active、リスナー HTTP:80 → ＊＊＊＊＊＊-＊＊-＊＊＊＊-test-tg へ forward、idle timeout 60秒（設定側の問題なし）

  全ターゲットが unhealthy の状態では ALB は unhealthy なターゲットにもルーティングを試みるため、503ではなく接続タイムアウトによる504が返ります。

  対処

  EC2側SGに ALB のSGを送信元とした 80番許可を追加してください（SG参照が推奨。IP直書きより保守が容易です）。

  aws ec2 authorize-security-group-ingress \
    --group-id sg-＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ \
    --protocol tcp --port 80 \
    --source-group sg-＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ \
    --region ap-northeast-1

  現在のクレデンシャルは readonly ロール (＊＊＊＊＊＊＊＊-federation-role-readonly) のため、私からは変更を適用していません。

  未検証の点として、インスタンス内で httpd/nginx が実際に起動し /healthcheck.html を200で返せるかは確認できていません（ssm:SendCommand が権限拒否）。インスタンスは 16:36 JST
  に起動したばかりなので、SG修正後もunhealthyが続く場合はWebサーバ自体の起動と該当ファイルの存在を確認してください。
▸ Credits: 4.18 • Time: 3m 51s

● Thought for 1s...
    ╰ I need to investigate why the ＊＊＊＊＊＊-＊＊-＊＊＊＊-test-alb is returning 504 Gateway Timeout errors. Let me start by locating the ALB and checking its configuration—it's currently 12:20 UTC
      on August 3rd, 2026.
  ALBの状態を確認します。
● use_aws
    ╰ label=Describe the ALB ＊＊＊＊＊＊-＊＊-＊＊＊＊-test-alb, operation_name=describe-load-balancers, region=ap-northeast-1, service_name=elbv2
● use_aws
    ╰ label=List target groups, operation_name=describe-target-groups, region=ap-northeast-1, service_name=elbv2
● Thought for 1s...
    ╰ I need to examine the target group ＊＊＊＊＊＊-＊＊-＊＊＊＊-test-tg by checking its health status, attributes like idle timeout on the ALB, listener configuration, and then reviewing the
      CloudWatch metrics for response times, ELB 5XX errors, and target connection errors.
● use_aws
    ╰ label=Describe target health, operation_name=describe-target-health, region=ap-northeast-1, service_name=elbv2
● use_aws
    ╰ label=Describe ALB attributes, operation_name=describe-load-balancer-attributes, region=ap-northeast-1, service_name=elbv2
● use_aws
    ╰ label=Describe listeners, operation_name=describe-listeners, region=ap-northeast-1, service_name=elbv2
● use_aws
    ╰ label=Describe target group attributes, operation_name=describe-target-group-attributes, region=ap-northeast-1, service_name=elbv2
● Thought for 1s...
    ╰ The target is timing out because it's the only one available and unhealthy, so the load balancer still sends traffic to it, resulting in 504 errors. I need to dig into the instance
      state, security group rules, and performance metrics to find what's actually causing the timeout.
  ターゲットが Target.Timeout で unhealthy です。原因を掘ります。
● use_aws
    ╰ label=Describe target instance, operation_name=describe-instances, region=ap-northeast-1, service_name=ec2
● use_aws
    ╰ label=Describe instance status, operation_name=describe-instance-status, region=ap-northeast-1, service_name=ec2
● use_aws
    ╰ label=Describe ALB security group, operation_name=describe-security-groups, region=ap-northeast-1, service_name=ec2
● Thought for 1s...
    ╰ Let me check the ingress rules for that security group and review both the security group and network ACL configurations, since the instance was just restarted a few hours ago.
● use_aws
    ╰ label=Describe instance security group, operation_name=describe-security-groups, region=ap-northeast-1, service_name=ec2
● use_aws
    ╰ label=Describe network ACLs for subnet, operation_name=describe-network-acls, region=ap-northeast-1, service_name=ec2
● Thought for 2s...
    ╰ The instance security group is restricting port 80 to a specific prefix list rather than the ALB's security group, which could be the culprit if that prefix list doesn't contain the
      ALB's private IPs. I need to verify what's actually in that prefix list — it could be customer-managed IPs like office networks, or it might be an AWS-managed list that doesn't include
      the ALB.
● use_aws
    ╰ label=Describe managed prefix list, operation_name=describe-managed-prefix-lists, region=ap-northeast-1, service_name=ec2
● use_aws
    ╰ label=Get prefix list entries, operation_name=get-managed-prefix-list-entries, region=ap-northeast-1, service_name=ec2
● Thought for 7s...
    ╰ So the web instance's security group is only allowing traffic from those four office IPs on port 80, which means the ALB can't reach the targets — that's why the health checks are
      timing out and requests are getting 504s. Though it's odd that the target was working before if this restriction was already in place.

      Let me check if the security group rule or prefix list was recently modified by looking at CloudTrail, and pull CloudWatch metrics to see exactly when the 504 errors and unhealthy
      hosts started appearing. I should also verify the httpd service is actually running on the instance — the security group would block everything anyway, but I want to rule out an
      application issue. I can use SSM to run a read-only check since the instance has the proper IAM profile, though I'll start with the audit logs and metrics first to establish the
      timeline.
● get_metric_data
    ╰ region=ap-northeast-1, start_time=2026-08-02T12:00:00Z, end_time=2026-08-03T12:25:00Z, target_datapoints=300
● lookup_events
    ╰ attribute_key=EventName, attribute_value=RevokeSecurityGroupIngress, region=ap-northeast-1, start_time=2026-07-27T00:00:00Z, max_results=20
● Thought for 5s...
    ╰ Found it—the user ＊＊＊＊＊＊＊＊@＊＊＊＊.co.jp removed the ingress rule allowing traffic from the ALB security group to the instance security group on port 80 at 21:13:07 JST, which matches when
      the outage occurred. This same rule was revoked earlier at 19:00:53 JST but was restored around 19:20, which is when service recovered.
● lookup_events
    ╰ attribute_key=EventName, attribute_value=AuthorizeSecurityGroupIngress, max_results=10, region=ap-northeast-1, start_time=2026-08-03T00:00:00Z
    {
      "content": [
        {
    ...+6 lines (ctrl+o to toggle)
● Thought for 5s...
    ╰ I've confirmed the root cause: a security group rule allowing TCP/80 traffic from the ALB was removed from the EC2 instance's security group at 21:13:07 JST. I'll document this finding
      and provide the command to restore the rule without making any changes, since the user only asked for investigation.
  原因

  EC2 側のセキュリティグループから「ALB からの TCP/80 許可」ルールが削除されているため、ALB がターゲットに接続できずタイムアウトしています。

  構成:

  - ALB ＊＊＊＊＊＊-＊＊-＊＊＊＊-test-alb (sg-＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊) → TG ＊＊＊＊＊＊-＊＊-＊＊＊＊-test-tg → EC2 ＊＊＊＊＊＊-＊＊-＊＊＊＊-test-web01 (i-＊＊＊..., 10.x.x.x)
  - ターゲットの状態: unhealthy / Target.Timeout (Request timed out)
  - EC2 の SG ＊＊-＊＊＊＊-test-web-sg-01 (sg-＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊) の inbound は現在 prefix list ＊＊＊＊＊＊-＊＊-＊＊＊＊-test-＊＊＊＊-ips（オフィスIP 4件）からの 80/22 のみ。ALB SG 参照ルールが無いため、ALB の
  ENI からの TCP/80 は届きません。

  ターゲットが1台しかなく全台 unhealthy なので、ALB は fail-open でそのまま転送します。応答が返らないまま idle timeout (60s) に達し 504 になります。EC2 自体は running・ステータスチェック
  ok、NACL は全開放なので、SG 以外の経路要因はありません。

  経緯（CloudTrail、いずれも ＊＊＊＊＊＊＊＊@＊＊＊＊.co.jp / マネコン / x.x.x.x）

| 時刻 (JST) | 操作 | 結果 |
| --- | --- | --- |
| 18:56:19 | ALB SG からの 80 許可を追加 | HealthyHostCount=1 に復旧 |
| 19:00:53 | 同ルールを削除 (sgr-＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊) | unhealthy → 504 4件 |
| 19:20:47 | 再追加 (sgr-＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊) | 復旧 |
| 21:13:07 | 再度削除 (sgr-＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊) | 21:15 以降 unhealthy、504 発生中 |

  メトリクスも一致しており、21:10 まで HealthyHostCount=1 → 21:15 以降 0、同時刻に HTTPCode_ELB_5XX_Count が計上されています。

  対処

  削除されたルールを戻せば復旧します。SG の変更になるので、実行しますか？

  aws ec2 authorize-security-group-ingress \
    --region ap-northeast-1 \
    --group-id sg-＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ \
    --ip-permissions 'IpProtocol=tcp,FromPort=80,ToPort=80,UserIdGroupPairs=[{GroupId=sg-＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊}]'

  なお、prefix list 経由のオフィスIPからの 80 許可はALBを経由しない直アクセス用途と思われます。ALB 経由のみに寄せるなら、そちらの 80 ルールは整理の検討余地があります。
▸ Credits: 5.32 • Time: 2m 53s