Daniel McLoughlin ☁️

Microsoft App Modernization Guidance for Azure

Daniel McLoughlin — Mon, 04 Aug 2025 12:55:51 GMT

In recent months, I’ve created visual tools to help people make sense of Microsoft’s most important cloud frameworks:

The Cloud Adoption Framework (CAF) – Microsoft’s end-to-end cloud journey guidance
The Well-Architected Framework (WAF) – principles for designing secure, reliable, and cost-effective workloads

These two frameworks underpin how organisations plan, govern, and build in Azure.

But at Microsoft Build (May 2025), a new addition quietly joined the party: the App Modernisation Guidance – a focused set of recommendations and patterns to help organisations bring legacy apps into the modern cloud world.

Where CAF shows you the overall journey and WAF ensures your workloads are well built, this new guidance zooms in on one of the most complex (and valuable) pieces of the puzzle – modernising legacy applications for the cloud.

What is the Microsoft App Modernisation Guidance?

The Microsoft App Modernisation Guidance is part of the wider Cloud Adoption Framework. It provides a practical, structured lifecycle to help organisations move from legacy systems to modern, cloud-native applications on Azure.

It breaks the journey into seven clear phases:

Get Started – Learn the lifecycle, define your roadmap, and assess where you are
Assess – Evaluate app portfolios, gather inventory, and check cloud readiness
Plan – Choose the right strategy using Microsoft’s 6 Rs (Rehost, Refactor, Rebuild, etc.)
Launch – Run a proof of concept, and embed identity, security, and compliance
Foundation – Set the groundwork for specific stacks like .NET, Java, SAP, Oracle, VMware
Expand – Rebuild using APIs, microservices, serverless platforms, and data modernisation
Innovate & Optimise – Introduce AI, low-code, performance, and scale improvements

Why does modernisation matter?

Modernising applications isn’t just a technical upgrade – it’s a business enabler. Most organisations still rely on legacy systems that are hard to scale, expensive to run, and difficult to integrate with modern services.

Modernisation helps you:

Deliver faster and adapt to change
Reduce technical debt and support overhead
Enable AI, analytics, and low-code tools
Improve performance, security, and scalability
Unlock agility and business value from your existing assets

This guidance provides structure and clarity for what can otherwise feel like an overwhelming task.

How does it relate to CAF and WAF?

Here’s the relationship in simple terms:

CAF = the full cloud journey
App Modernisation Guidance \= the "modernise your apps" part of that journey
WAF = best practices to make sure your apps are well-architected, secure, and scalable

The App Modernisation Guidance slots directly into CAF’s Modernise phase and can be used alongside WAF to validate the architecture of replatformed or rebuilt workloads.

AI-powered modernisation with Copilot

Microsoft is also bringing AI into the process. The GitHub Copilot Upgrade Assistants help speed up app modernisation by offering intelligent recommendations and automated code changes.

Copilot for .NET – for upgrading from .NET Framework to modern .NET
Copilot for Java – for migrating Java apps to Azure-native platforms

These tools can save a significant amount of time when migrating large legacy estates, and are well worth a try.

Why I built a visual explorer for this guidance

Like many others, I’ve found real value in having a visual, structured view of large Microsoft frameworks. After publishing explorers for CAF, WAF, and Microsoft AI Adoption, I wanted to do the same for this new addition.

The Markmap Visual Explorer for the App Modernisation Guidance lays out all seven phases in a single interactive map – with direct links to Microsoft’s official documentation.

It’s built for architects, developers, IT leads – anyone planning or delivering app modernisation.

📦 GitHub Repository
🗺 Launch Interactive Map

Final thoughts

In my opinion, this guidance is a real value-add to the Cloud Adoption Framework.

It helps clear away much of the ambiguity around how to get from A to B in the cloud – offering practical, grounded steps that go beyond theory. It’s not just about moving tech – it’s about aligning modernisation efforts to real business outcomes, in a way that’s measurable, focused, and easy to understand.

If you’re modernising legacy systems or preparing to – this is worth your time.

And if you want the big picture at a glance – give the Markmap a try.

A quick note on spelling…

You may notice a mix of UK and US spelling in this post. I’m based in the UK and follow British spelling conventions (like modernisation and optimise), but I also use Microsoft's official product names and terminology (like App Modernization Guidance) as they appear in the documentation - which typically uses US spelling. It’s a deliberate mix to keep things both accurate and readable.

Visuals for Azure Governance

Daniel McLoughlin — Tue, 24 Jun 2025 15:28:01 GMT

I've been working with the Azure Cloud Adoption Framework (CAF) and the Azure Well-Architected Framework (WAF) quite a bit recently - and while the content is excellent and comprehensive, I found it hard to navigate quickly or explain clearly in practice.

I'm a visual learner. The sheer volume of documentation can feel overwhelming, and I needed a better way to understand the structure, flow, and relationships between the key parts. So I built a couple of interactive mind maps using a tool called Markmap. They’ve helped me get to grips with the frameworks more easily, and I’m sharing them here in case they help others too.

Let’s take a look:

Azure CAF

This project visualises the structure of the Cloud Adoption Framework in a single, explorable map. From strategy and planning to governance and management, the layout is designed to help you grasp how the different stages fit together.

📦 GitHub Repository
🗺 Launch Interactive Map

Azure WAF

The WAF map breaks down the five pillars of the Well-Architected Framework, along with key principles and design considerations. It’s a handy way to refer to the framework during architecture sessions or to anchor discussions around best practices.

📦 GitHub Repository
🗺 Launch Interactive Map

Microsoft AI Adoption

The Microsoft AI Adoption framework is an official CAF adoption scenario designed to help organisations adopt AI responsibly and effectively – with tailored guidance for both startups and enterprises, plus checklists, best practices, and platform recommendations.

📦 GitHub Repository
🗺 Launch Interactive Map

Why and How

I built these maps because I learn best when I can see how things connect.

Working through long-form documentation is necessary - but sometimes, especially when preparing for reviews or walking through a framework with a team, I need a more structured, visual approach. That’s where Markmap comes in.

Markmap turns Markdown into an interactive mind map. It’s:

Lightweight and open source
Easy to maintain in GitHub
Perfect for creating skimmable, navigable versions of dense content

Each map starts with a plain Markdown file, structured using bullet points. Markmap does the rest.

If you're a visual thinker, or just looking for a more approachable way to engage with CAF and WAF, these tools might be helpful.

Both projects are open source and available to fork, adapt, or build upon. Feedback and contributions welcome.

Thanks for checking them out.

Dan

Azure AI Foundry vs Azure AI Services vs Azure Machine Learning

Daniel McLoughlin — Tue, 17 Jun 2025 11:39:07 GMT

Introduction

I've seen a lot of confusion recently about Azure AI Foundry and its role in the Azure AI ecosystem. Specifically, people are assuming Foundry is a full machine learning platform where you can train and run ML workloads. To make matters worse, a recent change in the Azure portal has renamed "Azure AI Services" to "AI Foundry," adding even more fuel to the fire.

Let's clear this up.

Azure AI Foundry: What It Actually Is

Azure AI Foundry is Microsoft's GenAI orchestration platform. It helps you build generative AI applications by bringing together:

Model catalogues (Azure OpenAI, OSS models, 3rd party models)
Prompt Flow integration
Fine-tuning for foundation models
Evaluation tooling
Responsible AI guardrails
Deployment endpoints
Agent and application templates

It's designed for building GenAI apps - not for classical machine learning.

You deploy Azure AI Foundry as an Azure resource, and access it via its own portal.

I go into much more detail on what Foundry is (and isn't) in my earlier post: "Azure AI Foundry: What It Is & What It Isn't".

What Foundry Is Not

Azure AI Foundry is not:

A platform for training ML models from your own data
A replacement for Azure Machine Learning
A full MLOps pipeline

Azure Machine Learning: Where ML Lives

If you're doing traditional ML - training models, running experiments, managing pipelines - you still use Azure Machine Learning. That's where the full ML workflow lives, including hyperparameter tuning, feature stores, custom models, and deployment.

Much like Azure AI Foundry, you deploy Azure Machine Learning as an Azure resource, and access it via its own portal, called Azure Machine Learning Studio.

The Portal Rename: The Root of the Confusion

The Azure portal renamed the "AI Services" blade to "AI Foundry". This blade now includes:

The Foundry platform itself
Azure OpenAI, AI Foundry (projects), AI Hubs (parents of the projects), AI Search
All the classic Cognitive Services (Vision, Speech, Language, Document Intelligence, etc.)
Azure Machine Learning (still listed as a separate resource)

Seeing all these services under the "AI Foundry" banner is leading people to assume Foundry now includes ML capabilities. It doesn't.

Azure Databricks is not included in any of this.

A Quick Word on Using Code

Regardless of whether you're using Azure AI Foundry or Azure Machine Learning, both platforms can be accessed programmatically using languages like Python. For Foundry, this typically involves working with the Azure SDKs, REST APIs, or integrating with tools like Prompt Flow in code. For Azure Machine Learning, Python is often the primary interface - from data preparation and training to deployment and monitoring, with full SDK support for end-to-end ML workflows.

You can also work with both platforms directly from Visual Studio Code. With or without extensions, VS Code gives you flexibility to write and manage code, interact with Azure resources, and integrate with version control. Microsoft offers specific extensions for Azure Machine Learning and Azure AI Foundry (in preview) that simplify code level integration with the deployed platform in Azure.

When it comes to endpoints, both Foundry and Azure ML allow you to manage deployment endpoints directly in the Azure portal. In Foundry, once you've selected and deployed a model from the model catalogue, an endpoint is automatically provisioned for you. You can then retrieve the endpoint URL and keys directly from the portal for use in your applications. Azure ML offers similar functionality for deploying custom models, exposing them as managed web services that can be consumed via REST APIs or integrated into larger applications.

Quick Rule of Thumb

Building GenAI apps? Use Azure AI Foundry.
Running ML workloads? Use Azure Machine Learning or Azure Databricks.
Using pre-trained APIs? Use the services within the AI Foundry portal blade (formerly Cognitive Services and AI Services).

Hopefully this helps cut through the noise. The Azure AI landscape is evolving fast, and it's easy to get tripped up - I'm learning it in public so you don't have to.

Azure AI Foundry vs Microsoft Copilot Studio

Daniel McLoughlin — Fri, 06 Jun 2025 14:34:03 GMT

Why reinvent the wheel - especially when someone else out there can do it better than you?

I had every intention of writing a piece comparing Azure AI Foundry to Microsoft Copilot Studio. It’s a question I’ve faced a few times in my line of work as a Tech Strategist, and it felt like a natural progression in my Azure AI Foundry series - where I’ve already explored what it is, what it isn’t, and why use it.

However, while scrolling LinkedIn earlier this week, I came across a post by none other than Peter De Tender - a well-respected Microsoft Technical Trainer - who had already tackled the exact comparison I had in mind.

So rather than start from scratch, I’m doing something better: amplifying his excellent article and encouraging you to give it a read.

👉 Here’s the link to his article:

https://techcommunity.microsoft.com/blog/azure-ai-services-blog/navigating-ai-solutions-microsoft-copilot-studio-vs-azure-ai-foundry/4411678

TL;DR – My Quick Take

Peter nails the distinction:

Copilot Studio is perfect for rapid, low-code solutions - chatbots, automation, and lightweight business workflows. It’s ideal for organisations already deeply embedded in the Microsoft 365 ecosystem.
Azure AI Foundry, on the other hand, is designed for developers and technical teams looking to build, customise, and scale GenAI apps with precision and flexibility. It’s about orchestration, experimentation, and end-to-end control.

They serve different purposes - but both are valuable depending on the problem you're solving.

So, like all things in tech, the answer to the question on which one to use is: it depends!

From my side, one key consideration that stems beyond usage is the cost model, and the surrounding ecosystem you deploy and build into.

For example, Azure AI Foundry is deployed into Azure as a resource - just like a storage account or virtual machine. Whilst the costs for Azure AI Foundry aren't immediately clear (I'll write more about this in detail in another post) - the costs themselves will be billed via the Azure subscription into which they are deployed.

Copilot Studio, in contrast, operates within the Power Platform environment. Solutions are developed in Power Apps environments and published into environments tied to your Microsoft 365 tenant. Pricing is typically consumption-based, with licensing linked to Power Platform plans or pay-as-you-go usage via Power Platform capacity. This means you’re operating inside the governance, compliance, and licensing model of Microsoft 365, not Azure.

Azure AI Foundry: What's New From Build 2025

Daniel McLoughlin — Thu, 29 May 2025 10:40:05 GMT

Introduction

Let’s be honest: keeping up with Microsoft Build announcements can feel like drinking from a fire hose - especially when AI is involved! But if, like me, you’re interested in Azure AI Foundry, this year’s updates are worth paying close attention to.

Following on from my last post - Why Use Azure AI Foundry? - I wanted to zoom in on the key announcements from Build 2025 and what they actually mean in practice. Not just the “what”, but the “why” - especially if you’re a builder trying to make sense of where to focus.

I won’t attempt to cover every announcement (there were loads!) - but I have pulled together the ones that stood out most to me from the Foundry perspective.

If you want the full rundown, the Build Book of News is a great companion resource.

Model Router

What it is:
This one is really cool! The Model Router is a new feature that automatically selects the most suitable Azure OpenAI model for your specific prompt, optimising for performance and cost.

By evaluating factors like query complexity, cost, and performance, it intelligently routes requests to the most suitable model.

Source

Why it matters:

Reduces the need for manual model selection
Enhances response quality by choosing the best-fit model
Optimises costs by selecting the most efficient model

Example use cases:

Dynamic selection between GPT-4 and GPT-3.5 based on prompt complexity
Automatically routing image-related prompts to vision models
Selecting lightweight models for simple tasks to save costs

More Models & More Capacity

What it is:
Soooo many models! In Azure AI Foundry, there are models sold directly by Microsoft, and models from third parties. The update here is that you can now use models from AI focussed tech companies xAI, Black Forest Labs, and Hugging Face.

On top of that, Microsoft is extending reserved capacity to cover Azure OpenAI and select Foundry Models (including Black Forest Labs, and xAI). This means you get consistent performance even when demand spikes.

Why it matters:

Huge increase in model choice - over 11,000!
Consistent performance under load with reserved capacity options
Fine-tune and experiment without infrastructure overhead

Example use cases:

Experiment with emerging models in development, then scale to production seamlessly
Ensure consistent response times for AI services during high-traffic periods

Foundry Local

What it is:
Foundry Local brings Azure AI Foundry capabilities directly to your own infrastructure – whether that’s a developer workstation, edge device, or air-gapped data centre. This includes support for offline execution! Imagine interacting with an AI chatbot as a Windows app on your laptop - even when completely offline!

Source

Why it matters:

Enables AI use in scenarios with strict data privacy or sovereignty requirements
Delivers sub-second response times without a cloud round-trip
Supports hybrid and offline environments with no connectivity needed

Example use cases:

Run AI models at the edge in manufacturing, retail, or healthcare settings
Enable offline document processing or vision capabilities on laptops
Deploy secure, private agents in government or defence environments

Fine-Tuning & Developer Tier

What it is:
Fine-tuning has traditionally been tricky – not just technically, but also in terms of cost and where you could actually run it. That’s changing.

Fine-tuning allows you to retrain a model on your own data so it adapts to your domain. This is different from grounding, which connects a model to external data at runtime without changing how the model is trained.

With the public previews of Global Training and the new Developer Tier, Azure AI Foundry is making fine-tuning more accessible than ever. You can now fine-tune the latest Azure OpenAI models in new worldwide regions, with lower pricing designed specifically for experimentation and iteration.

Global Training handles the infrastructure behind the scenes – and the Developer Tier removes the upfront hosting cost, so you only pay when you actually train or use a model.

Source

Why it matters:

Run fine-tuning closer to your data with expanded regional support
Experiment more freely with reduced pricing
Skip the infra setup – Foundry handles it for you

Example use cases:

Trial multiple fine-tuning approaches in a low-cost environment before committing to production
Fine-tune a model in-region to meet data residency requirements for financial or healthcare data
Quickly test how adding domain-specific examples affects summarisation performance - without setting up infrastructure
Build and evaluate early-stage agent prototypes on the Developer Tier, then scale seamlessly to production using the same workflows

Multi-agent Orchestration

What it is:
Azure AI Foundry now includes native tools for designing and coordinating multiple AI agents within a single system. This goes beyond prompt chaining - agents can now have distinct roles, shared memory, and coordinated workflows, all managed within Foundry. I need to write about this, and Agents in general, in a lot more detail!

As part of this, Microsoft also introduced an agent catalogue: a growing library of pre-built, configurable agents for common tasks like retrieval, planning, evaluation, and summarisation. You can use them as-is or customise them to fit your specific needs.

Source

Why it matters:

Enables more advanced, multi-step AI use cases
Removes the need for custom orchestration logic
Encourages modular, maintainable agent design
Supports real collaboration between specialised agents

Example use cases:

A planning agent delegates tasks to retrieval, generation, and validation agents
A multi-agent customer service flow handles triage, resolution, and escalation
A compliance assistant splits work across extraction, analysis, and reporting agents
A document workflow uses separate agents to summarise, translate, and format content

Identity for Agents

What it is:
Microsoft Entra Agent ID is a new capability that brings enterprise-grade identity and access management to AI agents. Just like you’d give an app or service a managed identity, you can now give AI agents their own secure, verifiable identity within your organisation.

This allows agents to authenticate, authorise, and operate securely across your systems, with support for auditing, policy enforcement, and lifecycle management - all integrated with Microsoft Entra.

Why it matters:

Secures agent interactions with APIs, data, and enterprise resources
Enables RBAC and policy enforcement for AI agents
Improves traceability and auditing of agent actions
Aligns agent behaviour with existing identity and governance frameworks

Example use cases:

An AI agent authenticates with Entra to access SharePoint or Microsoft Graph
Different agents have scoped permissions based on function - e.g. read-only vs full write access
Agent activity is logged and monitored alongside human and app identities

Azure AI Foundry Observability

What it is:
Azure AI Foundry Observability is a unified solution for governance, evaluation, tracing, and monitoring. It brings real-time visibility into models, agents, workflows, and user interactions - all from a single view.

In my last post, I briefly described evaluation and monitoring in Foundry. I’ve not had chance to look at this in greater detail as yet, but as I understand this announcement, Foundry Observability combines what existed before (within Foundry itself), such as live request tracing, model metrics, agent behaviours, evaluation results, etc - but now fully integrated with Azure Monitor, Application Insights, and the Foundry portal itself.

Source

Why it matters:

One integrated view - no more tool sprawl
Real-time tracing and evaluation across agents and models
Built-in governance features to support audits and responsible AI
Makes it easier to go from prototype to production with confidence

Example use cases:

Trace a user request across multiple agents in a multi-turn workflow
Set alerts when accuracy or safety thresholds are breached
Track agent behaviour over time to spot drift or unexpected changes
Export evaluation logs for compliance or internal reviews

And The Rest!

There’s a lot I haven’t covered here - from updates to Agentic Retrieval in Azure AI Search, to Agent Evaluators, and improvements to the Foundry API and SDK.

I’ve also noticed growing overlap with tools like Copilot Studio and Azure Logic Apps, which adds more capability - but also more complexity. It’s a lot to take in, but I hope this post has helped you cut through the noise and focus on what’s new and important in Azure AI Foundry.

The link below (click the image) will take you to another excellent write-up, and the Build Book of News is another fantastic resource for exploring the full range of announcements.

If you’d prefer to see it all in action, I highly recommend the Build session: Azure AI Foundry: The AI App and Agent Factory - complete with demos of many of the updates mentioned here.

Disclaimer: The views expressed in this blog are my own and do not necessarily reflect those of my employer or Microsoft.

Azure AI Foundry: Why Use It?

Daniel McLoughlin — Thu, 15 May 2025 19:13:21 GMT

Introduction

When I explore new tools and technologies, I tend to start with two questions: what is it, and why would I use it? Only once I’ve got a handle on those do I dive into the how.

In my previous post – Azure AI Foundry: What It Is & What It Isn’t – I covered the first of those questions. I unpacked what Azure AI Foundry actually is, what it isn’t, and how it fits into the broader Azure AI ecosystem.

This post focuses on the why.

Usually, this is the easy part. With traditional Azure services like Web Apps or Storage Accounts, it’s simple enough to connect features to use-cases, such as autoscaling for traffic spikes, geo-redundancy for disaster recovery, that sort of thing.

But Azure AI Foundry doesn’t work like that – and that’s where it gets interesting.

Foundry isn’t a single service. It’s not a standalone resource. It’s a platform – a combination of services, tooling, and governance layers designed to help you build, customise, deploy, monitor, and govern AI solutions in one place.

So if I’m going to explain why you’d use it, I need to talk about the platform as a whole and the building blocks within it – because that’s where the real value is.

Azure AI Foundry as a platform is structured into three core stages:

Note how each of these stages serves a purpose in the journey from idea to production!

In this post, I’m going to explore the use-cases for Azure AI Foundry by walking through each stage in turn.

Once you know why you’d make use of each stage, you’ll start to see the real power of AI Foundry as a wider platform.

Define and Explore

Before you build anything, you need to choose the right model – and that’s where Azure AI Foundry really sets itself apart, thanks to two key capabilities: the Model Catalogue and the Playground.

Model Catalogue

At the time of writing, the catalogue includes 1,987 models!! From OpenAI, Meta, Mistral, DeepSeek, and others – all accessible in one place through a unified interface.

The real benefit is that you don’t need to integrate with third parties or set up separate accounts and environments to use non-Microsoft models. You can also search, filter, and rank options against metrics such as quality, cost, and latency – helping you find the right fit without guesswork or hours of R&D.

Why it matters:

Access top models across providers without leaving Azure
Use leaderboards to evaluate quality, cost-efficiency, and throughput
Avoid vendor lock-in with consistent interfaces for every model

Example:
You’re building a chatbot for customer support. You need something that can:

Respond conversationally and accurately
Return answers quickly (throughput)
Stay within budget

Using the catalogue, you can shortlist models, compare them side-by-side, and pick one based on actual performance data – not just a brand name.

Playground

Think of the Playground as your safe space to get hands-on – whether you're working with text, speech, vision, or something more specialised.

And it’s not just for chatbots. There are dedicated playgrounds for:

Agents – build AI agents grounded in your enterprise data that can act independently
Audio – test native speech-to-speech and voice-based experiences
Images – generate visuals from text prompts using models like DALL·E
Speech, Language & Translation – summarise text, answer questions, or translate between languages

Once you’ve picked a model, you can start interacting with it – trying prompts, tuning system instructions, uploading data, and refining the experience – all within the same portal.

Why it matters:

Everything happens in one place – no infrastructure to spin up
Supports a wide range of AI tasks, not just conversational use-cases
You can test grounding, flow, tone, latency, and more

Example:
You’re building an insurance claims assistant. In the Playground, you can test whether a model can understand policy language, summarise complaints, and respond appropriately – all before writing any code.

There’s a clear pattern forming here: pick a model, try it out, then…

Build and Customise

Once you've identified the right model, Foundry provides everything you need to shape it into a working solution. This stage is where ideas become applications.

Agents

If you want AI that does more than just respond to prompts – like fetching data, making decisions, or calling APIs – Agents give you that flexibility within a structured workflow.

Why it matters:
Great for building multistep processes that need real-time decisions and data handling.

Example:
A user asks a chatbot, “Where’s my order?” Behind the scenes, agents could:

Call an API to get the status
Determine if a refund is needed
Respond with a personalised update – all automatically

Templates

Templates are code-first samples hosted on GitHub, with pre-written instructions and scripts ready to deploy locally, in containers, or GitHub Codespaces.

Why it matters:
They help you go from experiment to pro-code implementation fast – especially when you want to integrate a model into a real application.

Example:
You want to quickly test a multi-agent use-case that combines order tracking with sentiment analysis. Instead of starting from scratch, you deploy a GitHub-hosted template that wires everything together with minimal setup.

Fine-tuning

Fine-tuning allows you to retrain a model on your own data so it adapts to your domain. This is different from grounding, which connects a model to external data at runtime without changing how the model is trained.

Think of it like this:

Grounding is real-time – you point the model to fresh data each time it’s used
Fine-tuning is permanent – you change how the model behaves based on your own examples

Why it matters:
Fine-tuning lets you customise a model to better reflect your domain, tone, and terminology - so it can generate responses that are more accurate, aligned with your brand, and tailored to your users.

Example:
You run a financial services chatbot. By fine-tuning the model on your internal policies and product names, it gives more accurate and compliant responses without needing long prompts every time.

Content Understanding

Content Understanding uses AI and services like Azure AI Search to extract meaningful, structured, machine-readable data from unstructured sources – such as text, images, audio, or documents.

Why it matters:
Perfect for automating document processing, turning messy data into searchable content, and helping AI find the right information to generate accurate responses.

Example:
You upload scanned contracts, meeting transcripts, and product datasheets. Content Understanding processes these files, extracts key details like clauses, deadlines, and names, and makes them searchable – ready to power chatbots or automated review systems.

Prompt Flow

Prompt Flow is a visual tool for designing and testing AI workflows by combining models, logic, and data into repeatable steps.

Why it matters:
Prompt Flow gives you a faster, more reliable way to turn prompt experiments into real applications. Instead of managing scattered scripts and logic, you can design, test, and iterate on AI workflows in one place — with visibility, version control, and deployability built in.

Example:
You build a flow that takes customer feedback, summarises it using a model, runs sentiment analysis via a Python script, and stores the result in a database – all within a single visual workflow.

At this stage, you’ve picked a model, tested it, and now built it into something usable. But before it’s truly production ready, there’s more to consider…

Assess and Improve

Building an AI application is one thing – keeping it reliable, safe, and effective is another. Foundry supports this with tracing, evaluation, and Responsible AI tooling.

Tracing

Tracing gives you detailed visibility into how your AI application runs behind the scenes. It captures each step in a prompt flow – including model calls, API interactions, function executions, and data handling – and presents it as a visual timeline using Azure Application Insights.

Why it matters:
Tracing helps you understand exactly how your AI flow behaves – which is critical when diagnosing issues, identifying performance bottlenecks, or validating that your logic is working as expected. It saves hours of guesswork and gives you confidence that your app will behave reliably in production.

Example:
You’ve built a multi-step chatbot that fetches data from several APIs. A user reports slow responses. Using tracing, you discover a third-party API call is consistently delaying the flow – allowing you to pinpoint and fix the issue quickly.

Evaluation

Foundry's evaluation tooling lets you measure how well your application is performing using manual or automated evaluators. These are designed to test the quality, safety, and reliability of the outputs generated by your models, datasets, or prompt flows.

You can choose from Microsoft-curated evaluators like:

Groundedness Evaluator – checks how well the response stays tied to source data
Toxicity and Violence Evaluators – flag unsafe content
Relevance, Similarity, and Retrieval Evaluators – assess response quality
Hate-and-Unfairness Evaluator – monitors bias and discrimination
Indirect Attack Evaluator – part of red-teaming scenarios

All evaluators can be run manually, automated in CI/CD pipelines, or used during development to fine-tune quality before release.

Why it matters:
Evaluation helps you build trustworthy AI. It gives you clear metrics for performance and safety, helps you choose the best model or prompt for your scenario, and ensures consistent quality as your application evolves.

Example:
You're testing two prompt flows for summarising customer emails. By using the Relevance and Groundedness evaluators, you can see which one produces more accurate summaries, and automatically flag hallucinated content – before your app ever goes live.

Safety and Security

Foundry includes built-in tools to help you deliver AI responsibly – by identifying, measuring, and managing risk throughout your app’s lifecycle.

The process is structured around three key stages:

Map potential issues like misuse, bias, or unsafe content using red-teaming and testing
Measure how frequently risks occur and how severe they are, using test datasets and evaluation metrics
Manage risk in production with layered mitigation plans – including filters, grounding, system prompts, and operational monitoring

Why it matters:
When you're shipping AI into the real world, trust is everything. Foundry helps you catch issues early, prove your system is safe, and stay ahead of regulatory or reputational risks – without having to build your own safety stack from scratch.

Example:
You're about to launch a chatbot that handles customer queries. With Foundry, you can simulate harmful prompts, evaluate how the model responds, and configure output filters and safety layers to prevent misuse – all before your users ever see it.

There we go – you’ve picked a model, tested it, built it into something usable, and now you’ve embedded it into your application, knowing you can keep a close eye on it.

Conclusion

Let’s imagine for a moment that Azure AI Foundry didn’t exist. You’d be evaluating models from multiple providers, stitching together tools, and figuring out how to maintain visibility, security, and compliance at every step. Even spinning up a simple AI-enabled app would be time-consuming and complex.

Azure AI Foundry changes that. It brings everything into one unified platform – so you can move faster, stay consistent, and go from prototype to production with the guardrails already built in.

That’s the real value of Foundry: the heavy lifting is done for you. Everything’s under one roof and deeply integrated with the Azure ecosystem. You get consistency, speed, and security – so you can focus on building, not bolting things together.

Disclaimer: The views expressed in this blog are my own and do not necessarily reflect those of my employer or Microsoft.

🧠 Dan’s AI Terminology Tracker

Daniel McLoughlin — Mon, 07 Apr 2025 11:35:00 GMT

This past weekend - in between kids’ birthday parties, cake, and chaos - I pulled together something I’ve been meaning to build for a while:

🎯 A visual, open source AI terminology tracker - designed to help make sense of the rapidly evolving language around AI, ML, Generative AI, and the Microsoft AI ecosystem.

As someone diving deep into Azure AI Foundry, I kept running into scattered definitions, mismatched documentation, and “what does that mean again?” moments. So I did what we do - I built a tool.

🗺️ What It Is

The tracker is a Markmap-powered mind map that organizes:

AI/ML learning paradigms
LLM and Generative AI concepts
MLOps and GenAIOps workflows
Data pipelines and infrastructure
Microsoft-specific tools like Azure OpenAI, Prompt Flow, AI Studio, and more
Ethics, governance, and emerging regulations like the EU AI Act

It’s designed to be clickable, skimmable, and useful whether you’re a beginner or deep in the Azure AI space.

🔗 Explore It

Live Map: ai-terms.daniel.mcloughlin.cloud
GitHub Repo (open to contributions): github.com/clouddevdan/dans-ai-terminology-tracker

💬 Got a term I’ve missed? A better link? Open a PR or raise an issue - it’s a living resource.

🚧 A Few Notes

It’s still a work in progress — expect regular updates
It leans toward the Microsoft ecosystem — by design
Built with ❤️, Markdown, Markmap, and the 30 minutes between party clean-up and bedtime

Thanks for checking it out - and if it helps clarify something along your AI learning journey, I’d love to hear about it!

Azure AI Foundry: What It Is & What It Isn't

Daniel McLoughlin — Thu, 03 Apr 2025 13:03:36 GMT

Introduction

The title of this post probably gives the game away, but why write it in the first place? Azure AI Foundry sounds impressive, but isn’t it just a rebrand of Azure AI Services? And wasn’t that just a rebrand of Azure Cognitive Services? Or maybe it’s all just a frontend for some advanced OpenAI stuff? Or is it the umbrella for everything AI-related in Azure now? Where does Copilot fit into all of this?!

See my point.

The name is great, but the purpose isn’t immediately obvious - and when something isn’t immediately clear, I find it helpful to break it down. So, in this post, I’ll do my best to unpick what Azure AI Foundry is, what it is not, and how it fits into the wider Azure AI story.

A Brief History

When I think of Azure AI, the first thing that comes to mind is Azure Cognitive Services. From what I remember, that was essentially a wrapper - a way to bundle up existing services like Document Intelligence, Speech Services, and others under a single label.

Then came Azure AI Services, which, at a glance, looked like another round of consolidation and rebranding.

Things started to shift with the introduction of Azure OpenAI, and more recently Azure AI Studio, which introduced a more unified space to interact with multiple services in one place.

Now we have Azure AI Foundry, which looks like the next iteration of that effort - but with a clearer focus on generative AI but also orchestration.

Quick timeline to give this some context:

2015 (Apr): Project Oxford launched (origin of Microsoft Cognitive Services).
2016 (Mar): Rebranded as Microsoft Cognitive Services.
2017 (Apr): Cognitive Services reached general availability.
2017: Azure Machine Learning launched for model training and deployment.
2019–2020: Expanded enterprise AI with MLOps and responsible AI tools.
2023 (Jan): Microsoft expanded its OpenAI partnership with a major investment.
2023: Azure OpenAI Service launched (GPT, DALL·E, Codex via API).
2023 (Nov): Azure AI Studio launched at Ignite as a unified GenAI platform.
2024 (Mar): Azure AI Foundry announced for building and scaling GenAI solutions.
2024 (Nov): Azure AI Foundry launched, unifying Microsoft’s enterprise GenAI stack.

I used ChatGPT for this, so please forgive any inaccuracies.

Azure AI Foundry - What Is It?

In a nutshell, Azure AI Foundry is more than just a wrapper containing lots of related services - it’s a platform.

Under a unified interface, Azure AI Foundry:

Brings together what used to be known as Cognitive Services (Document Intelligence, Vision, Language, Translator, Speech), Azure OpenAI, Azure AI Search, and more.
Gives access to a huge model catalogue, far beyond just Azure OpenAI models. You can compare models based on features and capabilities.

Lets you deploy models directly from the catalogue (subject to availability), generating API endpoints along with sample code to get started.
Includes tools for model evaluation, helping you measure and compare model performance. (Model training also appears to be supported - I'll dig into the why and how in a future post.)
Provides a hands-on "playground" environment for experimentation, covering things like image generation and real-time audio. You can link your playground work to models from the catalogue.

Supports custom data connections for building more tailored applications.
Enables additional capabilities like building Agents, using Templates, fine-tuning models, and creating prompt-flows. (I’ll explore these more in future posts as I learn.)
Includes a dedicated set of features for safety and security - this is a big focus within Foundry and deserves its own section, which I plan to explore in more detail as I get hands-on.

When evaluating new products and services like this, I try to take a holistic view - looking beyond just the features and capabilities. Azure AI Foundry isn’t a resource in the traditional sense. It’s not like a virtual machine or web app that you simply deploy and start using. Instead, it’s a platform within a platform, with its own self-contained ecosystem. It brings together a wide range of powerful tools and capabilities, which are impressive on their own—but the real value emerges when you start stitching them together and integrating them with the wider Azure and Microsoft ecosystem.

For example, you might use Azure AI Foundry to prototype, validate, and test your AI workflows, incorporating Responsible AI checks along the way. Then, as you transition from prototype to production, you’d connect your work to other Azure services such as Entra ID, Azure Monitor, AKS, API Management, and more—unlocking end-to-end scalability, governance, and operational readiness.

This diagram illustrates the GenAIOps lifecycle that underpins the journey I’ve just tried to describe - showing how Azure AI Foundry supports the transition from experimentation to production.

In short: it’s actually really hard to describe! There’s a lot to it, and in all honestly, I’m finding the portal UI a bit overwhelming. I’ll break that down into manageable chunks as this series progresses.

Azure AI Foundry - What It Isn’t!

First off, at the time of writing at least, Azure AI Foundry is not something you have to use in order to consume Azure AI services. You can still deploy many of these services independently—for example, setting up Document Intelligence or Azure OpenAI as standalone resources.

Why might you want to do that? Well, deploying services independently may give you more flexibility, especially if you're only using a specific capability and don’t need the full orchestration layer that Foundry provides. It might also be preferable for production environments where you already have infrastructure and pipelines set up, or where resource-level access and governance are tightly controlled.

Second, Azure AI Foundry is not everything AI-related in Azure. Services like:

Azure Machine Learning (for model training and ML workflows)
Azure Databricks (for collaborative data science and big data analytics)
Azure Synapse Analytics and Microsoft Fabric (for end-to-end analytics solutions)

...are not natively part of Foundry.

That said, they can be integrated where needed. Foundry plays nicely with the rest of the Azure ecosystem, so you can still connect to data, embed workflows, or trigger interactions across services like Fabric or Logic Apps.

GitHub Marketplace

As with most things in IT, there’s more than one way to do things!

GitHub also offers a model catalogue and playground through the GitHub Marketplace.

Unlike Foundry, where you have to deploy a model to use it, the GitHub Marketplace allows you to use hosted models directly without any setup. You can even compare models side-by-side, much like you can in Foundry. So what’s the catch? GitHub is free to use, but comes with rate limits, making it better suited for experimentation and quick testing than anything more meaningful.

Azure AI Foundry vs Microsoft Copilot

Calm down! Calm down! I’m not going to get into the whole “Pro-code vs Low-code” debate here. Not in this blog post, anyway!

I feel the need to call this out as “Microsoft AI” isn’t just one thing, or even one suite of things. There are different tools for different jobs.

Azure AI Foundry is built for developers and technical teams who want to create tailored AI experiences. It’s highly configurable, gives access to a broad set of models, and is designed for integration with other Azure services.

Copilot, on the other hand, is a ready-made tool aimed at end-users. It’s built into Microsoft 365 apps like Word, Excel, and Dynamics, and is meant to enhance productivity out of the box. It’s low-code (or no-code), and while it can be extended and customised to some extent, it doesn’t offer the same depth or flexibility as Foundry.

I’ll be digging deeper into this comparison in a dedicated blog post, where I’ll explore use cases, integration approaches, and how to decide which makes sense for your project.

Conclusion

Azure AI Foundry isn’t a replacement for everything else in Azure’s AI and data stack - and it doesn’t try to be. Instead, it offers a structured, developer-friendly way to experiment with and build generative AI solutions using Microsoft’s growing set of pre-trained services.

As someone learning this in real time, I’m using this series to make sense of the evolving landscape. If you’re on a similar path, hopefully this helps clarify where Azure AI Foundry fits in - and where it doesn’t.

Disclaimer: The views expressed in this blog are my own and do not necessarily reflect those of my employer or Microsoft. AI tools were used to assist with structure, spelling, and grammar — not for content authoring or ideas.

Beginner To Builder with Azure AI Foundry

Daniel McLoughlin — Mon, 31 Mar 2025 16:22:38 GMT

Does anyone else feel utterly overwhelmed by the concept of learning generative AI, or is it just me?!

I love the variety you get when working in tech, but the rate of change can be hard to stay on top of - and when it comes to GenAI, it feels like it’s flying past me at a rate of knots.

I like to think I’m a dab hand with ChatGPT and Copilot, and I’ve done my fair share of prompting, but these days I can’t open LinkedIn without being bombarded by posts and images on topics like Agentic AI, MCP, and don’t even get me started on the latest image generation features from OpenAI…

👆 Yes - I made the image above using ChatGPT. Sorry, not sorry.

I’m taking it upon myself to go deeper into the world of AI, but I know I need to narrow the scope to avoid being overwhelmed. I also want to build on the skills and experiences I already have with Microsoft Azure. That way, I’m laying foundations on solid ground - not starting from absolute zero.

I’ve got a rough idea of where to begin (shoutout to the Azure AI Fundamentals certification on Microsoft Learn), but I find even that content fairly broad. And I know from experience: I learn best by doing.

Why Azure AI Foundry?

That’s why I’ve decided to anchor my learning on Azure AI Foundry - using the Fundamentals content as background reading, and getting hands-on within a self-contained platform that lets me move from beginner to builder, one step at a time.

I’ve chosen this platform because it offers a safe, structured space to explore GenAI specifically within the Azure ecosystem - my area of expertise - without the chaos of piecing everything together from scratch.

Azure AI Foundry brings together the key elements needed to build, customise, deploy, and scale GenAI-powered applications - all in one place. For someone like me, looking to explore real-world use cases without getting lost in the weeds, that’s a huge advantage.

What to Expect from This Series

I’m calling this series Beginner to Builder with Azure AI Foundry, because - quite literally - that’s the journey I’m on. I’ll be learning in public, documenting my findings, and sharing them in a way that helps others who might be in a similar place.

Expect posts that:

Break down AI Foundry into digestible, logical chunks
Explore strategic planning, customisation, optimisation, and operational considerations
Reflect on real-world applicability, not just technical possibilities
Speak to those who are curious but unsure where to start

If you’re keen to explore GenAI from a practical, Azure-first perspective - without trying to absorb everything at once - this series is for you.

First post dropping soon - keep an eye out!

Archive: Microsoft Azure AI Landing Zones

Daniel McLoughlin — Tue, 08 Aug 2023 12:15:25 GMT

Note: This article has been archived.

To say it’s a hot topic at the moment would be the understatement of the year!

One need only look at Microsoft’s announcements from Build and Inspire this year to understand the scale of their investment into AI. They’ve not only launched new AI driven products such as the Azure OpenAI Service and Bing Chat Enterprise – they’ve been baking it into what feels like their entire product set through the likes of Microsoft 365 Copilot, Microsoft Sales Copilot, GitHub Copilot and more. Microsoft has even partnered with Meta (the owners of Facebook et al.) to invest in Llama 2, a large language model (LLM) akin to ChatGPT (albeit with different use-cases).

Given the plethora of Microsoft marketing campaigns, announcements, updates, and initiatives such as the Microsoft Learn AI Skills Challenge, it’s understandably easy for those of us of working in the Microsoft space to fall down the rabbit hole of AI and lose sight of the bigger picture.

Consider OpenAI’s ChatGPT for example. It’s become so well known, even my non-technical friends and family have asked me about it. Conversational AI such as ChatGPT, and other generative AI such as OpenAI’s DALL·E 2 and Codex only form part of a much wider AI offering.

Consider the recently renamed Azure AI services offering from Microsoft. Whilst ChatGPT may be stealing the limelight, incredibly powerful AI based solutions such as Cognitive Search and Speech offer a plethora of AI based capabilities. Also, let’s not forget Azure Machine Learning, which rather confusingly seems to have been classified outside the Azure AI services grouping.

The point I’m trying to make is that AI, particularly in Azure, is way more than just OpenAI based solutions like ChatGPT.

The bigger picture, however, does not stop there. What good is AI without the data that feeds it, or the infrastructure that hosts it? And what good are either of those things without security, and governance, and connectivity, and so on….

AI in Azure is not something deployed in isolation. Not for anything beyond a dev/test scenario, anyway.

Consider the below Azure Speech Services solution:

In addition to the Azure Cognitive Services both for Language and Speech, there is data in the form of blob storage, processing in the form of Function Apps and presentation in the form of a Web App and Power Bi. The solution comprises several individual components working together.

Now, consider the security and governance aspects of this solution: Is each resource accessible from the internet, or behind a Private Endpoint? Can anyone in your organisation get read access to the data, or is it restricted to specific users or groups? What if multiple instances (and variations thereof) exist, such as production, development and testing environments?

This is where Landing Zones come in.

Applied at either an application level (such as in the above scenario) or at a platform level (covering your entire Azure tenant and subscriptions), an Azure Landing Zone can be used to define and maintain key design principles, such as security and governance.

Our sample solution could be deployed over multiple Azure subscriptions - one per environment. The subscription can be used as a boundary for both costs but also access. For example, the production environment is deployed to its own subscription. Access onto that subscription is applied via Role Based Access Control (RBAC) only to those users/groups that need it, and Azure Policy is used to audit or even enforce rules, such as the regional location to which resources can be deployed. You'd apply the same concept to a development environment for example, where you'd apply subscription level budgets to prevent costs spiralling out of control, and use Azure Policy to prevent the deployment is highly expensive SKUs.

You can scale this concept out even further, and have centralised resources such as a firewall and VPN gateway providing hub and spoke network topology, and so on.

You'd typically define your platform and application Landing Zones as infrastructure-as-code (IaC) such as Terraform or Bicep, maintain the code within source control, such as GitHub or Azure Repos, and deploy them via pipelines, such as GitHub Actions or Azure Pipelines. Doing so can ensure consistency, compliance and the application of best practice.

So how does this tie back to AI again?!

A couple of weeks ago, Microsoft released a reference architecture for an Azure OpenAI Landing Zone. Seen below:

What you're looking at here appears to be nothing more than a slight extension to the Microsoft provided reference architecture for an enterprise scale Azure landing zone, pictured below:

Note that in Microsoft's AI Landing Zone example, they only reference OpenAI!

What Microsoft have shared with us is their best practice approach to integrating Azure AI resources within a wider context, such as an application or platform level Landing Zone. This includes the likes of Private Endpoints, Network Security Groups and Web Application Firewalls. They also address concepts such as load balancing, monitoring, and identity management.

Building out this solution is way more complicated than it looks (for example via IaC and pipelines), especially with the complexities of private networking in Azure, but to me, this highlights the point I made earlier: AI in Azure doesn't exist in isolation.

Yes, it's new, shiny and very exciting. The possibilities are endless - and it's totally fine to get caught up in the hype! From an Azure perspective, however, implementing AI based resources needs to be as carefully considered as that of any other resource, such as a SQL Database or Virtual Machine. The AI itself is only as good (performant, secure, scalable, resilient etc.) as the infrastructure it's deployed on, and the environment it's deployed onto. Azure Landing Zones exist to help ensure just that.

Archive: Recovering From A Deleted Terraform State File

Daniel McLoughlin — Mon, 17 Apr 2023 12:15:25 GMT

Note: This article has been archived.

Context: The article refers to Terraform and Microsoft Azure, but the underlying concepts would likely apply to any Terraform resource provider.

The "how" isn't important here (you'd need to buy me a drink to get it out of me!) - but what you need to know is this:

Late last year, I was faced with a situation where one of my customers attempted to do a Terraform deployment to their Production environment, only to find the Terraform state file was missing! Not only that, the entire Storage Account hosting the state file had been deleted, along with the Staging environment state file as well.

The Storage Account in question had 14 day soft delete enabled, however, this issue was discovered on the 15th day, and Microsoft confirmed there was no way to recover the data.

The Terraform state file had been permanently deleted, and the customer's Production and Staging deployments were now blocked.

The Terraform state files for both Production and Staging needed to be manually recreated.

This is the story of how got out of this mess...

Rebuilding The Storage Account

The first thing I needed to do was create a new Storage Account in which to host the re-created state files.

It turns out the previous (now deleted) one had a very generic name (xxxxshared), so it really wasn't obvious what it was used for. It also turns out that it didn't have any resource locks to prevent accidental deletion, nor did it have any tags for further identification or metadata. The RBAC was somewhat suitable given the context, but clearly the data protection settings (14 day soft delete on blobs) were not.

The new Storage Account was given a name and tags by which it was VERY obvious what it was used for, and a resource lock was applied to prevent accidental deletion. The soft delete timeframe was extended, and snapshots were also enabled. The more data protection on this, the better!

Rebuilding The State File

The problem with the state file being deleted is that when you run a terraform plan, Terraform thinks that everything needs to be created from scratch, as if it were deploying to a clean environment.

When you try to run a terraform apply, Terraform throws a massive wobbly, complaining that resources exist in Azure, but not in state - which, to be fair, is totally accurate.

Error: A resource with the ID "/subscriptions/xxxxxx/resourceGroups/rsg-uks-xxxxxx" already exists - to be managed via Terraform this resource needs to be imported into the State. Please see the resource documentation for "azurerm_resource_group" for more information.

The way to fix that is to run the terraform import command, where you pass in the Terraform resource ID and the corresponding Azure resource ID.

Thomas Thornton has an excellent blog post on this, here.

terraform import azurerm_resource_group.xxxxxx /subscriptions/xxxxxx/resourceGroups/rsg-uks-xxxxxx

In itself, this is a fairly simple approach, however, this particular Terraform deployment was incredibly complex. It was partially modular, riddled with resource interdependencies, and it was huge, absolutely huge! For context, the state file for the development environment was 58,176 line long! I don't recall the number of Azure resources that were deployed, but there were a lot of them, in one big Terraform deployment.

This presented a rather large challenge when coming to run the terraform import commands (which I would need to do per resource). Firstly, how on earth was I going to get a list of every single Terraform resource, and then how would I get the corresponding Azure resource ID. Given the size and complexity of the Terraform deployment, this was going to be a challenge.

My saving grace is that I was able to get hold of the pipeline logs from the previous deployment to Staging.

From there, I was able to extract the Terraform terraform apply output, and from that I could parse the file (using PowerShell and some manual tweaking) to come up with a list of both Terraform and Azure resource IDs. The output of this was a whopping big script of multiple terraform import commands that I could run to rebuild the Staging state file.

For a reason I can no longer recall, the terraform apply output was all I could get access to at this time. I think it was down to the plan being output to file and saved as a build artifact, which was eventually removed.

With Production however, I was not so lucky. The Staging deployment was done recently in readiness to eventually deploy to Production. The most recent Production deployment logs were long gone due to a retention policy,

This meant that Staging was a version ahead of Prod. Therefore, there were infra differences between the two environments, so I couldn't just duplicate the Staging state file and do a search and replace on the subscription and resource names.

To get around this, I had to repeatedly run terraform import followed by terraform plan to capture the Terraform resource IDs, and manually match them to the Azure resource IDs. Updating as I go for anything the plan output flagged as being missing. Thankfully, several of the resource IDs could be pinched from the Staging work I did earlier, and repeatedly running terraform import followed by terraform plan allowed me to fill in the gaps. In was a painstaking process.

Deployment Issues

I discovered some resources simply could not be imported back into state.

One example of this was with the use of randomly generated uuid strings for the use of creating unique Storage Account names. The customer was using the random_uuid Terraform resource, such as the below:

resource "random_uuid" "ruuid" {}

resource "azurerm_storage_account" "xxx" {
  name                      =   substr(replace("xxx${random_uuid.ruuid.result}", "-", ""), 0, 23)
  resource_group_name       = var.rsg_name
  location                  = var.location_name
  account_tier              = "Standard"
  account_replication_type  = "LRS"
  enable_https_traffic_only = true
  min_tls_version           = "TLS1_2"
  tags                      = jsondecode(var.environment_tag)
  blob_properties {
    versioning_enabled = true
  }
}

With the above, the randomly generated UUID existed in state as its own entity. This would be something like aabbccdd-eeff-0011-2233-445566778899. The Storage Account name consisted of only part of this UUID, and that depended on the friendly name that was prepended to it. With the above example, the Storage account would be called: xxxaabbccddeeff00112233, but obviously this differed between Storage Accounts.

As I didn't know the original full UUIDs, there was no way I could import it back into state.

To get around this, I got a bit hacky by taking the UUID part of every existing storage account, and converting that into a UUID by adding a shed load of random numbers, being careful to add the hyphens in the right place. For example:

terraform import random_uuid.main aabbccdd-eeff-0011-2233-666666666666

Needless to say, it was a hacky faff, but it worked.

Another fairly critical issue I faced was with RBAC role assignments. For example:

resource "azurerm_role_assignment" "example" {
  scope                = data.azurerm_subscription.primary.id
  role_definition_name = "Reader"
  principal_id         = data.azurerm_client_config.example.object_id
}

These were numerous and existing in multiple different modules. I was able to get the Terraform resource IDs easy enough, but the corresponding Azure resource ID proved to be a nightmare, as they exist as GUIDs.

For example:

terraform import azurerm_role_assignment.example /subscriptions/00000000-0000-0000-0000-000000000000/providers/Microsoft.Authorization/roleAssignments/00000000-0000-0000-0000-000000000000

I was able to run the PowerShell command Get-AzRoleAssignment (source) to pull the IDs from Azure, but the problem here was the sheer amount of these to identify. It wasn't just a case of user IDs on a subscription or resource group, oooh no, there were also many, many inter-resource role assignments, for example a Function App Managed Identity with an RBAC role of "Azure Service Bus Data Sender" applied to an Azure Service Bus.

I was able to script this in PowerShell to pull a great big list of every single role assignment, and then did a lot of searching of the Terraform config to match the IDs.

Even with this in place, the terraform import command still failed on some, but not all, role assignments. Either I'd made mistakes when matching the IDs, or something else under the hood with Azure.

Ultimately, due to the complexity and time pressures, we had to manually delete some role assignments and let Terraform recreate them on the next apply.

Deployment Prep

Before the Production terraform apply was run following the state file recreation, I made a point of taking manual backups of the Key Vault secrets, App Config contents and ensuring the databases had good enough backups. Anything that was deemed critical and could potentially have been impacted by the deployment was backed up.

I mention this here should you be reading this article faced with a similar situation. May this be your prompt to make backups and be prepared for the worst!

Lessons Learned

As I'm sure you can imagine, this was a stressful time for both myself and my customer. The workarounds mentioned above were complex and far from ideal. Ultimately, the problem was resolved once the state files had been recreated, and terraform plan and apply jobs had been run against it.

If you're ever in this position, then I really feel for you, and may this article act as a reference on how I got out of it.

For anyone reading this, I would strongly suggest following the below Lessons Learned to hopefully avoid landing yourself in a similar situation. If you can think of any more, let me know!

When saving remote state in an Azure Storage Account:
- Give the Storage Account a suitable, easily identifiable name.
- Apply adequate data protection, such as soft delete and snapshots.
- Apply adequate access control, such as RBAC, ABAC and network restrictions where appropriate.
- Apply tags.
- Apply a resource lock.

In my customer example, we deployed dedicated Storage Accounts to contain the state files for both Staging and Production. Both with the above points applied.
Make backups of your Terraform plan and apply outputs. For example, add a pipeline step to save them to blob storage (with blob retention policies applied).
Terraform resources such as role assignments and RUUIDs are very difficult to recreate in state. Review the documentation carefully to fully understand their application.
Run Terraform Apply very carefully, especially when testing fixes. Don't use auto approve in this context, and carefully review the Terraform Plan outputs.
Have adequate documentation, ideally with diagrams. Knowledge is power in this scenario.
If you don't have one already, have a disaster recovery plan, and consider adding a scenario such as this to it. For example, if you have to go through something such as this, can you get access to your Terraform variable file contents and environment variables (for example GitHub secrets)? Can you run a deployment locally if you really had to? Proper Planning and Preparation Prevents P!ss Poor Performance!
Follow Terraform best practice. My personal advice would be to use a modular approach and have multiple smaller deployments (by component lifecycle for example) rather than one large, complex deployment (and therefore one large, complex state file). Having said that, there isn't a one-size-fits approach, so do what's right for your given scenario. Checkout Terraform Recommended Practices for more detail.

Archive: The Realities of Azure Private Endpoints

Daniel McLoughlin — Fri, 14 Apr 2023 12:15:25 GMT

Note: This article has been archived.

Following on from my previous article Private Endpoints and Terraform - A Tale of Time - I want to go into more detail about what my experience working with Private Endpoints has been like.

The use of Private Endpoints is an increasingly popular choice, and Microsoft suggest their use is considered best practice (ref), however, I feel a lot hinges on what your definition of the word 'private' really means.

In this article, I’ll go over what Private Endpoints are when compared to Service Endpoints and will provide examples of what I feel are the realities when working with them.

What is a Private Endpoint?

To avoid repeating myself, the below is an extract from my Tale of Time article (link above) that covers how I defined what a Private Endpoint is:

A Private Endpoint adds a network interface to a resource, providing it with a private IP address assigned from your VNET (Virtual Network). Once applied, you can communicate with this resource exclusively via the VNET.

The alternative to Private Endpoints is Service Endpoints, where the resources are still accessible over the public internet, however, their integrated firewalls restrict access only to designated VNETS/subnets or public IP addresses.

Private Endpoints are more secure in this context but come with additional complexity.

Once applied with a Private Endpoint, a resources endpoint is no longer publicly routable.

Private DNS Zones solve this issue. Linked to one or more VNETS, a Private DNS Zone holds DNS records for the private resources. When you deploy a Private Endpoint and link it to a Private DNS Zone, the resources public IP is updated with a CNAME record pointing it to the Private DNS Zone.

For example, mystorageaccount.blob.core.windows.net would point to mystorageaccount.privatelink.blob.core.windows.net, pointing it to something like 192.168.0.8.

Any VNET linked to one or more Private DNS Zones will resolve those endpoints privately.

Source: What is a private endpoint?

The Realities

With Service Endpoints, a PaaS resource is still publicly available. You can configure inbound traffic to come in either from designated public IPs or from within the VNET itself. The resource itself is still accessible online.

With a Private Endpoint, however, there is no option to allow designated public IPs. Traffic comes in from the VNET, or not at all.

Because of this, performance may be improved by reducing network latency as communication stays within the Microsoft network backbone.

Also note that you can apply network policies for Private Endpoints (NSGs and Route Tables on the subnet hosting them) so you can get granular control over your network traffic.

In a nutshell, using a Private Endpoint provides the most private and granular level of network access to a resource. But what does private in this context really mean, and do the cons of using a Private Endpoint outweigh the pros?

Consider the below:

Control Plane vs Data Plane

It's important to note the difference between control plane and data plane operations.

For example, let's presume we have an Azure Storage Account with a Private Endpoint applied for the blob endpoint. A control plane operation would be something like using the Azure CLI to return the account keys. A data plane operation would be something like listing blobs within a private container.

With a Private Endpoint applied for the blob endpoint, you can perform control plane operations regardless of your presence on the VNET. Yes, you need to be authenticated, but your source IP does not matter in this context.

With a data plane operation, however, you can only perform operations if you are coming at it from within the VNET.

I point this out here to highlight that adding a Private Endpoint does not make the resource totally private, only specific operations.

This is important when setting expectations.

DevOps & IaC

From a DevOps perspective (i.e. using pipelines to deploy infrastructure-as-code), you'll likely need to use self-hosted runners that have network connectivity onto the VNET on which the Private Endpointed resources are going to reside. Using a hub and spoke example you could deploy a VM within the hub that hosts the DevOps agents, ensuring the hub VNET is peered and routable to the spoke VNETS that have the Private Endpointed resources on.

As per my article Private Endpoints and Terraform - A Tale of Time, the automated deployment of resources with Private Endpoints introduces further complexity when the likes of Terraform try to deploy resources in parallel but get chewed up when a resources network config changes part way through.

Network Complexities

Imagine you have a hub and spoke network topology. In your hub, you have a VNET and shared Private DNS Zones. There are multiple spokes that each have their own VNET, including resources with Private Endpoints applied.

The hub VNET would need to peer with each spoke VNET, and every Private DNS Zones would need to be linked to the hub VNET and every single spoke VNET.

Best practice would dictate that there are granular permissions in place to separate the hub from the spokes. For example, the hub and each spoke could be on dedicated subscriptions with individual RBAC policies applies.

This may sound fairly straightforward, but consider how a Terraform deployment would deploy a spoke environment. The deployment would need to be on a self-hosted runner, likely in the hub to facilitate network connectivity. The Terraform deployment would also need to utilise multiple identities (e.g. Service Principals) to have the correct RBAC level access to both the hub and the spoke.

