以下の内容はhttps://xp-cloud.jp/blog/2026/02/26/100000より取得しました。

AWS Systems Manager Automationで始める運用自動化

AWS AWS Systems Manager Automation AWS Systems Manager

こんにちは。kanazawaです。
運用業務において、定期作業や障害対応手順の実行など、定型的なタスクを自動化することは運用負荷の削減につながります。
AWS Systems Manager Automation（以下、Automation）を使えば、複数ステップのワークフローを組み合わせて柔軟な運用自動化が実現できます。
本記事ではAutomationの概要と、実践としていくつかの例をご紹介します。

目次

AWS Systems Manager Automationとは

AWS Systems Manager Automationとは、AWS Systems Managerの機能の1つで、
EC2インスタンスやその他のAWSリソースに対する定期メンテナンス、アプリケーションデプロイ、障害復旧などの一般的なタスクを簡素化するサービスです。
JSON形式またはYAML形式のRunbookでワークフローを定義し、AWSリソースの管理を自動化できます。

Automationを使うことで、以下のような運用タスクを自動化できます。

  • 定期的なメンテナンス作業: 夜間・休日のインスタンス停止/起動、インスタンスタイプの変更
  • バックアップの自動化: AMIやスナップショットの定期作成、古いバックアップの削除
  • 障害対応の自動化: 異常検知時の自動復旧、ログ収集、通知
  • 変更作業の標準化: 承認フローを含む変更手順の実行、作業ミスの防止

Runbookの概要

Automationでは「Runbook」と呼ばれるYAML/JSON形式のファイルで自動化の内容を定義します。
Runbookには以下の2種類があります。

  • AWSマネージドRunbook: AWSが提供するRunbook（EC2起動/停止、AMI作成など）
  • カスタムRunbook: 独自の要件に合わせて作成するRunbook

Runbook内では複数のステップを組み合わせてワークフローを定義でき、AWS APIの呼び出し、リソースの状態監視、承認待ち、条件分岐などを実行できます。

Runbookは、schemaVersion、description、parameters、mainStepsなどの要素で構成されます。
以下は、EC2インスタンスを停止する最小構成の例です。

schemaVersion: '0.3'
description: 'EC2インスタンスを停止'
parameters:
  InstanceId:
    type: String
    description: '対象のEC2インスタンスID'
mainSteps:
  - name: StopInstance
    action: aws:executeAwsApi
    inputs:
      Service: ec2
      Api: StopInstances
      InstanceIds: ['{{ InstanceId }}']

必須要素

  • schemaVersion: 固定値 '0.3'
  • description: Runbookの説明
  • mainSteps: 実行する処理を順番に定義

主なオプション

parameters:

実行時に値を渡すためのパラメータを定義します。
上記の例では、InstanceId をパラメータとして定義し、mainSteps内で {{ InstanceId }} という形式で参照しています。

action:

mainStepsの各ステップでは、actionフィールドでアクションを指定します。
利用可能なアクションの詳細は、公式リファレンスを参照してください。

実践1: AWSマネージドRunbookを実行

AWSが事前に定義したRunbookを使ってみましょう。
この例では1台のEC2インスタンスをRunbookの実行によって停止しています。

AWS-StopEC2Instanceの実行

  1. AWS Systems Manager → 「自動化」をクリックします。
  2. 「オートメーションの実行」をクリックします。
  3. AWS-StopEC2Instance を検索して選択します。
    • ※「Amazonが所有」タブがマネージドRunbook、「自己所有」タブがカスタムRunbookです。
  4. パラメータを入力します。
    • 実行対象のEC2を選択することで、InstanceIdにインスタンスIDがパラメータとして渡されます。
  5. 「実行」をクリックして実行を開始します。

完了すると、以下のように全体のステータスと各ステップで「成功」と表示されました。
画面では以下の情報を確認できます。

  • ステータス: 成功 / 失敗 / InProgress（実行中）
  • 実行時間: 開始時刻と終了時刻
  • ステップの詳細: 各ステップの実行内容と結果

AWSマネージドRunbookの制約

AWSマネージドRunbookは便利ですが、以下の制約があります。

  • 単一の操作のみ: 停止だけ、起動だけなど、1つの操作しかできない
  • 複数ステップのワークフローが組めない: 停止→変更→起動のような一連の処理ができない
  • パラメータが固定: 柔軟な設定変更ができない

