【AWS研修レポート】Cloud Operations on AWS Day2 - 高可用性とモニタリング編

はじめに

こんにちは、山本です。

この記事は「Cloud Operations on AWS」研修レポートのDay2編です。

前回の振り返り

Day1では、運用の定義やIAMによるアクセス管理、CloudFormationによるIaCを学びました。今回のDay2では、高可用性とモニタリングについて学んでいきます。

この日のサマリ

項目	内容
テーマ	リソース管理、高可用性、スケーリング、モニタリング
主要サービス	Systems Manager, ELB, Route53, EC2 Auto Scaling, CloudWatch, EventBridge, X-Ray
キーワード	マネージドノード, ヘルスチェック, スケーリングポリシー, メトリクス/ログ/アラーム

モジュール内容

モジュール6: リソースの管理

デプロイしたリソースの管理方法、Systems Managerの活用について学びました。

運用との関連として、リソース情報を収集し確認可能な状態にすることで安定性を高め、リソース管理作業を効率化・自動化することで効率を上げます。

AWS Systems Managerの主要機能

Systems Managerはサーバー管理に関する機能が豊富で、オンプレミスも対象にできます。

カテゴリ	機能	説明
オペレーション管理	Explorer	運用情報の集約表示
オペレーション管理	OpsCenter	運用タスク（OpsItem）の管理
アプリケーション管理	Parameter Store	パラメータをキーバリュー形式で管理（基本無料）
アプリケーション管理	AppConfig	フィーチャーフラグ対応、段階的配信可能
変更管理	Run Command	複数サーバーへの一括コマンド実行
変更管理	メンテナンスウィンドウ	特定期間にドキュメントを自動実行
ノード管理	パッチマネージャー	環境ごとのパッチ適用管理

マネージドノードとは、Systems Managerで管理可能な状態のサーバーです。前提条件として、SSMエージェントのインストールとSystems Managerとの通信経路確保が必要です。

Parameter StoreとAppConfigは以下のように使い分けます。

• Parameter Store: 静的パラメータ向け（DB認証情報、ライセンスコード等）。基本こちらを使用
• AppConfig: 動的パラメータ、柔軟なデプロイが必要な場合

学び

Systems Managerは機能が多いため全体像を把握するのが難しいと感じていましたが、「オペレーション管理」「アプリケーション管理」「変更管理」「ノード管理」の4カテゴリで整理するとわかりやすくなりました。

モジュール7: 高可用性システムの構成

ELBとRoute53によるトラフィック分散とヘルスチェックについて学びました。

運用との関連として、システムの可用性を高める構成・サービスの活用で安定性を高め、ヘルスチェックで効率的な高可用性実現を図ります。

ELB（Elastic Load Balancing）

トラフィックを背後のサーバーに分散するマネージドサービスです。

• ALB: L7（HTTP/HTTPS）。ヘッダー・Pathでルーティング
• NLB: L4（TCP/UDP）。より広いプロトコル対応
• CLB: 旧世代
• GLB: オンプレミス連携時

ELBのコンポーネントは以下の通りです。

• リスナー: 受け付ける通信の設定（例: HTTP=80）
• ターゲット: EC2、Lambda、コンテナ
• ルール: 条件に応じたトラフィック振り分け

ヘルスチェック

• 設定項目: プロトコル、Path、チェック回数
• 動作: NG時は正常サーバーにのみ転送

Route53

• AWSのDNSサービス。SLA 100%（AWS内で唯一）
• 複数ELBへの負荷分散が可能（リージョン間の振り分け等）
• ヘルスチェックでプライマリ/スタンバイの切り替えが可能

学び

Route53のSLA 100%は印象的でした。リージョン間の振り分けやフェイルオーバーが実現できるのは、グローバル展開するサービスで重要になりそうです。

モジュール8: スケーリングの自動化

EC2 Auto Scalingによるサーバー台数の自動増減について学びました。

運用との関連として、システム需要の変化に柔軟に対応することで安定性を高め、需要変化への対応を自動化することで効率化します。

EC2 Auto Scalingの三要素

• 起動テンプレート: 増減するサーバーの設定（AMI ID、インスタンスタイプ等）
• ASグループ: サーバー配置の構成情報（NW設定、ELB統合等）
• ASポリシー: 希望容量の更新方法を定義

スケーリングポリシーの種類を以下にまとめます。

ポリシー	説明
スケジュール	時間指定でスケーリング（例: 朝2台増加、夜2台削減）
ステップスケーリング	閾値ごとに段階的スケーリング
ターゲット追跡スケーリング	メトリクスとターゲット値を指定（例: CPU使用率50%維持）。推奨
予測スケーリング	過去データから需要予測。スケールアウトのみ

複数ポリシー利用時は、一番大きい値が採用されます。ターゲット追跡スケーリングが推奨で、CloudWatchアラームが自動作成されます。

学び

