【SSM Patch Manager】EC2インスタンスへのパッチ適用前に AMIバックアップを取る

2021.06.28

はじめに

いくつか Systems Manager(SSM) Patch Managere を使ったパッチ適用環境のブログを上げてきました。

継続してパッチ適用を行うインスタンスには、同じく継続してAMIバックアップを取っておきたいです。 パッチ起因のトラブルに備えるためです。

今回は パッチ適用前に AMIバックアップを取る仕組みの 1例を紹介します。 メンテナンスウィンドウでパッチ適用を行う前提で、 そのメンテナンスウィンドウにAMIバックアップのタスクを組み込みます。

マネジメントコンソールから行います。 おおまかな流れは以下のとおりです。

  • メンテナンスウィンドウの作成
  • パッチタスクの設定
  • バックアップタスクの設定

メンテナンスウィンドウの作成

SSM メンテナンスウィンドウのページから [メンテナンスウィンドウの作成] を選択します。

ウィンドウの名前は適当に patching-window-with-backup 等にします。

img

次に スケジュールを定めます。

  • 毎日 AM2:00(JST) に実行
  • 期間は 1時間
  • カットオフは 0

としています

img

他の値はデフォルトで作成しましょう。

パッチタスクの設定

メンテナンスウィンドウから AWS-RunPatchBaseline SSMドキュメントを実行する タスクを登録します。

が、これはパッチマネージャー から簡単に登録できるので、そちらで実施します。 パッチマネージャーから [パッチ適用を設定] を選択します。

img

PatchWithBackup:true タグをターゲットとします。 後に ここで指定したタグを対象のインスタンスに付与します。

img

パッチ適用スケジュールは先程のメンテナンスウィンドウを選択します。

img

パッチ適用操作は「スキャンとインストール」を選択します。

img

作成が完了した後に メンテナンスウィンドウを確認すると、 パッチ適用のタスク PatchingTask が登録されているはずです。

img

「バックアップタスクの設定」の事前準備

「バックアップタスクの設定」では AWS-CreateImage と呼ばれる オートメーションドキュメントを活用します。 このオートメーションを実行するためのIAMロールを作成しておく必要があります。

以降で IAMロールを作成します。

  • 信頼されたエンティティの種類 … AWSサービス
  • ユースケース … Systems Manager

を選択して次に進みます。

一旦ポリシーは何も選択せず、名前を image-backup-automation-role などとして、 ロールを作成します。

作成後、以下のようなインラインポリシーを追加しました。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:CreateImage",
                "ec2:DescribeImages"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

ロールのARN arn:aws:iam::123456789012:role/image-backup-automation-role を控えておきます。

バックアップタスクの設定

AWS-CreateImage オートメーションを、パッチタスクの前に挿入します。

オートメーションタスクの登録 を選択します。

img

名前は create-image などとして、 オートメーションドキュメントは AWS-CreateImage を選択します。

img

↑優先度は 0(ゼロ) にしましょう。 すでに登録している PatchingTask(優先度1) よりも前に実行したいからです。

ターゲットは「パッチタスク作成」段階で生成された PatchingTarget を選択します。

img

入力パラメータは以下の通り。

  • InstanceId{{ TARGET_ID }} とします。 これは 疑似パラメータ と呼ばれるもので、 今回は「実行対象のインスタンスID」を表します
  • NoReboot はイメージ作成前にリブートするかどうか指定します。 今回は true(再起動しない) とします
  • AutomationAssumeRole は先程の事前準備で作成した IAMロールの ARNを指定します

img

レート制御は環境よって適宜チューニングしてください。

img

他デフォルトで作成します。 以下のように 2つのタスクが確認できたら OK です。

img

確認

以下のようなタグ情報を付与した EC2インスタンスを作成しました。 最低限 PatchWithBackup:true は必要です。 Patch Group タグは各々の環境で設定している Patch Manager ベースラインに合わせてください。

img

次の日に確認すると、履歴からタスク実行を確認できました。

img

2つのタスク AWS-CreateImage, AWS-RunPatchBaseline が実施されていること が確認できます。

img

以下 AWS-CreateImage タスクのログです。出力から AMI ID を確認できます。

img

以下 AWS-RunPatchBaseline タスクのログです。今回は Amazon Linux 2 インスタンスだったので PatchLinux ステップでパッチインストールのログを確認できます。 今回は S3バケットへのログ出力はしていません。パッチタスクのログはほぼコンソールで保存できる 文字数上限を超えてくるので、S3バケットへの保存をおすすめします。

img

おわりに

「AMIバックアップ → パッチ適用」の仕組みを作ってみました。 メリットは SSMの機能で完結するところでしょうか。 デメリットは 作成するAMIのライフサイクルを別途考える必要があることです。

AWS Backupを使えば AMIの有効期限を簡単に設定できるので、デメリットを解決したい場合は こちらを選択すると良さそうです。

参考