Before any rules or diagrams, let us get one clear picture of what this product is and what it is for.

Cloud Armor is a network security service on Google Cloud. It combines two protections in one product. The first is a web application firewall, usually shortened to WAF. A WAF reads web requests and blocks the ones that look like attacks, such as attempts to trick your database or to inject harmful scripts into your pages. The second is DDoS protection. DDoS stands for distributed denial of service, which means a flood of traffic from many machines at once, sent to overwhelm a site so real users cannot get in.

You control Cloud Armor through security policies. A policy is a list of rules, and each rule says “if a request looks like this, then do that”. You attach a policy to a service that sits behind a Google Cloud load balancer, and from that moment every request is checked against your rules before it is passed along.

What Cloud Armor can do

You cannot choose good defenses without knowing the attacks. This chapter explains the main ones in simple words.

Attack family 1: floods (DDoS)

A denial of service attack tries to make a service unusable by overloading it. When the traffic comes from thousands of hijacked computers at once, it is called a distributed denial of service. The hijacked machines form a botnet, a network of infected devices controlled remotely by an attacker, often without their owners knowing. DDoS attacks come in three main styles.

Attack family 2: exploits against your application

These attacks do not need huge numbers. They need only one weak spot.

• SQL injection: The attacker types database commands into a form field or web address. If your app is careless, the database obeys them and may reveal or delete data.
• Cross-site scripting (XSS): The attacker smuggles a harmful script into a page so that it runs in other visitors’ browsers and steals their sessions.
• Local and remote file inclusion: The attacker tricks the app into reading a file it should not, or loading code from the attacker’s site.
• Remote code execution: The attacker gets the server to run commands of their choosing. This is among the most dangerous outcomes.
• Scanners and probes: Automated tools that try thousands of common weak addresses and known flaws, looking for any unpatched system.

Attack family 3: abuse by bots

• Credential stuffing: Bots try lists of stolen usernames and passwords from other breaches on your login page.
• Scraping: Bots copy all your prices, articles, or listings, often to resell or undercut you.
• Inventory hoarding: Bots add scarce items to carts or buy them instantly, shutting out real customers.
• Fake account creation: Bots sign up in bulk to abuse free trials or spread spam.

The OWASP Top 10

OWASP, the Open Worldwide Application Security Project, is a respected nonprofit community that publishes a famous list of the most common serious web application risks, known as the OWASP Top 10. It includes problems such as injection, broken access control, and security misconfiguration. Many WAF products, Cloud Armor included, base part of their protection on a set of rules maintained by this community. A WAF can block many attempts to use these weaknesses, but it cannot fix flaws such as a login system that forgets to check permissions. Those must be fixed in the code.

Understanding the story explains why Cloud Armor lives where it does, at the edge of Google’s network.

Why the edge matters

Google runs a huge global network with many points of presence close to users all over the world. Traffic to a Google Cloud global load balancer enters this network at the point nearest the sender, and Cloud Armor rules are applied right there. Bad requests are dropped at the edge, thousands of kilometers from your servers, so they never consume your bandwidth, your CPU, or your money. Google has publicly reported that this approach has absorbed record-setting attacks, including a flood of tens of millions of requests per second reported in 2022, without the protected customer going offline.

Defense in depth

Security experts use the phrase defense in depth, meaning several independent layers of protection so that a failure in one does not cause a total breach. A castle has a moat, a wall, a gate, and guards inside. For a cloud application, the layers include secure code, patched software, careful access permissions, network firewalls, encryption, monitoring, and an edge WAF such as Cloud Armor. Cloud Armor is the first layer an attacker meets, and it is built to thin out most of the dangerous traffic before it reaches the others.

A handful of simple ideas explain almost everything in Cloud Armor.

The actions in detail

How priority works

The number is easy to mix up, so say it slowly: the smaller the number, the earlier the rule is checked. Rule 100 is looked at before rule 200. As soon as one rule matches, Cloud Armor applies its action and stops looking at the rest. So specific exceptions should have smaller numbers than broad blocks. A common pattern is to put “always allow my office” first, then “block bad addresses”, then “apply WAF rules”, then “rate limits”, and leave the default rule last.

Preview mode

Any rule can be set to preview. In preview mode the rule still checks every request and writes what it would have done into the logs, but it does not actually block anything. This is a priceless safety feature: you can test a new rule against real traffic and see which real customers it would have hurt before it ever touches them.

Now let us zoom out and see where Cloud Armor sits among the other parts of a Google Cloud application.

Cloud Armor is not a box you place in your network. It is a feature that is applied by Google’s load balancing infrastructure. Requests from users reach Google’s edge, go through the load balancer’s front end, are checked by the attached security policy, and only then travel on to your backends. The backends can be virtual machines, containers on Google Kubernetes Engine, serverless services such as Cloud Run, storage buckets, or even servers outside Google Cloud.

flowchart LR
    U["Users, Bots and Attackers"] --> EDGE["Google Edge Network"]
    EDGE --> LB["Global External Load Balancer"]
    LB --> CA["Cloud Armor Security Policy"]
    CA -->|"Allowed"| BS["Backend Service"]
    CA -->|"Denied"| BLK["Blocked at the Edge"]
    BS --> VM["VM Instance Groups"]
    BS --> GKE["GKE Containers"]
    BS --> RUN["Cloud Run Services"]
    CA --> LOG["Cloud Logging and Monitoring"]
    CA --> TI["Threat Intelligence and Adaptive Protection"]
    

The components, one at a time

What Cloud Armor protects

Over time Cloud Armor has been extended beyond the classic web setup. Depending on the type of policy, it can protect traffic arriving at external application load balancers, which handle web traffic, at external proxy network load balancers, and at passthrough network load balancers and virtual machines that have public addresses. The next chapters explain the different policy types and which ones fit which situation.

Let us follow one web request from a visitor’s browser all the way to your server, and see where each decision is made.

sequenceDiagram
    participant C as Client
    participant E as Google Edge
    participant A as Cloud Armor Policy
    participant L as Load Balancer
    participant B as Your Backend
    C->>E: Opens secure connection
    E->>A: Request details for evaluation
    A->>A: Check rules in priority order
    alt Request is allowed
        A-->>L: Allow
        L->>B: Forward request
        B-->>C: Response
    else Request is denied
        A-->>C: Error response such as 403
    end
    A->>A: Write decision to logs
    

The journey, step by step

What Cloud Armor can see in a request

• Source address: where the request appears to come from, and the approximate country it maps to.
• Method and path: for example, a POST to the login address.
• Query string: the part of the web address after the question mark.
• Headers: labelled extra details, such as the browser name, language, and cookies.
• Body: Cloud Armor can look at only an initial part of the request body, a few kilobytes in documented limits. Check the current limit, because an attacker may try to hide a harmful payload beyond the part that is inspected.

Encrypted traffic

Most web traffic today is encrypted. Because the secure connection ends at Google’s load balancer, which holds your certificate, the load balancer can read the request in plain form for evaluation. That is why Cloud Armor works with encrypted web traffic without extra effort, and why it must be tied to the load balancer, not to the backend machines.

Cloud Armor offers more than one kind of policy. Choosing the right kind depends on what sits behind the guard.

Not all traffic enters Google Cloud the same way, so Cloud Armor provides several policy types. Names and capabilities evolve, so verify the current list in the documentation, but the main ideas are stable.

A closer look

flowchart TD
    START["What are you protecting?"] --> Q1{"Web traffic through an application load balancer?"}
    Q1 -->|"Yes"| Q2{"Heavy use of Cloud CDN caching?"}
    Q2 -->|"Yes"| BOTH["Use backend policy plus edge policy"]
    Q2 -->|"No"| BACK["Use a backend security policy"]
    Q1 -->|"No"| Q3{"Network load balancer or VM with a public address?"}
    Q3 -->|"Yes"| NET["Use a network edge security policy"]
    Q3 -->|"No"| CHK["Check the current documentation for supported targets"]
    

Sharing one policy across services

A single policy can be attached to many backend services. This is wonderful for consistency: your company can create a baseline policy with its standard protections and attach it to every service, instead of rebuilding the same rules many times. If a service needs extra rules, give it its own policy, built on the baseline plus its specialties.

The simplest and most dependable rules look only at where a request comes from.

IP address rules

Every device on the internet has an IP address, a number that identifies where it is. A CIDR range is a compact way of writing a whole block of addresses at once. Cloud Armor rules can match a single address or a block, and then allow or deny it.

• Allow lists: permit only trusted ranges, such as your office or a partner, to reach an admin page. Everything else is denied.
• Deny lists: block addresses that have attacked you before.
• Combined with other tests: for example, only allow the office range to reach paths that begin with the admin section.

Geographic rules

Cloud Armor can guess the country or region of a request using a database that maps addresses to places, and use a standard two-letter region code in rules. This lets you block countries you never serve, or reserve a service for a single country because of law or licensing.

Named IP lists and threat intelligence

Maintaining huge lists of dangerous addresses by hand is impractical. The enterprise tier of Cloud Armor provides threat intelligence, which means curated, regularly updated groups of addresses that Google tracks. Typical groups include exit points of anonymizing networks, known malicious sources, and ranges used by search engine crawlers or public cloud providers. You simply reference the group name in a rule, and Google keeps the contents fresh.

• Block anonymizing exit points from a sensitive login page.
• Block ranges known as sources of malicious traffic.
• Allow well-known search engine crawlers so your site stays visible in search while you block scrapers.
• Treat traffic from public cloud ranges with extra suspicion on pages meant only for humans.

The client address behind other proxies

Cloud Armor must identify the real client. If your traffic first passes through another service before reaching Google, such as a third-party content network, the address Google sees is that service’s, not the visitor’s. In such cases you configure Cloud Armor to read the visitor’s address from a specific request header that the first service fills in. Without this, every visitor appears to come from the same address, and an address-based block or a rate limit would hit everybody at once.

Writing rules to catch every attack pattern yourself would take a team of experts years. Cloud Armor gives you a head start.

Cloud Armor includes preconfigured WAF rules. These are bundles of detection patterns, called signatures, built from versions of the OWASP ModSecurity Core Rule Set, a widely respected collection of attack-detection rules maintained by security experts. Instead of writing signatures yourself, you switch on a bundle by name and Cloud Armor applies it to your traffic.

The main bundles

Sensitivity levels

Each bundle can be applied at a chosen sensitivity level, from low to high. A lower level uses only the most reliable signatures, which rarely block normal visitors by mistake. A higher level adds more signatures that catch more subtle attacks, but also raise the chance of blocking legitimate traffic. This chance is called a false positive: a normal request wrongly treated as an attack.

False positives and how to tame them

Imagine a forum where people discuss programming. A user posts a message containing a database command as an example. A WAF may reasonably think it is an attack. The fix is not to switch the WAF off. It is to tune it, and Cloud Armor gives you several ways.

• Start in preview mode. See what would be blocked using real traffic before enforcing anything.
• Opt out of individual signatures. If one specific signature keeps blocking a legitimate action, disable that signature alone, not the whole bundle.
• Exclude specific request fields. Tell the WAF to ignore a particular parameter, header, or cookie when checking, for example a field that contains rich text.
• Apply different levels to different paths. Use a strict level on the login and payment paths, and a gentler one on the rest of the site.
• Add narrow exceptions. Create an allow rule with a smaller priority number for a trusted address or very specific safe request.

Your application is unique. Custom rules let you describe its special risks, and rate limiting keeps any single visitor from taking more than a fair share.

Custom rules with expressions

Besides simple address lists, Cloud Armor lets you write rule conditions as expressions, using a compact condition language called the Common Expression Language. An expression is a statement that is true or false for each request, and you can combine statements with “and”, “or”, and “not”. Without writing out code here, here is the kind of thing you can say in words:

• If the path begins with the admin section and the source is outside the office range, deny.
• If the method is one that your site never uses, deny.
• If a particular header is missing that every real client of your mobile app always sends, deny or challenge.
• If the browser identification text matches a known bad scraper, deny.
• If the request comes from a certain region and targets the checkout, send to a challenge.
• If the request carries a known-bad cookie value from an old attack, deny.

Rate limiting

Rate limiting restricts how often a client can do something. It is the right tool for problems that have nothing wrong with any single request, such as a bot hammering a login page. Cloud Armor offers two actions for this.

Who counts as “one client”?

A rate limit needs a way to decide which requests belong together. Cloud Armor lets you choose the key: the source address, the address from a forwarded header, the country, a particular header or cookie value, or other keys. Choosing carefully matters.

• By address: simple, but many people behind a company or school network share one address, and one noisy user could limit everybody.
• By a user or session identifier: more precise for logged-in areas, but attackers can rotate identifiers.
• By all clients together: a global ceiling protecting a fragile backend, at the cost of treating everyone alike.

Where limits help most

• Login and password reset pages, against guessing and stuffing.
• Search and report endpoints that are expensive to run.
• Sign-up and contact forms, against spam.
• Public APIs, to keep fair use among customers.

Not every harmful visitor is an exploit. Many are automated programs pretending to be people. Telling them apart is a different skill.

A bot is simply a program that does things on the internet automatically. Many bots are good: search engines use them to index your pages. Others are harmful. The hardest part is that harmful bots try hard to look human, using real browser identities and spreading their requests across thousands of addresses so no single one looks busy.

Ways Cloud Armor can help

A sensible bot defense plan

Floods are the loudest attacks. Defending against them takes both huge capacity and clever detection.

Always-on protection against floods

Traffic that reaches your application through Google Cloud’s global load balancing passes through Google’s own front end infrastructure, which is built to absorb enormous floods. Attacks aimed at the lower network layers, such as volumetric and connection-setup floods, are filtered automatically at this front end. You do not have to switch this on or write rules for it. It is part of how the platform works.

In recent years the largest recorded web floods have reached tens and even hundreds of millions of requests per second, such as the HTTP/2 “rapid reset” attack disclosed in 2023, which Google publicly described as the largest of its kind at the time. Such numbers show why defenses must live in a very large shared network, not at a single company’s front door.

The application layer is harder

A flood of ordinary-looking requests aimed at your most expensive pages is much harder to detect than a flood of garbage. Cloud Armor’s rules, rate limits, and bot checks form your first lines of defense against them. And for larger organizations there is a smarter helper.

Adaptive Protection

Adaptive Protection uses machine learning to study the normal pattern of traffic to each protected service. When the pattern suddenly changes in a way that looks like an attack, it raises an alert, describes the suspicious traffic, and suggests a rule that would block it. In the enterprise tier you can allow it to deploy such rules automatically. This is valuable because it spots new attack shapes that no signature list knows about yet.

flowchart LR
    TR["Normal Traffic Patterns Learned"] --> DET{"Sudden Unusual Pattern?"}
    DET -->|"No"| CONT["Keep Monitoring"]
    DET -->|"Yes"| ALR["Alert with Attack Details"]
    ALR --> SUG["Suggested Blocking Rule"]
    SUG --> REV["Team Reviews and Deploys"]
    SUG --> AUTO["Optional Automatic Deployment"]
    REV --> BLK["Attack Traffic Blocked"]
    AUTO --> BLK
    

The service tiers

The biggest fear with any firewall is blocking your own customers. A careful rollout removes most of that fear.

A security rule that is wrong can cause an outage as damaging as an attack. A checkout page that suddenly rejects every order because a signature disliked a coupon code costs real money. For that reason, experienced teams follow a repeatable process instead of switching rules on in a hurry.

flowchart TD
    A["Draft the rule"] --> B["Deploy in Preview Mode"]
    B --> C["Collect logs for several days"]
    C --> D{"Any false positives?"}
    D -->|"Yes"| E["Tune: opt out signatures, add exclusions, adjust level"]
    E --> B
    D -->|"No"| F["Enforce on a small share or one service"]
    F --> G["Watch errors and customer reports"]
    G --> H{"Healthy?"}
    H -->|"No"| I["Roll back to Preview"]
    I --> E
    H -->|"Yes"| J["Enforce everywhere and keep monitoring"]
    

The steps in plain words

Test with safe, controlled attacks

Once rules are enforced, check that they really work. In a test environment you own, send harmless sample attack-like requests and confirm they are denied with the expected response, while normal requests still succeed. Do this only against systems you are authorized to test, never against anyone else’s. Many teams add such checks to their release pipeline so a broken protection is noticed immediately.

Change management

• Keep policies in code and require peer review for rule changes.
• Record the reason for each rule in its description, so future staff know why it exists.
• Schedule regular reviews to remove outdated rules, because old rules clutter the policy and hide problems.
• Plan emergency changes in advance, such as a pre-approved procedure for quickly blocking an attacking range.

A security service that slows down or breaks your site is a bad bargain. Here is why Cloud Armor is designed to stay out of the way.

Speed

Cloud Armor’s checks are part of the load balancer’s own request handling and run inside Google’s network, so they add very little delay. Because rules are evaluated at the edge nearest the visitor, blocked requests are answered immediately, and allowed requests are not forced through a separate appliance in the middle of the path.

Scalability

There is no box with a maximum capacity to size, and no appliance to add when traffic grows. The protection scales with Google’s global load balancing infrastructure. When a sudden surge of visitors arrives, whether from a viral post or an attack, the same edge capacity handles it. You pay according to use, as covered in the cost chapter.

Availability

Because Cloud Armor is built into the load balancing layer, which is itself a distributed, highly available service, there is no single guard that can fall over. Policies are stored and distributed by Google to the edge locations, and a change you make is rolled out across the fleet after a short delay. Plan for that delay: do not expect a new rule to take effect in the same instant you save it.

Protect the capacity behind the guard

Cloud Armor stops what it can recognize as bad. The traffic it lets through still needs servers to handle it. For a robust design, combine Cloud Armor with autoscaling, which adds servers when load rises, and with caching through Cloud CDN, so repeated requests for the same content are served from the edge without touching your servers at all. This pairing protects both your security and your budget.

A strong front door does not help if the back door is open. This chapter covers the most common ways teams accidentally bypass their own protection.

Layer 1: Make the load balancer the only way in

Cloud Armor only sees traffic that passes through its load balancer. If an attacker discovers the direct public address of a virtual machine or a serverless service, they can skip the guard entirely. Closing every other entrance is one of the most valuable things you can do.

Layer 2: Who may edit policies (IAM)

IAM, Identity and Access Management, controls who can do what in Google Cloud. Security policies are powerful: a person who can edit them can open your site to attacks or, just as easily, block all your customers. Roles such as the Compute Security Admin role are designed for managing security policies. Follow the rule of least privilege.

• Give edit rights to a small, named security group, not to everyone in engineering.
• Give read-only access to those who only need to view logs and rules.
• Use separate automation accounts with narrow permissions for pipeline deployments.
• Require approvals for changes to production policies.

Layer 3: Audit trails

Cloud Audit Logs record who created, changed, or deleted a security policy and when. Send these logs to a protected location and alert on unexpected changes, particularly rules that move traffic from deny to allow, or the removal of a policy from a backend service.

Layer 4: Protect the certificates and domain

Cloud Armor depends on the load balancer, which depends on your domain name and certificates. Guard your DNS and registrar accounts with strong sign-in, because someone who can change where your name points can send visitors around your protection altogether.

You cannot defend what you cannot see, and in a usage-based service you cannot manage costs you do not watch.

What to watch

Questions your dashboard should answer

