Amazon Web Services ブログ

AWS Systems Manager Automation によるマルチアカウント、マルチリージョンでの一元的にスケジューリングされたパッチ適用

このブログは Erik Weber (World-wide Specialist Solutions Architect for AWS Management & Governance services)によって執筆された内容を⽇本語化したものです。原⽂はこちらを参照して下さい。

以前の ブログで、 AWS Systems Manager Automation を使用して、手動で(または AWS CLI から start-automation-execution を使用して)複数の AWS アカウントとリージョンにわたってマネージドノードにパッチを適用する方法を示しました。このブログでは、 Amazon EventBridge (旧 Amazon CloudWatch Events), AWS Lambda, および AWS Systems Manager Automation を使用して、複数の AWS アカウントとリージョンにわたってパッチ適用をスケジュールする方法を紹介します。

マルチアカウントの Automation パッチ適用をスケジュールするために AWS CloudFormation スタック を使って管理アカウントとターゲットアカウントを設定する手順を説明します。

管理モデル

このアーキテクチャとチュートリアルでは、組織内のターゲットアカウントに対するパッチ適用を 1 カ所から実行する一元管理方式を採用しています。

AWS Systems Manager を使用する利点は、 Systems Manager リソースデータの同期を使用することで、一元的なレポートソースを維持しつつ管理モデルを柔軟に変更できることです。リソースデータの同期を使用して、インベントリ、パッチ適用、コンプライアンスデータを送信できます。このデータは複数のマネージドノードから 1 つの Amazon Simple Storage Service (Amazon S3) バケットに収集されます。リソースデータの同期は、新しいインベントリデータが収集されると S3 バケットのデータを自動的に更新します。すべてのインベントリデータをターゲットの S3 バケットに保存すると、 Amazon Athena や Amazon QuickSight などのサービスを使用して、集計されたデータのクエリと分析を行うことができます。

アーキテクチャ概要

このチュートリアルでは、管理アカウントまたは権限の委任されたアカウントから EventBridge と Lambda を使用してマルチアカウントおよびマルチリージョンの Automation ランブックをスケジュールします。

 

管理アカウントには、スケジュールされた EventBridge ルール、Lambda 関数、Systems Manager Automation が含まれます

図 1: マルチアカウント/マルチリージョンのパッチ適用ワークフローをスケジュールするためのアーキテクチャ

このプロセスの流れは次のとおりです:

  1. 管理アカウントでは、指定された cron またはレートベースの式に基づいて EventBridge ルールがトリガされます。
  2. EventBridge ルールは Lambda 関数を呼び出し、マルチアカウント/マルチリージョンの Automation ワークフローを開始します。
  3. Systems Manager 管理ロールは、各リージョンの各ターゲットアカウントで実行ロールを引き受けます。
  4. 実行ロールは AWS-RunPatchBaseline の Run Command タスクを開始します。
    このコマンドは、指定された AWS Resource Group で指定されたターゲットマネージドノードに対して、更新をスキャンするか、不足している更新をインストールします。

前提条件

Automation ワークフローまたは Run Command タスクでタグベースのターゲット設定を使用する場合、ターゲットに指定できるのは単一のタグキーと値のペアのみです。 AWS Resource Group は複数のタグに基づくグループ化された評価基準をサポートしているため、今回はこれをターゲットとして使用します。

このブログで使用する Automation ランブック は、リソースグループを使用して Systems Manager マネージドノードを対象とします。マネージドノードに不足しているパッチをスキャンしたり更新をインストールしたりするには、リソースが対象のリソースグループに含まれている必要があります。

詳細については、 AWS Resource Groups ドキュメントの AWS Resource Groups でクエリとグループを作成する を参照してください。リソースグループは、すべてのターゲットアカウントでまったく同じ名前である必要があります。

マルチアカウントとマルチリージョンの管理

