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
Related
I have three separate GCP accounts. One account for productA, one account for productB and one account for devops monitoring. Each account has currently 1 project (more to be added in the future) which has multiple VMs. I want to monitor the VMs (for productA/project and productB/project) from the devops GCP account so I can consolidate the monitoring. The monitoring products are Promethesus, Grafana and Graylog (not GCP).
I am not using organisations at the moment (don't use gsuite or cloud identity)
Do I need VPC networking peering or shared VPC?
Any advice or recommendations on how to do this would be much appreciated.
Shared VPC allows an organization to connect resources from multiple projects to a common Virtual Private Cloud (VPC) network. If your resources are already in different projects, but using the same VPC, the shared VPC concept is already in place.
However, in your case it seems like your resources are using different VPC’s specifically to their own project. Here the concept for VPC peering can be used regardless of whether they belong to the same project or the same organization. It is possible to set up VPC Network Peering between two Shared VPC networks. Here is the Example on VPC Network Peering setup.
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.
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.
Why can't we implement multiple network interface on a single VPC (Which has multiple subnets) in GCP? Where as it is possible in AWS and Azure.
I came across with a problem where I had to implement multiple network interface in GCP. But in my case, all the subnets was present in the single VPC network, I read GCP documentation and got to know that, in GCP it is not possible to have multiple network interface in a single VPC network, in order to implement multiple network interface, all the subnets must be in a different VPC network, where as its completely opposite in AWS and Azure.
In AWS - all network interface must be available in the same VPC, and cannot at network interface from other VPC network.
In Azure vNet - all network interface must be available in the same VPC, and cannot at network interface from other vNet.
Of course, VPC in google cloud is little different from AWS, as an example, Azure vNet and AWS VPC's are regional in nature where as in GCP it is global in nature. And there are several other difference as well.
Was just curious to know about this limitation in GCP which I got.
Your assumption is wrong. You cannot attach more than one network interface to the same subnet, but you can to different subnets in the same VPC.
Google Cloud & AWS have different implementation for a VPC. In GCP VPC are associated with projects. What's confusing me is that in a GCP project you can have two different VPC but with same subnet CIDR. If anyone has any resource which can clear my doubts please
In GCP, 2 VPC networks in the same project must have different names, so they are distinguishable and completely independent/isolated. VMs in one VPC network have to go through external IP addresses to talk to VMs in other VPC network. Or you can connect them through VPC Peering, so that they can talk to each other through internal IPs. See:
GCP - VPC Network Overview.
GCP - VPC Network Peering
A feature you can use in this case is to create a Peering in the VPC, this function will 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.
VPC Network Peering enables you to connect VPC networks so that workloads in different VPC networks can communicate internally. Traffic stays within Google's network and doesn't traverse the public internet.
VPC Network Peering gives you several advantages over using external IP addresses or VPNs to connect networks, including: Network Latency,Network Security and Network Cost.
For information about Peering and VPC,see:
VPC: https://cloud.google.com/vpc/docs/vpc
Peering: https://cloud.google.com/vpc/docs/vpc-peering