DailyAzureUpdatesGenerator

November 21, 2025 - Azure Updates Summary Report (Details Mode)

Generated on: November 21, 2025 Target period: Within the last 24 hours Processing mode: Details Mode Number of updates: 12 items

Update List

1. Public Preview: Container network metrics filtering in Advanced Container Networking Services for (ACNS) for AKS

Published: November 20, 2025 20:00:10 UTC Link: Public Preview: Container network metrics filtering in Advanced Container Networking Services for (ACNS) for AKS

Update ID: 523076 Data source: Azure Updates API

Categories: In preview, Compute, Containers, Azure Kubernetes Service (AKS)

Summary:

• What was updated
  Azure Container Networking Services (ACNS) for AKS now supports container network metrics filtering, released in public preview.

• Key changes or new features
  This update enables selective ingestion of network metrics in containerized environments, allowing developers and IT professionals to filter out unnecessary or excessive network telemetry data. This helps reduce storage costs and prevents dashboards from becoming cluttered with irrelevant metrics, improving monitoring efficiency and cost management.

• Target audience affected
  Developers and IT professionals managing Azure Kubernetes Service (AKS) clusters using ACNS who require optimized network monitoring and cost control.

• Important notes if any
  As this feature is in public preview, users should evaluate it in non-production environments before full deployment. Filtering capabilities can be configured to tailor network metric collection to specific operational needs, enhancing observability while controlling data volume and associated costs.

For more details, visit: https://azure.microsoft.com/updates?id=523076

Details:

The recent public preview release of container network metrics filtering in Azure Container Networking Services (ACNS) for Azure Kubernetes Service (AKS) addresses the challenge of managing voluminous network telemetry data generated by containerized workloads. In modern AKS environments, continuous collection of detailed network metrics from containers can result in excessive data ingestion, leading to inflated monitoring storage costs and reduced operational clarity due to dashboard clutter. This update introduces granular filtering capabilities that enable IT professionals to selectively collect and retain only relevant network metrics, optimizing both cost and observability.

Background and Purpose
As container adoption grows, network observability becomes critical for diagnosing connectivity, performance, and security issues within microservices architectures. ACNS provides the underlying networking infrastructure for AKS, including network policy enforcement and telemetry. However, the default behavior of collecting all available network metrics can overwhelm monitoring systems such as Azure Monitor and Log Analytics, increasing storage consumption and complicating data analysis. The purpose of this update is to empower users to define filters that limit metric ingestion to a subset of interest, thereby reducing noise and cost while maintaining actionable insights.

Specific Features and Detailed Changes
The key feature introduced is the ability to configure metric filters at the ACNS level. Users can specify criteria such as namespaces, pods, or specific network interfaces to include or exclude from metric collection. This filtering applies to network-related metrics like packet counts, byte transfer, connection states, and latency measurements. The configuration is exposed via AKS cluster settings or through Azure CLI and ARM templates, allowing integration into Infrastructure as Code (IaC) workflows. The filtering logic operates before metrics are sent to Azure Monitor, ensuring only filtered data is ingested and stored.

Technical Mechanisms and Implementation Methods
Under the hood, ACNS integrates with the Azure Monitor Metrics pipeline. The filtering mechanism is implemented as a pre-ingestion processing step within the ACNS telemetry agent running on AKS nodes. This agent intercepts network telemetry emitted by container network interfaces and applies user-defined filter rules. The filters are declarative, supporting label selectors and resource identifiers, enabling precise targeting. The filtered metrics are then forwarded to Azure Monitor Metrics and Log Analytics workspaces configured for the cluster. This approach minimizes network overhead and storage usage by reducing the volume of telemetry data transmitted and retained.

Use Cases and Application Scenarios

• Cost Optimization: Organizations with large-scale AKS deployments can significantly reduce Azure Monitor costs by excluding metrics from less critical namespaces or development environments.
• Focused Troubleshooting: Teams can concentrate on metrics from specific microservices or pods experiencing issues, improving mean time to resolution (MTTR).
• Security Monitoring: Filtering can help isolate network metrics related to sensitive workloads for compliance and anomaly detection.
• Performance Tuning: Developers can selectively collect metrics from performance-critical services to analyze network latency and throughput without noise from unrelated components.

Important Considerations and Limitations

• As this feature is in public preview, it may not be supported in all Azure regions or AKS cluster configurations.
• Filtering rules must be carefully designed to avoid inadvertently excluding critical metrics that could impair monitoring and alerting.
• The preview may have limited support for complex filtering expressions or dynamic updates without cluster restarts.
• Integration with third-party monitoring tools relying on full metric sets may require adjustments.
• Users should monitor the impact of filtering on diagnostic capabilities and adjust filters iteratively.

Integration with Related Azure Services
This update tightly integrates with Azure Monitor Metrics and Log Analytics, the primary telemetry ingestion and analysis services in Azure. Filtered metrics are sent to these services, enabling continued use of Azure Monitor dashboards, alerts, and workbooks with reduced data volume. The filtering configuration can be managed via Azure CLI, ARM templates, or Azure Policy, facilitating automation and governance. Additionally, this feature complements Azure Network Watcher and Azure Security Center by refining the scope of network telemetry feeding into these services.

In summary, the public preview of container network metrics

---

2. Generally Available: MCP support for AI toolchain operator add-on in AKS

Published: November 20, 2025 18:45:04 UTC Link: Generally Available: MCP support for AI toolchain operator add-on in AKS

Update ID: 523152 Data source: Azure Updates API

Categories: Launched, Compute, Containers, Azure Kubernetes Service (AKS)

Summary:

• What was updated
  The AI Toolchain Operator add-on for Azure Kubernetes Service (AKS) now has Generally Available (GA) support for Model Context Protocol (MCP) within KAITO inference workspaces.

• Key changes or new features
  The update enables seamless integration of dynamic model management and tool calling via MCP, enhancing AI workload orchestration in AKS. This addresses challenges related to dynamic model context handling during inference, improving operational efficiency and scalability for AI deployments.

• Target audience affected
  Developers and IT professionals working with AI/ML workloads on AKS, particularly those leveraging KAITO inference workspaces and requiring robust model lifecycle and tool integration capabilities.

• Important notes if any
  The GA release signifies production readiness, encouraging adoption in enterprise environments. Users should review MCP integration best practices to maximize benefits and ensure compatibility with existing AI toolchain components.

Details:

The recent Azure update announces the general availability (GA) of Model Context Protocol (MCP) support for the AI Toolchain Operator add-on within Azure Kubernetes Service (AKS). This enhancement is designed to streamline and optimize AI model deployment and inference workflows by integrating MCP into KAITO inference workspaces, thereby addressing critical challenges in dynamic model management and tool interoperability.

Background and Purpose
As AI workloads become increasingly complex, managing inference pipelines that involve multiple models and tools dynamically is a significant challenge. The AI Toolchain Operator add-on in AKS facilitates the orchestration of AI model lifecycle and inference tasks within Kubernetes environments. However, prior to this update, there were limitations in dynamically linking models with associated tools and context during inference. The introduction of MCP support aims to standardize and simplify communication between models and tools, enabling more flexible, context-aware AI workflows.

Specific Features and Detailed Changes

