AWS

この記事にはアフィリエイト広告が含まれています。 冒頭まとめ AWSのエラーを検索して1件ずつ直しているのに、翌日は別のサービスで同じような壁に当たる。この繰り返しから抜けるには、覚える順序を変える必要があります。 AWSのエラーの多くは、4つの境界のどこかで起きています。誰として呼んでいるかという境界、何を許されているかという境界、自分の権限とサービスへ渡した権限の境界、そしてネットワークの到達性の境界です。エラー文はこの境界のどれで止まったかを示していますが、境界の存在を知らないと文言が読めません。 DockerやTerraformとの違いは、AWSがサービスの集まりであり、覚えるべきサービスの数に終わりがないことです。だからサービスを1つずつ潰す学び方は成立しません。代わりに、どのサービスでも共通して働く仕組みを先に押さえます。認証、認可、リージョン、ネットワーク、制限。この5つはS3でもLambdaでもRDSでも同じ形で現れます。 学ぶ順序は、認証情報とリージョン、IAMの評価順序、サービスへ渡す権限、ネットワークの到達性、制限と再試行、トラブルシューティングの6段階です。各段階には「次へ進む目安」を置きました。飛ばした段階は、後の段階のエラーとして別の顔で現れます。 個別に直すだけでは理解しにくい理由 検索で見つかる対処は、多くの場合その環境で有効だった手順です。なぜ有効だったかは書かれていないことがあります。 たとえば、アクセスが拒否されたときに管理者相当のポリシーを付けたら通った、という手順があります。確かにエラーは消えます。しかし何が足りなかったのかは分からないままです。次に同じ構成を作るとき、同じ広い権限を付けることになります。 同じことがネットワークでも起きます。繋がらないのでセキュリティグループを全開放したら通った、という手順は、どこで止まっていたのかを教えてくれません。セキュリティグループが原因だったのか、ルートテーブルが原因だったのかも区別できていません。 エラー文も同じです。AWSの拒否は、認証に失敗したのか、認証は通ったが許可がないのか、そもそも別のリージョンを見ているのかを示しています。この区別は、次に説明する全体像を知っていれば読み取れます。 最初に理解するべきAWSの全体像 先に、すべてのAWS操作が通る道筋を押さえます。ここを飛ばすと、後のすべての段階で判断がぶれます。 どのサービスへの操作も、同じ形をしています。まず、どの認証情報を使うかが決まります。次に、その認証情報が誰を表すのかが確定します。そのうえで、その相手にその操作が許されているかが判定されます。許されていれば、指定されたリージョンのそのサービスへ要求が届きます。 この道筋のうち、最初の2つと3つ目は別物です。認証情報が正しくても許可がなければ拒否されます。逆に、許可を持つ役割があっても、使っている認証情報が別人のものなら意味がありません。エラーを見るときは、この2つを分けて考えてください。 リージョンも独立した境界です。多くのサービスはリージョンごとに分かれており、東京リージョンで作ったものは大阪リージョンからは見えません。「作ったはずのものが一覧に出てこない」という症状は、リージョンの取り違えであることがよくあります。 まずは手元の環境が誰として動いているかを確認してください。 aws sts get-caller-identity aws configure list get-caller-identity は、いま使われている認証情報がどのアカウントの誰を表すかを返します。ここが想定と違えば、この先の調査はすべて無駄になります。 学習ステップ1：認証情報とリージョン 何を理解する段階か：認証情報がどこから読まれるか、そしてその優先順位です。 なぜエラー解決に必要か：手元では通るのに継続的インテグレーションでは拒否される、という症状の大半はここです。環境ごとに使われている認証情報が違います。 最低限覚える概念：公式ドキュメントによれば、AWS CLIはシステムやユーザーの環境変数、ローカルの設定ファイル、コマンドラインのパラメーターなど複数の場所にある認証情報と設定を使い、場所によって優先順位があります。優先順位は上から順に、コマンドラインオプション、環境変数、CLIの認証情報ファイル、CLIの設定ファイル、コンテナの認証情報、そしてEC2インスタンスプロファイルの認証情報です（Configuration settings and precedence）。 この順序が重要です。環境変数に古いキーが残っていると、設定ファイルを正しく直しても環境変数が優先されます。「設定を直したのに変わらない」という状況の典型です。 同じページには、認証情報ファイルと設定ファイルの両方に同じ名前のプロファイルがある場合、認証情報ファイルの値が優先されるという記述もあります。 実際に試すコマンド： # いま使われている認証情報の持ち主を確認する aws sts get-caller-identity # 各設定値がどこから来ているかを確認する（type 列に出所が出る） aws configure list # 環境変数に値が残っていないかを確認する env | grep -i "^AWS_" # プロファイルを明示して実行する aws sts get-caller-identity --profile <プロファイル名> # 現在のリージョンを確認する aws configure get region aws configure list の出力は、値そのものではなく出所を示します。env と出ていれば環境変数、shared-credentials-file と出ていればファイルから読まれています。ここを見れば、どこを直せばよいかが決まります。 ...

