Weekly Azure Roundup: AKS Policy, Agents, Security, and Fabric

by TechHub

Welcome to this week's Weekly Azure Roundup, where the theme is tightening the path from prototype to production across governance, security, and operations. AKS governance takes a Kubernetes-native step forward with CEL and Validating Admission Policy support, while networking and protection updates add practical controls like IPv6 for VPN Gateway and custom DDoS policy tuning. On the platform side, Azure Functions runtime updates and a large-scale migration case study highlight what it takes to keep serverless estates current under live load, and the agent stack continues to fill in with Foundry design tooling, delegated auth, a released Agent Framework runtime, and GA observability in Azure Monitor. We also cover new AI model options, expanding HPC capacity, and data streaming and network controls across Azure SQL and Fabric, plus hybrid updates spanning Azure Local storage and Logic Apps Hybrid on self-managed Kubernetes.

This Week's Overview

Kubernetes governance and secure connectivity updates

Azure Policy for Kubernetes adds CEL + VAP validation

Building on last week's broader theme of making “agent-ready” and operations-ready patterns more governable at scale, Azure Policy for Kubernetes now supports a Kubernetes-native path for admission control by integrating Gatekeeper with Kubernetes Validating Admission Policy (VAP) using CEL (Common Expression Language). The practical change is that policy checks can run in-process at admission time on AKS, while Azure Policy still handles assignment, rollout control, and compliance reporting across clusters.

For platform teams, this can reduce the operational overhead of managing separate webhook-based validators and align enforcement with upstream Kubernetes capabilities. The walkthrough shows how to package a CEL constraint template into an Azure Policy definition and then deploy it consistently across many AKS clusters, keeping policy-as-code and compliance tracking in one place.

AKS-to-Azure Files NFS encryption and IPv6 for VPN Gateway

In the same spirit as last week's focus on tightening operational baselines (from network posture guidance to resiliency patterns), this week's Azure update highlighted encryption support for AKS mounting Azure Files over NFS, closing a gap for teams that rely on NFS semantics but still need stronger data-in-transit protections. It is a concrete improvement for clusters that use Azure Files NFS for shared storage and want to tighten compliance without redesigning the storage layer.

On the networking side, Azure VPN Gateway gaining IPv6 support is another incremental but important step for organizations modernizing address plans or integrating with IPv6-first environments. Combined, these changes move AKS and core connectivity closer to the baseline expectations enterprises already have for encryption and dual-stack networking.

DDoS protection and cloud security posture tuning

Azure networking and security updates this week centered on getting more control over protection behavior without losing platform-managed telemetry and workflows.

Azure DDoS Protection custom policy (public preview)

Azure DDoS Protection custom policy entered public preview, adding per-resource tuning of detection thresholds with protocol-specific controls for TCP, UDP, and TCP SYN. The key benefit is that you can adjust sensitivity for workloads that do not fit default thresholds (for example, bursty traffic patterns) while still using Azure Monitor integrations and DDoS telemetry.

There are real preview constraints to plan around: configuration currently targets Standard Load Balancer frontend IPs, and the blog calls out that PowerShell is not supported yet. Deployment options include ARM and REST API, with portal-based setup steps outlined for getting started in the preview scope.

Defender assessments for PostgreSQL Flexible Server

Building on last week's “defense-in-depth is not one switch” message (for example, the Service Bus network posture guidance), Microsoft Defender for Cloud is extending assessment coverage for PostgreSQL Flexible Server, surfacing more security recommendations directly in the posture management workflow. For teams running managed Postgres, this means fewer blind spots between database configuration, policy expectations, and the reporting that security stakeholders rely on.

If you already gate deployments on Defender recommendations or export findings into a central SIEM/SOAR pipeline, the added assessments can change what “compliant” means for existing servers. Expect to review new recommendations and update exemptions, remediation playbooks, and baseline templates accordingly.

Azure Functions: runtimes moving forward and lessons from a large migration

Runtime updates: PowerShell 7.6 and Python 3.14

