This week in Azure

A lot of agent and AI infrastructure landed this week. Microsoft Agent Framework 1.0 went GA, merging Semantic Kernel and AutoGen into one stack. Foundry Agent Service picked up Boundary hosted agents (per-session VM isolation), bring-your-own AI gateway support, and a managed memory capability that could meaningfully change how personalized your agents feel. Prompt Flow is being retired in April 2027 as the Agent Framework takes over.

On the infrastructure side, AKS got pod-to-pod traffic encryption via WireGuard, Front Door Premium WAF added an ML-based HTTP DDoS rule set, and Elastic SAN picked up three storage features (CRC32C checksums, a Windows VM extension for iSCSI configuration, and Azure Backup support).

John also flagged a video on post-quantum cryptography. Worth watching if you haven’t started thinking about how quantum computing will affect your asymmetric encryption story.

AKS pod traffic encryption with WireGuard (GA)

For AKS clusters running Azure CNI powered by Cilium with Advanced Container Networking Services on top, you can now enable WireGuard-based encryption for pod traffic between nodes. No application changes, no sidecars, no instrumentation work — the encryption happens at the network layer.

Without encryption:
  Pod A (Node 1) ──[plaintext]──→ Pod B (Node 2)


With WireGuard:
  Pod A (Node 1) ──[encrypted via WireGuard]──→ Pod B (Node 2)
                  └── No app changes
                  └── No sidecars
                  └── Cilium agent handles it

You can enable this on existing clusters, but it requires a restart of the Cilium agent on every node. On large clusters, that takes a while and there’s a temporary impact on workloads during the rollover. Plan it for a maintenance window.

AKS Container Network Insights agent (preview)

A natural-language interface for AKS networking troubleshooting. You describe the problem in plain English; the agent goes and pulls the relevant telemetry, logs, metrics, and flow data, then suggests where the root cause might be and what to do next.

This is the kind of feature where the value depends entirely on the quality of the underlying telemetry and the agent’s ability to reason about it. Worth trying on a real incident scenario before forming an opinion. Preview for now.

Azure Red Hat OpenShift in Austria East (GA)

ARO (the jointly developed Microsoft and Red Hat OpenShift offering) is now available in the Austria East region. Useful if you have data residency requirements that pin you to that region.

Azure Functions Java 25 (GA)

Java 25 is supported on Azure Functions across Windows, Linux, and the Flex Consumption plan. If you’ve been holding back on adopting newer Java features because the runtime wasn’t there yet, that constraint is gone.

Azure Front Door WAF: HTTP DDoS rule set (GA)

Front Door Premium WAF now includes an HTTP DDoS protection rule set. Layer 7 DDoS is still a primary cause of application outages, and traditional WAF rules struggle with it because the requests look legitimate at the per-request level — what gives them away is the pattern at scale.

HTTP DDoS Protection Flow:
  1. Learn baseline traffic patterns (ML)
  2. Detect surge above baseline
  3. Identify source patterns of the surge
  4. Selectively block the source patterns
     └── Legitimate traffic continues

The rule set uses machine learning to learn your baseline traffic, detect surges that look like attacks, and selectively block the offending sources rather than throwing up a wholesale wall. Adaptive protection beats static rate limits for this class of problem.

Azure Virtual Network Manager cross-region IP pool association (GA)

Azure Virtual Network Manager (AVNM) handles centralized at-scale management of VNets, security rules, and IP address management across subscriptions. The IPAM piece now supports cross-region pool association: you create an IP pool in one region and associate it with a VNet in a different region.

If you’ve been carving up address space manually across regions, this gives you one place to manage it instead.

Azure Elastic SAN CRC32C checksums (GA)

Elastic SAN volumes now support CRC32C checksums for data integrity validation. The client header negotiates the checksum, and the SAN verifies that data arrived exactly as it was sent — no bit corruption, no silent data damage.

