On Google cloud, I have setup new three projects - dev, research and prod. So, then created an Shared VPC Host and three Service Projects as listed above. Also intend to have separate VPCs for each of these service projects (to add more security layer), hence also intend to use now VPC Peering. But confused here can we configure both Shared VPCs and VPC Peering on same set of Projects?. If so then i do not find any links on this and also is this an right thing to do?
Peering and Shared have their own usage. With peering, you are limited to 25 per project and the transitivity isn't possible.
For example, with peering, if you set up a peering between dev and research and between research and prod; dev can't reach the prod (transitivity is forbidden), you have to set up a peering between dev and prod for this. The peering can be interesting when you want to share a VPN or Interconnect endpoint. You perform a peering between the interconnect project and these that want to reuse this connexion.
With share VPC, you don't have the transitivity limitation, all the VM can be in the same VPC, even if they are in different projects.
However, with this config, you break the project strong isolation, your dev project can access to the prod without limitation!
Thereby I recommend you to set up VM network with at least "2 legs": 1 in the shared VPC, the other in a project dedicated VPC. And then to set up the correct firewalls rules on your VPC network for limiting interactions in the shared VPC, but by keeping an unrestricted limitation at project level with the leg in the VPC project.
Peering:
Peering allows internal IP address connectivity across two Virtual Private Cloud (VPC) networks regardless of whether they belong to the same project or the same organization. you are limited to 25 per project and the transitivity isn't possible.
VPC sharing:
Shared VPC allows an organization to connect resources from multiple projects to a common Virtual Private Cloud (VPC) network, so that they can communicate with each other securely and efficiently using internal IPs from that network. When you use Shared VPC, you designate a project as a host project and attach one or more other service projects to it. The VPC networks in the host project are called Shared VPC networks. Eligible resources from service projects can use subnets in the Shared VPC network.
Related
Instead of creating a VPN to every GCP project in our organization, can I somehow create a "super" VPN that can access all the projects? I was looking at shared VPC, but I can't figure out from the docs whether shared VPC will solve the problem. I'm not the best at networking and maybe I'm overlooking something. Suggestions welcome.
You have 2 solutions to solve this
Create a project with the VPN and then create peering with other projects. The problem with this is that you are limited to 25 peering per VPC. In addition, VPC peering has another limitation: transitivity is forbidden. If you have a peering between A and B and between B and C, A can'y reach C, the transitivity isn't permitted and that can cause some issues/limitation later in your design.
Use Shared VPC. You have a host project with a VPC with your VPN, and then service project that use either their own VPC (for standalone application) or the shared VPC. You have detail here. However in this solution, all the service project have access to the same VPC, and thus all the VM of the services projects can access to the VPC ressources (others VM, VPN, ...). The firewall rules will be very important; and a good way to solve this is to use firewall rules based on service account.
I need to set up a connection between VPCs. My plan was VPC peering but customer asks for Private Link as they heard it is the secure way. But I am mostly concerned with performance overhead with the private link. What I understood (maybe wrong); in the Private Link architecture there is an extra NLB. Does not this introduce a latency because of extra network hop?
VPC peering and Private Link serve two different purposes.
VPC peering enables you to connect two VPC in a same way you would connect to local networks together, and remote networks using VPN. VPC peering allows network traffic from one VPC to the second VPC. For example, you can SSH from an instance in VPC A into an instance in VPC B.
Private Link is used to expose individual services of yours in VPC A to VPC B. But this does not allow for free flow of network traffic from VPC A to VPC B. For example, let's say you've developed very cool application for image segmentation. The application and all its databases and other resources that it requires are in VPC A. Now a friend comes and he/she would like to use your application. But the friend is in VPC B. Since your application is private, not exposed to the internet, a way for your friend to use the app would be to expose it through Private Link. For this you create NLB in-front of your application, and your friend will get network interface in his VPC B through which he can access your private application in VPC A.
Based on this and your question, there is no clear answer as the two options are used for different purposes. I would suggest to clarify exactly what are your or your customer requirements.
But generally, both will be equally fast. AWS docs write about VPC peering the following:
AWS uses the existing infrastructure of a VPC to create a VPC peering connection; it is neither a gateway nor a VPN connection, and does not rely on a separate piece of physical hardware. There is no single point of failure for communication or a bandwidth bottleneck.
Other examples from AWS docs is here:
Example: Services Using AWS PrivateLink and VPC Peering
Edit: Based on #Michael comment.
I have an organization with multiple projects. I must have a service that all compute, serverless, gke assets can connect to from all projects through https. Preferably this would not traverse the internet and would stay inside our organization.
Is this only possible with a shared vpc?
There are 3 platform-native ways to connect VPCs:
Shared VPC
VPC Peering
Cloud VPN
Shared VPC is typically preferable for organizations that have central control over their networking. If you can't use Shared VPC, then your best bet for shared services is to settle for VPN tunnels.
You can use VPN tunnels between VPCs in different projects. Packets will hit the internet, but they will be secure.
Q1: Is a hub & spoke model with vpc peering better compared to using a shared vpc. See below tenancy design in AWS, we are trying to bring a similar structure.
Q2: Is there any native service/virtual appliance(Firewall) or feature available to route traffic between spokes without spoke to spoke peering?
Q3: Cross account access – Is it possible to have cross-account access
Q4: Do we use Subnet to create zones in GCP, refer diagram above
Q5: Is there randomization of the zones in GCP as in AWS (Zone a in one account would be Zone b in another)
Q2: Is there any native service/virtual appliance(Firewall) or feature available to route traffic between spokes without spoke to spoke peering?
No, the VPC peering is not transitive in nature. This means that VPC A peered with VPC B, VPC A peered with VPC C would mean that VPC B cannot see or send ICMP traffic to VPC C.
Q3: Cross account access – Is it possible to have cross-account access
Yes, as long as there is a peering is established between all communicating accounts
Q4: Do we use Subnet to create zones in GCP, refer diagram above
Availability zones in AWS and Zones in GCP are comparable. Subnet's are further slicing down the VPC to create dedicated areas for inbound/outbound traffic management and resources placements
Q5: Is there randomization of the zones in GCP as in AWS (Zone a in one account would be Zone b in another)
Yes the zones are randomized in GCP and do not represent fixed or known locations all the times.
Q1: Is a hub & spoke model with vpc peering better compared to using a shared vpc. See below tenancy design in AWS, we are trying to bring a similar structure.
Regarding Q1, the merits of the solution depend on the features accounted for the suitability of the solution, that would be different for each case.
There are two approaches for this hub-and-spoke architecture: shared VPC and peered VPC.
Shared VPC [1] allows one organization to connect resources from multiple projects to a common VPC network, so that they can communicate with each other securely and efficiently using internal IPs from that network. There will be:
A host project
One or more other service projects attached to it
VPC Network Peering [2] allows private connectivity across two VPC networks which may belong to one or multiple projects or organizations.
[1] https://cloud.google.com/vpc/docs/shared-vpc
[2] https://cloud.google.com/vpc/docs/vpc-peering
I know it's old but needs a correction:
Q2 - yes, you can route between spokes via hub VPC if you have a routing VM in hub and a proper custom route via that VM. Hub needs to export custom routes and spokes need to import. Pretty standard design for threat inspection between VPCs.
In google cloud I want to understand relation between project and VPC. Can vpc span multiple projects? or Can we say vpc is always in one project?
Per definition a VPC pertains only to a certain project, but you can share a VPC creating a shared VPC. Shared VPC allows an organization to connect resources from multiple projects to a common VPC network, so that they can communicate with each other securely and efficiently using internal IPs from that network. If you go here you can find some examples of shared VPCs.
Projects can contain multiple VPC networks. Unless you create an organizational policy that prohibits it, new projects start with a default network (an auto mode VPC network) that has one subnetwork (subnet) in each region.
You can also see more information about shared VPC: Shared VPC allows an organization to connect resources from multiple projects to a common Virtual Private Cloud (VPC) network, so that they can communicate with each other securely and efficiently using internal IPs from that network.
More information: https://cloud.google.com/vpc/docs/shared-vpc#use_cases
We also have VPC Peering: VPC networks can be connected to other VPC networks in different projects or organizations by using VPC Network Peering.
More information: https://cloud.google.com/vpc/docs/vpc-peering