Category Network Security Groups

Azure Functions falls into the Functions as a Service (FaaS) or serverless category. This means that you can run Azure Functions using a consumption plan whereby you only pay for the service as it is being executed. In comparison, Azure App Service runs on a service plan in which you define the CPU and RAM.

With Azure Functions, you don’t need to define CPU and RAM as the Azure platform automatically allocates whatever resources are required to complete the operation. Because of this, functions have a default timeout of 5 minutes with a maximum of 10 minutes – in other words, if you have a function that would run for longer than 10 minutes, you may need to consider an alternative approach.

Tip

Azure Functions can be run as an App Service plan the same as App Service. This can be useful if you have functions that will run for longer than 10 minutes, if you have spare capacity in an existing service plan, or if you require support for VNet integration. Using an App Service plan means you pay for the service in the same way as App Service, that is, you pay for the provisioned CPU and RAM whether you are using it or not.

Functions are event-driven; this means they will execute your code in response to a trigger being activated. The following triggers are available:

• HTTPTrigger: The function is executed in response to a service calling an API endpoint over HTTP/HTTPS.
• TimerTrigger: Executes on a schedule.
• GitHub webhook: Responds to events that occur in your GitHub repositories.
• CosmosDBTrigger: Processes Azure Cosmos DB documents when added or updated in collections in a NoSQL database.
• BlobTrigger: Processes Azure Storage blobs when they are added to containers.
• QueueTrigger: Responds to messages as they arrive in an Azure Storage queue.
• EventHubTrigger: Responds to events delivered to an Azure Event Hub.
• ServiceBusQueueTrigger: Connects your code to other Azure services or on-premises services by listening to message queues.
• ServiceBusTopicTrigger: Connects your code to other Azure services or on-premises services by subscribing to topics.

Once triggered, an Azure function can then run code and interact with other Azure services for reading and writing data, including the following:

• Azure Cosmos DB
• Azure Event Hubs
• Azure Event Grid
• Azure Notification Hubs
• Azure Service Bus (queues and topics)
• Azure Storage (blob, queues, and tables)
• On-premises (using Service Bus)

By combining different triggers and outputs, you can easily create a range of possible functions, as we see in the following diagram:

Figure 7.6 – Combining triggers and outputs with a Functions app

Azure Functions is therefore well suited to event-based microservice applications that are short-run and are not continuously activated. As with App Service, Functions supports a range of languages, including C#, F#, JavaScript, Python, and PowerShell Core.

By default, all traffic in Azure follows pre-defined routes that are set up within the VNETs. These routes ensure traffic flows correctly between VNETs and out to the internet as required.

When more advanced routing is required, you can set up your routes to force the traffic through set paths, sometimes known as service chaining.

An example is where you need to route your Azure VM traffic back on-premises for your internal ranges. In this instance, you could create a route that sends all traffic destined for your internal ranges to the VPN gateway in your hub VNET.

Another example would be when you wish to have all internet traffic traverse a central firewall; in this instance, you would define a route to send all internet traffic to a firewall device you have in a peered VNET.

When creating routes, you can create either user-defined routes or Border Gateway Protocol (BGP).

BGP automatically exchanges routing information between two or more networks. In Azure, it can be used to advertise routes from your on-premises network to Azure when using ExpressRoute or a site-to-site VPN.

Alternatively, you can create your custom route; although this is more manual and has a higher administrative overhead, it does provide complete control.

When defining a user-defined route, we set a descriptive name, an address prefix that specifies the address range that we will redirect traffic for, and the next hop. The next hop is where traffic will be routed through and can be any of the following:

• Virtual appliance: Such as a firewall or other routing device
• VNET gateway: Used when directing traffic through a VPN gateway
• VNET: Sends all traffic to a specific VNET
• Internet: Sends traffic to Azure internet routers
• None: Drops all data (that is, blocks all traffic for that range)

For example, if we want to route all traffic through a firewall device with the address of 10.0.0.10, we would create the following custom route:

Figure 8.15 – Example user-defined route

We can also add additional routes for other rules; for example, routing traffic through the firewall, we could add another rule to route internal bound traffic to a VPN gateway.

Because we can have a mixture of custom routes, system routes, and BGP routes, Azure uses the following order to decide where to send traffic in the event there is a conflict. That order is as follows:

1. User-defined routes
2. BGP routes
3. System routes

By using a combination, we can precisely control traffic depending on our precise requirements.

Another aspect of routing traffic is when we need to use load balancing components to share traffic between one or more services, and we will discuss this in the next section.

To connect to an Azure VPN gateway, you will need a VPN device on your corporate network that supports policy-based or route-based VPN gateways. It also needs to have a public IPv4 network address.

Azure resources

Within Azure, you need to set up the following components:

• VNET: The address space used by the VNET must not overlap with your corporate ranges.
• Gateway subnet: The VPN gateway must be installed in a specific subnet, and it must be called GatewaySubnet. It must have a range of at least /27 (32 addresses).
• Public IP address: An IP address that can be connected to from the public network (internet).
• Local network gateway: This defines the on-premises gateway and configuration.
• VNET gateway: An Azure VPN or ExpressRoute gateway.

The following diagram shows how this might look:

Figure 8.12 – VPN gateway

As we can see from the preceding diagram, a VPN connection is made to a specific subnet and VNET within Azure. In most cases, you would need to connect multiple VNETs to the same connection, which we can perform by peering the connected VNET to your workload VNETs.

This is often called a hub-spoke model; we can see an example hub-spoke model in the following diagram:

Figure 8.13 – Hub-spoke architecture

Earlier, we stated that connections between VNETs are not transitive, therefore to set up the hub-spoke architecture, we must use a gateway transit – we do this when we create our peering connection between the spoke VNET (which contains our workloads) and the hub VNET (which includes the VNET gateway). On the options when creating a peering request from the spoke to the hub, select the Use the remote virtual network’s gateway option, as we can see in the following example:

Figure 8.14 – Setting the peering option to use gateway transit

Using a VPN is a simple way to connect securely to Azure. However, you are still using the public network; thus, connectivity and performance cannot be guaranteed. For a more robust and direct connection into Azure, companies can leverage ExpressRoute.

ExpressRoute

ExpressRoute provides a dedicated and utterly private connection into Azure, Office 365, and Dynamics 365. Throughput is significantly increased since connections are more reliable with minimal latency.

Connectivity is via authorized network providers who ensure connections are highly available; this means you get redundancy built-in.

There are three different models to choose from when ordering an ExpressRoute – CloudExchange co-location, point-to-point Ethernet connection, and any-to-any connection:

• CloudExchange co-location is for companies that house their existing data center with an internet service provider.
• Point-to-point connections are dedicated connections between your premises and Azure.
• Any-to-any is for companies that have existing WAN infrastructure. Microsoft can connect to that existing network to provide connectivity from any of your offices.

A key aspect of ExpressRoute is that your connectivity is via private routes; it does not traverse the public internet – except for Content Delivery Network (CDN) components, which by design must leverage the internet to function.

As you leverage more advanced network options, you must have tighter control over traffic flow between VNETs and your on-premises network.

An ASG is another way of grouping together resources instead of just allowing all traffic to all resources on your VNET. For example, you may want one to define a single NSG that applies to all subnets; however, you may have a mixture of services, such as database servers and web servers, across those subnets.

You can define an ASG and attach your web servers to that ASG, and another ASG that groups your database servers. In your NSG, you then set the HTTPS inbound rule to use the ASG as the destination rather than the whole subnet, VNET, or individual IPs. In this configuration, even though you have a common NSG, you can still uniquely allow access to specific server groups.

The following diagram shows an example of this type of configuration:

Figure 8.6 – Example architecture using NSGs and ASGs

