【AWS】プライベートサブネット上のEC2(RHEL)にSSM Agentをインストールしたい

ejima

こんにちは、えじまです

本日は、プライベートサブネットに建てられたEC2インスタンスでセッションマネージャーを使う必要があったため、その方法を記載していきます

セッションマネージャーを利用するためには、SSM Agentをインストールしなくてはいけません

しかし、AMIによってデフォルトでインストールされているものと、いないものとあります
（公式ドキュメントにありますので気になる方は、こちらのリンクから）

そこで、今回はデフォルトでインストールされていないAMIの【RHEL】を使用して検証したいと思います

構成図

今回の学習ポイント

  • ネットワーク接続
    プライベートサブネット上のインスタンスはインターネットに接続されていないのでNATゲートウェイを利用する

  • セキュリティグループ
    今回EC2インスタンスのセキュリティグループには、アウトバウンドルールしか設定しません
    （後述: ステートレス・ステートフルな通信）

  • SSM Agentのインストール方法
    今回はEC2の機能の1つ、ユーザーデータを利用してSSM Agentをインストールします

構築手順

  1. VPCの作成
  2. IAM Roleの作成
  3. セキュリティグループの作成
  4. EC2インスタンスの作成

構築開始

VPCの作成

以下条件を満たしてれば大丈夫です。
AZの数：1
パブリックサブネットの数：1
プライベートサブネットの数: 1
NATゲートウェイ: 1 AZ内

（NATゲートウェイの立ち上げに多少時間がかかります）

IAM Roleの作成

マネジメントコンソールからIAMのページに行きます
左のサイドメニューから「ロール」を選択
「ロールを作成」をクリックし、下図に従って項目を選択

許可ポリシーに、【AmazonSSMManagedInstanceCore】を選択
「次へ」をクリック

任意のロール名を入力し、ロールを作成

セキュリティグループの作成

以下図の条件で作成してください

項目 タイプ 送信先
インバウンドルール – –
アウトバウンドルール HTTPS 0.0.0.0

EC2インスタンスの作成

以下画像を見ながら作成してください

  • ポイント
    1. AMIにRhelを選択しているか
    2. プライベートサブネットを選択しているか
    3. セキュリティグループは先ほど作成したものを選択しているか
    4. IAM Roleは先ほど作成したものを選択しているか
    5. ユーザーデータはあっているか

  • ユーザーデータコマンド
    インスタンス起動時にSSM Agentをインストールするコマンドです
    他バージョンや他AMIでインストールする場合コマンドが変わりますのでご注意ください
    公式サイトはこちら
#!/bin/bash

sudo dnf install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm

sudo systemctl enable amazon-ssm-agent
sudo systemctl start amazon-ssm-agent

※余談ですが、ユーザーデータはデフォルトではインスタンスの起動時に1度だけ機能するものです
例えば一部分間違えたからといって、修正して起動しなおしても反映されませんのでご注意ください
公式ドキュメントにも記載があります。

以上で構築準備はできました

セッションマネージャーを起動してみる

マネジメントコンソールから起動したEC2を選択
上部にある「接続」をクリック

セッションマネージャー欄から「接続」をクリック
（EC2起動からすぐは接続できないかと思います。5分ほど待っても接続できなければ設定を見直してみてください。）

以下の黒い画面が表示されれば成功です。

ワンポイント

ここまで構築をして疑問に思われた方もいらっしゃるかと思いますが、なぜインバウンドルールを許可していないのに、SSM Agentをインストールできたのでしょうか？

ステートフル・ステートレス

  • ステートフル
    「ステートフルな通信」とは、わかりやすくいうと「情報を維持した通信」です
    例えば、Amazonで買い物をされたことはあるでしょうか？
    「カートに追加」という機能がありますが、私たちが送った情報を維持してくれているので、何度も選びなおさなくて楽ですよね。
    このように。送った情報を維持して返してくれる通信をステートフルな通信といいます

  • ステートレス
    逆に、「ステートレスな通信」とは「情報を維持しない通信」になります
    これだけ聞くとデメリットに聞こえるかもしれませんが、情報を保持しない分、通信が早いなどのメリットがあります

AWSにおけるセキュリティグループとネットワークACLの違い

  • セキュリティグループ
    セキュリティグループは、ステートフルです。
    よって、アウトバウンドルールのみの設定で通信は自動的に許可されます

  • ネットワークACL
    逆に、ネットワークACLはステートレスです。
    そのため、インバウンド、アウトバウンドともに設定しなければ通信ができないです。
    その分、行きは許可するが、帰りは許可しないなどの設定はできます。

つまり今回通信をできたのはセキュリティグループを使用してアウトバウンド通信を許可したので、こちらが要求した「SSM Agentをインストールしたい」という情報を維持して"返してくれた通信"ということでインバウンドルールを設定していなくても、通信できたわけですね

まとめ

今回はネットワークの通信方法も含めて様々なことを学ぶことができた貴重な機会でした

また、勉強した内容をブログで発信していきたいと思います

ここまで読んでくださりありがとうございました

それでは

Last modified: 2023-06-13

Author