Azure Infrastructure Blog articles

Qurious About Quantum?

JohnGruszczyk — Tue, 14 Apr 2026 17:14:06 GMT

Why IT Should Care About Quantum Right Now – It’s Not Just A Research Problem

Today on April 14th, 2026 we celebrate World Quantum Day! There has been a noticeable rise in the topic of quantum computing appearing across technical conferences, business news, and strategic planning conversations. But what does this have to do with the IT pros and infrastructure architects driving today's technology decisions - isn't the focus on AI and agents? As it turns out, we may be in a state of superposition .

The last few years have produced genuine quantum breakthroughs, including our Majorana 1 topological quantum processor and partnership with QuNorth whose Magne system will be the world’s first commercially available level 2 quantum computer. These milestones represent a meaningful shift from theoretical promise to engineering reality. But quantum computing will not exist in isolation – it will require deep integration with classical computing, traditional systems and AI infrastructure. If you build or manage systems, familiarity with what you already know will get you further in understanding quantum than you might expect.

This lecture series does not deal in hype (quantum has enough of that). It’s designed to give IT pros, developers, researchers, and anyone curious about quantum a grounded understanding of what it will take to architect, scale, and run quantum systems in the real world. It offers clarity on what quantum computers will actually be good at, how to size one for a real problem, and how performance optimization techniques you already know from classical HPC can translate to quantum. So, whether you can derive a Hamiltonian in your sleep or have quietly searched "what is a qubit" more than once, no physics PhD is required.

Lecture 1: Utility Scale Quantum Applications

Where quantum shines and where classical still rules

Before diving into quantum computing, it helps to understand what it is actually useful for. The lecture opens with a deceptively simple question - when does a quantum computer beat a classical one and by how much does it need to beat it to actually matter? The answer involves computational complexity, scaling laws, and a reality check that will reframe how you think about quantum advantage. Spoiler alert: a quadratic speedup sounds impressive until you run the numbers and discover the crossover time is somewhere in the neighborhood of the age of the universe (not useful!). The problems that do survive this filter - chemistry, materials science, and biochemistry - turn out to be the ones that matter most for the future of fields like manufacturing, energy, medicine, and climate.

The lecture closes with an exciting vision still grounded in today's technology — using quantum computers to teach quantum physics to AI, combining the accuracy of quantum simulation with the speed of inference to unlock a new generation of materials and molecules. Watch Lecture 1

Lecture 2: Utility Scale Quantum Architecture

You already know more than you think!

A fun fact about quantum computing architecture is that the abacus and today's fastest GPU operate on the same fundamental principle. Quantum computers are where that 4,500-year streak finally ends, but the architecture built around them will look surprisingly familiar. This lecture covers how a quantum computer can easily fit into a cloud data center, and not as some exotic standalone machine, but as a complementary computational accelerator in the stack sitting alongside CPUs, GPUs, and FPGAs. From there the lecture covers the full software stack from high-level application code all the way down to the control pulses sent to physical qubits — and the parallels to classical compilation, optimization, and execution are striking at every layer.

And a prediction worth sitting with if you aren’t a quantum developer - by the time utility-scale quantum computers exist, most of us will be programming them in natural language with tools like Copilot. As it turns out vibe coding has a quantum future. Watch Lecture 2

Lecture 3: Utility Scale Quantum Resource Estimation

Sizing a quantum computer for real problems

Capacity planning for a quantum computer is one of the most consequential decisions in building one. Resource estimation is the quantum equivalent of sizing a classical HPC workload. The worked example of estimating the quantum resources required to simulate a ruthenium-based carbon fixation catalyst highlights the importance of the topic (no we won’t spoil the answer). Along the way you will meet magic state distillation, a wonderfully named process for producing high-fidelity quantum gate operations from noisy physical qubits. And if that isn’t enough excitement, explore why the tradeoff between qubit quality and qubit quantity is one of the most consequential engineering decisions in the field.

For chip architects, infrastructure designers, and anyone who loves going deep on system tradeoffs this one is for you. Watch Lecture 3

Lecture 4: High Performance Quantum Computing

BLAS, MPI, NUMA - meet your quantum counterparts

This is where HPC engineers will feel most at home, and maybe most surprised. The core challenges of high-performance quantum computing are not new problems. They are the same problems classical computing solved over decades, showing up again in a new context. Every one of these concepts - instruction-level parallelism, optimized kernel libraries, autotuning, message passing, non-uniform memory access - has a direct quantum analog covered with concrete examples. The quantum version of MPI even reuses nearly the entire standard. Just two new commands were added to handle something classical systems never had to worry about - you cannot copy a quantum state.

If you have ever tuned a distributed workload or wrestled with NUMA topology, this lecture will show you exactly where your existing expertise carries directly into quantum and open up a whole new context to apply it. Watch Lecture 4

Follow along for more lectures

Lecture 5 covering "Trade‑offs on the Path to Utility Scale" was published this morning as part of World Quantum Day covering multiple challenges that must be overcome to achieve utility-scale quantum computing. Dr. Troyer and the Microsoft Quantum team will continue expanding this series with new lectures covering what it takes to build and operate at quantum scale. Future topics include scalable quantum architecture, balancing the cost of utility-scale quantum computing, quantum simulations of chemical reactions, and responsible quantum computing.

Follow the series at https://quantum.microsoft.com/en-us/insights/industry-insights/quantum-architecture-series and we'd love to hear from you. Leave a comment below with the quantum topics you'd like to see covered next!

Service Mesh-Aware Request Tracing in AKS with Istio and Application Insights

Siddhi_Singh — Fri, 10 Apr 2026 16:37:58 GMT

Introduction

As platforms evolve toward microservice‑based architectures, observability becomes more complex than ever. In Azure Kubernetes Service (AKS), teams often rely on Istio to manage service‑to‑service communication and Azure Application Insights for application‑level telemetry.

While both are powerful, they operate at different layers and without deliberate configuration, correlating a single request across the service mesh and the application layer is not straightforward.

This blog walks through a practical, production‑ready solution to enable Istio (Envoy) access logging in AKS and correlate those logs with Application Insights telemetry, allowing engineers to trace a request end‑to‑end for faster troubleshooting and deeper visibility.

Platform Observability Context

The environment consists of:

AKS with managed Istio enabled
Envoy sidecars injected into application pods
Azure Application Insights SDK running inside workloads
Log Analytics as the centralized log store

Istio is responsible for traffic management, while Application Insights captures application‑level telemetry. The goal was to align these layers using a common trace context, without introducing additional tracing systems or custom agents.

Enabling Istio Access Logging at the Mesh Level

The first step is to ensure that Envoy access logs are emitted consistently across the service mesh. Istio provides the Telemetry API, which allows access logging to be enabled centrally without modifying individual workloads.

Apply a Telemetry resource in the Istio system namespace to enable Envoy access logging:

apiVersion: telemetry.istio.io/v1 kind: Telemetry metadata: name: mesh-access-logs namespace: aks-istio-system spec: accessLogging: - providers: - name: envoy

This configuration ensures that:

All Envoy sidecars emit access logs
Logging behavior is uniform across the mesh
The setup remains compatible with AKS managed Istio

Standardizing Envoy Logs Using EnvoyFilter

Access logs must be structured to be useful at scale. In AKS managed Istio, direct Envoy configuration is restricted, so EnvoyFilter is used to customize logging behavior.

EnvoyFilters are configured to:

Emit logs in structured JSON format
Write logs to /dev/stdout
Include trace and request correlation headers

To achieve full visibility, separate EnvoyFilters are applied for inbound and outbound sidecar traffic.

apiVersion: networking.istio.io/v1alpha3 kind: EnvoyFilter metadata: name: json-access-logs namespace: aks-istio-system spec: configPatches: - applyTo: NETWORK_FILTER match: context: SIDECAR_INBOUND listener: filterChain: filter: name: envoy.filters.network.http_connection_manager patch: operation: MERGE value: typed_config: "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager access_log: - name: envoy.access_loggers.file typed_config: "@type": type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog path: /dev/stdout log_format: json_format: timestamp: "%START_TIME%" method: "%REQ(:METHOD)%" path: "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%" response_code: "%RESPONSE_CODE%" response_flags: "%RESPONSE_FLAGS%" duration_ms: "%DURATION%" downstream_remote_address: "%DOWNSTREAM_REMOTE_ADDRESS%" x_request_id: "%REQ(X-REQUEST-ID)%" traceparent: "%REQ(TRACEPARENT)%" tracestate: "%REQ(TRACESTATE)%" x_b3_traceid: "%REQ(X-B3-TRACEID)%"

This configuration ensures inbound traffic logs contain both request metadata and correlation identifiers.

Configuring Outbound Envoy Access Logs

Outbound logging is required to observe downstream calls made by a service. Apply a second EnvoyFilter for outbound traffic:

apiVersion: networking.istio.io/v1alpha3 kind: EnvoyFilter metadata: name: json-access-logs-outbound namespace: aks-istio-system spec: configPatches: - applyTo: NETWORK_FILTER match: context: SIDECAR_OUTBOUND listener: filterChain: filter: name: envoy.filters.network.http_connection_manager patch: operation: MERGE value: typed_config: "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager access_log: - name: envoy.access_loggers.file typed_config: "@type": type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog path: /dev/stdout log_format: json_format: timestamp: "%START_TIME%" method: "%REQ(:METHOD)%" path: "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%" response_code: "%RESPONSE_CODE%" response_flags: "%RESPONSE_FLAGS%" duration_ms: "%DURATION%" downstream_remote_address: "%DOWNSTREAM_REMOTE_ADDRESS%" x_request_id: "%REQ(X-REQUEST-ID)%" traceparent: "%REQ(TRACEPARENT)%" tracestate: "%REQ(TRACESTATE)%" x_b3_traceid: "%REQ(X-B3-TRACEID)%"

Inbound and outbound logs now follow the same schema, enabling consistent querying and analysis.

Automating the Configuration with PowerShell

To standardize and repeat the setup across environments, wrap the configuration in a PowerShell script. The script should:

Validate the Istio system namespace
Apply the Telemetry resource
Apply inbound and outbound EnvoyFilters

$MeshRootNamespace = "aks-istio-system" $TelemetryName = "mesh-access-logs" $EnvoyFilterName = "json-access-logs" kubectl get ns $MeshRootNamespace --ignore-not-found $telemetryYaml | kubectl apply -f - $envoyFilterYaml | kubectl apply -f - $envoyFilterOutboundYaml | kubectl apply -f -

Log Ingestion into Azure Monitor

Because Envoy access logs are written to standard output:

AKS automatically collects them
Logs are ingested into Log Analytics
Data appears in the ContainerLogV2 table

No additional agents or custom log pipelines are required.

Aligning with Application Insights Telemetry

Application Insights uses W3C Trace Context, where the operation_Id represents the trace identifier. Since Envoy access logs capture the traceparent header, both systems expose the same trace ID.

This alignment allows service mesh logs and application telemetry to be correlated without changing application code.

Correlating Requests Using KQL

To analyze request flow:

Parse JSON access logs from ContainerLogV2
Extract the trace ID from traceparent
Join with Application Insights request telemetry

To validate end‑to‑end tracing, use Log Analytics to query Istio access logs collected in the ContainerLogV2 table. Since Envoy access logs include the traceparent header, the trace‑id embedded in it directly maps to the Application Insights operation_Id. By filtering istio-proxy logs on this trace‑id, it becomes possible to view the full Envoy request record for a specific application request and trace it across the service mesh and application layers.

KQL (filter Istio access logs using an Application Insights operation_Id)

let operationId = "<OperationID>"; // Replace with your actual operation_Id ContainerLogV2 | where TimeGenerated >= ago(24h) | where ContainerName == "istio-proxy" | where LogSource == "stdout" | where LogMessage startswith "{" | extend AccessLog = parse_json(LogMessage) | extend ExtractedOperationId = extract(@"00-([a-f0-9]{32})-", 1, tostring(AccessLog.traceparent)) | where ExtractedOperationId == operationId | project TimeGenerated, PodName, Method = tostring(AccessLog.method), Path = tostring(AccessLog.path), ResponseCode = toint(AccessLog.response_code), RequestId = tostring(AccessLog.x_request_id), TraceParent = tostring(AccessLog.traceparent), TraceState = tostring(AccessLog.tracestate), Authority = tostring(AccessLog.authority), RawLogMessage = LogMessage | order by TimeGenerated asc

Closing Thoughts

End‑to‑end request tracing in AKS is achieved by aligning service mesh logging and application telemetry around shared standards. By enabling structured Istio access logs and correlating them with Application Insights, platforms gain clear visibility into request flow across networking and application layers using Azure‑native tools.

This process scales well in managed Istio environments and provides meaningful observability without adding platform complexity.

Building an End-to-End MLOps Pipeline: From Training to Managed Endpoints on Azure

Gapandey — Thu, 09 Apr 2026 10:45:39 GMT

Introduction

Machine learning models are only as valuable as the infrastructure that supports them. A model trained in a Jupyter notebook and saved to a shared folder creates a chain of problems: no versioning, no reproducibility, no clear ownership, and no automated path to production. When the data scientist who trained it goes on vacation, nobody knows how to retrain it or where the latest version lives.

A well-designed MLOps pipeline solves all of this. It makes training repeatable, artifacts versioned, and deployment automated — so that the path from code change to live endpoint is a single merge to main.

This post provides a generic, end-to-end pattern covering the full lifecycle:

Train a scikit-learn model against data in Azure Blob Storage
Serialize the model as a self-contained pickle bundle
Register it in an Azure ML Registry for cross-team discovery
Deploy it to an Azure ML Managed Online Endpoint for real-time scoring

You can adapt this template for any scikit-learn model — classification, regression, clustering, or anomaly detection — by swapping in your own training and scoring scripts.

When to Use This Pattern

This pipeline template is a good fit when:

Your training data lives in Azure Blob Storage (Parquet, CSV, or similar)
You use scikit-learn (or any Python ML framework) for model training
You need versioned model artifacts in a central registry
You want an automated deployment path to a live scoring endpoint
Downstream consumers (scoring pipelines, APIs, dashboards) need a reliable handoff mechanism
You want to eliminate ad-hoc notebook-based training with no versioning or reproducibility

It is not the right fit if you need distributed training (use Azure ML pipelines instead), or if your model requires GPU inference (managed endpoints support GPU, but the config differs from what's shown here).

Architecture Overview

The pipeline follows a four-stage flow:

DevOps Gate → Train & Publish Artifact → Register in ML Registry → Deploy to Managed Endpoint

DevOps Stage — A required gate that logs the build number and validates the pipeline is running.
Train Stage — Installs Python dependencies, runs the training script against data in Azure Blob Storage, and publishes the pickle bundle as a pipeline artifact.
Register Stage — Downloads the artifact and registers it in an Azure ML Registry with automatic versioning.
Deploy Stage — Creates (or updates) a Managed Online Endpoint and deploys the newly registered model version to it for real-time scoring.

The first three stages run on every push to main. The Deploy stage can be gated with a manual approval if you want human review before going live.

The Training Script

The training script is the core of this pipeline — everything else is orchestration around it. It's a standalone Python CLI that you should be able to run locally before it ever touches a pipeline.

The general shape is:

Load data from Azure Blob Storage (Parquet, CSV, etc.) using libraries like adlfs and pyarrow.
Validate the schema — check that expected columns exist, types are correct, and there are enough rows to train on. Fail fast with a clear error message if not.
Engineer features — compute derived columns, handle missing values, encode categorical. This is where most of the domain-specific logic lives.
Train the model using scikit-learn (or your framework of choice).
Apply preprocessing (e.g., StandardScaler) and save the preprocessor alongside the model so that scoring uses the exact same transformations.
Serialize a bundle containing the model, preprocessor, feature column order, and training metadata into a single pickle file.

The script reads storage credentials from environment variables, keeping secrets out of the codebase entirely. It accepts an --output-path argument and writes the serialized bundle to that location — which the pipeline later publishes as an artifact.

What Goes in the Bundle

The pickle file isn't just the model — it's a self-contained scoring contract. Here's what's inside and why:

Key	Type	Purpose
model	scikit-learn estimator	The trained model (e.g., IsolationForest, RandomForestClassifier)
scaler	StandardScaler (or similar)	The exact preprocessor fitted on training data — scoring must use the same transform
feature_order	list[str]	Column names in the exact order the model expects — prevents silent column reordering bugs
metadata.trained_at	ISO timestamp	When the model was trained — useful for debugging stale predictions
metadata.source_rows	int	How many rows were in the raw data — helps detect data pipeline issues
metadata.clean_rows	int	How many rows survived cleaning — a sudden drop signals a data quality problem
metadata.scikit_learn_version	str	The scikit-learn version used — pickle compatibility can break across major versions

This structure means any consumer can load the bundle, inspect what's in it, and score new data without knowing anything about how the model was trained.

Choosing a Serialization Format

This template uses pickle, but you should choose based on your needs:

Format	Best For	Trade-off
pickle	Bundles with metadata (model + scaler + feature order + config)	Built-in, no extra deps. Not safe to load from untrusted sources.
joblib	Large NumPy array-heavy models	Faster for large arrays, but adds a dependency.
ONNX	Cross-framework interop (PyTorch ↔ scikit-learn)	Portable, but not all model types are supported.

Pickle works well when your artifact is a self-contained bundle — model, preprocessor, feature column order, and training metadata in one file. Any consumer who loads it gets everything needed to score new data correctly.

Security note: Never load pickle files from untrusted sources — deserialization can execute arbitrary code. This is safe when the pickle is produced by your own pipeline and stored in an access-controlled registry, but always validate provenance.

The Pipeline YAML

Here's the full pipeline template. Replace <your-...> placeholders with your values:

trigger: branches: include: - main paths: include: - <your-model-source-path>/* # e.g., src/models/anomaly-detection/* stages: - stage: DevOps displayName: Required DevOps Stage jobs: - job: Echo steps: - script: echo build initiated - $(Build.BuildNumber) - stage: Train dependsOn: DevOps displayName: 'Train Model & Publish Artifact' jobs: - job: TrainModel steps: - checkout: self - task: UsePythonVersion@0 inputs: versionSpec: '3.12' # Use a supported Python version - script: | python -m pip install --upgrade pip pip install -r requirements.txt displayName: 'Install Python dependencies' - script: | python <your-training-script>.py \ --output-path "$(Build.ArtifactStagingDirectory)/model_bundle.pkl" displayName: 'Train model' env: AZURE_STORAGE_ACCOUNT_NAME: $(AZURE_STORAGE_ACCOUNT_NAME) AZURE_STORAGE_ACCOUNT_KEY: $(AZURE_STORAGE_ACCOUNT_KEY) # See note on Managed Identity below - task: PublishPipelineArtifact@1 # Use the modern task inputs: artifactName: 'model-pkl' targetPath: '$(Build.ArtifactStagingDirectory)/model_bundle.pkl' - stage: Register dependsOn: Train displayName: 'Register Model in ML Registry' jobs: - job: RegisterModel steps: - task: DownloadPipelineArtifact@2 # Use the modern task inputs: artifactName: 'model-pkl' targetPath: '$(System.ArtifactsDirectory)/model-pkl' - task: AzureCLI@2 displayName: 'Register model in ML Registry' inputs: azureSubscription: '<your-service-connection>' scriptType: 'ps' scriptLocation: 'inlineScript' inlineScript: | az extension add -n ml --yes az ml model create ` --name <your-model-name> ` --path "$(System.ArtifactsDirectory)/model-pkl/model_bundle.pkl" ` --type custom_model ` --registry-name <your-ml-registry> ` --resource-group <your-resource-group>

Placeholder Reference

Placeholder	Description	Example
<your-model-source-path>	Path to your model code in the repo	src/models/anomaly-detection
<your-training-script>	Your Python training script	train_model.py
<your-service-connection>	Azure DevOps service connection name	prod-ml-connection
<your-model-name>	Name for the model in the registry	sales-anomaly-detector
<your-ml-registry>	Azure ML Registry name	contoso-ml-registry
<your-resource-group>	Resource group containing the registry	rg-ml-prod

Key Design Decisions

Credentials as environment variables — Storage credentials are stored in an Azure DevOps variable group and injected via the env: block. They never appear on the command line or in logs.

Prefer Managed Identity over keys. The template above shows AZURE_STORAGE_ACCOUNT_KEY for simplicity, but the recommended approach is to authenticate using a User Managed Identity (UMI) with the Storage Blob Data Reader role. This eliminates key rotation and reduces the credential surface. If your agent supports Managed Identity (e.g., self-hosted on an Azure VM), use DefaultAzureCredential in your training script instead of account keys.

Separate Train and Register stages — The training artifact is published as a pipeline artifact between stages. This means if registration fails, you don't have to retrain. It also gives you a downloadable artifact in Azure DevOps for debugging.

az ml model create with --registry-name — This registers the model in an Azure ML Registry (not a workspace). Registries are shared across workspaces and teams, making the model accessible to anyone with the right permissions.

Auto-versioning — Each az ml model create call with the same --name automatically increments the version number in the registry. No manual version management needed.

Permissions

The pipeline authenticates using a User Managed Identity (UMI) linked to an Azure DevOps service connection via workload identity federation. The UMI needs:

Role	Scope	Purpose
Storage Blob Data Reader	Storage account or container	Read training data
AzureML Registry User	ML Registry	Register model artifacts
AzureML Data Scientist	ML Workspace	Create/update managed endpoints and deployments

No Contributor or Owner access at the subscription or resource group level is required. Least-privilege access keeps the blast radius small.

Workload Identity Federation vs. secrets: If your Azure DevOps service connection uses workload identity federation (recommended), the UMI authenticates without any stored secrets. If using a service principal with client secret instead, store the secret in an Azure DevOps variable group marked as secret, and rotate it regularly.

Common Pitfalls

These are issues you'll likely hit when adapting this template:

Column name mismatches. Parquet files may have column names like periodid while your script expects Period ID. Add a case-insensitive column rename mapping in your training script and validate the data schema before training starts.

Windows agents use cmd.exe, not bash. If your pipeline runs on self-hosted Windows agents, backslash line continuations and bash-style commands won't work. Use single-line commands or PowerShell syntax, and use Windows-style path separators.

checkout: self vs named repositories. When your pipeline YAML lives in the same repo as your training code, always use checkout: self. A named repository checkout pulls the default branch, not the feature branch you're testing — leading to stale code running in your pipeline.

Start with the training script, not the pipeline. Get your training script working locally first. The pipeline is just orchestration — if the script doesn't work on your machine, it won't work in the pipeline either.

Pin your dependencies. Use a requirements.txt with pinned versions rather than inline pip install with unpinned packages. A scikit-learn minor version bump can change model behavior silently.

Deploying to a Managed Online Endpoint

Registering the model in the Azure ML Registry makes it discoverable. But for real-time scoring — where an API, dashboard, or another service sends data and gets predictions back — you need to deploy the model to a Managed Online Endpoint.

Azure ML Managed Online Endpoints handle the infrastructure: provisioning compute, load balancing, scaling, health probes, and rolling deployments. You provide the model and a scoring script.

HTTP Request (JSON) → Managed Online Endpoint → Deployment (blue) → score.py [init() / run()] + model.pkl → JSON Response (predictions)

Key concepts:

An endpoint is the HTTPS URL that clients call. It has auth (key or AAD token) and a DNS name.
A deployment sits behind the endpoint and runs your scoring code + model on provisioned compute.
You can have multiple deployments (e.g., blue and green) behind one endpoint for A/B testing or canary rollouts, controlled by traffic splitting.

The Scoring Script

The scoring script is the glue between the endpoint and your pickle bundle. Azure ML calls init() once when the container starts, and run() on every incoming request.

# score.py — deployed alongside the model import json import pickle import os import numpy as np import pandas as pd def init(): """Called once when the endpoint container starts.""" global model_bundle model_path = os.path.join(os.getenv("AZUREML_MODEL_DIR"), "model_bundle.pkl") with open(model_path, "rb") as f: model_bundle = pickle.load(f) print(f"Model loaded. Trained at: {model_bundle['metadata']['trained_at']}") print(f"Expected features: {model_bundle['feature_order']}") def run(raw_data): """Called on every scoring request.""" try: data = json.loads(raw_data) df = pd.DataFrame(data["input_data"]) # Enforce feature order from the bundle df = df[model_bundle["feature_order"]] # Apply the same scaler used during training scaled = model_bundle["scaler"].transform(df) # Predict predictions = model_bundle["model"].predict(scaled) return json.dumps({ "predictions": predictions.tolist(), "model_version": model_bundle["metadata"].get("scikit_learn_version", "unknown"), }) except KeyError as e: return json.dumps({"error": f"Missing expected column: {e}"}) except Exception as e: return json.dumps({"error": str(e)})

Key things to notice:

AZUREML_MODEL_DIR — Azure ML automatically downloads the model artifact from the registry and sets this environment variable to the local path. You never deal with storage URLs in scoring code.
Feature order enforcement — df[model_bundle["feature_order"]] ensures columns are in the exact order the model was trained on, even if the caller sends them in a different order.
Same scaler — The StandardScaler from the bundle is reused, so the numerical scaling matches training exactly. This is why we bundle the scaler with the model.

The Deploy Stage in the Pipeline

Add this stage after the Register stage. All endpoint and deployment configuration is done inline via az ml CLI parameters — no separate YAML config files needed:

- stage: Deploy dependsOn: Register displayName: 'Deploy to Managed Endpoint' jobs: - job: DeployModel steps: - checkout: self # to access score.py - task: AzureCLI@2 displayName: 'Create or update endpoint' inputs: azureSubscription: '<your-service-connection>' scriptType: 'ps' scriptLocation: 'inlineScript' inlineScript: | az extension add -n ml --yes # Create endpoint if it doesn't exist (idempotent) $exists = az ml online-endpoint show ` --name <your-endpoint-name> ` --resource-group <your-resource-group> ` --workspace-name <your-workspace> 2>$null if (-not $exists) { az ml online-endpoint create ` --name <your-endpoint-name> ` --auth-mode key ` --resource-group <your-resource-group> ` --workspace-name <your-workspace> } - task: AzureCLI@2 displayName: 'Deploy model to endpoint' inputs: azureSubscription: '<your-service-connection>' scriptType: 'ps' scriptLocation: 'inlineScript' inlineScript: | az extension add -n ml --yes az ml online-deployment create ` --name blue ` --endpoint-name <your-endpoint-name> ` --model azureml://registries/<your-ml-registry>/models/<your-model-name>/versions/<version-number> ` --code-path ./scoring ` --scoring-script score.py ` --environment-image mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu22.04:latest ` --instance-type Standard_DS3_v2 ` --instance-count 1 ` --resource-group <your-resource-group> ` --workspace-name <your-workspace> ` --all-traffic - task: AzureCLI@2 displayName: 'Smoke test the endpoint' inputs: azureSubscription: '<your-service-connection>' scriptType: 'ps' scriptLocation: 'inlineScript' inlineScript: | az extension add -n ml --yes # Send a test request to verify the deployment is healthy az ml online-endpoint invoke ` --name <your-endpoint-name> ` --resource-group <your-resource-group> ` --workspace-name <your-workspace> ` --request-file scoring/sample-request.json

Version pinning is critical. The scikit-learn version in your scoring environment must match the version used during training. Pickle deserialization can fail or produce wrong results if the versions differ.

Deploy Stage Placeholder Reference

Placeholder	Description	Example
<your-endpoint-name>	Unique endpoint name (DNS-safe)	anomaly-scoring-endpoint
<your-workspace>	Azure ML Workspace name	ml-workspace-prod

Complete Pipeline — All Four Stages

Here's the full pipeline structure showing how Train, Register, and Deploy connect:

stages: - stage: DevOps # Gate - stage: Train # Train model → publish pickle artifact dependsOn: DevOps - stage: Register # Register pickle in Azure ML Registry dependsOn: Train - stage: Deploy # Deploy to Managed Online Endpoint dependsOn: Register # Optional: add a manual approval gate here # condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))

Each stage is independently retriable. If Deploy fails, you don't retrain or re-register — you just redeploy.

Extending This Template

Once the base pipeline is working, consider these additions:

Model validation stage — Add a stage between Register and Deploy that runs the model against a holdout set and gates deployment on a minimum performance threshold.
Batch scoring pipeline — A separate pipeline or Azure Function loads the model from the registry and scores large datasets on a schedule using Azure ML Batch Endpoints.
Monitoring — Use Azure ML model monitoring to track data drift and prediction distributions over time. Trigger retraining automatically when drift exceeds a threshold.
Multi-environment promotion — Register to a dev registry first, deploy to a staging endpoint, run integration tests, then promote to production.
A/B testing — Use traffic splitting to evaluate a new model version against the current one on live traffic before committing.

Conclusion

An end-to-end MLOps pipeline doesn't need to be complex. The core pattern is:

Train — Run the training script, serialize the model bundle
Register — Push to Azure ML Registry with automatic versioning
Deploy — Create/update a Managed Online Endpoint with the new version
Score — Clients call a standard HTTPS API, the endpoint handles scaling

The value comes from making this repeatable and removing manual steps. Every push to main trains a fresh model, registers it, and deploys it to a live endpoint — with a rollback path through blue-green deployments if anything goes wrong.

Copy this template, replace the <your-...> placeholders, write your training script and scoring script, and you have a production-grade MLOps pipeline. The structure stays the same regardless of whether you're deploying an anomaly detector, a classifier, or a regression model.

Enterprise UAMI Design in Azure: Trust Boundaries and Blast Radius

AmitManchanda28 — Thu, 09 Apr 2026 08:13:33 GMT

As organizations move toward secretless authentication models in Azure, Managed Identity has become the preferred approach for enabling secure communication between services. User Assigned Managed Identity (UAMI) in particular offers flexibility that allows identity reuse across multiple compute resources such as:

Azure App Service
Azure Function Apps
Virtual Machines
Azure Kubernetes Service

While this flexibility is beneficial from an operational perspective, it also introduces architectural considerations that are often overlooked during initial implementation.

In enterprise environments where shared infrastructure patterns are common, the way UAMI is designed and assigned can directly influence the effective trust boundary of the deployment.

Understanding Identity Scope in Azure

Unlike System Assigned Managed Identity, a UAMI exists independently of the compute resource lifecycle and can be attached to multiple services across:

Resource Groups
Subscriptions
Environments

This capability allows a single identity to be reused across development, testing, or production services when required.

However, identity reuse across multiple logical environments can expand the operational trust boundary of that identity. Any permission granted to the identity is implicitly inherited by all services to which the identity is attached.

From an architectural standpoint, this creates a shared authentication surface across isolated deployment environments.

High-Level Architecture: Shared Identity Pattern

In many enterprise Azure deployments, it is common to observe patterns where:

A single UAMI is assigned to multiple App Services
The same identity is reused across automation workloads
Identities are provisioned centrally and attached dynamically

While this simplifies management and avoids identity sprawl, it may also introduce unintended privilege propagation across services.

For example:

In this architecture:

Multiple App Services across environments share the same managed identity.
Each compute instance requests an access token from Microsoft Entra ID using Azure Instance Metadata Service (IMDS).
The issued token is then used to authenticate against downstream platform services such as:
- Azure SQL Database
- Azure Key Vault
- Azure Storage

Because RBAC permissions are assigned to the shared identity rather than the compute instance itself, the effective authentication boundary becomes identity‑scoped instead of environment‑scoped.

As a result, any compromised lower‑tier environment such as DEV may obtain an access token capable of accessing production‑level resources if those permissions are assigned to the shared identity.

This expands the operational trust boundary across environments and increases the potential blast radius in the event of identity misuse.

Blast Radius Considerations

Blast radius refers to the potential impact scope of a security or configuration compromise.

When a shared UAMI is used across multiple services, the following conditions may increase the blast radius:

Design Pattern	Potential Risk
Single UAMI across environments	Cross‑environment access
Subscription‑wide RBAC assignment	Broad privilege scope
Identity used for automation pipelines	Lateral movement
Shared identity across teams	Ownership ambiguity

Because Managed Identity authentication relies on Azure Instance Metadata Service (IMDS), any compromised compute resource with access to IMDS may request an access token using the attached identity.

This token can then be used to authenticate with downstream Azure services for which the identity has RBAC permissions.

Enterprise Design Recommendations: Environment‑Isolated Identity Model

To reduce identity blast radius in enterprise deployments, the following architectural principles may be considered:

Environment‑Scoped Identity

Provision separate UAMIs per environment:

UAMI‑DEV
UAMI‑UAT
UAMI‑PROD

Avoid reusing the same identity across isolated lifecycle stages.

Resource‑Level RBAC Assignment

Prefer assigning RBAC permissions at:

Resource
Resource Group

instead of Subscription scope wherever feasible.

Identity Ownership Model

Ensure ownership clarity for identities assigned across shared workloads. Identity lifecycle should be aligned with:

Application ownership
Service ownership
Deployment boundary

Least Privilege Assignment

Assign roles such as:

Key Vault Secrets User
Storage Blob Data Reader

instead of broader roles such as:

Contributor
Owner

Recommended High‑Level Architecture

In this architecture:

Each App Service instance is attached to an environment‑specific managed identity.
RBAC assignments are scoped at the resource or resource group level.
Microsoft Entra ID issues tokens independently for each identity.
Trust boundaries remain aligned with deployment environments.
A compromised DEV compute instance can only obtain a token associated with UAMI‑DEV.

Because UAMI‑DEV does not have RBAC permissions for production resources, lateral access to PROD dependencies is prevented.

Blast Radius Containment:

This design significantly reduces the potential blast radius by ensuring that:

Identity compromise remains environment‑scoped.
Token issuance does not grant unintended cross‑environment privileges.
RBAC permissions align with application ownership boundaries.
Authentication trust boundaries match deployment lifecycle boundaries.

Conclusion

User Assigned Managed Identity offers significant advantages for secretless authentication in Azure environments. However, architectural considerations related to identity reuse and scope of assignment must be evaluated carefully in enterprise deployments.

By aligning identity design with trust boundaries and minimizing the blast radius through scoped RBAC and environment isolation, organizations can implement Managed Identity in a way that balances operational efficiency with security governance.

Enabling AI-Driven Enterprise Intelligence Using SAP and Microsoft 3-IQ Layers

srhulsus — Wed, 08 Apr 2026 19:24:25 GMT

Architectural Context

Enterprise SAP platforms such as SAP ECC, SAP S/4HANA, and SAP BW continue to function as authoritative transactional systems supporting financial accounting, treasury management, portfolio reporting, and regulatory compliance workflows. These environments are optimized for consistency in transactional processing and deterministic reporting. However, they are not designed to support real‑time inferencing workloads or cross‑domain contextual reasoning required for enterprise‑scale AI systems.

In most enterprise architectures, SAP operational data remains logically separated from analytical platforms and collaboration ecosystems such as Microsoft 365. This separation results in fragmentation across three intelligence domains:

Transactional business data
Analytical semantic models
Organizational workflow signals

AI workloads deployed against isolated analytical environments therefore lack direct access to governed ERP data, enterprise policy frameworks, and user workflow context. This limits the ability of AI systems to generate role‑aware, policy‑aligned recommendations within operational decision processes.

The integration of SAP Business Data Cloud with Microsoft Fabric introduces a unified data access model in which SAP business data products can be exposed directly into Microsoft Fabric’s OneLake environment through bi‑directional, zero‑copy sharing. This approach enables SAP data to be consumed by analytics and AI workloads without physical replication while preserving SAP‑defined semantics, lineage, and access controls. [news.sap.com], [windowsforum.com]

SAP Data Integration with Microsoft Fabric

Microsoft Fabric provides a SaaS‑based unified analytics platform built on OneLake, consolidating data engineering, warehousing, analytics, and AI workloads within a single environment.

SAP Business Data Cloud Connect integrates SAP datasets directly into OneLake without requiring traditional ETL‑driven staging layers. SAP data products are surfaced within Fabric in their native semantic form, allowing Fabric services to query operational ERP datasets in place while maintaining governance boundaries defined within SAP environments. [news.sap.com]

This architecture eliminates batch‑oriented data extraction pipelines and reduces latency associated with data synchronization between transactional and analytical platforms.

The integration model supports bidirectional data exchange. Analytical outputs generated within Fabric, such as aggregated financial metrics or predictive forecasts, can be made available to SAP systems to support downstream operational processes. This establishes a closed‑loop architecture in which transactional and analytical workloads continuously inform each other without requiring redundant data copies. [windowsforum.com]

Semantic Modeling through Fabric Intelligence Layer

Operational ERP datasets are not directly consumable by AI inferencing systems due to their structural complexity and absence of domain‑aligned semantics.

Fabric introduces a semantic modeling layer that standardizes structured enterprise datasets into business‑aligned entities, relationships, and domain metrics. This layer maps SAP transactional data into enterprise constructs such as financial exposure, liquidity position, or compliance thresholds.

By propagating standardized semantic definitions across analytical tools and AI workloads, the semantic layer ensures that all downstream consumers interpret ERP‑originated data consistently. This mitigates semantic divergence across departments and establishes a unified enterprise data model capable of supporting inferencing and automation.

Within financial services environments, this enables modeling of constructs such as portfolio risk or regulatory exposure in a form that AI workloads can process without requiring interpretation of underlying transactional tables.

Knowledge Grounding through Foundry Intelligence Layer

AI systems operating in regulated enterprise environments must operate within defined governance and audit frameworks.

Foundry introduces a controlled knowledge access layer that connects AI workloads to enterprise knowledge repositories, including:

SAP process logic
Financial reporting procedures
Internal governance policies
Regulatory documentation

Access to these knowledge sources is governed by identity‑driven access control and policy enforcement mechanisms, ensuring that AI outputs are grounded in approved enterprise content.

This knowledge grounding layer enables AI workloads to retrieve contextual policy information relevant to operational decision scenarios while maintaining traceability between AI‑generated outputs and source documentation.

From an architectural perspective, Foundry functions as the knowledge retrieval control plane across distributed enterprise data environments.

Contextual Intelligence through Work Intelligence Layer

Enterprise decision processes require contextual awareness of organizational roles and workflow dependencies.

The Work Intelligence layer derives contextual signals from Microsoft 365 collaboration environments, including communication patterns, document interactions, and meeting engagement data.

These signals are used to model organizational workflows and operational dependencies across business units.

This contextual layer enables AI workloads to tailor analytical outputs based on user role and decision responsibility. For example, identical financial datasets may produce different recommendations for a portfolio manager, risk analyst, or compliance officer depending on the operational context.

Work Intelligence therefore, introduces workflow‑specific contextualization into enterprise AI workloads.

End‑to‑End Architectural Flow

The architecture follows a layered intelligence model in which each component contributes a discrete capability:

This architecture avoids data duplication, preserves governance boundaries, and supports scalable AI adoption across enterprise financial environments.

Financial Services Application Scenario

Within financial services organizations, SAP environments manage general ledger processing, asset accounting, and risk calculations.

Fabric consumes operational ERP datasets and applies semantic modeling to define enterprise financial indicators.

AI workloads leverage structured data and governed knowledge sources to generate insights such as liquidity forecasts or compliance evaluations.

The Work Intelligence layer ensures that these outputs are delivered within the operational context of specific roles and workflows.

This enables automated reporting and decision support without disruption to existing SAP transactional environments.

The integration of SAP Business Data Cloud with Microsoft Fabric, in conjunction with the Work IQ, Fabric IQ, and Foundry IQ intelligence layers, establishes a scalable architectural framework that enables organizations to evolve from traditional ERP‑centric reporting toward AI‑enabled enterprise intelligence. By facilitating governed access to SAP data, enabling semantic alignment of business models, supporting policy‑driven knowledge retrieval, and incorporating contextual operational insights, this architecture allows enterprises to operationalize AI‑driven financial decision‑making within regulated environments while maintaining data integrity, governance, and compliance.

Build Your AI Agent in 5 Minutes with AI Toolkit for VS Code

isha_sahni — Wed, 08 Apr 2026 09:59:38 GMT

What if building an AI agent was as easy as filling out a form?

No frameworks to install. No boilerplate to copy-paste from GitHub. No YAML to debug at midnight. Just VS Code, one extension, and an idea.

AI Toolkit for VS Code turns agent development into something anyone can do — whether you're a seasoned developer who wants full code control, or someone who's never touched an AI framework and just wants to see something work.

Let's build an agent. Then let's explore what else this toolkit can do.

Getting Set Up

You need two things:

VS Code — download and install if you haven't already
AI Toolkit extension — open VS Code, go to Extensions (Ctrl+Shift+X), search "AI Toolkit", and install it

That's it. No terminal commands. No dependencies to wrangle. When AI Toolkit installs, it brings everything it needs — including the Microsoft Foundry integration and GitHub Copilot skills for agent development.

Once installed, you'll see a new AI Toolkit icon in the left sidebar. Click it. That's your home base for everything we're about to do.

Build an Agent — No Code Required

Open the Command Palette (Ctrl+Shift+P) and type "Create Agent". You'll see a clean panel with two options side by side:

Design an Agent Without Code — visual builder, perfect for getting started
Create in Code — full project scaffolding, for when you want complete control

Click "Design an Agent Without Code." Agent Builder opens up.

Now fill in three things:

Give it a name

Something descriptive. For this example: "Azure Advisor"

Pick a model

Click the model dropdown. You'll see a list of available models — GPT-4.1, Claude Opus 4.6, and others. Foundry models appear at the top as recommended options. Pick one.

Here's a nice detail: you don't need to know whether your model uses the Chat Completions API or the Responses API. AI Toolkit detects this automatically and handles the switch behind the scenes.

Write your instructions

This is where you tell the agent who it is and how to behave. Think of it as a personality brief:

Hit Run

That's it. Click Run and start chatting with your agent in the built-in playground.

Want More Control? Build in Code

The no-code path is great for prototyping and prompt engineering. But when you need custom tools, business logic, or multi-agent workflows — switch to code.

From the Create Agent View, choose "Create in Code with Full Control." You get two options:

Scaffold from a template

Pick a pre-built project structure — single agent, multi-agent, or LangGraph workflow. AI Toolkit generates a complete project with proper folder structure, configuration files, and starter code. Open it, customize it, run it.

Generate with GitHub Copilot

Describe your agent in plain English in Copilot Chat:

"Create a customer support agent that can look up order status, process returns, and escalate to a human when the customer is upset."

Copilot generates a full project — agent logic, tool definitions, system prompts, and evaluation tests. It uses the microsoft-foundry skill, the same open-source skill powering GitHub Copilot for Azure. AI Toolkit installs and keeps this skill updated automatically — you never configure it.

The output is structured and production-ready. Real folder structure. Real separation of concerns. Not a single-file script.

Either way, you get a project you can version-control, test, and deploy.

Cool Features You Should Know About

Building the agent is just the beginning. Here's where AI Toolkit gets genuinely impressive.

🔧 Add Real Tools with MCP

Your agent can do more than just talk. Click Add Tool in Agent Builder to connect MCP (Model Context Protocol) servers — these give your agent real capabilities:

Search the web
Query a database
Read files
Call external APIs
Interact with any service that has an MCP server

You control how much freedom your agent gets. Set tool approval to Auto (tool runs immediately) or Manual (you approve each call). Perfect for when you trust a read-only search tool but want oversight on anything that takes action.

You can also delete MCP servers directly from the Tool Catalog when you no longer need them — no config file editing required.

🧠 Prompt Optimizer

Not sure if your instructions are good enough? Click the Improve button in Agent Builder. The Foundry Prompt Optimizer analyzes your prompt and rewrites it to be clearer, more structured, and more effective.

It's like having a prompt engineering expert review your work — except it takes seconds.

🕸️ Agent Inspector

When your agent runs, open Agent Inspector to see what's happening under the hood. It visualizes the entire workflow in real time — which tools are called, in what order, and how the agent makes decisions.

💬 Conversations View

Agent Builder includes a Conversations tab where you can review the full history of interactions with your agent. Scroll through past conversations, compare how your agent handled different scenarios, and spot patterns in where it succeeds or struggles.

📁 Everything in One Sidebar

AI Toolkit puts everything in a single My Resources panel:

Recent Agents — one-click access to agents you've been working on
Local Resources — your local models, agents, and tools
Foundry Resources — remote agents and models (if connected)

Why AI Toolkit?

There are other ways to build agents. What makes this different?

Everything is in VS Code. You don't context-switch between a web UI, a CLI, and an IDE. Discovery, building, testing, debugging, and deployment all happen in one place.

No-code and code-first aren't separate products. They're two views of the same agent. Start in Agent Builder, click View Code, and you have a full project. Or go the other way — build in code and test in the visual playground.

Copilot is deeply integrated. Not as a chatbot bolted on the side — as an actual development tool that understands agent architecture and generates production-quality scaffolding.

Wrapping Up:

📥 Install: AI Toolkit on the VS Code Marketplace
📖 Learn: AI Toolkit Documentation

Open VS Code. Ctrl+Shift+P. Type "Create Agent."

Five minutes from now, you'll have an agent running. 🚀

Private DNS and Hub–Spoke Networking for Enterprise AI Workloads on Azure

deepthihr — Mon, 06 Apr 2026 07:56:39 GMT

Introduction

As organizations deploy enterprise AI platforms on Azure, security requirements increasingly drive the adoption of private-first architectures.

Private networking only
Centralized firewalls or NVAs
Hub–and–spoke virtual network architectures
Private Endpoints for all PaaS services

While these patterns are well understood individually, their interaction often exposes hidden failure modes, particularly around DNS and name resolution.

During a recent production deployment of a private, enterprise-grade AI workload on Azure, several issues surfaced that initially appeared to be platform or service instability. Closer analysis revealed the real cause: gaps in network and DNS design.

This post shares a real-world technical walkthrough of the problem, root causes, resolution steps, and key lessons that now form a reusable blueprint for running AI workloads reliably in private Azure environments.

Problem Statement

The platform was deployed with the following characteristics:

Hub and spoke network topology
Custom DNS servers running in the hub
Firewall / NVA enforcing strict egress controls
AI, data, and platform services exposed through Private Endpoints
Azure Container Apps using internal load balancer mode
Centralized monitoring, secrets, and identity services

Despite successful infrastructure deployment, the environment exhibited non-deterministic production issues, including:

Container Apps intermittently failing to start or scale
AI platform endpoints becoming unreachable from workload subnets
Authentication and secret access failures
DNS resolution working in some environments but failing in others
Terraform deployments stalling or failing unexpectedly

Because the symptoms varied across subnets and environments, root cause identification was initially non-trivial.

Root Cause Analysis

After end-to-end isolation, the issue was not AI services, authentication, or application logic. The core problem was DNS resolution in a private Azure environment.

1. Custom DNS servers were not Azure-aware

The hub DNS servers correctly resolved:

Corporate domains
On‑premises records

However, they could not resolve Azure platform names or Private Endpoint FQDNs by default.

Azure relies on an internal recursive resolver (168.63.129.16) that must be explicitly integrated when using custom DNS.

2. Missing conditional forwarders for private DNS zones

Many Azure services depend on service-specific private DNS zones, such as:

privatelink.cognitiveservices.azure.com
privatelink.openai.azure.com
privatelink.vaultcore.azure.net
privatelink.search.windows.net
privatelink.blob.core.windows.net

Without conditional forwarders pointing to Azure’s internal DNS, queries either:

Failed silently, or
Resolved to public endpoints that were blocked by firewall rules

3. Container Apps internal DNS requirements were overlooked

When Azure Container Apps are deployed with:

internal_load_balancer_enabled = true

Azure does not automatically create supporting DNS records.

The environment generates:

A default domain
.internal subdomains for internal FQDNs

Without explicitly creating:

A private DNS zone matching the default domain
*, @, and *.internal wildcard records

internal service-to-service communication fails.

4. Private DNS zones were not consistently linked

Even when DNS zones existed, they were:

Spread across multiple subscriptions
Linked to some VNets but not others
Missing links to DNS server VNets or shared services VNets

As a result, name resolution succeeded in one subnet and failed in another, depending on the lookup path.

Resolution

No application changes were required. Stability was achieved entirely through architectural corrections.

✅ Step 1: Make custom DNS Azure-aware

On all custom DNS servers (or NVAs acting as DNS proxies):

Configure conditional forwarders for all Azure private DNS zones
Forward those queries to: 168.63.129.16

This IP is Azure’s internal recursive resolver and is mandatory for Private Endpoint resolution.

✅ Step 2: Centralize and link private DNS zones

A centralized private DNS model was adopted:

All private DNS zones hosted in a shared subscription
Linked to:
- Hub VNet
- All spoke VNets
- DNS server VNet
- Any operational or virtual desktop VNets

This ensured consistent resolution regardless of workload location.

✅ Step 3: Explicitly handle Container Apps DNS

For Container Apps using internal ingress:

Create a private DNS zone matching the environment’s default domain
Add:
- * wildcard record
- @ apex record
- *.internal wildcard record
Point all records to the Container Apps Environment static IP
Add a conditional forwarder for the default domain if using custom DNS

This step alone resolved multiple internal connectivity issues.

✅ Step 4: Align routing, NSGs, and service tags

Firewall, NSG, and route table rules were aligned to:

Allow DNS traffic (TCP/UDP 53)
Allow Azure service tags such as:
- AzureCloud
- CognitiveServices
- AzureActiveDirectory
- Storage
- AzureMonitor
Ensure certain subnets (e.g., Container Apps, Application Gateway) retained direct internet access where required by Azure platform services

Key Learnings

1. DNS is a Tier‑0 dependency for AI platforms

Many AI “service issues” are DNS failures in disguise. DNS must be treated as foundational platform infrastructure.

2. Private Endpoints require Azure DNS integration

If you use:

Custom DNS ✅
Private Endpoints ✅

Then forwarding to 168.63.129.16 is non‑negotiable.

3. Container Apps internal ingress has hidden DNS requirements

Internal Container Apps environments will not function correctly without manually created DNS zones and .internal records.

4. Centralized DNS prevents environment drift

Decentralized or subscription-local DNS zones lead to fragile, inconsistent environments. Centralization improves reliability and operability.

5. Validate networking first, then the platform

Before escalating issues to service teams:

Validate DNS resolution
Verify routing
Check Private Endpoint connectivity

In many cases, the perceived “platform issue” disappears.

Quick Production Validation Checklist

Before go-live, always validate:

✅ Private FQDNs resolve to private IPs from all required VNets
✅ UDR/NSG rules allow required Azure service traffic
✅ Managed identities can access all dependent resources
✅ AI portal user workflows succeed (evaluations, agents, etc.)
✅ terraform plan shows only intended changes

Conclusion

Running private, enterprise-grade AI workloads on Azure is absolutely achievable—but it requires intentional DNS and networking design.

By:

Making custom DNS Azure-aware
Centralizing private DNS zones
Explicitly handling Container Apps DNS
Aligning routing and firewall rules

an unstable environment was transformed into a repeatable, production-ready platform pattern.

If you are building AI solutions on Azure with Private Endpoints and hub–spoke networking, getting DNS right early will save weeks of troubleshooting later.

Building Cost-Aware Azure Infrastructure Pipelines: Estimate Costs Before You Deploy

whosocurious — Mon, 06 Apr 2026 06:28:43 GMT

The Problem: Cost Is a Blind Spot in IaC Reviews

Code reviews for Bicep or Terraform templates typically focus on correctness, security, and compliance. But cost is rarely part of the review process because:

Developers don't have easy access to pricing data at review time
Azure pricing depends on region, tier, reservation status, and more
There's no built-in "cost diff" in any IaC tool

This means cost regressions slip through the same way bugs do when there are no tests.

iac-review-gap

Architecture Overview

Here's the pipeline we'll build:

architecture-overview

Step 1: Use Bicep What-If to Detect Changes

Azure's what-if deployment mode shows you exactly what resources will be created, modified, or deleted — without actually deploying anything.

az deployment group what-if --resource-group rg-myapp-prod --template-file main.bicep --parameters main.bicepparam --result-format ResourceIdOnly --out json > what-if-output.json

The JSON output contains a changes array where each entry has:

resourceId — the full ARM resource ID
changeType — one of Create, Modify, Delete, NoChange, Deploy
before and after — the full resource properties for modifications

This is the foundation: the what-if output tells us what is changing, and we can use that to look up what it costs.

what-if-cli-output

Step 2: Map Resources to Pricing with the Retail Prices API

The Azure Retail Prices API is a free, unauthenticated REST API that returns pay-as-you-go pricing for any Azure service.

Here's a Python script that takes a VM SKU and region and returns the monthly cost:

import requests def get_vm_price(sku_name: str, region: str = "eastus") -> float | None: """Query the Azure Retail Prices API for a Linux VM's pay-as-you-go hourly rate.""" api_url = "https://prices.azure.com/api/retail/prices" odata_filter = ( f"armRegionName eq '{region}' " f"and armSkuName eq '{sku_name}' " f"and priceType eq 'Consumption' " f"and serviceName eq 'Virtual Machines' " f"and contains(meterName, 'Spot') eq false " f"and contains(productName, 'Windows') eq false" ) response = requests.get(api_url, params={"$filter": odata_filter}) response.raise_for_status() items = response.json().get("Items", []) if not items: return None hourly_rate = items[0]["retailPrice"] monthly_estimate = hourly_rate * 730 # avg hours per month return round(monthly_estimate, 2) # Example usage before_cost = get_vm_price("Standard_D4s_v5") # e.g., $140.16/mo after_cost = get_vm_price("Standard_D8s_v5") # e.g., $280.32/mo delta = after_cost - before_cost # +$140.16/mo

You can extend this pattern for other resource types — App Service Plans, Azure SQL databases, managed disks, etc. — by adjusting the serviceName and meterName filters.

Step 3: Build the GitHub Actions Workflow

Here's a complete GitHub Actions workflow that ties it all together:

name: Cost Estimate on PR on: pull_request: paths: - "infra/**" permissions: id-token: write # For Azure OIDC login contents: read pull-requests: write # To post comments jobs: cost-estimate: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v4 - name: Azure Login (OIDC) uses: azure/login@v2 with: client-id: ${{ secrets.AZURE_CLIENT_ID }} tenant-id: ${{ secrets.AZURE_TENANT_ID }} subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }} - name: Run Bicep What-If run: | az deployment group what-if \ --resource-group ${{ vars.RESOURCE_GROUP }} \ --template-file infra/main.bicep \ --parameters infra/main.bicepparam \ --out json > what-if-output.json - name: Setup Python uses: actions/setup-python@v5 with: python-version: "3.12" - name: Install dependencies run: pip install requests - name: Estimate cost delta id: cost run: | python infra/scripts/estimate_costs.py \ --what-if-file what-if-output.json \ --output-format github >> "$GITHUB_OUTPUT" - name: Comment on PR uses: marocchino/sticky-pull-request-comment@v2 with: header: cost-estimate message: | ## 💰 Infrastructure Cost Estimate | Resource | Change | Before ($/mo) | After ($/mo) | Delta | |----------|--------|---------------|--------------|-------| ${{ steps.cost.outputs.table_rows }} **Estimated monthly impact: ${{ steps.cost.outputs.total_delta }}** _Prices are pay-as-you-go estimates from the Azure Retail Prices API. Actual costs may vary with reservations, savings plans, or hybrid benefit._ - name: Gate on budget threshold if: ${{ steps.cost.outputs.delta_value > 500 }} run: | echo "::error::Monthly cost increase exceeds $500 threshold. Requires finance team approval." exit 1

Step 4: The Cost Estimation Script

Here's the core of infra/scripts/estimate_costs.py that parses the what-if output and queries prices:

#!/usr/bin/env python3 """Parse Bicep what-if output and estimate cost deltas using Azure Retail Prices API.""" import json import argparse import requests PRICE_API = "https://prices.azure.com/api/retail/prices" # Map ARM resource types to Retail API service names RESOURCE_TYPE_MAP = { "Microsoft.Compute/virtualMachines": "Virtual Machines", "Microsoft.Compute/disks": "Storage", "Microsoft.Web/serverfarms": "Azure App Service", "Microsoft.Sql/servers/databases": "SQL Database", } def get_price(service_name: str, sku: str, region: str) -> float: """Query Azure Retail Prices API and return monthly cost estimate.""" odata_filter = ( f"armRegionName eq '{region}' " f"and armSkuName eq '{sku}' " f"and priceType eq 'Consumption' " f"and serviceName eq '{service_name}'" ) resp = requests.get(PRICE_API, params={"$filter": odata_filter}) resp.raise_for_status() items = resp.json().get("Items", []) if not items: return 0.0 return items[0]["retailPrice"] * 730 def parse_what_if(filepath: str) -> list[dict]: """Extract resource changes from what-if JSON output.""" with open(filepath) as f: data = json.load(f) results = [] for change in data.get("changes", []): change_type = change.get("changeType", "") resource_type = change.get("resourceId", "").split("/providers/")[-1].split("/")[0:2] resource_type_str = "/".join(resource_type) if len(resource_type) == 2 else "" if resource_type_str not in RESOURCE_TYPE_MAP: continue before_sku = (change.get("before") or {}).get("sku", {}).get("name", "") after_sku = (change.get("after") or {}).get("sku", {}).get("name", "") region = (change.get("after") or change.get("before") or {}).get("location", "eastus") service = RESOURCE_TYPE_MAP[resource_type_str] before_price = get_price(service, before_sku, region) if before_sku else 0.0 after_price = get_price(service, after_sku, region) if after_sku else 0.0 results.append({ "resource": change.get("resourceId", "").split("/")[-1], "change_type": change_type, "before": round(before_price, 2), "after": round(after_price, 2), "delta": round(after_price - before_price, 2), }) return results def main(): parser = argparse.ArgumentParser() parser.add_argument("--what-if-file", required=True) parser.add_argument("--output-format", default="text", choices=["text", "github"]) args = parser.parse_args() changes = parse_what_if(args.what_if_file) total_delta = sum(c["delta"] for c in changes) if args.output_format == "github": rows = [] for c in changes: sign = "+" if c["delta"] >= 0 else "" rows.append( f"| {c['resource']} | {c['change_type']} " f"| ${c['before']:.2f} | ${c['after']:.2f} " f"| {sign}${c['delta']:.2f} |" ) print(f"table_rows={'chr(10)'.join(rows)}") sign = "+" if total_delta >= 0 else "" print(f"total_delta={sign}${total_delta:.2f}/mo") print(f"delta_value={total_delta}") else: for c in changes: print(f"{c['resource']}: {c['change_type']} " f"${c['before']:.2f} → ${c['after']:.2f} " f"(Δ ${c['delta']:+.2f})") print(f"\nTotal monthly delta: ${total_delta:+.2f}") if __name__ == "__main__": main()

What the Developer Experience Looks Like

Once this pipeline is in place, every PR that touches infrastructure files gets an automatic cost comment:

Resource	Change	Before ($/mo)	After ($/mo)	Delta
vm-api-prod	Modify	$140.16	$280.32	+$140.16
disk-data-01	Create	$0.00	$73.22	+$73.22
plan-webapp	NoChange	$69.35	$69.35	+$0.00

Estimated monthly impact: +$213.38/mo

If the delta exceeds a configurable threshold (e.g., $500/mo), the pipeline fails and requires explicit approval — just like a failing test.

Extending This Further

Here are some ways to take this pipeline to the next level:

Support Azure Savings Plans and Reservations — Query the Prices API with priceType eq 'Reservation' and show both pay-as-you-go and committed pricing
Track cost trends over time — Store estimates in Azure Table Storage or a database and build a dashboard showing cost trajectory per environment
Add Slack/Teams notifications — Alert the team channel when a PR exceeds the threshold
Tag-based cost allocation — Parse resource tags from Bicep to attribute costs to teams or projects
Multi-environment estimates — Run the pipeline against dev, staging, and prod parameter files to show total organizational impact

Key Takeaways

Azure's What-If API gives you a deployment preview without making changes — use it as the foundation for any pre-deployment validation
The Azure Retail Prices API is free, requires no authentication, and returns granular pricing data you can query programmatically
Cost gates in CI/CD treat budget overruns the same way you treat test failures — as merge blockers that require explicit action
Shift cost left — just like security and testing, catching cost issues at PR time is 10x cheaper than catching them on the monthly bill

Infrastructure cost is infrastructure quality. By integrating cost estimation into your pull request workflow, you give every developer on the team visibility into the financial impact of their changes — before a single resource is deployed.

Demystifying On-Demand Capacity Reservations

KenHooverMSFT — Tue, 14 Apr 2026 17:21:11 GMT

About On-Demand Capacity Reservations

Introducing the “parking garage” metaphor

There are dozens of VM types available in Azure which span multiple generations of CPU across vendors and architectures. Within each Azure region are datacenters hosting pools of hardware which runs Azure services, such as virtual machines, of those types. As VMs are started and stopped by customers there is a constant ebb and flow of available capacity to run each type of VM within the region. Available capacity is driven by the rhythms of the business day, which creates variations in utilization on an hour-to-hour and even minute-to-minute basis. Longer cycles of demand such as holiday seasons, school calendars and other real-world events are also a factor.

When you command an Azure Virtual Machine (VM) to start, the Azure Resource Manager (ARM) – the “engine” that manages resources in the Microsoft cloud -- needs to do a few things to make it happen. The most important of these is that it needs to identify hardware within the target region with sufficient capacity to bring the desired type and size of VM online at that moment in time. If ARM finds space for the desired VM size, the VM starts normally. However, if there is no room to start the desired VM, you will see an error similar to this one:

This process of finding a place to start up an Azure VM has a lot of similarities to finding a place to park a vehicle. Parking facilities are built to handle typical demand for their location. If something is going on nearby, such as a large sporting event, which causes the need for parking to be much higher than normal then you might be out of luck when you try to find a spot because the garage is simply full.

During periods of high demand in Azure this can result in VMs failing to start simply because there is nowhere to run them at that particular moment. If this happens to a VM which needed to be stopped for a configuration change or other reasons this can cause impact to your environment which you certainly want to avoid.

On-Demand Capacity Reservations

Azure has a resource called an On-Demand Capacity Reservation, or ODCR, which allows you to reserve a spot for a VM in the appropriate hardware within a region for a specific VM size. This is similar to “owning" a parking space: It’s a reserved place exclusively for the use of a specific VM.

At a high level, the way this works is that you create an ODCR which matches the Azure region, availability zone and specific VM type, such as for a VM of type D16s_v6 in availability zone 2 of the Canada Central Azure region. Once the reservation is created, an Azure VM that matches that configuration can be associated to it so the VM now “owns” that “parking space”. This gives that VM priority over others of the same type when it needs to start because it already has a “parking space” assigned to it that can't be used by another one.

More detail about VM startup

Before we get further into what ODCRs are and how they work, it’s important to know a few more things about starting up a VM.

Azure does not provide an explicit SLA for VM startup for virtual machines without an ODCR. The process of finding a hypervisor slot to boot up a VM is purely a “best effort” action on Azure’s part.

Having quota headroom does not help with VM startup. Quota in Azure is your "credit limit" for creating VMs. Quota grants permission to create up to a certain number of cores’ worth of Virtual Machines from a particular family (like Ds_v6) but has no effect on whether you can actually start the machine once it’s created.

Similarly, having a Reserved Instance purchase or a Savings Plan for a particular number of cores of a given VM family does not have any impact on the ability to start a VM either. These mechanisms are a discount mechanism only where the customer pre-pays for a certain amount of VM cores to be running 24x7 at a discounted rate.

Assigning an ODCR to a virtual machine applies a formal SLA on startup for it. VMs with ODCRs get priority over ones that don’t so the likelihood of a successful startup is much higher for VMs that have one compared to those that do not, especially during times when Azure is experiencing a period of high demand for that particular VM type. The actual language of the ODCR SLA can be found in Microsoft's Service Level Agreements for Online Services document which can be downloaded from the linked site.

Cost Implications of ODCRs

These are the key points that you need to know about how billing works for ODCRs:

The compute cost for the ~~parking space~~ capacity reservation for a VM is exactly the same as a running VM of the same size. There is no “double billing” for a VM to have an ODCR associated with it.
Billing for the ODCR starts immediately if the quantity of reserved "parking spaces" is greater than zero.
Stopping a VM that has an ODCR associated with it does not impact cost. This is because the ODCR is holding the reserved hypervisor slot even if the VM is not running.
Having a Reserved Instance purchase or Savings Plan which covers the same scope as the ODCR means that the VM will be billed at the discounted rate.

Are there any cases where using ODCRs results in paying more for a VM?

There are two cases that I’ve identified where you pay for two ODCRs for the same VM.

First, if you are using Azure Site Recovery to protect a VM in Azure by replicating it to another location, you have the option to associate the remote replica of the VM with a capacity reservation. This helps ensure that the replica will start when it’s called upon because it has a pre-allocated spot reserved for it. In this situation, if the original VM also is associated with an ODCR you are paying for both the original (running) VM and also for the reservation being held for its replica.

Second, and similarly, when setting up replication for a VM that is preparing for migration into Azure via Azure Migrate, you can associate a capacity reservation with the replica for similar reasons to the above ASR example -- to ensure that the VM will start when its migrated replica is activated. If the source machine is also in Azure then you are again paying twice for the same machine.

When should I use them?

Capacity Reservations are an important element when designing for resiliency. They help ensure that VMs will be online when needed, even if they have to be shut down for some reason. For example, there was an incident where a customer had to shut down a VM that was serving as a firewall appliance to make an adjustment to its configuration and it failed to start up afterwards because of a capacity-related failure. This resulted in significant impact due to the loss of connectivity for systems dependent on the firewall for connectivity until they were able to bring it back online.

Based on field experience and resiliency assessments, applying ODCRs to VMs that must be available 24x7 is strongly recommended. Examples of this include key functions like AD domain controllers, application servers and database servers. Also, any VM-based appliances that may be running as firewalls, load balancers or other infrastructure-support services should be considered as well.

Microsoft offers assessments which review a workload for gaps that impact resiliency in many dimensions including outages in Azure. These assessments include checks for the presence of capacity reservations and will report any VM’s that do not have them as a high-risk finding.

Not all VM stops in Azure are voluntary

Even if you are careful to never stop a VM yourself it can sometimes happen. Not every shutdown of a VM in Azure is user-initiated. Involuntary shutdowns are rare but they can occur due to predictive hardware failures or other events which ARM will respond to by stopping the VM in order to move it out of harm's way.

Creating On-Demand Capacity Reservations

This section covers the components of an ODCR, the process of creating them and why creating them can fail.

Components of an ODCR:

An ODCR has two components to it. The first part is a Capacity Reservation Group (CRG) which is simply a "bucket" for any number of capacity reservations. To create a CRG you only need to provide its name, the region that it will be used for and which availability zones within that region it will have access to.

The second -- and more important -- component is the actual Capacity Reservation which is created within a CRG. The capacity reservation requires:

The name of the reservation. Including the VM size and other details in the name is useful to reduce ambiguity. An example could be “Zone1_D16s_v5”
The specific VM size the reservation is for, such as “D16s_v5”
The availability zone of the reservation. You can also create a regional reservation, where the VM is “zoneless”, as well.
The number of ~~parking spaces~~ instances that the reservation holds.

ODCRs can be created via the Azure portal, from the command line using PowerShell or the Azure CLI or deployed through IaC tools such as Bicep or Terraform. CRGs also can also be shared across subscriptions, which allows a CRG created and managed in one subscription to be utilized by VMs in a different subscription.

When the ODCR is created, if the number of instances it contains is higher than zero then ARM will attempt to allocate the desired number of instances of the specified VM type in the target region/zone. If there is capacity available for this then the creation succeeds and you can move on to associating machines with it to give them the protection of the ODCR.

If creating the ODCR is unsuccessful, the cause can be a variety of things, including:

No open hypervisor slots for the desired VM in the target location – the “parking lot” was full at the moment the request was submitted. This can result from outages within Azure that reduce capacity as well as demand pressure.
There is insufficient quota in the subscription to claim the necessary number of VM cores for the reservation in the region.
The VM type is simply not available in the target region or AZ. Since not all Azure regions are provisioned with identical hardware this can be the cause, especially for VM types other than the popular D, E and F series machines.
A restriction is applied to the subscription, zone or region that blocks creation of the reservation for some reason.

What you can do if creating an ODCR fails

Some things that may help if creating a capacity reservation fails and you know that quota or other restrictions are not a factor are below.

Not coincidentally, these are the same recommendations that you should try when a VM fails to start because the same ARM action – finding and allocating hardware with free capacity to start the VM – is taking place.

IN GENERAL, creating an ODCR outside of business hours has a higher probability of success. Demand for Azure services typically drops off at the end of the business day where the region is located.
Consider using a different VM type, availability zone or a different Azure region.
A script or other automation that retries at intervals until the reservation succeeds in claiming the desired number of spots can help, though it can take an unknown amount of time before this works. It may need to run for days or even weeks before it succeeds.

Submitting a support ticket will create visibility to your situation from Microsoft. If the root cause is something other than capacity, support can identify that cause and provide guidance on how to resolve it. If the issue truly is a capacity squeeze, the ability of support to help get the reservation created is extremely limited because the support folks, while helpful, are not able to create capacity where none exists. In this case the support teams will usually refer you to the three options above.

Protecting a VM with an ODCR

Once you have the ODCR created, applying it to a VM is straightforward. To do this from the portal, open the configuration tab on the VM’s screen. Then scroll to the bottom of the panel that appears to find the “Capacity reservations” section. Select “Capacity reservation group” from the list. The list of capacity reservation groups that match the VM will appear in a drop-down menu below. Select the CRG that the VM should use and click “Apply”.

If you are using an Infrastructure-as-Code approach such as Bicep or Terraform, an Azure VM is linked to a CRG by specifying the resource ID of the CRG in the appropriate property on the VM definition.

Impact of associating a virtual machine with an ODCR:

If the VM is not running then the change takes effect immediately.
If the VM is running and has no zone assignment (a “regional” VM) then it must be stopped and restarted for the protection of the ODCR to apply.
If the VM is running and has a zone assignment then the change is immediate and there is no disruption to the VM.

Important note for Terraform users: There appears to be a critical behavior difference between how the AzureRM provider and the Azapi provider handle this change. If you use the AzureRM provider, Terraform will always perform an immediate stop/deallocate of the VM, apply the change and then start the VM up again. The Azapi provider works as documented above. I believe this a result of how Hashicorp coded the AzureRM provider to manage Azure resources.

Where an ODCR is not the right answer

ODCRs are most effective when they are used to protect VMs that need to always be running because they are providing essential services. Examples include AD domain controllers, firewall or load balancer appliances, database servers, integration servers that support workflows and the like.

The primary thing to keep in mind is the cost impact of the ODCRs and whether they are necessary for the service to be functioning. Environments where machines come and go frequently, such as scale in/out setups used to minimize cost, are not ideal for ODCRs. For example, if you have a pool of app servers configured for scale-out, using ODCRs to cover the entire size of the pool means you would be paying for all machines, whether they are actually online or not. A possible approach in a scale-out environment is to determine the minimum number of VMs necessary for the service to be available -- even in a degraded state -- and use an ODCR to protect that number of instances. This way you can have confidence that at least that number of machines in the pool will always be running even if an attempt to scale out fails.

Working with On-Demand Capacity Reservations
(and three interesting behaviors that you should know about)

This section discusses some ins and outs of working with ODCRs in your environment, especially if you need to apply them to existing machines. This is a common scenario when you are attempting to improve the resiliency of a set of VMs against impacts from maintenance, outages or other situations that may cause VMs to restart.

“Associated” vs “Allocated”

A capacity reservation group will always have ownership of some number of "parking spots" within a region. The number that it holds is referred to as the reservation's capacity which is expressed as a number of allocated instances.

When you link a VM to a CRG, the VM becomes associated with the CRG and can take advantage of the protection that it offers from matching reservations that it contains.

It is possible to associate more VMs to a CRG than it has allocated capacity for. This is called overallocation.

When a CRG is overallocated, the VMs associated with it are protected on a first-come-first-served basis based on when they were started. If, for example, there are four VMs associated with a CRG but the CRG only has an allocated capacity of two, the first two associated machines which were started will receive protection but the others will not.

“Interesting” On-Demand Capacity Reservation behavior #1:

Here is the first of three interesting behaviors that you can use to your advantage when working with ODCRs.

You can add a running VM to a capacity reservation group.

As mentioned previously, if the VM is zonal then the change is immediate and nondisruptive. If the VM is regional then the VM must be stopped and restarted for the change to take effect.

This is conceptually different from other Azure mechanisms used for resiliency such as Availability Sets. You can only add a VM to an availability set at the time the VM is created but you can add or remove a VM from a Capacity Reservation Group at any time whether the VM is running or not.

“Interesting” On-Demand Capacity Reservation behavior #2

Interesting behavior #2 is deceptively simple. When creating a reservation, you can specify a capacity (number of allocated instances) of zero.

This should always succeed because Azure needs to take no action to fulfill it -- this is just a metadata adjustment for the reservation within the CRG.

This seems to not be terribly useful at first glance but keep reading.

“Interesting” On-Demand Capacity Reservation behavior #3

If the number of associated VMs is higher than the allocated capacity of the reservation, you can increase the capacity of the reservation to cover the running VMs.

Why does this work? Because running VMs, by definition, have a ~~parking spot~~ hypervisor allocation already so Azure doesn’t need to find one for it -- Azure can simply link the capacity reservation to the hypervisor slot that the running VM is using.

The payoff! Or, using these three behaviors to your advantage

Because ODCRs are relatively new and have not yet been adopted widely, a common finding to emerge from field resiliency assessments of running workloads is that the VMs that support the workload need to have ODCRs applied to them. In large environments there may be dozens or even hundreds of VMs that need to be protected. The process for doing this can seem daunting to a technical team that is not familiar with ODCRs.

Thankfully, these three behaviors make it possible to easily protect any number of running machines with a very high probability of success -- and zero disruption if they are zonal VMs -- by proceeding in this order:

Create a CRG with a reservation for the region, AZ and VM type for the machine(s) that need to be covered with a quantity of zero. (Interesting behavior #2)
Associate the VMs to the capacity reservation group. At this point the CRG is overallocated so the machines are not yet protected. Remember that if the VMs are regional, a restart is required to finalize the ODCR assignment. (Interesting behavior #1)
Update the reservation within the CRG to increase the number of allocated instances to match the number of running VMs. (Interesting behavior #3)

When the number of instances on the reservation is equal to or higher than the number of VMs associated with it, all of the associated VMs are protected and you’re done!

Final thoughts

This leads to a final piece of advice about working with ODCRs, especially when you know that capacity is a challenge in the target region: As a field CSA, I recommend that you bring VMs online first, then apply a capacity reservation to them.

Why? If you already have a set of running VMs that need to be protected then following what seems like the obvious process: Creating a CRG, creating reservations within it for the correct number of instances and then associating the VMs with the reservation – has a risk of failure at the step of creating the ODCR because Azure needs to find and allocate additional hypervisor slots for the reservation to own. This can be challenging when there is a lot of demand for the VM type.

As the example in the previous section showed, it’s much easier to protect VMs that are already online by associating them with an existing capacity reservation, even if it doesn’t have enough instances allocated to it, and then increasing the capacity of the ODCR to cover the running machines.

References:

On-Demand Capacity Reservations Overview

Monitor the list of restrictions on VM eligibility because it changes frequently

SLA Details for On-Demand Capacity Reservations

Legal fine print is in the consolidated SLA for Online Services (.docx)

Some details about Overallocating capacity reservations

Information on creating a Capacity Reservation Group via Bicep, Terraform or ARM template.

DevSecOps on AKS: Governance Gates That Actually Prevent Incidents

lakshaymalik — Fri, 03 Apr 2026 10:46:12 GMT

This article is for AKS platform/infra engineers, SREs, and security teams who want a practical, enforceable model for stopping common Kubernetes misconfigurations before they become incidents—without turning delivery into bureaucracy.

Why incidents still happen after “adding security to the pipeline”

Most teams do some of these:

container image scanning
secret scanning
IaC checks
PR approvals

Those are useful, but they don’t help when:

someone deploys directly with kubectl
a pipeline is misconfigured or bypassed
drift accumulates over time

The AKS baseline guidance emphasizes governance through policy and admission control as a core way to manage and secure clusters

The AKS DevSecOps model (where the gates belong)

A workable DevSecOps model in AKS applies controls across four layers:

Pre‑deployment (CI) – early feedback and guardrails
Admission control (Governance gates) – hard enforcement, prevents bad configs
Runtime protection – detection/response if something slips through
Continuous compliance – drift detection and auditing

This aligns with Microsoft’s AKS security guidance that emphasizes upgrades, policy governance, and operational monitoring as core best practices

The governance gates that prevent incidents

Gate 1 — Azure Policy for AKS (OPA Gatekeeper at admission)

Azure Policy extends Gatekeeper (OPA) to provide centralized, consistent enforcement of Kubernetes policies across AKS clusters. It installs as an add‑on/extension and can block non‑compliant resources at creation time, while also reporting compliance back to Azure Policy.

How it works (in plain terms)

Azure Policy:

checks assignments for the cluster
deploys policy definitions into the cluster as Gatekeeper resources
reports audit/compliance results to Azure Policy service

Call‑out: Why this prevents incidents
CI scans can be skipped. Admission control cannot be skipped (unless the cluster is misconfigured). Azure Policy for AKS enforces rules even when workloads are deployed outside your pipeline.

What to enforce first (high-impact controls)

The AKS baseline architecture highlights policy management as a key tool and explicitly calls out governance for container images and security validation.
Start with gates that stop the most common blast-radius problems: [Vnet peeri...rosoft Q&A | Learn.Microsoft.com]

image governance (trusted registries / approved images) [Vnet peeri...rosoft Q&A | Learn.Microsoft.com]
pod security baseline (privilege escalation controls)
public exposure controls (restrict risky patterns) [tech.hub.ms]

Gate 2 — Pod Security Standards (Baseline → Restricted) via Azure Policy

Azure Policy can apply built‑in Kubernetes initiatives such as pod security baseline standards and you can set the effect from audit to deny to block violations.

Call‑out: Practical rollout strategy
Start in Audit, fix violations, then move to Deny for production namespaces. Azure Policy supports staged enforcement and reporting, making rollout safer.

Gate 3 — Network policy enforcement (stop lateral movement)

The AKS DevSecOps guidance recommends securing and governing clusters with Azure Policy and using network policies to control pod-to-pod flows.
The AKS baseline architecture also centers on securing in‑cluster traffic and aligning networking/security/identity teams around a consistent baseline. [tech.hub.ms] [Vnet peeri...rosoft Q&A | Learn.Microsoft.com]

Call‑out: Incident prevention lens
Network isolation gates reduce “one compromised pod → entire cluster compromised” scenarios by limiting east‑west connectivity. [tech.hub.ms]

Gate 4 — Supply chain guardrails (image + deployment governance)

The AKS baseline architecture specifically highlights container images as a frequent vulnerability source and recommends governance using Azure Policy + Gatekeeper to ensure only approved images are deployed. [Vnet peeri...rosoft Q&A | Learn.Microsoft.com]

This is where many “quiet” incidents start: images pulled from unknown registries, unsigned builds, or non-standard tags. A governance gate stops that at admission time. [Vnet peeri...rosoft Q&A | Learn.Microsoft.com]

Runtime safety net (because prevention isn’t perfect)

Defender for Containers on AKS (runtime detection + posture)

Microsoft Defender for Containers provides runtime security monitoring and ongoing security operations workflows. The enablement guidance highlights:

enabling protection broadly or selectively
network/egress requirements for the Defender sensor
ongoing operations (review vulnerabilities, recommendations, investigate alerts) [Support fo...t peering) | ADO Work Item (UAT)], [techcommun...rosoft.com]

Call‑out: Don’t skip egress planning
For restricted egress clusters, Defender requires outbound access to specific endpoints/FQDNs to send security data and events. [Support fo...t peering) | ADO Work Item (UAT)], [techcommun...rosoft.com]

Operational knobs you’ll actually use

Defender configuration supports enabling/disabling components like:

agentless discovery
vulnerability assessment
Defender DaemonSet (sensor)
Azure Policy for Kubernetes (integration point) [digitaltho...uption.com]

And provides CLI examples for enabling Defender and adding the Azure Policy add‑on (useful for repeatable automation). [digitaltho...uption.com]

Continuous compliance (drift is inevitable)

Azure Policy for Kubernetes is designed to report compliance state back to Azure and centralize governance. That’s what helps you detect drift and keep controls enforced across clusters over time.

Mapping “common incident patterns” to gates (actionable cheat sheet)

Incident pattern you want to avoid	Gate that prevents it
Privileged containers / risky pod specs	Pod security standards enforced via Azure Policy (Audit → Deny)
Untrusted images running in prod	Image governance enforced by Azure Policy + Gatekeeper [Vnet peeri...rosoft Q&A \| Learn.Microsoft.com]
Flat east‑west network → lateral movement	Network policy guidance (DevSecOps on AKS + baseline) [tech.hub.ms]
Threat activity at runtime (post‑deploy)	Defender for Containers runtime protection + alerts [Support fo...t peering) \| ADO Work Item (UAT)], [techcommun...rosoft.com]
Silent drift & inconsistent posture across clusters	Azure Policy compliance reporting for Kubernetes

Azure SQL Managed Instance as an AI‑Enabled PaaS Platform

ShivaniThadiyan — Fri, 03 Apr 2026 09:42:50 GMT

AI Capabilities Built into Azure SQL Managed Instance

Azure SQL MI includes multiple intelligence layers by default:

Intelligent Insights for anomaly detection
Automatic tuning (recommend mode)
Copilot‑assisted diagnostics
Native vector data types for AI workloads

These capabilities work together without requiring external services or agents.

Why Azure SQL MI Is a Natural Fit for AI Workloads

Azure SQL MI already sits at the center of many mission‑critical platforms:

Fully managed SQL Server–compatible PaaS
Private networking with VNet isolation
Native HA/DR, automated patching, and backups
Enterprise governance, compliance, and security

What makes it ideal for AI adoption is proximity—your data, metadata, performance history, and operational context are already there.

AI works best where data does not need to move.

Built‑In AI for Operations: Intelligent Insights

Intelligent Insights continuously analyzes workload behavior and:

Detects blocking patterns
Identifies query plan regressions
Flags unusual performance deviations
Compares current behavior to historical baselines

Instead of manually searching for issues, DBAs receive actionable signals early.

Native Vector Support: Running AI Workloads on SQL MI

Azure SQL Managed Instance now supports native vector data types, enabling AI scenarios directly within the database boundary.

Example: Vector Search Query

SELECT * FROM Products ORDER BY VECTOR_DISTANCE(embedding, @queryEmbedding);

This enables:

Semantic search
Retrieval‑augmented generation (RAG)
AI‑powered recommendations

In‑Database Machine Learning with Python and R

Azure SQL Managed Instance includes Machine Learning Services, allowing you to run Python and R scripts inside the database engine itself.

This enables:

Data preparation and feature engineering in‑place
Model training directly against full relational datasets
Real‑time scoring using stored procedures or the native PREDICT() function
Use of open‑source libraries such as scikit‑learn, TensorFlow, and PyTorch

Why this matters for Infra and DBAs:

No data exfiltration to external services
Lower latency and reduced ETL pipelines
Security boundaries remain intact
Models become part of the database deployment lifecycle

This shifts ML from being adjacent to the platform to being embedded within it.

Copilot in Azure SQL: AI‑Assisted Operations

Microsoft Copilot is integrated with Azure SQL to provide context‑aware operational insights using Query Store, DMVs, and platform telemetry.

Instead of manually inspecting metrics, teams can ask Copilot direct questions.

Example – Performance Investigation

Why did query performance degrade on this database in the last 24 hours?

Copilot leverages:

Dynamic Management Views (DMVs)
Query Store data
Azure diagnostics
SQL metadata and schema context

Copilot in SSMS: Natural Language Meets T‑SQL

Copilot is also available in SQL Server Management Studio (SSMS), supporting Azure SQL Managed Instance connections.

Capabilities include:

Natural language → T‑SQL query generation
Query explanation and optimization suggestions
Schema‑aware code assistance
Faster troubleshooting of legacy queries

Crucially, Copilot respects permissions—it cannot access tables or data that your login cannot see.

Example – Query Generation

Show top 10 customers by total order value in the last 30 days.

Generated SQL (example):

SELECT TOP 10 CustomerId, SUM(OrderAmount) AS TotalOrderValue FROM Orders WHERE OrderDate >= DATEADD(DAY, -30, GETUTCDATE()) GROUP BY CustomerId ORDER BY TotalOrderValue DESC;

This makes it safe for production environments while accelerating both DBA and developer workflows.

Azure SQL MI as a Knowledge Source for AI Agents

Azure SQL can now act as a knowledge source for Copilot Studio agents, enabling conversational access to enterprise data powered by large language models.

With this approach:

Azure SQL MI provides structured truth
Copilot Studio provides conversational intelligence
The database becomes queryable via natural language APIs

This unlocks scenarios like:

Operational dashboards backed by live SQL data
AI‑powered support assistants querying ticket or telemetry tables
Governance‑controlled enterprise chatbots grounded in SQL data

Example – Copilot Studio Prompt

What were the top database performance issues last week?

Behind the scenes, Copilot queries Azure SQL MI, processes results via Azure OpenAI, and returns a response grounded in real data.

Operational Intelligence: AI for Platform Management

Beyond queries and data science, AI in Azure SQL MI improves platform operations:

Performance insights built on historical Query Store data
Intelligent recommendations surfaced via Azure Monitor and Copilot
Reduced dependency on manual runbooks during incidents

Instead of reacting to alerts in isolation, teams can ask the platform why something happened—and receive contextual answers grounded in real telemetry.

Security, Privacy, and Responsible AI

Microsoft emphasizes responsible AI boundaries across Azure SQL integrations:

Prompts and responses are not used to train foundation models
Data remains tenant‑isolated
Access controls and RBAC are always enforced
Azure OpenAI principles apply to Copilot integrations

This allows enterprises to adopt AI without compromising compliance or data governance.

When Azure SQL Managed Instance Makes Sense for AI Adoption

Azure SQL MI is a strong fit when:

Enterprise security and compliance are mandatory
Existing SQL estates already exist
AI adoption must be platform‑led
Operational safety is a priority

Final Thoughts: SQL MI Is No Longer “Just a Database”

Azure SQL Managed Instance is transitioning from:

Migration target → Intelligent platform

For infrastructure and platform teams, this means:

Fewer external dependencies for analytics
AI assistance embedded into daily operations
Data‑centric AI architectures with clear ownership boundaries

As AI adoption accelerates, platforms that already combine data, security, and operations will lead the way. Azure SQL MI sits firmly in that category.

AI‑Assisted Azure Infrastructure Validation and Drift Detection

ShivaniThadiyan — Fri, 03 Apr 2026 08:48:00 GMT

Why Traditional Drift Detection Isn’t Enough

Most teams already rely on:

Terraform plan reviews
Azure Policy compliance dashboards
Azure Resource Graph queries
Manual scripts and audits

The problem isn’t missing data—it’s interpretation at scale.

Validation outputs are:

Verbose and noisy
Spread across multiple tools
Difficult to prioritize
Dependent on human context

This is where AI as an assistive layer adds value.

Where AI Fits (And Where It Does Not)

AI should not:

Auto‑approve infrastructure changes
Apply remediation directly
Replace Terraform, Policy, or RBAC

AI should:

Summarize large outputs
Highlight risky or unexpected changes
Detect drift patterns
Assist human decision‑making

The goal is decision support, not autonomous enforcement.

Shift‑Left Terraform: Catch Issues Early

AI‑assisted validation works best when combined with shift‑left practices—detecting problems before infrastructure is deployed.

Shift‑left moves failure detection:

From production → pipelines
From pipelines → pull requests
From pull requests → developer machines

Step‑by‑Step: Shift‑Left Terraform Lifecycle

Code Commit ↓ Local Validation ↓ Static Analysis & Security ↓ Terraform Plan Review ↓ Drift Gate ↓ Approval ↓ Apply

Step 1: Local Terraform Validation

Start at the developer workstation.

terraform init terraform validate

Step 2: PR‑Level Static Validation

Run automated checks on pull requests:

terraform fmt
Linting (TFLint)
IaC security scanning (tfsec, Checkov, etc.)

This enforces standards before merge—and reduces review friction.

Step 3: Generate a Deterministic Terraform Plan

Separate planning from execution.

terraform plan -out=tfplan

This gives full visibility with zero impact to Azure.

Step 4: AI‑Assisted Terraform Plan Review

Large Terraform plans are accurate—but exhausting to review.

GitHub Copilot can summarize the impact.

Example Copilot prompt:

Summarize this Terraform plan: 1) Security, network, or identity-impacting changes 2) Potential downtime risks 3) Unexpected changes outside standard modules Provide a concise approval-ready summary.

Step 5: Drift‑Only Detection Gate (Critical Shift‑Left Control)

Before applying changes, confirm Terraform state still matches Azure.

terraform plan -refresh-only -detailed-exitcode

Exit codes:

0 → No drift
2 → Drift detected
1 → Error

This gate catches:

Manual Portal edits
Emergency fixes not back‑ported to IaC
External automation interference

Step 6: Human Approval (Governance Intact)

Shift‑left doesn’t remove humans.

Approvals validate:

Terraform plan
Drift results
AI summaries
Policy implications

This keeps governance strong without slowing delivery.

Step 7: Apply Exactly What Was Reviewed

terraform apply tfplan

No re‑calculation.
No surprises.
No uncontrolled changes.

Azure Resource Graph: Drift in the Real World

Terraform shows intended state.
Azure Resource Graph shows actual state at scale.

Who Changed What? (Change Analysis)

resourcechanges | extend changeTime = todatetime(properties.changeAttributes.timestamp) | extend targetResourceId = tostring(properties.targetResourceId) | extend changeType = tostring(properties.changeType) | extend changedBy = tostring(properties.changeAttributes.changedBy) | extend clientType = tostring(properties.changeAttributes.clientType) | extend operation = tostring(properties.changeAttributes.operation) | where changeTime > ago(7d) | project changeTime, targetResourceId, changeType, changedBy, clientType, operation | sort by changeTime desc

This reveals:

Portal vs automation changes
Actor identity
Operation type

AI can then flag suspicious patterns instead of manual scanning.

Detecting Tag Drift

ResourceContainers | where type =~ 'microsoft.resources/subscriptions/resourcegroups' | where isnull(tags['Owner']) or isempty(tostring(tags['Owner'])) | project subscriptionId, resourceGroup=name, location, tags

Tag drift is often the earliest sign of governance decay.

Azure Policy: From Compliance to Action

Azure Policy tells you what’s non‑compliant—but not what to fix first.

PolicyResources | where type =~ 'Microsoft.PolicyInsights/PolicyStates' | extend complianceState = tostring(properties.complianceState) | extend policyAssignmentName = tostring(properties.policyAssignmentName) | summarize count() by policyAssignmentName, complianceState

AI helps here by grouping violations, ranking risk, and suggesting remediation paths.

A Reusable Azure Infrastructure Prompt Library

Instead of ad‑hoc prompting, teams can standardize infra‑specific Copilot prompts.

Terraform Plan Review

Summarize this Terraform plan: - High-risk changes - Downtime risks - Unexpected modifications

Drift Interpretation

Analyze this terraform plan -refresh-only output. Explain drift cause and recommend revert, backport, or accept.

Resource Graph Drift Triage

Group these Azure resource changes by actor and clientType. Highlight suspicious patterns and suggest guardrails.

Policy Compliance Prioritization

Group policy violations by root cause. Rank by risk and suggest remediation approaches.

Key Takeaways

Drift is inevitable; unmanaged drift is optional
Shift‑left Terraform reduces risk before Azure is touched
AI excels at analysis, not enforcement
Terraform, KQL, Policy, and AI work best together
Governance becomes clearer—not weaker

AI doesn’t replace infrastructure engineers. It helps them think faster and safer—earlier.

🚀 General Availability of Private Application Gateway on Azure Application Gateway v2

kumaramit1 — Fri, 03 Apr 2026 07:24:09 GMT

🔍 What Is Private Application Gateway?

Historically, Application Gateway v2 required a public IP address to communicate with the Azure control plane (GatewayManager). This requirement imposed several constraints:

Mandatory public IP exposure
Restricted Network Security Group (NSG) rules
Limited route table flexibility
No support for forced tunneling

Private Application Gateway removes these limitations by introducing Application Gateway Network Isolation, enabling:

Private IP‑only frontend
No public IP requirement
Full NSG and route table control
Forced tunneling support
Controlled outbound connectivity

All management and data traffic remains on the Azure backbone network.

✅ Key Capabilities (Now Generally Available)

Capability	Description
Private IP‑only frontend	Application Gateway can be deployed without any public IP
Network Isolation	Removes dependency on GatewayManager service tag
Custom NSG rules	Full control of inbound and outbound rules
Deny All outbound support	Prevent unintended internet egress
Route table flexibility	Support for 0.0.0.0/0 to virtual appliances
Forced tunneling	Works with on‑premises or hub firewalls

🧩 Architecture Overview

Private Application Gateway Architecture

✅ No public IP
✅ No internet dependency
✅ Fully private traffic flow

🛠️ How to Enable Application Gateway Network Isolation

(Required for Private Application Gateway)

The Network Isolation feature must be enabled at deployment time.

✅ Option 1: Azure Portal (Recommended)

Go to Create Application Gateway
Select SKU: Standard_v2 or WAF_v2
During Advanced configuration:
- Enable Network isolation
Configure:
- Private frontend IP only
- No public IP
Deploy the gateway

Once enabled, the gateway no longer requires inbound GatewayManager access or unrestricted outbound internet access.

✅ Option 2: Azure CLI / PowerShell / ARM

When deploying via automation:

Enable the private deployment / network isolation capability during creation
Apply:
- Custom NSG rules
- Custom route tables
- Private DNS resolution

Existing gateways cannot be retrofitted—network isolation must be enabled at creation time.

📘 Reference:
https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-private-deployment

🔐 Recommended NSG & Routing Model

NSG

Allow only required inbound ports (for application traffic)
Explicit outbound allow rules for:
- Azure Monitor
- Key Vault (if used)
Final rule: Deny All outbound

Route Table

0.0.0.0/0 → Virtual Appliance (Firewall / NVA)
Supports forced tunneling and traffic inspection

🌍 Real‑World Scenarios

✅ Scenario 1: Financial Services – Regulatory Compliance

Banks deploy Application Gateway privately behind a hub firewall, ensuring:

No public IP exposure
All traffic inspected
Full audit control

✅ Scenario 2: Enterprise Landing Zones

Platform teams deploy standardized, policy‑compliant gateways:

Azure Policy blocks public IP creation
Private Application Gateway fully supported

✅ Scenario 3: Hybrid Connectivity with Forced Tunneling

Traffic from Application Gateway flows through:

Azure Firewall
On‑premises inspection devices
Central logging systems

✅ Scenario 4: Internal Line‑of‑Business Apps

HR, Finance, and internal portals:

Accessible only from corporate networks
No internet attack surface

⚠️ Important Considerations

Network Isolation must be enabled at creation
Requires Standard_v2 or WAF_v2
Private DNS planning is critical
Monitoring endpoints must be explicitly allowed

📌 When Should You Use Private Application Gateway?

✅ You want zero public exposure
✅ You require forced tunneling
✅ You enforce Deny All outbound
✅ You operate in regulated environments
✅ You follow Enterprise Landing Zone patterns

🎯 Final Thoughts

Private Application Gateway fundamentally changes how Application Gateway fits into secure Azure architectures. With Network Isolation now generally available, customers can finally deploy Application Gateway in fully private, firewall‑controlled, enterprise‑grade environments—without workarounds.

This feature unlocks new design patterns for:

Landing Zones
Hub‑and‑spoke networks
Regulated workloads
Hybrid connectivity

🔗 Learn More

Enterprise‑Scale Azure Subscription Vending Using Azure Verified Modules (AVM)

kumaramit1 — Fri, 03 Apr 2026 06:45:24 GMT

Why Subscription Vending Is Critical at Scale

Azure subscriptions define the security, governance, and billing boundary for workloads. In large organizations, manual subscription creation often leads to:

Inconsistent management group placement
Delayed or missing policy enforcement
Incorrect RBAC assignments
Lack of cost controls
Platform teams becoming a bottleneck

Subscription vending standardizes this process by allowing application teams to request subscriptions while platform teams enforce governance through automation. Microsoft formally recommends this approach as part of Azure Landing Zones.

Azure Verified Modules (AVM) – The Foundation

Azure Verified Modules (AVM) are Microsoft‑owned and Microsoft‑supported Infrastructure as Code modules that codify Azure Well‑Architected Framework guidance.

AVM provides:

Resource modules – deploy individual Azure resources
Pattern modules – deploy opinionated architectural patterns

Subscription vending is delivered as an AVM pattern module, making it the preferred and supported approach for enterprise landing zones.

Key benefits:

Microsoft supported
Terraform and Bicep support
Built‑in governance
Used by Azure Landing Zone accelerators

AVM Subscription Vending Pattern Overview

The Terraform module used for subscription vending is:

Azure/avm-ptn-alz-sub-vending

This module enables:

Azure subscription creation
Management group association
Resource provider registration
RBAC assignments
Budget enforcement
Optional networking scaffolding

The module uses the AzAPI provider, allowing subscription creation and governance configuration in a single Terraform apply.

Reference Architecture

High‑level flow:

Subscription request captured (YAML/JSON or pipeline input)
CI/CD pipeline triggers Terraform
AVM module creates the subscription
Subscription is placed in the correct management group
Governance (RBAC, policies, budgets) is applied automatically

This model aligns with Microsoft’s Landing Zone architecture.

Prerequisites

1. Azure Billing and Tenant

Enterprise Agreement (EA) or Microsoft Customer Agreement (MCA)
Billing Scope ID, for example:

/providers/Microsoft.Billing/billingAccounts/<id>/enrollmentAccounts/<id>

2. Management Group Hierarchy

A predefined management group hierarchy must exist:

Tenant Root ├── Platform ├── LandingZones │ ├── Corp │ └── Online └── Sandbox

3. Tooling

az version terraform version

Identity & Permissions Model (Critical Section)

Automated subscription vending requires a non‑interactive identity (Service Principal or Managed Identity).
The key permission is the Subscription Creator role, which is a billing‑scope role, not a standard Azure RBAC role.

⚠️ Important
The Subscription Creator role cannot be assigned using the Azure Portal.

Assigning the Subscription Creator Role (Enterprise Agreement)

Role Scope Summary

Agreement	Role Scope
EA	Enrollment Account
MCA	Billing Profile / Invoice Section

This guide covers Enterprise Agreement (EA), which is most common in large landing zones.

Step 1: Create a Service Principal

az ad sp create-for-rbac \ --name avm-subscription-vending-sp \ --skip-assignment

Store securely:

appId
tenant
password (or certificate)

Step 2: Get Service Principal Object ID

az ad sp show \ --id <appId> \ --query id \ --output tsv

⚠️ Use the Object ID, not the Application ID.

Step 3: Identify the Enrollment Account

az rest \ --method get \ --url "https://management.azure.com/providers/Microsoft.Billing/enrollmentAccounts?api-version=2019-10-01-preview"

Capture:

Enrollment Account ID
Full resource ID

Step 4: Assign Subscription Creator Role (REST API)

az rest \ --method put \ --url "https://management.azure.com/providers/Microsoft.Billing/enrollmentAccounts/<ENROLLMENT_ACCOUNT_ID>/providers/Microsoft.Authorization/roleAssignments/<GUID>?api-version=2019-10-01-preview" \ --body '{ "properties": { "principalId": "<SERVICE_PRINCIPAL_OBJECT_ID>", "roleDefinitionId": "/providers/Microsoft.Authorization/roleDefinitions/4f8fab4f-1852-4a58-9a5b-5f5f75a2f8a8" } }'

Notes:

<GUID> → any new GUID
Role definition ID corresponds to Subscription Creator

Step 5: Verify Assignment

az rest \ --method get \ --url "https://management.azure.com/providers/Microsoft.Billing/enrollmentAccounts/<ENROLLMENT_ACCOUNT_ID>/providers/Microsoft.Authorization/roleAssignments?api-version=2019-10-01-preview"

Important Constraints

Service Principal must be in the same tenant as the EA billing account
Cross‑tenant assignment is not supported
Subscription Creator will not appear in Azure Portal IAM

Terraform Implementation Using AVM

Provider Configuration

terraform { required_providers { azurerm = { source = "hashicorp/azurerm" version = "~> 3.0" } azapi = { source = "Azure/azapi" } } } provider "azurerm" { features {} }

AVM Subscription Vending Module

module "subscription_vending" { source = "Azure/avm-ptn-alz-sub-vending/azure" version = "0.1.1" location = "southeastasia" subscription_alias_enabled = true subscription_display_name = "corp-finance-prod" subscription_alias_name = "corp-finance-prod" subscription_workload = "Production" subscription_billing_scope = var.billing_scope subscription_management_group_association_enabled = true subscription_management_group_id = "Corp" }

Optional Governance

Budgets

budget_enabled = true budget_amount = 5000

RBAC

role_assignments = { ops = { principal_id = var.ops_group_id role_definition_name = "Contributor" } }

Deploy

terraform init terraform plan terraform apply

Validate

az account list --all --query "[?name=='corp-finance-prod']" az managementgroup subscription list --name Corp

Operational Best Practices

Use GitOps‑based subscription requests
Store parameters in version‑controlled YAML/JSON
Enforce PR approvals for new subscriptions
Treat subscriptions as immutable infrastructure
Regularly update AVM module versions
Avoid tenant‑wide Owner permissions

Conclusion

Subscription vending using Azure Verified Modules enables secure, scalable, and repeatable Azure subscription management.
By combining AVM, Terraform, and correctly scoped billing permissions, platform teams can fully automate subscription creation while enforcing governance from day one.

For any organization adopting Azure Landing Zones, AVM‑based subscription vending should be considered a foundational capability, not an optional enhancement.

References

Azure Verified Modules
https://azure.github.io/Azure-Verified-Modules/
AVM Subscription Vending Module
https://registry.terraform.io/modules/Azure/avm-ptn-alz-sub-vending/azure/latest
Subscription Vending – Azure Architecture Center
https://learn.microsoft.com/azure/architecture/landing-zones/subscription-vending
Assign EA roles to service principals
https://learn.microsoft.com/azure/cost-management-billing/manage/assign-roles-azure-service-principals

VS Code Custom Agents: AI-Powered Terraform Security Scanning in the IDE

SundarBalajiA — Thu, 02 Apr 2026 09:30:08 GMT

GitHub Copilot is already a powerful coding assistant, but out of the box it knows nothing specific about your project's conventions, security requirements, or operational processes. Custom agents change that. They let you define specialized AI assistants that live inside your repository, carry deep domain expertise, and behave consistently for every developer on your team.

This blog explains what VS Code custom agents are, what they can do, and how to build one from scratch. While the concepts apply broadly to any development workflow, this post focuses specifically on Azure infrastructure teams using Terraform and demonstrates the approach through a practical example: An AI-powered security scanner for Terraform IaC modules.

What are VS Code custom agents?

Starting with VS Code 1.99+, GitHub Copilot supports custom agents markdown files stored in your repository under .github/agents/. Each file defines a specialized AI assistant with its own:

Name and description: who this agent is and when to invoke it
Model selection: which AI model powers it
Tool permissions: what actions it can take (read files, search, run commands)
Instructions: a system prompt that defines its expertise, behavior, and constraints

When you open a workspace containing these files, the agents appear as selectable options in the Copilot Chat panel. You can invoke them by selecting from the agent picker or typing @AgentName in chat.

Think of custom agents as specialized team members you define once and every developer gets automatically when they clone the repository - a security reviewer, a code quality enforcer, a documentation generator, a deployment helper each with deep knowledge of their specific domain.

How custom agents differ from regular Copilot chat?

Aspect	Regular Copilot Chat	Custom Agent
Knowledge scope	General programming knowledge	Domain-specific expertise you define
Consistency	Varies by prompt phrasing	Consistent behavior across all users
Tool access	Context-dependent	Explicitly defined per agent
Invocation	Open chat	Named agent with focused scope
Portability	Per-user	Shared via repository
Constraints	None by default	You define guardrails (e.g., no file edits)

A regular Copilot chat session might give different answers about security best practices depending on how you phrase the question. A custom security agent gives consistent, structured findings every time because its behavior is defined in code you control.

Anatomy of a custom agent file:

A custom agent is a single markdown file with two parts:

Part 1: YAML frontmatter (metadata):

name: MyAgent description: "What this agent does and when to invoke it use keywords that match how users would naturally ask for help"
model: Claude Sonnet 4.5 (copilot)
tools: [read, search, execute]
argument-hint: "Hint text shown in the chat input when this agent is selected"

Part 2: Markdown body (instructions):

Everything after the frontmatter is the system prompt - the instructions that shape every response. This is where you define:

The agent's role and expertise
What it should and should not do
How it should structure its output
Domain-specific knowledge it should apply

The instructions can be as detailed as needed. Unlike a one-off prompt, these instructions are permanent and version-controlled alongside your code.

Frontmatter fields explained:

Name:
The agent's identifier. Appears in the agent picker dropdown and in @mentions. Use a clear, descriptive name without spaces.
Description:
This is more than a label; Copilot uses the description to determine when to suggest this agent. Include keywords that match natural language users would type: "security", "scan", "review", "deploy", "validate". The more specific, the better.
Model:
Which AI model powers the agent. Different models have different strengths:

Model	Best For
Claude Sonnet 4.5	Code analysis, security review, structured output
GPT-4o	General reasoning, broad knowledge
o3-mini	Fast responses, simple tasks

You choose the model that best fits the agent's job.

Tools:
What the agent can do. Tool selection is a security and capability decision:

Tool	Capability	Use When
ead	Read files in the workspace	Agent needs to analyze code
search	Search across workspace files	Agent needs to find files by name or content
execute	Run terminal commands	Agent needs to run scripts or tools
editFiles	Create or modify files	Agent should write or change code

Grant only what the agent needs. A read-only reviewer agent should never have editFiles. An agent that only answers questions needs only ead.

Argument-hint:
The placeholder text in the chat input when this agent is selected. Helps users understand what to type: "Specify a folder to scan or 'all' for entire workspace".

What can custom agents do?

Custom agents work well for any repetitive expert judgment task, some of the common examples include:

Use Case	What the Agent Does
Code Review	Reviews code for quality issues, anti-patterns, and naming violations with line-level findings
Security Scanning	Checks infrastructure or application code against security baselines (CIS, NIST) with remediation guidance
Documentation	Reads source code and generates API references, runbooks, or architecture summaries in your team's format
Onboarding	Answers questions about codebase conventions and patterns grounded in the actual repository
Deployment / Ops	Guides engineers through deployment or incident response using your actual infrastructure config
Testing	Reviews test coverage and suggests missing cases based on code changes
Release Management	Prepares release notes and version decisions from changelogs and git history

Prerequisites to get started:

Requirement	Details
VS Code	Version 1.99 or later
GitHub Copilot	Active subscription (Individual, Business, or Enterprise)
Copilot Chat extension	Installed and signed in to GitHub
Agent mode enabled	VS Code Settings > search "chat agent"
A repository	Agents live in .github/agents/ that is any local folder works

No additional extensions, frameworks, or infrastructure required. Agents are just markdown files.

Building the IaC security scanner: A step-by-step guide

In General, the teams writing Terraform modules for Azure infrastructure need to ensure:

RBAC roles follow least privilege (no Owner/Contributor assigned broadly)
Network rules do not allow unrestricted inbound traffic
Encryption is enforced with TLS 1.2 minimum
Diagnostic logging is configured for audit trails
Resource locks protect production resources from accidental deletion

These checks are typically done in CI/CD pipelines but that creates a slow feedback loop. A custom Copilot agent brings these checks into the IDE, giving developers security feedback while they write code.

Step 1: Create the directory:

Create .github/agents/ in your repository root if it does not already exist.

Step 2: Create the agent file:

name: IaCSecurityAgent description: "Scan Terraform and IaC files for security misconfigurations, insecure defaults, and compliance violations. Detects public endpoints, weak IAM, missing encryption, network exposure, and logging gaps. Use when user asks to check security, find misconfigurations, security review, or harden infrastructure"

model: Claude Sonnet 4.5 (copilot)

tools: [read, search, execute]

argument-hint: "Specify directory to scan (e.g., 'resource-groups'), multiple directories (e.g., 'resource-groups, nsg'), or 'all' for entire workspace"

Why Claude Sonnet 4.5?
This model was chosen for its strong code analysis, ability to reason about security context (not just pattern-match), and consistent structured output.
Why execute?
The agent saves reports by calling a helper PowerShell script. This eliminates a separate user-triggered step.
Why not editFiles?
When the agent reports findings, it does not fix them unless the user explicitly asks. This keeps the agent in an advisory role and prevents unintended changes.

Step 3: Open VS Code and test:

Open the Copilot Chat panel (Ctrl+Alt+I)
Click the agent picker (the @ icon or agent name area)
Your new agent should appear in the list
Select it and type: scan resource-groups

Step 4: Iterate on the instructions:

The instructions are just text and so anyone can easily edit them, commit the changes, and the agent behavior updates immediately for everyone on the team. Treat agent instructions like code: review, create versions and improve them over time.

What the agent checks:

The above agent's instructions in the name field define six security domains it checks against every Terraform resource:

Identity and Access Management (IAM):

Overly permissive RBAC roles (Owner, Contributor at broad scope)
Missing managed identity configuration (using keys instead)
Hardcoded credentials or secrets
Missing validation on role assignment variables

Network Security:

Public endpoints on databases, storage, Key Vaults
Admin ports (22, 3389) open to 0.0.0.0/0
Missing private endpoints for PaaS services
NSG rules allowing wildcard source addresses

Data Protection and Encryption:

Encryption at rest disabled
TLS version below 1.2
HTTPS not enforced
Secrets stored in plain text in variables

Logging and Monitoring:

Missing azurerm_monitor_diagnostic_setting resources
Log retention below 90 days
No audit logging on Key Vault, SQL, or AKS

Container and Workload Security:

AKS without RBAC enabled
Local accounts not disabled
Missing network policy configuration

Backup and Disaster Recovery:

Key Vault without purge protection
Missing soft delete configuration
No geo-redundancy for critical data

Compliance framework alignment:

Findings are mapped to Azure-relevant controls:

CIS Azure Foundations Benchmark (e.g., CIS 3.7 for storage public access, CIS 6.1 for NSG rules)
Azure Security Benchmark v3 (e.g., NS-1 for network segmentation, PA-7 for privileged access, DP-4 for encryption)
NIST 800-53 (e.g., SC-7 for boundary protection, AC-6 for least privilege)

Choosing the right scanning scope:

The agent supports flexible scope: single folder, multiple folders, or entire workspace auto-discovery. When a user says "scan all", the agent searches for every .tf file, groups them by directory, and scans each independently.

The structured security scan output:

Every finding follows a consistent format. Here is an example of a security scan result:

[MEDIUM] IAM-002: Missing principal_type default recommendation

File: user-assigned-identity/variables.tf (Line 45)

Resource: var.rg_role_assignments.principal_type

Issue: principal_type is optional with null default. In environments with ABAC policies, role assignments may fail if this is not explicitly set.

Impact: Role assignments could fail silently or be mis-scoped in ABAC-constrained environments.

Compliance: Azure Security Benchmark PA-7

Results from real scans:

Security Scan:

Scanning three Azure Terraform modules with custom agent produced the following results:

Module	HIGH	MEDIUM	LOW	Key Finding
resource-groups	1	3	2	Role assignments allow Owner/Contributor
nsg	1	3	2	Wildcard source addresses and ports not blocked
user-assigned-identity	1	3	2	Managed identity lacks role_assignments field — permissions must be set manually post-creation

Generated Security scan report:

All findings included exact file paths, line numbers, and Terraform code fixes.

The companion quality scanner:

Alongside the security agent, the workspace includes a second agent: a Super-Linter Scanner that runs native static analysis tools:

Tool	Version	Purpose
TFLint	v0.53.0	Naming conventions, unused declarations, provider pinning
terraform fmt	v1.9.8	Code formatting validation
yamllint	latest	YAML syntax and style
PSScriptAnalyzer	latest	PowerShell best practices

This agent calls a PowerShell script that produces SARIF output (viewable inline in VS Code via the SARIF Viewer extension) and an HTML report. Tool versions are pinned to match the CI/CD pipeline's super-linter commit, so local results are consistent with what CI would produce.

Why agent-based scanning goes beyond traditional tools?

Traditional static analysis tools like tfsec, Checkov, or tflint work by matching code patterns against a database of rules. They catch what they know about. The AI agent adds a layer of reasoning:

It can recognize that a variable accepting any role name is dangerous even when no bad value is currently assigned the vulnerability is the missing validation, not an existing misconfiguration.
It can correlate findings across files (a storage account in one file, its network rules in another).
It maps findings to compliance frameworks without you maintaining a rule-to-control mapping table.
It produces natural language explanations of why something is a problem, not just a rule ID.

This does not replace deterministic tools, but it complements them. Use both.

Key takeaways:

Custom VS Code Copilot agents are markdown files in .github/agents/ with no extension development, no deployment, no infrastructure required.
The YAML frontmatter controls model selection, tool permissions, and how Copilot decides when to suggest the agent.
The markdown body is your system prompt, treat it like code: version, review and iterate on it.
Tool permissions are a security decision: grant only what the agent needs.
Custom agents are portable that means anyone who clones the repository gets the agents automatically.
Combining AI reasoning with deterministic tools (tflint, terraform fmt) provides coverage neither can achieve alone.
The agent pattern applies far beyond security scanning such as documentation, onboarding, deployment, testing, compliance.

Useful resources:

Migrating Azure SQL Database Across Tenants Using Subscription Transfer

princy_rajpoot — Wed, 01 Apr 2026 16:01:18 GMT

Moving an Azure subscription between Microsoft Entra ID (formerly Azure Active Directory) tenants is a common requirement during:

Mergers and acquisitions
Organizational restructuring
Enterprise Agreement (EA) enrollment realignment
Lighthouse or multi‑tenant operating model changes

However, when that subscription hosts Azure SQL databases secured using Microsoft Entra ID authentication, the migration becomes identity‑dependent and must be executed carefully.

Microsoft Entra ID identities are tenant‑scoped. During a cross‑tenant subscription transfer, identities from the source tenant are no longer trusted by the target tenant. This directly impacts:

Azure RBAC role assignments
Azure SQL Entra ID logins
Managed identities
Application authentication tokens

If authentication sequencing is not handled correctly, administrators and applications can lose access to Azure SQL immediately after the migration.

This article provides a proven enterprise‑tested 8‑step migration playbook to safely migrate Azure SQL workloads across Microsoft Entra ID tenants without administrative lockout or application downtime.

Migration Overview

The migration follows a three‑stage operating model:

Before Subscription Transfer (Source Tenant)

Export RBAC assignments and SQL identity configuration
Perform and validate a SQL backup

During Migration

Temporarily enable SQL Authentication
Ensure administrative access independent of Entra ID

After Subscription Transfer (Target Tenant)

Configure new Entra ID administrator
Recreate RBAC assignments and database principals
Validate application connectivity

The diagram represents three distinct phases, which are explained below exactly as they appear in the flow.

Phase 1 – Pre‑Migration Preparation

Step 1 – Export SQL Server Logins, Database Users, Roles, and Permissions

Before initiating the subscription transfer, export all identity‑related configuration from the source Azure SQL Server.

This export serves as:

A rollback reference
A rebuild blueprint for the target tenant
An audit artifact for change tracking

Capture the following:

Server Level

Microsoft Entra ID users
Microsoft Entra ID groups
SQL Authentication logins

Database Level

Contained database users
Database role memberships
- db_owner
- db_datareader
- custom roles

Azure RBAC Assignments On

SQL Server
Resource Group

Database Permissions

GRANT
DENY
EXECUTE
Object‑level access

✅ Subscription transfers always remove Microsoft Entra ID–based role assignments. Treat this export as mandatory.

Step 2 – Perform SQL Database Backup

Take a fresh backup immediately before migration.

Recommended enterprise options include:

BACPAC export to Azure Blob Storage
Native BACKUP TO URL
Long‑Term Retention (LTR) snapshot

⚠️ A backup that has not been test‑restored is not a valid rollback strategy. Always validate restore operations in a non‑production environment before migration day.

Phase 2 – Migration Day Execution

Step 3 – Switch Authentication Mode (Entra ID ➜ SQL Authentication)

This is the most critical step in the entire migration workflow.

Before initiating the EA subscription transfer:

Disable Entra ID–only authentication
Enable SQL Authentication
Validate SQL Administrator login

Why This Is Required

Microsoft Entra ID identities exist only within their original tenant.
Once the subscription is transferred:

Source tenant identities become invalid
Azure SQL logins mapped to those identities stop functioning

SQL Authentication provides a:

Tenant‑independent authentication method
Temporary administrative access path

Skipping this step may result in complete administrative lockout.

Step 4 – Migrate Subscription via EA Transfer

The EA transfer moves the subscription to the target tenant directory.

Preserved During Migration

Azure resources
SQL databases
Database data
SQL Authentication logins

Removed During Migration

Azure RBAC assignments
Entra ID SQL logins
Managed Identity bindings

Phase 3 – Post‑Migration Configuration

Step 5 – Configure Microsoft Entra ID Administrator (Target Tenant)

After migration:

Assign a new Microsoft Entra ID Administrator to the Azure SQL Server
Use an Entra ID Group instead of an individual user
Optionally re‑enable Entra ID‑only authentication after validation

Using groups ensures identity continuity if administrators change or accounts are disabled.

Step 6 – Re‑Create RBAC Assignments and Database Identity Configuration

Using the exported configuration:

Reapply:

Azure RBAC role assignments
Microsoft Entra ID SQL logins
Database users
Role memberships
Object‑level permissions

✅ Automation is strongly recommended for environments hosting multiple databases or elastic pools.

Phase 4 – Validation and Testing

Step 7 – Database Integration Testing

Validate:

Entra ID administrator connectivity
Application identity access
Read and write operations
Stored procedures
Backup and restore functions
Firewall rules
Private endpoint connectivity

Step 8 – End‑to‑End Application Testing

Perform full application validation including:

Authentication via Entra ID tokens
Business transaction workflows
Scheduled jobs and background services
Performance baselines
Error telemetry

Migration should be considered complete only after application owner sign‑off.

Common Migration Pitfalls

Pitfall	Impact
SQL Authentication not enabled before transfer	Administrative lockout
Using individual Entra ID user as SQL admin	Risk of orphaned access
Assuming Azure RBAC survives migration	RBAC must be recreated
Hard‑coded tenant IDs in applications	Authentication failures
Untested backups	No reliable rollback

Migration Checklist

Pre‑Migration

Export SQL logins, users, roles, permissions
Export Azure RBAC assignments
Perform full database backup
Test restore in lower environment
Enable SQL Authentication
Validate SQL Admin login

Migration Day

Switch authentication mode
Store SQL admin credentials securely
Initiate EA transfer
Accept transfer in target enrollment
Confirm subscription visibility

Post‑Migration

Configure Microsoft Entra ID Admin
Reapply RBAC assignments
Recreate SQL Entra ID logins
Recreate database users
Reassign roles and permissions

Validation and Sign‑Off

Database validation complete
Application validation complete
Performance baseline verified
Security review approved
CAB approval obtained
Migration documentation completed

Conclusion

Cross‑tenant Azure SQL migrations succeed or fail based on authentication sequencing.

Temporarily switching from Microsoft Entra ID authentication to SQL Authentication prior to subscription transfer—combined with disciplined RBAC export and re‑application—provides a:

Safe
Repeatable
Auditable

migration strategy.

This approach scales from single‑database migrations to enterprise‑wide SQL estates and is particularly suited for regulated environments where downtime and access risk must be tightly controlled.

Subscription Vending in Azure: An Implementation Overview

abhilashasr — Tue, 31 Mar 2026 07:48:15 GMT

Subscription vending is a process that enables the creation of multiple Azure subscriptions using code, based on organizational segregation or workload-specific requirements. Rather than relying on resource groups as the primary boundary, this approach treats subscriptions as the fundamental unit for workload management.

Diagram 1: Subscription Vending

Subscription vending follows the concept of subscription democratization and applies it within the Azure Landing Zone (ALZ) model. With this approach, subscriptions act as the foundational boundary for the organization. This makes it easier to scale environments while also enabling stronger regulation, governance, and security controls.

Subscription democratization is a scalable approach that helps accelerate application migration or new application deployment. It enables teams to work independently and deliver results faster, while still maintaining proper governance and security. Through subscription vending, multiple subscriptions can be deployed based on individual workload requirements

Subscription Vending Implementation Guidance

Subscription vending is achieved through automation and typically involves the following tasks:

Collecting subscription request data
Initiating platform automation
Creating subscriptions using Infrastructure as Code (IaC)

There are multiple ways to implement subscription vending automation to complete these tasks. One example approach is GitFlow.

In this model, subscription request data is captured through a data collection tool and stored in a JSON or YAML parameter file. Once the request is approved, platform automation is triggered using a request pipeline, source control, and a deployment pipeline. IaC modules are then used to create the required subscription.

Diagram 2: Example of Subscription Vending GitFlow

Implementation Steps

The following steps describe the implementation flow shown in the diagram:

A data collection tool is used to gather subscription request information.
Once the subscription request is approved, platform automation is initiated through the request pipeline, source control, and deployment pipeline.

To standardize and regulate the foundational structure across environments, automation is implemented using Infrastructure as Code. This approach also enables new subscriptions to be deployed with minimal effort.

Resources Deployed During Subscription Creation

As a best practice, the following resources are deployed during subscription creation:

Management Group: Management groups are created based on the organizational design and structure.
Subscription: Subscriptions are created using code according to design requirements. During creation, billing account details are configured to align with the billing scope. A subscription alias is also added at this stage. Once the subscription is created, it is associated with the appropriate management group. Capabilities such as renaming or cancelling subscriptions can also be managed. Cancelling a subscription through Terraform can deactivate it; the subscription can be reenabled within 90 days. After 90 days, the subscription is permanently deleted.
Budget: Subscription budgets can be defined based on required thresholds.
Resource Provider Registration: Required resource providers are enabled by default, allowing the necessary REST operations for resource deployment.
Identity Management: Required role assignments, including custom roles, can be applied at the subscription or scoped level. Custom RBAC roles can be created if prebuilt roles do not meet requirements and assigned at the subscription level.

Additional Notes

A subscription alias in Azure is a resource type used to create a new subscription, typically under an Enterprise Agreement (EA) billing model. An alias enables the creation of new subscriptions but cannot be used to update existing ones.

Azure provides Azure Verified Modules (AVM) for all the resources mentioned above. These modules help standardize implementation and follow best practices. The reference implementation is available through the AVM pattern for subscription vending.

VS Code Extension

Shikhaghildiyal — Tue, 31 Mar 2026 03:00:06 GMT

What is a VS Code Extension?

A VS Code Extension is a small program that adds new features or enhances existing functionality in Visual Studio Code. Extensions allow developers to tailor the editor to their needs by adding support for new languages, tools, themes, debuggers, commands, and integrations.

VS Code extensions can help you:

Add language support (syntax highlighting, IntelliSense)
Create custom commands in the Command Palette
Automate repetitive development tasks
Integrate external tools and services
Improve productivity with formatting, linting, and debugging tools

Extensions are published and distributed through the Visual Studio Marketplace, where users can easily install and update them directly from VS Code .

At a high level, a VS Code extension:

Runs on Node.js
Is written in JavaScript or TypeScript
Uses the VS Code Extension API to interact with the editor .

How to Create a VS Code Extension (Step-by-Step)

Let’s walk through creating a simple Hello World VS Code extension using the official tooling provided by Microsoft.

Step 1: Prerequisites

Before you begin, make sure you have the following installed:

Node.js (required to run and build extensions)
npm (comes with Node.js)
Git (recommended for source control)
Visual Studio Code

VS Code extensions are built on Node.js and TypeScript/JavaScript, so Node.js is mandatory.

Step 2: Install Yeoman and the VS Code Extension Generator

Microsoft provides an official Yeoman generator to scaffold VS Code extensions quickly.

Run the following command in your terminal:

npm install -g yo generator-code

This installs:

Yeoman (yo) – a project scaffolding tool
generator-code – the VS Code extension generator.

Step 3: Scaffold a New Extension

Create a new extension project by running:

yo code

You’ll be prompted with a few questions:

Type of extension → New Extension (TypeScript or JavaScript)
Extension name
Identifier
Description
Package manager (npm recommended)

After answering these, Yeoman will generate a ready-to-use extension project structure.

Step 4: Understand the Project Structure

A typical generated extension contains:

package.json – Extension metadata, commands, and contributions
src/extension.ts or extension.js – Main extension logic
.vscode/launch.json – Debug configuration
README.md – Documentation

The package.json file tells VS Code:

What your extension contributes (commands, menus, settings)
Which VS Code versions it supports

The extension.ts file contains the code that runs when your extension is activated.

Step 5: Run and Test the Extension

To test your extension:

Open the extension project in VS Code
Press F5 (Start Debugging)
A new Extension Development Host window opens
Open the Command Palette (Ctrl+Shift+P)
Run your extension command (e.g., Hello World)

You should see a notification message, confirming your extension is working.

Step 6: Modify the Extension

You can now customize the extension behavior by editing extension.ts:

Change the message shown to users
Register new commands
Use VS Code APIs (notifications, input boxes, file access)

After making changes:

Reload the Extension Development Host
Re-run the command to see updates

VS Code provides built-in debugging tools to set breakpoints and inspect variables during extension execution.

Step 7: Package and Publish (Optional)

To publish your extension to the VS Code Marketplace:

Install the VS Code Extension CLI: npm install -g vsce
Create a publisher account
Package and publish the extension:

vsce package vsce publish

Use Case

In a recent enterprise infrastructure initiative, there was a recurring need to generate Terraform code for CPF modules in strict alignment with project reference guidelines and approved module templates. Although these modules were centrally maintained in a project repository, manual consumption required engineers to repeatedly search across repositories, interpret module definitions, and assemble boilerplate code. To reduce this overhead and improve consistency, a custom Visual Studio Code extension was implemented to automate Terraform scaffolding while ensuring the generated output remained compliant with project standards.

A key constraint for this solution was that MCP (or any managed AI orchestration platform) could not be used. Accordingly, the design was implemented entirely within the VS Code extension boundary, with deterministic control points to preserve auditability. The extension integrates with the repository through its APIs to fetch the latest module templates and then extracts relevant module metadata—such as variables, outputs, and structural requirements - to drive generation decisions. This ensured the extension was not dependent on static local templates and could remain aligned with repository-driven evolution of CPF modules.

For the Terraform code generator portion specifically, GitHub Copilot was incorporated to assist with producing the final Terraform configuration content efficiently. In this model, Copilot supports rapid iteration and contextual code generation within the developer workflow, while the VS Code extension continues to act as the governing layer that constrains and validates what gets generated (for example, enforcing module selection rules, naming conventions, and approved file structure). This mirrors the broader pattern where Copilot enhances developer experience and productivity in the IDE without replacing deterministic guardrails.

The overall result is an editor-native workflow that balances productivity and compliance: repository APIs provide the authoritative source of module templates; deterministic parsing and guideline enforcement provide consistency and repeatability; and GitHub Copilot accelerates the code authoring experience for Terraform files. This demonstrates that meaningful Infrastructure-as-Code automation can be delivered under strict platform constraints, while still leveraging AI-assisted development responsibly within controlled boundaries.

End to end Flow

Start
- User launches the VS Code extension.

Resource & Source Selection
- User selects resource types and chooses a source (GitLab or JFrog).

Source Choice Branching
- GitLab Path:
  - Fetch projects
  - Filter and rank modules
- JFrog Path:
  - Fetch artifacts
  - Filter and rank modules

Ranked Module List
- Consolidated ranked modules displayed to the user.
User Selection
- User selects modules to deploy.

Download/Clone Modules
- Clone Git repositories or download artifacts.
- Extract to workspace.

Terraform Parser
- Parse .tf files for:
  - locals
  - module calls
  - required_providers
  - provider blocks
  - backend configuration
Metadata Assembly
- Aggregate:
  - module_info
  - example_values (locals, module_calls, providers, backend)
Output Generation
- Save Module JSON:
  - Separate files for GitLab and JFrog.
- Generate Prompt:
  - Initialize prompt-for-Iac.md
  - Append module metadata.

AI-Assisted IaC Generation
- Use prompt to generate Terraform files:
  - main.tf
  - providers.tf
  - variables.tf
  - outputs.tf
Deployable Terraform Code
- Ready for:
  - terraform init
  - terraform plan
  - terraform apply

End
- User to review that code and replace the values (if required).

CI/CD as a Platform: Shipping Microservices and AI Agents with Reusable GitHub Actions Workflows

nasreensarah — Mon, 30 Mar 2026 10:48:39 GMT

The First Shift — Treating CI/CD as a Platform

The first insight is straightforward but underused:

Your CI/CD logic is infrastructure. It deserves the same design discipline as your application code.

That means centralizing it. Versioning it. Exposing it as reusable, callable workflows — not copy-pasted YAML scattered across dozens of repos.

In Part 1 of this series, we build exactly that. A platform repository that defines reusable GitHub Actions workflows for testing, building, and deploying containerized services to Azure. Application repos stay thin — they simply call the platform, like invoking an API.

Build once. Deploy anywhere. Fix once. Every team benefits.

The Second Shift — Governing AI Behavior

But software is changing.

We are no longer just shipping APIs and microservices. We are shipping AI agents — systems that reason, respond, and make decisions. And these systems break the assumptions that traditional CI/CD was built on.

A unit test can tell you whether your code is correct. It cannot tell you whether your AI agent is trustworthy. Prompts behave like code but drift differently. Model outputs are probabilistic. Quality degrades silently, without a failed test to catch it.

This creates a new engineering challenge:

How do you build a delivery pipeline for something that does not have a deterministic right answer?

In Part 2, we extend the platform to answer that question. We introduce evaluation as a deployment gate — a reusable workflow that scores agent behavior before any deployment is allowed. We integrate with Microsoft Foundry for agent runtime and observability. And we show how the same platform-thinking from Part 1 applies directly to AI systems.

What This Series Is Really About

This is not a tutorial on GitHub Actions syntax.

It is about maturity — the difference between a team that writes pipelines and a team that designs delivery systems. Between an organization that ships code and one that governs behavior.

By the end of both parts, you will have:

A reusable CI/CD platform that scales across any number of services
An evaluation-driven delivery pipeline for AI agents
A mental model for treating both code and AI as governed, versioned artifacts

The tools are GitHub Actions and Azure. The principle is platform thinking.

Let's build it.

The Problem — Why CI/CD Pipelines Don't Scale

Every pipeline starts simple.

You create a repository, add a workflow file, and within minutes your code is building and deploying automatically. It feels like a solved problem.

It isn't.

The Reality of Growth

The first pipeline is straightforward. The second is a copy of the first. The third is a copy of the second — with one small adjustment. By the time you have ten services, you have ten slightly different pipelines, each one drifting quietly away from the others.

This is pipeline sprawl — and it is far more costly than it appears.

Consider what happens in practice:

One team upgrades their Python version. Others don't.
A security fix gets applied to three pipelines. The other seven are missed.
A new compliance requirement means updating every workflow file — manually, one repo at a time.
A new engineer onboards using an old workflow and ships a pattern that was deprecated months ago.

None of this feels critical in the moment. But over time, your CI/CD layer becomes the most inconsistent, unmaintainable, and ungoverned part of your infrastructure — even though it controls everything that ships to production.

The Deeper Problem — No Separation of Concerns

The root cause is not a tooling limitation. It is a design problem.

Most teams treat CI/CD as something that lives inside an application repo — a secondary concern, not a first-class system. That model works at small scale. It breaks at org scale.

When CI/CD logic is distributed across every application repo:

There is no single source of truth for how deployments work
Platform teams cannot enforce standards without touching every repo individually
Security and compliance teams have no centralized control plane
Onboarding a new service means rebuilding from scratch — or copying from an outdated reference

The Cost You Don't See

The real cost of this pattern is not the duplicated YAML. It is the compounding overhead:

Problem	Visible Cost	Hidden Cost
Duplicated pipelines	Time to replicate	Drift and inconsistency over time
No centralized logic	Minor friction	Security gaps across repos
Manual updates	One-time effort per change	Multiplied across every service
No versioning	Manageable today	Breaking changes with no rollback path

What the Solution Looks Like

The answer is not a better YAML template.

It is a platform.

Specifically — a centralized repository that owns CI/CD logic, exposes it as reusable versioned workflows, and lets every application team consume it without duplicating a single line of pipeline code.

This is the same principle that drives every mature engineering organization:

Don't repeat infrastructure. Abstract it. Version it. Share it.

That is exactly what we are going to build.

The Architecture — What You're Building

Before writing a single line of code, it is worth understanding the system as a whole.

The architecture is intentionally simple. Two repositories. One cloud infrastructure. One clear separation of responsibilities.

The Two-Repo Model

This separation is the core design decision. Everything else follows from it.

The platform repo is not an application. It does not ship features. It ships workflow infrastructure — reusable, versioned, callable by any application team in your organization.

The application repo is deliberately thin on CI/CD. It contains a single workflow file that calls the platform. Nothing more.

How They Connect

The connection happens through GitHub's workflow_call trigger — a mechanism that allows one workflow to invoke another across repositories.

The application repo does not care how the build works. It only cares about the contract — inputs it needs to provide, outputs it can expect back.

This is the same mental model as an API:

The caller knows the interface. The platform owns the implementation.

The Deployment Flow

Once triggered, the pipeline moves through four clearly defined stages:

A few things to note about this flow:

The image is built exactly once. The same artifact moves through every environment — no rebuilds, no drift.
The Git SHA is the image tag. Every deployment is fully traceable back to a specific commit.
GitHub Environments control approvals. Staging and production are separate environments with configurable protection rules — no custom approval logic needed.

The Azure Infrastructure

On the cloud side, the system uses two Azure services:

Service	Role
Azure Container Registry (ACR)	Stores Docker images
Azure Container Apps	Runs the application in staging and production

Both are provisioned using Bicep — Azure's infrastructure-as-code language — so the infrastructure is versioned and repeatable alongside the workflows.

Responsibility Map

Here is how responsibilities are distributed across the system:

Layer	Owns	Does Not Own
Platform Repo	Test logic, build logic, deploy logic	Application code
Application Repo	Business logic, Dockerfile, requirements	Pipeline implementation
Azure	Runtime, registry, networking	Deployment decisions

This clean separation means:

Platform teams can update CI/CD logic without touching application code
Application teams can ship features without understanding pipeline internals
Infrastructure changes are isolated to the Bicep layer

Why This Scales

The real power of this architecture becomes clear at scale.

With fifty microservices:

One change to deploy.yml in the platform repo propagates to every service on the next run. No manual updates. No drift. No inconsistency.

This is what CI/CD as a platform means in practice.

Platform Repo — Structure and Reusable Workflows

The platform repo is the heart of this system. Everything it contains is designed to be reusable, versioned, and consumed by any application team in your organization.

Let's walk through it in full.

Repository Structure

Three workflows. One infrastructure file. That is the entire platform.

Each workflow has a single, well-defined responsibility:

Workflow	Responsibility
test-python.yml	Install dependencies and run tests
build.yml	Build Docker image and push to ACR
deploy.yml	Deploy a specific image to a specific environment

Workflow 1 — test-python.yml

This workflow handles dependency installation and test execution for any Python-based service.

name: test-python on: workflow_call: jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-python@v5 with: python-version: "3.11.9" - run: pip install -r requirements.txt - run: pytest

What to note:

The on: workflow_call trigger is what makes this reusable. It cannot be triggered directly — it must be called by another workflow.
The Python version is pinned to 3.11.9 — not a floating version like 3.11. This ensures every service tests against the exact same runtime, eliminating environment-specific failures.
Any application repo that calls this workflow gets consistent, centrally maintained test execution — without defining any of this logic themselves.

Workflow 2 — build.yml

This workflow builds the Docker image, tags it with the Git SHA, and pushes it to Azure Container Registry.

name: build on: workflow_call: outputs: image_tag: value: ${{ jobs.build.outputs.image_tag }} jobs: build: runs-on: ubuntu-latest outputs: image_tag: ${{ steps.meta.outputs.tag }} permissions: id-token: write contents: read steps: - uses: actions/checkout@v4 - id: meta run: echo "tag=${GITHUB_SHA}" >> $GITHUB_OUTPUT - uses: azure/login@v2 with: client-id: ${{ secrets.AZURE_CLIENT_ID }} tenant-id: ${{ secrets.AZURE_TENANT_ID }} subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }} - run: az acr login --name ${{ secrets.ACR_NAME }} - run: | docker build -t ${{ secrets.ACR_LOGIN_SERVER }}/app:${{ github.sha }} . docker push ${{ secrets.ACR_LOGIN_SERVER }}/app:${{ github.sha }}

What to note:

outputs — This workflow exposes image_tag as an output. The calling workflow captures this value and passes it downstream to the deploy workflow. This is how the same image tag flows from build → staging → production without being hardcoded anywhere.
id-token: write — This permission enables OIDC-based authentication with Azure. No long-lived credentials are stored as secrets. GitHub generates a short-lived token at runtime, which Azure trusts via a federated identity configuration. This is the recommended authentication pattern for production workloads.
${GITHUB_SHA} — Using the commit SHA as the image tag makes every build fully traceable. Given any running container, you can identify the exact commit it was built from.

Workflow 3 — deploy.yml

This workflow deploys a given image to a given environment in Azure Container Apps.

name: deploy on: workflow_call: inputs: environment: required: true type: string image_tag: required: true type: string app_name: required: true type: string jobs: deploy: runs-on: ubuntu-latest environment: ${{ inputs.environment }} steps: - uses: azure/login@v2 with: client-id: ${{ secrets.AZURE_CLIENT_ID }} tenant-id: ${{ secrets.AZURE_TENANT_ID }} subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }} - run: | az containerapp update \ --name ${{ inputs.app_name }} \ --resource-group ${{ secrets.AZURE_RESOURCE_GROUP }} \ --image ${{ secrets.ACR_LOGIN_SERVER }}/app:${{ inputs.image_tag }}

What to note:

Three inputs — environment, image_tag, and app_name. This single workflow handles every environment. The caller decides where to deploy by passing inputs — the workflow itself has no hardcoded environment logic.
environment: ${{ inputs.environment }} — This line is deceptively powerful. By mapping the job's environment to the input value, GitHub automatically applies whatever protection rules are configured for that environment — required reviewers, wait timers, deployment policies. Approval gates come for free.
secrets: inherit — When the calling workflow passes secrets: inherit, Azure credentials flow through automatically without being re-declared. Secrets are managed once, at the org or repo level.

The Versioning Contract

One detail that makes this system production-ready is workflow versioning.

When an application repo calls a platform workflow, it references a specific version:

The v1 tag means:

Application teams are insulated from breaking changes in the platform
Platform teams can ship improvements without forcing immediate upgrades
You can run v1 and @v2 side by side during migrations
Every deployment is traceable to a specific platform version

This versioning model is what separates a platform from a shared folder of YAML files.

What Application Teams See

From an application team's perspective, the entire platform surface looks like this:

Three uses statements. That is the entire CI/CD surface an application team needs to understand.

Everything else — authentication, image tagging, registry login, container update commands — is abstracted away inside the platform.

Azure Infrastructure

The platform workflows handle CI/CD logic. The Azure infrastructure handles the runtime — where your containers live, how they are stored, and how they are served to the outside world.

All infrastructure is defined in Bicep — Azure's native infrastructure-as-code language. This means your infrastructure is versioned, repeatable, and deployable from a single command.

Why Bicep

Before diving into the code, it is worth briefly explaining the choice.

Bicep compiles down to ARM templates but is significantly more readable. It integrates natively with Azure's resource model, requires no external state management, and fits naturally alongside GitHub Actions workflows.

For teams already working within the Azure ecosystem, it is the most straightforward path to infrastructure-as-code without introducing additional tooling dependencies.

Infrastructure Structure

The entire infrastructure is defined in a single file. For this architecture, you need two resources:

Resource	Purpose
Azure Container Registry (ACR)	Stores and serves Docker images
Azure Container Apps	Runs containers in a managed serverless environment

main.bicep

param location string = resourceGroup().location // Azure Container Registry resource acr 'Microsoft.ContainerRegistry/registries@2023-01-01-preview' = { name: 'myregistry' location: location sku: { name: 'Basic' } } // Azure Container App (Staging + Production) resource containerApp 'Microsoft.App/containerApps@2023-05-01' = { name: 'my-app' location: location properties: { configuration: { ingress: { external: true targetPort: 8000 } } } }

Breaking It Down

Container Registry

resource acr 'Microsoft.ContainerRegistry/registries@2023-01-01-preview' = { name: 'myregistry' location: location sku: { name: 'Basic' } }

The ACR is the central image store for your entire platform. Every image built by build.yml is pushed here, tagged with its Git SHA. Both staging and production pull from this registry — ensuring the exact same artifact runs in both environments.

The Basic SKU is sufficient for most team-scale workloads. For larger organizations with higher throughput requirements, Standard or Premium SKUs offer geo-replication and increased storage limits.

Container App

resource containerApp 'Microsoft.App/containerApps@2023-05-01' = { name: 'my-app' location: location properties: { configuration: { ingress: { external: true targetPort: 8000 } } } }

Azure Container Apps provides a fully managed serverless container runtime. You define what runs — it handles scaling, networking, and availability.

Two things to note here:

external: true — Makes the application publicly accessible over HTTPS. Azure Container Apps automatically provisions a fully qualified domain name and TLS certificate.
targetPort: 8000 — Maps to the port exposed by the FastAPI application inside the container. This must match the --port argument in your CMD instruction in the Dockerfile.

Staging vs. Production

You will deploy this infrastructure twice — once for staging, once for production — with different resource names:

# Deploy staging az deployment group create \ -- resource-group rg-ciplatform-staging \ -- template-file infra/main.bicep # Deploy production az deployment group create -- resource-group rg-ciplatform-production \ -- template-file infra/main.bicep

The deploy.yml workflow then targets the correct app by name via the app_name input:

This keeps staging and production fully isolated at the infrastructure level while sharing the same workflow logic.

GitHub Environments and Approval Gates

On the GitHub side, you configure two Environments — staging and production — inside your repository settings.

For production, add a required reviewer protection rule:

When the pipeline reaches the deploy-prod job, GitHub will pause and wait for a designated reviewer to approve before proceeding. This approval gate costs nothing extra — it is built into GitHub's environment model and wired automatically through the environment: field in deploy.yml.

Setting Up Azure Authentication

The workflows authenticate to Azure using OpenID Connect (OIDC) — a keyless authentication method that eliminates the need for long-lived service principal secrets.

Set up the federated identity once:

# Create a service principal az ad app create -- display-name "github-actions-platform" # Add federated credential for your repo az ad app federated-credential create \ -- id <app-id> \ -- parameters '{ "name": "github-actions", "issuer": "https://token.actions.githubusercontent.com", "subject": "repo:your-org/fastapi-app:ref:refs/heads/main", "audiences": ["api://AzureADTokenExchange"] }'

Then add these three secrets to your GitHub repository:

Secret	Value
AZURE_CLIENT_ID	Application (client) ID
AZURE_TENANT_ID	Directory (tenant) ID
AZURE_SUBSCRIPTION_ID	Azure subscription ID
AZURE_RESOURCE_GROUP	Target resource group name
ACR_NAME	Container registry name
ACR_LOGIN_SERVER	Registry login server (e.g. myregistry.azurecr.io)

With these in place, every workflow that calls azure/login@v2 authenticates automatically — no passwords, no rotation, no expiry management.

Application Repo — Structure, Code, and Release Workflow

With the platform repo in place, the application repo becomes remarkably simple. Its only CI/CD responsibility is to call the platform — everything else is focused purely on application logic.

This is the goal: application teams ship features, not pipelines.

Repository Structure

This is the entire CI/CD footprint of the application repo.

The Application — src/main.py

The application is a minimal FastAPI service with a single endpoint that returns the current deployed version and environment.

from fastapi import FastAPI import os app = FastAPI() @app.get("/version") def version(): return { "version": os.getenv("GITHUB_SHA", "dev"), "environment": os.getenv("APP_ENV", "local") }

This endpoint serves a practical purpose beyond demonstration. In a real system, a /version or /health endpoint like this allows you to:

Verify which commit is running in each environment
Confirm a deployment succeeded without inspecting container logs
Detect environment mismatches between staging and production

requirements.txt

All dependencies are pinned to exact versions. This ensures the same packages install in every environment — local development, CI, staging, and production — eliminating version drift as a source of failures.

Dockerfile

FROM python:3.11.9-slim WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt COPY src ./src CMD ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "8000"]

What to note:

python:3.11.9-slim — The base image uses the same Python version as the platform's test-python.yml workflow. Consistency between the test environment and the container runtime eliminates an entire class of environment-specific bugs.
Dependency layer first — requirements.txt is copied and installed before application source code. This is a deliberate layer ordering decision — Docker caches the dependency layer independently, so subsequent builds only reinstall packages when requirements.txt changes, not on every code change.
0.0.0.0 — Binds the server to all network interfaces inside the container, making it reachable from outside. Combined with targetPort: 8000 in the Bicep configuration, this completes the network path from Azure Container Apps to the application.

The Release Workflow — release.yml

This is the most important file in the application repo. It is also the simplest.

name: release on: push: branches: [main] permissions: id-token: write contents: read jobs: test: uses: ns-github-design/ci-platform/.github/workflows/test-python.yml@v1 build: needs: test uses: ns-github-design/ci-platform/.github/workflows/build.yml@v1 secrets: inherit deploy-staging: needs: build uses: ns-github-design/ci-platform/.github/workflows/deploy.yml@v1 with: environment: staging image_tag: ${{ needs.build.outputs.image_tag }} app_name: my-app-staging secrets: inherit deploy-prod: needs: [build, deploy-staging] uses: ns-github-design/ci-platform/.github/workflows/deploy.yml@v1 with: environment: production image_tag: ${{ needs.build.outputs.image_tag }} app_name: my-app-prod secrets: inherit

Walking Through the Pipeline

Trigger

Every merge to main triggers a full release. This reflects a trunk-based delivery model — main is always releasable, and every commit to it initiates the path to production.

Test Job

The first job calls the platform's test workflow. No configuration required — the platform handles Python setup, dependency installation, and test execution. The application team owns the test files; the platform owns the execution environment.

Build Job

The build job runs only after tests pass. It calls the platform's build workflow and inherits all secrets automatically — Azure credentials, ACR login server, registry name — without re-declaring them.

The critical output here is image_tag — the Git SHA of the current commit. This value is captured and passed downstream to both deploy jobs.

Deploy to Staging

The staging deployment runs immediately after a successful build. It passes three inputs to the deploy workflow:

environment: staging — triggers GitHub's staging environment rules
image_tag — the exact SHA built in the previous job
app_name: my-app-staging — the target Container App in Azure

Deploy to Production

Production deployment runs only after staging succeeds. It uses the same image_tag — the identical image that just ran successfully in staging is what gets promoted to production. No rebuild. No repackaging. The artifact is immutable.

If a required reviewer is configured on the production GitHub Environment, the pipeline pauses here until approval is granted.

The Complete Pipeline at a Glance

What the Application Team Never Has to Think About

It is worth being explicit about what this model abstracts away from application engineers:

Concern	Handled By
Azure authentication	Platform (build.yml, deploy.yml)
Docker build and push	Platform (build.yml)
Image tagging strategy	Platform (build.yml)
Container App update command	Platform (deploy.yml)
Approval gate mechanics	GitHub Environments
Python version consistency	Platform (test-python.yml)

The application team's CI/CD knowledge requirement is reduced to understanding three uses statements and two with input blocks. Everything else is the platform's responsibility.

Demo — Proving It Works

Your pipeline is now live and connected across three layers:

GitHub Actions (Reusable Workflows) – powering CI/CD logic
FastAPI Application Repo – consuming those workflows
Azure Container Apps – running staging and production

Step 1 – Trigger the CI/CD Pipeline

Push any commit to the main branch:

Then open:

You’ll see the workflow release start automatically.

Step 2 – Observe the Pipeline Run

The jobs execute in sequence:

Stage	Description
test	Runs pytest inside GitHub Actions using the reusable workflow test-python.yml
build	Builds and tags a Docker image with the current Git SHA, then pushes to ACR
deploy‑staging	Deploys that same image to your Container App my-app-staging
approval gate	Waits for approval of the production environment
deploy‑prod	On approval, promotes the identical image to my-app-prod

Your final dependency chain looks like this:

(You added needs: [build, deploy-staging]—perfect for ensuring the correct ordering.)

Step 3 – Review the Logs

Every job’s output is visible inside GitHub Actions:

test – confirms tests collected successfully
build – shows docker push ... to ACR
deploy‑staging – displays Azure CLI output updating the Container App
deploy‑prod – mirrors those steps after manual approval

This transparency is part of what makes reusable workflows auditable and support enterprise compliance.

Step 4 – Verify Running Apps

After both deployments succeed, confirm each environment is live.

Staging

Production

Expected response:

(The exact commit SHA replaces "abc1234".)

This proves:

The same container image was promoted unchanged.
Both environments are consistent.
The platform’s reusable workflows handled the full delivery flow.

The Bridge: Why AI Changes Everything

Your CI/CD platform now runs like a product: build once, test once, deploy anywhere.
But software itself is shifting.
The next generation of systems doesn’t just serve requests — it reasons.

We are no longer only shipping code.
We are shipping AI agents that evolve, learn, and behave based on prompts, data, and context.

And that introduces a new set of engineering realities.

The Old Contract

Traditional CI/CD pipelines assume:

Code is deterministic
Tests define correctness
Deployments promote immutable artifacts

Those assumptions hold for APIs and microservices.

The New Reality with AI Systems

AI systems violate the core idea of “deterministic correctness.”

Characteristic	Traditional Software	AI / Agent Systems
Behavior	Deterministic	Probabilistic
Definition of success	Binary pass/fail	Continuous score
Changes	Source code edits	Prompt/model/data changes
Validation method	Unit tests	Semantic evaluation
Risks	Bugs	Hallucination / drift / bias

Prompts, fine‑tuned models, retraining data, and external tool integrations become active code paths — yet they can’t be meaningfully validated with unit tests alone.

Why This Breaks Standard CI/CD

Your current CI/CD system answers only one question:

“Did the code pass its tests?”

But for an AI agent, that’s not enough.
You also need to know:

“Did the model behave acceptably across metrics that matter?”

Without that gate, an AI update that produces worse responses could still deploy perfectly — because the pipeline has no concept of semantic quality.

The Missing Layer — Evaluation

What testing is to code, evaluation is to AI.
It separates experimental prompts from production‑ready agents.

This leads to the next maturity step:

Extend your CI/CD platform into an AI Delivery Platform — one that can evaluate, score, and gate agent behavior before deployment.

What Changes Technically

You don’t replace the CI/CD you built.
You add a new reusable workflow to the same platform:

This new workflow introduces a stage that:

Runs offline or dataset‑based evaluation scripts
Computes a confidence / quality score
Blocks deployment if performance falls below threshold

What This Means Philosophically

Build pipelines become governance systems
Platform teams now own evaluation as much as deployment
Reusable workflows become policies for AI reliability

The same architecture — reusable calls, versioned workflows, staged promotions — continues serving you, but with a new function: safeguarding machine behavior.

Evaluation as a Gate

Your reusable CI/CD system already enforces two things:

Code quality → through tests
Deployment consistency → through shared workflows

The next maturity layer is enforcing behavioral quality — ensuring an AI agent performs to a defined standard before it goes live.

That’s where evaluation pipelines come in.

The Big Shift

In conventional systems:

For AI systems:

Instead of pass/fail assertions, you now gate deployments on scores — accuracy, relevance, factuality, safety, or any quantitative prompt‑response metric.

Reusable Workflow — evaluate-agent.yml

Add this new file to your platform repository:

File content:

Example Evaluation Script — eval.py

This script executes semantic evaluation logic for your agent.

As a proof‑of‑concept, this produces a random score.
In real use, this could compute accuracy against a dataset, compare responses to a gold standard, or call an LLM‑based judge service.

Integrating the New Stage

In your AI app repo (for example, agent-app or fastapi-app once it evolves into an agent):

This creates a simple but powerful control flow:

If eval.py writes a score below 0.8, the pipeline stops immediately — deployment blocked, logs recorded, everything traceable.

Key Takeaways

Concept	Description
Reusable	Same evaluate-agent workflow can gate hundreds of models
Configurable	Each use can override thresholds or metrics
Auditable	Evaluation scores logged as build artifacts
Safe	Prevents low-performing or biased agents from promotion

Beyond Thresholds

Later, you can evolve this into:

Adaptive thresholds per metric
Human‑in‑the‑loop approvals for borderline scores
Trend tracking – scores over time via GitHub Checks or dashboards
Integration with observability platforms (Azure App Insights, Foundry evaluations, etc.)

AI Delivery Pipeline + Foundry Integration

So far, you have:

A unified CI/CD platform powered by reusable GitHub Actions
Evaluation pipelines that gate AI deployments

Now we expand that architecture into a complete AI Delivery Platform by integrating with Microsoft Foundry.

The Goal

Combine:

GitHub Actions ↔ Foundry for seamless build‑evaluate‑deploy cycles
Reusable workflows for policies + governance
Foundry runtime for execution, scaling, and observability of agents

This transforms your CI/CD system into a behavior‑driven deployment layer for AI.

Conceptual Flow

Reusable CI/CD Workflows + Foundry Runtime

Your existing ci-platform repo now gains a fourth reusable workflow:

Each of these maps to a Foundry capability:

Workflow	Foundry Capability	Role
build.yml	Model packaging & versioning	Creates deployable image
evaluate-agent.yml	Evaluation service	Runs offline or dataset‑based checks
deploy.yml	Agent deployment	Publishes agent to Foundry runtime
(Additional) monitor.yml	Telemetry	Pulls evaluation metrics post‑deploy

Example Foundry‑Aware Pipeline

In an AI repository (e.g., agent-app):

This sequence guarantees that only successfully evaluated agent versions are deployed to Foundry.

How Foundry Fits In

Microsoft Foundry provides:

Agent runtime — scalable, managed environment for composable agents
Evaluation tools — integrate LLM‑as‑judge, dataset scoring, or automatic benchmarks
Observability layers — performance metrics, feedback loops, and telemetry
Orchestration frameworks — connect multiple tools or sub‑agents into an ecosystem

GitHub Actions handles delivery logic.
Foundry handles AI execution and lifecycle.

Together, they form a modular operations stack for AI systems.

Benefits of Integration

Benefit	Description
Governed Deployments	Only evaluated and approved agent versions reach Foundry
Traceability	Every deployed agent is linked to a Git commit and eval score
Reproducibility	Re‑running pipeline with the same commit reproduces identical behavior
Observability	Foundry telemetry pushes real‑world feedback back into the platform repo

Architecture View

Governance in Practice

Every deployment is evaluated before release.
Every evaluation is logged as metadata in the Actions run.
Foundry stores live metrics that can trigger automated re‑evaluation workflows downstream.

This unifies the DevOps and MLOps worlds under one pipeline.

Advanced Practices

Integrating evaluation and Foundry is the foundation. True enterprise reliability comes from how you operate and evolve those pipelines over time. Below are the main practices that transform this setup from “it works” to “it scales safely.”

1. Prompt Versioning

In AI systems, prompts are code.

A single word change in a prompt can shift an agent’s behavior as much as a logic rewrite does in software. Treat them accordingly:

Store prompts and configurations in git (/prompts/prompt_v1.txt, prompt_v2.txt).
Use clear change history — commits = versions.
Reference prompt versions explicitly in deployment metadata:

Re-runs of an old version must reproduce identical responses; versioned prompts make that possible.

2. Experiment Tracking

Track every experiment like you track every deployment.

Item	Example Format
Commit SHA	f9a3c2a
Prompt version	prompt_v3
Model checkpoint	gpt‑35‑turbo 2024‑06‑01
Dataset revision	dataset_v2
Evaluation score	0.87

Implementation tips:

Write a short artifact file (experiment.json) in each pipeline run.
Store it as a workflow artifact or upload it to an experiment tracker (MLflow, Azure ML Experiments, Foundry History).
You can later analyze how prompt or model changes affect score trends.

This allows data‑driven improvement cycles: evaluate → compare → promote → monitor.

3. Rollback Strategies

For deterministic software:

Rollback = redeploy previous container.

For AI systems you may need to rollback three dimensions:

Dimension	Example Rollback
Code	Checkout previous commit
Prompt	Revert to earlier prompt file
Model	Reuse prior checkpoint or model ID

Best practice: treat each version triple (code, prompt, model) as one immutable release unit in the pipeline.
GitHub tags + evaluation artifacts = auditable rollback point.

4. Continuous Evaluation

Evaluation shouldn’t stop at deployment.
Integrate post‑deployment monitoring jobs to detect drift:

Benefits:

Detects silent performance drops caused by new data or model API changes.
Keeps models aligned with their initial standards.
Creates long‑term confidence for compliance audits.

5. Fail Fast, Fail Safe

Configure pipelines such that failure to evaluate = failure to deploy.

When in doubt, err on protection.
Failures should be logged, retriable, and transparent — never silent.

This approach builds institutional trust in AI releases the same way software regression testing built trust in traditional CI/CD.

6. Governance by Design

Use GitHub’s native features (branch protections, required reviews, environment rules) as declarative governance.
Combine them with Foundry’s policy hooks:

restrict which teams can promote evaluated agents;
enforce minimum score thresholds;
auto‑disable underperforming models.

Governance embedded in code scales better than manual review boards.

7. Platform Observability

Push run data into dashboards. Correlate:

GitHub Actions runs
Evaluation scores
Production telemetry from Foundry

Visualization options: Azure Monitor, Power BI, Grafana.
Aim for a CI/CD + AI Ops Console view — one pane to observe quality, reliability, and speed.

Outcome of These Practices

Your organization achieves:

Consistency across microservices and AI systems
Accountability through versioned artifacts
Safety via evaluation gates and drift monitors
Agility because updates remain fast, but protected

Enterprise Scenarios

By this point, you’ve built an end‑to‑end platform:

standardized CI/CD for apps and agents,
reusable GitHub Actions workflows,
Azure runtime for reliable deployments,
Foundry‑integrated evaluation gates.

Now let’s see how this architecture performs in the wild.

Scenario 1 — Fifty Microservices, One Consistent Pipeline

Problem Statement

At scale, each microservice team usually maintains a slightly different workflow — fragmented test tools, drift in Python or Node versions, duplicated YAML.

What Goes Wrong

Compliance updates require 50 PRs.
Each team solves build problems differently.
Security teams can’t easily prove consistency.

Platform Solution

The ci-platform repo defines all workflows once (test‑python.yml, build.yml, deploy.yml).
Every service just calls them through uses:.
Upgrading the base image or CI version happens once and propagates to all services.

Result

Full organization upgrade from Python 3.10→3.11 in minutes.
Consistent quality gates, policies, and artifact naming.
Reduced cycle time, increased deployment confidence.

Scenario 2 — Regulated Enterprises (Compliance + Audit)

Problem Statement

Financial, healthcare, and government projects require strict controls:

Auditable promotion paths
Approval workflows
Traceability of versions and changes

What Goes Wrong

Manual change reviews are error‑prone.
Different CI/CD definitions per team produce inconsistent logs.
Compliance reports take weeks.

Platform Solution

GitHub Environments provide built‑in approvals and reviewer rules.
The same reusable workflows ensure identical build signatures.
Foundry integration logs evaluation scores and deployment metadata automatically.

Result

Reviewers approve through GitHub’s Environment gate — zero custom UI needed.
Each release carries an immutable commit ID + evaluation score + approvers record.
Audit reports generate directly from pipeline history.

Scenario 3 — AI‑Driven Customer Support Platform

Problem Statement

A company running customer support agents (GPT‑powered) wants to continuously improve responses but without risking live quality drops.

What Goes Wrong

Prompt changes can silently worsen accuracy.
Model updates impact intent coverage.
Hard to correlate user feedback with deployment versions.

Platform Solution

Add evaluate-agent.yml into the same CI/CD chain.
Feed evaluation datasets that cover FAQs and tone guidelines.
Require minimum score ≥ 0.85 for promotion.
Deploy via Foundry to production clusters once threshold met.
Stream Foundry telemetry → GitHub → Power BI for quality dashboards.

Result

Continuous prompt experimentation without sacrificing quality.
Regressed builds automatically blocked.
Business stakeholders track AI accuracy as a live metric.

Bonus Scenario — Enterprise AI R&D Platform

Multiple research teams train models on‑prem or in Azure ML. The central engineering platform exposes build, evaluate, deploy steps as reusable workflows.

Data scientists → run “evaluate‑agent” without touching infra.
Platform engineers → control policies, thresholds, approvals.
Leadership → gets consistent reporting on AI performance and cost.

This creates a single standard for AI lifecycle governance across business units.

Summary

Your platform now supports:

Area	Traditional Dev	AI Adaptation
Build & Test	Reusable workflows (Services)	Evaluation gate (Agents)
Deploy	Container Apps / GitHub Environments	Foundry + Telemetry Feedback
Governance	Environment approval rules	Evaluation threshold + human review
Scaling	One repo per service	One platform per organization

Across these cases, the core pattern holds:
Centralize workflow logic, decentralize application logic, unify governance.

14 — Conclusion

What began as a simple effort to clean up a few duplicated YAML files evolved into a complete delivery platform architecture — one that treats pipelines as first‑class products and extends their usefulness into the era of AI‑driven systems.

From Pipelines to Platforms

At first, you built reusable workflows in a shared repository.
That small structural change produced an outsized effect:

Reduced maintenance and drift
Consistent security and compliance
One‑click upgrades across every service

You proved that pipeline logic belongs in its own product — a CI/CD platform.

From Deterministic to Intelligent Delivery

Then the domain changed. Deterministic services gave way to AI agents. 
You responded by extending the same reusable platform into the AI dimension:

Added evaluate-agent.yml for semantic scoring
Introduced Foundry as the runtime for intelligent components
Unified evaluation, governance, and deployment under the same contracts

The underlying philosophy remained identical: don’t duplicate delivery logic — standardize it.

The Broader Pattern

This architecture expresses a clear maturity pathway:

Stage	What Changes	Technical Lever
CI/CD as Automation	Build pipelines per project	YAML and Actions
CI/CD as Product	Reusable workflows, shared logic	Platform Repo
CI/CD as Governance	Environments, approvals, tracking	GitHub Environments + Azure
AI Delivery Platform	Evaluation + behavioral policy	Foundry Integration

Every step adds structure, traceability, and scale, without sacrificing developer velocity.

Cultural Impact

Moving to a platform model does more than streamline releases.
It elevates DevOps to a product discipline:

Platform engineers design contracts, not scripts.
Application teams consume delivery APIs, not ad‑hoc builds.
AI teams get reliable evaluation and rollback mechanisms.

In short: velocity meets governance.

The Next Frontier

As this pattern matures, two frontiers are emerging:

Autonomous Evaluation — Agents that assess other agents in continuous feedback loops.
Dynamic Policy Enforcement — Pipelines that adjust deployment thresholds and configurations in real time based on observed performance.

The foundations you’ve built — centralized workflows, evaluation gates, and Foundry integration — already support that trajectory.

CI/CD maturity is not about writing workflows; it’s about designing reusable systems of workflows.

What you’ve built is more than CI/CD. It’s a platform that defines how modern software and AI move from idea to production safely.

Next we’ll close the series with a brief “What’s Next” section — outlining concrete next steps for building upon this foundation. Continue?

go ahead

Here’s the final piece — Section 15 — What’s Next, which closes the series with momentum and a clear roadmap for readers who want to replicate or extend what you’ve built.

15 — What’s Next

You’ve gone from writing pipelines to designing platforms.
The CI/CD model you created now governs the lifecycle of both microservices and AI agents — and it’s only the beginning.

Step 1 — Publish Your Platform

Make both repositories public (read‑only) so others can learn from the pattern:
- ns-github-design/ci-platform – your reusable workflow product
- ns-github-design/fastapi-app – your minimal consumer example
Tag the current stable version as v1.0 in both repos.
Add concise READMEs explaining purpose, usage, and version policy.

This turns your repos into live documentation — a working reference architecture.

Step 2 — Add Automated Docs and Visuals

Export your Draw.io architecture to SVG and embed it in each README.
Use GitHub Pages or Docsify to render a small site explaining:
- platform repo overview;
- how workflow_call works;
- how to set up Azure auth;
- example runs and outputs.

Readers love code + architecture in one place.

Step 3 — Extend to AI Agents

Add a third demo:
agent-evaluator — a lightweight agent that runs eval.py and demonstrates the evaluation gate.

In that repo:

Call evaluate-agent.yml from your platform.
Push commits that sometimes fail thresholds.
Show screenshots of blocked vs. approved runs.

You’ll have a fully working AI evaluation demo powered by your platform.

Step 4 — Instrument Foundry Feedback

Use Foundry’s APIs to stream live evaluation results or observability data back into GitHub Actions artifacts:

yaml

- name: Collect Foundry feedback run: foundry metrics export --project my-ai-agent --output metrics.json

That feedback loop will let you build dashboards of quality trends alongside deployment timeline.

Step 5 — Prepare Part 3 (Next Blog)

You now have a natural foundation for the next article:

“Autonomous Delivery Loops: Continuous Evaluation and Guardrails for AI Agents.”

Outline:

Continuous evaluation with scheduled runs
Self‑healing approval flows
Dynamic policy adjustment based on metrics
Cross‑team Governance as Code

That installment makes your series visionary and future‑ready.

Quick Recap

Phase	Achievement
1 – 4	Built CI/CD Platform + App Repo
5	Configured Azure + OIDC
6	Verified Pipeline End‑to‑End
8 – 15	Documented Demo → AI Integration → Enterprise Practices → Vision

You now have a complete blog series that is:

technically deep,
architecturally unique,
demonstrably real.

Every diagram, YAML, and code sample came from a working, reproducible system — the hallmark of strong engineering writing.

Final Thought

Software delivery used to end at deployment.
AI delivery begins there.

The future of platforms is not just to ship software faster — but to ensure that every agent behaves as designed.

From Toil to Trust: How Azure SRE Agent Is Redefining Cloud Operations

siddhigupta — Sat, 11 Apr 2026 05:36:05 GMT

As Azure environments scale, infrastructure teams face a familiar challenge: operating reliably at scale.
Outages are no longer caused by a single VM or misconfigured service—they emerge from complex dependencies across compute, networking, storage, and platform services.

Azure SRE Agent is designed to help infrastructure and SRE teams meet this challenge by bringing AI‑assisted diagnostics and remediation directly into Azure operations.

This post focuses on:

Infrastructure‑centric scenarios where Azure SRE Agent is most useful
How infra teams can access it from the Azure portal
Prerequisites required before onboarding

What Is Azure SRE Agent (From an Infrastructure Lens)

Azure SRE Agent is an AI‑powered reliability assistant integrated into Azure.
It continuously observes telemetry from Azure Monitor, Log Analytics, and service APIs to help engineers diagnose, investigate, and remediate production issues.

From an infrastructure standpoint, the agent understands:

Azure resource topology and dependencies
Common failure patterns across Azure services
Safe operational actions using Azure CLI and REST APIs

It can either recommend actions or execute remediation steps with appropriate guardrails and approvals.

The agent operates through multiple automation mechanisms, including:

Built-in Azure knowledge: Preconfigured understanding of Azure services with optimized operational patterns
Custom runbooks: Execute Azure CLI commands, and REST API calls for any Azure service
Subagent extensibility: Build specialized agents for specific services like VMs, databases, or networking components
External integrations: Connect to monitoring, incident management, and source control systems

Infrastructure Scenarios Where Azure SRE Agent Helps the Most

1. Incident Investigation & Production Outages

During an incident, infra engineers typically pivot between alerts, metrics, logs, and dashboards. Azure SRE Agent simplifies this by correlating telemetry automatically and summarizing the issue in natural language.

Typical infrastructure issues:

Virtual machines becoming unresponsive
App Service or Container App failures
Network connectivity or NSG misconfigurations
Storage throttling or capacity exhaustion

Instead of manually querying logs, engineers can ask the agent why something failed and get a reasoned response.

2. Log and Metric Driven Root Cause Analysis

Azure SRE Agent consumes Azure Monitor and Log Analytics data directly.
This allows it to perform context‑aware RCA without engineers needing to manually write KQL for common scenarios.

Example question:

“Why did my App Service start returning HTTP 500 errors after the last deployment?”

The agent correlates deployment activity, configuration changes, and telemetry to identify the most likely root cause.

3. Safe, Controlled Remediation for Infrastructure Issues

A key value for infra teams is controlled automation.

Azure SRE Agent supports:

Review mode – actions are proposed and require explicit approval
Autonomous mode – pre‑approved sub‑agents execute actions automatically

This is useful for repeatable infra tasks such as:

Restarting unhealthy services
Scaling compute resources
Rolling back failed deployments
Correcting known configuration drift

Automation is applied with guardrails, not blindly.

4. Infrastructure Guardrails & Operational Hygiene

Beyond incidents, Azure SRE Agent can continuously evaluate infrastructure posture and highlight operational risks.

Examples include:

Detecting insecure network exposure
Flagging unsupported SKUs or configurations
Identifying operational anti‑patterns

This helps infra teams move from reactive firefighting to proactive reliability management.

5. Extending Infrastructure Automation with Subagents

Infrastructure teams can extend Azure SRE Agent using subagents tailored to specific domains such as networking, databases, or storage.

Using the Subagent Builder, teams can:

Attach custom runbooks
Integrate external observability tools
Trigger actions on alerts or schedules

This enables gradual adoption—from advisory assistance to advanced automation.

How to Get Started with Azure SRE Agent

The following sections outline the prerequisites, connectivity considerations, and supported integrations required to onboard Azure SRE Agent in an enterprise Azure environment.

Prerequisites and Ownership Model

Azure SRE Agent introduces platform‑level prerequisites that span infrastructure, platform, security, and network teams. While infrastructure teams are the primary users, successful onboarding requires cross‑team alignment.

The sections below explicitly tag ownership for clarity.

1. Subscription & Region

Owner: Platform / Subscription Admin

Dedicated Azure subscription or resource group recommended for evaluation or PoC
During preview, the agent control plane must be created in an available location (Sweden Central, Australia East, US East 2), while monitored workloads can reside in any Azure region
Subscription may need to be allow‑listed for access

Infra teams typically request this setup; platform teams implement it.

2. Identity & Access (Critical)

Owner: Platform + Security
Consumer: Infra / SRE

Ability to create managed identities (system‑assigned or user‑assigned depending on scenario)
Elevated RBAC permissions required during onboarding:
- Microsoft.Authorization/roleAssignments/write at subscription scope
- Roles such as Owner, User Access Administrator, or RBAC Administrator
Post‑onboarding, the SRE Agent identity should be granted least‑privilege RBAC:
- Read‑only for investigation scenarios
- Scoped write access only where remediation is approved

Infra teams use the identity; security and platform teams govern access.

3. Resource Provider Registration

Owner: Platform

Required Azure resource providers must be registered in the subscription
Includes providers used by the agent runtime and dependent services

Typically, a one‑time platform task.

4. Monitoring & Telemetry Baseline (Hard Dependency)

Owner: Infra / Platform (Shared)

Azure Monitor enabled for target workloads
Diagnostic settings configured to send logs and metrics to:
- Log Analytics
- Application Insights (where applicable)
During agent creation, supporting resources may be deployed:
- Log Analytics workspace
- Application Insights
- Smart detector alert rules

Infra teams depend on this telemetry; platform teams often provide the shared foundation.

5. Network & Connectivity

Owner: Network / Security

Outbound HTTPS connectivity required to:
- Azure management endpoints (ARM, Monitor, etc.)
- External systems when integrations are enabled (for example, ServiceNow or MCP servers)
Custom MCP endpoints must be remote and HTTPS‑reachable (local endpoints not supported)
IP allow‑listing scenarios must be explicitly validated; static egress IPs are not guaranteed

Required only if the organization enforces strict network controls.

6. Connector‑Specific Prerequisites (Conditional)

Owner: Security + Platform
Consumer: Infra / SRE

Microsoft Teams / Outlook connectors
- OAuth consent for Microsoft 365 APIs
- User‑assigned managed identity required for connector authentication
Custom MCP connectors
- MCP base URL
- Authentication material (API key, token, or OAuth)
- RBAC permissions to configure and manage connectors

Applies only when integrations are enabled.

7. Automation Readiness

Owner: Infra / SRE + Security

Clear decision on recommendation‑only vs automated remediation
Defined approval model:
- Human‑in‑the‑loop
- Scoped autonomy for well‑understood actions
Agent identity granted write permissions only where automation is explicitly approved

Infra teams define operational intent; security teams validate boundaries.

8. Governance & Data Handling

Owner: Security / Governance

Acceptance that prompts, responses, and analysis data are stored in the agent’s region
Alignment with organizational policies for:
- Logging and retention
- Auditability
- Responsible AI usage and approvals

This is a governance prerequisite, not an infra task.

Azure SRE Agent operates as a managed control plane layered on Azure Resource Manager, Azure Monitor, Log Analytics, and managed identities. As a result, identity, telemetry, and governance foundations must be in place before infra teams can fully benefit from the agent.

Integration It Supports

Azure SRE Agent integrates with your operational ecosystem in the following ways:

Monitoring and observability:
- Azure Monitor (metrics, logs, alerts, workbooks)
- Application Insights
- Log Analytics
- Grafana
Incident management:
- Azure Monitor Alerts
- PagerDuty
- ServiceNow
Source control and CI/CD:
- GitHub (repositories, issues)
- Azure DevOps (repos, work items)
Data sources:
- Azure Data Explorer (Kusto) clusters
- Model Context Protocol (MCP) servers

Connectivity Matrix

1. Azure Control Plane Connectivity

Source	Destination	Direction	Protocol / Port	Authentication	Purpose
SRE Agent service	Azure Resource Manager (ARM)	Outbound	HTTPS / 443	Managed Identity (OAuth 2.0)	Read and (with approval) write operations on Azure resources.
SRE Agent service	Azure Monitor	Outbound	HTTPS / 443	Managed Identity	Alert ingestion and metric queries.
SRE Agent service	Log Analytics Workspace	Outbound	HTTPS / 443	Managed Identity	Log queries (KQL) for RCA.
SRE Agent service	Application Insights	Outbound	HTTPS / 443	Managed Identity	Application telemetry analysis.

All Azure control‑plane communication is outbound only from the agent.
No inbound connectivity to customer VNets is required.

2. Incident Management Integrations

Platform	Connectivity Type	Direction	Protocol / Port	Auth Mechanism	Data Exchanged
Azure Monitor Alerts	Native	Inbound → Agent	HTTPS / 443	Azure‑native	Alert payloads, severity, metadata
ServiceNow	Connector (Webhook/API)	Outbound & Inbound	HTTPS / 443	OAuth / API token	Incident creation, updates, status sync
PagerDuty	Connector (Webhook/API)	Outbound & Inbound	HTTPS / 443	OAuth / API token	Incident events, acknowledgements

Third‑party platforms require explicit connector configuration.
Payloads are limited to incident metadata and diagnostics context.

3. Collaboration & Notification Channels

Tool	Direction	Protocol / Port	Authentication	Typical Usage
Microsoft Teams	Outbound	HTTPS / 443	OAuth (User‑assigned Managed Identity)	Post incident summaries, updates
Outlook (Email)	Outbound	HTTPS / 443	OAuth (User‑assigned Managed Identity)	Incident notifications, reports

Only user‑assigned managed identities are supported for Office 365 connectors.
No mailbox‑level permissions are stored in the agent.

4. External & Custom Integrations

Integration Type	Direction	Protocol / Port	Auth	Example Use Cases
Custom MCP Servers	Outbound	HTTPS / 443	OAuth / API key	GitHub issues, Dynatrace, custom observability
Python Execution Tool	Outbound	HTTPS / 443	As defined by script	REST checks, custom diagnostics

Endpoints must be explicitly configured and approved.
Secrets do not persist; credentials are injected securely at runtime.

5. Firewall & Network Considerations

Add *.azuresre.ai to your firewall allow list. Some networking profiles might block access to this domain by default.
Allow outbound HTTPS (443) to:
- Azure control‑plane endpoints
- *.azuresre.ai (SRE Agent service)
- Configured third‑party endpoints (ServiceNow, PagerDuty, MCP servers)
No inbound firewall rules or private endpoint exposure is required.
Compatible with private VNets and restricted outbound models when allow‑listed.

How to Access Azure SRE Agent

Azure SRE Agent can be accessed directly from the Azure portal or via its own SRE portal.

Adding few screenshots below:

Via Azure PortalUsing it URL

Relatable links:

Check how to use SRE agent, here.
Understand how to automate workflow, here.
Perform Azure environment diagnosis using SRE agent, here.
Check about connectors used to extend reach to external system, here.
To setup your first investigation, here.
Learn about its pricing and billing, here.
Check how to manage permissions for SRE agent, here.
To setup the MCP connectors in SRE agent, here.
Anthropic as a sub-processor in Azure SRE Agent

Why Azure SRE Agent Matters for Infrastructure Teams

For infrastructure and SRE teams managing large Azure estates, Azure SRE Agent provides a single, agentic reliability layer that unifies observability, incident management, and delivery workflows into a governed, intent‑driven operating model.

Reduced Mean Time to Resolution (MTTR): By integrating natively with Azure Monitor and Log Analytics, the agent performs deep, multi‑signal investigation and root‑cause analysis without manual query building or correlation.
Faster investigation without dashboard hopping: Azure SRE Agent reasons across monitoring, incident, and delivery systems from one interface, eliminating context‑switching across tools.
Deep investigation & root-cause analysis: Performs multi‑signal correlation across logs, metrics, configuration state, and recent changes to identify true root causes rather than surface symptoms, with clear, explainable findings.
Lower operational toil: Repetitive diagnostics and triage tasks are handled by the agent, allowing engineers to focus on higher‑value reliability and platform improvements.
Consistent and auditable incident response: Through Azure Monitor, ServiceNow and PagerDuty integration, investigations are embedded directly into ITSM and on‑call workflows, ensuring traceability, consistency, and governance.
Scheduled tasks and proactive checks: Using scheduled workflows, teams can run daily or periodic health validations, drift checks, and post‑deployment verifications—shifting operations from reactive firefighting to proactive reliability management.
Extensible sub‑agents and skills: Infrastructure teams can create skills, subagents, and workflows to encode domain expertise into the agent, making reliability knowledge reusable and consistent.
Delivery and code awareness: Integration with GitHub and Azure DevOps allows the agent to correlate infrastructure issues with source code, IaC definitions, pipelines, and work items—enabling actionable follow‑ups such as bug creation, PR recommendations, or release fixes.
Safer, governed automation: Human‑in‑the‑loop controls ensure all recommendations and actions are auditable, reviewable, and aligned with enterprise governance, enabling progressive automation without compromising safety.
Better reliability at infrastructure scale: By shifting teams from manual diagnostics to intent‑driven, agent‑assisted operations, Azure SRE Agent helps organizations move from reactive firefighting to systematic, scalable reliability engineering.

It shifts teams from manual diagnostics to intent‑driven operations.

Closing Thoughts

Azure SRE Agent is not just another troubleshooting tool—it represents a shift toward agent‑assisted infrastructure operations. By embedding AI‑driven reasoning directly into Azure, infrastructure teams can focus less on repetitive investigation and more on building resilient platforms.