AWS Systems ManagerにEC2インスタンスが表示されない時に確認した設定箇所

  • 2021年4月15日
  • 2021年11月9日
  • AWS, IT
AWS

こんにちはますのです。

CloudWatchエージェントをインストールしたい。
そしてあわよくばSystemsManagerを使って管理したい。
格好良くセッションマネージャーからSSH接続したい。

そんな想いから検証を行っております。

反映されたりされなかったり、うまく行かないなぁ…。と悩んでいたので解決方法や設定方法について確認したところを備忘録として書いていきます。

目次

原因：プライベートサブネットでVPCエンドポイントを作成していない

結論です。
IAMロールのポリシー設定、EC2インスタンスへのアタッチだけでSystemsManagerに反映されていたのは「パブリックサブネット」のEC2インスタンスのみでした。

SystemsManagerがVPC外のサービスのようです。
そのため外部と通信を遮断していたプライベートサブネットではSystemsManager上で出てこなかったようです。

SystemsManagerを利用するための設定方法

  • EC2インスタンスにSystemsManagerエージェントをインストールする
  • SystemsManagerへのアクセスに必要なIAMロールをEC2インスタンスにアタッチする
  • VPCエンドポイントを設定する（※プライベートサブネットのみ）

EC2インスタンスにSystemsManagerエージェントをインストールする

SSMエージェントのインストールは「Amazon Linux2」にはデフォルトでインストールされているので割愛します。

systemctlでactive(running)になっていることを確認。

$ sudo systemctl status amazon-ssm-agent.service
● amazon-ssm-agent.service - amazon-ssm-agent
Loaded: loaded (/usr/lib/systemd/system/amazon-ssm-agent.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2021-04-15 05:53:38 UTC; 46s ago
Main PID: 3039 (amazon-ssm-agen)
CGroup: /system.slice/amazon-ssm-agent.service

各種インストール情報はこちらのサイトから確認ください。
参考：SSM エージェント の使用

SystemsManager疎通用 IAMロールの作成とアタッチ設定

IAMロールの作成とEC2インスタンスへのアタッチを行います。

IAMロールの作成

必要になるポリシーは以下となります。

  • AmazonSSMManagedInstanceCore

今回はCloudWatchエージェントも利用する用途だったので「CloudWatchAgentAdminPolicy」を含めていますが、SystemsManagerのみ利用する場合は不要となります。

別記事：CloudWatch AgentでEC2インスタンスのメモリ使用率を取得する

各種マニュアルを見ていると「AmazonEC2RoleforSSM」の記載がありますが【旧ポリシー】になります。
権限が強すぎるため、2020年4月の時点で利用は非推奨となりました。
参考：マネージドインスタンスポリシーのベストプラクティスの適用

コアエージェント機能 セッションマネージャー シームレスなドメイン参加 Cloud Watchエージェント Cloud Watch Logsコマンド出力 S3コマンド出力1 VSSスナップショット2
AmazonSSMManagedInstanceCore ✔ ✔
AmazonSSMDirectoryServiceAccess ✔
CloudWatchAgentServerPolicy ✔ ✔
カスタムポリシーが必要 ✔
カスタムポリシーが必要 ✔
AmazonEC2RoleforSSM（非推奨） ✔ ✔ ✔ ✔ ✔ ✔

EC2インスタンスへアタッチする

続いて先ほど作成したIAMロールEC2インスタンスへアタッチします。

  • 設定箇所：EC2ダッシュボード＞対象のEC2を選択＞アクション＞セキュリティ＞IAMロールを変更

以上で事前作業のIAMロール作成とアタッチは完了となります。

パブリックサブネットであればこの時点でSystemsManagerのセッションマネージャーを利用してSSH接続が可能となります。

プライベートサブネット用：SSMのVPCエンドポイントを作成する

続いてわたしの引っかかりポイント。
プライベートサブネットに対してはVPCエンドポイントを3つ作成しないとならないようです。

  • com.amazonaws.[region].ssm
  • com.amazonaws.[region].ec2messages
  • com.amazonaws.[region].ssmmessages

VPCエンドポイント「com.amazonaws.[region].ssm」の作成

サービスカテゴリ：AWSサービス　を選択

サービス名：com.amazonaws.ap-northeast-1.ssm　を選択

サブネットは対象のプライベートサブネットを選択

プライベートDNS名を有効にする：チェックを入れる

セキュリティグループは選択、もしくは新規に作成して設定する

今回は新規にセキュリティグループを作成しました。

  •  インバウンドルールは以下の通り設定する
    • タイプ：HTTPS(443)
    • ソース：プライベートサブネットのCIDR

ポリシー、タグについてはデフォルトのまま。

「エンドポイントの作成」をクリックして作成します。

他2つも同様にVPCエンドポイントを作成

  • com.amazonaws.ap-northeast-1.ssmmessages
  • com.amazonaws.ap-northeast-1.ec2messages

作成が終わるとVPCエンドポイントの画面で表示されます。
ステータスが「使用可能」に変われば完了です。

VPCエンドポイント作成時にエラーが出た際のチェックポイントです。

・VPC管理画面より
対象のVPCを選択＞アクション＞DNSホスト名を編集：DNS解決を編集をクリック
別記事：VPCエンドポイントを作成する時に「Enabling private DNS requires…」とエラーが出たので詳細を調べる

SystemsManager：セッションマネージャーでSSH接続を試す

さあ、ここまで出来れば準備完了です。

SystemsManager＞セッションマネージャー＞セッションの開始をクリック

あとはセッションの開始からEC2インスタンスを選択してSSH接続するだけで完了です。

Webブラウザ上からSSH接続してコマンド確認もOKです。
あとは「sudo su [ユーザ名]」で任意のユーザにログインして実行してもらえばユーザ管理もOKなのかなと。

セッションマネージャーに反映されるまで数分かかりました。
10分程度待っても出てこない場合は設定を一度見直しましょう。
VPCエンドポイントをルートテーブルに設定する必要あるのかな？？と思っていましたが、不要なようです。
VPCエンドポイントを作成すれば問題無く接続が出来るようですね。
これでセキュリティグループのSSHポートを外した運用が可能となり、IP制限が難しい場合に重宝しそうです。

参考資料

 

最新情報をチェックしよう！

AWSの最新記事