DailyAzureUpdatesGenerator

October 16, 2025 - Azure Updates Summary Report (Details Mode)

Generated on: October 16, 2025 Target period: Within the last 24 hours Processing mode: Details Mode Number of updates: 7 items

Update List

1. Generally Available: PowerShell, Az cmdlets, and Python SDK for Azure Database Migration Service

Published: October 15, 2025 22:15:50 UTC Link: Generally Available: PowerShell, Az cmdlets, and Python SDK for Azure Database Migration Service

Update ID: 500775 Data source: Azure Updates API

Categories: Launched, Databases, Migration, Azure Database Migration Service, Features

Summary:

What was updated
Azure Database Migration Service (DMS) now has general availability (GA) support for automation via PowerShell, Az cmdlets, and the Python SDK.
Key changes or new features
Developers and IT professionals can automate database migration workflows using Azure PowerShell module Az.DataMigration, custom cmdlets, and the Python SDK. Additionally, Azure CLI support with the az datamigration command group enables scripting and integration into CI/CD pipelines. These tools facilitate seamless migration of databases to Azure with improved automation, reducing manual intervention and enhancing operational efficiency.
Target audience affected
Database administrators, developers, and IT professionals responsible for managing and automating database migration projects to Azure.
Important notes if any
This GA release ensures production-ready stability and support for automation scenarios. Users should leverage the updated PowerShell modules and SDKs to integrate migration tasks into their existing automation frameworks. For detailed usage and examples, refer to the official Azure documentation.

Details:

The recent general availability (GA) of automation support for Azure Database Migration Service (DMS) via PowerShell, Az cmdlets, and the Python SDK marks a significant enhancement in managing database migration workflows programmatically. This update enables IT professionals to automate, script, and integrate database migration tasks more efficiently within DevOps pipelines and custom management tools.

Background and Purpose
Azure Database Migration Service facilitates seamless migration of on-premises and cloud databases to Azure with minimal downtime. Prior to this update, users primarily relied on the Azure portal for migration orchestration, which limited automation and integration capabilities. The GA release of PowerShell Az.DataMigration module, custom cmdlets, and Python SDK addresses this gap by providing robust programmatic interfaces to create, configure, monitor, and manage migration projects and tasks. This aligns with the broader Azure strategy to empower infrastructure as code (IaC) and automation-driven cloud operations.

Specific Features and Detailed Changes

PowerShell Az.DataMigration Module: Provides cmdlets to create migration services, projects, and tasks; start, stop, and monitor migrations; and retrieve detailed status and error information.
Azure CLI az datamigration Extension: Complements PowerShell by enabling similar capabilities through CLI commands, supporting cross-platform scripting.
Python SDK: Offers programmatic access to DMS features within Python applications, facilitating integration into custom automation scripts and frameworks.
Support for Multiple Database Engines: These tools support migrations involving SQL Server, MySQL, PostgreSQL, and other supported source and target databases.
Task Management: Users can automate complex migration workflows, including schema and data migration, cutover operations, and incremental syncs.
Monitoring and Logging: Enhanced capabilities for retrieving task progress, error diagnostics, and audit trails programmatically.

Technical Mechanisms and Implementation Methods
The Az.DataMigration PowerShell module and Python SDK interact with the Azure Database Migration Service REST API under the hood. They encapsulate authentication via Azure Active Directory (AAD), resource management, and migration orchestration into high-level commands and methods. Users authenticate using service principals or managed identities, then invoke cmdlets or SDK methods to provision migration service instances, define migration projects with source and target endpoints, and execute migration tasks asynchronously. The SDKs handle polling for task status and expose detailed error and performance data, enabling integration with monitoring systems.

Use Cases and Application Scenarios

DevOps Pipelines: Automate database migration as part of CI/CD workflows, enabling repeatable and consistent migrations during application deployments or environment refreshes.
Large-Scale Migrations: Script bulk migrations across multiple databases or servers, reducing manual overhead and human error.
Custom Migration Tools: Integrate migration capabilities into enterprise management portals or custom dashboards.
Disaster Recovery and Testing: Automate migration tasks for creating test environments or failover scenarios.
Incremental Data Sync: Schedule and automate incremental data migrations to minimize downtime during cutover.

Important Considerations and Limitations