Azure Functions runtime updates called out in John Savill's weekly roundup include support moving forward for PowerShell 7.6 and Python 3.14. For serverless teams, runtime currency is not just about features, it affects security patching cadence, dependency compatibility, and how long you can stay on supported language versions without last-minute rewrites.

If you maintain Functions apps across multiple stacks, this is a good time to review your runtime baselines and CI test matrices so upgrades are routine rather than disruptive. It is especially relevant for organizations standardizing on isolated worker models and trying to keep language runtimes aligned across environments.

Logic Apps migrates ~60,000 Functions apps under live load

Following last week's Logic Apps focus on packaging code with workflows and supporting hybrid deployments, a case study from the Azure Logic Apps team described migrating roughly 60,000 per-customer Azure Functions apps from deprecated v1/v2 runtimes to Functions v4 (isolated worker) while under live traffic. The approach relied on full-traffic shadowing, parity gating (only progressing when behavior matched), and a progressive rollout strategy with fast rollback based on hashing.

For engineers planning high-risk platform migrations, the techniques are the takeaway: build a shadow pipeline that sees real traffic, define measurable parity checks, and gate rollout on evidence rather than time. The write-up is also a reminder that runtime deprecations can become large operational projects, so investing early in migration tooling and rollback design pays off.

Agents on Azure: building, authenticating, observing, and shipping

This week had several related updates across Azure AI Foundry, GitHub Copilot, and Azure Monitor that together fill in more of the “production agent” toolchain: design, delegated access, runtime building blocks, and operational visibility.

Foundry Agent Canvas in the GitHub Copilot App (public preview)

Following last week's Foundry GA push toward hosted agents and shipping paths into Microsoft 365, Foundry Agent Canvas is now in public preview as a GitHub Copilot App extension that provides a visual canvas to scaffold and configure Foundry hosted agents. It also supports local testing using an Agent Inspector (running on port 8088) and deployment to Foundry Agent Service using Azure Developer CLI (azd) commands.

This matters if your workflow starts in GitHub and you want a tighter loop between prototyping and deployment without stitching together a custom UI or internal scaffolding scripts. The preview positions the canvas as a bridge between “agent design” artifacts and repeatable deployments that fit existing repo-based engineering practices.

Toolboxes in Foundry: delegated auth for MCP tools

Building on last week's emphasis on governed tool surfaces (MCP) and operational controls in Agent Framework skills, Azure AI Foundry introduced Toolboxes to centralize authentication and user delegation for MCP (Model Context Protocol) tools, so agents can call tools using the signed-in user's identity without embedding token handling and consent flows into agent code. The post calls out OAuth 2.0 user delegation patterns (including Entra On-Behalf-Of) and pairs them with governance features like responsible AI (RAI) guardrails and gateway fronting.

For teams building agentic apps that touch production systems, this shifts authentication from “every agent implements auth correctly” to a reusable platform primitive. It can also simplify audits because access mediation, tool registration, and guardrails live in one place instead of being scattered across codebases.

Microsoft Agent Framework Harness (released)

As a direct follow-on to last week's scaling and harness-based guidance in Agent Framework, the Microsoft Agent Framework Harness is now released, providing a batteries-included runtime for building agents in both .NET and Python. It includes planning, tool-calling, memory, approvals, web search, and OpenTelemetry hooks, which helps standardize common agent capabilities instead of re-implementing them per project.

If you are already using Microsoft.Extensions.AI or building on Azure AI Foundry, the harness can be a pragmatic starting point for production scaffolding. The OpenTelemetry support is particularly useful because it aligns agent execution with the same observability pipelines you use for other services.

Azure Copilot Observability Agent in Azure Monitor (GA)

Continuing last week's expansion of agentic operations in Azure Monitor (including the SRE Agent GA and Observability Agent autonomy preview), Azure Monitor now includes the Azure Copilot Observability Agent as a GA capability, focused on investigating Azure AI Foundry and other GenAI agent workloads through Application Insights telemetry. The agent is positioned to help diagnose failures and performance issues like latency, throttling, token spikes, and dependency problems across Azure services that your agent relies on.