In the preceding example, App1 and App2 are part of the ASGApps ASG, and Db1 and Db2 are part of the ASGDb ASG.

The NSG rulesets would then be as follows:

With the preceding in place, HTTPS inbound would only be allowed to App1 and App2, and port 1433 would only be allowed from App1 and App2.

ASGs and NSGs are great for discrete services; however, there are some rules that you may always want to apply, for example, blocking all outbound access to certain services such as FTP. A better option might be to create a central firewall that all your services route through in this scenario.

Azure Firewall

Whereas individual NSGs and ASGs form part of your security strategy, building multiple network security layers, especially in enterprise systems, is even better.

Azure Firewall is a cloud-based, fully managed network security appliance that would typically be placed at the edge of your network. This means that you would not usually have one firewall per solution or even subscription. Instead, you would have one per region and have all other devices, even those in different subscriptions, route through to it, as in the following example:

Figure 8.7 – Azure Firewall in a hub/spoke model

Azure Firewall offers some of the functionality you can achieve from NSGs, such as network traffic filtering based on port and IP or service tags. Over and above these basic services, Azure Firewall also offers the following:

• High availability and scalability: As a managed offering, you don’t need to worry about building multiple VMs with load balancers or how much your peak traffic might be. Azure Firewall will automatically scale as required, is fully resilient, and supports availability zones.
• FQDN tags and FQDN filters: As well as IP, addressing, and service tags, Azure Firewall also allows you to define FQDNs. FQDN tags are similar to service tags but support a more comprehensive range of services, such as Windows Update.
• Outgoing SNAT and inbound DNAT support: If you use public IP address ranges for private networks, Azure Firewall can perform Secure Network Address Translation (SNAT) on your outgoing requests. Incoming traffic can be translated using Destination Network Address Translation (DNAT).
• Threat intelligence: Azure Firewall can automatically block incoming traffic originating from IP addresses known to be malicious. These addresses and domains come from Microsoft’s threat intelligence feed.
• Multiple IPs: Up to 250 IP addresses can be associated with your firewall, which helps with SNAT and DNAT.
• Monitoring: Azure Firewall is fully integrated with Azure Monitor for data analysis and alerting.
• Forced tunneling: You can route all internet-bound traffic to another device, such as an on-premises edge firewall.

Azure Firewall provides an additional and centralized security boundary to your systems, ensuring an extra layer of safety.

So far, we have looked at securing access into and between services that use VNETs, such as VMs. Some services don’t use VNETs directly but instead have their firewall options. These firewall options often include the ability to either block access to the service based on IPs or VNETs, and when this option is selected, it uses a feature called service endpoints.

NSGs allow you to define inbound and outbound rules that will allow or deny the flow of traffic from a source to a destination on a specific port. Although you define separate inbound and outbound rules, each rule is stateful. This means that the flow in any one direction is recorded so that the returning traffic can also be allowed using the same rule.

In other words, if you allow HTTPS traffic into a service, then that same traffic will be allowed back out for the same source and destination.

We create NSGs as components in Azure and then attach them to a subnet or network interface on a VM. Each subnet can only be connected to a single NSG, but any NSG can be attached to multiple subnets. This allows us to define rulesets independently for everyday use cases (such as allowing web traffic) and then reusing them across various subnets.

When NSGs are created, Azure applies several default rules that effectively block all access except essential Azure services.

If you create a VM in Azure, a default NSG is created for you and attached to the network interface of the VM; we can see such an example in the following screenshot:

Figure 8.5 – Example NSG ruleset

In the preceding figure, we can see five inbound rules and three outbound. The top two inbound rules highlighted in red were created with the VM – in the example, we specified to allow RDP (3389) and HTTP (80).

The three rules in the inbound and outbound highlighted in green are created by Azure and cannot be removed or altered. These define a baseline set of rules that must be applied for the platform to function correctly while blocking everything else. As the name suggests on these rules, AllowVnetInBound allows traffic to flow freely between all devices in that VNET, and the AllowAzureLoadBalancerInBound rule allows any traffic originating from an Azure load balancer. DenyAllInBound blocks everything else.

