{"id":25544,"date":"2025-04-29T14:24:15","date_gmt":"2025-04-29T08:54:15","guid":{"rendered":"https:\/\/opstree.com\/blog\/?p=25544"},"modified":"2025-04-29T15:05:50","modified_gmt":"2025-04-29T09:35:50","slug":"gcp-shared-vpc","status":"publish","type":"post","link":"https:\/\/opstree.com\/blog\/2025\/04\/29\/gcp-shared-vpc\/","title":{"rendered":"GCP Shared-VPC"},"content":{"rendered":"

Shared VPC in GCP allows multiple projects to share a centralized VPC network. The host project <\/span>contains the VPC, while service projects create resources that use this shared network. This setup enables <\/span>secure, scalable, and centralized network management across projects.<\/span><\/p>\n

<\/p>\n

Why shared-VPC?<\/h3>\n

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.<\/p>\n

Now, instead of duplicating efforts, you follow a\u00a0consistent folder structure<\/b>. 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.
\n<\/span>
Similarly, in GCP, Shared VPC lets different projects (like team members) use a common VPC network <\/span>(like shared folders) managed in a central host project. Each service project can create its resources <\/span>while reusing the shared network setup, just like you reuse the language setup in your task.<\/span><\/p>\n

\"\"<\/p>\n

What is shared-VPC<\/h3>\n

In Google Cloud Platform (GCP), a Shared VPC allows multiple projects within the same organization to <\/span>share a common Virtual Private Cloud (VPC) network. This means instead of creating separate networks <\/span>in every project, you create one central network (in a host project) and let other <\/span>projects (service projects) <\/span>use it to deploy their resources, like virtual machines or Kubernetes clusters.<\/span><\/p>\n

This setup is great for larger teams or organizations where different teams work on separate projects but <\/span>still need to connect securely and consistently over the same network. It ensures centralized network <\/span>control, better security, and easier management.
\n<\/span>
For example, a Kubernetes cluster in a service project is using a VPC network that lives in a different host <\/span>project. This allows the teams to manage their applications while relying on a centrally managed and <\/span>secured network, just like multiple departments in a company using a shared office infrastructure.<\/span><\/p>\n

\"\"<\/p>\n

Shared-VPC vs VPC-Peering<\/span><\/h3>\n

\"\"<\/p>\n

Comparison Summary<\/h3>\n

\u25cf <\/span>Shared-VPC<\/span><\/strong> is ideal for large organizations that want to <\/span>centralize control over networking<\/span>, <\/span>security, and routing policies, while still allowing different teams to work on separate projects. All <\/span>communication stays within the shared network space, making it <\/span>easy to manage and secure<\/span>. <\/span>Importantly, IAM permissions are used to control who can use the shared VPC and to what <\/span>extent.
\n<\/span>
\u25cf<\/span>VPC Peering<\/span><\/strong> in GCP allows private connectivity between two VPC networks, enabling <\/span>resources in each network to communicate using internal IPs. Each VPC remains independently <\/span>managed, with its subnets, routes, and policies. The peering is <\/span>non-transitive<\/span>, meaning <\/span>traffic doesn\u2019t automatically pass through multiple peered networks. This is ideal for connecting <\/span>projects that need limited, private communication without sharing network infrastructure.<\/span><\/p>\n

Case Study: Shared VPC for GKE Clusters<\/h3>\n

Imagine a scenario where a company uses GKE to deploy microservices for its web application. They <\/span>have several development, testing, and production teams, each managing their own GKE clusters.
\n<\/span>
\u25cf<\/span> Before Shared VPC:<\/span><\/strong>
Each team might have its own VPC network, leading to duplicate resources, increased <\/span>management overhead, and potential networking conflicts.
\n<\/span>
\u25cf<\/span> With Shared VPC:<\/span><\/strong>
The organization can designate a host project and attach the GKE clusters to it, sharing the same <\/span>VPC network.<\/span><\/p>\n

Conclusion<\/h3>\n

This blog explored the concept of <\/span>GCP Shared VPC<\/span><\/strong>,<\/strong> highlighting how it empowers organizations to <\/span>centralize network management while allowing teams to independently manage their resources in <\/span>separate projects. Through simple analogies and real-world examples like GKE deployments, we <\/span>demonstrated the benefits of Shared VPC in reducing complexity, enhancing security, and promoting <\/span>efficient collaboration across teams.<\/span><\/p>\n

 <\/p>\n

CONTACT US<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

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.<\/p>\n","protected":false},"author":244582697,"featured_media":25570,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_coblocks_attr":"","_coblocks_dimensions":"","_coblocks_responsive_height":"","_coblocks_accordion_ie_support":"","jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false},"version":2}},"categories":[28070474],"tags":[1907028,768739524,768739523],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/opstree.com\/blog\/wp-content\/uploads\/2025\/04\/9e9835c3-c12c-41bc-bd79-8109b3a73979.jpg","jetpack_likes_enabled":true,"jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/pfDBOm-6E0","jetpack-related-posts":[],"_links":{"self":[{"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/posts\/25544"}],"collection":[{"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/users\/244582697"}],"replies":[{"embeddable":true,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/comments?post=25544"}],"version-history":[{"count":6,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/posts\/25544\/revisions"}],"predecessor-version":[{"id":25590,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/posts\/25544\/revisions\/25590"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/media\/25570"}],"wp:attachment":[{"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/media?parent=25544"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/categories?post=25544"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/tags?post=25544"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}