GCP Cloud Armor & VPC Firewall: — Edge DDoS, WAF and Network Defense

① Two layers of GCP network defence

Picture Sneha, an L1 cloud-security engineer at Flipkart, on her first on-call week. Two alerts land within the hour. The first: a burst of SQL-injection requests hammering the public checkout site. The second, later: one of the web servers behind that site has started probing TCP 5432 on the database subnet — a host that should never initiate database connections directly. Same incident, but the two problems live at two completely different layers, and Google Cloud hands her a different tool for each.

The first is a north-south, application-layer problem: bad HTTP coming from the internet into the app. The right guard is Cloud Armor — a WAF that runs in Google's edge, attached to the external Application Load Balancer. It reads the request itself and can recognise a SQLi or XSS string before it ever touches a server.

The second is an east-west, network-layer problem: one internal workload talking to another it shouldn't. The right guard is the VPC firewall — stateful L3-L4 rules attached to the VPC network. The firewall doesn't know or care what HTTP is; it decides whether the web tier is even allowed to open a connection to the database tier. Cloud Armor never sees that VM-to-VM traffic at all.

Here's the shape to hold in your head. The VPC firewall is built into every VPC and is always on: it has an implied deny-ingress rule so nothing reaches a VM unless a rule you wrote says yes. Cloud Armor is opt-in: you create a security policy and attach it to your load balancer's backend service. One protects the perimeter of your app; the other segments the inside.

Edge vs inside, in one tap each

Tap each card — this is the mental split every GCP network question (and interview) tests.

② VPC firewall done right

Let's make the VPC firewall second nature, because most production incidents are a firewall rule that was too broad or in the wrong order. Three facts anchor everything. One: rules have a priority from 0 to 65535 — lower number wins, and the first matching rule stops the search (first hit, not best fit). Two: firewall rules are stateful — allow the inbound and the return traffic is automatically allowed; you rarely write the reply rule. Three: every VPC ships with two implied rules you can't delete — deny-ingress and allow-egress, both at priority 65535.

That third fact has a sharp edge. Ingress is denied by default — good. But egress is allowed by default. So a freshly compromised VM can, out of the box, phone home to a command-and-control server or exfiltrate data outbound, and no rule stops it. Mature teams therefore add deny-by-default egress: a low-priority deny to 0.0.0.0/0, then narrow allow rules above it for exactly the destinations the workload needs.

Now the rule that separates juniors from people who get hired: target by tag or service account, not by source IP. A network tag like web is convenient but it's just a string any editor can stick on a VM. A service account is an IAM-controlled identity — it says what the VM is, and only IAM admins can change it. For production least-privilege, prefer --target-service-accounts. Either way, the rule then follows the workload, not a fragile IP that changes when the VM is recreated.

gcloud compute firewall-rules create allow-web-to-db \
  --network=prod-vpc \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=tcp:5432 \
  --source-service-accounts=web-sa@my-proj.iam.gserviceaccount.com \
  --target-service-accounts=db-sa@my-proj.iam.gserviceaccount.com \
  --priority=1100

Creating firewall...done.
NAME              NETWORK   DIRECTION  PRIORITY  ALLOW      DENY  DISABLED
allow-web-to-db   prod-vpc  INGRESS    1100      tcp:5432         False
  sourceServiceAccounts: web-sa@my-proj.iam.gserviceaccount.com
  targetServiceAccounts: db-sa@my-proj.iam.gserviceaccount.com

That last point scales up to org-wide guardrails. A hierarchical firewall policy is attached at the organisation or folder level and is evaluated before any project's own rules, so a security team can mandate, say, "deny inbound RDP 3389 from the internet everywhere, no exceptions" across the whole org. There are also global and regional network firewall policies for consistent rule sets within a VPC. Note one gotcha: hierarchical policies can't target by instance network tag — they target VPC networks and service accounts.

③ Cloud Armor — the edge WAF & DDoS layer

