My journey to DevOps

In GCP, you have two options for sharing networks across GCP projects: Shared VPC and VPC Network Peering.

In this article, we discuss more detail its features and how to implement them.

Shared VPC overview

• Shared VPC is a centralized approach to multi-project networking allowing 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
• Shared VPC network is created and managed by a Shared VPC Admin which is nominated by an Organization Admin
• Shared VPC Admin is responsible to enable shared vpc feature on the host project and attach service projects to the host project. He can also delegate access to some or all subnets in the shared VPC network by granting the compute.networkUser role for Service Project Admins at the project level or the subnet level
• Service Project Admins in his turn maintain ownership and control over resources defined in their service projects. They could create and manage resources (vm instances, instance templates, instance groups, static internal ip, load balancers) in the shared VPC.

Yesterday, I have passed the Azure Security Engineer Associate exam (AZ-500) after two months of preparation. It’s quite tricky but I learned a lot from this exam 😊

In this article, I would like to share with you some important points considering the mentioned exam.

Exam’s Format:

• 51 questions (with an important part of lab questions)
• 1 case study (4 questions in general)
• 180 minutes
• skills measured: link

Preparation Guide:

• Microsoft Learning is your good friend: link
• Also, Stanislas Quastana (Microsoft’s Cloud Solution Architect) wrote a great article on his blog in concern of this exam: link

In contrast of Google Cloud Platform, Azure Virtual Machine has access to the Internet by default (even if your vm doesn’t have a public ip). You don’t need to do anything to have internet access.

But what if you would like to control the web traffic (http/https) to the internet from your virtual networks (due to the company’s policy for example). You may need to establish a single access point to the internet on which you could control the outbound access.

In the previous article, we discussed the Hub-Spoke Topology. We will expand this architecture to cover our topic today.

Our architecture modified:

As you saw in the previous architecture, we have three virtual networks:

• Hub virtual network (hub-vnet): region France Central
• Spoke 1 virtual network (finance-vnet): region West Europe
• Spoke 2 virtual network (it-vnet): region North Europe

We need to control the web traffic from all spoke networks to the Internet .

We will add a new virtual network:

• Proxyout virtual network (proxyout-vnet): region France Central

On this new virtual network, we place two virtual machines (proxyout) behind a Azure Load Balancer Standard to receive/control the web traffic (http/https) from other spoke networks. You could install a middleware (squid) to allow/deny the access.

So, our architecture will be the following:

Today, we will implement a hub-spoke topology in Azure.

The hub is a virtual network in Azure that acts as a central point of connectivity to your on-premises network.

The spokes are virtual networks that peer with the hub and can be used to isolate workloads.

For more information, we refer to this document.

In our case-study, we don’t have on-premises network, so the architecture will be adjusted a little bit:

As you know in the previous article, we could take advantage of Cloud NAT to go to the Internet without an external IP.

But the NAT gateway created in one VPC network cannot provide NAT to VMs in other VPC networks connected by using VPC Network Peering, even if the VMs in peered networks are in the same region as the gateway.

So, how we can use Cloud NAT in case of we have some VPC networks ? I will explain to you in this article.

This is the third part of GCP’s series. In the first article, you have seen that a virtual machine needs to have an external IP to reach out to the services outside of the VPC in which it is deployed.

Topics to cover:

• Private Google Access
• Cloud NAT

This is the second part of GCP’s series. In the previous article we covered some basic terminology in GCP.

As you know, each virtual machine created has an internal IP assigned. From the same network, you can reach out to this vm using it’s internal IP or it’s internal DNS.

This is the first part of GCP’s series. In this article, you will familiar with some of the basic terminology used in Google Cloud Platform (GCP).

Topics to cover:

• Google Cloud
• Projects and networks
• Internal IP and External IP
• DNS resolution for internal IP
• DNS resolution for external IP
• Cloud DNS
• Firewall
• Route