Professional Google Cloud Network Engineer: Designing, Planning, and Prototyping a GCP Network, Part 2: PrepAway Certification (2023)

13. 1.2 Design of a virtual private cloud (VPC) - other concepts

VPC. VPC shared other concepts. So you may need to propose different departments or applications or different entities on different projects for their budget or access permissions or whatever, right, right, that's where you'll use Shared VPC. So the concept of a Shared VPC is that you have the host project that hosts your VPC, which is a network, and that network is shared by multiple projects, and those multiple projects are called a service project. So everything is controlled by Shared VPC in terms of networking and sharing. This particular VPC has a security administrator, who is an organization-wide network administrator, as you might guess, and you don't need that specific administrator or network administrator for individual projects.

And this is where the concept of Shared VPC comes into play. Individual project teams, they don't have their own network, they can have their own network if they do. You manage some internal steps there, but you can use the Shared VPC network for your VM instances or cloud resources. Some of the terminology around Shared VPC Shared VPC Host Project This host project actually hosts Shared VPC and has a Shared VPC service project for network security administrators and these are the service projects that these networks use Shared VPC. And typically when you look at this particular architecture, all of these features within the service project are billed to the service projects and not the host project. Therefore, billing is still done through the service project. It teaches that they use the backbone, the backbone of the Shared VPC network.

These projects are stand-alone projects, they can be under one or more organizations. Therefore, the Shared VPC network is typically the network that forms the backbone of all IAM service designs, rules, and policies. And here you can already imagine that it is different, right? So we said you can have a specific network administrator or security administrator that spans multiple projects and one administrator can manage network control for all the service projects that you have in an organization and in an organization with multiple projects, and this It is the concept of organization. Nothing new here. You can have an organization administrator control permissions for network administrators to access the Shared VPC, and you can have a Shared VPC administrator as the network administrator.

So the service project can also have a management state, but ultimately the network management network is controlled by the Shared VPC and not by the service project administrator. You can still go ahead and get the permission associated with the service project admin as a network, but he can only view the network and not change it. So he has network administrator rights as a computer network administrator and security rights as a computer security administrator and that was like a Shared VPC concept. If you go to the console here, you can go ahead and create the Shared VPC and it will tell you that Shared VPC is only available to projects within an organization. So my project is not under an organization. If you look at me clicking on that particular project, oh my gosh, let me see. Click here to open the details. If you're not looking for an organization, if there is one, I have an organization here defined by G Suite, I can just create a Shared VPC that shares the VPC between projects. VPC Peering VPC Peering is another concept where you can connect multiple VPCs together, right? And here it may be necessary for different networks, managed individually by different projects or within the project.

And you want to connect them so that the feature can communicate with each other. And this is where you use VPC peering. It can be used to connect one to many VPCs subject to a quota based on the total number of VMs in the peer VPC. And this is really important because it really comes down to the quota of what you can do in a given VPC. And that's true if you're peering two different VPCs, it's non-transitive in nature. That is, if A is peered with B and B is peered with C, it cannot expect A's resources to be able to communicate directly with C. Therefore, it is inherently non-transitive. Security policies remain independent and can limit the ability of two VPCs to communicate. And these security policies are independent, right? And this is not the same as VPC sharing. With VPC peering, you have different admins or network admins or security admins that are independent of each other. For example, if you have a VPC managed by a specific group of people and another VPC managed by a different group of people.

The quota limit, as I said, there is a VPC quota, right? The VPC quota, such as the total number of 15,500 VMs you can create in the VPC share or VPC peering, is applied to the same quota. And that means if you're peering three different VPCs, the total number of VMs in those three VPCs combined shouldn't exceed 15,500. A network can have up to 50. A network of 25, a total of 25 directly connected networks. So you can add up to 25 networks. You can match it. So if I go back to the console, you can go here and do the VPC network peering. And I can go ahead and create something. So I have this specific project. I'm still with the same project. I am in the process of creating a GCP project peering. This will take a while. I'll take a break

So now it's on. VPC Network Peering is enabled. I'll go ahead and create it. I will continue So VPC interconnecting your network. I don't really have many networks here. Well, you should have two different networks here, right? client and default. VPC removal. Can I enable it for a node for this project? Or even if I have it in another project and I have access to it, I can select another project, but it's in the same project. Custom VPC, the network name is Custom VPC, the default value is selected. So I want to connect by default to a custom VPC. I'll go ahead and create this connection expecting a previous network.