Costs

A single Private Endpoint costs approx £7.55 per month. Multiply that by how many resources you plan to add a Private Endpoint to, over how many environments you need to deploy, and the result can be expensive. Especially when you consider resources like Storage Accounts that have multiple endpoints (blob, table, file, queue) and therefore need multiple Private Endpoints for every endpoint used.

Furthermore, a single Private DNS Zones also costs approx £7.55.

Source: Pricing calculator

Examples

What I want to do here is demonstrate some of the realities of working with Private Endpoints, using a Storage Account as an example.

Core Infrastructure

My core infra consists of a resource group called rsg-pe-testing and a VNET called vnet-uks-01. Within the VNET I've created a dedicated subnet for all Private Endpoints.

I've also created a Virtual Machine called vm-uks-jumpbox, attached the to above VNET. I'll be using this as a point of access to my VNET. I opted for a Ubuntu 20.04 VM so I don't have to faff about with an OS GUI and I can jump right into the CLI.

Storage Account

For my first example, I've created an LRS Storage Account called strukspetestingdmclo01. By default, I've left the network connectivity open to public access.

Before we move on, I want to talk about the above screen a little bit. I interpret the middle option 'selected virtual networks and IP addresses' to be related to public internet access and Service Endpoints. This is where direct internet access is still routed to the Storage Account through whitelisted public IPs or via Service Endpoints on the Microsoft backbone.

I interpret the bottom option as the one to select if I wanted to use a Private Endpoint i.e. public internet is outright blocked and the only allowed inbound traffic is from within the VNET itself.

Note the text in the above screenshot is from the Azure portal when first creating the Storage Account. Once within the Storage Account page itself, under the Networking blade, that option simply says 'Disabled'.

Under the Endpoints blade of the Storage Account in the Azure portal, I can pull the different endpoints for the Storage Account, such as Blob and Table. As expected, these currently resolve to a public IP address from both within and external to my VNET.

Service Endpoints

To prove the point that the Storage Account is still exposed over the public internet, I enable the Microsoft.Storage Service Endpoint on the subnet that the VM is running on and configured my Storage Account to only allow traffic from that specific subnet. This can be a faff to do in the portal as if you forget to click on the Save button, your changes won't be applied!

Once applied, the nslookup command both internally and externally still resolves the public IP address of the Storage Account - as expected here.

To further prove the point, I used the Azure CLI on both the Jump Box (inside the VNET - left pane) and my laptop (outside the VNET - right pane) to try and create a new blob container. As expected, it worked from within the VNET, but not from the outside. Creating a blob container is a data plane operation.

Note that the VM has a Managed Identity assigned and both that, along with the user account from my laptop have the Storage Blob Data Owner RBAC role applied to the specified Storage Account.

Private Endpoints

Next, let's see what happens when I simply click the 'Disable' radio button on the Networking blade (before any Private Endpoints have been created).

What I'm expecting to see here is an outright block of any network ingress to the Storage Account.

As you can see, the nslookup command still resolved the endpoint DNS to a public IP address, but the Azure CLI command to create a new container is blocked both internally and externally due to the network rules.

This suggests to me that the Storage Account endpoint is still resolvable, but not routable. What I understand to be happening is that all traffic (regardless of source) is still hitting the Storage Account directly, but it's the integrated firewall that's blocking the requests.

Now (clearly) I'm not a network expert, far from it, but this doesn't sit right with me. If I wanted my Storage Account to be totally private and only accessible over the VNET, I'm not sure I'd be happy about this. In theory, I could run a denial-of-service attack on the Storage Account as it's still reachable online.

I turned to the docs to see if there was anything official to back this up, but all I came out with was the below:

I created a new storage account called strukspetestingdmclo02 with networking disabled during the creation wizard in the portal, however, this yielded the same results.

Let's see what adding a Private Endpoint does to this. After all, in the above test I am hitting the public endpoint, so let's flip this and run the same tests.

For strukspetestingdmclo02 I create a new Private Endpoint and a Private DNS Zone for privatelink.blob.core.windows.net. The Private DNS Zone is linked to my VNET, and I can see that the blob endpoint for my Storage Account has been assigned an internal IP of 10.0.1.4.

Running nslookup on the Jump Box returns the private IP as expected, but my laptop returns the public IP still.

Trying to create a new container yields the same results too. It works from the Jump Box, but my laptop is blocked by the network rules applied to the integrated firewall, not because it cannot reach it. Again, this is a data plane operation. A control plane operation such as returning the account keys still works from both devices.

Repeating the same tests on an Azure Function app confirms my theory. With public access enabled, the default landing page is displayed from my laptop:

However, with a Private Endpoint applied, I am presented with a 403 Forbidden error. I'm still hitting the Function App directly, but its integrated firewall is blocking my requests - it's not that I outright cannot route to it.

Summary

So what am I getting at here exactly?

First of all, I've demonstrated that the use of Private Endpoints, or simply setting a resource to Disable public access doesn't actually disable public access. Not in the true sense of the word. Public traffic still reaches the resource, it's just blocked by an integrated firewall.

In my mind I presumed this would work in the same way as deleting a Public IP address from a VM would work i.e. public traffic cannot in any way shape or form hit the resource.

Also note that a Private Endpoint will only protect data plane operations, not the control plane.

To be nit-picky, a Private Endpoint is not actually private. It's just more private that the other options!

This may be an important consideration when working with security-conscious customers. Customers like these may wrongly presume that following Microsoft's best practices and adding Private Endpoints will totally render their environment offline, which isn't strictly true.

Private Endpoints are the most private and granular level of network access you can define on an Azure PaaS resource, but the term 'private' needs to have the correct expectations set.

Conclusion

In summary, Azure Private Endpoints and Service Endpoints both offer secure communication between virtual networks and Azure services, but they differ in their approach and benefits.

Private Endpoints provide a more secure and efficient communication option but introduce added costs and complexities. Also, be clear on the term 'private', as it can mean different things to different people.

Service Endpoints, on the other hand, are easier to configure and support, but do not provide as private connectivity to Azure services as Private Endpoints would.

When choosing between Private Endpoints and Service Endpoints, organisations should consider their security and performance needs, as well as the specific Azure services they plan to use. With the right configuration, both options can help organisations achieve a secure and efficient cloud environment.

Feedback

Your feedback is welcome here. Networking is out of my comfort zone, and the above article is based on my experiences and opinions. Please feel free to comment or get in touch. Thank you.

Archive: Private Endpoints and Terraform - A Tale of Time

Daniel McLoughlin — Sat, 25 Feb 2023 13:15:25 GMT

Note: This article has been archived.

Adding Private Endpoints to resources in Azure is an excellent way to secure their connectivity by preventing access over public internet. Taking resources offline however adds its own challenges, particularly when a resources DNS changes part-way through a parallel deployment.

This article highlights the pitfalls with deploying private resources in Azure via Terraform, and how to overcome them.

This article is also my contribution to Azure Spring Clean 2023 - aimed at promoting well-managed Azure tenants.

Mission Statement

I've been brought in to help a customer with a complex Terraform deployment.

Their application infrastructure consists of an Azure Web App front-end, and multiple back-end components including Storage Accounts, Key Vaults and Cosmos DB.

Their existing Terraform is modular, however, the entire solution is deployed in one run.

The infra deployment is via GitHub Actions on a self-hosted runner, running on an Azure VM.

I've already worked with this customer to implement a hub and spoke network topology, where centralised resources such as the self-hosted runner and Private DNS Zones are in the hub, and the application itself is deployed as a spoke.

The app infra deployment peers the spoke VNET to the hub VNET, and links the hubs Private DNS Zones to the spoke VNET.

The infrastructure deployment is throwing a lot of very confusing errors.

My job is to solve the problem.

Replicating The Issue

The Terraform deployment is complex, but I know the errors are specific to Private Endpoints. To save time and remove complexity, I replicate the scenario with a stripped-down Terraform config, deploying a smaller number of resources, as per the below:

My Terraform deployment does the following:

Deploys the spoke VNET and a subnet called Endpoints (for the Private Endpoints).
Peers the spoke VNET with the hub VNET (and vice versa).
Links the hub Private DNS Zones to the spoke VNET.
Deploys a Key Vault with a Private Endpoint, and sets the network rules to deny public access.
Deploys a number of Storage Accounts, each with multiple blob containers, tables and queues.
Each Storage Account will need 3 x Private Endpoints, one for blob, one for table and one for queue.
The network rules for each Storage Account are set to deny public access.
The primary key for each Storage Account is saved as a secret within the Key Vault.

This is only a sample of what the wider app infra looks like.

You can see my Terraform for this in my GitHub repo, here.

What is a Private Endpoint?

A Private Endpoint adds a network interface to a resource, providing it with a private IP address assigned from your VNET. Once applied, you can communicate with this resource exclusively via the VNET.

The alternative to Private Endpoints is Service Endpoints, where the resources are still accessible over public internet, however, their integrated firewalls restrict access only to designated VNETS/subnets or public IP addresses.

Private Endpoints are more secure in this context but come with additional complexity.

Once applied with a Private Endpoint, a resources endpoint is no longer publicly routable.

For example, mystorageaccount.blob.core.windows.net would point to privatelink.blob.core.windows.net, pointing it to something like 192.168.0.8.

Any VNET linked to one or more Private DNS Zones will resolve those endpoints privately.

In the context of my solution, the Private DNS Zones need to be linked to both the hub and spoke VNETS so that resources attached to either VNET can resolve private DNS requests correctly.

Below is an example of a Private DNS Zone for blob.core.windows.net:

In this solution example, the Private DNS Zones are centralised in the hub, so they can be shared amongst multiple spoke environments.

Source: What is a private endpoint?

Understanding The Errors

Using my stripped-down sample, I've been able to replicate the errors my customer has been experiencing.

The one thing they all have in common is StatusCode=403 (HTTP Forbidden).

Sometimes the error is thrown when trying to save the Storage Account key as a Key Vault secret, other times it fails to create a particular blob container or storage queue, again, with a 403 error. There's no consistency - but it's clearly network related.

The interesting point here is that these errors only happen on the first run. If I re-run the entire deployment, everything works.

The issue here was clearly to do with time.

Terraform (quite rightly) is trying to deploy as much as it can in parallel whilst working out its own dependency maps.

Terraform may understand that the Key Vault needs to exist before the Storage Account key can be written as a secret, but whilst it's queuing up its list of resources to deploy their network settings are changing. What was originally publicly resolvable is now exclusively privately resolvable. The DNS has changed!

A re-run of the same deployment does not replicate the issue as Terraform can determine the network change, but also the self-hosted runner can pick up on it too.

I have a distant memory of something like this happening in Bicep a while ago, but I can't recall the specifics. I have a suspicion the underlying issue could be down to the Azure APIs under the hood. Either that or it's simply a race condition issue, or possibly DNS caching, either on the runner or in Terraform itself.

I can't be certain of the exact root cause on this one, but I'm going to blame it on DNS...

Considering My Options

My first instinct was to split this rather large and complex deployment into multiple, smaller deployments according to resource lifecycle. For example, different Terraform deployments for the VNET, Key Vault and Storage Accounts.

Whilst this would have been a relatively simple job for my stripped-down sample, the customer's full-blown solution was far more complex and would have required significant re-work.

The issues would have been distributing the config between multiple deployments, and capturing the outputs of one deployment as input for another over a matrix of linked resources and modules.

I considered tools such as Terragrunt to centralise the config, but the customer wasn't keen.

I needed to get my hands dirty with some Terraform!

A Tale of Time

The code for my working solution can be found in my GitHub repo, here.

The first thing I did was determine the order in which resources were created. Primarily within the Storage Account module.

For example, I used depends_on blocks to specify that the Private Endpoint goes on only after the containers, tables and queues have been created. The resource to deny all public access to the Storage Account was set to go on last.

resource "azurerm_storage_account_network_rules" "example" {
  storage_account_id = azurerm_storage_account.example.id
  default_action     = "Deny"
  ip_rules           = []
  bypass             = ["None"]
  depends_on = [
    azurerm_storage_container.example,
    azurerm_storage_queue.example,
    azurerm_storage_table.example,
    azurerm_private_endpoint.private_endpoint
  ]
}

This helped, but I was still getting some ad-hoc 403 errors. I needed to allow time for the VNETs to peer, and DNS to propagate.

I solved this by adding some cheeky little sleep timers, using the Terraform time_sleep resource.

resource "time_sleep" "peering_propagation" {
  create_duration = "2m"
  triggers = {
    peering_confirmation = module.vnet.peering_confirmation
  }
}

Within the VNET module, I set an output of the ID provided from the peering with the HUB VNET. Once the peering had been completed and the ID was produced, Terraform then waits for 2 minutes.

I did the same thing with the VNET links to the Private DNS zones in the hub, and also the creation of the Key Vault. For example:

resource "time_sleep" "vault_endpoint_propagation" {
  create_duration = "2m"

  triggers = {
    propagation = module.private-key-vault.vault_endpoint_propagation
  }
}

Terraform will wait for 2 minutes once the Private Endpoint resource ID has been produced.

To determine the order in which my modules were deployed (e.g. don't run the Storage Account module until the Key Vault has a Private Endpoint applied), I used the depends_on block again, but this time linked to the sleep timer.

module "private-storage-account" {
  source               = "./private-storage-account"
  count                = var.resource_count
  tags                 = local.tags
  app_name             = local.app_name
  location             = local.location
  resource_group_name  = azurerm_resource_group.rg.name
  virtual_network_name = module.vnet.spoke-vnet-name
  endpoints_subnet_id  = module.vnet.endpoints-subnet-id
  private_dns_zone_ids = data.azurerm_private_dns_zone.dns_zones
  key_vault_id         = module.private-key-vault.key_vault_id
  depends_on = [
    time_sleep.vault_endpoint_propagation
  ]
}

Now, the Storage Account module will not run until the Key Vault has a Private Endpoint, and two minutes have passed, allowing time for DNS propagation.

Thankfully both mine and the customer's Terraform config is modular. So any module that needs access to the Key Vault, or to otherwise resolve private DNS can be set to wait until the prerequisite resources have been deployed first.

It's not pretty, but it works!

Testing The Solution

By running the fixed Terraform config and monitoring the output, I can clearly see the resources are being deployed roughly in the right order of what I set. Anything that can be done in parallel will be handled by Terraform.

The sleep timers add some delay to the total time the deployment takes to complete, but it's better than waiting for it to fail and having to re-run it every time.

Another thing to note here is that before my fix was applied, Terraform destroy would also throw similar 403 errors. Following my fix, this is no longer an issue

Top Tips

These are some tips I've picked up whilst working on this solution:

If your GitHub Actions run on a self-hosted runner, add an action to flush DNS before running a plan or apply. If DNS changes have been made on the network (such as adding Private DNS zones) - this will clear things up. For example:

Use command line tools (on the runner itself) to check the DNS resolution of a particular endpoint, for example: nslookupclouddevdan-kv.vault.azure.net
If your Terraform code needs to interact with resources in a different subscription or resource group (such as with my example, performing write actions on the hub VNET by establishing a peer), you can use an additional Terraform azurerm provider and use it to specify different credentials and tenant/subscription IDs. For example:

# provider.tf
provider "azurerm" {
  alias           = "hub"
  subscription_id = var.hub_subscription_id
  tenant_id       = var.az_tenant_id
  client_id       = var.azure_cli_hub_networking_client_id
  client_secret   = var.azure_cli_hub_networking_secret
  features {}
}

# vnet module call in main.tf (referencing the additional provider with alias "hub" (set above)
module "vnet" {
  source                         = "./vnet"
  resource_group_name            = azurerm_resource_group.rg.name
  location                       = local.location
  tags                           = local.tags
  virtual_network_name           = local.virtual_network_name
  hub_resource_group_name        = data.azurerm_resource_group.hub-rg.name
  hub_virtual_network_name       = data.azurerm_virtual_network.hub-vnet.name
  hub_virtual_network_id         = data.azurerm_virtual_network.hub-vnet.id
  address_space                  = local.address_space
  endpoints_subnet_name          = local.endpoints_subnet_name
  endpoints_subnet_address_space = local.endpoints_subnet_address_space
  providers = {
    azurerm.hub = azurerm.hub
  }
}

# within the vnet module main.tf, set:
terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "=3.47.0"
      configuration_aliases = [ azurerm.hub ]
    }
  }
}

# peering hub to spoke vnet using the "hub" provider
resource "azurerm_virtual_network_peering" "hub-to-spoke" {
  provider                     = azurerm.hub
  name                         = "hub-to-${var.virtual_network_name}"
  resource_group_name          = var.hub_resource_group_name
  virtual_network_name         = var.hub_virtual_network_name
  remote_virtual_network_id    = azurerm_virtual_network.vnet.id
  allow_virtual_network_access = true
  allow_forwarded_traffic      = true
  allow_gateway_transit        = false
  depends_on = [
    azurerm_virtual_network_peering.spoke-to-hub
  ]
}

Conclusion

What I've learnt from this is that you can't always apply best practices.

No matter how much you may want to, sometimes your hands are tied and you need to make good on a tricky situation.

My solution may appear to be a tad hacky, but from a bigger picture, it's relatively simple. All I'm doing is controlling the order in which some Azure resources are deployed in Terraform, and adding in small time delays in between some of them to account for network changes.

Thanks for reading!

All my source code is available within this GitHub repo.

Source of cover photo by Icons8 Team on Unsplash

Daniel McLoughlin ☁️

Microsoft App Modernization Guidance for Azure

What is the Microsoft App Modernisation Guidance?

Why does modernisation matter?

How does it relate to CAF and WAF?

AI-powered modernisation with Copilot

Why I built a visual explorer for this guidance

Final thoughts

Visuals for Azure Governance

Azure CAF

Azure WAF

Microsoft AI Adoption

Why and How

Azure AI Foundry vs Azure AI Services vs Azure Machine Learning

Introduction

Azure AI Foundry: What It Actually Is

What Foundry Is Not

Azure Machine Learning: Where ML Lives

The Portal Rename: The Root of the Confusion

A Quick Word on Using Code

Quick Rule of Thumb

Further Reading

Azure AI Foundry vs Microsoft Copilot Studio

TL;DR – My Quick Take

Azure AI Foundry: What's New From Build 2025

Introduction

Model Router

More Models & More Capacity

Foundry Local

Fine-Tuning & Developer Tier

Multi-agent Orchestration

Identity for Agents

Azure AI Foundry Observability

And The Rest!

Azure AI Foundry: Why Use It?

Introduction

Define and Explore

Model Catalogue

Playground

Build and Customise

Agents

Templates

Fine-tuning

Content Understanding

Prompt Flow

Assess and Improve

Tracing

Evaluation

Safety and Security

Conclusion

🧠 Dan’s AI Terminology Tracker

🗺️ What It Is

🔗 Explore It

🚧 A Few Notes

Azure AI Foundry: What It Is & What It Isn't

Introduction

A Brief History

Azure AI Foundry - What Is It?

Azure AI Foundry - What It Isn’t!

GitHub Marketplace

Azure AI Foundry vs Microsoft Copilot

Conclusion

Beginner To Builder with Azure AI Foundry

Why Azure AI Foundry?

What to Expect from This Series

Archive: Microsoft Azure AI Landing Zones

Archive: Recovering From A Deleted Terraform State File

Rebuilding The Storage Account

Rebuilding The State File

Deployment Issues

Deployment Prep

Lessons Learned

Archive: The Realities of Azure Private Endpoints

What is a Private Endpoint?

The Realities

Control Plane vs Data Plane

DevOps & IaC

Network Complexities

Costs

Examples