AWSにおけるログ集約の要所 Data Lakeについて説明する。
目次
1. ログ集約の必要性とData Lakeとは
AWSインフラでは、EC2・Lambda・RDS・ALB・CloudFrontなど、多種多様なサービスが異なる形式でログを出力している。これらをバラバラに扱っていると、障害調査・セキュリティ監査・コスト分析などの場面で大きなコストがかかる。
そこで重要になるのが ログの集約 だ。ログを1か所にまとめることで、横断的な検索・分析・可視化が初めて可能になる。
Data Lakeに求められる3つの役割
| 役割 | 説明 |
|---|---|
| 🗃 集約 (Aggregation) | 異なるサービス・フォーマットのログを1か所に集める |
| 🔒 改ざん防止 (Governance) | セキュリティ・コンプライアンス要件に対応するイミュータビリティ保証 |
| ⏳ 保存期間担保 (Retention) | 法令・社内ポリシーに基づいたログの保持期間を確実に管理する |
S3 vs CloudWatch — どちらを選ぶか？
AWSにおけるData Lakeの主な二択は S3 と CloudWatch Logs だ。ユースケースによって使い分けが必要となる。
| 観点 | S3 | CloudWatch Logs |
|---|---|---|
| 主な用途 | 大量データの長期保管・バッチ分析 | リアルタイムモニタリング・アラート |
| スケーラビリティ | 実質無制限（ペタバイト規模対応） | 十分だが大規模長期保管にはコスト高 |
| コスト | ストレージコストが安い（Glacierなら極安） | 長期保管はS3より割高になりやすい |
| 分析機能 | Athena・Glue等との連携で強力 | Insights機能あるが外部サービスが多い |
| リアルタイム性 | Near-realtimeが限界 | リアルタイム処理に強み |
💡 補足: Kinesis Firehose をログ出力先として利用するサービスもあるが、これはStreaming処理のHubとして機能するものであり、最終的な出力先は
S3になることが多い。
AWSサービス別ログ出力先まとめ(一部)
| # | サービス名 | ログの種類 | S3 | CWL | Firehose | 備考 |
|---|---|---|---|---|---|---|
| 1 | ALB / NLB | アクセスログ |  |
 |
|
S3保存が基本。CWLへはLambda等で転送。 |
| 2 | API Gateway | アクセスログ |  |
|
|
カスタムアクセスログでFirehose指定可。 |
| 3 | AppSync | 実行ログ | |
|
|
基本はCloudWatch Logs(CWL)のみ。 |
| 5 | Bedrock | モデル呼び出しログ | |
|
|
ガバナンス目的で3種全てに対応。 |
| 7 | CloudFront | 標準/リアルタイムログ | |
|
|
標準はS3のみ、リアルタイムはFirehose。 |
| 8 | CloudTrail | データイベント等 | |
|
|
CWLへは明示的な有効化が必要。 |
| 12 | EC2 | OS/アプリログ | |
|
|
CloudWatch Agent経由で全般に対応。 |
| 13 | EventBridge | バス実行ログ | |
|
|
2025年アップデートで直接3種に対応。 |
| 15 | Lambda | 実行ログ | |
|
|
2024年アップデートで直接3種に対応。 |
| 17 | Network Firewall | 通信ログ | |
|
|
初期から3種への直接出力をサポート。 |
| 18 | RDS | DBログ | |
|
|
Auroraと同様の挙動。 |
| 19 | Route 53 | 公開クエリログ | |
|
|
設定によりCWLへ出力。 |
| 20 | VPC | フローログ | |
|
|
ネイティブに3種への出力をサポート。 |
| 21 | WAF | Web ACL ログ | |
|
|
リクエスト量に応じた無料枠もあり。 |
2. S3 — スケーラブルなData Lake
S3はData Lakeの基盤として最も広く使われるサービスだ。データ量に応じた柔軟なスケーリングと豊富な機能セットにより、あらゆる規模のログ集約基盤として機能する。
Data Lakeに求められる機能をS3はどう満たすか
| 機能 | 説明 |
|---|---|
| 🗃 Scalability(集約) | 容量無制限。データ量の増加に対してインフラ変更なしで対応できる |
| 🗃 多様フォーマット対応(集約) | JSON・CSV・Parquet・Avroなど構造化・非構造化データを格納 |
| 🔒 改ざん防止 (Governance) | Object Lockで削除・上書きを防止。WORM（Write Once Read Many）を実現 |
| ⏳ 保存期間担保 (Retention) | Lifecycle configurationでストレージクラス移行や自動削除期間を設定 |
主要機能の詳細
Versioning
- オブジェクトの複数世代を保存する
- 誤削除・上書き対策、監査ログ管理に活用
Lifecycle Configuration
-
S3 Standard→S3 IA→S3 Glacierへの自動移行ルールを設定 - TTL（Time To Live）でオブジェクトの自動削除期間も設定可能
- コスト最適化と保存期間担保を同時に実現
Object Lock
- Governance モード: 特定のIAM権限を持つユーザーは解除可能
- Compliance モード: rootユーザーを含め誰も削除・変更不可（法規制対応）
- WORM要件や金融・医療分野のコンプライアンス対応に有効
Bucket Policy / IAM
- バケット・オブジェクトレベルで細粒度のアクセス権限を制御
- 最小権限原則（Principle of Least Privilege）の実装
⚠️ 注意: Object Lock の Compliance モードは root ユーザーも含め誰も削除・変更できなくなる。設定前に保持期間を慎重に決定すること。
3. CloudWatch — リアルタイムログ監視
CloudWatch Logsはリアルタイムのログ出力と監視に強みを持つ。ログ集約に止まらず、収集したraw dataを元にメトリクスを生成・可視化する機能も持つ。
CloudWatchの特徴
- リアルタイムログ収集: 各AWSサービスからのログをほぼリアルタイムで収集
- Metric Filter: ログからカスタムメトリクスを生成し、アラームと連携可能
- Log Insights: ログのクエリ・集計・可視化機能
分析機能の現状
CloudWatchの分析機能は比較的シンプルであり、大規模データの深い分析には向いていない側面がある。
🔍 実際のプロジェクトでは分析機能の観点から Datadog などの外部サービスを CloudWatch と組み合わせて利用するケースが多い。また、AI時代の到来に伴い、CloudWatchの分析機能も強化されつつある。
4. Bedrockのlog設定から両者の差異を分かる
S3は大容量対応、IAM roleに依存せず、Bucket Policyで細かく制御可能
CloudWatchは大容量logに向いていない、roleでアクセス制御
-
S3の場合、location指定のみ
-
CloudWatchの場合、log groupのほか、role指定、大きいsizeやbinary dataの場合S3 Localtionも指定
5. CloudWatchからS3へのエクスポート方法
CloudWatchのリアルタイム性とS3の長期保管を組み合わせるため、CloudWatch → S3へのデータ転送はよくあるアーキテクチャパターンだ。目的やリアルタイム要件に応じて3つの方法がある。
方法①: Export Task — コスト重視の定期エクスポート
- CloudWatch Logsのデータを非同期でS3にエクスポートするバッチ処理
- リアルタイム性は不要でコスト観点でのログ保管を目的とする場合に適している
- ラグが数時間〜数十分程度発生する点に注意
方法②: Kinesis Firehose — S3出力に特化したNear-realtimeパイプライン
- Subscription FilterからKinesis Data Firehoseへ流すシンプルなパイプライン
- 変換・圧縮・バッファリングを行いS3に出力
- Near-realtimeで扱いやすく、S3への出力に特化した用途で最もよく使われる
方法③: Kinesis Subscription Filter — リアルタイム最優先
- CloudWatch LogsのSubscription FilterからKinesis Data Streamsへリアルタイムに流し込む
- リアルタイム性を最優先する場合の選択肢
- 後段にLambdaやKinesis Firehoseを接続してS3や他サービスへ転送する
3方法の比較
| 方法 | リアルタイム性 | 用途 | 複雑さ |
|---|---|---|---|
| Export Task | 低（数時間ラグ） | コスト重視の長期保管 | 低 |
| Firehose | 中（Near-realtime） | S3への安定出力 | 中 |
| Subscription Filter + Kinesis | 高（リアルタイム） | リアルタイム処理・分析 | 高 |
アーキテクチャ全体像
各AWSサービス (EC2 / Lambda / RDS...)
↓
CloudWatch Logs [Realtime収集]
↓
Kinesis Firehose [Streaming Hub]
↓
S3 [Data Lake / 長期保管]
✅ Kinesis Firehoseは最終的な出力先がS3になるケースが最も多い。S3をData Lakeの中心に置き、CloudWatchとKinesisを組み合わせることで、リアルタイム監視と長期保管の両立が可能になる。
5. まとめ
- ログ種類・出力サービスが多いAWSでは、Data Lakeによるログ集約が不可欠
- S3はスケーラビリティ・リテンション・ガバナンスを兼ね備えた長期保管向けData Lake
- CloudWatchはリアルタイムログ収集・メトリクス生成に強いが、分析にはDatadog等の外部連携が現実的
- CloudWatch → S3の転送は目的に応じて
Export Task/Subscription Filter + Kinesis/Firehoseの3択 - Kinesis FirehoseはStreamingのHubとして機能し、最終出力先はS3が一般的