Google Cloud Armor: WAF and DDoS Protection Guide

Google Cloud Armor is Google Cloud's network security service for stopping distributed denial-of-service (DDoS) attacks and web application attacks like SQL injection and cross-site scripting before they reach your backends. It works as a set of security policies attached to your load balancers, combining DDoS defense, a Web Application Firewall (WAF), rate limiting, and bot management in one service.

For anyone building a career in cloud security, Cloud Armor is a tool worth knowing cold. It shows up on the Professional Cloud Security Engineer exam, comes up often in cloud security interviews, and is one of the few GCP services where a misconfiguration can mean the difference between a healthy production environment and a multi-hour outage.

What Google Cloud Armor Actually Does

Cloud Armor sits at the edge of Google's global network, in front of your load balancer, not inside your VPC. Traffic gets inspected and, if necessary, blocked before it ever reaches your virtual machines, containers, or serverless backends, unlike a host-based firewall or an in-VPC appliance that only sees traffic after it has already consumed network capacity.

Cloud Armor protects global and classic external Application Load Balancers, regional internal Application Load Balancers, proxy Network Load Balancers, and regional passthrough Network Load Balancers. It also protects backend buckets serving cached content through Cloud CDN.

At a high level, Cloud Armor gives you four capabilities:

1. Always-on Layer 3 and Layer 4 DDoS protection for volumetric and protocol-based attacks.
2. A configurable Layer 7 firewall using security policies and a custom rule language.
3. Preconfigured WAF rules based on the OWASP Core Rule Set (CRS), covering common attack classes such as SQL injection, cross-site scripting, remote code execution, and local and remote file inclusion.
4. Rate limiting and bot management to control abusive or automated traffic.

The Three Types of Cloud Armor Security Policies

Each of the three policy types protects a different layer of the stack.

Backend security policies are the ones you will use most often. They attach to backend services behind external and regional Application Load Balancers or proxy Network Load Balancers, and support the full feature set: IP and geography-based filtering, rate limiting, bot management, WAF rules, and Adaptive Protection.

Edge security policies filter cached content at Google's network perimeter, upstream of Cloud CDN. They support fewer match conditions than backend policies but can run alongside them for layered protection, and are the only policy type that applies to backend buckets.

Network edge security policies block traffic further out, at Google's network edge, for regional passthrough Network Load Balancers, protocol forwarding, and VMs with public IP addresses. Because they do not consume VM or host resources, they help stop high-volume traffic before it exhausts compute resources.

Rules within a policy are evaluated from the lowest priority number to the highest, with 0 as the highest priority, and a default rule always sits at priority 2147483647 for anything that matches nothing else. One detail that trips up newer engineers: Cloud Armor evaluates header-based rules before the request body arrives, so a low-priority header rule can allow a request that a higher-priority body-inspection rule would otherwise have blocked.

WAF Rules and the OWASP Core Rule Set

Cloud Armor's preconfigured WAF rules are built on the OWASP Core Rule Set, with support for CRS versions 3.0, 3.3, and 4.2. Each rule bundles dozens of signatures for a specific attack category, such as SQL injection or PHP injection, so you do not have to hand-write detection logic for known attack patterns.

You can also write custom rules using Cloud Armor's rule language, matching on IP ranges, geography, request headers, cookies, and other request attributes. This supports virtual patching, where you block a known bad pattern immediately while a permanent code fix is still in progress, a technique worth knowing for both incident response and certification exams.

Rate Limiting: Throttle vs. Rate-Based Ban

Cloud Armor supports two rate limiting actions, and understanding the difference is a common interview question.

Action	What it does	Best for
Throttle	Limits requests to a defined maximum rate while still allowing some traffic through	Legitimate traffic spikes, aggressive bots that should be slowed rather than blocked
Rate-based ban	Blocks all further requests from a source once it crosses a threshold, for a set ban duration	Clear abuse or attack traffic that should be cut off entirely

Thresholds are defined as a request count over a time interval, for example 2,000 requests per 1,200 seconds. Enforcement happens independently in each region where your backend is deployed, so in a multi-region deployment the effective global rate can exceed what you configured in any single region. You can key rate limiting on the client IP, an HTTP header or cookie value, the request's region code, the forwarded IP, TLS fingerprint, or ASN, and you can combine up to three keys for finer-grained control.

Cloud Armor Standard vs. Cloud Armor Enterprise

Cloud Armor ships in two tiers, and the difference is one of the most exam-relevant distinctions in the whole service.

Capability	Standard	Cloud Armor Enterprise
L3/L4 DDoS protection	Included	Included
Configurable L7 security policies	Included	Included
Preconfigured WAF rules (OWASP CRS)	Included	Included
Adaptive Protection (ML-based L7 DDoS detection)	Not included	Included
Google Threat Intelligence feeds	Not included	Included
Advanced network DDoS protection for VMs with public IPs	Not included	Included
DDoS attack visibility and telemetry	Not included	Included
DDoS Response Team access	Not included	Included with Premium support on the annual plan
Pricing model	Pay for policies and rules used	Annual subscription or pay-as-you-go, plus per-resource fees

Adaptive Protection is the flagship Enterprise feature. It analyzes traffic patterns to global external Application Load Balancers and automatically proposes, or optionally auto-deploys, custom rules to counter an emerging Layer 7 DDoS attack. Standard tier gives you strong baseline protection, but organizations with high-value public applications, or compliance requirements around documented DDoS response, generally need Enterprise.

Setting Up Cloud Armor: A Practical Starting Point

A reasonable first Cloud Armor configuration for a production web application looks like this:

1. Create a backend security policy and attach it to the backend service behind your external Application Load Balancer.
2. Enable the relevant preconfigured WAF rules for your stack, SQL injection and XSS at minimum, in preview mode first, so you can see what would be blocked before you enforce it.
3. Add a rate limiting rule keyed on client IP to blunt basic credential-stuffing and scraping attempts.
4. Add explicit allow or deny rules for known-good or known-bad IP ranges and geographies, based on where your legitimate users actually are.
5. Review Cloud Logging entries before switching rules from preview to enforce, so a legitimate workflow does not get blocked by mistake.
6. If your workload justifies it, move to Cloud Armor Enterprise for Adaptive Protection and Google Threat Intelligence.

Preview mode deserves its own callout: it lets a rule log what it would have done without actually blocking traffic, which is the safest way to validate a new WAF rule against real production traffic before it goes live.

Where Cloud Armor Fits in Your Cloud Security Career

Cloud Armor is one of the services tested on Google's Professional Cloud Security Engineer exam, alongside IAM, Security Command Center, and Cloud KMS. If you are studying for that certification, or building toward a broader Cloud & AI Platform Security Engineer skill set, set up a real Cloud Armor policy in a sandbox project rather than only reading about it. Configuring preview-mode WAF rules and reading the resulting logs will teach you more in an afternoon than a week of slide decks.

This connects to two topics we have covered before: GCP VPC Service Controls for stopping data exfiltration at the network boundary, and GCP Cloud KMS and CMEK for protecting data at rest. Together, these three services cover network edge defense, data exfiltration prevention, and encryption, which is a large share of a GCP security engineer's daily responsibilities.

Common Mistakes to Avoid

Engineers new to Cloud Armor tend to make the same few errors: enforcing a new WAF rule immediately instead of testing it in preview mode first, which can take down legitimate traffic without warning; relying only on IP-based rate limiting, which does nothing against distributed attacks from many source addresses; forgetting that network edge security policies exist separately from backend policies, leaving VMs with public IPs unprotected even when the load balancer in front of them is well configured; and treating Cloud Armor as a replacement for secure application code rather than a complementary layer. A WAF reduces risk from known attack patterns, but it does not fix an application that is vulnerable to begin with.

Frequently asked questions

What is Google Cloud Armor used for? Google Cloud Armor protects Google Cloud applications from distributed denial-of-service attacks and Layer 7 web application attacks such as SQL injection and cross-site scripting. It attaches security policies to load balancers, so malicious or abusive traffic is filtered at Google's network edge before it reaches your backend services.

What is the difference between Cloud Armor Standard and Cloud Armor Enterprise? Standard includes always-on Layer 3 and Layer 4 DDoS protection plus configurable Layer 7 security policies and WAF rules. Enterprise adds Adaptive Protection for automated Layer 7 DDoS detection, Google Threat Intelligence feeds, advanced network DDoS protection for VMs with public IPs, attack telemetry, and access to a DDoS Response Team for eligible support plans.

Does Cloud Armor protect against Layer 7 DDoS attacks? Yes, but protection depth depends on the tier. Standard gives you configurable rate limiting and WAF rules that help mitigate application-layer abuse. Enterprise adds Adaptive Protection, which analyzes traffic patterns and automatically suggests or deploys rules in response to an active Layer 7 DDoS attack.

How do preconfigured WAF rules work in Cloud Armor? Preconfigured WAF rules are built on the OWASP Core Rule Set and bundle detection signatures for a specific attack category, such as SQL injection or remote code execution. Enable them at the sensitivity level appropriate for your application, and run them in preview mode first so you can confirm they do not block legitimate traffic before switching to enforce mode.

What is the difference between throttle and rate-based ban actions? Throttle limits the rate of requests from a client to a configured maximum while still allowing some traffic through, suiting legitimate but bursty traffic. Rate-based ban blocks all further requests from a source entirely once it crosses a threshold, for a configured ban duration, suiting clear abuse or attack traffic.

Is Cloud Armor covered on the Professional Cloud Security Engineer exam? Yes. Cloud Armor is one of the network security services covered on Google's Professional Cloud Security Engineer exam, alongside IAM, Security Command Center, VPC Service Controls, and Cloud KMS. Hands-on practice configuring a security policy is more useful for exam prep than memorization alone.

Cloud Armor is a foundational piece of GCP network security, and it is exactly the kind of hands-on, exam-relevant skill our 20-week Cloud & AI Platform Security Engineer program is built around. If you want to build real, defensible experience with services like Cloud Armor, IAM, and VPC Service Controls, take a look at the curriculum and see where it fits your background.