• How many requests are being denied, and is that number moving?
• Which rules block the most traffic, and are they still useful?
• Which source countries, networks, and paths are most targeted?
• Are real customers hitting denies? Look at denied requests with ordinary-looking addresses and paths.
• Did any preview rule record a very large number of matches that would have caused harm?

Alerts worth setting

• A sudden jump in denied requests, which signals an attack or a faulty new rule.
• A sudden drop in total requests, which may mean a rule is blocking customers.
• An Adaptive Protection alert for any service.
• Any change to a production security policy outside approved windows.
• Spending that crosses a budget threshold.

How billing works

For most applications, the cost of protection is small compared with the cost of one successful attack or one long outage. Exact prices change and depend on tier and usage, so read the current pricing page before estimating.

Cloud Armor works best when it is part of the whole delivery chain and managed like the rest of your code.

Treat security policy as code

A policy edited by clicking in a console is hard to review and easy to break. Mature teams describe their policies in files stored in version control, using an infrastructure-as-code tool such as Terraform, and apply them through a reviewed pipeline. This gives history, peer review, easy rollbacks, and the ability to recreate the same policy for testing and for production.

An incident runbook

Prepare a written plan for the day an attack arrives, because during an attack nobody thinks clearly. A simple runbook lists who is on call, where dashboards and logs are, how to find the attack’s common features, which kinds of rules to add first, how to communicate with customers, and how to bring the situation back to normal. After each incident, review what worked and update the plan.

Every tool has strengths and weak spots. Knowing both lets you choose with open eyes.

The trade-offs behind the choice

How it compares with other options

Many organizations combine layers: secure code at the base, Cloud Armor at the edge, and monitoring on top. Some also keep a third-party edge in front for a single policy across several clouds. Choose a design that your team can actually operate well.

Teams keep solving the same protection problems. Here are the patterns that work, and the traps that catch people.

Patterns that work

Anti-patterns to avoid

A practical checklist, followed by a simple method for working out why a request was blocked or allowed.

Best practices

Common mistakes

• Forgetting the rule order. A broad deny with a small number can catch the traffic you meant to allow.
• Relying on geography alone. Location from an address is approximate, and attackers can use addresses anywhere.
• Rate limits set too low. Legitimate mobile apps and busy offices are blocked.
• Ignoring false positives. Customers quietly fail to check out, and no one notices until revenue dips.
• Attaching the policy to the wrong service. The rules are correct, but the service that matters is not protected.
• Leaving staging endpoints open. Attackers use them to find weaknesses and as stepping stones.
• Assuming a saved rule works instantly. There is a short delay while changes spread across the edge.
• Treating the WAF as a substitute for patching. Known flaws still need real fixes.

A simple troubleshooting path

flowchart TD
    A["A request was blocked or allowed unexpectedly"] --> B["Find the request in the load balancer logs"]
    B --> C["Read the matched policy and rule"]
    C --> D{"Is the matched rule the one you expected?"}
    D -->|"No"| E["Look for an earlier rule with a smaller priority number"]
    D -->|"Yes"| F{"Is it a WAF signature?"}
    F -->|"Yes"| G["Turn on verbose logging, find the signature, opt out or exclude the field"]
    F -->|"No"| H["Check the expression, the client address source and the rate-limit key"]
    E --> I["Adjust priorities or add a narrow exception"]
    G --> J["Retest in preview mode"]
    H --> J
    I --> J
    

These illustrative scenarios show how the ideas combine in typical organizations. They are teaching examples, not descriptions of specific companies.

Quick answers to the questions beginners ask most often.

If you remember only a few things from this guide, remember these.

Cloud Armor is Google Cloud’s managed web application firewall and DDoS defense, applied at the edge of Google’s global network through your load balancers. You write a security policy made of prioritized rules, use ready-made WAF bundles for common attacks, add custom rules and rate limits for your own risks, and bring in bot scoring and Adaptive Protection where the stakes are higher. Used well, it quietly removes most hostile traffic before it ever touches your servers.