Generated on: July 26, 2025 Target period: Within the last 24 hours Processing mode: Details Mode Number of updates: 3 items
Published: July 25, 2025 10:45:12 UTC Link: Generally Available: ExpressRoute - Auto-assigned Public IP for ExpressRoute Gateways
Update ID: 498361 Data source: Azure Updates API
Categories: Launched, Hybrid + multicloud, Networking, Azure ExpressRoute, Features, Security
Summary:
What was updated
Azure ExpressRoute Virtual Network Gateways now use auto-assigned Public IP addresses by default for all new deployments.
Key changes or new features
The update removes the need for developers and IT professionals to manually assign Public IP addresses to ExpressRoute gateways. This automation simplifies gateway setup, reduces configuration errors, and accelerates deployment times. The auto-assigned Public IP is managed by Azure, ensuring consistent and reliable connectivity.
Target audience affected
This change primarily impacts network architects, cloud engineers, and IT professionals responsible for designing, deploying, and managing Azure ExpressRoute gateways and virtual networks.
Important notes if any
Existing ExpressRoute gateways with manually assigned Public IPs are not affected by this update. Users can continue to assign Public IPs explicitly if needed for specific scenarios. This enhancement streamlines new gateway deployments but does not change existing gateway behaviors or configurations. For detailed guidance, refer to the official Azure update documentation.
Details:
The recent Azure update announces the general availability of auto-assigned Public IP addresses for ExpressRoute Virtual Network Gateways, fundamentally enhancing the deployment and management experience for IT professionals working with Azure ExpressRoute.
Background and Purpose of the Update
Traditionally, when deploying an ExpressRoute Virtual Network Gateway, administrators were required to manually create and assign a Public IP address resource to the gateway. This process added complexity, increased the potential for configuration errors, and extended deployment time. The update addresses these challenges by automating Public IP assignment, thereby simplifying gateway provisioning and reducing operational overhead.
Specific Features and Detailed Changes
With this update, all newly deployed ExpressRoute Virtual Network Gateways will automatically receive a Public IP address assigned by Azure. This auto-assignment eliminates the need for users to explicitly create or manage Public IP resources for the gateway. Existing gateways with manually assigned Public IPs remain unaffected, ensuring backward compatibility. The change streamlines the gateway creation process in the Azure portal, CLI, PowerShell, and ARM templates, as the Public IP parameter is no longer mandatory during gateway deployment.
Technical Mechanisms and Implementation Methods
Under the hood, Azure’s control plane now integrates Public IP resource provisioning as part of the ExpressRoute gateway deployment workflow. When a new gateway is created, Azure automatically generates and associates a Public IP address within the same resource group and region, adhering to best practices for network resource locality and security. This IP is managed by Azure, including lifecycle and scaling operations, ensuring consistent availability and performance. The auto-assigned Public IP supports both IPv4 and IPv6, depending on the gateway SKU and configuration.
Use Cases and Application Scenarios
This update is particularly beneficial for organizations deploying new ExpressRoute connections to establish private, high-throughput, low-latency connectivity between on-premises networks and Azure virtual networks. It simplifies scenarios such as hybrid cloud architectures, disaster recovery setups, and data center extension projects by reducing the complexity of gateway setup. Automation scripts and infrastructure-as-code deployments benefit from fewer parameters and reduced risk of misconfiguration. Additionally, managed service providers can streamline ExpressRoute gateway provisioning for multiple customers.
Important Considerations and Limitations
While auto-assigned Public IPs simplify deployment, administrators lose direct control over the IP address selection and naming, which may impact scenarios requiring static, pre-approved IP addresses for firewall or compliance reasons. For such cases, manual Public IP assignment remains supported. Also, this feature applies only to new ExpressRoute Virtual Network Gateways; existing gateways must be recreated or updated to leverage auto-assignment. It is important to verify compatibility with network security groups (NSGs), route tables, and other network policies to ensure seamless integration with the auto-assigned IP. Monitoring and auditing should be adjusted to track these dynamically assigned IPs.
Integration with Related Azure Services
The auto-assigned Public IP feature integrates seamlessly with Azure networking components such as Azure Firewall, Azure DDoS Protection, and Azure Monitor. For example, Azure Firewall policies referencing gateway IPs will need to accommodate dynamic IPs or use service tags where possible. Azure Monitor and Network Watcher can track connectivity and performance metrics for the gateway without additional configuration changes. Furthermore, this update aligns with Azure’s broader push towards simplified resource management and automation, complementing tools like Azure Resource Manager templates, Azure CLI, and Azure Policy for governance.
In summary, the general availability of auto-assigned Public IPs for ExpressRoute Virtual Network Gateways significantly reduces deployment complexity, enhances automation capabilities, and streamlines network architecture management, while maintaining flexibility for scenarios requiring explicit IP control. This update empowers IT professionals to deploy and manage ExpressRoute gateways more efficiently within Azure’s evolving networking ecosystem.
Published: July 25, 2025 10:30:26 UTC Link: Public Preview: Modernizing Azure Resource Manager Throttling for Sovereign Clouds
Update ID: 498893 Data source: Azure Updates API
Categories: Launched, Management and governance, Azure Resource Manager, Features, Management
Summary:
What was updated
Azure Resource Manager (ARM) throttling mechanisms are being modernized to achieve parity between public Azure and sovereign cloud environments.
Key changes or new features
The update introduces consistent throttling policies across both public and sovereign clouds, eliminating discrepancies in request limits and behaviors. This modernization aims to provide a unified developer and operational experience by standardizing API rate limiting and improving reliability when managing resources in sovereign clouds. The rollout is planned to complete by the end of 2026.
Target audience affected
Developers and IT professionals managing resources in sovereign cloud environments (such as Azure Government, Azure China, and Azure Germany) will benefit from consistent ARM throttling behavior aligned with the public cloud. This affects automation scripts, deployment pipelines, and management tools interacting with ARM APIs.
Important notes if any
This is a public preview announcement; users should test their workloads for any impact due to changes in throttling limits or patterns. The update will help reduce unexpected throttling errors and improve scalability but may require adjustments in retry logic or request pacing in existing automation. Monitoring and logging ARM API usage remains critical during the transition period.
Details:
The Azure update titled “Public Preview: Modernizing Azure Resource Manager Throttling for Sovereign Clouds” announces the initiative to align the throttling mechanisms of Azure Resource Manager (ARM) in sovereign clouds with those in the public Azure cloud by the end of 2026, enhancing consistency and performance management across cloud environments.
Background and Purpose:
Azure Resource Manager is the deployment and management service for Azure resources, which enforces throttling to maintain platform stability and ensure fair resource usage. Historically, sovereign clouds—such as Azure Government, Azure China, and Azure Germany—have had different throttling policies and limits compared to the public Azure cloud due to regulatory, compliance, and infrastructure differences. This disparity has led to inconsistent developer experiences and operational challenges when managing resources across multiple cloud environments. The update aims to modernize and standardize ARM throttling in sovereign clouds, bringing parity with the public cloud to simplify management, improve reliability, and optimize resource utilization.
Specific Features and Detailed Changes:
Technical Mechanisms and Implementation Methods:
The modernization involves re-architecting the ARM throttling subsystem to use a centralized, policy-driven throttling engine that applies consistent rules across cloud instances. This engine leverages real-time telemetry data and machine learning models to predict and mitigate throttling scenarios proactively. The implementation includes:
Use Cases and Application Scenarios:
Important Considerations and Limitations:
Integration with Related Azure Services:
In summary, this update represents a significant step toward unifying Azure Resource Manager throttling across sovereign and public clouds, improving operational consistency, resource management, and developer experience while respecting compliance requirements inherent to sovereign environments. Technical professionals should plan to incorporate these changes into their cloud governance, monitoring, and automation strategies to fully leverage the benefits of this modernization.
Published: July 25, 2025 10:30:26 UTC Link: Generally Available: Search Job Enhancements in Log Analytics
Update ID: 498462 Data source: Azure Updates API
Categories: Launched, DevOps, Management and governance, Azure Monitor, Features
Summary:
What was updated
Azure Log Analytics now generally supports Search Jobs, enabling asynchronous queries across all data in your Log Analytics workspace, including long-term retention data.
Key changes or new features
Search Jobs allow running queries asynchronously on any data, returning results as a new Analytics table within the workspace. This enables further querying and analysis on the search results without rerunning the original query. It supports data from both the standard retention period and long-term retention, improving data accessibility and operational efficiency.
Target audience affected
Developers and IT professionals who use Azure Monitor and Log Analytics for querying and analyzing large datasets, especially those dealing with long-term retained data or requiring asynchronous query execution.
Important notes if any
Search Jobs enhance performance and flexibility by decoupling query execution from result consumption. This feature is generally available, meaning it is fully supported for production use. Users can integrate Search Jobs into automated workflows via API for improved data management and analysis.
Details:
The recent general availability of Search Job enhancements in Azure Log Analytics introduces a powerful asynchronous query capability that significantly improves data exploration and analysis across both current and long-term retention data within a Log Analytics workspace. This update addresses the need for more flexible, scalable, and persistent querying mechanisms on large datasets, enabling IT professionals to perform complex investigations and build advanced analytics workflows.
Background and Purpose
Traditionally, Log Analytics queries run synchronously and are limited to data within the standard retention period. However, many organizations require the ability to query archived or long-term retention data, which can be substantial in volume and critical for compliance, forensic analysis, or trend investigations. The Search Job feature was introduced to allow asynchronous execution of queries over any data in the workspace, including long-term retention, without the timeouts or performance constraints of synchronous queries. This update marks the general availability of enhanced Search Jobs, making the feature production-ready and supported for enterprise use.
Specific Features and Detailed Changes
Technical Mechanisms and Implementation Methods
Search Jobs operate by submitting a Kusto Query Language (KQL) query asynchronously to the Log Analytics service. The service processes the query in the background, including data retrieval from long-term retention storage, which may involve cold storage access patterns. Once the query completes, the results are stored in a new, user-specified Analytics table within the workspace. This table behaves like any other Log Analytics table, supporting further KQL queries, joins, and visualizations. The asynchronous nature decouples query execution from client interaction, enabling longer-running queries without client timeouts. The service exposes REST APIs and Azure CLI commands for job lifecycle management, including job submission, status polling, and result retrieval.
Use Cases and Application Scenarios
Important Considerations and Limitations
Integration with Related Azure Services
Search Jobs integrate seamlessly with Azure Monitor and Log Analytics, leveraging the existing Kusto query engine and workspace architecture. They complement Azure Sentinel
This report was automatically generated - 2025-07-26 03:01:45 UTC