Hi, Xiaowen, I'd like to connect my Cloud Run
service to other resources in my VPC network.
How do I set that up? Hi, Martin.
Okay, so you've got a bunch of resources
running your own virtual network on Google Cloud, right?
Yeah, I have a Redis cache, and my company also
has a database hosted on a virtual machine.
Got it.
So let me show you how to connect your Cloud Run service
to resources in a VPC or a virtual private cloud network.
We now have a great new feature where you can connect directly
instead of proxying it through a connector.
Xiaowen, you are a product manager
for Cloud Run, focusing on networking and security, right?
That's right.
And as a product manager,
I hear from customers who want to make calls from Cloud Run
to other resources in their VPC network or attached to their VPC network.
These resources can be virtual machines, databases,
memory storage instances, and even on-prem systems.
And I'm happy to say that this is now much easier to do.
Great. How does it work?
When you create a new Cloud Run service,
you can decide which VPC network it should be able to send traffic to.
Here is one of my Cloud Run services.
It can send traffic to the default VPC network.
I see.
And connecting it directly like this is probably easier than what we had to do
before, right?
Yes. It's easier to set up and your traffic will be faster too.
We have heard from a lot of customers who really like the direct connectivity.
For example, Carrefour said that is simplifies their architecture,
aligns with their pay-as-you-go model and it improves the total cost
of ownership of their pipelines. Excellent.
I like it when things become easier and faster.
Now I built a simple REST API in Cloud Run.
The REST API returns artists from a database.
For example, when I hit this endpoint
it returns
Frida Kahlo, one of my favorite artists.
Hmm. That felt a bit slow. Yes.
And that's where the cache comes in.
I'd like to speed up my API by caching artists
in a Redis cache and there is a Google product called Memorystore.
It’s a managed Redis instance.
And do you have a Memorystore instance already?
Yep. Here it is.
When I set it up, I had to fill out which VPC network it should belong to.
I picked “default” here.
Is that fine? Yes.
Let's use that.
Your Memorystore instance will be reachable from that VPC.
The default network was automatically created for your project.
All right.
I updated my source code to check the cache first
whenever the REST API is called.
Now how do I configure my Cloud Run service
so it can connect to the Memorystore instance?
First, go to your Cloud Run service in the Console.
Then click “Edit and deploy new revision”.
Pick Networking.
Check “Connect to a VPC for outbound traffic”.
Here you can choose either “Serverless VPC access connectors”
or you can send traffic directly to a VPC.
Let's pick that second option and select the default network and subnet.
You remember that our Memorystore instance is on the default VPC network.
So we want our Cloud Run service to connect to that network.
Got it.
What should I write in the “Network tags” field?
That field is optional.
You can write something that lets you identify the service.
Let's enter “frontend” for now.
We'll come back to this later.
Now deploy the updates.
Nice.
That was super easy. Yep.
And can you click on the Networking tab?
Sure. Here we go.
I see.
It shows the network, the subnet, and the network tag that I configured.
Should we check that it worked?
Oh, right. Let's do that.
Let's hit the service and ask for Frida Kahlo again.
Okay.
We got a reply, and it was pretty slow.
Now let's do it again.
Now, the cache should help us.
There it is.
Much faster than the previous time.
The cache seems to be working fine. Great.
Yes, indeed.
But I have a few questions for you, Xiaowen.
Sure.
I know a lot of viewers also have services running on-prem,
and those services are connected to their VPC in Google Cloud.
Can Cloud Run also connect or hit those on-prem systems
using this new feature we just looked at? Yes.
As long as the on-prem systems are connected to your Google Cloud VPC
using either Cloud Interconnect or a VPN.
Got it. Next question.
How much does this VPC connectivity cost not just for calling from Cloud Run
to on-prem systems, but also for Cloud Run calling
Memorystore, CloudSQL, virtual machines and so on?
Glad you asked.
There's no fixed monthly cost.
You'll pay for traffic going from your Cloud Run service
just like you'd pay for traffic from a virtual machine and the VPC
and it's charged at the same rate.
And if I'm using any Serverless VPC connectors in my project today,
I can switch my Cloud Run services
over to this direct access and remove those connectors.
Because that would lower my cloud bill, right?
Yes, for sure.
And some customers have done that already.
But before you do so, be aware that as of this recording,
this feature is still in preview.
So I shouldn't use it for my production workloads just yet.
Right, exactly.
And it currently comes with some limitations.
Many of them will go away when this feature goes to General Availability.
And I see a preview banner here.
That will go away when it hits General Availability?
Yes, check that banner or the release notes for the status of this feature.
Sounds great. All right. Next question.
One of my projects has several Cloud Run Jobs that run every night.
They do database cleanup and such.
Can these Cloud Run Jobs connect directly to a VPC as well?
Yes, they can.
And what about Cloud Functions?
Cloud Functions second generation can connect directly as well.
You have to set direct VPC egress on the function’s underlying Cloud Run service.
Excellent.
My next question is about fine grained access.
Let's say I have a sensitive ERP system
also running in my VPC, and to play it really safe,
I don't want my Cloud Run service to be able to reach that ERP system.
How would I set that up?
You can do that with firewall rules.
Remember how you set the network tag “frontend” when you configured VPC access?
All right. You told me to. Yeah.
Yeah.
You can define firewall rules based on network tags.
So you can, for example, define a rule that blocks traffic
from “frontend” to resources tagged “erp”.
Very good.
Now, about IP addresses.
Any virtual machine on my VPC will use an IP address.
I know that much.
Will my Cloud Run service also use these internal IP addresses?
Yes, they will.
You can run this command
to see which IP addresses have been allocated from your subnet.
You can also see these IP addresses here in the Cloud Console
under VPC network, IP addresses.
Got it.
And can I write firewall rules based on those IP addresses?
No, not quite.
Those IP addresses are dynamically allocated and can change at any time.
You're better off writing firewall rules based on network tags,
just like we talked about. Got it.
What if my Cloud Run service scales up?
It gets a lot of traffic.
I guess it would use more internal IP addresses.
Can I run out of them?
That's a great question.
Cloud Run pre-allocates IPs to make scaling up faster.
You need to make sure there are enough IPs available on your subnet.
My rule of thumb is that you should have
at least a few hundred IP addresses available. If the subnet’s total number
of instances across all Cloud Run services and jobs grows beyond 100,
then multiply the max instance count by four
and make sure there are at least that many internal IP addresses available.
Well, I'm not really a networking guy.
Could I just use the default VPC network and subnet?
Guess what?
If your company does not have a networking guy or gal,
then the default VPC and subnet will almost certainly work for you.
IP address exhaustion typically becomes an issue
in more advanced networking setups, such as if you're managing a single
shared VPC, connecting together services from hundreds or more projects.
In that case,
you can read our documentation to learn more about additional options.
All right, let's recap. Xiaowen.
What are the takeaways?
Your Cloud Run services can now access the resources
in a VPC directly in a way that's easier and faster.
And you will also reduce your bill and your system complexity
when you get rid of your Serverless VPC access connectors.
If you're going to use this new feature in production, check the documentation
first and make sure it has graduated from preview to General Availability.
I will try it out for my Cloud Run services.
It's just a few clicks after all.
I think anyone watching this should try it out as well.
Thanks for joining me today, Xiaowen.
Thanks for having me, Martin.
And thank you, everyone for watching.
If you have questions for Xiaowen or me, please add a comment below.
Also, let me know
if there are other serverless topics you'd like to see in future episodes.
I read every single comment.
Until next time.