Azure

冒頭まとめ Azure で 502 Bad Gateway を受け取る場面は、Application Gateway を前段に置いた構成に集中します。表示される文言も定型で、要求を取り次いだ側が背後から正しい応答を得られなかった、という趣旨のものです。 公式のトラブルシューティング文書は、このエラーの原因を明確に列挙しています。ネットワークの遮断規則・利用者定義の経路・独自の名前解決による遮断、既定の正常性確認が背後に届かないこと、独自の正常性確認の設定不備、背後の一覧が未設定または空であること、一覧の中に正常な相手が1つも無いこと、要求の時間切れや接続の問題、そして背後の証明書が一致しないことです。 並べてみると、多くが1点に帰着します。背後が正常だと判定されていない、ということです。同じ文書には、一覧内のすべてが正常でないと判定された場合、要求は転送されず 502 が返る、と明記されています。したがって調査の起点は、設定ファイルではなく背後の正常性の状態です。 もう1つ、時間に関する記述があります。要求を受け取った Application Gateway は、背後からの応答を一定時間待ちます。既定は20秒です。そして「v1 では、この時間内に応答が返らないと利用者は 502 を受け取る」と、版を明示したうえで書かれています。版を明示しているということは、別の版では同じ状況が同じ結果にならない可能性がある、ということです。自分の環境がどちらの版かを先に確認してください。 エラーの概要 利用者側には定型の文言が表示されます。応答が無効だった、という趣旨のものです。 Server Error: 502 - Web server received an invalid response while acting as a gateway or proxy server. 判断の材料は、この画面ではなく背後の正常性の状態です。公式文書には、一覧内のすべてが正常でないと判定された場合に 502 が返ることと、詳細を示す欄に表示される内容から調査を始めるべきことが書かれています。 正常性の確認の既定の挙動も定義されています。確認の要求は <プロトコル>://127.0.0.1:<番号> の形で送られ、番号とプロトコルは設定から引き継がれます。そして、正常と見なされる応答は 200 から 399 までの状態コードだけです。この範囲外を返すパスを確認先にしていると、背後が正しく動いていても正常でないと判定されます。 まず最初に：背後の正常性を見る 第一に、背後の正常性の状態を確認します。すべてが正常でないと判定されていれば、原因はそこにあります。アプリケーションの中身を調べる前に、判定が通るようにしてください。 第二に、詳細を示す欄の内容を読みます。公式文書には、接続を確立できない場合の文言として、確認に使う番号で背後が応答しているかを確かめること、そして遮断の設定が邪魔していないかを確かめることが挙げられています。 第三に、正常と判定されているのに 502 が出る場合を分けて考えます。この場合、判定は通っているので、疑うのは実際の通信の側です。証明書の不一致や、名前の扱いの食い違いが候補になります。 よくある原因と解決手順 原因1：遮断の設定で、確認の通信が届いていない 公式文書が最初に挙げている原因です。ネットワークの遮断規則、利用者定義の経路、独自の名前解決のいずれかが、Application Gateway から背後への到達を妨げていると、正常性の確認が失敗し、結果として 502 になります。 同じ文書には、これらの設定が Application Gateway 側の区画にある場合と、背後の機器がある区画にある場合の両方がありうる、と書かれています。片方だけを見て安心しないでください。 さらに、管理用の通信に必要な範囲も決まっています。公式の正常性に関する文書によれば、v1 では 65503 から 65534、v2 では 65200 から 65535 への受信を許可しておく必要があります。この範囲を塞ぐと、背後の設定が正しくても機能しません。 ...

冒頭まとめ Azure で 504 Gateway Timeout を受け取ったとき、出どころは2系統に分かれます。資源の作成や設定変更を受け付ける管理側の窓口が返すものと、利用者からの通信を取り次ぐ中継役が返すものです。前者は Azure Resource Manager、後者は Application Gateway や Azure Front Door などが該当します。 管理側の 504 には、原因を絞り込める特徴があります。文言に、応答しなかったリソースプロバイダの名前が含まれるためです。The gateway did not receive a response from 'Microsoft.Web' within the specified time period. のような形で、Microsoft.Web や Microsoft.App といった名前が入ります。この名前は、どの機能群が応答しなかったかを示します。自分が操作している資源の種類と一致していれば、その資源の担当が遅れています。一致していなければ、内部で呼ばれている別の機能群が遅れています。 最も注意すべき点は2つあります。1つ目は、504 を受け取っても操作が完了している場合があることです。管理側の窓口は要求を受け取って担当へ渡しており、担当の処理は続いています。応答が返る前に取り次ぎ役が待つのをやめただけ、という状況が実際に起きます。 2つ目は、Azure のソフトウェア開発キットの既定の挙動です。共通部分のソースを読むと、再試行の対象となる状態コードは 408・429・500・502・503・504 と定義されています。そのうえで、通常は再送しない POST と PATCH についても、500・503・504 のときだけは再試行する、という例外が明示的に書かれています。つまり、資源を作る要求が 504 で戻った場合、利用者が何もしなくても同じ要求がもう一度送られる可能性があります。 エラーの概要 管理側から返る場合、応答にはコード名と、リソースプロバイダ名を含む文言が入ります。 { "error": { "code": "GatewayTimeout", "message": "The gateway did not receive a response from 'Microsoft.App' within the specified time period." } } 各社の道具を経由している場合も、この文言はそのまま持ち回されます。たとえば構成管理の道具からは、次のような形で表示されます。 ...

