Posts

エラーの概要 AWS の 404 エラーは「Not Found」を意味し、指定したリソースが見つからないことを示します。S3 バケット、EC2 インスタンス、API Gateway、Lambda 関数など、あらゆる AWS サービスで発生する可能性があります。このエラーが返される場合、リソースが存在しない、リソース名が誤っている、別のリージョンに存在している、またはアクセス権限がないなどの原因が考えられます。 実際のエラーメッセージ例 S3 へのアクセス時のエラーレスポンス： <?xml version="1.0" encoding="UTF-8"?> <Error> <Code>NoSuchKey</Code> <Message>The specified key does not exist.</Message> <Key>nonexistent-file.txt</Key> <BucketName>my-bucket</BucketName> <RequestId>4TZ432A73F8A1A1A</RequestId> <HostId>SlFydFBhMjMzMzMzL2ZpbGUuanNvbg==</HostId> </Error> AWS CLI でのエラーメッセージ： { "Error": { "Code": "ResourceNotFoundException", "Message": "Could not connect to the endpoint URL: https://dynamodb.<region>.amazonaws.com/" }, "ResponseMetadata": { "RequestId": "12345678-1234-1234-1234-123456789012", "HTTPStatusCode": 404, "HTTPHeaders": { "date": "Thu, 15 Jan 2024 10:30:00 GMT" } } } よくある原因と解決手順 原因 1：リソース名またはリソース ID のスペルが誤っている リソース名に小文字・大文字の違いやハイフンの位置が異なるとエラーが発生します。AWS では大文字小文字を区別するサービスが多いため、タイプミスは高確率で 404 につながります。 Before（エラーが起きる例）： # S3 バケット名が誤っている aws s3 cp myfile.txt s3://my-backet/path/ # Lambda 関数名が誤っている aws lambda invoke --function-name MyLamda output.json After（修正後）： ...

冒頭まとめ AWS の 429 Too Many Requests は「呼び出しすぎ」を示しますが、絞り込みを行った層によって、見えるエラーも対処も変わります。代表は3層です。第一に API Gateway で、レートとバーストの超過、または利用計画（usage plan）の割当量の超過で 429 を返します。第二に Lambda で、同時実行の枠が尽きると TooManyRequestsException（Rate exceeded）の 429 を返します。第三に、Lambda などのコードの中から呼び出している AWS の各サービス API のスロットリングで、こちらは SDK 上では 429 ではなく 400 の ThrottlingException 系として現れることもあります。 共通の第一手は、正しい再試行（ジッター付き指数バックオフ）です。ただし1つ重要な例外があります。利用計画の割当量（1日1万回など期間あたりの上限）を使い切った 429 は、待って再試行しても期間が切り替わるまで直りません。「再試行が効く429」か「割当が尽きた429」かの見極めが、最初の分岐になります。 エラーの概要 3層それぞれの典型的なエラーの形です。 API Gateway が絞り込んだ場合（レート超過、または割当超過）： { "message": "Too Many Requests" } { "message": "Limit Exceeded" } Lambda の同時実行が尽きた場合（呼び出し元に返るエラーの例。実際の報告の形式）： Rate Exceeded. (Service: AWSLambda; Status Code: 429; Error Code: TooManyRequestsException; Request ID: ...) コード内の AWS API が絞り込まれた場合（SDK のエラー。この例では HTTP は 400）： An error occurred (ThrottlingException) when calling the <操作名> operation (reached max retries: 4): Rate exceeded 3つ目のように、AWS のサービス API のスロットリングは HTTP 429 とは限らず、400 の ThrottlingException や TooManyRequestsException として記録されることがあります（SDK の内部では retryable、つまり再試行してよいエラーとして扱われます）。「429」という数字だけを探すと見落とすため、Rate exceeded・Throttling という文言で探すのが確実です。 ...

