Virtual Private Cloud (VPC) is Google's managed networking functionality for the
Cloud platform resources
Networking is dissected into its fundamental components - Projects, Networks, Subnets, IP addresses, Routes
and Firewall Rules, along with network pricing
VPC is a comprehensive set of Google managed networking objects - Projects, Networks, Subnets
Projects are going to encompass every single service that one uses including
networks
VPC provides IP addresses for internal and external use along with granular IP address range selections
This following illustration describes Projects and Networks:
Fig.4
Projects actually contain entire networks. The default quota for each project is 5 networks. One can simply
request additional quota using the GCP console
Networks can be shared with other projects or they can be peered with networks in other projects
Networks do not have IP ranges but are simply a construct for all of the individual IP addresses and
services within that network
Networks are global, spanning all available regions across the world. This means a user can have one
network that exists anywhere in the world, Asia, Europe, Americas, all simultaneously
Inside a network a user can segregate their resources with regional subnetworks
This following illustration shows the VPC network types:
Fig.5
Networks come in three different flavors - Default, Auto
Mode, and Custom Mode
Every project is provided with a Default VPC network with preset subnets and firewall rules.
Specifically a subnet is allocated for each region with non-overlapping CIDR blocks and firewall rules
that allow ingress traffic from ICMP, RDP, and SSH traffic from anywhere, as well as ingress traffic
from within the default network for all protocols and ports
In an Auto Mode network, one subnet from each region is automatically created within it. The Default
network is actually an Auto mode network. These automatically created subnets uses set of predefined IP
ranges with a /20 mask that can be expanded to a /16. All of these subnets fit within the 10.128.0.0/9
CIDR block. Therefore, as new GCP regions become available, new subnets in those regions are automatically
added to auto mode networks using an IP range from that block
Auto Mode Networks are easy to set up and use because they automatically create Subnets in each Region.
However, one does not have complete control over the IP address ranges used within the Subnets created in
their VPC network
When Auto Mode Network is created, it will have the same standard Firewall Rules that the Default
Network has
A Custom Mode network does not automatically create subnets. This type of network provides the user
with complete control over its subnets and IP ranges. The users decide which subnets to create in regions
they choose and using IP ranges they specify within the RFC 1918 address space. These IP ranges cannot
overlap between subnets of the same network
One can convert an Auto mode network to a Custom mode network to take advantage of the control that
Custom mode networks provide. However, this conversion is one way. Meaning that Custom mode networks
cannot be changed to Auto mode networks
** TIP **
If one ever deletes the Default Network, one can quickly re-create it by creating an Auto Mode Network
This following illustration is an example of a Project with 5 networks:
Fig.6
In the above example in Fig.6, the Project contains five Networks. All of these networks span multiple
Regions across the world. Each Network contains separate VMs - A, B, C, and D
VM's A and B are in the same network and they can communicate using their internal IP address even
though they are in different Regions. Even though the VMs exist in different locations across the world,
they take advantage of Google's global fiber network. Those VMs appear as though they are sitting in the
same rack when it comes to a network configuration
VMs C and D are not in the same network. Therefore by default these VM's must communicate using their
external IP addresses even though they are in the same region. The traffic between VMs C and D is not
actually touching the public Internet but is going through the Google's Edge Routers. This has different
billing and security ramifications
This following illustration shows the global nature of VPCs:
Fig.7
Because VM instances within a VPC network can communicate privately on a GLOBAL
scale, a single VPN can securely connect a users on-prem network to a GCP network
Even though the two VM instances are in separate Regions, they leverage Google's private network to
communicate between each other and to the on-prem network through a VPN gateway. This reduces cost and
network management complexity
This following illustration shows that Subnets cross Zones:
Fig.8
Subnets operate on a REGIONAL scale. Because a Region contains several
Zones, Subnets can cross zones
A Subnet is simply an IP address range and one can use IP addresses within that range
Given the Subnet 10.0.0.0, the first address (10.0.0.0) and second address (10.0.0.1) in the range
are reserved for the network and the gateway respectively
Similarly, the second-to-last address (10.0.0.254) and last address (10.0.0.255) in the range are
reserved as broadcast addresses
In short, every subnet has 4 reserved IP addresses in its primary IP range
Even though the two VMs (in Fig.8) are in different Zones, they still communicate with each other
using the same Subnet IP address. This means that a single Firewall Rule can be applied to both VM's
even though they are in different Zones
This following illustration shows how Subnets can be expanded without downtime:
Fig.9
VPC's allow a user to increase the IP address space of a Subnet without any workload shutdown
or downtime. There are few restrictions though - the new Subnet must not
overlap with any other Subnet in the same VPC and the new Subnet must
stay inside the RFC 1918 address spaces
The new network range must be larger than the original which means the prefix length value must
be a smaller number
One cannot undo a subnet expansion
Auto mode subnets start with a /20 IP range. They can be expanded to a /16 IP range but no larger
Assume a user creates a custom Subnet with a /29 mask. A /29 mask provides the user with 8 IP
addresses. But of those, 4 are reserved by GCP, which leaves the user with another 4 for their VM
instances
This following illustration shows the two types of IP addresses a VM instance can have:
Fig.10
Each VM can have two IP addresses assigned - an Internal IP address
and an optional External IP address
The Internal IP address is going to be assigned via DHCP internally
When a VM is created in GCP, its symbolic name is registered with an internal DNS service that
translates the name to the Internal IP address
DNS is scoped to the Network so it can translate web URLs and VM names of hosts in the same
Network. It cannot translate host names from VMs in a different Network
The External IP address is optional. An External IP address can be assigned from a pool making
it Ephemeral. Or it can be assigned a reserved External IP address making
it Static
When an instance is stopped, any Ephemeral External IP addresses assigned to the instance are
released back into the general Compute Engine pool and become available for use by other Projects.
When a stopped instance is started again, a new Ephemeral External IP address is assigned to the
instance from the pool
Reserved Static External IP addresses are assigned to a project indefinitely until they are
explicitly released
NOTE: one is billed for reserving External IP addresses even
when they are not attached to a running VM
The External IP address is mapped to the VM's Internal address transparently by VPC
Running the ifconfig command within a VM returns the Internal IP
address
This following illustration shows the Internal address DNS resolution:
Fig.11
Each VM instance has a hostname (same as the instance name) which resolves to the Internal IP
address
The Fully Qualified Domain Name (FQDN) of a VM instance has the format:
<instance-name>.<zone>.c.<project-id>
.internal
Deleting and recreating VM instances will change the Internal IP address
Each VM instance has a Metadata Server that also acts as a DNS
resolver for that instance. The Metadata Server handles all DNS queries for local network resources
and routes all the other queries to Google's public DNS servers for public name resolution
This following illustration shows the External address DNS resolution:
Fig.12
The VPC network stores a Lookup Table that matches External IP
addresses with the Internal IP addresses of the relevant instances
Instances with External IP addresses can allow connections from hosts outside of the Project.
Users can do so directly using the External IP address
Public DNS records pointing to instances are not published automatically
This following illustration shows Google's Cloud DNS:
Fig.13
Cloud DNS is a scalable, reliable and managed authoritative Domain Name
System (DNS) running on the same infrastructure as Google
Cloud DNS translate requests for domain names like google.com into IP
addresses
GCP offers a 100% uptime Service Level Agreement (SLA) for domains configured in Cloud DNS
This following illustration shows assigning an alias IP address to a VM:
Fig.14
Alias IP ranges allow a user to assign a range of Internal IP addresses as an alias to VMs network
interface
This is useful if we have multiple services running on a VM and want to assign a different IP address
to each service
In essence one can configure multiple IP addresses representing containers or applications hosted in
VMs without having to define a separate network interface
The Alias IP range must be assigned from the local subnets primary or secondary CIDR ranges
By default, every Network has routes that let instances within the Network send traffic directly to
each other even across Subnets
Every Network has a default route that directs packets to destinations that are outside the Network
The Default Network has preconfigured Firewall Rules that allow all instances within a Network to talk
with each other
Routes match packets by destination IP addresses
No traffic will flow without matching a Firewall Rule
This following illustration shows route mapping to destination networks:
Fig.15
A Route is created when a Network is created, enabling traffic delivery from anywhere. Also, a Route
is created when a Subnet is created. This is what enables VM's on the same network to communicate with
each other
This following illustration shows Routing Table in a VM instance:
Fig.16
Each Route in the routing collection may apply to one or more instances
A Route applies to an instance if the network and instance Tags
match
If the network matches and there are no instance Tags specified, the Route applies to all instances
in that Network
Google Compute Engine uses the routes collection to create individual read-only Routing
Table for each instance
Each VPC Network has a massively scalable Virtual Router at its core
Every VM instance in the Network is directly connected to the Virtual Router, and all packets leaving
the VM instance are first handled at this layer before they are forwarded to the next hop
The Virtual Router selects the next hop for a packet by consulting the Routing Table for that
instance
Every VPC network functions as a Distributed Firewall
Although Firewall Rules are applied to the Network as a whole, connections are allowed or denied at
the instance level
Firewall Rules in GCP are STATEFUL. This means that if a connection is
allowed between a source and a target, all subsequent traffic in either direction will be allowed. In other
words, firewall rules allow bidirectional communication once a session is established
If for some reason all Firewall Rules in a Network are deleted, there is still an implied
deny all ingress (incoming) rule and an implied allow all
egress (outgoing) rule for the Network
This following illustration shows important parameters for Firewall Rules:
Fig.17
A Firewall Rule is composed of the following parameters - the Direction of
the rule, the Source or the Destination,
the Protocol and the Port, the
Action, and the Priority
Inbound connections are matched against ingress rules only. Similarly, outbound connections are
matched against egress rules only
The Action of the rule which is to allow or deny packets that match the direction, protocol, port
and source or destination of the rule
The Priority of the rule governs the order in which rules are evaluated
By default, all Rules are assigned to all instances. One can assign certain Rules to certain instances
only
For egress Firewall Rules, destinations to which a Rule applies may be specified using IP CIDR
ranges
This following illustration shows the pricing for Network traffic:
Fig.18
Traffic coming into GCP Network (ingress) is not charged unless there is a resource such as a
Load Balancer that is processing ingress traffic
Responses to request are counted as egress and are charged
Egress traffic in the same Zone is not
charged as long as that egress is through the Internal IP address of an
instance
Egress traffic to Google products like YouTube, Maps, Drive within the same
Region is not charged for
There is a charge for egress between Zones in the same Region, egress within the Zone if the traffic
is through the External IP address of the instance, and egress between Regions
This following illustration shows a sample Project with 3 Networks:
Fig.19
One can ping the External IP address of all VM instances, even though they are either in a different
Zone or different Network. This confirms that public access to those instances is only controlled by the
ICMP Firewall Rules that are established for the sample Project
One can ping the Internal IP address of mynet-eu-vm because it is on the
same VPC Network as the source of the ping (mynet-us-vm), even though both VM
instances are in separate Zones and Regions
One cannot ping the Internal IP address of managementnet-us-vm and
privatenet-us-vm because they are in separate VPC Networks from the source of
the ping (mynet-us-vm), even though they are all in the same Zone
(us-central1-c)
VPC Networks are by default, isolated private networking domains. Therefore, no internal IP address
communication is allowed between Networks, unless one sets up mechanisms such as VPC peering, or a VPN
connection
This following illustration shows a pattern for increased availability with multiple Zones:
Fig.20
If an application needs increased availability, one can place two VMs into multiple Zones, but within
the same Subnet. Using a single Subnet allows one to create Firewall Rules against the single Subnet thus
reducing security complexity
A Regional managed Instance Group contains instances from multiple Zones across the same Region, which
provides increased availability
This following illustration shows a pattern for increased failure independence:
Fig.21
Putting resources in different Regions provides a higher degree of failure independence. This allows
one to design robust systems with resources spread across different failure domains
When using a Global Load Balancer like the HTTP Load
Balancer, one can route traffic to the Region that is closest to clients. This can result in better
latency for clients and lower network traffic costs for a Project
This following illustration shows a pattern for Bastion host:
Fig.22
A Bastion Host provides an external facing point of entry into a Network
containing private Network instances. This host can provide a single-point of fortification or audit and
can be started and stopped to enable or disable inbound SSH communication from the Internet
When instances do not have External IP addresses, they can only be reached by other instances on the
same Network or via a managed VPN gateway. In above example (Fig.22), the Bastion VM (Instance 2) serves
as a management and maintenance interface for the VM without External IP address (Instance 1)
