← AWSサービスの内部原理 コース
43. バケットは4階層 — 使用量プランとAPIキーによる客ごとの制限
API Gateway の門番は「トークンバケット」1個ではなく4階層の入れ子で、APIキーと使用量プランで客ごとに配分する — その全体像を5枚の図で追う。
① トークンバケット — rate が速度、burst が容量
rate毎秒トークンを補充
= 定常状態のリクエスト/秒バケット容量 = burst
= 瞬間的に受けられる上限リクエスト1件 = 1トークン消費
バケットが空になると
429 Too Many Requestsリクエストは通れない
- rate = 平均的な処理速度 / burst = 一気に受けられる同時リクエストの上限、という役割分担
- ネットワークやOSで学ぶレート制限そのもの。マネージドサービスの中身も基礎アルゴリズム
トークンが一定速度で補充されるバケツからリクエストが1個ずつトークンを取る。空なら429で弾かれる、それだけの単純なアルゴリズムが門番の正体。
② バケットは1個じゃない — 4階層の入れ子構造
(4) AWSリージョン全体全アカウント一律
顧客は変更不可この中に収まる
(3) アカウント × リージョンサポート申請で引き上げ可
ただし(4)は超えられないこの中に収まる
(2) ステージのメソッド別制限(4)を超えられない
この中に収まる
(1) 使用量プランクライアント別 / メソッド別
(3)のアカウント制限を超えられない- 適用は内側(1)から外側(4)の順
- 資源を段階的に分け与える「階層的資源分配」— OSのcgroupのネスト制限と同じ発想
外側は「これ以上は全体が壊れる」安全弁、内側は「この顧客はここまで」の細かい配分。内側の制限は外側を絶対に超えられない。
③ APIキーは「名札」— 識別であって認証ではない
APIキー20〜128文字の英数字
役割 = 識別(誰であるか)認証・認可はこちらに任せる
IAMロール
Lambdaオーソライザー
Cognitoユーザープール
- 公式も明言:「アクセス制御のための認証・認可にAPIキーを使ってはならない」
- 理由: 1つの使用量プランに複数APIが紐づくと、あるAPIの有効キーで同じプラン内の全APIにアクセスできてしまう
APIキーの正体は「どの客か」を示すラベルにすぎない。アクセスを許すかどうか(認証・認可)は別の仕組みの仕事。
④ 使用量プラン — 客ごとに「速度」と「総量」を配る
APIキー客の識別ラベル
紐づけ
使用量プラン誰がどのステージ・メソッドに アクセスできるかを定義
キーごとに2種類の制限を設定
スロットリングrate + burst
1秒あたりの瞬間的な速度クォータ日・週・月あたりの上限
一定期間の総リクエスト数- 制限はそのAPIキーがプラン内の全ステージにまたがって送ったリクエストを合算して適用
APIキーに実際の制限値を紐づけるのが使用量プラン。スロットリングが瞬間の速度、クォータが期間あたりの総量を抑える二段構え。
⑤ 制限は「目標値」— 分散システムゆえの割り切り
多数のノードが並列処理リージョン内で分散
各ノードが独立にカウント1件ごとの完全同期はしない
制限は「だいたい効く」目標クォータ超過もありうる
だから確実にやりたいことは専用サービスへ
コスト管理→ AWS Budgets
アクセス遮断→ AWS WAF
- 公式: 制限は「保証された上限」ではなく「目標値」として扱うべき
- 使用量プランのクォータ/スロットリングをコスト制御やアクセスブロックの手段にしてはいけない
多数のノードが独立に数えるため、制限はベストエフォート。厳密な同期を取るとカウンタ自体がボトルネックになるので、厳密さよりスループットを優先する。