Azure Bastion Developer SKU の接続失敗および Azure Files アップロード失敗について

Yuta Seki 様 ,

投稿ありがとうございます。 状況整理すると、

• Azure Bastion（Developer SKU）だけが Windows VM への接続で **HTTP request timed out（HttpClient.Timeout 30 seconds）**になっている
• 同一 VM／同一利用者／同一ネットワークで Bastion Basic SKU は接続成功
• 同じ時期に Azure Files のアップロードも失敗（クライアントは HTTPS プロキシ環境）

という構図ですね。 以下、公開情報（ご提示ドキュメント）に基づく範囲で、確認観点と進め方をまとめます。

1) Azure Bastion Developer SKU の既知事象/リージョン障害について

ご提示ドキュメント内に、Japan East の Developer SKU に特化した現在の既知障害を直接裏づける記載はありませんでした。 ただし、Developer は 共有インフラで動作し、Basic/Standard/Premium は 専用（dedicated）配置という アーキテクチャ差があります。 そのため、Basic が成功して Developer がタイムアウトという結果は「SKU差・経路差があり得る」ケースとしては整合します。

2) Developer SKU と Basic SKU の通信要件の差異

公開情報から言える差分は主に「アーキテクチャ/前提」の違いです。

• Developer SKU: 開発/テスト向けの 無料SKU。 共有インフラで動作し、（要件として）VNet内の AzureBastionSubnet が不要とされています。 また 同時に 1 VM 接続の制約があります。
• Basic SKU: dedicated deployment。 **AzureBastionSubnet（/26 以上のprefix）**や関連ネットワーク前提が必要です（アップグレード時の説明でも AzureBastionSubnet 必要性が明記）。

このため、Developer と Basic は同じ“Bastion”機能名でも、通信経路・必要な前提が完全一致しない可能性があります。 今回の「Developerのみタイムアウト」は、その可能性を押し上げます。

3) Bastion Developer の接続失敗と Azure Files アップロード失敗の関連可能性

ご提示ドキュメント上、Bastion（Developer）と Azure Files の直接的な依存関係は確認できません。

ただし今回は、

• どちらも HTTPS ベースの通信
• クライアントが HTTPS プロキシ環境
• 同時期に両方が失敗

なので、**共通のネットワーク要因（プロキシ配下での到達/制限/タイムアウト）**があるかは、十分に調査価値があります。 一方で、Basic では Bastion 接続成功しているため、VM側・NSG側だけでは説明しにくく、Developer の通信経路だけがプロキシ/中継の影響を受けているなどの可能性も切り分け対象になります。

4) HTTPS プロキシ環境で注意すべき点（公開情報ベース）

ご提示ドキュメント内に「Developer SKU や Azure Files でプロキシがこうなる」という具体的な既知事象は見当たりませんでした。 そのため、公開情報に沿って実施するなら、次のように **切り分け（どこで失敗しているか）**を重視するのが現実的です。

• Bastion 側は、Azure Bastion リソースの Connection Troubleshoot（Network Watcher）で、どこへどの宛先で到達できているかを確認する
• ファイル転送（Bastion 経由）ではない点は注意 （今回 “Azure Files アップロード” とのことなので、Bastion の file transfer 機能自体とは別経路です。 ただし「失敗点の切り分け」は同じ発想で有効です）

**
5) 追加で取得すべきログ/診断情報（このケースで役立つもの）

Bastion（接続失敗）**

ご提示ドキュメントでは、まず Azure Bastion の診断/ Connection Troubleshoot を推奨しています。

• Azure Bastion Diagnostics / resource diagnostics
• Azure Bastion リソースの Help 内 Connection Troubleshoot の結果
• 可能なら **ブラウザの失敗時のトレース（例：HAR）**や、失敗のUTC時刻、エラーの詳細（Correlation ID等があれば）

※ドキュメント上の推奨手順としては、接続性チェックが主です。

Azure Files（アップロード失敗）

ご提示ドキュメント内に Azure Files の取得ログ手順そのものはありませんでしたが、一般に切り分けには

• クライアント側のエラー詳細
• アップロード要求のタイムアウト/HTTPステータス
• 可能なら ブラウザやツールのトレース（HAR/クライアントログ） が有用です。 加えて、プロキシ側のログが参照できるなら「プロキシで落ちていないか」を確認すると早いです。

6. 共通要因（ネットワーク/サービス側既知事象）を探すための進め方

公開情報ベースの推奨に沿うと、以下が現実的です。

1. Bastion 側は Connection Troubleshoot で失敗地点を特定 Network Watcher の Connection Troubleshoot は「ソース（VMなど）から宛先（FQDN/URI/IP等）へ直接 TCP 接続をチェック」できるため、**“到達できているのにアプリ層で落ちる”**のか **“ 到達自体ができていない”**のかが分かります。
2. プロキシ配下の切り分け 可能なら、同じ操作を
   • プロキシを使わない環境
     • 別プロキシ/別ネットワーク で試し、失敗が追従するか確認（追従すれば共通ネットワーク要因の可能性が上がります）。
3. Bastion Developer の性質を踏まえて確認 Developer は 共有インフラで、また 1 VM at a timeの制約があります。 これらが今回のタイムアウト挙動と噛み合う可能性もあるため、接続タイミングや同時性も確認対象になります。

ご案内した対応方針がお役に立ったか、ぜひ状況をお聞かせいただけますでしょうか。

また、ご不明な点や追加で確認したい事項がございましたら、お気軽にお知らせください。 引き続きサポートさせていただきます。

本回答がお役に立った場合は、同様の事象に遭遇した他のコミュニティメンバーの参考にもなりますので、「Upvote」 をご検討いただけますと幸いです。

Yuta Seki 様

先日ご案内した内容について、ご確認いただけましたでしょうか。

ご案内した情報がお役に立ったかお伺いできれば幸いです。

また、ご不明な点や追加で確認したい事項などございましたら、お気軽にお知らせください。引き続きサポートさせていただきます。

どうぞよろしくお願いいたします。