In this final chapter of our Google Cloud Platform journey by an Azure guy, we will check some of the cool features in Google Cloud Platform, namely the network component, logs and monitoring, and security settings for apps and data. The previous articles on the journey can be found here, here, here, and here.
Understanding GCP virtual private cloud (VPC)
Before getting back to the wizard, we need to understand the network stack when using GCP. Google has a software-defined network called Andromeda, and the virtual private cloud (VPC) is one of the subproducts of the network stack. The VPC allows connectivity for the IaaS (VMs), GKE (Google Kubernetes Engine), App Engine flexible environment, and other Google Cloud services. It provides high availability through load balancers and connectivity.
A GCP project is not limited to a single VPC. By default, any new projects start with a default network and contain one subnet in each region. One of the cool features of GCP is that a VPC expands across regions, wherein Azure we have a limitation where the virtual network is bounded to a subscription/region.
Step 8: Set up the network configuration
(Just a quick reminder: Steps 1-7 in setting up your organization can be found in our previous Google Cloud Platform journey articles. Check the links at the bottom of the page.) The wizard will guide us to understand the VPC architecture and instruct us to create a shared VPC. A shared VPC helps to place resources from several projects in a single VPC. This design is perfect for a network team with the core network as a project, and all other projects will use that shared VPC to place their IaaS, GKE, and so forth.
As part of the network configuration, the wizard will help us create the VPC, configure it as shared VPC, manage connectivity with on-premises and other cloud providers, configure external traffic, firewall rules, and inbound (including load balancing).
The wizard has interactive buttons. When we select the project (Item 1) to host the VPC, and if the given project does not have capabilities to provision VMs, the wizard will facilitate to enable the API (Item 2) for the given type of workload. That is new for Azure cloud administrators like me since Azure's subscription supports virtual networks and IaaS without any cloud administrator approval or interaction.
The VPC creation will end up in the VPC network area (a ping-pong game between wizard with documentation, documentation only, and the actual page to configure the feature already mentioned twice) of the GCP Console. We can see the wizard that enables the creation of our VPC network containing subnets and routing, and we can also configure them as part of the process.
The result of the creation of a new VPC is depicted in the image below. We created one subnet in each region of Canada available at GCP. The default network is there as well, and we can see that it has 28 subnets and one in each region of the GCP global cloud (Pretty cool, eh?).
In Step 3, configure connectivity between the external providers and the GCP section. It will use a gateway and a tunnel. The wizard allows us to create a VPN connection from on-prem or another cloud to GCP and enable the hybrid network between environments.
The Azure counterpart would be creating a VPN gateway/ExpressRoute to support the traffic in a hybrid cloud. We will not pursue that connection at this time, and we will click Continue.
On Step 4, set up a path for an external egress traffic section. We can create a cloud NAT service from GCP, a feature of Google’s software-defined managed service (Andromeda Software). It provides SNAT (source network address translation) for VMs without public IP addresses.
We can configure cloud NAT. Later on, it can be found under Network Services in the GCP Console.
Comparing this to Azure, this section would be similar to Azure Virtual Network NAT that provides outbound public IP for Azure resources.
In Step 5, implement network security controls, which is where we can configure firewall rules. Firewall rules are applied at the VPC level, which means a specific project or network. We can have a firewall policy that applies to multiple VPC networks within an organization.
The firewall rules in GCP are similar to network security groups in Azure, having the following options: priority, action, enforcement, target, source, protocols, and ports.
In Step 6, choose an ingress traffic option. Here is where we can configure the load balancer to support our future applications and provide high availability from the GCP platform.
Step 9: Set up logging and monitoring
We can set up monitoring by choosing a project that will host all monitoring in GCP or any other design you may have (one monitoring project per environment, for example). The wizard helps select the project and create the workspace (there is one button for each function).
All monitoring can be centrally managed from the Monitoring area of the GCP Console. We can add new projects as well. We can ingest logs from different sources and forward them to external data sinks (like Google’s BigQuery service).
Logging in Microsoft Azure is simpler. We have diagnostic settings on all Azure resources, and they are forward to Log Analytics (similar to Google’s Workspace).
Step 10: Configure Google Cloud security settings for apps and data
Finally, we got to the last step! Now it is time to secure the environment, and we can do that by going to the Google Cloud Platform Security Command Center, as recommended by the wizard.
In our first visit, we will be prompted with a small step-by-step to configure the security at the organization level, as depicted in the image below.
Google’s Security Command Center requires its own article series. It is a solution that protects GCP and cannot be explained in a single section. However, the steps followed will be able to get you protected with default settings. Compared to Azure — from my perspective — Azure Security Center makes things much easier to follow and protect the environment where Google has too many options, and some settings are hidden within sections and sometimes more than two clicks away.
Google Cloud Platform journey: We’ve made it!
In this final article of our series, we complete the configuration of our organization following Google’s recommendations. Their process ensures that we understand the platform’s high-level architecture and enable some fundamental pieces required to have your environment.
In theory, you are ready to explore your GCP environment. In our Google Cloud Platform journey, we configured the identity, security, and core infrastructure to support new workloads.
Featured image: Shutterstock
More Google Cloud Platform Journey articles
- Google Cloud Platform journey: Creating and setting up the hierarchy
- Google Cloud Platform journey: Validating your domain
- Google Cloud Platform journey: Setting up an organization with Cloud Identity
- Google Cloud Platform journey by a longtime Azure Guy