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. Understanding this distinction is essential for protecting cached content and backend servers effectively.
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. You use edge policies to block traffic at the earliest point, such as requests from unwanted geographic regions or specific IP addresses.
Backend security policies apply only to requests that are sent to the backend service itself. This includes dynamic content requests and cache misses—requests that the CDN cannot fulfill from its cache. 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.
To configure edge-tier filtering, you create a Cloud Armor security policy with rules and attach it to the backend service of your load balancer. Rules can be based on IP lists, geographic location, or pre-configured Web Application Firewall (WAF) rules that detect common attacks like SQL injection. For Cloud Storage backend buckets serving static content, edge policies can filter requests based on geography or IP before any cache check occurs. This setup ensures malicious requests are rejected at the Google network edge, protecting your origin and preventing unwanted data from polluting the CDN cache.
Cloud Armor edge security policies let you enforce access controls based on geography or IP address to block malicious traffic before cache evaluation. You can allow or block traffic from specific countries, which is useful for licensing compliance or blocking regions with high attack rates. You can also create lists to allow or block specific IP addresses or ranges. These controls, combined with WAF rules, provide a defense-in-depth strategy for CDN-enabled workloads, stopping unwanted traffic as soon as it arrives.
When using Cloud Armor with serverless backends like Cloud Run, App Engine, or Cloud Functions, you must prevent users from bypassing the load balancer. Serverless applications have a default public URL. If users access this URL directly, they circumvent the load balancer and its attached Cloud Armor policies. To close this security gap, you must disable the default URL for your Cloud Run service. Alternatively, you can configure the service's ingress setting to internal-and-gclb. This setting allows traffic only from internal sources and from the external IP address of your load balancer, blocking all direct public access to the default URL.
Google Cloud Armor security policies attach to specific load balancer resources to filter traffic. Managing these attachments, configuring how rules are evaluated, and using tools to test rules are critical for effective security operations without disrupting production services.
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. You can leave gaps between priority numbers (like 100, 110, 120) to make it easy to insert new rules later without reordering everything. 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. An allow default creates a denylist model (only blocked requests are specified). A deny default creates a zero-trust allowlist model (only explicitly allowed requests pass). For HTTP load balancers, a deny action can return a custom error like "403 Forbidden." For TCP-based proxy load balancers, a deny action simply resets the client connection.
Preview mode lets you safely test new security rules against live production traffic without actually blocking any requests. You can enable preview mode for individual rules or for an entire policy. When a request matches a preview rule, Cloud Armor logs the match but does not enforce the rule's action (like deny). Instead, it continues checking lower-priority rules until it finds an active, non-preview rule to enforce.
This is especially useful for testing complex preconfigured WAF rules that might accidentally block legitimate traffic (false positives). By reviewing the preview logs, you can tune the rules, perhaps by excluding certain non-malicious patterns, before turning off preview mode and enforcing the rules.
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 logs will contain separate JSON structures detailing the outcome of both edge and backend policy evaluations, as well as any matches from rules in preview mode.
Cloud Monitoring provides metrics like the rate of allowed or denied requests per policy. For network edge policies, it exports packet-level counts. You can build custom dashboards and set up alerts based on these metrics to be notified of traffic spikes or unusually high denial rates.
Backend security policies are rules attached to load balancers to protect your applications from Layer 7 (application-layer) attacks. You configure these policies in Cloud Armor, which integrates with Google Cloud load balancers to inspect and filter traffic before it reaches your servers.
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. Finally, the proxy sends traffic to your application services.
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. This load balancer provides a global IP and fully supports Cloud Armor backend security policies for threat mitigation. For clients inside your Virtual Private Cloud (VPC) or connected private networks, you use an internal Application Load Balancer. While it handles private traffic and TLS, Cloud Armor's advanced threat mitigation features are primarily designed for and attached to external-facing load balancers.
A two-level gateway enables sophisticated, staged threat mitigation. The first security layer is the Cloud Armor policy on your external Application Load Balancer. It can use preconfigured WAF rulesets and custom rules to block common exploits. Traffic that passes this check is sent to your custom edge proxy (the second-level gateway). This proxy, managed via Cloud Service Mesh, can enforce advanced policies like complex rate limiting based on application logic or specialized bot management. This architecture also allows for separation of duties: network teams can manage the perimeter security on the cloud load balancer, while application teams manage the finer-grained security within their service mesh.
StudyCerts
StudyCertsinternal-and-gclb to force all traffic through the load balancer and its Cloud Armor policies.An edge security policy is evaluated before the Cloud CDN cache is checked, blocking malicious traffic at the very edge of Google's network. A backend security policy is evaluated only for traffic that is sent to the origin server, such as dynamic requests or cache misses. For a CDN-enabled service, the edge policy acts as a first filter for all traffic.
Use a two-level gateway architecture when you need to enforce advanced security or traffic management policies that the managed Google Cloud load balancer does not support. This includes complex rules based on regular expressions in HTTP headers or sophisticated application-layer rate limiting. The first level (the cloud load balancer) handles basic security, while the second level (your custom proxy) handles these advanced, application-specific policies.
Preview mode allows a new WAF rule to log requests it would match without actually blocking them. This lets you review the logs to see if the rule would accidentally block legitimate user traffic (create false positives). You can then adjust or tune the rule based on this real-world data before enabling enforcement, preventing service disruption.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills