AutoGineer
Generated banner for Google Cloud Global Frontend Configuration
Generated logo for Google Cloud Global Frontend Configuration

Google Cloud Global Frontend Configuration

GoogleOfficialPublished by Google

  • Skill
  • Workflow
  • Cloud and DevOps
  • Apache-2.0
  • No issues found
Download ZIP

From the author

Guides agents through a 6-step discovery process to design and deploy Google Cloud global external Application Load Balancers with Cloud CDN, Cloud Armor, and Service Extensions, mapping workload requirements to best-practice configurations. Use when: - Designing, configuring, or deploying a Google Cloud global external Application Load Balancer, Cloud CDN, Cloud Armor WAF, or Service Extensions. - Discovering existing Google Cloud resources (Cloud Storage, MIGs, GKE, Cloud Run) to use as backends. - Generating production-grade Terraform HCL or gcloud CLI scripts for global external Application Load Balancers. - Actuating deployments via Infrastructure Manager or bash scripts, including IAM pre-checks. - Detecting, analyzing, or reconciling configuration drift on deployed global external Application Load Balancers. Don't use for: - Non-Google Cloud load balancing or security configurations. - Purely regional or internal load balancing setups (unless part of a hybrid/failover global design).
— the description by Google

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured, interactive process for agents to assist users in building production-grade Google Cloud global external Application Load Balancers. It covers the full lifecycle, including resource discovery, backend configuration, traffic management, and security policy setup using Cloud CDN and Cloud Armor. The skill follows an opinionated, best-practice approach, progressively disclosing complexity and offering automated generation of Terraform HCL or gcloud CLI scripts for deployment and drift management.

What it does

  • Discovers existing Google Cloud resources like GKE, Cloud Run, and MIGs for backend integration.
  • Maps specific workload types to optimized Cloud CDN and Cloud Armor security configurations.
  • Generates production-ready Terraform HCL or gcloud CLI scripts based on user requirements.
  • Facilitates deployment through Google Cloud Infrastructure Manager.
  • Detects and reconciles configuration drift between deployed infrastructure and code.
  • Provides a structured 6-step flow to ensure all critical load balancer components are configured correctly.

When to use it

  • When designing or deploying a new global external Application Load Balancer on Google Cloud.
  • When you need to integrate Cloud CDN or Cloud Armor WAF with existing backend services.
  • When you need to generate infrastructure-as-code (Terraform) for load balancing components.
  • When you need to identify and fix configuration drift on existing load balancer deployments.

Advantages

  • Ensures adherence to Google Cloud best practices for performance and security.
  • Reduces manual configuration errors through a guided, step-by-step discovery process.
  • Simplifies complex load balancer setups by hiding advanced options unless requested.
  • Provides clear paths for both initial deployment and ongoing infrastructure maintenance.

Usage examples

“Help me set up a global load balancer for my Cloud Run service.”
The agent will initiate the 6-step flow, starting with project discovery and guiding the user through selecting the Cloud Run backend and applying recommended security/caching settings.
“I need to secure my API backend with Cloud Armor. Can you help?”
The agent will identify the workload as a 'Cacheable API' or 'Uncacheable API' and propose the appropriate Cloud Armor rate limiting and OWASP protection rules.
“Check if my load balancer configuration has drifted.”
The agent will use Infrastructure Manager to generate a preview, compare it against the local Terraform code, and present options to either overwrite or backport the changes.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/google/google-cloud-global-frontend-configuration/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip google-cloud-global-frontend-configuration.zip -d .agents/skills

Documentation by Google

Google Cloud global external Application Load Balancer Configuration Skill

Attribution

MUST READ: Before executing any gcloud, REST API, or MCP command, you MUST read Usage Attribution. For commands executed directly in the terminal (never in generated scripts, Terraform, or user code), prefix gcloud with CLOUDSDK_METRICS_REQUEST_ATTRIBUTION="agent-skills/1.0 (skill:google-cloud-global-frontend-configuration)" and append agent-skills/1.0 (skill:google-cloud-global-frontend-configuration) to User-Agent headers.

Purpose & Agent Guidance

This skill enables the agent to guide users through a structured, 6-step discovery process to design and deploy Google Cloud global external Application Load Balancers (incorporating Cloud CDN, Cloud Armor, and Service Extensions).

Assumptions & Target Environments:

  • This skill assumes it is called from environments (such as Gemini CLI, Antigravity, etc.) where the Google Cloud CLI (gcloud) can be executed.

  • If gcloud is not available or accessible, the skill cannot perform automated resource discovery or managed deployment actuation. In such environments, the skill will limit its support to guiding the design and generating Terraform HCL configurations.

When executing this skill, the agent must:

  • Map user workload requirements to simplified, opinionated best-practice configurations using actual Google Cloud product names.

  • Progressively disclose details, hiding advanced complexity unless the user explicitly asks for customization.

  • Leverage the reference documents in the references/ directory to perform resource discovery, code generation, actuation, and drift detection.

The 6-Step Configuration Flow

Step 1: Basics

  • Project Discovery: Consult references/resource-discovery.md to auto-detect the Google Cloud project ID. Present the discovered project ID to the user.

  • Ask the user for the foundational details of their load balancer:

    • Name & Description: What should we call this load balancer?

    • Protocol Selection: Do they need HTTP, HTTPS, or both?

    • Certificate Management: Do they want to use Google-managed certificates or bring their own existing certificates?

Step 2: Origin Configuration

Help the user define their backend workloads through a strictly sequential, step-by-step loop. Do NOT ask everything at once. All steps are mandatory.

  • Sub-step A - Origin Setup: Ask if they have a single origin or need multi-origin support. Wait for response.

  • Sub-step B - Origin Types: Ask them to select the backend types from: Cloud Storage Buckets, Compute Engine Managed Instance Groups (MIGs), Google Kubernetes Engine (GKE) Clusters, Cloud Run Services, or External/Internet origins (IP/FQDN). Wait for response.

  • Sub-step C - Origin Definition Loop: Execute the following loop sequentially for EACH origin type selected in Sub-step B. Wait for the user to answer for one origin before asking about the next:

    • Resource Discovery: For Google Cloud-native origins (Cloud Storage, MIGs, GKE, Cloud Run), consult references/resource-discovery.md to fetch resources. Present the list starting with 1. Create New, 2. NA. For External/Internet origins, just ask for the FQDN/IP.

    • Workload Type (CRITICAL): Immediately after they define the resource, ask exactly what type of workload is being served:

      1. Static Images / Objects (Static content, images, videos, styling assets)

      2. Cacheable API (Read-only, public APIs where cached data is acceptable)

      3. Uncacheable API / Transactions (Transactional endpoints, login, checkout, account changes)

      4. Dynamic Web (SSR) (Dynamic pages, server-side rendered apps, custom dynamic sessions)

  • Sub-step D - Routing Rules: Once ALL origins have been fully defined one by one, ask how traffic should be routed between them (Path-based, header-based, or query-param-based). Wait for response.

  • Sub-step E - Logging: After routing is established, ask if they want to enable Cloud CDN logging, and if so, at what sampling rate (0-100%). Wait for response.

Step 3: Traffic Management & Extensibility

  • Provide a brief summary of the origins and routing rules defined in Step 2.

  • Ask if they need to enable Advanced Traffic Management settings (such as granular weighted load balancing, traffic mirroring, or Cloud Load Balancing Service Extensions for custom WASM plugins / callouts), or if they want to proceed with Google Cloud Best Practice Configuration.

Step 4: Caching (Cloud CDN)

Propose a "Recommended Configuration" based entirely on the Workload Type from Step 2. Do not list the advanced settings (TTL, Cache Keys, Compression) unless they reject the recommendation and want to customize.

  • If Workload = Static Images / Objects:

    • Cache Mode: Cache All Static

    • TTL: Client (1 day / 86400s), Default (30 days / 2592000s), Max (365 days / 31536000s) — balances long-term cache offload for static assets with periodic re-validation.

    • Cache Key: Protocol + Host + Path (Ignore Query Strings)

    • Compression: Enabled (Brotli & Gzip)

    • Negative Caching: Enabled

    • Serve while stale: Enabled

  • If Workload = Cacheable API:

    • Cache Mode: Use Origin Headers

    • TTL: Managed by Origin (Omitted from configuration to prevent errors)

    • Cache Key: Protocol + Host + Path + Include Query Strings

    • Compression: Enabled (Gzip)

    • Negative Caching: Enabled

    • Serve while stale: Disabled

  • If Workload = Uncacheable API / Transactions:

    • Cache Mode: Disabled (CDN Bypassed)

  • If Workload = Dynamic Web (SSR):

    • Cache Mode: Use Origin Headers

    • TTL: Managed by Origin (Omitted from configuration to prevent errors)

    • Cache Key: Protocol + Host + Path

    • Compression: Enabled (Brotli & Gzip)

    • Cache Bypass: Bypass cache if session cookies (e.g., SESSID, JWT) are present