冒頭まとめ ELB の 504 Gateway Timeout を調べるとき、最初にやるべきことは原因の推測ではありません。その 504 を、ロードバランサが作ったのか、ターゲットが返したのかを確定させることです。 この2つは、調べる場所がまったく違います。前者ならロードバランサとターゲットの間の話、後者ならターゲットの内側の話です。にもかかわらず、クライアントから見える応答は同じ 504 です。 判定は一瞬で終わります。アクセスログの target_status_code を見るだけです。公式文書によれば、この欄はターゲットへの接続が確立され、かつターゲットが応答を返した場合にのみ記録され、それ以外は - になります。つまり elb_status_code が 504 で target_status_code が - ならロードバランサ生成、両方 504 ならターゲット自身が返した 504 です。多段構成でターゲット側に別の中継役がいる場合、後者になります。 ロードバランサ生成だった場合、原因は公式に6つ挙げられています。関わるタイマーは2種類で、接続を確立するまでの10秒と、応答を待つ idle timeout（既定60秒）です。前者は変更できません。 なお、よく混同されますが、ターゲット側の keep-alive がロードバランサの idle timeout より短い場合に返るのは 504 ではなく 502 です。公式の 502 の説明にその条件が明記されています。 エラーの概要 アクセスログの1行から読み取れる情報が、このエラーの診断の中心です。 https 2026-08-03T12:00:00.000000Z app/my-alb/50dc6c495c0c9188 203.0.113.10:54321 10.0.1.23:8080 0.001 -1 -1 504 - 512 0 "GET https://example.com:443/report HTTP/1.1" 読むべき欄は3つです。 elb_status_code が 504。target_status_code が -。この2つが揃えば、ロードバランサが生成した 504 です。 ...

エラーの概要 AWSの409（Conflict）エラーは、リクエストの内容がAWSリソースの現在の状態と競合していることを示します。このエラーはS3、EC2、DynamoDB、CloudFormation、IAMなど複数のAWSサービスで発生し、リソースが完了していない状態遷移中であったり、既に同じ名前のリソースが存在していたりするときに返されます。一時的な問題か永続的な設定ミスかを判別することが解決の第一歩となります。 実際のエラーメッセージ例 S3バケット作成時: { "Error": { "Code": "BucketAlreadyExists", "Message": "The requested bucket name is not available. The bucket namespace is shared by all AWS accounts." }, "ResponseMetadata": { "HTTPStatusCode": 409 } } EC2インスタンス操作時: { "Error": { "Code": "InvalidInstanceID.Transitional", "Message": "The instance ID 'i-1234567890abcdef0' is in a transitional state and cannot be modified at this time." }, "ResponseMetadata": { "HTTPStatusCode": 409 } } DynamoDBテーブル操作時: { "Error": { "Code": "ResourceInUseException", "Message": "Cannot update a table while an update is in progress" }, "ResponseMetadata": { "HTTPStatusCode": 409 } } よくある原因と解決手順 原因1：S3バケット名がグローバルに重複している S3のバケット名はAWS全体で一意である必要があります。既に別のAWSアカウントが使用しているバケット名を指定すると409エラーが発生します。 ...

エラーの概要 AWS における 422 Unprocessable Entity は、HTTP リクエストの形式は正しいが、含まれるデータが処理不可能または検証に失敗したことを示します。CloudFormation、API Gateway、Lambda、EventBridge、DynamoDB など複数のAWSサービスで発生する可能性があります。このエラーが返されるのは、リクエストの構文は valid だが、ビジネスロジックレベルでの矛盾や制約違反があるためです。 実際のエラーメッセージ例 CloudFormation で展開時に発生する 422 エラー: { "message": "Template error: instance of Fn::GetAtt references undefined resource", "code": "ValidationError", "statusCode": 422 } API Gateway を経由した Lambda 呼び出しでのエラーレスポンス: { "message": "Invalid request body: required field 'userId' is missing", "errorType": "UnprocessableEntity", "statusCode": 422 } よくある原因と解決手順 原因1: CloudFormation テンプレートのリソース参照ミス CloudFormation スタックをデプロイする際、テンプレート内で存在しないリソースを参照している場合に 422 が返されます。Fn::GetAtt や Ref を使用してリソース間の依存関係を記述しているとき、参照先のリソース名が誤っていたり、そのリソースが定義されていなかったりすることが原因です。 Before（エラーが発生する例）: Resources: MyLambdaRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: lambda.amazonaws.com Action: sts:AssumeRole MyLambda: Type: AWS::Lambda::Function Properties: Runtime: python3.11 Handler: index.handler Role: !GetAtt NonExistentRole.Arn Code: ZipFile: | def handler(event, context): return 'Hello' After（修正後）: ...

