【入門編】 API GatewayにおけるレートリミットとスロットリングによるDoS攻撃防御 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

こんにちは！インフラやセキュリティの世界へようこそ。
初めてセキュリティやAPIの仕組みに触れるとき、次々に出てくる専門用語に「なんだか難しそう……」と圧倒されてしまいますよね。でも、一歩ずつ身近な例に置き換えて見ていけば、実はとってもシンプルな仕組みでできていることが分かります。

今回は、現代のWebシステムでは欠かせない「API Gatewayにおけるレートリミット（流量制限）とスロットリング（防御機構）によるDoS攻撃防御」について、一緒に優しく紐解いていきましょう！

—

1. 家の玄関で考える「API Gateway」と「DoS攻撃」の防犯

まずは、私たちが普段暮らしている「お家」をイメージしてみてください。

あなたのお家には、大切な家族や財産を守るための「玄関の鍵」がありますよね。家族や、合い鍵を渡した信頼できる友達なら、鍵を開けてスムーズに入ることができます。
しかし、もし悪意を持った泥棒がやってきて、「1秒間に1,000回の勢いでガチャガチャとドアノブを乱暴に回し続けたら」どうなるでしょうか？

  • 家族が本当に入りたい時に、ドアの前に人が群がっていて入れない。
  • ドアノブが壊れてしまうかもしれない。
  • 家の中の人が、その対応だけに追われて他のことが何もできなくなってしまう。

これが、インターネットの世界でいう「DoS（Denial of Service：サービス拒否）攻撃」です。
攻撃者は、あなたが作った大切なWebサービス（API）に対して、ボット（自動プログラム）などを使って、人間には到底不可能な数のリクエストをものすごい勢いで送りつけます。すると、バックエンドにあるサーバー（お家の中）がパンクしてしまい、本当のユーザーがサービスを使えなくなってしまうのです。

API Gatewayは「優秀なコンシェルジュ」

ここで登場するのが、今回主役となる「API Gateway（APIゲートウェイ）」です。
API Gatewayは、いわばマンションの「オートロック付きエントランスにいる超優秀なコンシェルジュ」のような存在です。

すべてのリクエスト（来訪者）は、まずこのコンシェルジュ（API Gateway）のところに通されます。コンシェルジュは、来訪者が怪しい動きをしていないか、ルールを守っているかをチェックしてから、奥のサーバー（お部屋）へ通すかどうかを判断してくれます。

—

2. クライアント単位の流量制限（レートリミット）とは？

コンシェルジュがチェックするルールのひとつが、「レートリミット（流量制限）」です。

例えば、近所のパン屋さんで「おひとり様につき、1分間に買えるパンは3個までです」というルールがあったとします。これによって、一人の人が買い占めてしまって、後ろに並んでいる人が買えないという事態を防げますよね。

これと同じことをAPIの世界でも行います。
API Gatewayの「Usage Plan（利用プラン）」という機能を使うと、「このアプリ（クライアント）からは、1秒間に何回までリクエストを送っていいよ」という上限をきっちり決めることができます。

レートリミットを超えたときの「お返事」

もし、決まったルール（例えば「1秒間に5回まで」）を超えて、6回目、7回目のリクエストを送ってきた人がいたらどうなるでしょうか？
コンシェルジュは優しく、しかし毅然とした態度でこう伝えます。

> 「ちょっとペースが早すぎます！少し落ち着いてからまた来てくださいね。」

この時に返されるのが、HTTPステータスコードの 429 Too Many Requests というエラーです。「リクエストが多すぎますよ」という意味の、セキュリティの世界ではおなじみの合図になります。

—

3. バックエンドを守る「スロットリング閾値」の算出ロジック

次に、API Gateway自身ではなく、その奥にある「本当のサーバー（バックエンド）」を守るための「スロットリング（防御の目詰まり防止）」について考えてみましょう。

コンシェルジュ（API Gateway）がどれだけ優秀でも、奥にいるサーバー（データベースやアプリケーション）が一度に耐えられる限界を超えて仕事を与えてしまったら、サーバーは倒れてしまいます。

ここで重要になるのが、「スロットリング閾値（しきいち：限界ライン）」の算出です。

算出ロジックの考え方（ざっくり計算式）

バックエンドサーバーの限界を見極めるために、現場では次のような泥臭いストレステスト（負荷テスト）を行います。

1. サーバーの限界値を知る

  • 「うちのデータベースサーバーは、最大で1秒間に1,000回のリクエストまでなら耐えられるな」という物理的な限界（キャパシティ）を調べます。

2. バッファ（ゆとり）を持たせる

  • 限界ギリギリで動かすのは、道路でいえば常に大渋滞を起こしているようなものです。安全マージンとして、例えば「安全のために、限界の50%である500リクエスト/秒を上限にしよう」と決めます。

3. 全体と個別のバランスを取る

  • もし利用者が10人いるなら、1人あたり平均してどれくらい使えるべきか、全体の上限（Burst Limit / Rate Limit）を逆算してAPI Gatewayに設定します。

この「これ以上負荷をかけたらシステムが壊れてしまう」という安全弁を正しく設定することが、インフラエンジニアの腕の見せどころなんです。

—

4. 実務で使える！API Gateway設定とレスポンスのイメージ

それでは、AWSのAPI Gatewayや一般的なクラウド環境を想定した設定と、その裏側の仕組みを少しだけコードや設定例で見てみましょう。
「一歩ずつ設定を学んでいきましょう！」

① API GatewayのUsage Plan（利用プラン）の設定例（イメージ）

多くのクラウドプラットフォームでは、次のようなパラメータで流量制限を設定します。

{
  "usagePlanName": "StandardDeveloperPlan",
  "description": "一般開発者向けの標準API利用プラン",
  "throttle": {
    "rateLimit": 10,  
    "burstLimit": 20  
  },
  "quota": {
    "limit": 10000,
    "period": "DAY"
  }
}
  • rateLimit（スロットリングレート）: 1秒あたりに処理する平均リクエスト数の上限（例：秒間10回まで）。
  • burstLimit（バースト限界）: 瞬間的な急増（バースト）に耐えられる一時的な上限（例：瞬間最大20回まで）。
  • quota（クォータ）: 1日あたり、あるいは1ヶ月あたりに通してよい総リクエスト数の上限（例：1日10,000回まで）。

② クライアント側（JavaScript）での 429 エラーハンドリング例

もしクライアントアプリが制限を超えてリクエストを送り、コンシェルジュ（API Gateway）から 429 エラーを受け取った場合、プログラム側できちんと優しくハンドリング（対処）してあげる必要があります。
そのまま突っ込むのではなく、「少し待ってから再トライ（リトライ）」する実装がマナーです。

async function callMyApi() {
  try {
    const response = await fetch('https://api.example.com/v1/data');
    
    // もし流量制限に引っかかった場合
    if (response.status === 429) {
      console.warn('⚠️ リクエストの制限を超えました。少し待ってから再試行します。');
      
      // レスポンスヘッダーから「何秒待てばいいか」を取得することもあります
      const retryAfter = response.headers.get('Retry-After') || 5;
      
      // 指定された秒数だけ処理を待つ（スリープ）
      await new Promise(resolve => setTimeout(resolve, retryAfter * 1000));
      
      // 再度リクエストを送る（リトライ処理）
      return callMyApi();
    }

    if (!response.ok) {
      throw new Error(`予期せぬエラーが発生しました: ${response.status}`);
    }

    const data = await response.json();
    return data;

  } catch (error) {
    console.error('API通信エラー:', error.message);
  }
}

このように、コードの中でも「制限にかかったら少し待つ（バックオフ処理）」という思いやりを持たせることが、安定したシステムを作る上でとても大切になります。

—

まとめ

今回は、API Gatewayにおけるレートリミットとスロットリングについて、お家の防犯やコンシェルジュの例えを交えてお話ししました。

  • API Gateway は、サーバーを守る優秀なコンシェルジュ。
  • レートリミット は、クライアントごとの「1秒間にこれだけにしてね」というお約束。
  • スロットリング閾値 は、バックエンドのサーバーがパンクしないための命綱。

最初は難しく感じるセキュリティの仕組みも、「どうやったらお互いに気持ちよく、安全にシステムを使えるか」というおもいやりの心で設計していくと、とてもスッキリと腑に落ちるはずです。

日々の開発やインフラ構築の中で、「このAPI、もし誰かが何万回も同時に叩いたらどうなるだろう？」という視点を少しだけ持ってみてくださいね。その小さな気づきが、あなたのシステムを守る最高の第一歩になります。

それでは、また次回のセキュリティ解説でお会いしましょう！

スポンサーリンク

コメント

タイトルとURLをコピーしました