エラーの概要 AWS における 500 Internal Server Error は、クライアント側のリクエストに問題はないにもかかわらず、AWS サービス側で予期しない障害が発生したことを示します。Lambda 関数の未処理例外やタイムアウト、API Gateway の統合エラー、CloudFormation のスタック操作失敗など、複数のサービスにまたがって発生しうるサーバーサイドの障害です。一時的な AWS 基盤の不具合である場合もありますが、大半はアプリケーションコードや設定の問題に起因します。 実際のエラーメッセージ例 API Gateway 経由での呼び出し時： { "message": "Internal server error", "statusCode": 500 } Lambda の CloudWatch Logs に出力されるスタックトレース： [ERROR] Runtime.UnhandledPromiseRejection: Error: connect ETIMEDOUT 10.0.1.5:5432 Traceback (most recent call last): File "/var/task/handler.py", line 14, in handler result = db.query(sql) TimeoutError: Connection timed out after 3000ms CloudFormation スタック操作失敗時： Resource handler returned message: "Internal Server Error" (RequestToken: ..., HandlerErrorCode: InternalFailure) よくある原因と解決手順 原因1：Lambda 関数の未処理例外 Lambda がエラーをキャッチせずに例外をスローすると、API Gateway は 500 を返します。エラーハンドリングを実装して例外を適切に処理します。 ...

エラーの概要 502 Bad Gateway は、API Gateway や Application Load Balancer（ALB）がバックエンド（EC2、Lambda、ECS など）から不正な応答を受け取った、あるいは応答を得られなかったことを示すエラーです。AWS 環境では、バックエンドサービスの一時的な障害やタイムアウト、リソース不足など複数の原因で発生しやすいステータスコードです。 実際のエラーメッセージ例 API Gateway から返されるレスポンス例： { "message": "502 Bad Gateway" } CloudWatch Logs に記録されるロードバランサーのログ例： [ALB] 2024-01-15T10:23:45Z app/my-app/1234567890abcdef 192.0.2.1:54321 10.0.1.100:8080 0.050 0.100 0 502 - - arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/my-targets/1234567890abcdef "GET http://example.com/ HTTP/1.1" "Mozilla/5.0" - arn:aws:acm:ap-northeast-1:123456789012:certificate/12345678-1234-1234-1234-123456789012 - ecs default - - よくある原因と解決手順 原因1：バックエンドのタイムアウトまたはクラッシュ Lambda 関数や EC2 インスタンス上のアプリケーションが処理中にタイムアウトするか、予期せず停止している場合、ALB や API Gateway は 502 を返します。 Before（タイムアウト設定が不適切）： # Lambda 関数がタイムアウト時間内に完了できない import time def lambda_handler(event, context): time.sleep(35) # デフォルトのタイムアウト 30秒を超える return {"statusCode": 200} After（タイムアウトを延長し、処理を最適化）： ...

冒頭まとめ AWS で 503 Service Unavailable を受け取ったとき、最初に確定すべきなのは「どのコンポーネントが503を返したのか」です。代表的な発生源は3つあります。第一に、Application Load Balancer（ALB）です。公式ドキュメントのとおり、ALB が503を返すのはターゲットグループに登録済みターゲットが存在しない場合です。第二に、Classic Load Balancer で、こちらはロードバランサー自体の一時的な容量不足か、登録インスタンスが存在しない場合です。第三に、S3 などの AWS サービス自体が過負荷の保護として返す503で、S3 では 503 Slow Down という形をとります。 注意すべき誤解が1つあります。「ヘルスチェックに失敗してターゲットが全部 unhealthy になると503になる」という説明を見かけますが、ELB の公式仕様では逆です。登録済みターゲットがすべて unhealthy の場合、ロードバランサーは状態にかかわらず全ターゲットへリクエストを振り分けます（fail open と呼ばれる動作）。つまり全滅時の症状は503ではなく、ターゲット自身が返すエラー（502や504など）として現れます。ALB の503は「unhealthy だから」ではなく「そもそも登録がないから」です。 エラーの概要 503 は「一時的にサービスを提供できない」ことを示すコードですが、AWS の構成ではロードバランサー・マネージドサービス・自分のアプリケーションのどれもが503を返しうるため、コードの数字だけでは原因の場所が分かりません。ALB が自身で生成する503は、ブラウザでは「503 Service Temporarily Unavailable」と表示され、CloudWatch では HTTPCode_ELB_5XX_Count（内訳として HTTPCode_ELB_503_Count）に計上され、ALB のアクセスログでは elb_status_code が 503 になります。逆に、ターゲット（アプリケーション）が返した503は HTTPCode_Target_5XX_Count とアクセスログの target_status_code 側に記録されます。この記録の場所の違いが、発生源を確定する決め手です。 まず最初に：どこが503を返したかを確定する 3つの確認で発生源を特定します。 第一に、CloudWatch メトリクスです。HTTPCode_ELB_503_Count が増えていればロードバランサー自身が生成した503（原因1・2）、HTTPCode_Target_5XX_Count 側ならターゲットのアプリケーションが返した503です（この場合の調査対象はアプリケーション側です）。 第二に、ALB のアクセスログです。elb_status_code = 503 で target_status_code が空（-）なら、リクエストはターゲットに届く前に ALB で503になっています。 第三に、S3 など API 呼び出しでの503なら、エラーメッセージ自体に発生源が書かれています。S3 の場合は Status Code: 503 とともに Slow Down という文言が含まれます（原因3）。 ...

