Weekly Azure Roundup: AKS networking, GitOps, and AI governance

by TechHub

This week's Azure roundup focuses on making production operations more predictable across clusters, workflows, and clouds. AKS adds multi-NIC capabilities for stricter network separation, Argo CD GitOps on AKS reaches GA, and Azure Arc simplifies onboarding for EKS and GKE to unify policy and inventory. On the app and integration side, Functions previews bring structured, durable AI workflows and agent bindings, while API Management expands into MCP tool governance and requires action on service-tag network rules for classic tiers. Cost and reliability updates round out the week with Databricks cost controls, measurable token economics for self-hosted LLM serving, and concrete resiliency steps like Site Recovery for Azure Local plus new PostgreSQL backup options.

This Week's Overview

Kubernetes on Azure: More network control, GitOps maturity, and easier multicloud onboarding

This week brought several concrete steps toward running more complex, production-grade Kubernetes setups on Azure. AKS gained new networking capabilities for workloads that need multiple interfaces, while GitOps and Arc updates focused on standardizing operations across clusters and clouds, building on last week's AKS isolation-and-scale storyline by tightening the operational and networking control plane.

AKS multi-NIC with DRANET (public preview)

AKS now has public preview support for multi-NIC node pools powered by an AKS-managed DRANET driver. The big shift is that you can attach secondary NICs to nodes and, optionally, attach NICs at the pod level using Kubernetes Dynamic Resource Allocation (DRA) for workloads that need explicit access to multiple networks.

For teams running network functions, appliances, or any workload that depends on separate data/control planes, this is a path away from fragile host-level networking customization. It also signals a tighter integration between AKS and upstream Kubernetes resource allocation patterns, rather than one-off platform-specific wiring.

GitOps with Argo CD extension for AKS (GA)

The GitOps with Argo CD extension for AKS is now generally available, pushing GitOps into a more “platform-managed” shape, and it is a direct follow-through on the GitOps path we called out last week (Argo CD extension) now landing as a GA baseline teams can standardize on. Microsoft highlights a managed lifecycle for the extension, Entra ID SSO, workload identity federation for accessing ACR and Azure DevOps, hardened Azure Linux images, and Azure Managed Prometheus metrics support.

Practically, this is a cleaner baseline for teams that want Argo CD on AKS without treating it as a bespoke cluster add-on. The identity and observability pieces matter most in regulated environments, where “who can deploy what” and “how do we audit it” are the hard parts of GitOps adoption.

Azure Arc Multicloud Connector for EKS and GKE (public preview)

Azure Arc added a public preview “Multicloud Connector” onboarding solution that can automatically discover and onboard Amazon EKS and Google GKE clusters into Azure Arc-enabled Kubernetes. The preview includes filtering options, proxy/gateway connectivity choices, and periodic sync so cluster inventory does not drift from reality.

If you already use Flux v2 GitOps, Azure Policy for Kubernetes, Defender for Cloud, or Azure Resource Graph, this is an attempt to make those controls feel consistent across clouds, extending last week's theme of standardizing governance and blast-radius controls beyond any single cluster or environment. The value for developers is less about “moving clusters into Azure” and more about reducing the number of governance planes you have to wire up and maintain.

Serverless and integration: Azure Functions and API Management move deeper into agentic and event-driven architectures

A clear theme this week was “bring AI and governance to the edge of your workflow” - letting serverless apps connect to more systems, and letting API Management act as both the front door and the control point for tools, agents, and event-driven pipelines.

Dynamic Workflows in Azure Functions Hosted Skills (preview)

Azure Functions Hosted Skills introduced Dynamic Workflows in preview: an LLM generates a typed DAG plan once, then Durable Functions executes that plan durably with retries, timers, and observability via Durable Task Scheduler. The design is meant to keep planning (probabilistic) separate from execution (deterministic), with validation and safety checks before the workflow runs.

For event-driven apps that need fan-out/fan-in patterns (for example, processing many documents or tasks in parallel), the benchmark takeaway is that planning once can reduce both token usage and latency versus repeated “think/act” loops. Durable execution semantics (idempotency planning, at-least-once realities, replay-safe patterns) still apply, so this is most useful when you already know how to operate Durable Functions in production.

Azure Functions Agent bindings for Python (preview)

Azure Functions Agent bindings for Python are now in preview, offering a way to embed bounded agentic reasoning into function apps via the Microsoft Agent Framework while keeping your function code as the control surface, and it follows last week's push to make agents operable by default (identity, isolation, and repeatable execution) instead of letting them sprawl as ad-hoc chat apps. The examples cover both direct HTTP-triggered functions and Durable Functions orchestrations, plus local run steps and samples.

The practical benefit is that you can centralize tool access, constraints, and execution flow in code, instead of letting an agent “free run” in your environment. For teams experimenting with MCP (Model Context Protocol) and AI Foundry, this is a way to iterate without giving up the operational predictability that functions provide.

Azure Functions managed connectors via Azure Connector Namespace (public preview)

Azure Functions added managed connectors in public preview, built on Azure Connector Namespace, so functions can use connector triggers and typed clients across roughly 1,700 services, picking up from last week's managed-connectors preview by expanding the story from “new integration surface” into a clearer serverless pattern for SaaS-heavy workflows. The published sample uses the .NET isolated worker to react to a SharePoint upload, extract info with Azure AI Content Understanding, and post an Adaptive Card to Teams.

This is a meaningful shift for teams that want serverless code but do not want to hand-roll OAuth flows, SDK glue, and webhook plumbing for every SaaS integration. Expect new design questions around connection lifecycle, secret management boundaries, and how you test connector-driven triggers in CI.

API Management as an AI gateway: MCP governance and control-plane networking changes

Microsoft announced a public preview integration between Microsoft Agent 365 and Azure API Management to govern and enforce access to MCP servers and tools at runtime, which builds on last week's APIM-and-Service-Bus integration angle by extending APIM from message ingress into a broader policy enforcement point for tool-calling. Optional protections layer in with Microsoft Defender and Microsoft Purview, positioning APIM not just as an API front door, but as a policy enforcement point for tool-calling.

In parallel, Azure API Management customers on classic (v1) tiers using VNet internal/external deployments need to update NSGs, UDRs, and firewall rules to use the ApiManagement service tag by November 30, 2026. New control-plane IPs are being added, and relying on pinned IP allowlists risks losing management access when the change lands.

Reference architecture: Governed, event-driven AI intake pipeline

A production-minded reference architecture showed how to build a document-heavy intake pipeline with API Management as a governed front door (and AI gateway), then orchestrate work through Logic Apps, Service Bus, Functions, Document Intelligence, Foundry models, and Event Grid, reinforcing last week's thread that “day 2” agent platforms depend on traceability, identity boundaries, and repeatable integration primitives. A single correlation ID is carried end-to-end so you can trace a request across services and retries, which becomes critical once you introduce dead-lettering and asynchronous fan-out.

The details worth copying are operational: using Service Bus dead-letter queues intentionally, emitting CloudEvents through Event Grid, and treating traceability as a first-class requirement rather than an afterthought. If you are building intake for claims, onboarding, RFPs, or case management, this is a good blueprint for making “AI + integration” auditable and supportable.

Logic Apps Automation pricing and free grants (public preview)

Azure Logic Apps Automation introduced public preview pricing along with monthly free grants. Microsoft detailed what the grant covers (runtime, retention, connectors, AI usage, knowledge storage, isolated code execution) and how the free environment grant is applied and tracked.

For developers prototyping automation or event-driven workflows, this changes the early cost conversation: you can validate connector-heavy designs before committing to a paid baseline, which fits the same cost-and-governance-through-line we highlighted last week across agent platforms and integration runtimes. It also raises a practical governance task for teams: define when experiments “graduate” from free grants into a managed cost center with tagging and alerting.

Data and AI economics: Better orchestration, safer bulk loads, and measurable LLM cost-per-token

This week’s Azure data and AI content leaned into operational reality: controlling spend, loading data without disrupting production systems, and instrumenting model serving so you can answer “is this worth it” with numbers instead of guesses.

Azure Databricks: Cost governance with tags, system tables, and alerts

A practical Databricks cost governance approach combined tagging (including query tags and serverless usage policies), Unity Catalog billing system tables, and account-console budgets. Scheduled Databricks SQL alerts then surface overspend early, before the invoice arrives.

The actionable idea is to treat cost signals like operational telemetry: tag consistently, query the system tables to attribute usage, and alert on thresholds that match your team's spending tolerance, echoing last week's emphasis that cost controls belong in the platform defaults rather than as after-the-fact reporting. If you already run serverless, policy-driven usage controls plus SQL alerts can be a lighter-weight guardrail than manually reviewing Azure Cost Analysis after the fact.

Azure Databricks Lakeflow Jobs: Multiple triggers per job (beta)

Lakeflow Jobs (beta) now supports up to five triggers per job, which can reduce job sprawl when one pipeline needs multiple schedules or event-driven start conditions. The guide includes Jobs API examples and points to system.lakeflow.jobs system tables for monitoring.

In practice, this helps teams keep orchestration logic centralized, while still adapting to different upstream cadences (for example, hourly incremental loads plus a nightly full reconcile). If you rely on system tables for observability and chargeback, the monitoring angle is as important as the trigger limit itself.

Lakebase Postgres: LTAP Direct Writes for bulk loads (beta)

Databricks’ LTAP Direct Writes (beta) for Lakebase Postgres aims to load terabytes without pushing bulk ingest work through the Postgres primary. The design moves the heavy lifting to parallel Spark executors and uses an atomic WAL (write-ahead log) based handoff, with CLI and Python SDK examples for creating and monitoring Synced Tables.

The current limitations matter for production planning: index building and feature scope are not fully covered yet, so you should test whether your schema and query patterns still meet SLAs after the load. Still, for data platforms that need near-continuous ingest without degrading OLTP-like behavior, the “off-primary bulk load” pattern is the key idea.

Qwen3.8-27B on Azure H100 Spot: Instrumentation-driven token economics

A hands-on guide explored running Qwen3.8-27B on an Azure H100 Spot VM using vLLM and LiteLLM, then instrumenting the full stack with OpenTelemetry into Azure Monitor / Application Insights. Azure Managed Grafana dashboards are used to visualize the cost story end-to-end so you can compare token throughput and latency against compute spend.

The main takeaway is methodological: if you cannot trace request timing, batching behavior, retries, and token counts, you cannot reason about “cheap Spot inference” beyond anecdotes, and it pairs well with last week's Foundry focus on trace-driven evaluation by applying the same “measure, then optimize” loop to self-hosted serving. This setup gives you the pieces to build a per-endpoint cost model and decide when Spot volatility is acceptable for your SLA.

Document Intelligence vs Content Understanding: Choosing the right extraction approach

A practical comparison broke down where Azure Document Intelligence and Azure Content Understanding overlap (OCR and layout) and where they differ in approach. Document Intelligence tends toward purpose-trained document models and consistent field extraction, while Content Understanding leans into generative, schema-based extraction and broader multimodal scenarios.

For developers building preprocessing for RAG or intake workflows, the decision hinges on content variability, schema stability, and evaluation metrics tied to business outcomes, extending last week's intake and connector examples that used Content Understanding into a clearer decision framework for when to standardize on one extractor vs mix approaches. The guide’s framing is useful when you need to explain to stakeholders why “one model for all documents” often fails in production.

Identity, security, and governance: Tooling changes you need to act on

Several updates this week were less about new capabilities and more about avoiding breakage or tightening operational security. If you run older tooling, or you manage keys and encryption at scale, these are the sorts of changes that create real incidents when missed.

Azure AD Graph retirement: older Azure CLI and PowerShell versions will break

Azure AD Graph API retirement reached its final shutdown steps, with phased disablement starting after October 6, 2026. Older Azure CLI and Azure PowerShell versions that still rely on legacy Azure AD Graph endpoints (including direct graph.windows.net calls) will fail, and you need to migrate usage to Microsoft Graph.

The immediate work is inventory: check your tool and module versions in build agents and developer machines, and scan scripts for legacy endpoint calls. Treat this like a production dependency retirement, because it effectively is one when your automation cannot resolve users, groups, or service principals.

Azure CLI on macOS: broker-based authentication (preview)

Azure CLI 2.91.0 on macOS added preview support for native broker-based authentication using MSAL. This enables a native account picker, SSO, and sign-in flows that work better with Conditional Access and enterprise policy requirements.

The post also notes the move to Homebrew Cask distribution and provides commands to enable, verify, and disable the broker feature. For teams that support macOS developers, this can reduce “auth pop-up” churn and align CLI sign-in behavior more closely with corporate identity controls.

Azure Key Vault BYOK: re-importing key material does not restore the original version URI

A Key Vault BYOK (bring your own key) post highlighted a sharp edge: re-importing BYOK key material creates a new key version, and it will not recreate the old version identifier that downstream services (like Azure Storage CMK) may still reference. The guidance focuses on recovery order, rotation timing, monitoring queries, and Azure CLI backup/restore steps, with reminders about soft delete and purge protection.

For encryption-dependent workloads, the practical implication is that “we still have the same key material” is not enough if the consuming service is pinned to a specific version URI, and it lines up with last week's identity-and-blast-radius focus by showing how key/version coupling can turn a recovery event into an outage if you do not have runbooks. Teams should validate whether their CMK integrations use versionless URIs (where appropriate) or have operational runbooks that account for key version coupling.

Deployment Stacks What-If: noise reduction baselines

Azure Deployment Stacks What-If added a noise reduction feature that records a baseline after successful stack deployments. Later what-if runs can filter out provider-default and read-only diffs that often swamp meaningful changes, making reviews more actionable.

For infrastructure-as-code teams using Bicep, Azure CLI, or Azure PowerShell, this is a practical improvement to change management workflows, complementing last week's “docs as artifacts” Bicep work by reducing friction in reviews and approvals around the same IaC pipelines. Less diff noise means faster approvals, and fewer risky “approve because everything looks noisy anyway” moments.

Reliability and resiliency: DR for Azure Local, better Postgres backups, and region-specific container app failures

This week included both proactive resiliency improvements and an immediate troubleshooting signal. It is a mix of “here is how to be ready” and “here is what to do when the platform is not healthy,” continuing last week's resilience theme of proving readiness through tested mechanisms, not just architecture intent.

Azure Site Recovery for Azure Local (GA)

Azure Site Recovery for Azure Local is now generally available, with a one-page Azure portal wizard to prepare infrastructure and enable VM replication to Azure. GA adds WDAC (Windows Defender Application Control) enforcement-mode support and built-in proxy configuration, alongside DR basics like test failover, recovery plans, and failback.

This matters for teams modernizing on-prem virtualization while keeping an Azure-based DR target. The wizard-style prep suggests Microsoft is trying to reduce the hidden setup steps that often derail DR projects late in the process.

Azure Backup v2 for PostgreSQL flexible server and elastic cluster (public preview)

Azure Backup v2 for PostgreSQL entered public preview, switching to snapshot-based physical backups with incremental scheduling and expanded scale. It also adds a “Restore as Server” capability, retention options (including long-term retention), vault security controls, and a one-way migration path from v1 to v2, with pricing start details called out.

If you run Postgres on Azure at scale, snapshot-based physical backups can reduce backup windows and operational overhead compared to purely logical approaches, but you will want to validate restore time objectives with the new restore model, matching last week's broader call to continuously validate resilience rather than assume it. The one-way migration note is important: test in non-production and document the rollback story before switching.

Azure Container Apps incident pattern in Austria East (community thread)

A community troubleshooting thread reported Azure Container Apps in Austria East stalling at AssigningReplica and failing with ActivationFailed before any PullingImage or container start events. The Azure Portal diagnostics error indicated it could not resolve the Kusto cluster for the location, suggesting platform-side diagnostics dependencies may be involved.

The practical guidance is operational: preserve failing resources for investigation, capture revision and system details, check Azure Service Health/Resource Health, open a high-severity support request, and fail over to another region if you need immediate continuity, and it is a timely counterpoint to last week's push for stronger isolation and scaling in Container Apps by highlighting the separate need for region-level contingency plans. If your deployment strategy assumes “region swap” is easy, this is a reminder to keep templates and configuration portable across regions.

Other Azure News

John Savill's weekly update (Oct 9, 2026) is worth scanning for breadth: it touched AKS, App Service, networking/WAF, API Management, PostgreSQL, SQL Server, Fabric/OneLake, and multiple retirements, including Azure SQL Database Always Encrypted with Intel SGX enclaves. Retirements are often the items that break CI pipelines and compliance baselines first, so this video is a good “what do I need to chase this week” list.

Anyscale on Azure reached GA, bringing an Azure-native way to run Ray on AKS in your subscription while Anyscale operates the control plane. Governance hooks (ARM, Azure Policy, Entra ID, RBAC) and private connectivity support make it a cleaner fit for enterprise ML platforms that want managed Ray without losing subscription-level control.