冒頭まとめ AWS の 504 Gateway Timeout は、リクエストを中継するコンポーネントが、その先からの応答を待ちきれずに打ち切ったことを示します。対処を決めるのは「どの中継役の、どのタイマーで時間切れになったか」です。代表的な発生源は3つです。第一に Application Load Balancer（ALB）で、ターゲットへの接続確立が10秒の接続タイムアウト内に完了しない場合（経路の遮断が典型）と、接続後の応答が idle timeout（既定60秒）内に返らない場合（遅い処理が典型）があります。第二に Classic Load Balancer で、応答が idle timeout を超える場合と、バックエンドの keep-alive が先に切れて接続が閉じられる場合です。第三に API Gateway で、統合タイムアウト（既定29秒）内にバックエンドが応答しない場合に、Endpoint request timed out という504が返ります。 504 は「待った末の時間切れ」であり、接続自体の失敗や不正な応答（502）、ターゲットの未登録（503）とは原因の場所が異なります。まずどのタイマーかを特定し、遅い側を速くするか、待つ側の設定を実態に合わせるかを判断します。 エラーの概要 504 を最初に受け取ったとき、502 との違いを押さえておくと迷いません。502 は「相手から不正な応答を受け取った、または接続に失敗した」、504 は「応答を待ったが時間内に届かなかった」です。同じ「バックエンドの問題」でも、502 は接続や応答の形式、504 は時間が争点になります。 ALB では、504 の記録の形に特徴があります。実際の調査記録に共通するのは、アクセスログで elb_status_code が 504、target_processing_time と response_processing_time が -1、target_status_code が -（空）という形です。これは、ALB がターゲットからの応答を一度も受け取れないままタイムアウトで接続を閉じたことを意味します。API Gateway の場合は、応答本文そのものが手がかりです。 { "message": "Endpoint request timed out" } まず最初に：どのタイマーで時間切れになったかを特定する 発生源ごとに、見るべき記録が決まっています。 ALB 経由なら、CloudWatch の HTTPCode_ELB_504_Count（ALB が生成した504）を確認し、あわせて TargetConnectionErrorCount（接続確立の失敗）と TargetResponseTime（ターゲットの応答時間）を見ます。接続エラーが増えていれば経路の問題（原因1の接続確立側）、応答時間が idle timeout に張り付いていれば処理の遅さ（原因1の応答待ち側）です。 ...

エラーの概要 AWS の HTTP 400 エラーは「Bad Request（不正なリクエスト）」を意味し、AWS API に送信されたリクエストに構文的な誤りや不正なパラメータが含まれている場合に返されます。AWS では API Gateway、S3、DynamoDB、Lambda、IAM など複数のサービスで発生する可能性があり、クライアント側の設定ミスやリクエスト形式の誤りが主な原因となります。 実際のエラーメッセージ例 AWS SDK を使用した場合、以下のようなエラーが出力されます。 { "Error": { "Code": "BadRequest", "Message": "1 validation error detected: Value null at 'instanceIds' failed to satisfy constraint: Member must not be null" } } AWS CLI での例： $ aws s3api put-object --bucket <your-bucket-name> --key test.txt An error occurred (InvalidArgument) when calling the PutObject operation: The authorization header is malformed; the Credential is mal-formed; expecting 'AWS4-HMAC-SHA256 Credential=...' よくある原因と解決手順 原因1：必須パラメータの欠落またはデータ型の誤り なぜ発生するか AWS API は厳密なパラメータ検証を行います。必須パラメータが指定されていない、または文字列型で数値を渡すなどデータ型が異なる場合、400 エラーが返されます。特に DynamoDB や EC2 API では顕著です。 ...

エラーの概要 AWSで401エラーが返される場合、リクエストに含まれる認証情報が無効であることを示しています。AWS API、SDK、CLIのいずれかを使用する際に、アクセスキー、シークレットアクセスキー、セッショントークン、またはIAMロールの認証情報が不正または期限切れの状態で送信されると発生します。このエラーは認証層での問題であり、比較的簡単に解決できるケースがほとんどです。 実際のエラーメッセージ例 AWS CLIを使用した場合： $ aws s3 ls An error occurred (InvalidAccessKeyId.NotFound) when calling the ListBuckets operation: The AWS Access Key Id you provided does not exist in our records. AWS SDK（Python）でのJSONレスポンス例： { "Error": { "Code": "UnrecognizedClientException", "Message": "The security token included in the request is invalid" } } API Gateway経由での呼び出しでのエラー： HTTP/1.1 401 Unauthorized { "message": "Unauthorized" } よくある原因と解決手順 原因1：アクセスキーが無効または存在しない AWS IAMユーザーのアクセスキーが削除されたり、誤入力されたりしている場合に発生します。特に手動で環境変数やConfigファイルに設定した場合は打ち間違いが多いです。 Before（エラーが起きるコマンド）： export AWS_ACCESS_KEY_ID="<your-access-key-id>" export AWS_SECRET_ACCESS_KEY="<your-secret-access-key>" aws ec2 describe-instances After（修正後）： # IAMコンソールで現在のアクセスキーを確認 # または新しいアクセスキーを生成してから設定 export AWS_ACCESS_KEY_ID="<your-access-key-id>" export AWS_SECRET_ACCESS_KEY="<your-secret-access-key>" aws ec2 describe-instances 確認手順は以下の通りです。AWSマネジメントコンソールでIAM→ユーザー→セキュリティ認証情報タブを開き、アクセスキーが有効（Active）な状態であることを確認してください。無効な場合は新しいアクセスキーを生成する必要があります。 ...

エラーの概要 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 という文言で探すのが確実です。 ...