AWS

冒頭まとめ AWS CLIやboto3で次のエラーが出たら、その処理が参照できる場所に認証情報が見つかっていません。 Unable to locate credentials. You can configure credentials by running "aws configure". まず、エラーが出た環境でaws configure listを実行します。プロファイルを指定しているなら、確認コマンドにも同じ--profileを付けてください。手元のターミナルでは成功しても、DockerやCI、別の実行ユーザーでは設定ファイルも環境変数も異なります。 開発環境では使用するプロファイルとログイン状態、EC2ではインスタンスプロファイル、ECSではタスクロールを確認します。認証情報が見つからない段階なので、S3の権限を増やしてもこのエラーは解消しません。 Unable to locate credentialsの意味 Pythonでは次のように表示されます。 botocore.exceptions.NoCredentialsError: Unable to locate credentials botocoreの例外定義では、NoCredentialsErrorの本文をUnable to locate credentialsとしています。要求に署名する処理は、認証情報がNoneならこの例外を送出します。 これはAWSサービスが返すAccessDeniedとは異なります。署名付きの要求を送るための認証情報を、クライアント側で取得できていない状態です。boto3のクライアントを作成できても、実際にAPIを呼ぶときに初めてエラーが出ることがあります。 AWS CLIに表示されるaws configureの案内は、設定方法の一例です。組織がIAM Identity Centerを使っている場合や、EC2・ECSのロールを利用する場合まで、アクセスキーを手入力する必要があるわけではありません。 最初に取得元とプロファイルを確認する 失敗したコマンドと同じユーザー、同じコンテナ、同じCIのステップで確認します。 aws configure list access_keyとsecret_keyが<not set>なら、その実行条件では取得できていません。値が表示される場合は、TypeとLocationで取得元を確認します。環境変数から取得していればenv、共有認証情報ファイルならshared-credentials-fileなどが表示されます。取得処理自体に問題がある場合は、この確認コマンドもエラーになることがあります。 プロファイルを指定している場合は、次のように同じ指定で調べます。devは実際のプロファイル名に置き換えてください。 aws configure list --profile dev aws sts get-caller-identity --profile dev 後者が成功したら、返されたAccountとArnが想定したアカウントとロールか確認します。成功しても、S3などの個別の操作が許可されているとは限りません。 CLIでは成功し、Pythonだけ失敗する場合は、Pythonが同じプロファイルを使っているか確認します。 import boto3 session = boto3.Session(profile_name="dev") identity = session.client("sts", region_name="ap-northeast-1").get_caller_identity() print(identity["Account"], identity["Arn"]) この例はローカルのdevプロファイルを使う場合の確認です。EC2やECSのロールを使うプログラムでは、プロファイル名を固定せずboto3.Session()で既定の取得経路を使います。 認証情報の優先順位を確認する boto3は複数の取得元を順に調べ、認証情報を取得できたところで探索を止めます。公式の認証情報ガイドには、クライアントやSessionへの明示的な指定、環境変数、AssumeRole、Web Identity、IAM Identity Center、共有ファイル、コンテナ、EC2メタデータなどの順序が記載されています。取得元の種類はバージョンによって追加されるため、単に「環境変数かファイルのどちらか」と考えると、実際の取得元を見落とします。 ...

冒頭まとめ AWS CLIやSDKの実行中に次のエラーが出た場合、使用中の一時的な認証情報が期限切れになっています。 ExpiredToken: The security token included in the request is expired 最初にaws configure listと環境変数を確認し、AWS CLIやSDKがどこから認証情報を取得しているかを特定します。AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_SESSION_TOKENを手動で設定している場合は、3つをまとめて削除し、新しい認証情報を取得してください。 一時的な認証情報を毎回環境変数へコピーする運用では、期限切れが再発します。AWS CLIではロールを指定したプロファイル、EC2ではインスタンスプロファイル、ECSではタスクロールを使い、CLIやSDKに取得と更新を任せる方法へ変更します。 ExpiredTokenの意味 一時的な認証情報は、アクセスキーID、シークレットアクセスキー、セッショントークンの3つで構成され、有効期限があります。AWS IAMの公式文書によると、期限を過ぎた認証情報は再利用できません。 代表的な表示は次のとおりです。 An error occurred (ExpiredToken) when calling the ListBuckets operation: The provided token has expired. The security token included in the request is expired エラー名やHTTP状態コードはサービスによって異なります。STSの共通エラー文書ではExpiredTokenExceptionを403、Amazon S3のエラー文書ではExpiredTokenを400としています。そのため、HTTP状態コードだけで判断せず、ExpiredToken、ExpiredTokenException、説明文を確認してください。 IAMユーザーの長期アクセスキーには、ロールセッションのような有効期限はありません。ただし、無効化や削除は可能です。ExpiredTokenが出た場合は、セッショントークンを含む一時的な認証情報、または有効期限のあるIDプロバイダーのトークンを使っていないか確認します。 認証情報の取得元を確認する まず、AWS CLIが現在どこからアクセスキーなどを取得しているかを確認します。 aws configure list このコマンドは、プロファイル、アクセスキー、シークレットアクセスキー、リージョンの値と取得元を表示します。TypeやLocationがenvや環境変数名になっていれば、環境変数が使われています。セッショントークン自体はこの一覧に通常表示されないため、別に確認します。 LinuxとmacOSでは次のコマンドを使います。 env | grep '^AWS_' PowerShellでは次のコマンドで確認できます。 Get-ChildItem Env:AWS_* AWS_SESSION_TOKENがあれば、環境変数に一時的な認証情報が設定されています。ただし、表示されない場合でも、プロファイル、EC2のインスタンスプロファイル、ECSのタスクロールなどから一時的な認証情報を取得している可能性があります。 有効な認証情報へ更新した後は、呼び出し元も確認します。 aws sts get-caller-identity このコマンドで返るアカウントとARNが想定どおりかを確認してください。期限切れの状態ではこのコマンド自体も失敗するため、更新後の確認に使います。 環境変数の期限切れを直す aws sts assume-roleの結果を環境変数へ手動設定した場合、その値は期限が来ても自動更新されません。古い3要素をすべて削除してから、新しい認証情報を取得します。 ...