このブログでは、社内の他のアカウントからの結果を監視および集計する管理アカウントが設定されていることを前提としています。AWS CloudFormation StackSets を使用して、管理アカウントからターゲットアカウントにスタックを伝播して実行します。管理アカウントとターゲットアカウントに、これらのスタックの実行に必要な権限が設定されていることを確認します。詳細については、 AWS CloudFormation ドキュメントで、 スタックセットオペレーションの前提条件 を確認してください。この設定がない場合、または StackSets の使用を避けたい場合は、各ターゲットアカウントで個々の CloudFormation スタックを使用できます。

チュートリアル

手順の流れは以下の通りです。

  1. AWS CloudFormation スタックをデプロイして管理アカウントをセットアップし、以下のリソースを作成します。
    • EventBridge ルール
    • Lambda 用の AWS Identity & Access Management (IAM) サービスロール
    • Lambda 関数
    • 管理アカウントの Automation 用 IAM サービスロールである AWS-SystemsManager-AutomationAdministrationRole
    • AWS-RunPatchBaseline コマンドドキュメントを実行するための Automation ランブック
  2. AWS CloudFormation スタックをデプロイしてターゲットアカウントをセットアップし、ターゲットアカウントの Automation 用の IAM サービスロールである AWS-SystemsManager-AutomationExecutionRole を作成します。

ステップ 1: 管理アカウントにリソースをデプロイする

まず、管理アカウントとして 1 つのアカウント、管理リージョンとして 1 つの AWS リージョンを選択します。この管理場所 (管理アカウントと管理リージョン) から、他の AWS アカウントとリージョンを対象とする Automation タスクをスケジュールできます。すでに Systems Manager Explorer または AWS Organizations を使用している場合は、AWS Organizations 管理アカウント、または Systems Manager Explorer の委任管理者として指定されたアカウントを使用できます。詳細については、 委任管理者の設定 を参照してください。

以下の GitHub ページを開き、 Scheduled-Patch-Automation.yaml ファイルをダウンロードします。

https://github.com/aws-samples/aws-systems-manager-schedule-central-patch-example/blob/main/Templates/Scheduled-Patch-Automation.yaml

  1. 管理アカウントの管理リージョンで、AWS CloudFormation コンソールに移動します。
  2. 左側のナビゲーションペインで スタック を選択し、 スタックの作成 を選択します。
  3. ドロップダウンリストから 新しいリソースを使用 (標準) を選択します。
  4. スタックの作成 ページで テンプレートファイルのアップロード 、 ファイルの選択 を選択し、先ほどダウンロードした Scheduled-Patch-Automation.yaml ファイルを指定し、 次へ を選択します。
  5. スタックの詳細を指定 ページで以下の操作を行います。
    • EventBridgeRuleSchedule には、EventBridge ルールのスケジュールに対する cron またはレートベースの式を入力します。たとえば、 “cron(15 22 ? * TUE *)” は、火曜日の 22:15 UTC にパッチ適用を開始するようにルールをスケジュールします。詳細については、 Amazon EventBridge ドキュメント の スケジュールに従って実行する Amazon EventBridge ルールの作成 を参照してください。
    • ExecutionRoleName では、マルチアカウントおよびマルチリージョン Automation のパッチ適用操作中にターゲットアカウントで引き受ける Automation 実行ロールをオプションで変更できます。
    • ExistingAutomationAdministrationRole では、マルチアカウントおよびマルチリージョンの Automation ワークフローを呼び出す権限を持つ既存の Automation 管理ロールの IAM ロール ARN をオプションで入力できます。ARN を指定しない場合、AWS CloudFormation テンプレートによって Automation 管理ロールが作成されます。
    • MaximumConcurrency では、このタスクを並列に実行できるターゲットの最大数を指定します。10 などの数値、または 10% などのパーセンテージを指定できます。デフォルト値は 10% です。
    • MaximumErrors では、システムが追加のターゲットでタスクの実行を停止するまでに許容されるエラーの最大数を指定します。10 などの数値、または 10% などのパーセンテージを指定できます。デフォルト値は 10% です。
    • ResourceGroupName では、ターゲットとなるリソースを含むリソースグループ名を指定します。リソースグループ名では大文字と小文字が区別されます。
    • RunPatchBaselineInstallOverrideList では、インストールするパッチのリストへの HTTPS URL または Amazon S3 パススタイルの URL をオプションで入力できます。このパッチインストールリストは、デフォルトのパッチベースラインで指定されているパッチを上書きします。
    • RunPatchBaselineOperation で Scan を選択すると
      不足している更新プログラムのスキャンのみを行います。Install を選択すると、パッチベースラインのルールに基づいて不足している更新プログラムをスキャンしてインストールします。
    • RunPatchBaselineRebootOption では、パッチ適用時の再起動動作を選択します。有効なオプションは RebootIfNeeded と NoReboot です。デフォルトのオプションである RebootIfNeeded は、更新プログラムがインストールされると強制的に再起動します。重要: Scan が選択されている場合、更新プログラムはインストールされません。詳細については、 AWS-RunPatchBaseline parameters を参照してください。
    • TargetAccounts では、ターゲットアカウントのリストをカンマ区切りのリストで入力します。AWS アカウント ID または AWS Organizations の OU ID (例: 012345678901,987654321098 ) を指定できます。
    • TargetLocationMaxConcurrency では、 Automation を同時に実行できる AWS アカウントと AWS リージョンの最大数をオプションで変更できます。デフォルト値は 1 です。
    • TargetLocationMaxErrors では、アカウントとリージョンのペア単位で、追加の Automation 実行のキューイングを停止するまでに許容されるエラーの最大数をオプションで変更できます。デフォルト値は 1 です。
    • TargetRegionIds では、ターゲットリージョンのリストをカンマ区切りのリスト (例: us-east-1,us-east-2 ) で入力します。

