Photo by Yosuke Ota on Unsplash

On this page

This chapter follows VPC networks in Google Cloud. Cloud Armor is a WAF and DDoS layer for traffic that hits an external Application Load Balancer. It does not sit directly on the Cloud Run URL; it evaluates requests at the edge before they reach a serverless network endpoint group (NEG) backed by your service.

For load-balancer concepts shared across clouds, see Proxy, reverse proxy, and load balancer.

Architecture: load balancer to Cloud Run

Diagram 1
flowchart LR
  user[Internet clients] --> lb[External HTTPS LB]
  lb --> armor[Cloud Armor policy]
  armor --> neg[Serverless NEG]
  neg --> run[Cloud Run file-api]

Steps at a high level:

  1. Reserve a global static IP and create an external managed HTTPS load balancer.
  2. Create a serverless NEG pointing at the file-api Cloud Run service.
  3. Attach a backend service with that NEG.
  4. Create a Cloud Armor security policy and bind it to the backend service.
  5. Set Cloud Run ingress to internal-and-cloud-load-balancing so users cannot bypass the load balancer via the default Run URL.

Restrict direct access:

Terminal window
gcloud run services update file-api \
--region=europe-west1 \
--ingress=internal-and-cloud-load-balancing

Console workflows under Network services → Load balancing mirror the same objects; names vary slightly by UI version.

Security policies and rule priority

A security policy is an ordered list of rules with priorities (lower numbers evaluated first). Each rule has a match (IP lists, geo, expression language) and an action: allow, deny, or rate-based ban.

Create a policy with a default allow and a deny for a test IP:

Terminal window
gcloud compute security-policies create file-api-policy \
--description="WAF for file API"
gcloud compute security-policies rules create 1000 \
--security-policy=file-api-policy \
--expression="origin.ip == '203.0.113.10'" \
--action=deny-403
gcloud compute security-policies rules create 2147483647 \
--security-policy=file-api-policy \
--action=allow

Attach the policy when you configure the backend service (Console or gcloud compute backend-services update with --security-policy).

Preconfigured WAF rules

Cloud Armor preconfigured rules wrap ModSecurity-style signatures (SQLi, XSS, CVE-specific patterns). Enable in preview first so matches log without blocking:

Terminal window
gcloud compute security-policies rules create 2000 \
--security-policy=file-api-policy \
--expression="evaluatePreconfiguredExpr('sqli-v33-stable')" \
--action=deny-403 \
--preview

Promote to enforce when false positives are acceptable.

Rate limiting

Rate-based rules throttle abusive clients (for example more than 100 requests per minute per IP):

Terminal window
gcloud compute security-policies rules create 3000 \
--security-policy=file-api-policy \
--expression="true" \
--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

Tune thresholds from Cloud Monitoring metrics on the load balancer.

Adaptive Protection

Adaptive Protection (when enabled) learns normal traffic on your backend and suggests rules during L7 attacks. It complements static WAF rules; enable at the security policy level in the Console for production services under sustained attack risk.

Next: Cloud Logging collects structured logs from Cloud Run and the load balancer.

Check your understanding

Question 1 of 5

0 of 5 checked

  1. 1. Why set Cloud Run ingress to internal-and-cloud-load-balancing in this setup?

Search articles

Type a word to search published articles.

Open the search page