AWS Systems Managerを使ってサーバ管理してみた

今回はAWS初心者向けハンズオンからAWS Systems Managerを使ったサーバ管理はじめの一歩編を構築してみました。

一般に実運用環境で複数のサーバを管理する際には

• 各サーバの接続情報は？
• OSのバージョンはいくつか？
• 全サーバに同じコマンドを実行したい
• ●●のxxバージョンで脆弱性があるらしいが、該当するサーバがあるか調べたい

といった要望があると思います。
これらの要望への対応を可能とするSystems Managerというサービスについて、
そのメリットや構築でポイントとなる箇所をお伝えしていきます。

アーキテクチャ図

本ハンズオンで構築するアーキテクチャは次の通りです。

利用しているAWSサービス

AWS Systems Manager

EC2やオンプレ環境のサーバの管理を行うことができるサービスです。
Windows/Linux両方に対応しており、対象のサーバをグループ化することも可能です。

大きくは以下の機能群で構成されています。

• ノード管理
• 運用管理
• 変更管理
• アプリケーション管理

特に「ノード管理」は上で挙げたサーバ管理における要望を解決するための以下のような機能を持ちます。

• Fleet Manager：GUIでのサーバ管理
• Inventory：構成情報の収集・閲覧
• Session Manager：サーバへのリモートアクセス
• Run Command：複数サーバに対する一括コマンド実行(特定のサーバのみ、または、タグ・リソースグループによる指定が可能)
• State Manager：サーバの構成を指定した状態に維持

サーバをSystems Managerで管理可能な状態にするには以下3つの設定をする必要があります。

1. サーバにSystems Managerのエージェントである「SSM Agent」をインストールする
   ※Amazon Linux, macOS, SUSE linux, Ubuntu, Windows ServerのオフィシャルイメージにはSSM Agentがプリインストールされている
2. SSM Agent(VPC内)からSystems Manager(VPC外)にアクセスするためのアウトバウンドの経路を用意する
3. SSM AgentからSysmtes Managerへのアクセスを許可するため、SSM AgentがインストールされたEC2に「AmazonSSMManagedInstanceCore」というポリシーをアタッチする

Session Manager

Systems Managerの一つの機能であるSession Managerについて少し解説します。

Session Managerはマネージメントコンソール（ブラウザ）からシェルを利用してSystems Managerが管理するサーバへのアクセスを可能とする機能です。
Systems Managerにアクセス可能なIAMロールを持ったユーザにてマネージメントコンソールにログインするだけで対象のサーバにリモートログインできるようになりますので、

• 踏み台サーバ(bashion)を建てたり
• sshアクセスのためのキーペアを管理したり
• VPN接続の環境をセットアップしたり

といった面倒なことからは解放されます。

なお、Session Managerを使ったアクセスでは、対象サーバ(SSM AgentがインストールされているEC2)へのインバウンド通信を開けておく必要はありません。
理由としては、SSM AgentがVPC内からアウトバウンド通信でVPC外のSystems Managerと通信しているので、Systems Managerにさえアクセスできれば、そこを経由してEC2までアクセスが可能となるからです。

Session Managerで接続したサーバ上での操作ログはS3、またはCloudWatch Logsで保存が可能です。
ログはEC2からS3、またはCloudWatchに送信することになりますので、もしこの操作を行いたい場合は、EC2からそれらのサービスへのアクセスを許可するポリシー(CloudWatchLogsFullAccess等)をEC2に付与したIAMロールにアタッチする必要があります。
※Session Managerで接続したこと自体(セッション開始操作)はCloudTrailで記録可能です

構築(ポイントとなる箇所のみ)

EC2

Amazon Linuxの無料枠で作成していきます。
事前にIAMの画面で「AmazonSSMManagedInstanceCore」ポリシーを紐づけたロールを作成しておき、それを付与することを忘れないようにしてください。

また、今回はプライベートサブネットにEC2を建てますが、上で説明したとおり、Systems Managerへのアウトバウンド経路が通っている必要があります。
プライベートサブネットに紐づけるセキュリティグループのルートテーブルにて、NAT gatewayへの通信が可能となるように設定します。

SSM Agent

Agentの自動更新

SSM Agent自体は今回利用しているAmazon Linuxにプリインストールされていますので、インストール作業は必要ありません。
ここではSSM Agentの自動更新の設定を行います。
設定自体は非常に簡単で、Systems ManagerのFleet Managerの画面から「SSMエージェントの自動更新」を選択するだけとなります。

自動更新をすることで次のことが可能となります。

• Systems Managerの最新機能が利用可能となる
• バージョンアップのたびに手動で更新する必要がなくなる(特にサーバ台数が多い場合は非常に有効)

インベントリ

マネージドインスタンスの構成情報を定期的(デフォルト30分)に取得することが可能となります。
取得できる構成情報はセットアップ時に選択します。以下のような情報が取得可能です。

セットアップ自体は管理コンソールから　Systems Manager > ノードツール > インベントリ と辿って、「セットアップインベントリ」ボタンを押すだけなので割愛します。

動作確認

EC2がマネージドインスタンスとしてSystems Managerで管理されていることを確認します。
確認はSystems ManagerのFleet Managerで行います。

無事EC2が管理対象として表示されていることが確認できました。

なお、Fleet Managerは以下のようなマネージドインスタンスの管理機能を持ちます。

• マネージドインスタンスの一覧表示
• ファイルシステムの参照
• OSユーザ/グループ管理
• 一般的なパフォーマンス情報の確認
• プロセス管理

次に、インベントリの収集についても確認していきましょう。
Fleet Managerの画面から対象のマネージドインスタンスを選択すると、収集した構成情報が確認できます。

画像ではLinuxのプロセスの情報が確認できていますが、「インベントリタイプ」を切り替えることでAWSコンポーネント(SSM Agent等)やその他の情報も参照可能です。

また、Systems Manager > インベントリ　画面では検索窓から条件を入力することで該当する情報を検索することができます。
例えば、AWSコンポーネントの名前が「amazon-ssm-agent」で、バージョンが3.4より小さいもの、という条件で検索すると今回作成したEC2がヒットしています。(インストールしたSSM Agentのバージョンは3.3.1345.0です)

その他、Systems Managerの画面からは次のことが可能です。

• Session Managerを利用したEC2へのリモートアクセス
• Run Commandを利用した一括コマンド実行と結果の確認

感想

Systems Managerを利用することでサーバの管理がマネジメントコンソール上から簡単に実現できることが分かりました。
しかも、今回利用した機能についてはSystems Manager自体の料金は無料で、EC2、NAT gateway、CloudWatchの費用しか必要ないというのも魅力の一つだと思いました。
※他のSystems Managerの機能には有料のものもあります
今後は実運用でもこちらの機能の利用を検討したいと思います。
ではまた。