• +000 0000 000
  • [email protected]
    • Contact Us

    Category Archives: Implementing subnets

    1. Home / 
    2. Archive by category "Implementing subnets"
    Sep 4, 2024
    Deploying AKS 2 – Creating and Configuring Containers
    1. Next, we have the Authentication tab; here, you will note we can modify the setting for the Authentication method type to either Service principal or System-assigned managed identity. This will be used by AKS for managing the infrastructure related to the service. For this exercise, we will leave this at its default setting. Then, you have the Role-based access control (RBAC) option. By default, this is set to Enabled; this is the best option to manage the service as it allows fine-grained access control over the resource; leave this as Enabled. You will also have the choice to enable AKS-managed Azure Active Directory. Checking this will enable you to manage permissions for users on the service based on their group membership within Azure AD. Note that once this function has been enabled, it can’t be disabled again, so leave this unchecked for this exercise. Finally, you have the option of the Encryption type value you want. For this exercise, leave it as the default setting. Click Next: Networking >. The process is illustrated in the following screenshot:

    Figure 11.47 – Creating a Kubernetes cluster: Authentication tab

    1. For the Networking section, we will leave most of the settings as their default configuration. Note that for Network configurations we have two options here, one for Kubenet and another for Azure CNI. kubenet is a new VNet for the cluster whereby Pods are allocated an IP address and containers have network address translation (NAT) connections over the shared Pod IP. Azure Container Networking Interface (Azure CNI) enables Pods to be directly connected to a VNet. In association, this allows containers to have an IP mapped to them directly, removing the need for NAT connection. Next, we have the DNS name prefix field, which will form the first part of your FQDN for the service. You will then notice Traffic routing options available to us for the service—we will discuss this more in one of the next exercises, as well as the Security options available to us. Select Calico under Network policy. Click Next: Integrations >. The process is illustrated in the following screenshot:

    Figure 11.48 – Creating a Kubernetes cluster: Networking tab

    1. On the Integrations tab, you will note the option to select a container registry. We will select the registry that we previously deployed. You will also note you have the option to deploy a new registry directly from this creation dialog. Next, we have the option to deploy container monitoring into the solution on creation. We will leave the default setting here, but monitoring will not be covered under the scope of this chapter. Finally, you have the option of applying Azure Policy directly to the solution; this is recommended where you want to enhance and standardize your deployments. This solution enables you to deliver consistently and control your deployments on AKS more effectively. Click Review + create, then click Create. The process is illustrated in the following screenshot:

    Figure 11.49 – Creating a Kubernetes cluster: deployment

    You have just successfully deployed your first Kubernetes cluster; you now know how to deploy and manage containers at scale and in a standardized way. Next, we will look at how we configure storage for Kubernetes and make persistent storage available to our solution.

    More Details
    Apr 6, 2024
    Configuring scaling for AKS – Creating and Configuring Containers

    Configuring scaling for AKS

    You will note that from our previous exercises, there was no option to automatically scale and resize containers. The only way to change this was to redeploy our container instances and groups. With Kubernetes, this dynamic changes as you can change the scale settings before and after your deployment, and they can be configured to scale manually or automatically. For this exercise, we will run through changing the auto-scale settings of our AKS cluster. Proceed as follows:

    1. Sign in to the Azure portal at https://portal.azure.com.
    2. Navigate to the AKS cluster you created in the previous section. On the left menu, select the Node pools option and click on your deployed agentpool node pool, as illustrated in the following screenshot:

    Figure 11.56 – Configuring a Kubernetes cluster: Node pools

    1. Selecting either the Overview or Configuration pane will present you with the option to change your pool scale settings. Click Scale node pool, as illustrated in the following screenshot:

    Figure 11.57 – Configuring a Kubernetes cluster: Overview

    1. To change the automatic scale option, set the Scale method type to Autoscale, enter a value for your Min and Max node count, then click Apply. The process is illustrated in the following screenshot:

    Figure 11.58 – Configuring a Kubernetes cluster: Scale node pool

    1. For the manual scale option, set the Scale method type to Manual, enter a Node count value (this will be the number of nodes you want to run), and click Apply. The process is illustrated in the following screenshot:

    Figure 11.59 – Configuring a Kubernetes cluster: Scale node pool (continued)

    1. After applying the settings, you will notice your agent pool goes into an Updating state, as illustrated in the following screenshot:

    Figure 11.60 – Configuring a Kubernetes cluster: Updating

    You now know how to scale your agent pools within AKS and can feel confident about managing this aspect. If you would like to change the VM size for the agent pool, you will need to redeploy the pool. In the next section, we will look at managing network configurations on your AKS cluster.

    More Details
    Sep 10, 2023
    Understanding App Service plans and App Service – Creating and Configuring App Services

    Understanding App Service plans and App Service

    When discussing Azure app services and understanding what they are, compared to traditional servers, it’s important to understand the relationship between Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS), andserverless (such as Function as a service (FaaS)). As you move through the different service offerings, you have different layers of responsibility that you manage. This is also the easiest way of understanding the differences between the services. IaaS, PaaS, SaaS, and serverless are cloud-based services and fit well into the Azure platform since Microsoft has developed some great ways to manage the services you deploy. This also allows you to choose the level of control you would like to adopt. There are limitations to each model, which is a much deeper topic, but understanding these limitations at a core level will help you succeed in your Azure journey. The following diagram illustrates the management relationships between the cloud-based services:

    Figure 12.1 – Shared responsibility model

    As you can see, the closer you approach SaaS, the fewer components you are required to manage and, subsequently, can manage. Finally, the serverless component can be a little confusing as it falls between the PaaS and SaaS layers; you can only manage your code and, ideally, split your code into single repeatable components called functions. Serverless components are also classified as microservices since the services are broken down into their most basic forms. Here, you define the functions you need to run your code; you can deploy the code and forget about which server it runs on. This approach does lead to more in-depth and complex discussions that are beyond the scope of this book; you just need to understand that this exists and that in Azure, we often refer to it as FaaS. Now that you understand the relationship between these services and what you manage, we can classify Azure app services. They fall into the PaaS category; therefore, you only have to worry about how you manage your application and its data. You also have the choice to secure your application using controls that have been exposed to Azure. The rest is taken care of by the platform itself.

    App Service plans

    To run your applications, you must deploy and configure your server infrastructure appropriately to suit your applications. For example, your applications may require the Windows operating system and the .NET Framework. To accommodate these configurations, Azure has App Service plans. This is a server that’s related to your application deployments, where you can choose an operating system, the number of nodes in your cluster, server-related security configurations, and operations. It also allows you to run several applications against a server with the chosen specifications for memory and CPU resources and only scales as per your requirements or budget.

    Top Tip

    Although Azure Functions falls into the serverless category, when assigned to an App Service plan, it becomes a PaaS service since it is linked to a server. This increases what you can manage on the service and allows better control over, for example, security features.

    Now that you understand more about Azure App Service and App Service plans, let’s dive into some exercises where we will work with these later. In the next section, we will deploy an App Service plan and dive into the available configuration options.

    More Details
    Mar 1, 2023
    PowerShell scripts – Creating and Configuring App Services

    PowerShell scripts

    Please ensure that the Az module is installed, as per the Technical requirements section at the beginning of this chapter.

    Here, we are going to create an App Service plan and Web Apps service via PowerShell.

    To do so, follow these steps:

    Note: Change the parameters to suit your requirements

    • First connect your Azure account using your credentials Connect-AzAccount
    • Parameters

    $ResourceGroup = “AZ104-Chapter12”

    $Location = “WestEurope”

    $SubscriptionId = “xxxxxxx”

    $WebAppName = “mysecondwebapp10101”

    $AppServicePlanName = “mylinuxappserviceplan10101”

    • If necessary, select the right subscription as follows Select-AzSubscription -SubscriptionId $SubscriptionId
    • Create a resource group for the Availability Set as follows

    New-AzResourceGroup -Name “$ResourceGroup” -Location “$Location”

    # Create an App Service Plan for Linux

    New-AzAppServicePlan -Name $AppServicePlanName -Tier Standard -Location $Location -Linux -NumberofWorkers 1 -WorkerSize Small -ResourceGroupName $ResourceGroup

    # Create a Web App

    New-AzWebApp -Name $WebAppName -ResourceGroupName $ResourceGroup -Location $Location -AppServicePlan $AppServicePlanName

    Just as you did previously, you can browse to the web application’s URL and see the same screen you did prior. With that, you have just completed your first few web application deployments to Azure using the Web Apps service. You should now feel confident in deploying web applications when required in Azure, either through the portal or through PowerShell. Next, you will learn how to scale your applications.

    Configuring the scaling settings of an App Service plan

    In this exercise, you will configure the scaling settings for the App Service plan you created previously. Recall that we mentioned that there are two different types of scaling options you can choose from. Horizontal scaling (Scale out in the application menu) refers to the number of app services that have been deployed, while vertical scaling (Scale up in the application menu) refers to the size of the VM hosting the web app service. The VM refers to the App Service plan. As you may recall, we have the option to choose an SKU and size when we deploy that refers to the specifications for the App Service plan that we would like to have. First, we will explore Scale up:

    1. Navigate to the App Service plan you worked on in the previous exercise.
    2. From the left menu blade, underSettings, click Scale up (App Service plan).
    3. You will be presented with a screen containing different SKU sizes that you can choose from. The top bar represents the category that identifies the SKUs that are suitable for the type of workloads you will be deploying, such as dev/test and production.

    The Isolated environment is a more secure environment that deploys a set of resources that are isolated from the shared server environment you typically consume from; this will cost more to deploy as you will be the only one utilizing the server resources you are looking to consume for the applications in your service plan. Select Dev / Test and then select B1 as the SKU size. Note that the bottom part of the screen will display the features and hardware that are included related to the SKU you’ve selected. Also, note that under the SKUs, you have the option to See additional options. Click Apply:

    Figure 12.12 – Scale up

    More Details
    Jan 11, 2023
    Securing an app service 2 – Creating and Configuring App Services
    1. You will see a screen with additional configuration settings. The first item to configure is the application registration. This can be used to assign permissions and will configure a service principal account in Azure AD called an app registration. For this exercise, select Create new app registration and assign a name. Next, select the option for supported account types for your application. Depending on how and where your application is used, this will dictate the configuration that best suits your security requirements. For instance, if you are looking to deliver an internal application such as something that lists the mobile numbers of employees within your organization so that you can contact someone urgently (where sharing this information is disallowed publicly), then you would want to restrict public access (that is, anyone external to your organization).

    Using your identity provider will help you determine if they have an account with your organization or not. In such cases, you can select Current tenant – Single tenant. Any Azure AD direction – Multi-tenant will allow you to accept user logins from any other Azure AD directory. The next option, Any Azure AD directory & personal Microsoft accounts, opens access to public accounts too, where personal accounts can be used. Finally, Personal Microsoft accounts only removes access from other Azure accounts and limit this to personal Microsoft accounts. This is typically used for gaming services, whereyou want to allow friends to connect but you also want to restrict business accounts from accessing the service. As you can see, the most secure option is Current tenant – Single tenant. You can also configure Restrict access, where you can force authentication to be conducted before access is granted to your application. Unauthenticated access allows users to log in anonymously. Choose Require authentication since this is the most secure option. Finally, you can choose what kind of error handling you would like to deliver upon detection, such as delivering an HTTP 401 Unauthorized error message. Select HTTP 302 Found redirect. Then, click Next : Permissions >:

    Figure 12.27 – Identity provider configuration

    1. The next blade relates to the Permissions options you would like to grant. The default option is User.Read, which allows the application to read the user’s profile. These permissions can be modified as needed to deliver the required information to your application. These permissions will be prompted by the user when they access the application and are being authenticated. They will need to consent to this permission request if they wish to access the application. Click Add:

    Figure 12.28 – Identity provider – Permissions

    1. Click Identity from the left menu pane for the application. You will be presented with two tabs – System assigned and User assigned. Here, you can choose which deployment configuration you would like to use. System assigned allows you to create a managed identity whose life cycle is controlled and managed by Azure. A managed identity allows you to grant RBAC permissions to the application as if it were a user, which gives them better control over resources and prevents user management issues such as abuse of privileges or mistakes being made. Enabling this setting increases the security of your application and prevents credentials from being injected directly into code, which would allow account and system compromise to occur. User assigned is managed manually but can be configured more granularly for control over the specific RBAC permissions you would like to grant to the application. On the System assigned tab, click On under the Status option, then click Save:

    Figure 12.29 – System assigned

    1. After clicking Save, you will see a new configuration option, where you can configure the Azure RBAC permissions for your application:

    Figure 12.30 – Adding a role assignment

    More Details
    Jan 10, 2023
    Securing an app service – Creating and Configuring App Services

    Securing an app service

    There are several mechanisms you can use to enhance the security of your application on Azure. As part of the AZ-104 exam, we will explore the configuration options that are native to the web application directly. However, note that for real-world implementations, you should investigate additional measures for enhancing the security of your applications, such as employing a firewall – especially a web application firewall – for your web-based applications. These services provide traffic that’s in line with your application and scan for disallowed or heuristic behavior.

    In this exercise, we will look at various native application configurations that can be used to increase the security level of your app services:

    1. Navigate to the App Service plan you worked on in the previous exercise.
    2. From the left menu blade, under theSettings context, click Configuration. The first tab you will be greeted with is called Application settings. Application settings are variables that are presented securely to your application, but they can be configured externally from the application code. This enhances security by obfuscating the password from code and prevents developers that don’t have RBAC permissions on the Azure portal for the App Service resource from seeing sensitive data, such as secrets that may be stored under Application settings. The other item that can be configured is Connection strings:

    Figure 12.22 – Application settings

    1. The next tab is General settings. Here, you will want to ensure File Transfer Protocol (FTP) traffic is conducted securely if it’s allowed by your organizational policies. FTP is a technology that enables file transfer operations for your systems. It is commonly used by developers to upload code to the system; an alternative, as we explored in the previous chapter, is to use a source code repository such as Git. The most secure option is to disallow all FTP-based traffic as prevention is better than a cure. However, since many applications require developers to be able to upload their code, changing the FTP transfer protocol that’s being used is the next best option. Setting traffic to FTPS only ensures that the FTP traffic is conducted over an HTTPS tunnel, meaning that all the data is encrypted. So, even if it is intercepted, it is less likely to be compromised. Set this to FTPS only for
      this exercise:

    Figure 12.23 – FTP state

    1. Click Save at the top of the screen:

    Figure 12.24 – Options menu

    Note that after clicking Save, you will be warned that the application needs to be restarted.

    1. The last tab that can be configured in the General settings menu is Path mappings. We won’t explore this here.
    2. From the left menu pane, clickAuthentication. This blade contains the configuration settings related to authentication, the type of identity provider service that’s being used, and the authentication flow. To explore the available configurations, click Add identity provider:

    Figure 12.25 – Add identity provider

    1. At the time of writing, you can choose from several identity providers – that is, Microsoft, Facebook, Google, Twitter, and OpenID Connect. ClickMicrosoft:

    Figure 12.26 – Add an identity provider

    More Details
    Sep 4, 2022
    Configuring a backup for an app service – Creating and Configuring App Services

    Configuring a backup for an app service

    Your application is running well, but you’re concerned that if something should fail or data is lost, you can’t restore your application. You decide that backing it up is a good idea and start to explore different ways to back up your application. Thankfully, Azure makes this a simple process, where you just need to think about what your backup strategy needs to look like and then configure the service accordingly. Remember that using a backup is different from performing DR in that DR restores operational services, whereas backups enable point-in-time restorations of data to recover from loss or accidental deletion. Follow these steps to configure a backup for your application:

    1. Navigate to the App Service plan you worked on in the previous exercises.
    2. From the left menu blade, underSettings, click Backups. From the blade that appears, click Configure at the top of the screen. The Backup Configuration blade will appear.
    3. You will need a storage account to store your backups. Since we haven’t pre-created an account, we will create it as part of this exercise. Click the Storage Settings button:

    Figure 12.49 – Storage Settings

    1. Create your storage account and click OK. Next, you will be prompted for a container. Currently, this doesn’t exist since we created a new storage account. Click + Container, name the container backups, and click Create. Click the new container and click Select.
    1. For backups, you have the option to decide if you would like an automated schedule or if you would like to manually back up as and when needed. Preferably, you would like an automated schedule that prevents mistakes from occurring, such as forgetting to back up. Enable Scheduled backup. Configure your backup so that it runs every day at a set time from the date you would like this to start. In this example, we have set this to 28/12/2021 at 7:05:38 pm. Set your Retention period (in days) and set Keep at least one backup to Yes:

    Figure 12.50 – Backup Schedule

    1. Note that you also have the option to configure a backup for your database. We won’t configure this for this exercise. Click Save:

    Figure 12.51 – Backup Database

    1. You will see that your first backup is currently in progress and that the light blue box reflects the configuration for your backup schedule. You will also see two other blue buttons; the first, Backup, is for manually initiating a backup to be performed, while the other, Restore, allows you to recover data when required:

    Figure 12.52 – Backup overview

    You now understand how to back up your Azure App Service and should feel confident in configuring this going forward. In the next section, you will learn about the various network settings. Since we covered some of the available networking configurations in the previous sections, we will focus predominantly on how to configure a private endpoint.

    More Details
    Mar 4, 2022
    Downloading and extracting files for labs – Practice Labs – Deploying and Managing Azure Compute Resources

    Downloading and extracting files for labs

    Follow these steps to download and extract the required files:

    1. Navigate to the following URL and download the archive folder (.zip): https://github.com/MicrosoftLearning/AZ-104-MicrosoftAzureAdministrator/archive/master.zip.
    2. Depending on the browser you are using, you will likely be presented with different versions of the following dialog. Click Save File and OK at the bottom of the screen:

    Figure 13.1 – Downloading files (ZIP)

    1. Right-click the ZIP file you downloaded and click Extract All…(on Windows systems):

    Figure 13.2 – Extract All… (ZIP)

    1. Navigate to your downloaded folder and follow instructions from labs when needing files that will be in that folder.

    You have now downloaded all the files you need for performing the labs later in the chapter.

    Managing virtual machines lab

    This lab willguide you through creating standalone Virtual Machines (VMs) and VMs as a scale set, as well as exploring storage for these different deployments and how both solutions can be scaled. Furthermore, you will explore how VM custom script extension can be assigned and use to automatically configuring your VMs.

    Estimated time: 50 minutes.

    Lab method: PowerShell, ARM templates, and the Azure portal.

    Lab scenario: In this lab, you play the role of an administrator evaluating different methods for deploying VMs for scale and resiliency. You are also exploring how VMs manage storage to support your scale. You need to determine whether standalone VMs or VMs deployed as a scale set are best suited to your deployments and understand the differences between them to ascertain when to use the different deployment types. As part of your exploration task, you want to see whether there is any mechanism that can assist you in reducing the administrative effort involved in deploying your VMs or automatically completing configuration tasks. You have heard that a custom script extension can assist with this, and you want to see how this will guide you to achieve your expected result.

    Visit the following link (Lab URL) to the official Microsoft Learning GitHub labs, where you will be guided through each task step by step to achieve the following objectives.

    Lab objectives:

    1. Task one: Deploy two VMs in two different zones for resiliency.

    II. Task two: Use VM extensions to configure your VMs.

    III. Task three: Configure and attach data disks to your VMs.

    IV. Task four: Register the required resource providers for your subscription.

    V. Task five: Deploy your VM scale sets.

    VI. Task six: Use VM extensions to configure your scale set.

    VII. Task seven: Configure autoscale for your scale set and attach data disks.

    Lab URL: https://microsoftlearning.github.io/AZ-104-MicrosoftAzureAdministrator/Instructions/Labs/LAB_08-Manage_ Virtual_Machines.html.

    Lab architecture diagram: The following diagram illustrates the different steps and deployment components involved in the exercise. The tasks are numbered 1 to 7 to correlate with the steps in the exercise:

    Figure 13.3 – Managing VMs – architecture diagrams

    You have now experienced working with VMs both as individual resources and scale sets and should feel confident in working with these in your environments. It’s best practice to delete your resources from the lab to prevent unnecessary spending.

    More Details
    Oct 4, 2021
    Deploying Web App service lab – Practice Labs – Deploying and Managing Azure Compute Resources

    Deploying Web App service lab

    In this lab, you will be guided through the deployment of an Azure container instance with using a Docker image as the source. Finally, you will test connectivity to your containers to prove a successful deployment.

    Estimated time: 30 minutes.

    Lab method: PowerShell and the Azure portal.

    Lab scenario: In this lab, you play the role of an administrator who is looking to utilize Azure App Services for hosting your company’s web applications. Your organization, Contoso, has several websites running in on-premises data centers on servers using a PHP runtime stack. Furthermore, you are looking to start using DevOps practices within your organization and want to use app deployment slots to improve your deployment strategy.

    Visit the following URL to the official Microsoft Learning GitHub labs, where you will be guided through each task step by step to achieve the following objectives.

    Lab objectives:

    I.  Task one: Deploy your Web App and Service plan.

    1. Task two: Create a staging deployment slot for your web app.

    III. Task three: Configure deployment settings for the local Git.

    IV. Task four: Deploy your staging code.

    V. Task five: Swap the staging and production deployment slots.

    VI. Task six: Configure autoscaling and test your web app.

    Lab URL: https://microsoftlearning.github.io/AZ-104-MicrosoftAzureAdministrator/Instructions/Labs/LAB_09a-Implement_Web_Apps.html.

    Lab architecture diagram: The following diagram illustrates the different steps involved in the exercise:

    Figure 13.6 – Deploying an Azure web app – architecture diagram

    You have now experienced working with Azure web apps on the Azure portal as well as configuring autoscale rules. You should now feel confident in using this service within your daily role. It is best practice to remove unused resources to ensure that there are no unexpected costs.

    Summary

    In this chapter, we looked at several compute infrastructure type deployments. We explored the deployments of app services, Azure Container Instances, Azure Kubernetes Service, and VM deployments. We also looked at how to scale and manage these systems through a practical demonstration. You should now feel confident in managing Azure compute resources and working with these on Azure.

    In the next part of the book, we’ll cover the deployment and configuration of network-related services and components. We will explore the management of Azure virtual networks and securing services. We will then explore the load balancing services available to us, and finally, how to monitor and troubleshoot network-related issues.

    More Details
    Aug 8, 2021
    Creating and configuring virtual networks, including peering 2 – Implementing and Managing Virtual Networking

    One of the exam objectives for this chapter is to gain the ability to configure VNet peering. VNet peering is when two or more VNets are linked with each other so that traffic can be sent from one network to another. There are two types of VNet peering:

    • VNet peering: Connects VNets with the same region. There is also a cost associated with inbound and outbound data transfers for VNet peering.

    • Global VNet peering: Connects VNets across different regions. This is more costly than VNet peering within the same region.

    When using the Azure portal to configure VNet peering, there are a few settings that you should be aware of:

    • Traffic to a remote VNet: Allows communication between two VNets, as this allows the remote VNet address space to be included as a part of the virtual-network tags.

    • Traffic forwarded from a remote VNet: Allows traffic forwarded by a VNet appliance in a VNet that did not originate from the original VNet to flow via VNet peering to the other VNet.

    • Virtual network gateway or Route Server: This is relevant when a VNet gateway is deployed to the VNet and needs traffic from the peered VNet to flow through the gateway.

    • Virtual network deployment model: Select which deployment model you want with the peered VNet. This will either be classic or the standard resource manager method.

    Let’s go ahead and configure VNet peering. To do this, we need to create another VNet first using these steps:

    1. In PowerShell, use the following command:

    Connect-AzAccount

    1. Next, the following command will create another VNet, which will include a subnet that links to the VNet in the same RG that we created earlier in this chapter:

    $vnet = @{

    Name = ‘DemoVNet_2’

    ResourceGroupName = ‘VNet_Demo_ResourceGroup’ Location = ‘WestEurope’ AddressPrefix = ‘192.168.0.0/24’
    }

    $virtualNetwork = New-AzVirtualNetwork @vnet $subnet = @{

    Name = ‘Main_Subnet’

    VirtualNetwork = $virtualNetwork

    AddressPrefix = ‘192.168.0.0/24’

    }

    $subnetConfig = Add-AzVirtualNetworkSubnetConfig @subnet $virtualNetwork | Set-AzVirtualNetwork

    1. Sign in to the Azure portal by visiting https://portal.azure.com and navigating to the RG:

    Figure 14.5 – Both VNets showing in the Azure portal

    1. Next, select DemoVNet, and under Peerings, select Add:

    Figure 14.6 – Configuring VNet peering

    1. Next, configure the peering link name, as shown in Figure 14.7, and set the following fields as Allow (default):

    I. Traffic to remove virtual network

    II. Traffic forwarded from remote virtual network

    III. Virtual network gateway or Route Server:

    Figure 14.7 – Configuring VNet peering for DemoVNet

    1. Next, give the remote peering link a name of VNet_Peering, select the VNet, and configure the following fields as Allow (default):

    I. Traffic to remove virtual network

    II. Traffic forwarded from remote virtual network III. Virtual network gateway or Route Server Next, click on Add:

    Figure 14.8 – Configuring VNet peering for DemoVNet_2

    1. Give the peering status a few minutes to enforce the peering. The final peering status will be Connected:

    Figure 14.9 – Successfully configured peering between VNets

    In this section, we had a look at how virtual networking works in Azure as well as how to create a VNet and subnet via PowerShell. We also had a look at how to configure VNet peering between two VNets.

    We encourage you to read up on Azure virtual networking and VNet peering further by using the following links:

    • https://docs.microsoft.com/en-us/azure/virtual-network/ quick-create-powershell

    • https://docs.microsoft.com/en-us/azure/virtual-network/ manage-virtual-network

    • https://docs.microsoft.com/en-us/azure/virtual-network/ virtual-network-peering-overview

    More Details