GCP Static IP vs VPN Speed: Three Variables, One Test

The transfer got faster after the address was reserved, and the conclusion wrote itself. Except the same change also switched the tunnel from UDP to TCP, moved the test to a different evening, and possibly landed on a VM in another zone. Reserving an external address fixes a lifecycle problem: it keeps the endpoint the same across restarts. It has no mechanism that would accelerate packets, so a speed difference in that experiment belongs to the other variables, and the decision in front of you is which one to test next.

What a reserved address actually buys

Compute Engine distinguishes ephemeral addresses, allocated and released with the instance, from static addresses that you reserve and keep. That difference is about retention and billing, not about the path a packet takes. A stable endpoint is genuinely useful for DNS records, remote access profiles, partner allowlists and firewall rules that should not change when a VM restarts.

Those are good reasons to reserve one. None of them is a throughput reason.

Keep tier, address and transport as three variables

Google Cloud also sells Premium and Standard Network Service Tiers, and the two take different paths to the internet with different feature availability. Static addressing is orthogonal to both, so treat static and Premium as unrelated facts about a VM rather than synonyms. Record the actual tier, the region and any interconnection or attachment in play, because those describe the path in a way the address label never will.

Three variables, three separate experiments, or the result is a story rather than a measurement.

Design a test that answers one question

Hold the VM, address, client location, destination and workload fixed while comparing approved UDP and TCP profiles. Both a server listener per transport and matching firewall rules are required; editing a client keyword and leaving the listener unchanged tests nothing but your patience. Use a repeatable transfer, and record direction, duration, single versus parallel streams and the units, since MB/s and Mb/s differ by a factor of eight.

Watch the VM's CPU as well, because a small instance saturates on encryption or softirq work long before the network does, and that ceiling will look exactly like a provider limit.

Retransmission and loss counters from the VM and the client separate path trouble from transport trouble, and a progress bar cannot. A workable sequence with iperf3 takes about ten minutes per transport. Start the server on the far side, run the client for thirty seconds in each direction, and repeat each direction three times. Discard the first run of every series, then compare sender and receiver rates together with the retransmit count the TCP runs print.

Why UDP and TCP differ, mechanically

OpenVPN over UDP carries datagrams and lets the application's own transport handle loss. Over TCP, the tunnel's reliable stream sits underneath an already reliable application stream, so one lost segment stalls everything behind it while the outer connection retransmits on its own schedule. That head-of-line behaviour is a property of tunnelling TCP inside TCP, not a provider policy. MTU and MSS handling differ between the two modes as well, which changes fragmentation behaviour on the same path.

A faster TCP trial therefore proves that TCP was faster that day on that path, and nothing more general.

Write the result so it survives review

A defensible conclusion has a shape: this profile, on this machine size, on this network tier, sustained this measured workload in this direction under these conditions. Anything broader needs more runs than one evening can supply. If the slower case stays unexplained, keep it as an observation with its packet and resource evidence rather than inventing a throttle that no provider document describes.

Address stability and transfer speed can both matter to the same deployment, and the useful decision is which of them you are buying with each change.