Difference Between Shared VPC and VPC Peering

Networking your Virtual Private Clouds (VPCs) effectively is essential when managing resources in cloud settings, particularly inside Google Cloud Platform (GCP). There are two main ways to join VPCs: VPC Peering and Shared VPC. Both link several VPCs together, but they serve various use cases and have unique benefits.

Key Terminologies

Virtual Private Cloud (VPC)

A VPC is a virtual network within a cloud provider's infrastructure that is logically isolated from other virtual networks. It provides users with the ability to launch resources, such as virtual machines, databases, and other services, in a secure and scalable environment. Users can define their own IP address ranges, create subnets, configure route tables, and set up network gateways.

Shared VPC

A Shared VPC allows multiple projects to connect to and use a common VPC network managed by a central host project. This configuration enables centralized control over network policies and security, making it easier to manage and enforce consistent network configurations across multiple projects within an organization.

VPC Peering

VPC Peering is a networking connection between two VPCs that allows them to communicate as if they are within the same network. This connection is established directly between the VPCs, enabling private communication without the need for a central managing entity or public IP addresses.

Shared VPC

Definition and Use Cases

Shared VPC can be described as a Google Cloud tool which enables an organization to associate certain projects to a single VPC network and be able to share subnets, routes, firewalls, and other components of networking. It affords an approach that allows projects to be compartmentalized at the resource access level but is still able to allow them access to the shared networking resources.

Shared VPC is ideal for organizations that require centralized control over network policies and efficient management of network resources across multiple projects. It is particularly useful for:

Centralized control over network policies and configurations.
Efficient use of network resources across multiple projects.
Simplified security management with consistent firewall rules.

Steps to Set Up and Configure Shared VPC:

Log in to the GCP console.
Select the host project.
Navigate to the VPC network and click on Shared VPC.
Click on Setup Shared VPC in the Shared VPC Setup wizard.

Enable Host Project:

In the Shared VPC Setup wizard, enable the host project by following the prompts.
After enabling, click "Continue" to proceed to the next step.

Select Subnets:

Choose the subnets you want to share within the host project.
You can share all subnets or select individual subnets according to your requirements.
For example, you can choose to share "subnet1" and "subnet2".
After making your selections, click "Continue to Next" to move forward.

Attach Service Projects:

In the "Give Permission" section, you need to attach service projects to the Shared VPC.
Attach at least one service project and grant it the compute network user role on the selected subnets.
For instance, you might attach "service-project1" and "service-project2".
After attaching the service projects, click "Save" to apply the changes.

Enable Compute Engine API:

If the attached service projects are not visible, the Compute Engine API might not be enabled for those projects.
Navigate to each service project and manually enable the Compute Engine API.
Return to the host project, go to the "ATTACHED PROJECTS" tab, and attach the projects again to ensure they are properly linked.

Test Shared VPC:

To verify the Shared VPC setup, spin up a new VM in one of the service projects.
During the VM deployment, select the shared network instead of the regular networks.
Ensure that the shared VPC is available for the service project, confirming that the setup is successful.

Create a firewall rule in the host project to allow SSH:

$ gcloud compute firewall-rules create allow-ssh \
      --network=my-network1 \
      --allow=tcp:22 \
      --source-ranges=0.0.0.0/0 \
      --direction=INGRESS

Update Subnet Permissions:

By default, every shared subnet is accessible to all attached service projects.
To restrict access, update user permissions on each subnet.
Grant permissions only to specific accounts that need access to the subnets.

Create and Test New User:

Create a new user, for example, "demo-user@lyfedge.com", in your Google Workspace.
Grant this user the Compute Admin role for the service project.
Log in to the GCP console with the new user account.
Select the organization and open the service project to verify if the user can access the shared subnetworks.

Log in with the new user and verify access to the shared subnetworks.

Grant Subnet Access:

If the new user cannot access the subnetworks, return to the host project with an admin account.
Go to the Shared VPC section, select the specific subnet (e.g., "subnet1"), and click "ADD PRINCIPAL".
Add the new user (e.g., "demo-user@lyfedge.com") to grant access to the subnet.

Retest with New User:

Log in again with the new user account to ensure that they can now access the subnetworks.
Verify that the shared networks are visible and accessible to the user.

Attach More Service Projects:

To add additional service projects to the Shared VPC, create new projects as needed.
From the host project, navigate to the Shared VPC section and attach the new projects.
Follow the same steps to grant necessary permissions and ensure the projects are correctly configured.

Example Scenario

An organization with separate projects for development, testing, and production environments can use a shared VPC to maintain a unified network infrastructure. The development project can access certain subnets of the shared VPC, while the testing and production projects can access others, with centrally managed security rules.

VPC Peering

Definition and Use Cases

VPC peering is a functionality that enables two VPCs whether in the same or in different AWS accounts though in the same region. The VPCs are still fully logically separated but are allowed to communicate by means of private IP addresses. VPC peering does not require the use of a gateway or encryption or a tunnel to allow traffic to pass between differently numbered VPCs – instead, new routes are added to the route tables of the peered VPCs so that traffic can flow between them as if they were on the same VPC. They set up certain or all rules and pathways for transiting traffic between the VPCs through the peering connection. It is on the basis of a request/accept workflow, and once the connection is set, there is the ability to exchange information in both directions. Many VPCs peers may join in creating a star or mesh structure. Inter-communication remains localized within AWS infrastructure giving fastest connection with minimal delay. Extra layers of filtering can be done at the instance level across the peers using security groups.

How VPC Peering Works

VPC peer in GCP is a mechanism that enables two VPC networks to be connected, and enables the workloads of the VPC networks to communicate with each other over internal IP address. This enables them to efficiently transfer traffic between the two VPCs without having to use the public Internet.

VPC peering works between two VPC’s and not subnetworks or subnets as most of us Google practitioners know. After two VPC networks are connected by the peering connection, resources in any of the subnets of those networks can communicate.
Peering connections are not fully transitive. All VPC networks that want to peer with another VPC network C need to peer individually with C.
VPC peering can be accessed without any additional cost when compared to other services offered by Amazon web services. Traffic that originates from the peered VPC is deemed as internal traffic and comes at usual charges.
It can be inter-VPC if both VPCs are in the same project, inter-project if the VPCs are in different projects but in the same organization, or inter-organization if the VPCs are in different organizations.
Peered VPC networks routes are not propagated automatically between them. In this case, routing needs to be set up in order to send traffic to the remote network.
Unlike VPLS, VPC peering has bandwidth limitations. By default on this limit is up to 3 Gbps. Some may be of normal capacity while others may be larger and this can be increased by request.
Therefore in conclusion, VPC peering is a mechanism that allows two VPCs to connect and transmit traffics in a native manner across projects and organizations but within the boundary of Google Cloud. It affords greater flexibility in constructing intricate networks with interconnectivity between the nodes.

Sample Situation

An organization has to share data between two departments, each having its own VPC. VolP These VPCs can communicate directly through peering without disclosing any information online.