So this is a throwaway creation, right? So I go ahead and create another connection from a custom VPC to another standard VPC P-Ring and now this will be joined and controlled by each individual VPC right? Since I have both networks within the project, I don't need to log in and out or have different permissions, but if anything, let's say one network is managed by one project team and another network is managed by another project team, each individual can disconnect and disconnect that particular network. VPC peering is already configured, default network resources can communicate with resources for custom VPCs as long as firewall rules are open. That's VPC peering in a nutshell. So what is the difference between VPC Peering and Shared VPC, and when do you want to use it? To the right? Therefore, use cases where you want to use VPC Peering instead of Shared VPC. If your networks are inside your project, Shared VPC is not possible. You can do VPC peering, we've just seen that. If you have multiple organizations, Shared VPC isn't possible. But you can do VPC peering with multiple organizations that you can use for network management, and that's a really important aspect from a networking and security standpoint, isn't it? For a Shared VPC, you have a network administrator designated as the host project that manages the entire Shared VPC backbone. But in the case of VPC peering, individual project teams manage their own VPCs and control their own VPCs.

As an example here, if I go back from the default network, I just delete that pairing. The peering will disappear and even custom VPCs with this peering enabled will wait and not be able to connect you to the default network. Soon continue. Therefore, these are individually managed connections. That's what you might think of VPC quotas and limits, we'll cover that in the next chapter. VPC Quotas and Limits VPC does not support IPV Six on the network. Therefore, IPV 6 is not compatible with VPC. VPC only supports IPV 4. Unicast or Multiclast Multicast is not supported here or within VPC. VPC networks can have 15,500 VM instances, and you can't expand this number. There is no limit per subnet only in VPC.

So you can have a specific subnet with all 15,500 VMs or multiple subnets with different numbers of VMs, but the total number of VMs should not exceed 15,000. That way, even with Shared VPC, you can See what limitations apply to Shared VPC. The number of Service Projects that can be attached to the Host Project is up to 100. The number of Shared VPC Host Projects that you can have is 100. The number of Host Projects that a Service Project can be attached to is one. Ok, this is really important for matching. You must observe the interconnect limits per instance, the number of instances, etc. B. per network, secondary IP, max tags.

So all of those are like additional limits. You can make sure you understand routers, firewall rules, and forwarding rules. How many rules can you create? So all of this affects your quotas and limits and you probably want to check them. Let's take a look at some of the security requirements we have for VPC. And this is the first one, the bastion host. So what you can do is, if correct, some instances are internal to your VPC and should not be accessed outside of your VPC network.

And you can imagine that you have a database application server that you want to completely isolate, or you have some instances of processing or back-end processing that are not exposed to the outside. What you can do is get the external IP address of that specific VM instance, and your internal clients will connect to those specific VM instances when needed. And you're fine with that if you want maintenance, if there's something, if you want to install or update software there or fix certain things at maintenance time. What you can do is create a bastion host.

This is another virtual machine inside the network. And for that network, you can open the firewall to connect to that particular instance and do whatever activities you want. This instance only has external access for this specific maintenance window. And once the maintenance is done, you can easily delete that particular instance. And that host is called Passion Host. It is used for temporary or maintenance purposes to bring internal instances or virtual machines online at maintenance time. The other time, there is no access from outside the network to these specific instances. As you can imagine, this allows you to isolate your internal servers from the outside world. The second aspect of security is when services actually want to connect instances to their internal instances.

And that's the outside of the grid. So you might have two different networks, perhaps your data center or another project's network resources that want to connect your internal instance. Here you can go ahead and use the nat gateway. So when you look at the instance, it usually doesn't have an external IP address, right? And it's definitely not accessible from the outside and that's how we can protect it, right? You can configure instance two as a nat gateway, with the IP forwarding rule configured on instance two. What happens is that instance three can connect to instance two and the traffic is routed to instance one and you can configure the firewall rules on the instance to only pull connections from the instance from the other network. And you can really imagine that if you want to isolate the instance but at the same time have access to the system and then secure connections to your other network.

And that's what a nat gateway can do. We'll see this in the Nat Gateway and Bastion Host demo. Let's jump into a demo and see this in action for the Nat Gateway and Bastion Host. guys, thanks VPC Flow Logs The VPC Flow Log records a sample of the network flow sent and received by A-VM instances. And you can think of it as the network protocol. Whenever external entities or the system access the network, everything in the VPC flow log is blocked. By default, it is not checked when it is created or you can update it to create flow records. This logging is definitely very large, so when you enable it, you need to make sure that you enable it, and that wherever you store these flow logs, you have the aforementioned retention policy in place. Therefore, these locks can be used for network monitoring, real-time security forensics, and cost optimization.

Crash Collection, Flow locks are collected every 5 seconds from each virtual machine connection. And that is the annotated data that is sent to the Stackdriver log in the data format described here. Blocks are stored in the Stackdriver registry for 30 days. If you want to keep the record longer, you'll need to export it at the destination and we'll be looking at those flu records shortly. Use cases. You can monitor the network, understand network usage, and optimize network traffic. And again this is very important, if your network traffic is constantly going to the region or the resources aren't really close to your client then you can probably increase the back end instances on the network where there are a significant amount of traffic. To the right. So you might have multiple use cases like this to understand flow logging or go into details.

The way you enable flow logging is in the console on the fly. So if I go into my network here, if I click read, I should be able to see OK, if I go to create the network, I can enable flow blocks here. Ok, so it's part of the subnet. Let me go ahead and use what is available. Flow locks are disabled. You can go ahead and edit and now you can enable flow locks. All network access for that particular instance residing on that subnet is captured in the Stackdriver log and when I go into the Stackdriver log it takes some time to get the logs. So what you can do is type subnet or just go directly to the GCE subnet for that specific subnet and get the logs for that specific subnet. So it only sees that specific subnet because I just enabled it for a specific subnet. You can go ahead and enable it for as many other subnets as you like. I can go here and to the VPC network. So if I go to the default network here, I can click here and edit and you can enable flow blocking for those subnets. So this is how you can get the flow locks. As an example here, I tried to connect it from Windows Nt, on the right and you can see the compute engine details, that's the timestamp, that's ok and that's the end point. In the same way, you can get flow logs and perform flow block analysis. If you have any questions about the flow gate, please let me know; otherwise, you can move on to the next lesson.

With VPC pricing, VPC is designed for outbound Internet traffic that varies from region to region, region to region on the same network, or between zones within a region. So you have to make sure that you design, design the network, design it correctly. It is not designed for traffic from Grace VM to VM in a single zone or traffic from GCE services and a limit may apply. You can actually go ahead and look at the pricing documentation, as it might have changed by watching this particular video.

Another thing to note here is that they have developed a standard and premium tier for you to review and more importantly you need to make sure you get the standard tier vs premium tier - understand any tier you can think of. The Standard tier is like all the other public cloud network offerings we have available, like AWS and Azure, which use the public internet most of the time to get your traffic to the service where it is. In the context of Google, many locations have a fiber optic network and a point of presence.

So they route their traffic closer to the customer through their own fiber optic network and that's the premium tier. So when I used it the last few years, everything was premium level. That's why I can guess. But now they have also created a standard level to reduce the prices that the customer incurs. That's it for the VPC folks. In short, we will go into details about the demo. But if you have no doubts about the theory, let me know. If not, you can skip to the next chapter. Thanks.

14. 1.3 Design of a hybrid network

Hybrid cloud network connectivity. We'll cover the connection between your own premises and your VPC, and we've already seen how you can use VPC to create your private network in a public cloud environment. Now we'll see how to connect this private network environment to your own data center, if you have one, or to your office. So hybrid connectivity, or connecting your own office to your private cloud or network, is part of the network service, and the network service is part of one of the three main services available in a public cloud environment. We will see that we have already seen VPC which is your private network in the cloud. Now let's connect it as a VPC to your own premises via VPN or peering, and we'll get to that in a bit.

Therefore, to connect your own facilities to GCP, you have several options that you can use depending on your use case. The first option is to simply copy and paste whatever you can imagine into the Google Cloud platform. The first option is Google Cloud Interconnect and what is it? So this is necessary if you want meaningful data exchange between your Google cloud platform and your own office, not your end customers but your own office or data center, and that's where you use Cloud Interconnect. We'll get into the details of Interconnect shortly, but we just want to give you an overview.

The other option you have if you don't want a dedicated connection is Cloud VPN. You can think of it as a traditional VPN or an IPsec VPN that can be used on the public Internet. There is no physical connection when using Cloud VPN, you just go through the public internet and why you are using it. You don't really have the use case of connecting your connection to the cloud or having a dedicated GCP VPC conduit or channel for your own premises and this is where you'll start with Cloud VPN. It is cheap compared to interconnects and has its pros and cons. But this is the second service. The third is mating.