エラーの概要 Azure 503 エラーは「Service Unavailable」を意味し、Azureサービスが一時的に利用できない状態を示します。リクエストがサーバーに到達しても、システムの過負荷、メンテナンス、インフラ障害などによってレスポンスを返すことができません。このエラーは一時的な場合が多いため、リトライ戦略を実装することが重要です。 実際のエラーメッセージ例 Azure Portal の HTTP レスポンス： HTTP/1.1 503 Service Unavailable Content-Type: application/json Retry-After: 60 { "error": { "code": "ServiceUnavailable", "message": "The service is currently unavailable. Please try again later.", "target": "App Service" } } Azure CLI からのエラー出力： ERROR: (BadRequest) Service Unavailable: The service is temporarily unavailable. Please retry the request after some time. RequestId: abc123def456 よくある原因と解決手順 原因1：Azureリージョンで障害が発生している Azure のデータセンター障害やメンテナンス作業により、特定のリージョン全体がサービス停止している場合があります。この場合、アプリケーション側での修正では解決できず、Azure のサービス復旧を待つか、別リージョンへの切り替えが必要です。 Before（エラーが起きるコード）： # 単一のリージョンにのみデプロイされている from azure.storage.blob import BlobServiceClient account_url = "https://mystorageaccount.blob.core.windows.net" blob_service_client = BlobServiceClient(account_url=account_url) try: container_client = blob_service_client.get_container_client("mycontainer") blobs = container_client.list_blobs() except Exception as e: print(f"Error: {e}") # リージョン障害時は対応策がない After（修正後）： ...

エラーの概要 Azure 409 Conflict エラーは、リソースの現在の状態と API リクエストが競合している場合に発生します。通常、同じ名前のリソースが既に存在する、リソースがプロビジョニング途中である、または削除処理中の状態で新しい操作を実行しようとしたときに返されます。このエラーは Azure Portal、Azure CLI、Azure PowerShell、REST API など複数のインターフェースで発生する可能性があります。 実際のエラーメッセージ例 Azure REST API レスポンス： { "error": { "code": "Conflict", "message": "The resource 'myStorageAccount' already exists in the resource group 'myResourceGroup'.", "status": "409" } } Azure CLI の出力： (Conflict) The storage account myStorageAccount already exists. Code: Conflict Message: The storage account myStorageAccount already exists. よくある原因と解決手順 原因1：同じ名前のリソースが既に存在する 同じ名前のリソース（ストレージアカウント、App Service、Cosmos DB など）が既に同じリソースグループ内に存在すると、新規作成時に 409 Conflict が発生します。Azure の多くのリソースはグローバルに一意な名前を要求するため、他のリソースグループや他のサブスクリプションの同名リソースも競合の原因となります。 Before（エラーが起きるコード）： az storage account create \ --name myStorageAccount \ --resource-group myResourceGroup \ --location eastus After（修正後）： ...

エラーの概要 429 Too Many Requests エラーは、Azure API がスロットリング制限に達したことを示す HTTP ステータスコードです。Azure では、各サブスクリプションと API に対して一定期間内のリクエスト数に上限を設定しており、この制限を超えたときに発生します。特に、自動化スクリプトやバッチ処理でループ内から大量のリクエストを送信する場合に頻繁に見られます。 実際のエラーメッセージ例 Azure REST API の直接呼び出しで見られる典型的なレスポンス： { "error": { "code": "SubscriptionThrottled", "message": "The subscription is throttled for the following operation: Microsoft.Compute/virtualMachines/write. Please try after 30 seconds." } } Azure SDK（Python）で発生した場合のコンソール出力： azure.core.exceptions.HttpResponseError: (429) Throttling error. Subscription has exceeded throttling limits for operation 'Microsoft.Storage/storageAccounts/write'. Retry after 60 seconds. よくある原因と解決手順 原因1：リクエストレートが上限を超えている Azure には、API ごと・操作ごと（例：仮想マシン作成、ストレージ読み書き）に一定秒あたりのリクエスト数制限があります。制限値はサブスクリプション、リージョン、リソースの種類によって異なり、ループ内で連続して API を呼び出すと瞬時に制限に達します。 Before（エラーが起きるコード）： from azure.identity import DefaultAzureCredential from azure.mgmt.compute import ComputeManagementClient credential = DefaultAzureCredential() client = ComputeManagementClient(credential, "<subscription_id>") # 50 台の VM を一気に作成しようとする for i in range(50): client.virtual_machines.begin_create_or_update( "<resource_group>", f"vm-{i}", vm_config ) After（修正後）： ...

