Shared VPC in GCP allows multiple projects to share a centralized VPC network. The host project contains the VPC, while service projects create resources that use this shared network. This setup enables secure, scalable, and centralized network management across projects.
Why shared-VPC?
Imagine you’re working on a project with multiple team members, each assigned different tasks. Your task is to create documentation for setting up an API, which includes sub-tasks like salary, employee, etc. Other teammates are documenting environment setups for languages like Python, Java, and Golang.
Now, instead of duplicating efforts, you follow a consistent folder structure. This way, when you need Python-related setup for your API, you can directly refer to the existing Python documentation maintained by your teammate. It avoids conflicts, promotes reusability, and makes collaboration easier, just like how Shared VPC lets multiple projects use a common network setup efficiently.
Similarly, in GCP, Shared VPC lets different projects (like team members) use a common VPC network (like shared folders) managed in a central host project. Each service project can create its resources while reusing the shared network setup, just like you reuse the language setup in your task.
What is shared-VPC
In Google Cloud Platform (GCP), a Shared VPC allows multiple projects within the same organization to share a common Virtual Private Cloud (VPC) network. This means instead of creating separate networks in every project, you create one central network (in a host project) and let other projects (service projects) use it to deploy their resources, like virtual machines or Kubernetes clusters.
This setup is great for larger teams or organizations where different teams work on separate projects but still need to connect securely and consistently over the same network. It ensures centralized network control, better security, and easier management.
For example, a Kubernetes cluster in a service project is using a VPC network that lives in a different host project. This allows the teams to manage their applications while relying on a centrally managed and secured network, just like multiple departments in a company using a shared office infrastructure.
Shared-VPC vs VPC-Peering
Comparison Summary
● Shared-VPC is ideal for large organizations that want to centralize control over networking, security, and routing policies, while still allowing different teams to work on separate projects. All communication stays within the shared network space, making it easy to manage and secure. Importantly, IAM permissions are used to control who can use the shared VPC and to what extent.
●VPC Peering in GCP allows private connectivity between two VPC networks, enabling resources in each network to communicate using internal IPs. Each VPC remains independently managed, with its subnets, routes, and policies. The peering is non-transitive, meaning traffic doesn’t automatically pass through multiple peered networks. This is ideal for connecting projects that need limited, private communication without sharing network infrastructure.
Case Study: Shared VPC for GKE Clusters
Imagine a scenario where a company uses GKE to deploy microservices for its web application. They have several development, testing, and production teams, each managing their own GKE clusters.
● Before Shared VPC:
Each team might have its own VPC network, leading to duplicate resources, increased management overhead, and potential networking conflicts.
● With Shared VPC:
The organization can designate a host project and attach the GKE clusters to it, sharing the same VPC network.
Conclusion
This blog explored the concept of GCP Shared VPC, highlighting how it empowers organizations to centralize network management while allowing teams to independently manage their resources in separate projects. Through simple analogies and real-world examples like GKE deployments, we demonstrated the benefits of Shared VPC in reducing complexity, enhancing security, and promoting efficient collaboration across teams.