Authentication Requirements: Proper Azure RBAC roles and permissions are required for service principal or managed identity accounts used in automation.
API Rate Limits: Large-scale or frequent migration task automation should consider Azure API throttling limits.
Supported Database Versions: Ensure source and target database engines and versions are supported by DMS and the automation tools.
Error Handling: Automation scripts should implement robust error checking and retry logic based on detailed task status information.
Service Availability: DMS is region-specific; automation scripts must target the appropriate Azure region where the migration service is provisioned.
Feature Parity: While the GA release covers core migration scenarios, some advanced portal features may not yet be fully exposed via automation APIs.

Integration with Related Azure Services

**Azure Resource

2. Generally Available: Availability Zones and network restricted Key Vault and App Configuration references for Flex Consumption

Published: October 15, 2025 18:00:12 UTC Link: Generally Available: Availability Zones and network restricted Key Vault and App Configuration references for Flex Consumption

Update ID: 512379 Data source: Azure Updates API

Categories: Launched, Compute, Containers, Internet of Things, Azure Functions, Features, Regions & Datacenters

Summary:

What was updated
Azure Functions Flex Consumption plan now generally supports Availability Zones and network-restricted references to Azure Key Vault and App Configuration.
Key changes or new features
1. Availability Zones can be enabled both during app creation and post-deployment, automatically distributing function instances across zones to improve reliability and fault tolerance.
2. Support for network-restricted references to Azure Key Vault and Azure App Configuration allows secure access to secrets and configurations within virtual networks, enhancing security posture.
3. New region support for these features is included, expanding geographic availability.
Target audience affected
Developers and IT professionals deploying serverless applications using Azure Functions Flex Consumption plan who require high availability and secure configuration management.
Important notes if any
Enabling Availability Zones requires appropriate regional support and may impact deployment architecture. Network restrictions for Key Vault and App Configuration references necessitate proper virtual network configuration to ensure connectivity. These features help meet enterprise-grade reliability and security requirements for serverless workloads.

Details:

The recent Azure update announces the general availability of Availability Zones support and network-restricted Key Vault and App Configuration references for Azure Functions running on the Flex Consumption plan. This enhancement significantly improves the resilience, security, and configuration management capabilities of serverless applications deployed in Azure.

Background and Purpose
Azure Functions Flex Consumption is a serverless hosting plan that provides dynamic scaling and flexible resource allocation for event-driven workloads. Prior to this update, Flex Consumption apps did not natively support Availability Zones, limiting their fault tolerance against zone-level failures within a region. Additionally, referencing Azure Key Vault and App Configuration resources from Flex Consumption apps lacked network restriction capabilities, potentially exposing sensitive configuration data to broader network access. This update addresses these gaps by enabling zone redundancy and secure, network-restricted configuration references, aligning Flex Consumption with best practices for high availability and security.

Specific Features and Detailed Changes

Availability Zones Support: Users can now enable Availability Zones for Flex Consumption apps both at creation and after deployment. When enabled, Azure Functions instances are automatically distributed across multiple physically separate zones within the same Azure region. This distribution mitigates the risk of downtime caused by zone-specific outages, enhancing application reliability and uptime SLAs.
Network-Restricted Key Vault and App Configuration References: Flex Consumption apps can now securely reference Azure Key Vault secrets and App Configuration values with network restrictions applied. This means that these references can be limited to trusted virtual networks or service endpoints, reducing the attack surface and ensuring that sensitive configuration data is accessed only from authorized network locations.

Technical Mechanisms and Implementation Methods

Availability Zones: The Azure Functions platform orchestrates the deployment of function instances across multiple zones by leveraging the underlying Azure infrastructure’s zone-aware resource allocation. This is transparent to the user but requires enabling the feature via Azure CLI, ARM templates, or the Azure portal. Post-deployment enabling involves updating the function app’s zone redundancy configuration.
Network Restrictions: Azure Key Vault and App Configuration support virtual network service endpoints and private endpoints. Flex Consumption apps can now be configured to access these resources through private endpoints or service endpoints, ensuring traffic remains within the Azure backbone network. This requires configuring the Key Vault and App Configuration resources with appropriate firewall and virtual network rules and updating the function app’s managed identity permissions accordingly.

Use Cases and Application Scenarios