And this is not just a part of Google Cloud Platform, but you can imagine that peering is required if you want to connect your Google Cloud Google Platform. As with G Suite apps, you'll want access to all other Google services and take advantage of the reduced subscription fee. And that's where you use peering. It has several peering options like Direct Peering and Carrier Peering and we will see the differences in all of these shortly. So the first one is Cloud Interconnect. So with Cloud Interconnect, you can connect your own website, or any data center you can imagine, to the Google Cloud platform. The additional benefit you get from Cloud Interconnect is that you have a dedicated connection directly to GCP and can exchange data there. You can change the network settings, e.g. B. If you have a subnet deployment in your own data center and want to connect your resources, virtual machines, or physical servers to GCP resources, or if GCP wants to connect to its own servers.

This is where Cloud Interconnect can help you establish a dedicated Internet connection or connections between your premises and Google Cloud Platform. It functions at such a high level that it is a highly available, low latency service that you can use to connect your local business to Google Cloud Platform. You can have dedicated and partner connection options. So you might have a location where you can connect to Google to get the location popup. However, there are some companies that do not have connections or a location close to the Google Pop location. Here you can go with the partner connection option. Compliant with RFC 1918.

What does that mean? This means that you can have a network exchange between on-premises and the cloud, and all of these resources can communicate with each other. You can create IP ranges and IP ranges. That's how we saw it in VPC, right? Similarly, you can have network or support connections between your campus or office with your GCP VPC, and it's a direct or private line that you can think of as a data center from your data center to Google Cloud facilities. Another option that we have is direct or partner harmonization and why use it? So you can't imagine that you want to change the network locally with Google Cloud Platform.

So all you can think about is Google and you just want to lower your egress rates and have a high speed connection and this is where you use direct interconnect. They do not share network information with Google Cloud Platform through the peering option. So the features allow you to have direct connections to Google or a partner wherever you are, if you're not available there with a direct connection you can have a VPN that you can set up or go directly to the internet for example. B. Public Internet and you want to reduce the cost of egress fees, right? And here you use direct interconnect. The third option we have is Cloud VPN and this VPN is a traditional traditional VPN. So why are you using it? It has an SLA, a 99.9 service availability SLA.

You can have site-to-site connections, and you can create multiple connections to the cloud environment or GCP environment from your own data center or offices. It supports cloud routers and we'll go into detail about what it is and what it means for us. Like a cloud router. However, you may want to consider exchanging your own location's network information with GCP, as this allows GCP service resources to discover your local resources. A cloud router can be used and you can have encrypted or secure traffic with Cloud VPN and here you use Cloud VPN. In general, we will look at Cloud Interconnect, Cloud Direct and Carrier Peering, Cloud VPN, and Cloud Router. Cloud Router is just a plugin. You can imagine what service you need to use to announce changes to the network, if any. And let's go into details.

This is high level, you can think of a decision tree, and based on that decision tree, you want to use one service or another to connect your on-premises data, office, or data center to the Google Cloud platform. Do you need direct high-level access to your private computing resource in Google Cloud? The answer is no. There you go to the matchmaking options, right? So here you are only accessing your local Google Cloud and not your cloud resources, accessing your local data and this is where it differs. To the right. Need to connect your G Suite? Yes.

And can you meet the matchmaking requirement? If you are in the Google location, you can look directly. If you're not there, there are partners you can connect to Google with their own connections, and this is where you use carrier pairing. So this page is where you want to exchange data between the premises and the Google Cloud platform with the interconnects or network gateways, and that's where you need to take that path. Do you need to extend your data center to the cloud?

Yes, this is the default. Do you encrypt sensitive information at the application level? If you encrypt sensitive information at the application layer, go ahead and switch to Interconnect, as Interconnect does not provide encryption for that particular channel. If you need encryption because your app doesn't, use Cloud VPN. OKAY? So if your app encrypts or doesn't need to encrypt your data, you can choose the interconnect route. Can you meet Google at one of our Pops locations? And that's where it tells you if you're in the featured place. There you can choose this route. Or just talk to the interconnect partner and connect it to Google, right?

Do you need 10 GB or more? And then you have direct connections, because if it's less than ten GB, Google recommends going with the partner because it's cheaper. To the right. I won't go into too much detail here, but the general idea here is that if you need an SLA, go for dedicated and VPN connections. If you care less about SLA, choose Direct Peering or Carrier Peering. More importantly, if you want to exchange your own data center network with Google or have a direct connection between these two, your own data center and Google Cloud Platform, then choose Dedicated Interconnect or Cloud Vpier.