• MCP Integration: MCP is a protocol designed to provide contextual metadata about AI models and their execution environment. By incorporating MCP, the AI Toolchain Operator can now manage model context more effectively during inference, allowing tools to access relevant model metadata dynamically.
• KAITO Inference Workspace Support: KAITO, Azure’s AI inference platform, now supports MCP-enabled workspaces. This integration allows seamless invocation of AI tools with contextual awareness, improving inference accuracy and operational efficiency.
• Dynamic Tool Calling: The add-on now supports dynamic invocation of AI tools based on the model context, enabling adaptive inference pipelines that can select and execute appropriate tools at runtime without manual reconfiguration.
• Operator Enhancements: The AI Toolchain Operator has been updated to handle MCP metadata propagation and enforce protocol compliance, ensuring consistent and reliable communication across the AI toolchain components.

Technical Mechanisms and Implementation Methods
The implementation leverages Kubernetes Custom Resource Definitions (CRDs) to represent AI models, tools, and their contexts. The AI Toolchain Operator watches these CRDs and orchestrates the deployment and execution of inference workloads. MCP metadata is embedded within these resources, enabling tools to query and utilize model context dynamically. Communication between components uses standard Kubernetes APIs and custom MCP-compliant interfaces, ensuring extensibility and interoperability. The operator also integrates with Azure Container Registry and Azure Monitor for image management and telemetry, respectively.

Use Cases and Application Scenarios

• Dynamic AI Pipelines: Enterprises deploying multi-model inference pipelines can benefit from MCP’s dynamic context propagation, enabling real-time adaptation to varying input data or operational conditions.
• Model Versioning and Rollouts: MCP facilitates smooth version transitions by providing contextual metadata that tools can use to select appropriate model versions during inference.
• Hybrid AI Workflows: Organizations combining multiple AI services and custom tools can leverage MCP to maintain consistent context across heterogeneous components, improving workflow coherence and debugging.
• Edge and Cloud Inference: The operator’s Kubernetes-native design supports scalable inference deployments both in cloud and edge environments, with MCP ensuring context consistency across distributed nodes.

Important Considerations and Limitations

• Protocol Compliance: All AI tools integrated into the pipeline must support MCP to fully leverage context propagation features. Legacy tools may require updates or wrappers.
• Resource Overhead: Embedding and managing additional MCP metadata may introduce slight resource overhead; careful monitoring is advised for large-scale deployments.
• Security and Access Control: Proper RBAC policies should be enforced to protect sensitive model metadata and inference data within Kubernetes namespaces.
• Version Compatibility: Ensure that AKS clusters and the AI Toolchain Operator are updated to versions supporting MCP to avoid compatibility issues.

Integration with Related Azure Services

• Azure Kubernetes Service (AKS): The core platform hosting the AI Toolchain Operator and inference workloads, providing scalable and managed Kubernetes infrastructure.
• Azure Container Registry (ACR): Used for storing and managing container images of AI models and tools deployed by the operator.
• **Azure Monitor

---

3. Generally Available: Cluster-wide Cilium network policy with Azure CNI powered by Cilium for AKS

Published: November 20, 2025 18:30:02 UTC Link: Generally Available: Cluster-wide Cilium network policy with Azure CNI powered by Cilium for AKS

Update ID: 523120 Data source: Azure Updates API

Categories: Launched, Compute, Containers, Azure Kubernetes Service (AKS)

Summary:

• What was updated
  Azure Kubernetes Service (AKS) now offers Generally Available (GA) support for cluster-wide Cilium network policies with Azure CNI powered by Cilium.

• Key changes or new features
  This update enables platform teams to define and enforce consistent network policies across all Kubernetes namespaces within an AKS cluster using Cilium’s advanced networking and security capabilities integrated with Azure CNI. It addresses the complexity of managing multi-tenant network policies by providing a unified, cluster-wide policy model. This improves security posture, simplifies policy management, and enhances observability and troubleshooting through Cilium’s eBPF-based datapath.

• Target audience affected
  Developers, DevOps, and IT professionals managing AKS clusters, especially those operating multi-tenant or large-scale Kubernetes environments requiring consistent and scalable network security policies.

• Important notes if any
  Users should ensure their AKS clusters are running compatible versions to leverage this feature. Transitioning to cluster-wide policies may require reviewing existing namespace-scoped policies to avoid conflicts. This GA release signals production readiness and Microsoft’s commitment to integrating Cilium’s capabilities deeply with Azure networking.

Reference: https://azure.microsoft.com/updates?id=523120

Details:

The recent general availability of cluster-wide Cilium network policy support for Azure Kubernetes Service (AKS) clusters using Azure CNI powered by Cilium addresses a critical challenge in Kubernetes network security management by enabling consistent, scalable, and fine-grained network policy enforcement across all namespaces within a cluster. Traditionally, managing network policies on a per-namespace basis in multi-tenant or large-scale Kubernetes environments has been complex and error-prone, often leading to inconsistent security postures and operational overhead for platform teams. This update introduces a unified approach to defining and enforcing network policies cluster-wide, simplifying security governance and improving operational efficiency.

From a feature perspective, this update extends the Azure CNI integration with Cilium to support cluster-wide network policies, allowing administrators to define network policies that apply uniformly across all namespaces rather than requiring duplication or namespace-scoped policies. Cilium, an open-source eBPF-based networking and security solution, leverages the Linux kernel’s extended Berkeley Packet Filter (eBPF) technology to provide high-performance, programmable packet processing. By integrating Cilium’s advanced capabilities with Azure CNI, AKS clusters benefit from enhanced network observability, security, and scalability. The cluster-wide policies can specify ingress and egress rules that control traffic flows between pods, namespaces, and external endpoints, enabling zero-trust network segmentation at scale.

Technically, the implementation relies on Cilium’s eBPF datapath programs that run within the Linux kernel on each node, intercepting and enforcing network policies at the packet level with minimal latency. The Azure CNI plugin, responsible for IP address management and routing in AKS, now works in tandem with Cilium’s datapath to apply these cluster-wide policies consistently across nodes and namespaces. The policy definitions use Kubernetes Custom Resource Definitions (CRDs) extended for cluster-wide scope, allowing declarative management via standard Kubernetes tools (kubectl, Helm, GitOps pipelines). This architecture ensures that network policies are enforced natively within the kernel, avoiding the overhead of proxy-based solutions and enabling scalability to large clusters with thousands of nodes and pods.

Use cases for this update include multi-tenant AKS clusters where platform teams need to enforce baseline security policies across all namespaces to prevent lateral movement and unauthorized access, as well as large-scale environments requiring consistent network segmentation without the complexity of managing numerous namespace-scoped policies. It also benefits DevOps teams seeking to implement zero-trust networking models by defining global ingress and egress controls that apply uniformly, simplifying compliance and audit processes.

Important considerations include ensuring that cluster-wide policies are carefully designed to avoid unintended traffic disruptions, as these policies override or complement namespace-scoped policies. Platform teams should validate policy rules in staging environments before production rollout. Additionally, while Cilium’s eBPF-based enforcement offers high performance, it requires Linux kernel versions and node configurations compatible with eBPF features; thus, cluster node OS and kernel versions should be verified for compatibility. Monitoring and troubleshooting tools provided by Cilium and Azure Monitor should be leveraged to gain visibility into policy enforcement and network flows.

Integration with related Azure services is seamless: AKS clusters using Azure CNI powered by Cilium can integrate with Azure Monitor for container insights, enabling detailed network telemetry and alerting. Azure Policy can be used to enforce compliance of network policy CRDs, and Azure Active Directory integration supports RBAC for managing network policy resources. Furthermore, this update complements Azure Security Center’s Kubernetes threat detection capabilities by providing stronger network segmentation controls.