Mission-critical serverless applications requiring high availability and minimal downtime, such as financial transaction processing or real-time telemetry ingestion, benefit from zone redundancy.
Applications handling sensitive data can leverage network-restricted Key Vault and App Configuration references to comply with organizational security policies and regulatory requirements.
Multi-zone deployments improve disaster recovery posture by reducing the blast radius of zone-level failures.
Enterprises implementing zero-trust network architectures can enforce strict network access controls on configuration stores accessed by serverless functions.

Important Considerations and Limitations

Enabling Availability Zones may affect cold start times slightly due to distribution across zones, though this is generally offset by improved reliability.
Not all Azure regions support Availability Zones; users must verify regional availability before enabling.
Network restrictions require careful configuration of virtual networks, service endpoints, or private endpoints, which may increase setup complexity.
Existing Flex Consumption apps need to be updated to leverage these features; legacy apps will not benefit automatically.
Monitoring and diagnostics should be enhanced to track zone distribution and network access patterns.

Integration with Related Azure Services

Azure Key Vault: Enhanced integration with network security features such as private endpoints and firewall rules.
Azure App Configuration: Supports secure, network-restricted access patterns for centralized configuration management.
Azure Virtual Network: Enables service endpoints and private endpoints to secure resource access.
Azure Monitor and Application Insights: Can be used to monitor the health and performance of zone-distributed function instances.
Azure Resource Manager (ARM): Supports declarative configuration of

3. Generally Available: Azure Storage Discovery

Published: October 15, 2025 17:00:38 UTC Link: Generally Available: Azure Storage Discovery

Update ID: 515479 Data source: Azure Updates API

Categories: Launched, Storage, Storage Accounts, Services, Features, Management

Summary:

What was updated
Azure Storage Discovery is now generally available, offering comprehensive visibility across your entire Azure Storage estate.
Key changes or new features
The service provides detailed insights into storage capacity usage and activity patterns that were previously unavailable. It enables deep analysis to optimize storage costs, improve security posture, and enhance operational efficiency. Developers and IT professionals can leverage these insights to identify underutilized resources, detect unusual access patterns, and streamline storage management at scale.
Target audience affected
This update primarily benefits developers, IT administrators, and cloud architects responsible for managing and securing Azure Storage environments within enterprises.
Important notes if any
Azure Storage Discovery aggregates data via APIs, ensuring up-to-date and accurate analytics. Organizations can now make data-driven decisions for cost optimization and security enhancements with enterprise-wide storage visibility. Integration with existing monitoring and governance workflows is recommended to maximize operational benefits.

For more details, visit: https://azure.microsoft.com/updates?id=515479

Details:

Azure Storage Discovery is now generally available, offering enterprise-wide visibility and actionable insights into your Azure Storage data estate. This update addresses the growing need for centralized management and optimization of storage resources across large and complex Azure environments.

Background and Purpose
As organizations scale their cloud adoption, managing and optimizing storage resources becomes increasingly challenging. Previously, gaining comprehensive visibility into storage usage, activity patterns, and cost drivers across multiple subscriptions and storage accounts required manual aggregation and disparate tooling. Azure Storage Discovery was introduced to fill this gap by providing a unified, enterprise-wide view of Azure Storage assets. The primary goal is to empower IT professionals and cloud architects with detailed insights to optimize capacity, reduce costs, enhance security posture, and improve operational efficiency.

Specific Features and Detailed Changes

Enterprise-wide Visibility: Aggregates storage data across subscriptions, resource groups, and storage accounts to present a consolidated dashboard of storage usage and activity.
Capacity and Activity Analysis: Provides granular metrics on used capacity, data growth trends, and access patterns, enabling deeper understanding of storage consumption.
Cost Optimization Insights: Identifies underutilized storage, redundant data, and potential cost-saving opportunities such as tiering or archiving cold data.
Security Enhancements: Highlights security configurations and anomalies, such as public access settings or unusual access patterns, to help mitigate risks.
Operational Reporting: Enables generation of detailed reports for compliance, auditing, and capacity planning purposes.

Technical Mechanisms and Implementation Methods
Azure Storage Discovery leverages Azure Monitor, Azure Resource Graph, and Azure Storage Analytics to collect telemetry and metadata from storage accounts across an enterprise. It uses scalable data aggregation and indexing techniques to consolidate this information into a centralized repository. The service integrates with Azure Lighthouse for cross-tenant management, allowing managed service providers and enterprises with multiple tenants to gain visibility across boundaries. Data is presented through an intuitive portal interface and can be exported via APIs for integration with custom dashboards or automation workflows.

Use Cases and Application Scenarios

Capacity Planning: IT teams can forecast storage needs based on historical growth trends and avoid unexpected resource shortages.
Cost Management: Finance and cloud operations teams can identify and remediate inefficient storage usage, such as orphaned blobs or rarely accessed data, to reduce spend.
Security Auditing: Security teams can monitor storage access patterns and configurations to detect potential vulnerabilities or compliance violations.
Operational Reporting: Cloud administrators can generate periodic reports for stakeholders detailing storage utilization, activity, and optimization recommendations.
Multi-Tenant Management: Managed service providers can use Storage Discovery to oversee storage estates across multiple customers efficiently.

Important Considerations and Limitations

The service requires appropriate RBAC permissions (typically Reader or higher) on the storage accounts and subscriptions to collect data.
Data latency may exist as telemetry is aggregated periodically rather than in real-time.
Some advanced analytics or custom metrics may require integration with Azure Monitor Logs or custom solutions.
Currently, the service focuses on Azure Blob Storage, File Shares, and related storage services; integration with other storage types may evolve.
Enterprises should evaluate data residency and compliance requirements when aggregating storage metadata across regions.

Integration with Related Azure Services

Azure Monitor: Provides foundational telemetry and alerting capabilities that feed into Storage Discovery.
Azure Resource Graph: Enables efficient querying and inventory of storage resources at scale.
Azure Lighthouse: Facilitates cross-tenant visibility and management for service providers.
Azure Cost Management: Complements Storage Discovery by providing billing and cost analysis tied to storage consumption.
Azure Security Center: Works alongside Storage Discovery to enhance security posture through threat detection and recommendations.

In summary, Azure Storage Discovery GA equips IT professionals with a powerful toolset to gain comprehensive visibility, optimize costs, and strengthen security across their Azure Storage environments, streamlining enterprise storage management and operational decision-making.

4. Generally Available: SAP Business Data Cloud Connect to Azure Databricks

Published: October 15, 2025 17:00:38 UTC Link: Generally Available: SAP Business Data Cloud Connect to Azure Databricks

Update ID: 511743 Data source: Azure Updates API

Categories: Launched, AI + machine learning, Analytics, Azure Databricks, Features

Summary:

What was updated
SAP Business Data Cloud (BDC) Connect to Azure Databricks is now generally available.
Key changes or new features
This update enables secure, bi-directional, zero-copy data sharing between SAP BDC and Azure Databricks leveraging Delta Sharing technology. It allows seamless integration of SAP business data with external datasets in Azure Databricks without data duplication. This facilitates unified analytics and data science workflows by providing real-time access to SAP data alongside other data sources.
Target audience affected
Developers, data engineers, and IT professionals working with SAP data and Azure Databricks for analytics, data integration, and machine learning scenarios will benefit from this capability.
Important notes if any
The zero-copy data sharing reduces data movement overhead and latency, improving efficiency and governance. Users should ensure proper access controls and security configurations when enabling Delta Sharing between SAP BDC and Azure Databricks. This integration supports enhanced collaboration between SAP-centric teams and data science teams on Azure.

For more details, visit: https://azure.microsoft.com/updates?id=511743

Details:

The recent general availability of SAP Business Data Cloud (BDC) Connect to Azure Databricks introduces a robust, secure, and efficient integration enabling bi-directional, zero-copy data sharing between SAP BDC and Azure Databricks through Delta Sharing, aimed at unifying SAP and external data sources for advanced analytics and data science workloads.

Background and Purpose
SAP Business Data Cloud is a cloud-native data management platform designed to provide enterprises with harmonized, high-quality SAP data for analytics and operational use. Azure Databricks is a fast, scalable Apache Spark-based analytics platform optimized for Azure. Prior to this update, integrating SAP BDC data with Azure Databricks required complex ETL pipelines or data duplication, which increased latency, storage costs, and data governance challenges. The purpose of this update is to streamline data sharing between SAP BDC and Azure Databricks, enabling real-time, secure access to SAP data without the need for data copying or synchronization, thus accelerating analytics workflows and reducing operational overhead.

Specific Features and Detailed Changes

Delta Sharing Support: The integration leverages Delta Sharing, an open protocol for secure data sharing, allowing SAP BDC to expose datasets as Delta tables accessible directly from Azure Databricks.
Bi-directional Data Access: Both SAP BDC and Azure Databricks can read and write data, enabling collaborative data workflows and real-time data updates.
Zero-Copy Data Sharing: Data is shared without duplication, eliminating the need for ETL jobs or data movement, which reduces latency and storage costs.
Secure and Governed Access: Built-in authentication and authorization mechanisms ensure that only authorized users and services can access shared data, maintaining compliance with enterprise data governance policies.

Technical Mechanisms and Implementation Methods
The integration uses Delta Sharing’s REST-based protocol to expose SAP BDC datasets as Delta tables. SAP BDC acts as a Delta Sharing server, publishing datasets with defined schemas and access controls. Azure Databricks acts as a Delta Sharing client, connecting to SAP BDC via secure endpoints using token-based authentication. Data is accessed on-demand, with Delta Lake’s ACID transaction support ensuring consistency and reliability. The zero-copy mechanism means that data physically resides in SAP BDC storage, and Databricks queries it directly without ingestion or replication. Implementation involves configuring SAP BDC to enable Delta Sharing endpoints, setting up access tokens or service principals for authentication, and configuring Azure Databricks clusters with the Delta Sharing connector to consume shared datasets.

Use Cases and Application Scenarios

Unified Analytics: Data scientists and analysts can combine SAP operational data with external datasets in Azure Databricks for comprehensive business insights.
Real-Time Reporting: Business intelligence teams can build dashboards that reflect the latest SAP data without delays caused by data replication.
Data Science and Machine Learning: Data engineers can access SAP data directly in Databricks notebooks for feature engineering and model training.
Cross-Organizational Collaboration: Different teams or partners can securely share SAP datasets without moving data, preserving data sovereignty.

Important Considerations and Limitations

Data Latency: While zero-copy sharing reduces latency compared to batch ETL, query performance depends on network speed and SAP BDC storage performance.
Access Control Complexity: Proper configuration of authentication and authorization is critical to prevent unauthorized data access.
Data Format Compatibility: Delta Sharing requires data to be in Delta Lake format; SAP BDC datasets must be appropriately formatted or converted.
Feature Parity: Some advanced Delta Lake features may not be fully supported in the shared datasets depending on SAP BDC implementation.

Integration with Related Azure Services

Azure Active Directory (AAD): Used for identity management and secure authentication between SAP BDC and Azure Databricks.
Azure Data Lake Storage (ADLS): SAP BDC may leverage ADLS Gen2 as underlying storage

5. Public Preview: Private Link Service Direct Connect

Published: October 15, 2025 17:00:38 UTC Link: Public Preview: Private Link Service Direct Connect

Update ID: 503988 Data source: Azure Updates API

Categories: In preview, Networking, Azure Private Link, Features, Services, Security, Management

Summary:

What was updated
Azure Private Link Service now supports Direct Connect in public preview, enabling a simplified and more secure way to expose your applications privately to customers.
Key changes or new features
The update removes the requirement to place applications behind a standard load balancer when configuring Private Link Service. Developers can now directly connect their services, reducing complexity and potentially lowering latency. This enhancement streamlines the setup process and improves network security by minimizing exposure to the public internet.
Target audience affected
Developers and IT professionals who build and manage private, secure application endpoints using Azure Private Link Service will benefit from this update. It is particularly relevant for those integrating services with customers or partners over private connectivity.
Important notes if any
This feature is currently in public preview, so it should be used with caution in production environments. Users should review the preview limitations and provide feedback to Microsoft. Also, ensure compatibility with existing network and security configurations before adopting Direct Connect.

For more details, visit: https://azure.microsoft.com/updates?id=503988

Details:

The Azure update titled “Public Preview: Private Link Service Direct Connect” introduces a significant enhancement to the Azure Private Link service, enabling more streamlined and secure connectivity for applications exposed to customers via private endpoints. This update addresses existing complexities and expands the deployment flexibility of Private Link services.

