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.
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.
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.
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
I am chasing some general guidance for setting up my network and VPN peering.
Basically, I want to setup a connection from my office to aws, but am wondering what the best practice is for multiple aws accounts?
Should I setup the vpn peer from the office to just one account subnet, and then peer to the other account from that subnet or,
should I setup individual vpn peers to both/all accounts from the office
I am just chasing what is the normal best practice for network design in this case.
It's now possible to link multiple VPCs and your VPN connection with a Transit Gateway.
so you can use your vpn to connect to the TGW then connect to any VPC-A or VPC-B.
https://aws.amazon.com/transit-gateway/
You can enable VPC Peering between accounts and their respective VPCs, but VPC Peering is not transitive, meaning that they will not forward packets. This means that if you use a VPN to connect to VPC-A and VPC-A is peering with VPC-B, your VPN traffic will NOT be forwarded to VPC-B thru VPC-A. So this eliminates VPC Peering as an option.
The best solution is to create a site-to-site VPN from your office to each account/VPC that you need connectivity with. I recommend that you look into a software solution such as OpenSwan or Windows Server Routing and Remote Access if you need company wide routing. AWS also lists a number of hardware routers that work very well. If just individuals need access then a good choice is OpenVPN (Desktop to AWS).
Keep in mind that there will be costs to enable site-to-site routing. You will either need AWS VGW or an EC2 instance running VPN software. This means a per hour cost 24 hours per day. VGW is $.05 per hour (for most regions). EC2 instance is around another $.05 per hour for a small instance. VGW is the better choice but then you are limited on what types of hardware / software that supports connections to VGW and its setup complexity. However, VGW allows you to use one VPN connection to route to multiple VPCs.
For more complex configurations / very high bandwidth, AWS and Cisco have partnered on the Cisco CSR. This is a high end solution with a high end cost. There is also Direct Connect for the best solution of all.
Your final choice will be determined by cost, software versus hardware solution, site-to-site or client-to-site, permanent always on routing or connect when required routing.