Professional Cloud Network Engineer
Rate limiting in Google Cloud Armor (Cloud Armor) is a Layer 7 security control that inspects incoming HTTP and HTTPS traffic to protect backend services from volumetric denial-of-service (DDoS) attacks, brute-force attempts, and API exhaustion. Cloud Armor enforces these rate limits at the edge of Google's network within Google points of presence (PoPs) before incoming packets enter Virtual Private Cloud (VPC) networks. By measuring request rates against defined thresholds, the service throttles or blocks abusive clients while permitting valid traffic to reach backend workloads.
Cloud Armor rate limiting rules evaluate incoming requests against configured thresholds to trigger distinct conform or exceed actions. When incoming traffic stays below the threshold, the rule executes a conform action such as allow, which forwards requests directly to the target backend service. If traffic exceeds the threshold, the rule triggers exceed actions such as throttle to slow down requests, rate-based ban to temporarily block the client, or deny to return a specific HTTP error code. Security policies can also execute redirect actions such as GOOGLE_RECAPTCHA or EXTERNAL_302 to challenge bots or send clients to an alternate web page.
Rate limiting thresholds define the maximum number of requests an individual client or key can transmit during a specified interval evaluation window. The security policy tracks request counts across this time window to spot sudden bursts or sustained resource-draining queries. When incoming traffic matches the rule criteria, Cloud Armor tallies requests against that client's specific key until the time window resets. Setting appropriate interval evaluation windows protects instance groups, network endpoint groups (NEGs), and Cloud Storage buckets from sudden traffic spikes.
Enforcement keys determine the specific request properties Cloud Armor uses to group and isolate client traffic for rate tracking. Cloud Armor can track standard client IP addresses (origin.ip), forwarded IP headers (origin.user_ip), HTTP request headers, cookie values, or TLS fingerprints such as JA3 and JA4. Security rules can also filter traffic using Server Name Indication (SNI) identifiers, geographic region codes (origin.region_code), or normalized URLs formatted by functions like lower() and urlDecode(). Grouping traffic by these granular attributes isolates abusive actors individually without degrading access for other users sharing the same application.
Rate limiting rules reside inside security policies that attach directly to the backend services of supported Google Cloud load balancers. Cloud Armor supports rate limiting across the following load balancer types:
In this architecture, traffic travels from the client to the load balancer frontend, undergoes Cloud Armor inspection at the network edge, and continues only to healthy backends if the rate limit allows it. Creating and updating policy rules requires the Compute Security Admin role (roles/compute.securityAdmin), while attaching a security policy to a target backend service requires the Compute Network Admin role (roles/compute.networkAdmin).
Monitoring, testing, and tuning rate limiting policies involves analyzing telemetry from Cloud Logging and Cloud Monitoring to validate rules in preview mode before activating enforcement on production traffic. Reviewing policy telemetry helps administrators spot traffic anomalies and tune threshold settings to avoid blocking legitimate users.
Cloud Armor logs detailed rate limiting events in Cloud Logging, including the policy name, rule priority, rule ID, and final enforcement outcome. Each evaluated log entry contains a rateLimitAction field displaying the key value used for tracking and an outcome field showing RATE_LIMIT_THRESHOLD_CONFORM, RATE_LIMIT_THRESHOLD_EXCEED, or BAN_THRESHOLD_EXCEED. The rate limit key value is truncated to 36 bytes in log records and is omitted entirely if the key type is ALL or if the specified header or cookie is missing. Administrators can review these log streams by selecting a security policy in the Google Cloud console and navigating to Logs Explorer.
Cloud Monitoring provides visual dashboards and metrics to observe rate limiting activity across Application Load Balancers. The predefined Cloud Armor policies overview dashboard displays request metrics categorized by outcome: allowed, denied, previewed allowed, and previewed denied. Administrators can also build custom dashboards for the Network Security Policy resource type to track request counts and configure alerts for abnormal traffic spikes. These metrics are exported in one-minute batches and stored for six weeks, allowing teams to analyze traffic patterns across multiple days or weeks.
Preview mode validates the behavior of rate limiting rules against live production traffic without actively blocking or throttling any requests. When a rule has preview mode enabled via the --preview flag or the web console, Cloud Armor logs the simulated outcome while continuing to evaluate subsequent rules in the policy. The resulting log record includes a previewSecurityPolicy field displaying the action the rule would have taken alongside the enforcedSecurityPolicy field showing the actual applied action. Preview rules incur the standard per-request Cloud Armor evaluation charges while protecting applications from unintended false positives.
Tuning rate limiting thresholds requires measuring baseline application traffic to set limits that block attacks without disrupting real users. When creating a default security policy during load balancer setup, the system assigns a default threshold of 500 requests per minute. A standard tuning practice involves querying Cloud Logging for the 99th percentile of requests per client IP over a 24-hour period and setting the threshold to match that level. If legitimate users still encounter limits, administrators can cache static assets using Cloud CDN, expand the evaluation interval, or implement rate-based bans with allowed ban durations of 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700, or 3600 seconds.
Cloud Armor enforces rate limiting thresholds independently across each Google Cloud region where backend services are deployed. Because of this distributed enforcement, a backend service deployed in two separate regions could receive up to twice the configured aggregate threshold if traffic is split between them. Traffic using the client IP key type generally routes to the nearest region, making enforcement effectively centralized per client. Cloud Armor rate limits are approximate controls designed for availability protection and abuse mitigation rather than strict billing or quota enforcement.
Ban thresholds and adaptive mitigation actions in Cloud Armor temporarily block offending clients and present interactive challenges to separate automated bots from human users. Combining temporary bans with dynamic challenges provides stronger protection against aggressive brute-force attacks and credential stuffing.
A ban threshold is a specific burst limit that temporarily isolates clients sending an excessive volume of requests. When a client exceeds this configured burst count, Cloud Armor flags the client as abusive and places it into a banned state. The client remains blocked for the configured ban duration, dropping all subsequent requests until the timer expires. Once the ban duration concludes, the client automatically transitions back to a monitored state where requests are evaluated normally.
Adaptive response mechanisms allow Cloud Armor to handle suspicious traffic with dynamic challenges rather than simple packet drops. Security rules can be configured to issue an HTTP redirect that sends client browsers to a warning page or an external landing URL. Alternatively, Cloud Armor can integrate with reCAPTCHA Enterprise to deliver an inline challenge token. Automated bots fail to solve these interactive challenges, allowing legitimate human users to verify their identity and continue to the application.
Ban thresholds and adaptive actions operate as sequential enforcement steps inside a broader Cloud Armor rate limiting rule. The security policy first evaluates incoming traffic against initial match criteria, such as request rates per IP address. If traffic surpasses the primary threshold, the policy checks whether the request count also violates the secondary burst ban threshold. Crossing this secondary limit triggers the configured mitigation response, immediately executing a ban, an HTTP redirect, or a reCAPTCHA challenge.
StudyCerts
StudyCertsban_threshold_count alongside a ban_duration_sec, which supports fixed values ranging from 60 to 3600 seconds.roles/compute.securityAdmin), whereas binding a policy to a backend service requires the Compute Network Admin role (roles/compute.networkAdmin).Active enforcement applies configured actions like throttling, bans, or HTTP error codes directly to matching client requests. Preview mode allows Cloud Armor to evaluate rules and log the simulated outcome under the previewSecurityPolicy log field while letting the traffic pass through to subsequent rules without intervention.
Cloud Armor enforces rate limiting thresholds independently within each Google Cloud region where backend instances run. If an application backend is deployed across two regions, incoming traffic split evenly across both regions could reach up to two times the configured threshold in aggregate before triggering rate limiting.
An administrator should choose a reCAPTCHA Enterprise challenge when traffic is suspicious but might include legitimate human users, such as during a high-traffic sale or login event. An HTTP deny action immediately drops or rejects the request, whereas a reCAPTCHA challenge allows human users to prove their legitimacy while blocking automated scripts.
Prepare and test your skills
Prepare and test your skills