冒頭まとめ 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が再現・継続する場合にサポートへ渡す情報の中核になります。 ...

冒頭まとめ Docker の 400 Bad Request は、デーモンまで届いたリクエストの形式や値が不正で、デーモンが処理を始められなかったことを示します。実際の環境で最も多いのは、クライアントとデーモンの API バージョン不一致です。エラー文言が client version <番号> is too new（クライアントが新しすぎる）または too old（古すぎる）なら、これに該当します。新しい CLI やツールと古いデーモンの組み合わせ、CI の Docker-in-Docker 構成、DOCKER_API_VERSION 環境変数の固定ミスが典型です。そのほか、デーモンの API を直接呼び出す場合の壊れた JSON や、設定値の検証で弾かれるケースが400になります。 逆に、400と誤解されやすいが400ではないものも押さえておくと迷いません。Dockerfile の構文エラーはビルド時の解析エラー、compose ファイルの YAML 不正はクライアント側の読み込みエラー、イメージ名の形式違反は invalid reference format としてデーモンに送る前に拒否されます。いずれもデーモンの400応答ではなく、調査の場所が異なります。 エラーの概要 docker コマンドは、裏側で Docker デーモンの API に HTTP リクエストを送るクライアントです。Error response from daemon: で始まるエラーは、リクエストがデーモンまで届いたことを意味します。デーモンは、不正なパラメータに分類されるエラーを 400 として応答する実装になっており（Docker のソースコードで確認できます）、API バージョンの範囲外もこの分類に含まれます。実際の報告に共通する文言は次の2種です。 Error response from daemon: client version 1.52 is too new. Maximum supported API version is 1.43 Error response from daemon: client version 1.41 is too old. Minimum supported API version is 1.44 too new はクライアントの要求する API バージョンがデーモンの上限を超えている状態、too old は逆に、デーモンが受け付ける下限より古い状態です。後者は、Docker Engine のバージョン29が受け付ける最小 API バージョンを引き上げたことに伴い、古いクライアントやツールを使う環境で報告が増えています。 ...

エラーの概要 Dockerで401エラーが発生するのは、レジストリ（Docker Hub、ECR、プライベートレジストリなど）への認証に失敗したときです。認証情報が提供されていない、または提供されていても無効・期限切れの場合に表示されます。特に docker pull、docker push、docker login の実行時によく見られます。 なお、2020年11月以降、Docker Hubの匿名（ログインなし）でのイメージダウンロード数に制限が導入されたため、以前はログインなしで利用できていたパブリックイメージでも、現在は認証が必須になるケースが増えています。 実際のエラーメッセージ例 Error response from daemon: unauthorized: incorrect username or password { "errors": [ { "code": "UNAUTHORIZED", "message": "authentication required", "detail": null } ] } Error response from daemon: Get "https://registry-1.docker.io/v2/": unauthorized: authentication required, 401 よくある原因と解決手順 原因1：Docker Hubへのログインが完了していない Docker Hubのパブリックイメージであっても、ダウンロード数制限により認証が必須になるケースがあります。また、プライベートイメージにアクセスする場合は必ず認証が必要です。 Before（エラーが起きるコード）： # ログインなしで直接pullを実行 docker pull <your-username>/<image-name>:latest After（修正後）： # 最初にDocker Hubにログイン docker login # プロンプトにユーザー名とパスワード（またはPersonal Access Token）を入力 # その後でpullを実行 docker pull <your-username>/<image-name>:latest 原因2：AWS ECRの認証トークンが期限切れ ECRの認証トークンは12時間の有効期限があります。Docker daemonに保存されたトークンが期限切れになると401エラーが発生します。 ...

エラーの概要 Docker の 403 エラーは、認証（ログイン）には成功したものの、対象のリソース（イメージ、レジストリ、ボリューム等）へのアクセス権限がないことを示します。これはプライベートリポジトリへのアクセス、組織内のアクセス制限、または不十分な認証トークンの権限が原因で発生することがほとんどです。Docker CLI、Docker Desktop、または docker push/pull 時に頻繁に遭遇するエラーです。 実際のエラーメッセージ例 Error response from daemon: Head "https://registry-1.docker.io/v2/myuser/myimage/manifests/latest": unauthorized: authentication required 403 Forbidden { "errors": [ { "code": "DENIED", "message": "permission denied", "detail": "requested access to the resource is denied" } ] } docker push myrepo/myimage:tag denied: requested access to the resource is denied よくある原因と解決手順 原因1：Docker Hub のログイン認証が無効または権限不足 なぜ発生するか：Docker CLI がログインしていない状態、または無効なトークンでリポジトリにアクセスしようとすると、403 エラーが返されます。特にプライベートリポジトリの場合、認証なしでのアクセスが拒否されます。 Before（エラーが起きるコマンド） # ログインせずにプライベートリポジトリをプルしようとする docker pull myusername/private-image:latest # または古い認証情報で実行 docker push myrepo/myimage:tag After（修正後のコマンド） ...

冒頭まとめ Docker の 404 は「指定したものが見つからない」ことを示しますが、探した場所によって原因も対処も変わります。系統は3つです。第一に、手元のデーモンが管理する資源が見つからない場合で、No such container: や No such image: という文言になります。第二に、レジストリ（Docker Hub などのイメージ保管先）にリポジトリはあるがタグが見つからない場合で、manifest for … not found という文言になります。第三に、リポジトリ自体にたどり着けない場合で、pull access denied for …, repository does not exist or may require ‘docker login’ という文言になります。この3つ目の文言が「存在しない」と「権限がない」を並記しているのは意図的な設計で、Docker Hub は非公開リポジトリの存在を外部に確認させないため、両者を区別しないエラーを返します。 つまり Docker の404の調査は、エラー文言を読んで「手元」「タグ」「リポジトリ（または権限）」のどれかを確定するところから始まります。 エラーの概要 docker コマンドのエラーで Error response from daemon: と付くものは、Docker デーモンまで指示が届いたうえで、デーモンが処理を拒否したことを示します。デーモンは、コンテナやイメージなどの資源が見つからない場合、API 上は 404 として応答し、CLI には No such container: <名前> のような文言で表示されます（この対応は Docker のソースコードで確認できます）。一方、docker pull や docker push でレジストリとやり取りする場合の404は、レジストリ側の応答に由来します。レジストリの標準仕様では、リポジトリ名が不明な場合のエラーコードは NAME_UNKNOWN（repository name not known to registry）で、これも HTTP 404 に対応付けられています。 どの場合も、エラーコードの数字より文言のほうが多くを語ります。以下、文言ごとに切り分けます。 まず最初に：エラー文言で3つに分岐する No such container: <名前> や No such image: <名前> なら、手元のデーモンの中に該当する資源がありません（原因1）。 ...