AWS Certified CloudOps Engineer - Associate (SOA-C03) #4 Domain 1-3 モニタリング — 自動復旧とパフォーマンス最適化
#2 のメトリクスと #3 のログで検知を整理しました。運用の次のステップは、検知したあと人手なしで自動的に対処すること です。SOA-C03 が「手動介入なしで (without manual intervention)」という条件をよく付ける理由がここにあります。この記事では自動復旧の構成要素と、モニタリングドメインの最後の軸であるパフォーマンス最適化を整理します。
EventBridge — イベントに反応する中心 #
EventBridge は AWS で起きるイベントをルールで受け取り、ターゲットへ送る ルーターです。自動復旧の出発点です。
| 構成 | 説明 |
|---|---|
| Event source | イベントを出す場所。AWS サービス、ユーザー定義、SaaS パートナー |
| Rule | イベントパターンでフィルタリングするか、スケジュール (cron) でトリガー |
| Target | 送るターゲット。Lambda、SSM Automation、SNS、Step Functions など |
2 つのトリガー方式が核心です。
- イベントパターン — 「EC2 インスタンスが
stopped状態に変わったら」「Health イベントが発生したら」のように 状態変化に反応 - スケジュール (Scheduled) — cron・rate 式で 周期実行。以前の CloudWatch Events の役割をそのまま引き継ぐ
「インスタンスが特定の状態になったら自動的に何かをせよ」というシナリオの出発点が EventBridge ルールです。
Systems Manager Automation — 復旧ランブック #
検知 (EventBridge) の次の 実際の対処 を担うのが Systems Manager Automation です。ランブック (Runbook、Automation document) という段階的な手順を定義しておいて実行します。
- AWS 提供ランブック:
AWS-RestartEC2Instance、AWS-StopEC2Instanceなどすぐに利用可能 - ユーザー定義ランブック: 複数の段階 (スナップショット → 復旧 → 検証) をまとめて定義
- 権限: ランブックが使う IAM Role で動作
代表的な自動復旧の流れは次のとおりです。
CloudWatch Alarm (または EventBridge ルール)
→ SSM Automation ランブック実行
→ インスタンスの再起動・置き換え・タグ付けなどの対処
→ SNS で結果通知「ディスクがいっぱいになったら自動的にクリーンアップスクリプトを回せ」のような要求は EventBridge/アラーム → SSM Automation ランブック で実装します。
EC2 自動復旧と Auto Scaling 自己修復 #
自動復旧にはもっと簡単な組み込みの仕組みもあります。
| 仕組み | 動作 | いつ |
|---|---|---|
| EC2 自動復旧 (recover) | 同じインスタンスを新しいハードウェアで復旧。ID・IP を維持 | システムステータスチェック (ハードウェア) 失敗 |
| Auto Scaling ヘルスチェック | 異常なインスタンスを終了し、新しいインスタンスに置き換え | EC2 または ELB ヘルスチェック失敗 |
両者の違いが試験のポイントです。
- 自動復旧 は 同じインスタンスを生かす ことです。単一インスタンスのハードウェア障害に使います。
- Auto Scaling は 異常なインスタンスを捨てて新しいものに置き換え ます。ステートレス (stateless) ワークロードの自己修復に使います。
状態 (state) をインスタンスに持っていて置き換えが難しいなら自動復旧、状態がなくいつでも置き換え可能なら Auto Scaling が答えです。Auto Scaling ヘルスチェックを ELB ヘルスチェックに設定 してこそアプリケーションレベルの障害まで捉えられる、という点も定番です。
パフォーマンス最適化 — 診断の順序 #
SOA-C03 ではパフォーマンスは別ドメインではなくモニタリングドメインの中に入りました。核心は メトリクスでボトルネックを特定したうえで適切な対処を選ぶ 流れです。
| リソース | ボトルネックの兆候 (メトリクス) | 代表的な対処 |
|---|---|---|
| コンピューティング | CPUUtilization が持続的に高い | インスタンスタイプの引き上げ、ASG 拡張、より大きなファミリー |
| メモリ | (Agent) メモリ使用率が高い | メモリ最適化ファミリー (R 系) |
| EBS | VolumeQueueLength が高い、IOPS 限界 | gp3 IOPS 引き上げ、io2 へ切り替え |
| RDS | ReadIOPS が高い、FreeableMemory が低い | Read Replica、インスタンス引き上げ、キャッシング |
| ネットワーク | 帯域幅の限界 | 拡張ネットワーキング、より大きなインスタンス |
EBS パフォーマンスのポイント #
EBS は試験の定番です。gp3 は容量と無関係に IOPS・スループットを別々に上げられるので、gp2 でパフォーマンスが不足したときの第一の答えです。非常に高く一貫した IOPS が必要なら io2/io2 Block Express です。「ディスクが遅いが容量は十分」の答えは通常、gp3 に切り替えて IOPS を上げることです。
Compute Optimizer とコスト・パフォーマンスのバランス #
Compute Optimizer は過去のメトリクスを分析して インスタンスが過大・過小プロビジョニングされているか を推奨します。EC2・ASG・EBS・Lambda を対象とします。
- 過大プロビジョニング — 使用率の低いインスタンスをより小さなタイプへ → コスト削減
- 過小プロビジョニング — 使用率が限界のインスタンスをより大きなタイプへ → パフォーマンス改善
パフォーマンスとコストは同じ診断の両面です。「コストは減らすがパフォーマンスは維持せよ」という要求の答えとして、Compute Optimizer の推奨に従った ライトサイジング (rightsizing) がよく出ます。メモリの推奨を受け取るには CloudWatch Agent のメモリメトリクス が必要だ、という点も一緒に覚えておくとよいでしょう。
試験での出題パターン #
- 状態変化に自動反応 → EventBridge ルール
- 検知後に複数段階の復旧を自動化 → SSM Automation ランブック
- 単一インスタンスのハードウェア障害を自動復旧 → EC2 自動復旧 (同じインスタンス)
- ステートレスワークロードの自己修復 → Auto Scaling + ELB ヘルスチェック (置き換え)
- ディスクが遅いが容量は十分 → gp3 に切り替えて IOPS 引き上げ
- コストは減らすがパフォーマンス維持 → Compute Optimizer ライトサイジング
よくある落とし穴 #
1) 自動復旧と Auto Scaling を同じとみなす #
自動復旧は 同じインスタンスを生かし、Auto Scaling は 捨てて置き換え ます。状態を持つかどうかで分かれます。
2) Auto Scaling ヘルスチェックを EC2 のみにする #
デフォルトの EC2 ヘルスチェックはインスタンスが生きているかだけを見ます。アプリケーション障害を捉えるには ELB ヘルスチェック を有効にする必要があります。
3) パフォーマンス問題に無条件でインスタンスを大きくする #
ボトルネックが EBS IOPS なのにインスタンスタイプを大きくする答えは外れます。メトリクスでボトルネックリソースをまず特定 する必要があります。
4) Lambda を EventBridge なしで周期実行しようとする #
Lambda 自体にはスケジューラーがありません。周期実行は EventBridge スケジュールルール でトリガーします。
まとめ #
この記事で押さえたこと:
- EventBridge が自動復旧の出発点。イベントパターン (状態変化) とスケジュール (cron) の 2 つのトリガー
- SSM Automation ランブック で検知後の多段階の対処を自動化。アラーム・EventBridge がトリガー
- EC2 自動復旧 は同じインスタンスを生かす (ハードウェア障害)、Auto Scaling は捨てて置き換え (ステートレス)
- Auto Scaling ヘルスチェックを ELB 基準 にしてこそアプリケーション障害まで自己修復
- パフォーマンスは メトリクスでボトルネックリソースを特定 してから対処。EBS は gp3 IOPS 引き上げ が定番
- Compute Optimizer で過大・過小プロビジョニングを診断。コストとパフォーマンスを一緒にライトサイジング
次: Domain 2-1 Multi-AZ と Auto Scaling #
モニタリングドメインを終えました。次は 2 番目のドメインである 信頼性とビジネス継続性 です。
#5 Domain 2-1 信頼性 — Multi-AZ・Auto Scaling・ELB ヘルスチェック では、アベイラビリティーゾーンをまたぐ多重化構成、Auto Scaling グループのキャパシティ・ポリシー・ライフサイクル、ELB の種類別ヘルスチェックと接続ドレイニング、そして Route 53 フェイルオーバーまで整理し、可用性設計の考え方を押さえます。