Generally 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 Arc
Announcing 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 documentationNew 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.
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.
Microsoft Agent Pre-Purchase Plan: One Unified Path to Scale AI Agents
AI is now essential, and at Microsoft Ignite 2025, we introduced a new foundation for intelligent agents: Work IQ, Fabric IQ, and Foundry IQ. These three IQs represent the intelligence layer that gives agents deep context; understanding how people work, connecting to enterprise data, and orchestrating knowledge across platforms. Together with the launch of Microsoft Agent Factory, organizations now have a unified program to build, deploy, and manage agents powered by these IQs. Microsoft Agent Pre-Purchase Plan (P3) is designed to for organizations looking to confidently invest in AI agent development with a single, predictable budget. It empowers businesses to experiment, build, and scale sophisticated AI agents without the friction of fragmented licensing or unexpected costs. By unifying access to agentic services across Microsoft Foundry, Microsoft Copilot Studio*, Microsoft Fabric, and GitHub, Microsoft Agent P3 empowers organizations to harness the full potential of the IQ layer thus removing barriers and unlocking the value of truly intelligent, context-driven agents. What is Microsoft Agent Pre-Purchase Plan and how to does it work? Microsoft Agent P3 is a one-year pay-upfront option. Customers commit upfront to a lump-sum pool of Agent Commit Units (ACU) that can be used at any time during the one-year term. Every time you consume eligible services across Microsoft Foundry, Microsoft Copilot Studio*, Microsoft Fabric, and GitHub, the ACUs are automatically drawn down from your P3 balance. If you use up your balance before the year ends, you can add another P3 plan or switch to pay-as-you-go. If you don’t use all your credits by the end of the year, the remaining balance expires. Pricing* *Pricing as of November 2025, subject to change. **Example if Microsoft Copilot Studio generates a retail cost of $100 based on Copilot Credit and Microsoft Foundry usage, then 100 Agent CUs (ACUs) are consumed. What is covered by the Microsoft Agent Pre-Purchase Plan? * List as of February 2026, subject to change ** Currently in Private Preview *** Covers Copilot Credits enabled agentic services: Microsoft Copilot Studio, Dynamics 365 first-party agents, and Copilot. Microsoft reserves the right to update Copilot Credit eligible products. Customer Example Suppose a customer expects to consume 1,500,000 Copilot Credit with custom agents created in Microsoft Copilot Studio. Assuming the pay-as-you-go rate for Copilot Credit to be $0.01, then at the pay-as-you-go rate, this will cost $15,000. In addition, if they are using 5000 Microsoft Foundry Provisioned Throughput Units (PTU) and assuming the pay-as-you-go rate for PTU to be $1, then at the pay-as-you-go rate, this will cost $5,000. By purchasing Tier 1 (20,000 ACUs) Microsoft Agent P3 at the cost of $19,000, it will give a 5% saving compared to the pay-as-you-go rate for the same usage. How to purchase a Microsoft Agent Pre-Purchase Plan? Sign in to the Azure portal →Reservations → + Add → Microsoft Agent Pre-Purchase Plan. Select your subscription and scope Choose your tier and complete payment. What sets Microsoft Agent Pre-Purchase Plan apart? At the heart of Microsoft Agent Pre-Purchase Plan are four pillars that redefine how organizations consume AI services: One Plan: A single offer that spans Microsoft Foundry, Microsoft Copilot Studio*, Microsoft Fabric, and GitHub. No more siloed credits or SKU-level complexity, just one pool for all your AI workloads. Breadth of Services: Access to 30+ services, from Azure AI Search and Cognitive Services to orchestration tools and Copilot-enabled experiences. One Governance Path: Simplifies procurement and budget management. Procurement teams gain visibility and control without sacrificing agility. Predictable Savings: Get discounts and avoid surprises when you choose this plan. Conclusion The Microsoft Agent Pre-Purchase Plan is designed to make your AI journey simpler, smarter, and more cost-effective. By combining the strengths of Microsoft Foundry, Microsoft Copilot Studio*, Microsoft Fabric, and GitHub into a single, unified offer, the plan eliminates the need to choose one platform or manage multiple contracts. Organizations benefit from predictable budgeting, streamlined procurement, and the flexibility to innovate across more than 30+ agentic services—all with one pool of funds. Whether you’re just starting with AI or scaling enterprise-wide adoption, the Microsoft Agent Pre-Purchase Plan empowers you to unlock the full value of Microsoft’s agentic platform—driving innovation, efficiency, and business impact. And with support for agents built on Work IQ, Fabric IQ, and Foundry IQ, customers can be confident their solutions are grounded in the latest intelligence announced at Ignite. What’s next Read the Microsoft Agent P3 Offer MS Learn Doc Purchase Microsoft Agent P3 in your Azure Portal * Covers Copilot Credits enabled agentic services: Microsoft Copilot Studio, Dynamics 365 first-party agents, and Copilot. Microsoft reserves the right to update Copilot Credit eligible products
Accelerating SCOM to Azure Monitor Migrations with Automated Analysis and ARM Template Generation
Accelerating SCOM to Azure Monitor Migrations with Automated Analysis and ARM Template Generation Azure Monitor has become the foundation for modern, cloud-scale monitoring on Azure. Built to handle massive volumes of telemetry across infrastructure, applications, and services, it provides a unified platform for metrics, logs, alerts, dashboards, and automation. As organizations continue to modernize their environments, Azure Monitor is increasingly the target state for enterprise monitoring strategies. With Azure Monitor increasingly becoming the destination platform, many organizations face a familiar challenge: migrating from System Center Operations Manager (SCOM). While both platforms serve the same fundamental purpose—keeping your infrastructure healthy and alerting you to problems—the migration path isn’t always straightforward. SCOM Management Packs contain years of accumulated monitoring logic: performance thresholds, event correlation rules, service discoveries, and custom scripts. Translating all of this into Azure Monitor’s paradigm of Log Analytics queries, alert rules, and Data Collection Rules can be a significant undertaking. To help with this challenge, members of the community have built and shared a tool that automates much of the analysis and artifact generation. The community-driven SCOM to Azure Monitor Migration Tool accepts Management Pack XML files and produces several outputs designed to accelerate migration planning and execution. The tool parses the Management Pack structure and identifies all monitors, rules, discoveries, and classes. Each component is analyzed for migration complexity: some translate directly to Azure Monitor equivalents, while others require custom implementation or may not have a direct equivalent. Results are organized into two clear categories: Auto-Migrated Components – Covered by the generated templates and ready for deployment Requires Manual Migration – Components that need custom implementation or review Instead of manually authoring Azure Resource Manager templates, the tool generates deployable infrastructure-as-code artifacts, including: Scheduled Query Alert rules mapped from SCOM monitors and rules Data Collection Rules for performance counters and Windows Events Custom Log DCRs for collecting script-generated log files Action Groups for notification routing Log Analytics workspace configuration (for new environments) For streamlined deployment, the tool offers a combined ARM template that deploys all resources in a single operation: Log Analytics workspace (create new or connect to an existing workspace) Action Groups with email notification All alert rules Data Collection Rules Monitoring Workbook One download, one deployment command — with configurable parameters for workspace settings, notification recipients, and custom log paths. The tool generates an Azure Monitor Workbook dashboard tailored to the Management Pack, including: Performance counter trends over time Event monitoring by severity with drill-down tables Service health overview (stopped services) Active alerts summary from Azure Resource Graph This provides immediate operational visibility once the monitoring configuration is deployed. Each migrated component includes the Kusto Query Language (KQL) equivalent of the original SCOM monitoring logic. These queries can be used as-is or refined to match environment-specific requirements. The workflow is designed to reduce the manual effort involved in migration planning: Export your Management Pack XML from SCOM Upload it to the tool Review the analysis — components are separated into auto-migrated and requires manual work Download the All-in-One ARM template (or individual templates) Customize parameters such as workspace name and action group recipients Deploy to your Azure subscription For a typical Management Pack, such as Windows Server Active Directory monitoring, you may see 120+ components that can be migrated directly, with an additional 15–20 components requiring manual review due to complex script logic or SCOM-specific functionality. The tool handles straightforward translations well: Performance threshold monitors become metric alerts or log-based alerts Windows Event collection rules become Data Collection Rule configurations Service monitors become scheduled query alerts against Heartbeat or Event tables Components that typically require manual attention: Complex PowerShell or VBScript probe actions Monitors that depend on SCOM-specific data sources Correlation rules spanning multiple data sources Custom workflows with proprietary logic The tool clearly identifies which category each component falls into, allowing teams to plan their migration effort with confidence. A Note on Validation This is a community tool, not an officially supported Microsoft product. Generated artifacts should always be reviewed and tested in a non-production environment before deployment. Every environment is different, and the tool makes reasonable assumptions that may require adjustment. Even so, starting with structured ARM templates and working KQL queries can significantly reduce time to deployment. Try It Out The tool is available at https://tinyurl.com/Scom2Azure.Upload a Management Pack, review the analysis, and see what your migration path looks like.Announcing the preview of Azure Local rack aware cluster
As of 1/22/2026, Azure Local rack aware cluster is now generally available! To learn more: Overview of Azure Local rack aware clustering - Azure Local | Microsoft Learn We are excited to announce the public preview of Azure Local rack aware cluster! We previously published a blog post with a sneak peek of Azure Local rack aware cluster and now, we're excited to share more details about its architecture, features, and benefits. Overview of Azure Local rack aware cluster Azure Local rack aware cluster is an advanced architecture designed to enhance fault tolerance and data distribution within an Azure Local instance. This solution enables you to cluster machines that are strategically placed across two physical racks in different rooms or buildings, connected by high bandwidth and low latency within the same location. Each rack functions as a local availability zone, spanning layers from the operating system to Azure Local management, including Azure Local VMs. The architecture leverages top-of-rack (ToR) switches to connect machines between rooms. This direct connection supports a single storage pool, with rack aware clusters distributing data copies evenly between the two racks. Even if an entire rack encounters an issue, the other rack maintains the integrity and accessibility of the data. This design is valuable for environments needing high availability, particularly where it is essential to avoid rack-level data loss or downtime from failures like fires or power outages. Key features Starting in Azure Local version 2510, this release includes the following key features for rack aware clusters: Rack-Level Fault Tolerance & High Availability Clusters span two physical racks in separate rooms, connected by high bandwidth and low latency. Each rack acts as a local availability zone. If one rack fails, the other maintains data integrity and accessibility. Support for Multiple Configurations Architecture supports 2 machines up to 8 machines, enabling scalable deployments for a wide range of workloads. Scale-Out by Adding Machines Easily expand cluster capacity by adding machines, supporting growth and dynamic workload requirements without redeployment. Unified Storage Pool with Even Data Distribution Rack aware clusters offer a unified storage pool with Storage Spaces Direct (S2D) volume replication, automatically distributing data copies evenly across both racks. This ensures smooth failover and reduces the risk of data loss. Azure Arc Integration and Management Experience Enjoy native integration with Azure Arc, enabling consistent management and monitoring across hybrid environments—including Azure Local VMs and AKS—while maintaining the familiar Azure deployment and operational experience. Deployment Options Deploy via Azure portal or ARM templates, with new inputs and properties in the Azure portal for rack aware clusters. Provision VMs in Local Availability Zones via the Azure Portal Provision Azure Local virtual machines directly into specific local availability zones using the Azure portal, allowing for granular workload placement and enhanced resilience. Upgrade Path from Preview to GA Deploy rack aware clusters with the 2510 public preview build and update to General Availability (GA) without redeployment—protecting your investment and ensuring operational continuity. Get started The preview of rack aware cluster is now available to all interested customers. We encourage you to try it out and share your valuable feedback. To get started, visit our documentation: Overview of Azure Local rack aware clustering (Preview) - Azure Local | Microsoft Learn Stay tuned for more updates as we work towards general availability in 2026. We look forward to seeing how you leverage Azure Local rack aware cluster to power your edge workloads!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.
Moving the Logic Apps Designer Forward
Today, we're excited to announce a major redesign of the Azure Logic Apps designer experience, now entering Public Preview for Standard workflows. While these improvements are currently Standard-only, our vision is to quickly extend them across all Logic Apps surfaces and SKUs. ⚠️ Important: As this is a Public Preview release, we recommend using these features for development and testing workflows rather than production workloads. We're actively stabilizing the experience based on your feedback. This Is Just the Beginning This is not us declaring victory and moving on. This is Phase I of a multi-phase journey, and I'm committed to sharing our progress through regular blog posts as we continue iterating. More importantly, we want to hear from you. Your feedback drives these improvements, and it will continue to shape what comes next. This redesign comes from listening to you—our customers—watching how you actually work, and adapting the designer to better fit your workflows. We've seen the pain points, heard the frustrations, and we're addressing them systematically. Our Roadmap: Three Phases Phase I: Perfecting the Development Loop (What we're releasing today) We're focused on making it cleaner and faster to edit your workflow, test it, and see the results. The development loop should feel effortless, not cumbersome. Phase II: Reimagining the Canvas Next, we'll rethink how the canvas works—introducing new shortcuts and workflows that make modifications easier and more intuitive. Phase III: Unified Experiences Across All Surfaces We'll ensure VS Code, Consumption, and Standard all deliver similarly powerful flows, regardless of where you're working. Beyond these phases, we have several standalone improvements planned: a better search experience, streamlined connection creation and management, and removing unnecessary overhead when creating new workflows. We're also tackling fundamental questions that shouldn't be barriers: What do stateful and stateless mean? Why can't you switch between them? Why do you have to decide upfront if something is an agent? You shouldn't. We're working toward making these decisions dynamic—something you can change directly in the designer as you build, not rigid choices you're locked into at creation time. We want to make it easier to add agentic capabilities to any workflow, whenever you need them. What's New in Phase I Let me walk you through what we're shipping at Ignite. Faster Onboarding: Get to Building Sooner We're removing friction from the very beginning. When you create a new workflow, you'll get to the designer before having to choose stateful, stateless, or agentic. Eventually, we want to eliminate that upfront choice entirely—making it a decision you can defer until after your workflow is created. This one still needs a bit more work, but it's coming soon. One View to Rule Them All We've removed the side panel. Workflows now exist in a single, unified view with all the tooling you need. No more context switching. You can easily hop between run history, code view, or visual editor, and change your settings inline—all without leaving your workflow. Draft Mode: Auto-Save Without the Risk Here's one of our biggest changes: draft mode with auto-save. We know the best practice is to edit locally in VS Code, store workflows in GitHub, and deploy properly to keep editing separate from production. But we also know that's not always possible or practical for everyone. It sucks to get your workflow into the perfect state, then lose everything if something goes wrong before you hit save. Now your workflow auto-saves every 10 seconds in draft mode. If you refresh the window, you're right back where you were—but your changes aren't live in production. There's now a separate Publish action that promotes your draft to production. This means you can work, test your workflow against the draft using the designer tools, verify everything works, and then publish to production—even when editing directly on the resource. Another benefit: draft saves won't restart your app. Your app keeps running. Restarts only happen when you publish. Smarter, Faster Search We've reorganized how browsing works—no more getting dropped into an endless list of connectors. You now get proper guidance as you explore and can search directly for what you need. Even better, we're moving search to the backend in the coming weeks, which will eliminate the need to download information about thousands of connectors upfront and deliver instant results. Our goal: no search should ever feel slow. Document Your Workflows with Notes You can now add sticky notes anywhere in your workflow. Drop a post-it note, add markdown (yes, even YouTube videos), and document your logic right on the canvas. We have plans to improve this with node anchoring and better stability features, but for now, you can visualize and explain your workflows more clearly than ever. Unified Monitoring and Run History Making the development loop smoother means keeping everything in one place. Your run history now lives on the same page as your designer. Switch between runs without waiting for full blade reloads. We've also added the ability to view both draft and published runs—a powerful feature that lets you test and validate your changes before they go live. We know there's a balance between developer and operator personas. Developers need quick iteration and testing capabilities, while operators need reliable monitoring and production visibility. This unified view serves both: developers can test draft runs and iterate quickly, while the clear separation between draft and published runs ensures operators maintain full visibility into what's actually running in production. New Timeline View for Better Debugging We experimented with a timeline concept in Agentic Apps to explain handoff—Logic Apps' first foray into cyclic graphs. But it was confusing and didn't work well with other Logic App types. We've refined it. On the left-hand side, you'll now see a hierarchical view of every action your Logic App ran, in execution order. This makes navigation and debugging dramatically easier when you're trying to understand exactly what happened during a run. What's Next This is Phase I. We're shipping these improvements, but we're not stopping here. As we move into Phase II and beyond, I'll continue sharing updates through blog posts like this one. How to Share Your Feedback We're actively listening and want to hear from you: Use the feedback button in the Azure Portal designer Join the discussion in GitHub/Community Forum – https://github.com/Azure/LogicAppsUX Comment below with your thoughts and suggestions Your input directly shapes our roadmap and priorities. Keep the feedback coming. It's what drives these changes, and it's what will shape the future of Azure Logic Apps. Let's build something great together.
