Why architecture matters here
Edge filtering is architectural because the economics of an attack are decided by where you meet it. A volumetric DDoS is an attempt to exhaust a finite resource — bandwidth, connections, CPU — by overwhelming it with volume. If you try to absorb that flood at your own instances, you have already lost: the traffic traversed the network to reach you, so it consumed that path, and your machines must spend real capacity distinguishing bad from good. Meeting the flood at Google's edge inverts the economics. The edge has vastly more aggregate capacity than any attacker can marshal, it is distributed globally via anycast so an attack is spread across many points of presence rather than concentrated on one, and it rejects bad traffic before it ever enters the path to your backends. You cannot replicate that capacity or that topology yourself; renting it is the entire point.
The second architectural reason is that the load balancer is the natural, unavoidable choke point, and a choke point is exactly where a policy belongs. All external traffic to your application already flows through the external HTTP(S) load balancer; attaching the security policy there means every request is inspected in one place, with one consistent rule set, before any of it fans out to GKE pods, managed instance groups, or serverless backends. This is the same logic that makes an API gateway the right home for cross-cutting concerns: a shared enforcement point gives you one place to define who may reach the app, one place to update when a new attack appears, and a guarantee that no backend is reachable except through the policy. Scattering IP allow-lists and WAF logic across individual services would be inconsistent, incomplete, and impossible to reason about.
But concentrating enforcement at the edge concentrates the blast radius of a mistake, and that is the constraint the operational model answers to. A rule is evaluated against every request, so a rule that is too broad, mis-ordered, or falsely matching does not degrade one feature — it can deny your entire user base at the front door. A WAF rule set tuned for maximum coverage will inevitably flag some legitimate requests that happen to resemble an attack (a customer whose form input contains a SQL keyword, an API payload that looks like a script). The power to block everything bad at one point is inseparable from the power to block everything, full stop, and that is why Cloud Armor's operational discipline centers on preview mode — evaluating rules and logging what they would do without actually enforcing — so you measure a rule's real effect on live traffic before it can hurt anyone.
There is a boundary condition that the architecture makes it easy to forget, and forgetting it quietly voids the whole protection: Cloud Armor only guards traffic that actually flows through the load balancer it is attached to. The edge is a shield in front of a specific front door, not a force field around your project. If a backend is reachable by another path — a VM with a public IP, an internal load balancer exposed by a misconfiguration, a service that clients can hit directly — then that path has no policy on it, and an attacker who finds it walks straight past every WAF rule and rate limit you so carefully tuned. The security value of an edge policy is exactly as strong as your guarantee that the guarded load balancer is the only ingress. This is why edge protection is a network-architecture decision as much as a rules decision: the rules are worthless if the perimeter they sit on has a hole, so locking down every alternative path to the backends is as much a part of deploying Cloud Armor as writing the policy itself.
The architecture: every piece explained
Top row: the request path from internet to backend. Internet traffic — a mix of real users and attackers — arrives at Google's edge, a global anycast frontend that terminates connections close to the client. The security policy, an ordered list of rules, is evaluated here in association with the external HTTP(S) load balancer the policy is attached to. The policy is the attach point: it binds to a backend service, so every request bound for that service is filtered before the load balancer forwards it. Placing evaluation at the edge/load-balancer layer means rejection happens before traffic consumes anything downstream.
Middle row: what the enforcement actually does. L3/L4 DDoS — volumetric network and transport floods — is absorbed by the edge's always-on capacity, never reaching the policy engine or the backends; this protection is inherent to sitting behind Google's frontend. On top of that, the policy applies WAF rules: preconfigured rule sets encoding common attack signatures (SQL injection, cross-site scripting, and the rest of the OWASP Top 10) plus any custom expression rules you write. Rate limiting throttles clients that exceed a configured request rate — per source IP, per key, or per other attribute — to blunt credential stuffing, scraping, and application-layer floods that individual requests look innocent but aggregate to abuse. Each rule, when it matches, applies its action: allow, deny with a status code, redirect (e.g. to a challenge), or throttle. Rules are evaluated in priority order and the first match wins, which is why rule ordering is a first-class design concern.
Bottom rows: the intelligence layer and the destination. Adaptive Protection is Cloud Armor's ML-driven defense against application-layer (L7) DDoS: it learns your normal traffic pattern, detects anomalous surges that look like an attack, and generates a suggested rule — often a signature that isolates the attack traffic — that you can deploy to block it, shrinking response time during a live incident. Only traffic that survives the policy reaches the backends — GKE clusters, managed instance groups, Cloud Run, or other serverless targets — which therefore see only filtered, rate-limited, WAF-cleared requests. The ops strip is the discipline that makes this safe: roll out rules in preview mode first, tune WAF sensitivity to kill false positives, order rules carefully so specific allows precede broad denies, and monitor the allowed-versus-blocked counts to see what the policy is actually doing.
End-to-end flow
Walk a normal request and an attack through the same policy. A legitimate user in Germany loads the app. Their request hits the nearest Google edge point of presence, where the L3/L4 DDoS protection passes it (it is a single ordinary request, not a flood). The security policy evaluates its ordered rules: an early rule allows traffic from the app's served regions, so the request matches allow and proceeds; the WAF rules find no injection signature in a normal page load; the rate limiter sees this client is well under threshold. The request reaches a backend and is served. The user experienced a normal, fast page load, and the policy did its work in the edge in the time it takes to evaluate a handful of rules.
Now a volumetric flood: a botnet directs millions of packets per second at the app's IP, trying to saturate its bandwidth. This never becomes the application's problem. The flood is L3/L4, and Google's edge absorbs it across its global anycast capacity — the attack is spread over many points of presence, each of which has far more headroom than the attacker's share, and the malicious packets are dropped at the edge. The backends see no unusual load; the load balancer forwards only the legitimate traffic that passed. From the application team's perspective, a massive DDoS registered as a blip in edge metrics and nothing more, because the absorption happened at a layer and a scale they never had to touch.
Now an application-layer attack. An attacker sends a stream of requests carrying SQL-injection payloads in query parameters, trying to find an exploitable endpoint. Each request is individually well-formed and would pass an L3/L4 filter, but the WAF rule set matches the injection signatures and denies them with a 403, logging each. Simultaneously the attacker's IP is making requests far faster than any human, so the rate-limiting rule throttles it, redirecting further requests to a challenge. The backends never see the injection attempts; the application code is never even given the chance to mishandle a malicious payload, because the malicious shape was recognized and rejected at the edge.
Finally, the operational scenario that separates a safe rollout from a self-inflicted outage. The team wants to add a strict new WAF rule. If they enforced it directly and it had a false positive — say it flags a legitimate API payload whose JSON happens to contain a string that looks like a script tag — they would start returning 403s to real customers the instant it deployed, at the front door, for everyone the rule falsely matched. Instead they deploy it in preview mode: the rule evaluates and logs what it would block, but takes no action. They watch the logs over real traffic, discover the rule would have blocked a stream of legitimate API calls, tune the expression to exclude that pattern, and only then flip it to enforcing. The exact same discipline applies to rule ordering: a broad geo-deny placed above a specific allow-list rule would deny partners in a blocked region before the allow rule ever ran, so they order specific allows above broad denies and verify with preview. The power to block everything at one point demands measuring before enforcing — preview mode is how you spend that power without shooting yourself in the foot.