Securing cloud applications begins with understanding how request traffic moves through Google Cloud’s infrastructure. From the moment a request leaves the client machine to the moment it reaches backend services, every component along the path contributes to performance, resilience, and security.
When I first explored this flow, I found myself overwhelmed by the number of services involved — and unsure which ones were essential, optional, or security‑critical. What happens at each hop? How do these services interact? And which layers truly matter when building a secure, compliant, and scalable cloud application in Google Cloud?
This post breaks down those questions using a simple, intuitive analogy: an airport journey. In this model, the client request becomes a passenger navigating terminals, security checkpoints, and routing desks — eventually boarding the airplane (backend service) where your application runs.
In the next post, I’ll flip the perspective and walk through the return trip — how the response travels from backend to client.
TL;DR:
- Traffic first lands at the nearest GFE Point of Presence (PoP) — think of it as the closest airport building reached via anycast.
- Inside that building, the GFE proxy layer inspects and processes the request (your airport staff + systems).
- For your application, GFE applies your Cloud Load Balancer rules/configuration, effectively becoming the Load Balancer Edge (LB Edge).
- All edge security controls — TLS termination, Cloud Armor, IAP, CDN — are enforced here before the request enters Google’s private backbone.
Glossary: Airport Analogy (in request flow order)
1. Client → Passenger
The journey begins when the passenger decides to travel.
2. DNS (Cloud DNS) → Trip Planning & Directions
The passenger figures out which airport to go to — resolving your domain to the nearest entry point.
3. GFE PoP (Edge Location) → Airport Terminal Building
The passenger arrives at the closest physical airport building via anycast.
4. GFE Proxy (LB Data Plane) → Airport Staff & Check‑in Systems
This includes:
- Cloud Armor → Security Checkpoint
- IAP → ID Check
- CDN → Gate Baggage / Screening & Optimization
5. Premium Backbone → Runway / High‑speed Flight Path
The passenger moves onto the premium, dedicated runway — Google’s private global network.
6. API Gateway (Optional) → Boarding Gate
A controlled entry point where only valid passengers (requests) can board.
7. Service Mesh (Optional) → In‑Flight Crew
Ensures secure communication, policies, and telemetry during the internal journey.
8. Backend → Airplane / Destination System
The passenger finally boards the airplane — your backend service — and reaches the hosting environment.
Traffic Flow: Client → DNS (Cloud DNS) → GFE PoP (Edge Location) → GFE Proxy (LB Data Plane: Armor + IAP + CDN) → Premium Backbone → [Optional: API Gateway → Service Mesh] → Backend
Traffic Flow Explained:
1. Client: Passenger starting their journey
│ Always start here
│
└── 2. DNS (Cloud DNS): Airline ticketing system/ travel agent resolving which airport to go to
│ User’s domain resolves to a Google‑advertised anycast IP.
│ That IP routes the request to the nearest GFE PoP (Point of Presence) — the physical edge location where Google Front End runs.
│
└── 3. Google Front End (GFE) PoP (Points of Presence): The nearest Airport Terminal Building where passengers (requests) first step in (the terminal itself).
│ - GFE PoP receives the traffic (place where passengers arrive).
│ - GFE PoPs are located worldwide.
│ - GFE PoP is the actual PHYSICAL entry point / physical EDGE location (edge node) where GFE systems run, where requests land before being processed and routed deeper into Google’s backbone via anycast routing.
│ - GFE PoP sits between DNS resolution and your Cloud Load Balancer/CDN.
│ - GFE PoP as part of the Cloud Load Balancer dataplane.
│ - When you configure a Cloud Load Balancer, its dataplane is implemented on top of GFE infrastructure.
│ - That means the GFE PoP is not just a generic edge node — it’s the Cloud Load Balancer dataplane in action.
│ - GFE PoPs act as intelligent entry gates into Google’s private backbone network.
│ - GFE PoP refers to the globally distributed Points of Presence where Google’s infrastructure first receives and processes user traffic.
│ - At a GFE PoP, the GFE systems (LB data plane) terminate the client connection and handles ALL traffic coming to Google’s own products (Search, YouTube, Gmail, Maps, Cloud Load Balancing, etc.), including traffic coming to YOUR Google-hosted apps behind Cloud Load Balancing FIRST HITS a GFE. Here, termination is done by GFE inside the PoP, not the PoP itself.
│ - GFE PoP is the building, but the GFE inside performs the work.
│ - GFE PoP is where Google advertises anycast IPs for services like Cloud Load Balancing.
│ -- When a user sends a request to a Google-hosted app, it’s routed to the nearest GFE PoP using BGP anycast.
│
│ 3.1 Google Front End (GFE) is the Staff and Security Systems inside the terminal (security scanners, check‑in counters, routing desks, check‑in counters, and staff inside the building) that process them once they’ve arrived.
│ - Google Front End (GFE) runs inside the GFE PoP, is a SOFTWARE proxy layer.
│ -- GFE, the proxy layer:
│ --- Processes traffic (handling security - SSL/TLS, DDoS and routing systems).
│ --- This is where the Cloud Load Balancer data plane (Cloud Armor + IAP + Cloud CDN) lives.
│ --- This is where Cloud Armor, IAP, TLS termination, routing, etc. happen.
│ -- GFE is what happens inside once passengers arrive there — the actual processing.
│ -- GFE runs on Google’s globally distributed edge infrastructure, which consists of GFE PoPs.
│ -- GFE processes each passenger (request) — checking documents (SSL/TLS termination), scanning luggage (DDoS protection), and handling security screening (handles the Cloud Load Balancer (HTTP/S) data plane work: Cloud Armor, filtering requests, and, directing to the right gate (routing) — into Google’s private backbone network at GFE PoP as part of the Cloud Load Balancer dataplane to reach the backend service.
│ -- From there, the passenger enters the airline’s private secure internal network (Google’s private backbone network) to reach their destination (backend service)
│ -- So when someone says “traffic hits the GFE,” they mean: Traffic is received via anycast at the nearest GFE PoP (the closest airport terminal) - and processed by GFE systems inside it.
│
│ Note:
│ - Passengers arrive at the GFE PoP (nearest Airport Terminal building), and are processed by GFE (the terminal’s systems).
│ - GFE is the execution engine of the Cloud Load Balancer HTTP/S data plane.
│ - GFE PoPs (PHYSICAL entry point) + GFE (SOFTWARE proxy layer) = Form global edge entry platform for all Google traffic.
│ - GFE PoP RECEIVES the traffic. GFE PROCESSES the traffic.
│
└── 4. Load Balancer Edge (LB Edge): Simply Google Front End (GFE) configured for YOUR PROJECT
│ YOUR airline's check‑in counter inside the terminal that decide where you go next, directing passengers to the right flight (backend service).
│ - It applies your airline’s rules at the check‑in counters.
│ - It’s the Edge of Google’s Cloud Load Balancing system.
│ - LB Edge is the GFE data plane (staff wearing your airline’s uniform) running your Cloud Load Balancer’s policies.
│ - LB Edge is simply GFE configured for YOUR PROJECT. (same GFE infrastructure, but now following your project’s instructions. It’s GFE customized for your project’s Cloud Load Balancer dataplane).
│ - The logical point within GFE where traffic destined for your project’s load balancer is processed.
│
│ Remember: GFE systems terminate the client connection and handles ALL traffic coming to Google’s own products (Search, YouTube, Gmail, Maps, etc.), including traffic coming to YOUR Google-hosted apps behind Cloud Load Balancing FIRST HITS a GFE. AND then switches traffic for your Google‑hosted app to your project‑specific Load Balancer Edge (LB Edge) configured specifically for your project.
│ - LB Edge is for YOUR PROJEC:
│ -- Decides how to distribute traffic to backend services (VMs, GKE, Cloud Run, etc.)
│ -- It enforces your SSL certificates.
│ -- It enforces your Cloud Armor policies.
│ -- It routes traffic according to your backend service definitions.
│ - Load Balancer Edge is a function of GFE when you configure Cloud Load Balancing for your project.
│ - Load Balancer Edge uses GFE infrastructure under the hood, but it’s specifically tied to your configured load balancer (e.g., HTTP(S) LB, TCP/UDP LB) for your project.
│ - Essentially, LB Edge is GFE acting on behalf of your Cloud Load Balancer.
│ - Google Front End (GFE) includes LB Edge = the airport terminal + check-in counter.
│
└── 4.1 Cloud Load Balancer (HTTP/S) Data Plane: YOUR airline's staff carrying out your airline’s rules inside the terminal
│ │
│ ├── 4.2 Cloud Armor (WAF): The security officer at the airport security checkpoint (Security screening: scanners, metal detectors).
│ │ Filters out prohibited items (malicious traffic) before you’re allowed to proceed.
│ │ Even though your ticket (backend service object) shows where you’re headed, the inspection happens at the edge of the airport (LB Edge/GFE).
│ │ Cloud Armor sits before API Gateway
│ │ - Defined/Configured in your Load Balancer configuration, tied to Backend Service objects.
│ │ - Attached/Linked to those "Backend Service objects" because they are the Load Balancer’s next-hop targets.
│ │ - But Applied/Enforced at the Load Balancer Edge (the logical point within GFE) / at GFE PoP where actual traffic .filtering/inspection/ blocking happens before requests/traffic enters Google's backbone to reach the backend. (NOTE: enforcement happens at the dataplane edge, not on the backend).
│ │ -- This way backend service objects (Backend VMs / GKE / Cloud Run) receive only already-filtered traffic.
│ │ -- Not applied on backend services even though they are associated with and configured on backend service objects (Backend VMs / GKE / Cloud Run).
│ │ - Backend Service objects can represent services (external HTTP(S) Load Balancers), backend buckets (Cloud Storage sites), or serverless NEG-backed services (Cloud Run, Cloud Functions, App Engine). While this may appear backend-side, in practice all Cloud Armor policy checks are enforced at Google’s global Edge within the Load Balancer dataplane.
│ │
│ │ - 4.3 Cloud Armor (WAF) Policy uses:
│ │ -- Cloud Armor (WAF) Rules - individual conditions and actions (allow, deny, rate-limit, etc.) inside Cloud Armor (WAF) Policies.
│ │ -- L7 filtering
│ │ -- IP Allow/Deny
│ │ -- Geo blocking
│ │ -- Bot mitigation
│ │ -- Rate limiting
│ │
│ ├── 4.4 Identity-Aware Proxy (IAP): ID/badge check after security
│ │
│ │
│ └── 4.5 Cloud CDN (optional): Baggage already waiting at the gate (a cache hit).
│ - What you need is already stocked (cached items), you get it immediately without boarding a flight.
│ - If not, you continue on to your gate (backend).
│
│ - Cloud CDN is not a separate layer (Data Plane) before or after the load balancer — it’s a feature of the HTTP(S) Load Balancer, leveraging GFE’s Edge locations to serve cached content globally
│ -- Works with Global HTTP/S Load Balancer. If the frontend is static, you get free global caching.
│ -- Cloud CDN attaches to the HTTP(S) Load Balancer.
│ -- When enabled, cached content is served directly from GFE Edge locations.
│ -- This means Cloud CDN actually “sits on top of” the Load Balancer Edge/GFE infrastructure — it doesn’t exist as a separate hop, but as a feature of the load balancer.
│ -- If the requested content is cached, GFE returns it immediately from the Edge (logical point within GFE).
│ -- If not cached, the request continues through the load balancer to your backend.
│
└── 4.6 Cloud Load Balancer (HTTP/S) Logic: The airline operations/routing desk that decides which gate the passenger goes to.
│ - Decides which gate and which plane you should board (backend service objects).
│ - Cloud Load Balancer (HTTP/S) is the control plane - Configuration + policy engine.
│ -- It defines your routing rules, backend services, SSL certificates, Cloud Armor policies, and URL maps.
│ -- It does not process packets directly.
│ -- It programs the GFE systems at the PoPs to enforce your project’s rules.
│ - Works with the security guard (IAP) to check IDs before boarding.
│ Forwards traffic to the backend service objects, which in turn route traffic to the actual backend resources (VMs, GKE pods, Cloud Run services, etc.).
│ Mandatory for large-scale web apps.
│ The Cloud Load Balancer defines SSL/TLS certs, but termination is executed at GFE.
│ Uses the backend service to decide:
│ - Where should traffic go next?
│ - Which policies apply to this routing path?
│
│ Remember: Cloud Load Balancer control plane (no traffic protocol — API/config only) programs the GFE with your project’s configuration. It is your airline’s operations desk that decides routing rules, while the actual proxy workers who enforce those rules live at the check‑in counters (GFE inside the GFE PoP).
│ - Data plane = GFE enforcing your Cloud Load Balancer’s instructions at the PoPs = The check‑in counter staff carrying out your airline’s rules inside the terminal.
│ - Control plane = decides the rules = Your airline’s operations desk.
│ - GFE = proxy system that enforces the rules = The staff and scanners inside the terminal.
│ - GFE PoP = the place where enforcement happens.
│
│ - Applies Cloud Armor (WAF) Policies
│ - Integrates with Identity-Aware Proxy (IAP) to enforce authentication/authorization at the load balancer edge before forwarding traffic to backend service objects.
│ - 4.7 Identity-Aware Proxy (IAP): The security guard checking boarding passes and IDs before you’re allowed to board the plane (backend service).
│ - IAP is enforced in the GFE, the proxy layer as the load balancer, right after Cloud Armor. It does not happen later at API Gateway or backend unless you deliberately configure it that way (rare). Most production setups use IAP at the LB level.
│ - Cloud Load Balancer + IAP = secure, identity-aware entry point for your apps.
│ -- IAP is a separate service that works in conjunction with the HTTP(S) Load Balancer.
│ -- IAP intercepts the request at the LB dataplane and enforces identity checks (OAuth2 login, IAM policy) before allowing traffic through.
│ -- IAP is layered on top of the LB dataplane — it doesn’t replace the LB, but adds identity enforcement before backend traffic.
│ -- IAP can sit either in front of the LB or after API Gateway depending on design (IAP can be deployed at multiple points — either at the LB Edge or integrated with the API layer).
│
│ Remember: IAP Lives in GFE (and not API Gateway) because IAP is designed to:
│ - Protect workloads before they reach your backend.
│ - Enforce identity at the edge.
│ - Integrate with Cloud Armor.
│ - Run on the same global proxy infrastructure as the LB.
│ - API Gateway is downstream — it’s not the edge.
│ - GFE is the edge.
│ - That’s why IAP belongs there.
│
└── 5. Premium Tier Backbone: Private runway system transporting passengers internally
│
└── 6. API Layer (Optional): The boarding gate staff.
│ Internal airport systems for handling special requests
│ They check your boarding pass and direct you to the correct plane section (API Gateway, Apigee, Endpoints).
│ - Correct placement after Cloud Armor but before your actual service.
│ - Choose one: API Gateway or Apigee or Cloud Endpoints
│ -- API Gateway (a separate API control plane, not part of backend) → lightweight gateway
│ -- or
│ -- Apigee (a separate API control plane, not part of backend) → enterprise API management
│ -- or
│ -- Cloud Endpoints → no-frills API protection layer
│
└── Identity Layer (Optional, Backend-Level Auth): The passport control officer at the destination gate.
│ Performs internal ID verification before final boarding.
│ Verifies your identity and authorization before you step onto the plane.
│ Confirms you are authorized to access this specific flight (backend service).
│ Authentication/authorization happens here.
│ IAM / JWT Auth / IAP is not a backend service.
│ Identity-Aware Proxy (IAP): IAP can be enabled at the LB dataplane (for backend service objects) or integrated at the API/Identity layer depending on design.
│
└── 7. Service Mesh / Ingress (Optional and only relevant if the backend lives on GKE or uses microservices): The in‑flight crew managing passengers inside the plane.
│ Only matters once you’re inside the aircraft (your cluster or VPC).
│ External passengers never interact with them directly.
│ Ensures each passenger reaches the correct seat (service‑to‑service routing).
│ Applies internal policies such as mTLS, retries, traffic shaping, and observability.
│ This layer operates entirely inside your cluster/VPC, governing internal mesh traffic;
│ External traffic never directly interacts with the service mesh.
│
│ ├── GKE Ingress
│ ├── Anthos Service Mesh (Envoy)
│ └── Traffic Director (Service Mesh routing)
│
└── 8. Backend Services (UI Hosting / APIs / Apps): The destination city — the final stop for the incoming request.
Where the request finally arrives, whether it’s:
- a big metropolitan hub (App Engine, GKE),
- a small town (Cloud Functions),
- or a resort (Cloud Storage + CDN).
- UI Hosting (UI / Webpage / Application GUI / Frontend hosting)
- Every valid Google Cloud hosting method for web apps:
├── App Server (UI + API together) → Traditional Monolithic Architecture
│ - A single server or service that handles both frontend and backend.
│ - Runs on Compute Engine VMs, GKE, or App Engine.
│ - Simple, but less scalable/decoupled than modern architectures.
│
├── App Engine (Standard or Flexible) — Fully Managed UI Hosting
│ - PaaS for dynamic UI frameworks, templated apps, and web apps.
│ - Auto scaling, versioning, traffic splitting included.
│ - Ideal for Python, Node.js, Java, Go, PHP-based UIs.
│
├── Separate Frontend / UI Server (Decoupled UI)
│ - Frontend deployed separately; backend lives on APIs.
│ - UI server can run on Compute Engine, GKE, or Cloud Run.
│ - Great for microservices and modern frontend architectures.
│
├── Cloud Run (Frontend Hosting)
│ - Containerized frontend with serverless scaling.
│ - Ideal for:
│ -- React/Angular/Vue SSR builds
│ -- Next.js server-side rendering
│ -- Combined UI + API apps
│ -- Auto-scaling to zero for cost efficiency
│
├── Cloud Functions (UI Edge Cases / Dynamic Rendering)
│ - Not common for full UI, but useful for:
│ -- Micro-frontends
│ -- Dynamic HTML rendering
│ -- Lightweight edge logic endpoints
│
├── GKE Workloads (Kubernetes Pods Serving UI)
│ - Best when:
│ -- You need Kubernetes-level orchestration.
│ -- You have many microservices including UI.
│ -- You want fine-grained scaling and networking control.
│
├── Cloud Storage + CDN (Static UI Hosting)
│ - Perfect for static web apps (React build, Angular dist, Vue static).
│ - Benefits:
│ -- Global CDN
│ -- Extremely low cost
│ -- Near-infinite scale
│ - Often paired with Cloud Run or API Gateway for backend APIs.
│
└── Compute Engine VMs (Raw VM Hosting)
- Traditional approach.
- Host any web server (Apache, NGINX, IIS, Node.js, etc.).
- Maximum control, minimal managed features.
Comments