Virtual Private Cloud (VPC)
VPC Networks
Global resources (not associated with any zone) and include subnets, routes and firewall rules
VPC Networks do not have any IP addresses associated with them (unlike AWS)
Resources within a VPC can communicate with one another using the internal IP addresses
By default, resources in two different VPCs cannot communicate with each other. The communication can be facilitated by VPC Network Peering
VPC networks support IPv4 unicast traffic only. They do not support broadcast, multicast or IPv6 traffic within the network
VPC Subnets
Subnets represent VPC Network partitions using one or more useful IP address ranges
Subnets are regional resources. Each subnet comprises of a range of IP addresses. These can be primary IP ranges or secondary IP ranges (alias)
A network must have at least one subnet before it can be used
More than one subnet per region can be created
VPC Network supports following modes of subnet creation:
Auto Mode VPC networks
Create subnets in each region automatically
Adds new subnets automatically, if a new region becomes available
Can be switched to custom mode VPC networks
Custom Mode VPC Networks
Start with no subnets, giving full control over subnet creation
Cannot be switched to auto mode VPC Networks
These are better suited for the production environments
Changing IP address range of a Subnet
It is possible to expand the IP address range of a subnet by modifying the subnet mask. This is usually required in the production environments when the existing ranges are insufficient to handle IP address allocations for the new devices.
VPC Routes
Provide path for packets egressing out of the instances (sources).
Comprises of a destination prefix (the packet's ultimate destination) and next hop (where should the packet go first, to reach its final destination)
Routes are defined at the VPC network level but implemented at each VM instance level
Route Learning Mechanism: Whenever changes are made to the VPC routes (add / modify / delete), GCP notifies the changes to the VM instance's internal controller that keeps track of all the applicable routes configured at the VPC level. The controller ensures that the outgoing packet destined to a particular destination is routed to the configured next hop.
Route Types
system-generated routes (applied at the VPC level to all the instances)
default - send traffic from instances to the internet. These routes can be removed or replaced
subnet routes - route traffic among its subnets and updated automatically by Google cloud (in response to subnet additions, deletions etc.)
custom routes
Static routes created manually or dynamic routes maintained automatically by the Cloud Routers
Can be applied to all the instances using network tag
VPC Private Access Options
VPC Private Access allows VM instances with internal IP addresses (inside a VPC) to communicate with APIs and services
Private Google Access
Allows VMs to connect to the external IP addresses used by Google APIs and services
This is to avoid assigning public IPs (i.e. direct external internet access) to the Google Cloud (VPC) resources just for accessing Google APIs
Private Google Access is configured on the subnet level (not VPC level) and is used by the VM's Network interface
Provides routing options as follows:
Use default route with the next-hop being default internet gateway and it provides a path to the default domains, private.googleapis.com and restricted.googleapis.com
Use custom static routes, each having a more specific destination, and each using the default internet gateway next hop
Private Services Access
Private connection between VPC network and Google owned network or 3rd party provider network
Enables resources in a VM network to communicate with Internet resources using private IP addresses (without providing direct internet access to the VPC resources)
Shared VPC
Allows an organization to have a centralized (shared) VPC in a single project and connect resources from multiple other projects to this centralized VPC
Shared VPC (sort of, hub) project designated as Host project
One or more projects connecting the Host project are designated as Service projects
Allows enforcement of decentralized administration. Service project admins manage their respective service projects and the Host project (Shared VPC Admin) admin (sort of, super admin) manages the Host project
A host project contains one or more Shared VPC networks and attaches one or more service projects to it
A service project attaches to the host project and leverages the services offered by Shared VPC, of the host project
Rules of Attachment
A project cannot be both host and service project --> This prevents daisy chaining projects in a tree-like hierarchy.
In case of multiple host projects, each service project can only attach to a single host project
A project that does not participate in Shared VPC is called standalone project
Shared VPC Networks can comprise of subnets either in auto or custom mode
Host and Service Projects are attached at the Project level
Comments
Post a Comment