AWS運用手順書の作り方｜記載項目・作成手順・更新のポイント

AWSの運用を担当者の経験や記憶に頼ると、作業方法や判断にばらつきが生じ、確認漏れや対応の遅れにつながります。こうした属人化を防ぐために必要なのが、運用手順書です。

手順書は、AWS環境の変更に合わせて見直していく必要があります。内容が実際の環境とずれると、かえって作業を迷わせる原因になるためです。

この記事では、AWS運用手順書に必要な項目と作り方、定常運用・障害対応・設定変更の具体例、作成後も使い続けるためのポイントを解説します。

AWS運用手順書とは

AWS運用手順書は、監視やバックアップ、設定変更、障害対応などについて、担当者が実際に行う作業をまとめた文書です。

AWS Well-Architected Frameworkでは、定常的な作業にはランブックを用い、問題の調査や解決にはプレイブックを用いる考え方が示されています。こうした手順を整えておくことで、担当者による判断や作業方法のばらつきを減らし、同じ結果を再現しやすくなります。

運用設計書と運用手順書の違い

運用設計書は「どのような方針で運用するか」を決める文書、運用手順書は「その方針を現場でどう実行するか」をまとめた文書です。

運用設計書では、監視対象やバックアップ方針、障害発生時の体制、変更管理のルールなどを定めます。運用手順書では、それらを実行するための具体的な作業内容まで落とし込みます。

たとえば、運用設計書で「EC2インスタンスを定期的にバックアップする」と決めた場合、運用手順書には対象リソース、実施タイミング、操作手順、完了の確認方法、失敗した場合の対応などを記載します。

運用設計書だけでは実際の作業方法までは分かりません。一方、運用方針が決まっていないまま手順だけを作ると、作業の目的や正常と判断する基準が曖昧になります。

AWS運用で手順書が必要な理由

AWSでは、マネジメントコンソールやCLIから設定を変更できます。操作を誤れば、サービス停止やセキュリティ上の問題につながる可能性があります。

手順書がなければ、「この場合はAさんに聞く」「この設定はBさんしか変更できない」といった運用になりやすく、担当者の不在や交代によって作業が止まる原因になります。

手順書を整備しておけば、担当者が変わっても、同じ手順と判断基準に沿って作業できます。AWS Well-Architected Frameworkでも、ランブックには手作業によるエラーを減らし、担当者が異なっても一貫した結果を得られるというメリットが挙げられています。

AWS運用手順書に記載する項目

AWS運用手順書には、対象作業や担当者、実施条件、操作手順、完了条件、異常時の対応などを記載します。

対象作業・対象者・必要な権限

対象となるAWSアカウント、サービス、リソース、実施する作業を記載し、手順書の範囲を明確にします。

あわせて、担当部署や担当者、作業に必要なIAMロールや権限も記載します。AWSでは、タスクの実行に必要な権限だけを付与する「最小権限」がIAMのベストプラクティスとして推奨されています。

たとえばAmazon EC2の操作であれば、対象インスタンス、リージョン、実施する操作、利用するIAMロールまで特定します。

関連記事：最小権限の原則とは？過剰権限のリスクとIAM設計の具体手順

実施条件・所要時間・事前確認

作業日時、メンテナンス時間、事前承認の有無、関連作業の完了状況など、作業を始めるための条件を記載します。想定所要時間や、サービス停止など利用者への影響がある場合はその範囲も明記します。

事前確認では、対象リソース、現在の設定値、バックアップの取得状況などをチェックします。

「バックアップ済みであること」だけでは、確認方法が担当者任せになります。どのリソースのバックアップを、どこで確認するのかまで決めておけば、対象の取り違えや確認漏れを防げます。

具体的な操作手順

担当者が手順書を見て作業できる粒度で記載します。

AWSマネジメントコンソールを使う場合は、対象サービスや設定項目、入力する値などを順番に示します。AWS CLIを使う場合は、コマンドに加えて、対象環境やパラメータ、期待する実行結果も記載します。

細かく書きすぎると、更新の負担が増える点には注意が必要です。画面キャプチャやメニューの位置まで固定すると、AWS側の画面構成が変わるたびに修正が発生します。

どのリソースに対して何を行うのか、変更前後の状態はどうなるのか、どの結果が得られれば成功なのかが分かる粒度を目安にします。

作業後の確認方法・完了条件

作業後に何を確認し、どの状態になれば完了なのかを決めます。

設定変更であれば、設定値が反映されたことに加えて、対象サービスが正常に動いているか、想定外のアラートやエラーが出ていないかも確認します。

AWS Well-Architected Frameworkでは、ランブックで達成したい結果を明確にすることが推奨されています。完了条件を決めておけば、「操作は終わったが、サービスは正常ではない」といった状態の見逃しを防げます。

異常時の対応・切り戻し・エスカレーション

エラーが発生した場合に、作業を続ける条件、中止する条件、変更前の状態へ戻す手順を決めておきます。

エスカレーションも「必要に応じて責任者へ連絡する」ではなく、判断できる条件まで具体化します。

• 一次対応を始めてから○分経過しても復旧しない

• ○回再実行しても同じエラーが発生する

• サービスへの影響が○○まで広がった

時間や回数は一律ではなく、システムの重要度やSLO、RTO、障害の重大度に応じて設定します。

AWS Well-Architected Frameworkでも、エスカレーションのトリガーと手順を事前に定義し、一定時間の経過などを条件にする考え方が示されています。

AWS運用手順書の作り方

AWS運用手順書は、対象となる作業を洗い出し、優先順位を付けて作成します。その後、第三者による検証を経て公開します。

運用作業を洗い出す

現在のAWS環境で発生している運用作業を洗い出します。

対象は、監視、バックアップ、アカウントや権限の管理、設定変更、メンテナンス、障害対応などです。日常的な作業だけでなく、障害発生時や構成変更時に行う作業も含めます。

運用設計書に加えて、作業チケット、障害記録、問い合わせ履歴も確認します。担当者へのヒアリングだけでは、普段は意識せず行っている作業や、頻度の低い例外対応が抜けることがあるためです。

「この作業は○○さんしか分からない」「障害時は△△さんに聞く」といった業務も、手順化する対象として確認します。

手順化する作業の優先順位を決める

すべての作業を一度に手順化する必要はありません。実施頻度、失敗した場合の影響、判断の難しさ、特定の担当者への依存度などから優先順位を決めます。

優先度が高いのは、次のような作業です。

• 実施頻度が高い

• 複数の担当者が実施する

• 誤操作した場合の影響が大きい

• 障害時に短時間で対応する必要がある

• 特定の担当者しか対応方法を把握していない

ただ、優先度が高い作業から手順書を作ればよいとは限りません。

AWS Well-Architected Frameworkでは、ランブック作成を始める候補として、一定の頻度で行い、手順が比較的短く、失敗しても影響が小さい作業を挙げています。まず低リスクの作業でフォーマットやレビュー方法を固め、その後に重要度の高い作業へ広げる方法もあります。

実際のAWS環境に沿って手順を作成する

一般的なAWSの操作説明ではなく、自社の環境に合わせて作成します。

AWSアカウント、リージョン、サービス、対象リソース、必要なIAM権限を明記し、実際の作業順序に沿って記載します。作業前の確認事項、完了条件、エラーが起きた場合の対応も含めます。

たとえば「Amazon EC2を停止する」だけでは、対象や実行条件が分かりません。どのインスタンスを、どの条件で停止し、何を確認して作業完了とするのかまで具体化します。

AWS Well-Architected Frameworkでも、ランブックには期待する結果、必要なツールや権限、エラー処理、例外、エスカレーションなどを含めることが推奨されています。

第三者が手順どおりに実行して検証する

作成後は、別の担当者に手順書だけを渡して実行してもらいます。AWS Well-Architected Frameworkでも、別のチームメンバーがランブックを実行し、不足や不明点があれば更新する流れが示されています。

この検証では、作成者が横から説明しないことがポイントです。

補足しなければ作業を進められない箇所があれば、その情報は手順書から抜けています。質問された箇所、判断に迷った箇所、想定と違う結果になった箇所を記録し、内容を修正します。

可能であれば、本番環境に影響しない検証環境で確認します。作成者自身では気づきにくい前提知識の抜けを見つけやすくなります。

承認・公開し、更新ルールを決める

検証が終わった手順書は、責任者の確認を経て、運用担当者が参照できる場所に公開します。

管理責任者、更新日、バージョンも明記し、どれが現在の手順なのか分かる状態にしておきます。

AWS Well-Architected Frameworkでも、ランブックを一元的に公開し、プロセスの変更に合わせて更新する考え方が示されています。具体的な更新方法については、後述する「AWS環境の変更に合わせて手順書を更新する」で解説します。

AWS運用手順書のテンプレート・具体例

基本のフォーマットを揃えておくと、手順書ごとの抜け漏れを減らし、レビューや更新もしやすくなります。作業の種類に応じて項目を調整しながら使います。

基本的な手順書のフォーマット

AWS運用手順書には、次のような項目を設けます。

AWS Well-Architected Frameworkが示すランブックの例にも、目的、使用ツール、必要な権限、作成者、最終更新日、エスカレーション先などが含まれています。

すべての手順書を同じ長さに揃える必要はありません。作業のリスクや複雑さに応じて項目を調整します。

定常運用の手順書

監視結果やバックアップ状況の確認など、繰り返し行う作業は次のように整理できます。

AWS Backupのバックアップジョブを確認する場合の例です。

AWS Backupでは、コンソール上で「Completed with issues」と表示されるジョブがあります。APIではこの状態もCOMPLETEDですが、MessageCategoryはSUCCESS以外です。

APIやCLIで確認を自動化する場合、COMPLETEDだけを正常終了の条件にすると、注意が必要なジョブを見落とす可能性があります。完了条件には、ジョブのステータスだけでなく、実際に確認すべき結果まで含めます。

関連記事：AWS Backup導入ガイド｜EC2・RDSの自動バックアップ設定と運用トラブルを防ぐ実践知識

障害対応の手順書

障害対応では、異常の検知から影響確認、一次対応、復旧確認、エスカレーションまでの流れを整理します。

Amazon CloudWatchのアラームを起点とする場合の例です。

CloudWatchのメトリクスアラームには、OK、ALARM、INSUFFICIENT_DATAの状態があります。「ALARMでなくなった」ことだけで復旧とせず、対象サービスが正常に動いていることも確認します。

関連記事：AWS監視設計の基本｜CloudWatch活用と運用設計のポイント

設定変更・メンテナンスの手順書

設定変更やメンテナンスでは、変更前後の状態と切り戻し条件まで記載します。

AWSリソースの設定を変更する場合の例です。

「問題があれば元に戻す」だけでは、切り戻すタイミングを担当者がその場で判断することになります。時間やエラー率などの条件を作業前に決めておけば、問題発生後の判断を減らせます。

AWS運用手順書を継続的に活用するためのポイント

手順書の内容が実際のAWS環境とずれたり、最新版が分からなくなったりすると、次第に参照されなくなります。「詳しい人に聞いた方が早い」という状態に戻れば、属人化も解消できません。

作成後は、AWS環境や担当者の変更に合わせて見直し、実際に使える状態を保つ必要があります。

AWS環境の変更に合わせて手順書を更新する

リソースの追加・削除、設定変更、利用サービスの変更があれば、関連する手順書も見直します。

半年に1回などの定期レビューだけでは、変更から見直しまでの間に内容が古くなる可能性があります。変更申請や作業チケットに「関連する運用手順書の更新要否」という項目を設けておけば、システム変更と同じタイミングで確認できます。

AWS Well-Architected Frameworkでも、ランブックの更新を変更管理プロセスの一部として扱う考え方が示されています。

関連記事：AWS構成管理の進め方｜設定変更を把握し、属人化を防ぐ方法

担当者変更・引き継ぎ時に内容を見直す

引き継ぎは、手順書に足りない情報を見つける機会になります。

新しい担当者に手順書を渡し、前任者の補足なしで作業できるか確認します。途中で質問が必要になった箇所には、前任者の経験や知識に依存した情報が残っている可能性があります。

質問された内容を追記すれば、引き継ぎと手順書の検証を同時に進められます。AWS Well-Architected Frameworkでも、ランブックによって新しいチームメンバーが作業を始めやすくなることがメリットとして挙げられています。

IAM権限と作業者の責任範囲を明確にする

担当者や役割が変わった際は、手順書に記載したIAMロールや権限も確認します。

あわせて見直したいのが、担当者が自分で判断してよい範囲です。たとえば、「本番環境の設定変更は実行できるが、サービス停止を伴う場合は責任者の承認が必要」といったルールを決めておきます。

IAMで制御できるのは操作の可否です。業務上どこまで判断を任せるかは別途決める必要があります。

定期的に手順を実行・レビューする

障害対応や復旧作業のように実行頻度が低い手順は、読み返すだけでは不備を見つけにくいものです。

そこで使えるのが、AWS Well-Architected Frameworkでも推奨されている「Game Day」です。障害や異常なイベントを疑似的に発生させ、実際の障害対応に近い状況でシステム、人、プロセスが機能するかを確認します。

障害対応手順書であれば、次のような点をチェックします。

• 担当者が手順書をすぐ見つけられるか

• 必要な権限で対応できるか

• エスカレーションが想定どおり機能するか

• 復旧条件を正しく判断できるか

• 手順書にない判断が発生しないか

障害対応手順書の不備は、本番障害が起きる前に見つけておく必要があります。 

Game Dayで手順どおりに進まなかった場合は、原因を確認して手順書や運用プロセスを修正します。AWSでも、実施後に振り返りを行い、改善事項を反映することが推奨されています。

AWS Systems Managerで定型作業を自動化する

毎回同じ操作を繰り返している作業は、自動化の候補になります。

AWS Systems Manager Automationでは、AWSリソースに対する一連の処理をランブックとして定義できます。AWSが提供する事前定義ランブックに加え、独自のランブックも作成可能です。

ただし、手順が曖昧な状態で自動化すると、その曖昧さまで処理に組み込むことになります。正常終了の条件や異常時の処理を確認したうえで、判断を必要としない部分から自動化します。

AWS Well-Architected Frameworkでも、短く頻繁に使うランブックから自動化し、段階的に対象を広げる考え方が示されています。

まとめ

AWS運用手順書は、担当者が変わっても同じ手順で作業できる状態をつくるためのものです。

作成時は、運用作業を洗い出して優先順位を付け、実際のAWS環境に合わせて内容を具体化します。公開後も、第三者による実行確認やGame Dayで手順が機能するかを確かめ、環境の変更に合わせて見直します。

繰り返し行う定型作業は、AWS Systems Manager Automationなどによる自動化も検討できます。

まずは、現在のAWS運用で「特定の担当者しかやり方を知らない作業」を1つ洗い出してみてください。