In summary, the general availability of cluster-wide Cilium network policy support in AKS with Azure CNI powered by Cilium delivers a robust, scalable, and efficient solution for managing Kubernetes network security at the cluster level, empowering platform and security teams to implement consistent, high-performance network policies across multi-tenant and large-scale AKS environments with enhanced observability and integration into Azure’s security and monitoring ecosystem.

---

4. Generally Available: Local redirect policy in Azure CNI powered by Cilium for AKS

Published: November 20, 2025 18:30:02 UTC Link: Generally Available: Local redirect policy in Azure CNI powered by Cilium for AKS

Update ID: 523081 Data source: Azure Updates API

Categories: Launched, Compute, Containers, Azure Kubernetes Service (AKS)

Summary:

• What was updated
  Azure CNI powered by Cilium for Azure Kubernetes Service (AKS) now generally supports the local redirect policy feature.

• Key changes or new features
  The local redirect policy optimizes network traffic by redirecting pod-to-pod communication locally within the same node, reducing cross-node traffic. This significantly lowers latency and improves performance for high-scale AKS workloads by minimizing unnecessary routing through other nodes or network hops.

• Target audience affected
  Developers and IT professionals managing large-scale AKS clusters with performance-sensitive applications will benefit most. Network engineers and cloud architects focusing on Kubernetes networking and Azure CNI configurations should consider adopting this feature.

• Important notes if any
  Enabling local redirect policy requires Azure CNI powered by Cilium integration in AKS clusters. It is particularly valuable for workloads with heavy east-west traffic patterns. Users should validate compatibility and test workloads to ensure optimal performance gains. For detailed implementation guidance, refer to the official Azure documentation linked in the update.

Details:

The recent general availability of the local redirect policy in Azure CNI powered by Cilium for Azure Kubernetes Service (AKS) addresses critical performance challenges faced by high-scale AKS workloads, particularly those arising from inefficient cross-node traffic routing. Traditionally, when pods communicate across nodes in AKS clusters, network traffic often traverses multiple hops, leading to increased latency and reduced throughput. This update introduces a local redirect policy that optimizes traffic flow by ensuring that intra-node pod-to-pod communications are handled locally whenever possible, thereby minimizing unnecessary cross-node routing.

From a feature standpoint, the local redirect policy enhances the Azure CNI plugin integrated with Cilium, an open-source networking and security layer for Kubernetes. This policy dynamically redirects traffic destined for pods on the same node to local endpoints, bypassing the default routing path that would otherwise send traffic through the node’s network stack and potentially across nodes. This results in significant reductions in latency and improvements in network throughput for pod-to-pod communications within the same node. The implementation leverages Cilium’s eBPF (extended Berkeley Packet Filter) capabilities, which allow for high-performance, kernel-level packet processing and redirection without the overhead of user-space proxies or additional hops.

Technically, the local redirect policy is configured as part of the Azure CNI configuration in AKS clusters using Cilium as the CNI provider. When enabled, Cilium programs eBPF hooks into the Linux kernel networking stack on each node, intercepting traffic flows and applying the redirect logic based on pod IP addresses and node locality. This mechanism ensures that traffic destined for pods residing on the same node is locally redirected, reducing the need for encapsulation or routing through the Azure virtual network infrastructure. The policy is managed through Kubernetes Custom Resource Definitions (CRDs) and can be fine-tuned via Cilium network policies, providing granular control over traffic redirection behavior.

Use cases for this update are particularly relevant for large-scale AKS deployments running latency-sensitive applications such as real-time analytics, financial services, gaming, and microservices architectures where inter-pod communication is frequent and performance-critical. By reducing network latency and improving throughput, the local redirect policy can enhance overall application responsiveness and resource efficiency. It also benefits scenarios involving service meshes or complex network policies where minimizing network hops can reduce overhead and simplify troubleshooting.

Important considerations include ensuring that the AKS cluster is running a compatible version of Azure CNI and Cilium that supports the local redirect policy feature. Network administrators should validate that enabling local redirect does not conflict with existing network policies or security configurations, as the redirection occurs at the kernel level and may affect packet inspection or monitoring tools. Additionally, while the policy optimizes intra-node traffic, cross-node traffic still follows standard routing paths, so overall cluster network design and node distribution remain important for performance tuning.

Integration-wise, this update complements other Azure networking services such as Azure Virtual Network, Azure Network Security Groups (NSGs), and Azure Monitor for network insights. The local redirect policy works seamlessly within the Azure VNet infrastructure, ensuring that pod networking remains consistent and secure while benefiting from enhanced performance. It also integrates with Azure Policy and Azure Arc for governance and compliance in hybrid or multi-cloud Kubernetes deployments.

In summary, the general availability of the local redirect policy in Azure CNI powered by Cilium for AKS provides a kernel-level traffic optimization that significantly improves intra-node pod communication performance by leveraging eBPF-based local redirection, making it a valuable enhancement for high-scale, latency-sensitive Kubernetes workloads on Azure.

---

5. Generally Available: Layer 7 policy with Advanced Container Networking Services (ACNS) for AKS

Published: November 20, 2025 18:15:25 UTC Link: Generally Available: Layer 7 policy with Advanced Container Networking Services (ACNS) for AKS

Update ID: 523115 Data source: Azure Updates API

Categories: Launched, Compute, Containers, Azure Kubernetes Service (AKS)

Summary:

• What was updated
  Azure Container Networking Services (ACNS) for Azure Kubernetes Service (AKS) has reached general availability for its Layer 7 Policy feature.

• Key changes or new features
  The Layer 7 Policy enables granular, application-layer traffic control within microservices architectures. Developers and IT professionals can now define and enforce fine-grained routing, filtering, and security policies based on HTTP/S attributes such as headers, methods, paths, and query parameters. This enhances traffic management capabilities beyond traditional Layer 3/4 controls, supporting scenarios like canary deployments, A/B testing, and zero-trust security models within AKS clusters.

• Target audience affected
  This update primarily impacts developers building microservices on AKS and IT/network administrators responsible for securing and managing containerized workloads. It benefits teams requiring advanced traffic governance and security at the application protocol level.

• Important notes if any
  Since Layer 7 Policy is now generally available, it is production-ready and supported by Microsoft. Users should review the updated ACNS documentation to implement these policies effectively and consider potential impacts on cluster networking and application performance. Integration with existing AKS networking configurations and security practices is recommended to maximize benefits.

Details:

The recent Azure update announces the general availability of Layer 7 policy enforcement within Advanced Container Networking Services (ACNS) for Azure Kubernetes Service (AKS), addressing the critical need for granular traffic control in microservices-based architectures. This enhancement enables IT professionals to implement fine-grained, application-layer (Layer 7) traffic policies directly within the AKS networking stack, improving security, compliance, and operational control over containerized workloads.

Background and Purpose
As organizations increasingly adopt microservices and containerized applications on AKS, managing east-west traffic between services becomes complex. Traditional Layer 3/4 network policies (IP and port-based) are often insufficient for controlling traffic based on application-level attributes such as HTTP methods, URLs, headers, or payload content. To meet these requirements, Azure introduced Layer 7 policy capabilities in ACNS, allowing detailed inspection and enforcement of traffic rules at the application layer, thus enhancing security posture and traffic governance.

