Before diving into rules and policies, we need a clear picture of the problems this service addresses and the place it holds in the architecture.

The threats on the internet

Any application reachable from the internet is constantly probed. Some attacks aim to knock the application offline by overwhelming it with traffic, known as distributed denial of service, or DDoS. Others try to trick the application into misbehaving by sending specially crafted input, such as attempts to inject database commands or hostile scripts. Others use automated programs, called bots, to scrape content, guess passwords, or abuse features at scale. A few simply come from places or networks you never intended to serve.

Defending against all of this inside the application itself is difficult and wasteful. Your servers would spend precious capacity inspecting and rejecting hostile traffic, and every team would have to reinvent the same protections. It is far better to stop bad traffic at the edge, before it reaches the servers.

What the service gives you

Cloud Armor is Google Cloud’s managed web application firewall, often shortened to WAF, together with DDoS protection. You attach security policies to your load balancer backends. Each policy is a set of rules that decide whether to allow, deny, throttle, or challenge each request. The rules are evaluated at the edge of Google’s global network, so malicious traffic is stopped close to where it enters, using the same infrastructure Google uses to protect its own services. You get preconfigured rules for common web attacks, rate limiting, bot management, geography and address filters, and machine-learning-based defenses, all without running any firewall hardware.

Every security product has its own words. These are the ones you will meet in nearly every Cloud Armor conversation.

How the words fit together

You create a security policy and fill it with rules. Each rule has a match condition, an action, and a priority. You attach the policy to a backend service of a load balancer. When a request arrives, Cloud Armor checks the rules from the lowest priority number upward. The first rule whose condition matches decides what happens. If nothing matches, a default rule at the end applies. Preview mode lets you try rules safely, and logs let you see what happened.

To use Cloud Armor well, you must understand where in the traffic path it acts and which load balancers it protects.

In the path of every request

Cloud Armor works together with Google Cloud load balancers. A request from a user travels over the internet and enters Google’s network at a point of presence near the user. For global external load balancers, the request meets the load balancing front end at that edge location, where security policies are evaluated. Only requests that pass the policy are forwarded to your backends, such as virtual machines, containers, serverless services, or storage buckets. Blocked requests never reach your servers, so they cost you no backend capacity.

flowchart LR
    U["Internet users and attackers"] --> E["Google edge"]
    E --> LB["Load balancer front end"]
    LB --> SP{"Cloud Armor security policy"}
    SP -->|"Allowed"| BE["Backend service"]
    SP -->|"Denied or throttled"| BL["Blocked response"]
    BE --> APP["Your application"]
        

Supported attachment points

Security policies attach to backend services of supported load balancers, including the external Application Load Balancers, the regional internal Application Load Balancer, and certain proxy network load balancers. Different features are available with different load balancer types, so check the current compatibility documentation when choosing. Network-level DDoS protections also exist for workloads that use external network load balancers, protocol forwarding, and virtual machines with public addresses.

Hybrid and multi-cloud reach

Because the policy sits on the load balancer, the backends behind it can be anywhere the load balancer can reach, including endpoints outside Google Cloud, in setups that use internet or hybrid network endpoint groups. This allows organizations to apply one consistent firewall layer across applications that are spread across several environments.

The heart of Cloud Armor is the policy. Learning how rules are matched and ordered is the single most valuable skill.

Anatomy of a rule

The default rule

Every policy has a default rule with the lowest possible precedence. It applies when no other rule matches. You decide whether the default is to allow traffic, which suits most public websites, or to deny traffic, which suits tightly controlled applications that should only be reachable by known sources. Choosing the default deliberately is one of the first design decisions.

A recommended rule ordering

A sensible structure is to arrange rules in broad groups. Explicit deny rules for unwanted address ranges, regions, or networks come first, because there is no reason to inspect traffic you already know you do not want. Next come narrowly trusted allow rules, for example for security scanners or trusted partner systems, used with great caution. Then come the security rules, such as the preconfigured WAF rules and custom rules that inspect content. After those, broader allow rules, for example for known networks or particular header values. Finally, the default rule decides everything left.

flowchart TD
    R["Incoming request"] --> A{"Explicit deny rules match?"}
    A -->|"Yes"| X["Deny"]
    A -->|"No"| B{"Trusted allow rules match?"}
    B -->|"Yes"| OK["Allow"]
    B -->|"No"| C{"Security rules like WAF match?"}
    C -->|"Yes"| X
    C -->|"No"| D{"Broader allow rules match?"}
    D -->|"Yes"| OK
    D -->|"No"| E["Default rule decides"]
        

Priority spacing

Leave gaps between priority numbers, for example by tens or hundreds, rather than numbering rules one, two, three. Later you will need to insert a rule between two existing ones, and without gaps you would have to renumber many rules and risk mistakes. Spacing is a tiny habit that saves painful rework.

Cloud Armor includes ready-made protections for common web attacks, plus a flexible language for your own rules.

Preconfigured WAF rules

Preconfigured WAF rules are collections of signatures for known attack patterns, assembled from open industry standards and aimed at the most common web vulnerabilities, including the well-known OWASP Top 10 list. They cover categories such as SQL injection, cross-site scripting, local and remote file inclusion, remote code execution attempts, protocol attacks, scanner detection, and session fixation. You turn them on by referencing them in a rule, instead of writing signatures yourself.

Sensitivity levels

Each preconfigured rule set can be applied at a chosen sensitivity level. A lower sensitivity catches only the most clear-cut attacks and produces fewer false alarms. A higher sensitivity includes more signatures, catching subtler attacks but also flagging more legitimate requests that merely look suspicious. The right level depends on how sensitive your application is and how much tuning time you have. Many teams start at a lower level, observe the results, and raise it as they learn.

Stable and canary rule sets

There are two flavors of the managed rule sets. The stable version changes rarely and predictably, which suits production. The canary version receives newer signatures earlier, which lets you test upcoming changes before they reach the stable set. A cautious approach is to run canary rules in preview mode alongside stable ones so you can see what would change before it affects real traffic.

flowchart LR
    NEW["New and updated signatures"] --> CAN["Canary rule set"]
    CAN -->|"Tested in preview"| STB["Stable rule set"]
    STB --> PROD["Production enforcement"]
    CAN -.->|"Logs only"| LOGS["Review what would change"]
        

Tuning to avoid false positives

Real web applications sometimes send data that happens to match attack signatures. A rich text editor may submit HTML, a developer portal may accept code snippets, and a search box may include symbols that resemble injection attempts. Rule tuning lets you disable individual noisy signatures, or exclude certain request parts, so that legitimate users are not blocked while the rest of the protection stays active.

JSON parsing

Modern applications often send data as JSON in request bodies. If body parsing for JSON is not enabled, the WAF rules may treat the body as a plain blob of text, producing noisy matches and false positives. Enabling JSON parsing lets the rules understand the structure of the data and reduces needless blocking, so it is usually worth enabling for applications that exchange JSON.

Custom rules language

Beyond the preconfigured sets, you can write your own match conditions using an expression language. You can combine conditions on source address, region, request path, headers, query parameters, and other attributes with logical operators. This is how you express business-specific rules, such as allowing an administrative path only from your corporate network, or denying requests that carry a certain unwanted header.

Not all abuse looks like an attack signature. Sometimes the problem is simply too many requests from one client.

Why rate limiting matters

Some harmful behavior consists of perfectly normal-looking requests sent in huge numbers: guessing passwords one after another, hammering a login page, scraping every product page, or flooding an expensive search feature. No single request looks malicious. The pattern is the problem. Rate limiting counts requests from a client over a time window and reacts when the count passes a threshold you set.

Throttle and ban

Choosing what to count

A rate limit must decide who counts as one client. Counting by source address is the simplest, but many legitimate users can share one address, such as an office or a mobile network, and attackers can change addresses. Other keys let you count by something more specific, such as the request path, a particular header or cookie value, the region, or the server name in the connection. Choosing a sensible key keeps legitimate shared-address users from being punished and makes evasion harder.

Setting thresholds well

Some threats are automated clients pretending to be people, and some attacks are so large and odd that fixed rules cannot anticipate them. Two features address these.

Bot management

Bots range from helpful, such as search engine crawlers, to harmful, such as scrapers, fraud tools, and account takeover scripts. Cloud Armor integrates with a reCAPTCHA product designed for protecting websites and applications, so that decisions about whether a visitor is a human or a bot can be made at the edge and used inside your rules. A rule can, for example, allow requests that carry a valid token showing the visitor passed a check, redirect suspicious visitors to a challenge, or deny those that look automated. Because this happens at the edge, bots are stopped before they consume backend capacity.

sequenceDiagram
    participant V as Visitor
    participant E as Edge with Cloud Armor
    participant R as Bot detection service
    participant B as Backend
    V->>E: Request without valid token
    E-->>V: Redirect to challenge
    V->>R: Complete challenge
    R-->>V: Issue token
    V->>E: Request with token
    E->>E: Verify token and evaluate rules
    E->>B: Forward legitimate request
    B-->>V: Response
        

Adaptive Protection

Adaptive Protection is a machine-learning feature that watches the normal pattern of traffic to your applications and learns what usual looks like. When it detects a sudden, unusual surge that looks like an application-layer DDoS attack, it raises an alert, describes the suspicious pattern, and suggests a rule you can deploy to block it. It can adapt to attacks that no pre-written signature would catch, because it compares traffic against your own baseline rather than a universal list.

Advanced network DDoS protection

For workloads that use external network load balancers, protocol forwarding, or virtual machines with public addresses, there is an additional protection for volumetric network and protocol attacks. It provides always-on detection and mitigation, with extra visibility into attacks. Google Cloud’s global infrastructure already absorbs a very large amount of attack traffic by default, and this feature adds more tailored defense and telemetry for the resources you choose to protect.

Besides inspecting content, Cloud Armor can decide who may reach you based on where they come from, and it can protect cached content before it is ever served.

Geography and network rules

You can allow or deny traffic based on the region the request appears to originate from, or on the autonomous system, which identifies the network operator that owns the source address. These controls are valuable for applications that serve a single country, for meeting legal restrictions, or for cutting off regions where you have no customers but plenty of abuse. Because address-to-location mapping is never perfect, geography rules should be treated as a coarse filter and not a precise one, and people using certain networks may appear to be elsewhere.

Named IP lists

Named IP lists are curated collections of address ranges maintained by third-party providers and made available for use in rules. For example, a list might represent the ranges of well-known content networks or other recognized sources. Using such a list lets you allow or deny large, changing sets of addresses with a single rule, without maintaining the ranges yourself.

Edge security policies for cached content

When content is served from the edge cache, such as through a content delivery network or from storage buckets, a request can be answered without ever reaching your backend. Edge security policies apply filtering and access control to that cached content, so that you can restrict who may fetch it, for example by blocking certain regions or addresses, before it is served. This matters because cached assets are often the largest volume of traffic and would otherwise bypass backend-focused rules.

flowchart LR
    U["User request"] --> ES{"Edge security policy"}
    ES -->|"Blocked"| BL["Rejected at the edge"]
    ES -->|"Allowed"| CACHE{"Content in cache?"}
    CACHE -->|"Yes"| SERVE["Served from cache"]
    CACHE -->|"No"| BP{"Backend security policy"}
    BP -->|"Allowed"| BE["Fetch from backend or bucket"]
    BP -->|"Denied"| BL
        

A firewall you cannot see into is a firewall you cannot trust. Cloud Armor provides the visibility you need, and the best teams use it constantly.

Request logs

Cloud Armor decisions appear in the load balancer’s request logs in Cloud Logging. Each log entry records which policy and rule applied, what the outcome was, and details of the request. For rules in preview mode, the logs show what would have happened. By searching these logs, you can answer questions such as which rule blocked a particular customer, which signatures fire most often, and where attacks are coming from.

Verbose logging for tuning

For WAF rules, a more detailed logging level can reveal exactly which signature matched and which part of the request triggered it. This is invaluable when tuning false positives, but it generates more log volume and may include more request data. It is meant for short tuning periods, not for permanent use in production.

Metrics and dashboards

Metrics about policy decisions flow into Cloud Monitoring, where you can build dashboards and alerts. You can also see suspicious traffic patterns surfaced in the central security dashboard of Google Cloud. A good dashboard shows allowed versus denied requests, the top rules by hits, the top sources, and any sudden changes.

The safe rollout loop

flowchart TD
    A["Write or change a rule"] --> B["Deploy in preview mode"]
    B --> C["Watch logs for would-be matches"]
    C --> D{"Any legitimate traffic affected?"}
    D -->|"Yes"| E["Tune the rule or exclusions"]
    E --> B
    D -->|"No"| F["Enable enforcement"]
    F --> G["Monitor dashboards and alerts"]
    G --> A
        

Cloud Armor attaches to load balancers, so using it with containers and serverless services means understanding how those services sit behind load balancers.

Containers on Kubernetes

For applications running on Google Kubernetes Engine and exposed through the platform’s ingress, a configuration resource can reference a Cloud Armor security policy so that the generated load balancer backend carries it. This keeps protection tied to the way the application is exposed, and lets platform teams manage policies centrally while application teams simply reference them.

Serverless backends

Serverless services can sit behind a global external Application Load Balancer through a special backend type, which allows Cloud Armor policies to protect them. This is useful because serverless services otherwise expose a direct address that bypasses load balancer protections. To make the protection effective, restrict the serverless service so it accepts traffic only through the load balancer, which prevents attackers from reaching it directly.

Policies as code

Security policies are configuration, and configuration belongs in version control. Define policies and rules with infrastructure-as-code tools so that every change is reviewed, tracked, tested in a non-production environment, and repeatable. This also helps when you run many applications that should share a common baseline, because the shared rules are defined once and applied consistently.

Cloud Armor is offered in tiers with different pricing models. Understanding them helps you match protection to risk and budget.

Standard and Enterprise tiers

The standard tier is pay-as-you-go. You are charged for the security policies and rules you create, and for the well-formed requests that are evaluated by those policies. It suits smaller workloads and teams that want to pay only for what they use. The enterprise tier is subscription based, with a predictable monthly price that includes DDoS and WAF services, curated rule sets, access to Adaptive Protection, and attack visibility telemetry. It suits organizations with large or critical applications that value predictable cost and the extra features. Tier names, features, and prices are updated over time, so always confirm on the official pages.

What drives cost

Advantages and trade-offs

Where Cloud Armor fits among defenses

Good patterns make Cloud Armor quiet and effective. Anti-patterns make it either useless or a source of outages.

Patterns worth adopting

Anti-patterns to avoid

A checklist of habits that experienced teams build into every Cloud Armor deployment, and the traps that catch newcomers.

Best practices

Common mistakes

A short pre-launch review

These illustrative scenarios, drawn from common industry patterns, show how the ideas combine in practice.

What these scenarios share

Each team combined several layers instead of relying on one control. Each tested rules in preview, tuned for false positives, protected the most sensitive paths specially, closed direct access to backends, and watched logs and dashboards. None treated the firewall as set and forget.

Short, direct answers to questions that come up again and again.

It protects applications reachable through supported load balancers from DDoS and web attacks, bots, and unwanted sources, and extends protection to certain network-level workloads and cached content through related features.

To the backend service of a supported load balancer. Edge security policies attach to cached-content backends such as CDN-enabled services and storage buckets.

In priority order, lowest number first. The first rule that matches decides the outcome. If none matches, the default rule applies.

A setting that lets a rule log what it would have done without enforcing it, so you can test rules against real traffic safely.

Use preview mode, start with a lower WAF sensitivity, enable JSON parsing where needed, tune noisy signatures individually, and monitor logs and traffic drops after enforcement.

Throttling limits a client to a permitted rate and rejects the excess. A rate-based ban blocks a client entirely for a set time after it exceeds a higher threshold.

It can, through integration with a reCAPTCHA product and through rate limiting and custom rules. Bot management is not perfect, so combine it with other controls on sensitive paths.

It learns your normal traffic with machine learning, detects unusual high-volume application-layer attacks, and suggests rules to block them. It is best for volumetric attacks.

Yes, when those services sit behind a supported load balancer through internet or hybrid backend types, so the policy is applied at the edge in front of them.

Use the load balancer logs in Cloud Logging, which record the policy, rule, and outcome for each request, and the monitoring dashboards for aggregate views.

A standard tier charges pay as you go for policies, rules, and evaluated requests. An enterprise tier is subscription based with added features. Confirm current details on the official pricing page.

If backends are reachable directly, yes. Restrict access so only the load balancer can reach them, and layer other controls, because signature-based rules cannot catch everything.

No. It is an important edge layer, but you still need secure code, patching, authentication, least privilege, and network and data protections.

Cloud Armor is Google Cloud’s managed web application firewall and DDoS defense, enforced at the edge of Google’s network in front of your load balancers. You build security policies from prioritized rules, where lower numbers are checked first and the first match wins, and a default rule catches everything else. Preconfigured WAF rules cover common web attacks and can be tuned by sensitivity and by disabling noisy signatures, while custom expressions handle your own logic. Rate limiting, with throttle and ban actions and a choice of counting keys, stops floods, scraping, and password guessing. Bot management through reCAPTCHA integration separates people from automation, and Adaptive Protection learns your traffic to catch unusual high-volume attacks. Geography filters, address lists, and edge security policies decide who may reach you and protect cached content. Logs, metrics, and preview mode let you test safely and keep watching, and policies are best kept as reviewed code. The standard tier is pay as you go, and the enterprise tier is a subscription with extra features. Success depends on layering defenses, ordering rules carefully, tuning to avoid false positives, closing every back door, and remembering that a firewall complements, and never replaces, secure software.