AWS

エラーの概要 AWS の 403 エラーは、HTTP ステータスコード 403 Forbidden として返されます。これは認証には成功したものの、実行しようとしている操作に対する IAM (Identity and Access Management) 権限が不足していることを意味します。AWS リソースへのアクセス、API 呼び出し、AWS マネジメントコンソール上での操作など、様々な場面で発生する一般的なエラーです。 実際のエラーメッセージ例 AWS CLI でよく見かける 403 エラーレスポンスを示します。 { "Error": { "Code": "AccessDenied", "Message": "User: arn:aws:iam::123456789012:user/john-dev is not authorized to perform: s3:GetObject on resource: arn:aws:s3:::my-bucket/config.json" } } また、AWS マネジメントコンソール上では、より簡潔なエラーが表示されることもあります。 User: arn:aws:iam::123456789012:user/jane-admin is not authorized to perform: ec2:DescribeInstances on resource: * よくある原因と解決手順 原因 1：IAM ポリシーに必要な Action が含まれていない IAM ポリシーに、実行したい操作（Action）が明示的に許可されていない場合、403 エラーが発生します。例えば S3 バケットから読み取りはできるが、アップロード（PutObject）が許可されていない状況が典型的です。 Before（エラーが起きる IAM ポリシー）： { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": "arn:aws:s3:::my-bucket/*" } ] } このポリシーでは GetObject（読み取り）のみが許可されているため、PutObject でアップロードしようとするとアクセス拒否されます。 ...

エラーの概要 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）。 ...