As an infrastructure or cloud engineer, your job isn’t just to build; it’s to protect. When you deploy applications to the cloud, you’re exposing them to the public internet, a space filled with threats ranging from automated bots to large-scale Distributed Denial-of-Service (DDoS) attacks. Your first line of defense isn’t the VM’s firewall—it’s the network edge.
In Google Cloud, that defense is Google Cloud Armor.
This article will be a deep, technical dive into what Cloud Armor is, how it works, and how you can configure it to protect your workloads. We’ll skip the marketing fluff and get straight to the architecture, rules, and commands.
What is Google Cloud Armor?
At its core, Google Cloud Armor is a Web Application Firewall (WAF) and DDoS mitigation service.
It’s not a service you deploy on a VM. Instead, it integrates directly with Google’s Global External Application Load Balancer (and other supported load balancers) to filter traffic before it ever reaches your backend services. This is crucial. By sitting at the very edge of Google’s massive global network, it can absorb and block petabyte-scale DDoS attacks and filter malicious application requests (like SQL injection) far away from your VPC.
Think of it as the highly intelligent, globally distributed security guard standing in front of your application’s front door (the load balancer).
How It Works: Policies and Targets
The entire Cloud Armor model is built on two simple concepts: Security Policies and Targets.
- Security Policy: This is the object that contains your set of rules. It’s a collection of “if-then” statements with a priority order. For example:
- Priority 1000: IF
origin.ipis in1.2.3.4/32, THENdeny(403). - Priority 2000: IF
request.pathcontains'/etc/passwd', THENdeny(404). - Default:
allow.
- Priority 1000: IF
- Target: This is the thing you attach the policy to.9 The most common target is a backend service.
When traffic flows to your load balancer, it’s directed to a backend service. Cloud Armor intercepts this flow, evaluates the attached security policy from top-to-bottom (lowest priority number first), and as soon as it finds a matching rule, it executes the action (e.g., allow, deny, throttle).
This model is powerful because you can apply the same policy to multiple backend services, ensuring consistent security for your entire application.
🛡️ Core Features and Capabilities
Cloud Armor is much more than a simple IP blocklist. Its features are layered from L3 to L7.
L3/L4 DDoS Protection
This is the “always-on” protection you get with Cloud Armor Standard. It defends against volumetric and protocol-based attacks like SYN floods, UDP floods, and TCP reflection attacks. This protection is built into Google’s edge and automatically mitigates attacks aimed at your External Load Balancers.
L7 WAF (Web Application Firewall) Rules
This is where you’ll spend most of your time. Cloud Armor’s L7 rules let you inspect incoming HTTP(S) requests.
- Pre-configured WAF Rules: This is a massive time-saver. You can apply Google-curated rulesets to instantly protect against the OWASP Top 10 vulnerabilities With a single rule, you can block common SQL injection (SQLi), Cross-Site Scripting (XSS), Remote File Inclusion (RFI), and other attack patterns.
- Custom Rules (CEL): For more granular control, you can write your own rules using the Common Expression Language (CEL) This lets you build rich expressions based on almost any part of the HTTP request.
Example CEL Rules:
- Geo-blocking: Block traffic from a specific country (e.g., North Korea). origin.region_code ‘KP’
- User-Agent Blocking: Block a specific bad bot. request.headers[‘user-agent’].contains(‘BadBot’)
- Complex Logic: Block a specific path unless it comes from an internal IP. request.path.matches(‘/admin/*’) && !inIpRange(origin.ip, ‘10.0.0.0/8’)
Rate Limiting
A critical defense against brute-force login attempts or content-scraping bots. You can create rules to throttle or ban clients that exceed a certain request threshold.
- Example: “Allow no more than 100 requests per 5 minutes from any single IP.”
- Example: “Allow no more than 20
POSTrequests to/login.phpper 10 minutes from any single IP.”
Adaptive Protection
This is a key feature of the “Enterprise” tier. Adaptive Protection uses machine learning (ML) to analyze your application’s normal traffic patterns. When it detects a high-volume, anomalous L7 traffic spike (a potential application-layer DDoS attack), it can:
- Generate an alert in Security Command Center.
- Provide a suggested rule (e.g., “This traffic shares a common
User-AgentandRefererheader; block it.”) - Automatically deploy that rule to mitigate the attack.
Threat Intelligence
Another “Enterprise” tier feature. This allows you to block traffic based on Google’s own internal threat intelligence feeds. You can create rules to block known malicious IP addresses, Tor exit nodes, and other indicators of compromise.
Standard vs. Enterprise Tiers
Cloud Armor is offered in two main tiers. Choosing the right one is critical.
| Feature | Cloud Armor Standard | Cloud Armor Enterprise |
|---|---|---|
| Pricing Model | Pay-as-you-go (per policy, per rule, per million requests) | Subscription (fixed monthly fee + data processing fee) |
| Always-on DDoS (L3/L4) | ✔️ Yes | ✔️ Yes |
| WAF Rules (OWASP, CEL) | ✔️ Yes | ✔️ Yes |
| Adaptive Protection (L7 ML) | ⚠️ Alerting only | ✔️ Alerting + Mitigation |
| Threat Intelligence | ❌ No | ✔️ Yes |
| Advanced Network DDoS | ❌ No | ✔️ Yes (Protects Passthrough NLBs, VMs) |
| DDoS Bill Protection | ❌ No | ✔️ Yes (Credits for cost spikes during a DDoS) |
| DDoS Response Support | ❌ No | ✔️ Yes (Access to Google’s security team) |
The takeaway: Standard is great for basic WAF and OWASP protection. Enterprise is a managed security service for mission-critical applications that need automated L7 DDoS mitigation, advanced threat intel, and financial/support-based peace of mind.
💻 Practical Example: gcloud Configuration
Let’s build and apply a simple security policy from the command line.
Objective:
- Create a new policy.
- Block a specific “naughty” IP address (e.g.,
198.51.100.10). - Apply the pre-configured OWASP Top 10 rules.
- Attach the policy to an existing backend service.
Assume you already have a Global External HTTP(S) Load Balancer with a backend service named my-app-backend-service.
Bash
######
# Step 1: Create the empty security policy
######
gcloud compute security-policies create my-app-policy \
--description "Main security policy for my-app"
######
# Step 2: Add a rule to block the 'naughty' IP (high priority: 1000)
######
gcloud compute security-policies rules create 1000 \
--policy my-app-policy \
--expression "origin.ip == '198.51.100.10/32'" \
--action "deny-403" \
--description "Block known bad actor"
######
# Step 3: Add the OWASP Top 10 ruleset (lower priority: 2000)
# This rule will evaluate for SQLi, XSS, etc.
######
gcloud compute security-policies rules create 2000 \
--policy my-app-policy \
--expression "evaluatePreconfiguredExpr('owasp-crs-v33-stable')" \
--action "deny-403" \
--description "Apply OWASP Top 10 rules"
######
# Step 4: Set the default rule (lowest priority) to allow all other traffic
# Note: The default rule is implicitly 'allow' if not set, but being explicit is good practice.
######
gcloud compute security-policies rules update default \
--policy my-app-policy \
--action "allow" \
--priority 2147483647
######
# Step 5: Attach the policy to your backend service
######
gcloud compute backend-services update my-app-backend-service \
--global \
--security-policy my-app-policy
Just like that, your application is now protected.
Command Reference Table
Here are the essential gcloud commands for managing Cloud Armor.
| Command | Description |
|---|---|
gcloud compute security-policies create [NAME] | Creates a new, empty security policy. |
gcloud compute security-policies list | Lists all security policies in your project. |
gcloud compute security-policies describe [NAME] | Shows the details and rules of a policy. |
gcloud compute security-policies rules create [PRIO] | Creates a new rule in a policy. |
gcloud compute security-policies rules update [PRIO] | Updates an existing rule. |
gcloud compute security-policies rules delete [PRIO] | Deletes a rule from a policy. |
gcloud compute backend-services update [BE_NAME] | Attaches a policy to a backend service. |
gcloud compute backend-services describe [BE_NAME] | Shows which policy is attached to a backend. |
⚠️ Common Pitfalls and Best Practices
- Pitfall: Thinking it only protects GCE. Cloud Armor protects any backend service. This includes GCE Instance Groups, Google Kubernetes Engine (GKE) (via Ingress/Gateway), Cloud Run, App Engine, and even on-prem or multi-cloud servers (when configured as an Internet Network Endpoint Group – NEG).
- Best Practice: Use “Preview Mode.” When adding a new rule, especially a complex CEL rule, you can set it to “preview” mode instead of “enforce.” –action “allow” –preview The rule will be evaluated and logged (e.g., in Cloud Logging), but it won’t actually block traffic. This lets you test your rule’s impact on production traffic before you cause an outage by blocking legitimate users.
- Pitfall: Forgetting about Logging. If you don’t enable logging on your backend service, you’ll be blind. Cloud Armor logs its actions (allowed, denied, previewed) to Cloud Logging. You must enable logging on your load balancer’s backend service to see why a request was blocked. This is non-negotiable for troubleshooting.
- Best Practice: Start with OWASP. Always apply the pre-configured evaluatePreconfiguredExpr(‘owasp-crs-v33-stable’) rules first (at a low priority). This gives you a fantastic baseline of protection against 90% of common attacks with zero custom development.
- Pitfall: Rule Priority Confusion. Rules are evaluated from the lowest priority number to the highest. A rule at priority 1000 runs before a rule at priority 2000. The default rule always runs last at priority 2147483647. A common mistake is to create an allow rule at a high priority that accidentally bypasses a more-specific deny rule at a lower priority.
Final Thoughts
Google Cloud Armor is a mandatory component for any security-conscious architecture on GCP. It provides scalable, first-line-of-defense protection that integrates seamlessly with the load balancing infrastructure you’re already using.
By starting with the Standard tier, applying the pre-configured OWASP rules, and using logging to monitor for threats, you can significantly harden your application’s posture. As your needs grow, the Enterprise tier offers a powerful, ML-driven managed defense to automatically counter more sophisticated L7 attacks.