Each rule requires a set of options to be provided:

• Name and Description: For reference; these have no bearing on the actual service. They make it easier to determine what it is or what it is for.
• Source and Destination port: The port is, of course, the network port that a particular service communicates on – for RDP, this is 3389; for HTTP, it is 80, and for HTTPS, it is 443. Some services require port mapping; that is, the source may expect to communicate on one port, but the actual service communicates on a different port.
• Source and Destination location: The source and destination locations define where traffic is coming from (the source) and where it is trying to go to (the destination). The most common option is an IP address or list of IP addresses, and these will typically be used to define external services.

For Azure services, we can either choose the VNET – that is, the destination is any service on the VNET the NSG is attached to – or a service tag, which is a range of IPs managed by Azure. Examples may include the following:

– Internet: Any address that doesn’t originate from the Azure platform

– AzureLoadBalancer: An Azure load balancer

– AzureActiveDirectory: Communications from the Azure Active Directory service

– AzureCloud.EastUS: Any Azure service in the East US region

As we can see from these examples, with the exception of the internet option, they are IP sets that belong to Azure services. Using service tags to allow traffic from Azure services is safer than manually entering the IP ranges (which Microsoft publishes) as you don’t need to worry about them changing.

• Protocol: Any, TCP, UDP, or ICMP. Services use different protocols, and some services require TCP and UDP. You should always define the least access; so, if only TCP is needed, only choose TCP. ICMP protocol is used primarily for Ping.
• Priority: Firewall rules are applied one at a time in order, with the lowest number, which is 100, being used last. Azure applies a Deny All rule to all NSGs with the lowest priority. Therefore, any rule with a higher priority will overrule this one. Deny all is a failsafe rule – this means everything will be blocked by default unless you specifically create a rule to allow access.

Through the use of NSGs, we can create simple rules around our VNET-integrated services and form part of an effective defense strategy. There may be occasions, however, when you want to apply different firewall rules to other components within the same subnet; we can use Application Security Groups (ASGs) for these scenarios.

If you own your domain, bigcorp.com, you can create a zone in Azure and then configure your domain to use the Azure name servers. Once set up, you can then use Azure to create, edit, and maintain the records for that domain.

You cannot purchase domain names through Azure DNS, and Azure does not become the registrar. However, using Azure DNS to manage your domain, you can use RBAC roles to control which users can manage DNS, Azure logs to track change, and resource locking to prevent the accidental deletion of records.

We have looked at the different options for setting up VNETs with IP addressing and name resolution; we will now investigate to ensure secure communications to and between our services.

Implementing network security

Ensuring secure traffic flow to and between services is a core requirement for many solutions. An example is an external communication to a VM running a website – you may only want to allow traffic to the server in a particular port such as HTTPS over port 443. All other traffic, such as SMTP, FTP, or file share protocols, need to be blocked.

It isn’t just inbound traffic that needs to be controlled; blocking outbound traffic can be just as important. For many organizations today, ensuring you are protected from insider threats is just as crucial, if not more so, than external threats. For this reason, we may want to block all but specific outbound access so that if a service is infected by malware, it cannot send traffic out – known as data exfiltration.

Important Note

Data exfiltration is a growing technique for stealing data. Either by manually logging on to a server or through malware infection, data is copied from an internal system to an external system.

As solutions become more distributed, the ability to control data between components has also become a key design element and can often work to our advantage. A typical and well-used architectural pattern is an n-tier architecture. The services in a solution are hosted on different layers – a User Interface (UI) at the front, a data processing tier in the middle, and a database at the back. Each tier could be hosted on its subnet with security controls between them. In this way, we can tightly control who and what has access to each tier individually, which helps prevent any attacker from gaining direct access to the data, as we can see in the following example:

Figure 8.4 – N-tier architecture helps protect resources

