Azure

Joe Carlyle

What is – Azure Firewall Policy Analytics

Ever since the change to Azure Firewall Policy from classic rules, there has been a requirement and a want to have greater inspection capabilities with regard to your Azure Firewall Policies (AFPs). Depending on your environment, you might have several, or several hundred AFPs in place, securing your Azure footprint. Regardless, analytics of these policies is crucial.

With the increasing adoption of cloud workloads, and as workloads move to the cloud, network security policies like AFPs must evolve and adapt to the changing demands of the infrastructure, which can be updated multiple times a week, which can make it challenging for IT security teams to optimise rules.

Optimisation while at least retaining, if not increasing security, is key objective with AFP Analytics. As the number of network and application rules grow over time, they can become suboptimal, resulting in degraded firewall performance and security. Any update to policies can be risky and potentially impact production workloads, causing outages, unknown impact and ultimately – downtime. We’d like to avoid all of that if possible!

AFP Analytics offers the ability to analyse and inspect your traffic, right down to a single rule. Several elements are enabled without action, however, I would recommend enabling the full feature set, which is a simple task. Open the AFP you’d like to enable it for, and follow the steps linked here.

Once enabled, AFP Analytics starts to fully inspect your Policy and the traffic passing through it. My demo Azure Firewall, currently looks fantastic, as nothing is happening 🙂

AFP Analytics blade in Azure Portal

There are several key features to make use of with AFP Analytics, Microsoft list them as follows:

  • Policy insight panel: Aggregates insights and highlights relevant policy information. (this is the graphic above)
  • Rule analytics: Analyses existing DNAT, Network, and Application rules to identify rules with low utilization or rules with low usage in a specific time window.
  • Traffic flow analysis: Maps traffic flow to rules by identifying top traffic flows and enabling an integrated experience.
  • Single Rule analysis: Analyzes a single rule to learn what traffic hits that rule to refine the access it provides and improve the overall security posture.

Now I view all of these as useful. I can see the purpose and I can see myself using them regularly. However, I was most excited about – Single Rule Analysis – that was, until I went to test and demo it.

I created a straight forward Application rule, a couple of web categories allowed on HTTPS. I enabled Analytics, sat back for a bit, got a coffee (it recommends 60 minutes due to how logs are aggregated in the back end) and then tried it out. To my disappointment, I was met with the below:

Tags and categories I could initially understand, but IP Groups confused me. I thought, this is a core feature, why not allow analysis when this is in scope – then I realised; the analysis is aiming to optimise the rule. AFP views rules using these as fairly spot on already. So, I decide to create a stupid rule (in my opinion). Allowing TCP:443 from around 20 IPs to around 10 IPs. First up, my Insight Panel flagged it

Next, Single Rule Analysis and…success, it dislikes the rule! It summarises it, and flags the aspects it does not feel are optimal. I did expect the recommendation to be to delete the rule, as you can see it is flagging there is no traffic matching the rule, but perhaps the caution here is in combination with the rule and data in place for the last 30 days, or lack thereof.

I can see this feature being really powerful in a busy production environment. There are some more scenarios listed on Microsoft’s blog announcement of GA earlier in the year too, if you’d like to check them out.

A final note. While you might think that it’s only the Log Analytics element you have to pay for to make use of AFP Analytics, you would be wrong. There is a charge for the enablement, analysis, and insight components. These price in at around €225/month, billed hourly. So double check your budget before enabling on every AFP.

As always, if you have any questions, please just ping me!

Joe Carlyle

Can Azure OpenAI Write This Blog Post?

This is the fear right? Or maybe it’s not a fear, and is a desire for some people, but it’s still not clear what the impact may be. What am I talking about? AI of course; specifically for this post, Azure OpenAI. Now, my idea here is to see what I think of the quality of responses it can give me based on specific prompts to try and tie together a simple blog post. I will pick a topic, an objective for the post, and I will be 100% transparent on what is AI written and what is me – just in case it is not obvious! I will also include the settings being used for my model at the end and whether I adjusted them during.

Ok, let’s get started. My topic is going to be Virtual Network Manager in my usual style of exploration.

What is Azure Virtual Network Manager? Write an opening paragraph for a blog post.

Azure Virtual Network Manager is an essential tool for managing and organizing your cloud-based virtual networks. With virtual networks, you can securely connect and isolate your Azure resources, control traffic flow, and expand your on-premises network into the cloud. However, managing virtual networks can be a challenging task, especially when you have multiple resources and services scattered across different regions. This is where the Azure Virtual Network Manager comes in, offering a centralized and user-friendly interface to help you efficiently manage and monitor your virtual networks. In this blog post, we will take a closer look at the Azure Virtual Network Manager and explore its features and benefits.

What are the top three use cases for Azure Virtual Network Manager? Write a detailed paragraph including bullet points and examples for each.

Azure Virtual Network Manager is a versatile tool that can support various use cases, depending on your organization’s needs. Here are the top three use cases for Azure Virtual Network Manager:

  1. Hybrid Cloud Connectivity: Azure Virtual Network Manager can help organizations establish secure, high-speed connections between their on-premises datacenters and Azure resources. This allows companies to take advantage of the scalability and flexibility of the cloud while maintaining the security and control of their own infrastructure. With Azure Virtual Network Manager, organizations can easily configure VPN gateways, express routes, and other connectivity options to seamlessly integrate their on-premises networks with Azure.

    Examples:
  • Connecting an on-premises Active Directory to Azure to manage identity and access for cloud resources.
  • Extending a corporate LAN to Azure to host applications and services in the cloud.
  • Using Azure as a backup and disaster recovery site for on-premises datacenters.
  1. Multi-Tier Application Architecture: Azure Virtual Network Manager enables organizations to create complex multi-tier application architectures in the cloud, with the ability to isolate and secure different layers of the application. This is done by creating multiple virtual networks, each with its own subnets and security groups. This approach provides better control over network traffic and reduces the risk of security breaches by limiting the attack surface.

    Examples:
  • Hosting a web application in Azure with a separate virtual network for the web server, application server, and database server.
  • Creating a DMZ in Azure to host public-facing services, with a separate virtual network for internal services.
  • Separating development, testing, and production environments into different virtual networks to ensure isolation and security.
  1. Global Network Management: Azure Virtual Network Manager provides a centralized interface to manage virtual networks across different regions and subscriptions. This allows organizations to monitor network traffic, troubleshoot connectivity issues, and optimize network performance from a single location. With Azure Virtual Network Manager, organizations can also implement advanced networking features, such as traffic routing, load balancing, and network security groups.

    Examples:
  • Creating a global load-balancing solution to distribute traffic across multiple regions and availability zones.
  • Implementing Azure Firewall to provide centralized network security management across multiple virtual networks.
  • Enabling Azure Traffic Manager to route traffic to the nearest endpoint based on geographic location or network latency.

What are the current limitations or known issues of Azure Virtual Network Manager? Write a paragraph in the blog post.

While Azure Virtual Network Manager is a powerful tool for managing virtual networks in the cloud, there are some limitations and known issues that organizations should be aware of. Some of the current limitations of Azure Virtual Network Manager include:

  • Limited support for hybrid networking configurations: Currently, Azure Virtual Network Manager has limited support for hybrid networking configurations, which can make it challenging to manage virtual networks that span multiple cloud providers or on-premises datacenters.
  • Limited visibility into network traffic: Azure Virtual Network Manager provides limited visibility into network traffic, which can make it difficult to troubleshoot connectivity issues or monitor network performance.
  • Limited integration with third-party tools: Azure Virtual Network Manager has limited integration with third-party tools, which can make it challenging to implement advanced networking features or security solutions.

    Organizations should carefully evaluate their networking needs and consider these limitations before deploying Azure Virtual Network Manager. However, Microsoft is continually improving the tool and addressing these limitations through updates and new features.

Is there a tutorial or general steps that should be recommended as part of this blog post for people who are interested in now trying Azure Virtual Network Manager? Include high level steps and a link to the appropriate site if possible

Yes, Microsoft offers a comprehensive tutorial on how to set up and manage virtual networks using Azure Virtual Network Manager. Here are the high-level steps for getting started with Azure Virtual Network Manager:

  1. Create a virtual network: The first step is to create a virtual network in Azure. This involves specifying the name, address space, and subnets for your network. You can also configure advanced network settings, such as DNS servers and network security groups.
  2. Create a gateway subnet: If you plan to connect your virtual network to an on-premises network, you need to create a gateway subnet. This subnet is used to deploy a VPN gateway or an ExpressRoute gateway.
  3. Configure VPN or ExpressRoute: Once you have created your virtual network and gateway subnet, you can configure a VPN or ExpressRoute connection to connect your on-premises network to Azure.
  4. Set up network security: Azure Virtual Network Manager provides several tools for securing your virtual network, including network security groups, application security groups, and Azure Firewall. You can use these tools to control inbound and outbound traffic, restrict access to specific resources, and monitor network activity.
  5. Monitor and troubleshoot your network: Azure Virtual Network Manager provides several tools for monitoring and troubleshooting your virtual network, including network performance monitoring, packet capture, and network watcher.

    For more detailed instructions on how to use Azure Virtual Network Manager, check out the official Microsoft tutorial: https://docs.microsoft.com/en-us/azure/virtual-network/tutorial-create-virtual-network.

Based on your previous responses do you think there is anything else that is important to know about Virtual Network Manager? Write a closing paragraph with a call to action to get in touch if you have any questions

In conclusion, Azure Virtual Network Manager is a powerful tool that can help organizations manage and secure their virtual networks in the cloud. With Azure Virtual Network Manager, organizations can establish secure connections between their on-premises and cloud-based resources, create complex multi-tier application architectures, and manage virtual networks across different regions and subscriptions. While there are some limitations and known issues with the tool, Microsoft is continually improving it with updates and new features.

If you have any questions about how to use Azure Virtual Network Manager or want to learn more about how it can support your organization’s networking needs, don’t hesitate to get in touch. Our team of experts is always available to help you navigate the complexities of cloud networking and find the best solutions for your business.

Let’s start with the settings used, I started with these and didn’t change them at all during the process:

engine="35t", (gpt35-turbo)
temperature=0.8,
max_tokens=800,
top_p=0.95,
frequency_penalty=0,
presence_penalty=0

Overall, I think it has the basics nearly correct. However, it has very little personalisation, it obviously speak to no real experience, and is essentially a modified read of the Docs pages. So I am pretty confident that at no point in near future could it be used to write an entire post that I would be happy with publishing. However, where a post calls for something more generic, like known issues, or intros, it could definitely be used as a starting point.

I am interest to see if a GPT4 model would make a huge difference, but for this style of work, I am not sure. Also, I could of course edit the temperature or top p, but I am unsure as to whether that impact again would be noticeable enough.

In conclusion, Azure OpenAI can definitely write a blog post – I am just not sure it’s a blog post I would be happy with!

Joe Carlyle

Azure Networking BCDR – Azure Back to School 2023

Introduction

We are now several days into another year of Azure Back to School, I hope you’ve enjoyed the content so far as much as I have, and thanks again to the team for organising and having me back for another year, I can’t wait for the rest of the month. Check it all out over at – https://azurebacktoschool.github.io/

This year, I’m going to take a look at some of the challenges that BCDR (Business Continuity and Disaster Recovery) can pose to Azure Networking. This is something I have seen pop up quite a lot recently, as companies move to solidify their footprint, close gaps, and make use of all Azure has to offer to “keep the lights on”.

High-Level Architecture

As with many of my articles like this, it is important to call out the scope of the discussion. Azure is a vast platform, and I will be the first to say that every environment is unique. As such, this doesn’t aim to be an exhaustive, several thousand word long piece covering every scenario. For the sake of discussion, it will focus on these core network services – Virtual Network, Virtual Network Gateway, Azure Firewall, Network Security Group, Route Table, and Public IP.

Core BCDR Components

In a similar introductory fashion, it is also important to highlight the Azure BCDR relevant concepts that are included in discussion. Essentially an understanding of what an Azure region is, and what Availability Zones are will cover you here.

Network arch and scenario to cover outage

OK, so let’s look at a typical production network setup in Azure. Heading over to the Azure Architecture Center, we can find some excellent materials and guides, however, we’re going to focus on this one – Hub-Spoke

Azure Hub-Spoke architecture diagram

As you can see from the diagram, this visually includes several services I have mentioned, some secondary, like Public IP addresses, are not there explicitly, but we all know that Bastion, Firewall and VPN Gateway require one.

Network Services Alignment

So let’s look at where these services align to core Azure BCDR requirements. One thing to note here is that Azure divides its services up into different categories based on their regional availability by design:

  • Foundational – Available in all recommended and alternate regions when a region is generally available, or within 90 days of a new foundational service becoming generally available.
  • Mainstream – Available in all recommended regions within 90 days of a region’s general availability. Mainstream services are demand-driven in alternate regions, and many are already deployed into a large subset of alternate regions.
  • Strategic – Targeted service offerings, often industry-focused or backed by customized hardware. Strategic services are demand-driven for availability across regions, and many are already deployed into a large subset of recommended regions

