Once again this month, I’m back with my recurring series focused on the evolution of Azure management and security services, with a special focus on hybrid and multicloud scenarios enabled by Azure Arc and enhanced by the use of Artificial Intelligence.
This monthly series aims to:
-
Provide an overview of the most relevant updates released by Microsoft;
-
Share operational tips and field-proven best practices to help architects and IT leaders manage complex and distributed environments more effectively;
-
Follow the evolution towards a centralized, proactive, and AI-driven management model, in line with Microsoft’s vision of AI-powered Management.
The main areas addressed in this series, together with the corresponding tools and services, are described in this article.
Hybrid and multicloud environment management
Azure Arc
Secure automation of Azure Arc server onboarding at scale with Ansible
Microsoft has introduced a new Azure Arc onboarding role designed specifically for automation scenarios, such as those based on Ansible playbooks, with the goal of making it easier and more secure to connect servers to Azure Arc. This new approach follows the principle of least privilege, granting automation identities only the permissions required to perform onboarding, without relying on overly permissive service principals. This update addresses a common need in hybrid and multicloud environments, where large-scale onboarding is often hindered by manual steps, lack of standardization, and security-related risks. By integrating the new role into existing Ansible workflows, organizations can automate the entire process in a repeatable, consistent, and scalable way, reducing operational risk and simplifying the adoption of Azure Arc across distributed datacenters and infrastructures hosted on different clouds.
Azure Arc introduces support for SQL Server on Azure Virtual Machines as a migration target (preview)
Azure Arc now introduces, in Public Preview, support for SQL Server on Azure Virtual Machines as a destination for migration paths. With this enhancement, Azure Arc-enabled SQL Server instances can be migrated not only to Azure SQL Managed Instance, but also to SQL Server running on Azure infrastructure, using the same unified migration workflow. This extension provides greater flexibility for organizations planning SQL Server modernization initiatives, allowing them to choose the most suitable Azure destination based on application requirements, existing operating models, and compatibility needs. For many enterprise organizations, this capability represents a gradual approach to modernization, combining the benefits of cloud infrastructure with the operational and functional continuity required by applications that still heavily depend on traditional SQL Server.
Run the latest version of the Azure Arc agent with Automatic Agent Upgrade (preview)
Microsoft has introduced new ways to enable Automatic Agent Upgrade for the Azure Arc agent at scale, with the goal of simplifying the management of distributed environments consisting of large numbers of servers. In hybrid and multicloud scenarios, manually configuring each server individually is not sustainable and can lead to operational inconsistencies, delays in adopting new features, and reduced timeliness in applying security updates. To address this need, Microsoft has made available a built-in Azure Policy that can verify whether automatic agent upgrade is enabled within a specific scope and, where necessary, automatically remediate non-compliant configurations. In addition, for newly registered servers, this capability can now be enabled during onboarding by using the
Security posture across hybrid and multicloud infrastructures
Microsoft Defender for Cloud
Anti-malware detection and blocking for containers
Microsoft has announced the availability of anti-malware detection and blocking capabilities for the container runtime in Microsoft Defender for Containers. The capability is now available for Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS), and Google Kubernetes Engine (GKE) environments, strengthening the protection of containerized workloads also in hybrid and multicloud scenarios. This capability makes it possible to detect and block malware when a container attempts to execute a file identified as malicious. The inspection therefore takes place while the workload is running, providing an additional layer of defense compared to earlier stages of the application lifecycle, such as build, image scanning, and deployment. A key element is the ability to define custom anti-malware policies by configuring specific conditions for alert generation and blocking actions. This allows security teams to distinguish more accurately between legitimate activities and potentially dangerous behaviors, reducing operational noise and improving incident response effectiveness. For organizations managing Kubernetes clusters distributed across multiple clouds, this capability represents another step toward a more consistent, centralized, and scalable runtime protection model.
DNS Detection for Kubernetes
DNS Detection for Kubernetes is now generally available in Microsoft Defender for Containers for Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS), and Google Kubernetes Engine (GKE) environments. This update strengthens runtime threat detection capabilities, with a specific focus on DNS traffic generated by pods and applications running in Kubernetes clusters. DNS Detection monitors DNS queries originating from containerized workloads to identify suspicious activities, such as communications with malicious domains or potential DNS tunneling techniques. Attackers can use the latter to exfiltrate data or maintain hidden communication channels by abusing the DNS protocol. To use this capability, the Defender sensor must be deployed through Helm. Once enabled, DNS Detection provides security and cloud operations teams with greater visibility into the network behavior of Kubernetes workloads, helping them identify potential indicators of compromise at an early stage. In hybrid and multicloud scenarios, the consistent availability of this capability across different platforms helps build a more uniform, governable, and integrated security posture.
Defender for Storage integration in the Azure portal Storage Center
Microsoft has made generally available the integration of Microsoft Defender for Storage within the Storage Center in the Azure portal. This integration brings security information directly into the native storage management experience, simplifying the analysis of the protection posture and the identification of areas for improvement. With this update, customers can view the protection status provided by Defender for Storage directly alongside their resources. The Storage Center therefore becomes a centralized and contextual point of observation, useful not only for the operational management of storage accounts but also for assessing their exposure to risk. The new experience makes it possible to quickly identify which storage accounts are protected, partially protected, or unprotected. It also allows customers to verify whether capabilities such as malware scanning, activity monitoring, and sensitive data discovery are enabled, providing a clearer view of active coverage and potential gaps. This integration is particularly useful in enterprise environments, where services such as Azure Blob Storage and Azure Files may be distributed across multiple subscriptions, business units, and workloads. The goal is to make storage security more accessible to operational teams by embedding it into day-to-day management processes and promoting a more proactive approach to data protection.
Container security capabilities in Azure Government cloud
Microsoft has announced the general availability of container security capabilities in Azure Government cloud. This development enables U.S. federal and government agencies, including Department of Defense (DoD) organizations and civilian agencies, to protect Kubernetes workloads through advanced Cloud Security Posture Management (CSPM), vulnerability assessment, and runtime threat protection capabilities.
Defender for SQL Server on machines plan update for Fairfax customers
Microsoft has announced an update to the Defender for SQL Server on machines plan in Microsoft Defender for Cloud for Fairfax customers. The plan protects SQL Server instances hosted on Azure machines, Amazon Web Services (AWS), Google Cloud Platform (GCP), and on-premises environments, offering a consistent protection model for hybrid and multicloud scenarios. The new solution uses the existing SQL infrastructure and no longer requires the deployment of the Azure Monitor Agent (AMA). This change reduces operational complexity and makes adoption of the plan easier, especially in distributed environments where agent management can represent a critical factor. Starting from an estimated date in May 2026, customers will also need to verify the protection status of SQL Server instances across the different environments to ensure that the new configuration has been applied correctly and that the instances are effectively protected. This update confirms Microsoft’s direction toward protection models that are easier to deploy and maintain, reducing dependency on additional components and improving centralized visibility into the security status of SQL Server instances, regardless of their infrastructure location.
Governance and policy management
Azure Policy
New “Local” Management Group for Azure Landing Zone and Sovereign Landing Zone
Microsoft has introduced a new dedicated Management Group, named “Local”, within the conceptual architecture of Azure Landing Zone (ALZ). This new node is positioned under the Landing Zones Management Group, alongside the existing Corp and Online Management Groups. Since the Sovereign Landing Zone (SLZ) extends and depends on the ALZ architecture, the SLZ hierarchy also automatically inherits this new Management Group in the same position. The main goal of this evolution is to provide a clear and consistent placement for scenarios related to Azure Local, both when workloads run directly on Azure Local clusters and when they are currently hosted in the Azure public cloud but need to be designed with portability requirements toward Azure Local disconnected operations (ALDO). In this way, organizations that must meet sovereignty, resilience, or business continuity requirements can define a dedicated governance perimeter from the outset, applying consistent controls, policies, and guardrails. The new “Local” Management Group therefore enables centralized application of governance and security policies to workloads that must be “exit-ready by construction”, meaning ready to be moved to a disconnected Azure Local environment should the need arise. This approach prevents portability from being managed manually or documented in external tools, instead relying on the platform to prevent incompatible configurations. To support this scenario, Microsoft has made available a new built-in Azure Policy in preview, designed to restrict resource types to only those Azure services supported in Azure Local disconnected operations mode. The policy can be used in Audit mode, to gain visibility into already deployed non-compatible resources, or in Deny mode, to prevent the deployment of services that would compromise the ability to move the workload to Azure Local in disconnected mode. It is important to highlight that the new “Local” Management Group is not intended as a generic container for all Azure Arc-enabled resources, such as servers connected through Azure Arc. Microsoft confirms that these resources should continue to be placed in their respective application subscriptions, following the standard Azure Landing Zone guidance, for example within Corp or Online landing zones. The “Local” Management Group should instead be interpreted as a dedicated scope for Azure Local scenarios and for workloads that require a structured exit-planning strategy toward Azure Local disconnected operations.
New sovereign policy initiatives for Sovereign Landing Zone
Microsoft has updated Sovereign Landing Zone (SLZ) by replacing the previous built-in initiatives named Sovereignty Baseline with a new set of sovereign policy initiatives, directly aligned with the three control levels defined by Microsoft’s sovereignty model. This update introduces greater consistency between the technical implementation of SLZ and the official documentation related to the controls and principles of the Sovereign Public Cloud. The new built-in initiatives are organized around three levels: Level 1, focused on data residency; Level 2, focused on encryption of data at rest and in transit; and Level 3, focused on encryption of data in use through Confidential Computing technologies. This structure allows organizations to apply more targeted controls based on data classification and the sovereignty requirements of different workloads. Previously, SLZ assigned two broader built-in initiatives: one related to global sovereignty policies, with controls for location restrictions and Trusted Launch, and one dedicated to confidential scenarios, with policies covering customer-managed keys, confidential compute, and restrictions on resource types and geographic regions. While useful as a general baseline, these initiatives were not designed to map precisely to the L1/L2/L3 model used by Microsoft to describe sovereign controls. The new approach provides several operational benefits. First, the policies assigned by SLZ become consistent with what is documented in Microsoft Learn, reducing the need for manual interpretation or mapping. In addition, each control level can be more naturally associated with data classification, allowing organizations to apply only the controls that are actually required for each scope. This simplifies governance, improves architectural readability, and makes the dialogue between cloud, security, compliance, and risk management teams more effective. A further benefit is the reduced maintenance burden. By using built-in initiatives managed directly by the Microsoft product group responsible for sovereignty scenarios, customers can benefit from future updates without having to maintain customized copies of the policies within their own SLZ implementation. Moreover, because these are built-in initiatives, the policies integrate natively with tools such as Azure Policy compliance reporting and Microsoft Defender for Cloud, facilitating auditing activities and the production of compliance evidence.
Deploying Ansible playbooks through Azure Policy and Machine Configuration (preview)
Microsoft has announced the private preview of a new capability that enables the deployment and execution of Ansible playbooks through Azure Policy by using Machine Configuration on Linux machines in Azure and on Azure Arc-enabled Linux servers. This update is part of the Azure Arc strategy to unify security, compliance, and management for Windows and Linux systems, regardless of whether they are located in on-premises datacenters, at the edge, or across public clouds. The new capability makes it possible to orchestrate playbook execution directly from the Azure control plane, without the need to provision a dedicated Ansible control node, while also integrating compliance reporting and automatic remediation mechanisms. In increasingly heterogeneous operating environments, many organizations use Ansible to configure operating systems and applications, but face challenges in ensuring configuration consistency, detecting drift over time, and integrating those automations into centralized governance processes. With this preview, Azure Policy becomes a single control point also for Ansible-based Linux automation, bringing these workloads into the same governance model already adopted for other environments. Playbook execution results and compliance status are made visible directly in the Azure Policy compliance dashboard, providing a unified management, security, and control experience while also preserving the value of the investments organizations have already made in the Ansible ecosystem.
Backup & Resilience
Azure Backup
Configuring AKS backup with a single command using Azure Backup
Microsoft has announced a new simplified Azure CLI-based experience that enables Azure Kubernetes Service (AKS) backup to be configured with a single command through Azure Backup. This update addresses the need to reduce the complexity of onboarding AKS clusters to data protection, a process that previously required coordination across multiple CLI domains and the execution of several separate steps, including extension installation, storage account provisioning, backup vault creation, policy definition, trusted access configuration, and backup instance initialization. With this new approach, platform teams can significantly accelerate the enablement of cluster protection, making it easier to integrate backup into automation processes and CI/CD pipelines. The initiative is part of a broader strategy aimed at making Azure Backup increasingly suitable for cloud-native scenarios, with the goal of extending a similar experience over time to other workloads supported by the service.
Azure Backup for Elastic SAN (preview)
Azure Backup introduces support for Elastic SAN in Public Preview, offering a fully managed solution for backing up and restoring Elastic SAN volumes. This new capability makes it possible to protect data from critical scenarios such as accidental deletion, ransomware incidents, or failed application updates by exporting Elastic SAN volumes to independent, incremental snapshots based on Managed Disks. The snapshots are stored in Locally Redundant Storage (LRS) and remain separate from the lifecycle of the original Elastic SAN volume, increasing the level of operational resilience. In this preview phase, the solution supports up to 450 recovery points with a backup frequency of every 24 hours, is available only in selected Azure regions, and supports volumes of up to 4 TiB. Microsoft also clarifies that, during the preview, long-term backups in vaults and hourly backup frequencies are not yet supported. Although no Azure Backup Protected Instance charges are applied during this preview phase, the standard costs associated with incremental Managed Disk snapshots still apply.
Azure Site Recovery
Azure Site Recovery supports Azure Windows VMs with NVMe disk controllers (preview)
Azure Site Recovery extends support for replication and disaster recovery of Azure Windows virtual machines running on second-generation VM families enabled for NVMe, currently in Public Preview. Supported scenarios include Azure-to-Azure protection for series such as Da/Ea/Fa v6 and Ebsv5/Ebdsv5, which allow high-performance and I/O-intensive workloads to run using the NVMe disk controller. This update significantly expands the service coverage for performance-sensitive virtual machines, offering new resiliency opportunities for critical applications and advanced enterprise scenarios. The capability is available in all Azure public cloud regions, within the churn limits supported by Azure Site Recovery.
Monitoring
Azure Monitor
Monitoring AKS applications with OpenTelemetry and Azure Monitor (preview)
Azure Monitor introduces, in Public Preview, support for monitoring applications running on Azure Kubernetes Service (AKS) by using OpenTelemetry for instrumentation and data collection. Customers can choose an auto-instrumentation approach by deploying the Azure Monitor OpenTelemetry distribution directly on their workloads, or adopt an auto-configuration mode to route OpenTelemetry Protocol (OTLP) signals from applications already instrumented with open-source, vendor-neutral SDKs to Azure Monitor. This evolution simplifies the implementation of observability in AKS environments while strengthening alignment with open standards in the cloud-native ecosystem, promoting greater interoperability and more consistent management of application telemetry.
Azure Monitor for Azure Arc-enabled Kubernetes environments based on OpenShift and Azure Red Hat OpenShift
Azure Monitor extends its availability, in General Availability, to Azure Arc-enabled Kubernetes environments based on OpenShift and Azure Red Hat OpenShift through Container Insights and Managed Prometheus. This evolution enables organizations to obtain a comprehensive monitoring experience for Kubernetes infrastructure layers and the applications running on them, strengthening observability capabilities in hybrid and cloud-native scenarios. Thanks to this integration, IT teams can collect, analyze, and visualize operational telemetry from OpenShift environments, improving troubleshooting, performance management, and health monitoring for distributed workloads. This is an important step toward an increasingly centralized management model, where Azure Monitor becomes the reference point also for Kubernetes platforms running outside the traditional Azure perimeter.
Azure Monitor pipeline
Azure Monitor pipeline is now generally available and introduces an advanced layer of control over telemetry collection, transformation, and resilience before data reaches Azure Monitor. This capability allows logs to be routed directly to Azure-native schemas through automatic schema mapping into tables such as Syslog and CommonSecurityLog. A particularly relevant element is the ability to reduce the risk of data loss in the presence of intermittent connectivity through local buffering on persistent storage and subsequent automatic backfill. Azure Monitor pipeline also enables organizations to optimize ingestion costs by applying centralized filtering, aggregation, and transformation logic before data is sent to the cloud. The solution is designed to support high and continuous telemetry volumes through a scalable architecture, and also includes capabilities for secure ingestion through Transport Layer Security (TLS) and mutual TLS (mTLS), automatic certificate provisioning, visibility into the health of the ingestion infrastructure, and sizing tools for large-scale planning.
Native ingestion of OpenTelemetry Protocol (OTLP) signals through Azure Monitor Agent (preview)
Azure Monitor introduces, in Public Preview, support for native ingestion of OpenTelemetry Protocol (OTLP) signals through Azure Monitor Agent (AMA). This capability enables applications instrumented with OpenTelemetry to send telemetry directly to Azure Monitor, with Azure Monitor Agent receiving OTLP signals from the applications and exporting them to the monitoring platform. Microsoft supports several OTLP ingestion mechanisms, including OpenTelemetry Collector, Azure Monitor Agent, and the Azure Kubernetes Service (AKS) add-on. The approach based on Azure Monitor Agent is designed in particular for applications running on Azure Virtual Machines, Virtual Machine Scale Sets, or Azure Arc-enabled servers. This evolution helps organizations standardize observability by adopting open standards, simplifying telemetry collection across cloud, hybrid, and distributed environments, and strengthening the path toward a more uniform and proactive management model.
Conclusions
The April 2026 updates confirm the evolution of Azure as a central platform for the management, security, governance, and observability of hybrid and multicloud environments. Azure Arc continues to strengthen its role as a key element for extending Azure control to distributed servers, databases, and workloads, with increased focus on automation, security, and continuous agent updates. At the same time, Microsoft Defender for Cloud expands its runtime protection capabilities, particularly for containers, Kubernetes, storage, and SQL Server, offering an increasingly consistent security posture across Azure, Amazon Web Services (AWS), Google Cloud, and on-premises environments. Governance is also taking a step forward, thanks to the evolution of Azure Landing Zones, the new sovereign initiatives, and the integration of Azure Policy with automation scenarios such as Ansible. These capabilities help organizations standardize configurations, reduce drift, and apply consistent controls across distributed infrastructures. On the resilience and monitoring side, Azure Backup, Azure Site Recovery, and Azure Monitor extend support to modern workloads such as Azure Kubernetes Service (AKS), Elastic SAN, NVMe virtual machines, OpenShift, and OpenTelemetry-based applications, simplifying protection, disaster recovery, and observability. Overall, the message is clear: the management of hybrid and multicloud environments must become increasingly automated, secure, and centrally governed. The recommendation is therefore to assess these updates as building blocks of an integrated strategy, starting from Azure Arc, Azure Policy, Defender for Cloud, Backup, and Monitor to build a more consistent, resilient, and scalable operating model.