This is most relevant for teams that already instrument agent backends but struggle to turn raw traces and metrics into a coherent incident narrative. If you operate agents with hard latency budgets or volatile token usage, expect this to influence how you set up dashboards, alerts, and runbooks around AI-specific signals.

Agent governance guidance: “Path to Production for Agents” webinar series

In line with last week's recurring thread of moving from demos to operable, governed systems (cost controls, tracing, approval gates, and least privilege), Microsoft also promoted an upcoming “Path to Production for Agents” webinar series (July 27-28) that focuses on production concerns like governance, landing zone design on Azure, multi-agent architectures, AgentOps deployment and observability, and security practices. If your organization is moving beyond prototypes, the agenda maps well to the real blockers: identity, policy, operations, and safe-by-default deployment patterns.

Even if you cannot attend live, the topics are a useful checklist for gaps in your current approach, especially around multi-agent coordination and operational ownership. Pair it with the new Toolboxes and observability updates for a clearer picture of Microsoft's intended reference stack.

Azure AI models and infrastructure: more options for regulated and large-scale workloads

MAI-Image-2.5-Pro and MAI-Voice-2-Flash (public preview)

Building on last week's Foundry model and Voice Live API momentum, Microsoft announced MAI-Image-2.5-Pro and MAI-Voice-2-Flash in public preview, including pricing and performance positioning, and pointed to existing production usage across Microsoft products and Azure experiences (including Azure Voice Live and Dynamics 365 Contact Center). For builders, the practical question is whether these models fit cost, latency, and quality requirements better than existing image and voice options already available through Azure AI Foundry.

Because the models are in preview, plan for constraints around regional availability, quotas, and API surface changes. Still, it is another signal that Microsoft is broadening first-party model choices alongside third-party offerings.

Microsoft and Mistral expand partnership for controllable deployments

Echoing last week's focus on data zones and Azure Local options for running Foundry closer to where data lives, Microsoft and Mistral expanded their partnership to bring Mistral Medium 3.5 and Mistral OCR 4 into Microsoft AI Foundry, with explicit emphasis on deployments across Azure, Azure Local, and fully disconnected environments for regulated industries. The packaging matters as much as the models: offering Azure Local and disconnected scenarios supports data residency and operational constraints that common hosted-only deployments cannot meet.

The announcement also referenced Europe-focused GPU capacity expansion using NVIDIA Vera Rubin systems, pointing to continued investment in regional capacity planning. If you operate in regulated environments, the combination of model availability plus deployment topology options is the more actionable part of the news.

Azure expands AI and HPC infrastructure with AMD

As a continuation of last week's “cost and capacity reality” thread for production agents (model routing, caching, and token economics), Microsoft announced expanded Azure AI and HPC infrastructure with AMD, including upcoming HDv2 and HXv2 VM families and the ND MI455X v7 VM aimed at production-scale AI inference and agentic workloads. The details signal continued diversification of GPU and HPC offerings, with AMD EPYC and InfiniBand called out for performance characteristics that matter in tightly coupled workloads.

For teams planning capacity, price-performance comparisons, or vendor diversity, these new families are a reminder to revisit instance selection and scaling assumptions. They also intersect with Foundry-managed compute patterns, where the underlying GPU mix can influence throughput and cost per token.

Data platforms and streaming patterns across Azure SQL and Fabric

Change Event Streaming (CES) preview across SQL Server 2025, Azure SQL, and Fabric SQL

Building on last week's SQL roundup that highlighted embeddings and MCP support showing up in mainstream tooling, Change Event Streaming (CES) is in public preview across the Microsoft SQL estate, including SQL database in Fabric, Azure SQL, and SQL Server 2025. The Data Exposed episode positions CES relative to existing patterns like Change Data Capture (CDC) and mirroring, which helps teams choose the right tool depending on latency needs, operational complexity, and downstream consumers.