If you don't need your on-premises resources to communicate with Google Cloud Platform, choose Direct Peering and Carrier Peering. If you only access G Suite applications or the collaboration platform and want to reduce your outbound traffic, you can simply use Direct Peering or Carrier Pairing, depending on where you are or where you are. Ok, this is straight to the point. We will go into more detail about Cloud VPN in the next presentation. Thanks. Where can you really go and explore hybrid connectivity options? You can go to the console and you can go to the network and you have hybrid connectivity and there you see three options, right? VPN and interconnects are connection options and Cloud Router only displays or announces your network or Internet changes. So when I get here, you can't see the pairing option here because the pairing is supported by the G Suite connection and not as part of the Google Cloud Platform connection. So you can go here and create a VPN connection.

If you want to have a VPN connection you can go here and do interconnects if you have a data center and you can replicate and you can connect a cloud router built from this that we used in the demo for VPN that you'll see. I can't show the Interconnect demo because I don't have a data center to connect to. But I can show you the region-to-region demo on the Google Cloud platform, and then we also add a cloud router to advertise changes to the network, and we'll see that in the demo as well. So that's all about the hybrid connectivity guys. If you have any questions here, you can wait for theory for individual services or ask me in our questions. Thanks.

15. 1.3 Designing a hybrid network VPN

Cloud VPN. This is the VPN service that we are traditionally known for in IPsec. Usually you really want to connect your data center or local office to Google Cloud Platform, and this is the Go Vayu Internet channel, it is public Internet, and you can connect through a VPN gateway or VPN gateway in the cloud with GCP, and we'll see it in a nutshell. But it is used for your local VPN to connect to Google Cloud Platform VPN. And we are talking about this particular VPN. We are not talking about local VPN. You can have that hardware appliance or you can have that software appliance on-premises, but we're talking about cloud VPN in the cloud for GCP. Therefore, you can use IPsec VPN to securely connect some of the Cloud VPN resources to your on-premises network with GCP VPC. It has high performance over IPsec, communication tunnels or communication channels you can use, and if you need more performance, just add tunnels and you're done.

It is scalable to accommodate your data. Compatible with Ikea V One and Ikea V Two. Both can even run on Google Cloud Interconnect. We'll see shortly that to encrypt ECMP over multiple VPN tunnels for higher aggregate performance, the traffic is encrypted per VPN by default. It supports static and dynamic routing through cloud routers, supports high performance with security and reliability, and is a managed service. You don't need to manage anything on Google Cloud Platform. It is managed by Google. The SLE is 99.9% of the monthly availability of the service.

You pay for individual tunnels, and as you add more and more tunnels, you pay for multiples of those tunnels. The VPN uses points of presence around the world, so your data is routed to the point of presence closest to where you have it. Cloud VPN uses ESP in tunnel mode with authentication. So Cloud VPN does not support Ah or ESP in transport mode and this is just one node. So how does it all really work? So you have a Vpnr connection in your own data center or office, right? And you have different departments, like marketing and legal, and you want to connect to the Google Cloud platform where your VPC is spread across two different regions.

In summary, the VPC is global in nature, but has subnets in region one and region two. And you want to connect your vpn vpn data center to the cloud and there you can connect different vpn routers per region and that's one per region. So if you have your connection to region one, you'll have a VPN connection, and if you want to support region two, you may need another VPN connection. You need public IP addresses on both sides of the connection. It can be global native, can support up to three GPUs with data, a single tunnel, and can scale out with multiple tunnels. If you add it to the demo, we will connect one region to another using a VPN connection. As I have no location and no data center to connect to these GCP services. Okay, where I work, I can't prove that data from your data center or the company I work for is going from there to the Google Cloud platform, because that's not allowed.

Then I have to present the demo. At Riverain, we connected region one to region two with VPN and also added a cloud router so you can see network exchanges in both locations. That's it for Cloud VPN. We'll cover the demo in the next chapter, but let me show you where to go and watch the demo. So you're looking for networks and network services, not true hybrid connectivity. And there you will see VPN, Cloud Interconnect and Cloud Router.

By going here I can create a VPN connection and explain where it wants to go, where I want to connect to it, what network I want to connect to, say custom VPC when I get to the region I want to connect to for that specific VPC and you can create it. We will have a demo for that. But here you can easily create a VPN connection. That's it for VPN. Guys, if you have any questions about the theory, please let me know. If not, you can skip to the next lesson, which is a VPN demo. Thank you.