こうした疑問は、AnsibleでAWSリソースの自動化を始める段階で必ずぶつかる壁です。
AnsibleのAWSモジュールとAWS CLIは、どちらも内部でboto3という共通のPython SDKを使っています。そのため「AWS CLIで設定した認証情報がAnsibleにも効く」のは偶然ではなく、設計上の必然です。ただし、boto3には認証情報を解決するための「優先順位ルール」があり、これを把握していないと意図しないAWSアカウントで動いてしまうリスクがあります。
この記事では、AnsibleのAWSモジュールがboto3を介してどのように認証情報を解決するかを、優先順位の高い順に整理します。ローカル開発・CI/CD・本番EC2それぞれでの推奨設計パターンまで網羅します。動作確認環境はRHEL 10 / Rocky Linux 9です。
この記事のポイント
・AnsibleのAWSモジュールはboto3経由でAWS CLIと共通の認証情報チェーンを利用する
・認証情報の優先順位は「環境変数 → CLIプロファイル → EC2インスタンスプロファイル」の順
・aws_profile変数でPlaybookから明示的にCLIプロファイルを指定できる
・本番EC2ではIAMロールのみで認証できるためシークレットをサーバーに保存しなくていい
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
AnsibleのAWSモジュールはboto3を仲介して認証情報を解決する
Ansibleのモジュール（例:amazon.aws.ec2_instance や amazon.aws.s3_object）は、内部でPythonのAWS SDK「boto3」を呼び出してAWSのAPIと通信しています。Ansible自体がAWSの認証情報を管理するのではなく、boto3に認証を委ねている形です。処理の流れを整理すると次のようになります。
・Ansible Playbook → amazon.awsモジュール → boto3 / botocore → AWS API
AWS CLIも内部でboto3を使っています。つまりAnsibleとAWS CLIは「同じライブラリ経由でAWSを操作するツール」であり、boto3が参照する認証情報の設定ファイル（
~/.aws/credentialsや~/.aws/config）を共有できます。この構造を理解すると、「AWS CLIで設定したプロファイルがAnsibleにも使える」理由が明確になります。逆に、boto3の認証チェーンを把握していないと、デフォルトのプロファイルが意図しないアカウントを指している場合に気づかずミス操作をするリスクがあります。
必要なパッケージの確認
AWSモジュールを使うには、ansible実行環境にboto3とbotocoreが入っている必要があります。
# boto3/botocoreのインストール確認 pip3 show boto3 botocore # 未インストールの場合 pip3 install boto3 botocore # amazon.awsコレクションのインストール（Ansible 2.9以降） ansible-galaxy collection install amazon.aws
boto3が認証情報を探す優先順位
boto3は以下の順序で認証情報を検索し、最初に見つかったものを使います。・1位: 環境変数（AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY）
・2位: AWS CLIプロファイル（~/.aws/credentials の指定プロファイルまたはdefault）
・3位: EC2インスタンスプロファイル（IAMロールによる自動認証）
一般にはこの3つで大半のユースケースをカバーできます。それぞれを具体的に見ていきます。
1. 環境変数（最優先・CI/CDや一時的な切り替えに向く）
最も優先度が高いのが環境変数です。Playbookを実行する前に以下の環境変数を設定しておくと、boto3は必ずこれを最初に参照します。# 基本的な認証情報（IAMユーザーの静的アクセスキー） export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY export AWS_DEFAULT_REGION=ap-northeast-1 # STS一時クレデンシャルを使う場合はセッショントークンも必要 export AWS_SESSION_TOKEN=AQoXnyc4lcK4w...（一時トークン）
実機での確認例（環境変数設定後にAnsibleを実行した際の出力）:
$ export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE $ export AWS_DEFAULT_REGION=ap-northeast-1 $ ansible -m amazon.aws.aws_caller_info -c local localhost localhost | SUCCESS => { "account": "123456789012", "account_aliases": [], "arn": "arn:aws:iam::123456789012:user/ansible-ci", "user_id": "AIDAIOSFODNN7EXAMPLE" }
amazon.aws.aws_caller_info モジュールは認証中のIAMエンティティ情報を返します。認証情報の確認用として覚えておくと便利です。2. AWS CLIプロファイル（~/.aws/credentials・ローカル開発に向く）
環境変数が設定されていない場合、boto3は~/.aws/credentials と ~/.aws/config を参照します。どちらも aws configure コマンドで生成されるファイルです。# ~/.aws/credentials の例（複数プロファイル） [default] aws_access_key_id = AKIAIOSFODNN7EXAMPLE aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY [staging] aws_access_key_id = AKIAI44QH8DHBEXAMPLE aws_secret_access_key = je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY [production] aws_access_key_id = AKID1234567890EXAMPLE aws_secret_access_key = prod-secret-key-placeholder
AWS_PROFILE を設定するか、Ansibleモジュールの aws_profile パラメータを指定することで、使用するプロファイルを切り替えられます。# 環境変数でプロファイルを切り替える方法 export AWS_PROFILE=staging # または Playbook 内のタスクで直接指定する方法 - name: S3バケット一覧を取得する（stagingプロファイル使用） amazon.aws.s3_bucket_info: aws_profile: staging region: ap-northeast-1 register: bucket_list
~/.aws/config にリージョンを記載している場合はモジュールの region パラメータを省略できますが、明示的に書く方が可読性が上がります。3. EC2インスタンスプロファイル（IAMロール・本番環境に最適）
AnsibleのコントロールノードをEC2上で動かしている場合、そのEC2インスタンスにIAMロールを付与することで、認証情報ファイルなしにAWSリソースへアクセスできます。これを「インスタンスプロファイル」と呼びます。boto3はEC2のIMDS（Instance Metadata Service）から自動的に一時クレデンシャルを取得します。手順は次のとおりです。
・ステップ1: IAMロールを作成し、必要なポリシー（例: AmazonEC2ReadOnlyAccess）をアタッチする
・ステップ2: IAMロールをEC2インスタンスにアタッチする（EC2コンソール → アクション → セキュリティ → IAMロールの変更）
・ステップ3: EC2上でAnsibleを実行する（認証情報の追加設定は不要）
実際にIMDSから認証情報が取得されていることを確認する例（EC2インスタンス上での実行）:
# curlでIMDSからインスタンスプロファイル名を確認する $ curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/ ansible-control-role # 一時クレデンシャルの内容を確認する（確認用） $ curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/ansible-control-role { "Code" : "Success", "LastUpdated" : "2026-09-17T01:00:00Z", "Type" : "AWS-HMAC", "AccessKeyId" : "ASIAIOSFODNN7EXAMPLE", "SecretAccessKey" : "wJalrXUtnFEMI/K7MDENG/...", "Token" : "IQoJb3JpZ2lu...", "Expiration" : "2026-09-17T07:30:00Z" }
Ansibleモジュールのaws_profile変数でプロファイルを明示的に指定する
amazon.aws コレクションのモジュールにはaws_profile パラメータが用意されており、タスク単位でCLIプロファイルを指定できます。この設計により、Playbookの実行環境（どのPCで、誰が実行するか）に関わらず、使う認証情報を固定できます。1. タスクレベルでaws_profileを指定する
# playbook-aws-check.yml --- - name: AWSリソースを確認するPlaybook例 hosts: localhost connection: local gather_facts: false tasks: - name: 認証中のIAMエンティティを確認する（stagingアカウント） amazon.aws.aws_caller_info: aws_profile: staging region: ap-northeast-1 register: staging_identity - name: 認証結果を表示する debug: var: staging_identity.arn
2. group_vars で環境ごとにプロファイルを切り替える
複数の環境（staging / production）を同一のPlaybookで扱う場合、group_vars でプロファイルを環境ごとに定義すると管理しやすくなります。# group_vars/staging.yml aws_profile: staging aws_region: ap-northeast-1 # group_vars/production.yml aws_profile: production aws_region: ap-northeast-1 # Playbookのタスク側はgroup_vars変数を受け取る - name: EC2インスタンス一覧を取得する amazon.aws.ec2_instance_info: aws_profile: "{{ aws_profile }}" region: "{{ aws_region }}" register: instances
AWS SSOプロファイルをAnsibleから使う方法
AWS IAM Identity Center（旧 AWS SSO）を使っている組織では、aws sso login で生成した一時クレデンシャルをAnsibleから利用できます。botocore 1.22.0以降（aws-cli v2に付属のバージョン）であればSSO対応しています。# ~/.aws/config にSSOプロファイルを定義する例 [profile my-sso-dev] sso_start_url = https://my-org.awsapps.com/start sso_region = us-east-1 sso_account_id = 123456789012 sso_role_name = DeveloperAccess region = ap-northeast-1 output = json
・ステップ1:
aws sso login --profile my-sso-dev を実行してブラウザ認証を行う・ステップ2:
~/.aws/sso/cache/ に一時クレデンシャルが保存される・ステップ3: Playbookに
aws_profile: my-sso-dev を指定して実行する注意点として、SSOによる一時クレデンシャルの有効期限は通常1～8時間です。長時間のPlaybook実行では途中でExpiredTokenExceptionが発生することがあります。ジョブ開始前に
aws sso login を行うCIパイプラインを設計するか、SSOを使わずにIAMロール（インスタンスプロファイル）で運用する方が安定します。よくある認証エラーと原因診断
「Unable to locate credentials」が出る場合
boto3の認証チェーン全体を通して有効な認証情報が見つからなかった場合に発生します。・環境変数（AWS_ACCESS_KEY_ID等）が設定されていない
・
~/.aws/credentials が存在しないか、defaultプロファイルが空・EC2上で実行しているがインスタンスにIAMロールが付与されていない
対処として、まず
aws sts get-caller-identity（AWS CLI）でAWS CLIから認証できるか確認しましょう。CLIで認証できればAnsibleも同じ設定で動くはずです。「AuthFailure」「InvalidClientTokenId」が出る場合
認証情報は見つかったが、キーが無効または期限切れの場合に発生します。STS一時クレデンシャルでよく起きます。・静的アクセスキーが無効化されていないか確認する
・STS一時クレデンシャルを使っている場合は期限切れの可能性がある
・AWS_SESSION_TOKEN を設定し忘れた場合にも発生する
「NoRegionError: You must specify a region.」が出る場合
リージョンが未設定の場合に発生します。boto3はリージョンを以下の順で解決します。・1位: モジュールの
region パラメータ・2位: 環境変数
AWS_DEFAULT_REGION・3位:
~/.aws/config の region 設定いずれかの方法でリージョンを指定することで解消します。Playbookには
region: ap-northeast-1 を明示的に書いておくのが一番確実です。本記事のまとめ
| シナリオ | 推奨する認証方法 |
|---|---|
| ローカル開発・検証 | ~/.aws/credentials のCLIプロファイル + aws_profile 指定 |
| GitHub Actions / GitLab CI | 環境変数（AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY） |
| 本番EC2上のコントロールノード | EC2インスタンスプロファイル（IAMロール） |
| マルチアカウント切り替え | 名前付きCLIプロファイル + aws_profile or AWS_PROFILE 環境変数 |
| SSOログイン環境 | aws sso login 後に名前付きSSOプロファイルを aws_profile で指定 |
aws_profile を明示的に書いておくと、意図しないアカウントへの誤操作を防ぎやすくなります。認証情報の設計は「どの実行環境でAnsibleを動かすか」で決まります。ローカル開発はCLIプロファイル、CI/CDは環境変数、本番EC2はIAMロール——この3つの使い分けを基本パターンとして覚えておきましょう。
Ansible実践ハンズオンの詳細を見る ＞＞
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：Ansibleのrole引数設計｜呼び出し側からroleへ変数を渡す経路と既定値の置き場所
- この記事の属するカテゴリ：Ansibleへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます