Azure

Content relative to Microsoft Azure

Joe Carlyle

Microsoft Copilot in Azure – Networking Edition

Welcome all from Azure Back to School, another year and another excellent community event from the guys behind the scenes. And a thanks to the event sponsors Captain Hyperscaler and Trace3.

For this year, I have decided to combine my favourite tech – Azure Networking – with the buzziest tech of the moment – Copilot. Specifically of course, Microsoft Copilot in Azure.

For those not familiar with this, or Copilot of any form, essentially it is an AI assistant. Microsoft are aiming to make these services as integrated as possible. So, you see Copilot logos, chats, prompts etc built into portals and applications to help make engagement with the service as seamless as possible.

Screengrab of Copilot for Azure chat window

Copilot in Azure, is exactly as it sounds, an AI assistant focussed on Azure. It has mixed capabilities depending on what you are trying to do. It is currently in Public Preview, at no additional cost, so I would recommend making use of it for assessment purposes, if it is of interest to you.

There are a base set of use cases as below, so I want to explore how practical these are across some common Networking services.

Let’s start with Virtual Network!

Design – I’ve actually already covered an attempt at this here – How to – Design a Virtual Network with Microsoft Azure Copilot

Operate – I tried some basic queries, and they worked quite well actually. It defaults to Resource Graph queries to convert your ask to something tangible.

What I like here, and where this service has improved since launch, is the follow up suggestions are now based on capabilities and aligned to previous asks, so I now get:

Choosing the subnets ask, it outputs via Resource Graph, a nice list for me however I was expecting it to include the address ranges, not just the names. However, a follow up ask displays them no problem.

Optimise – This one is trickier. A limitation here is me working within my demo environments, which have either limited functionality, or are configured exactly to best practice. Here was the set of questions I tried and answers I got:

  • Are there any active recommendations for my virtual networks
    • There are no active alerts in resource group rg_network for resource type microsoft.network/virtualnetworks
  • Can you show me the metrics for my virtual networks?
    • Responded with a table of all possible metrics, but no details linked to my resources
  • are there any reliability improvements I could make to my virtual networks
    • Responded with a list of best practice recommendations and reference links again not related to my resources.

I think one of the challenges here is the prompt and possible output. There isn’t really enough information or intelligence to be able to respond. For example, if I phrased a question similar to “are there any improvements I could make to my virtual network address ranges” It doesn’t give anything specific to my virtual networks, just accurate best practice advice.

Troubleshoot – So I don’t have a specific issue to ask it about, so I looked for what might be useful, maybe something you don’t know about!

Neither are great responses to be honest. As at least the second was a question I thought would allow for query generation. I couldn’t find a useful one here for this use case, which is a shame, but my guess would be this improves over time, perhaps as it is able to better work with Azure Advisor.

Next, let’s take a look at a Public IP

Design – I know this won’t take information from my own resources, so this just helps with best practice guidance. I went for a question I think most people, even some who have worked with for Azure for a while aren’t sure about and I was impressed with the response. Good examples, excellent awareness and detail in my opinion.

Operate – For this use case, I tried some knowledge gathering queries. I was most impressed with the below. Clever query creation, accurate result, clear (enough) presentation. Exactly what you need for at scale work like this. Not sure why it added Location, but no harm done!

Optimise – Starts getting tricky here. I know there is little that can be done for say Cost or Performance, and there are so maybe contextual questions that could be better with more context, like asking for ‘orphaned’ IPs instead of the below

I tried a security configuration check and recommendation prompt, but it somehow lost its way and prompted to choose a Storage Account, I did, and it gave accurate recommendations for that. Confusing how that happened, but also the output is what I wanted, so kinda half correct?

Troubleshoot – Basic but effective, C minus.

I think I started to crack the best prompt methods at this point in the article research. I quite like this format and output, but I am aware this requires advanced knowledge of the resource and options in advance of prompting. It also got the associated resource part wrong, that’s an orphaned IP I have been working with.

Finally, let’s look at Network Security Group

Design – This is difficult in one way. You can build an NSG with nearly no configuration, just name and location. And that ticks a Defender for Cloud box, if you attach to a subnet etc. But generally there is more configuration, so I thought how could this help me? Well what if I give it my needs and see can it give the right logical output…

Nice! Now, can it help me build it?

Colour me impressed – this was my best interaction to date. Clear, accurate and usable.

Operate Optimise Troubleshoot- A triple whammy as I started to drift across the lot at this point in terms of use case. I wanted to try queries that would help me work with NSGs both day to day and in a potential high stress situation. So I started with this:

So it took my context and decided that a rule that has allow enabled and a direction of inbound would be insecure, fair enough, or at least worth checking in on. Comes back with the correct answer! So, I switched up a few rules on my NSGs to allow all inbound from any source etc. The Portal flags this is as a dumb decision, let’s see if Copilot spots it.

Nope – odd result there. So I tried it a different way. Again, this means I have to know more advanced detail, but nothing you wouldn’t pick up quickly as you upskill.

Output correct! They are the three rules I switched up. It didn’t directly get my port element right, but that just needs a more accurate prompt. I think one logical approach for actual operational queries is to think in pseudo code, and in steps, allowing it work to your meaning quicker. Essentially avoid prompts like – ‘any rules giving off bad vibes in my NSGs? Respond in iambic pentameter’ – they don’t work and let’s be honest, are weird.

To wrap up – I like Copilot in Azure now. I have found multiple use cases that would actually help me work day-to-day. However, would that work be quicker? I am not sure. I feel like I would need to build up a prompt library. And if I was doing that, why would I not just use Resource Graph queries instead? Quicker, more accurate etc. Also, some of the knowledge levels required don’t allow it to be most useful to the people I think it should be useful to – Azure newbies. Design and advice sure, actual hands-on resource work appears to require more contextual knowledge.

Some helpful links to hit up for Copilot in Azure:

Overview

Responsible AI FAQ

Example prompts

Manage access – will become more important depending on your use cases, the cost when it hits GA etc.

As always, get in touch if you have any questions, or even if you have prompts you want to chat about! And don’t worry, I reverted those terrible rule changes right after testing 🙂

Don’t forget to check out all of the other content throughout the month over on Azure Back to School!

Joe Carlyle

wedoAI 2024

Something a little different…

Head over to https://wedoai.ie to checkout a new online event that just launched on August 22nd.

The idea of this event is to promote learning and sharing of knowledge within the Microsoft AI community. To achieve this, we have community driven articles that highlight best-practises, lessons learned, and help with some of the more difficult topics of Microsoft AI.

For anyone familiar with Azure Spring Clean – you will see some similarities!

Joe Carlyle

Exploring – Network Design in the Azure Architecture Center

One of the most common deployment, and as a result, design requirements in Azure, is Networking. Within all environments, not just Azure, Networking is critical. It is of upmost importance to get the design right, and get it right early.

However, if starting out on Azure, or potentially looking to progress to a more complex design based on requirements, Networking can be challenging. Not only is it a vast component of Azure, it has some of its own quirks in comparison to your on-prem environment. From experience, I have seen this lead to incorrect assumptions and frustration once a design is finally in use.

However, good design can obviously be somewhat subjective. For example, avoid discussing naming conventions for Azure on Twitter/X! (I joke…) But what can really help is to follow or at least begin with best practice. For Azure, this is thankfully centrally located for you on Docs. I know it’s called Learn now, but I will forever call it Docs – the difference it made to us all when it launched means it has my loyalty forever! Below is an image from Ignite 2018, where Docs was launched, and I spent more time than I’d like to admit winning one of those mascots. A mascot my small dog subsequently got hold of and made short work of unfortunately.

There is a wealth of information on the Azure Architecture Center, I’ve linked to Networking, but you can see there are many other sections covering all aspects of Azure. My new favourite indicator of content depth on Docs is the “Download PDF” button. For Networking alone, it is 257 pages!

Specific to Networking, it is broken into three sections:

  • Explore ideas about
  • Design Architectures
  • Apply Guidance

Explore ideas about

Here is where you will find specific and complex concepts – for example Video capture and analytics for retail. These are meant to serve as both a start point and potentially a comparison solution/concept. Architects should use these as references and examples of what is possible.

Design Architectures

This is divided in two:

  • Network Topology – Here you will find high-level architectures, example arrangements of network components and best practice guidance for knitting your network fabric together.
  • Network Security – Same idea here, guidance and some specific Security scenarios.

Apply Guidance

This is the big section. It contains expansions and further guidance on the previous sections. This has some of the most useful guidance, whether you are starting out with Azure or not. One of the most useful articles for me is Network Level Segmentation.

This article helps form your understanding and design for nearly all other patterns. It’s crucial to good network design on Azure.

The other article I would recommend or even go as far as to suggest it as required reading is Spoke-to-spoke networking. Everything you need for Virtual Network design is covered in these two articles.

Why this central documentation is useful?

Azure Architecture is challenging. It changes regularly, new services, updates to old ones, can change design principles. Keeping up to date, applying the latest best practice, and being confident in a performant and well designed solution is important. Docs help with this. A huge amount of work is put into these web pages. They are your first point of call for new detail, they are your sanity check on something you can’t quite remember, and they are your older sibling, backing you up if/when you are questioned on a design decision. Use them – always.

Did you know you can contribute?

One final point – you can help make Docs better. You can fix an item you have spotted that isn’t correct, or simply suggest an improvement. Microsoft have written and maintain a full guide here – Overview of editing documentation on Microsoft Learn. For anyone familiar with GitHub, this will be simple for you. For anyone who would like to get familiar with it, this is a great entry point!

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

Joe Carlyle

How to – Design a Virtual Network with Microsoft Azure Copilot

Having access to Microsoft Azure Copilot has been really interesting. On one hand, the use cases are almost limitless, essentially a choice of what do you want to try do with it? On the other, there is still work to be done to maximise its potential (acknowledge by Microsoft throughout use in fairness).

Working with any of the ‘Copilots’, one important element for me is to get a grounded understanding of what it is capable of, based on something I am an expert on. I cannot tell how good it is if I am asking it help with something I don’t know arguably better than it does. So – let’s I decided to push it with a Virtual Network.

My objective when starting this post was to hopefully reach the point where one single, detailed prompt would spit out an acceptable VNET design statement, perhaps even the code to build it, but that part was less important to me right now. Anyone can create a good Azure design right? 🙂

I am first going to outlay my thinking with respect to a VNET, it’s purpose, my security posture, connectivity requirements, and likely workloads. Rewording this into a statement that is aligned to the Cloud Adoption Framework, and Azure Network Architecture details.

To get a baseline of a basic prompt, I started with the below. I believe this helps work towards the ‘best’ prompt.

So this jumps all over the place. We have perimeter references, AVS and App Gateway all mentioned. Not ideal. But I did ask for an example, and it does provide links. So let’s tighten our prompt.

This is much better, proper sequential statements, however that third link to hybrid with Citrix is irrelevant. Now, as Copilot functions in a chat method, let’s use this prompt and response to expand detail.

So this approach doesn’t work. When you select the (perhaps) relevant items, the output is not aligned to the original ask.

So – let’s try this another way. We know the first recommend prompt returned good results. Rather than continue in a chat-response format, let’s try one very specific prompt. To ensure no confusion – I started a new chat for this.

This is better, but to be honest – I am not looking for design principles like ‘zero trust’. So we need to adjust the wording. Again, I have started a new chat for this.

Now we are getting somewhere. If this had included Bastion I would have ranked it 9/10. The first link is good, second link is not so this scores a 7/10 for me. It is a great improvement on previous asks, and I am trying to ask as few leading questions as possible. I tried another following response to get some more detail

Again, the general detail is good, but the links are hit and miss. This could introduce some confusion. I tried another follow on from this, but again it went a different route based on my existing subscription services.

Rather than say this didn’t work, I think I have set out with a task that isn’t really achievable at present. There are so many elements that require consideration, some sequential, some overlapping, some interdependent, that a single chat response is going to be very difficult if not impossible. At the same time, repeat responses are also challenging, especially when you’re not looking for something relevant to what you currently have, but aligned to best practice.

Overall, I think Copilot for Azure is improving every month, and the use cases are constantly expanding. However, I don’t believe, based on current functionality that it will be able to fully assist with design guidance and decisions, beyond providing principles and guided links. For the real design work – you will still need an expert 😉

Joe Carlyle

How to – Control Azure Regions with Azure Policy and Bicep

Updated: March 2024 – repo link now updated to new Github structure!

A common requirement for many tenants is to control or restrict the regions in which Azure can be used, this is most commonly done via Azure Policy. Wanting/needing to restrict regions can be for several reasons, below are some of the most common:

  • Alignment – Align to local presence for performance etc.
  • Governance – Align to compliance, residency and data restriction requirements.
  • Features – Not all data regions are created equally – restrict to those with features required.

For anyone who has created a Policy like this in the past, the experience is quite straight forward. Azure provides an out-of-the-box template, you simply have to pick which regions are allowed from a drop down. However, there are actually three policies you should consider for this in my opinion, all are included here.

  • Allowed Locations – when a resource deploys, it must align
  • Allowed Locations for Resource Groups – when an RG deploys, it must align
  • Audit resource location matches resource group location – just nice to have for governance!

So, with multiple policies to deploy, a controlled and accurate solution is to define these Policies via code, in my case, Bicep. How you manage this (i.e. deployment and repo management etc) is not for this blog post, but is achievable with this as your base Policy. Two elements are required for this to work correctly:

  1. Bicep file to deploy our Policy resources
  2. Parameters file for policy definitions IDs and regions required.

Item 1 is simple, I’ve included the code below, and will link off to a repo with all of this at the end too.



//params
param locations array
param allowedLocationsDefintion string
param rgLocationsDefinition string
param locationMatchDefinition string

//vars
var allowedLocations = 'Allowed locations'
var rgLocations = 'Allowed locations for resource groups'
var locationMatch = 'Audit resource location matches resource group location'


//deploy policy assignments
  
resource allowLocations 'Microsoft.Authorization/policyAssignments@2022-06-01' = {
    name: 'allowed-locations'
    properties: {
      displayName: allowedLocations
      policyDefinitionId: allowedLocationsDefintion
      parameters: {
          listOfAllowedLocations: {
            value: locations
          }
        }
      }
    }
  
    resource allowRGLocations 'Microsoft.Authorization/policyAssignments@2022-06-01' = {
    name: 'rg-locations'
    properties: {
      displayName: rgLocations
      policyDefinitionId: rgLocationsDefinition
      parameters: {
          listOfAllowedLocations: {
            value: locations
          }
        }
      }
    }
  
    resource resourceLocationMatch 'Microsoft.Authorization/policyAssignments@2022-06-01' = {
    name: 'location-match'
    properties: {
      displayName: locationMatch
      policyDefinitionId: locationMatchDefinition
      }
    }

To explain the above:

  • We will pass an array of chosen regions/locations, and the strings of the built-in Policy definitions.
  • We use a variable to define the Policy names.
  • We deploy a resource object per policy, combining each of these into one Policy deployment.

The only real decision required here is which regions you want to allow. Some pointers from me, always include Global, otherwise some features like Traffic Manager, cannot be deployed. Only include the regions you need now, you can always update later.

How to decide on your regions? That’s probably a whole blog post by itself (adds idea to drafts) but my advice would be choose local, and choose as mature a region as possible. This should offer you the best mix of features, performance, and reliability. Once that is decided, also allow the paired region, so BCDR is possible when needed.

Once you have your list completed, that is now the detail we will use in the parameter file to pass our array of regions for deployment, note these must be in exact format required by ARM.

Now to deploy, simply pick your method! For this post, I am using PowerShell (as I am already logged in) and will complete a Subscription level deployment, as this is a Policy. I will pass both files as command parameters, Azure will do the rest! The below should work for you, and I will include a PS1 file in the repo too for reference, but adjust as per your files, tenant etc.

New-AzSubscriptionDeployment -Name 'az-region-policy-deploy' -Location northeurope -TemplateFile 'C:\folderthatexists\region-restrict-policy.bicep'
-TemplateParameterFile 'C:\folderthatexists\policy.parameters.json'

Once that runs successfully, you can verify all is correct via the Portal. Again, as this is Bicep, you can run this over and over and it will simply update the Policy if there are changes. Meaning all it requires is an update of your location parameters to add or remove regions from being allowed.

And that’s it! As promised, here is a repo with the files for reference. Please note – as always, all code is provided for reference only and should not be used on your environment without full understanding and testing. I cannot take responsibility for your environment and use of code. Please do reach out if you have questions.