A New Platform Management Group & Subscription for Security in Azure landing zone (ALZ)
At the start of 2025, during the January 2025 ALZ Community Call, we asked everyone for their feedback, via these discussions on our GitHub repo: 1898 & 1978 , on the future of Microsoft Sentinel in the Azure landing zone (ALZ) architecture as we were receiving feedback that it needed some changes and additional clarity from what ALZ was deploying and advising then. We have now worked with customers, partners, and internal teams to figure out what we should update in ALZ around Microsoft Sentinel and Security tooling and have updated the ALZ conceptual architecture to show this. What did ALZ advise and deploy before, by default? Prior to these updates ALZ advised the following: The central Log Analytics Workspace (LAW) in the Management Subscription should Be used to capture all logs, including security/SIEM logs The Microsoft Sentinel solution (called Security) should be installed upon this LAW also And in the accelerators and tooling it deployed, by default: The central Log Analytics Workspace (LAW) in the Management Subscription with the Microsoft Sentinel solution installed Microsoft Sentinel had no additional configuration apart from being installed as a solution on the central LAW What are the changes being made to ALZ from today? Based on the feedback from the GitHub discussions and working with customers, partners and internal teams we are making the following changes: A new dedicated Security Management Group beneath the Platform Management Group A new dedicated Security Subscription placed in the new Security Management Group Nothing will be deployed into this subscription by ALZ by default. This allows: Customers & partners to deploy and manage the Microsoft Sentinel deployment how they wish to The 31-day 10GB/day free trial can be started when the customer or partner is ready to utilise it No longer deploy the Microsoft Sentinel solution (called Security) on the central LAW in the Management Subscription This allows for separating of operational/platform logs from security logs, as per considerations documented in Design a Log Analytics workspace architecture The changes have only been made to our ALZ CAF/MS Learn guidance as of now, and the changes to the accelerators and implementation tools will be made over the coming months đ These changes can be seen in the latest ALZ conceptual architecture snippet below The full ALZ conceptual architecture can be seen here on MS Learn. You can also download a Visio or PDF copy of all the ALZ diagrams. What if we have already deployed ALZ? If you have already deployed ALZ and haven't tailored the ALZ default Management Group hierarchy to create a Security Management Group then you can now review and decide whether this is something you'd like to create and align with. While not mandatory, this enhancement to the ALZ architecture is recommended for new customers. The previous approach remains valid; however, feedback from customers, partners, and internal teams indicates that using a dedicated Microsoft Sentinel and Log Analytics Workspace within a separate security-focused Subscription and Management Group is a common real-world practice. To reflect these real-world implementations and feedback, weâre evolving the ALZ conceptual architecture accordingly đ Closing We hope you benefit from this update to the ALZ conceptual architecture. As always we welcome any feedback via our GitHub Issues
GA: Enhanced Audit in Azure Security Baseline for Linux
Weâre thrilled to announce the General Availability (GA) of the Enhanced Azure Security Baseline for Linuxâa major milestone in cloud-native security and compliance. This release brings powerful, audit-only capabilities to over 1.6 million Linux devices across all Azure regions, helping enterprise customers and IT administrators monitor and maintain secure configurations at scale. What Is the Azure Security Baseline for Linux? The Azure Security Baseline for Linux is a set of pre-configured security recommendations delivered through Azure Policy and Azure Machine Configuration. It enables organizations to continuously audit Linux virtual machines and Arc-enabled servers against industry-standard benchmarksâwithout enforcing changes or triggering auto-remediation. This GA release focuses on enhanced audit capabilities, giving teams deep visibility into configuration drift and compliance gaps across their Linux estate. For our remediation experience, there is a limited public preview available here: What is the Azure security baseline for Linux? | Microsoft Learn Why Enhanced Audit Matters In todayâs hybrid environments, maintaining compliance across diverse Linux distributions is a challenge. The enhanced audit mode provides: Granular insights into each configuration check Industry aligned benchmark for standardized security posture Detailed rule-level reporting with evidence and context Scalable deployment across Azure and Arc-enabled machines Whether you're preparing for an audit, hardening your infrastructure, or simply tracking configuration drift, enhanced audit gives you the clarity and control you needâwithout enforcing changes. Key Features at GA â Broad Linux Distribution Support đ Full distro list: Supported Client Types đ Industry-Aligned Audit Checks The baseline audits over 200+ security controls per machine, aligned to industry benchmarks such as CIS. These checks cover: OS hardening Network and firewall configuration SSH and remote access settings Logging and auditing Kernel parameters and system services Each finding includes a description and the actual configuration stateâmaking it easy to understand and act on. đ Hybrid Cloud Coverage The baseline works across: Azure virtual machines Arc-enabled servers (on-premises or other clouds) This means you can apply a consistent compliance standard across your entire Linux estateâwhether itâs in Azure, on-prem, or multi-cloud. đ§ Powered by Azure OSConfig The audit engine is built on the open-source Azure OSConfig framework, which performs Linux-native checks with minimal performance impact. OSConfig is modular, transparent, and optimized for scaleâgiving you confidence in the accuracy of audit results. đ Enterprise-Scale Reporting Audit results are surfaced in: Azure Policy compliance dashboard Azure Resource Graph Explorer Microsoft Defender for Cloud (Recommendations view) You can query, export, and visualize compliance data across thousands of machinesâmaking it easy to track progress and share insights with stakeholders. đ° Cost Thereâs no premium SKU or license required to use the audit capabilities with charges only applying to the Azure Arc managed workloads hosted on-premises or other CSP environmentsâmaking it easy to adopt across your environment. How to Get Started Review the Quickstart Guide đ Quickstart: Audit Azure Security Baseline for Linux Assign the Built-In Policy Search for âLinux machines should meet requirements for the Azure compute security baselineâ in Azure Policy and assign it to your desired scope. Monitor Compliance Use Azure Policy and Resource Graph to track audit results and identify non-compliant machines. Plan Remediation While this release does not include auto-remediation, the detailed audit findings make it easy to plan manual or scripted fixes. Final Thoughts This GA release marks a major step forward in securing Linux workloads at scale. With enhanced audit now available, enterprise teams can: Improve visibility into Linux security posture Align with industry benchmarks Streamline compliance reporting Reduce risk across cloud and hybrid environmentsDesigning for Certainty: How Azure Capacity Reservations Safeguard MissionâCritical Workloads
Why capacity reservations matter now Cloud isnât running out of metal, but demand is compounding and often spikes. Resource strain shows up in specific regions, zones, and VM SKUs, especially for popular CPU families, memory-optimized sizes, and anything involving GPUs. Seasonal events (retail peaks), regulatory cutovers, emergency response, and bursty AI pipelines can trigger sudden surges. Even with healthy regional capacity, a single zone or a specific SKU can be tight. Capacity reservations acknowledge this reality and make it designable instead of probabilistic. Root reality: Capacity is finite at the SKU-in-zone granularity, and demand arrives in waves. Risk profile: The risk is not âno capacity in the cloud,â but âno capacity for this exact size in this exact place at this exact moment.â Strategic move: Reserve what matters, where it matters, before you need it. What capacity means in practice Think of three dimensions: region, zone, and SKU. Your workloadâs SLO ties to all three. Region: The biggest pool of resources. It gives you flexibility but doesnât guarantee availability in a specific zone. Zone: This is where fault isolation happens and where youâll often feel the pinch first when demand spikes. SKU: The specific type of machine youâre asking for. This is usually the tightest constraint, especially for popular sizes like Dv5, Ev5, or anything with GPUs. Azure Capacity Reservations let you lock capacity for a specific VM size at the regional or zonal scope and then place VMs/scale sets into that reservation. Payâasâyouâgo vs capacity reservations vs reserved instances Attribute Payâasâyouâgo Capacity Reservations Reserved Instances Primary purpose Flexibility, no commitment Guarantee availability for a VM size Reduce price for steady usage What it guarantees Nothing beyond current availability Capacity in region/zone for N of a SKU Discount on matching usage (1â or 3âyear term) Scope Region/zone at runtime, bestâeffort Bound to region or specific zone Billing benefit across scope rules Commitment None Active while you keep it (onâdemand) Term commitment (1 or 3 years) Key clarifications Capacity reservations â discount tool: They exist to secure availability. You pay while the reservation is active (even if idle) because Azure is holding that capacity for you. Reserved Instances â capacity guarantee: They reduce the rate you pay when you run matching VMs, but they donât hold hardware for you. Together: Use Capacity Reservations to ensure the VMs can run; use Reserved Instances to lower the cost of the runtime those VMs consume. This is universal, not just Azure Every major cloud faces the same physics: finite hardware, localized spikes, SKU-specific constraints, and growth in high-demand families (especially GPUs). AWS offers OnâDemand Capacity Reservations; Google Cloud offers zonal reservations. The names differ; the pattern and the need are the same. If your architecture depends on âmust run here, as this size, and right now,â you either design for capacity or accept availability risk. When missionâcritical means âreserve itâ If failure to acquire capacity breaks your SLO, treat capacity as a dependency to engineer, not a variable to assume. High-stakes cutovers and events: Examples: Black Friday, tax deadlines, trading close, clinical batch windows. Action: Preâreserve the exact SKU in the exact zones for the surge window. HA across zones: Goal: Survive a zone failure by scaling in active zones. Action: Consider keeping extra capacity in each zone based on your failover plan, whether thatâs N+1 or matching peak load, depending on active/active vs. active/passive. Change windows that deallocate/recreate: Risk: If a VM is deallocated during maintenance, it might not get the same placement when restarted. Action: Associate VMs/VMSS with a capacity reservation group before deallocation. FixedâSKU dependencies: Signal: Performance needs, licensing rules, or hardware accelerators that lock you into a specific VM family. Action: Reserve by SKU. If possible, define fallback SKUs and split reservations across them. Regulated or latencyâsensitive workloads: Constraint: Must run in a specific zone or region due to compliance or latency. Action: Prefer zonal reservations to control both locality and availability. How reserved instances complement capacity reservations Two-layer strategy: Layer 1: Availability: Capacity reservations ensure your compute can be placed when needed. Layer 2: Economics: Reserved Instances (or Savings Plans) apply a pricing benefit to the steadyâstate hours you actually run. Practical pairing: Steady base load: Cover with 1/3âyear Reserved Instances for maximum savings. Critical surge headroom: Hold with Capacity Reservations; if the surge is predictable, you can still layer partial RI coverage aligned to expected utilization. Dynamic burst: Leave as payâasâyouâgo or use shortâlived reservations during known windows. FinOps hygiene: Coverage ratios: Track RI coverage and capacity reservation utilization separately. Rightsizing: Align reservations to the SKU mix you truly run; shift or cancel idle capacity reservations quickly. Chargeback: Attribute the cost of âinsuranceâ (capacity) to the workloads that require the SLO, separate from the cost of âfuelâ (compute hours). Conclusion In todayâs cloud landscape, resilience isnât just redundancy; itâs about assured access to the exact resources your workload demands. Capacity Reservations remove uncertainty by guaranteeing placement, while Reserved Instances drive cost efficiency for predictable use. Together, they form a strategic duo that keeps missionâcritical services running smoothly under any demand surge. Build with both in mind, and you turn capacity from a risk into a controlled asset.
Announcing Public Preview for Azure Service Groups!
What are Service groups? Service Groups are a new resource container enabling management and observability scenarios where flexibility in hierarchy and membership is needed. Service Groups are tenant level resources so they can have members across the tenant but do not interfere or use tenant-wide RBAC or Policy abilities. Key Features Low Privilege Management: Service Groups are designed to operate with minimal permissions, ensuring that users can manage resources without needing excessive access and appealing to multiple personas. Access to a Service Group does not grant role-based access control or policy inheritance to its members. Flexible and Varying Hierarchies: Azure resources and scopes, from anywhere in the tenant, can become members of one or multiple service groups. Additionally, Service Groups can be nested providing the ability to have multiple hierarchy structures, i.e. Cost Center, Product, Organization, and more! Monitoring Capabilities: From your application to infrastructure health, Azure Monitor features (such as Health Models) are now available to help you troubleshoot, investigate, and monitor your Service Group. When should I use them? Service Groups should be leveraged in scenarios where resources sprawl across existing containers making it difficult to monitor and manage them. This is commonly found in scenarios needing to model application hierarchy, company services and workloads. Service Groups cannot be used as a deployment scope nor to manage Policy nor RBAC. Try it out! Quickly start with Service Groups using REST API or Azure Portal! For more information on Service Groups, please visit aka.ms/servicegroups. FAQ⯠Do Service Groups replace existing Azure groups? âŻâŻ No, Service Groups have been designed to work in parallel with existing Azure Groups. For a comparison of existing scopes, please review the scenario comparison documentation. Who can create Service Groups? Anyone with a valid Azure user account in a Microsoft Entra directory can leverage Service Groups! Why are Service Groups tenant level? Service Groups are tenant level so they can have membership from across the tenant. However, unlike pre-existing tenant level resources (i.e, Management Groups), Service Groups do not have grant users' tenant wide access. Share Your Feedback You can reach our team by email at azureservicegroups@microsoft.com.Upgrading your server and client TLS protocol just got easier using Automanage Machine Configuration
Ensuring secure communication protocols across server environments has been a clear requirement for IT admins, operators, and developers for the past two decades. What wasnât clear was how to set a desired communication protocol and maintain this at scale, until now. Tech Communityđ¨ Azure Service Health Built-In Policy (Preview) â Now Available!
Resiliency is a key focus for Microsoft in making sure our customers experience minimal impact due to planned or unexpected outages that may occur. Up until now there has been no native scalable solution to provide consistent notifications across Azure subscriptions for Service Health events. Building on the success of Azure Monitor Baseline Alerts (AMBA) where this functionality is currently available, the AMBA team has combined with the Service Health Product team to include this capability into the Azure native experience. Weâre excited to announce the release of Azure Service Health Built-In Policy (Preview), a new built-in Azure Policy designed to simplify and scale the deployment of Service Health alerts across your Azure environment. This policy enables customers to automatically deploy Service Health alerts across subscriptions, ensuring consistent visibility into platform-level issues that may impact workloads. Existing subscriptions can be remediated in bulk and new Azure subscriptions, created once the Policy has been assigned, will automatically be configured for receiving Service Health alerts. đ What's the purpose of this announcement? It addresses situations where customers only permit the use of built-in policies. It automates the setup of Service Health alerts across all subscriptions when deployed at the management group level. It ensures consistent alert coverage for platform events. It helps reduce manual setup and ongoing maintenance. đ ď¸ What options are available with the Policy? All the learnings from AMBA have been taken into consideration in designing and creating this policy. There are now a wide range of options available to provide flexibility based on your needs. These options are surfaced as parameters within the policy: It audits the existing environment for compliance. It ensures the ability to provide custom alert rules that align with the naming standards. It gives the ability to choose the types of Service Health events to monitor. It supports Bring-your-own Action Group, or the ability to create a new Action Group as part of the Policy assignment. For ARM role notification, it ensures the ability to choose from a pre-set list of built-in roles for notifications. It provides the ability to choose from email, Logic App, Event Hubs, webhook, and Azure Functions within the Action Group. It enables naming Resource groups, and location flexibility. It gives the ability to add Resource tags. 𧊠What about Azure Monitor Baseline Alerts? The AMBA team have been working to incorporate the newly built-in policy into a future release. The team plans to roll this out in the next few weeks along with details for existing customers on replacing the existing AMBA custom policy. These changes will then be consumed into Azure Landing Zones. AMBA continues to offer a wide range of alerts for both platform and workload services in addition to Service Health alerts. This announcement does not serve as a replacement for AMBA but simply compliments the AMBA solution. đŁ Whatâs Next? Check out the guidance on leveraging this policy in your environment Deploy Service Health alert rules at scale using Azure Policy - Azure Service Health Should you require support for this policy please raise a support ticket via the portal as comments raised below may not be addressed in a timely mannerAnnouncing AuthorizationResources in Azure Resource Graph
We are excited to announce support for Azure RBAC resources in Azure Resource Graph (ARG) via the AuthorizationResources table! You can now query your Role Assignments, Role Definitions, and Classic Admins resources. This will unlock a set of new scenarios to be able to get visibility into the access controls that are defined and used within customer environments at scale.