You can do better than just enabling it: at the volume level, you can enforce CRC usage. With enforcement on, the SAN rejects any connection that doesn’t include the required checksum digest in the header. That turns checksums from a best-effort feature into a hard requirement.

Azure Elastic SAN Windows VM extension (GA)

Connecting a Windows VM to Elastic SAN used to mean configuring iSCSI initiator and MPIO inside the guest OS by hand. That work is now wrapped in a VM extension: it enables the native iSCSI and MPIO capabilities in Windows, configures them, and connects to the iSCSI target — all from the extension.

Template-based deployment:
  ARM / Bicep / Terraform
        │
        ▼
  VM + Extension
        ├── iSCSI initiator configured
        ├── MPIO enabled
        └── Connected to Elastic SAN target

The reason this matters: extensions can be configured as part of templates. So your full deployment — VM plus iSCSI connectivity to Elastic SAN — can now go through Bicep, Terraform, or whatever IaC tool you use, without any post-deployment manual configuration.

Azure Backup for Elastic SAN (GA)

Elastic SAN now has Azure Backup support. The backup data is stored separately from Elastic SAN itself, using independent managed disk snapshots. That separation is the point: if you lose the SAN to accidental deletion, malicious deletion, or logical corruption (encryption, content tampering), the backup is somewhere else and you can restore from it.

Snapshots run every 24 hours, with up to 450 recovery points retained. That’s a meaningful retention window for ransomware recovery scenarios.

Blob user-delegated SAS prefix scoping (GA)

User-delegated SAS keys for blob storage now support prefix-based scoping. A quick refresher on the layers here:

SAS evolution:
  Account-key SAS  ──→ Signed by storage account key
                       Broad blast radius if leaked


  User-delegated SAS ──→ Signed by Entra-issued delegation key
                         Tighter time bounds
                         Identity-based attribution


  + prefix scoping  ──→ Restricts access to blobs starting
                        with specific characters (i.e., a
                        virtual directory in regular blob)

Regular blob storage doesn’t have a real directory hierarchy (that’s a separate option with hierarchical namespace), but the slash-separated naming convention creates “virtual directories” that most tools render as folders. With prefix scoping, you can restrict a SAS to blobs whose names start with a specific prefix — effectively limiting access to a single virtual directory.

The scenario this fixes: one storage account holding data for multiple projects, business units, or customers. Without prefix scoping, your only options were a SAS for the entire container or one storage account per tenant. Now you can issue narrowly-scoped SAS keys per virtual directory while keeping the data consolidated.

PostgreSQL cascading read replicas (GA)

Azure Database for PostgreSQL now supports replicas of replicas — two levels deep. Previously you could have up to 5 read replicas on a primary. With cascading replicas, each of those can have 5 of its own, taking the total to 30 read replicas.

Before:
  Primary ──→ 5 read replicas (max)


After:
  Primary ──→ 5 first-level replicas
              │
              └──→ each can have 5 second-level replicas
                   ├── Total: up to 30 read replicas
                   └── Primary still only feeds 5 directly

The point isn’t just the higher count — it’s that the primary’s replication load doesn’t go up. The primary still feeds 5 replicas; the second tier of replicas reads from the first tier. This makes regional read fan-out (one read replica per region for low-latency reads, then more replicas downstream) a real option without overloading the primary.

Microsoft Agent Framework 1.0 (GA)

The Microsoft Agent Framework is GA in both .NET and Python. This is the merger of Semantic Kernel and AutoGen into one framework. Two main capabilities:

  • Agents (autonomous, prompt-driven)
  • Graph-based workflows (finer control over multi-step tasks where you need explicit orchestration)

If you’ve been picking between Semantic Kernel and AutoGen for new projects, that decision is now consolidated. If you have existing code in either, plan a migration to the unified framework — it’s where the investment is going.

Foundry Boundary hosted agents (preview)

