STEPHANIE WONG: As a Cloud Developer,
one realization you quickly have is
that despite being on the cloud, you
don't want everything publicly accessible.
In this episode of Cloud Networking,
we cover how to protect your internal endpoints
using Cloud NAT.
Stay tuned.
Let's say you've got a cloud application
with internal services and you want
to restrict inbound communication while still
allowing outbound.
One of the traditional ways to do this
would be through a VPN service that secures, authorizes,
and handles that connection for you, which is fine but runs
into a large problem that you're still
using public IPs, which leaves you
vulnerable to malicious actors.
Another secure setup would be something
called a bastion host--
basically an external endpoint which allows your clients
to SSH from the public internet and still
keep your apps from being public-facing, which,
again, works, but this only deals with one
side of the problem.
Namely, inbound communication.
But let's say you have a multi-tiered application
setup in the cloud and you have an update server on premise.
You want to allow your instances outbound access
to the internet for updates, patching,
config management, and more without having an external IP
address.
That way, you can keep your instances
entirely internet-facing in a controlled and efficient
manner.
For this, it makes a lot more sense
to setup a Network Address Translation, NAT,
gateway machine, which routes traffic and lets multiple VMs
in a subnet reach the internet using a single public IP
address.
Now, normally, this requires a fair bit of toil.
Building a high availability and high bandwidth NAT gateway
usually requires reserving static IP addresses,
creating compute instance groups as the NAT gateways,
creating health checks to monitor their responsiveness,
and adding default routes to these instances.
And with traditional NATs, you'd have a NAT proxy
instance between your cloud instances
and their destination.
This means a potential choke point in the path,
undermining performance, throughput, and availability.
Fortunately, Google Cloud NAT is a software-defined networking
SDN solution that avoids these problems.
It's a fully managed offering that lets Google Cloud VM
instances without external IP addresses
and private GKE clusters connect to the internet.
It doesn't require custom routing and simplifies
and delivers scale, because it uses
SDN instead of being an instance or an appliance
that you have to manage.
And better yet, outside resources
can't directly access any of the private instances behind Cloud
NAT, thereby helping to keep your VPCs isolated and secure.
The best part?
It doesn't use a proxy.
Instead, each of your internal instances
is given a unique set of NAT IPs and port ranges,
which are used by Andromeda, Google's network virtualization
stack, to perform that.
This means no choke points, better scalability,
performance, and availability.
Cloud NAT scales seamlessly with the number of instances
and the volume of network traffic.
And you get as much bandwidth as instances that do
have external IP addresses.
Let's dive into how to set up Cloud NAT.
Here I have two VMs set up in the same VPC and subnet.
I want web server to be private, so I've set it up
with no external IP address.
In order to access it, I've set up a second VM
to act as a bastion host, which does have an external IP
and allows for inbound traffic to my web server.
I've also set up firewall rules so
that I can only use the bastion host to SSH into the web
server.
I'm using the local terminal to SSH into the bastion host
to then SSH into the web server.
You can see here I don't have the ability
to access the public internet, because when
I try to pull content from example.com, it hangs.
Now, let's set up Cloud NAT to route egress traffic
from the web server to the internet using Cloud NAT's
allocation of IP addresses.
Head to the Google Cloud NAT page and click Get Started.
Enter a gateway name.
Choose the VPC network your instances are in.
Set the region for the NAT gateway,
which should be the same as where your instances are.
Now create a Cloud Router in the region and give it a name.
Leave the rest as default. Leave the NAT IP
addresses to automatic, which is recommended and automatically
allocates IP addresses based on usage.
These IPs are used to translate the internal addresses
of instances.
And now click Create.
Now, going back to my web server instance,
I can now access example.com and see its content while it still
has no external IP address.
It's important to note that Cloud NAT doesn't set up
inbound NAT.
So instances outside your VPC can't
initiate their own new connections to your cloud
instances with NAT.
But Cloud NAT is a great managed service
for things like fetching periodic updates
from an external server and another network.
As you grow your cloud environment,
centralizing control and simplifying your network
topology is going to save you cycles in the long run.
Stay tuned for the next episode.
And remember, optimizing your network
means freeing up your bandwidth.
[MUSIC PLAYING]