Athena分析対象別ドキュメント一覧
このドキュメントは、Amazon Athenaで分析可能な各種ログソースについて、分析対象ごとの詳細設計ドキュメントを整理したインデックスです。
前提
各分析対象の詳細に進む前に、Athena基本設計ガイドを参照してください。基本的な設計方針、権限設計、コスト最適化、セキュリティ設計などの共通事項が記載されています。
分析対象の分類
Phase 1: S3保存済み(Athena統合は個別に確認が必要)
以下のログソースは既にS3に保存されています。Athenaテーブルを定義すれば分析可能ですが、一部のログソースではAthena統合のための追加設定が必要な場合があります。
1. Datadogログアーカイブ分析
ステータス: ✅ S3保存済み S3バケット: {prefix}-{env}-datadog-log-archivesデータ形式: JSON 保持期間: 7年間(Object Lock有効)
分析用途:
- 長期保存されたアプリケーションログの再分析
- Datadogの保持期間を超えた過去ログの調査
- コンプライアンス要件に基づくログ監査
- コスト削減(Datadogでの長期保持より安価)
詳細ドキュメント: athena-datadog-logs.md(作成予定)
主要なクエリパターン:
- エラーログの集計
- 特定期間のアプリケーション動作分析
- サービスごとのログ量分析
2. AWSコスト分析
ステータス: ⚠️ S3保存済み(Athena統合は未設定) S3バケット: コスト分析専用バケット(output/phase1/YYYY/MM/result/) データ形式: CSV(Cost Explorerベース) 現状: Cost ExplorerベースのCSV出力。CUR(Cost and Usage Report)設定は将来対応予定 Athena統合: 未設定(テーブル定義後に分析可能、CUR実装時に詳細分析が可能)
現状の実装: FastDoctorでは、Cost Explorerベースのコスト集計システムが稼働しており、以下のデータがS3に保存されています:
- Phase 1:
monitoring_ce_YYYYMMDD_HHmmss.csv- 事業部×アカウント別コスト集計(USD建て) - Phase 1.5:
manual_allocation_YYYYMMDD_HHmmss.csv- タグなしリソース手動配分結果 - Phase 2:
monitoring_adjusted_YYYYMMDD_HHmmss.csv- 代理店割引適用後の再配分結果(JPY建て)
これらのCSVデータに対してAthenaでテーブルを定義することで、コスト分析が可能です。
将来の実装予定: AWS Cost and Usage Report (CUR) のS3エクスポートを設定し、リソースID単位の詳細なコスト分析を実現する予定です。
- CUR用S3バケット:
fd-cur-export-${environment}(作成予定) - データ形式: Parquet(CUR標準フォーマット)
- Athena統合:
ATHENAartifact設定 - Glue Crawler: 自動スキーマ更新
分析用途:
- 事業部別コスト分析(オンライン診療/在宅/AmazonConnect/共通)
- アカウント別コスト分析
- タグベースコスト配分
- 月次/週次コストレポート作成
- コスト異常検知
- (CUR実装後)リソースID単位の詳細コスト分析
- (CUR実装後)リザーブドインスタンス/Savings Plans活用状況
関連ドキュメント:
- AWSコスト集計自動化システム設計書 - 現行システムの詳細設計
詳細ドキュメント: athena-cost-analysis.md(作成予定)
主要なクエリパターン(現行CSV):
- 月別・事業部別コスト集計
- アカウント別コスト推移
- タグ付き/タグなしリソースの比率分析
主要なクエリパターン(CUR実装後):
- リソースID単位のコスト分析
- AWSサービス別詳細コスト
3. ALB/NLBアクセスログ分析
ステータス: ✅ S3保存済み S3バケット: サービスごとのALB/NLBログバケット データ形式: スペース区切りテキスト パーティション: 日付ベース(推奨)
分析用途:
- アクセスパターン分析(トラフィック量、リクエスト元IP)
- レスポンスタイム分析(パフォーマンス問題の特定)
- エラーレート分析(4xx/5xxエラーの傾向)
- セキュリティ調査(異常なアクセスパターン検出)
詳細ドキュメント: athena-alb-logs.md(作成予定)
主要なクエリパターン:
- 時間帯別リクエスト数
- エラー率の推移
- レスポンスタイムの分布
- IPアドレス別アクセス集計
4. CloudTrailログ分析
ステータス: ✅ S3保存済み S3バケット: 環境ごとのCloudTrailバケット データ形式: JSON パーティション: 日付ベース
分析用途:
- API監査(誰が、いつ、何を実行したか)
- セキュリティイベント調査(不正アクセス、権限変更)
- コンプライアンス確認(監査証跡)
- リソース変更履歴の追跡
- 異常なAPI呼び出しの検出
詳細ドキュメント: athena-cloudtrail-logs.md(作成予定)
主要なクエリパターン:
- ユーザー別API呼び出し履歴
- リソース変更イベントの抽出
- エラーが発生したAPI呼び出し
- 特定リソースへのアクセス履歴
5. VPCフローログ分析
ステータス: ✅ S3保存済み S3バケット: 環境ごとのVPCフローログバケット データ形式: スペース区切りテキスト 保持期間: 365日
分析用途:
- ネットワークトラフィックパターン分析
- 異常トラフィック検出(DDoS、ポートスキャン等)
- ネットワークパフォーマンス問題の診断
詳細ドキュメント: athena-vpc-flow-logs.md(作成予定)
主要なクエリパターン:
- 送信元/送信先IP別トラフィック量
- Reject率の高い通信の分析
- NAT Gateway経由トラフィック量
- 時間帯別ネットワーク使用量
6. CloudFrontアクセスログ分析
ステータス: ✅ S3保存済み S3バケット: CloudFrontログバケット(cloudfront/プレフィックス) データ形式: タブ区切りテキスト パーティション: 日付ベース(推奨)
分析用途:
- CDNヒット率分析(キャッシュ効率)
- 地理的分布分析(アクセス元の国・リージョン)
- キャッシュ効率最適化
- ユーザーエクスペリエンス分析(レスポンスタイム)
詳細ドキュメント: athena-cloudfront-logs.md(作成予定)
主要なクエリパターン:
- ヒット率(Hit/Miss/RefreshHit)の集計
- 国別アクセス分布
7. Bastion監査ログ分析
ステータス: ✅ S3保存済み S3バケット: 環境ごとのBastion監査ログバケット データ形式: SSM Session Managerログ
分析用途:
- SSM Session Manager接続履歴の監査
- ユーザー別接続パターン分析
- セキュリティインシデント調査
- コンプライアンス報告
詳細ドキュメント: athena-bastion-logs.md(作成予定)
主要なクエリパターン:
- ユーザー別セッション履歴
- 接続時間帯の分析
- 異常な接続パターンの検出
8. S3アクセスログ分析
ステータス: ✅ S3保存済み(一部バケット) S3バケット: 各S3バケットのアクセスログバケット データ形式: スペース区切りテキスト
分析用途:
- バケットアクセスパターン分析
- データ転送量分析(コスト最適化)
- セキュリティ監査(誰がアクセスしたか)
- 異常アクセス検出(不正ダウンロード等)
詳細ドキュメント: athena-s3-access-logs.md(作成予定)
主要なクエリパターン:
- IPアドレス別アクセス集計
- オペレーション別集計(GET/PUT/DELETE)
- 時間帯別アクセスパターン
- エラー率分析
9. ECS/アプリケーションログ分析
ステータス: ✅ Datadogログアーカイブ経由でS3保存済み(一部サービスは未実装) S3バケット: {prefix}-{env}-datadog-log-archivesデータ形式: JSON 保存経路: ECS → CloudWatch Logs → Datadog → S3(Datadogログアーカイブ) 推奨方針: Datadogログアーカイブ機能の実装を優先(CloudWatch Logs → S3への直接エクスポートは非推奨)
分析用途:
- アプリケーションエラーログ集計
- サービス別ログ量分析
- パフォーマンス問題の特定(スロークエリ、長時間処理)
- ビジネスメトリクス抽出(注文数、ユーザー行動等)
詳細ドキュメント: athena-ecs-application-logs.md(作成予定)
実装方針: 多くのマイクロサービスで既にDatadogログアーカイブが有効化されており、S3に自動保存されています。Datadogログアーカイブ機能を使用することで、既存のDatadog統合を活用し、追加のインフラ設定を最小限に抑えることができます。
既存実装:
- S3バケット:
{prefix}-{env}-datadog-log-archives - 保持期間: 7年間(Object Lock有効)
- 詳細は「1. Datadogログアーカイブ分析」を参照
未実装サービスへの対応: Datadogログアーカイブが未実装のサービスについては、以下の手順で実装を検討してください:
template_modules/options/datadog-log-archivesモジュールの使用- マイクロサービスモジュールへの統合(
microservice-ecs等) - Datadog側でのログアーカイブ設定
詳細はAthena基本設計ガイド - Datadogログアーカイブの設定を参照してください。
Phase 2: 追加設定後に分析可能(CloudWatch Logs → S3エクスポート設定が必要)
以下のログソースは現在CloudWatch Logsに保存されていますが、S3へのエクスポート設定を行うことでAthena分析が可能になります。
10. API Gatewayアクセスログ分析
ステータス: ⚠️ CloudWatch Logs → S3エクスポート設定が必要 現在の保存先: CloudWatch Logs 必要な設定: CloudWatch Logs → S3エクスポート(または、Kinesis Data Firehose経由)
分析用途:
- APIエンドポイント別アクセス分析
- レスポンスタイム・レイテンシ分析
- エラーレート分析(4xx/5xx)
- 認証失敗パターンの分析
- APIスロットリング分析
詳細ドキュメント: athena-api-gateway-logs.md(作成予定)
エクスポート設定例:
# CloudWatch Logs → S3へのエクスポート
aws logs create-export-task \
--log-group-name /aws/apigateway/access-logs \
--from 1609459200000 \
--to 1612137600000 \
--destination api-gateway-logs-bucket \
--destination-prefix logs/11. Lambdaログ分析
ステータス: ⚠️ CloudWatch Logs → S3エクスポート設定が必要 現在の保存先: CloudWatch Logs 必要な設定: CloudWatch Logs → S3エクスポート
分析用途:
- Lambda関数ごとの実行回数・エラー率
- コールドスタート分析
- 実行時間・メモリ使用量分析
- エラーパターンの分析
- コスト最適化(実行時間短縮の機会発見)
詳細ドキュメント: athena-lambda-logs.md(作成予定)
主要なクエリパターン:
- 関数別実行統計
- エラーログの集計
- 実行時間の分布
- コールドスタート頻度
12. RDS/Auroraログ分析
ステータス: ⚠️ CloudWatch Logs → S3エクスポート設定が必要 現在の保存先: CloudWatch Logs ログ種類: スロークエリログ、エラーログ、監査ログ
分析用途:
- スロークエリの特定と最適化
- データベースエラーパターン分析
- 監査ログ分析(誰がどのクエリを実行したか)
- パフォーマンスボトルネックの特定
詳細ドキュメント: athena-rds-logs.md(作成予定)
エクスポート設定例:
# RDSスロークエリログをCloudWatch Logs → S3へエクスポート
aws logs create-export-task \
--log-group-name /aws/rds/instance/my-db/slowquery \
--from 1609459200000 \
--to 1612137600000 \
--destination rds-logs-bucket \
--destination-prefix slowquery-logs/13. OpenSearchログ分析
ステータス: ⚠️ CloudWatch Logs → S3エクスポート設定が必要 現在の保存先: CloudWatch Logs ログ種類: Search slow log, Index slow log, Application log, Audit log
分析用途:
- スロークエリの特定
- インデックス作成パフォーマンス分析
- OpenSearchクラスタの健全性監視
- 監査ログ分析
詳細ドキュメント: athena-opensearch-logs.md(作成予定)
Phase 3: ログ出力設定が必要
以下のログソースは、まずログ出力設定を有効化する必要があります。
14. WAFログ分析
ステータス: ❌ ログ出力設定が必要(WAFリソースは存在するが、ログ出力は未設定) 設定先: S3、CloudWatch Logs、またはKinesis Data Firehose 推奨設定: S3(コストとAthena分析の容易さ)
分析用途:
- 攻撃パターン分析(SQLインジェクション、XSS等)
- ブロック/許可ルールの効果測定
- 誤検知調査(正当なリクエストがブロックされていないか)
- セキュリティインシデント対応
- IPレピュテーション分析
詳細ドキュメント: athena-waf-logs.md(作成予定)
ログ出力設定例:
# WAFログ用S3バケット(バケット名は "aws-waf-logs-" で始まる必要がある)
resource "aws_s3_bucket" "waf_logs" {
bucket = "aws-waf-logs-${var.project}-${var.env}" # 重要: 必ず "aws-waf-logs-" で始める
tags = {
Name = "WAF Logs"
Purpose = "waf-logging"
}
}
# WAFログ出力設定
resource "aws_wafv2_web_acl_logging_configuration" "main" {
resource_arn = aws_wafv2_web_acl.main.arn
log_destination_configs = [
aws_s3_bucket.waf_logs.arn
]
}注意事項:
- S3バケット名は必ず
aws-waf-logs-で始まる必要があります(AWS仕様) - ログは約5分間隔でS3に配信されます
- ファイルは自動的に圧縮されます(gzip形式)
その他の分析対象(必要に応じて)
15. GuardDuty Findings分析
ステータス: 設定確認が必要(GuardDutyが有効化されている場合) 保存先: S3(GuardDutyから直接エクスポート)、EventBridge(自動送信、約5分以内) 推奨設定: GuardDutyから直接S3にエクスポート(JSON形式)
分析用途:
- セキュリティ脅威の傾向分析
- 誤検知パターンの特定
- インシデント対応時の調査
- 長期的な脅威動向の分析
詳細ドキュメント: athena-guardduty-findings.md(作成予定)
エクスポート設定の選択肢:
GuardDutyから直接S3にエクスポート(推奨)
- GuardDutyコンソールまたはAPIで設定
- 新しい検出結果が自動的にS3にエクスポートされる
- JSON形式で保存、Athenaで直接分析可能
EventBridge経由でS3に保存
- EventBridgeルールを作成し、Lambda等を経由してS3に保存
- 検出結果の加工や通知と組み合わせる場合に有効
- リアルタイム性が高い(約5分以内)
注意事項:
- GuardDutyは新しい検出結果をEventBridgeに自動的に送信します(S3エクスポートとは別)
- S3エクスポートは履歴データの追跡と長期分析に適しています
- EventBridgeは即時対応(アラート、自動修復等)に適しています
参考: Exporting GuardDuty Findings
16. Route53クエリログ分析
ステータス: ログ出力設定が必要(Route53ゾーンは存在するが、クエリログは未設定) 保存先: CloudWatch Logs(Route53から直接送信、必須) 推奨設定: CloudWatch Logs → S3エクスポート(長期保存・Athena分析用)
分析用途:
- DNSクエリパターン分析
- トラフィック元の地理的分布
- 異常なDNSクエリの検出
- DDoS攻撃の兆候検出
詳細ドキュメント: athena-route53-query-logs.md(作成予定)
設定の流れ:
Route53クエリログ設定の有効化
- Route53コンソールまたはTerraformで設定
- ログはCloudWatch Logsに直接送信される
- Route53コンソールからは閲覧不可、CloudWatch Logsコンソールから閲覧可能
CloudWatch Logs → S3エクスポート(オプション)
- 長期保存とコスト削減のため、S3にエクスポート
- Athena分析用にParquet形式への変換を推奨
- Kinesis Data Firehose経由でのリアルタイムエクスポートも可能
注意事項:
- Route53クエリログはCloudWatch Logsにのみ直接送信されます(S3への直接送信は不可)
- ログはCloudWatch Logsコンソールで閲覧可能です
- S3エクスポートはコスト削減と長期保存のためのオプションです
- クエリログ機能を有効化すると、CloudWatch Logsの使用料が発生します
コスト考慮:
- CloudWatch Logsのストレージコストは比較的高額
- 長期保存が必要な場合は、早めにS3にエクスポートすることを推奨
- 分析頻度が低い場合は、必要時のみエクスポートすることも検討
次のステップ
- Phase 1のログソース: 即座に分析可能なため、優先的にドキュメント作成
- Phase 2のログソース: S3エクスポート設定の検討と実装
- Phase 3のログソース: ログ出力の必要性を評価し、必要に応じて設定
関連ドキュメント
- Athena基本設計ガイド - 共通設計方針