はじめに
この記事はDevOps on AWS大全の一部です。
DevOps on AWS大全の一覧はこちら。
この記事ではAWS Systems Managerに関連する内容を超詳細にまとめています。
具体的には以下流れで説明します。
- AWS Systems Managerとは
- AWS Systems Managerの仕組み
- AWS Systems Managerのセキュリティ
- AWS Systems Manager for Advance
AWSの区分でいう「Level 200：トピックの入門知識を持っていることを前提に、ベストプラクティス、サービス機能を解説するレベル」の内容です。
この記事を読んでほしい人
- AWS Systems Managerがどういうサービスか説明できるようになりたい人
- AWS Systems Managerを採用するときのベストプラクティスを説明できるようになりたい人
- AWS Certified DevOps Engineer Professionalを目指している人
AWS Systems Managerとは
AWS Systems ManagerはEC2とオンプレミスのサーバを管理するためのツールです。
具体的にはインフラの状態を取得し、運用のためのインサイト提供やコンプライアンス強化のためのパッチ適用の自動化を行うことができます。
WindowsとLinuxどちらでも利用可能なのでEC2を使っているのであればぜひ、活用の検討をしましょう。
IaCは徹底できていてもAWS Systems Managerを使った運用の自動化を徹底できている実プロジェクトは少ない印象なので、AWS Systems Managerを使うことで運用の効率化という面で大きく差をつけることができます。
AWS Systems Managerの仕組み
AWS Systems Managerは大きく6つのカテゴリに分類された多くの機能で構成されています。
ここで、すべてを説明することは難しいのでよく使う機能に絞って取り上げていきます。
サービス分類
まずはサービス分類の一覧をまとめましょう。
| カテゴリ名 | 機能名 |
|---|---|
| 共有リソース | Documents |
| アプリケーション管理 |
Parameter Store AppConfig |
| ノード管理 |
Fleet Manager Session Manager Run Command Patch Manager Inventory State Manager Compliance Distributor Hybrid Activations |
| オペレーション管理 | Incident Manager Explorer OpsCenter CloudWatch Dashboards |
| 変更管理 |
Automation Maintenance Windows Change Manager Change Calender |
| Quick Setup | - |
これを見るだけでもSystems Managerの中には多くの機能があることがわかると思います。
ただし、すべてを使わないと何かを達成できないということはなく、やりたいことに合わせてSystems Manager内の機能を組み合わせて使っていきます。
Systems Managerはあくまで運用管理を自動化あるいは効率化するための機能群の総称だと思ってください。
今回は多くの機能の中から実プロジェクトで利用頻度が高いあるいは試験に出やすいものを選んで、超詳細解説していきます。
超詳細解説対象は表中太字のものです。
リソースグループ
Systems Managerの機能説明に入る前にリソースグループという考え方を説明します。
リソースグループとはTagを用いて複数のリソースを1つのグループのように扱う概念です。
複数のリソースをグルーピングできるため、AWS内で操作対象をまとめて指定するときに重宝します。
つまり、運用の効率化や自動化の対象を指名するときに個々のリソース指定ではなくリソースグループ名を指定すればよくなるので、Systems Managerと組み合わせることでより効率的な運用ができます。
共有リソース
Documents
DocumentsはSystems Manager が実行する操作を定義します。
Documents Typeには、State Manager と Run Command で使用される Command Documentsや、Systems Manager Automation で使用される Automation Runbookなどがあります。
Systems Manager には、実行時にパラメータを指定して使用できる事前設定済みのドキュメントが 数十件含まれているため、一から起こす必要はないことがほとんどです。
例えば、Run Commandでhttpdをインストールしたいときには以下のようなDocumentsを記載します。
---
schemaVersion: "2.2"
description: "Install httpd using runcommand"
mainSteps:
- action: "aws:runShellScript"
name: "installHttpd"
inputs:
runCommand:
- "#!/bin/bash"
- "yum -y install httpd"
- "systemctl start httpd"
- "systemctl enable httpd"
アプリケーション管理
Parameter Store
Parameter Storeは文字通り、パラメータを格納するためのサービスです。
CloudFormationやアプリケーションのパラメータを安全に格納するために利用します。
格納したパラメータは必要に応じて呼び出すことができます。
このとき、認可部分はIAMと統合されているので不要な人がパラメータを読み取ってしまう心配はありません。
Parameter Storeへ格納する形式は平文あるいは暗号化のいずれかを選べます。
RDSへの接続情報などシークレット値は暗号化をかけるのがベストプラクティスです。
なお、ローテーションしたいシークレット値はParameter StoreではなくSecrets Managerへの格納がベストプラクティスになるので使い分けは正しく行いましょう。
ノード管理
Fleet Manager
Fleet Managerは、EC2フリートを効果的に管理するためのサービスです。
コンソールからリアルタイムでフリートの状態を監視し、構成変更やパッチ適用を容易に行えます。
セキュリティポリシーの統一や、異なるリージョンやアカウントでのフリートの展開をサポートします。
ただし、Fleet Managerの最も多い用途はWindowsサーバへのRDPです。
Fleet Managerを用いるとマネジメントコンソールからWindowsサーバにRDPライクな接続をすることができます。
画面転送なので動作はやや遅いですが、踏み台を作らずにWindowsサーバにアクセスできるメリットは非常に大きいです。
しかし、注意点は操作ログが完全には取れないという点です。
Windowsサーバの宿命ですが画面操作を伴う場合、ログにすべての操作が出ないため監査がある場合には別途画面録画ソフトなどが必要になります。
Session Manager
AWS Systems ManagerのSession Managerは、SSHやSCPなどのセキュアなリモートシェルアクセスを提供するサービスです。
SSHと比較してアクセス用のポートを穴あけする必要がなくなるためNW観点でのセキュリティが向上します。
また、Session ManagerはIAMロールやポリシーを使用してアクセスを管理し、セッションログを自動的に記録します。
これにより、踏み台の管理をなくしながらもセキュリティと監査レベルの維持が可能です。
ただし、画面はないのでWindowsサーバへのRDPに近いことをしたければFleet Managerを利用する必要があります。
Run Command
Run CommandはEC2内部でコマンド実行するための機能です。
大きな特徴はSSHが不要なことです。
SSH不要で使えるため、SSHを用いたコマンド実行よりもNW観点でのセキュリティが向上します。
また、EventBridgeを起点にコマンドを実行できるので定期実行のみではなくイベント駆動でのコマンド実行も可能です。
なお、コマンドの出力はS3やCloudWatchLogsに送れるのでコマンド結果の解析に困ることはありません。
Run Commandを利用すると、例えばcrontabに書いていた処理をCloudFormation側に寄せることができるので資材の管理がより容易になります。
つまり、IaCの観点からもセキュリティの観点からもEC2内部でコマンド実行したい際にはRun Commandを使うのがベストプラクティスです。
Patch Manager
Patch Managerはセキュリティ関連とその他のアップデートの両方でノードにパッチ適用するプロセスを自動化します。
Patch Managerを利用するためにはまず、パッチベースラインを自動あるいは手動で設定します。
加えて、パッチを適用する単位のパッチグループを定義します。
ここまで設定できればあとはパッチベースラインからのずれをパッチグループ単位に適用していく、というのが基本の流れです。
パッチ適用の方法はパッチワークベースラインに対して自動適用あるいは、承認済みのパッチのみ適用の2つの方法を選ぶことができます。
AWSとしては自動適用がベストプラクティスですが、実プロジェクトではそうもいかないので承認済みのパッチのみ適用するのが現実的です。
また、パッチの適用タイミングはオンデマンドあるいはMaintenance Windowsを用いたスケジュール適用を選ぶことが可能です。
こちらも実プロジェクトではダウンタイムを管理したいという要望から後者を選ぶことがベストプラクティスです。
なお、Patch Managerはパッチの適用だけではなく、ノードをスキャンして不足しているパッチを洗い出すことも可能です。
AWS Systems Managerのセキュリティ
AWS Systems ManagerはほかのAWSサービス同様セキュリティを重視し、以下の機能を通じてリソースやデータの保護を実現しています。
まず、アクセス制御です。
IAMロールを使用して、AWS Systems Managerへのアクセスを制御します。
必要なユーザーにのみ権限を与え、最小特権の原則に基づいてセキュリティを確保します。
次にParameter Storeの暗号化についてです。
Parameter StoreはKMSを使用してデータを暗号化し、セキュリティを強化します。
最後にネットワークについてです。
AWS Systems Managerは、VPCエンドポイントを通じて内部ネットワークでの通信を可能にします。
インターネットを経由せずにVPC内で通信することで、セキュリティを向上させます。
特にSession Managerではインターネットを経由せずにEC2へのアクセスが可能となるため、エンタープライズでは使用することがベストプラクティスになります。
AWS Systems Manager for Advance
変更管理
Automation
AutomationはEC2やほかのAWSリソースに対する運用やデプロイ作業を自動化するための機能です。
具体的な用途はAMIの作成、ドライバーとエージェントの更新プログラムの適用、Windows Server インスタンスでのパスワードのリセット、Linux インスタンスでの SSH キーのリセットなどがあげられます。
Automationを使うときにはRunbookと呼ばれるDocumentsを作成します。
なお、ここでいうDocumentsは共有リソースのDocumentsで説明したものと同じです。
Run Commandと違うのはEC2内部でのコマンド実行だけではなくAWSのAPI実行も守備範囲という点です。
また、呼び出し元はEventBridge以外にもマネジメントコンソールやAWS SDKなど様々な種類があります。
そのため、自動化だけではなく定型作業をRunbookに記載しておき、必要な時にはAutomationを実行するという使い方も可能です。
これはAWSにおける運用の効率化観点でのベストプラクティスです。
Maintenance Windows
Maintenance Windowsは、予定されたパッチ適用やリソースの保守作業を自動化するためのサービスです。
指定された時間帯に、指定したリソースグループに対して一括でアクションを実行できます。
柔軟なスケジュール設定と統合されたターゲティングにより、運用効率が向上します。
なお、Maintenance Windowsはこれ単体で利用するというよりもPatch Managerなどと組み合わせてタイミングを指定する用途で使うことが多いです。
まとめ
この記事ではAWS Systems Managerに関連する内容を超詳細にまとめました。
- AWS Systems Managerとは
- AWS Systems Managerの仕組み
- AWS Systems Managerのセキュリティ
- AWS Systems Manager for Advance
次回からはクラウドのレジリエントについてまとめていきます。