It also then divides how Azure services support Availability Zones:

  • Zonal – A resource can be deployed to a specific, self-selected availability zone to achieve more stringent latency or performance requirements. Resiliency is self-architected by replicating applications and data to one or more zones within the region. Resources are aligned to a selected zone.
  • Zone-Redundant – Resources are replicated or distributed across zones automatically. Think ZRS Storage Account as an example.
  • Always-Available – Always available across all Azure geographies and are resilient to zone-wide outages and region-wide outages. 

Finally, before we get to our specific services, remember that not all Azure regions are equal. Some have all services, some don’t. Some support Availability Zones, some don’t. Make sure you are confirming your requirements against your proposed region – every time – as updates happen quickly!

Ok, so onto our specific network services and how they align:

  • Virtual Network – Foundational & Zone-Redundant
  • Virtual Network Gateway – Foundational & Zone-Redundant*
  • Azure Firewall – Mainstream & Zonal & Zone-Redundant*
  • Network Security Group – Foundational & Zone-Redundant
  • Route Table – Foundational & Zone-Redundant
  • Public IP – Foundational & Zonal & Zone-Redundant*

*SKU dependent, not all SKUs have the same feature set.

First thing that you should notice, is that all of these Networking services have really strong coverage for BCDR. However, not one of them is regionally resilient. That means regardless of our in-region, zonal design, we may need additional regional configuration and deployment, depending on your requirements.

Let’s look at within a single region first, using our same example deployment architecture. Within a fully supported region, (remember, always check!) such as North Europe, we can deploy the entire architecture to be zone-redundant. This means that should an entire zone be lost, our network services will stay active. This is the equivalent of a 99.99% SLA in Azure terms. Obviously this requires some small tweaks during deployment to achieve, and a slight uptick in cost due to SKU requirements, but this is honestly an excellent baseline to work from.

Challenges

One challenge here, I am not aware of a service that allows you to modify zonal deployment/configuration after deployment. You must do it at deployment. This means if you’re approaching an existing environment with this in mind, you might have quite a few maintenance windows and rebuilds etc. Bicep is your friend here for testing and deployment.

Obviously we then have the regional challenge. And by challenge, I guess that ultimately means if you need your services, should a region go down, how do you deal with that in advance? When it comes to networking in Azure, there is no replication service, or tick box to make it multi-region. Why not you ask? That’s for a different post, but let’s look at what is needed.

Generally you would deploy several elements ahead of time, when it comes to networking as per our example design. You could in fact deploy the whole thing, if you have the budget for Azure Firewall in both regions. The network would then be viewed as a hot secondary, allowing you to run individual workloads there permanently, or as part of testing. By deploying these elements ahead of time, it greatly reduces your RTO times, and if you have VMs, you will definitely need at least the Virtual Network as a target for Azure Site Recovery. Again, Bicep can really help here, but ultimately I would recommend having everything within budget deployed ahead of time. Small items, like where a Public IP is on an allow-list, catch you with BCDR. Azure only allocates these on deployment (if a Prefix, and if you’re not using prefixes, why not!?), so get them deployed and added to your vendors etc ahead of time. Similarly, you can plan and runbook changes required based on existing configuration.

Unavoidable Issues

With zone redundancy deployments, I would call out two issues and they have already been highlighted in brief. It has to be actioned at time of deployment, and SKU costs. Configuration wise, for networking it’s fairly simple and shouldn’t pose challenges.

With regional redundancy, there are quite a few more. A lot of it based on the complexity demanded by running two regions, two footprints and that replication methods do not exist for all services – for example replicating a Virtual Machine vs no ability to replicate Azure Firewall natively. There is also cost of course, having two footprints, in theory means double your network costs. Unfortunately, as we all know, cost is only a challenge before an outage, you would have unlimited budget to recover!

Closing Recommendation

To sum up so – Azure Networking BCDR – Zonal Redundancy for a standard footprint is very achievable, and is definitely the way to go. If you need regional redundancy, try build ahead everything you can to mirror the primary region.

Joe Carlyle

Where to Start – NLP with Azure OpenAI

I think without a doubt, one of the most talked about subjects at the moment is AI. Mass usage of OpenAI’s ChatGPT service exploded onto the scene this year, and we haven’t looked back. However, starting at such a broad scale of possibilities can be daunting. This post aims to simplify things down a bit, by looking at one single use case.

In this instance, I am going to take the Natural Language Processing capability offered by Azure OpenAI and have a GPT model summarise a piece of text for me. I completed sample lab files for this as part of a Microsoft Learn course, and I am reusing the Python here with some tweaks of mine!

All of the code for this solution is on Github here – https://github.com/wedoazure/sumo

The idea is that we take a text file, in my code I am using the first chapter from ‘Sherlock Holmes – The Hound of the Baskervilles’, but feel free to use whatever txt file you like, and send it to Azure OpenAI and ask for it to be summarised.

The app itself is command line based, very simple. It reads your text file, then sends a chat completion prompt to the Open AI model asking it to summarise your text.

The model then responds with a fixed length summary based on your input of word count and temperature.

The ability to adjust both is something I have added as my little variation. I had a couple of reasons for changing this up, but mostly built on the fact that your opinion of the output is important. For an example, read the actual text you want summarised, then have the app do it. Is the summary accurate? Is it a bit short, is it a bit too stiff? Change things up! Here is a 50 word summary at a temp of 0.5 versus 0.9 for the same txt file.

Sherlock Holmes and Dr. Watson examine a visitor’s stick, deducing that its owner is a country practitioner who walks a lot and has likely received a presentation from a hospital. The visitor, Dr. James Mortimer, arrives and confirms their deductions. He seeks Holmes’ assistance with a serious and extraordinary problem.

50 words at 0.5 temp

Dr. James Mortimer visits Sherlock Holmes and asks for his assistance with a mysterious problem. Through analyzing a stick left by a previous visitor, Holmes deduces that Dr. Mortimer is a country practitioner who used to work at Charing Cross Hospital. Dr. Mortimer confirms this and reveals that he has a strange case involving the curse of the Baskervilles.

50 words at 0.9 temp

As you can see, these are very different outputs, I personally prefer the response at 0.9, as I am summarising a work of fiction. However, if it was a financial report, you may need a lot less creativity and therefore force a lower temp. Similarly, you may want more words, or less, depending on your scope.

And that’s it! Short and sweet, using a single use case, minimal effort but impactful and useful outcome. I am sure I may make more tweaks, adding more advanced file input is definitely on the list. Let me know if you have any questions!

Joe Carlyle

Exploring – Azure Firewall Basic

Anyone who follows this blog knows that Azure Firewall is a key resource for me in successful Azure deployments. Its combination of ease of deployment and functionality easily outpace alternative vendor choices on Azure. Up until now, we have had a Standard and Premium SKU. The Premium SKU introduced new features to Standard. Now, we have a Basic SKU and several features have been removed. Let’s explore what the Basic SKU offers.

First up, deployment and infrastructure. At it’s core, Basic is the same resource. Meaning it still has built-in HA. However, it is a fixed scale, meaning two instances only. However, Availability Zones are still covered, meaning choices up to 99.99% for SLAs are achievable. Fixed scale does mean a more limited bandwidth capability, Basic has up to 250Mbps in comparison to Standard which is up to 30Gbps. That’s not a typo!

Microsoft call out the fact they are targeting SMB customers with this SKU. But that doesn’t mean that the features of Basic wouldn’t suit an Enterprise spoke, or specific environment requirement where cost vs features work.

So let’s take a look at the features included. The basics are all the same, multiple Public IPs, inbound/outbound NAT etc. (there is a full list here) but some specifics worth calling out are:

  • Network Rules – As Basic does not support DNS Proxy, you can only use standard, non-FQDN rules in Network filtering. More on that for Standard here.
  • Threat Intelligence – While it can be enabled, it can only be used in alert mode. This means you would have to accept this, and/or monitor logs to adjust rules based on alerts.

This means that once you are aware of the functionality and limitations, Basic may be a great choice for your environment. Especially when you consider one of its main benefits – cost. There are two costs associated directly with Azure Firewall:

  • Deployment
  • Data Processing

Deployment wise, Basic is considerably cheaper versus Standard. Deploying to North Europe, Basic should be approximately €266/month in comparison to Standard at circa €843/month.

However, data processing is more expensive on Basic. 1Tb of data processing for Basic, in North Europe will be approximately €62/month, which is quite a bit more than Standard coming in at around €15/month. So this is definitely one to keep an eye on in your environment. There is no reservation or similar choice here, Standard and Premium simply have a lower processing price.

Thankfully, integration with Azure Monitor is unchanged across SKUs, so you can capture all of the data you need.

The experience within portal, or via shell for deployment and management is also unchanged. The portal dynamically calls out what is allowed/functional when using a Basic policy, so confusion is avoided.

In conclusion, I think Basic is a great addition to the AFW family. I would have liked to see DNS Proxy included in the feature set, I see this deployed everywhere now and the Network rule functionality it adds is excellent. I am also interested to see how/if that throughput limit will come into play for specific scenarios.

As always, if there are any questions, please get in touch!