Specific Features and Detailed Changes

• Layer 7 Policy Enforcement: Enables defining policies based on HTTP/S attributes including methods (GET, POST, etc.), paths, headers, and query parameters.
• Granular Traffic Control: Supports allow/deny rules for specific API endpoints or service interactions within AKS clusters.
• Integration with ACNS: Layer 7 policies are natively integrated into ACNS, leveraging its high-performance dataplane for efficient traffic filtering without significant latency impact.
• Policy Management: Policies can be defined declaratively via Kubernetes Custom Resource Definitions (CRDs), enabling seamless integration with GitOps workflows and Kubernetes-native management tools.
• Logging and Monitoring: Enhanced observability with detailed logs and metrics for Layer 7 policy enforcement events, facilitating auditing and troubleshooting.

Technical Mechanisms and Implementation Methods
The Layer 7 policy feature is implemented as part of ACNS, which extends the Azure CNI plugin for AKS. ACNS operates at the pod network interface level, intercepting and inspecting traffic flows. For Layer 7 inspection, ACNS integrates with a lightweight proxy or eBPF-based filtering mechanism capable of parsing HTTP/S traffic inline. Policies are compiled from Kubernetes CRDs into efficient filtering rules applied at the datapath, ensuring minimal performance overhead. TLS traffic inspection is supported via integration with service mesh sidecars or by terminating TLS at ingress points, depending on deployment architecture.

Use Cases and Application Scenarios

• Microservices Security: Enforce strict access controls between microservices, allowing only authorized API calls and blocking unauthorized or malformed requests.
• Compliance and Governance: Implement policies that restrict sensitive data exposure by controlling traffic at the application layer.
• Traffic Shaping and Routing: Combine Layer 7 policies with routing rules to direct traffic based on URL paths or headers.
• Zero Trust Networking: Enforce zero trust principles by validating application-level attributes before allowing communication between pods.
• Multi-tenant AKS Clusters: Isolate tenant workloads by restricting Layer 7 traffic flows within shared clusters.

Important Considerations and Limitations

• Performance Impact: While optimized, Layer 7 inspection introduces additional processing overhead; performance testing is recommended for high-throughput environments.
• TLS Traffic Handling: Full Layer 7 inspection requires access to decrypted traffic; thus, integration with service mesh or ingress TLS termination is necessary.
• Policy Complexity: Overly complex or numerous policies may increase management overhead and complicate troubleshooting.
• Compatibility: Ensure that Kubernetes versions and ACNS plugin versions are compatible with Layer 7 policy features.
• Scope: Layer 7 policies currently focus on HTTP/S traffic; other protocols are not supported for application-layer filtering.

Integration with Related Azure Services

• Azure Monitor and Log Analytics: Layer 7 policy logs and metrics can be ingested into Azure Monitor for centralized observability and alerting.
• Azure Policy: Can be used to enforce compliance

---

6. Generally Available: Azure NetApp Files single file restore from backup

Published: November 20, 2025 18:15:25 UTC Link: Generally Available: Azure NetApp Files single file restore from backup

Update ID: 522077 Data source: Azure Updates API

Categories: Launched, Storage, Azure NetApp Files

Summary:

• What was updated
  Azure NetApp Files now supports single file restore directly from backup vaults.

• Key changes or new features
  Users can restore individual files from backups without restoring the entire volume. This granular restore capability reduces recovery time and operational costs by avoiding full volume restores when only specific files are needed.

• Target audience affected
  Developers and IT professionals managing Azure NetApp Files workloads who require efficient data recovery options, including those responsible for backup and disaster recovery strategies.

• Important notes if any
  This feature is generally available, ensuring production readiness and support. It enhances data protection workflows by enabling faster, more cost-effective restores, improving business continuity and minimizing downtime.

Details:

The recent Azure update announces the general availability of the single file restore capability from Azure NetApp Files (ANF) backups, enabling IT professionals to recover individual files directly from backup snapshots without restoring entire volumes. This enhancement addresses the operational inefficiencies and resource overhead associated with volume-level restores, providing a more granular, cost-effective, and time-saving data recovery option.

Background and Purpose:
Azure NetApp Files is a high-performance, enterprise-grade file storage service optimized for workloads requiring low latency and high throughput. Previously, backup and restore operations in ANF were volume-centric, meaning that to recover lost or corrupted data, administrators had to restore entire volumes from backup snapshots. This approach often resulted in unnecessary downtime, increased storage consumption, and operational complexity, especially when only a few files needed recovery. The introduction of single file restore from backup aims to streamline data recovery processes by allowing selective restoration of individual files, thereby minimizing disruption and resource usage.

Specific Features and Detailed Changes:

• Granular File Recovery: Users can now browse backup snapshots stored in the Azure NetApp Files backup vault and select specific files or folders to restore without reinstating the entire volume.
• Integration with Backup Vault: The feature leverages the existing ANF backup vault infrastructure, ensuring seamless access to snapshots and consistent data protection policies.
• User Interface and API Support: The restore operation can be initiated via the Azure portal, Azure CLI, or REST APIs, providing flexibility for automation and integration into existing workflows.
• Performance Optimization: By restoring only the necessary files, the process reduces network bandwidth consumption and accelerates recovery time objectives (RTO).

Technical Mechanisms and Implementation Methods:
Under the hood, Azure NetApp Files backups are based on snapshot technology that captures point-in-time, read-only copies of volumes. The single file restore feature extends this by enabling file-level access to these snapshots. When a restore request is made for specific files:

1. The system mounts the snapshot in a secure, isolated environment.
2. It exposes the snapshot’s file system namespace, allowing enumeration and selection of individual files.
3. Selected files are copied from the snapshot to the target volume or a specified location.
4. The process ensures data consistency and integrity by leveraging snapshot immutability and ANF’s underlying storage architecture.
   This approach avoids the overhead of full volume restore and leverages Azure’s scalable infrastructure to handle concurrent restore operations efficiently.

Use Cases and Application Scenarios:

• Accidental File Deletion or Corruption: Quickly recover individual files without impacting the entire volume or application availability.
• Application-Level Recovery: Restore specific configuration files, logs, or datasets critical to application continuity.
• Compliance and Auditing: Retrieve historical versions of files for audit or compliance purposes without full volume recovery.
• Development and Testing: Extract specific files from backups to support development or testing scenarios without duplicating entire volumes.

Important Considerations and Limitations:

• Supported Protocols: Single file restore is applicable to volumes using supported protocols such as NFS and SMB; verify compatibility with your specific ANF deployment.
• Backup Retention Policies: The availability of files for restore depends on the retention period configured for backups in the ANF backup vault.
• Performance Impact: While more efficient than full volume restores, large-scale file restores may still impact network and storage performance; plan accordingly.
• Security and Access Control: Proper RBAC permissions are required to access backup vaults and perform restore operations; ensure compliance with organizational security policies.

Integration with Related Azure Services:

• Azure Backup Vault: The feature integrates tightly with the Azure NetApp Files backup vault, leveraging its snapshot management and retention capabilities.
• Azure Monitor and Alerts: Administrators can monitor restore operations and receive alerts through Azure Monitor, enabling proactive management.
• Azure Policy: Organizations can enforce backup and restore policies using Azure Policy

---

7. Generally Available: DNS security policy Threat Intelligence feed

Published: November 20, 2025 17:00:13 UTC Link: Generally Available: DNS security policy Threat Intelligence feed

Update ID: 530183 Data source: Azure Updates API

Categories: Launched, Networking, Azure DNS

Summary:

• What was updated
  Azure DNS Security Policy now includes a generally available Threat Intelligence feed.

• Key changes or new features
  The update introduces a Microsoft-managed Threat Intelligence feed integrated into DNS security policies. This feed helps detect and block DNS queries to known malicious domains, enhancing protection against cyberattacks that often start with DNS lookups. The feed is continuously updated to provide smart, real-time protection.

• Target audience affected
  Developers and IT professionals responsible for network security, DNS management, and threat mitigation in Azure environments will benefit from this feature. It is particularly useful for security teams aiming to reduce exposure to phishing, malware, and other DNS-based threats.

• Important notes if any
  Implementing the Threat Intelligence feed requires enabling it within Azure DNS security policies. This feature leverages Microsoft’s extensive threat data, reducing the need for manual threat list management. It is recommended to monitor alerts and logs generated by this feed to respond promptly to potential threats. For detailed configuration and best practices, refer to the official Azure documentation.

Link for more information: https://azure.microsoft.com/updates?id=530183

Details:

The Azure update announcing the general availability of the DNS Security Policy Threat Intelligence feed introduces a managed, continuously updated threat intelligence feed designed to enhance DNS-level security by blocking access to known malicious domains. This feature leverages Microsoft’s extensive threat intelligence to proactively protect enterprise environments from attacks that typically begin with DNS queries, such as phishing, malware distribution, and command-and-control communications.

Background and Purpose:
DNS is a critical component of network infrastructure, translating domain names into IP addresses. However, it is also a frequent vector for cyberattacks, as adversaries use DNS queries to reach malicious domains or exfiltrate data. Traditional DNS filtering solutions require manual updates or third-party feeds, which may lag behind emerging threats. The purpose of this update is to provide Azure customers with a native, integrated, and automatically maintained threat intelligence feed that blocks DNS requests to domains identified as malicious by Microsoft’s global security telemetry.

Specific Features and Detailed Changes:

• Managed Threat Intelligence Feed: The feed is curated and updated by Microsoft security experts, ensuring high accuracy and timely inclusion of newly discovered malicious domains.
• Integration with Azure DNS Security Policies: Customers can enable the Threat Intelligence feed as part of their DNS security policies within Azure Firewall or Azure DNS Private Resolver, allowing automatic blocking or alerting on DNS queries to flagged domains.
• Granular Policy Controls: Administrators can configure actions such as block, allow, or monitor on DNS queries matching the threat intelligence feed, enabling flexible enforcement based on organizational risk tolerance.
• Real-time Protection: The feed updates dynamically without requiring manual intervention, ensuring protection against zero-day or rapidly evolving threats.

Technical Mechanisms and Implementation Methods:
The Threat Intelligence feed operates by maintaining a list of domains categorized as malicious based on Microsoft’s global threat telemetry, including signals from Microsoft Defender, Azure Sentinel, and other Microsoft security products. When a DNS query is processed by Azure Firewall DNS Proxy or Azure DNS Private Resolver configured with DNS security policies, the queried domain is checked against the threat intelligence feed. If a match is found, the configured policy action (e.g., block) is enforced. This mechanism leverages Azure’s scalable cloud infrastructure to perform DNS inspection with minimal latency impact. The feed is delivered as a managed service, abstracting complexity from customers and ensuring continuous updates.

Use Cases and Application Scenarios:

• Enterprise Network Security: Organizations can prevent users and devices from resolving domains associated with phishing, malware, ransomware, or botnet command-and-control servers.
• Zero Trust Network Architectures: DNS filtering using threat intelligence supports the principle of least privilege by restricting network communications to trusted domains only.
• Cloud Workloads Protection: Azure-hosted applications and services can avoid connecting to compromised or malicious domains, reducing the risk of data breaches or service disruptions.
• Incident Response and Monitoring: Security teams can monitor DNS queries flagged by the threat intelligence feed to identify potential compromise or insider threats.

Important Considerations and Limitations:

• False Positives: Although Microsoft curates the feed carefully, some legitimate domains may occasionally be flagged, so administrators should monitor alerts and adjust policies accordingly.
• Policy Scope: The threat intelligence feed applies only to DNS queries processed through Azure Firewall DNS Proxy or Azure DNS Private Resolver with DNS security policies enabled; it does not cover DNS traffic outside these services.
• Customization: Currently, customers cannot modify the threat intelligence feed contents but can configure policy actions and exclusions.
• Latency Impact: While designed for minimal latency, enabling DNS inspection may introduce slight delays in DNS resolution, which should be considered in latency-sensitive environments.

Integration with Related Azure Services:

• Azure Firewall: The Threat Intelligence feed integrates seamlessly with Azure Firewall DNS Proxy, allowing DNS-level filtering as part of a broader network security posture.
• Azure DNS Private Resolver: Organizations using private DNS resolution within Azure VNets can apply DNS security policies leveraging the threat intelligence feed.

---

8. Generally Available: Azure Sphere OS version 25.10 is now available

Published: November 20, 2025 16:00:12 UTC Link: Generally Available: Azure Sphere OS version 25.10 is now available

Update ID: 522390 Data source: Azure Updates API

Categories: Launched, Internet of Things, Azure Sphere

Summary:

• What was updated
  Azure Sphere OS has been updated to version 25.10 and is now generally available in the Retail feed.

• Key changes or new features
  This release focuses solely on updates to the Azure Sphere OS itself. No updates to the Azure Sphere SDK are included in this version. Devices connected to the internet will automatically receive the OS update via the cloud.

• Target audience affected
  Developers and IT professionals managing Azure Sphere devices who rely on the OS for secure IoT device operation.

• Important notes if any
  Since the SDK remains unchanged, developers do not need to update their development environment to support this OS version. Ensure devices maintain internet connectivity to receive the update seamlessly. Review device-specific release notes for any security or performance improvements included in this OS update.

Details:

Azure Sphere OS version 25.10 has reached general availability and is now accessible via the Retail feed, representing a targeted update to the operating system component of Azure Sphere without accompanying SDK changes. This update is designed to enhance the security, reliability, and functionality of Azure Sphere devices by delivering incremental OS improvements directly through cloud-based updates to internet-connected devices.

Background and Purpose:
Azure Sphere is a secured, high-level application platform with built-in communication and security features for IoT devices. The OS is a critical element that ensures device integrity, security, and connectivity. Version 25.10 continues Microsoft’s commitment to providing robust security and operational stability by refining the OS layer, addressing vulnerabilities, and improving system performance without requiring developers to update their development environment or SDK.

Specific Features and Detailed Changes:
While the update does not introduce new SDK features or APIs, it includes important under-the-hood enhancements such as security patches, kernel updates, improved device management capabilities, and possibly optimizations in networking stacks or system services. These changes help protect devices from emerging threats, improve system responsiveness, and enhance compatibility with Azure Sphere Security Service. The exact patch notes typically detail fixes for known vulnerabilities, performance improvements, and reliability enhancements.

Technical Mechanisms and Implementation Methods:
Azure Sphere OS updates are delivered over-the-air (OTA) via the Azure Sphere Security Service. Devices connected to the internet automatically receive the update from the cloud, ensuring seamless deployment without manual intervention. The update process is designed to be secure and resilient, employing cryptographic verification to prevent tampering and rollback protections to maintain device integrity. The update mechanism supports staged rollouts and can be monitored through Azure Sphere CLI or Azure Sphere Security Service dashboards.

Use Cases and Application Scenarios:
This update is critical for enterprises deploying Azure Sphere-based IoT solutions in environments requiring continuous security compliance, such as industrial automation, smart appliances, and critical infrastructure monitoring. By maintaining devices on the latest OS version, organizations can reduce the risk of security breaches, ensure compliance with regulatory standards, and improve device uptime and reliability. The update is particularly relevant for large-scale deployments where manual updates would be impractical.

Important Considerations and Limitations:

• Since this release updates only the OS, no changes to application code or SDK usage are required. However, developers should verify device compatibility and test their applications against the new OS version in staging environments before broad deployment.
• Devices must be connected to the internet to receive the update automatically; offline devices require manual update procedures.
• The update does not introduce new APIs or SDK features, so application capabilities remain unchanged.
• Monitoring update status and device health post-update is recommended to detect any anomalies early.

Integration with Related Azure Services:
Azure Sphere OS version 25.10 continues to integrate tightly with the Azure Sphere Security Service, which manages device authentication, update distribution, and threat detection. The OS improvements enhance the overall security posture when combined with Azure IoT Hub for device telemetry and Azure Defender for IoT for advanced threat protection. Organizations leveraging Azure Sphere alongside Azure IoT services benefit from a comprehensive, secure IoT solution stack that simplifies device lifecycle management and security compliance.

In summary, Azure Sphere OS version 25.10 delivers essential security and reliability enhancements through a cloud-managed OS update process, reinforcing the secure foundation of Azure Sphere devices without requiring SDK changes, thereby enabling IT professionals to maintain secure and stable IoT deployments efficiently.

---

9. Generally Available: Trusted Launch is now supported for Arm64 Marketplace Images

Published: November 20, 2025 15:00:59 UTC Link: Generally Available: Trusted Launch is now supported for Arm64 Marketplace Images

Update ID: 529797 Data source: Azure Updates API

Categories: Launched, Compute, Virtual Machines

Summary:

• What was updated
  Azure Marketplace now offers Arm64 virtual machine images with Trusted Launch support generally available.

• Key changes or new features
  Trusted Launch, a security feature that provides secure boot, virtual TPM, and integrity monitoring, is now enabled for Arm64-based Marketplace images. This allows users to leverage Arm64 VMs’ cost and performance advantages while maintaining enhanced security protections.

• Target audience affected
  Developers and IT professionals deploying Azure VMs who require both cost-efficient Arm64 architecture and advanced security features. This is particularly relevant for workloads that benefit from Arm64 performance and need compliance or security hardening through Trusted Launch.

• Important notes if any
  This update enables a combination of security and efficiency previously unavailable, facilitating secure deployment of Arm64 workloads in Azure. Users should verify compatibility of their applications with Arm64 architecture and consider Trusted Launch requirements when selecting VM images.

For more details, visit: https://azure.microsoft.com/updates?id=529797

Details:

The recent Azure update announces the general availability of Trusted Launch support for Arm64-based Marketplace images, enabling customers to deploy Arm64 virtual machines (VMs) with enhanced security guarantees provided by Trusted Launch. This update combines the cost-efficiency and performance advantages of Arm64 architecture with Azure’s advanced VM security features, addressing the growing demand for secure, high-performance cloud workloads on Arm64 platforms.

Background and Purpose:
Azure has been expanding its Arm64 VM offerings to provide customers with more cost-effective and energy-efficient compute options, particularly suited for scale-out workloads, web servers, and containerized applications. However, security remains a paramount concern, especially for enterprise and regulated workloads. Trusted Launch is an Azure security feature that provides a secure boot process, virtualized Trusted Platform Module (vTPM), and integrity monitoring to protect VMs from firmware and boot-level malware attacks. Prior to this update, Trusted Launch was primarily available for x86 VMs. Extending Trusted Launch to Arm64 Marketplace images addresses the need to secure Arm64 workloads with the same robust protections, enabling broader adoption of Arm64 in sensitive environments.

Specific Features and Detailed Changes:

• Trusted Launch Support for Arm64: Arm64 Marketplace images now support Trusted Launch, including secure boot, vTPM, and measured boot capabilities.
• Marketplace Availability: Customers can deploy pre-configured Arm64 images from the Azure Marketplace with Trusted Launch enabled, simplifying secure VM provisioning.
• Dual Benefits: Users gain the performance and cost advantages of Arm64 architecture alongside Trusted Launch’s security features, without trade-offs.
• Compatibility: This update supports a range of Arm64 VM sizes and SKUs that are compatible with Trusted Launch.

Technical Mechanisms and Implementation Methods:
Trusted Launch integrates several security technologies:

• Secure Boot: Ensures that the VM boots only with trusted firmware and OS loaders by verifying digital signatures during the boot process.
• Virtual Trusted Platform Module (vTPM): Provides hardware-rooted security functions in a virtualized environment, enabling features like BitLocker encryption and secure key storage.
• Measured Boot: Records boot measurements in a secure log to detect unauthorized changes to the boot components.
  For Arm64 VMs, Azure has adapted these mechanisms to the Arm64 architecture and firmware stack, ensuring compatibility with Arm Trusted Firmware and UEFI secure boot standards. The Marketplace images are pre-configured to leverage these features, and customers can enable Trusted Launch during VM creation via Azure Portal, CLI, or ARM templates.

Use Cases and Application Scenarios:

• Regulated Workloads: Enterprises running compliance-sensitive applications on Arm64 can now meet security requirements with Trusted Launch protections.
• Multi-tenant Environments: Cloud service providers and ISVs can offer Arm64 VMs with enhanced security guarantees to their customers.
• Security-sensitive Applications: Workloads requiring protection against boot-level malware, rootkits, or firmware tampering benefit from Trusted Launch on Arm64.
• Cost-optimized Secure Compute: Organizations seeking to reduce costs by leveraging Arm64’s efficiency can do so without compromising on VM security.

Important Considerations and Limitations:

• Image Availability: Only Marketplace images that explicitly support Trusted Launch on Arm64 can be used; custom images require manual configuration.
• VM Size Compatibility: Trusted Launch support is limited to specific Arm64 VM SKUs; users must verify SKU compatibility.
• Performance Overhead: While minimal, enabling Trusted Launch may introduce slight boot latency due to security checks.
• Feature Parity: Some advanced Trusted Launch features available on x86 may still be under development or limited on Arm64.
• Licensing and Pricing: There are no additional charges for Trusted Launch itself, but customers should consider Arm64 VM pricing and Marketplace image costs.

Integration with Related Azure Services:

• Azure Security Center / Defender: Trusted Launch VMs integrate with Azure

---

10. Public Preview: Azure NetApp Files migration assistant (portal support)

Published: November 20, 2025 13:45:47 UTC Link: Public Preview: Azure NetApp Files migration assistant (portal support)

Update ID: 525620 Data source: Azure Updates API

Categories: In preview, Storage, Azure NetApp Files

Summary:

• What was updated
  Azure NetApp Files (ANF) migration assistant now supports portal integration in public preview.