In the example, in the preceding figure, the UI tier only allows traffic from the user over HTTP (port 443), and as the UI only contains frontend logic and no data, should an attacker compromise the service, they can only access that code.

The next tier only allows traffic from the UI tier; in other words, an external attacker has no direct access. If the frontend tier was compromised, an attacker could access the business logic tier, but this doesn’t contain any actual data.

The final tier only accepts SQL traffic (port 1433) from the business tier; therefore, a hacker would need to get past the first two tiers to gain access to it.

Of course, other security mechanisms such as authentication and authorization would be employed over these systems, but access by the network is often considered the first line of defense.

Firewalls are often employed to provide security at the network level. Although Azure provides discrete firewall services, another option is often used to provide simpler management and security – Network Security Groups (NSGs).

Once we have our resources built in Azure, we need to resolve names with IP addresses to communicate with them. By default, services in Azure use Azure-managed DNS servers. Azure-managed DNS provides name resolution for your Azure resources and doesn’t require any specific configuration from you.

Azure-managed DNS servers

Azure-managed DNS is highly available and fully resilient. VMs built in Azure can use Azure-managed DNS to communicate with other Azure services or other VMs in your VNETs without the need for a Fully Qualified Domain Name (FQDN).

However, this name resolution only works for Azure services; if you wish to communicate with on-premises servers or need more control over DNS, you must build and integrate with your DNS servers.

When configuring a VNET in Azure, you can override the default DNS servers. In this way, you can define your DNS servers to ensure queries to your on-premises resources are resolved correctly. You can also enter the Azure-managed DNS servers as well; if your DNS solution cannot resolve a query, the service would then fall back to the alternate Azure DNS service. The address for the Azure DNS service is 168.63.129.16.

To change the default DNS servers in Azure, perform the following steps:

1. Navigate to the Azure portal at https://portal.azure.com.
2. In the search bar, search for and select Virtual Networks.
3. Select your VNET.
4. On the left-hand menu, select DNS servers.
5. Change the default option from Default (Azure-provided) to Custom.
6. Enter your DNS servers, optionally followed by the Azure internal DNS server address.

The following screenshot shows an example of how this might look:

Figure 8.3 – Setting up custom DNS servers

These settings must be set up on each VNET that you wish to set up the custom DNS settings.

Tip

Be careful how many DNS servers you set. Each DNS server will be queried in turn, and if you put too many, the request will time out before it reaches the final server. This can cause issues if you need to fall back to the Azure DNS service for Azure-hosted services.

You can also leverage Azure private DNS, using private zones, for your internal DNS needs, using your custom domain names.

Azure private DNS zones

Using custom DNS allows you to use your domains with your Azure resources without the need to set up and maintain your DNS servers for resolution.

This option can provide much tighter integration with your Azure-hosted resources as it allows automatic record updates and DNS resolution between VNETs. As a managed solution, it is also resilient without maintaining separate VMs to run the DNS server.

Azure also provides you with the ability to manage your external domain records. Using Azure DNS zones, you can delegate the name resolution for your custom domain to Azure’s DNS servers.

Private zones are also used with PrivateLink IP services, which we will examine in the next section, Implementing network security.

A public IP address is a discrete component that can be created and attached to many services, such as VMs. The public IP component is dedicated to a resource until you un-assign it – in other words, you cannot use the same public IP across multiple resources.

Public IP addresses can be either static or dynamic. With a static IP, once the resource has been created, the assigned IP address it is given stays the same until that resource is deleted. A dynamic address can change in specific scenarios. For example, if you create a public IP address for a VM as a dynamic address, when you stop the VM, the address is released and is different when assigned once you start the VM up again. With static addresses, the IP is assigned once you attached it to the VM, and it stays until you manually remove it.

Static addresses are useful if you have a firewall device that controls access to the service that can only be configured to use IP addresses or DNS resolution as changing the IP would mean the DNS record would also need updating. You also need to use a static address if you use TLS/SSL certificates linked to IP addresses.