これらの制約を解決するために、カスタムRunbookを作成します。

実践2: カスタムRunbookでインスタンスタイプ変更

AWSマネージドRunbookではできない、複数ステップのワークフローを実装します。
今回の例では以下の運用シナリオを想定しています。

  • 開発環境のコスト削減のため、業務時間外は小さいインスタンスタイプに変更したい。
  • 停止→変更→起動を一連のワークフローで実行することで、手作業のミスを防ぎたい。

カスタムRunbookの作成

  1. AWS Systems Manager → 「ドキュメント」 → 「ドキュメントの作成」 → 「オートメーション」をクリックします。
  2. 任意のドキュメント名を入力します。
  3. 以下のコードを入力して「ランブックを作成」から作成します。
schemaVersion: '0.3'
description: 'EC2インスタンスタイプを変更'

# 実行時に指定するパラメータ
parameters:
  InstanceId:
    type: String
    description: '対象のEC2インスタンスID'
  NewInstanceType:
    type: String
    description: '変更後のインスタンスタイプ'
    default: 't3.medium'   # デフォルト値（未入力時はt3.mediumに変更）

mainSteps:
  # ステップ1: インスタンスを停止
  - name: StopInstance
    action: aws:executeAwsApi
    description: 'インスタンスを停止'
    inputs:
      Service: ec2
      Api: StopInstances
      InstanceIds: ['{{ InstanceId }}']
  
  # ステップ2: 停止完了を待機（最大5分）
  - name: WaitForStopped
    action: aws:waitForAwsResourceProperty
    description: '停止完了を待機'
    timeoutSeconds: 300
    inputs:
      Service: ec2
      Api: DescribeInstances
      InstanceIds: ['{{ InstanceId }}']
      PropertySelector: '$.Reservations[0].Instances[0].State.Name'
      DesiredValues: ['stopped']
  
  # ステップ3: インスタンスタイプを変更
  - name: ModifyInstanceType
    action: aws:executeAwsApi
    description: 'インスタンスタイプを変更'
    inputs:
      Service: ec2
      Api: ModifyInstanceAttribute
      InstanceId: '{{ InstanceId }}'
      InstanceType:
        Value: '{{ NewInstanceType }}'
  
  # ステップ4: インスタンスを起動
  - name: StartInstance
    action: aws:executeAwsApi
    description: 'インスタンスを起動'
    inputs:
      Service: ec2
      Api: StartInstances
      InstanceIds: ['{{ InstanceId }}']

AWSコンソール上で、作成したRunbookのフローを確認することもできます。
今回のフローは以下の通りです。

実行方法

  1. 作成したドキュメントを選択します。
  2. 「オートメーションを実行」をクリックします。
  3. パラメータを入力します。
    • InstanceId: 対象のEC2インスタンスID
    • NewInstanceType: 変更後のインスタンスタイプ
  4. 「実行」をクリックして実行を開始します。

完了すると、以下のように全体のステータスと各ステップで「成功」と表示されました。
実行したEC2はt3.smallでしたが、実行後はt3.mediumに変更されていました。

実践3: エラーハンドリングと通知

実運用では、失敗時に通知を受け取りたいケースが多いかと思います。
意図的にエラーを発生させて、通知が届くことを確認してみましょう。
今回の例では以下の運用シナリオを想定しています。

  • インスタンスタイプ変更（実践2の処理）が失敗した場合、運用担当者にメール通知したい。

エラー発生時のフロー:

エラー発生
    ↓
    `onFailure`: `step:NotifyFailure` が動作
    ↓
`NotifyFailure`を実行
    ↓
    SNS経由でメール通知
    ↓
実行終了

前提条件

SNSトピックとメールサブスクリプションを作成しておきます。
詳細な手順は公式ドキュメントを参照してください。

  • SNSトピックARN（例: arn:aws:sns:ap-northeast-1:123456789012:AutomationAlerts）
  • メールアドレスでサブスクリプションを作成済み

エラー通知付きRunbookの作成

実践2で作成したRunbookに、エラーハンドリングと通知処理を追加します。

schemaVersion: '0.3'
description: 'エラー通知付きインスタンスタイプ変更'

parameters:
  InstanceId:
    type: String
    description: '対象のEC2インスタンスID'
  NewInstanceType:
    type: String
    description: '変更後のインスタンスタイプ'
    default: 't3.medium'
  SnsTopicArn:
    type: String
    description: '通知先SNSトピックARN'

