[Public Preview] Introducing Customizable Security Baseline Policies in Machine Configuration
Background: Azure Machine Configuration remains committed to enabling greater security and simplicity in at-scale server management for all Azure customers. Machine Configuration (previously known as Azure Policy Guest Configuration) enables both built-in and custom configuration as code allowing you to audit and configure OS, app, and workload level settings at scale, both for machines running in Azure and hybrid Azure Arc-enabled servers. We’re excited to announce Public Preview support for Customizable Security Baselines in Azure Policy and Machine Configuration. This feature empowers you to tailor industry security benchmarks—such as CIS benchmarks for Linux or Azure Security Baselines for Windows and Linux —to align with your organization’s unique compliance standards across both Azure and Arc-connected machines. This feature builds on top of our existing audit baseline capabilities for Windows and Linux. Now you can create, parameterize, and assign custom baselines at scale, enabling continuous compliance visibility across your entire environment. Learn more about how to get started here: Customize Security Baselines with Azure Policy and Machine Configuration. What's New? Customizable security baselines in Azure Policy and Machine Configuration bring a powerful new way to assess, monitor, and improve your security posture across both Windows and Linux servers. Built on industry benchmarks such as the Center for Internet Security (CIS) and Microsoft’s own Azure Compute Security Baselines, this capability enables you to adapt compliance frameworks to your organization’s specific needs — all while maintaining a consistent governance model across Azure and hybrid environments. By passing custom baseline parameters directly into Azure Policy, you can represent internal controls at scale, ensuring that compliance reflects your enterprise’s unique standards and regulatory requirements. This cloud-native approach embodies Microsoft’s Secure by Design and Secure by Default principles — ensuring your workloads stay compliant, wherever they run. Key Scenarios Baseline Customization Tailor your security standards through the Modify Settings wizard under Policy > Machine Configuration. You can: Enable, exclude, or adjust rules from existing benchmarks Apply organization-specific parameters Export your custom configuration as a downloadable JSON file Each baseline JSON file serves as a reusable, declarative artifact—ideal for policy-as-code workflows, version control, and CI/CD integration. Assign Audit Policies When you assign a baseline via Azure Policy, it automatically: Evaluates configurations against your defined standards Reports compliance in near real time Surfaces findings in Azure Policy, Azure Resource Graph, and the Guest Assignments view This integrated visibility helps IT administrators, security teams, and auditors track compliance status with minimal overhead. Integration and Automation Security baselines integrate seamlessly into your DevOps pipelines and configuration management workflows. Each baseline produces a declarative settings catalog (JSON) that can be versioned and deployed using: Azure CLI ARM templates Bicep CI/CD automation This ensures reproducible, traceable compliance configurations across environments. Supported Standards Standard Description CIS Linux Benchmarks Official CIS Benchmarks for Azure-endorsed Linux distributions, matching the latest CIS versions. Azure Compute Security Baseline for Windows Applies security controls for Windows Server 2022 and 2025, aligned with Azure Compute guidance. Azure Compute Security Baseline for Linux Enforces consistent controls aligned with Azure Compute recommendations. Availability Customizable security baselines are available in all public Azure regions. NOTE: Support for Azure Government and Sovereign Clouds will be added in a future release. These environments are not included in the current Public Preview. Getting Started Prerequisites Before you begin: Deploy the Azure Machine Configuration prerequisite policy initiative. (This installs the required Guest Configuration extension on supported VMs.) Ensure your Azure subscription or management group includes supported Windows or Linux VMs. Have sufficient permissions (Owner or Resource Policy Contributor) to create and assign custom policy definitions. Step-by-Step Guidance Select a baseline from the Machine Configuration tab in Azure Policy. Modify settings to enable, exclude, or parameterize rules to match your internal policies. Download JSON to export your customized baseline configuration file for programmatic and repeatable customization. Assign the policy which can be deployed through the Azure portal, CLI, or your CI/CD pipeline. Review compliance results to track outcomes in Azure Policy, Azure Resource Graph, or the Guest Assignments page. Coming Soon Leverage baseline customization to gradually remediate server security non-compliance using Azure Policy! Join the waitlist here: https://aka.ms/BaselineRemediationWaitlist Learn More Azure Machine Configuration security baselines official documentation CIS Benchmark for Linux documentation Azure Windows Baseline and Azure Linux Baseline documentation Please note that the use of Azure Machine Configuration on Azure Arc-enabled servers will incur a charge.
What’s new in Azure Local: Cloud infrastructure for distributed locations enabled by Azure Arc
Today’s enterprises are navigating competing challenges: delivering AI-enabled digital experiences at the edge while also meeting growing demands for data sovereignty and regulatory compliance. Whether it’s a hospital needing local compute for patient care, or a government agency requiring full control over its infrastructure, the need for flexible, secure, and cloud scale solutions has never been greater. That’s why we introduced Azure Local—Microsoft’s solution for running Azure services and workloads at distributed locations, all managed through Azure Arc. With Azure Local, customers can deploy cloud-native and traditional applications on their own infrastructure while maintaining centralized visibility and control through the Azure portal. This approach is resonating: Microsoft has been named a Leader in the Gartner® Magic Quadrant™ for Distributed Hybrid Infrastructure every year since its inception. Azure Local is the foundation of Microsoft’s Sovereign Private Cloud, delivering Azure consistent services in customer controlled environments which meet strict data residency and compliance requirements. Read more about our recent Sovereign announcements here. See the Sovereign Private Cloud come to life here: Today, we’re so excited to tell you about the incredible new capabilities on Azure Local including support for external SAN storage, rack aware clustering, larger scale deployments, and more. Operate and scale with the power of the cloud Azure Local empowers organizations to operate and scale infrastructure with the power of the cloud, no matter where it’s deployed. From the Azure portal, customers can define and deploy infrastructure across distributed locations, apply one-click updates to entire clusters, and centrally monitor performance, health, and security. This cloud-based control plane ensures consistency and agility across environments—whether in datacenters, branch offices, or sovereign sites. NEW: Local Identity with Azure Key Vault (Preview) Azure Local now supports deployments without Active Directory using local identity with Azure Key Vault, currently in preview. This new option simplifies setup by removing the need for domain controllers, while still providing secure access and centralized secret management through Azure. Read the announcement here. Ready for all your apps, VMs and containers alike Azure Local is built to run all your applications—whether they’re virtual machines, containers, or Azure services. It offers full-featured, general-purpose VMs with cloud-consistent management, and includes Azure Kubernetes Service (AKS) built-in for modern containerized workloads. Customers can also deploy some of Azure’s most popular PaaS services like Azure Virtual Desktop, SQL Managed Instance, and Azure IoT Operations directly on Azure Local. With support for GPU-enabled nodes and Arc VM extensions, Azure Local is ready for everything from legacy line-of-business apps to AI-powered workloads. Migrate from VMware to Azure Local (Generally Available) Azure Migrate from VMware to Azure Local is now generally available, enabling customers to seamlessly move VMware virtual machines into their Azure Local infrastructure. This agentless migration path keeps data flows local, minimizes downtime, and simplifies onboarding with a cloud-consistent experience. Customers can discover, replicate, and migrate workloads using the Azure portal, with support for validated hardware and reference architectures. Azure Migrate unlocks a fast path to modernization for organizations consolidating legacy infrastructure. Read the announcement here. Customer Spotlight: How Publix Employees Federal Credit Union strengthened its disaster recovery strategy with Azure Loc... NEW: Microsoft 365 Local to meet your Private Sovereign Cloud needs (Generally Available) Microsoft 365 Local brings trusted productivity services like Exchange Server, SharePoint Server, and Skype for Business Server into customer-controlled environments, running directly on Azure Local infrastructure. Designed for those who need productivity tools in a private cloud environment, it leverages Azure Arc to provide a unified control plane for easy infrastructure management, simplified deployment, and streamlined updates. The solution features a validated reference architecture with certified hardware to ensure optimal performance and reliability, along with a hardened security baseline and robust controls to safeguard your infrastructure. It’s a key part of Microsoft’s Sovereign Private Cloud strategy, now generally available. Read the announcement here. Flexibility to meet your requirements Azure Local gives customers the flexibility to deploy infrastructure that fits their exact needs—whether that’s choosing from over 100 validated hardware platforms in the Azure Local catalog or operating in fully connected or disconnected environments. You can run Azure Local in public Azure regions or in Azure Government cloud, supporting both commercial and regulated workloads. Azure Local adapts to everything from retail edge sites to sovereign datacenters, disconnected oil rigs to connected manufacturing plants, all while maintaining a consistent Azure management experience. NEW: SAN Support (Preview) Azure Local now delivers greater infrastructure flexibility with expanded support for leading external SAN storage solutions, a capability that customers have long sought. Customers can now integrate their existing Fiber Channel-based SAN storage from leading vendors such as Pure Storage, NetApp, Dell, Lenovo, HPE, and Hitachi directly with Azure Local clusters. External storage support allows organizations to achieve high performance, scalability, and resilience while continuing to use their trusted storage infrastructure. It also enables consistent management across virtual machines, AKS clusters, and Arc-enabled services through the familiar Azure experience. Customers now have the freedom to modernize their environments while maximizing the value of their existing investments. Our customers are already exploring the impact this brings to enterprise customers. “We’re excited to partner with Microsoft and their trusted storage vendors to test external storage support for Azure Local,” said David McKenney, VP of Public Cloud Products at TierPoint. “This milestone gives customers greater flexibility to address performance, scalability, resilience, and investment protection needs. It reflects Microsoft’s ongoing dedication to making Azure Local the leading distributed cloud solution by listening to the needs of their customers and partners.” Support for more Storage protocols and other storage capabilities coming soon. Reach out to Microsoft or our storage partners to be part of this limited preview. NEW: Rack Aware Clusters (Preview) Rack aware clustering is now available in preview for Azure Local, enabling intelligent placement and resiliency across multi-rack deployments using one storage pool. This feature allows Azure Local to detect physical rack boundaries and distribute workloads accordingly, improving fault tolerance and minimizing impact from localized hardware failures. It’s especially valuable for larger deployments where high availability and service continuity are critical. Rack awareness integrates seamlessly with Azure Local’s update orchestration and VM placement logic, helping ensure infrastructure stays resilient at scale. Read the announcement here. NEW: Support for NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs (Generally Available) Azure Local now supports the NVIDIA RTX PRO 6000 Blackwell Server Edition GPU, generally available for high-performance workloads including AI inferencing, simulation, and visualization. This enterprise-grade GPU delivers exceptional compute density and energy efficiency, making it ideal for deployments that require advanced acceleration. Customers can deploy this powerful GPU in new Azure Local solutions—including Dell AX-770, Lenovo ThinkAgile MX650a V4, and HPE ProLiant DL380 Gen 12. Read the announcement here. NEW: Azure Local for larger deployments (Preview) Azure Local now scales further, with instances of up to 10,000+ cores across 100+ nodes delivered as multiple integrated racks with disaggregated storage. This enables customers to run the same familiar Azure Arc-enabled infrastructure and services at significantly larger scale, supporting a greater variety of workloads and scenarios. This new capability is available now in preview. Contact your Azure account representatives to learn more. Secure by default Azure Local is built with security at its core, offering a hardened infrastructure stack aligned with Microsoft’s secure-by-default principles, built-in Microsoft Defender for Cloud integration, and trusted launch VMs. Every VM is Azure Arc-enabled, allowing customers to apply security baselines, monitor threats, and enforce policies using familiar Azure tools. These protections are automatically enabled, so customers can operate confidently from day one. Network segmentation (Generally Available) To protect and isolate your network traffic between VMs or logical networks, Azure Local now supports network security groups (NSGs), generally available as of the 2510 release. NSGs enable precise filtering of network traffic using policy-driven access controls by applying inbound and outbound allow/deny rules. Rules support the full five-tuple of source IP, source port, destination IP, destination port, and protocol, and are enforced within the virtual switch at the virtual port level. NSGs can be applied to both logical networks and individual network interfaces and can be managed using the Azure Portal for centralized policy management of your edge workloads. Read the announcement here. Get Started Today For new production deployments Azure Local is generally available for production use. Explore the solutions catalog to find hardware from your preferred vendor and read the deployment overview to get started today. For evaluation (virtual) Want to try out Azure Local but don’t have hardware? Get a dedicated Azure Local sandbox in one click with Azure Arc Jumpstart. All you need is an Azure subscription to get started. Thank you! As we mark the second year since announcing Azure Local, we want to extend a heartfelt thank you to our customers, partners, and community. It’s incredibly rewarding to see Azure Local continue to be the infrastructure of choice for enterprises seeking flexibility, security, and innovation at the edge. We’re excited to continue delivering the solutions you need to thrive in a rapidly evolving world. Thank you for trusting Azure Local to power your most important workloads—here’s to another year of partnership and progress! If you’re at Ignite this week, please come say hello at: Our session dedicated to Azure Local What’s new in Azure Local Our booth “Azure Arc and Azure Local” in the Cloud and AI Platforms neighborhood See everything going on with Adaptive Cloud on our Ignite website Adaptive Cloud @Ignite 2025 FAQ What is Azure Local? Azure Local is Microsoft’s full-stack infrastructure software that runs on validated hardware in your own facilities. It brings Azure capabilities to distributed or sovereign locations, so you can run virtual machines, containers, and select Azure services locally while maintaining a consistent management experience through Azure Arc. How are Azure Local and Private Sovereign Cloud related? Azure Local is the foundation and core product fueling Microsoft’s Private Sovereign Cloud offering. It enables customers to meet strict data residency and regulatory requirements by hosting workloads on-premises, disconnected or semi-connected, while still benefiting from Azure innovation and security. When should I use Azure Local? Use Azure Local when you need modern cloud capabilities in locations where connectivity is limited, data sovereignty is critical, or latency-sensitive applications must run close to where data is generated. It’s ideal for industries like manufacturing, retail, and government that require local control with Azure consistency.Build Smarter, Simpler IoT Messaging with Azure Event Grid MQTT Broker
Why this matters for modern IoT solutions As IoT solutions grow, teams need messaging that is reliable, scalable, and simple enough to operate across devices, apps, and cloud services. Azure Event Grid MQTT broker helps organizations connect devices and applications using standard MQTT patterns while also integrating with Azure services for downstream processing and automation. The result is a managed, cloud-native approach to messaging that supports both technical flexibility and business agility. With support for MQTT v3.1.1 and MQTT v5, Azure Event Grid MQTT broker enables device-to-device, device-to-cloud, and server-to-device communication patterns. It is especially useful in scenarios where customers want to ingest telemetry, send commands, broadcast alerts, and route data into analytics or workflow systems without building and maintaining broker infrastructure themselves. In this post, we focus on four capabilities that make the experience even more powerful and easier to adopt: MQTT Retain support, Shared Subscriptions, HTTP Publish of MQTT messages, and Subscription Identifiers. These features help new subscribers get context immediately, allow multiple consumers to scale out work, let HTTP-native back-end services participate in MQTT workflows, and make message handling more efficient for clients. Four features that make MQTT messaging easier to use These capabilities are designed to solve everyday problems that customers face when building real-world IoT systems. MQTT Retain support helps newly connected clients get the latest known value right away. Shared Subscriptions help distribute message processing across multiple consumers for better scale and resilience. HTTP Publish of MQTT messages enables back-end services to send MQTT messages without keeping long-lived MQTT sessions open. Subscription Identifiers help clients understand which subscription matched a received message, making routing and processing simpler. Together, these features reduce application complexity, improve responsiveness, and make it easier for teams to build user-friendly, production-ready IoT experiences. MQTT Retain support: Give new subscribers the latest known value instantly One of the most helpful MQTT patterns is the ability to retain the latest message on a topic. With MQTT Retain support in Azure Event Grid, the broker stores the last known good value for a topic and delivers it immediately to a new subscriber. That means a client does not have to wait for the next live publish to understand the current state. This is especially valuable for scenarios such as device state, configuration settings, last reported sensor readings, and control values. When a new application, dashboard, or device comes online, it can immediately understand the current state of the system and take action faster. Example Imagine a smart factory dashboard subscribing to the topic factory/line1/status. If the latest retained message says Running, a newly opened dashboard can display that status immediately instead of waiting for the next update. Retained messages ensure new subscribers instantly receive the latest device state without waiting for the next publish Why customers like it Faster onboarding for newly connected devices and apps Better user experience in dashboards and operator tools Less waiting for current state information Simpler application logic for recovering context Common use cases Device online or offline state Latest environmental reading such as temperature or humidity Machine mode, recipe, or configuration profile Current command state for field equipment Shared Subscriptions: Scale message processing without extra complexity As message volume grows, a single subscriber may not be enough to process all incoming data efficiently. Shared Subscriptions solve this by allowing multiple consumers to share the work for a subscription. Instead of every consumer receiving every message, the broker distributes messages across members of the shared group. This is a powerful pattern for scaling out telemetry processing, command handling, or event enrichment pipelines. It also helps improve resilience because work can continue even if one consumer instance goes offline. Example Suppose you have a fleet of connected vehicles publishing telemetry to vehicles/+/telemetry. A back-end processing service might run three worker instances subscribed through a shared subscription. Rather than each worker processing all messages, the workload is divided across the three instances, which improves throughput and reduces duplicate effort. Shared subscriptions distribute telemetry messages across multiple worker nodes for scalable, load-balanced, and resilient stream processing. Why customers like it Easier horizontal scaling for high-volume topics Improved throughput for back-end processing Better fault tolerance for worker-based applications Cleaner architecture for stream processing pipelines Common use cases Telemetry ingestion at scale Alarm processing pipelines Order or command handling across multiple workers Message transformation before routing to analytics platforms Shared Subscriptions help teams grow from pilot projects to production-scale deployments without redesigning their application model. They make it easier to add processing capacity as business needs expand. HTTP Publish of MQTT messages: Bring HTTP-native back-end systems into MQTT workflows Not every application wants to maintain a persistent MQTT connection. Many back-end systems are built around stateless HTTP APIs and prefer simple request-based interactions. Azure Event Grid supports publishing MQTT messages over HTTP, which makes it easier for server-side applications to send messages into MQTT-based solutions. This capability is a strong fit for server-to-device command and control, updates from enterprise systems, and retained message management. It also helps protect broker stability by reducing the need for a large number of long-lived sessions from services that do not truly need them. Example Imagine a support application that needs to send a message to a field device asking it to refresh its configuration. Instead of opening an MQTT session, the application can make an HTTP POST request that maps to an MQTT publish operation and sends the command to the desired topic. Why customers like it Simple integration for HTTP-native applications No need for persistent broker sessions in back-end services Consistent messaging flow across HTTP and MQTT publishers Easier integration with business systems and automation workflows Common use cases Server-to-device commands Application-driven updates and prompts Retained message management Integration with business processes, portals, and line-of-business apps Subscription Identifiers: Make client-side message handling smarter As applications grow, a single client may subscribe to many topic filters at the same time. Subscription Identifiers help the client understand which subscription matched a delivered message. This makes application logic cleaner because the client does not have to guess why a message arrived or manually compare it against every subscribed filter. In practical terms, this is useful when one client is listening for different kinds of data such as telemetry, alerts, and control acknowledgments. Instead of writing extra parsing logic, the client can use the identifier to route the message to the right processing path immediately. Example A monitoring application subscribes to one filter for devices/+/telemetry and another for devices/+/alerts. When a message arrives, the subscription identifier helps the application know whether the message should be shown on a live dashboard, routed to alert handling, or stored for analysis. Why customers like it Simpler client code Cleaner separation of processing paths Easier troubleshooting and observability Better support for sophisticated MQTT v5 client applications Common use cases Applications subscribing to multiple topic categories Edge gateways handling mixed streams Dashboards that separate operational data from alerts Services that apply different business logic based on subscription intent Putting it all together: A simple customer scenario Consider a smart manufacturing plant. Machines, PLCs, and industrial sensors continuously publish telemetry such as production counts, machine health, vibration, and temperature. Operations dashboards subscribe to real-time machine status and line performance. Maintenance systems send commands to equipment when anomalies or thresholds are detected. Meanwhile, analytics workers process high-volume telemetry streams in parallel for quality monitoring, predictive maintenance, and throughput optimization. In this scenario, MQTT Retain support ensures that a newly opened operations dashboard immediately sees the latest machine state without waiting for the next update. Shared Subscriptions enable multiple analytics workers to process telemetry streams in parallel, improving scalability and avoiding duplicate processing. HTTP Publish of MQTT messages allows MES or maintenance applications to send commands to machines through simple HTTP requests, without needing a persistent MQTT connection. Subscription Identifiers help downstream systems distinguish between telemetry, alerts, and control signals, enabling clean routing to the right processing pipelines. The result is a unified, event-driven architecture that is scalable, efficient, and easier to operate—supporting real-time visibility, faster decision-making, and continuous optimization across the manufacturing floor. Azure Event Grid MQTT broker continues to make cloud-scale MQTT messaging more approachable for customers building modern IoT and event-driven solutions. Features such as MQTT Retain support, Shared Subscriptions, HTTP Publish of MQTT messages, and Subscription Identifiers help simplify application design while improving responsiveness, scale, and operational efficiency. For teams looking to build customer-ready solutions faster, these capabilities can reduce custom code, accelerate onboarding, and create a smoother path from proof of concept to production. Whether you are building connected products, industrial monitoring systems, smart spaces, or data-driven operations, Azure Event Grid MQTT broker provides a flexible foundation for reliable communication across devices, services, and applications. Now is a great time to explore how these features can help simplify your architecture and unlock new patterns for device connectivity and cloud integration.
Stream data in near real time from SQL to Azure Event Hubs - Public preview
If near-real time integration is something you are looking to implement and you were looking for a simpler way to get the data out of SQL, keep reading. SQL is making it easier to integrate and Change Event Streaming is a feature continuing this trend. Modern applications and analytics platforms increasingly rely on event-driven architectures and real-time data pipelines. As the businesses speed up, real time decisioning is becoming especially important. Traditionally, capturing changes from a relational database requires complex ETL jobs, periodic polling, or third-party tools. These approaches often consume significant cycles of the data source, introduce operational overhead, and pose challenges with scalability, especially if you need one data source to feed into multiple destinations. In this context, we are happy to release Change Event Streaming ("CES") feature into Public Preview for Azure SQL Database. This feature enables you to stream row-level changes - inserts, updates, and deletes - from your database directly to Azure Event Hubs in near real time. Change Event Streaming addresses the above challenges by: Reducing latency: Changes are streamed (pushed by SQL) as they happen. This is in contrast with traditional CDC (change data capture) or CT (change tracking) based approaches, where an external component needs to poll SQL at regular intervals. Traditional approaches allow you to increase polling frequency, but it gets difficult to find a sweet spot between minimal latency and minimal overhead due to too frequent polls. Simplifying architecture: No need for Change Data Capture (CDC), Change Tracking, custom polling or external connectors - SQL streams directly to configured destination. This means simpler security profile (fewer authentication points), fewer failure points, easier monitoring, lower skill bar to deploy and run the service. No need to worry about cleanup jobs, etc. SQL keeps track of which changes are successfully received by the destination, handles the retry logic and releases log truncation point. Finally, with CES you have fewer components to procure and get approved for production use. Decoupling: The integration is done on the database level. This eliminates the problem of dual writes - the changes are streamed at transaction boundaries, once your source of truth (the database) has saved the changes. You do not need to modify your app workloads to get the data streamed - you tap right onto the data layer - this is useful if your apps are dated and do not possess real-time integration capabilities. In case of some 3rd party apps, you may not even have an option to do anything other than database level integration, and CES makes it simpler. Also, the publishing database does not concern itself with the final destination for the data - Stream the data once to the common message bus, and you can consume it by multiple downstream systems, irrespective of their number or capacity - the (number of) consumers does not affect publishing load on the SQL side. Serving consumers is handled by the message bus, Azure Event Hubs, which is purpose built for high throughput data transfers. onceptually visualizing data flow from SQL Server, with an arrow towards Azure Event Hubs, from where a number of arrows point to different final destinations. Key Scenarios for CES Event-driven microservices: They need to exchange data, typically thru a common message bus. With CES, you can have automated data publishing from each of the microservices. This allows you to trigger business processes immediately when data changes. Real-time analytics: Stream operational data into platforms like Fabric Real Time Intelligence or Azure Stream Analytics for quick insights. Breaking down the monoliths: Typical monolithic systems with complex schemas, sitting on top of a single database can be broken down one piece at a time: create a new component (typically a microservice), set up the streaming from the relevant tables on the monolith database and tap into the stream by the new components. You can then test run the components, validate the results against the original monolith, and cutover when you build the confidence that the new component is stable. Cache and search index updates: Keep distributed caches and search indexes in sync without custom triggers. Data lake ingestion: Capture changes continuously into storage for incremental processing. Data availability: This is not a scenario per se, but the amount of data you can tap into for business process mining or intelligence in general goes up whenever you plug another database into the message bus. E.g. You plug in your eCommerce system to the message bus to integrate with Shipping providers, and consequently, the same data stream is immediately available for any other systems to tap into. How It Works CES uses transaction log-based capture to stream changes with minimal impact on your workload. Events are published in a structured JSON format following the CloudEvents standard, including operation type, primary key, and before/after values. You can configure CES to target Azure Event Hubs via AMQP or Kafka protocols. For details on configuration, message format, and FAQs, see the official documentation: Feature Overview CES: Frequently Asked Questions Get Started Public preview CES is available today in public preview for Azure SQL Database and as a preview feature in SQL Server 2025. [update 20-mar-2026] Change Event Streaming is now in public preview for Azure SQL Managed instance. Read more here. Private preview CES is also available as a private preview for Azure SQL Managed Instance and Fabric SQL database: you can request to join the private preview by signing up here: https://aka.ms/sql-ces-signup We encourage you to try the feature out and start building real-time integrations on top of your existing data. We welcome your feedback—please share your experience through Azure Feedback portal or support channels. The comments below on this blog post will also be monitored, if you want to engage with us. Finally, CES team can be reached via email: sqlcesfeedback [at] microsoft [dot] com. Useful resources Free Azure SQL Database. Free Azure SQL Managed Instance.Cloud Native Identity with Azure Files: Entra-only Secure Access for the Modern Enterprise
Azure Files introduces Entra only identities authentication for SMB shares, enabling cloud-only identity management without reliance on on-premises Active Directory. This advancement supports secure, seamless access to file shares from anywhere, streamlining cloud migration and modernization, and reducing operational complexity and costs.
New Azure API management service limits
Azure API Management operates on finite physical infrastructure. To ensure reliable performance for all customers, the service enforces limits calibrated based on: Azure platform capacity and performance characteristics Service tier capabilities Typical customer usage patterns Resource limits are interrelated and tuned to prevent any single aspect from disrupting overall service performance. Changes to service limits - 2026 update Starting March 2026 and over the following several months, Azure API Management is introducing updated resource limits for instances across all tiers. The limits are shown in the following table. Entity/Resource Consumption Developer Basic/ Basic v2 Standard/ Standard v2 Premium/ Premium v2 API operations 3,000 3,000 10,000 50,000 75,000 API tags 1,500 1,500 1,500 2,500 15,000 Named values 5,000 5,000 5,000 10,000 18,000 Loggers 100 100 100 200 400 Products 100 100 200 500 2,000 Subscriptions N/A 10,000 15,000 25,000 75,000 Users N/A 20,000 20,000 50,000 75,000 Workspaces per workspace gateway N/A N/A N/A N/A 30 Self-hosted gateways N/A 5 N/A N/A 100 1 1 Applies to Premium tier only. What's changing Limits in the classic tiers now align with those set in the v2 tiers. Limits are enforced for a smaller set of resource types that are directly related to service capacity and performance, such as API operations, tags, products, and subscriptions. Rollout process New limits roll out in a phased approach by tier as follows: Tier Expected rollout date Consumption Developer Basic Basic v2 March 15, 2026 Standard Standard v2 April 15, 2026 Premium Premium v2 May 15, 2026 Limits policy for existing classic tier customers After the new limits take effect, you can continue using your preexisting API Management resources without interruption. Existing classic tier services, where current usage exceeds the new limits, are "grandfathered" when the new limits are introduced. (Instances in the v2 tiers are already subject to the new limits.) Limits in grandfathered services will be set 10% higher than the customer's observed usage at the time new limits take effect. Grandfathering applies per service and service tier. Other existing services and new services are subject to the new limits when they take effect. Guidelines for limit increases In some cases, you might want to increase a service limit. Before requesting a limit increase, note the following guidelines: Explore strategies to address the issue proactively before requesting a limit increase. See the article here Manage resources within limits. Consider potential impacts of the limit increase on overall service performance and stability. Increasing a limit might affect your service's capacity or increase latency in some service operations. Requesting a limit increase The product team considers requests for limit increases only for customers using services in the following tiers that are designed for medium to large production workloads: Standard and Standard v2 Premium and Premium v2 Requests for limit increases are evaluated on a case-by-case basis and aren't guaranteed. The product team prioritizes Premium and Premium v2 tier customers for limit increases. To request a limit increase, create a support request from the Azure portal. For more information, see Azure support plans. Documentation For more information, please see documentation hereGenerally Available: Azure SQL Managed Instance Next-gen General Purpose
Overview Next-gen General Purpose is the evolution of General Purpose service tier that brings significantly improved performance and scalability to power up your existing Azure SQL Managed Instance fleet and helps you bring more mission-critical SQL workloads to Azure. We are happy to announce that Next-gen General Purpose is now Generally Available (GA) delivering even more scalability, flexibility, and value for organizations looking to modernize their data platform in a cost-effective way. The new #SQLMINextGen General Purpose tier delivers a built-in performance upgrade available to all customers at no extra cost. If you are an existing SQL MI General Purpose user, you get faster I/O, higher database density, and expanded storage - automatically. Summary Table: Key Improvements Capability Current GP Next-gen GP Improvement Average I/O Latency 5-10 ms 3-4 ms 2x lower Max Data IOPS 30-50k 80k 60% better Max Storage 16 TB 32 TB 2x better Max Databases/Instance 100 500 5x better Max vCores 80 128 40% better But that’s just the beginning. The new configuration sliders for additional IOPS and memory provide enhanced flexibility to tailor performance according to your requirements. Whether you require more resources for your application or seek to optimize resource utilization, you can adjust your instance settings to maximize efficiency and output. This release isn’t just about speed - It’s about giving you improved performance where it matters, and mechanisms to go further when you need them. Customer story - A recent customer case highlights how Hexure reduced processing time by up to 97.2% using Azure SQL Managed Instance on Next-gen General Purpose. What’s new in Next-gen General Purpose (Nov 2025)? 1. Improved baseline performance with the latest storage tech Azure SQL Managed Instance is built on Intel® Xeon® processors, ensuring a strong foundation for enterprise workloads. With the next-generation General Purpose tier, we’ve paired Intel’s proven compute power with advanced storage technology to deliver faster performance, greater scalability, and enhanced flexibility - helping you run more efficiently and adapt to growing business needs. The SQL Managed Instance General Purpose tier is designed with full separation of compute and storage layers. The Classic GP version uses premium page blobs for the storage layer, while the Next-generation GP tier has transitioned to Azure’s latest storage solution, Elastic SAN. Azure Elastic SAN is a cloud-native storage service that offers high performance and excellent scalability, making it a perfect fit for the storage layer of a data-intensive PaaS service like Azure SQL Managed Instance. Simplified Performance Management With ESAN as the storage layer, the performance quotas for the Next-gen General Purpose tier are no longer enforced for each database file. The entire performance quota for the instance is shared across all the database files, making performance management much easier (one fewer thing to worry about). This adjustment brings the General Purpose tier into alignment with the Business Critical service tier experience. 2. Resource flexibility and cost optimization The GA of Next-gen General Purpose comes together with the GA of a transformative memory slider, enabling up to 49 memory configurations per instance. This lets you right-size workloads for both performance and cost. Memory is billed only for the additional amount beyond the default allocation. Users can independently configure vCores, memory, and IOPS for optimal efficiency. To learn more about the new option for configuring additional memory, check the article: Unlocking More Power with Flexible Memory in Azure SQL Managed Instance. 3. Enhanced resource elasticity through decoupled compute and storage scaling operations With Next-gen GP, both storage and IOPS can be resized independently of the compute infrastructure, and these changes now typically finish within five minutes - a process known as an in-place upgrade. There are three distinct types of storage upgrade experiences depending on the kind of storage upgrade performed and whether failover occurs. In-place update: same storage (no data copy), same compute (no failover) Storage re-attach: Same storage (no data copy), changed compute (with failover) Data copy: Changed storage (data copy), changed compute (with failover) The following matrix describes user experience with management operations: Operation Data copying Failover Storage upgrade type IOPS scaling No No In-place Storage scaling* No* No In-place vCores scaling No Yes** Re-attach Memory scaling No Yes** Re-attach Maintenance Window change No Yes** Re-attach Hardware change No Yes** Re-attach Update policy change Yes Yes Data copy * If scale down is >5.5TB, seeding ** In case of update operations that do not require seeding and are not completed in place (examples are scaling vCores, scaling memory, changing hardware or maintenance window), failover duration of databases on the Next-gen General Purpose service tier scales with the number of databases, up to 10 minutes. While the instance becomes available after 2 minutes, some databases might be available after a delay. Failover duration is measured from the moment when the first database goes offline, until the moment when the last database comes online. Furthermore, resizing vCores and memory is now 50% faster following the introduction of the Faster scaling operations release. No matter if you have end-of-month peak periods, or there are ups and downs of usage during the weekdays and the weekend, with fast and reliable management operations, you can run multiple configurations over your instance and respond to peak usage periods in a cost-effective way. 4. Reserved instance (RI) pricing With Azure Reservations, you can commit to using Azure SQL resources for either one or three years, which lets you benefit from substantial discounts on compute costs. When purchasing a reservation, you'll need to choose the Azure region, deployment type, performance tier, and reservation term. Reservations are only available for products that have reached general availability (GA), and with this update, next-generation GP instances now qualify as well. What's even better is that classic and next-gen GP share the same SKU, just with different remote storage types. This means any reservations you've purchased automatically apply to Next-gen GP, whether you're upgrading an existing classic GP instance or creating a new one. What’s Next? The product group has received considerable positive feedback and welcomes continued input. The initial release will not include zonal redundancy; however, efforts are underway to address this limitation. Next-generation General Purpose (GP) represents the future of the service tier, and all existing classic GP instances will be upgraded accordingly. Once upgrade plans are finalized, we will provide timely communication regarding the announcement. Conclusion Now in GA, Next-gen General Purpose sets a new standard for cloud database performance and flexibility. Whether you’re modernizing legacy applications, consolidating workloads, or building for the future, these enhancements put more power, scalability, and control in your hands - without breaking the bank. If you haven’t already, try out the Next-gen General Purpose capabilities for free with Azure SQL Managed Instance free offer. For users operating SQL Managed Instance on the General Purpose tier, it is recommended to consider upgrading existing instances to leverage the advantages of next-gen upgrade – for free. Welcome to #SQLMINextGen. Boosted by default. Tuned by you. Learn more What is Azure SQL Managed Instance Try Azure SQL Managed Instance for free Next-gen General Purpose – official documentation Analyzing the Economic Benefits of Microsoft Azure SQL Managed Instance How 3 customers are driving change with migration to Azure SQL Accelerate SQL Server Migration to Azure with Azure ArcAnnouncing the General Availability (GA) of the Premium v2 tier of Azure API Management
Superior capacity, highest entity limits, unlimited included calls, and the most comprehensive set of features set the Premium v2 tier apart from other API Management tiers. Customers rely on the Premium v2 tier for running enterprise-wide API programs at scale, with high availability, and performance. The Premium v2 tier has a new architecture that eliminates management traffic from the customer VNet, making private networking much more secure and easier to setup. During the creation of a Premium v2 instance, you can choose between VNet injection or VNet integration (introduced in the Standard v2 tier) options. In addition, today we are also adding three new features to Premium v2: Inbound Private Link: You can now enable private endpoint connectivity to restrict inbound access to your Premium v2 instance. It can be enabled along with VNet injection or VNet integration or without a VNet. Availability zone support: Premium v2 now supports availability zones (zone redundancy) to enhance the reliability and resilience of your API gateway. Custom CA certificates: Azure API management v2 gateway can now validate TLS connections with the backend service using custom CA certificates. New and improved VNet injection Using VNet injection in Premium v2 no longer requires configuring routes or service endpoints. Customers can secure their API workloads without impacting API Management dependencies, while Microsoft can secure the infrastructure without interfering with customer API workloads. In short, the new VNet injection implementation enables both parties to manage network security and configuration settings independently and without affecting each other. You can now configure your APIs with complete networking flexibility: force tunnel all outbound traffic to on-premises, send all outbound traffic through an NVA, or add a WAF device to monitor all inbound traffic to your API Management Premium v2—all without constraints. Inbound Private Link Customers can now configure an inbound private endpoint for their API Management Premium v2 instance to allow your API consumers securely access the API Management gateway over Azure Private Link. The private endpoint uses an IP address from an Azure virtual network in which it's hosted. Network traffic between a client on your private network and API Management traverses over the virtual network and a Private Link on the Microsoft backbone network, eliminating exposure from the public internet. Further, you can configure custom DNS settings or an Azure DNS private zone to map the API Management hostname to the endpoint's private IP address. With a private endpoint and Private Link, you can: Create multiple Private Link connections to an API Management instance. Use the private endpoint to send inbound traffic on a secure connection. Apply different API Management policies based on whether traffic comes from the private endpoint. Limit incoming traffic only to private endpoints, preventing data exfiltration. Combine with inbound virtual network injection or outbound virtual network integration to provide end-to-end network isolation of your API Management clients and backend services. More details can be found here Today, only the API Management instance’s Gateway endpoint supports inbound private link connections. Each API management instance can support at most 100 Private Link connections. Availability zones Azure API Management Premium v2 now supports Availability Zones (AZ) redundancy to enhance the reliability and resilience of your API gateway. When deploying an API Management instance in an AZ-enabled region, users can choose to enable zone redundancy. This distributes the service's units, including Gateway, management plane, and developer portal, across multiple, physically separate AZs within that region. Learn how to enable AZs here. CA certificates If the API Management Gateway needs to connect to the backends secured with TLS certificates issued by private certificate authorities (CA), you need to configure custom CA certificates in the API Management instance. Custom CA certificates can be added and managed as Authorization Credentials in the Backend entities. The Backend entity has been extended with new properties allowing customers to specify a list of certificate thumbprints or subject name + issuer thumbprint pairs that Gateway should trust when establishing TLS connection with associated backend endpoint. More details can be found here. Region availability The Premium v2 tier is now generally available in six public regions (Australia East, East US2, Germany West Central, Korea Central, Norway East and UK South) with additional regions coming soon. For pricing information and regional availability, please visit the API Management pricing page. Learn more API Management v2 tiers FAQ API Management v2 tiers documentation API Management overview documentation
Announcing public preview of query-based metric alerts in Azure Monitor
Azure Monitor metric alerts are now more powerful than ever Azure Monitor metric alerts now support all Azure metrics - including platform, Prometheus, and custom metrics - giving you complete coverage for your monitoring needs. In addition, metric alerts now offer powerful query capabilities with PromQL, enabling complex logic across multiple metrics and resources. This makes it easier to detect patterns, correlate signals, and customize alerts for modern workloads like Kubernetes clusters, VMs, and custom applications. Key Benefits Full metrics coverage: metric alerts now support alerting on any Azure metrics including platform metrics, Prometheus metrics and custom metrics. PromQL-Powered Conditions: Use PromQL to select, aggregate, and transform metrics for advanced alerting scenarios. Powerful event detection: Query-based alert rules can now detect intricate patterns across multiple timeseries based on metric change ratio, complex aggregations, or comparison between different metrics and timeseries. You can also analyze metrics across different time windows to identify change in metric behavior over time. Flexible Scoping: For query-based alert rules, choose between resource-centric alerts for granular RBAC or workspace-centric alerts for cross-resource visibility. Alerting at scale: Query-based alert rules allow monitoring metrics from multiple resources within a subscription or a resource group, using a single rule. Managed Identity Support: Securely authorize queries using Azure Managed Identity, ensuring compliance and reducing credential management overhead. Customizable Notifications: Add dynamic custom properties and custom email subjects for faster triage and context-rich alerting. Reuse community alerts: Easily import and re-use PromQL alert queries from the open-source community or from other Prometheus-based monitoring systems. Supported metrics At this time, query-based metric alerts support any metrics ingested into Azure Monitor Workspace (AMW). This currently includes: Metrics collected by Azure Monitor managed service for Prometheus, from Azure Kubernetes Services clusters (AKS) or from other sources. Virtual machine OpenTelemetry (OTel) Guest OS Metrics Other OTel custom metrics collected into Azure Monitor. You can still create threshold-based metric alerts as before on Azure platform metrics. Query-based alerts on platform metrics will be added in future releases. Comparison: Query-based metric alerts vs. Prometheus rule groups alerts Query-based metric alerts serve as an alternative to alerts defined in Prometheus rule groups. Both options remain viable and execute the same PromQL-based alerting logic. However, metric alerts are natively integrated with Azure Monitor, aligning seamlessly with other Azure alert types. They now support all your metric alerting needs within the same rule type. They also offer richer functionality and greater flexibility, making them a strong choice for teams looking for consistency across Azure monitoring solutions. See the table below for detailed comparison of the two alternatives. Stay tuned - additional enhancements to metric alerts are coming in future releases! Feature Azure Prometheus rule groups Query-based metric alerts Alert rule management Part of a rule group resource Independent Azure resource Supported metrics Metrics in AMW (Managed Prometheus) Metrics in AMW (Managed Prometheus, OTel metrics) Condition logic PromQL-based query PromQL-based query Aggregation & transformation Full PromQL support Full PromQL support Scope Workspace-wide Resource-centric or workspace-wide Alerting at scale Not supported Subscription level, Resource-group level Cross-resource conditions Supported Supported RBAC granularity Workspace level Resource or workspace level Managed identity support Not supported Supported Notification customization Supported - Prometheus labels and annotations Advanced - dynamic custom properties, custom email subject Getting Started If you have an Azure Monitor workspace containing Prometheus or OpenTelemetry metrics, you can create query-based metric alert rules today. Rules can be created and managed using the Azure Portal, ARM templates, or Azure REST API. For details, visit Azure Monitor documentation.
