Cloud Run direct to your VPC
Cloud Run direct to your VPC
Direct from the source to the private network, now with less hops!
Currently in public preview, a new way of connecting to your internal VPC network from the public-internet-mode of Cloud Run is using Cloud Run in Direct VPC egress mode. This has a number of benefits including increased throughput with fewer network hops and as a result, lower latency. There are some considerations which are important to review though. Let’s get stuck in!
What is it?
What is Cloud Run in VPC Egress mode anyway? Before we answer that, it’s important to understand what the current lay of the land is before we jump into the new and shiny. Currently in GA, the way to connect to your internal network from the public-internet-running Cloud Run instances is to make use of the tried and true VPC serverless access connectors. These connectors provide a proxied connection to internal resources inside your VPC such as VMs and CloudSQL instances. There’s no direct route to your internal network, so this connector proxy acts as a bridge to provide that access.
Ok, so now that we know what we’re dealing with currently, what’s the new shiny approach? Glad you asked. The Direct VPC Egress mode, that Google is calling it, is allowing your serverless compute which runs on a public network access the internal resources without the need for a connector. When you enable this mode the Cloud Run instances that are serving your traffic are given internal VPC IP addresses. The network interface that is assigned to this instance is automatically provisioned with a firewall rule that only allows for TCP/UDP egress. This means you can’t reach the Cloud Run instance via the VPC network. You’ll have to go through the public HTTP routes if your VPC is walled off and you have a NAT. This should make the security team happy!
Comparison
Wietse Venema has some excellent diagrams on the two access methods which I’ll share here.
Now that we know what we’re dealing with, let’s compare some of the advantages of Direct VPC Egress (DVE) vs VPC Access Connectors (VAC).
In both cases you can still scale your service to zero, however with the VAC method, you’re still paying for the VM(s) running the connectors regardless of if they’re in use or not, however with DVE, you’re only paying when your instances are in use. The flipside of this, is that the instance autoscaling is slower due to additional provisioning time of the new VPC network interface we discussed earlier that provides the Cloud Run instance with its private IP. Although, if you’re scaling very rapidly then there might be some additional latency if more VAC instances are added to the network.
With the above in mind, some advantages as briefly mentioned earlier are that the latency is lower and the throughput is higher with the DVE mode as there are fewer network hops before your instances are connecting to your internal VPC resources. In both cases the usual trimmings of the gcloud cli are available if that’s how you roll, along with the console. However, if you’re more an infrastructure-as-code kinda engineer, then there is terraform available for both modes.
What’s holding me back?
So you’re sold on Direct VPC Egress? Cool. But before diving in, what are the limitation of this new fandangled mode of running Cloud Run instances?
The most up to date info will always be in the documentation, so please double check before running off, but for the sake of this post, let’s talk about some of the few key limitations.
The biggest one and also the first on the list in the docs at time of writing is that you’re limited to at most, 100 instances. The docs also mention only using DVE for jobs that don’t require more than 8 concurrent requests.
Second, there’s only 5 regions supported. And sadly, the two Australian regions aren’t in that list. The supported regions are:
Iowa
South Carolina
Belgium
Frankfurt
Tokyo
A number of services are not supported by DVE either, this includes (but isn’t limited to): Cloud NAT, VPC Flow Logs, IPv6, network tags in firewalls for ingress on the destination resource. I’d encourage you to check the docs for the full list.
Summary
The development of the Direct VPC Egress for serverless services is exciting and a great step forward. For some use cases though there are still benefits to using the existing connector service. For example, availability in more regions and being able to route out through NAT. Also that it will use fewer private IPs (if that is of concern).
With this said, it’s important to remember that this new mode is still very much in preview and I would hazard a guess that a number of these features are being worked on to bring closer parity to the connector method. Another option to consider is: do you even really need it? If you’re only connecting to SQL instances for example, you could make use of the CloudSQL auth proxy.