Adaptive Protection is an advanced machine learning (ML)-based attack detection system built into Google Cloud Armor that automatically identifies and mitigates Layer 7 distributed denial of service (DDoS) attacks. Unlike traditional rule-based filtering, Adaptive Protection works by building a dynamic model of what normal or "good" traffic looks like for a specific application, then using that model to detect anomalies that indicate malicious activity. This approach allows the system to adapt to the unique traffic patterns of each protected service rather than relying on static, one-size-fits-all signatures.
Cloud Armor inspects all incoming requests at Google's global edge locations before they reach backend services. Adaptive Protection continuously analyzes traffic characteristics such as request frequency, request patterns, header attributes, and payload signatures to establish a baseline of legitimate behavior. When the ML model detects traffic that deviates significantly from this baselineâsuch as a sudden surge in requests from suspicious sources or patterns matching known attack vectorsâit generates alerts and can automatically apply mitigation rules. This enables the system to distinguish between legitimate traffic spikes, such as those caused by a marketing campaign or viral content, and actual DDoS attacks designed to overwhelm resources.
Adaptive Protection operates as part of a broader Cloud Armor security policy that includes preconfigured web application firewall (WAF) rules targeting common threats like SQL injection (SQLi) and cross-site scripting (XSS). When Adaptive Protection is enabled, its ML-based detection complements these rules by identifying attack patterns that rules alone might miss. The system integrates with the Cloud Armor policy framework, meaning that when an anomaly is detected, the resulting mitigation actions respect any existing policy configurations administrators have defined. This includes the ability to allow, deny, or rate-limit traffic based on the severity of the detected threat.
To minimize false positivesâwhere legitimate traffic is incorrectly flagged as maliciousâadministrators must calibrate Adaptive Protection by analyzing the alerts it generates and adjusting threshold parameters accordingly. The focus area emphasizes reviewing ML-based anomaly detection alerts to distinguish between genuine attacks and legitimate traffic spikes, then fine-tuning sensitivity settings to match the application's expected traffic profile. Organizations should monitor alert patterns over time, particularly during known high-traffic periods, and adjust thresholds to ensure that normal usage is not inadvertently blocked while still maintaining effective protection against emerging threats.
Google Cloud Armor is a web application firewall (WAF) and DDoS protection service that integrates directly with Google Cloud's global load balancers. It inspects and filters incoming HTTP(S) traffic at the network edge before it reaches your backend services, protecting applications from attacks like SQL injection, cross-site scripting (XSS), and HTTP floods.
A Google Cloud Armor security policy is a set of rules that define how to handle incoming requests. You attach this policy to the backend service of a global external HTTP(S) Application Load Balancer (or the classic Application Load Balancer). Once attached, the load balancer sends all incoming traffic to the attached backend service through the Cloud Armor policy for evaluation. The policy rules are processed in order of priority; the first matching rule determines the action (allow, deny, or redirect). This integration means Cloud Armor acts as a security gatekeeper, sitting logically between the internet-facing load balancer and your application backends.
To analyze traffic patterns and the effectiveness of your security policies, you must enable logging on the backend services that have Cloud Armor policies attached. By default, the global external and classic Application Load Balancers do not enable logging, so you must manually turn it on. You should set the log sampling rate to 1 (100% of requests) when you are actively tuning and implementing Cloud Armor. After tuning is complete, you can keep full request logging enabled or reduce the sampling rate to a lower value for cost management. These logs are part of Cloud Load Balancing logs in Cloud Logging. However, logs specifically for Adaptive Protection, Cloud Armor's machine learning-based threat detection system, are exposed under the network_security_policy resource in the Google Cloud console, not under the load balancer logs.
For operational visibility, Cloud Armor provides a dedicated security dashboard within Cloud Monitoring. This dashboard gives you a clear, aggregated view of metrics related to your security policies, such as the volume of traffic allowed or denied. You can use this to monitor attack patterns and assess policy efficacy. Additionally, you can export Cloud Logging logs to your own platform for further analysis. If you are using Adaptive Protection, it is critical to establish an alerting and escalation path for any alerts it generates, as these indicate potential Layer 7 DDoS attacks or other high-frequency malicious activity that the system has detected.
For secure and efficient management, adhere to Identity and Access Management (IAM) best practices. The Compute Security Admin role is required to create and modify Cloud Armor security policies, while the Compute Network Admin role or the specific compute.backendServices.setSecurityPolicy permission is needed to attach a policy to a backend service. To simplify management, minimize the number of policies by designing reusable ones that can be attached to multiple backend services. For infrastructure as code and reliable rollbacks, use Terraform, which has full integration for Cloud Armor's generally available features. When using Google Kubernetes Engine (GKE), you must configure Cloud Armor through BackendConfig parameters on your ingress resources, avoiding manual configuration of the load balancer itself. You can also use the Kubernetes Gateway API with a GCPBackendPolicy to enable Cloud Armor; note that if you are enabling a regional Gateway, you must create a corresponding regional Cloud Armor backend security policy.
Google Cloud Armor security policies are collections of point-of-ingress rules that inspect, filter, and mitigate Layer 3 through Layer 7 traffic at the Google network edge before it reaches backend workloads. By enforcing security controls at the infrastructure perimeter, security policies prevent malicious requests and distributed denial-of-service (DDoS) attempts from consuming compute capacity or penetrating Virtual Private Cloud (VPC) networks. Security administrators build advanced rules by pairing match expressionsâsuch as source IP addresses, geographical codes, request headers, and preconfigured attack signaturesâwith concrete enforcement actions such as allow, deny, redirect, or throttle.
A Cloud Armor security policy consists of an ordered sequence of rules evaluated against incoming requests based on numerical priority. Rule priority is defined as an integer ranging from 0 to 2,147,483,646, where the lowest numeric value possesses the highest logical evaluation precedence. A reserved default rule sits at priority 2,147,483,647 (INT-MAX), ensuring that any traffic that does not match a higher-priority rule receives a predictable fallback action such as allow or deny. When a client sends a request to an external Application Load Balancer, Cloud Armor evaluates the request against rules starting from the lowest numerical priority and executes the action of the first matching rule. Once a standard rule matches, evaluation terminates and lower-priority rules are skipped; however, if a matching rule is set to preview mode, the system logs the theoretical match and continues evaluating subsequent rules until an active rule applies.
Cloud Armor custom rule expressions utilize an extension of the Common Expression Language (CEL) to construct complex Layer 7 filtering logic across multiple request attributes. A single custom rule can combine up to five subexpressions using logical operators (&&, ||, and !) to match granular request characteristics. These attributes include origin.ip for IP addresses or Classless Inter-Domain Routing (CIDR) ranges, origin.region_code for two-letter ISO 3166-1 alpha-2 country codes, and specific Layer 7 elements such as request.headers, request.path, and request.method. Architects combine these attributes to implement precise conditional logic, such as restricting access to specific administrative endpoints while allowing trusted networks. Advanced evaluations can also perform regular expression matching with request.path.matches(), search for cookie data inside request headers, decode Base64 strings, or inspect TLS client identifiers using TLS_JA3_FINGERPRINT and TLS_JA4_FINGERPRINT keys.
Preconfigured WAF rules are curated, managed expression sets derived from the Open Web Application Security Project (OWASP) Core Rule Set (CRS 3.3.2) designed to defend against common application-layer exploits. Instead of manually writing individual signatures for vulnerabilities, an administrator invokes prebuilt rule sets using the evaluatePreconfiguredWaf() expression. These preconfigured rule sets protect applications against high-risk categories in the OWASP Top 10, including SQL injection (SQLi), cross-site scripting (XSS), local file inclusion (LFI), remote file inclusion (RFI), and remote code execution (RCE). Preconfigured rules inspect up to the first 8 KB of a request body by default, and individual signatures within a set can be disabled to tune out false positives. Organizations can also leverage Google Threat Intelligence by invoking the evaluateThreatIntelligence('iplist-known-malicious-ips') function in their rule expressions to block recognized malicious IPs.
Advanced security policies provide proactive mitigation mechanisms beyond simple allow and deny decisions, including rate limiting, bot defense, and non-disruptive testing. Rate limiting rules enforce maximum traffic thresholds by keying on parameters such as source IP address, HTTP headers, cookies, or URL paths. Administrators select between a throttle action, which allows traffic up to a threshold count within an interval and denies or redirects excess requests, or a rate_based_ban action, which temporarily blocks all subsequent traffic from an offending client for a specified ban duration once a limit is exceeded. Bot management integrates Google reCAPTCHA Enterprise into Cloud Armor security rules to distinguish legitimate human users from automated scrapers or bots, redirecting suspicious requests to a reCAPTCHA challenge page or evaluating token scores at the network edge. To validate new rate limits, bot workflows, or WAF expressions safely, administrators enable preview mode on individual rules, which sends detailed match telemetry to Cloud Logging and Cloud Monitoring without disrupting live user traffic.
StudyCerts
StudyCertsthrottle, which allows traffic up to a threshold count within an interval, and rate_based_ban, which temporarily blocks an offending client for a set duration after exceeding the limit.Review the machine learning-based anomaly detection alerts that Adaptive Protection generates and analyze patterns such as request frequency, source distribution, and request characteristics. Legitimate traffic spikes from marketing campaigns or viral content typically show diverse, geographically distributed sources with consistent request patterns, whereas DDoS attacks often show concentrated request origins, repetitive payloads, or unusual header attributes.
A backend security policy attaches to the backend service of an Application Load Balancer and filters traffic after it reaches the load balancer but before it reaches the backend instances. An edge security policy attaches to a caching service like Cloud CDN and filters traffic at the edge cache location, before the request reaches the load balancer, which means it operates at an earlier stage of the request flow.
Enable preview mode on a new or modified rule when you want to test its behavior without disrupting live user traffic. Preview mode logs every theoretical match to Cloud Logging and Cloud Monitoring, allowing you to assess the rule's impact and tune false positives before promoting the rule to an active enforcement mode.
In GKE, you must configure Cloud Armor through BackendConfig parameters defined on your ingress resources rather than by manually attaching policies to the load balancer. For regional Kubernetes Gateways, you use a GCPBackendPolicy resource and must create a corresponding regional Cloud Armor backend security policy.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills