Business Challenge
Two posts of Cloud Router and dynamic routing have been building towards the product that uses them, and the first thing to settle is that these are not two service levels. The glossary is unusually direct about it. Classic VPN: the predecessor to HA VPN. And HA VPN: replaces Classic VPN with a gateway that provides a 99.99% availability SLA. Predecessor and replaces are the documentation's words, not a reading of a roadmap.
What makes that worth a whole post is that the two are not merely configured differently — they are different resources with no path between them, and the differences land in places people do not look until something is already built.
There is no upgrade. You cannot migrate an existing Cloud VPN tunnel or tunnels on a Classic VPN gateway to an HA VPN gateway. The instruction is explicit about what you do instead: instead, you need to create new tunnels and delete the old ones. There is not even a transitional topology to lean on, because you cannot connect a Classic VPN gateway to an HA VPN gateway. And the address does not survive: the external IP address of your Cloud VPN gateway cannot be preserved.
Correct approachDecide once, at design time, and decide it with the peer's owner in the room — because the deciding constraint is on their equipment, not yours. If the peer cannot run BGP you do not have a choice to make at all, and if it can, there is no reason to build the thing you will have to tear down. Treat "start with Classic" as a commitment to a future rebuild with a new IP address, and price that honestly.
It will not, per tunnel. Each Cloud VPN tunnel supports up to 250,000 packets per second for the sum of ingress and egress traffic, and that sentence is about Cloud VPN tunnels, not about one gateway type. HA VPN gives you an SLA, two interfaces and more tunnels; the ceiling on each tunnel is the same one Classic has.
Correct approachSize with tunnel count, not gateway choice, and note what the limit is actually denominated in. It is packets, not bits — 250,000 packets per second is equivalent to between 1 Gbps and 3 Gbps of bandwidth, and which end of that range you get is decided by your average packet size, which is a property of your traffic rather than of your configuration.
Only if you brought up both interfaces. This is the sharpest sentence on the page: 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. Not a reduced SLA — no availability SLA. The resource is still called an HA VPN gateway, the console accepts it, and the thing you chose it for is simply absent.
Correct approachAudit interface and tunnel count, not resource type. "Is it an HA VPN gateway?" is the wrong question; "are both interfaces active, each with a tunnel to its own peer interface?" is the right one. And note the ceiling even when you do it properly: HA VPN provides 99.99% SLA for most topologies, with a few exceptions — most, with exceptions, which is #86's subject.
Architecture
Two resources, one of them superseded, and a set of differences that is longer than the SLA line everyone quotes.
The split, in full
The gateways differ on availability, on addressing, on routing, on protocol support and on what they are even called in the API. Taking those in order, because each one has an operational consequence.
Availability. HA VPN provides 99.99% SLA for most topologies, with a few exceptions; Classic provides a 99.9% SLA. Stated again in prose: Classic VPN gateways provide an SLA of 99.9% service availability.
Addressing and setup. For HA VPN, external IP addresses created from a pool; no forwarding rules required. For Classic, external IP addresses and forwarding rules must be created. HA VPN's allocation is automatic and deliberately spread: when you create an HA VPN gateway, Google Cloud automatically chooses two external IP addresses, one for each of its interfaces, and each IP address is automatically chosen from a unique address pool to support high availability. They are not yours to keep — when you delete the HA VPN gateway, Google Cloud releases the IP addresses for reuse.
Routing. HA VPN is only dynamic routing (BGP); Classic is only static (policy-based, route-based) routing. The creation page states the HA side as a flat prohibition: HA VPN does not support static routing.
Protocol support. HA VPN supports dual stack (IPv4 and IPv6) and IPv6-only configuration; Classic does not, said three ways across two pages — Classic VPN gateways don't support IPv6, Classic VPN does not support IPv6, and at tunnel level HA VPN tunnels support the exchange of IPv6 traffic, but Classic VPN tunnels don't. If IPv6 is anywhere on the horizon the decision is already made.
What they are called. HA VPN is known as the vpn-gateway resource; Classic is known as the target-vpn-gateway resource, and Classic VPNs are referred to as target VPN gateways in the API documentation.
They are different resource types, so every tool that touches them is type-specific: Terraform resources, IAM conditions, org policy constraints, asset inventory queries, custom dashboards, scripts that enumerate gateways. An estate that migrates Classic to HA VPN has to revisit all of it, and the failure mode is quiet — a query that enumerates targetVpnGateways keeps returning results for as long as one Classic gateway survives, then starts returning an empty list that reads exactly like "no VPN configured". Audit tooling written against the old resource does not error after a migration; it reports clean.
A tunnel is half a connection
One definition in the glossary explains more support cases than its length suggests: two VPN tunnels must be established to create a connection between two VPN gateways, each defining the connection from the perspective of its own gateway, and traffic can only pass after the pair of tunnels is established.
So a tunnel showing healthy on your side is not a working connection, and "my end is up, the problem is yours" is a sentence with no content — your end being up is the normal state of a half-configured connection. Related and useful when a peer blames direction: Cloud VPN always initiates IKE.
The pairing also explains a Classic limit that looks arbitrary: with Classic VPN, it isn't possible to create two VPN tunnels within the same Cloud VPN gateway to the same destination VPN gateway. With one interface and one address there is no second vantage point to define a second connection from, so redundancy has to come from a second gateway — you can provide redundancy and failover for Classic VPN gateways by using a second Classic VPN gateway. That is the whole architectural difference in miniature: on Classic, redundancy is another gateway you build and operate; on HA VPN it is the gateway, because each of the HA VPN gateway interfaces supports multiple tunnels.
What the bandwidth number is really telling you
The limit is quoted in packets and alerted on in bytes, and the page does the conversion rather than leaving it to you: when converted to bytes, the limit is 375 megabytes per second (MBps). That is 3 Gbps divided by 8 bits, so if you are building an alert, the threshold is 375 — and the metric you compare against it is the sum of sent and received, because the packet limit is itself a sum of both directions.
The practical trap is the gap between the two ends of the stated range. A tunnel carrying small packets — telemetry, DNS, health checks, chatty RPC — hits 250,000 packets per second nearer 1 Gbps than 3. A tunnel carrying bulk transfer reaches the upper end. So two tunnels with identical configuration can saturate at a three-fold difference in apparent bandwidth, and neither is misbehaving. If a link is being throttled well below what you provisioned for, the question is packet rate, not bits.
Why This Architecture Holds Up
Because there is no conversion, migration is a build-and-cut-over, and the documentation lists the constraints plainly. The first is not yours to fix: your peer VPN device or service must support the Border Gateway Protocol (BGP). If it does not, you cannot use HA VPN. That is the gate on the entire decision, and it sits in somebody else's equipment room.
Then there is a constraint that will catch anyone with an existing hybrid estate, and it is the kind of thing you discover at the worst moment: the Cloud Router that you use must not already manage a BGP session for a VLAN attachment associated with a Partner Interconnect connection, because of that attachment's specific ASN requirements. If your plan was to reuse the Cloud Router that already serves your Partner Interconnect, the plan needs a new Cloud Router.
The last instruction in the migration procedure is the one to put in the runbook: if the previous VPN tunnel or tunnels were policy-based or route-based, remove any leftover custom static routes.
Read against #84, that is not housekeeping. Those tunnels used static routing — a policy-based or route-based Classic VPN tunnel uses static routing — and #84 established that dynamic routes always rank below static routes. So the orphaned static routes do not sit harmlessly alongside the BGP-learned routes your new HA VPN tunnels produce. They beat them. The new gateway comes up, BGP establishes, the dynamic routes appear in the table exactly as expected, and traffic still goes to a next hop you have deleted. Every check you would naturally run — tunnel status, BGP session state, route presence — passes.
There is one more reason those routes linger, and it is worth knowing which way round it works: a Cloud VPN tunnel can be a next hop for a custom route in your VPC network. If the console created those routes for you when the tunnel was built — which it does for policy-based tunnels, from the remote ranges you typed — then nobody on the team ever wrote them, nobody owns them, and they are not in anyone's Terraform. They are exactly the kind of resource that survives a migration.
Two pages that appear to disagree
Worth flagging, because it will come up the moment anyone reads past the comparison table. The overview's table says Classic supports only static (policy-based, route-based) routing, and the only documented way to create a Classic gateway is a page titled for static routing. But the routing reference describes, in the present tense and more than once, a Cloud Router always manages a Classic VPN tunnel that uses dynamic routing or an HA VPN tunnel.
I am not going to narrate a cause the documentation does not state. What I will say is how to read them: the comparison table and the creation page tell you what you can build; the routing reference tells you how something that exists behaves. If you have inherited an estate, the second may describe your tunnels even though the first describes your options. If you are designing something new, only the first applies.
Where the regional boundary sits
One line from the glossary that is easy to skim and governs blast radius: each Cloud VPN gateway is a regional resource that uses one or more regional external IP addresses. A gateway is regional, on both types. The reach of what it learns, though, is not a property of the gateway — that is the dynamic routing mode from #84, set on the network. Two separate decisions, and conflating them is how people end up expecting one HA VPN gateway to be a global ingress.
The two also compose with the routing mode differently, which closes the loop on #84's scope limit. HA VPN tunnels are BGP, so they are Cloud Router tunnels and the dynamic routing mode governs them. Classic's policy-based and route-based tunnels are static, which is precisely why #84's page said the mode does not affect them. The setting that looked network-wide stops at the gateway type.
Key Architecture Decisions
| Situation | Decision | Because |
|---|---|---|
| Any new VPN connection | HA VPN, unless the peer cannot run BGP | Classic is the predecessor; HA VPN replaces it, and there is no upgrade path. |
| Peer device cannot run BGP | Classic VPN, knowingly | Without BGP on the peer, you cannot use HA VPN at all. |
| Checking you have the SLA you chose HA VPN for | Count active interfaces, not resource type | A one-interface HA VPN gateway provides no availability SLA. |
| IPv6 anywhere in the plan | HA VPN, no discussion | Classic supports neither dual stack nor IPv6-only. |
| Needing more throughput | Add tunnels; do not change gateway type | The 250,000 pps per-tunnel limit is the same on both. |
| Alerting on tunnel saturation | Threshold 375 MBps on sent plus received | The limit is a sum of both directions, and the metrics are in bytes. |
| A tunnel saturating below expectations | Look at packet rate, not bits | The same limit is 1 Gbps or 3 Gbps depending on average packet size. |
| Redundancy on Classic | Build a second Classic gateway | Two tunnels to the same peer gateway from one Classic gateway are not possible. |
| Planning a Classic to HA VPN migration | Treat it as a new build with a cut-over | Tunnels cannot be migrated and the external IP cannot be preserved. |
| Hoping to run both during cut-over | Plan peer-side redundancy instead | A Classic gateway cannot be connected to an HA VPN gateway. |
| Reusing the Cloud Router that serves Partner Interconnect | Create a new Cloud Router | That router must not already manage a Partner Interconnect attachment's BGP session. |
| Finishing a migration | Delete the leftover custom static routes | Static routes outrank your new dynamic ones, so traffic keeps going nowhere. |
| A peer insisting the fault is your end | Confirm both tunnels of the pair are established | Traffic passes only after the pair is up; one healthy side proves nothing. |
| Inventory or IAM tooling after a migration | Rewrite it for the vpn-gateway resource | The two gateways are different resource types, and the old query returns empty, not an error. |
The one to look at today
List every Cloud VPN gateway you have and record two things per gateway: its resource type, and how many interfaces are actually carrying a tunnel. That gives you the real answer to "what is our VPN availability", which is not the same as what the resource is called. Then, for anything already migrated, list the custom static routes whose next hop is a Cloud VPN tunnel and check that each one still points at a tunnel that exists. That second list is the one most likely to contain something nobody meant to keep.
Closing Thought
The honest shape of this topic is that the interesting part is not the comparison. The feature table takes a minute and the conclusion is never in doubt once you have read the word "predecessor". What takes the day is everything the comparison does not mention: that the resource types differ and so does every tool that names them, that an HA VPN gateway can be built in a configuration that quietly carries no SLA, that the throughput ceiling people migrate for does not move, and that the final cleanup step is load-bearing in a way its one sentence does not convey.
That last one is the thing I would want to have known in advance. The migration can be executed perfectly — new gateway, two interfaces, BGP up, routes learned, old tunnels deleted — and still not carry traffic, because of a static route created automatically years earlier from a form field, owned by nobody, and ranking above everything you just built. #84 made that ordering rule sound like a piece of routing trivia. It is the sharpest edge in this post.
#86 takes the exceptions seriously: HA VPN topologies and their SLAs — which arrangements actually earn 99.99%, which fall back to 99.9%, and which earn nothing at all.
Official Google Cloud Reference
- Cloud VPN overview
- Cloud VPN key terms
- Classic VPN topologies
- Move from Classic VPN to HA VPN
- Order of routes
- Create a Classic VPN gateway using static routing
- HA VPN topologies
- Create HA VPN gateways
- Networks and tunnel routing
- MTU considerations
- Supported IKE ciphers
- Topologies to increase bandwidth
- Check VPN status
Comments