サービス レート制限ポリシーを使用すると、信頼できるクライアントが過剰な量のリソースを消費する可能性がある場合でも、サービスの可用性を維持できます。ポリシーは、サービスの過負荷時に重要なクライアント トラフィックを優先し、事前定義されたしきい値を超えるクライアントをスロットリングすることで、これを実現します。
サービス レート制限ポリシーを他のタイプのレート制限と組み合わせることができます。たとえば、信頼できないクライアントを明示的に禁止して不正行為を防止する Cloud Armor セキュリティ ポリシーなどです。セキュリティ ポリシーの詳細については、セキュリティ ポリシーの概要と Cloud Armor のレート制限の概要をご覧ください。
サービス レート制限ポリシーは、サポートされているロードバランサの転送ルールまたは Secure Web Proxy ゲートウェイ リソースに接続します。Secure Web Proxy インスタンスでサービス レート制限ポリシーを使用する方法については、サービス レート制限ポリシーを構成するをご覧ください。
サポートされているターゲット
サービス レート制限ポリシーは、次のターゲットで使用できます。
- リージョン内部アプリケーション ロードバランサ
- Secure Web Proxy
リクエスト フィルタリングの順序
サービス レート制限ポリシーは、リクエストに適用されるフィルタの 1 つにすぎません。次の図は、フィルタが適用される順序を示しています。
ルール
各サービス レート制限ポリシーには、HTTP ルールのリストが含まれています。各ルールでは、一致条件と一連のレート制限アクションを指定します。リクエストがルールのマッチ条件を満たすと、リクエストは構成済みの 1 つ以上のレート制限バケットに対して評価されます。
一致条件
一致条件とそのプロパティは次のとおりです。各プロパティは、完全な文字列、接頭辞、接尾辞、部分文字列と一致させることができます。
Source: リクエストの送信元。principal: クライアント証明書から派生した ID のリスト。いずれかのプリンシパルがルールに一致すると、一致が発生します。サービス レート制限にプリンシパルを使用する方法については、サービス レート制限にプリンシパルを使用するをご覧ください。
Destination: リクエストの宛先。複数のプロパティを指定すると、それらは論理AND演算子で結合されます。header_set: HTTP ヘッダーのリスト。一致は、header_set内のすべてのヘッダーがルールと一致する場合に発生します。hosts: HTTP ホストのリスト。リクエストがリスト内の指定されたホストのいずれかに送信されると、一致が発生します。paths: URL パスのリスト。リクエストがリスト内の指定されたパスのいずれかを使用すると、一致が発生します。methods: 有効な HTTP メソッド（GETやPOSTなど）のリスト。リクエストがリスト内の指定されたメソッドのいずれかを使用すると、一致します。
送信元プロパティと宛先プロパティは、論理 AND 演算子で結合され、ルールがリクエストと一致するかどうかを判断します。つまり、送信元と宛先を指定する場合、リクエストは一致条件を満たすために両方に一致する必要があります。また、空のルールはすべてのリクエストに一致します。
ルールの評価順序
ルールは、ポリシーで定義されている最初のルールから、ポリシーで定義されている最後のルールまで順番に評価されます。リクエストに一致する最初のルールが、レート制限アクションをリクエストに適用します。それ以降のルールは評価されません。ルールに複数のレート制限アクションがあり、そのいずれかが構成されたしきい値を超えると、リクエストはスロットリングされます。
レート制限バケット
1 つ以上のレート制限バケットを構成します。各バケットには 1 つ以上のレート制限キーがあります。リクエストがルールのマッチ条件に一致すると、リクエストは構成済みの 1 つ以上のレート制限バケットに対して評価されます。次に、バケットは構成済みのレート制限キーを適用して個々のクライアントを識別し、制限を適用します。
キータイプに加えて、次のバケット プロパティを構成できます。
- ドライラン: ドライラン モードでは、ルールが評価され、一致が追跡されますが、ルール アクションは適用されません。これにより、クライアントをスロットリングしたり、本番環境のトラフィックに影響を与えたりすることなく、レート制限ルールをテストできます。
- ユーザー オーバーライド: 特定のキー値のデフォルトのリクエスト上限をオーバーライドできます。たとえば、クライアントごとに 1 分あたり 100 件のリクエストというデフォルトの上限が設定されたバケットがあり、そのバケットで
SOURCE_IPキータイプを使用している場合、特定の IP アドレスの上限をオーバーライドして、1 分あたり 200 件のリクエストの上限を適用できます。
鍵のタイプ
レート制限の対象となる個別のクライアントを特定するには、次のキータイプを使用してリクエストを集約し、レート制限を適用します。
- ALL: ルールの一致条件を満たすすべてのリクエストに対する単一のキー。
- SOURCE_IP: リクエストがルールの一致条件を満たすクライアント IP アドレスを表す一意のキー。
- HTTP_HEADER: 名前が構成された一意の HTTP ヘッダー値を表す一意のキー。キー値は、ヘッダー値の最初の 128 バイトに切り詰められます。このようなヘッダーが存在しない場合、キータイプはデフォルトで ALL になります。
- HTTP_PATH: HTTP リクエストの URL パス。キー値は、最初の 128 バイトに切り詰められます。
- プリンシパル: クライアント証明書から派生した ID を表す文字列。サポートされているプリンシパル タイプは
CLIENT_CERT_COMMON_NAMEのみです。
各ルールには 1 つ以上の鍵タイプを指定できます。複数のキータイプを指定すると、各クライアントのキーの組み合わせ全体が一意のキーとして使用されます。たとえば、SOURCE_IP と HTTP_PATH を組み合わせて、特定の IP アドレスが特定のエンドポイントにアクセスする頻度にレート制限を適用できます。
サービス レート制限にプリンシパルを使用する
トラフィックのソースを高い粒度で識別するには、クライアントの証明書から派生した ID に基づくサービス レート制限ポリシーを構成します。この方法では、ロードバランサでフロントエンド mTLS を有効にする必要があります。また、クライアント証明書の共通名（CLIENT_CERT_COMMON_NAME）属性を識別用のプリンシパル セレクタとして使用します。
識別用のプリンシパル セレクタが指定されていない場合、CLIENT_CERT_URI_SAN がデフォルトのプリンシパル セレクタとして使用されます。つまり、レート制限を判断する際に、クライアント証明書の URI SAN が評価されます。
プリンシパル ベースのレート制限が機能するには、次の条件を満たしている必要があります。
フロントエンド mTLS が有効になっている。フロントエンド mTLS が有効になっていない場合、クライアントは証明書を提示しません。その結果、サービス レート制限ポリシーのプリンシパル ベースのルールは、評価する証明書情報を見つけられません。たとえば、
CLIENT_CERT_URI_SANをチェックするルールは空の値を確認します。有効なクライアント証明書が存在する。mTLS が有効になっていても、欠落している証明書または無効な証明書で接続が確立された場合、クライアント証明書はレート制限に使用されません。このシナリオは、mTLS クライアント検証モードが permissive モード
ALLOW_INVALID_OR_MISSING_CLIENT_CERTに設定されている場合に発生します。この場合も、サービス レート制限ポリシーのプリンシパル ベースのルールは、評価する証明書情報を見つけられません。たとえば、CLIENT_CERT_URI_SANをチェックするルールは空の値を確認します。
属性のサイズ上限の影響
レート制限の決定は、クライアント証明書の属性のサイズに影響されます。属性がサイズの上限を超え、その特定の属性を検証するようにポリシーが構成されている場合、リクエストは拒否されます。
ポリシーが CLIENT_CERT_COMMON_NAME に対して検証され、証明書のサブジェクト（共通名を含む）がサイズの上限を超えている場合、拒否が発生する可能性があります。