SAA / SAP 攻略ナビ
ホーム セキュリティ監視・コンプライアンス

ログ集約設計 — CloudTrail / CloudWatch / OpenSearch

CloudTrail、CloudWatch Logs、OpenSearch (Elasticsearch) を組み合わせたマルチアカウント・マルチリージョンログ集約アーキテクチャを SAA 基礎から SAP 高度設計まで解説。

最終更新: 2026-07-27 カテゴリ: セキュリティ監視・コンプライアンス

AWS 環境の監査と運用には ログの集約設計 が不可欠です。 CloudTrail（API 操作）、CloudWatch Logs（アプリ/システムログ）、OpenSearch（検索・分析）を 統合したログ基盤を設計します。 本記事ではログ集約アーキテクチャを SAA / SAP 両面から整理します。

SAA レベル：基礎概念

3 つのログサービスの役割

サービス記録対象主な用途
CloudTrailAWS API 操作（管理イベント + データイベント）誰が何をしたかの監査
CloudWatch Logsアプリケーション/システムログアプリログの集約・監視
OpenSearch Service検索・分析エンジンログの高速検索・可視化

SAA レベル：基礎概念

ログ集約の 3 本柱は 「API 監査 (CloudTrail) + アプリログ (CloudWatch Logs) + 検索分析 (OpenSearch)」 です。

  • CloudTrail は AWS の操作履歴 を記録
  • CloudWatch Logs は アプリ/OS のログ を集約
  • OpenSearch は 大量ログの高速検索・ダッシュボード を提供 この役割分担が SAA の基礎です。

CloudTrail の基本

CloudTrail は AWS アカウントの API 操作を記録 するサービスです。

  • 管理イベント (Management Events): AWS リソースの作成/変更/削除等（デフォルト記録）
  • データイベント (Data Events): S3 GET/PUT, Lambda 関数実行等（有効化が必要）
  • インサイトイベント (Insights Events): 異常な API 活動の自動検知
  • ログの保管: S3 バケットに JSON 形式で保管

SAA 試験のポイント

CloudTrail は 管理イベントはデフォルトで記録 されますが、 データイベント（S3/Lambda の詳細操作）は明示的に有効化 が必要です。 「S3 バケットのオブジェクトアクセスを監査したい」→ データイベント有効化、が SAA の頻出です。

CloudWatch Logs の基本

CloudWatch Logs は アプリケーション/システムログを集約・監視 します。

  • ロググループ (Log Group): ログの分類単位
  • ログストリーム (Log Stream): ロググループ内の個別シーケンス
  • メトリクスフィルター: ログからメトリクスを抽出
  • サブスクリプションフィルター: ログを別サービス（Lambda/OpenSearch/Kinesis）へ転送

SAA 頻出

CloudWatch Logs のサブスクリプションフィルター は ログを OpenSearch や Kinesis、Lambda に転送する機能です。 「CloudWatch Logs → OpenSearch」の連携に使うのが SAA の頻出パターンです。

OpenSearch Service の基本

OpenSearch Service（旧 Elasticsearch Service）は ログの高速検索・分析 を提供します。

  • フルマネージド: クラスタ管理を AWS が担当
  • Kibana / OpenSearch Dashboards: 可視化ダッシュボード
  • ログ分析: CloudTrail, CloudWatch Logs, VPC Flow Logs 等の分析
  • インデックス: ログを高速検索可能な形式で保管

SAP レベル：高度な設計シナリオ

マルチアカウント・マルチリージョンログ集約

SAP では 全アカウント・全リージョンのログを 1 箇所に集約 する設計が定石です。

SAP レベル：高度な設計シナリオ

SAP のログ集約定石は 「LogArchive アカウントに全ログを集約」 です。 CloudTrail は組織トレイルで全アカウント対象、CloudWatch Logs はサブスクリプションフィルターで転送、 OpenSearch は LogArchive アカウントに配置して全ログを統合分析します。

[全メンバーアカウント] (全リージョン)
  ├── CloudTrail ──────────── [LogArchive の S3] ── OpenSearch
  ├── CloudWatch Logs ─────── (Subscription Filter) ── Kinesis ── OpenSearch
  └── VPC Flow Logs ───────── [LogArchive の S3] ── OpenSearch

組織トレイル (Organization Trail)

組織トレイル を使うと、全メンバーアカウントの CloudTrail を 1 つの S3 に集約できます。

  • 管理アカウントから作成: 1 つ作るだけで全アカウント対象
  • 新規アカウント自動対象: 組織に追加されたアカウントは自動的にトレイル対象
  • KMS 暗号化: LogArchive アカウントの CMK で暗号化
  • S3 Object Lock: ログの改ざん防止（WORM: Write Once Read Many）

組織トレイルの設計論点

組織トレイルは 新規アカウントが自動的にログ対象 になるため、 「新規アカウントのログ漏れ」を構造的に防げます。 これを個別アカウントのトレイルでやると新規アカウント追加時に設定忘れが発生しやすく、 SAP では組織トレイルが推奨です。

CloudTrail のログ不変性設計

セキュリティ監査の観点で ログの改ざん防止 が重要です。

手法説明設計論点
S3 バケットポリシーLogArchive アカウントのみ書込可書き込み元の制限
S3 Object LockWORM（書き込み一回のみ）改ざん防止
KMS 暗号化LogArchive の CMK で暗号化鍵の分離
MFA Delete削除に MFA 要求悪意削除の防止

ログの改ざんリスク

CloudTrail ログを書き込む S3 バケットは、ログ生成元アカウントからの書き込みのみ許可 し、 かつ Object Lock で変更不可 にする必要があります。 これをしないと、悪意ある管理者がログを改ざん・削除できてしまいます。SAP の重要論点です。

