EC2 を 1 台立てて動かせたあと、「次に何を回し続ければいいのか」が見えないという声は多いものです。OS から上は自分の持ち分だと聞いても、パッチもバックアップも監視も、誰がいつ何でやるのかが分からないと、SSH で入って手作業で回す前提になりがちです。この記事は、その仕事を 4 つの定期作業に分け、手作業ではなく仕組みに任せる形に落とします。
この記事の結論
- OS から上は利用者の持ち分です。回す作業は「パッチ・バックアップ・監視・費用」の 4 つに分けると漏れません。
- パッチは Patch Manager が担当します。パッチベースラインで承認する対象を決め、スケジュールで適用し、準拠状況を見ます。
- EBS のデータは AWS が自動では守りません。スナップショットを定期的に取り、自動化は Data Lifecycle Manager か AWS Backup に任せます。
- CloudWatch の標準メトリクスにあるのは CPU・ネットワーク・ステータスチェックなどで、メモリとディスク使用率は無く、エージェントで集めます。
- 使わない時間帯の停止はスケジュール化し、止め忘れを人の記憶に任せません。1 台ずつ手で直す運用は、タグで対象を選ぶ一括実行に置き換えます。
EC2 の運用とは何か｜OS から上は自分の持ち分、という前提
責任共有モデルでは、クラウド「の」セキュリティ（データセンターや物理ホスト、仮想化の層）は AWS、クラウド「内」の設定や管理は利用者が持つと整理されています。EC2 は OS を丸ごと利用者が持つサービスなので、OS のパッチ、データのバックアップ、アプリや OS の監視は利用者の仕事です。
ここで「運用」とは、立てたあとに繰り返し発生する作業のことです。繰り返す作業は、人の記憶と手作業に頼るほど漏れます。そこで次の 4 つの定期作業に分け、それぞれに任せる仕組みを決めます。
| 定期作業 | 何をするか | 任せる仕組み |
|---|---|---|
| パッチ | OS やソフトの更新を当てる | Systems Manager の Patch Manager |
| バックアップ | EBS のデータの復元点を持つ | スナップショット＋ Data Lifecycle Manager / AWS Backup |
| 監視 | 異常に気づく | CloudWatch（標準メトリクス＋エージェント） |
| 費用 | 使わない分を止め、大きさを見直す | 停止・起動のスケジュール |
FOUR ROUTINES運用の定期作業
EC2 の運用は4 つの定期作業を回し続けること
EC2 の運用
OS から上は自分の持ち分
- パッチ
- バックアップ
- 監視
- 費用の見直し
パッチはどう当てるか｜Patch Manager・パッチベースライン・メンテナンスウィンドウ
AWS Systems Manager の機能の 1 つである Patch Manager は、マネージドノード（Systems Manager の管理下に入ったインスタンス）に対して、パッチの確認と適用を自動化します。使うときは 3 つの部品を押さえます。
- パッチベースライン: どのパッチを承認するかの基準です。「重要なセキュリティ更新だけ」など、適用してよい範囲をここで決めます。
- 実行方法: 定期的に当てるにはパッチポリシーかメンテナンスウィンドウを使い、今すぐ当てるなら Patch now があります。
- 操作の種類: Scan は不足パッチを調べるだけ、Scan and install は調べて適用します。まず Scan で状況を見て、問題なければ適用に進めると安全です。
メンテナンスウィンドウは「いつ作業してよいか」の時間帯を決める部品です。たとえば業務への影響が少ない深夜にだけ適用する、という約束をスケジュールに落とせます。基準（ベースライン）と時間帯（ウィンドウ）を分けて持つ、と覚えると整理できます。
注意が 2 点あります。公式ドキュメントによれば、AWS がパッチをテストしてくれるわけではないので、本番に当てる前の確認は利用者が組みます。また、準拠状況が「準拠」と出ることは安全の保証ではなく、ベースラインで承認したパッチが当たっているというだけです。
CHECK 3ここまでの確認
パッチを当てる対象（どのパッチを承認するか）の基準を決めるのは何?
答えと解説
答え: 1. パッチベースライン
基準を決めるのがパッチベースライン、いつ実行するかを決めるのがメンテナンスウィンドウです。「パッチはどう当てるか」を読み直してください。
バックアップはどう取るか｜EBS スナップショットと自動化、「AWS は自動では取らない」
EBS ボリュームのバックアップはスナップショットです。2 回目以降は前回からの変更分だけを保存する増分の仕組みで、容量と時間を抑えられます。復元するときは、スナップショットから新しいボリュームを作ります。
大事なのは、公式ドキュメントが「AWS は EBS のデータを自動ではバックアップしない」と明記している点です。インスタンスを立てただけではバックアップは無く、取る仕組みは利用者が用意します。
| やり方 | 向いている場面 |
|---|---|
| 手でスナップショットを取る | 変更の直前に 1 回だけ取りたいとき |
| Data Lifecycle Manager | EBS のスナップショットを、タグで選んだ対象に定期的に取り、古いものを消したいとき |
| AWS Backup | EBS 以外のサービスも含めて、バックアップの方針を一箇所で管理したいとき |
スナップショットと AMI は役割が違います。スナップショットはデータを守るための復元点で、AMI はインスタンスを起動するためのテンプレートです（AMI の位置づけは ec2-toha を参照）。データを守るために AMI だけを頼りにしない、と覚えておくと混同しません。
CHECK 1ここまでの確認
EBS ボリュームのデータは、利用者が何もしなくても AWS が自動でバックアップしてくれる?
答えと解説
答え: 2. 自動では取られない。スナップショットを利用者が取る（定期化は Data Lifecycle Manager か AWS Backup）
公式ドキュメントは、AWS が EBS のデータを自動でバックアップしないと明記しています。「バックアップはどう取るか」を読み直してください。
何を監視するか｜標準メトリクスとステータスチェック、メモリ・ディスクはエージェント
EC2 は CloudWatch に標準でメトリクスを送ります。代表は CPU 使用率、ネットワークの入出力、そしてステータスチェックです。基本モニタリングの間隔は 5 分で、ステータスチェックは 1 分間隔で評価されます。
ステータスチェックには 2 種類あります。システムステータスチェックは AWS 側の基盤（ホストなど）の問題を、インスタンスステータスチェックはインスタンス内部の問題を見ます。基盤の問題でシステムステータスチェックが失敗したときは、CloudWatch アラームの復旧アクションで同じインスタンス ID とプライベート IP のまま復旧させる使い方があります。1 台構成のサーバーで効く手です。
一方、メモリ使用率とディスク使用率は標準メトリクスに含まれません。 これは OS の内側の値で、ハイパーバイザー側からは見えないためです。メモリ不足に気づけないという事故を避けるには、CloudWatch エージェントをインストールして、メモリ・ディスクのメトリクスやアプリのログを集めます。
エージェントが「入っていて、動いていて、設定が決まった状態」を保つには、Systems Manager の State Manager が使えます。関連付けで対象・設定のドキュメント・スケジュールを指定すると、誰かが止めても定期的にあるべき状態へ戻されます。台数が増えるほど、手で入れる運用は漏れるので、ここも仕組みに任せます。
CHECK 2ここまでの確認
EC2 の標準メトリクスに含まれず、CloudWatch エージェントで集める必要があるのはどれ?
答えと解説
答え: 3. メモリ使用率
標準で見えるのは CPU・ネットワーク・ステータスチェックなどです。OS の内側にあるメモリとディスク使用率はエージェントで集めます。「何を監視するか」を読み直してください。
費用の運用｜使わない時間は止める、サイズが合っているかを見直す
費用は、立てた時点で決まるだけでなく、回し方で変わります。小さく始めやすいのは次の 2 つです。
- 使わない時間は止める: 開発用や検証用は、夜間と休日に使わないことが多いはずです。EventBridge Scheduler なら、タイムゾーンを指定して EC2 の停止・起動の API を直接呼べます。「止め忘れ」を人の記憶に任せず、スケジュールに書いてしまいます。
- サイズが合っているかを見直す: CPU 使用率などのメトリクスを見て、常に低いなら小さいインスタンスタイプへ、足りないなら大きく、と見直します。
停止中でも EBS の容量の料金は続く点に注意します（ec2-toha を参照）。無料枠の範囲や金額は変わるので、数値はここには書かず、公式ページで確認してください。
CHECK 4ここまでの確認
夜間と休日に使わない開発用のインスタンスの費用を抑える運用はどれ?
答えと解説
答え: 2. スケジュールで停止と起動を自動化する
止め忘れは人の記憶に任せると必ず起きます。スケジュールに落とすのが運用の考え方です。「費用の運用」を読み直してください。
台数が増えたらどうするか｜タグで対象を選んで一括実行する（SSH で 1 台ずつやらない）
5 台、50 台と増えると、1 台ずつ SSH で入って直す運用は破綻します。鍵の配布、踏み台、作業の記録のどれも重くなるためです。そこで、タグで対象を選び、まとめて実行する形に変えます。
- Run Command: タグ（たとえば Role=api）を対象に、同じコマンドを一斉に実行します。出力は S3 や CloudWatch Logs に残せます。
- Session Manager: 22 番ポートを開けずに、ブラウザやCLIからシェルに入れます。操作の記録も残せます。
- Patch Manager・State Manager・DLM: いずれも、タグで対象を選べます。
タグは、運用の対象を決める「名札」です。環境（dev / prod）や役割をタグで揃えておくと、パッチの対象もバックアップの対象も停止スケジュールの対象も、同じ名札で選べます。
BY HAND OR BY SYSTEM手作業と仕組み
1 台ずつの手作業をやめて、タグで選んでスケジュールで回す
手作業の運用
台数が増えると破綻
- 1 台ずつ SSH で入って直す
- 鍵の配布と踏み台が要る
- やったかどうかが人の記憶
仕組みに任せる運用
台数が増えても同じ
- タグで対象を選んで一斉に実行
- Session Manager で 22 番を開けない
- スケジュールと記録が残る
PROBLEM TO TOOL困りごとと仕組み
運用の困りごとには、対応する仕組みがある
困りごと
使う仕組み
困りごと: パッチ漏れ
使う仕組み: Patch Manager
困りごと: データ消失
使う仕組み: スナップショット
困りごと: メモリ不足に気づけない
使う仕組み: CloudWatch エージェント
困りごと: 止め忘れ
使う仕組み: 停止スケジュール
運用の週次・月次チェックリスト
定期作業は、頻度を決めて当番表にすると続きます。たとえば次のように分けます（頻度は目安で、環境ごとに決めてください）。
- 毎日（自動）: スナップショットの取得、メトリクスの収集、停止・起動のスケジュール
- 週次: パッチの準拠状況の確認、アラームが鳴った件数の確認、直近のスナップショットが取れているかの確認
- 月次: インスタンスサイズの見直し、不要なスナップショットと停止中インスタンスの整理、復元の手順を 1 回試す
「取っているだけ」のバックアップは、復元できて初めてバックアップです。月に 1 回、スナップショットから復元できるかを試す枠を当番表に入れておきます。
次に読むなら、台数の増減そのものを自動化する auto-scaling-toha が自然な続きです。
READ ALSO — 学習中向け・段2 構成
Amazon EC2 Auto Scaling とは何か｜台数を自動で増減し、壊れた1台を入れ替える仕組み
まとめ
EC2 の運用は、パッチ・バックアップ・監視・費用の 4 つの定期作業に分けると漏れません。パッチは Patch Manager、バックアップはスナップショットと DLM または AWS Backup、監視は CloudWatch の標準メトリクスとエージェント、費用は停止スケジュールに任せます。台数が増えたらタグで対象を選び、SSH で 1 台ずつは直しません。最初は、バックアップと開発用インスタンスの停止スケジュールから始めるのが小さく始めやすい一歩です。
参照ソース
- AWS Systems Manager Patch Manager（公式ドキュメント） — パッチベースライン、Scan と Scan and install、実行方法（パッチポリシー・メンテナンスウィンドウ・Patch now）、パッチをテストしない点と準拠の意味の根拠
- Amazon EBS スナップショット（公式ドキュメント） — スナップショットが増分であること、EBS のデータを AWS が自動ではバックアップしないこと、自動化に Data Lifecycle Manager と AWS Backup を使うことの根拠
- CloudWatch で EC2 のメトリクスを見る（公式ドキュメント） — 標準メトリクス、基本モニタリングの間隔、ステータスチェックの間隔の根拠