• Key changes or new features
  The migration assistant leverages ONTAP’s SnapMirror replication engine to enable efficient, cost-effective data migration from on-premises environments, Cloud Volumes ONTAP (CVO), or other cloud providers directly to Azure NetApp Files. The new portal support simplifies management by allowing users to initiate and monitor migrations through the Azure portal UI, improving usability and operational visibility.

• Target audience affected
  Developers, IT professionals, and cloud architects responsible for data migration, storage management, and hybrid cloud deployments using Azure NetApp Files.

• Important notes if any
  This feature is currently in public preview, so users should evaluate it in test environments before production use. Familiarity with ONTAP SnapMirror and Azure NetApp Files is recommended to maximize migration efficiency and minimize downtime. The portal integration aims to streamline migration workflows but may have limitations compared to CLI or API-based approaches during preview.

Details:

The Azure NetApp Files migration assistant public preview introduces portal-based support for leveraging NetApp ONTAP’s SnapMirror replication technology to facilitate efficient, reliable, and cost-effective data migration from on-premises NetApp systems, Cloud Volumes ONTAP (CVO), or other cloud providers directly into Azure NetApp Files (ANF). This update aims to simplify and streamline the migration process by integrating migration management into the Azure portal, enabling IT professionals to orchestrate and monitor data replication tasks within a familiar Azure management interface.

Background and Purpose
Enterprises increasingly adopt Azure NetApp Files for high-performance, enterprise-grade file storage in the cloud. Migrating large datasets from existing NetApp ONTAP environments—whether on-premises or in other clouds—can be complex, time-consuming, and costly. Traditionally, migrations required manual setup of SnapMirror relationships and external tooling. This update addresses these challenges by embedding migration assistant capabilities directly into the Azure portal, reducing operational overhead and accelerating cloud adoption.

Specific Features and Detailed Changes

• Portal-based Migration Assistant: Users can now initiate, configure, and monitor SnapMirror-based replication workflows from the Azure portal without needing separate CLI or third-party tools.
• Support for SnapMirror Replication: Utilizes ONTAP’s native SnapMirror technology to replicate volumes incrementally, ensuring minimal downtime and data consistency during migration.
• Source Environment Compatibility: Supports migration from on-premises NetApp ONTAP systems, Cloud Volumes ONTAP running in other clouds, and potentially other NetApp-compatible environments.
• Cost and Performance Optimization: Incremental replication reduces network bandwidth usage and migration time, lowering overall migration costs.
• Status Monitoring and Reporting: Provides real-time visibility into replication progress, health status, and error reporting within the portal.

Technical Mechanisms and Implementation Methods
The migration assistant leverages ONTAP SnapMirror, a block-level replication engine that asynchronously copies data between source and destination volumes. The process involves:

1. Establishing secure connectivity between the source ONTAP system and the Azure NetApp Files destination.
2. Configuring SnapMirror relationships via the portal interface, which automates the creation of replication policies and schedules.
3. Initial baseline data transfer followed by incremental updates to synchronize changes.
4. Final cutover operation to switch workloads to the Azure NetApp Files volume with minimal downtime.
   The portal integration abstracts much of the underlying ONTAP CLI complexity, providing a guided workflow and automation.

Use Cases and Application Scenarios

• Cloud Migration: Enterprises moving file-based workloads to Azure NetApp Files for improved scalability, performance, and integration with Azure services.
• Disaster Recovery Setup: Establishing secondary replicas in Azure for DR purposes with ongoing synchronization.
• Cloud Bursting and Hybrid Scenarios: Temporarily replicating data to Azure for burst compute workloads or hybrid cloud architectures.
• Data Center Consolidation: Phasing out on-premises NetApp infrastructure by migrating data seamlessly to the cloud.

Important Considerations and Limitations

• Preview Status: As a public preview feature, it may have limited support and could undergo changes before general availability.
• Network Requirements: Adequate bandwidth and low latency are recommended to optimize replication performance.
• Source System Compatibility: Only supported ONTAP versions and configurations can participate in SnapMirror replication; users must verify compatibility.
• Security: Secure VPN or ExpressRoute connections are advised to protect data in transit.
• Cutover Planning: Final cutover requires careful coordination to minimize application downtime.

Integration with Related Azure Services

• Azure NetApp Files: The target platform for migration, providing fully managed, high-performance file storage.
• Azure Portal: Centralized management interface now enhanced with migration assistant capabilities.
• Azure ExpressRoute or VPN Gateway: Recommended for secure, high-throughput

---

11. Public Preview: Azure NetApp Files cache volumes

Published: November 20, 2025 13:45:47 UTC Link: Public Preview: Azure NetApp Files cache volumes

Update ID: 523917 Data source: Azure Updates API

Categories: In preview, Storage, Azure NetApp Files

Summary:

• What was updated
  Azure NetApp Files has introduced cache volumes, now available in public preview. This feature leverages NetApp’s ONTAP FlexCache technology to provide persistent, high-performance caching within Azure.

• Key changes or new features
  Cache volumes enable a local, read-only cache of data stored on ONTAP-based storage systems, reducing latency and improving performance for workloads accessing remote or central data repositories. This persistent cache accelerates data access without duplicating data, optimizing throughput and reducing network traffic. It supports seamless integration with existing Azure NetApp Files deployments.

• Target audience affected
  Developers and IT professionals managing high-performance file storage workloads in Azure, particularly those using ONTAP-based storage systems who require low-latency access and improved data throughput for distributed applications.

• Important notes if any
  As this feature is in public preview, users should evaluate it in non-production environments and provide feedback. Pricing and SLA details may change upon general availability. Integration requires familiarity with ONTAP FlexCache concepts and Azure NetApp Files configurations.

For more details, visit: https://azure.microsoft.com/updates?id=523917

Details:

The recent public preview release of Azure NetApp Files (ANF) cache volumes introduces a significant enhancement designed to optimize data access performance for ONTAP-based storage workloads in Azure by leveraging NetApp’s proven FlexCache technology. This update addresses the growing demand for low-latency, high-throughput access to shared datasets distributed across multiple geographic locations or cloud environments.

Background and Purpose
Azure NetApp Files is a high-performance, enterprise-grade file storage service built on NetApp’s ONTAP technology, widely used for mission-critical applications requiring SMB and NFS protocols. Traditionally, accessing data stored in a central ONTAP volume from remote locations or multiple clients can introduce latency and bandwidth constraints. The cache volumes feature aims to mitigate these issues by providing a persistent, local cache that accelerates read operations and reduces network load, thereby improving application responsiveness and scalability.

Specific Features and Detailed Changes

• Cache Volumes: These are special ANF volumes that act as read-only caches for a source ONTAP volume. They maintain a synchronized copy of frequently accessed data locally.
• Persistent Caching: Unlike ephemeral caches, the cache volumes persist across reboots and maintain cache consistency using ONTAP’s FlexCache coherence protocols.
• High Performance: Cache volumes leverage the underlying SSD-backed storage of ANF, delivering low latency and high IOPS for cached data.
• Transparent to Clients: Applications access cache volumes as standard ANF volumes via NFS or SMB without requiring changes to client configurations.
• Cache Management: Administrators can create, monitor, and manage cache volumes through the Azure portal, CLI, or REST APIs, including cache invalidation and refresh policies.

