Business Challenge
#85 closed on a phrase worth returning to: HA VPN provides 99.99% SLA for most topologies, with a few exceptions. Most, with exceptions. The exceptions turn out not to be exotic — they are designs a competent team would arrive at by accident, and the gap between them is a whole nine.
Put the two figures in units anyone can argue about. A 99.99% availability SLA permits roughly 52.56 minutes of unavailability a year. A 99.9% one permits roughly 525.6 minutes — about eight and three-quarter hours. Same product, same console, same resource type, and the difference between those two outcomes is which interfaces you hung tunnels on and which region you put a gateway in.
That is the most expensive instinct in this post. Connecting two VPC networks with a gateway in each is a 99.99% topology only when the HA VPN gateways are deployed in the same region. Separate them and however, this topology provides a 99.9% availability SLA — and the documentation does not leave the recommendation implicit: unless you have a requirement for the HA VPN gateways to be in different regions, we don't recommend having the HA VPN gateways in different regions.
Correct approachPut both gateways in one region, because the reach you were buying with the second region is already free: VPC networks are global resources, which means you can use HA VPN to connect resources in different regions while the HA VPN gateways are deployed in the same region. The gateway's region decides nothing about which regions can use the tunnel — that is #84's dynamic routing mode, set on the network. Spreading gateways geographically buys no reach and costs you a nine.
The requirement is per interface, not per gateway. To receive the 99.99% availability SLA, configure at least one tunnel on each HA VPN gateway interface. A single tunnel from a single interface doesn't provide enough redundancy to meet the availability SLA because there is an unused interface on the HA VPN gateway, which does not have a tunnel configured on it. For the VPC-to-VPC case it is stated as its own sentence: configuring only one tunnel on one interface for each HA VPN gateway doesn't provide 99.99% availability SLA.
Correct approachAudit for idle interfaces, which is a different query from audit for down tunnels. An interface with no tunnel configured on it is not an alert anywhere — nothing is broken, nothing is failing a health check, and the gateway reports fine. It is a gap in the configuration, so it has to be found by looking rather than by waiting.
Possibly, but know why you are doing it. A full mesh configuration is not required for 99.99% availability SLA on the Google Cloud side, where a full mesh means two tunnels from each HA VPN interface to each of the two peer interfaces. What the SLA asks for is less: if the peer gateway has two interfaces, then configuring two tunnels, one from each peer interface to each HA VPN gateway interface, meets the requirements for the 99.99% availability SLA.
Correct approachBuild the mesh if your peer vendor recommends it, and record that it is their requirement rather than Google's. The distinction matters at review time: four tunnels is twice the configuration, twice the BGP sessions and twice the monitoring surface, and if nobody can say which document asked for it, it tends to get halved by whoever simplifies next — possibly down past the two the SLA does require.
Architecture
Four documented topologies, three stated SLAs, and one that is not stated at all.
The four topologies
Two earn four nines. Connect an HA VPN gateway to one or two separate peer VPN gateways is the ordinary hybrid case, and it is 99.99% whether the far end is one device or two. Connect two Google Cloud VPC networks by using an HA VPN gateway in each network is also 99.99%, with the same-region condition above, and the table is careful to separate the two questions of where the gateways are and where the workloads are: the VPC networks can be in the same region or different regions.
Two do not. Connect an HA VPN gateway to Compute Engine VM instances with external IP addresses — the pattern for terminating IPsec on a network virtual appliance — is a 99.9% topology, and the page is explicit that even that figure is conditional: this topology provides 99.9% availability SLA when configured correctly.
And the fourth is the one to read twice. For connect an HA VPN gateway to only one Compute Engine VM instance with an external IP address, there is no Cloud VPN figure at all: the availability SLA is determined by the availability SLA provided for a single VM instance of memory-optimized machine family for Compute Engine.
Three of these topologies tell you what Cloud VPN guarantees. The fourth tells you to go and read another product's SLA, for a single instance, of a specific machine family. That is not a smaller number in the same units — it is a different document with different terms, different exclusions and a different remedy. Any design review that records "HA VPN, SLA covered" against this topology has recorded something it did not check. And there is a fifth case with no number at all, carried over from #85: you can configure an HA VPN gateway with only one active interface and one external IP address; however, this configuration does not provide an availability SLA.
What four nines requires, precisely
One sentence carries it: to meet the 99.99% availability SLA on the Google Cloud side, there must be a tunnel from each of the two interfaces on the HA VPN gateway to the corresponding interfaces on the peer gateway. Note "on the Google Cloud side" — the sentence is scoped, and the peer's own availability is the peer's problem.
For the VPC-to-VPC case the wiring is given as an exact pairing rather than left to interpretation: tunnel 0 connects interface 0 on one HA VPN gateway to interface 0 on the other HA VPN gateway, and tunnel 1 connects interface 1 on one HA VPN gateway to interface 1 on the other HA VPN gateway. Interface 0 to interface 0, interface 1 to interface 1 — not crossed.
The peer-side arrangement shows up in the API as a redundancy type, which is the field to grep for when auditing: with two peer addresses the REDUNDANCY_TYPE for this configuration takes the value TWO_IPS_REDUNDANCY, and where the peer offers a single address that is internally redundant, the REDUNDANCY_TYPE for this configuration takes the value SINGLE_IP_INTERNALLY_REDUNDANT. Both reach 99.99%; a peer with one address is not automatically a downgrade.
The VM topologies ask for more tunnels, not fewer. For multiple VMs, to meet the 99.9% SLA, there must be at least two tunnels from each of the two interfaces on the HA VPN gateway to the corresponding interfaces on each of the VMs. For the single-VM case, to meet the 99.9% availability SLA, there must be two tunnels from each of the two interfaces on the HA VPN gateway to the interface of the Compute Engine VM. Four tunnels for a lower SLA than two tunnels earn against a real peer gateway — which is the clearest possible argument against terminating IPsec on VMs when you have any alternative.
Why This Architecture Holds Up
Both arrangements require BGP, since VPN tunnels connected to HA VPN gateways must use dynamic (BGP) routing, and the choice between them is made entirely in route metrics. Which brings us to the sentence that should be read before anyone says "we run active-passive" in a design review: for both of these routing configurations, both VPN tunnels remain active.
Passive does not describe a tunnel. It describes a priority. In active-active, your peer gateway advertises the peer network's routes with identical multi-exit discriminator (MED) values for each tunnel, and the Cloud Router imports these routes as custom dynamic routes in your VPC network with identical priorities, so egress traffic sent to your peer network uses equal-cost multipath (ECMP) routing. In active-passive, your peer gateway advertises the peer network's routes with different MED values for each tunnel, the Cloud Router imports these routes as custom dynamic routes in your VPC network with different priorities, and the result is that your peer gateway can only use the tunnel with highest priority to send traffic to Google Cloud.
This is #83 and #84 cashing out. MED is the attribute the tie-break ladder reaches last, and it is the one Cloud Router translates into route priority. So the entire active-active versus active-passive decision is a decision about what MED values your peer advertises — which means it is configured on the peer, not in Google Cloud, and a team that believes it chose active-passive in the console has not chosen anything.
Active-active gets you capacity: the effective aggregate throughput is the combined throughput of both tunnels. Active-passive gets you a guarantee about what survives: it uses a maximum of one tunnel at a time so that the second tunnel is able to handle all your egress bandwidth if the first tunnel fails and needs to be failed over. The cost is stated bluntly for the active-passive column — after reducing from two active tunnels to one, the effective overall throughput is cut in half, which can mean slower connectivity or dropped packets.
Which is the real decision: active-active doubles your usable bandwidth and makes a single tunnel failure a capacity event; active-passive halves your usable bandwidth and makes a single tunnel failure a non-event. If you have sized for the aggregate of both tunnels, you have quietly chosen the first and must plan for the cliff. Each tunnel is still capped at the 250,000 packets per second from #85, so active-active is also the only way to exceed one tunnel's ceiling on a single gateway pair.
What the nines do not promise
Cloud VPN repairs itself at two levels, and both are genuinely automatic. If a Cloud VPN tunnel goes down, it restarts automatically. And, more impressively, if an entire virtual VPN device fails, Cloud VPN automatically instantiates a new one with the same configuration. You do not rebuild a failed gateway.
But the routing has to catch up, and here is the figure that belongs in every design document that quotes an availability SLA: when a tunnel becomes unhealthy the Cloud Router withdraws the learned routes whose next hops are the unavailable tunnel, and the withdrawal process can take 40-60 seconds, during which packet loss is expected. Expected — not possible.
Set that against the budget. Four nines allows about 52.56 minutes a year. A withdrawal window is up to a minute of expected loss, and it is spent on an event the SLA counts as working-as-intended, because the tunnel failed and failover happened. So the availability figure and the user experience are measuring different things: one asks whether the service was available, the other asks whether in-flight connections survived, and a sub-minute routing convergence does not register against the first while being extremely visible in the second.
One distinction in the failover description is worth keeping for incident reviews: if a BGP session down occurs, Cloud Router removes the learned routes whose next hops are the unavailable tunnel, without causing a tunnel to be unhealthy. A BGP session can drop, your routes can vanish, and the tunnel will still report healthy. Anyone debugging by tunnel status alone will conclude nothing is wrong.
Key Architecture Decisions
| Situation | Decision | Because |
|---|---|---|
| Connecting two VPC networks | Both gateways in the same region | Different regions provides 99.9%, and is explicitly not recommended. |
| Workloads in several regions need the tunnel | Keep one region and use global dynamic routing mode | VPC networks are global; gateway placement does not decide reach. |
| Wiring a VPC-to-VPC pair | Tunnel 0 interface 0 to interface 0; tunnel 1 interface 1 to interface 1 | The pairing is specified, not left to preference. |
| Peer offers only one external IP address | Proceed; expect SINGLE_IP_INTERNALLY_REDUNDANT | That redundancy type still reaches 99.99%. |
| Vendor runbook demands a full mesh | Build it, and record it as the vendor's requirement | A full mesh is explicitly not required for 99.99% on the Google Cloud side. |
| Auditing an existing gateway | Look for interfaces with no tunnel, not just for down tunnels | An unused interface is the stated reason a configuration fails the SLA, and it raises no alert. |
| Terminating IPsec on Compute Engine VMs | Avoid where a real peer gateway is possible | It needs four tunnels to reach 99.9%, below what two tunnels earn elsewhere. |
| Connecting to a single VM | Go and read the Compute Engine SLA | The availability is inherited from a single memory-optimized VM instance. |
| Someone says "we are active-passive" | Ask what MED values the peer advertises | Both tunnels remain active in both modes; the mode is a metric, not a tunnel state. |
| Sized capacity against both tunnels | You are active-active; plan for half | Losing one tunnel is a capacity event, not a non-event. |
| Needing more than one tunnel's throughput | Active-active | Aggregate throughput is the combined throughput of both tunnels. |
| Quoting an availability SLA to an application team | Quote the 40 to 60 second withdrawal window too | Packet loss during withdrawal is expected and does not show up in the nines. |
| Routes gone but the tunnel looks healthy | Check the BGP session, not the tunnel | A BGP session down removes routes without making the tunnel unhealthy. |
| A gateway failed entirely | Wait; do not rebuild | Cloud VPN instantiates a replacement with the same configuration automatically. |
The one to look at today
For every HA VPN gateway, write down three facts: how many of its two interfaces have at least one tunnel, which region it is in relative to its peer gateway when the peer is another Google Cloud gateway, and what sits on the far end. Those three answers give you the SLA you actually have, which may not be the one in the design document — and all three are configuration rather than health, so no dashboard is going to volunteer them. If any gateway comes back with one idle interface, that is the cheapest nine you will ever buy.
Closing Thought
What makes this topic worth a post rather than a table is that every one of these distinctions is invisible at runtime. A gateway with one idle interface works. Gateways split across regions work. IPsec on a single VM works. Active-passive with a peer that never set different MED values works, and looks exactly like the active-active it actually is. Nothing in the console, and nothing in any health check, distinguishes the 99.99% arrangement from the one that inherits a single VM's SLA. The only way to know which you built is to read the wiring against the four topologies and check.
And the honest footnote on the nines themselves: 52.56 minutes a year is the budget, while a single tunnel failure spends up to a minute of expected packet loss on a routing withdrawal that the SLA does not count as downtime at all. The number is doing a narrower job than people assume. It describes whether the service was there, not whether your connections survived — and after three posts on Cloud Router, dynamic routing and MED, it is satisfying that the answer to "why did the failover hurt" turns out to be route convergence rather than anything about the VPN.
#87 leaves IPsec behind for the first time in this block: Cloud Interconnect, Dedicated — the option where the capacity is physical and the SLA is bought with cross-connects rather than tunnels.
Comments