{"id":727,"date":"2026-04-15T04:49:33","date_gmt":"2026-04-15T04:49:33","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-armor-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking\/"},"modified":"2026-04-15T04:49:33","modified_gmt":"2026-04-15T04:49:33","slug":"google-cloud-armor-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-armor-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking\/","title":{"rendered":"Google Cloud Armor Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Networking"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Networking<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Google Cloud Armor is Google Cloud\u2019s managed security service that helps protect internet-facing applications and APIs from common web attacks and distributed denial-of-service (DDoS) events when those apps are served through supported Google Cloud load balancers and CDN paths.<\/p>\n\n\n\n<p>In simple terms: you put Google Cloud Armor in front of your application (via Google Cloud Load Balancing \/ Cloud CDN), then define security rules like \u201cblock these IPs,\u201d \u201conly allow these countries,\u201d \u201crate-limit login requests,\u201d and \u201cblock common attack patterns.\u201d Google enforces those rules at Google\u2019s edge and load-balancing infrastructure so malicious traffic is filtered before it reaches your backends.<\/p>\n\n\n\n<p>Technically, Google Cloud Armor is implemented as security policies attached to supported backend services or backend buckets. Requests are evaluated against ordered rules (priorities). Rules can match on source IP, geography, request attributes (such as path and headers), and can use advanced detections (such as managed WAF rule sets and adaptive protection features) depending on your edition\/features. Enforcement happens in the load balancer\/CDN request path, and results can be logged to Cloud Logging for analysis and auditing.<\/p>\n\n\n\n<p>Google Cloud Armor solves problems like:\n&#8211; Blocking common web attacks (e.g., injection patterns, suspicious user agents, exploit probes)\n&#8211; Mitigating application-layer (L7) DDoS attacks and abusive traffic spikes\n&#8211; Implementing IP allowlists\/denylists and geo restrictions\n&#8211; Rate limiting and traffic shaping for sensitive endpoints (logins, signups, APIs)\n&#8211; Centralizing edge security controls consistently across multiple backends and services<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Google Cloud Armor?<\/h2>\n\n\n\n<p><strong>Official purpose (in Google Cloud terms):<\/strong> Google Cloud Armor is a security policy and enforcement system that helps protect applications behind Google Cloud Load Balancing (and supported CDN configurations) with WAF-like controls and DDoS defense capabilities. It is designed to work with Google\u2019s global edge and load-balancing infrastructure.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Security policies<\/strong> with ordered rules to allow, deny, redirect, or rate-limit requests (supported actions vary by feature\/edition\u2014verify in official docs).<\/li>\n<li><strong>IP-based and geo-based access controls<\/strong> to restrict who can reach your app.<\/li>\n<li><strong>Web application firewall (WAF) capabilities<\/strong>, including custom request matching and managed\/preconfigured WAF rule sets (names\/versions evolve\u2014verify in official docs).<\/li>\n<li><strong>Layer 7 DDoS defense<\/strong>, benefiting from Google\u2019s edge capacity and optional advanced detection\/automation features (edition-dependent).<\/li>\n<li><strong>Observability<\/strong> via request logging and integrations with Cloud Logging\/Monitoring.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Security policy<\/strong>: A container for rules, evaluated in priority order.<\/li>\n<li><strong>Rules<\/strong>: Each rule has a priority, a match condition (e.g., an expression), and an action (allow\/deny\/rate limit\/etc.).<\/li>\n<li><strong>Policy attachment point<\/strong>: Typically a <strong>backend service<\/strong> (for load-balanced backends) or a <strong>backend bucket<\/strong> (commonly for Cloud CDN origins). Some features also relate to <strong>edge enforcement<\/strong> when using CDN paths\u2014verify your specific load balancer and CDN configuration in docs.<\/li>\n<li><strong>Logging and metrics<\/strong>: Rule evaluation can be logged for analysis and incident response.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed edge\/application security service<\/strong> integrated with Google Cloud\u2019s networking stack\u2014primarily <strong>Cloud Load Balancing<\/strong> and <strong>Cloud CDN<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope (global\/regional\/project)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud Armor policies are managed at the <strong>project<\/strong> level.<\/li>\n<li>Enforcement scope depends on the load balancer type and configuration. Many common deployments are <strong>global<\/strong> when using global external HTTP(S) load balancing, and <strong>regional<\/strong> when using regional application load balancers.<br\/>\n<strong>Verify the exact global\/regional behavior for your chosen load balancer<\/strong> in the official documentation because support varies by load balancer type and feature.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Google Cloud ecosystem<\/h3>\n\n\n\n<p>Google Cloud Armor is not a standalone firewall for VM NICs. Instead, it fits into the <strong>Networking<\/strong> and <strong>application delivery<\/strong> layer:\n&#8211; Sits in front of applications delivered via <strong>External Application Load Balancer (HTTP(S))<\/strong> and supported paths.\n&#8211; Complements:\n  &#8211; <strong>VPC firewall rules \/ hierarchical firewall policies<\/strong> (network-layer access control inside your VPC)\n  &#8211; <strong>Cloud IDS<\/strong> (intrusion detection inside your VPC)\n  &#8211; <strong>Identity-Aware Proxy (IAP)<\/strong> (identity-based access to apps)\n  &#8211; <strong>reCAPTCHA Enterprise<\/strong> (bot and abuse signals; may integrate with Armor features\u2014verify)<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Google Cloud Armor?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Reduce downtime risk<\/strong>: Mitigate DDoS and abusive traffic before it hits your app infrastructure.<\/li>\n<li><strong>Lower operational burden<\/strong>: Managed WAF-style protections without running and patching WAF appliances.<\/li>\n<li><strong>Consistent policy<\/strong>: Apply standard protections across many services and teams.<\/li>\n<li><strong>Faster incident response<\/strong>: Block attacks quickly with policy changes rather than redeployments.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Edge enforcement<\/strong>: Filtering can occur before traffic reaches your backends, reducing load and latency impact.<\/li>\n<li><strong>Fine-grained HTTP request matching<\/strong>: Build rules targeting paths, headers, query parameters, geographies, etc. (feature details vary; verify).<\/li>\n<li><strong>Integration with Google Cloud Load Balancing and Cloud CDN<\/strong>: Works in the request path where it matters for internet-facing services.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Centralized logging<\/strong>: Send security events and rule actions to Cloud Logging.<\/li>\n<li><strong>Policy as code<\/strong>: Manage policies using gcloud\/REST and infrastructure-as-code tools (e.g., Terraform). (Tooling support is broad; specifics depend on your stack.)<\/li>\n<li><strong>Repeatable rollouts<\/strong>: Use preview\/evaluation modes (where supported) to reduce false positives (verify feature availability).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Baseline protection<\/strong> for common web threats and scanning.<\/li>\n<li><strong>Geo restrictions<\/strong> can support policy requirements (e.g., limiting access by region), though compliance typically needs additional controls beyond geofencing.<\/li>\n<li><strong>Auditable changes<\/strong> through Cloud Audit Logs for policy modifications.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Absorb and filter at scale<\/strong> using Google\u2019s edge and load-balancing capacity.<\/li>\n<li><strong>Protect origin capacity<\/strong> by reducing unnecessary traffic to backends (especially important for autoscaling serverless and microservices).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose Google Cloud Armor when:\n&#8211; Your app is served through supported Google Cloud load balancers and you need WAF\/DDoS controls.\n&#8211; You want managed protections integrated into Google Cloud Networking.\n&#8211; You need rapid response controls (block IPs, rate-limit endpoints) without changing app code.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>Consider alternatives or complementary services when:\n&#8211; Your service is <strong>not<\/strong> behind a supported Google Cloud load balancer\/CDN path (Armor won\u2019t attach directly to VM external IPs).\n&#8211; You need <strong>deep request inspection<\/strong> beyond what the service supports (e.g., full request body inspection) or highly customized third-party signatures.\n&#8211; You need dedicated bot mitigation features beyond what your edition provides; you may need <strong>reCAPTCHA Enterprise<\/strong>, application-level controls, or a specialized edge provider.\n&#8211; You require protection for non-HTTP protocols without supported attachment points (verify load balancer support matrix).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Google Cloud Armor used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>E-commerce and retail (protect checkout, login, product APIs)<\/li>\n<li>SaaS and B2B platforms (multi-tenant API protection)<\/li>\n<li>Media and streaming (protect content delivery and APIs)<\/li>\n<li>Financial services (protect sensitive portals; meet security baselines)<\/li>\n<li>Gaming (rate-limit abusive traffic, protect matchmaking APIs)<\/li>\n<li>Education and public sector (protect public portals from scans and floods)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering (standardized policies for many apps)<\/li>\n<li>DevOps\/SRE (incident response, traffic control, reliability)<\/li>\n<li>Security engineering (WAF policy, threat response, audit readiness)<\/li>\n<li>Application teams (protect sensitive routes without rewriting app logic)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Public web apps behind External HTTP(S) Load Balancing<\/li>\n<li>Public REST\/gRPC APIs (HTTP\/2 via HTTPS load balancing; verify feature constraints)<\/li>\n<li>Serverless backends (Cloud Run\/App Engine) behind load balancing<\/li>\n<li>Static content fronted by Cloud CDN (via backend buckets)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Single-region backends with global ingress<\/li>\n<li>Multi-region active\/active services with global anycast front door<\/li>\n<li>Microservices behind a shared external application load balancer<\/li>\n<li>CDN + origin architectures where edge security reduces origin load<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production<\/strong>: Enforced policies with logging and alerting; staged rollouts using preview modes where supported.<\/li>\n<li><strong>Dev\/Test<\/strong>: Lower-risk environments to test new rules and validate false positives; load-testing rate limits.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are practical scenarios where Google Cloud Armor is commonly used.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) IP allowlisting for admin portals<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Admin endpoints must only be accessible from corporate networks.<\/li>\n<li><strong>Why Google Cloud Armor fits:<\/strong> Enforce source IP allowlists at the edge\/load balancer before requests hit backends.<\/li>\n<li><strong>Example:<\/strong> Only allow <code>\/admin<\/code> from <code>203.0.113.0\/24<\/code>; deny everyone else with 403.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Country\/region restrictions for compliance or fraud reduction<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You only operate in certain markets; traffic from other geographies is mostly fraud\/scanning.<\/li>\n<li><strong>Why it fits:<\/strong> Geo-based matching can deny or challenge traffic from unwanted locations (capabilities vary\u2014verify).<\/li>\n<li><strong>Example:<\/strong> Allow only traffic from selected countries to a payment API.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Rate limiting login and signup endpoints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Credential stuffing and brute-force attempts overload authentication endpoints.<\/li>\n<li><strong>Why it fits:<\/strong> Rate limiting reduces abusive request volume before it reaches your auth service.<\/li>\n<li><strong>Example:<\/strong> Rate-limit <code>\/login<\/code> to a safe threshold per IP, while allowing normal usage.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Basic mitigation for Layer 7 DDoS spikes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Attackers flood HTTP endpoints with expensive requests.<\/li>\n<li><strong>Why it fits:<\/strong> Edge filtering + rate limiting + managed DDoS features reduce load and cost.<\/li>\n<li><strong>Example:<\/strong> During an attack, temporarily deny suspicious user agents and throttle hot paths.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Blocking known malicious IPs (threat intelligence)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Repeated attacks from known bad infrastructure.<\/li>\n<li><strong>Why it fits:<\/strong> Some Google Cloud Armor tiers include threat intelligence-based matches (verify exact mechanisms).<\/li>\n<li><strong>Example:<\/strong> Deny traffic from known malicious IP lists as part of a baseline policy.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Protecting APIs for mobile and partner integrations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> APIs get abused by scraping, unauthorized clients, and bursts.<\/li>\n<li><strong>Why it fits:<\/strong> Apply consistent rules at a shared API gateway\/load balancer layer.<\/li>\n<li><strong>Example:<\/strong> Restrict methods\/paths, enforce rate limits, block unusual header patterns.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) WAF protections against common web exploits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Automated scanners probe for XSS, SQLi, path traversal, and RCE patterns.<\/li>\n<li><strong>Why it fits:<\/strong> Managed\/preconfigured WAF rules can catch common classes of attacks; custom rules handle app-specific patterns.<\/li>\n<li><strong>Example:<\/strong> Apply a managed WAF profile to <code>\/api\/*<\/code> and stricter rules to <code>\/admin\/*<\/code>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Protecting static content with Cloud CDN + backend buckets<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Attack traffic targets static sites and causes egress\/cache churn.<\/li>\n<li><strong>Why it fits:<\/strong> Attach security policy to CDN-backed origins to reduce abusive requests.<\/li>\n<li><strong>Example:<\/strong> Deny abusive IPs from downloading large files repeatedly.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Reducing cost from abusive traffic to autoscaling backends<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Serverless or autoscaling systems scale up under attack, creating surprise bills.<\/li>\n<li><strong>Why it fits:<\/strong> Block\/limit abusive requests before they trigger autoscaling.<\/li>\n<li><strong>Example:<\/strong> Throttle suspicious clients hitting <code>\/search<\/code> that triggers expensive queries.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Safe rollout of new security controls (preview\/testing)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> New WAF rules can break real users if tuned incorrectly.<\/li>\n<li><strong>Why it fits:<\/strong> Preview\/evaluation modes (where supported) let you observe matches before enforcing.<\/li>\n<li><strong>Example:<\/strong> Run new rules in preview for a week, review logs, then enforce.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Multi-tenant SaaS noisy-neighbor control<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> One tenant\u2019s integration floods the API and affects others.<\/li>\n<li><strong>Why it fits:<\/strong> Rate limits and path-based controls can reduce noisy traffic at the edge.<\/li>\n<li><strong>Example:<\/strong> Rate-limit a tenant-specific path prefix if their client misbehaves.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Incident-response \u201ckill switch\u201d during active attacks<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You need to block traffic quickly without deploying code.<\/li>\n<li><strong>Why it fits:<\/strong> Policy updates propagate faster than app releases and can be automated.<\/li>\n<li><strong>Example:<\/strong> Emergency deny rule for a path under attack; revert after mitigation.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>This section focuses on current, widely used Google Cloud Armor features. Some items are edition-dependent or depend on your load balancer type\u2014verify in official docs for your environment.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Security policies (rule containers)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> A security policy contains a prioritized list of rules.<\/li>\n<li><strong>Why it matters:<\/strong> Policies are your unit of management and reuse across backends.<\/li>\n<li><strong>Practical benefit:<\/strong> Standardize baseline protections across services.<\/li>\n<li><strong>Caveats:<\/strong> Policies must be attached to supported backend services\/buckets; they don\u2019t protect direct VM external IPs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Priority-based rule evaluation<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Rules run in ascending priority order (lower number = higher priority). First matching rule typically applies.<\/li>\n<li><strong>Why it matters:<\/strong> Deterministic outcomes and predictable overrides.<\/li>\n<li><strong>Practical benefit:<\/strong> Put critical allowlists\/denylists at high priority; keep a default catch-all rule at the end.<\/li>\n<li><strong>Caveats:<\/strong> Misordered priorities are a common cause of unexpected blocks.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Custom match expressions for HTTP attributes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Match requests based on attributes like source IP, path, headers, method, query string, etc., using an expression language (CEL-based).<\/li>\n<li><strong>Why it matters:<\/strong> Enables app-aware rules without changing code.<\/li>\n<li><strong>Practical benefit:<\/strong> Restrict <code>\/admin<\/code>, block suspicious user agents, enforce header presence.<\/li>\n<li><strong>Caveats:<\/strong> Typically does not inspect full request body; avoid assuming deep payload visibility. Verify which attributes are available.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) IP allow\/deny controls (CIDR matching)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Allow or deny traffic from specific IPv4\/IPv6 ranges.<\/li>\n<li><strong>Why it matters:<\/strong> A fast, reliable baseline control.<\/li>\n<li><strong>Practical benefit:<\/strong> Block known attackers and allow only trusted networks for sensitive routes.<\/li>\n<li><strong>Caveats:<\/strong> IP reputation changes; NAT\/shared IPs can cause collateral blocks.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Geo-based access control<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Match requests by geographic attributes derived from IP geolocation.<\/li>\n<li><strong>Why it matters:<\/strong> Reduce unwanted traffic and certain fraud patterns.<\/li>\n<li><strong>Practical benefit:<\/strong> Limit access to countries\/regions you operate in.<\/li>\n<li><strong>Caveats:<\/strong> Geo-IP is not perfect; travelers\/VPNs can appear elsewhere.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Rate limiting \/ traffic throttling (where supported)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Limit request rate per key (commonly per source IP) for specific endpoints.<\/li>\n<li><strong>Why it matters:<\/strong> Controls abusive behavior and reduces DDoS impact.<\/li>\n<li><strong>Practical benefit:<\/strong> Protect login, password reset, search, and expensive APIs.<\/li>\n<li><strong>Caveats:<\/strong> Tune carefully to avoid harming NAT\u2019d users. Exact configuration and actions vary\u2014verify in docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Managed \/ preconfigured WAF rule sets<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Provides vendor-managed rule sets to detect common web attack classes (e.g., injection and XSS patterns).<\/li>\n<li><strong>Why it matters:<\/strong> Faster baseline protection than writing every rule yourself.<\/li>\n<li><strong>Practical benefit:<\/strong> Apply a managed WAF profile and iterate based on logs.<\/li>\n<li><strong>Caveats:<\/strong> Rule set names\/versions and tuning knobs change over time. Always validate in a test environment and consult current docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Adaptive protection \/ advanced L7 DDoS features (edition-dependent)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Uses traffic analysis to detect anomalies and help mitigate L7 DDoS and abusive spikes, sometimes generating recommended rules (feature set varies).<\/li>\n<li><strong>Why it matters:<\/strong> Helps when attack patterns shift quickly.<\/li>\n<li><strong>Practical benefit:<\/strong> Reduce manual analysis time during incidents.<\/li>\n<li><strong>Caveats:<\/strong> Typically requires specific editions and has operational workflows to review\/approve suggested mitigations\u2014verify.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Edge enforcement with CDN paths (configuration-dependent)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> In some architectures (for example, when using Cloud CDN), policy enforcement can occur closer to the edge.<\/li>\n<li><strong>Why it matters:<\/strong> Drops unwanted traffic before it consumes cache\/origin resources.<\/li>\n<li><strong>Practical benefit:<\/strong> Better protection for static assets and reduced origin egress.<\/li>\n<li><strong>Caveats:<\/strong> Edge vs backend enforcement depends on your load balancer and CDN configuration\u2014verify supported combinations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Logging, monitoring, and auditability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Generates logs for allowed\/denied\/rate-limited requests (configurable) and captures policy changes in audit logs.<\/li>\n<li><strong>Why it matters:<\/strong> You need evidence and data to tune rules and investigate incidents.<\/li>\n<li><strong>Practical benefit:<\/strong> Build dashboards\/alerts around spikes in denies or specific rule hits.<\/li>\n<li><strong>Caveats:<\/strong> Logging high-volume traffic can be expensive; use sampling and targeted logging where possible.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Policy rollout safety (preview\/evaluation modes where supported)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Lets you observe what a rule would match before enforcing it.<\/li>\n<li><strong>Why it matters:<\/strong> Reduces risk of false positives breaking production.<\/li>\n<li><strong>Practical benefit:<\/strong> Iterative tuning based on real traffic.<\/li>\n<li><strong>Caveats:<\/strong> Feature availability and semantics vary by rule type\u2014verify.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level service architecture<\/h3>\n\n\n\n<p>Google Cloud Armor sits in the request path of supported Google Cloud load balancers and (in certain setups) CDN edges. You do not deploy appliances. Instead:\n1. Client connects to your <strong>Load Balancer frontend<\/strong> (global or regional).\n2. The load balancer evaluates the request against <strong>Google Cloud Armor security policy<\/strong> attached to the targeted backend service\/bucket.\n3. If allowed, the request is routed to the backend (VMs, GKE, Cloud Run, etc.).\n4. If denied or rate-limited, the load balancer returns the configured response.\n5. Logs\/metrics flow to <strong>Cloud Logging<\/strong> and <strong>Cloud Monitoring<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Data plane (requests):<\/strong><\/li>\n<li>Client \u2192 Google Front End (GFE) \/ Load balancer \u2192 Cloud Armor rule evaluation \u2192 Backend (if allowed)<\/li>\n<li><strong>Control plane (configuration):<\/strong><\/li>\n<li>Admin (Console\/gcloud\/API\/Terraform) \u2192 Create\/update policy rules \u2192 Attach policy to backend \u2192 Changes propagate<\/li>\n<li><strong>Observability plane:<\/strong><\/li>\n<li>Load balancer request logs + Cloud Armor outcomes \u2192 Cloud Logging \u2192 Alerts\/dashboards\/exports to SIEM<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related Google Cloud services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud Load Balancing<\/strong>: Primary integration point; policies attach to backend services\/buckets.<\/li>\n<li><strong>Cloud CDN<\/strong>: Common for static content; can reduce origin load when combined with Armor.<\/li>\n<li><strong>Cloud Logging \/ Cloud Monitoring<\/strong>: Logs, metrics, alerting.<\/li>\n<li><strong>Cloud Audit Logs<\/strong>: Tracks policy changes for governance.<\/li>\n<li><strong>Security Command Center (SCC)<\/strong>: Often used for centralized security posture; integration depends on your SCC setup (verify).<\/li>\n<li><strong>reCAPTCHA Enterprise<\/strong>: Used for bot and abuse signals; may integrate with Armor features depending on configuration and tier (verify).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A supported <strong>load balancer<\/strong> and its components (URL maps, target proxies, forwarding rules, backend services\/buckets).<\/li>\n<li>Backends such as <strong>Compute Engine<\/strong>, <strong>GKE<\/strong>, <strong>Cloud Run<\/strong>, <strong>App Engine<\/strong>, or <strong>backend buckets<\/strong> (Cloud Storage).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAM controls<\/strong> who can create\/update policies and attach them to load balancers.<\/li>\n<li>Policies are resources within a project; access is governed by IAM roles such as Compute security administration roles (see prerequisites).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Operates at the application delivery layer of Google Cloud Networking via the load balancer.<\/li>\n<li>Works best as part of a layered defense:<\/li>\n<li>Edge controls (Cloud Armor)<\/li>\n<li>Identity controls (IAP, OAuth, mTLS at app layer, etc.)<\/li>\n<li>Network segmentation (VPC, firewall policies)<\/li>\n<li>Workload security (least privilege, patching, runtime security)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Turn on logging selectively for security rules that need visibility.<\/li>\n<li>Create alerting for sudden changes in denied traffic volume.<\/li>\n<li>Use labels\/naming conventions for policies and rules to support audits.<\/li>\n<li>Restrict who can attach policies to production backends.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  U[User \/ Attacker] --&gt; LB[External HTTP(S) Load Balancer]\n  LB --&gt;|Evaluate rules| CA[Google Cloud Armor Policy]\n  CA --&gt;|Allow| BE[Backend Service&lt;br\/&gt;Cloud Run \/ GKE \/ VMs]\n  CA --&gt;|Deny \/ Rate limit| R[Response to client]\n  LB --&gt; LOG[Cloud Logging]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Edge[Google Edge \/ Front Door]\n    DNS[Cloud DNS] --&gt; LB[External Application Load Balancer]\n    LB --&gt; CA[Google Cloud Armor&lt;br\/&gt;Security Policies]\n    LB --&gt; CDN[Cloud CDN&lt;br\/&gt;(optional)]\n  end\n\n  CA --&gt;|Allowed| UM[URL Map &amp; Routing]\n\n  UM --&gt; B1[Backend Service A&lt;br\/&gt;GKE Ingress \/ NEG]\n  UM --&gt; B2[Backend Service B&lt;br\/&gt;Cloud Run (Serverless NEG)]\n  UM --&gt; BB[Backend Bucket&lt;br\/&gt;Cloud Storage Origin]\n\n  CDN --&gt; BB\n\n  subgraph Observability[Operations &amp; Security]\n    LOG[Cloud Logging] --&gt; SIEM[SIEM Export&lt;br\/&gt;(optional)]\n    MON[Cloud Monitoring] --&gt; AL[Alerting]\n    AUD[Cloud Audit Logs]\n  end\n\n  LB --&gt; LOG\n  CA --&gt; LOG\n  CA --&gt; MON\n  CA --&gt; AUD\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Account\/project\/billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A Google Cloud account with a <strong>project<\/strong> where you can create:<\/li>\n<li>Cloud Run service (for this lab)<\/li>\n<li>Load balancer resources (URL maps, backend services, forwarding rules)<\/li>\n<li>Google Cloud Armor security policies<\/li>\n<li><strong>Billing enabled<\/strong> on the project (load balancing, logging, and Cloud Run can incur costs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles (minimum practical set for this lab)<\/h3>\n\n\n\n<p>You can use a dedicated lab identity, but you must have permissions to:\n&#8211; Deploy Cloud Run:\n  &#8211; <code>roles\/run.admin<\/code>\n  &#8211; <code>roles\/iam.serviceAccountUser<\/code> (if specifying a runtime service account)\n&#8211; Create load balancer resources:\n  &#8211; <code>roles\/compute.loadBalancerAdmin<\/code> (or broader Compute admin roles)\n&#8211; Manage Google Cloud Armor policies:\n  &#8211; <code>roles\/compute.securityAdmin<\/code> (often used for security policies)<\/p>\n\n\n\n<p>Organizations may split duties; in production, restrict who can attach policies to production backends.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">CLI\/SDK\/tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/cloud.google.com\/sdk\/docs\/install\">Google Cloud SDK (<code>gcloud<\/code>)<\/a> installed and authenticated<\/li>\n<li>Optional: <code>curl<\/code> for testing<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Run is regional; pick a region near you (e.g., <code>us-central1<\/code>).<\/li>\n<li>Load balancer and Armor availability depends on load balancer type. External HTTP(S) load balancing is broadly available, but always verify:<\/li>\n<li><a href=\"https:\/\/cloud.google.com\/armor\/docs\">Google Cloud Armor documentation<\/a><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits to be aware of<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Number of forwarding rules, URL maps, backend services<\/li>\n<li>Google Cloud Armor policy and rule quotas<\/li>\n<li>Cloud Logging ingestion volume (cost\/quotas)<\/li>\n<\/ul>\n\n\n\n<p>Quotas change; check:\n&#8211; Google Cloud Console \u2192 IAM &amp; Admin \u2192 Quotas<br\/>\n&#8211; Official quota docs (verify in official docs).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services\/APIs to enable<\/h3>\n\n\n\n<p>For this lab, enable:\n&#8211; Cloud Run API\n&#8211; Compute Engine API (for load balancer resources)\n&#8211; (Optional) Cloud Logging API (usually enabled by default)<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Google Cloud Armor is usage-based, and actual SKUs and costs depend on which features you enable and how much traffic you process. <strong>Do not rely on blog posts for exact numbers<\/strong>; use official pricing.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Official pricing references<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud Armor pricing: https:\/\/cloud.google.com\/armor\/pricing  <\/li>\n<li>Google Cloud Pricing Calculator: https:\/\/cloud.google.com\/products\/calculator<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (high-level)<\/h3>\n\n\n\n<p>Common dimensions you should expect (exact SKUs vary):\n&#8211; <strong>Per-policy and\/or per-rule charges<\/strong>: You may be billed based on the number of active policies\/rules.\n&#8211; <strong>Per-request processing<\/strong>: Charges can apply per number of requests inspected\/enforced by Cloud Armor.\n&#8211; <strong>Advanced feature add-ons<\/strong>: Managed WAF rule sets, adaptive protection, bot management, or threat intelligence features may have separate pricing and\/or require specific editions.<\/p>\n\n\n\n<p>Because Google updates SKUs, <strong>verify the current breakdown<\/strong> on the official pricing page.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<p>Google Cloud Armor may not have a broad always-free tier for meaningful production use; any free allowances (if present) are SKU-specific. <strong>Verify in official pricing<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Cost drivers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Request volume<\/strong>: More requests inspected \u2192 higher cost.<\/li>\n<li><strong>Number of policies\/rules<\/strong>: More granular policies across many services can increase cost.<\/li>\n<li><strong>Logging volume<\/strong>: Enabling detailed logging on high-traffic services can generate significant Cloud Logging ingestion and retention costs.<\/li>\n<li><strong>Cloud Load Balancing and Cloud CDN<\/strong>: Armor is part of an architecture that includes other billable components:<\/li>\n<li>Load balancer forwarding rules, proxying, and data processing<\/li>\n<li>Backend egress, Cloud CDN cache egress\/fill<\/li>\n<li>Cloud Run\/Compute\/GKE compute for allowed traffic<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden\/indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Autoscaling under attack<\/strong>: If Armor is not strict enough, abusive traffic may still reach backends and trigger scaling (especially serverless), increasing compute spend.<\/li>\n<li><strong>Data egress<\/strong>: Serving responses to attack traffic can increase egress costs, even if responses are small.<\/li>\n<li><strong>Operational overhead<\/strong>: Time spent tuning rules and investigating false positives.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Armor itself doesn\u2019t \u201cstore\u201d data, but it influences how much traffic reaches:<\/li>\n<li>Your backends (compute cost)<\/li>\n<li>Your CDN\/origin (cache fill and egress)<\/li>\n<li>Blocking early reduces downstream network egress and compute.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Start with a baseline policy<\/strong> reused across services; avoid duplicating identical rule sets.<\/li>\n<li><strong>Log selectively<\/strong>: Enable logging on key rules or during tuning windows, not everywhere forever.<\/li>\n<li><strong>Use preview modes<\/strong> (where supported) to reduce costly production incidents from false positives.<\/li>\n<li><strong>Use rate limits<\/strong> on expensive endpoints to prevent autoscaling and database overload.<\/li>\n<li><strong>Protect caching paths<\/strong>: Combine Cloud CDN + Armor to reduce origin traffic.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (conceptual)<\/h3>\n\n\n\n<p>A small test environment might include:\n&#8211; 1 external HTTP load balancer\n&#8211; 1 backend service (Cloud Run)\n&#8211; 1 Cloud Armor policy with a handful of rules\n&#8211; Low request volume (developer testing)<\/p>\n\n\n\n<p>Your costs will be dominated by load balancer hourly\/processing and Cloud Run invocations, with smaller incremental Armor charges. <strong>Use the pricing calculator<\/strong> and plug in:\n&#8211; Estimated requests\/month\n&#8211; Number of policies\/rules\n&#8211; Logging volume<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>For a production API receiving high request volume:\n&#8211; Per-request Armor costs can become significant.\n&#8211; Logging can become a major line item if not controlled.\n&#8211; CDN and load balancer data processing and egress often rival or exceed Armor costs.\n&#8211; Advanced features (managed WAF, adaptive protection) can add cost but may reduce incident impact and backend scaling costs\u2014evaluate via ROI rather than SKU alone.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab builds a real, minimal architecture:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A <strong>Cloud Run<\/strong> service as the backend<\/li>\n<li>An <strong>External HTTP Load Balancer<\/strong> in front (required so Google Cloud Armor can enforce)<\/li>\n<li>A <strong>Google Cloud Armor<\/strong> security policy attached to the backend service<\/li>\n<li>A few practical rules (deny <code>\/admin<\/code>, deny your IP as a test, and enable logging)<\/li>\n<\/ul>\n\n\n\n<p>This is designed to be low-cost, but it still creates load balancer resources that may incur charges.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Deploy a simple public service behind an external HTTP load balancer and protect it with Google Cloud Armor rules, then validate that rules are enforced and logged.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Set environment variables and enable APIs\n2. Deploy a Cloud Run service (<code>hello-armor<\/code>)\n3. Create a serverless NEG and external HTTP load balancer resources\n4. Create and attach a Google Cloud Armor security policy\n5. Test allowed and denied requests\n6. Review logs\n7. Clean up all resources<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Set up your environment<\/h3>\n\n\n\n<p>1) Choose a project and region:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export PROJECT_ID=\"YOUR_PROJECT_ID\"\nexport REGION=\"us-central1\"\ngcloud config set project \"${PROJECT_ID}\"\ngcloud config set run\/region \"${REGION}\"\n<\/code><\/pre>\n\n\n\n<p>2) Enable required APIs:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services enable run.googleapis.com compute.googleapis.com\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> APIs are enabled successfully.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Deploy a Cloud Run service (public)<\/h3>\n\n\n\n<p>Deploy a minimal HTTP service. Cloud Run provides a public URL, but we will place it behind a load balancer for Cloud Armor enforcement.<\/p>\n\n\n\n<pre><code class=\"language-bash\">export SERVICE_NAME=\"hello-armor\"\n\ngcloud run deploy \"${SERVICE_NAME}\" \\\n  --image=\"us-docker.pkg.dev\/cloudrun\/container\/hello\" \\\n  --allow-unauthenticated \\\n  --region=\"${REGION}\"\n<\/code><\/pre>\n\n\n\n<p>Get the Cloud Run service URL:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export RUN_URL=\"$(gcloud run services describe \"${SERVICE_NAME}\" --region \"${REGION}\" --format='value(status.url)')\"\necho \"${RUN_URL}\"\n<\/code><\/pre>\n\n\n\n<p>Test it directly:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -i \"${RUN_URL}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> HTTP 200 with a hello response.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create a serverless NEG (Network Endpoint Group)<\/h3>\n\n\n\n<p>External Application Load Balancers route to serverless backends via <strong>serverless NEGs<\/strong>.<\/p>\n\n\n\n<pre><code class=\"language-bash\">export NEG_NAME=\"neg-${SERVICE_NAME}\"\n\ngcloud compute network-endpoint-groups create \"${NEG_NAME}\" \\\n  --region=\"${REGION}\" \\\n  --network-endpoint-type=serverless \\\n  --cloud-run-service=\"${SERVICE_NAME}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The NEG is created in your chosen region.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create an external HTTP load balancer and backend service<\/h3>\n\n\n\n<p>We\u2019ll create the core load balancing resources using <code>gcloud<\/code>. This uses the modern external application load balancing scheme.<\/p>\n\n\n\n<p>1) Create a backend service:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export BACKEND_SERVICE=\"bs-${SERVICE_NAME}\"\n\ngcloud compute backend-services create \"${BACKEND_SERVICE}\" \\\n  --global \\\n  --load-balancing-scheme=EXTERNAL_MANAGED \\\n  --protocol=HTTP\n<\/code><\/pre>\n\n\n\n<p>2) Add the serverless NEG as a backend:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute backend-services add-backend \"${BACKEND_SERVICE}\" \\\n  --global \\\n  --network-endpoint-group=\"${NEG_NAME}\" \\\n  --network-endpoint-group-region=\"${REGION}\"\n<\/code><\/pre>\n\n\n\n<p>3) Create a URL map:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export URL_MAP=\"um-${SERVICE_NAME}\"\n\ngcloud compute url-maps create \"${URL_MAP}\" \\\n  --default-service=\"${BACKEND_SERVICE}\"\n<\/code><\/pre>\n\n\n\n<p>4) Create a target HTTP proxy:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export HTTP_PROXY=\"hp-${SERVICE_NAME}\"\n\ngcloud compute target-http-proxies create \"${HTTP_PROXY}\" \\\n  --url-map=\"${URL_MAP}\"\n<\/code><\/pre>\n\n\n\n<p>5) Reserve a global IP address:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export IP_NAME=\"ip-${SERVICE_NAME}\"\n\ngcloud compute addresses create \"${IP_NAME}\" --global\nexport LB_IP=\"$(gcloud compute addresses describe \"${IP_NAME}\" --global --format='value(address)')\"\necho \"${LB_IP}\"\n<\/code><\/pre>\n\n\n\n<p>6) Create a global forwarding rule on port 80:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export FWD_RULE=\"fr-${SERVICE_NAME}\"\n\ngcloud compute forwarding-rules create \"${FWD_RULE}\" \\\n  --global \\\n  --load-balancing-scheme=EXTERNAL_MANAGED \\\n  --address=\"${IP_NAME}\" \\\n  --target-http-proxy=\"${HTTP_PROXY}\" \\\n  --ports=80\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You have a public IP serving your Cloud Run app via the load balancer.<\/p>\n\n\n\n<p>It can take a few minutes for provisioning. Test:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -i \"http:\/\/${LB_IP}\/\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> HTTP 200 from the hello service.<\/p>\n\n\n\n<p>If you get a 404\/502 initially, wait a minute and retry.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Create a Google Cloud Armor security policy<\/h3>\n\n\n\n<p>1) Create a security policy:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export ARMOR_POLICY=\"sp-${SERVICE_NAME}\"\n\ngcloud compute security-policies create \"${ARMOR_POLICY}\" \\\n  --description=\"Lab policy for ${SERVICE_NAME}\"\n<\/code><\/pre>\n\n\n\n<p>2) (Optional but recommended) Review the default rule:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute security-policies describe \"${ARMOR_POLICY}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> A policy exists, typically with a default allow rule at the lowest priority end.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Add a rule to deny access to <code>\/admin<\/code><\/h3>\n\n\n\n<p>Create a rule that denies any request whose path starts with <code>\/admin<\/code>.<\/p>\n\n\n\n<blockquote>\n<p>Note: Google Cloud Armor uses a CEL-based expression language. If the expression function names differ in your environment, <strong>verify the correct expression syntax in official docs<\/strong> and adjust.<\/p>\n<\/blockquote>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute security-policies rules create 1000 \\\n  --security-policy=\"${ARMOR_POLICY}\" \\\n  --expression=\"request.path.matches('\/admin.*')\" \\\n  --action=deny-403 \\\n  --description=\"Deny admin paths\" \\\n  --enable-logging\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Rule priority 1000 is created.<\/p>\n\n\n\n<p>Attach the policy to the backend service:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute backend-services update \"${BACKEND_SERVICE}\" \\\n  --global \\\n  --security-policy=\"${ARMOR_POLICY}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The backend service now enforces this Cloud Armor policy.<\/p>\n\n\n\n<p>Test both routes:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -i \"http:\/\/${LB_IP}\/\"\ncurl -i \"http:\/\/${LB_IP}\/admin\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong>\n&#8211; <code>\/<\/code> returns HTTP 200\n&#8211; <code>\/admin<\/code> returns HTTP 403 (denied by Cloud Armor)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Add an IP-based deny rule (test rule)<\/h3>\n\n\n\n<p>This rule blocks your current public IP to demonstrate IP matching.<\/p>\n\n\n\n<p>1) Get your public IP from a trusted source (example uses <code>ifconfig.me<\/code>; use your preferred method):<\/p>\n\n\n\n<pre><code class=\"language-bash\">export MY_IP=\"$(curl -s ifconfig.me)\"\necho \"${MY_IP}\"\n<\/code><\/pre>\n\n\n\n<p>2) Create a deny rule for that IP:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute security-policies rules create 900 \\\n  --security-policy=\"${ARMOR_POLICY}\" \\\n  --expression=\"inIpRange(origin.ip, '${MY_IP}\/32')\" \\\n  --action=deny-403 \\\n  --description=\"Deny my IP for testing\" \\\n  --enable-logging\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Rule priority 900 is created (higher precedence than 1000).<\/p>\n\n\n\n<p>Now test:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -i \"http:\/\/${LB_IP}\/\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> HTTP 403 (your IP is denied).<\/p>\n\n\n\n<p>Remove or disable this rule after confirming. To delete:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute security-policies rules delete 900 \\\n  --security-policy=\"${ARMOR_POLICY}\" \\\n  --quiet\n<\/code><\/pre>\n\n\n\n<p>Test again:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -i \"http:\/\/${LB_IP}\/\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Back to HTTP 200.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: Review logs for Cloud Armor enforcement<\/h3>\n\n\n\n<p>You enabled logging on specific rules. You can review logs in:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud Console \u2192 <strong>Logging<\/strong> \u2192 <strong>Logs Explorer<\/strong><\/li>\n<li>Filter by load balancer resource type and look for Cloud Armor outcomes.<\/li>\n<\/ul>\n\n\n\n<p>A starting point filter (may need adjustment based on logging fields and load balancer type; verify in your logs):\n&#8211; Resource type often relates to HTTP load balancing.\n&#8211; Look for fields referencing enforced security policy and rule.<\/p>\n\n\n\n<p>You can also try a <code>gcloud logging read<\/code> query, but field names can vary. Start broad:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud logging read \\\n  'resource.type=(\"http_load_balancer\" OR \"https_load_balancer\")' \\\n  --limit=20 \\\n  --format=json\n<\/code><\/pre>\n\n\n\n<p>Then refine based on what you see in returned entries.<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> You find log entries showing requests to <code>\/admin<\/code> being denied and allowed requests to <code>\/<\/code> being served.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use this checklist:<\/p>\n\n\n\n<p>1) Load balancer serves your app:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -i \"http:\/\/${LB_IP}\/\"\n<\/code><\/pre>\n\n\n\n<p>Expected: <strong>HTTP 200<\/strong><\/p>\n\n\n\n<p>2) Cloud Armor blocks admin paths:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -i \"http:\/\/${LB_IP}\/admin\"\n<\/code><\/pre>\n\n\n\n<p>Expected: <strong>HTTP 403<\/strong><\/p>\n\n\n\n<p>3) Cloud Armor logs exist for denied requests:\n&#8211; Logs Explorer shows entries corresponding to the deny rule (priority 1000), if logging is enabled and sampling\/volume allows.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common issues and fixes:<\/p>\n\n\n\n<p>1) <strong>LB IP returns 404 or 502<\/strong>\n&#8211; Wait 2\u20135 minutes; provisioning can take time.\n&#8211; Verify the forwarding rule points to the correct target proxy.\n&#8211; Confirm the URL map default service is your backend service.\n&#8211; Confirm the backend service has the NEG attached.<\/p>\n\n\n\n<p>2) <strong>Cloud Armor rule expression fails to create<\/strong>\n&#8211; Error may indicate unsupported expression syntax.\n&#8211; Use the console rule builder or verify expression examples in official docs:\n  https:\/\/cloud.google.com\/armor\/docs\n&#8211; Try simpler expressions (e.g., match only on path) before adding IP functions.<\/p>\n\n\n\n<p>3) <strong>Policy attaches but denies don\u2019t happen<\/strong>\n&#8211; Confirm the policy is attached to the correct backend service:\n  <code>bash\n  gcloud compute backend-services describe \"${BACKEND_SERVICE}\" --global<\/code>\n&#8211; Confirm rule priority ordering (lower number wins).\n&#8211; Ensure you are testing through the load balancer IP, not the direct Cloud Run URL.<\/p>\n\n\n\n<p>4) <strong>No logs show up<\/strong>\n&#8211; Logging must be enabled per rule (as done with <code>--enable-logging<\/code>).\n&#8211; Some environments sample logs; generate a few requests and wait.\n&#8211; Check Cloud Logging permissions and exclusions\/sinks.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>Delete resources to avoid ongoing charges.<\/p>\n\n\n\n<p>1) Delete forwarding rule:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute forwarding-rules delete \"${FWD_RULE}\" --global --quiet\n<\/code><\/pre>\n\n\n\n<p>2) Delete target HTTP proxy:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute target-http-proxies delete \"${HTTP_PROXY}\" --quiet\n<\/code><\/pre>\n\n\n\n<p>3) Delete URL map:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute url-maps delete \"${URL_MAP}\" --quiet\n<\/code><\/pre>\n\n\n\n<p>4) Delete backend service:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute backend-services delete \"${BACKEND_SERVICE}\" --global --quiet\n<\/code><\/pre>\n\n\n\n<p>5) Delete NEG:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute network-endpoint-groups delete \"${NEG_NAME}\" --region=\"${REGION}\" --quiet\n<\/code><\/pre>\n\n\n\n<p>6) Release global IP:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute addresses delete \"${IP_NAME}\" --global --quiet\n<\/code><\/pre>\n\n\n\n<p>7) Delete Cloud Armor policy:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute security-policies delete \"${ARMOR_POLICY}\" --quiet\n<\/code><\/pre>\n\n\n\n<p>8) Delete Cloud Run service:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud run services delete \"${SERVICE_NAME}\" --region=\"${REGION}\" --quiet\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Put all public apps behind a supported load balancer<\/strong> so Armor policies can be consistently applied.<\/li>\n<li><strong>Use separate policies by risk domain<\/strong>:<\/li>\n<li>A shared baseline policy (common threats)<\/li>\n<li>App-specific policies (business logic endpoints, admin paths)<\/li>\n<li><strong>Layer defenses<\/strong>: Combine Armor with CDN caching (where appropriate), backend authentication, and VPC controls.<\/li>\n<li><strong>Use multi-region backends<\/strong> for resilience; Armor protects the front door but doesn\u2019t replace HA.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Separate duties<\/strong>:<\/li>\n<li>Security team can manage security policies (<code>compute.securityAdmin<\/code>)<\/li>\n<li>Platform team manages load balancers (<code>compute.loadBalancerAdmin<\/code>)<\/li>\n<li><strong>Restrict who can attach policies<\/strong> to production backend services. Attaching\/removing a policy is a high-impact change.<\/li>\n<li><strong>Use least privilege<\/strong> and avoid broad roles in production.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Avoid \u201clog everything\u201d<\/strong> on high-traffic services; enable logging for:<\/li>\n<li>High-signal deny rules<\/li>\n<li>Temporary tuning windows<\/li>\n<li><strong>Use Cloud CDN for static assets<\/strong> and protect it with Armor to reduce origin and backend spend.<\/li>\n<li><strong>Rate-limit expensive endpoints<\/strong> (search, auth, report exports) to prevent scaling and database load.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Keep rules maintainable<\/strong>: A smaller, well-organized rule set is easier to audit and tune.<\/li>\n<li><strong>Use priority ordering intentionally<\/strong>:<\/li>\n<li>Allow known-good traffic first where appropriate (e.g., health checks, trusted IPs)<\/li>\n<li>Deny known-bad traffic early<\/li>\n<li>Default allow\/deny at the end based on your security posture<\/li>\n<li><strong>Avoid overly broad regex<\/strong> that might match legitimate requests.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Use preview\/evaluation<\/strong> (when supported) before enforcing new WAF rules.<\/li>\n<li><strong>Have an incident playbook<\/strong>:<\/li>\n<li>How to add emergency deny rules<\/li>\n<li>How to roll back changes quickly<\/li>\n<li>Who approves changes during an incident<\/li>\n<li><strong>Automate changes<\/strong> with change management (CI\/CD + approvals).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Dashboards and alerts<\/strong>:<\/li>\n<li>Alert on spikes in denied traffic<\/li>\n<li>Track top source IPs\/countries\/user agents for denied requests<\/li>\n<li><strong>Export logs to SIEM<\/strong> using Logging sinks if required.<\/li>\n<li><strong>Tag and name policies consistently<\/strong> (environment, app, owner, purpose).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<p>A practical convention:\n&#8211; Policy: <code>sp-&lt;env&gt;-&lt;app&gt;-&lt;purpose&gt;<\/code>\n&#8211; Rules: Include description + ticket reference\n&#8211; Use labels where supported (for related resources like load balancer components)<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Managed via <strong>IAM<\/strong> and enforced by the load balancer.<\/li>\n<li>Use:<\/li>\n<li><code>roles\/compute.securityAdmin<\/code> for policy management<\/li>\n<li>Separate roles for load balancer modification<\/li>\n<li>Protect production policies with:<\/li>\n<li>Approval workflows<\/li>\n<li>Audit log monitoring<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Armor is part of the load balancer path.<\/li>\n<li>For HTTPS:<\/li>\n<li>TLS terminates at the load balancer (or uses end-to-end patterns depending on design).<\/li>\n<li>Armor evaluates requests after termination where it can see HTTP attributes.<\/li>\n<li>For pure HTTP (as in the lab), traffic is unencrypted\u2014use HTTPS in production.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Armor protects <strong>public entry points<\/strong> behind supported load balancers.<\/li>\n<li>It does not replace:<\/li>\n<li>VPC firewall rules<\/li>\n<li>Private service access controls<\/li>\n<li>Application authentication\/authorization<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Do not put secrets into headers\/query strings expecting Armor to \u201chide\u201d them.<\/li>\n<li>Avoid logging sensitive headers or query parameters via application logs.<\/li>\n<li>Use Secret Manager and application-layer authentication patterns.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud Audit Logs<\/strong>: Track who changed policies and attachments.<\/li>\n<li><strong>Cloud Logging<\/strong>: Track enforcement actions. Use retention policies and sinks for compliance.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Armor can support compliance goals (e.g., baseline protections, logging), but compliance typically also requires:<\/li>\n<li>Identity controls and MFA<\/li>\n<li>Secure SDLC and vulnerability management<\/li>\n<li>Data governance and encryption<\/li>\n<li>Incident response procedures<\/li>\n<li>Geo restrictions can help but are not a complete compliance control.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Assuming Armor protects traffic that bypasses the load balancer (direct VM IP access).<\/li>\n<li>Enforcing strict rules without preview\/testing, causing outages.<\/li>\n<li>Over-blocking NAT\u2019d users with aggressive per-IP rate limits.<\/li>\n<li>Not logging key deny rules, leaving no evidence during incidents.<\/li>\n<li>Letting too many users modify policies and attachments.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use HTTPS load balancing for production.<\/li>\n<li>Implement a baseline policy:<\/li>\n<li>Deny obvious malicious patterns<\/li>\n<li>Rate-limit sensitive endpoints<\/li>\n<li>Enable logging for deny rules<\/li>\n<li>Add app-specific protections:<\/li>\n<li><code>\/admin<\/code> allowlist<\/li>\n<li>Known partner IP allowlists for partner APIs<\/li>\n<li>Integrate with centralized monitoring and a SIEM where required.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Always confirm the latest support matrix and feature behavior in official docs, because this area changes.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitations \/ constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Attachment constraint:<\/strong> Google Cloud Armor applies when traffic flows through supported Google Cloud load balancers \/ backend buckets. It is not a general-purpose VPC firewall.<\/li>\n<li><strong>Protocol scope:<\/strong> Primarily designed for HTTP(S) application traffic; non-HTTP protocols require different controls or specific supported proxy load balancers (verify).<\/li>\n<li><strong>Inspection scope:<\/strong> Typically matches on request metadata (path\/headers\/query\/etc.). Do not assume full request body inspection.<\/li>\n<li><strong>False positives:<\/strong> WAF-style rules can block legitimate traffic if not tuned.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Limits on number of policies and rules per project (varies; verify).<\/li>\n<li>Load balancer resource quotas also apply.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Regional constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Behavior differs between global vs regional load balancers and between classic vs \u201cexternal managed\u201d application load balancing.<\/li>\n<li>Some features may only be available for certain load balancer types or tiers\u2014verify.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>High request volumes can create significant per-request charges.<\/li>\n<li>Logging can be expensive at scale.<\/li>\n<li>Backend autoscaling costs can dwarf Armor costs if you don\u2019t block effectively.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Some load balancer types or architectures may not support all rule actions (rate limiting, redirects, edge enforcement).<\/li>\n<li>CDN + Armor behavior depends on where enforcement occurs (edge vs backend); validate with testing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Rule priority mistakes cause unexpected blocks or bypasses.<\/li>\n<li>Emergency changes during an incident can create later tech debt\u2014document and revert cleanly.<\/li>\n<li>If you only test via the backend URL (e.g., Cloud Run direct URL), you are bypassing Armor and will think it \u201cdoesn\u2019t work.\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Moving from another WAF (Cloudflare, F5, AWS WAF) requires:<\/li>\n<li>Translating rules and semantics<\/li>\n<li>Validating behavior differences (header normalization, regex differences)<\/li>\n<li>Planning for staged rollout and monitoring<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Nearest services in Google Cloud<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>VPC firewall rules \/ hierarchical firewall policies<\/strong>: Network-layer controls for VMs and subnets; not a WAF.<\/li>\n<li><strong>Cloud IDS<\/strong>: Detects threats within VPC traffic; does not enforce HTTP WAF rules at the edge.<\/li>\n<li><strong>Identity-Aware Proxy (IAP)<\/strong>: Identity-based access control for apps; complements Armor (identity vs request filtering).<\/li>\n<li><strong>reCAPTCHA Enterprise<\/strong>: Bot detection\/abuse signals; can complement Armor for bot mitigation (verify integration capabilities).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Nearest services in other clouds<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS WAF + AWS Shield \/ Shield Advanced<\/strong><\/li>\n<li><strong>Azure Web Application Firewall + Azure DDoS Protection<\/strong><\/li>\n<li>These offer similar patterns: attach policies to edge\/load balancers and enforce WAF\/DDoS controls.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Open-source or self-managed alternatives<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>ModSecurity + OWASP CRS<\/strong> on NGINX\/Envoy\/Apache<\/li>\n<li><strong>NGINX App Protect<\/strong> (commercial)<\/li>\n<li>Pros: full control and portability  <\/li>\n<li>Cons: operational overhead, scaling, patching, signature updates, global distribution complexity<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Google Cloud Armor<\/td>\n<td>Google Cloud apps behind supported load balancers\/CDN<\/td>\n<td>Managed, integrated with Google Cloud Networking, policy-based enforcement, logging\/audit<\/td>\n<td>Limited to supported attachment points; feature availability depends on LB type\/edition<\/td>\n<td>You want managed edge\/WAF-style controls on Google Cloud<\/td>\n<\/tr>\n<tr>\n<td>VPC firewall rules \/ hierarchical firewall policies (Google Cloud)<\/td>\n<td>Network-layer access control for VMs and VPC<\/td>\n<td>Simple, fast L3\/L4 controls, broad coverage inside VPC<\/td>\n<td>Not HTTP-aware; doesn\u2019t stop app-layer attacks<\/td>\n<td>You need subnet\/VM traffic controls and segmentation<\/td>\n<\/tr>\n<tr>\n<td>Cloud IDS (Google Cloud)<\/td>\n<td>Detecting threats in VPC traffic<\/td>\n<td>Deep detection and visibility inside the network<\/td>\n<td>Detection rather than edge enforcement; separate workflows<\/td>\n<td>You need IDS capabilities in addition to edge protection<\/td>\n<\/tr>\n<tr>\n<td>IAP (Google Cloud)<\/td>\n<td>Identity-based access to internal apps<\/td>\n<td>Strong authN\/authZ in front of apps<\/td>\n<td>Not a WAF; not meant for public anonymous sites<\/td>\n<td>You need user identity gating for web apps<\/td>\n<\/tr>\n<tr>\n<td>Cloudflare WAF \/ similar edge providers<\/td>\n<td>Multi-cloud and internet edge control<\/td>\n<td>Very broad edge network, mature bot tooling<\/td>\n<td>Adds external dependency; integration complexity<\/td>\n<td>You need multi-cloud edge\/WAF or already use that CDN<\/td>\n<\/tr>\n<tr>\n<td>AWS WAF + Shield \/ Azure WAF + DDoS<\/td>\n<td>Workloads primarily in those clouds<\/td>\n<td>Native integration and managed rules<\/td>\n<td>Cloud-specific; portability challenges<\/td>\n<td>Your primary workloads run on AWS\/Azure<\/td>\n<\/tr>\n<tr>\n<td>Self-managed ModSecurity\/NGINX WAF<\/td>\n<td>Maximum control\/customization<\/td>\n<td>Portable, customizable, deep tuning<\/td>\n<td>Operational burden, scaling, patching<\/td>\n<td>You must meet bespoke requirements and can operate it reliably<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: Global e-commerce platform<\/h3>\n\n\n\n<p><strong>Problem<\/strong>\nA global e-commerce company runs a multi-region storefront and checkout APIs on Google Cloud. They experience:\n&#8211; Constant scanning (XSS\/SQLi probes)\n&#8211; Periodic L7 DDoS spikes during promotions\n&#8211; Credential stuffing against login endpoints<\/p>\n\n\n\n<p><strong>Proposed architecture<\/strong>\n&#8211; External Application Load Balancer (global)\n&#8211; Cloud CDN for static assets\n&#8211; Google Cloud Armor:\n  &#8211; Baseline policy: managed WAF protections (where licensed), deny known-bad IPs, geo restrictions for non-operational regions\n  &#8211; Rate limits: <code>\/login<\/code>, <code>\/password-reset<\/code>, <code>\/api\/checkout<\/code>\n  &#8211; Custom rules: protect <code>\/admin<\/code> by IP allowlist and header requirements\n&#8211; Backends:\n  &#8211; GKE for storefront services\n  &#8211; Cloud Run for some APIs\n&#8211; Observability:\n  &#8211; Cloud Logging sinks to SIEM\n  &#8211; Monitoring alerts on deny spikes and rate-limit triggers\n&#8211; Governance:\n  &#8211; Separate IAM for security policy authors vs load balancer operators<\/p>\n\n\n\n<p><strong>Why Google Cloud Armor was chosen<\/strong>\n&#8211; Native enforcement in Google Cloud Networking and load balancing path\n&#8211; Centralized policies across multiple backends\n&#8211; Operational speed for incident response without deploying appliances<\/p>\n\n\n\n<p><strong>Expected outcomes<\/strong>\n&#8211; Reduced backend load during attacks\n&#8211; Faster mitigation response time\n&#8211; Improved visibility into attack patterns via logs and dashboards\n&#8211; Lower risk of autoscaling cost spikes<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: B2B SaaS API<\/h3>\n\n\n\n<p><strong>Problem<\/strong>\nA small SaaS team exposes a public API behind Cloud Run. A partner integration accidentally sends too many requests and causes latency for all tenants.<\/p>\n\n\n\n<p><strong>Proposed architecture<\/strong>\n&#8211; External HTTP(S) load balancer in front of Cloud Run (serverless NEG)\n&#8211; Google Cloud Armor policy:\n  &#8211; Rate limit for <code>\/api\/*<\/code> and stricter limits for <code>\/api\/search<\/code>\n  &#8211; Deny rules for obvious scanning paths\n  &#8211; Allowlist for admin tools (founder\u2019s IP + VPN range)\n&#8211; Basic monitoring and logs in Cloud Logging with alerts<\/p>\n\n\n\n<p><strong>Why Google Cloud Armor was chosen<\/strong>\n&#8211; Minimal operational overhead versus self-managed WAF\n&#8211; Quick controls (rate limiting) without rewriting application logic\n&#8211; Easy to attach to the load balancer front door<\/p>\n\n\n\n<p><strong>Expected outcomes<\/strong>\n&#8211; Stabilized latency under partner bursts\n&#8211; Fewer outages from abusive clients\n&#8211; Clearer audit trail and faster incident response<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Google Cloud Armor the same as a VPC firewall?<\/strong><br\/>\nNo. VPC firewall rules control traffic at the network layer for VMs and subnets. Google Cloud Armor is enforced in the request path of supported load balancers\/CDN configurations and is designed for application-layer protections.<\/p>\n\n\n\n<p>2) <strong>Do I need a load balancer to use Google Cloud Armor?<\/strong><br\/>\nTypically yes. Cloud Armor policies are attached to supported backend services or backend buckets used by Cloud Load Balancing\/Cloud CDN. If traffic bypasses the load balancer, Armor won\u2019t see it.<\/p>\n\n\n\n<p>3) <strong>Can Google Cloud Armor protect Cloud Run?<\/strong><br\/>\nYes, when Cloud Run is placed behind a supported external HTTP(S) load balancer (commonly using a serverless NEG), as shown in the lab.<\/p>\n\n\n\n<p>4) <strong>Can Google Cloud Armor protect GKE?<\/strong><br\/>\nYes, if your GKE services are behind supported Google Cloud load balancing (for example via Ingress\/NEGs). Exact setup depends on your GKE ingress approach.<\/p>\n\n\n\n<p>5) <strong>Does Google Cloud Armor stop DDoS attacks automatically?<\/strong><br\/>\nIt helps significantly, especially for applications behind Google\u2019s edge and load balancing. For advanced L7 DDoS workflows and adaptive features, edition\/tier matters\u2014verify in official docs.<\/p>\n\n\n\n<p>6) <strong>Does it inspect request bodies?<\/strong><br\/>\nDo not assume full request body inspection. Cloud Armor commonly matches on request metadata (path, headers, query, IP, geo). Verify inspection capabilities in official docs for your use case.<\/p>\n\n\n\n<p>7) <strong>What\u2019s the difference between custom rules and managed WAF rules?<\/strong><br\/>\nCustom rules are written by you (e.g., match specific paths, headers, IP ranges). Managed WAF rules are vendor-maintained rule sets designed to detect common attack classes. Managed rules can reduce effort but require tuning.<\/p>\n\n\n\n<p>8) <strong>How do I avoid blocking real users (false positives)?<\/strong><br\/>\nUse preview\/evaluation modes where supported, start with logging, roll out gradually, and monitor denies. Tune rules based on observed legitimate traffic patterns.<\/p>\n\n\n\n<p>9) <strong>Can I rate-limit only one endpoint (like <code>\/login<\/code>)?<\/strong><br\/>\nYes, rate limiting can be scoped to a path match, depending on load balancer type and supported rule actions. Verify configuration details in the docs for your environment.<\/p>\n\n\n\n<p>10) <strong>How quickly do policy changes take effect?<\/strong><br\/>\nPropagation is generally fast but not instantaneous. For incident response, test changes and monitor logs to confirm enforcement.<\/p>\n\n\n\n<p>11) <strong>Does Google Cloud Armor replace reCAPTCHA?<\/strong><br\/>\nNo. They solve related but different problems. reCAPTCHA focuses on user interaction and bot detection; Armor is edge policy enforcement. They can be complementary; verify integration patterns.<\/p>\n\n\n\n<p>12) <strong>Where do Cloud Armor logs appear?<\/strong><br\/>\nTypically in Cloud Logging associated with load balancer request logs and security policy outcomes (field names vary). Ensure rule logging is enabled.<\/p>\n\n\n\n<p>13) <strong>What response codes can I return when denying?<\/strong><br\/>\nCommon options include returning 403 (forbidden). Additional deny\/redirect actions may exist depending on features\u2014verify in official docs and gcloud help output.<\/p>\n\n\n\n<p>14) <strong>Can I apply one policy to many services?<\/strong><br\/>\nYes. A single policy can be attached to multiple supported backends, which is useful for standard baselines.<\/p>\n\n\n\n<p>15) <strong>Is Google Cloud Armor global or regional?<\/strong><br\/>\nPolicies are managed at the project level. Enforcement location depends on load balancer type (global vs regional) and configuration. Confirm your architecture in the official support matrix.<\/p>\n\n\n\n<p>16) <strong>How do I test Cloud Armor locally?<\/strong><br\/>\nYou generally can\u2019t \u201crun it locally.\u201d Test via a staging environment and send requests through the load balancer IP\/hostname so Armor evaluates them.<\/p>\n\n\n\n<p>17) <strong>What\u2019s the biggest operational mistake with Cloud Armor?<\/strong><br\/>\nForgetting that direct backend access bypasses Armor. Ensure your architecture forces traffic through the load balancer (and restrict direct access where possible).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Google Cloud Armor<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Google Cloud Armor docs \u2014 https:\/\/cloud.google.com\/armor\/docs<\/td>\n<td>Authoritative feature descriptions, rule language, supported load balancers, and how-to guides<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>Google Cloud Armor pricing \u2014 https:\/\/cloud.google.com\/armor\/pricing<\/td>\n<td>Current SKUs, pricing dimensions, and edition details<\/td>\n<\/tr>\n<tr>\n<td>Pricing tool<\/td>\n<td>Google Cloud Pricing Calculator \u2014 https:\/\/cloud.google.com\/products\/calculator<\/td>\n<td>Model costs for requests, policies\/rules, and related services<\/td>\n<\/tr>\n<tr>\n<td>Architecture guidance<\/td>\n<td>Google Cloud Architecture Center \u2014 https:\/\/cloud.google.com\/architecture<\/td>\n<td>Reference architectures for load balancing, edge security, and web app protection<\/td>\n<\/tr>\n<tr>\n<td>Load balancing docs<\/td>\n<td>Cloud Load Balancing docs \u2014 https:\/\/cloud.google.com\/load-balancing\/docs<\/td>\n<td>Required to understand attachment points (backend services\/buckets) and request flow<\/td>\n<\/tr>\n<tr>\n<td>Cloud CDN docs<\/td>\n<td>Cloud CDN docs \u2014 https:\/\/cloud.google.com\/cdn\/docs<\/td>\n<td>Useful when protecting cached\/static content and understanding edge\/origin behavior<\/td>\n<\/tr>\n<tr>\n<td>Logging docs<\/td>\n<td>Cloud Logging docs \u2014 https:\/\/cloud.google.com\/logging\/docs<\/td>\n<td>Build queries, alerts, and exports for Cloud Armor-related logs<\/td>\n<\/tr>\n<tr>\n<td>Cloud Run + LB patterns<\/td>\n<td>Cloud Run docs \u2014 https:\/\/cloud.google.com\/run\/docs<\/td>\n<td>Guides for serverless NEGs and fronting Cloud Run with load balancing<\/td>\n<\/tr>\n<tr>\n<td>Official videos<\/td>\n<td>Google Cloud Tech YouTube \u2014 https:\/\/www.youtube.com\/@googlecloudtech<\/td>\n<td>Often includes networking and security deep dives (search within channel for \u201cCloud Armor\u201d)<\/td>\n<\/tr>\n<tr>\n<td>Samples (official\/trusted)<\/td>\n<td>GoogleCloudPlatform GitHub \u2014 https:\/\/github.com\/GoogleCloudPlatform<\/td>\n<td>Find load balancing and security policy automation examples (verify relevance to Cloud Armor)<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, platform teams<\/td>\n<td>DevOps, cloud operations, CI\/CD, fundamentals that support Cloud Armor deployments<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Beginners to intermediate engineers<\/td>\n<td>SCM\/DevOps foundations, process and tooling that complement cloud networking\/security<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud engineers and operations teams<\/td>\n<td>Cloud operations practices, monitoring, and operational readiness<\/td>\n<td>Check website<\/td>\n<td>https:\/\/cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, reliability engineers<\/td>\n<td>SRE practices, incident response, observability\u2014useful for operating Cloud Armor<\/td>\n<td>Check website<\/td>\n<td>https:\/\/sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops and platform teams exploring AIOps<\/td>\n<td>Monitoring automation and operational analytics concepts<\/td>\n<td>Check website<\/td>\n<td>https:\/\/aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site Name<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud training content (verify offerings)<\/td>\n<td>Engineers looking for guided learning resources<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training (verify course catalog)<\/td>\n<td>Beginners to intermediate DevOps practitioners<\/td>\n<td>https:\/\/devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps expertise marketplace\/profile site (verify services)<\/td>\n<td>Teams seeking short-term guidance or training<\/td>\n<td>https:\/\/devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support\/training style services (verify offerings)<\/td>\n<td>Ops teams needing practical troubleshooting help<\/td>\n<td>https:\/\/devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company Name<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify exact services)<\/td>\n<td>Architecture reviews, deployment automation, ops maturity<\/td>\n<td>Designing edge security with load balancing; implementing IaC for policies<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps and cloud consulting\/training (verify service scope)<\/td>\n<td>Implementation support, skills enablement, process setup<\/td>\n<td>Setting up CI\/CD to manage Cloud Armor policies; observability and operational runbooks<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify exact services)<\/td>\n<td>DevOps transformation, cloud migration support<\/td>\n<td>Load balancer + Cloud Armor rollout; logging\/monitoring integration<\/td>\n<td>https:\/\/devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Google Cloud Armor<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>HTTP fundamentals<\/strong>: methods, headers, status codes, caching basics<\/li>\n<li><strong>Web security basics<\/strong>: OWASP Top 10, common attack patterns (XSS, SQLi)<\/li>\n<li><strong>Google Cloud Networking foundations<\/strong>:<\/li>\n<li>VPC basics, firewall concepts<\/li>\n<li>Cloud Load Balancing (forwarding rules, proxies, URL maps, backends)<\/li>\n<li><strong>IAM and auditability<\/strong>: roles, least privilege, audit logs<\/li>\n<li><strong>Observability<\/strong>: Cloud Logging queries, log-based metrics, dashboards<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Google Cloud Armor<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud CDN<\/strong> tuning and cache strategy (performance + origin protection)<\/li>\n<li><strong>Advanced abuse protection<\/strong> patterns:<\/li>\n<li>reCAPTCHA Enterprise (bot\/abuse)<\/li>\n<li>API management (Apigee or API Gateway) where appropriate<\/li>\n<li><strong>Security operations<\/strong>:<\/li>\n<li>Log exports to SIEM<\/li>\n<li>Incident response playbooks<\/li>\n<li>Threat modeling and continuous tuning<\/li>\n<li><strong>Infrastructure as Code<\/strong>:<\/li>\n<li>Terraform modules for load balancing + Cloud Armor<\/li>\n<li>Policy rollout pipelines with approvals<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud\/Platform Engineer<\/li>\n<li>DevOps Engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Cloud Security Engineer<\/li>\n<li>Network\/Edge Security Engineer<\/li>\n<li>Solutions Architect<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (if available)<\/h3>\n\n\n\n<p>Google Cloud certifications don\u2019t map 1:1 to a single service, but Cloud Armor knowledge is most relevant to:\n&#8211; Professional Cloud Security Engineer\n&#8211; Professional Cloud Network Engineer\n&#8211; Professional Cloud Architect<\/p>\n\n\n\n<p>Verify the current exam guides on Google Cloud\u2019s certification site.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a multi-service external load balancer routing to two Cloud Run backends and apply different Cloud Armor rules per backend service.<\/li>\n<li>Implement a safe rollout pipeline:<\/li>\n<li>New rules in preview<\/li>\n<li>Log review step<\/li>\n<li>Promote to enforce with approval<\/li>\n<li>Create rate limits for <code>\/login<\/code> and build dashboards for:<\/li>\n<li>Requests allowed\/denied<\/li>\n<li>Top denied IPs<\/li>\n<li>Denies by country (if available in logs)<\/li>\n<li>Combine Cloud CDN + Armor for a static site and measure cache hit improvements and reduced origin load.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Google Cloud Armor<\/strong>: Google Cloud service providing security policies for WAF-style controls and DDoS protection integrated with supported load balancers\/CDN.<\/li>\n<li><strong>Security policy<\/strong>: A set of ordered rules evaluated for incoming requests.<\/li>\n<li><strong>Rule priority<\/strong>: Determines evaluation order; lower numbers evaluate first.<\/li>\n<li><strong>WAF (Web Application Firewall)<\/strong>: Security controls focused on protecting web apps by inspecting HTTP requests for malicious patterns.<\/li>\n<li><strong>DDoS (Distributed Denial of Service)<\/strong>: Attack that attempts to overwhelm a service with traffic from many sources.<\/li>\n<li><strong>Layer 7 (L7)<\/strong>: Application-layer traffic (HTTP\/HTTPS), as opposed to L3\/L4 (IP\/TCP\/UDP).<\/li>\n<li><strong>External Application Load Balancer<\/strong>: Google Cloud HTTP(S) load balancing product used for global\/regional app delivery (terminology and variants exist\u2014verify for your deployment).<\/li>\n<li><strong>Backend service<\/strong>: Load balancer object defining how to reach backends and apply policies (including Cloud Armor).<\/li>\n<li><strong>Backend bucket<\/strong>: Load balancer object commonly used to serve content from Cloud Storage (often with Cloud CDN).<\/li>\n<li><strong>Serverless NEG<\/strong>: Serverless network endpoint group used to connect load balancing to serverless backends like Cloud Run.<\/li>\n<li><strong>Cloud Logging<\/strong>: Central logging service where load balancer and policy logs can be analyzed.<\/li>\n<li><strong>Cloud Monitoring<\/strong>: Metrics, dashboards, and alerting for Google Cloud resources.<\/li>\n<li><strong>Preview mode<\/strong>: A mode (where supported) to test rule matches without enforcing, used to reduce false positives.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Google Cloud Armor is Google Cloud\u2019s managed edge\/application security service in the <strong>Networking<\/strong> stack that protects internet-facing apps behind supported load balancers and CDN configurations. It uses security policies and ordered rules to allow, deny, and (where supported) rate-limit traffic, and it can incorporate managed WAF protections and advanced DDoS capabilities depending on your configuration and edition.<\/p>\n\n\n\n<p>It matters because it helps stop common web attacks and abusive traffic <strong>before<\/strong> they reach your backends\u2014improving reliability and reducing operational load. Cost-wise, the biggest drivers are request volume, enabled advanced features, and logging volume; indirect costs often come from backend scaling and egress if attacks are not blocked early. Security-wise, treat policy changes as high-impact: lock down IAM, use audit logs, and roll out new rules safely.<\/p>\n\n\n\n<p>Use Google Cloud Armor when your services are delivered through Google Cloud Load Balancing\/Cloud CDN and you need managed WAF\/DDoS-style controls with strong integration into Google Cloud operations. Next, deepen your skills by learning Cloud Load Balancing internals, Cloud CDN behaviors, and building a CI\/CD-based policy rollout process with monitoring and alerting.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Networking<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[51,50],"tags":[],"class_list":["post-727","post","type-post","status-publish","format-standard","hentry","category-google-cloud","category-networking"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/727","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=727"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/727\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=727"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=727"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=727"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}