For the first time in a while, I’m writing just about my thoughts on a topic, rather than specifics. As a result, this will be categorised differently, and maybe I will continue it as a series…
It is hard to spend a single moment of a day at the moment without AI popping up. Social media is alight with opinions, dos and don’ts, hype and Skynet fear. I’m going to start by saying – I think that’s important.
If you spend some time looking at the capabilities that modern AI can offer, you quickly realise that this isn’t a fad. This is something that is coming at us like a train, and is here to stay. That certainty is why I think a mix of opinions is important. Experts on the subject are openly saying they are unsure where this can, will, or should go. That is both exciting and terrifying.
Rather than focus on the terrifying (I personally don’t think it will get there FWIW), I want to focus on the exciting. Recently I’ve seen some use cases, and some demos that have convinced me that this will make my work life better. While I haven’t seen something yet that helps my personal life directly, perhaps AI helping work can indirectly give me a better balance of time.
Also, I currently have zero interest in the creative side. Art, music, even blog posts are something I have no care for seeing AI involved with.
Part of my job requires me to explain complex technology to people in simple language. I have spent some time trying to think how could I explain AI in this way. I think simply stating it’s a new assistant is more confusing than helpful. “I don’t want or need another Siri”. I also think getting to deep on LLMs etc helps no one. I’ve simply settled on AI is an enabler for a new generation of your productivity tool.
In the same vein that an abacus helped you count, and a calculator was a leap forward, AI will be the tech that facilitates a leap forward for your tool.
Let’s take Excel as an example. It’s not a core tool of mine, but I use it a lot. Mostly to read data, rarely to work with complex sets. However when I do, finding out how to do something is difficult. Excel has been around a long time, there is a huge amount of content, searching and finding what you want always takes longer than a single Google search. Enter AI to boost productivity. This is what I want from it.
Working with VS code and GitHub Copilot creating Bicep templates etc. I’ve seen some of this already, write a comment, get some code. It’s not perfect, and sometimes maybe it’s not even correct and this is important to me and why I am calling AI tech to boost your tool.
I don’t think AI can replace someone. I might be wrong, absolutely. But right now, I see it making people more productive. You still need people to validate and confirm the value of what AI has returned. Regardless of capability, I don’t want AI to find data, edit it, and send it to a client, without me involved. I do want it to do the heavy lifting for me, hopefully helping me hit send quicker and with less mental effort. But that is far enough for now please.
As the title says, I’m sold. As long as modern AI can save me time and do so with a degree of accuracy that ensures I can spend time validating and tweaking rather than correcting work it has done I think this will change how we work forever. It is a very exciting time to be working with this technology.
As part of the Microsoft MVP program, every year, Microsoft run a specific summit for MVPs only. At this event, MVPs interact with Microsoft teams on NDA content and hang out with peers. Over the last number of years, this has been virtual. However, this year the event was hybrid, with MVPs able to attend at Microsoft HQ in Seattle. It was also a celebration of 30 years of the MVP program!
Thankfully I was able to make the trip! Here I am looking delighted with myself after picking up my badge:
As all details within the event are under the MVP NDA, unfortunately I cannot even share a round-up. However, I can say that I am very excited for Build, which is again hybrid in Seattle. You can register here – https://build.microsoft.com/en-US/home
And finally, if you saw all of the posts from this past week and feel like you may be a fit for the program, let’s have a chat about a nomination!
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!
Virtual Networks are arguably one of the most common resources in Azure. You will find them in the vast majority of environments facilitating some form of private or static network functionality. However, they haven’t always been around.
For those that remember the older Azure days, the ASM model didn’t have the same network concept. We have only had Virtual Networks since the introduction of ARM and they have changed drastically over the years.
Don’t get me wrong, at it’s core a Virtual Network is still just an address range. A private network of at least one subnet that sets your connectivity boundary. However, it has been a long time since I have seen a Virtual Network only operate in its basic capacity.
As a result of this ever growing list of services a Virtual Network offers, I think it is about time we talk about VNETs!
But aren’t VNETs straight forward? I deploy them all the time etc. Yes they can be, but they also offer an enormous range of network services. As an abstract piece of evidence, did you know that if you download the Virtual Network documentation page on Docs to a PDF, it is 848 pages!?
First off, what this article is not – an explanation of the basic elements of a VNET. For example subnets and address spacing. So presuming you have some familiarity, let’s discuss what I like to call secondary services.
So, what is a secondary service? For me, it’s a service that cannot exist, or serves no purpose without requiring a VNET. Think Bastion, Route Server, NSGs etc. they all serve specific purposes but commonly enhance the functionality of a VNET. Some of these, like Bastion, I feel would be better if included within a VNET resource, like Service Endpoints. However, that is for another post!
They are also drastically different in their complexity. For example, a Service Endpoint can be deployed without much effort and barely any planning (just double check those routes). However, Route Server requires significant elements of both.
While this list of secondary services is ever growing, I do not necessarily think this is a bad thing. I am always all for extra functionality. However, understanding that you cannot simply deploy a VNET and have the majority of network features that most people use is something that should be clearer. There are new services released like Network Manager that will help with management, but none offer a single view of everything.
To both convey the complexity, but help simplify things (weird I know) I thought it best to pick two services, create a test environment so you can try them, and discuss some of the components. So I’ve chosen two of the newer services:
Azure Route Server
NAT Gateway
Azure Route Server
Route Server is an excellent addition to routing services within Azure. Previously, there could be some routes originating from Virtual Network Gateways via BGP, the system routes and everything else would be via Route Table. While this works, it can be cumbersome and management at scale of Route Tables is almost non-existent. Route Server solves some of those problems by allowing BGP interaction between NVAs, Virtual Network Gateways and your VNETs system routing table. It’s also nice that it is a managed service, and HA out-of-the-box.
The objective of Route Server is to simplify and centralise routing management. This is helped by using a default peering process, meaning if your NVA supports BGP – it should work with Route Server. It also natively supports peering of VNETs with the same switch as “use remote gateway” meaning it slots very neatly into Hub-Spoke designs. Including the use of Virtual Network Gateways as peers (note VPN VNGs have to be configured in active-active mode).
As with many secondary services, Route Server requires a dedicated subnet in your VNET and each VNET can only have a single Route Server. The subnet does not allow the addition of an NSG or a UDR. This may flag as a concern as Route Server now requires a Public IP, however, this is only to guarantee access to management services and does not open the VNET (according to Microsoft). Also, no data traffic is sent between Route Server and your NVAs.
However, it’s important to note some of the configurations where Route Server alone is not the answer and in some cases begs the question that if I still have to use UDRs for that, why should I bother with Route Server? For example, ExpressRoute will advertise routes that will be preferred over Route Server routes, meaning you would need to overwrite this with a UDR. You cannot simply turn off the ER advertisement as this runs over the same peering functionality. A nice fix here would be to split that choice into two switches. One for VNGs, one for Route Server.
Another element that may be important is price. VNETs are free, UDRs are free, Route Server is far from that. On many large environments, this may be a negligible cost. However, you should weigh up the benefits vs the cost with introducing Route Server.
So to help, as promised, here is a repo that will build a test footprint for you. I’ve taken the Route Server tutorial using Quagga and integrated it with theother services from this article. You can follow the steps to complete the configuration and confirm you have a functioning peer. You should see output similar to the below from Cloud Shell:
Learned routes in Route Server
NAT Gateway
Implicit internet outbound is potentially one of the Azure network features that surprise most people. Deploy a VM into a VNET and you will be able to reach the internet with a random IP from the region deployed. Not exactly a dream scenario for many admins!
However VMs are not where I see this used most often. That doesn’t mean it’s not a good solution for VMs, it works exactly the same and works well. I just more commonly see this to facilitate static outbound IPs for PaaS resources. Like an App Service that requires a static IP due to a vendor allow list.
One interesting piece here, NAT Gateway when configured on a subnet, will take precedent over locally attached Public IPs and Standard Load Balancer Outbound NAT rules. However, UDRs will still overwrite this when advertising 0/0. Another item of note, no ICMP support, only TCP/UDP.
To try out NAT Gateway, I have again included it within a repo. This will also deploy a Ubuntu VM, which you can use Bastion to connect to and login. This VM has a Public IP locally attached but is deployed to a subnet with a NAT Gateway. So, use Bastion to connect, then simply copy the ipcheck script and paste it into the command line, it will give you an output similar to the below which you can then verify against your NAT Gateway resource. Proving NAT Gateway is taking precedence over the locally attached IP.
Locally attached IPNAT Gateway seen as the outbound IP publicly
Roundup
In closing, I think that more and more secondary services does two things.
Makes networking in Azure ever more complex
Solidifies VNETs as the most important core resource
Now, everyone should agree with number one. However, two may cause some concern, but hear me out. Regardless of your resource deployment, your application architecture etc. 99/100 you will deploy a VNET and 9/10 you will need at least one secondary service. This means that getting it right, having it well designed for deployment, management etc is crucial. Not everyone loves networking, but within Azure at the moment – you’ve gotta learn it!
wedoAzure 