最近、提供サービスのリクエストが異常に増えた日があり、ELBのレイテンシアラートが鳴りまくって焦りました。
こんなときのために、AthenaでELBのアクセスログを分析できる基盤をつくってあったんですが、緊急時だとSQLをつかった分析はめっちゃ時間がかかりました(書く→直す→集計待つ→また直す...)。なんとか怪しいIPからの大量リクエストをみつけてブロックまでもっていけたのですが、原因調査から対応までの時間をもっと短縮できたんじゃないかな〜とちょっとモヤモヤが残りました。
それでAWS公式のMCPサーバーをあらためて眺めてみたところ、自然言語でAthenaを叩けるやつがありました。AWS Data Processing MCP Serverという名前だったので、関係ないと思ってこれまでスルーしていました。
ドキュメントをみて導入してみてください！で終わりなのですが、つまったところもあるので、そのあたりも含めて手順と使い勝手をメモとして残そうと思います。
導入
今回はClaude DesktopからMCP連携したので、claude_desktop_config.jsonに以下の定義を追加しました。work-mcpはこの用途向けにつくったAWS_PROFILEです。
{
"mcpServers": {
"aws.dp-mcp": {
"command": "uvx",
"args": ["awslabs.aws-dataprocessing-mcp-server@latest"],
"env": {
"FASTMCP_LOG_LEVEL": "ERROR",
"AWS_PROFILE": "work-mcp",
"AWS_REGION": "ap-northeast-1"
},
"autoApprove": [],
"disabled": false
}
}
}
IAMポリシー(少しハマった)
ドキュメント記載の権限だけだと、自環境ではエラーが出た(athena:StartQueryExecutionが足りないなど)ので改修しました。以下のポリシーで動作確認しました(S3のバケット名は各自書き換えが必要です)。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AthenaQueryAccess",
"Effect": "Allow",
"Action": [
"athena:StartQueryExecution",
"athena:GetQueryExecution",
"athena:GetQueryResults",
"athena:StopQueryExecution"
],
"Resource": "*"
},
{
"Sid": "AthenaMetadataAccess",
"Effect": "Allow",
"Action": [
"athena:GetDatabase",
"athena:GetTableMetadata",
"athena:ListDatabases",
"athena:ListTableMetadata"
],
"Resource": "*"
},
{
"Sid": "GlueDataCatalogAccess",
"Effect": "Allow",
"Action": [
"glue:GetDatabase",
"glue:GetDatabases",
"glue:GetTable",
"glue:GetTables"
],
"Resource": "*"
},
{
"Sid": "S3LogsAccess",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::your-alb-logs-bucket",
"arn:aws:s3:::your-alb-logs-bucket/*"
]
},
{
"Sid": "AthenaResultsS3Access",
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:GetObject",
"s3:ListBucket",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::your-athena-results-bucket",
"arn:aws:s3:::your-athena-results-bucket/*"
]
}
]
}
使用例
質問1
Athenaのalb_access_logsを分析したい。
2025-08-07 00:00:00 ~ 23:59:59 JST のリクエストでボットっぽいものがあるか教えて。
回答1(機密部分はマスク済)
# ALBアクセスログのボット分析結果（2025年8月7日 JST／一部マスク済）
AthenaでALBアクセスログを分析し、ボット／ボット疑いのアクセスを抽出しました。
※外部IPは `[IP-A]` のように匿名ラベル化、内部APIパスはパラメータ化し、件数は概数レンジで表記しています。
## 🤖 User-Agentベースで検出されたボット
1. **VirusTotalBot** — 合計 \~160 リクエスト
* 代表IP: `[IP-V1]`, `[IP-V2]`, `[IP-V3]`
2. **Googlebot** — 数件
* 代表IP: `[IP-G1]`
3. **Google-Safety Bot** — 数十件
* 代表IP: `[IP-GS1]`, `[IP-GS2]`
4. **Plesk screenshot bot** — \~50件
* 代表IP: `[IP-P1]`
5. **その他**
* **AmazonProductDiscovery bot**（少数）
* **Brainfeedbot**（少数）
* **meta-externalads**（少数／Facebook関連）
* **MicroAdBot**（単発）
* **curl**（少数）
6. **User-Agent未設定（"-"）** — \~1.1k件（最多は `[IP-U1]`）
## 🚨 大量リクエストによる疑わしいアクティビティ（Top例）
1. **\[IP-A]** — **\~280k** リクエスト（当日最多）
* 主なUA: 一般的なブラウザUA（例：デスクトップChrome系）
* ユニークURL: \~2.0k
* 特徴: **特定セッションに対する高頻度ポーリング**（ピーク時 1時間あたり \~3k–5k）
2. **\[IP-B]** — **\~180k** リクエスト
* UA数: 2
* ユニークURL: \~18k
3. **\[IP-C]** — **\~120k** リクエスト
* UA数: 3
* ユニークURL: \~10k
4. **\[IP-D]** — **\~56k** リクエスト
* 特徴: **3時間前後に集中**（ピーク 1時間あたり \~4k）
## 🔍 特異なアクセスパターン（抜粋）
* **\[IP-A]** は以下の特徴からボット的／不適切設定のクライアント挙動が強く疑われます：
* 同一系URLに対して**高頻度ポーリング**が終日継続
* エンドポイント例：`/v1/log/{sessionId}` などセッション監視系APIへの集中アクセス
## 📊 全体統計（当日）
* **総リクエスト数**: \~15.2M
* **明確なボット**: \~1.4k
* **大量アクセス（≥1k/日）**: \~20 IP から合計 \~2.0M
**結論**: 特に `[IP-A]` のアクセスは、**ポーリング間隔が過度に短い**ため、ボットもしくはクライアント設定不備の可能性が高いです。アクセス制御やレート制限、キャッシュ／プッシュ型への置換などの対策検討を推奨します。
質問2
AWS WAFのBot Controlルールを追加したとして、ブロック件数はそんなに多くない?
また、[IP-A]とか[IP-B]のアクセスはスルー?
回答2
# AWS WAFのBot Controlルールについて（マスク済み）
まず、今回検出されたボットの種類と件数を整理します。
## 🛡️ **AWS WAF Bot Controlルールでの検出予測**
### **確実にブロックされるボット（明確なボットUA）**
1. **VirusTotalBot**: **\~160** リクエスト
2. **Googlebot**: **数件**（※通常は許可設定が望ましい）
3. **Google-Safety Bot**: **数十件**（※通常は許可設定が望ましい）
4. **MicroAdBot**: **\~10件**
5. **Brainfeedbot**: **\~10件**
6. **Plesk screenshot bot**: **数件〜数十件**
7. **curl**: **数件**
**合計: 概ね \~230–\~290 リクエスト/日**
### **User-Agent未設定（"-"）**: **\~0.5k–\~1.1k リクエスト/日**
* 一部はBot Controlで検出対象
* 正当なプロキシ経由アクセスが含まれる可能性あり
### 📊 **ブロック件数の予測**
**結論: 量は多くない**
* **明確なボット**: **\~300–\~400 リクエスト/日**
* **全体比**: **\~0.002–\~0.003%**（1,500–1,800万/日規模のうち）
---
## 🎯 **\[IP-A] と \[IP-B] はスルーされるか？**
### **\[IP-A] の判定**（例：グローバルIP）
**おそらくスルーされる可能性が高い**
**根拠（マスク済み）:**
* User-Agent: **一般的なデスクトップChrome 系UA**（具体バージョンは省略）
* Bot Control は主に **UA識別** を基点とするため
**ただし検出されうる条件:**
* **行動パターン分析**（高頻度・長時間・規則性）
* 例：**\~25k/日** の機械的アクセスが継続
### **\[IP-B] の判定**（例：企業ネットワーク由来）
**ほぼスルー（対象外）となる見込み**
**根拠（マスク済み）:**
* UAは一般的なブラウザ系
* **認証済みクライアントによる正当なAPIアクセスが多い傾向**
* Bot Control は主に **汎用スクレイピング系ボット** を対象
**補足:**
* アクセス先は企業向けAPIの一部（例：`/v1/companies/{...}` など）。
* **設定ミスや実装由来の過剰アクセス**が疑われ、悪意ボットとは言い切れない。
---
## 🔧 **より効果的なWAF設定の提案**
### 1) Rate Limiting Rules（レート制限）
同一IP:
- 1分間あたり ~100 リクエスト
- 1時間あたり ~1,000 リクエスト
### 2) API-specific Rules（エンドポイント別）
/v1/companies/* : 1分間 ~10 リクエスト/IP
/v1/log/* : 1分間 ~5 リクエスト/IP
### 3) カスタムルール（振る舞い検知）
- 同一URLへの短時間大量アクセス
- 深夜帯の不自然な高頻度
- 均等間隔のポーリングパターン
### 4) 例外（ホワイトリスト）
- 必要な企業固定IP範囲（/24 or ASN単位）の許可
- 特定User-Agentの除外（社内監視系など）
## 📊 **実際の効果予測**
* **Bot Control単体**: **\~300–\~500 リクエスト/日** をブロック
* 主要課題（\[IP-A]/\[IP-B] の大量正当UAアクセス）は **未解決**の可能性
* **Rate Limiting併用**で体感的効果は大幅改善、正当ユーザー影響も最小化可能
**結論**: **Bot Control だけでは不十分**。**レート制限**や**振る舞い検知**を併用して、正当アクセスを保護しつつ過剰アクセスを抑制する構成が現実解。
WAFの設計判断にも効いた
ボットっぽいリクエストが何件？みたいなクエリをSQLで実装するとかなり骨が折れるので、ここまで詳細に分析してくれてかなり助かりました。AWS WAFのルールにBot Controlを追加するかどうか、が効果面と費用面(他ルールと違って追加料金がかかる)で悩みどころだったのですが、今回のリクエストはBot Controlを基本的にすり抜けることが数字でわかったのもよかったです。
MCPを入れたからといってSQLが不要になるわけではないのですが、アラートが鳴ってから最初の仮説を出すまでの時間が明らかに短くなりました。