The Google edge, explained

This month the fleet's front door moved. Every request to every application we host now enters through one global edge — Google's — before it touches an application server. Two earlier posts mentioned pieces of this (our WAF baseline, our choice of regions); this is the full picture of what a request crosses on its way in.

One front door for the whole fleet

Every domain we serve resolves to dedicated addresses on Google's global load balancer, so a visitor connects to the nearest Google point of presence and rides Google's own network from there. Certificates are issued and rotated by Google, strict transport security is on, and the whole edge is declared configuration — reviewed, versioned and reproducible, like everything else on the platform.

The cheapest attack to survive is the one that never reaches you.

Inspected before it arrives

In front of every application sits the same armour. A rate-based ban shields every login — five attempts in a minute earns the address a ten-minute time-out — and a query guard drops requests carrying obvious injection patterns before they reach the application. Google's preconfigured OWASP rule sets evaluate every request alongside, and payment webhooks are deliberately carved out of pattern-matching: they authenticate by provider signature instead, because a rule that cannot tell a real payment payload from an attack is a rule that breaks your revenue.

Signed names, gated doors

The addresses themselves are part of the perimeter now: our fifteen domains live on Google Cloud DNS and every zone is DNSSEC-signed, so a resolver can verify it is talking to the genuine zone and not an impostor. Our own operations surfaces — the fleet's panels, even SSH to the machines — open only to verified Google identity, never to a password on the open internet. And what remains anonymous is exactly what we declared anonymous: health endpoints and payment webhooks, listed in the fleet registry, nothing else.