CloudWatch Logs から OpenSearch への転送

CloudWatch Logs → OpenSearch の連携は サブスクリプションフィルター で実現します。

[CloudWatch Logs]
  └── Subscription Filter
        │ (Lambda を経由 or 直接)
        ▼
[OpenSearch Service] (LogArchive アカウント)
  • 直接転送: CloudWatch Logs → OpenSearch（AWS 提供の Lambda 関数）
  • Kinesis Data Streams 経由: 大規模・高スループット向け
  • クロスアカウント: 別アカウントの OpenSearch にも転送可能

大規模ログ転送の設計

ログ量が大きい場合は CloudWatch Logs → Kinesis Data Firehose → OpenSearch の構成が安定します。 Firehose はバッチング・リトライ・変換を担うため、CloudWatch Logs から直接より信頼性が高くなります。 SAP の大規模環境では Firehose 経由が定石です。

OpenSearch のアーキテクチャ設計

OpenSearch クラスタの設計要素：

要素設計論点SAP での判断
インスタンスタイプロード量に応じた選択c/r/i シリーズの使い分け
ノード数可用性と性能のバランス3 ノード以上で HA
マスターノードクラスタ管理の分離専用マスターで安定性向上
ストレージEBS vs インスタンスストアログは EBS が無難
インデックス管理期限切れログの自動削除ISM (Index State Management)

ISM によるログライフサイクル

OpenSearch の ISM (Index State Management) で「30 日経過したインデックスは削除」等の ライフサイクルポリシーを定義します。ログを無限に保管するとストレージコストが膨張するため、 SAP では保管期間の設計が必須です。

ログの保管期間とコンプライアンス

コンプライアンス要件に応じた ログ保管期間 の設計：

要件保管期間実装
一般監査90 日〜 1 年S3 ライフサイクルで Glacier 移行
PCI DSS1 年（即時利用）+ 3 年（アーカイブ）S3 + Glacier Deep Archive
金融規制5〜7 年Glacier Deep Archive
GDPR最小限（目的達成後削除）自動削除ポリシー

保管期間のコスト影響

長期保管は Glacier / Glacier Deep Archive に移行 しないとコストが膨張します。 S3 ライフサイクルポリシーで「30 日後 Glacier、90 日後 Glacier Deep Archive」等の 階層化が SAP のコスト最適化定石です。

Amazon Athena によるログ分析

S3 に保管された CloudTrail / VPC Flow Logs は Athena で直接クエリ できます。

-- CloudTrail ログから特定ユーザーのアクションを検索
SELECT eventtime, eventsource, eventname, sourceip
FROM cloudtrail_logs
WHERE useridentity.sessioncontext.sessionissuer.principalid = 'AROAXXXXXXXXXXX'
ORDER BY eventtime DESC;
  • サーバーレスクエリ: クラスタ管理不要
  • S3 直接参照: ログを OpenSearch に移さず分析可能
  • Glacier からの復元不要: 標準 S3 に置いた期間分は即時クエリ可能

SAP レベル：高度な設計シナリオ

SAP では「OpenSearch は短期・高頻度検索、Athena は長期・アドホック分析」の使い分けが定石です。 直近 30 日は OpenSearch でダッシュボード表示、過去数年分は S3 + Athena で必要時だけクエリ。 この二段構えでコストと性能の両立を図ります。

異常検知とアラート

集約したログから異常を検知する設計：

ログソース異常検知手法アラート先
CloudTrailCloudTrail Insights（異常 API 活動）EventBridge → SNS
CloudWatch Logsメトリクスフィルター + 異常値検出CloudWatch Alarm
VPC Flow LogsGuardDuty（通信異常検知）Security Hub
OpenSearchAlerting プラグイン（閾値監視）SNS / Slack

CloudTrail Insights

CloudTrail Insights は CloudTrail の管理イベントを分析し、 通常と異なる API 活動パターン を自動検知します。 「突然大量の API 呼び出し」「未使用リージョンからのアクセス」等を検知。 SAP では Insights 有効化が推奨ベストプラクティスです。

クロスアカウントログ共有のセキュリティ

ログを共有する際のセキュリティ設計：

  • リソースポリシー: LogArchive の S3/OpenSearch が送信元アカウントを許可
  • IAM ロール: 読み取り専用ロールで最小権限
  • KMS 条件キー: aws:PrincipalAccount でアカウントを限定
  • VPC エンドポイント: プライベート接続でログ転送

クロスアカウントログの落とし穴

LogArchive アカウントの KMS CMK を使って暗号化 する場合、 キーポリシーで 送信元アカウントに KMS 復号権限 を付与する必要があります。 これを忘れると「ログは書き込めたが読み返せない」状態になります。SAP の典型的な落とし穴です。

制約と考慮事項

項目制約 / 注意
CloudTrail データイベント有料、対象リソース指定必要
CloudWatch Logs 転送量サブスクリプションでデータ転送料金
OpenSearch クラスタ最小 3 ノード推奨（HA）
S3 ログ保管Object Lock で不変性確保

まとめ

  • SAA: CloudTrail（API 監査）、CloudWatch Logs（アプリログ）、OpenSearch（検索分析）の 役割分担と連携の基本を理解する。
  • SAP: 組織トレイル、ログ不変性設計、OpenSearch アーキテクチャ、Athena との使い分け、 異常検知、クロスアカウントログ共有の統合設計が求められる。

次は ネットワークセキュリティ で、SG / NACL / WAF / Shield の設計を学びましょう。

スポンサーリンク（広告枠） 728×90

関連記事