2026年7月28日

AWS IAMユーザーとロールの作成方法｜使い分け・EC2へのロール付与・アクセスキーの安全な扱い

VPS・クラウド

AWSで「誰が操作するか」を表す主体には、主にIAMユーザーとIAMロールの2種類があります。結論から言うと、人の作業はIAM Identity Center（またはIAMユーザー）で、EC2上のWordPressのようなサーバー上のプログラムはIAMロールで動かし、長期のアクセスキーはAWSの外から呼ぶどうしても必要な場面だけに絞るのが基本です。この記事では、ユーザーとロールの違い、それぞれの作成手順、WordPressの運用でよくある構成への当てはめ方、作成後の確認方法を説明します。

権限の中身（どの操作をどのリソースに許すか）を書くポリシーの書き方は、別記事の「IAMポリシーの書き方と管理方法」で扱います。この記事は「権限を誰に持たせるか」の側に絞っています。

ユーザーとロールの違いを先に整理する

IAMユーザーは、パスワードやアクセスキーといった長期の認証情報を持つ主体です。一度発行したアクセスキーは、削除するまで有効なままです。漏えいすると、気付くまでの間ずっと悪用される可能性があります。

IAMロールは、それ自体はパスワードもアクセスキーも持ちません。「このロールを引き受けてよいのは誰か」を定めた信頼ポリシーと、「引き受けたら何ができるか」を定めた権限ポリシーの組み合わせです。ロールを引き受けると、有効期限つきの一時的な認証情報が発行され、期限が来れば自動的に使えなくなります。

使い分けの目安は次のとおりです。

人がコンソールやCLIを使う：IAM Identity Centerのユーザー（小規模でIdentity Centerを使わない場合はIAMユーザー＋MFA）
EC2、Lambda、ECSなどAWS上で動くプログラム：IAMロール
AWSの外のサーバー（他社のVPSやレンタルサーバー）からAWSのAPIを呼ぶ：IAMユーザーのアクセスキー、または条件が合えばIAM Roles Anywhere
別のAWSアカウントからの操作：クロスアカウントのIAMロール

AWSは人のアクセスについて、IAMユーザーより一時的な認証情報を使う方法を推奨しています（2026年10月現在）。ただし、レンタルサーバー上のWordPressからS3やSESを使う場合など、アクセスキーを避けられない構成もあります。その場合は後述の対策で被害の範囲を小さくします。

IAMロールを作成してEC2に付与する

EC2上のWordPressがS3（メディアの保存先やバックアップ先）を使う構成を例にします。ロールを使えば、wp-config.phpにアクセスキーを書く必要がなくなります。

コンソールで作成する場合

IAMコンソールの「ロール」からロールの作成を選び、信頼されたエンティティの種類として「AWSのサービス」、ユースケースとして「EC2」を選びます。次に権限ポリシーを付け、ロール名を付けて作成します。コンソールでEC2用のロールを作ると、EC2に付けるための入れ物である「インスタンスプロファイル」が同じ名前で自動的に作られます。画面の項目名は変わることがあるため、迷ったら公式ドキュメントで最新の手順を確認してください。

作成したら、EC2コンソールで対象インスタンスを選び、セキュリティの設定からIAMロールの変更を行ってロールを付けます。インスタンスの再起動は不要です。

CLIで作成する場合

CLIでは、ロール・インスタンスプロファイル・インスタンスへの関連付けを別々に行います。まず信頼ポリシーをファイルに書きます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "ec2.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

# ロールを作成（trust-ec2.json は上の信頼ポリシー）
aws iam create-role \
  --role-name wp-ec2-role \
  --assume-role-policy-document file://trust-ec2.json

# 権限ポリシーを付ける（ポリシーは事前に作成しておく）
aws iam attach-role-policy \
  --role-name wp-ec2-role \
  --policy-arn arn:aws:iam::123456789012:policy/wp-media-s3

# インスタンスプロファイルを作ってロールを入れる
aws iam create-instance-profile --instance-profile-name wp-ec2-role
aws iam add-role-to-instance-profile \
  --instance-profile-name wp-ec2-role \
  --role-name wp-ec2-role

# インスタンスに関連付ける
aws ec2 associate-iam-instance-profile \
  --instance-id i-0123456789abcdef0 \
  --iam-instance-profile Name=wp-ec2-role

つまずきやすいのは、CLIで作った場合にインスタンスプロファイルを作り忘れることです。ロールだけではEC2に付けられません。アカウントIDやインスタンスIDは自分の環境の値に置き換えてください。

ロールが効いているか確認する

インスタンスにSSHで入り、次のコマンドで今どの主体として動いているかを確認します。

aws sts get-caller-identity