ターゲット追跡スケーリングは「CPU使用率50%を維持」のように目標値を指定するだけで良いので、設定がシンプルです。現場でAuto Scalingを設定する際は、まずこの方式を検討したいと思いました。

モジュール9: システム正常性のモニタリングと維持

CloudWatchによるメトリクス・ログ収集とアラーム・イベント対応について学びました。

運用との関連として、システムの変化・予兆をいち早く捉え対応することで安定性を高め、把握した事象への対応を効率化します。

運用全体のフローは以下の通りです。

1. 収集: メトリクス・ログを集める
2. モニタリング・分析: CloudWatch Metrics/Logs
3. 応答: CloudWatch Alarm → SNS/Lambda等

CloudWatch メトリクス

• 標準メトリクス: デフォルトで取得（EC2: CPU、RDS: メモリ等）
• カスタムメトリクス: CloudWatchエージェントで取得（EC2: メモリ、ディスク等）

モニタリング間隔

• 基本: 5分（無料）
• 詳細: 1分（有料）

CloudWatch Logs

• Lambdaはデフォルトで出力、EC2はエージェント設定が必要
• Logs Insights: SQLライクなクエリでログ分析

CloudWatch アラーム

• 状態: OK / ALARM / データ不足
• スパイク対策: 連続N回閾値超過でアラーム発生の設定可能
• アクション: SNS連携（メール通知等）、後続処理のトリガー

EventBridge

• AWSイベント（EC2起動、S3アップロード等）をトリガーに後続処理を実行
• GUIでルール作成可能

その他のモニタリングサービスを以下にまとめます。

サービス	用途
AWS Health Dashboard	AWSサービス自体の障害確認
CloudWatchインターネットモニター	ISP障害状況の確認
X-Ray	分散アプリケーションのトレース、障害箇所特定

学び

X-RayはTraceMapで構成図と障害箇所（赤色）を確認できるという点が印象的でした。マイクロサービス構成で「どのサービスが原因で遅延しているか」を特定する際に有効そうです。

ラボ体験

ラボ3: Operations as Code

SSMを使った管理作業を体験しました。

実施内容

• CloudWatch ロググループ作成（SSM出力ログ用）
• コマンドドキュメント作成・実行（Apacheインストール、コンテンツ更新）
• オートメーションドキュメントで設定変更デプロイ
• CloudWatch Logsで操作ログ確認

学び

以下の点が業務効率化の観点で活かせるかもしれないと感じました。

• コマンドドキュメントとオートメーションドキュメントの作成・実行方法
• ログストリームによる変更監査の仕組み

ラボ4: アプリケーションとインフラストラクチャをモニタリングする

CloudWatchエージェント設定とアラーム・通知を体験しました。

実施内容

• CloudWatchエージェントのインストール・設定・起動
• CloudWatchダッシュボード作成
• SNSトピックのサブスクライブ
• CloudWatchアラーム作成・テスト
• Lambda Canary関数の作成・アラーム設定

学び

以下の部分が業務効率化やSOA対策として有益だと感じました。

• EC2へのテレメトリー設定（エージェント、Parameter Store、Run Command）
• ダッシュボード・アラーム・SNS通知の連携
• Lambda Canaryによる外形監視

疑問点と解消

研修中に気になった点をトレーナーに質問しました。

Q: メンテナンスウィンドウとEventBridgeの使い分けは？

両方とも定期実行ができるため、違いが気になりました。

トレーナー回答

• EventBridge: 汎用的。AWSリソースほぼ全てを呼び出せる
• メンテナンスウィンドウ: タスク限定（Run Command、オートメーション、Lambda、Step Functions）。終了時刻までに完了させる厳密な制御に特化

まとめると、EventBridgeは汎用的、メンテナンスウィンドウは定期実行の厳密さに特化しているということでした。

今後試してみたいこと

• X-Rayの導入検討: マイクロサービスの障害切り分けに活用できそう。現場のアプリケーションに導入できないか検討する
• CloudWatchダッシュボードの整備: 現場で使用しているダッシュボードを見直し、必要なメトリクスが揃っているか確認する
• ターゲット追跡スケーリングの理解を深める: Auto Scalingの設定を見直す際の参考にする

最後に

Day2では、Systems Managerによるリソース管理から、ELB/Route53による高可用性、Auto Scalingによるスケーリング、CloudWatchによるモニタリングまで学びました。

特にX-Rayは、分散システムの障害箇所特定に有効なツールとして印象に残りました。現場で活用できる場面を探していきたいと思います。

次回のDay3では「セキュリティとストレージ」について学びます。

参考リンク

• AWS Systems Manager Overview（Black Belt）
• AWS Systems Manager Maintenance Windows編（Black Belt）
• ヘルスチェックの実装
• Route 53 SLA 100% の舞台裏
• SSM機能群の全体像

クラスメソッドオペレーションズ株式会社について

クラスメソッドグループのオペレーション企業です。

運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。

当社は様々な職種でメンバーを募集しています。

「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。※2026年1月 アノテーション㈱から社名変更しました