mainSteps:
  # ステップ1: インスタンスを停止
  - name: StopInstance
    action: aws:executeAwsApi
    description: 'インスタンスを停止'
    onFailure: 'step:NotifyFailure'
    inputs:
      Service: ec2
      Api: StopInstances
      InstanceIds: ['{{ InstanceId }}']
  
  # ステップ2: 停止完了を待機(最大5分)
  - name: WaitForStopped
    action: aws:waitForAwsResourceProperty
    description: '停止完了を待機'
    onFailure: 'step:NotifyFailure'
    timeoutSeconds: 300
    inputs:
      Service: ec2
      Api: DescribeInstances
      InstanceIds: ['{{ InstanceId }}']
      PropertySelector: '$.Reservations[0].Instances[0].State.Name'
      DesiredValues: ['stopped']
  
  # ステップ3: インスタンスタイプを変更
  - name: ModifyInstanceType
    action: aws:executeAwsApi
    description: 'インスタンスタイプを変更'
    onFailure: 'step:NotifyFailure'
    inputs:
      Service: ec2
      Api: ModifyInstanceAttribute
      InstanceId: '{{ InstanceId }}'
      InstanceType:
        Value: '{{ NewInstanceType }}'
  
  # ステップ4: インスタンスを起動
  - name: StartInstance
    action: aws:executeAwsApi
    description: 'インスタンスを起動'
    onFailure: 'step:NotifyFailure'
    inputs:
      Service: ec2
      Api: StartInstances
      InstanceIds: ['{{ InstanceId }}']
  
  # ステップ5: 失敗通知
  - name: NotifyFailure
    action: aws:executeAwsApi
    description: '失敗通知'
    inputs:
      Service: sns
      Api: Publish
      TopicArn: '{{ SnsTopicArn }}'
      Subject: '[失敗] インスタンスタイプ変更エラー'
      Message: 'インスタンス {{ InstanceId }} の変更処理でエラーが発生しました。確認してください。'

以下がフロー図です。
エラー発生時にNotifyFailureへ進み、正常に完了した場合はメール通知不要としています。

エラーを発生させて通知を確認

意図的にエラーを発生させて、失敗通知が届くことを確認します。

  1. 作成したドキュメントを選択します。
  2. 「オートメーションを実行」をクリックします。
  3. パラメータを入力します。
    • InstanceId: 存在しないインスタンスID（例: i-9999999999999）
    • NewInstanceType: 任意のインスタンスタイプ
    • SnsTopicArn: 作成したSNSトピックのARN
  4. 「実行」をクリックします。

実行すると、想定通りに失敗しました。
StopInstanceでエラーが発生したためNotifyFailureに進み、
エラー通知には成功したことが確認できました。

メールを確認すると指定通りのメッセージを受信しています。
これで、運用担当者はAWSコンソールにログインすることなくRunbookの失敗を把握することができます。

備考

  • 3つの実践でご紹介した例では単一インスタンスを対象に実行していましたが、例えば複数インスタンスに同じタグ値を設定し、そのタグを入力パラメータで指定することで、複数インスタンスを対象に実行することも可能です。
  • 複数インスタンスが実行対象、且つ独立で並列処理をさせたい（他インスタンスの処理を待機しない）場合、Step Functionsと組み合わせることで実装可能です。
  • aws:approveを利用することで、本番環境で重要な変更作業をAutomationによって実施する際など、一時的に処理を停止させ、手動で承認してから再開することも可能です。

総括

本記事では、AWS Systems Manager Automationの概要から基礎的な活用方法までをご紹介しました。
Automationは単体でも便利ですが、EventBridge、Lambda、Step Functionsなどの他のAWSサービスと組み合わせることで、さらに柔軟な運用自動化を実現できます。
これらの応用的な実践についてはまたの機会に触れたいと思います。

過去に、夜間にExcelの手順書を見ながらEC2停止やEventBridgeスケジュールの有効化などを実施したことがありましたが、やはり手作業のため慎重に進める必要があり、非常に時間がかかりました。
コード作成や検証には時間がかかりますが、将来的には負荷を減らすことになるでしょう。
AWS Systems Manager Automationをぜひ活用してみましょう。



以上の内容はhttps://xp-cloud.jp/blog/2026/02/26/100000より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます
不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14