Generated on: August 21, 2025 Target period: Within the last 24 hours Processing mode: Details Mode Number of updates: 5 items
Published: August 20, 2025 17:45:19 UTC Link: Public Preview: Azure Bastion now supports connectivity to private AKS clusters via tunneling
Update ID: 500996 Data source: Azure Updates API
Categories: In preview, Networking, Security, Compute, Containers, Azure Bastion, Azure Kubernetes Service (AKS), Features
Summary:
What was updated
Azure Bastion now supports connectivity to private Azure Kubernetes Service (AKS) clusters via tunneling.
Key changes or new features
Users can establish a secure tunnel from their local machines through Azure Bastion directly to the AKS API server. This allows developers and IT professionals to use standard Kubernetes tools (kubectl, etc.) to manage private AKS clusters without exposing the API server publicly. The feature also supports seamless access to both private and public AKS clusters’ API servers through the same mechanism.
Target audience affected
Developers, DevOps engineers, and IT administrators managing AKS clusters, especially those working with private AKS clusters requiring secure, private access to the Kubernetes API server.
Important notes if any
This feature is currently in public preview. It enhances security by eliminating the need for public IP exposure or VPNs to access private AKS API servers. Users should evaluate the preview feature in non-production environments before broad adoption.
For more details, visit: https://azure.microsoft.com/updates?id=500996
Details:
The recent Azure Bastion public preview update introduces native support for secure connectivity to private Azure Kubernetes Service (AKS) clusters via tunneling, enabling IT professionals to seamlessly access AKS API servers without exposing them to the public internet.
Background and Purpose:
Traditionally, accessing private AKS clusters—where the Kubernetes API server endpoint is isolated within a virtual network—requires complex VPN setups, jump boxes, or exposing the API server endpoint publicly, which can increase security risks. Azure Bastion, a fully managed PaaS service providing secure RDP/SSH access to VMs without public IPs, now extends its tunneling capabilities to AKS clusters. This update aims to simplify and secure cluster management by allowing direct, encrypted access to private AKS API servers from a local machine using standard Kubernetes CLI tools (kubectl), without additional network infrastructure.
Specific Features and Detailed Changes:
Technical Mechanisms and Implementation Methods:
Azure Bastion acts as a secure proxy within the Azure virtual network hosting the AKS cluster. When a user initiates a connection, Bastion establishes an encrypted tunnel from the user’s local machine to the AKS API server endpoint inside the VNet. This is achieved by leveraging Bastion’s existing RDP/SSH proxy infrastructure, extended to support Kubernetes API traffic forwarding. The user configures kubectl to connect via this tunnel, typically by setting a local port forwarding or proxy configuration that routes API calls through Bastion. Authentication and authorization continue to be managed via Azure AD and Kubernetes RBAC, ensuring secure access control.
Use Cases and Application Scenarios:
Important Considerations and Limitations:
Integration with Related Azure Services:
Published: August 20, 2025 17:30:35 UTC Link: Public Preview: Azure NetApp Files Flexible service level now supports cool access
Update ID: 500712 Data source: Azure Updates API
Categories: In preview, Storage, Azure NetApp Files, Features
Summary:
What was updated
Azure NetApp Files Flexible service level now supports cool access in public preview.
Key changes or new features
The Flexible service level, which enables independent configuration of storage capacity and throughput, has been enhanced to include cool access tier support. This allows customers to optimize costs by storing infrequently accessed data at a lower price point while maintaining the ability to scale performance independently. It is particularly suited for workloads requiring large capacity but low throughput, such as archival or backup data.
Target audience affected
Developers and IT professionals managing file storage solutions with Azure NetApp Files, especially those handling workloads with variable performance and capacity needs or seeking cost optimization through tiered storage.
Important notes if any
This feature is currently in public preview, so users should evaluate it in non-production environments before full deployment. Integration with existing Flexible service level configurations is seamless, but monitoring access patterns is recommended to ensure cost-effectiveness when using the cool tier.
For more details, visit: https://azure.microsoft.com/updates?id=500712
Details:
The recent public preview update for Azure NetApp Files introduces support for cool access within the Flexible service level, enhancing storage management by enabling independent configuration of capacity and throughput tailored to workload demands. This update addresses the need for cost-efficient storage solutions that balance performance and capacity, particularly for workloads requiring large volumes with lower throughput.
Background and Purpose:
Azure NetApp Files (ANF) is a high-performance, enterprise-grade file storage service designed for demanding workloads. The Flexible service level was introduced to decouple storage capacity from throughput, allowing customers to optimize costs by precisely matching performance to workload needs. Prior to this update, Flexible service level primarily supported hot access tiers optimized for high throughput. The addition of cool access support aims to provide a more cost-effective tier for workloads with infrequent access patterns or lower performance requirements, aligning with Azure’s tiered storage strategy.
Specific Features and Detailed Changes:
Technical Mechanisms and Implementation Methods:
Azure NetApp Files uses underlying SSD and HDD storage media managed by the Azure NetApp Files control plane. The cool access tier leverages storage media optimized for lower cost and power consumption, suitable for less frequently accessed data. The Flexible service level’s decoupled architecture allows throughput to be scaled independently, which is implemented via QoS policies at the storage backend. The introduction of cool access involves integrating tiering policies that redirect data to appropriate storage media while maintaining throughput guarantees configured by the user. Customers can select the access tier during volume creation or modify it on existing volumes through the Azure portal, CLI, or REST API.
Use Cases and Application Scenarios:
Important Considerations and Limitations:
Integration with Related Azure Services:
In summary, the addition of cool access support to
Published: August 20, 2025 16:45:09 UTC Link: Private Preview: DCesv6 and ECesv6 series confidential VMs with Intel® TDX
Update ID: 489745 Data source: Azure Updates API
Categories: In preview, Compute, Virtual Machines, Features, Services, Security
Summary:
What was updated
Azure has introduced the private preview of the DCesv6 and ECesv6 series Confidential Virtual Machines (VMs), leveraging 5th Gen Intel® Xeon® processors (Emerald Rapids) with Intel® Trust Domain Extensions (Intel® TDX).
Key changes or new features
These new VM series provide enhanced hardware-based confidential computing capabilities by isolating workloads within Intel TDX-enabled trusted execution environments. This improves data protection and workload isolation for sensitive applications. The DCesv6 and ECesv6 VMs offer improved performance and security compared to previous confidential VM generations, enabling organizations to run highly sensitive workloads in the cloud with greater assurance.
Target audience affected
Developers and IT professionals focused on security-sensitive workloads, such as financial services, healthcare, and government sectors, will benefit from these VMs. Organizations requiring confidential computing to protect data in use and meet compliance requirements are the primary audience.
Important notes if any
This offering is currently in private preview, so interested customers must apply for access. The use of Intel TDX requires compatible software stacks and may involve adjustments in workload deployment to fully leverage confidential computing features. Further details and availability timelines will be provided as the preview progresses.
Details:
The Azure update announces the private preview release of the DCesv6 and ECesv6 series Confidential Virtual Machines (VMs), leveraging Intel® Trust Domain Extensions (Intel® TDX) on 5th Gen Intel® Xeon® processors (Emerald Rapids). This advancement represents Azure’s next generation of confidential computing infrastructure designed to enhance data security and privacy in cloud workloads.
Background and Purpose
Confidential computing aims to protect data in use by isolating workloads within hardware-based trusted execution environments (TEEs). Previous Azure confidential VM series utilized technologies like AMD SEV and Intel SGX. The introduction of DCesv6 and ECesv6 series with Intel TDX addresses evolving security requirements by providing stronger isolation boundaries that protect data and code from unauthorized access, including from higher-privileged software such as the hypervisor or host OS. This update is targeted at organizations with stringent data protection needs, such as those in finance, healthcare, and government sectors.
Specific Features and Detailed Changes
Technical Mechanisms and Implementation Methods
Intel TDX extends the CPU architecture to create isolated execution environments called Trust Domains. Each TD runs a guest OS and applications, with memory encryption keys managed by the CPU itself, preventing the host or hypervisor from inspecting or tampering with the VM’s memory. The VM launch process involves remote attestation, allowing customers to verify the integrity and configuration of the confidential VM before deploying sensitive workloads. Azure’s hypervisor integrates with Intel TDX to manage these Trust Domains while maintaining cloud-scale orchestration and management.
Use Cases and Application Scenarios
Important Considerations and Limitations
Integration with Related Azure Services
Published: August 20, 2025 16:30:32 UTC Link: Retirement: Microsoft Sentinel Deprecation in Microsoft Azure operated by 21Vianet Announcement
Update ID: 498754 Data source: Azure Updates API
Categories: Hybrid + multicloud, Security, Microsoft Sentinel, Retirements
Summary:
What was updated
Microsoft announced the retirement and deprecation of Microsoft Sentinel in the Microsoft Azure environment operated by 21Vianet.
Key changes or new features
The service will be discontinued due to increasing infrastructure and operational complexity, making continued support unfeasible. No new features will be introduced, and existing Microsoft Sentinel deployments under 21Vianet will be phased out.
Target audience affected
Developers, IT professionals, and security teams using Microsoft Sentinel within the Azure operated by 21Vianet cloud region in China will be impacted. Organizations relying on this service for security information and event management (SIEM) need to plan migration or alternative solutions.
Important notes if any
Customers should begin transitioning their security monitoring and incident response workflows to other supported platforms or regions. Microsoft recommends reviewing current Sentinel configurations and data retention policies to avoid service disruption. Further guidance and timelines for retirement will be provided by Microsoft to assist with migration planning. This change affects only the Azure operated by 21Vianet environment and does not impact Microsoft Sentinel availability in other Azure global regions.
Details:
The recent announcement regarding the retirement of Microsoft Sentinel in the Microsoft Azure operated by 21Vianet environment reflects a strategic decision driven by operational and infrastructure complexities unique to this sovereign cloud region. Microsoft Sentinel, a cloud-native Security Information and Event Management (SIEM) and Security Orchestration Automated Response (SOAR) solution, has been a critical tool for threat detection, investigation, and response. However, maintaining parity of this service in the 21Vianet-operated Azure China region has become increasingly challenging.
Background and Purpose of the Update
Microsoft continuously evaluates its service portfolio to ensure optimal security, reliability, and performance. The decision to deprecate Microsoft Sentinel in the Azure China region operated by 21Vianet stems from the growing complexity in infrastructure management and operational overhead, which impacts the ability to deliver the service at the expected standards. This update aims to inform customers of the impending retirement, enabling them to plan migration or alternative security monitoring strategies accordingly.
Specific Features and Detailed Changes
The core change is the complete retirement of Microsoft Sentinel within the Azure China operated by 21Vianet environment. This means that new deployments of Sentinel will no longer be possible, and existing Sentinel workspaces will be phased out over a defined timeline. Key features affected include:
Technical Mechanisms and Implementation Methods
Microsoft Sentinel operates by ingesting security data into Log Analytics workspaces, applying analytics rules, and triggering alerts and automated responses. The retirement implies that these underlying Log Analytics workspaces will no longer support Sentinel-specific features. Customers will need to export or archive their existing logs and configurations before the service is disabled. Microsoft typically provides a deprecation timeline with milestones for disabling new data ingestion, alerting, and eventual workspace deletion. Customers should leverage Azure Resource Manager (ARM) templates or APIs to export configurations and data where applicable.
Use Cases and Application Scenarios
Microsoft Sentinel is widely used for centralized security monitoring, threat hunting, compliance reporting, and incident response automation. Organizations operating in China using Azure 21Vianet who rely on Sentinel for these scenarios will need to seek alternative solutions. Potential alternatives include third-party SIEM solutions compatible with Azure China or native Azure Security Center capabilities that remain supported. This update primarily affects enterprises with stringent security monitoring requirements who must adapt their security operations workflows accordingly.
Important Considerations and Limitations
Integration with Related Azure Services
Microsoft Sentinel integrates deeply with Azure Security Center, Azure Active Directory, Azure Monitor, and Logic Apps for automated workflows. With the retirement, these integrations will be impacted in the 21Vianet environment. Customers should evaluate how these services can be used independently or in conjunction with third-party SIEM tools. For example, Azure Security Center will continue to provide security recommendations and alerts, but without Sentinel’s advanced analytics and orchestration capabilities. Logic Apps can still be used for automation but will require reconfiguration outside of Sentinel playbooks.
In summary, the retirement of Microsoft Sentinel in the Azure China region operated by 21Vianet is a significant change driven by operational challenges,
Published: August 20, 2025 16:30:32 UTC Link: Retirement: Microsoft Defender for Cloud Deprecation in Microsoft Azure Operated by 21Vianet Announcement
Update ID: 498749 Data source: Azure Updates API
Categories: Hybrid + multicloud, Security, Microsoft Defender for Cloud, Retirements
Summary:
What was updated
Microsoft announced the retirement of Microsoft Defender for Cloud in the Azure operated by 21Vianet environment.
Key changes or new features
The service will be deprecated due to increasing infrastructure and operational complexity, making continued support unfeasible. No new features will be introduced, and existing Defender for Cloud protections in this region will be discontinued.
Target audience affected
Developers, IT professionals, and security teams using Microsoft Defender for Cloud within Azure operated by 21Vianet (China region) are directly impacted. Customers relying on Defender for Cloud for workload protection and security management in this environment must plan for alternative solutions.
Important notes if any
Microsoft advises customers to transition to other security tools or services as Defender for Cloud support ends in this region. It is critical to review current security postures and update configurations accordingly to maintain protection levels. Further details and timelines should be monitored via official Azure updates. This retirement does not affect Microsoft Defender for Cloud in other global Azure regions.
Details:
The recent announcement regarding the retirement of Microsoft Defender for Cloud in the Microsoft Azure environment operated by 21Vianet reflects a strategic decision driven by increasing infrastructure and operational complexities that impact the service’s sustainability and reliability within this specific regional cloud. This update signifies the deprecation of Microsoft Defender for Cloud—Microsoft’s unified cloud security posture management (CSPM) and cloud workload protection platform (CWPP)—in the China region managed by 21Vianet, which operates Azure services under local compliance and operational frameworks.
Background and Purpose of the Update
Microsoft Defender for Cloud provides advanced threat protection, continuous security assessment, and compliance management across Azure resources. However, the Azure operated by 21Vianet environment has unique infrastructure and regulatory requirements that introduce additional operational overhead. After comprehensive evaluation, Microsoft concluded that maintaining Defender for Cloud in this environment is no longer viable without compromising service quality or compliance. The retirement aims to streamline service offerings, reduce complexity, and focus on core security capabilities that align with regional operational constraints.
Specific Features and Detailed Changes
The update entails the complete deprecation of Microsoft Defender for Cloud within the 21Vianet-operated Azure region. This means that all Defender for Cloud features—including continuous security posture assessment, advanced threat detection, vulnerability management, and compliance monitoring—will cease to function in this environment. Customers will no longer receive security alerts, recommendations, or integrated threat intelligence from Defender for Cloud services. The retirement also impacts integrations such as Security Center dashboards, automated remediation workflows, and API endpoints related to Defender for Cloud.
Technical Mechanisms and Implementation Methods
The deprecation is implemented by disabling Defender for Cloud service endpoints and backend processing within the 21Vianet Azure infrastructure. This involves shutting down telemetry collection, security analytics, and policy evaluation engines specific to Defender for Cloud. Customers’ existing configurations, policies, and security alerts tied to Defender for Cloud will be invalidated. Microsoft will likely provide transition guidance and timelines to allow customers to export existing data and migrate to alternative security solutions. The operational change is region-specific and does not affect Microsoft Defender for Cloud in other global Azure regions.
Use Cases and Application Scenarios
Prior to retirement, Defender for Cloud was widely used for securing multi-cloud and hybrid environments, enforcing compliance standards (e.g., CIS, ISO, NIST), and detecting threats across virtual machines, containers, databases, and serverless workloads. Post-retirement, customers in the 21Vianet region must seek alternative security posture management tools or native security features offered by Azure or third-party vendors compliant with local regulations. Use cases involving automated threat response, integrated vulnerability scanning, and compliance reporting will require re-architecting to accommodate the absence of Defender for Cloud.
Important Considerations and Limitations
Integration with Related Azure Services
Microsoft Defender for Cloud integrates deeply with Azure Security Center, Azure Sentinel, Azure Policy, and Azure Monitor. With its retirement in the 21Vianet region, these integrations will be disrupted. Azure Security Center’s unified security management features will be limited, and Azure Sentinel’s threat detection capabilities may lose Defender for Cloud’s telemetry inputs. Customers should evaluate native security features within Azure 21Vianet and consider third-party SIEM or CSPM tools to maintain security operations continuity. Additionally, Azure Policy enforcement will continue but without Defender for Cloud’s enhanced security recommendations.
In summary, the retirement of Microsoft Defender for Cloud in the Azure operated by 21
This report was automatically generated - 2025-08-21 03:03:00 UTC