Technical Mechanisms and Implementation Methods
The cache volumes feature is implemented using ONTAP FlexCache technology, which creates a distributed caching layer that maintains cache coherence with the source volume. When a client reads data from the cache volume, ONTAP checks if the data is current; if not, it fetches updated data from the source volume and updates the cache. Write operations are not permitted on cache volumes, ensuring data integrity by funneling all writes to the authoritative source volume. The cache volumes reside within the same Azure region or can be deployed in different regions to optimize cross-region data access. The underlying synchronization uses ONTAP’s metadata and data consistency protocols to ensure cache freshness and minimize stale reads.

Use Cases and Application Scenarios

• Global Collaboration: Organizations with distributed teams can deploy cache volumes closer to end-users to accelerate access to shared datasets such as CAD files, media assets, or large scientific datasets.
• Disaster Recovery and Backup: Cache volumes can serve as a fast-access layer during failover scenarios, reducing downtime by providing immediate read access to cached data.
• High-Performance Computing (HPC): Workloads requiring repeated reads of large datasets benefit from reduced latency and network traffic.
• Dev/Test Environments: Cache volumes enable rapid provisioning of data copies without duplicating the entire dataset, saving storage costs and time.

Important Considerations and Limitations

• Cache volumes are currently read-only; write operations must be directed to the source volume.
• Cache synchronization introduces some latency on cache misses, so initial access to uncached data will be slower.
• The feature is in public preview; therefore, it may have limitations in SLA guarantees and feature completeness.
• Network bandwidth between cache and source volumes impacts performance; optimal placement and network configuration are essential.
• Compatibility is limited to ONTAP-based source volumes within Azure NetApp Files; integration with other storage types is not supported.

Integration with Related Azure Services
Cache volumes integrate seamlessly with Azure NetApp Files management tools and monitoring via Azure Monitor and Azure Resource Manager. They can be combined with Azure Virtual Machines, Azure Kubernetes Service (AKS), and Azure HPC clusters to accelerate file-based workloads. Additionally, cache volumes

---

12. Public Preview: Azure Monitor for Azure Arc-enabled Kubernetes with OpenShift and Azure Red Hat OpenShift

Published: November 20, 2025 08:00:32 UTC Link: Public Preview: Azure Monitor for Azure Arc-enabled Kubernetes with OpenShift and Azure Red Hat OpenShift

Update ID: 530174 Data source: Azure Updates API

Categories: In preview, Hybrid + multicloud, Compute, Containers, DevOps, Management and governance, Azure Arc, Azure Kubernetes Service (AKS), Azure Monitor

Summary:

• What was updated
  Azure Monitor now supports monitoring for Azure Arc-enabled Kubernetes clusters running OpenShift, including Azure Red Hat OpenShift (ARO), currently in public preview.

• Key changes or new features
  This update extends Azure Monitor’s capabilities to provide comprehensive health and performance monitoring across Kubernetes infrastructure layers and workloads on OpenShift clusters managed via Azure Arc. Developers and IT professionals can collect metrics, logs, and alerts from these hybrid and multicloud Kubernetes environments, enabling unified observability alongside native Azure Kubernetes Service (AKS) clusters.

• Target audience affected
  Developers, DevOps engineers, and IT operations teams managing Kubernetes workloads on Azure Arc-enabled OpenShift clusters, including Azure Red Hat OpenShift users, who require integrated monitoring and diagnostics within the Azure ecosystem.

• Important notes if any
  This feature is currently in public preview, so users should evaluate it in non-production environments and expect ongoing improvements. Integration requires Azure Arc-enabled Kubernetes clusters with OpenShift configured and appropriate Azure Monitor agents deployed. Refer to official documentation for setup details and limitations during preview.

Details:

The recent public preview announcement of Azure Monitor support for Azure Arc-enabled Kubernetes clusters running OpenShift and Azure Red Hat OpenShift (ARO) extends Azure’s comprehensive monitoring capabilities to hybrid and multi-cloud Kubernetes environments, enabling IT professionals to gain unified observability across on-premises, edge, and cloud deployments.

Background and Purpose:
Azure Monitor is a native Azure service designed to provide end-to-end monitoring of applications and infrastructure. Traditionally, Azure Monitor has supported Azure Kubernetes Service (AKS) clusters, but with the increasing adoption of hybrid cloud strategies and Kubernetes distributions like OpenShift, there is a need for consistent monitoring across diverse environments. Azure Arc enables management of Kubernetes clusters outside Azure, including on-premises and other clouds. This update aims to bridge the observability gap by integrating Azure Monitor with Azure Arc-enabled Kubernetes clusters running OpenShift and ARO, allowing organizations to leverage Azure’s monitoring stack uniformly.

Specific Features and Changes:

• Support for OpenShift and ARO on Azure Arc: Azure Monitor can now collect telemetry data (logs, metrics, and events) from OpenShift clusters connected via Azure Arc. This includes both self-managed OpenShift clusters and Azure Red Hat OpenShift clusters.
• Unified Monitoring Experience: Users can view health, performance, and diagnostic data of these clusters alongside native AKS clusters within the Azure portal.
• Container Insights Extension: The Azure Monitor Container Insights solution is extended to support OpenShift workloads, enabling detailed pod, node, and container-level metrics and logs.
• Log Analytics Integration: Collected data is ingested into Azure Log Analytics workspaces, allowing advanced querying, alerting, and visualization using Kusto Query Language (KQL).
• Preview Status: As a public preview feature, it is available for evaluation but may have limitations and is not recommended for production-critical workloads without validation.

Technical Mechanisms and Implementation:

• Azure Arc-enabled Kubernetes Agent: The Azure Arc agent is deployed on the OpenShift cluster to establish connectivity and enable management.
• Azure Monitor Container Insights Agent: This agent, typically based on the Azure Monitor for containers solution, is installed as a DaemonSet on the Kubernetes cluster. It collects telemetry data such as node CPU/memory usage, pod statuses, container logs, and Kubernetes events.
• Data Pipeline: The telemetry data is securely transmitted to Azure Monitor via the Azure Arc control plane and ingested into Log Analytics.
• OpenShift Compatibility: The monitoring agents are adapted to work with OpenShift’s Kubernetes distribution, including its unique networking and security configurations.
• Configuration: Users configure monitoring via Azure CLI, Azure portal, or ARM templates, specifying the Log Analytics workspace and enabling the Container Insights solution on the Arc-enabled cluster.

Use Cases and Application Scenarios:

• Hybrid Kubernetes Monitoring: Organizations running OpenShift clusters on-premises or in other clouds can centralize monitoring in Azure Monitor.
• Multi-Cluster Observability: IT teams managing heterogeneous Kubernetes environments can use a single pane of glass for health and performance metrics.
• DevOps and SRE Workflows: Enables proactive alerting and troubleshooting by correlating application logs and infrastructure metrics across environments.
• Compliance and Auditing: Centralized log collection supports compliance reporting and forensic analysis.
• Capacity Planning and Optimization: Detailed telemetry helps optimize resource allocation and cluster scaling decisions.

Important Considerations and Limitations:

• Preview Limitations: Being in public preview, some features may be incomplete or subject to change. Support and SLA levels differ from GA services.
• Agent Compatibility: Ensure the Azure Arc and Container Insights agents are compatible with your OpenShift version.
• Network Requirements: Outbound connectivity to Azure Monitor endpoints is required; network security policies must allow this traffic.
• Data Residency and Compliance: Data is stored in Azure Log Analytics workspaces; consider data residency requirements.
• **Resource Over

---

This report was automatically generated - 2025-11-21 03:08:01 UTC

This site is open source. Improve this page.