Step 5: Security (Cloud Armor)

Propose a "Recommended Configuration" based entirely on the Workload Type from Step 2. Keep advanced protection (Bot Management, Threat Intel, Geo-blocking) hidden unless requested.

  • If Workload = Static Images / Objects:

    • Rate Limiting: None (Standard Edge behavior; rate limiting is unsupported on Cloud Armor Edge policies for Cloud Storage buckets).

    • OWASP Protection: Disabled

  • If Workload = Cacheable API:

    • Rate Limiting: 100 requests per minute per client IP (standard baseline to prevent API abuse and DDoS while accommodating normal interactive usage).

    • OWASP Protection: Enabled (SQLi, XSS, Local File Inclusion)

  • If Workload = Uncacheable API / Transactions:

    • Rate Limiting: Strict 30 requests per minute per client IP (tight threshold to protect sensitive transactional endpoints like login/checkout from credential stuffing and brute-force attacks).

    • OWASP Protection: Enabled (SQLi, XSS, Remote Command Execution, Session Fixation)

    • Bot Management & Threat Intel: Enabled (Block malicious bots and known malicious IPs)

  • If Workload = Dynamic Web (SSR):

    • Rate Limiting: 120 requests per minute per client IP (generous threshold to accommodate burst requests for initial page loads and asset hydration in SSR web applications).

    • OWASP Protection: Enabled (SQLi, XSS, CSRF, Shellshock)

    • Geo-blocking: Optional (Restrict/allow specific country access)

Step 6: Review & Deploy

  • Configuration Summary: Generate a complete, formatted markdown table showing all finalized settings from Steps 1 through 5, using Google Cloud product names. Follow this exact template structure:

    ComponentParameter / SettingValue & Justification
    Load BalancerName & Protocol<Name> (HTTP/HTTPS)
    OriginsBackends & Workloads<Backend 1> (<Workload Type>), <Backend 2>...
    Traffic ManagementRouting Rules<Path / Header rules or Default>
    Cloud CDNCache Mode & TTLs<Cache Mode>, Default TTL: <TTL>
    Cloud ArmorRate Limiting & OWASP<RPM Limit>, OWASP Rules: <Enabled/Disabled>
    Service ExtensionsWASM / Callouts<Enabled/Disabled or N/A>

  • Next Action: Ask the user to choose their deployment/generation format (Terraform HCL or gcloud CLI Bash Script) and their next action:

    1. Show Code / Script (Display the HCL code or gcloud bash script. Once displayed, offer options to Download or Deploy/Execute)

    2. Download files (Save main.tf or deploy.sh to the local workspace)

    3. Deploy Configuration: Initiate the deployment via Infrastructure Manager or execute the gcloud script. This should be done using the deployment instructions in references/managed-deployment.md.

Relevant Documentation & Supportive Links

Files

references/terraform-module.md

Google Cloud global external Application Load Balancer Official Terraform Module Guidelines

This reference document provides guidelines and examples for designing and managing Google Cloud global external Application Load Balancer architectures using the official Google-managed Terraform modules (lb-http and cloud-armor).

Table of Contents

  • Core Directives

  • Comprehensive Multi-Backend Example

    • Cloud Armor Security Policies

    • Serverless NEG (Cloud Run)

    • Global Load Balancer (Official Module)

Core Directives

  1. Prefer Official Modules: Whenever generating complex, production-grade configurations, prefer using the official Google-supported modules to ensure best-practices, security defaults, and ongoing updates:

  2. Module Versioning: Always lock the module version to the latest stable major version (e.g., version = "~> 10.0" for lb-http or version = "~> 2.0" for cloud-armor) to prevent breaking changes.

  3. Backend Structure: Map the design spec origins to the backends map of the lb-http module. Each backend entry must configure protocol, enable_cdn, cdn_policy, and its target endpoint groups (groups).

Comprehensive Multi-Backend Example

The following example demonstrates a complete, production-ready main.tf using the official modules to configure a Google Cloud global external Application Load Balancer with three distinct backends (Serverless NEG for API, Google Cloud Storage bucket for static content, and Cloud Armor security policies):

