AWSでEC2インスタンスからS3バケットへアクセスしようとした際に、多くの開発者やオペレーターが一度は遭遇する可能性のあるエラー、それが「Unable to locate credentials」です。このエラーメッセージは文字通り「認証情報が見つかりません」という意味であり、EC2インスタンスがS3に対して「私はあなたにアクセスして良い者です」と名乗るための「身分証明書」を提示できない状態を示しています。
この状況を分かりやすく例えるなら、次のようなイメージです。
あなたの代わりにEC2サーバーくんが、遠く離れたS3バケットという名の「倉庫」に大切な荷物（例えば、ウェブサイトのバックアップファイルやアップロードされた画像など）を置きに行こうとしました。
しかし、倉庫の入り口には厳重な「番人（S3サービス）」が立っています。番人は、入ろうとするEC2くんに対してこう尋ねます。
「あなたは誰ですか？この倉庫に荷物を置くことを許可された身分証明書（認証情報）を見せてください。」
残念ながら、この時のEC2くんは、S3倉庫にアクセスするための正式な身分証明書を持っていませんでした。そのため、番人であるS3に「あなたは許可されていません」と門前払いされてしまったのです。
つまり、「Unable to locate credentials」というエラーは、現在のEC2インスタンスが「S3にファイルを置く、あるいは読み書きする権限」を持っていない、またはその権限を証明するための認証情報を見つけられていない状態にあることを意味します。
この記事では、この「Unable to locate credentials」エラーを根本的に解決するための方法として、AWSのIAM（Identity and Access Management）サービスを活用した「IAMロール」の設定について、初心者の方にも分かりやすく、そして具体的に解説していきます。この記事を最後まで読めば、あなたのEC2インスタンスが自信を持ってS3にアクセスできるようになるはずです。
「認証情報が見つかりません」エラーの技術的な背景
AWSにおいて、あるサービス（今回の場合はEC2）が別のサービス（今回の場合はS3）にアクセスする際には、必ずそのアクセスが正当なものであることを証明する「認証」と、そのアクセスで何が許されているかを定義する「認可」のプロセスが必要になります。
- 認証 (Authentication): 「あなたは誰ですか？」を証明するプロセス。AWSでは、IAMユーザーのアクセスキー/シークレットアクセスキー、一時的なセキュリティ認証情報、そして今回扱うIAMロールなどがこれにあたります。
- 認可 (Authorization): 「あなたは〇〇さんですね。では、あなたは△△という操作を□□というリソースに対して行うことを許可されています」と、許可される操作の範囲を定義するプロセス。これは「IAMポリシー」によって定義されます。
「Unable to locate credentials」エラーは、主に認証の段階で問題が発生していることを示唆しています。EC2インスタンスがS3にアクセスしようとした際に、S3がEC2インスタンスに対して認証情報を求めたにも関わらず、EC2インスタンスがそれを提示できなかった、あるいは見つけられなかったために発生します。
IAMロールとは何か？
この問題の解決策の中心となるのが「IAMロール」です。IAMロールは、特定のユーザーやサービス（今回のEC2インスタンスなど）に対して、AWSリソースにアクセスするための一時的な認証情報と権限を付与するための仕組みです。
IAMユーザーにアクセスキーを付与する方法と似ていますが、IAMロールは特定のエンティティ（人ではなく、AWSサービスや外部アカウントなど）が「引き受ける（Assume）」ことを前提として設計されています。EC2インスタンスにIAMロールを割り当てることで、インスタンス自体が認証情報を持つことなく、そのロールに定義された権限でAWSサービスにアクセスできるようになります。これはセキュリティの観点から非常に推奨される方法です。
提供されたテキストにある通り、この問題を解決するには「このEC2インスタンスは、S3バケットにファイルを置くことを許可されていますよ」という特別な役割（IAMロール）を作成し、その役割をEC2インスタンスに与えてあげる必要があります。
次のセクションでは、具体的にどのようにIAMロールを作成し、EC2インスタンスに割り当てるのか、その手順を詳しく見ていきましょう。
解決策：EC2に「S3へのアクセス許可証（IAMロール）」を与える具体的手順
それでは、EC2インスタンスにS3へのアクセス権限を付与するための具体的な設定手順に進みましょう。この作業は、AWSマネジメントコンソールを使って行います。大きく分けて以下の2つのステップがあります。
- パート1：IAMロール（許可証）を作成する
- パート2：作成したロールをEC2インスタンスに割り当てる
パート1：IAMロール（許可証）を作成する
まず、S3へのアクセス権限を持つ新しいIAMロールを作成します。
ステップ1：IAMの管理画面に移動する
AWSマネジメントコンソールにログインし、画面左上にある検索窓に「IAM」と入力します。検索結果に表示された「IAM」サービスをクリックして、IAMダッシュボードに移動します。
ステップ2：ロールの作成を開始する
IAMダッシュボードの左側メニューから「ロール」をクリックします。
ロールの一覧画面が表示されるので、画面上部にある青い「ロールを作成」ボタンをクリックします。
ステップ3：信頼されたエンティティを選択する
「ロールを作成」画面が表示されます。ここで、このロールをどのようなエンティティ（実体）が引き受けることができるかを定義します。EC2インスタンスにこのロールを使わせたいので、「信頼されたエンティティの種類」として「AWSのサービス」が選択されていることを確認します。
次に、「ユースケース」を選択します。ここで、このロールを使用するAWSサービスを指定します。今回はEC2インスタンスが使用するので、リストの中から「EC2」を選択します。選択したら、画面下部にある「次へ」ボタンをクリックします。
ステップ4：許可ポリシーを追加する
次に、このロールにどのような「権限（許可ポリシー）」を与えるかを定義します。今回の目的はEC2からS3へのアクセスなので、S3関連の権限を持つポリシーを選択します。
「許可ポリシー」という検索ボックスに、「AmazonS3FullAccess」と入力します。
検索結果に「AmazonS3FullAccess」というポリシーが1件表示されるはずです。このポリシーは、S3バケット内のすべてのオブジェクト（ファイル）とバケット自体に対して、読み取り、書き込み、削除など、すべての操作を許可する非常に強力な権限を持っています。
その左側にあるチェックボックスにチェックを入れます。
| ポリシー名 | 権限範囲 | 注意点 |
|---|---|---|
| AmazonS3FullAccess | 指定したAWSアカウント内のすべてのS3バケットに対して、すべての操作（読み取り、書き込み、削除、バケット作成/削除など）を許可します。 | 非常に広範な権限です。セキュリティ上のリスクが高まるため、必要最低限の権限（最小権限の原則）を与えることを強く推奨します。今回のエラー解決には有効ですが、本番環境ではより制限されたポリシーを検討すべきです。 |
| AmazonS3ReadOnlyAccess | 指定したAWSアカウント内のすべてのS3バケットに対して、読み取り操作のみを許可します。 | S3からファイルをダウンロードしたりリストしたりすることはできますが、アップロードや削除はできません。 |
| S3への特定バケットへのアクセス権限を持つカスタムポリシー | 特定のS3バケット、特定のパスに対して、許可したい操作のみを細かく定義できます。 | 最も安全な方法です。IAMポリシーのJSONを記述する必要がありますが、セキュリティを考慮する上で最も推奨されます。 |
今回はエラーを迅速に解決するため、広範な権限を持つ「AmazonS3FullAccess」を使用しますが、本番運用では「最小権限の原則」に基づき、必要な操作のみを許可するポリシーを別途作成・適用することを強く推奨します。
ポリシーを選択したら、画面下部にある「次へ」ボタンをクリックします。
ステップ5：ロールに名前を付けて完了する
最後の画面では、作成するロールの名前や説明、タグを設定します。
「ロール名」に、このロールの目的が分かりやすい名前を入力します。例えば、「EC2-S3-Access-Role」や「MyApplication-S3-Role」など、あなたが管理しやすい名前を付けましょう。
説明（Description）は任意ですが、このロールが何のために使われるのかを簡単に記述しておくと、後から見たときに分かりやすくなります。
タグ（Tags）も任意ですが、リソースの管理やコスト配分に役立ちます。必要に応じて設定してください。
他の設定項目はデフォルトのままで問題ありません。一番下にある青い「ロールを作成」ボタンをクリックします。
これで、「S3にフルアクセスできる権限を持つIAMロール」が完成しました！ IAMのロール一覧画面に戻り、今作成したロールがリストに表示されていることを確認してください。
パート2：作成したロールをEC2インスタンスに割り当てる
IAMロールを作成しただけでは、EC2インスタンスはこのロールを使うことができません。次に、作成したロールを対象のEC2インスタンスに関連付ける作業を行います。これにより、EC2インスタンスがそのロールの権限を引き受けてAWSサービスにアクセスできるようになります。
ステップ1：EC2の管理画面に戻る
AWSマネジメントコンソールの上部にある検索窓から「EC2」と入力し、EC2のダッシュボードに戻ります。
左側メニューの「インスタンス」をクリックし、インスタンス一覧画面を表示します。
ステップ2：インスタンスにロールを関連付ける
インスタンスの一覧から、S3へのアクセス権限を付与したいEC2インスタンスを選択します。（インスタンスIDの左側にあるチェックボックスをクリックします。）
インスタンスを選択すると、画面下部にそのインスタンスの詳細情報が表示されます。画面右上にある「アクション」ボタンをクリックします。ドロップダウンメニューが表示されるので、「セキュリティ」にカーソルを合わせると、さらにサブメニューが表示されます。その中から「IAMロールを変更」を選択します。
ステップ3：ロールを選択して更新する
「IAMロールを変更」画面が表示されます。ここで、このEC2インスタンスに割り当てるIAMロールを選択します。
「IAMロール」というプルダウンメニューをクリックすると、AWSアカウント内に存在するIAMロールのリストが表示されます。このリストの中に、先ほどパート1で作成したロール（例: EC2-S3-Access-Role）が表示されているはずです。そのロールを選択します。
選択したら、画面下部にある青い「IAMロールの更新」ボタンをクリックします。
これで、選択したEC2インスタンスにIAMロールが正常に割り当てられました！ この変更は即座に反映されるため、特別な再起動などは不要です。
設定後の確認とトラブルシューティング
IAMロールの作成とEC2インスタンスへの割り当てが完了したら、実際にEC2インスタンスからS3にアクセスできるか確認してみましょう。
最も簡単な確認方法は、EC2インスタンスにSSHなどで接続し、AWS CLI（Command Line Interface）を使ってS3の操作を試みることです。
確認方法：AWS CLIを使う
EC2インスタンスにAWS CLIがインストールされている必要があります。多くのAMI（Amazon Machine Image）には最初から含まれていますが、もしインストールされていない場合はインストールしてください。
インスタンスに接続後、以下のコマンドを実行して、S3バケットのリストを取得できるか確認します。
aws s3 ls
このコマンドがエラーなく実行され、あなたのAWSアカウント内のS3バケットのリストが表示されれば、正しく権限が設定され、EC2インスタンスがS3にアクセスできるようになったことを意味します。
特定のバケットの内容を確認したい場合は、以下のコマンドを実行します。（your-bucket-name は実際のバケット名に置き換えてください）
aws s3 ls s3://your-bucket-name/
ファイルの内容をダウンロードしたり、ファイルをアップロードしたりするコマンドも試してみると良いでしょう。
# S3からファイルをダウンロード
aws s3 cp s3://your-bucket-name/path/to/your/file /local/path/
# ローカルからS3にファイルをアップロード
aws s3 cp /local/path/to/your/file s3://your-bucket-name/path/
これらのコマンドが正常に実行できれば、「Unable to locate credentials」エラーは解消され、EC2インスタンスからS3へのアクセスが可能になったと判断できます。
トラブルシューティング：それでもエラーが出る場合
IAMロールの設定は正しく行ったはずなのに、まだ「Unable to locate credentials」エラーが表示される場合、他の原因が考えられます。以下に、確認すべきポイントをいくつか挙げます。
| 確認ポイント | 確認方法 / 考えられる原因 |
|---|---|
| IAMロールが正しくインスタンスに割り当てられているか | EC2インスタンスの詳細画面で、「IAMロール」の項目に作成したロール名が表示されているか確認します。割り当てが反映されるまでにわずかな時間がかかる場合もあります。 |
| IAMロールのポリシーにS3へのアクセス権限が含まれているか | IAMロールの詳細画面で、アタッチされているポリシー（例: AmazonS3FullAccess）を確認し、そのポリシーがS3への必要なアクション（s3:* や s3:GetObject, s3:PutObject など）を許可しているか確認します。 |
| EC2インスタンスがインターネットに接続できているか | S3へのアクセスにはインターネット接続が必要です（VPCエンドポイントを使用している場合を除く）。EC2インスタンスのセキュリティグループやネットワークACL、ルートテーブルの設定を確認し、アウトバウンド通信が許可されているか確認します。特にS3のリージョンエンドポイントへのHTTPS通信（ポート443）が許可されている必要があります。 |
| AWS CLIやSDKのバージョンが古い、または設定ファイルに問題がある | EC2インスタンス内でAWS CLIやSDKを使用している場合、古いバージョンだとIAMロールからの認証情報取得に問題がある場合があります。また、~/.aws/credentials や ~/.aws/config ファイルに、IAMユーザーのアクセスキーなどが誤って設定されていないか確認します。IAMロールを使用する場合、これらのファイルに認証情報を記述する必要はありません。環境変数 AWS_ACCESS_KEY_ID や AWS_SECRET_ACCESS_KEY が設定されていないかも確認します。これらの設定があると、IAMロールよりも優先される場合があります。 |
| S3バケットポリシーやACLによる制限 | S3バケット自体に設定されているバケットポリシーやACL（Access Control List）によって、特定のプリンシパル（今回の場合はEC2インスタンスのIAMロール）からのアクセスが拒否されている場合があります。S3バケットの設定も確認が必要です。 |
| EC2インスタンスプロファイルが一時的に利用できない状態になっている | 稀なケースですが、EC2インスタンスメタデータサービス（インスタンスが自身の情報やIAMロールの認証情報を取得する仕組み）に一時的な問題が発生している可能性もゼロではありません。インスタンスの再起動で解消される場合もあります。 |
これらのポイントを一つずつ確認していくことで、エラーの原因を特定し、解決に繋げることができます。特にAWS CLIやSDKを使用している場合は、環境変数や設定ファイルに意図しない認証情報が設定されていないかを重点的に確認してください。IAMロールを使用する場合、インスタンスはメタデータサービスを通じて自動的に一時的な認証情報を取得するため、手動で認証情報を設定する必要はありません。
セキュリティの観点：最小権限の原則
前述の通り、今回のエラー解決のために「AmazonS3FullAccess」というポリシーを使用しましたが、これはS3に対する非常に広範な権限を付与するものです。本番環境でこのポリシーを安易に使用することは、セキュリティ上のリスクを高める可能性があります。
AWSにおけるセキュリティのベストプラクティスとして「最小権限の原則（Principle of Least Privilege）」があります。これは、ユーザーやサービスに対して、そのタスクを実行するために必要最低限の権限のみを与えるべきという考え方です。
例えば、EC2インスタンスがS3バケットにファイルをアップロードするだけであれば、「s3:PutObject」や「s3:ListBucket」といった特定の操作のみを許可するカスタムポリシーを作成し、それをIAMロールにアタッチする方が安全です。これにより、もしインスタンスが侵害されたとしても、攻撃者がS3内のすべてのデータを削除したり、機密情報を読み取ったりするリスクを最小限に抑えることができます。
「AmazonS3FullAccess」ポリシーは検証や一時的な利用には便利ですが、本番環境では必ず必要最低限の権限を持つカスタムポリシーに置き換えることを強く推奨します。
カスタムポリシーの作成にはIAMポリシーのJSON構文を理解する必要がありますが、AWSの公式ドキュメントには多くの例が提供されており、学習リソースも豊富にあります。安全なクラウド環境を構築するためには、ぜひ最小権限の原則に基づいたポリシー設計を心がけてください。
IAMロールとインスタンスプロファイルの詳細
EC2インスタンスにIAMロールを割り当てる際に、内部的には「インスタンスプロファイル」という概念が関わっています。
この仕組みにより、EC2インスタンスのファイルシステム上に恒久的な認証情報（IAMユーザーのアクセスキーなど）を保存する必要がなくなります。これは、認証情報が漏洩するリスクを大幅に低減するため、セキュリティ上非常に優れています。AWS SDKやAWS CLIは、EC2インスタンス上で実行されていることを検出すると、自動的にインスタンスメタデータサービスに問い合わせて一時的な認証情報を取得しようとします。「Unable to locate credentials」エラーは、この自動的な認証情報取得プロセスが何らかの理由で失敗した場合にも発生します。
今回の手順でIAMロールを作成し、EC2インスタンスに割り当てることで、インスタンスプロファイルが正しく設定され、EC2インスタンスがS3アクセスに必要な一時的な認証情報を取得できるようになります。
まとめ：エラー解決と次へのステップ
この記事では、EC2インスタンスからS3へのアクセス時に発生する「Unable to locate credentials」エラーの原因と、その最も一般的な解決策であるIAMロールの設定方法について詳しく解説しました。
- 「Unable to locate credentials」エラーは、EC2インスタンスがS3にアクセスするための認証情報を見つけられないために発生します。
- この問題を解決する最も推奨される方法は、IAMロールを作成し、必要なS3アクセス権限（ポリシー）を付与し、そのロールをEC2インスタンスに割り当てることです。
- IAMロールをEC2に割り当てることで、インスタンスはインスタンスプロファイルを通じて一時的な認証情報を安全に取得できるようになります。
- 権限設定においては、セキュリティ向上のため「最小権限の原則」に従い、必要最低限の権限を持つカスタムポリシーを使用することが推奨されます。
- 設定後もエラーが解消されない場合は、ネットワーク設定やAWS CLI/SDKの設定、S3バケットポリシーなど、複数の要因を確認する必要があります。
これらの手順と知識を身につけることで、あなたはAWS環境における認証と認可の基本的な仕組みを理解し、同様のエラーに遭遇した際に自信を持って対処できるようになります。
クラウド環境での開発や運用において、リソース間の連携は不可欠です。IAMロールを適切に活用することは、セキュアで効率的なシステム構築の鍵となります。今回のS3へのアクセス設定を皮切りに、他のAWSサービスへのアクセス権限設定にもIAMロールを積極的に利用してみてください。
この記事が、あなたのAWSでの作業において直面した課題を解決し、さらに一歩進んだクラウド活用の助けとなれば幸いです。安全で快適なAWSライフを！