Private IP addresses

Private IP addresses can be assigned to various Azure components, such as VMs, network load balancers, or application gateways. The devices are connected to a VNET, and the IP range you wish to use for your resources is defined at the VNET level.

When creating VNETs, you assign an IP range; the default is 10.0.0.0/16 – which provides 65,536 possible IP addresses. VNETs can contain multiple ranges if you wish; however, you need to be careful that those ranges do not interfere with public addresses.

When assigning IP ranges, you denote the range using CIDR notation – a forward slash (/) followed by a number that defines the number of addresses within that range. The following are just some example ranges:

Tip

CIDR notation is a more compact way to state an IP address and it’s ranged based on a subnet mask. The number after the slash (/) is the count of leading 1 bits in the network mask. The complete range of addresses can be found here: https://bretthargreaves.com/ip-cheatsheet/.

For more in-depth details of CIDR, see https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing.

Subnets are then created within the VNET, and each subnet must also be assigned an IP range that is within the range defined at the VNET level, as we can see in the following example diagram:

Figure 8.2 – Subnets within VNETs

For every subnet you create, Azure reserves five IPs for internal use – for smaller subnets, this has a significant impact on the number of available addresses. The reservations within a given range are as follows:

With these reservations in mind, the minimum size of a subnet in Azure is a /29 network with eight IPs, of which only three are useable. The largest allowable range is /8, giving 16,777,216 IPs with 16,777,211 usable.

Private ranges in Azure can be used purely for services within your Azure subscriptions. If you don’t connect the VNETs or require communications between them, you can have more than one VNET with the same ranges.

If you plan to allow services within one VNET to communicate with another VNET, you must consider more carefully the ranges you assign to ensure they do not overlap. This is especially crucial if you use VNETs to extend your private corporate network into Azure, as creating ranges that overlap can cause routing and addressing problems.

As with public IPs, private IPs can also be static or dynamic. With dynamic addressing, Azure assigns the next available IP within the given range. For example, if you are using a 10.0.0.0 network, and 10.0.0.3–10.0.0.20 are already used, your new resource will be assigned 10.0.0.21.

We looked at containerization, and specifically with Docker (Azure’s default container engine), in the previous section. Now we have container images registered in Azure Container Registry, and from there, we can then use those images to spin up instances or running containers.

Two questions may spring to mind – the first is what now? Or perhaps more broadly, why bother? In theory, we could achieve some of what’s in the container with a simple virtual machine image.

Of course, one reason for containerization is that of portability – that is, we can run those images on any platform that runs Docker. However, the other main reason is it now allows us to run many more of those instances on the same underlying hardware because we can have greater density through the shared OS.

This fact, in turn, allows us to create software using a pattern known as microservices.

Traditionally, a software service may have been built as monolithic – that is, the software is just one big code base that runs on a server. The problem with this pattern is that it can be quite hard to scale – that is, if you need more power, you can only go so far as adding more RAM and CPU.

The first answer to this issue was to build applications that could be duplicated across multiple servers and then have requests load balanced between them – and in fact, this is still a pervasive pattern.

As software started to be developed in a more modular fashion, those individual modules would be broken up and run as separate services, each being responsible for a particular aspect of the system. For example, we might split off a product ordering component as an individual service that gets called by other parts of the system, and this service could run on its own server.

While we can quickly achieve this by running it on its virtual server, the additional memory overhead means as we break our system into more and more individual services, this memory overhead increases, and we soon run very efficiently from a resource usage point of view.

And here is where containers come in. Because they offer isolation without running a full OS each time, we can run our processes far more efficiently – that is, we can run far more on the same hardware than we could on standard virtual machines.

By this point, you might now be asking how do we manage all this? What controls the spinning up of new containers or shutting them down? And the answer is orchestration. Container orchestrators monitor containers and add additional instances in response to usage thresholds or even for resiliency if a running container becomes unhealthy for any reason. Kubernetes is an orchestration service for managing containers.

