With the release of Azure Bicep v0.43.1, two new functions have been introduced: like() and distinct(). In this blog, I will explain how these new functions work and showcase several useful real world scenarios where you can use them in your Bicep deployments. 💪🏻

Like Function

The like() function in Bicep is used to compare a string against a pattern. It returns true when the value matches the specified pattern and false when it does not. Let’s start with a simple example:

param parInput string = 'Hello, World!'
 
output outOutput bool = like(parInput, '*World*')

In this example, the like() function checks whether the value of parInput contains the word World. The wildcard character *means that any characters before or after World are allowed. Since the string Hello, World! contains the word World, the output will return true.

In this example, the like() function is used to check whether the workloadName variable contains the value prod. The workloadName is dynamically created by combining the string xyz- with the value of the parEnvironment parameter. The result of this comparison is stored in the applyLock variable. If the workload name contains prod, the expression evaluates to true. As a result, the resource lock is deployed.

param parEnvironment string

var workloadName = 'xyz-${parEnvironment}'
var applyLock = like(workloadName, '*prod*')

resource lock 'Microsoft.Authorization/locks@2020-05-01' = if (applyLock) {
 name: 'cannot-delete'
 properties: {
  level: 'CanNotDelete'
  notes: 'Production protection'
 }
}

We can see that the output is true because our parEnvironment variable has been assigned the value prod.

In this example, we use the like() function to determine whether the parEnvironment parameter contains the value prod. The parameter is limited to the values prod, test, and acc by using the allowed decorator.

@allowed([
  'prod'
  'test'
  'acc'
])
param parEnvironment string

module appi 'br/public:avm/res/insights/component:0.7.1' = if (like(parEnvironment, '*prod*')) {
  params: {
    name: 'appi-${parEnvironment}'
    workspaceResourceId: 'idHere'
  }
}

Distinct Function

The next function is distinct(). This function can be very useful when working with arrays that may contain duplicate values. The distinct() function returns a new array that contains only the unique elements from the input array. Any duplicate values are removed automatically.

Let’s start with a simple example:

param fruits array = [
 'apples'
 'bananas'
 'apples'
]

var normalizedFruits = distinct(fruits)

output ouFruits array = normalizedFruits

In this example, the fruits array contains the value apples twice. The distinct() function filters out the duplicate value and creates a new array that only contains unique entries. This function is especially useful when processing tags, role assignments, IP ranges, or any other configuration where duplicate values should be avoided.

In this example, the distinct() function is used to remove duplicate IP ranges from an array of IP groups. Each IP group contains a name and a list of IP addresses. First, a new array called ipAddresses is created using a for expression. This extracts the first IP address from each IP group object. Next, the distinct() function filters out duplicate IP ranges and stores only the unique values in the normalizedIpGroupsvariable.

param ipGroups array = [
  {
    name: 'ipGroup1'
    ipAddresses: [
      '192.168.10.0/24'
    ]
  }
  {
    name: 'ipGroup2'
    ipAddresses: [
      '192.168.5.0/24'
    ]
  }
  {
    name: 'ipGroup3'
    ipAddresses: [
      '192.168.10.0/24'
    ]
  }
]

var ipAddresses = [for ipGroup in ipGroups: ipGroup.ipAddresses[0]]
var normalizedIpGroups = distinct(ipAddresses)

module ipGroup 'br/public:avm/res/network/ip-group:0.4.0' = [
  for ipGroup in normalizedIpGroups: {
    params: {
      name: ipGroup.name
      ipAddresses: ipGroup.ipAddresses
    }
  }
]

This can be very useful in scenarios where multiple teams or workloads provide overlapping IP ranges. By removing duplicate entries before deployment, you can avoid unnecessary resources and keep your configuration cleaner and easier to maintain.

That’s all for today. As you could see, the new Azure Bicep functions help you create cleaner, more flexible, and easier to maintain deployments. Whether you are validating naming conventions with like() or removing duplicate values with distinct(), these functions can simplify many real world deployment scenarios. The Azure Bicep code is available in my GitHub repository: GitHub — brianveldman/azure-bicep. Feel free to star the repository and clap for this story and let me know if you have any feedback. I look forward to seeing you in the next session. Until then, take care! ❤️

The NEW Bicep Like and Distinct Functions ✨ was originally published in Microsoft Azure on Medium, where people are continuing the conversation by highlighting and responding to this story.

Yet choosing the “right” base image is still largely guesswork for most teams. Developers pull from untrusted registries, pick popular tags, assume “latest” means “safest,” and move on. The reality is harsher: industry reports consistently show that public container images often ship with known vulnerabilities, and software supply chain attacks continue to rise year over year.

The base image decision is made once but amplified across every build, every deployment, every environment. A single unpatched CVE in your base image becomes a fleet-wide exposure.

We built SBI (Secure Base Image Recommendations) to replace guesswork with data — specifically for Microsoft Container Registry (MCR) images.

Introducing SBI — Secure Base Image Recommendations

SBI is an open-source (MIT) tool that nightly scans configured MCR container base images for vulnerabilities and generates ranked recommendation reports. It answers a simple question: for my language and target OS, which base image has the fewest vulnerabilities and the smallest footprint?

How It Works

Every night at 02:00 UTC, a GitHub Actions workflow runs the full pipeline:

1. Discover — Enumerate image tags from MCR
2. Pull & Analyze — Pull images, generate SBOMs with Syft to catalog installed packages and detect language runtimes
3. Scan — Run Trivy vulnerability scanning
4. Verify — Execute runtime commands inside each container to confirm detected language versions (e.g., python3 --version, dotnet --info)
5. Store — Persist results in a SQLite database
6. Report — Generate ranked reports, commit and push to the repository

The Ranking Algorithm

Images are ranked per language, per base OS using this sort order:

1. Fewest critical vulnerabilities
2. Fewest high vulnerabilities
3. Fewest total vulnerabilities
4. Smallest image size

This means the #1 image in each section is the best-ranked option under SBI’s criteria: lowest known vulnerability count, then smallest size.

What’s Covered

The nightly scan currently covers 37+ image sources across:

• Languages: .NET, Python, Node.js, Java, Go
• Base/No-Runtime: Minimal and distroless images for deploying static binaries (Go, Rust, etc.)
• Base OSes: Azure Linux, Ubuntu, Debian

See the latest report for the full list of scanned images.

Why No Website?

SBI started as a side project — we got tired of manually researching which base images to recommend to teams. We needed something quick and automated, not a product with a web frontend to maintain.

Plain files committed to a Git repo turned out to be the right answer: developers read markdown on GitHub, CI/CD pipelines fetch JSON via raw URLs, and security teams clone the repo and run jq locally. No servers, no hosting, no additional attack surface — just the data.

Three Report Formats — Something for Everyone

SBI generates three report formats nightly, each designed for a different audience and workflow.

📄 Markdown Report — Language-Specific Recommendations

View the latest report →

The markdown report is a human-readable set of ranked tables, organized by language and base OS. Need the best Python image on Azure Linux? The best .NET image on Ubuntu? Just scroll to your language section and pick the top-ranked option.

Each language section is ranked by base OS. For example, in the Go section:

Each entry includes the image digest and a pinned reference (image@sha256:...). For base images in your Dockerfile, you'll typically want the tag (e.g., :3.12) so you automatically pick up security patches when MCR pushes them. The pinned digest is valuable when deploying final images to a cluster or container app, where you want an exact, immutable reference.

The report also includes a “Base / No Runtime” section for minimal and distroless images — useful when deploying statically compiled binaries (Go, Rust) where you don’t need a language runtime at all:

📊 JSON Report — For Automation

View the latest report →

The JSON report provides the same per-language, per-OS rankings in a machine-readable format — a flat array of image objects with language and baseOS fields for easy filtering. Each entry includes:

• pinnedReference — the digest-pinned image reference
• stableTag — the human-friendly tag
• dockerfileFrom — ready to drop into a FROM line
• Vulnerability counts, size, creation date

This makes it straightforward to integrate into CI/CD pipelines, policy engines, or tooling. For instance, a tool or AI agent could read the JSON, detect the languages in your workspace, and recommend the best base images automatically.

🔍 Detailed JSON Report — For Deeper Analysis

View the latest report → (large file — use “View raw” or clone the repo)

Once you’ve narrowed down top-ranked images from the markdown or JSON reports, the detailed report lets you validate that choice. For every scanned image (not just top-N), it provides:

• Full vulnerability breakdown: CVE ID, severity, CVSS score, affected package, package version, fixed version (if available), and description
• Complete system package inventory: Every RPM/DEB/APK package installed
• Package managers detected: pip, npm, etc.

The report documentation includes ready-to-use jq commands for common security workflows:

# List all images with critical vulnerabilities
jq '.images[] | select(.vulnerabilitySummary.critical > 0) |
  {name, critical: .vulnerabilitySummary.critical}' \
  docs/daily_recommendations_detail.json

# Show CVEs with available fixes for a specific image
jq '.images[] | select(.name | contains("python:3.12")) |
  .vulnerabilities[] | select((.fixedVersion // "") != "") |
  {id, severity, packageName, fixedVersion}' \
  docs/daily_recommendations_detail.json

When comparing image alternatives, the package inventories and vulnerability details help you make an informed shortlist decision. For example, two images might have similar vulnerability counts, but one has fixes available for its CVEs while the other doesn’t — that matters when choosing between them.

How to Use SBI in Practice

Pick a base image for your language: Browse the markdown report, find your language section, and pick the top-ranked image for your Dockerfile.

Automate recommendations: Feed the JSON report into your tooling — a tool or agent can detect languages in a workspace and recommend the best available base images.

Compare alternatives in depth: Use the detailed JSON report to drill into package inventories and vulnerability details when narrowing down your shortlist.

Run it yourself: SBI is distributed as a Go CLI. Local scanning requires Docker, Syft, and Trivy — or just use the included devcontainer which comes preinstalled with everything:

go install github.com/microsoft/sbi@latest
sbi scan --verbose

Verifying MCR Image Integrity

Images on MCR are signed by Microsoft. Before deploying to production, it’s recommended to verify the integrity of the images you use.

How it works: When Microsoft publishes an image, a cryptographic signature is generated that binds the publisher’s identity to the image digest. A verification tool like Notation (from the CNCF Notary Project) checks that the signature matches a trusted certificate and that the image content hasn’t been modified since signing. If either the identity or the content doesn’t match, verification fails — telling you the image may have been tampered with.

Verifying with Notation

Install Notation, then set up Microsoft’s Supply Chain root certificate and a trust policy:

# 1. Download Microsoft's Supply Chain root certificate
curl -Lo msft_supply_chain_cert.crt \
  "https://www.microsoft.com/pkiops/certs/Microsoft%20Supply%20Chain%20RSA%20Root%20CA%202022.crt"

# 2. Add it to Notation's trust store
notation cert add --type ca --store microsoft msft_supply_chain_cert.crt

# 3. Create a trust policy for MCR repositories
cat <<EOF > trustpolicy.json
{
    "version": "1.0",
    "trustPolicies": [
        {
            "name": "mcrtrustpolicy",
            "registryScopes": [
                "mcr.microsoft.com/azurelinux/base/core",
                "mcr.microsoft.com/azurelinux/distroless/base",
                "mcr.microsoft.com/azurelinux/distroless/minimal",
                "mcr.microsoft.com/azurelinux/base/python",
                "mcr.microsoft.com/azurelinux/base/nodejs",
                "mcr.microsoft.com/azurelinux/distroless/python",
                "mcr.microsoft.com/azurelinux/distroless/nodejs",
                "mcr.microsoft.com/dotnet/aspnet",
                "mcr.microsoft.com/dotnet/runtime",
                "mcr.microsoft.com/dotnet/sdk",
                "mcr.microsoft.com/oss/go/microsoft/golang",
                "mcr.microsoft.com/openjdk/jdk"
            ],
            "signatureVerification": {
                "level": "strict"
            },
            "trustStores": ["ca:microsoft"],
            "trustedIdentities": ["*"]
        }
    ]
}
EOF

# 4. Import the trust policy
notation policy import trustpolicy.json

# 5. Verify an image (use the pinned digest from the SBI report)
notation verify mcr.microsoft.com/azurelinux/base/python:3.12@sha256:485299b016fe5ae745ffee27f0b8a850576841205ed1d420c9a84b126198e320

# Successfully verified signature for 
# mcr.microsoft.com/azurelinux/base/python@sha256:485299b...

The registryScopes above include repositories currently scanned by SBI. Add any other MCR repository you use. The root certificate reference comes from Microsoft's image signing announcement.

For Kubernetes environments, Ratify can enforce signature verification at admission time — ensuring only verified images are deployed to your clusters.

For more details, see Microsoft’s documentation:

• Overview of signing and verifying OCI artifacts
• Verify container image signatures with Ratify and Azure Policy

Why SBI

• Data-driven: Objective ranking based on real vulnerability scans, not opinions or popularity
• Fresh daily: Nightly scans mean vulnerability data is always current — even if an MCR image hasn’t been updated in days, newly disclosed CVEs affecting it will show up in the next report
• Community-extensible: Want an MCR image added to the nightly scan? Submit a PR adding it to config/repositories.json — after merge, the next nightly run will pick it up
• Not limited to MCR: The SBI repository is configured to scan MCR images by default, but the tool itself supports any OCI-compliant registry. Fork it and point it at Docker Hub, GitHub Container Registry, or your private registry

Get Started

Your container’s security posture starts with the base image. Stop guessing — let data drive that decision.

• 📦 Repo: github.com/microsoft/sbi
• 📄 Latest markdown report: daily_recommendations.md
• 📊 Latest JSON report: daily_recommendations.json
• 🔍 Latest detailed report: daily_recommendations_detail.json (large file — use “View raw” or clone the repo)

Want an MCR repository scanned? Open a PR adding it to config/repositories.json.

Use a different registry? Fork the repo, update repositories.json with your image sources, and set up the nightly workflow for your own registry.

Contributions are welcome — whether it’s adding new image sources, improving language detection, or extending report formats. Check out the repo to get started. If you find it useful, a ⭐ helps others discover it.

The Best MCR Base Image for Your Language? SBI Scans Nightly So You Don’t Have To was originally published in Microsoft Azure on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introducing the article

This article explores the challenges and architectural trade-offs of enforcing Next-Generation Firewall (NGFW) inspection for East-West traffic inside Azure Kubernetes Service (AKS), particularly when using Azure CNI Overlay. While Kubernetes and the CNCF ecosystem already provide mature cloud-native security capabilities such as network policies, mTLS, runtime protection, and workload isolation, some organizations still require traditional firewall inspection between internal services.

The article explains why this requirement is difficult to implement with Azure CNI Overlay, since pod-to-pod traffic remains encapsulated and invisible to Azure networking constructs such as route tables and NSGs. It then presents several architectural approaches to force traffic through Azure Firewall, including the use of Application Gateway as an internal reverse proxy combined with Istio Gateway API resources, as well as an alternative design based on Private Link Service (PLS).

The discussion highlights the technical feasibility while maintaining a deliberately ironic tone toward applying traditional perimeter-security thinking to modern cloud-native environments.

Explaining the problem statement and trying to persuade CISO first

Kubernetes and the broader Cloud Native Computing Foundation (CNCF) landscape offer many tools and products to control layer 4 and layer 7 traffic efficiently. AKS itself ships with Advanced Container Networking Services, which allows you to control and observe your network traffic at scale.

However, some CISO departments only swear by Next-Generation firewalls, including for East-West traffic inside the cluster. While this requirement makes sense for North-South (Ingress/Egress), it is rather less interesting to inspect traffic and leverage IDPS features for pod-to-pod communication, where both sides of the communication are 100% under your control. Having a good security posture like, ensuring an end to end follow up from the supply chain to the running container, using the following methods:

• SAST and DAST (e.g. Snyk, JFrog Xray) to detect and remediate vulnerabilities.
• Applying strict policies enforced by Gatekeeper, making sure that containers do not run as root, have read-only file systems, restricted capabilities, etc., effectively minimizing the potential impact of a malicious activity.
• Ensuring runtime security using solutions such as Defender for containers, CrowdStrike or CNCF solutions such as Falco, to detect and suspicious activity in real-time.
• Adopting the least privilege approach and identity-level controls such as mTLS, fine-grained authorizations and token validation using built-in addons such as Istio.
• Applying native network policies with K8s, Calico or Cilium to prevent unexpected lateral movements.
• Making sure internet ingress traffic is proxied and inspected by a WAF (e.g Cloudflare, Application Gateway, Imperva, etc.) and egress traffic is routed to a next-gen firewall.
• Leverage NSGs to rule Azure-level traffic in addition to the next gen firewalls.
• Running private clusters.

All the above, among other things, should in theory satisfy most security requirements. Additionally, you can offload data to Azure data services for apps you build yourself, which means that you can leverage native Azure security and governance tools to handle data concerns.

At last, in the Cloud and although Kubernetes was not built for this, it is also rather easy to work with dedicated clusters as we can easily provision them. You can decide to govern them all using fleet managers to ensure consistency across clusters.

Working with dedicated clusters allows you to drastically reduce the blast radius should any incident, security-related or not, occur.

However, despites the numerous possibilities, some security teams, about 12 years after the launch of Kubernetes and 13 years after the launch of Docker, still don’t get it and only see security through firewalls. Nothing else exist but firewalls.

So, if your CISO department were to momentarily or permanently lose its senses and you still had to address these next-gen firewalls pressing requirements, you may first try some of the following:

1. Do not use K8s, just use plain VMs and forget about cloud native. You may as well stay on-premises and do business as usual. A bit radical but efficient!
2. Send your CISO staff to trainings.

If they still don’t get it (most likely), I’m afraid you’ll have to read the next section.

You couldn’t escape!

If your attempt to convince CISO failed miserably, I’m afraid you’ll have to resort to one of the following options:

1. Leverage specialized products such as Palo Alto CN Series. This type of products live inside the cluster and let you define K8s-friendly policies and keep your single pane of glasses whether dealing with containers or not.
2. Use Azure-native constructs, and, that’s what I’m going to focus on.

First things first, using Azure CNI or CNI Overlay is already a game changer. With Azure CNI, the regular Azure network controls can be applied as with plain virtual machines or any other VNET-friendly PaaS service. With CNI Overlay, pod-to-pod traffic as well as pod-to-load balancer traffic is completely encapsulated within the overlay layer, making this traffic insensitive to route tables and network security groups. Simply put, Azure doesn’t even see this traffic. Many companies prefer CNI Overlay over CNI because it consumes much less IP addresses.

Since the real challenge is with CNI Overlay, I will only focus on this.

Regardless of the chosen network interface, dealing with North-South is easy:

Traffic coming from the outside is typically proxied by a Web Application Firewall (WAF) forwarded or not to a next gen firewall which ultimately forwards the traffic to the AKS’s internal load balancer (ILB) used by our ingress controllers and/or our K8s gateways. For API-related traffic, we may also add an API gateway behind the WAF, in the hub or in the spoke before hitting the ILB. The rule of thumb here is to avoid exposing AKS directly to internet.

For cluster egress traffic, internet-bound or not, we can easily route everything to a next gen firewall. The CNI we use in AKS makes no difference since all these IPs and FQDNs are external to the cluster so, all can be caught by the usual Azure plumbing. All of the above is business as usual, nothing new but just a refresh.

Now, what if we want our Backend-for-Frontend (BFF), behind a WAF, to go through a firewall before it can talk to the actual backend?

Both, our frontend and backend layers are AKS namespaces. The WAF (not shown above), proxies the BFF. We want our BFF to transit to a next-gen firewall before it can talk to the actual backend.

Well, by default, we can’t because both the BFF and the backend pods are part of the pod CIDR range, which in turn, is part of the overlay network, regardless of the node they are running onto. So, even splitting nodes into different node pools mapped to different subnets doesn’t change anything, since both pods will anyway remain in that CIDR range that is not even seen by Azure. The same consideration applies to the AKS service range of course. Since Azure cannot “see” those IPs, none of the traditional network components (route tables, NSGs, etc.) can come to the rescue. So, the above setup simply doesn’t work. Beware that this works with Kubenet because, unlike CNI Overlay, when pods are distributed across nodes and subnets, Azure sees the node IP instead of the pod IP. However, since Kubenet is on the deprecation path, its use is strongly discouraged.

You may think, ok, let’s use a service of type LoadBalancer instead of a ClusterIP one with an external IP, as illustrated below:

Although the IP address you define originates from a subnet of your choice, and is, as such, not part of the cluster itself, it remains totally invisible to Azure since the CNI Overlay plumbing encapsulates it…So, you can’t put a route table on the frontend subnet with a route targeting the load balancer one because when the BFF is calling the ILB IP, it’d still be seen as “internal” traffic. Additionally, you would not be able to specify a return route on the backend subnet since the pods running in the frontend subnet are part of the pod CIDR range…so no luck with this setup either.

The reason why ILB is considered internal is because the IPs provisioned on the load balancer are not true network interfaces. Therefore, we need something else. One of the options is to use Application Gateway but this time as a mere reverse-proxy (WAF is not required) to proxy the ILB. Here is an end-to-end example using Application Gateway, Istio and the native support of K8s gateway CRD (in preview as of 05/2026 when used together with Istio).

The entry point is one WAF-enabled Application Gateway instance to inspect incoming internet traffic. In our example, the UI components as well as the BFF are internet facing. You may decide to split them should you want parallel channels for internal and external access. Note that this is also feasible with a single frontend layer.

Another Application Gateway instance using internal listeners only is used to proxy the internal frontend layer materialized by IP addresses exposed on the ILB. You use K8s gateways for HTTP and API traffic. In the above diagram, I’m only considering a single application but you could use a similar technique with one or two main K8s gateways per application, each having its own listeners on the Application Gateway. In this single app example, all the API endpoints can be behind a single gateway resource and my HTTP endpoints behind another one. My API routes use prefixes (e.g. /apis/api1) behind the same FQDN. This allows for a one-shot configuration at the level of Application Gateway.

You should also make sure to control internal traffic so that only the ingress-related namespaces are allowed to talk to other namespaces. Similarly, you should prevent backend namespaces to directly target the ILB IPs using either Calico or Cilium policies since they would bypass the Application Gateway. In other words, you must combine cloud-native controls with Azure appliances such as Azure Firewall. Now, because the traffic flows over Application Gateway, you can easily use route tables and NSGs as shown below.

In practice, this means that traffic flows from the Application Gateway to the gateway pods running on nodes connected to the ingress subnet through Azure Firewall. A route table applied to the ingress subnet ensures the return route. Communication between the gateway pod and the actual backend pods, such as the BFF or backend services, remains encapsulated within the overlay network. When the BFF invokes a backend service, it must use the FQDN exposed through the Application Gateway, which in turn directs the traffic through Azure Firewall. The relationship between the gateway pod and the backend pods is established through the HTTPRoute CRD. By locking down traffic internally, you should make sure to only allow the BFF to talk back to Application Gateway and nothing else. Other AKS subnets could also route traffic destined to Application Gateway to Azure Firewall, which in this case, requires a return route on the gateway subnet (red routes in the diagram). Note that return routes in general are only required if you do not apply SNAT at the level of the firewall.

In practice, the above setup requires a few FQDNs to be published to Application Gateway:

where FQDNs should target the private frontend IP of the Application Gateway. Then you should define your backends and use routing rules to map the frontend FQDN to the one known by AKS. For example, bff.eyskens.internal forwards to bff-aks.eyskens.internal, which uses one of the ILB IPs as shown below.

gatewayClassName: istio
  infrastructure:
    annotations: 
      service.beta.kubernetes.io/azure-load-balancer-internal: "true"
      service.beta.kubernetes.io/azure-load-balancer-internal-subnet: "ingress"
      service.beta.kubernetes.io/azure-load-balancer-ipv4: "10.0.1.8"

The gateway should allow HTTPRoute resources to reference whenever needed. Here is an example of such route:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: bff
  namespace: frontend
spec:
  parentRefs:
  - name: bff-gateway
    namespace: ingress
  hostnames: ["bff-aks.eyskens.internal"]
  rules:

The above snippet will be considered a match whenever bff-aks.eyskens.internal is called by the Application Gateway.

Next, when the BFF calls a backend service, it does it using the FQDN published on Application Gateway, such as for example api.eyskens.internal/apis/api1. You could decide to use the same technique to the backend layer itself if required or let them call each other internally.

The downside of this approach is an additional complexity, compared to simply using the built-in tools. Moreover, the Application Gateway generates extra costs.

As an alternative, you could use Private Link Service (PLS), to expose private endpoints mapped to the ILB IPs. This way, traffic destined to those private endpoints can be steered to Azure Firewall. Most of the previous setup considerations also apply here.

With the above setup, all FQDNs should target the private endpoints that are used by PLS to forward traffic to the ILB IPs. The benefit of this approach is that PLS is free of charge. Private endpoints are not but they’re cheaper than Application Gateway. The only potential change compared to the previous approach, is the way you handle routing to and from private endpoints since these are special beast (see this post https://medium.com/microsoftazure/top-asymmetric-routing-issues-and-unexpected-firewall-bypass-in-azure-7456a1c1a9ff for more info). Regardless, you should make sure that the subnet holding the private endpoints is configured with the appropriate network policy.

Note that if you are mostly dealing with APIs, you may as well consider using Azure API Management (APIM) instead of Application Gateway and use exactly the same routing methods. APIM would also allow you to deal more efficiently with APIs than Application Gateway.

Conclusion

Ultimately, trying to force traditional Next-Generation Firewall patterns onto Kubernetes East-West traffic often results in significant architectural complexity to solve a problem the cloud-native ecosystem already addresses more elegantly through identity, policy, workload isolation, runtime security, and observability. While Azure-native constructs such as Application Gateway, API Management, Azure Firewall, and Private Link Service can technically satisfy stringent network inspection requirements, they introduce additional costs, routing considerations, operational overhead, and design constraints. In most cases, organizations should first evaluate whether modern Kubernetes-native security controls already provide the required level of protection before reproducing legacy datacenter patterns inside AKS. However, when governance or compliance requirements leave no room for negotiation, the approaches described in this article can provide a pragmatic path forward.

Inspecting AKS East-West Traffic with Next-Generation Firewalls: Solving a Problem Kubernetes… was originally published in Microsoft Azure on Medium, where people are continuing the conversation by highlighting and responding to this story.

Azure SRE Agent helps you maintain the health and performance of your Azure resources through AI-powered monitoring and assistance. Agents continuously watch your resources for problems, provide troubleshooting help, and suggest remediation steps in a natural-language chat interface. To ensure accuracy and control, any action that an agent takes on your behalf requires your approval. In this blog I will show you the power of Azure SRE agents, how to get started! While we could do everything using ClickOps why not automate using Azure Bicep? 💪🏻

The main.bicep template serves as the entry point for the Bicep configuration and defines the parameters, variables, and core resources used throughout the deployment. It orchestrates the provisioning of key Azure components such as Log Analytics, Application Insights, a managed identity, and the Azure SRE agent. Additionally, it configures role based access control assignments and sets up the necessary permissions and context for the SRE agent to monitor, analyze, and interact with resources within the specified scope.

metadata name = 'Azure SRE Deployment'
metadata description = 'Deploys Azure SRE resources'
metadata owner = 'Brian Veldman'
metadata version = '1.0.0'

targetScope = 'resourceGroup'

@description('Solution name for resource naming')
param parSolution string = 'infra'

@description('Deployment environment')
param parEnvironment string = 'prod'

@description('Deployment number for uniqueness')
param parDeploymentNumber string = '001'

@description('Deployment location')
@allowed([
  'eastus2'
  'swedencentral'
  'australiaeast'
])
param parLocation string = 'swedencentral'

@description('Model provider')
param parDefaultModelProvider string = 'Anthropic'

@description('User object id')
param parUserObjectId string = deployer().objectId

@allowed([
  'Low'
  'Medium'
  'High'
])
param parAccessLevel string = 'Low'

@description('Defining our variables')
var varShortEnvironmentMapping = {
  swedencentral: 'swc'
  eastus2: 'eus2'
  australiaeast: 'aue'
}
var varShortEnvironment = varShortEnvironmentMapping[parLocation] ?? parLocation

@description('Deploy Log Analytics Workspace')
resource workspace 'Microsoft.OperationalInsights/workspaces@2023-09-01' = {
  name: 'log-${parSolution}-${parEnvironment}-${varShortEnvironment}-${parDeploymentNumber}'
  location: parLocation
  properties: {
    sku: {
      name: 'PerGB2018'
    }
    retentionInDays: 30
    features: {
      enableLogAccessUsingOnlyResourcePermissions: true
    }
  }
}

@description('Deploy Application Insights')
resource appInsights 'Microsoft.Insights/components@2020-02-02' = {
  name: 'appi-${parSolution}-${parEnvironment}-${varShortEnvironment}-${parDeploymentNumber}'
  location: parLocation
  kind: 'web'
  properties: {
    Application_Type: 'web'
    Request_Source: 'SreAgent'
    WorkspaceResourceId: workspace.id
  }
}

@description('User assigned identity for the agent')
resource identity 'Microsoft.ManagedIdentity/userAssignedIdentities@2024-11-30' = {
  name: 'id-${parSolution}-${parEnvironment}-${varShortEnvironment}-${parDeploymentNumber}'
  location: parLocation
}

@description('Deploy SRE Agent')
#disable-next-line BCP081
resource agent 'Microsoft.App/agents@2025-05-01-preview' = {
  name: 'sre-${parSolution}-${parEnvironment}-${varShortEnvironment}-${parDeploymentNumber}'
  location: parLocation
  identity: {
    type: 'SystemAssigned, UserAssigned'
    userAssignedIdentities: {
      '${identity.id}': {}
    }
  }
  properties: {
    knowledgeGraphConfiguration: {
      managedResources: []
      identity: identity.id
    }
    actionConfiguration: {
      mode: 'review'
      identity: identity.id
      accessLevel: parAccessLevel
    }
    logConfiguration: {
      applicationInsightsConfiguration: {
        appId: appInsights.properties.AppId
        connectionString: appInsights.properties.ConnectionString
      }
    }
    defaultModel: {
      provider: parDefaultModelProvider
      name: 'Automatic'
    }
  }
}

@description('Assign SRE Agent Administrator role to the user at agent scope')
resource agentAdminRole 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(agent.id, parAccessLevel, 'agent-admin')
  scope: agent
  properties: {
    roleDefinitionId: resourceId('Microsoft.Authorization/roleDefinitions', 'e79298df-d852-4c6d-84f9-5d13249d1e55')
    principalId: parUserObjectId
    principalType: 'User'
  }
}

Customize the code to align with your specific requirements, then execute it. After a few minutes, all the necessary resources will be deployed. This can be done using: New-AzResourceGroupDeployment -Name deploymentName -TemplateFile .\main.bicep.

We can see the Azure resources deployed within the resource group.

To start using the Azure SRE agent we just deployed, go to the SRE Azure portal, and click on the name of the agent.

When reviewing the Azure SRE resource, we can provide the agent with context to enable more effective investigations. The more context it has, the better it can correlate changes, dependencies, and issues across your environment. In this case, the SRE agent does not yet have any information about my applications, so it will not be able to answer questions.

For the first example, I will provide the Azure SRE agent with context about a specific resource group within my subscription. The agent analyzes Azure resources to understand the service architecture, dependencies, and runtime context of the system.

I checked the ZTA resource group because this is a proof of concept I am running, and I want to grant the Azure SRE agent access to it.

Next, it is up to you to decide which permissions the agent receives. You can choose between Reader and Privileged access. Privileged access includes both read and write permissions, allowing the agent to diagnose issues and perform remediation actions.

After waiting a couple of seconds, the permissions have been added. You can remove them at any time if needed. For now, this is enough. It is time to test our SRE agent.

For the best and full experience I visit sre.azure.com From there I can select the SRE agent we deployed using Bicep. 💪🏻

From here, we can interact with the SRE agent. For this example, users have reported that the Azure Web App in Canada Central is not functioning, which is why I will ask the Azure SRE agent to investigate and determine how to resolve the issue.

Within seconds, it detects that the Azure App Service is in a stopped state. It then requests permission to start the Azure App Service, since the Azure SRE agent is running in read only mode and any action it wants to perform must be approved. Before proceeding, I want to verify in the Azure portal that the Azure App Service is not running.

When checking the Azure App Service in the Azure Portal, it appears that it is not running… 😱

Next, we can approve the action to allow the SRE agent to start the Azure App Service to remediate the issue.

And just like that, the Azure App Service is running. This means users can now access the web app. 💪🏻

We also receive the root cause analysis, which shows that Brian Veldman stopped the Azure App Service four minutes before we started interacting with the Azure SRE agent. It also provides recommended next steps to help prevent these types of issues in the future.

From a monitoring perspective, we can see what users are asking the Azure SRE agents. All logs are sent to Log Analytics and are also visible in Azure Application Insights.

When reviewing one of the end to end transactions, we can see the message the user sent: “Users are complaining that my Azure Web App is not accessible in Canada Central.” This is correct and aligns with the session we previously conducted to resolve the issue and perform the root cause analysis.

So, as you saw, the Azure SRE agents are super powerful! However, what we did until now was manually asking the Azure SRE agent to check the Web App issue. In production scenarios, you want to do this in an automated way. This is where Azure SRE Agents Incident Management kicks in. You can connect your incident platform, like Azure Monitor. 😍

Azure SRE Agents pricing

From a billing perspective there are two things to consider:

• First, there is the always on flow, which represents the fixed cost of keeping the agent running. This is billed per hour as long as the agent is active, regardless of whether it is doing any work. It ensures that the agent is continuously available, monitoring and ready to respond. This is a fixed baseline which costs 4 AAU (Azure Agent Units) per hour, which means 2.920 AAU per month (730 hours x 4 AAU/h) = ~€253.46
• Second, there is the active flow, which represents the variable, usage based cost. This is billed in Azure Agent Units based on the actual work performed by the agent, such as processing events, triggering actions, or generating responses. You only incur these costs when the agent is actively handling tasks.

For this example it costed me ~3 EUROS for 2/3 hours;

Azure SRE Agents + Service Provider Tenant = ❤️

Can we use SRE agents to manage multi-tenant Azure resources using Lighthouse? Yes. By assigning the appropriate permissions through the service provider offer, we can connect to customer resources, resource groups, or subscriptions and perform analysis using the Azure SRE agent hosted in the service provider tenant.

That’s all for today. As you could see Azure SRE Agent helps you maintain the health and performance of your Azure resources through AI-powered monitoring and assistance. The Azure Bicep code is available in my GitHub repository: GitHub — brianveldman/azure-bicep. Feel free to star the repository and clap for this story. Also, let me know if you have any feedback. I look forward to our next session. That’s all for today, until then, take care! ❤️

This is why you should start using Azure SRE Agents! 😍 was originally published in Microsoft Azure on Medium, where people are continuing the conversation by highlighting and responding to this story.

I. Embrace the broader ecosystem

In Azure and AKS, your code is only part of the system, the platform’s SDKs, services, and tools are just as critical. Use local debuggers, emulators, and CI/CD pipelines, and treat infrastructure with the same curiosity as your own code because it will be your own code one day.

II. Design for horizontal scaling

Ban in-memory sessions, caches, and tokens from your code, and design business transactions to survive horizontal scale.

III. Design for failure

Transient errors are mainstream. Design your applications so they expect timeouts, retries, restarts, and partial outages. Make applications multi-region aware and do not rely solely on infrastructure for resilience.

IV. Instrument early

Adopt OpenTelemetry early, or observability will always lag behind reality.

VI. Master OAuth and OIDC early

They are mainstream in the cloud, and no modern application can be built without them.

VII. Breathe Event-Driven Architecture

Whatever the architecture style you choose, you will eventually build a distributed system.

VIII. Breathe API-Driven Architecture

Whatever the architecture style you choose, you will eventually rely on APIs.

IX. Master containers

Containers are on your way no matter what.

X. Read the Azure Cloud Native Architecture Mapbook

You should see the whole picture: to truly understand Azure and AKS — application development and beyond — step back, think holistically, identify tradeoffs and deepen your architectural views.

Check out my new book https://www.amazon.com/Azure-Cloud-Native-Architecture-Mapbook/dp/1805805053

The 10 Commandments of Azure Development was originally published in Microsoft Azure on Medium, where people are continuing the conversation by highlighting and responding to this story.

I. Think workload types, not services

Azure is too vast to approach service‑by‑service. Categorize workloads into Systems of Engagement (SoE), Systems of Record (SoR), Systems of Insights (SoIn), Systems of Intelligence (SoI), and Systems of Integration (SoInt) to see the bigger picture. Connect the Azure services to these workload types to gain clarity.

II. Let non‑functional requirements drive architecture decisions

In the cloud, there are a thousand ways to achieve the same outcome but it is not magically scalable, performant, or secure. You must make it so!

III. Breathe Event-Driven and API-Driven architecture styles

Whatever the architecture style you choose, you will eventually build a distributed system that will contain APIs.

IV. Return to fundamentals

In the cloud, there are a thousand ways to achieve the same outcome (again ). Only strong fundamentals (eg: ACID vs BASE, discrete events vs telemetry, streaming vs batch processing, request/reply vs asynchronous, etc.) make the right way obvious and help you pick the right technologies.

V. Understand the platform rules

What you can design is largely shaped by how the underlying platforms are governed. Know the rules before you start drawing. Be disruptive if rules don’t make sense.

VI. Master OAuth and OIDC early

They are mainstream in the cloud, and no modern solution can be built without them.

VII. Master Azure, Kubernetes and OpenShift networking fundamentals

No modern solution exists independently of its network architecture.
Understanding Azure, Kubernetes and OpenShift networking is essential to grasp how workloads integrate, communicate, and sometimes even how components of the same system interact. Core concepts such as north–south and east–west traffic are foundational, non-negotiable.

VIII. Anticipate capacity limits

This page https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits should be your primary reference and single source of truth before designing any solution.

IV. Do not hide behind abstraction

An Azure Solution Architect is specialized by design as opposed to a generalist. High-level abstraction is not enough to shine.

X. Read the Azure Cloud Native Architecture Mapbook

You should see the whole picture: to truly understand Azure Solution Architecture and beyond — step back, think holistically, identify tradeoffs and deepen your architectural views.

Check out my new book https://www.amazon.com/Azure-Cloud-Native-Architecture-Mapbook/dp/1805805053

The 10 Commandments of Azure Solution Architecture was originally published in Microsoft Azure on Medium, where people are continuing the conversation by highlighting and responding to this story.

Azure Virtual WAN is already in place and all branch sites are connected successfully. BGP peering is up, routes are propagating as expected and end to end connectivity is stable. You have also completed the migration from on-premises to Azure including the older management virtual machines that were previously used for administrative access. With that groundwork done you now want to modernize remote access by introducing Azure Bastion. After all keeping Windows Server jump hosts just to reach other virtual machines no longer makes much sense when Bastion can provide secure browser based access without exposing workloads directly. But when you kick off the Azure Bastion deployment it does not complete. Instead the deployment fails and an error is shown:

Why do I get this error message?

When we look into the following diagram we see the Azure Virtual WAN architecture. This service acts as a global networking layer that connects multiple virtual networks through a centralized hub. At the center of the architecture there is a VWAN Hub which functions as the main routing and connectivity point for the environment. Traffic between all connected networks flows through this hub, enabling centralized routing, connectivity, and network management. The dashed lines between the hub and the spokes represent the connections from each virtual network to the VWAN hub. This hub and spoke model ensures that communication between the networks is centrally managed and routed through the hub.

However this architecture introduces a challenge when Azure Bastion is used together with Azure Virtual WAN. Azure Bastion requires direct outbound connectivity to the public internet in order to operate correctly. In a Virtual WAN topology network traffic is typically routed through the Virtual Hub. Because the Bastion subnet has a default route of 0.0.0.0/0, its outbound traffic is also routed through the Virtual Hub instead of going directly to the internet. As a result Azure Bastion cannot meet its requirement for direct internet connectivity, which leads to compatibility issues and can cause the Bastion deployment to fail.

This is exactly the effect shown in the diagram above. To demonstrate this behavior, an Azure Virtual Machine was deployed in the Azure Bastion VNet in order to inspect the effective routes on the Network Interface Card. By reviewing the effective routes on the NIC, it becomes clear how the routing is handled in the Virtual WAN topology and how the default route influences the path that outbound traffic follows. This helps illustrate why traffic from the Bastion subnet is routed through the Virtual Hub instead of going directly to the public internet.

But why does this happen? The behavior originates from the Propagate Default Route setting within the Virtual WAN Virtual Network Connection towards the Azure Bastion VNet. When this setting is enabled, the Virtual WAN hub propagates the default route 0.0.0.0/0 to the connected virtual networks. This means that all outbound traffic that does not match a more specific route is automatically sent to the Virtual Hub. Because of this behavior, traffic from the Azure Bastion VNet would be routed through Azure Virtual WAN instead of going directly to the public internet. Since Azure Bastion requires direct outbound connectivity to the internet, this routing behavior causes a problem. To solve this, the Propagate Default Route setting was disabled on the Azure Bastion VNet connection. This ensures that the 0.0.0.0/0 route is not learned from the Virtual WAN hub, allowing outbound traffic from the Azure Bastion VNet to break out directly to the internet.

After applying this change we can verify the behavior again on the test virtual machine. When checking the effective routes on the network interface card we can now see that the 0.0.0.0/0 route forwards to the Internet service tag.

When deploying Azure Bastion again, our deployment succeeds! We can now succesfully use Azure Bastion within our Azure vWAN setup! 😍

From here you now know how to integrate Azure Bastion within an Azure Virtual WAN setup. This approach ensures that Bastion keeps the required direct internet connectivity while the rest of the environment continues to benefit from the centralized connectivity provided by Azure Virtual WAN. One of the advantages of this solution is the operational simplicity. It allows administrators to access virtual machines directly through the Azure Portal instead of having to deploy and manage separate jumpbox virtual machines. This reduces management overhead while still providing a secure and convenient way to connect to workloads inside the environment. Feel free to clap for this story. Also, let me know if you have any feedback. I look forward to our next session. That’s all for today, until then, take care! ❤️

Integrating Azure Bastion in Azure Virtual WAN setup was originally published in Microsoft Azure on Medium, where people are continuing the conversation by highlighting and responding to this story.

Power BI Copilot has already changed how we build reports. Natural language prompts now accelerate visual creation, summarization, and exploration. But semantic models — the backbone of analytics — remain largely manual, technical, and dependent on deep modeling expertise. This creates a bottleneck where report creation accelerates, but model development does not. In this post, I walk through an agentic development approach for Power BI semantic models using GitHub Copilot with Power BI Modeling MCP Server and show how AI can meaningfully participate in semantic model creation — without removing the human from the loop.

The diagram below illustrates the high‑level components and flow involved in developing Power BI semantic models using the Power BI Modeling MCP Server. This blog focuses on explaining the core concepts and architecture rather than providing step‑by‑step instructions. For a complete end‑to‑end walkthrough, please refer to the full demo available on YouTube — https://youtu.be/EKOG86ynOn0

If you’d like to try this yourself using the same datasets shown in the demo, you’ll need to set up the Fabric CMS Medicare Part D sample from the GitHub repository and have access to VS Code, GitHub Copilot, and the Power BI Modeling MCP Server.

Inspiration: Agentic AI for Power BI Development

The key enabler for this work is the Power BI Modeling MCP Server, exposed as a Visual Studio Code extension along with GitHub Copilot Agent mode. This extension allows semantic model operations to be executed through a MCP (Model Context Protocol), making them accessible to AI agents like GitHub Copilot.

The approach was heavily inspired by Rui Romano’s GitHub repository, which demonstrates fully agentic Power BI development — from semantic models to reports — using GitHub Copilot. That work proved the concept was possible. My focus here was narrower and more pragmatic: semantic model generation only. Semantic models are where business meaning, relationships, and measures are defined. If we want AI‑accelerated analytics to scale, semantic modeling must evolve beyond purely manual craftsmanship.

This experiment explored a simple question:

Can an AI agent, given the right context and tools, build a Power BI semantic model comparable to one created manually to accelerate development velocity?

Microsoft Fabric CMS Part D sample solution as the Playground

The experiment builds on an end‑to‑end Microsoft Fabric analytics solution maintained by Greg Beaumont and I, which uses real CMS Medicare Part D dataset.

The solution includes:

• Data ingestion from the CMS website using Fabric Spark notebooks
• Storage in a Fabric Lakehouse
• Transformations via Spark Notebooks orchestrated using Fabric pipelines
• Consumption through Fabric data agents, Power BI Semantic Model and Power BI Reports

The architecture supports both manual and automated setup paths, highly recommended checking out the repository if not already familiar with it — fabric-samples-healthcare/analytics-bi-directlake-starschema at main · isinghrana/fabric-samples-healthcare

Screenshot of the Semantic Model created manually as part of the sample in the GitHub Repo

Agentic Development of Power BI Semantic Model for CMS Medicare Sample

Crawl, Walk, Run: Scoping the Experiment

Early attempts to have an agent generate a semantic model from scratch ran into some challenge so I changed tactics:

1. Create a minimal baseline semantic model manually in the Fabric web interface
2. Switch to Visual Studio Code
3. Let GitHub Copilot, via the Power BI Modeling MCP Server, enhance the model using Agentic AI

Establishing the Baseline

Creation of baseline semantic model:

• Opened the Fabric Lakehouse using Fabric Web Interface
• Create a new Semantic Model with core CMS fact and dimension tables

The goal was not novelty — it was parity. The agent’s task was to take something basic and evolve it toward a usable Semantic Model for report creatin using Power BI Copilot.

VS Code + MCP Server: Enabling Agentic Development

With Visual Studio Code GitHub Copilot was used as the agent interface and Power BI Modeling MCP Server extension available as a tool (ensured it was started) executed the following two steps:

1. Connect GitHub Copilot Agent to Fabric Workspace and Semantic Model using simple prompt — “Connect to semantic model ‘<semantic-model-name>’ in Fabric Workspace ‘<fabric-workspace-name>’”
2. Next GitHub Copilot prompt to start the semantic build out work — “Please us the instructions from `.\Semantic_Model_Implementation_Guidance.md` to build out a production ready semantic model which can be easily used to generate reports”.

Prompt Text File available on GitHub here and Semantic Model Implementation Guidance markdown file available here

A few notes on the implementation guidance file:

• Framed strong business context first — clear analytical objectives, explicit business questions, and grounding in official CMS Medicare Part D documentation — gave the agent intent rather than just tasks.
• Clear objectives and questions were more important than verbose instructions, enabling the model to reason correctly about outcomes.
• Technical guidance like give business user-friendly names for table and column names, data type formatting, hide technical columns like Surrogate Keys.
• Couple notes in the Critical Section of guidance file were based on iterative attempts where failures were encountered, example newly created semantic model was not usable with “CalculationNeeded” error message so instead of having the model created in a bad state and then ask GitHub Copilot to fix it an explicit instruction was added so that GitHub Copilot creates Semantic Model in a usable state to begin with
• A simple mandate to document every step in a log file with details on the step executed by agent (observed other patterns where planning step documents and get the details

Results: Surprisingly Close to Manual

The resulting AI generated semantic model was very similar to the manually created one.

• Contained sensible relationships, semantic tables and columns were given business user-friendly names
• Included usable, well‑structured DAX measures
• Usable for Report creation using Power BI Copilot

Resources:

• End to End YouTube Video for the Demo
• Power BI Modeling MCP Server
• Rui Romano Agentic PBI Development GitHub Repo
• Microsoft Fabric End-to-End Analytics Sample using CMS Medicare Part D Dataset

Related Reading

As we move into a new era where AI is accelerating our day‑to‑day work, we’re seeing many innovative ways to apply it in practice. If using MCP with Visual Studio Code feels too much like traditional coding and isn’t of your, my colleague Greg Beaumont offers a great alternative. In his article (with a companion video), Greg shows how M365 Copilot can assess an existing Power BI semantic model and recommend targeted optimizations. The result is an AI‑generated set of actionable recommendations that Power BI developers can use to improve their semantic models faster and more efficiently. Read more here — Use M365 Copilot to improve Power BI semantic models, power query, and report speed

Agentic AI development for Power BI Semantic Models using GitHub Copilot and Power BI Modeling MCP… was originally published in Microsoft Azure on Medium, where people are continuing the conversation by highlighting and responding to this story.

Have you been curious about feature rollouts — how do you enable features for specific users or toggle something off quickly without redeploying? Recently, I built a demo API to explore this concept using Azure App Configuration. The idea was simple: control features and manage user access dynamically, all without touching code or restarting services.

In this article, I’ll walk you through implementing dynamic configuration in a .NET API using Azure App Configuration, IOptionsSnapshot, and IFeatureManager

The Problem

Let’s say you’re building an API and need to:

· Enable a new feature for beta users only

·Quickly disable a feature that’s causing errors

· Manage which users can access certain functionality

· Make these changes instantly without redeployment

The traditional approach? Update appsettings.json, push to GitHub, wait for CI/CD pipelines, and deploy. But what if a feature breaks at midnight and you need to turn it off immediately?

Why Azure App Configuration?

Azure App Configuration is a managed service for storing application settings and feature flags centrally. The best part? Your app can pull updated values at runtime without restarting. Think of it as a remote control for your application’s behavior.

Understanding IFeatureManager vs IOptionsSnapshot

Before we dive into code, let me explain these two patterns because they solve different problems:

IFeatureManager — Feature Flags (Boolean Toggles)

What it does: Controls whether a feature is ON or OFF.

Use it when:

· You need a simple yes/no decision

· Toggling entire features on/off

· A/B testing scenarios

· Emergency feature kill switches

Example use case: “Should we show the new checkout flow?”

var isEnabled = await _featureManager.IsEnabledAsync("ApplyDiscount");

if (isEnabled)
{
    // Execute feature logic
}

IOptionsSnapshot — Configuration Values (Complex Data)

What it does: Provides structured configuration data (strings, numbers, lists, objects).

Use it when:

· You need actual values, not just toggles

· Managing lists (allowed users, product IDs)

· Configuration thresholds or limits

· Structured settings that change frequently

Example use case: “Which users are allowed to access this feature?”

var allowedUsers = _optionsSnapshot.Value.AllowedUserIds;
if (allowedUsers.Contains(userId))
{
    // Grant access
}

Real-World Example

Let’s say you have a discount feature. Here’s how you’d use both together:

// Step 1: Check if discount feature is enabled (IFeatureManager)
var isDiscountEnabled = await _featureManager.IsEnabledAsync("ApplyDiscount");

if (isDiscountEnabled)
{
    // Step 2: Get the discount configuration (IOptionsSnapshot)
    var discountPercentage = _optionsSnapshot.Value.Percentage;
    var allowedUsers = _optionsSnapshot.Value.AllowedUserIds;
    
    // Step 3: Apply business logic
    if (allowedUsers.Contains(userId))
    {
        price = price * (1 - discountPercentage);
    }
}

IFeatureManager answers: “Is the discount feature turned on?”

IOptionsSnapshot answers: “What’s the discount percentage and who’s eligible?”

This separation is powerful because you can:

· Toggle features on/off instantly without changing business logic

· Update configuration values (like discount percentage) without touching feature flags

· Combine both for granular control

Now let’s see how to implement this in a real API.

Prerequisites

Before we start:

· .NET 8.0 SDK

· Azure subscription (free tier is enough)

· Basic knowledge of ASP.NET Core

Project Setup

Create Azure App Configuration Resource on Azure

Capture the Connection String from the Azure portal:

Note: The code snippets added below can be referenced from my GitHub repo

Create a new Web API project:

dotnet new webapi -n TestAppConfig
cd TestAppConfig

Install the required packages:

dotnet add package Microsoft.Azure.AppConfiguration.AspNetCore
dotnet add package Microsoft.FeatureManagement.AspNetCore

Local Configuration files:

Notice two sections:

• FeatureManagement — for feature flags (IFeatureManager)
• DiscountSettings — for configuration values (IOptionsSnapshot)

Creating the Configuration Model

First, let’s define a model for our settings. I’m keeping it simple with two lists — allowed users and products:

Here’s where it gets interesting. Open Program.cs and add the Azure connection:

Let me break down what’s happening here:

Connection Setup: We check if an Azure connection string exists before attempting to use it. This way, the app works locally without Azure too.

Refresh Strategy: The RegisterAll() method tells Azure to monitor all configuration keys. We set a 5-second refresh interval, meaning the app checks for updates every 5 seconds.

Feature Management: AddFeatureManagement() registers the feature flag system, making IFeatureManager available for dependency injection.

Options Pattern: Configure<DiscountSettings> binds our configuration section to the strongly-typed model, enabling IOptionsSnapshot<DiscountSettings>.

Middleware: app.UseAzureAppConfiguration() is crucial — it enables automatic configuration refresh on incoming requests.

Building the Controller

Let’s create an endpoint that demonstrates both patterns:

This controller shows both patterns in action:

debug-config — Shows current feature flag state and configuration values

Adding Feature Flags (IFeatureManager)

In the Azure Portal:

1. Navigate to your App Configuration resource
2. Open Feature Manager (this is specifically for IFeatureManager)
3. Click Create
4. Enter name: ApplyDiscount
5. Toggle it ON or OFF as needed

Important: Feature flags go in Feature Manager, not Configuration Explorer. This is the section that feeds IFeatureManager.

Adding Configuration Values (IOptionsSnapshot)

Go to Configuration Explorer (this is for IOptionsSnapshot data):

The Content Type Detail

Here’s something that wasn’t obvious from the docs — content type matters a lot for IOptionsSnapshot.

When you set content type to application/json:

· Azure parses your JSON value

· It creates hierarchical configuration keys internally

· IOptionsSnapshot can properly bind these to List<string>

Without application/json:

· Azure stores your value as a plain string:

· IOptionsSnapshot receives the literal text “[“user15”,”user16"]”

· It can’t convert this string to a list automatically

· Your app falls back to local appsettings.json values

This detail cost me about 15 mins of debugging. I kept wondering why my Azure values weren’t showing up in IOptionsSnapshot, and it turned out to be just the missing content type setting.

Note: Feature flags (IFeatureManager) don’t need content type because they’re always booleans.

Make sure to build and run the project:

dotnet build

dotnet run

Testing Without Any Values configured in Azure App Config:

curl http://localhost:5054/api/products/debug-config

It picks from the local configuration file

Testing the Hot Reload

curl http://localhost:5054/api/products/debug-config

It picks from the Azure App Config Resource

This shows how IFeatureManager and IOptionsSnapshot work together!

Why IOptionsSnapshot is Request-Scoped

One important detail: IOptionsSnapshot is request-scoped, meaning it gets fresh configuration values on each HTTP request.

Other options patterns:

• IOptions — Singleton, never reloads (not useful for hot reload)
• IOptionsMonitor — Singleton, reloads but same instance across all requests
• IOptionsSnapshot — Scoped per request, perfect for hot reload in APIs

That’s why we use IOptionsSnapshot for this scenario — it automatically picks up refreshed values on each request.

Final Thoughts

Azure App Configuration with IOptionsSnapshot and IFeatureManager gives you real-time control over your application’s behavior. Understanding when to use each pattern is key:

• IFeatureManager — Boolean toggles (is feature on/off?)
• IOptionsSnapshot — Configuration data (what are the values?)

The key points to remember:

Use RegisterAll() with SetRefreshInterval for automatic updates

• Always set content type to application/json for arrays and objects in IOptionsSnapshot
• IOptionsSnapshot is request-scoped and perfect for hot reload
• The middleware (UseAzureAppConfiguration) is what makes refresh work
• Feature flags go in Feature Manager, configuration goes in Configuration Explorer

This approach has made my demo API much more flexible. No more redeployments just to change a configuration value or toggle a feature. Hope this helps you implement something similar!

References:

• dotnet-demos/TestAppConfig at main · sainiteshGit/dotnet-demos
• Quickstart for adding feature flags to ASP.NET Core apps - Azure App Configuration
• What is Azure App Configuration?

Managing Feature Flags and Dynamic Configuration in .NET Web App with Azure App Configuration was originally published in Microsoft Azure on Medium, where people are continuing the conversation by highlighting and responding to this story.

Been digging into the Microsoft Agent Framework lately, and I came across this feature that’s pretty fundamental for production agents: ChatHistoryProvider.

If you’re building anything beyond a quick prototype, you’ll probably need this.

The Default Behavior (And Why It’s a Problem):

So, here’s what happens out of the box — agents store conversation history in memory. Which is fine for testing. But the second your container recycles or your app restarts? Gone. All of it.

Think about a support bot that takes an order number, then ten minutes later has no idea what you were talking about. Or a multi-step workflow that can’t survive a deployment. That’s what you get with in-memory storage.

The framework solves this with ChatHistoryProvider — basically a pluggable backend for where conversations get saved.

What’s Available?

A few options ship with the framework:

· In-memory — the default, works for dev

· CosmosChatHistoryProvider — what I’m using

· Custom implementations — if you need something specific

I went with Cosmos DB because I wanted to explore the integration with cosmos database and is less code to maintain.

Setting It Up:

You will need Azure OpenAI and Azure CosmosDB resource created. Follow instructions here to create cosmos and Azure OpenAI

Cosmos: https://learn.microsoft.com/en-us/azure/cosmos-db/quickstart-portal

Azure OpenAI: https://learn.microsoft.com/en-us/microsoft-cloud/dev/tutorials/openai-acs-msgraph/02-openai-create-resource

Include the following packages in your .NET project:

Please refere this GitHub repo for the full code for below project

<PackageReference Include="Microsoft.Agents.AI" Version="1.0.0-preview.260128.1" />
<PackageReference Include="Microsoft.Agents.AI.CosmosNoSql" Version="1.0.0-preview.260128.1" />
<PackageReference Include="Microsoft.Extensions.AI.OpenAI" Version="9.5.0-preview.1.25265.7" />
<PackageReference Include="Azure.AI.OpenAI" Version="2.2.0-beta.1" />

The ChatHistoryProviderFactory is a delegate. Framework calls it when it needs a provider instance. Flexible pattern — you could route different users to different backends.

Running the agent:

Messages get persisted automatically after that.

Session Serialization

This part is useful. You can serialize sessions:

Auth Options

Connection string works for local dev

Managed identity for production

Things to Watch Out For

Partition key — Has to be /conversationId. The provider expects that exact path.

Resources don’t auto-create — If the database or container doesn’t exist, you get a 404. Create them first.

Preview packages — These are still preview, so APIs might shift between versions.

The above provided snippets is available in my GitHub repo

Running the Application:

State in Cosmos Database:

When Does This Make Sense

· Multi-turn conversations where context matters

· Distributed deployments with multiple instances

· Anything that might restart or get recycled

· You need audit logs of conversations

References:

• Integration with Azure AI Agent Service - Azure Cosmos DB for NoSQL
• Agent Framework Integrations
• Quickstart - Azure portal - Azure Cosmos DB
• sample-ai-project/msft-agent-framework-integrations/ChatHistoryProviderSample at master · sainiteshGit/sample-ai-project

Chat History Providers in Microsoft Agent Framework — Making Agents Remember was originally published in Microsoft Azure on Medium, where people are continuing the conversation by highlighting and responding to this story.