SCS-2.5ログ分析ソリューションを設計する。

ヒントボタン

毎秒10万件を5秒以内で検索するには、取り込み段階で自動スケールしつつ低レイテンシ配信を行える Kinesis Data Streams オンデマンドと、その出力を秒単位でバッファして Amazon OpenSearch Service へ送り込む Kinesis Data Firehose を組み合わせると、ピーク2倍までの変動にも運用介入なく追従できます。
RPOを0にしながら保管コストを抑えるには、Firehose の失敗レコード自動再試行と Amazon S3 への同時バックアップで11ナインの耐久性を確保しつつライフサイクルルールで30日後に S3 Standard-IA へ遷移させ、結果として復旧性とコスト最適化を両立できます。
可用性99.9％以上を確保するにはデータ層をマルチAZで冗長化できる Amazon OpenSearch Service を使用し、SSE-KMS による透過的暗号化とドメインの細粒度 IAM ポリシーで権限制御を行い、ストリーム取り込みと耐久保管を全てマネージドで担う Kinesis と S3 を組み合わせることでスループット・レイテンシ・RPO・運用負荷の全要件を同時に満たす総合的な最適解となります。

ヒントボタン

5 分以内に Athena で検索するという厳しいレイテンシ目標に対し、WAF から 300 GB/日のログを受け取るパイプラインは Kinesis Data Firehose のバッファを 1 MB／60 秒程度に抑えることでストリームに近い速度で S3 へ書き込めるため、Data Streams＋Lambda のシャード管理や CloudWatch Logs の日次エクスポートに比べて運用がシンプルかつスケーラブルになります。

転送経路と保存時の暗号化は Firehose の SSE-KMS と S3 の CMK を併用し、S3 Bucket Keys を有効にして KMS 呼び出しを最小化するとともに、保存は S3 Intelligent-Tiering に任せれば 1 年間の保管中にアクセス頻度が変化してもクラス遷移が自動化され、Standard や Standard-IA を固定利用する場合よりセキュリティとコスト最適化を同時に満たせます。

Glue Crawler でパーティションを自動生成し、EventBridge スケジュールで Athena クエリを 1 時間ごとに実行して悪意 IP を抽出し GuardDuty のカスタムフィードへ出力する流れまでコード化しておけば、ログの取り込み・暗号化・保管・分析・脅威連携という複数要件をすべて自動で回せるため、Firehose＋Intelligent-Tiering を中心に据えた構成が総合的に最も運用負荷が低い選択となります。

ヒントボタン

7 年間の改ざん不可保管という厳格な金融監査要件を CloudTrail で満たすには、Organizations で統制した 1 本の組織 Trail をマルチリージョンで S3 に集約し、バージョニングと S3 Object Lock Compliance モードを併用して WORM を実装する方法が最も一般的であり、各アカウント側で設定漏れや削除リスクを気にせずログを横断的に保護できます。
CloudTrail ログを S3 に保存すると Athena で直接クエリできますが、90 日を超えた大量データでも数秒以内に応答させるには、Glue データカタログが自動生成するパーティションでメタデータを最適化し、Athena スケジュールクエリを EventBridge から呼び出して日次集計を行う構成が効果的で、マネージドサービスだけでパッチやサーバー管理なしに性能を確保できます。
Athena クエリで抽出した AssumeRole 失敗件数を EventBridge ルールで受け取り、Security Hub のカスタムアクションや SNS 経由で SOC システムへリレーすることで日次の自動監視が実現でき、改ざん防止と高速検索という保管要件と合わせて俯瞰すると、サーバーレスのマネージド構成が最も合理的だと判断できます。

ヒントボタン

マルチアカウントの CloudTrail を集約するときは Organizations で統合トレイルを作り、gzip 圧縮したログを単一 S3 バケットに日付パーティションで配置し、90 日程度は Standard か Intelligent-Tiering の Frequent Access 層で保持し、その後ライフサイクルで 180 日後に Glacier Deep Archive へ自動移行させることで、2 TB/日でも 7 年保管コストを最小化しつつ後続分析に必要なオンライン性能を確保でき、クロスリージョン転送料も抑えられます。
Athena と Glue Crawler を組み合わせると、S3 に置いた CloudTrail CSV や JSON を自動でデータカタログ登録し、時間でパーティションを切ればパーティションプルーニングが効くため、eventName と errorCode=AuthFailure などで WHERE 句を絞れば 30 日分でもスキャン量は数 GB で済み、Presto エンジンの結果が 5 秒以内で返りやすく、CloudWatch Logs Insights や Redshift Spectrum に比べて取り込みコストや復元待ちが不要となり、純粋なクエリ料金だけで済みます。
CSV に個人情報が混ざるリスクには Amazon Macie の自動分類を S3 全バケットに有効化し、週次ジョブの Findings を EventBridge ルールで SNS トピックへ転送すれば配信の再試行やマルチサブスクライバ対応も自動化でき、外部アプライアンスや Lambda 実装が不要となりますので、ストレージ階層管理・高速検索・PII 検出という三つの要件をフルマネージドで同時に満たす設計が総合的に運用負荷と費用を最適化する道筋です。

ヒントボタン

ピーク毎秒5万件を60秒以内に可視化するには、取り込みレイヤーが自動でスループットに追従し、ほぼリアルタイムに検索基盤へ流せることが重要です。Kinesis Data Firehose はバッファサイズだけで伸縮し Amazon OpenSearch Service に直接書き込める一方、Kinesis Data Streams はシャード計画、CloudWatch Logs Export はバッチ待ち時間という運用負荷を考慮する必要があります。

保持30日かつホット→コールドを自動階層化するには、データストア自身がライフサイクルポリシーを備えるかが鍵です。Amazon OpenSearch Service は Index State Management で標準ストレージから UltraWarm、さらに S3 Snapshot へ自動遷移でき即時検索を維持します。S3 と Glacier のみの構成は復元遅延、EBS スナップショットは単なるバックアップという違いを確認してください。

99.9%以上の可用性と追加サーバのメンテナンス禁止という要件は、マルチAZ配置とパッチ・スケールをサービス側に委ねられるかで選択肢が絞られます。Amazon OpenSearch Service と Kinesis Data Firehose は SLA と Auto Scaling が明示され、AWS KMS による転送・保存の暗号化もワンクリックです。EC2 上の Elasticsearch や Amazon MSK では障害対応やバージョン管理が利用者責任になるため、複数要件を俯瞰するとフルマネージド型でリアルタイム取り込みと検索を完結させる構成が最も合理的だと判断できます。

ヒントボタン

30 アカウント 60 VPC から発生する Route 53 Resolver の Query Logging をセキュリティアカウントに集約するには、AWS Organizations 配下でも CloudWatch Logs グループにクロスアカウント書き込みを許可するリソースポリシーを設定するのが最もシンプルです。S3 にアカウント別保存を選ぶと Glue や Athena を横断的に回す運用が増え、バケット管理や権限制御が煩雑になりがちです。また CloudWatch Logs は自動で水平スケールするため、ピーク 5,000 QPS × 60 VPC のトラフィックでも取りこぼしの心配がありません。

上位送信元 IP やドメインの急増を 5 分以内に把握したい場合、CloudWatch Logs 直結の Contributor Insights が到着したログを即座に集計し CloudWatch アラームへメトリクスを公開できるため、追加コードなしでリアルタイム可視化が可能です。Athena＋QuickSight はクエリ遅延とパーティション管理、Firehose＋Lambda＋OpenSearch は独自 ETL とスケール設計が必要になるため、短時間検知と運用簡素化の両立が難しくなりやすい点を比べてみてください。

18 TB/月のログを 1 年保管するコストを最小化するには、CloudWatch Logs から 30 日程度で S3 にエクスポートし、ライフサイクルで Glacier Deep Archive へ自動移行する方法が有効です。365 日 CloudWatch Logs に置き続けると料金が高騰し、OpenSearch インデックス維持もノード増加とスナップショット管理が伴います。可視化速度・集中保管・長期コストという複数要件を俯瞰し、最小運用でバランスを取れる構成を選ぶ視点が鍵となります。