現場で戦うエンジニア諸君。セキュリティは「チェックリストを埋める作業」ではない。「想定外を想定するゲーム」だ。
今日は、クラウドネイティブ環境におけるDDoS対策について話そう。教科書には「WAFを入れろ、Auto Scalingを設定しろ」としか書いていないが、その先にある「攻撃者の心理」と「システム崩壊のトリガー」について触れる。
1. 攻撃者が狙う「リソース枯渇」の盲点
DDoSは単なるトラフィックの洪水ではない。攻撃者は常に「コスト対効果」を計算している。彼らは、最も安価に、最も確実に君たちのインフラをダウンさせるため、以下の2点を狙い撃ちにする。
1. L7（アプリケーション層）の重い処理： 検索クエリやPDF生成など、CPUを食うエンドポイント。
2. Auto Scalingの追従遅延： 負荷が急増してからインスタンスが立ち上がるまでの「数分間の空白」。
この空白こそが、サービスが最も無防備になる時間だ。ここをどう守るか。
2. 実装：Nginxでのレートリミット（現場の第一防衛線）
クラウドのWAFを過信してはいけない。WAFがトラフィックを捌き切る前に、オリジン（Nginx等）で接続を制限する実装を必ず入れること。
# nginx.conf: 特定のIPからの過剰なリクエストを遮断する設定
# 1秒間に10リクエストまで。超過した場合は即座に503を返す
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
server {
location /api/heavy-process {
# 503を返すことで、過負荷を回避しつつ接続を早期切断する
limit_req zone=api_limit burst=20 nodelay;
proxy_pass http://backend_pool;
}
}この設定の肝は nodelay だ。キューに溜めず、即座に弾くことで、サーバーのワーカープロセスが枯渇するのを防ぐ。
3. Auto ScalingとCloudFront/WAFの連携の極意
クラウドネイティブなDDoS対策の本質は、「耐える」ことではなく「逃がす」ことだ。AWSを使うなら、CloudFront + AWS WAF + Auto Scalingの3段構えが基本だが、「スケールアウトのトリガー」に注意が必要だ。
CPU使用率だけでスケールさせていないか？それだと、DBのコネクション枯渇や、メモリ不足によるOOM Killerで死ぬ前にインスタンスが落ちる。必ず「Request Count Per Target」をメトリクスに含めろ。
AWS WAFのレートベースルール（JSON例）
コンソールでポチポチ設定するのもいいが、CI/CDで管理できるようJSON化しておくのがプロの流儀だ。
{
"Name": "RateLimitRule",
"Priority": 1,
"Action": { "Block": {} },
"Statement": {
"RateBasedStatement": {
"Limit": 2000, // 5分間で2000リクエストを超えたらブロック
"AggregateKeyType": "IP"
}
},
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "RateLimitMetric"
}
}4. アプリケーション側での「セーフティネット」
最後に、Webアプリ側でできる泥臭い対策だ。どんなにインフラを固めても、バックエンドが詰まれば終わりだ。APIには必ずタイムアウトを実装しろ。
Python (FastAPI/requests) でのタイムアウト設定
import httpx
# 外部APIを叩く際、デフォルトのタイムアウトを放置するのは自殺行為だ
async def fetch_external_resource():
async with httpx.AsyncClient(timeout=httpx.Timeout(2.0, connect=5.0)) as client:
try:
response = await client.get("https://third-party-api.com/data")
return response.json()
except httpx.TimeoutException:
# タイムアウトしたら即座に例外を投げ、ユーザーには「ただいま混雑中」と伝える
return {"error": "Service Temporarily Unavailable"}エンジニアへのアドバイス
DDoS対策において、最も危険なのは「過信」だ。
「Auto Scalingが効くから大丈夫」と思っていると、攻撃者がインフラの課金上限を叩き、莫大な請求書だけを残してサービスが落ちる「経済的DDoS」に直面する。
- 予算アラートの徹底： AWS Budgets等で、急激な課金増を検知したら即座にエンジニアへSlack通知を飛ばす仕組みを作ること。
- 定期的な負荷試験： 本番環境に近い構成で、あえて
abコマンドやLocustを使い、どの負荷でAuto Scalingが発動し、どの負荷でサービスが崩壊するかを数値で把握しておくこと。
コードを書くとき、インフラを組むとき、常に「これが攻撃されたらどこが死ぬか？」を自問自答してほしい。それができる人間だけが、真のエンジニアだ。
健闘を祈る。何かあればまた相談に来い。
コメント