結果の Arn に assumed-role/wp-ec2-role/... のように表示されれば、ロールの一時的な認証情報が使われています。AWS SDKやCLIは、認証情報が環境変数や設定ファイルに無い場合、インスタンスメタデータからロールの認証情報を自動で取得します。逆に言えば、サーバー上に古いアクセスキー（~/.aws/credentials や環境変数）が残っていると、そちらが優先されてロールが使われません。結果がIAMユーザーのARNになっていたら、残っている認証情報を探して削除します。

あわせて、インスタンスメタデータはトークンが必要なIMDSv2のみに制限しておくと、サーバー側の脆弱性を突いてロールの認証情報を盗まれる危険を減らせます。

aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-tokens required

古いソフトウェアがIMDSv1しか使えない場合は取得に失敗するため、ステージング環境で動作を確認してから本番に適用してください。

IAMユーザーを作成する

人が使うユーザー

Identity Centerを使わず、少人数でIAMユーザーを使う場合は、ユーザーを作成してコンソールへのアクセスを有効にし、権限は直接付けずにグループ経由で付けます。「管理者」「開発者」のようなグループに権限を付け、ユーザーをグループに入れる形にしておくと、人が増えたり辞めたりしたときの管理が楽になります。作成後は本人にMFAを登録してもらい、MFAが無いと操作できないようにしておくと安全です。

プログラムが使うユーザー（アクセスキー）

レンタルサーバー上のWordPressからS3やSESを使う場合など、AWSの外から呼ぶときはアクセスキーを発行します。

aws iam create-user --user-name wp-offsite-media
aws iam attach-user-policy \
  --user-name wp-offsite-media \
  --policy-arn arn:aws:iam::123456789012:policy/wp-media-s3
aws iam create-access-key --user-name wp-offsite-media

シークレットアクセスキーが表示されるのは作成時だけです。表示された値はパスワードマネージャーなどに保管し、チャットやメールに貼らないようにします。プログラム用のユーザーにはコンソールのパスワードを付けません。

アクセスキーを使うときの注意点

アクセスキーをWordPressに渡す方法は、使うプラグインによって異なります。たとえばメディアをS3に置くWP Offload Mediaは、管理画面に入力する方法のほか、wp-config.phpの定数で渡す方法を用意しています。データベースに保存される方法より、wp-config.phpの定数やサーバーの環境変数で渡す方法のほうが、DBのバックアップやエクスポートから漏れる経路を減らせます。具体的な定数名はプラグインのドキュメントで確認してください。また、EC2上で動かす場合はキーを渡さずにサーバーのロールを使う設定を選べるプラグインもあります。

アクセスキーの扱いでは、次の点を守ります。

1つのキーを複数の用途で使い回さず、用途ごとにユーザーを分けて権限を最小限にする
wp-config.phpや .env をGitに含めない。Gitの履歴に残ったキーは、ファイルを消しても履歴から読めてしまう
定期的にローテーションする。1ユーザーにつきキーは2つまで持てるので、新しいキーを作成→WordPress側を切り替え→古いキーを無効化→問題が無ければ削除、の順に進める
最終使用日時を確認し、使われていないキーは無効化する

# キーの一覧と状態
aws iam list-access-keys --user-name wp-offsite-media

# 古いキーをいったん無効化（削除の前に影響を確認する）
aws iam update-access-key --user-name wp-offsite-media \
  --access-key-id AKIAIOSFODNN7EXAMPLE --status Inactive

いきなり削除せずに無効化を挟むのは、どこかでまだ使われていた場合に、有効に戻すだけで復旧できるようにするためです。

よくあるつまずき

ロールを付けたのに「Access Denied」になる場合、原因の多くは権限ポリシーの不足です。エラーメッセージには拒否された操作名（例: s3:PutObject）が出るので、その操作がポリシーで許可されているか、対象のリソース（バケット名やARN）が合っているかを確認します。S3の場合は、バケットポリシーやブロックパブリックアクセスの設定で拒否されていることもあります。

信頼ポリシーの Principal を誤ると、そもそもロールを引き受けられません。EC2なら ec2.amazonaws.com です。

もう1つ多いのが、ルートユーザーでアクセスキーを作ってしまうケースです。ルートユーザーのキーは権限を絞れないため、作ってしまった場合は削除し、IAMユーザーやロールに置き換えてください。

まとめ

AWS上で動くWordPressにはIAMロールを付け、アクセスキーをサーバーに置かない構成を優先する
EC2に付けるにはインスタンスプロファイルが必要。CLIで作るときは作り忘れに注意する
aws sts get-caller-identity で実際に使われている主体を確認し、古いキーが残っていないかを見る
人の作業はIdentity CenterかIAMユーザー＋MFAで、権限はグループ経由で付ける
アクセスキーは用途ごとに分け、Gitに含めず、無効化を挟んでローテーションする