前回「AWS動作検証【3】（AWS BackupによるEC2バックアップ・復元）」の続きとなります。
#■■ 筆者情報 ■■
・AWSの資格試験はプロフェッショナルまで取得済。
・AWSの操作経験は初心者並み。
・理論は解っていても操作は解っていない状況。
※資格試験取得に興味のある方は「AWS認定試験の勉強方法」を参照ください。
#■■ この記事を読んでほしい対象 ■■
・AWSの知識はある程度ついたので、AWS操作を一通り実施したい人。
・AWS公式ドキュメントをベースに手順を確認したい人。
※手順を簡単にまとめてくれているサイトも多々ありますが、可能な限りAWSの公式ドキュメントを読み解きながら確認を実施しています。その為、この記事のリンクの多くは公式ドキュメントに対して貼られており、どうしても公式ドキュメントのみだと解らない場合に、個人のHPを頼っています。
#■■ AWSのEC2サーバ自動化運用 ■■
EC2インスタンスに関しては、インスタンス起動中のみ課金される前提となります。そうなると利用しない時間帯はインスタンスを停止しておけば、課金額を抑えることができます。サードベンダーの多機能・高性能なジョブ管理ツールを使用してCLIで指示する形が理想形だと思いますが、まずはAWS単体の機能で実施できることを整理してみました。
・方式【1】「CloudWatch-Event」＋「SystemsManager」パターン
・方式【2】「CloudWatch-Event」＋「Lambda」パターン
パターンとしては概ねこの2パターンになります。これまでのAWSでは方式【2】が主流だったようですが、SystemMangerの機能が追加されてからは方式【1】が主流になっているようです。
その為、今回の検証は、方式【1】を実施します。
#■SystemsManagerの仕様について（検討要）
基本的にEC2インスタンスは利用しない時は手動で停止していました。本日2日ほど起動せずに置いているとSystemsManagerの「マネージドインスタンス一覧」に表示されていなことに気付きました。EC2インスタンスを起動すると、再度表示されるようになりました。
SystemsManagerの「インベントリ」画面でもインスタンス停止中は何も表示されません。
しかし、インスタンスを起動させると表示されます。
AWSのHPを調べていると「Systems Manager コンソールの [マネージドインスタンス] に EC2 インスタンスが表示されないのはなぜですか?」との投稿がありました。前提条件の「当該インスタンスにおいてSSMエージェントがインストールおよび実行されている」がポイントで、要は「インスタンス停止中＝SSMエージェントが実行されていない=マネージドインスタンスの対象にならない」ということです。
インスタンスをマネージドインスタンスにするには、次の前提条件を満たす必要があります。
・AWS Systems Manager エージェント (SSM エージェント) がインストールおよび実行されている。
・SSM エージェントを使用して Systems Manager エンドポイントに接続されている。
・適切な AWS Identity and Access Management (IAM) ロールがアタッチされている。
・インスタンスメタデータサービスに接続されている。
私はSSMエージェントを設定したインスタンス情報はインスタンス状況に関わらず一元管理できると思っていたので、サーバ管理に利用できると思っていました。ただ、この仕様だと例えば利用料の関係で停止している開発用サーバ等はこの一覧には表示されないので、全体のサーバ情報としては確認できないことになります。その為、そういった用途の場合は、別の仕組みを考える必要がありそうです。
#■EC2インスタンスの自動停止・自動起動（SystemsManager)
方式【1】「CloudWatch-Event」＋「SystemsManager」の動作確認を実施しました。
##IAMロールの作成（IAM）
Systems Manager Automation に対するサービスロール (引き受けロール) を作成します。
##ロールへの信頼関係追加（IAM）
信頼されたエンティティに対して「events.amazonaws.com」を追加します。
信頼されたエンティティに正常に表示されることを確認します。
##イベント追加・動作確認（自動停止）（CloudWatch-Events）
AWSに日本語版のドキュメントが無く、英語版のドキュメントをGoogle Cromeを使用して解読しました。英語力のある人には必要の無い労力です。Cromeで一度「日本語の翻訳」を選択して翻訳するとリンクページを含めてすべて日本語に翻訳してくれるので大変便利です。
EC2インスタンスの停止設定を実施します。
スケジュールはCron式での登録になります。UTC時間なので、日本時間マイナス9時間で考える必要があります。例えば日本時間が12時なら、UTC時間は3時なので、3時で登録する必要があります。
| 項目 | 選択内容 |
|---|---|
| イベントソース | 「スケジュール」を選択 |
| スケジュール入力欄 | スケジュールを設定 |
| ターゲット | SSM Automation |
| ドキュメント | AWS-StopEC2Instance |
| オートメーションパラメータの設定 | 「定数」を選択。 |
| instanceID | 停止させたいインスタンスのIDを設定 |
| インプットトランスフォーマー | 「既存のロールを使用」を選択。 |
| ロール入力欄 | 先ほど作成したロールを設定 |
| ルールの定義：名前 | ルールの定義の名前を設定 |
 |
|
 |
|
| ルールの定義画面で設定した名前のルールが作成されます。 | |
 |
設定した時間になるとインスタンスが停止しました。実行結果はSystemsManagerの「自動化」画面で確認できます。この後でサーバを起動しなおしてOS画面上でシステムログを確認しましたが、通常のシャットダウンと同じ停止の流れでした。
なお、CloudWatchでもルール名称で検索することで、実行結果を確認できます。
##イベント追加・動作確認（自動起動）（CloudWatch-Events）
EC2インスタンスの起動設定を実施します。
スケジュールはCron式での登録になります。UTC時間なので、日本時間マイナス9時間で考える必要があります。例えば日本時間が12時なら、UTC時間は3時なので、3時で登録する必要があります
| 項目 | 選択内容 |
|---|---|
| イベントソース | 「スケジュール」を選択 |
| スケジュール入力欄 | スケジュールを設定 |
| ターゲット | SSM Automation |
| ドキュメント | AWS-StaartEC2Instance |
| オートメーションパラメータの設定 | 「定数」を選択。 |
| instanceID | 起動させたいインスタンスのIDを設定 |
| インプットトランスフォーマー | 「既存のロールを使用」を選択。 |
| ロール入力欄 | 先ほど作成したロールを設定 |
| ルールの定義：名前 | ルールの定義の名前を設定 |
 |
|
 |
|
| ルールの定義画面で設定した名前のルールが作成されます。 | |
 |
設定した時間になるとインスタンスが起動しました。実行結果はSystemsManagerの「自動化」画面で確認できます。サーバに接続してOS画面上で確認しましたが、問題なく起動されており、エラー等はありませんでした。
なお、CloudWatchでもルール名称で検索することで、実行結果を確認できます。
#■■ まとめ ■■
今回のサーバ自動停止・自動起動はかなり簡単に設定可能でした。また、CloudWatchとSystemsMangerを組み合わせれば他にも色々なことができそうなので、試してみたいと思いました。今回は単体でのサーバ自動停止・自動起動でしたが、業務システムが稼働している場合は、前後にサービス停止処理等を実施する必要が出てきます。そういった処理をAWSの仕組みを使ってうまく実現できるかを、今後検証したいと思います。今回はあくまでGUIでしたがコマンドラインを利用した処理を検証していきたいです。
また、SystemsManagerの「当該インスタンスにおいてSSMエージェントがインストールおよび実行されている」というところの仕様把握ができたので、今後は資産管理の観点でどう機能を使い分けるかも検討していきたいと思います。
次回は「AWS動作検証【5】（AWS CLIによるサーバ停止・スナップショット取得・サーバ起動）」です。
以 上