If you are building event-driven architectures off relational data, CES could reduce glue code compared to hand-rolled CDC pipelines, but you will want to validate semantics and operational behavior during preview. This is particularly relevant for teams standardizing on streaming into Fabric or other analytics layers while keeping transactional systems stable.

Streaming enrichment with Fabric Eventstreams, Spark, and AI Functions

A Fabric-focused guide described an end-to-end pattern for turning operational cart events into real-time, AI-enriched outputs using CDC connectors, DeltaFlow (Preview), and Spark Structured Streaming notebooks with AI Functions for PySpark. The architecture centers on continuously ingesting change data, applying transformations in Spark, and calling AI Functions inline to generate enriched fields for downstream use.

For data engineering teams, the value is in the concrete wiring between ingestion (CDC), storage/processing (DeltaFlow + Spark), and enrichment (AI Functions) without treating AI as a separate batch job. Because DeltaFlow is still in preview, plan for change and keep a close eye on operational characteristics like checkpointing, backpressure, and replay behavior.

OneLake resource instance rules (GA) for tighter network controls

OneLake resource instance rules reached general availability, letting Fabric workspace admins allow inbound access from specific trusted Azure resource instances validated by ARM identity. This adds a more precise control layer alongside Private Link, IP firewall rules, and data permissions, which is useful when you want to permit only known Azure resources (and not broad network ranges) to reach OneLake.

In practice, this can simplify secure-by-default Fabric deployments in enterprises where network teams want clear allowlists tied to resource identity. It is a step toward reducing the friction between data platform adoption and strict network governance.

Hybrid and edge: Azure Local storage options and self-managed Logic Apps Hybrid

Azure Local adds iSCSI support for SAN-backed deployments

Building on last week's notes about Foundry Local and broader hybrid patterns, Azure Local expanded SAN capabilities with iSCSI support, complementing existing Fibre Channel support. This enables both hybrid storage architectures (Storage Spaces Direct (S2D) plus SAN) and SAN-only disaggregated deployments, giving infrastructure teams more flexibility in how they modernize or reuse existing storage investments.

The update also noted Azure Migrate support for SAN-backed Azure Local deployments (including NTFS volumes), which reduces friction for moving workloads into these hybrid patterns. Upcoming work mentioned around deployment, replication, and BCDR (business continuity and disaster recovery) is worth tracking if you plan to standardize on Azure Local for edge or datacenter footprints.

Logic Apps Hybrid on RKE2 with MetalLB and Arc connectivity

Following last week's Hybrid Logic Apps on OpenShift walkthrough, a hands-on guide walked through deploying Azure Logic Apps Hybrid on a single-node RKE2 Kubernetes cluster, using MetalLB to provide LoadBalancer IPs and Azure Arc for connectivity. The post is practical about the rough edges you can hit in self-managed Kubernetes, including RKE2-specific DNS behavior (CoreDNS) and Linux inotify limit issues that can break workloads in surprising ways.

If you are running hybrid integration workloads outside Azure-managed Kubernetes, the value here is the concrete troubleshooting trail and the end-to-end shape of the deployment. It is a good reference when you need Logic Apps Hybrid but your platform standard is RKE2 rather than AKS.

Other Azure News

This week's grab bag includes new guidance for enterprise architecture, plus more building blocks for MCP-based agent integrations and production SQL agent safety.

A new reference approach explains how to put Azure API Management in front of MCP servers for authentication (Entra ID), authorization (OAuth 2.1 patterns), logging, and policy enforcement, with Azure API Center used for discovery and lifecycle management. In parallel, SQL MCP Server 2.0 adds OBO authentication and emphasizes security guardrails so agentic apps can access production SQL data with better control over tool and API exposure.

Case studies and platform notes rounded out the week: CDK Global described migrating more than 1,000 databases to Azure SQL Managed Instance using Managed Instance link for near real-time replication and rollback-capable cutovers, and John Savill's weekly update also mentioned new Log Analytics support for generative AI workloads (useful for teams centralizing AI telemetry).