パスワードや鍵を埋め込まずに、EC2 から S3 を読む

手順に迷ったときや、用語の意味を確かめたいときに開きましょう。

※ リンク切れの場合は、ページタイトルで検索してください。

EC2 に「S3 読み取り」の IAM ロールを付けます。サーバーは鍵を持たず、ロールから渡される一時的な権限で S3 のファイルを取得します。取得した内容をブラウザで表示して確認します。

以下の要件を満たし、EC2 がロールの権限で S3 を読めることをブラウザで確認してください。

「S3 にファイルを置く → ロールを作る → ロールを付けて EC2 を起動 → ブラウザで確認」の順に進みます。サーバーに鍵を書かない、という点を意識してください。

1. S3 バケットを作り、ファイルを置く（非公開のまま）

   リージョンが東京であることを確認し、S3 でバケットを 1 つ作成します（非公開のまま）。message.txt というテキストファイルを作り（中に「これは S3 から取得したファイルです」などと書く）、アップロードします。

   公開しないのがポイント

   バケットは非公開のままにします。誰でも見られる状態ではないので、EC2 が読めるのは「ロールの権限のおかげ」だとはっきり分かります。

2. EC2 用の IAM ロールを作成する

   IAM コンソールの「ロール」→「ロールを作成」を開きます。信頼されたエンティティで「AWS のサービス」→「EC2」を選びます。次の許可ポリシーの画面で AmazonS3ReadOnlyAccess を検索してチェックを入れ、ロール名（例：ec2-s3-read-role）を付けて作成します。

   ロールを作成 — 信頼されたエンティティ（イメージ）

   信頼されたエンティティタイプ

   AWS のサービス

   EC2 など AWS のサービスに引き受けさせる

   別の AWS アカウント

   他アカウントに引き受けさせる

   ウェブアイデンティティ

   外部 ID プロバイダー向け

   ユースケース

   EC2

   EC2 インスタンスにロールを渡す

   Lambda

   Lambda 関数にロールを渡す

   ↳「AWS のサービス」→「EC2」を選びます

   「誰に持たせるロールか」を決める

   信頼するサービスに EC2 を選ぶことで、「このロールは EC2 が引き受けられる」という意味になります。許可ポリシー（S3 読み取り）が、その役割でできることの中身です。今回は学習のため読み取り全般を許可しますが、実際は対象のバケットだけに絞るのが望ましいです。

3. ロールを付けて EC2 を起動する（ユーザーデータで S3 から取得）

   EC2 を 1 台起動します。Amazon Linux 2023・無料利用枠タイプ、パブリック IP の自動割り当てを有効、HTTP（80）を許可します。「高度な詳細」の「IAM インスタンスプロフィール」で、手順 2 のロール（ec2-s3-read-role）を選びます。同じ「高度な詳細」の「ユーザーデータ」に、次を貼り付けます（バケット名 は自分のものに置き換え）。

   ユーザーデータ（バケット名を置き換え）

   #!/bin/bash
   dnf install -y httpd
   systemctl enable --now httpd
   # 付けた IAM ロールの権限で S3 からファイルを取得する（鍵は書かない）
   aws s3 cp s3://バケット名/message.txt /var/www/html/index.html

   この 1 行に鍵が無いことに注目

   aws s3 cp … の行には、アクセスキーもパスワードも書かれていません。それでも S3 から取得できるのは、EC2 に付けたロールが、一時的な権限を自動で渡しているからです（aws コマンドは Amazon Linux に最初から入っています）。

4. ブラウザで確認する

   インスタンスが「実行中」になって数分待ったら、パブリック IPv4 アドレスにブラウザでアクセスします。S3 に置いた message.txt の内容（例：「これは S3 から取得したファイルです」）が表示されるはずです。サーバーに鍵を書かずに、S3 のファイルを読み出せました。

   表示まで少し待つ

   起動直後は、ユーザーデータの実行（Apache の導入と S3 からの取得）に 1〜2 分かかることがあります。すぐ表示されないときは、少し待ってから再読み込みしてみましょう。

初学者がよく引っかかる箇所を先回りでまとめました。答えそのものは載せていませんが、「どこを見直せばよいか」の手がかりとして使ってください。

要件の再確認ではなく、画面のどこを見れば達成を確認できるかをまとめました。S3・IAM・EC2 コンソールとブラウザを開いて、次を順に確かめましょう。

• S3 バケットが非公開のままで、message.txt が入っている。
• IAM の「ロール」に ec2-s3-read-role があり、S3 読み取りの権限と、EC2 が信頼されている設定になっている。
• EC2 インスタンスの詳細で、IAM ロールが ec2-s3-read-role としてアタッチ済みになっている。
• ブラウザで EC2 のパブリック IP を開くと、S3 のファイルの内容が表示される。
• ユーザーデータのどこにも、アクセスキーやパスワードを書いていない（鍵なしで読めている）。

手を動かすことに加えて、次の問いに自分の言葉で答えられるようにしておくと、理解がより深まります。

1. アクセスキー（長期の鍵）をサーバーに書いておく方法と、IAM ロールを付ける方法では、安全性にどんな差があるでしょうか。鍵が「漏れたとき」を想像して比べてみましょう。
   ヒント

   埋め込んだ長期の鍵が漏れると、その鍵は（消すまで）ずっと有効で、被害が長く続きます。ロールが渡す認証情報は一時的で自動更新されるため、仮に一時的に漏れても有効期限で使えなくなります。「鍵の寿命」と「埋め込む場所」という観点で考えてみましょう。
2. 今回はロールに「S3 の読み取り全般」を許可しました。実際の運用では、これをどう絞るとより安全になるでしょうか。
   ヒント

   「すべての S3」ではなく「このバケットだけ」「読み取りだけ（書き込み・削除は不可）」のように、必要な範囲だけに絞れます（最小権限）。許可を狭くするほど、万一のときにできることも限られます。「その役割が本当に必要な操作だけ」を許可する、という観点で考えてみましょう。
3. EC2 だけでなく、Lambda などの他のサービスも IAM ロールで権限を受け取れます。なぜ AWS は、サービスにロールを「持たせる」かたちを基本にしているのでしょうか。共通する利点を考えてみましょう。
   ヒント

   どのサービスでも「鍵を埋め込まない・一時的な権限・必要な分だけ」を共通の作法にできる、という利点があります。サービスごとにバラバラの鍵管理をするより、ロールで統一したほうが安全で管理も楽、という観点で考えてみましょう。

作ったものを片づけます。EC2 は起動している間ずっと課金されるため、忘れず終了しましょう。

1. EC2 インスタンスを終了する：「インスタンス」で対象を選び、「インスタンスを終了（Terminate）」します。
2. IAM ロールを削除する（任意）：もう使わない場合、IAM の「ロール」で ec2-s3-read-role を削除できます。
3. S3 のオブジェクトとバケットを削除する：message.txt を削除し、バケットを空にしてから削除します。
4. セキュリティグループを削除する（任意）：このハンズオン用に作ったものは、インスタンス終了後に削除できます。