管理アカウントにデプロイする CloudFormation スタックのパラメータ例

図 2: AWS CloudFormation コンソールの スタックの詳細を指定 画面

  1. スタックオプションの設定 ページで必要なタグを追加し 次へ を選択します。
  2. すべての情報を確認し、AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します。 を選択し、スタックの作成 を選択してスタック設定を送信します。

ページが更新されると、スタックのステータスは CREATE_IN_PROGRESS になります。ステータスが CREATE_COMPLETE に変わったら、次のセクションに進みます。

ステップ 2: ターゲットアカウントにリソースをデプロイする

ターゲットアカウントで Automation 実行ロール AWS-SystemsManager-AutomationExecutionRole を既に作成している場合はこのステップをスキップできます。このロールを作成しておらず、管理アカウントとの信頼関係を確立していない場合は、次の手順に従ってターゲットアカウントを設定します。

次の GitHub ページを開き、 AWS-SystemsManager-AutomationExecutionRole.yaml ファイルをダウンロードします。

https://github.com/aws-samples/aws-systems-manager-schedule-central-patch-example/blob/main/Templates/AWS-SystemsManager-AutomationExecutionRole.yaml

このテンプレートは、ターゲットアカウントに AWS-SystemsManager-AutomationExecutionRole を作成します。

  1. 管理アカウントで AWS CloudFormation コンソール に移動し、左側のナビゲーションペインから StackSets を選択し、StackSet の作成 を選択します。
  2. テンプレートの選択 ページで、以下の内容を指定します。
    アクセス許可 セクションの内容は、AWS Organizations を有効にしているかどうかによって異なります。

    • AWS Organizations を有効にしていない場合は、セルフサービスのアクセス許可 を選択します。
    • AWS Organizations を有効にしている場合は、サービスマネージドアクセス許可 を選択し、 StackSet を組織または OU に適用できます。手動で制御する場合は セルフサービスのアクセス許可 を選択することもできます。今回は、 セルフサービスのアクセス許可 を選択します。

    テンプレートファイルのアップロード、ファイルの選択 を選択し、 先ほどダウンロードした AWS-SystemsManager-AutomationExecutionRole.yaml ファイルを選択し、次へ を選択します。

  3. StackSet の詳細を指定 ページで任意の StackSet 名を、 ManagementAccountNumber で管理アカウントのアカウント番号を入力し、次へ を選択します。

管理アカウントにデプロイする StackSet のパラメータ例

