こんにちは、AWS グループの尾谷です。
Kiro コンソールを開くと、以下のメッセージが表示されました。
企業ネットワーク環境で Kiro を運用している方には影響がありそうです。
詳しく見ていきます。
この記事は、組織のファイアウォールやプロキシで通信先を制限している企業ユーザー向け です。
個人利用などでファイアウォール制御をしていない方は、特に対応は不要です。
対応しないとどうなるか
まず結論から。
5 月 15 日以降にリリースされる Kiro の新バージョンに更新した際、ファイアウォールにブロックされて以下のような問題が発生する可能性があります。
- Kiro にサインインできない
- チャットやコード補完が動作しない
- 自動更新が失敗する
- Powers（Kiro の拡張機能・追加機能の仕組み）のインストールができない
2026年5月15日以降にリリースされる Kiro デスクトップアプリ / CLI の新バージョンは、新しい kiro.dev エンドポイントを利用します。既存の q.<region>.amazonaws.com はレガシー扱いで、公式ドキュメント上も将来的な非推奨化が示されています。したがって、5月15日までに kiro.dev 側を許可しておくのが安全です。
ファイアウォール設定の変更依頼
詳細は、こちら のドキュメントにまとめられていました。
Kiro からの公式アナウンスで、サービス基盤の移行に伴うファイアウォール設定の変更依頼でした。
何が起きるのか
Kiro のサービスエンドポイントが kiro.dev ドメインに移行されます。
2026年5月15日以降にリリースされる Kiro デスクトップアプリ / CLI の新バージョンは、新しい kiro.dev ドメイン配下のエンドポイントと通信するようになります。既存の q.<region>.amazonaws.com はレガシー扱いで、公式ドキュメント上も将来的な非推奨化（deprecated）が示されています。
つまり、組織のファイアウォールで通信先を制限している場合、新しいドメインを許可しないと Kiro が使えなくなる可能性があるということです。
対応が必要なケース
以下に該当する場合は対応が必要です。
- 組織のファイアウォールやプロキシで、Kiro へのアウトバウンド通信を許可リスト（ホワイトリスト）で制御している
- VPC やデータ境界（Data Perimeter）を設定して、通信先を制限している
必要な対応
2026年5月15日までに、以下のドメインをファイアウォールの許可リストに追加する必要があります。
ワイルドカードで簡略化する場合
ネットワークポリシーでワイルドカードルールが許可されている場合は、*.kiro.dev を許可リストに追加することで個別指定を省略できます。
ただし、ファイアウォールによっては *.kiro.dev が単一サブドメインレベルしかマッチしない場合があります（例：app.kiro.dev にはマッチするが assets.app.kiro.dev にはマッチしない）。その場合は *.app.kiro.dev も追加するか、マルチレベルのサブドメインを明示的にリストしてください。
個別ドメインの詳細
Core URLs（全 Kiro 製品で必須）— クリックで展開
| ドメイン | 用途 |
|---|---|
app.kiro.dev |
サインインポータル |
assets.app.kiro.dev |
アプリケーションアセット |
cli.kiro.dev |
CLI アプリケーション |
prod.us-east-1.auth.desktop.kiro.dev |
トークン交換・リフレッシュ・ログアウト |
prod.us-east-1.telemetry.desktop.kiro.dev |
テレメトリ |
prod.download.desktop.kiro.dev |
自動更新・Powers レジストリ・アイコン |
prod.download.cli.kiro.dev |
CLI ダウンロード・更新 |
desktop-release.q.us-east-1.amazonaws.com |
CLI インストーラーダウンロード（※） |
runtime.us-east-1.kiro.dev |
Kiro サービス（US East） |
runtime.eu-central-1.kiro.dev |
Kiro サービス（Europe） |
management.us-east-1.kiro.dev |
設定・アクセス管理（US East） |
management.eu-central-1.kiro.dev |
設定・アクセス管理（Europe） |
telemetry.us-east-1.kiro.dev |
テレメトリ（US East） |
telemetry.eu-central-1.kiro.dev |
テレメトリ（Europe） |
※ CLI インストーラーのダウンロードについては、引き続き
amazonaws.comドメインが使われます。レガシーエンドポイントについて
q.us-east-1.amazonaws.comおよびq.eu-central-1.amazonaws.comは引き続き動作しますが、将来のリリースで廃止予定です。新規設定では上記のruntime、management、telemetryエンドポイントを使用してください。
ソーシャルサインイン（Google / GitHub）を使っている場合 — クリックで展開
| ドメイン | 用途 |
|---|---|
cognito-identity.us-east-1.amazonaws.com |
ソーシャルサインイン用フェデレーション ID |
IAM Identity Center を使っている場合 — クリックで展開
| ドメイン | 用途 |
|---|---|
<region>.signin.aws |
AWS サインイン |
<idc-directory-id-or-alias>.awsapps.com |
IAM Identity Center ポータル |
oidc.<sso-region>.amazonaws.com |
OIDC トークン交換 |
外部 IdP（Microsoft Entra ID や Okta）を利用している場合は、それぞれの IdP ドメイン（login.microsoftonline.com や <your-org>.okta.com）も許可が必要です。
サブスクリプション管理（Google / GitHub / AWS Builder ID でサインインしている場合）— クリックで展開
| ドメイン | 用途 |
|---|---|
billing.stripe.com |
課金ポータル |
checkout.stripe.com |
プランアップグレード |
IAM Identity Center を使っているエンタープライズのお客様はこれらのドメインは不要です。
プロキシ環境での注意点
Kiro の CLI は標準的なプロキシ環境変数（HTTP_PROXY、HTTPS_PROXY、NO_PROXY）を優先するようです。
ただし、サインイン時にはデフォルトブラウザで app.kiro.dev が開かれ、このブラウザトラフィックは OS のネットワークスタックを使用するため、CLI のプロキシ設定をバイパスします。ファイアウォールでは、プロキシ設定に関係なく、ネットワークレベルで IAM Identity Center の URL と app.kiro.dev を許可する必要があると記載されていました。
エンタープライズ環境での実践的な対応
ここからは、Data Perimeter や AWS Network Firewall を構築している環境向けに、具体的な対応例を紹介します。
AWS Network Firewall でのドメインリスト設定
AWS Network Firewall を使って通信先を制御している場合、ドメインリストルールグループに *.kiro.dev を追加します。
# 1. 既存ルールグループの UpdateToken を取得 aws network-firewall describe-rule-group \ --rule-group-arn arn:aws:network-firewall:ap-northeast-1:123456789012:stateful-rulegroup/allow-domains \ --type STATEFUL # 2. 取得した UpdateToken を指定して更新 # ※ Targets の ".kiro.dev" は先頭ドットにより kiro.dev とそのサブドメイン全てにマッチします aws network-firewall update-rule-group \ --rule-group-arn arn:aws:network-firewall:ap-northeast-1:123456789012:stateful-rulegroup/allow-domains \ --update-token "<describe-rule-group で取得した UpdateToken>" \ --rules '{"RulesSource":{"RulesSourceList":{"Targets":[".kiro.dev"],"TargetTypes":["HTTP_HOST","TLS_SNI"],"GeneratedRulesType":"ALLOWLIST"}}}' \ --type STATEFUL
補足:
update-rule-groupを実行するには、事前にdescribe-rule-groupで取得したUpdateTokenの指定が必須です。これは楽観的ロック機構で、他の更新との競合を防ぎます。
VPC エンドポイントポリシー / Data Perimeter への影響
PrivateLink を利用しているかどうかで対応が異なります。
PrivateLink / VPC エンドポイントを利用していない場合
SCP や VPC エンドポイントポリシーで aws:SourceVpce や aws:PrincipalOrgID 条件を使って通信先を制限している場合でも、Kiro の kiro.dev ドメインへの通信はインターネット（NAT Gateway）経由となるため、VPC エンドポイントポリシーの対象外です。ファイアウォールや Security Group で kiro.dev への HTTPS アウトバウンドが許可されていることを確認してください。
Kiro の VPC エンドポイント / Private DNS を利用している場合
Kiro の VPC エンドポイントで Private DNS を有効にしている環境では、runtime.<region>.kiro.dev、management.<region>.kiro.dev、telemetry.<region>.kiro.dev は既存の VPC エンドポイント経由で自動的に名前解決されます。そのため、追加の VPC エンドポイント作成は不要です。
ただし、ファイアウォールや Route 53 Resolver DNS Firewall で q.<region>.amazonaws.com のみを明示的に許可している場合は、*.kiro.dev も許可対象に追加してください。
Data Perimeter の整理
- VPC エンドポイントポリシー
PrivateLink 未使用の場合、Kiro のkiro.devドメインへの通信には影響しない（インターネット経由のため）。PrivateLink 利用時は既存エンドポイント経由で到達可能 - Security Group / NACL
アウトバウンドで HTTPS（443）が許可されていれば問題なし - NAT Gateway 経由の通信
DNS 解決と HTTPS アウトバウンドが許可されていることを確認 - Route 53 Resolver DNS Firewall
kiro.devドメインをブロックリストに入れている場合は除外が必要
疎通確認の手順
設定変更後、以下のコマンドで新エンドポイントへの疎通を確認できます。実際に手元の環境で試してみました。
DNS 解決の確認
nslookup runtime.us-east-1.kiro.dev
投入結果
% nslookup runtime.us-east-1.kiro.dev Server: 2001:xxxx:xxxx::x Address: 2001:xxxx:xxxx::x#53 Non-authoritative answer: Name: runtime.us-east-1.kiro.dev Address: 32.196.245.245 Name: runtime.us-east-1.kiro.dev Address: 3.229.221.164
DNS が正常に解決できていれば OK です。NXDOMAIN や SERVFAIL が返る場合は、Route 53 Resolver DNS Firewall や社内 DNS でブロックされている可能性があります。
HTTPS 接続の確認（TLS ハンドシェイクまで）
curl -sv https://runtime.us-east-1.kiro.dev 2>&1 | head -20
投入結果
% curl -sv https://runtime.us-east-1.kiro.dev 2>&1 | head -20 * Host runtime.us-east-1.kiro.dev:443 was resolved. * IPv6: (none) * IPv4: 32.196.245.245, 3.229.221.164 * Trying 32.196.245.245:443... * Connected to runtime.us-east-1.kiro.dev (32.196.245.245) port 443 * ALPN: curl offers h2,http/1.1 * (304) (OUT), TLS handshake, Client hello (1): } [331 bytes data] * CAfile: /etc/ssl/cert.pem * CApath: none * (304) (IN), TLS handshake, Server hello (2): { [88 bytes data] * (304) (OUT), TLS handshake, Client hello (1): } [364 bytes data] * (304) (IN), TLS handshake, Server hello (2): { [155 bytes data] * (304) (IN), TLS handshake, Unknown (8): { [19 bytes data] * (304) (IN), TLS handshake, Certificate (11): { [3818 bytes data]
Connected to ... と表示され、TLS ハンドシェイクが進行していれば、ネットワーク的な到達性は問題ありません。ここで Connection refused や Connection timed out になる場合は、ファイアウォールや Security Group でアウトバウンド 443 がブロックされています。
複数エンドポイントの一括確認
for endpoint in \ app.kiro.dev \ runtime.us-east-1.kiro.dev \ management.us-east-1.kiro.dev \ telemetry.us-east-1.kiro.dev \ prod.download.desktop.kiro.dev; do echo -n "$endpoint: " curl -so /dev/null -w "%{http_code}" "https://$endpoint" 2>/dev/null || echo "FAILED" echo "" done
投入結果
app.kiro.dev: 200 runtime.us-east-1.kiro.dev: 404 management.us-east-1.kiro.dev: 404 telemetry.us-east-1.kiro.dev: 403 prod.download.desktop.kiro.dev: 403
結果の読み方：
- 200 — 正常にアクセス可能
- 403 / 404 — HTTP レスポンスが返っている = ネットワーク的には到達できている。これらのエンドポイントは認証付きの API アクセスを前提としているため、ブラウザや curl で直接叩くと 403（Forbidden）や 404（Not Found）が返るのは正常な挙動です
- FAILED / 000 — TCP 接続自体が失敗している。ファイアウォールでブロックされている可能性が高い
つまり、HTTP ステータスコードが何かしら返ってくれば疎通は成功と判断できます。FAILED が出た場合のみ、ネットワーク設定の見直しが必要です。
まとめ
今日は 5月8日なので、期限まであと 1 週間 です。
対応内容はシンプルで、ファイアウォールの許可リストに *.kiro.dev（またはドキュメントに記載された個別ドメイン）を追加するだけです。ネットワーク管理者やインフラチームの方は、ぜひ早めにご確認ください。
エンタープライズ環境では、Network Firewall のドメインリストや Route 53 Resolver DNS Firewall のルールも忘れずに確認してください。Kiro の VPC エンドポイント / Private DNS を利用している場合は、追加の VPC エンドポイント作成は不要ですが、DNS Firewall 等で *.kiro.dev の許可を忘れないようにしましょう。
個人利用でファイアウォール制御をしていない方は、特に何もしなくて大丈夫です。Kiro を更新すれば自動的に新しいエンドポイントに切り替わります。
参考ドキュメント：
Configuring a firewall, proxy server, or data perimeter for Kiro
以上です。