Background and Purpose of the Update
Azure Private Link allows customers to access Azure PaaS services or customer-owned services over a private endpoint in their virtual network, thereby eliminating exposure over the public internet. Traditionally, to expose an application privately using Private Link, the service owner must deploy the Private Link service behind a standard Azure Load Balancer (SLB). This requirement adds architectural complexity, operational overhead, and potential latency. The purpose of this update is to simplify the architecture by enabling direct connectivity to Private Link services without mandating the use of a standard load balancer, thereby improving performance, reducing costs, and easing management.

Specific Features and Detailed Changes

Direct Connect Capability: The core feature introduced is the ability to connect directly to a Private Link service without placing it behind a standard load balancer. This removes the dependency on SLB for Private Link service exposure.
Simplified Setup: Service owners can now configure Private Link services with direct network interfaces, reducing the number of components and configuration steps required.
Improved Performance: By eliminating the load balancer hop, network latency is reduced, and throughput can be improved.
Public Preview Availability: This feature is currently available in public preview, allowing customers to test and provide feedback before general availability.

Technical Mechanisms and Implementation Methods
Previously, Private Link services required a frontend IP configuration on a standard load balancer to route traffic from private endpoints to backend resources. With Direct Connect, Azure allows the Private Link service to be exposed directly via a network interface associated with the service. This is achieved by:

Creating a Private Link service resource linked directly to the network interface(s) of the application or service.
Enabling inbound traffic from private endpoints to connect directly to these network interfaces without traversing a load balancer.
Maintaining the security model where only approved private endpoint connections can access the service.
Supporting integration with Network Security Groups (NSGs) and routing policies to control traffic flow.

Use Cases and Application Scenarios

Simplified Service Exposure: Developers and service owners can expose internal applications (e.g., APIs, microservices) privately to customers or partners without the overhead of managing load balancers.
Cost Optimization: Reducing or eliminating the need for standard load balancers lowers infrastructure costs, especially for services with many Private Link connections.
Latency-Sensitive Applications: Applications requiring low latency and high throughput benefit from direct connectivity, improving user experience.
Multi-Tenant SaaS Services: SaaS providers can securely expose their services to tenants over private endpoints with simplified architecture and reduced management complexity.

Important Considerations and Limitations

Preview Status: As a public preview feature, it should be used cautiously in production environments, with awareness of potential changes or limitations.
Supported Regions and Services: Availability may initially be limited to certain Azure regions and specific service types; users should verify regional support.
Security Controls: While direct connectivity simplifies architecture, it remains critical to properly configure NSGs, firewall rules, and endpoint policies to maintain security posture.
Compatibility: Existing Private Link services using standard load balancers will continue to function; migration to Direct Connect requires planning and validation.
Monitoring and Diagnostics: New monitoring capabilities or adjustments to existing diagnostics may be necessary to track traffic flows and troubleshoot issues.

Integration with Related Azure Services

Azure Virtual Network: Direct Connect integrates tightly with VNets, leveraging private endpoints and network interfaces for secure connectivity.
Azure Network Security Groups (NSGs): NSGs continue to provide granular traffic filtering on network

6. Retirement: The F, Fs, Fsv2, Lsv2, G, Gs, Av2, Amv2, and B series VMs are retiring in 2028

Published: October 15, 2025 16:15:01 UTC Link: Retirement: The F, Fs, Fsv2, Lsv2, G, Gs, Av2, Amv2, and B series VMs are retiring in 2028

Update ID: 500682 Data source: Azure Updates API

Categories: Retirements

Summary:

What was updated
Microsoft announced the retirement of several Azure Virtual Machine (VM) series: F, Fs, Fsv2, Lsv2, G, Gs, Av2, Amv2, and B series. These VM types will be officially retired on November 15, 2028.
Key changes or new features
After the retirement date, these VM series will no longer be available for deployment or purchase. Existing VMs running on these series must be migrated or upgraded before the deadline to avoid service disruption.
Target audience affected
Developers and IT professionals currently using or planning to use any of the retiring VM series for their workloads and applications in Azure.
Important notes if any
It is critical to plan migration strategies well in advance to newer VM series that offer improved performance, security, and features. Review your current VM usage and start testing alternatives to ensure seamless transition before November 15, 2028. Failure to migrate may result in inability to run workloads on these VM types post-retirement.