図 3: AWS CloudFormation コンソールの StackSet の詳細を指定 画面

  1. StackSet オプションの設定 ページで必要なタグを追加して 次へ を選択します。
  2. デプロイオプションの設定 ページでは、この Automation プロセスを実行するターゲットのアカウント番号をカンマ区切りリストで入力します。アカウント番号を記載した .csv ファイルをアップロードすることもできます。ターゲットのリージョンをリストから選択し、 次へ を選択します。

管理アカウントで指定する StackSet のデプロイ先の例

図 4: Set deployment options ページ

  1. 次のページで設定内容を確認し、AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します。 を選択します。次に、送信 を選択して StackSet 設定を送信します。

ページが更新されると StackSet が表示されます。リソースの作成が完了すると、ステータスは SUCCEEDED に変わります。

Automation の実行を確認する

Automation が実行されると、Systems Manager で実行結果を確認することができます。

Systems Manager コンソールに移動し、自動化 を選択します。このページには、実行済みの Automation ドキュメント（ランブック）の一覧が表示されます。

ドキュメント名 と 実行者 をもとに、実行結果を確認することができます。Lambda 関数の実行結果は、実行者 列に Lambda 実行ロールの ARN が設定されます。

Automation の実行と実行ロール

図 5: AWS Systems Manager コンソールの Automation の実行

クリーンアップ

このチュートリアルのステップ 1 で作成したリソースを削除するには、管理アカウントの AWS CloudFormation コンソール に移動します。作成したスタックを選択し、削除 を選択します。

このチュートリアルのステップ 2 で作成したリソースを削除するには、管理アカウントの AWS CloudFormation コンソール に移動します。左側のナビゲーションペインで StackSets を選択し、作成した StackSet を選択し、アクション から StackSet からスタックを削除 を選択します。デプロイオプションの設定 画面で StackSet をデプロイしたターゲットアカウントのアカウント番号を入力して すべてのリージョンを追加 を選択し、 次へ を選択し、 送信 を選択します。すべてのスタックインスンタンスを削除したら、あらためて StackSet の一覧画面から対象の StackSet を選択し、アクション から StackSet の削除 を選択します。

まとめ

このブログでは、EventBridge、Lambda、および Systems Manager Automation を使用して、複数の AWS アカウントとリージョンにわたって Systems Manager マネージドノードのパッチ適用をスケジュールする方法を紹介しました。

まず、AWS CloudFormation を使用して、管理アカウントに必要なリソースを作成する方法を説明しました。管理アカウントを設定した後、AWS CloudFormation StackSets を使用して Automation 実行ロールをターゲットアカウントにデプロイする方法を説明しました。

マルチアカウントおよびマルチリージョンのパッチ適用オペレーションを最初に呼び出した後、結果を表示して、必要な更新が不足しているマネージドノードを特定できます。AWS Systems Manager Explorer を使用すると、環境全体のパッチ適用コンプライアンスを表示できます。これは、マネージドノードのパッチ適用コンプライアンス状態を含む、カスタマイズ可能な運用ダッシュボードを提供します。詳細については AWS Systems Manager のドキュメント で、AWS Systems Manager Explorer と、複数のアカウントおよびリージョンのデータを表示するように Systems Manager Explorer を設定する を確認してください。

リソースデータの同期設定を作成することで、パッチ適用、コンプライアンス、インベントリのデータを 1 つの場所に集約し、任意の S3 バケットに同期することができます。詳細については インベントリのリソースデータの同期の設定 を参照してください。

リソースデータの同期設定を作成したら、Amazon Athena と Amazon QuickSight を設定して、パッチ適用とインベントリ関連データの可視化を開始することができます。詳細については 複数のリージョンとアカウントからのインベントリデータをクエリする を参照してください。

このブログで紹介されているリソースと可視化に必要なリソースを作成する CloudFormation サンプルテンプレートについては、GitHub サンプル Operational Management: Inventory, Patching, and Compliance を参照してください。

作者について

Erik Weber

Erik Weber は、AWS Management & Governance サービスのワールドワイドスペシャリストソリューションアーキテクトです。AWS Systems Manager と AWS Config を専門としています。仕事以外では、ハイキング、料理、サイクリングに情熱を注いでいます。

翻訳は Solutions Architect の小野が担当しました。原文はこちらです。