Professional Cloud Network Engineer
Cloud Armor provides two main types of security policies for protecting services behind a load balancer: edge security policies and backend security policies. These policies work with Cloud CDN and load balancers to filter malicious traffic. The key difference is when in the request flow they are applied.
Edge security policies are the first line of defense for services using Cloud CDN. They are attached to the backend service of a global external Application Load Balancer and filter incoming requests before the system checks if the content is in the CDN cache. If a request is blocked by an edge policy, it never reaches the cache or the origin server. This protects cache resources and reduces load on backends.
Backend security policies apply only to requests that are sent to the backend service itself, including dynamic content requests and cache misses. When both edge and backend policies are attached to the same service, the backend policy only evaluates the cache-miss traffic that first passed the edge policy. This creates a layered defense: edge policies stop bulk threats early, while backend policies apply more granular security to the dynamic traffic that actually reaches your origin servers.
Cloud Armor offers three policy types, each designed for a specific point in your architecture. Backend security policies (type CLOUD_ARMOR) attach directly to backend services behind Application Load Balancers and external proxy Network Load Balancers. Edge security policies (type CLOUD_ARMOR_EDGE) attach to backend services or buckets enabled with Cloud CDN or Media CDN; they filter traffic at the outermost Google network edge, before cache lookups or Identity-Aware Proxy (IAP) authentication. Network edge security policies (type CLOUD_ARMOR_NETWORK) work with advanced DDoS protection for resources like external passthrough Network Load Balancers and VMs with public IPs.
A single backend service can have up to two policies attached simultaneously: one edge policy and one backend policy. For a CDN-enabled service, the edge policy evaluates all incoming requests first. Only the cache-miss traffic that passes the edge policy is then evaluated by the backend policy. A security policy cannot be deleted while it is still attached to any backend service or target.
Rules within a Cloud Armor policy are evaluated in order based on a numerical priority, where lower numbers are checked first. Every policy has a mandatory default rule with the reserved highest priority number (INT-MAX). This default rule acts as a catch-all for any request that doesn't match your higher-priority rules. You configure the default rule to either allow or deny traffic, defining your security model.
Preview mode lets you safely test new security rules against live production traffic without actually blocking any requests. When a request matches a preview rule, Cloud Armor logs the match but does not enforce the rule's action. Instead, it continues checking lower-priority rules until it finds an active, non-preview rule to enforce.
To monitor Cloud Armor, you use Cloud Logging for detailed request records and Cloud Monitoring for aggregated metrics. Request logging is not turned on by default; you must enable it for each backend service you want to monitor.
The gateway is your network's entry point, and its design dictates how security is layered. A common, simple pattern uses a single Google Cloud-managed load balancer as the gateway. In this flow, client traffic goes to the load balancer, which applies Cloud Armor security policies. The load balancer then forwards the allowed traffic directly to your backend services.
For more advanced needs, a two-level gateway architecture provides deeper control. Here, traffic first goes to a managed load balancer (first-level gateway) for initial Cloud Armor policy enforcement. It then forwards traffic to a second-level gateway, which is a custom Cloud Service Mesh-configured edge proxy running on your own VMs or GKE. This proxy can enforce more complex policies that the managed load balancer doesn't support, like advanced traffic routing based on HTTP headers.
Your choice of load balancer as the gateway depends on where your clients are. For public internet clients, you use an external Application Load Balancer. For clients inside your Virtual Private Cloud (VPC) or connected private networks, you use an internal Application Load Balancer.
When using Cloud Armor with serverless backends like Cloud Run, App Engine, or Cloud Functions, you must prevent users from bypassing the load balancer. To close this security gap, you must disable the default URL for your Cloud Run service or configure the service's ingress setting to internal-and-gclb.
Google Cloud Armor is a web application firewall (WAF) and distributed denial-of-service (DDoS) mitigation service that defends web applications and APIs from Layer 7 threats like SQL injection (SQLi), cross-site scripting (XSS), and remote file inclusion (RFI). The service uses preconfigured rule sets derived from the OWASP ModSecurity Core Rule Set (CRS), allowing administrators to apply built-in detection signatures against every incoming HTTP(S) request.
The request path follows a strict order across Google Cloud's network boundary. The client sends an HTTP(S) request to the external Application Load Balancer. Google Cloud Armor inspects the request at the edge, evaluating all configured security policy rules in priority order. If the request violates any policy rule, Cloud Armor drops or rejects the request immediately at the edge and returns an error status code to the client. Only when a request passes all security policy rules does the load balancer forward traffic to backend services.
Preconfigured WAF rules are added to security policies using Cloud Armor's custom rules language. These rules target common OWASP Top 10 vulnerabilities, including SQLi, XSS, and RFI. Each preconfigured rule set includes a rule ID and a sensitivity level that governs how aggressively the signatures match incoming traffic. For example, using the sqli-v33-stable rule set at sensitivity level 2 ensures protection against complex JSON-based SQL injection bypasses.
Preconfigured WAF rules operate with specific technical boundaries. Rule updates and changes take several minutes to propagate globally. For requests containing an HTTP request body, Cloud Armor evaluates preconfigured rules against only the first 8 KB of the body content. When a request field exclusion is configured on a preconfigured WAF rule, the rule action cannot be set to allow, as matched exclusion patterns are automatically allowed past that specific rule.
Web Application and API Protection (WAAP) unites Google Cloud Armor, reCAPTCHA Enterprise, and Apigee into a layered defense architecture. In a WAAP deployment, incoming HTTP(S) traffic first hits Google Cloud Armor for DDoS protection and OWASP Core Rule Set inspection. Once cleared, requests pass to reCAPTCHA to assess risk scores and differentiate between legitimate human users and automated bots. Finally, validated API traffic routes through Apigee to verify API keys and access tokens before reaching backend microservices.
Common Expression Language (CEL) is the evaluation language used in Google Cloud Armor to build custom security rules based on Layer 7 HTTP(S) attributes. CEL rules allow administrators to inspect origin IP addresses, HTTP request headers, cookies, query parameters, and URI paths at the edge of the Google network.
CEL expressions evaluate boolean logic against Layer 7 traffic fields to decide whether an assigned security action triggers. Operators and standard functions check conditions such as IP subnets using inIpRange(origin.ip, '192.0.2.1/24') or confirm header presence with has(request.headers['header-name']). When a CEL expression evaluates to true, Cloud Armor executes the configured rule action on that request.
Administrators can link custom request attributes with preconfigured WAF rules in a single CEL expression using logical operators like && and ||. Functions such as evaluatePreconfiguredWaf('xss-stable') invoke OWASP CRS signatures across headers, URLs, and request bodies. Preconfigured WAF expressions inside CEL support sensitivity levels from 1 to 4, which correspond to OWASP CRS paranoia levels. Lower sensitivity levels evaluate high-confidence detection signatures to prevent false positives, while higher sensitivity levels inspect complex attack obfuscation techniques at a higher risk of catching legitimate traffic.
Tuning WAF signatures in Cloud Armor is the operational process of modifying preconfigured rules to block real web attacks while permitting valid application traffic. Administrators adjust rule set sensitivity, implement granular field exclusions, and evaluate rule behavior in preview mode before active enforcement.
The sensitivity setting controls matching aggressiveness, where lower sensitivity levels apply only high-confidence signatures to reduce false alarms. Sensitivity adjustments apply across the entire rule set rather than individual signatures.
Signature exclusions allow administrators to bypass WAF inspection for specific, safe portions of an HTTP request that would otherwise trigger a false positive. Exclusions target request components including headers, cookies, query parameters, or URIs. Rules with exclusions cannot use the allow action because excluded matching fields are automatically permitted through that rule.
Before enforcing rules in a live production environment, administrators can run Cloud Armor rules in preview mode to verify behavior using Cloud Logging. In preview mode, Cloud Armor evaluates incoming traffic and logs matching requests without executing the blocking or redirecting action. Once validated, administrators transition the rule from preview mode to enforced.
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 traffic looks like for a specific application, then using that model to detect anomalies that indicate malicious activity.
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, it generates alerts and can automatically apply mitigation rules.
Adaptive Protection operates as part of a broader Cloud Armor security policy that includes preconfigured WAF rules. 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 mitigation actions respect any existing policy configurations.
To minimize false positives, administrators must calibrate Adaptive Protection by analyzing the alerts it generates and adjusting threshold parameters accordingly. 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.
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).
To analyze traffic patterns, 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 actively tuning Cloud Armor. Logs specifically for Adaptive Protection are exposed under the network_security_policy resource in the Google Cloud console.
For operational visibility, Cloud Armor provides a dedicated security dashboard within Cloud Monitoring. This dashboard gives you an aggregated view of metrics such as the volume of traffic allowed or denied. If you are using Adaptive Protection, it is critical to establish an alerting and escalation path for any alerts it generates.
For secure management, the Compute Security Admin role is required to create and modify Cloud Armor security policies, while the Compute Network Admin role is needed to attach a policy to a backend service. When using Google Kubernetes Engine (GKE), you must configure Cloud Armor through BackendConfig parameters on your ingress resources. You can also use the Kubernetes Gateway API with a GCPBackendPolicy to enable Cloud Armor.
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.
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, origin.region_code for country codes, and specific Layer 7 elements such as request.headers, request.path, and request.method.
Preconfigured WAF rules are curated, managed expression sets derived from the OWASP Core Rule Set (CRS 3.3.2). An administrator invokes prebuilt rule sets using the evaluatePreconfiguredWaf() expression. These rule sets protect against 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.
Advanced security policies provide proactive mitigation mechanisms beyond simple allow and deny decisions. 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 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. To validate new rules safely, administrators enable preview mode on individual rules.
Rate limiting in Google 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.
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.
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.
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 geographic region codes (origin.region_code) or normalized URLs.
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 global external Application Load Balancers, classic Application Load Balancers, regional external and internal Application Load Balancers, and global external proxy Network Load Balancers (TCP/SSL).
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.
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. These metrics are exported in one-minute batches and stored for six 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, 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.
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.
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.
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. 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.
Bot management in Google Cloud Armor integrates reCAPTCHA Enterprise into security policy rules to distinguish legitimate human users from automated bots and scrapers. When a request is suspicious, Cloud Armor can redirect the client to a reCAPTCHA challenge page or evaluate a reCAPTCHA token at the network edge. Automated bots typically fail to solve the challenge, while human users can prove their identity and continue to the application.
Bot management rules are configured as part of a Cloud Armor security policy, often combined with rate limiting or WAF rules. For example, a rule can be set to redirect traffic to GOOGLE_RECAPTCHA when certain conditions are met, such as a high request rate from a single IP. This allows administrators to protect login endpoints, APIs, and other sensitive resources from credential stuffing and scraping attacks without blocking legitimate users.
Google Threat Intelligence provides a curated list of known malicious IP addresses that Cloud Armor can use to block traffic from recognized threat actors. Administrators apply this intelligence by invoking the evaluateThreatIntelligence('iplist-known-malicious-ips') function inside a custom CEL rule expression. When a request originates from an IP address on the threat intelligence list, Cloud Armor can deny or redirect that request at the edge.
This feature is typically combined with other Cloud Armor rules, such as preconfigured WAF rules and rate limiting, to create a layered defense. The threat intelligence list is updated regularly by Google, ensuring protection against emerging threats without requiring manual signature updates.
StudyCerts
StudyCertsCLOUD_ARMOR), edge security policies (type CLOUD_ARMOR_EDGE), and network edge security policies (type CLOUD_ARMOR_NETWORK), each attaching to different load balancer resources.An edge security policy filters traffic before the Cloud CDN cache is checked, blocking malicious requests at the outermost Google network edge. A backend security policy filters traffic only after a cache miss or for dynamic requests, applying to traffic that reaches the origin server. For a CDN-enabled service, the edge policy is evaluated first for all incoming requests.
Preview mode allows a new WAF rule to log requests it would match without actually blocking them. This lets administrators review the logs to see if the rule would accidentally block legitimate user traffic (false positives). They can then adjust sensitivity or add exclusions before turning on active enforcement, preventing service disruption.
Use a rate-based ban when you want to temporarily block a client entirely after it exceeds a burst threshold, rather than just slowing down its requests. A throttle action allows traffic up to a limit and denies excess requests, but the client can keep trying. A rate-based ban places the client into a banned state for a fixed duration (60 to 3600 seconds), dropping all subsequent requests until the timer expires.
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.
Prepare and test your skills
Prepare and test your skills