terraform {
  required_version = ">= 1.0"
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 5.0"
    }
  }
}

provider "google" {
  project = var.project_id
  region  = var.region
}

# --- Cloud Armor Security Policies ---

module "security_policy_api" {
  source  = "GoogleCloudPlatform/cloud-armor/google"
  version = "~> 2.0"

  project_id   = var.project_id
  policy_name  = "${var.architecture_name}-waf-api"
  description  = "Cloud Armor WAF policy for API backends"
  default_action = "allow"

  # Rate limiting rule (100 RPM)
  rate_limiting_rules = [
    {
      action        = "throttle"
      priority      = 1000
      description   = "Rate limit API requests"
      src_ip_ranges = ["*"]
      
      rate_limit_options = {
        exceed_action            = "deny(403)"
        rate_limit_threshold = {
          count        = 100
          interval_sec = 60
        }
      }
    }
  ]

  # Preconfigured OWASP rules
  preconfigured_rules = [
    {
      action        = "deny(403)"
      priority      = 9000
      description   = "OWASP SQLi protection"
      expression    = "evaluatePreconfiguredExpr('sqli-v33-stable')"
      src_ip_ranges = ["*"]
    },
    {
      action        = "deny(403)"
      priority      = 9001
      description   = "OWASP XSS protection"
      expression    = "evaluatePreconfiguredExpr('xss-v33-stable')"
      src_ip_ranges = ["*"]
    }
  ]
}

# --- Serverless NEG (Cloud Run) ---

resource "google_compute_region_network_endpoint_group" "serverless_neg" {
  name                  = "${var.architecture_name}-serverless-neg"
  network_endpoint_type = "SERVERLESS"
  region                = var.region
  
  cloud_run {
    service = var.cloud_run_service_name
  }
}

# --- Global Load Balancer (Official Module) ---

module "gce_lb_http" {
  source  = "GoogleCloudPlatform/lb-http/google"
  version = "~> 10.0"

  project       = var.project_id
  name          = var.architecture_name
  firewall_networks = [] # Not creating internal firewall rules for global external LB

  # Frontend Configuration
  ssl                          = true
  use_ssl_certificates        = false
  ssl_certificates             = [google_compute_managed_ssl_certificate.default.id]
  http_forward                 = true

  backends = {
    # Default External Backend (API)
    default = {
      protocol        = "HTTP"
      enable_cdn      = true
      security_policy = module.security_policy_api.policy_id

      cdn_policy = {
        cache_mode = "USE_ORIGIN_HEADERS"
        cache_key_policy = {
          include_query_string = true
        }
      }

      groups = [
        {
          group = google_compute_global_network_endpoint_group.external_neg.id
        }
      ]
    }

    # Google Cloud Storage Bucket Backend
    gcs = {
      protocol        = "HTTP"
      enable_cdn      = true

      cdn_policy = {
        cache_mode  = "CACHE_ALL_STATIC"
        default_ttl = 2592000
        max_ttl     = 2592000
      }

      groups = [
        {
          group = "projects/${var.project_id}/global/backendBuckets/${var.architecture_name}-gcs-backend"
        }
      ]
    }

    # Serverless Backend
    serverless = {
      protocol        = "HTTP"
      enable_cdn      = true
      security_policy = module.security_policy_api.policy_id

      cdn_policy = {
        cache_mode  = "CACHE_ALL_STATIC"
        default_ttl = 2592000
        max_ttl     = 2592000
      }

      groups = [
        {
          group = google_compute_region_network_endpoint_group.serverless_neg.id
        }
      ]
    }
  }

  # Custom Path Routing Matchers
  url_map = {
    default_service = "default"
    path_matchers = {
      main-matcher = {
        default_service = "default"
        path_rules = [
          {
            paths   = ["/api", "/api/*"]
            service = "default"
          },
          {
            paths   = ["/static", "/static/*"]
            service = "gcs"
          },
          {
            paths   = ["/app", "/app/*"]
            service = "serverless"
          }
        ]
      }
    }
  }
}

resource "google_compute_managed_ssl_certificate" "default" {
  name = "${var.architecture_name}-cert"

  managed {
    domains = [var.domain_name]
  }
}

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Google
Publisher
Google (Official)
Source
google/skills · skills/cloud/google-cloud-global-frontend-configuration · commit 2194d3b
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Google or Google.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download google-cloud-global-frontend-configuration.zip