Amazon SOA-C02: 監視、ロギング、および修復 — 学習ガイド

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

こちらの一部です： AWS SysOps Administrator Associate SOA-C02 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

モニタリング、ロギング、修復は、AWS環境の運用における神経系のような役割を果たし、問題を検出し、コンテキストを提供し、是正措置を推進します。このドメインでは、意味のあるメトリクスとダッシュボードの作成、コスト効率の高いログの収集と保持、追跡可能なアプリケーションのオブザーバビリティの構築、アラートと修復の自動化について説明します。優れた実装は、シグナルとノイズのバランスを取り、コストを管理し、プレイブックと自動化がテスト済みで監査可能であることを保証します。

CloudWatchのメトリクス、ダッシュボード、アラーム

ビジネスおよび運用のSLI（レイテンシー、エラーレート、キューの深さ、インフラのCPU/メモリ）を中心にメトリクスを設計します。組み込みメトリクス（EC2、RDS、ELB）に加えて、アプリケーションレベルのカウンターのためにPutMetricDataを介したカスタムメトリクス（

undefined

）を使用します。フィルタリングを可能にするディメンション（InstanceId、ServiceName）を優先し、メトリクスコストを急増させる高カーディナリティのディメンションは避けます。

CloudWatchダッシュボードを使用して、メトリクス、ログ、アラームを運用ビューに統合します。コンソールまたはCloudFormation（AWS::CloudWatch::Dashboard）を介してウィジェットを作成し、メトリクス計算を使用して派生メトリクスを作成します。メトリクス計算（ERRORS/SUM(REQUESTS)）を使用してエラーレートを計算し、パーセンタイル（p50、p90、p99）を表示します。アラームについては、目的に基づいて設定パターンを選択します。

単一メトリクスアラーム：単純なしきい値に使用します。

undefined

複合アラーム：複数のアラームにまたがる条件（AND/OR）を組み合わせてノイズを削減します。
異常検出：しきい値を自動調整します。季節的な変動が予測されるメトリクスに対してCloudWatchの異常検出を使用します。

決定基準：評価期間とアラーム発生までのデータポイント数を設定して、アラームのバタつきを回避します。アラームアクションとしてSNS、Auto Scaling、またはSystems Manager Automationをトリガーします。ベースラインが変動する環境では、複合アラームと異常検出を優先します。

CloudWatch Logs、Logs Insights、保持期間

CloudWatch Logsのロググループでログを集約し、アプリケーションと環境ごとに構造化します。CLIでロググループを作成し（

undefined

）、保持期間を設定します（

undefined

）。サブスクリプションフィルターを使用して、ログをKinesis Data Firehose（S3/Redshift用）、Lambda（リアルタイム処理用）、またはパートナーツールにストリーミングします。S3で圧縮・パーティション分割してストレージコストを削減します。

アドホックなクエリやダッシュボードにはCloudWatch Logs Insightsを使用します。トレースIDやエラーコンテキストを抽出する保存済みクエリを構築します（例：

undefined

）。保持期間と取り込みコストの管理方法：

コンプライアンスやトラブルシューティングのニーズに基づき、ロググループごとに適切な保持期間（7/30/90/365日）を設定します。
古いログは、保持期間のライフサイクルまたはFirehose経由でS3にエクスポートし、圧縮とライフサイクルルールを適用してGlacier/Archiveに移行します。
サンプリングや構造化ログ（JSON）、埋め込みメトリクスフォーマット（EMF）を使用して、高価な高カーディナリティのログを削減しつつ、メトリクスを派生させます。

決定基準：詳細なデバッグログには短い保持期間を、監査/セキュリティログには長い保持期間を設定します。大量のログは、CloudWatchで無期限に保持するのではなく、S3に転送します。

CloudTrail、監査証跡、イベント履歴

すべてのリージョンとアカウントでCloudTrailを有効化します。組織の証跡を作成して、保護されたS3バケットに監査ログを一元化し、ログファイルの検証とSSE-KMSによる暗号化を適用します。管理イベント（読み取り/書き込み）を設定し、データイベントは量が多くコストも高いため、詳細な監査が必要な場合にのみ選択的に有効化します（S3オブジェクトレベル、Lambda関数の呼び出しなど）。

コンソール上のCloudTrailイベント履歴を90日間の迅速な検索に利用し、長期的な分析や調査には、S3にエクスポートしたログに対してCloudTrail LakeまたはAthenaを使用します。証跡を保護する方法：

複数リージョンにまたがる証跡を強制し、グローバルサービスのイベントをキャプチャします。
CloudTrailをCloudWatch Logsと統合してほぼリアルタイムの検出を行うか、EventBridgeと統合して特定のイベントをLambda/Systems Managerにルーティングし、自動修復を行います。
S3バケットポリシーと（必要に応じて）S3 Object Lockを適用して、改ざんを防止します。

決定基準：フォレンジックな可視性が必要なバケット/関数に対してのみデータイベントを有効化します。一元化された証跡とクロスアカウントアクセスパターンを使用して、コンプライアンスを簡素化します。

アプリケーションのトレースとオブザーバビリティ（X-Ray）

AWS X-Ray SDKでアプリケーションを計装し、セグメントとサブセグメントを生成します。計装されていないランタイムでは、X-Rayデーモン/エージェントをサイドカーまたはサービス（ECSタスク、EC2デーモン、またはLambdaの組み込みトレース）として実行します。サンプリングルールを設定してトレース量を制御し、ServiceLensでサービスマップを設定してサービス間の依存関係を可視化します。ビジネキー（userId、orderId）でトレースにアノテーションを付け、例外/メタデータを記録してトリアージを支援します。

アプリケーションログにX-RayトレースID（トレースヘッダーまたはSDKを使用して現在のトレースIDを取得）を含めることで、トレースとログを関連付けます。これにより、CloudWatch Logs Insightsのクエリでログとトレースを結合できます。Lambdaでは、アクティブトレースを有効にして（コンソールまたは

undefined

）、トレースを自動的にX-Rayに送信します。トレース分析を使用して、テールレイテンシー、ホットスポット、データベースコールの内訳を検出します。

決定基準：重要なサービスに対してトレースを有効にし、アダプティブサンプリングを使用してコストを抑制します。ログとトレースの相関を決定的にするために、構造化されたトレース（アノテーション/メタデータ）を優先します。

自動修復とアラート通知 (EventBridge/Lambda)

EventBridge ルールを使用して、CloudWatch アラームの状態変化、CloudTrail イベント、またはカスタムイベントを照合し、Lambda、Systems Manager Automation ドキュメント、Step Functions、SNS などのターゲットにルーティングします。入力トランスフォーマーを使用してルールを作成し、修復アクションに最小限のコンテキストを渡します (aws events put-rule –name HighErrorRule –event-pattern ‘{“source”:[“aws.cloudwatch”],…}’)。軽量な修復（サービスの再起動、認証情報の失効）には Lambda 関数を実装しますが、チェックポイント付きの長時間実行可能で監査可能なプレイブックには SSM Automation または Step Functions を使用します。

安全性を考慮して修復を設計します。ドライランモード、べき等性、検証ステップ、IAM の最小権限、ロギング、およびキルスイッチ（緊急停止スイッチ）を含めます。EventBridge/Lambda 統合ではデッドレターキューと再試行ポリシーを使用し、修復の試みを監査ログまたはセキュリティ証跡に発行します。ステージングアカウントで自動化をテストし、デプロイ後にカナリアテストを実行します。

決定基準: 複数ステップの復旧や人間の承認が必要な場合は SSM Automation または Step Functions を優先します。シンプルで迅速な修正には Lambda を使用します。リスクの高いアクションには、常に手動ロールバックまたはヒューマンインザループのブレークポイントを含めます。

一般的な落とし穴と決定基準

健全性の判断を単一のメトリクスに依存する: 誤検知を避けるために、メトリクス（例: エラー率 + レイテンシー + スロットリング）を組み合わせるか、複合アラーム/メトリクス数式を使用します。
ログの保持期間と取り込みコストを考慮しない: ロググループごとに保持期間を設定し、大量のログは Firehose 経由で圧縮して S3 にルーティングし、ライフサイクルポリシーを使用して古いデータをより安価なストレージ階層に移動します。
高カーディナリティディメンションやトレースサンプリングの無効化による過剰なインストルメンテーション: ディメンションを制限し、アダプティブサンプリングを有効にして、シグナルを維持しつつコストを管理します。
テストせずに自動修復をデプロイする: 本番環境で有効化する前に、ステージングで検証し、ドライランフラグを使用し、べき等性と安全なロールバックを確認します。
ノイズの多いアラームによるアラート疲れ: 異常検知、複合アラーム、抑制期間を使用し、意味のあるイベントのみをオンコール担当者にエスカレーションします。
ログ、メトリクス、トレース間の相関関係の欠如: トレース ID をログと EMF メトリクスに伝播させ、保存済みの Logs Insights クエリと ServiceLens ビューを構築してデータを結びつけます。

実践的な問題: ユースケースシナリオ

Acme Payments 社では、ピークトラフィック時に決済処理が断続的に失敗しています。エンジニアはレイテンシーの増加と散発的な 5xx エラーを確認していますが、自動再起動によって根本原因が覆い隠されてしまうことがありました。

X-Ray SDK と EMF メトリクスで決済サービスをインストルメント化します。アプリケーションログにトレース ID を追加し、構造化メトリクスである OrdersFailed と OrdersProcessed を PutMetricData/EMF 経由で送信します。
エラー率 (OrdersFailed / OrdersProcessed) を計算するために CloudWatch メトリクス数式を作成し、エラー率 > しきい値 AND p99 レイテンシー > しきい値を組み合わせた複合アラームを作成します。
アラームアクションを EventBridge ルールにルーティングし、そのルールが診断ステップ（最近のトレース/ログの収集、ヘルスチェックの実行）のための Step Functions ワークフローをトリガーするようにします。そして、安全な場合は SSM Automation 経由で自動再起動を実行します。
CloudTrail と CloudWatch Logs サブスクリプションを設定し、完全なログを S3 に（圧縮して）アーカイブし、ライフサイクルポリシーで Glacier に移行します。また、詳細なデバッグログについては CloudWatch で短い保持期間を設定します。
本番環境で自動修復を有効にする前に、エンドツーエンドテストとカナリア合成トランザクション (CloudWatch Synthetics) を実行して、可観測性と修復フローを検証します。

論理的根拠: 症状を繰り返し対処するのではなく、メトリクス、ログ、トレースを相関させて根本原因を特定します。アラームを組み合わせてノイズを削減し、監査可能でテスト済みの自動化 (Step Functions/SSM) を使用して安全な修復を行いつつ、ログストレージのコストを管理します。

すべてのドメイン · 高可用性、耐障害性、および災害対策 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →