[MUSIC PLAYING]
STEPHANIE WONG: One of the linchpins of on-prem systems
is the aggressive use of IP addresses
to balance, scatter, and manage traffic
coming into your environment.
This is built into the configuration of your routers,
firewalls, and most of the hardware and software you've
got lying around.
As you migrate portions of your environment to the cloud,
however, you have to be aware that this IP address logic will
change in various ways.
As such, it's crucial to plan ahead for your IP address
changes that could affect your workloads
and how they interact with internal and public network
traffic.
In this episode, I'll be covering private and public IPs
on Google Cloud, and how you can achieve remappable
IP addresses for your cloud resources.
Stay tuned.
The main challenge is that you can't simply
move your existing IP addresses to the cloud
along with your services.
Cloud providers and data centers have a limited pool
of IP addresses that they own, and they often
reuse previously-assigned IPs in order to maximize them.
The result is that your services will receive
a dynamically-assigned internal and public IP address, which
by default are ephemeral, meaning
if you restart those instances, you'll lose those IPs.
For companies in this situation, there
are basically two solutions which you could run through.
Define firewall rules by using tags instead of IP addresses.
Forward traffic through a managed load
balancer with a static IP.
Of course, both will work, but they both
come with a large downside.
As your cloud IPs continue to change,
they'll break any dependencies your services might
have on those IPs which are hardcoded
or require a network admin to manually change,
which can quickly turn into a nightmare of maintenance.
For example, let's say you spin up your first back-end machines
in the cloud and decide to tear them down for a period of time
to save on costs.
Suddenly, when you're ready to get them up and running again,
you'll notice that you lost those dynamically-assigned IPs,
only to find new ones.
Now you have to reconfigure your on-prem app
and any firewall rules to point to the new public IP
of your cloud back-end.
This can grow pretty tiresome and unwieldy
over large environments.
Thankfully, Google Cloud allows you
to get around this situation by reserving
static IPs for your services.
So if your VM is shut down, you can
retain the same internal and public IPs
when you spin it back up.
What this means is that you can feel relaxed
knowing that if you point a forwarding rule, firewall
rule, or application to your cloud instance
IP from within or out of the VPC network,
you won't need to reconfigure the IPs each time
you shut down your instances.
This really comes in handy if you
are dependent on a specific IP address for your service
and need to prevent your teammates from being
able to use that address.
And the best part?
You can even promote a previously ephemeral IP
to be a static one, helping you cut corners in a few places.
Let's dive into IPs a bit more.
For Compute Engine, you can assign one internal and one
public IP address for each VM.
It's important to note that you don't
need public IPs for your VMs within the same VPC
to communicate, and this can really
help network performance.
On the other hand, if you need the VM to communicate
with the internet or any VM in a different VPC network,
your VM has to have a public IP address,
unless you've set up some sort of proxy or VPN
in the other network.
For both cases of internal and public IP addresses,
you can choose ephemeral and static IPs.
Let's start with internal IPs.
When you create a VM, unless you specify an internal IP
within your subnet range, Google will just
assign your VM an ephemeral internal IP
from your subnet range.
You can reserve one later on and assign it to your VM
if you decide you need a static internal IP later.
For public IPs, the same applies.
Unless you assign your VM a reserved static public IP,
Google will assign an ephemeral public IP randomly from a pool,
or you can choose not to assign a public IP whatsoever,
which can be good for keeping instances
from being exposed to the public internet
and reduce security risk.
Later on, you can always assign one.
There's also a way to create a custom public IP on GCP, as
well, but I'll point you to the documentation linked below.
Let's walk through IP setup.
Let's take a look at a VM I just created with Apache 2 installed
deployed in useast-1.
First, head to the Networking tab.
By default, you're given an ephemeral internal and public
address.
I'm going to remove the ephemeral public IP,
and you can now see it has no public IP address.
It's important to note that if you're an internal VM talking
to other internal VMs, then you need
to be using the internal address for the best performance.
Otherwise, your internal VM has to travel back
to the public internet, which can slow it down.
Now, as I mentioned, by default, your VMs
will use ephemeral public IPs, but sometimes you
need static ones that won't change over time.
Thankfully, you can create this right in Google Cloud.
Go to the Network tab, and then in External IP Addresses,
create a static one.
And note that we can also just promote an ephemeral one.
You want to create the IP in the same region as the instance,
unless you're doing global forwarding,
because static IPs are regional resources.
You can assign the IP to the instance right from here.
And now you see we have a new static public IP address
assigned to the instance.
And as long as you have the right firewall
setup to allow HTTP traffic on port 80,
now you can see that we have access to the web page
through the new static IP address.
Once you understand how IP addresses are affected
when different actions are performed
in your overall architecture, you
start to realize the importance of using remappable IP
addresses, especially for front-end servers in the cloud.
But what if you don't want a public IP address in order
to maintain higher security, yet you still
want to be able to do things like fetch updates
from the public internet?
Stay tuned for the next episode to find out how.
And remember, optimizing your network
means freeing up your bandwidth.
[MUSIC PLAYING]