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.
Related
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.
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.
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.
I have 2 Google Cloud accounts, account_1 and account_2. On each of those accounts I created a project and I bootstrapped 2 virtual machines.
I want to know if it's possible to place those 4 machines in the same network space, to be able to communicate.
Thanks!
Yes, this is possible using VPC network peering. The shared VPC is different because it's between an organization projects, as you have you VMs in different accounts what you have to do is VPC network peering, check this article. After configuring on both VPCs and set the proper firewall rules you should be able to reach your 4 VMs using the internal IP, although they will not be in the same subnet but they will be able to communicate between them.
Yes, it is possible. Take a look at the Shared VPC Overview documentation.
However, not all resources will be shared, you can check which ones are supported here.
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