Foundry Agent Service now offers Boundary hosted agents: each agent session runs in its own isolated environment with VM kernel-mode isolation. The isolation is per-session, not per-agent — every conversation gets a fresh boundary.

Boundary hosted agent:
  Container image (your code, any framework)
        │
        ▼
  Push to Azure Container Registry
        │
        ▼
  Foundry Agent Service deploys per-session:
    ├── VM-isolated environment
    ├── Configurable CPU / memory
    ├── Identity assigned
    ├── $HOME and /files for persistence
    └── Endpoint exposed

The framework you bring is up to you — Microsoft Agent Framework, LangGraph, custom code, custom protocols. You package it as a container image, push it to Azure Container Registry, and the Agent Service handles standing it up with an identity and exposing the endpoint. Persistence comes via special endpoints ($HOME, /files) that survive the session.

This is the right shape for agents that need to execute untrusted code, handle sensitive data per-session, or run at multi-tenant scale without leaking state between sessions.

Foundry Toolkit for VS Code (GA)

A VS Code extension for scaffolding and developing against the Microsoft Agent Framework and the broader Foundry agent stack. If you’re building agents, this is the local developer experience.

Foundry Agent Service: bring your own AI gateway (GA)

Foundry Agent Service now lets you front it with your own AI gateway. Azure API Management is one option, but non-Azure AI gateways work too. The point is flexibility in how you control model routing, rate limiting, observability, and cost attribution without being locked into a specific gateway.

If you’ve already standardized on a gateway product across your organization, you don’t have to give it up to use Foundry Agent Service.

Foundry Agent Service: Managed Memory (preview)

This is the most interesting Foundry update this week. Memory-as-a-service for agents: the ability to maintain long-term context across sessions, automatically extract key information from interactions, consolidate stored memories over time, and recall them on demand.

Agent interaction:
  User ──→ Agent
            │
            ├── Memory search tool reads relevant context
            ├── Conversation happens
            └── Key info extracted, written back to memory store


Over time:
  - Memories consolidated to keep storage efficient
  - Personalization improves with each interaction
  - Conversation history persists across sessions

The reason this matters: model quality is converging. The differentiation is increasingly in the knowledge and personalization you can layer on top. A long-term memory layer changes the experience qualitatively because the agent stops being a stateless function and starts feeling like something that knows you.

Integration is via a memory search tool added to the agent, which gives it read/write access to the memory store. Works with both Microsoft Agent Framework and LangGraph.

Prompt Flow retirement

Prompt Flow is being retired in April 2027. The Microsoft Agent Framework now covers what Prompt Flow was built for — developing LLM-based AI applications — and Microsoft is consolidating around the new framework.

If you have Prompt Flow workloads, plan the migration to Agent Framework. You have time, but don’t start new projects on the deprecated stack.

Final thoughts

The agent stack consolidation is the headline. Agent Framework 1.0 GA plus Boundary hosted agents plus Managed Memory plus the BYO gateway story — that’s a complete platform pitch. If you’ve been holding back on building agents because the framework choice felt unstable (Semantic Kernel? AutoGen? Custom?), the answer is now Agent Framework.

Managed Memory is the feature most likely to surprise people in a good way. The “stateless function” feel of most current agent deployments is something users notice immediately. Long-term memory changes that, and the fact that it’s managed rather than something you have to build means a much shorter path to a personalized experience.

On the infrastructure side, the Elastic SAN trio (CRC32C, Windows extension, Azure Backup) is worth attention if you’re using or considering Elastic SAN. Backup separation is the most important of the three — without it, ransomware on the SAN was a much harder recovery scenario.

WireGuard pod encryption on AKS is a nice security upgrade, but pay attention to the rollout impact. Cilium agent restart on every node isn’t free.

Sources

  1. John Savill, “Azure Update - 1st May 2026,” YouTube, https://www.youtube.com/watch?v=FqYQSLI6vuk