冒頭まとめ AWSへのリクエストで次のエラーが出る場合、送信した署名とAWS側が同じリクエストから再計算した署名が一致していません。 SignatureDoesNotMatch The request signature we calculated does not match the signature you provided. Check your key and signing method. 最初に、AWS SDKまたはAWS CLIでも同じ操作が失敗するか確認します。SDKやCLIでは成功するなら、資格情報そのものより、独自に実装した署名処理、リクエストの変更、事前署名URLの使い方に原因がある可能性が高くなります。 AWS CLIでも失敗する場合は、使用中のアクセスキー、プロファイル、リージョン、時刻を確認してください。S3の事前署名URLでは、URL、HTTPメソッド、Content-Typeなどの署名対象が発行時と使用時で一致している必要があります。 SignatureDoesNotMatchの意味 AWS Signature Version 4は、HTTPメソッド、パス、クエリ文字列、見出し、本文の要約値などから署名を作る認証方式です。AWSは署名付きリクエストを受け取ると、受信した内容から署名を再計算して、送られた署名と比較します。 一致しなければ、HTTP 403とSignatureDoesNotMatchが返ります。AWS公式のSigV4トラブルシューティングにも、署名値がAWS側の計算結果と一致しないエラーだと記載されています。 HTTP 403だけを見て、すべてIAM権限の問題と判断してはいけません。Amazon S3では、権限拒否のAccessDeniedも403ですが、SignatureDoesNotMatchは署名不一致を示します。エラーの状態コードだけでなく、コードと本文を確認してください。 IAMポリシーを広げても、誤った署名は正しくなりません。まず署名と資格情報を直し、その後にAccessDeniedが出た場合は必要な権限を調べます。 SDKやCLIでも失敗する場合 AWS CLIがどのプロファイル、アクセスキー、リージョンを使っているか確認します。 aws configure list このコマンドはアクセスキーとシークレットアクセスキーの一部を伏せ、値の取得元も表示します。環境変数、共有資格情報ファイル、指定したプロファイルのどれが使われているかを確認してください。 名前付きプロファイルを使う場合は、対象を明示します。 aws configure list --profile example 資格情報でAWS APIを呼べるかは、次のコマンドでも確認できます。 aws sts get-caller-identity --profile example 想定と違う利用者やロールが表示された場合は、環境変数、プロファイル、実行環境に割り当てたロールを見直します。アクセスキーIDとシークレットアクセスキーが別の組から混ざっていないかも確認してください。 一時的な資格情報を使う場合は、アクセスキーとシークレットアクセスキーに加えてセッショントークンが必要です。AWS公式の署名手順では、X-Amz-Security-Tokenを見出しまたはクエリ文字列へ含めるよう説明されています。 計算機の時刻も確認します。 date -u Windows PowerShellでは次を実行できます。 Get-Date -AsUTC 時刻がずれている場合は、OSの自動時刻設定や時刻同期を有効にします。仮想マシンや休止状態から復帰した環境では、ホストとの時刻同期も確認してください。 手動署名ではCanonical Requestを比較する SDKやCLIを使わずに署名を組み立てている場合は、Canonical RequestとString to Signを確認します。Canonical Requestは、リクエストを署名計算用の決められた形へ並べ直した文字列です。 SigV4のCanonical Requestは、次の要素を改行で連結します。 ...

この記事にはアフィリエイト広告が含まれています。 冒頭まとめ 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）な状態であることを確認してください。無効な場合は新しいアクセスキーを生成する必要があります。 ...