For more details, visit: https://azure.microsoft.com/updates?id=500682

Details:

The announced retirement of the F, Fs, Fsv2, Lsv2, G, Gs, Av2, Amv2, and B series Azure Virtual Machines (VMs) effective November 15, 2028, marks a planned deprecation of these legacy VM families, requiring customers to transition workloads to newer VM types prior to this date to maintain operational continuity. This update reflects Microsoft’s ongoing effort to optimize its compute infrastructure by phasing out older hardware and VM SKUs that may no longer meet evolving performance, security, and efficiency standards.

Background and Purpose:
These VM series have served diverse workload needs over the years, ranging from general-purpose (Av2, Amv2, B series) to compute-optimized (F, Fs, Fsv2) and storage-optimized (Lsv2) configurations, as well as high-memory and GPU-enabled options (G, Gs). However, advancements in Azure’s underlying hardware, processor generations, and platform capabilities have led to the introduction of newer VM families offering better price-performance ratios, enhanced security features, and improved scalability. The retirement is intended to streamline the VM portfolio, reduce maintenance overhead, and encourage customers to adopt modern VM types that leverage the latest Azure innovations.

Specific Features and Detailed Changes:
Post-November 15, 2028, these VM series will no longer be available for deployment or resizing. Existing VMs running these SKUs will cease to function, and customers will be unable to create new instances or scale existing ones using these series. The update necessitates proactive migration planning to alternative VM families such as the Dv5, Ev4, or newer B-series VMs, which provide comparable or superior CPU, memory, and storage capabilities. This change also impacts associated features like VM scale sets and availability sets that incorporate these VM types.

Technical Mechanisms and Implementation Methods:
Microsoft will enforce the retirement by disabling provisioning and management operations on the affected VM SKUs within the Azure Resource Manager (ARM) platform. Customers should leverage Azure Migrate and Azure Cost Management tools to assess current VM usage, identify dependencies, and estimate migration costs. Migration can be performed via Azure Site Recovery, VM image capture and redeployment, or re-architecting workloads for containerization or Platform as a Service (PaaS) alternatives. Automation scripts and ARM templates referencing retired VM sizes will require updates to prevent deployment failures.

Use Cases and Application Scenarios:
These VM series have historically supported a wide range of applications including web servers, batch processing, development/test environments, and database workloads. For example, F-series VMs have been favored for compute-intensive tasks, while Lsv2 series were used for low-latency storage scenarios. Post-retirement, customers running such workloads should evaluate newer VM families that align with their performance and cost requirements, ensuring minimal disruption and leveraging improved Azure capabilities such as enhanced networking, accelerated networking, and better integration with Azure security services.

Important Considerations and Limitations:

Migration should be planned well in advance of the 2028 deadline to avoid service interruptions.
Some legacy applications may require compatibility testing on new VM types due to differences in CPU architecture or driver support.
Pricing models and SLA guarantees may differ on newer VM families, necessitating budget adjustments.
Backup and disaster recovery strategies should be updated to reflect the new VM configurations.
Customers using Reserved Instances or Spot VMs with these SKUs must review contract terms and transition plans.

Integration with Related Azure Services:
The retirement impacts services tightly coupled with VM infrastructure, including Azure Virtual Machine Scale Sets (VMSS), Azure Backup, Azure Monitor, and Azure Security Center. Customers should verify that monitoring alerts, automation runbooks, and security policies are updated to reference supported VM sizes. Additionally, integration with Azure DevOps pipelines and Infrastructure as Code (IaC) tools must be revised to prevent deployment errors. Transitioning to newer VM families also

7. Generally Available: Locations API Update for UK Azure Regions

Published: October 15, 2025 16:00:24 UTC Link: Generally Available: Locations API Update for UK Azure Regions

Update ID: 513376 Data source: Azure Updates API

Categories: Launched, Management and governance, Azure Resource Manager, Compliance, Security

Summary:

What was updated
Azure has updated the Locations API metadata for UK-based regions, specifically modifying the geographyGroup and regionalDisplayName attributes.
Key changes or new features
The geographyGroup classification and the regionalDisplayName values for UK Azure regions have been revised to better reflect current compliance and regulatory frameworks. These updates ensure that location metadata aligns with the latest governance and data residency requirements.
Target audience affected
Developers and IT professionals who consume the Azure Locations API for region metadata, especially those managing resources or compliance in UK Azure regions, will be impacted. This includes teams automating deployments, compliance auditing, or regional data handling based on API responses.
Important notes if any
The changes will take effect in October 2025. It is recommended to review any automation, scripts, or applications that parse or rely on geographyGroup and regionalDisplayName values to ensure compatibility with the updated metadata. Staying informed will help maintain compliance and avoid disruptions in region-specific operations.

For more details, visit: https://azure.microsoft.com/updates?id=513376

Details:

The October 2025 update to the Azure Locations API introduces revised metadata for UK-based Azure regions, specifically modifying the geographyGroup and regionalDisplayName attributes to better reflect current compliance and regulatory frameworks. This change is designed to ensure that Azure’s regional metadata accurately aligns with evolving UK data residency and sovereignty requirements, thereby supporting organizations’ governance and risk management strategies.

Background and Purpose:
Azure’s Locations API provides programmatic access to metadata about Azure regions, including geographic grouping and display names, which are critical for compliance, billing, and resource management. The UK government and regulatory bodies have introduced updated guidelines emphasizing data residency and sovereignty, prompting Azure to update its metadata to reflect these changes. This update ensures that customers targeting UK regions can rely on accurate, compliant metadata when designing their cloud architectures and compliance controls.

Specific Features and Detailed Changes:
The update modifies two key metadata fields for UK regions:

geographyGroup: This field groups regions by geography for compliance and billing purposes. The update reclassifies UK regions to a geographyGroup that aligns with UK-specific compliance zones, distinguishing them more clearly from other European or global regions.
regionalDisplayName: This user-friendly display name is updated to reflect the new compliance context, potentially including references to UK-specific data residency or sovereignty assurances.

These changes apply to all UK Azure regions currently available, such as UK South and UK West, and will be reflected in the Locations API responses starting October 2025.

Technical Mechanisms and Implementation Methods:
The Locations API is a RESTful service endpoint that returns JSON-formatted metadata about Azure regions. Clients query this API to retrieve up-to-date region information. With this update, the API’s JSON response schema remains unchanged, but the values of geographyGroup and regionalDisplayName fields for UK regions will be updated. This backward-compatible approach ensures existing integrations continue functioning without modification, while providing enhanced metadata for compliance-aware applications.

Developers and automation scripts that consume the Locations API should plan to refresh their cached metadata after the update to incorporate the new values. This can be done by scheduling periodic API calls or triggering refreshes in deployment pipelines to ensure compliance-related decisions use the latest metadata.

Use Cases and Application Scenarios:

Compliance and Governance: Organizations subject to UK data residency laws can programmatically verify that resources are deployed in compliant regions by checking the updated geographyGroup metadata.
Automated Deployment Pipelines: Infrastructure-as-Code (IaC) tools and deployment scripts can dynamically select UK regions based on updated metadata, ensuring resources are provisioned in appropriate compliance zones.
Billing and Cost Management: Accurate geography grouping assists in cost allocation and reporting aligned with UK-specific billing requirements.
Multi-Region Application Design: Applications with geo-fencing or data sovereignty requirements can leverage the updated regionalDisplayName to present accurate region information to end users or administrators.

Important Considerations and Limitations:

The update affects only metadata; there are no changes to the underlying physical infrastructure or service availability in UK regions.
Clients relying on hardcoded geographyGroup or regionalDisplayName values must update their logic to accommodate the new values to avoid inconsistencies.
The update is backward-compatible, but testing is recommended to ensure downstream systems correctly interpret the new metadata.
The update applies only to UK regions; other global regions remain unaffected.

Integration with Related Azure Services:

Azure Policy and Blueprints: These services can leverage the updated metadata to enforce region-specific compliance policies more accurately.
Azure Cost Management: Updated geographyGroup data can improve cost tracking and reporting for UK-based resources.
Azure Resource Manager (ARM) Templates and Bicep: Templates that dynamically query the Locations API can incorporate the updated metadata to select compliant UK regions during deployments.
Azure SDKs and CLI: Tools that expose region metadata will reflect these changes once the API is updated, enabling developers to build compliance-aware tooling.

This report was automatically generated - 2025-10-16 03:05:12 UTC

This site is open source. Improve this page.