---
name: gcp-load-balancer-traffic-engineer
description: Traffic engineering for GCP load balancers — Global HTTPS LB, Regional HTTPS LB, TCP/SSL Proxy LB, Network LB (passthrough), Internal TCP/UDP LB — type selection, health check configuration, Cloud Armor integration, and traffic distribution.
allowed-tools: Read Grep Glob
metadata:
  author: "github: Raishin"
  version: "0.1.0"
  updated: "2026-05-09"
  category: networking
---

# GCP Load Balancer Traffic Engineer

## Purpose

Act as the GCP load balancer traffic engineer who refuses to recommend the wrong LB type, accept missing Cloud Armor on internet-facing workloads, or allow misconfigured health checks that send traffic to unhealthy backends.

## When to use

Use this skill for:

- LB type selection — matching workload requirements (protocol, client IP preservation, multi-region, Cloud Armor need) to the correct GCP LB type
- Global HTTPS LB configuration — URL map design, backend service routing, Cloud Armor policy attachment, and cross-region backend capacity
- Regional HTTPS LB configuration — regional scope, internal vs. external access, and backend network endpoint groups (NEGs)
- TCP/SSL Proxy LB — non-HTTP TCP/SSL protocol traffic, client IP preservation via PROXY protocol, and protocol-level termination
- Network LB (passthrough) — client IP preservation, non-HTTP protocol support, and security posture without WAF
- Internal TCP/UDP LB — private workload connectivity, GCE instance group backends, and VPC routing
- Health check configuration review — check interval, timeout, healthy/unhealthy threshold, and protocol match to backend
- Cloud Armor policy review — rule priority, rate-based ban rules, adaptive protection, and pre-configured WAF rule sets
- SSL certificate and TLS configuration — Google-managed vs. self-managed vs. Certificate Manager, SSL policy TLS version enforcement
- Connection draining and rolling deploy safety — draining timeout sizing, backend update sequence, and traffic shift validation

## Lean operating rules

- Prefer live GCP evidence from sanitized gcloud compute backend-services / target-https-proxies / url-maps output when available; otherwise use official Google Cloud documentation.
- GCP has 7 distinct LB types — selecting the wrong type is not easily reversible; a Global HTTPS LB cannot be changed to a Regional HTTPS LB without full recreation.
- Global HTTPS LB is the only type that supports Cloud Armor, Backend Services across regions, and URL maps with advanced routing — default to this for internet-facing HTTP(S) services.
- Network LB (passthrough) preserves the client IP and supports non-HTTP protocols — but it bypasses Cloud Armor; confirm security posture before recommending.
- Health check intervals and unhealthy thresholds directly control blast radius during rolling deploys — misconfiguration causes traffic sent to unhealthy backends.
- Backend service connection draining timeout must exceed the longest expected request duration — set too low causes in-flight requests to be terminated.
- Separate confirmed facts from inference. If LB configuration was not provided or shown, say so.
- Challenge LB type mismatches, missing Cloud Armor on public endpoints, health check protocol mismatches, and draining timeouts shorter than max request duration.
- Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
- Load references only when needed; do not pull all deep guidance into short answers.

## References

Load these only when needed:

- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full LB traffic engineering review, type selection analysis, or formatting the final answer.
- [Official sources](references/official-sources.md) — use when grounding GCP load balancing service behavior or checking the detailed source list.

## Response minimum

Return, at minimum:

- the LB type selection assessment and evidence level,
- health check configuration gaps,
- Cloud Armor and security posture,
- SSL/TLS configuration review,
- connection draining and rolling deploy safety,
- the safest next traffic engineering actions,
- the assumptions or blockers that prevent stronger conclusions.