Now the front gate. A Cloud Armor security policy is an ordered list of rules — each with a priority, a match condition, and an action — that you attach to a load-balancer backend service. When a request hits the external Application Load Balancer, Cloud Armor evaluates it top-down (again lowest priority number first) and the first matching rule's action wins. At the very bottom sits a default rule at priority 2147483647 — set to allow out of the box, which you typically keep as the catch-all.

The star feature is the preconfigured WAF rules. Instead of hand-writing attack signatures, you reference a named expression. evaluatePreconfiguredExpr('sqli-v33-stable') turns on the whole SQL-injection rule set; evaluatePreconfiguredExpr('xss-v33-stable') the cross-site-scripting set. These are built on the OWASP Core Rule Set and cover most of the OWASP Top 10 — SQLi, XSS, local/remote file inclusion, remote code execution and more.

Each preconfigured rule has a sensitivity level (1-4). Higher sensitivity catches more attacks but raises false positives; lower sensitivity uses only high-confidence signatures. You can also tune a rule to exclude specific OWASP rule IDs that trip on your legitimate traffic (e.g. a field that legitimately contains characters the WAF reads as XSS). The skill here is balance: too tight and you block real customers; too loose and you miss the attack.

Beyond signatures, Cloud Armor brings volumetric and behavioural defences. Rate-limiting gives you two actions: throttle (slow a noisy client down to a request rate) and rate-based-ban (temporarily ban a client that blows past the limit). You can key the limit on source IP, an HTTP header, or a JA4 fingerprint. Bot management can challenge suspected bots, and geo-based rules (origin.region_code == 'IN') and named IP/address lists let you allow or deny whole countries or known-good/bad IP ranges in one place.

The smartest layer is Adaptive Protection — machine learning that watches each backend service for anomalous Layer-7 traffic in real time. When it spots an HTTP flood, it does three things: alerts you, generates a signature describing the attack, and suggests a custom rule you can deploy with one click. This is what stands between you and an L7 DDoS that no static signature would have caught — and Google's edge has used exactly these mechanisms to absorb record floods peaking above 398 million requests/second (the HTTP/2 Rapid Reset class, CVE-2023-44487).

# 1) policy + attach to the backend service
gcloud compute security-policies create web-policy --description "edge WAF for checkout"
gcloud compute backend-services update checkout-bes --global --security-policy web-policy

# 2) block SQL injection using the OWASP preconfigured rule (preview, watch logs first)
gcloud compute security-policies rules create 1000 \
  --security-policy web-policy \
  --expression "evaluatePreconfiguredExpr('sqli-v33-stable')" \
  --action deny-403 --preview

# 3) rate-based ban: >100 req/min from one IP gets a 10-min 429
gcloud compute security-policies rules create 1200 \
  --security-policy web-policy --src-ip-ranges "*" \
  --action rate-based-ban --rate-limit-threshold-count 100 \
  --rate-limit-threshold-interval-sec 60 --ban-duration-sec 600 \
  --conform-action allow --exceed-action deny-429 --enforce-on-key IP

Created [.../securityPolicies/web-policy].
Updated [.../backendServices/checkout-bes].
Created rule [1000] (preview)  action: deny-403  expr: evaluatePreconfiguredExpr('sqli-v33-stable')
Created rule [1200]            action: rate-based-ban  key: IP  threshold: 100/60s  ban: 600s

④ Putting it together — block an SQLi flood + a bad bot

Time to wire both layers into one defence. The design pattern you'll see on the job: Cloud Armor at the edge for L7 and DDoS on the public Application Load Balancer, and VPC firewall rules inside for east-west segmentation between every tier. Cloud Armor stops the attack arriving; the firewall stops it spreading. Let's walk a real incident through both.

For your certification path, this lesson lands squarely on the Professional Cloud Security Engineer blueprint — specifically the "configure network security" domain (roughly 20-25% of the exam), which calls out VPC firewall rules, Cloud Armor, DDoS protection and configuring web application firewalls by name. A favourite exam (and interview) trap is exactly the myth we opened with: knowing that Cloud Armor is L7-at-the-edge and the VPC firewall is L3-L4-east-west, and that you need both, answers a surprising share of the network-security questions outright.