エラーの概要 Azure への API リクエストやコマンド実行時に 401 Unauthorized エラーが返される場合、認証情報が無効であるか期限切れになっていることを示しています。このエラーが発生すると、Azure リソースへのアクセスが完全にブロックされ、デプロイやリソース管理の操作が実行できなくなります。Azure CLI、SDK、マネージド ID など複数の認証方式で発生する可能性があります。 実際のエラーメッセージ例 Azure CLI での出力例： $ az group list ERROR: The command failed with an unexpected status code: 401 (Unauthorized). The command failed with an error. (AuthenticationFailed) Authentication failed. The `Credentials` object was not initialized. Please call `Credentials.Initialize()` before making any requests. REST API レスポンス例： { "error": { "code": "AuthenticationFailed", "message": "Authentication failed. The user or application is not authorized to access the resource.", "details": [ { "code": "Unauthorized", "message": "The request requires authentication information." } ] } } よくある原因と解決手順 原因1：az login のセッションが期限切れになっている Azure CLI の認証セッションには有効期限があります。特に長時間セッションを保持していたり、PC のスリープ後に再度コマンドを実行したりする場合、自動的にセッションが無効化されることがあります。 ...

エラーの概要 Azure リソースへのアクセスが拒否されたことを示す HTTP 403 エラーです。このエラーは、ユーザーやアプリケーションが認証には成功（401 ではなく）したものの、対象リソースに対する操作権限がないことを意味します。Azure では RBAC（ロールベースアクセス制御）、Azure Policy、ネットワーク設定などの複数のレイヤーで権限チェックが行われるため、403 が頻繁に発生します。 実際のエラーメッセージ例 Azure Portal や Azure CLI を通じて 403 エラーが出力される場合、以下のような形式で表示されます。 { "error": { "code": "AuthorizationFailed", "message": "The client 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' with object id 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' does not have authorization to perform action 'Microsoft.Compute/virtualMachines/write' over scope '/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Compute/virtualMachines/<vm-name>'." } } $ az vm create --resource-group <resource-group> --name <vm-name> ... (AuthorizationFailed) The client 'user@example.com' with object id '...' does not have authorization to perform action 'Microsoft.Compute/virtualMachines/write' よくある原因と解決手順 原因 1：RBAC で必要なロールが割り当てられていない Azure RBAC により、ユーザーやサービスプリンシパルに対して明示的にロールを割り当てない限り、リソースへの操作は拒否されます。例えば、仮想マシンの作成には「仮想マシン共同作成者」や「共同作成者」ロールが必要です。サブスクリプションやリソースグループレベルでロールが割り当てられていなければ、その配下のすべてのリソース操作が 403 で拒否されます。 ...

エラーの概要 Azureの404エラーは、APIやポータルからアクセスしようとしたリソースが見つからないことを示すHTTPエラーです。このエラーが発生すると、指定したリソース名、リソースID、あるいはAPIエンドポイントが存在しないか、アクセス権限がない状態を意味します。Azure CLIやREST API、Azure Portalを通じてリソースを操作する際に頻繁に遭遇するエラーであり、原因の特定と対処には体系的なアプローチが必要です。 実際のエラーメッセージ例 Azure CLIの出力例： { "error": { "code": "ResourceNotFound", "message": "The Resource 'Microsoft.Compute/virtualMachines/<vm-name>' under resource group '<resource-group-name>' was not found." } } REST APIレスポンス例： { "code": "NotFound", "message": "The specified blob does not exist.", "details": [] } Azure CLI標準エラー出力例： The resource with id /subscriptions/<subscription-id>/resourceGroups/<rg-name>/providers/Microsoft.Storage/storageAccounts/<account-name> does not exist. (Code: ResourceNotFound) よくある原因と解決手順 原因1：リソース名またはIDの綴りが間違っている Azureのリソース名やリソースIDに入力ミスがあると、404エラーが発生します。特にストレージアカウント名やVirtual Machine名は大文字小文字が区別され、ハイフンやアンダースコアが混在することで綴り間違いが起きやすくなります。また、REST APIで完全修飾リソースID（例：/subscriptions/.../resourceGroups/.../providers/...）を指定する場合、パス内のどこかに誤字があると該当リソースが見つかりません。 Before（エラーが起きるコード）： az vm show --resource-group myResourceGroup --name myVirtualMahine After（修正後）： az vm show --resource-group myResourceGroup --name myVirtualMachine Before（エラーが起きるコード）： curl -X GET \ https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/myRG/providers/Microsoft.Storage/storageAccounts/mystorgeaccount/listKeys?api-version=2023-01-01 \ -H "Authorization: Bearer <access-token>" After（修正後）： ...

エラーの概要 Azure 400エラーは「Bad Request」を意味し、Azure APIへのリクエストに含まれるパラメータや値に誤りがある場合に発生します。これは認証エラーではなく、リクエストの内容そのものが仕様に違反していることを示す重要な信号です。Azure PortalやAzure CLI、REST APIを通じてリソースを作成・更新する際に頻繁に遭遇するエラーであり、適切な対応により確実に解決できます。 実際のエラーメッセージ例 Azure REST APIのレスポンス例： { "error": { "code": "BadRequest", "message": "The value of parameter 'vmName' is invalid.", "details": [ { "code": "InvalidParameterValue", "message": "The name 'my-vm-123456789-toolongname' is longer than the maximum allowed length of 15 characters." } ] } } Azure CLIの出力例： $ az vm create --resource-group myRG --name "invalid@vm#name" --image UbuntuLTS (BadRequest) The name 'invalid@vm#name' does not match the allowed pattern. よくある原因と解決手順 原因1：必須パラメータの不足または型の不正 リクエストに必須のパラメータが含まれていないか、指定した値がAPIが期待するデータ型と異なっている場合に発生します。例えば、リソースIDは文字列型で指定が必須であるのに対し、数値型で送信された場合などが該当します。Azure APIの仕様では厳密な型チェックが行われるため、JSONペイロードの構造確認は必須です。 Before（エラーが起きるコード）： import requests payload = { "properties": { "adminUsername": "azureuser", # adminPassword が不足している "osProfile": { "computerName": "myvm" } } } response = requests.put( "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/myRG/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2021-07-01", headers={"Authorization": f"Bearer {token}"}, json=payload ) After（修正後）： ...

冒頭まとめ Azure の 500 Internal Server Error は、まず「どの URL が返したか」で2系統に分けると迷いません。第一に、Azure の管理 API（management.azure.com への操作）や各サービスの API が返す500で、エラー応答の code は InternalServerError などになります。これは Azure 側の予期しない内部エラーで、手元のリクエストを直して消えるものではありません。Azure の公式 SDK は、408・429・500・502・503・504 を既定の再試行対象とし、既定で合計10回まで再試行する設計になっており（Python 版 SDK の共通基盤 azure-core のソースコードで確認できます）、SDK 経由で500がエラーとして見えた時点で、この再試行はすでに尽きています。第二に、自分がデプロイしたアプリ（App Service）の URL が返す500です。こちらは Azure 側の障害ではなくアプリの調査で、ASP.NET Core の場合は 500.30 のようなサブステータスが失敗の種類まで教えてくれます。 500だと思い込みやすいのに500ではないエラーも先に押さえます。リソースプロバイダーの未登録は、公式トラブルシューティング文書のある MissingSubscriptionRegistration で、実際の応答は 409 Conflict です。クォータやスロットリングは 429 系、テンプレートやパラメータの不正は 400 系の検証エラー、権限不足は 403 の AuthorizationFailed です。「プロバイダー未登録で500」「クォータ超過で500」という説明は Azure の実際の応答と一致しません。 エラーの概要 Azure の管理 API のエラーは、error オブジェクト（code と message）を持つ JSON で返ります。500の場合の code は InternalServerError などで、message は一時的なエラーである旨と再試行の案内になっているのが典型です。切り分けでまず読むべきは HTTP のコードではなく、この code フィールドです。MissingSubscriptionRegistration や AuthorizationFailed のような具体的な code が入っているなら、それは500の調査ではありません。 もう1つ、Azure の応答には必ず控えるべきヘッダーがあります。x-ms-request-id と x-ms-correlation-request-id です（実際のエラー応答の記録でも、この2つのヘッダーが含まれていることが確認できます）。この値は Azure 側のログでリクエストを特定する参照 ID で、500が再現・継続する場合にサポートへ渡す情報の中核になります。 ...