A Kubernetes cluster consists of worker machines, called nodes, that run containerized applications, and every cluster has at least one worker node. The worker node(s) host pods that are the application’s components, and a control plane or cluster master manages the worker nodes and the pods in the cluster. We can see a logical overview of a typical Kubernetes cluster, with all its components, in the following diagram:

Figure 7.11 – Kubernetes control plane and components

AKS is Microsoft’s implementation of a managed Kubernetes cluster. When you create an AKS cluster, a cluster master is automatically created and configured; there is no cost for the cluster master, only the nodes that are part of the AKS cluster.

The cluster master includes the following Kubernetes components:

• kube-apiserver: The API server exposes the Kubernetes management services and provides access for management tools such as the kubectl command, which is used to manage the service.
• etcd: A highly available key-value store that records the state of your cluster.
• kube-scheduler: Manages the nodes and what workloads to run on them.
• kube-controller-manager: Manages a set of smaller controllers that perform pod and node operations.

You define the nodes’ number and size, and the Azure platform configures secure communication between the cluster master and nodes.

For this example, you will need a Windows VM set up in your subscription:

1. Navigate to the Azure portal at https://portal.azure.com.
2. In the search bar, type and select Virtual Machines and select the virtual machine you wish to apply Update Management to.
3. On the left-hand menu, click Guest + host updates under Operations.
4. Click the Go to Update Management button.
5. Complete the following details:
   a) Log Analytics workspace Location: The location of your VM, for example, East US
   b) Log Analytics workspace: Create default workspace
   c) Automation account subscription: Your subscription
   d) Automation account: Create a default account
6. Click Enable.

The process can take around 15 minutes once completed. Go back to the VM view and again select Guest + host updates under Operations, followed by Go to Update Management.

You will see a view similar to the following screenshot:

Figure 7.8 – Update Management blade

You can get to the same view but for all the VMs you wish to manage in the portal by searching for Automation Accounts and selecting the automation account that has been created. Then click Update management.

If you want to add more VMs, click the + Add Azure VMs button to see a list of VMs in your subscription and enable the agent on multiple machines simultaneously – as we see in the following screenshot:

Figure 7.9 – Adding more virtual machines for Update Management

The final step is to schedule the installation of patches:

1. Navigate to the Azure portal by opening https://portal.azure.com.
2. Type Automation into the search bar and select Automation Accounts.
3. Select the automation account.
4. Click Update Management.
5. Click Schedule deployment and complete the details as follows:
   a) Name: Patch Tuesday
   b) Operating System: Windows
   c) Maintenance Window (minutes): 120
   d) RebootReboot options:Reboot if required
6. Under Groups to update, click Click to Configure.
7. Select your subscription and Select All under Resource Groups.
8. Click Add, then OK.
9. Click Schedule Settings.
10. Set the following details:
    a) Start date: First Tuesday of the month
    b) Recurrence: Recurring
    c) Recur Every: 14 days
11. Click OK.
12. Click Create.

Through the Update Management feature, you can control how your virtual machines are patched and when and what updates to include or exclude. You can also set multiple schedules and group servers by resource group, location, or tag.

In the preceding example, we selected all VMs in our subscription, but as you saw, we had the option to choose a machine based on location, subscription, resource group, or tags.

In this way, you can create separate groups for a variety of purposes. For example, we mentioned earlier that a common practice would be to test patches before applying them to production servers. We can accommodate this by grouping non-production servers into a separate subscription, resource group, or simply tagging them. You can then create one patch group for your test machines, followed by another for production machines a week later – after you’ve had time to confirm the patches have not adversely affected workloads.

As part of any solution design that utilizes VMs, accommodation must be included to ensure they are always running healthily and securely, and Update Management is a critical part of this. As we have seen, Azure makes the task of managing OS updates easy and straightforward to set up.

Next, we will investigate another form of compute that is becoming increasingly popular – containerization and Kubernetes.