Category: Microsoft
Category Archives: Microsoft
Modernizing Azure Automation: A 2023 Retrospective and Future outlook
Majority of the organizations are at different stages of their cloud adoption journey, as they navigate through public clouds, private clouds and on-premises data centers. Their IT landscape is often characterized by multiple applications and services, that are spread across diverse environments. Managing this complex landscape manually or with multiple orchestration services can be daunting and inefficient. Irrespective of whether organizations are completely on-premises or exploring cloud solutions for the first time or born in the cloud, all share a common goal: to enhance efficiency and agility. Orchestration has become indispensable to streamline management tasks effectively to reduce cost and allow business to focus on its core priorities.
Azure Automation has emerged as a pivotal service for managing complex hybrid environments by delivering a consistent user experience across multiple cloud platforms. Customers utilize Azure Automation for a variety of tasks, such as resource lifecycle management, mission-critical jobs that often require manual intervention, guest management at scale and other common enterprise IT operations such as periodic maintenance. It targets orchestration on a wide array of resources such as Virtual Machines, Arc-enabled Servers, Databases, Storage, Azure Active Directory, Mailboxes and much more, along with complex workflows involving many resources. Azure Automation provides a complete end-to-end solution that facilitates authoring of PowerShell and Python scripts, with a serverless platform for execution of those scripts, offers the flexibility to execute those scripts on-premises or in customer’s local environment and monitors those executions comprehensively.
A 2023 Retrospective
Azure Automation has made substantial investments in modernizing its platform and significantly improving user experience over the previous year and promises to continue delivering value to its customers in the years to come. Here is a summary of key enhancements so far, that have laid the foundation for even greater benefits in the future:
New runtime languages: PowerShell 7.2 and Python 3.8 runbooks are Generally available. This enables Developers and IT administrators to execute runbooks in the most popular scripting languages. Customers are adopting Azure Automation to consolidate their scripts that are distributed on-premises and across multiple clouds and gaining operational efficiency by managing their Azure and Arc-enabled resources through a consistent experience.
Support for Azure CLI commands: Now Azure CLI commands can be invoked in Azure Automation runbooks (preview). The rich command set of Azure CLI expands capabilities of runbooks even further, allowing you to reap combined benefits of both to automate and streamline resource management on Azure.
Advanced script authoring experience: Azure Automation extension for Visual Studio Code is Generally Available. It offers an advanced authoring and editing experience for PowerShell and Python scripts. The extension leverages GitHub Copilot for intelligent code completion that provides suggestions directly within the editor, thereby making the coding process faster and simpler.
Granular control through Runtime environment: Module management and runbook update has never been so hassle-free! Runtime environment (preview) allows complete configuration of the job execution environment without worrying about mixing different module versions in a single Automation account. You can upgrade runbooks to newer language versions with minimal effort to stay secure and take advantage of latest functionalities. It is strongly recommended to use Runtime environment to update runbooks on end-of-support runtimes PowerShell 7.1 and Python 2.7 since both PowerShell 7.1 and Python 2.7 have been announced retired by parent products PowerShell and Python respectively.
Unified experience across diverse platforms: Hybrid Worker extension is Generally Available and supports Azure VMs, off-Azure servers registered as Arc-enabled servers, Arc-enabled SCVMM and Arc-enabled VMware VMs. This empowers organizations to orchestrate their entire hybrid environment at scale through a single interface. You can directly install the extension on Azure or Arc-enabled servers and execute runbooks for a variety of scenarios. These include in-guest VM management, access to other services privately from Azure Virtual Network, and to overcome organizational restrictions of keeping data in cloud.
State-of-the-art backend platform: Azure Automation has redesigned its platform and majority of the runbooks are now executing successfully on secure and modern Hyper-V containers. With this move and additional measures taken to minimize infrastructure failures, the service has further hardened its security and improved reliability. These enhancements have established the groundwork for faster release of innovative features in the coming months. If your runbooks have taken dependency on old platform and you observe unexpected job failures, take a look at the known issues and workarounds here.
Future outlook
Azure Automation is continuously evolving and enhancing its capabilities, striving to become the best-in-class platform for resource management in an adaptive cloud. It is providing organizations with more efficient and reliable ways to navigate across different services and applications residing in multiple clouds (on-premises data centers, private clouds, and public clouds). In addition to its ongoing commitments to strengthen security, reliability, resiliency and scale, Azure Automation is building critical features to further improve customer experience. Here are some of the improvements currently under development and expected to be released soon:
Aligning Runbook support with latest Runtime releases: Azure Automation is working actively to reduce the time gap between release of new PowerShell and Python language versions and their support in runbooks. Stay tuned for upcoming announcements on PowerShell 7.4!
Source control integration for new runtimes: You would now be able to keep runbooks updated with scripts in GitHub or Azure DevOps source control repository. This feature simplifies the process of promoting code that has undergone testing in the development environment to the production Automation account.
Native integration with Azure services: Azure Automation is already being used for creating runbooks that orchestrate across multiple resources. Keep an eye out for deeper integrations with more Azure resources for ease of management and to improve efficiency.
Richer Gallery of Runbooks: Improvements are planned in Runbook Gallery to help you search runbooks effortlessly for common scenarios and boost your productivity. Contribute to the community by sharing your scripts here.
Reminder for upcoming Retirements
Ensure to transition to the supported services/features prior to the retirement date:
AzureRM PowerShell module will retire on 29 February 2024 and will be replaced by Az PowerShell module. Update your outdated runbooks immediately.
With the retirement of Log Analytics agent, following dependent services/features will retire on 31 August 2024. It is strongly recommended to migrate to supported services before retirement date:
Log Analytics agent-based Hybrid Runbook Worker will be retired in favor of extension-based Hybrid Runbook Worker. Learn more.
Azure Automation Update Management will be retired in favor of Azure Update Manager. Learn more.
Azure Automation Change Tracking & Inventory will be retired in favor of Change Tracking & Inventory with AMA. Learn more.
For any questions or feedback, please reach out to askazureautomation@microsoft.com
Microsoft Tech Community – Latest Blogs –Read More
Modernizing Azure Automation: A 2023 Retrospective and Future outlook
Majority of the organizations are at different stages of their cloud adoption journey, as they navigate through public clouds, private clouds and on-premises data centers. Their IT landscape is often characterized by multiple applications and services, that are spread across diverse environments. Managing this complex landscape manually or with multiple orchestration services can be daunting and inefficient. Irrespective of whether organizations are completely on-premises or exploring cloud solutions for the first time or born in the cloud, all share a common goal: to enhance efficiency and agility. Orchestration has become indispensable to streamline management tasks effectively to reduce cost and allow business to focus on its core priorities.
Azure Automation has emerged as a pivotal service for managing complex hybrid environments by delivering a consistent user experience across multiple cloud platforms. Customers utilize Azure Automation for a variety of tasks, such as resource lifecycle management, mission-critical jobs that often require manual intervention, guest management at scale and other common enterprise IT operations such as periodic maintenance. It targets orchestration on a wide array of resources such as Virtual Machines, Arc-enabled Servers, Databases, Storage, Azure Active Directory, Mailboxes and much more, along with complex workflows involving many resources. Azure Automation provides a complete end-to-end solution that facilitates authoring of PowerShell and Python scripts, with a serverless platform for execution of those scripts, offers the flexibility to execute those scripts on-premises or in customer’s local environment and monitors those executions comprehensively.
A 2023 Retrospective
Azure Automation has made substantial investments in modernizing its platform and significantly improving user experience over the previous year and promises to continue delivering value to its customers in the years to come. Here is a summary of key enhancements so far, that have laid the foundation for even greater benefits in the future:
New runtime languages: PowerShell 7.2 and Python 3.8 runbooks are Generally available. This enables Developers and IT administrators to execute runbooks in the most popular scripting languages. Customers are adopting Azure Automation to consolidate their scripts that are distributed on-premises and across multiple clouds and gaining operational efficiency by managing their Azure and Arc-enabled resources through a consistent experience.
Support for Azure CLI commands: Now Azure CLI commands can be invoked in Azure Automation runbooks (preview). The rich command set of Azure CLI expands capabilities of runbooks even further, allowing you to reap combined benefits of both to automate and streamline resource management on Azure.
Advanced script authoring experience: Azure Automation extension for Visual Studio Code is Generally Available. It offers an advanced authoring and editing experience for PowerShell and Python scripts. The extension leverages GitHub Copilot for intelligent code completion that provides suggestions directly within the editor, thereby making the coding process faster and simpler.
Granular control through Runtime environment: Module management and runbook update has never been so hassle-free! Runtime environment (preview) allows complete configuration of the job execution environment without worrying about mixing different module versions in a single Automation account. You can upgrade runbooks to newer language versions with minimal effort to stay secure and take advantage of latest functionalities. It is strongly recommended to use Runtime environment to update runbooks on end-of-support runtimes PowerShell 7.1 and Python 2.7 since both PowerShell 7.1 and Python 2.7 have been announced retired by parent products PowerShell and Python respectively.
Unified experience across diverse platforms: Hybrid Worker extension is Generally Available and supports Azure VMs, off-Azure servers registered as Arc-enabled servers, Arc-enabled SCVMM and Arc-enabled VMware VMs. This empowers organizations to orchestrate their entire hybrid environment at scale through a single interface. You can directly install the extension on Azure or Arc-enabled servers and execute runbooks for a variety of scenarios. These include in-guest VM management, access to other services privately from Azure Virtual Network, and to overcome organizational restrictions of keeping data in cloud.
State-of-the-art backend platform: Azure Automation has redesigned its platform and majority of the runbooks are now executing successfully on secure and modern Hyper-V containers. With this move and additional measures taken to minimize infrastructure failures, the service has further hardened its security and improved reliability. These enhancements have established the groundwork for faster release of innovative features in the coming months. If your runbooks have taken dependency on old platform and you observe unexpected job failures, take a look at the known issues and workarounds here.
Future outlook
Azure Automation is continuously evolving and enhancing its capabilities, striving to become the best-in-class platform for resource management in an adaptive cloud. It is providing organizations with more efficient and reliable ways to navigate across different services and applications residing in multiple clouds (on-premises data centers, private clouds, and public clouds). In addition to its ongoing commitments to strengthen security, reliability, resiliency and scale, Azure Automation is building critical features to further improve customer experience. Here are some of the improvements currently under development and expected to be released soon:
Aligning Runbook support with latest Runtime releases: Azure Automation is working actively to reduce the time gap between release of new PowerShell and Python language versions and their support in runbooks. Stay tuned for upcoming announcements on PowerShell 7.4!
Source control integration for new runtimes: You would now be able to keep runbooks updated with scripts in GitHub or Azure DevOps source control repository. This feature simplifies the process of promoting code that has undergone testing in the development environment to the production Automation account.
Native integration with Azure services: Azure Automation is already being used for creating runbooks that orchestrate across multiple resources. Keep an eye out for deeper integrations with more Azure resources for ease of management and to improve efficiency.
Richer Gallery of Runbooks: Improvements are planned in Runbook Gallery to help you search runbooks effortlessly for common scenarios and boost your productivity. Contribute to the community by sharing your scripts here.
Reminder for upcoming Retirements
Ensure to transition to the supported services/features prior to the retirement date:
AzureRM PowerShell module will retire on 29 February 2024 and will be replaced by Az PowerShell module. Update your outdated runbooks immediately.
With the retirement of Log Analytics agent, following dependent services/features will retire on 31 August 2024. It is strongly recommended to migrate to supported services before retirement date:
Log Analytics agent-based Hybrid Runbook Worker will be retired in favor of extension-based Hybrid Runbook Worker. Learn more.
Azure Automation Update Management will be retired in favor of Azure Update Manager. Learn more.
Azure Automation Change Tracking & Inventory will be retired in favor of Change Tracking & Inventory with AMA. Learn more.
For any questions or feedback, please reach out to askazureautomation@microsoft.com
Microsoft Tech Community – Latest Blogs –Read More
Wired for Hybrid – What’s New in Azure Networking – January 2024 edition
Hello Folks,
Azure Networking is the foundation of your infrastructure in Azure. Each month we bring you an update on What’s new in Azure Networking.
In this blog post, we’ll cover what’s new with Azure Networking in January 2024. In this blog post, we will cover the following announcements and how they can help you.
Standard and High-Performance VPN Gateway SKUs will be retired
Migration of Azure Virtual Network injected Azure Data Explorer cluster to Private Endpoints
Security Update for Azure Front Door and Application Gateway WAF
Prohibiting Domain Fronting with Azure Front Door and Azure CDN Standard from Microsoft
Simplified management of Listeners TLS certificates
Public preview: Private subnet
Enjoy!
Standard and High-Performance VPN Gateway SKUs will be retired
On 30 September 2025, Basic SKU public IP addresses will be retired in Azure. You can continue to use your existing Basic SKU public IP addresses until then, however, you will no longer be able to create new ones after 31 March 2025.
Standard SKU public IP addresses offer significant improvements, including:
Access to a variety of other Azure products, including Standard Load Balancer, Azure Firewall, and NAT Gateway.
Security by default—closed to inbound flows unless allowed by a network security group.
Zone-redundant and zonal front ends for inbound and outbound traffic.
If you have any Basic SKU public IP addresses deployed in Azure Cloud Services (extended support), those deployments will not be affected by this retirement, and you do not need to take any action for them. Because of the retirement of Basic IP, which Standard and High-Performance SKUs only accept, we will retire these SKUs on 30 September 2025. Starting 1 December 2023, you will no longer be able to create a new gateway with these SKUs.
Recommended action: Post December 2024, you will be able to upgrade your Standard/High-Performance gateway SKU to one of the other VPN Gateway SKUs available.
If you do not upgrade your gateway by August 2025, your gateway will be automatically upgraded to VPNGw1AZ (Standard) or VPNGw2AZ (High-Performance) after 30 September 2025.
Migration of Azure Virtual Network injected Azure Data Explorer cluster to Private Endpoints
An Azure Virtual Network injected Azure Data Explorer cluster is a cluster that is deployed into a subnet in your Virtual Network (VNet). This enables you to access the cluster privately from your Azure virtual network or on-premises, access resources such as Event Hubs and Azure Storage inside your virtual network and restrict inbound and outbound traffic.
Private Endpoint is a network interface that connects your ADX cluster to a private IP address within your VNet. Private endpoints enable you to connect to your ADX cluster using a private IP address within your VNet, without the need for public IP addresses.
Microsoft Azure has released a preview feature that allows users to migrate their VNet injected ADX cluster to Private Endpoints with minimal downtime and disruption. This migration is recommended as VNet injection has some limitations and drawbacks, such as increased complexity, reduced scalability, and dependency on public IP addresses.
The migration process is simple and can be done using the Azure portal, the ARM template, or any code which uses the ADX SDK 1. For more information on the migration process, prerequisites, and steps to follow, please refer to the detailed documentation article.
Resources:
Azure Data Explorer documentation
Migrate a Virtual Network injected cluster to private endpoints (Preview)
Microsoft Azure Data Fundamentals: Explore relational data in Azure
Data analysis in Azure Data Explorer with Kusto Query Language
Create dashboards in Azure Data Explorer
Security Update for Azure Front Door and Application Gateway WAF
Front Door and Application Gateway web application firewall (WAF) protects web applications from common vulnerabilities and exploits.
Azure-managed rule sets provide an easy way to deploy protection against a common set of security threats. Since such rule sets are managed by Azure, the rules are updated as needed to protect against new attack signatures.
Default rule set also includes the Microsoft Threat Intelligence Collection rules that are written in partnership with the Microsoft Intelligence team to provide increased coverage, patches for specific vulnerabilities, and better false positive reduction.
Customers also have the option of using rules that are defined based on the OWASP (Open Worldwide Application Security Project (OWASP) core rule sets 3.2, 3.1, 3.0, or 2.2.9.
At the end of December, we updated our Default Rule Set (DRS) and OWASP has updated the Core Rule Set (CRS) to address the security vulnerability CVE-2023-50164. (An attacker can manipulate file upload params to enable paths traversal and under some circumstances this can lead to uploading a malicious file which can be used to perform Remote Code Execution)
Prohibiting Domain Fronting with Azure Front Door and Azure CDN Standard from Microsoft
Domain fronting is a network technique that enables an attacker to conceal the actual destination of a request by sending traffic to a different domain in HTTP host header than the one used in the TLS/SSL handshake.
Azure Front Door and Azure CDN Standard from Microsoft (classic) protects against domain fronting occurring on domains hosted across different Azure subscriptions. The Server Name Indication (SNI) in TLS/SSL handshake and HTTP host header, whether they are the same or different, must be configured under the same Azure subscription.
Starting from January 22, 2024, all existing Azure Front Door and Azure CDN Standard from Microsoft (classic) resources will block any HTTP request that exhibits domain fronting behavior. The enforcement of blocking changes may require up to two weeks to propagate on the global PoPs (point of presences) starting from January 22, 2024.
To help identify if an Azure Front Door or Azure CDN from Microsoft (classic) resources display domain fronting behavior, two new log fields will be available on December 25, 2023.
Resources:
Prohibiting Domain Fronting with Azure Front Door and Azure CDN
Azure Networking Blog – Microsoft Community Hub.
Simplified management of Listeners TLS certificates
If you use Application Gateway, you know that terminating TLS (HTTP traffic) can be done on the Gateway to take the burden off the backend resources. Given you many have a large number of backend resources with difference hostnames (FQDNs), this can be challenging to manage. Traditionally, this could only be done with Azure PowerShell or Azure CLI.
Now you can manage all your TLS certificates for APP Gateway through the Azure portal:
Key Features include:
Quick listing
Certificate information
Bulk Operations
Resources:
Simplified management of Listeners TLS certificates
Public preview: Private subnet
Now customers will be able to create custom private subnets in Azure for their resources.
Currently, when virtual machines are created in a virtual network without any explicit outbound connectivity, they are assigned a default outbound public IP address. These implicit IPs are subject to change, not associated with a subscription, difficult to troubleshoot, and do not follow Azure’s model of “secure by default” which ensures customers have strong security without additional steps needed. (The depreciation for this type of implicit connectivity was recently announced and is scheduled for September 2025.)
The private subnet feature will let you prevent this insecure implicit connectivity for any newly created subnets by setting the “default outbound access” parameter to false. You can then pick your preferred method for explicit outbound connectivity to the internet.
How to implement and turn off default outbound?
Utilize Private Subnet parameter
Add the Private subnet feature at creation
Add an explicit outbound connectivity method
NAT Gateway
Standard LB
Standar Public IP
Use Flexible orchestration mode for Virtual Machine Scale sets
Resources:
Default outbound access in Azure
How can I transition to an explicit method of public connectivity (and disable default outbound access)?
That’s it for this month. Happy 2024! (it’s January… I can still say that. Right?!?)
Cheers
Pierre
Microsoft Tech Community – Latest Blogs –Read More
WingetCreate: Keeping WinGet packages up-to-date!
This post was written by Muhammad Danish
In the ever-evolving landscape of software development, efficiency is key. Windows users have long awaited an experience, where the simplicity of installing, updating, and managing software could be as seamless as executing a single command. Enter Windows Package Manager, or WinGet, a powerful tool that reshapes the way we handle software packages on the Windows platform. WinGet brings the simplicity of Linux package managers to the Windows environment, enabling users to use the command-line for installing their favorite packages.
To submit software packages to Windows Package Manager, the open-source Microsoft Community Package Manifest Repository is available on GitHub. Independent Software Vendors (ISVs) can submit package manifests (defined in a YAML format) in the repository to have their software packages considered for inclusion with Windows Package Manager. With frequent updates and new versions to software rolling out, the process of generating and updating manifest files must be swift and uncomplicated.
What’s WingetCreate
Recognizing the need for simplicity and efficiency in this process, WingetCreate emerges as a solution, providing a user-friendly interface for manifest generation. WingetCreate presents two distinct modes to cater to varying user needs. The interactive mode guides new users through a series of questions, simplifying the manifest creation process and enabling easy submissions to the Community Repository. On the other hand, the autonomous mode for the update process is strategically designed for CI/CD environments, seamlessly integrating into existing pipelines. Publishers can now automate the entire workflow, from manifest generation to pull request submission, ensuring a smooth and streamlined update process on the WinGet repository.
Installing WingetCreate
If you already have the Windows Package Manager (WinGet) installed on your machine, you can install the manifest creator with a simple command:
winget install wingetcreate
Alternatively, you can visit the WingetCreate GitHub Repository and download the latest release from https://github.com/microsoft/winget-create/releases. Once you have the tool installed, type `wingetcreate` in a terminal session to see the tool’s help text.
WingetCreate Features
The tool supports several different functionalities. For now, we’ll look at a couple of key commands:
new: Interactive command that can help you generate a brand-new manifest. You’ll want to use this command if your package does not exist in the winget repository yet. The manifest generated will serve as the base manifest for a future update using the update command.
show: This command lets you see the manifest for an existing package in the community repository. Alternatively, you can visit the packages repository on GitHub (https://github.com/microsoft/winget-pkgs) and find the package manifest under the manifests/ directory.
update: This is where the fun happens. This command lets you update an existing manifest from the community repository. Pass in `–interactive` if you want the interactive experience. By default, the command runs in autonomous mode.
If you run the commands passing `–help` e.g., `wingetcreate new –help`, it will show you the help text and supported options for each command.
See how the update command is used using an actual example in the video:
Using the tool in a CI/CD environment
The power of WingetCreate is most highlighted in a CI/CD environment. Here we’ll look at how the folks over at Microsoft’s DevHome repository (https://github.com/microsoft/devhome) automate their releases using WingetCreate. DevHome uses GitHub Actions as their CI environment to publish releases to WinGet repository. The WingetCreate docs (https://github.com/microsoft/winget-create/blob/main/pipelines/azure-pipelines.release.yml) also specify an example for usage in Azure Pipelines. Here we will look at the workflow file defined in DevHome’s repository: https://github.com/microsoft/devhome/blob/main/.github/workflows/winget-submission.yml
name: Submit Microsoft.DevHome package to Windows Package Manager Community Repository
on:
workflow_dispatch:
release:
types: [published]
jobs:
winget:
name: Publish winget package
runs-on: windows-latest
steps:
– name: Submit package to Windows Package Manager Community Repository
run: |
$packageId = “Microsoft.DevHome”
$gitToken = “${{ secrets.WINGET_PAT }}”
# Fetching latest release from GitHub
$github = Invoke-RestMethod -uri “https://api.github.com/repos/microsoft/devhome/releases”
$targetRelease = $github | Where-Object -Property name -match ‘Dev Home’| Select-Object -First 1
$installerUrl = $targetRelease | Select-Object -ExpandProperty assets -First 1 | Where-Object -Property name -match ‘Windows.DevHome.*?msixbundle’ | Select-Object -ExpandProperty browser_download_url
$packageVersion = $targetRelease.tag_name.Trim(“v”)
# Update package using wingetcreate
Invoke-WebRequest https://aka.ms/wingetcreate/latest -OutFile wingetcreate.exe
.wingetcreate.exe update $packageId –version $packageVersion –urls “$installerUrl” –submit –token $gitToken
Using the `on:` keyword, we instruct the workflow to run on specific events. Here by specifying `release: types: [publised]`, the workflow will trigger only when a new release is published on GitHub, allowing you to define this workflow file once and forget about updating your package.
The file contains a single job that runs a simple PowerShell script. It fetches the latest release version and URLs from GitHub, downloads WingetCreate in the agent created by GitHub Action and invokes `wingetcreate update` passing in all the required parameters. At the end of the update, a pull request is automatically submitted to the Windows Package Manager Community Repository.
PR submission to the WinGet GitHub Repository requires you to create a GitHub Personal Access Token and pass it to WingetCreate using the `–token option`. Instructions on how to generate the token can be found in the WingetCreate docs (https://github.com/microsoft/winget-create#github-personal-access-token-classic-permissions). Since you never want to be hardcoding your tokens (very bad idea!), GitHub allows you to define it as a repository secret (https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#creating-encrypted-secrets-for-a-repository) for security.
Workflow in action, generating and submitting PRs to update the Microsoft.DevHome package:
Conclusion
WingetCreate provides a convenient method for generating and updating manifests for the community repository. Publishers are encouraged to use the tool in their release pipelines, ensuring timely package submissions so that users consistently receive the most up-to-date and secure versions of their software.
Additional Resources
Microsoft Learn – Windows Package Manager
Workflow syntax for GitHub Actions
Microsoft Tech Community – Latest Blogs –Read More
Azure Landing Zones Accelerators for Bicep and Terraform. Announcing General Availability!
The Azure Landing Zones team is delighted to announce the general availability of our Azure Landing Zones Accelerators for Bicep and Terraform, having both reached the version 1.0 milestone. This article will provide an overview of the accelerators and dive into the common approaches for deploying them.
We’ll cover:
What is an Azure Landing Zone?
What are the Azure Landing Zones Accelerators?
Why should you use an Accelerator?
How do you use the Accelerator?
What does the Bicep Accelerator deploy and configure?
What does the Terraform Accelerator deploy and configure?
Where can you learn more?
Thank you to our collaborators!
What is an Azure Landing Zone?
An Azure Landing Zone serves as the cornerstone of your cloud adoption, establishing guardrails and facilitating the deployment of workloads into Azure in a secure, standardized, and scalable manner. Further details can be found in our Cloud Adtion Framework documentation under: What is an Azure landing zone?
For the purpose of this article, you can consider the landing zone to consist of the initial setup of:
Management groups
Azure RBAC Roles
Azure Policy
Management resources, such as centralized logging and automation accounts
Hub networking, Azure DNS, and other connectivity resources
See the green boxes in this diagram:
Figure: Azure Landing Zones Accelerator Scope
What are the Azure Landing Zones Accelerators?
The Azure Landing Zones Accelerators for Bicep and Terraform serve as automation frameworks and include corresponding documentation. Their purpose is to assist our customers and partners in swiftly deploying their Azure Landing Zone architecture by utilizing our pre-existing Azure Landing Zones Bicep or Terraform modules and adhering to best practices. While these accelerators are crafted to meet the requirements of 90% of users by default, they can be tailored to accommodate the specific needs of advanced scenarios.
The Accelerators follow a three phase approach:
Pre-requisites: Instructions to configure credentials and subscriptions.
Bootstrap: Automation or instructions to bootstrap managed IaC modules into Continuous Integration and Continuous Delivery Pipelines.
Run: Trigger the pipelines to deploy the Azure Landing Zone architecture.
The Accelerators offer support for utilizing GitHub or Azure DevOps as targets for the bootstrapping automation.
Why should you use an Accelerator?
The Azure Landing Zones Accelerators for Bicep and Terraform play a crucial role in minimizing the effort needed for analyzing and creating an Azure Landing Zone deployment. They offer opinionated patterns and comprehensive automation for setting up Azure Landing Zones modules, ensuring a production-ready configuration.
Before the Accelerators were available, teams invested considerable time constructing their automation for our Azure Landing Zones modules and making decisions regarding the configuration and security of Continuous Delivery. The Accelerators eliminate this overhead by offering a reusable deployment pattern.
How do you use the Accelerator?
The Accelerators wikis provide comprehensive documentation and quick start guides for using the Accelerators. These can be found here:
The Accelerators use a shared approach to the bootstrapping process with a common PowerShell module. The ALZ PowerShell module is available from the PowerShell Gallery.
The basic PowerShell to bootstrap GitHub or Azure DevOps is:
# Install the PowerShell Module
Install-Module -Name ALZ
# Deploy the Bootstrap for Bicep and GitHub
New-ALZEnvironment -i “bicep” -c “github”
# Deploy the Bootstrap for Bicep and Azure DevOps
New-ALZEnvironment -i “bicep” -c “azuredevops”
# Deploy the Bootstrap for Terraform and GitHub
New-ALZEnvironment -i “terraform” -c “github”
# Deploy the Bootstrap for Terraform and Azure DevOps
New-ALZEnvironment -i “terraform” -c “azuredevops”
What does the Bicep Accelerator deploy and configure?
The Azure Landing Zone Bicep Accelerator comes with a comprehensive set of instructions to guide you through the provisioning process. It assists in selecting options that are relevant to your needs and prompts you for choices within the PowerShell automation.
The Bicep Accelerator offers flexibility, allowing you to determine how you want to secure your repositories and pipelines/actions. While we provide guidance and examples, you have the freedom to choose the type of authentication that GitHub or Azure DevOps employs.
Details of what is deployed by following the Accelerator steps:
Microsoft Azure
Deployment identity
Version Control System (GitHub or Azure DevOps)
Repositories and files
Azure Pipelines/GitHub Workflows
Environment Variables
Branch Policies
The Azure Pipelines and GitHub Workflows leverage PowerShell scripts for deploying the modules, and their structure is illustrated in the following diagram:
Additionally, we provide prescription documentation for managing specific scenarios:
Handling upgrades to newer versions of ALZ-Bicep.
An opinionated approach to introducing a branching strategy into your CI/CD process.
Process for incorporating modified ALZ-Bicep Modules into the Accelerator framework.
Ultimately, the documentation comprehensively guides the setup of Azure DevOps/GitHub, encompassing the configuration of the repository, pipelines, and branch policies. Furthermore, there are intentions to implement automation to streamline and reduce manual efforts. Stay tuned for future updates on this blog post as we finalize and incorporate these enhancements!
What does the Terraform Accelerator deploy and configure?
The Azure Landing Zones Terraform Accelerator has many options to choose from when deploying the bootstrap. You can use variables to choose between the options shown in the table below. Our default options are shown in green text, as these provide the highest level of security and leverage best practice authentication.
Version Control System
Agents / Runners
Networking
Authentication
GitHub
Microsoft Hosted
Public
Workload identity federation
GitHub
Self Hosted
Public
Workload identity federation
GitHub
Self Hosted
Private
Workload identity federation
Azure DevOps
Microsoft Hosted
Public
Workload identity federation
Azure DevOps
Self Hosted
Public
Workload identity federation
Azure DevOps
Self Hosted
Private
Workload identity federation
Azure DevOps
Self Hosted
Public
Managed identity
Azure DevOps
Self Hosted
Private
Managed identity
The Terraform Accelerator follows the 3 phase approach as described previously:
Details of what is deployed by the bootstrap can be found in our documentation, but in summary the bootstrap will deploy:
Microsoft Azure
Storage
Identity
Networking
Self-hosted Agents / Runners
Version Control System (GitHub or Azure DevOps)
Repositories and files
Pipelines / Actions
Environments
Approvals
Branch Policies
Variables
Where can you learn more?
Bicep Issues
Terraform Issues
ALZ PowerShell Issues
Thank you to our collaborators
We express our heartfelt gratitude to everyone who collaborated on the Azure Landing Zones Accelerators. The tremendous support from individuals involved in testing, offering feedback, contributing code, documentation, and ideas has been invaluable. Thank you for your dedication and contributions to the success of the Accelerators.
Microsoft Tech Community – Latest Blogs –Read More
Wired for Hybrid – What’s New in Azure Networking – January 2024 edition
Hello Folks,
Azure Networking is the foundation of your infrastructure in Azure. Each month we bring you an update on What’s new in Azure Networking.
In this blog post, we’ll cover what’s new with Azure Networking in January 2024. In this blog post, we will cover the following announcements and how they can help you.
Standard and High-Performance VPN Gateway SKUs will be retired
Migration of Azure Virtual Network injected Azure Data Explorer cluster to Private Endpoints
Security Update for Azure Front Door and Application Gateway WAF
Prohibiting Domain Fronting with Azure Front Door and Azure CDN Standard from Microsoft
Simplified management of Listeners TLS certificates
Public preview: Private subnet
Enjoy!
Standard and High-Performance VPN Gateway SKUs will be retired
On 30 September 2025, Basic SKU public IP addresses will be retired in Azure. You can continue to use your existing Basic SKU public IP addresses until then, however, you will no longer be able to create new ones after 31 March 2025.
Standard SKU public IP addresses offer significant improvements, including:
Access to a variety of other Azure products, including Standard Load Balancer, Azure Firewall, and NAT Gateway.
Security by default—closed to inbound flows unless allowed by a network security group.
Zone-redundant and zonal front ends for inbound and outbound traffic.
If you have any Basic SKU public IP addresses deployed in Azure Cloud Services (extended support), those deployments will not be affected by this retirement, and you do not need to take any action for them. Because of the retirement of Basic IP, which Standard and High-Performance SKUs only accept, we will retire these SKUs on 30 September 2025. Starting 1 December 2023, you will no longer be able to create a new gateway with these SKUs.
Recommended action: Post December 2024, you will be able to upgrade your Standard/High-Performance gateway SKU to one of the other VPN Gateway SKUs available.
If you do not upgrade your gateway by August 2025, your gateway will be automatically upgraded to VPNGw1AZ (Standard) or VPNGw2AZ (High-Performance) after 30 September 2025.
Migration of Azure Virtual Network injected Azure Data Explorer cluster to Private Endpoints
An Azure Virtual Network injected Azure Data Explorer cluster is a cluster that is deployed into a subnet in your Virtual Network (VNet). This enables you to access the cluster privately from your Azure virtual network or on-premises, access resources such as Event Hubs and Azure Storage inside your virtual network and restrict inbound and outbound traffic.
Private Endpoint is a network interface that connects your ADX cluster to a private IP address within your VNet. Private endpoints enable you to connect to your ADX cluster using a private IP address within your VNet, without the need for public IP addresses.
Microsoft Azure has released a preview feature that allows users to migrate their VNet injected ADX cluster to Private Endpoints with minimal downtime and disruption. This migration is recommended as VNet injection has some limitations and drawbacks, such as increased complexity, reduced scalability, and dependency on public IP addresses.
The migration process is simple and can be done using the Azure portal, the ARM template, or any code which uses the ADX SDK 1. For more information on the migration process, prerequisites, and steps to follow, please refer to the detailed documentation article.
Resources:
Azure Data Explorer documentation
Migrate a Virtual Network injected cluster to private endpoints (Preview)
Microsoft Azure Data Fundamentals: Explore relational data in Azure
Data analysis in Azure Data Explorer with Kusto Query Language
Create dashboards in Azure Data Explorer
Security Update for Azure Front Door and Application Gateway WAF
Front Door and Application Gateway web application firewall (WAF) protects web applications from common vulnerabilities and exploits.
Azure-managed rule sets provide an easy way to deploy protection against a common set of security threats. Since such rule sets are managed by Azure, the rules are updated as needed to protect against new attack signatures.
Default rule set also includes the Microsoft Threat Intelligence Collection rules that are written in partnership with the Microsoft Intelligence team to provide increased coverage, patches for specific vulnerabilities, and better false positive reduction.
Customers also have the option of using rules that are defined based on the OWASP (Open Worldwide Application Security Project (OWASP) core rule sets 3.2, 3.1, 3.0, or 2.2.9.
At the end of December, we updated our Default Rule Set (DRS) and OWASP has updated the Core Rule Set (CRS) to address the security vulnerability CVE-2023-50164. (An attacker can manipulate file upload params to enable paths traversal and under some circumstances this can lead to uploading a malicious file which can be used to perform Remote Code Execution)
Prohibiting Domain Fronting with Azure Front Door and Azure CDN Standard from Microsoft
Domain fronting is a network technique that enables an attacker to conceal the actual destination of a request by sending traffic to a different domain in HTTP host header than the one used in the TLS/SSL handshake.
Azure Front Door and Azure CDN Standard from Microsoft (classic) protects against domain fronting occurring on domains hosted across different Azure subscriptions. The Server Name Indication (SNI) in TLS/SSL handshake and HTTP host header, whether they are the same or different, must be configured under the same Azure subscription.
Starting from January 22, 2024, all existing Azure Front Door and Azure CDN Standard from Microsoft (classic) resources will block any HTTP request that exhibits domain fronting behavior. The enforcement of blocking changes may require up to two weeks to propagate on the global PoPs (point of presences) starting from January 22, 2024.
To help identify if an Azure Front Door or Azure CDN from Microsoft (classic) resources display domain fronting behavior, two new log fields will be available on December 25, 2023.
Resources:
Prohibiting Domain Fronting with Azure Front Door and Azure CDN
Azure Networking Blog – Microsoft Community Hub.
Simplified management of Listeners TLS certificates
If you use Application Gateway, you know that terminating TLS (HTTP traffic) can be done on the Gateway to take the burden off the backend resources. Given you many have a large number of backend resources with difference hostnames (FQDNs), this can be challenging to manage. Traditionally, this could only be done with Azure PowerShell or Azure CLI.
Now you can manage all your TLS certificates for APP Gateway through the Azure portal:
Key Features include:
Quick listing
Certificate information
Bulk Operations
Resources:
Simplified management of Listeners TLS certificates
Public preview: Private subnet
Now customers will be able to create custom private subnets in Azure for their resources.
Currently, when virtual machines are created in a virtual network without any explicit outbound connectivity, they are assigned a default outbound public IP address. These implicit IPs are subject to change, not associated with a subscription, difficult to troubleshoot, and do not follow Azure’s model of “secure by default” which ensures customers have strong security without additional steps needed. (The depreciation for this type of implicit connectivity was recently announced and is scheduled for September 2025.)
The private subnet feature will let you prevent this insecure implicit connectivity for any newly created subnets by setting the “default outbound access” parameter to false. You can then pick your preferred method for explicit outbound connectivity to the internet.
How to implement and turn off default outbound?
Utilize Private Subnet parameter
Add the Private subnet feature at creation
Add an explicit outbound connectivity method
NAT Gateway
Standard LB
Standar Public IP
Use Flexible orchestration mode for Virtual Machine Scale sets
Resources:
Default outbound access in Azure
How can I transition to an explicit method of public connectivity (and disable default outbound access)?
That’s it for this month. Happy 2024! (it’s January… I can still say that. Right?!?)
Cheers
Pierre
Microsoft Tech Community – Latest Blogs –Read More
Wired for Hybrid – What’s New in Azure Networking – January 2024 edition
Hello Folks,
Azure Networking is the foundation of your infrastructure in Azure. Each month we bring you an update on What’s new in Azure Networking.
In this blog post, we’ll cover what’s new with Azure Networking in January 2024. In this blog post, we will cover the following announcements and how they can help you.
Standard and High-Performance VPN Gateway SKUs will be retired
Migration of Azure Virtual Network injected Azure Data Explorer cluster to Private Endpoints
Security Update for Azure Front Door and Application Gateway WAF
Prohibiting Domain Fronting with Azure Front Door and Azure CDN Standard from Microsoft
Simplified management of Listeners TLS certificates
Public preview: Private subnet
Enjoy!
Standard and High-Performance VPN Gateway SKUs will be retired
On 30 September 2025, Basic SKU public IP addresses will be retired in Azure. You can continue to use your existing Basic SKU public IP addresses until then, however, you will no longer be able to create new ones after 31 March 2025.
Standard SKU public IP addresses offer significant improvements, including:
Access to a variety of other Azure products, including Standard Load Balancer, Azure Firewall, and NAT Gateway.
Security by default—closed to inbound flows unless allowed by a network security group.
Zone-redundant and zonal front ends for inbound and outbound traffic.
If you have any Basic SKU public IP addresses deployed in Azure Cloud Services (extended support), those deployments will not be affected by this retirement, and you do not need to take any action for them. Because of the retirement of Basic IP, which Standard and High-Performance SKUs only accept, we will retire these SKUs on 30 September 2025. Starting 1 December 2023, you will no longer be able to create a new gateway with these SKUs.
Recommended action: Post December 2024, you will be able to upgrade your Standard/High-Performance gateway SKU to one of the other VPN Gateway SKUs available.
If you do not upgrade your gateway by August 2025, your gateway will be automatically upgraded to VPNGw1AZ (Standard) or VPNGw2AZ (High-Performance) after 30 September 2025.
Migration of Azure Virtual Network injected Azure Data Explorer cluster to Private Endpoints
An Azure Virtual Network injected Azure Data Explorer cluster is a cluster that is deployed into a subnet in your Virtual Network (VNet). This enables you to access the cluster privately from your Azure virtual network or on-premises, access resources such as Event Hubs and Azure Storage inside your virtual network and restrict inbound and outbound traffic.
Private Endpoint is a network interface that connects your ADX cluster to a private IP address within your VNet. Private endpoints enable you to connect to your ADX cluster using a private IP address within your VNet, without the need for public IP addresses.
Microsoft Azure has released a preview feature that allows users to migrate their VNet injected ADX cluster to Private Endpoints with minimal downtime and disruption. This migration is recommended as VNet injection has some limitations and drawbacks, such as increased complexity, reduced scalability, and dependency on public IP addresses.
The migration process is simple and can be done using the Azure portal, the ARM template, or any code which uses the ADX SDK 1. For more information on the migration process, prerequisites, and steps to follow, please refer to the detailed documentation article.
Resources:
Azure Data Explorer documentation
Migrate a Virtual Network injected cluster to private endpoints (Preview)
Microsoft Azure Data Fundamentals: Explore relational data in Azure
Data analysis in Azure Data Explorer with Kusto Query Language
Create dashboards in Azure Data Explorer
Security Update for Azure Front Door and Application Gateway WAF
Front Door and Application Gateway web application firewall (WAF) protects web applications from common vulnerabilities and exploits.
Azure-managed rule sets provide an easy way to deploy protection against a common set of security threats. Since such rule sets are managed by Azure, the rules are updated as needed to protect against new attack signatures.
Default rule set also includes the Microsoft Threat Intelligence Collection rules that are written in partnership with the Microsoft Intelligence team to provide increased coverage, patches for specific vulnerabilities, and better false positive reduction.
Customers also have the option of using rules that are defined based on the OWASP (Open Worldwide Application Security Project (OWASP) core rule sets 3.2, 3.1, 3.0, or 2.2.9.
At the end of December, we updated our Default Rule Set (DRS) and OWASP has updated the Core Rule Set (CRS) to address the security vulnerability CVE-2023-50164. (An attacker can manipulate file upload params to enable paths traversal and under some circumstances this can lead to uploading a malicious file which can be used to perform Remote Code Execution)
Prohibiting Domain Fronting with Azure Front Door and Azure CDN Standard from Microsoft
Domain fronting is a network technique that enables an attacker to conceal the actual destination of a request by sending traffic to a different domain in HTTP host header than the one used in the TLS/SSL handshake.
Azure Front Door and Azure CDN Standard from Microsoft (classic) protects against domain fronting occurring on domains hosted across different Azure subscriptions. The Server Name Indication (SNI) in TLS/SSL handshake and HTTP host header, whether they are the same or different, must be configured under the same Azure subscription.
Starting from January 22, 2024, all existing Azure Front Door and Azure CDN Standard from Microsoft (classic) resources will block any HTTP request that exhibits domain fronting behavior. The enforcement of blocking changes may require up to two weeks to propagate on the global PoPs (point of presences) starting from January 22, 2024.
To help identify if an Azure Front Door or Azure CDN from Microsoft (classic) resources display domain fronting behavior, two new log fields will be available on December 25, 2023.
Resources:
Prohibiting Domain Fronting with Azure Front Door and Azure CDN
Azure Networking Blog – Microsoft Community Hub.
Simplified management of Listeners TLS certificates
If you use Application Gateway, you know that terminating TLS (HTTP traffic) can be done on the Gateway to take the burden off the backend resources. Given you many have a large number of backend resources with difference hostnames (FQDNs), this can be challenging to manage. Traditionally, this could only be done with Azure PowerShell or Azure CLI.
Now you can manage all your TLS certificates for APP Gateway through the Azure portal:
Key Features include:
Quick listing
Certificate information
Bulk Operations
Resources:
Simplified management of Listeners TLS certificates
Public preview: Private subnet
Now customers will be able to create custom private subnets in Azure for their resources.
Currently, when virtual machines are created in a virtual network without any explicit outbound connectivity, they are assigned a default outbound public IP address. These implicit IPs are subject to change, not associated with a subscription, difficult to troubleshoot, and do not follow Azure’s model of “secure by default” which ensures customers have strong security without additional steps needed. (The depreciation for this type of implicit connectivity was recently announced and is scheduled for September 2025.)
The private subnet feature will let you prevent this insecure implicit connectivity for any newly created subnets by setting the “default outbound access” parameter to false. You can then pick your preferred method for explicit outbound connectivity to the internet.
How to implement and turn off default outbound?
Utilize Private Subnet parameter
Add the Private subnet feature at creation
Add an explicit outbound connectivity method
NAT Gateway
Standard LB
Standar Public IP
Use Flexible orchestration mode for Virtual Machine Scale sets
Resources:
Default outbound access in Azure
How can I transition to an explicit method of public connectivity (and disable default outbound access)?
That’s it for this month. Happy 2024! (it’s January… I can still say that. Right?!?)
Cheers
Pierre
Microsoft Tech Community – Latest Blogs –Read More
Wired for Hybrid – What’s New in Azure Networking – January 2024 edition
Hello Folks,
Azure Networking is the foundation of your infrastructure in Azure. Each month we bring you an update on What’s new in Azure Networking.
In this blog post, we’ll cover what’s new with Azure Networking in January 2024. In this blog post, we will cover the following announcements and how they can help you.
Standard and High-Performance VPN Gateway SKUs will be retired
Migration of Azure Virtual Network injected Azure Data Explorer cluster to Private Endpoints
Security Update for Azure Front Door and Application Gateway WAF
Prohibiting Domain Fronting with Azure Front Door and Azure CDN Standard from Microsoft
Simplified management of Listeners TLS certificates
Public preview: Private subnet
Enjoy!
Standard and High-Performance VPN Gateway SKUs will be retired
On 30 September 2025, Basic SKU public IP addresses will be retired in Azure. You can continue to use your existing Basic SKU public IP addresses until then, however, you will no longer be able to create new ones after 31 March 2025.
Standard SKU public IP addresses offer significant improvements, including:
Access to a variety of other Azure products, including Standard Load Balancer, Azure Firewall, and NAT Gateway.
Security by default—closed to inbound flows unless allowed by a network security group.
Zone-redundant and zonal front ends for inbound and outbound traffic.
If you have any Basic SKU public IP addresses deployed in Azure Cloud Services (extended support), those deployments will not be affected by this retirement, and you do not need to take any action for them. Because of the retirement of Basic IP, which Standard and High-Performance SKUs only accept, we will retire these SKUs on 30 September 2025. Starting 1 December 2023, you will no longer be able to create a new gateway with these SKUs.
Recommended action: Post December 2024, you will be able to upgrade your Standard/High-Performance gateway SKU to one of the other VPN Gateway SKUs available.
If you do not upgrade your gateway by August 2025, your gateway will be automatically upgraded to VPNGw1AZ (Standard) or VPNGw2AZ (High-Performance) after 30 September 2025.
Migration of Azure Virtual Network injected Azure Data Explorer cluster to Private Endpoints
An Azure Virtual Network injected Azure Data Explorer cluster is a cluster that is deployed into a subnet in your Virtual Network (VNet). This enables you to access the cluster privately from your Azure virtual network or on-premises, access resources such as Event Hubs and Azure Storage inside your virtual network and restrict inbound and outbound traffic.
Private Endpoint is a network interface that connects your ADX cluster to a private IP address within your VNet. Private endpoints enable you to connect to your ADX cluster using a private IP address within your VNet, without the need for public IP addresses.
Microsoft Azure has released a preview feature that allows users to migrate their VNet injected ADX cluster to Private Endpoints with minimal downtime and disruption. This migration is recommended as VNet injection has some limitations and drawbacks, such as increased complexity, reduced scalability, and dependency on public IP addresses.
The migration process is simple and can be done using the Azure portal, the ARM template, or any code which uses the ADX SDK 1. For more information on the migration process, prerequisites, and steps to follow, please refer to the detailed documentation article.
Resources:
Azure Data Explorer documentation
Migrate a Virtual Network injected cluster to private endpoints (Preview)
Microsoft Azure Data Fundamentals: Explore relational data in Azure
Data analysis in Azure Data Explorer with Kusto Query Language
Create dashboards in Azure Data Explorer
Security Update for Azure Front Door and Application Gateway WAF
Front Door and Application Gateway web application firewall (WAF) protects web applications from common vulnerabilities and exploits.
Azure-managed rule sets provide an easy way to deploy protection against a common set of security threats. Since such rule sets are managed by Azure, the rules are updated as needed to protect against new attack signatures.
Default rule set also includes the Microsoft Threat Intelligence Collection rules that are written in partnership with the Microsoft Intelligence team to provide increased coverage, patches for specific vulnerabilities, and better false positive reduction.
Customers also have the option of using rules that are defined based on the OWASP (Open Worldwide Application Security Project (OWASP) core rule sets 3.2, 3.1, 3.0, or 2.2.9.
At the end of December, we updated our Default Rule Set (DRS) and OWASP has updated the Core Rule Set (CRS) to address the security vulnerability CVE-2023-50164. (An attacker can manipulate file upload params to enable paths traversal and under some circumstances this can lead to uploading a malicious file which can be used to perform Remote Code Execution)
Prohibiting Domain Fronting with Azure Front Door and Azure CDN Standard from Microsoft
Domain fronting is a network technique that enables an attacker to conceal the actual destination of a request by sending traffic to a different domain in HTTP host header than the one used in the TLS/SSL handshake.
Azure Front Door and Azure CDN Standard from Microsoft (classic) protects against domain fronting occurring on domains hosted across different Azure subscriptions. The Server Name Indication (SNI) in TLS/SSL handshake and HTTP host header, whether they are the same or different, must be configured under the same Azure subscription.
Starting from January 22, 2024, all existing Azure Front Door and Azure CDN Standard from Microsoft (classic) resources will block any HTTP request that exhibits domain fronting behavior. The enforcement of blocking changes may require up to two weeks to propagate on the global PoPs (point of presences) starting from January 22, 2024.
To help identify if an Azure Front Door or Azure CDN from Microsoft (classic) resources display domain fronting behavior, two new log fields will be available on December 25, 2023.
Resources:
Prohibiting Domain Fronting with Azure Front Door and Azure CDN
Azure Networking Blog – Microsoft Community Hub.
Simplified management of Listeners TLS certificates
If you use Application Gateway, you know that terminating TLS (HTTP traffic) can be done on the Gateway to take the burden off the backend resources. Given you many have a large number of backend resources with difference hostnames (FQDNs), this can be challenging to manage. Traditionally, this could only be done with Azure PowerShell or Azure CLI.
Now you can manage all your TLS certificates for APP Gateway through the Azure portal:
Key Features include:
Quick listing
Certificate information
Bulk Operations
Resources:
Simplified management of Listeners TLS certificates
Public preview: Private subnet
Now customers will be able to create custom private subnets in Azure for their resources.
Currently, when virtual machines are created in a virtual network without any explicit outbound connectivity, they are assigned a default outbound public IP address. These implicit IPs are subject to change, not associated with a subscription, difficult to troubleshoot, and do not follow Azure’s model of “secure by default” which ensures customers have strong security without additional steps needed. (The depreciation for this type of implicit connectivity was recently announced and is scheduled for September 2025.)
The private subnet feature will let you prevent this insecure implicit connectivity for any newly created subnets by setting the “default outbound access” parameter to false. You can then pick your preferred method for explicit outbound connectivity to the internet.
How to implement and turn off default outbound?
Utilize Private Subnet parameter
Add the Private subnet feature at creation
Add an explicit outbound connectivity method
NAT Gateway
Standard LB
Standar Public IP
Use Flexible orchestration mode for Virtual Machine Scale sets
Resources:
Default outbound access in Azure
How can I transition to an explicit method of public connectivity (and disable default outbound access)?
That’s it for this month. Happy 2024! (it’s January… I can still say that. Right?!?)
Cheers
Pierre
Microsoft Tech Community – Latest Blogs –Read More
Wired for Hybrid – What’s New in Azure Networking – January 2024 edition
Hello Folks,
Azure Networking is the foundation of your infrastructure in Azure. Each month we bring you an update on What’s new in Azure Networking.
In this blog post, we’ll cover what’s new with Azure Networking in January 2024. In this blog post, we will cover the following announcements and how they can help you.
Standard and High-Performance VPN Gateway SKUs will be retired
Migration of Azure Virtual Network injected Azure Data Explorer cluster to Private Endpoints
Security Update for Azure Front Door and Application Gateway WAF
Prohibiting Domain Fronting with Azure Front Door and Azure CDN Standard from Microsoft
Simplified management of Listeners TLS certificates
Public preview: Private subnet
Enjoy!
Standard and High-Performance VPN Gateway SKUs will be retired
On 30 September 2025, Basic SKU public IP addresses will be retired in Azure. You can continue to use your existing Basic SKU public IP addresses until then, however, you will no longer be able to create new ones after 31 March 2025.
Standard SKU public IP addresses offer significant improvements, including:
Access to a variety of other Azure products, including Standard Load Balancer, Azure Firewall, and NAT Gateway.
Security by default—closed to inbound flows unless allowed by a network security group.
Zone-redundant and zonal front ends for inbound and outbound traffic.
If you have any Basic SKU public IP addresses deployed in Azure Cloud Services (extended support), those deployments will not be affected by this retirement, and you do not need to take any action for them. Because of the retirement of Basic IP, which Standard and High-Performance SKUs only accept, we will retire these SKUs on 30 September 2025. Starting 1 December 2023, you will no longer be able to create a new gateway with these SKUs.
Recommended action: Post December 2024, you will be able to upgrade your Standard/High-Performance gateway SKU to one of the other VPN Gateway SKUs available.
If you do not upgrade your gateway by August 2025, your gateway will be automatically upgraded to VPNGw1AZ (Standard) or VPNGw2AZ (High-Performance) after 30 September 2025.
Migration of Azure Virtual Network injected Azure Data Explorer cluster to Private Endpoints
An Azure Virtual Network injected Azure Data Explorer cluster is a cluster that is deployed into a subnet in your Virtual Network (VNet). This enables you to access the cluster privately from your Azure virtual network or on-premises, access resources such as Event Hubs and Azure Storage inside your virtual network and restrict inbound and outbound traffic.
Private Endpoint is a network interface that connects your ADX cluster to a private IP address within your VNet. Private endpoints enable you to connect to your ADX cluster using a private IP address within your VNet, without the need for public IP addresses.
Microsoft Azure has released a preview feature that allows users to migrate their VNet injected ADX cluster to Private Endpoints with minimal downtime and disruption. This migration is recommended as VNet injection has some limitations and drawbacks, such as increased complexity, reduced scalability, and dependency on public IP addresses.
The migration process is simple and can be done using the Azure portal, the ARM template, or any code which uses the ADX SDK 1. For more information on the migration process, prerequisites, and steps to follow, please refer to the detailed documentation article.
Resources:
Azure Data Explorer documentation
Migrate a Virtual Network injected cluster to private endpoints (Preview)
Microsoft Azure Data Fundamentals: Explore relational data in Azure
Data analysis in Azure Data Explorer with Kusto Query Language
Create dashboards in Azure Data Explorer
Security Update for Azure Front Door and Application Gateway WAF
Front Door and Application Gateway web application firewall (WAF) protects web applications from common vulnerabilities and exploits.
Azure-managed rule sets provide an easy way to deploy protection against a common set of security threats. Since such rule sets are managed by Azure, the rules are updated as needed to protect against new attack signatures.
Default rule set also includes the Microsoft Threat Intelligence Collection rules that are written in partnership with the Microsoft Intelligence team to provide increased coverage, patches for specific vulnerabilities, and better false positive reduction.
Customers also have the option of using rules that are defined based on the OWASP (Open Worldwide Application Security Project (OWASP) core rule sets 3.2, 3.1, 3.0, or 2.2.9.
At the end of December, we updated our Default Rule Set (DRS) and OWASP has updated the Core Rule Set (CRS) to address the security vulnerability CVE-2023-50164. (An attacker can manipulate file upload params to enable paths traversal and under some circumstances this can lead to uploading a malicious file which can be used to perform Remote Code Execution)
Prohibiting Domain Fronting with Azure Front Door and Azure CDN Standard from Microsoft
Domain fronting is a network technique that enables an attacker to conceal the actual destination of a request by sending traffic to a different domain in HTTP host header than the one used in the TLS/SSL handshake.
Azure Front Door and Azure CDN Standard from Microsoft (classic) protects against domain fronting occurring on domains hosted across different Azure subscriptions. The Server Name Indication (SNI) in TLS/SSL handshake and HTTP host header, whether they are the same or different, must be configured under the same Azure subscription.
Starting from January 22, 2024, all existing Azure Front Door and Azure CDN Standard from Microsoft (classic) resources will block any HTTP request that exhibits domain fronting behavior. The enforcement of blocking changes may require up to two weeks to propagate on the global PoPs (point of presences) starting from January 22, 2024.
To help identify if an Azure Front Door or Azure CDN from Microsoft (classic) resources display domain fronting behavior, two new log fields will be available on December 25, 2023.
Resources:
Prohibiting Domain Fronting with Azure Front Door and Azure CDN
Azure Networking Blog – Microsoft Community Hub.
Simplified management of Listeners TLS certificates
If you use Application Gateway, you know that terminating TLS (HTTP traffic) can be done on the Gateway to take the burden off the backend resources. Given you many have a large number of backend resources with difference hostnames (FQDNs), this can be challenging to manage. Traditionally, this could only be done with Azure PowerShell or Azure CLI.
Now you can manage all your TLS certificates for APP Gateway through the Azure portal:
Key Features include:
Quick listing
Certificate information
Bulk Operations
Resources:
Simplified management of Listeners TLS certificates
Public preview: Private subnet
Now customers will be able to create custom private subnets in Azure for their resources.
Currently, when virtual machines are created in a virtual network without any explicit outbound connectivity, they are assigned a default outbound public IP address. These implicit IPs are subject to change, not associated with a subscription, difficult to troubleshoot, and do not follow Azure’s model of “secure by default” which ensures customers have strong security without additional steps needed. (The depreciation for this type of implicit connectivity was recently announced and is scheduled for September 2025.)
The private subnet feature will let you prevent this insecure implicit connectivity for any newly created subnets by setting the “default outbound access” parameter to false. You can then pick your preferred method for explicit outbound connectivity to the internet.
How to implement and turn off default outbound?
Utilize Private Subnet parameter
Add the Private subnet feature at creation
Add an explicit outbound connectivity method
NAT Gateway
Standard LB
Standar Public IP
Use Flexible orchestration mode for Virtual Machine Scale sets
Resources:
Default outbound access in Azure
How can I transition to an explicit method of public connectivity (and disable default outbound access)?
That’s it for this month. Happy 2024! (it’s January… I can still say that. Right?!?)
Cheers
Pierre
Microsoft Tech Community – Latest Blogs –Read More
Wired for Hybrid – What’s New in Azure Networking – January 2024 edition
Hello Folks,
Azure Networking is the foundation of your infrastructure in Azure. Each month we bring you an update on What’s new in Azure Networking.
In this blog post, we’ll cover what’s new with Azure Networking in January 2024. In this blog post, we will cover the following announcements and how they can help you.
Standard and High-Performance VPN Gateway SKUs will be retired
Migration of Azure Virtual Network injected Azure Data Explorer cluster to Private Endpoints
Security Update for Azure Front Door and Application Gateway WAF
Prohibiting Domain Fronting with Azure Front Door and Azure CDN Standard from Microsoft
Simplified management of Listeners TLS certificates
Public preview: Private subnet
Enjoy!
Standard and High-Performance VPN Gateway SKUs will be retired
On 30 September 2025, Basic SKU public IP addresses will be retired in Azure. You can continue to use your existing Basic SKU public IP addresses until then, however, you will no longer be able to create new ones after 31 March 2025.
Standard SKU public IP addresses offer significant improvements, including:
Access to a variety of other Azure products, including Standard Load Balancer, Azure Firewall, and NAT Gateway.
Security by default—closed to inbound flows unless allowed by a network security group.
Zone-redundant and zonal front ends for inbound and outbound traffic.
If you have any Basic SKU public IP addresses deployed in Azure Cloud Services (extended support), those deployments will not be affected by this retirement, and you do not need to take any action for them. Because of the retirement of Basic IP, which Standard and High-Performance SKUs only accept, we will retire these SKUs on 30 September 2025. Starting 1 December 2023, you will no longer be able to create a new gateway with these SKUs.
Recommended action: Post December 2024, you will be able to upgrade your Standard/High-Performance gateway SKU to one of the other VPN Gateway SKUs available.
If you do not upgrade your gateway by August 2025, your gateway will be automatically upgraded to VPNGw1AZ (Standard) or VPNGw2AZ (High-Performance) after 30 September 2025.
Migration of Azure Virtual Network injected Azure Data Explorer cluster to Private Endpoints
An Azure Virtual Network injected Azure Data Explorer cluster is a cluster that is deployed into a subnet in your Virtual Network (VNet). This enables you to access the cluster privately from your Azure virtual network or on-premises, access resources such as Event Hubs and Azure Storage inside your virtual network and restrict inbound and outbound traffic.
Private Endpoint is a network interface that connects your ADX cluster to a private IP address within your VNet. Private endpoints enable you to connect to your ADX cluster using a private IP address within your VNet, without the need for public IP addresses.
Microsoft Azure has released a preview feature that allows users to migrate their VNet injected ADX cluster to Private Endpoints with minimal downtime and disruption. This migration is recommended as VNet injection has some limitations and drawbacks, such as increased complexity, reduced scalability, and dependency on public IP addresses.
The migration process is simple and can be done using the Azure portal, the ARM template, or any code which uses the ADX SDK 1. For more information on the migration process, prerequisites, and steps to follow, please refer to the detailed documentation article.
Resources:
Azure Data Explorer documentation
Migrate a Virtual Network injected cluster to private endpoints (Preview)
Microsoft Azure Data Fundamentals: Explore relational data in Azure
Data analysis in Azure Data Explorer with Kusto Query Language
Create dashboards in Azure Data Explorer
Security Update for Azure Front Door and Application Gateway WAF
Front Door and Application Gateway web application firewall (WAF) protects web applications from common vulnerabilities and exploits.
Azure-managed rule sets provide an easy way to deploy protection against a common set of security threats. Since such rule sets are managed by Azure, the rules are updated as needed to protect against new attack signatures.
Default rule set also includes the Microsoft Threat Intelligence Collection rules that are written in partnership with the Microsoft Intelligence team to provide increased coverage, patches for specific vulnerabilities, and better false positive reduction.
Customers also have the option of using rules that are defined based on the OWASP (Open Worldwide Application Security Project (OWASP) core rule sets 3.2, 3.1, 3.0, or 2.2.9.
At the end of December, we updated our Default Rule Set (DRS) and OWASP has updated the Core Rule Set (CRS) to address the security vulnerability CVE-2023-50164. (An attacker can manipulate file upload params to enable paths traversal and under some circumstances this can lead to uploading a malicious file which can be used to perform Remote Code Execution)
Prohibiting Domain Fronting with Azure Front Door and Azure CDN Standard from Microsoft
Domain fronting is a network technique that enables an attacker to conceal the actual destination of a request by sending traffic to a different domain in HTTP host header than the one used in the TLS/SSL handshake.
Azure Front Door and Azure CDN Standard from Microsoft (classic) protects against domain fronting occurring on domains hosted across different Azure subscriptions. The Server Name Indication (SNI) in TLS/SSL handshake and HTTP host header, whether they are the same or different, must be configured under the same Azure subscription.
Starting from January 22, 2024, all existing Azure Front Door and Azure CDN Standard from Microsoft (classic) resources will block any HTTP request that exhibits domain fronting behavior. The enforcement of blocking changes may require up to two weeks to propagate on the global PoPs (point of presences) starting from January 22, 2024.
To help identify if an Azure Front Door or Azure CDN from Microsoft (classic) resources display domain fronting behavior, two new log fields will be available on December 25, 2023.
Resources:
Prohibiting Domain Fronting with Azure Front Door and Azure CDN
Azure Networking Blog – Microsoft Community Hub.
Simplified management of Listeners TLS certificates
If you use Application Gateway, you know that terminating TLS (HTTP traffic) can be done on the Gateway to take the burden off the backend resources. Given you many have a large number of backend resources with difference hostnames (FQDNs), this can be challenging to manage. Traditionally, this could only be done with Azure PowerShell or Azure CLI.
Now you can manage all your TLS certificates for APP Gateway through the Azure portal:
Key Features include:
Quick listing
Certificate information
Bulk Operations
Resources:
Simplified management of Listeners TLS certificates
Public preview: Private subnet
Now customers will be able to create custom private subnets in Azure for their resources.
Currently, when virtual machines are created in a virtual network without any explicit outbound connectivity, they are assigned a default outbound public IP address. These implicit IPs are subject to change, not associated with a subscription, difficult to troubleshoot, and do not follow Azure’s model of “secure by default” which ensures customers have strong security without additional steps needed. (The depreciation for this type of implicit connectivity was recently announced and is scheduled for September 2025.)
The private subnet feature will let you prevent this insecure implicit connectivity for any newly created subnets by setting the “default outbound access” parameter to false. You can then pick your preferred method for explicit outbound connectivity to the internet.
How to implement and turn off default outbound?
Utilize Private Subnet parameter
Add the Private subnet feature at creation
Add an explicit outbound connectivity method
NAT Gateway
Standard LB
Standar Public IP
Use Flexible orchestration mode for Virtual Machine Scale sets
Resources:
Default outbound access in Azure
How can I transition to an explicit method of public connectivity (and disable default outbound access)?
That’s it for this month. Happy 2024! (it’s January… I can still say that. Right?!?)
Cheers
Pierre
Microsoft Tech Community – Latest Blogs –Read More
Wired for Hybrid – What’s New in Azure Networking – January 2024 edition
Hello Folks,
Azure Networking is the foundation of your infrastructure in Azure. Each month we bring you an update on What’s new in Azure Networking.
In this blog post, we’ll cover what’s new with Azure Networking in January 2024. In this blog post, we will cover the following announcements and how they can help you.
Standard and High-Performance VPN Gateway SKUs will be retired
Migration of Azure Virtual Network injected Azure Data Explorer cluster to Private Endpoints
Security Update for Azure Front Door and Application Gateway WAF
Prohibiting Domain Fronting with Azure Front Door and Azure CDN Standard from Microsoft
Simplified management of Listeners TLS certificates
Public preview: Private subnet
Enjoy!
Standard and High-Performance VPN Gateway SKUs will be retired
On 30 September 2025, Basic SKU public IP addresses will be retired in Azure. You can continue to use your existing Basic SKU public IP addresses until then, however, you will no longer be able to create new ones after 31 March 2025.
Standard SKU public IP addresses offer significant improvements, including:
Access to a variety of other Azure products, including Standard Load Balancer, Azure Firewall, and NAT Gateway.
Security by default—closed to inbound flows unless allowed by a network security group.
Zone-redundant and zonal front ends for inbound and outbound traffic.
If you have any Basic SKU public IP addresses deployed in Azure Cloud Services (extended support), those deployments will not be affected by this retirement, and you do not need to take any action for them. Because of the retirement of Basic IP, which Standard and High-Performance SKUs only accept, we will retire these SKUs on 30 September 2025. Starting 1 December 2023, you will no longer be able to create a new gateway with these SKUs.
Recommended action: Post December 2024, you will be able to upgrade your Standard/High-Performance gateway SKU to one of the other VPN Gateway SKUs available.
If you do not upgrade your gateway by August 2025, your gateway will be automatically upgraded to VPNGw1AZ (Standard) or VPNGw2AZ (High-Performance) after 30 September 2025.
Migration of Azure Virtual Network injected Azure Data Explorer cluster to Private Endpoints
An Azure Virtual Network injected Azure Data Explorer cluster is a cluster that is deployed into a subnet in your Virtual Network (VNet). This enables you to access the cluster privately from your Azure virtual network or on-premises, access resources such as Event Hubs and Azure Storage inside your virtual network and restrict inbound and outbound traffic.
Private Endpoint is a network interface that connects your ADX cluster to a private IP address within your VNet. Private endpoints enable you to connect to your ADX cluster using a private IP address within your VNet, without the need for public IP addresses.
Microsoft Azure has released a preview feature that allows users to migrate their VNet injected ADX cluster to Private Endpoints with minimal downtime and disruption. This migration is recommended as VNet injection has some limitations and drawbacks, such as increased complexity, reduced scalability, and dependency on public IP addresses.
The migration process is simple and can be done using the Azure portal, the ARM template, or any code which uses the ADX SDK 1. For more information on the migration process, prerequisites, and steps to follow, please refer to the detailed documentation article.
Resources:
Azure Data Explorer documentation
Migrate a Virtual Network injected cluster to private endpoints (Preview)
Microsoft Azure Data Fundamentals: Explore relational data in Azure
Data analysis in Azure Data Explorer with Kusto Query Language
Create dashboards in Azure Data Explorer
Security Update for Azure Front Door and Application Gateway WAF
Front Door and Application Gateway web application firewall (WAF) protects web applications from common vulnerabilities and exploits.
Azure-managed rule sets provide an easy way to deploy protection against a common set of security threats. Since such rule sets are managed by Azure, the rules are updated as needed to protect against new attack signatures.
Default rule set also includes the Microsoft Threat Intelligence Collection rules that are written in partnership with the Microsoft Intelligence team to provide increased coverage, patches for specific vulnerabilities, and better false positive reduction.
Customers also have the option of using rules that are defined based on the OWASP (Open Worldwide Application Security Project (OWASP) core rule sets 3.2, 3.1, 3.0, or 2.2.9.
At the end of December, we updated our Default Rule Set (DRS) and OWASP has updated the Core Rule Set (CRS) to address the security vulnerability CVE-2023-50164. (An attacker can manipulate file upload params to enable paths traversal and under some circumstances this can lead to uploading a malicious file which can be used to perform Remote Code Execution)
Prohibiting Domain Fronting with Azure Front Door and Azure CDN Standard from Microsoft
Domain fronting is a network technique that enables an attacker to conceal the actual destination of a request by sending traffic to a different domain in HTTP host header than the one used in the TLS/SSL handshake.
Azure Front Door and Azure CDN Standard from Microsoft (classic) protects against domain fronting occurring on domains hosted across different Azure subscriptions. The Server Name Indication (SNI) in TLS/SSL handshake and HTTP host header, whether they are the same or different, must be configured under the same Azure subscription.
Starting from January 22, 2024, all existing Azure Front Door and Azure CDN Standard from Microsoft (classic) resources will block any HTTP request that exhibits domain fronting behavior. The enforcement of blocking changes may require up to two weeks to propagate on the global PoPs (point of presences) starting from January 22, 2024.
To help identify if an Azure Front Door or Azure CDN from Microsoft (classic) resources display domain fronting behavior, two new log fields will be available on December 25, 2023.
Resources:
Prohibiting Domain Fronting with Azure Front Door and Azure CDN
Azure Networking Blog – Microsoft Community Hub.
Simplified management of Listeners TLS certificates
If you use Application Gateway, you know that terminating TLS (HTTP traffic) can be done on the Gateway to take the burden off the backend resources. Given you many have a large number of backend resources with difference hostnames (FQDNs), this can be challenging to manage. Traditionally, this could only be done with Azure PowerShell or Azure CLI.
Now you can manage all your TLS certificates for APP Gateway through the Azure portal:
Key Features include:
Quick listing
Certificate information
Bulk Operations
Resources:
Simplified management of Listeners TLS certificates
Public preview: Private subnet
Now customers will be able to create custom private subnets in Azure for their resources.
Currently, when virtual machines are created in a virtual network without any explicit outbound connectivity, they are assigned a default outbound public IP address. These implicit IPs are subject to change, not associated with a subscription, difficult to troubleshoot, and do not follow Azure’s model of “secure by default” which ensures customers have strong security without additional steps needed. (The depreciation for this type of implicit connectivity was recently announced and is scheduled for September 2025.)
The private subnet feature will let you prevent this insecure implicit connectivity for any newly created subnets by setting the “default outbound access” parameter to false. You can then pick your preferred method for explicit outbound connectivity to the internet.
How to implement and turn off default outbound?
Utilize Private Subnet parameter
Add the Private subnet feature at creation
Add an explicit outbound connectivity method
NAT Gateway
Standard LB
Standar Public IP
Use Flexible orchestration mode for Virtual Machine Scale sets
Resources:
Default outbound access in Azure
How can I transition to an explicit method of public connectivity (and disable default outbound access)?
That’s it for this month. Happy 2024! (it’s January… I can still say that. Right?!?)
Cheers
Pierre
Microsoft Tech Community – Latest Blogs –Read More
Wired for Hybrid – What’s New in Azure Networking – January 2024 edition
Hello Folks,
Azure Networking is the foundation of your infrastructure in Azure. Each month we bring you an update on What’s new in Azure Networking.
In this blog post, we’ll cover what’s new with Azure Networking in January 2024. In this blog post, we will cover the following announcements and how they can help you.
Standard and High-Performance VPN Gateway SKUs will be retired
Migration of Azure Virtual Network injected Azure Data Explorer cluster to Private Endpoints
Security Update for Azure Front Door and Application Gateway WAF
Prohibiting Domain Fronting with Azure Front Door and Azure CDN Standard from Microsoft
Simplified management of Listeners TLS certificates
Public preview: Private subnet
Enjoy!
Standard and High-Performance VPN Gateway SKUs will be retired
On 30 September 2025, Basic SKU public IP addresses will be retired in Azure. You can continue to use your existing Basic SKU public IP addresses until then, however, you will no longer be able to create new ones after 31 March 2025.
Standard SKU public IP addresses offer significant improvements, including:
Access to a variety of other Azure products, including Standard Load Balancer, Azure Firewall, and NAT Gateway.
Security by default—closed to inbound flows unless allowed by a network security group.
Zone-redundant and zonal front ends for inbound and outbound traffic.
If you have any Basic SKU public IP addresses deployed in Azure Cloud Services (extended support), those deployments will not be affected by this retirement, and you do not need to take any action for them. Because of the retirement of Basic IP, which Standard and High-Performance SKUs only accept, we will retire these SKUs on 30 September 2025. Starting 1 December 2023, you will no longer be able to create a new gateway with these SKUs.
Recommended action: Post December 2024, you will be able to upgrade your Standard/High-Performance gateway SKU to one of the other VPN Gateway SKUs available.
If you do not upgrade your gateway by August 2025, your gateway will be automatically upgraded to VPNGw1AZ (Standard) or VPNGw2AZ (High-Performance) after 30 September 2025.
Migration of Azure Virtual Network injected Azure Data Explorer cluster to Private Endpoints
An Azure Virtual Network injected Azure Data Explorer cluster is a cluster that is deployed into a subnet in your Virtual Network (VNet). This enables you to access the cluster privately from your Azure virtual network or on-premises, access resources such as Event Hubs and Azure Storage inside your virtual network and restrict inbound and outbound traffic.
Private Endpoint is a network interface that connects your ADX cluster to a private IP address within your VNet. Private endpoints enable you to connect to your ADX cluster using a private IP address within your VNet, without the need for public IP addresses.
Microsoft Azure has released a preview feature that allows users to migrate their VNet injected ADX cluster to Private Endpoints with minimal downtime and disruption. This migration is recommended as VNet injection has some limitations and drawbacks, such as increased complexity, reduced scalability, and dependency on public IP addresses.
The migration process is simple and can be done using the Azure portal, the ARM template, or any code which uses the ADX SDK 1. For more information on the migration process, prerequisites, and steps to follow, please refer to the detailed documentation article.
Resources:
Azure Data Explorer documentation
Migrate a Virtual Network injected cluster to private endpoints (Preview)
Microsoft Azure Data Fundamentals: Explore relational data in Azure
Data analysis in Azure Data Explorer with Kusto Query Language
Create dashboards in Azure Data Explorer
Security Update for Azure Front Door and Application Gateway WAF
Front Door and Application Gateway web application firewall (WAF) protects web applications from common vulnerabilities and exploits.
Azure-managed rule sets provide an easy way to deploy protection against a common set of security threats. Since such rule sets are managed by Azure, the rules are updated as needed to protect against new attack signatures.
Default rule set also includes the Microsoft Threat Intelligence Collection rules that are written in partnership with the Microsoft Intelligence team to provide increased coverage, patches for specific vulnerabilities, and better false positive reduction.
Customers also have the option of using rules that are defined based on the OWASP (Open Worldwide Application Security Project (OWASP) core rule sets 3.2, 3.1, 3.0, or 2.2.9.
At the end of December, we updated our Default Rule Set (DRS) and OWASP has updated the Core Rule Set (CRS) to address the security vulnerability CVE-2023-50164. (An attacker can manipulate file upload params to enable paths traversal and under some circumstances this can lead to uploading a malicious file which can be used to perform Remote Code Execution)
Prohibiting Domain Fronting with Azure Front Door and Azure CDN Standard from Microsoft
Domain fronting is a network technique that enables an attacker to conceal the actual destination of a request by sending traffic to a different domain in HTTP host header than the one used in the TLS/SSL handshake.
Azure Front Door and Azure CDN Standard from Microsoft (classic) protects against domain fronting occurring on domains hosted across different Azure subscriptions. The Server Name Indication (SNI) in TLS/SSL handshake and HTTP host header, whether they are the same or different, must be configured under the same Azure subscription.
Starting from January 22, 2024, all existing Azure Front Door and Azure CDN Standard from Microsoft (classic) resources will block any HTTP request that exhibits domain fronting behavior. The enforcement of blocking changes may require up to two weeks to propagate on the global PoPs (point of presences) starting from January 22, 2024.
To help identify if an Azure Front Door or Azure CDN from Microsoft (classic) resources display domain fronting behavior, two new log fields will be available on December 25, 2023.
Resources:
Prohibiting Domain Fronting with Azure Front Door and Azure CDN
Azure Networking Blog – Microsoft Community Hub.
Simplified management of Listeners TLS certificates
If you use Application Gateway, you know that terminating TLS (HTTP traffic) can be done on the Gateway to take the burden off the backend resources. Given you many have a large number of backend resources with difference hostnames (FQDNs), this can be challenging to manage. Traditionally, this could only be done with Azure PowerShell or Azure CLI.
Now you can manage all your TLS certificates for APP Gateway through the Azure portal:
Key Features include:
Quick listing
Certificate information
Bulk Operations
Resources:
Simplified management of Listeners TLS certificates
Public preview: Private subnet
Now customers will be able to create custom private subnets in Azure for their resources.
Currently, when virtual machines are created in a virtual network without any explicit outbound connectivity, they are assigned a default outbound public IP address. These implicit IPs are subject to change, not associated with a subscription, difficult to troubleshoot, and do not follow Azure’s model of “secure by default” which ensures customers have strong security without additional steps needed. (The depreciation for this type of implicit connectivity was recently announced and is scheduled for September 2025.)
The private subnet feature will let you prevent this insecure implicit connectivity for any newly created subnets by setting the “default outbound access” parameter to false. You can then pick your preferred method for explicit outbound connectivity to the internet.
How to implement and turn off default outbound?
Utilize Private Subnet parameter
Add the Private subnet feature at creation
Add an explicit outbound connectivity method
NAT Gateway
Standard LB
Standar Public IP
Use Flexible orchestration mode for Virtual Machine Scale sets
Resources:
Default outbound access in Azure
How can I transition to an explicit method of public connectivity (and disable default outbound access)?
That’s it for this month. Happy 2024! (it’s January… I can still say that. Right?!?)
Cheers
Pierre
Microsoft Tech Community – Latest Blogs –Read More
Wired for Hybrid – What’s New in Azure Networking – January 2024 edition
Hello Folks,
Azure Networking is the foundation of your infrastructure in Azure. Each month we bring you an update on What’s new in Azure Networking.
In this blog post, we’ll cover what’s new with Azure Networking in January 2024. In this blog post, we will cover the following announcements and how they can help you.
Standard and High-Performance VPN Gateway SKUs will be retired
Migration of Azure Virtual Network injected Azure Data Explorer cluster to Private Endpoints
Security Update for Azure Front Door and Application Gateway WAF
Prohibiting Domain Fronting with Azure Front Door and Azure CDN Standard from Microsoft
Simplified management of Listeners TLS certificates
Public preview: Private subnet
Enjoy!
Standard and High-Performance VPN Gateway SKUs will be retired
On 30 September 2025, Basic SKU public IP addresses will be retired in Azure. You can continue to use your existing Basic SKU public IP addresses until then, however, you will no longer be able to create new ones after 31 March 2025.
Standard SKU public IP addresses offer significant improvements, including:
Access to a variety of other Azure products, including Standard Load Balancer, Azure Firewall, and NAT Gateway.
Security by default—closed to inbound flows unless allowed by a network security group.
Zone-redundant and zonal front ends for inbound and outbound traffic.
If you have any Basic SKU public IP addresses deployed in Azure Cloud Services (extended support), those deployments will not be affected by this retirement, and you do not need to take any action for them. Because of the retirement of Basic IP, which Standard and High-Performance SKUs only accept, we will retire these SKUs on 30 September 2025. Starting 1 December 2023, you will no longer be able to create a new gateway with these SKUs.
Recommended action: Post December 2024, you will be able to upgrade your Standard/High-Performance gateway SKU to one of the other VPN Gateway SKUs available.
If you do not upgrade your gateway by August 2025, your gateway will be automatically upgraded to VPNGw1AZ (Standard) or VPNGw2AZ (High-Performance) after 30 September 2025.
Migration of Azure Virtual Network injected Azure Data Explorer cluster to Private Endpoints
An Azure Virtual Network injected Azure Data Explorer cluster is a cluster that is deployed into a subnet in your Virtual Network (VNet). This enables you to access the cluster privately from your Azure virtual network or on-premises, access resources such as Event Hubs and Azure Storage inside your virtual network and restrict inbound and outbound traffic.
Private Endpoint is a network interface that connects your ADX cluster to a private IP address within your VNet. Private endpoints enable you to connect to your ADX cluster using a private IP address within your VNet, without the need for public IP addresses.
Microsoft Azure has released a preview feature that allows users to migrate their VNet injected ADX cluster to Private Endpoints with minimal downtime and disruption. This migration is recommended as VNet injection has some limitations and drawbacks, such as increased complexity, reduced scalability, and dependency on public IP addresses.
The migration process is simple and can be done using the Azure portal, the ARM template, or any code which uses the ADX SDK 1. For more information on the migration process, prerequisites, and steps to follow, please refer to the detailed documentation article.
Resources:
Azure Data Explorer documentation
Migrate a Virtual Network injected cluster to private endpoints (Preview)
Microsoft Azure Data Fundamentals: Explore relational data in Azure
Data analysis in Azure Data Explorer with Kusto Query Language
Create dashboards in Azure Data Explorer
Security Update for Azure Front Door and Application Gateway WAF
Front Door and Application Gateway web application firewall (WAF) protects web applications from common vulnerabilities and exploits.
Azure-managed rule sets provide an easy way to deploy protection against a common set of security threats. Since such rule sets are managed by Azure, the rules are updated as needed to protect against new attack signatures.
Default rule set also includes the Microsoft Threat Intelligence Collection rules that are written in partnership with the Microsoft Intelligence team to provide increased coverage, patches for specific vulnerabilities, and better false positive reduction.
Customers also have the option of using rules that are defined based on the OWASP (Open Worldwide Application Security Project (OWASP) core rule sets 3.2, 3.1, 3.0, or 2.2.9.
At the end of December, we updated our Default Rule Set (DRS) and OWASP has updated the Core Rule Set (CRS) to address the security vulnerability CVE-2023-50164. (An attacker can manipulate file upload params to enable paths traversal and under some circumstances this can lead to uploading a malicious file which can be used to perform Remote Code Execution)
Prohibiting Domain Fronting with Azure Front Door and Azure CDN Standard from Microsoft
Domain fronting is a network technique that enables an attacker to conceal the actual destination of a request by sending traffic to a different domain in HTTP host header than the one used in the TLS/SSL handshake.
Azure Front Door and Azure CDN Standard from Microsoft (classic) protects against domain fronting occurring on domains hosted across different Azure subscriptions. The Server Name Indication (SNI) in TLS/SSL handshake and HTTP host header, whether they are the same or different, must be configured under the same Azure subscription.
Starting from January 22, 2024, all existing Azure Front Door and Azure CDN Standard from Microsoft (classic) resources will block any HTTP request that exhibits domain fronting behavior. The enforcement of blocking changes may require up to two weeks to propagate on the global PoPs (point of presences) starting from January 22, 2024.
To help identify if an Azure Front Door or Azure CDN from Microsoft (classic) resources display domain fronting behavior, two new log fields will be available on December 25, 2023.
Resources:
Prohibiting Domain Fronting with Azure Front Door and Azure CDN
Azure Networking Blog – Microsoft Community Hub.
Simplified management of Listeners TLS certificates
If you use Application Gateway, you know that terminating TLS (HTTP traffic) can be done on the Gateway to take the burden off the backend resources. Given you many have a large number of backend resources with difference hostnames (FQDNs), this can be challenging to manage. Traditionally, this could only be done with Azure PowerShell or Azure CLI.
Now you can manage all your TLS certificates for APP Gateway through the Azure portal:
Key Features include:
Quick listing
Certificate information
Bulk Operations
Resources:
Simplified management of Listeners TLS certificates
Public preview: Private subnet
Now customers will be able to create custom private subnets in Azure for their resources.
Currently, when virtual machines are created in a virtual network without any explicit outbound connectivity, they are assigned a default outbound public IP address. These implicit IPs are subject to change, not associated with a subscription, difficult to troubleshoot, and do not follow Azure’s model of “secure by default” which ensures customers have strong security without additional steps needed. (The depreciation for this type of implicit connectivity was recently announced and is scheduled for September 2025.)
The private subnet feature will let you prevent this insecure implicit connectivity for any newly created subnets by setting the “default outbound access” parameter to false. You can then pick your preferred method for explicit outbound connectivity to the internet.
How to implement and turn off default outbound?
Utilize Private Subnet parameter
Add the Private subnet feature at creation
Add an explicit outbound connectivity method
NAT Gateway
Standard LB
Standar Public IP
Use Flexible orchestration mode for Virtual Machine Scale sets
Resources:
Default outbound access in Azure
How can I transition to an explicit method of public connectivity (and disable default outbound access)?
That’s it for this month. Happy 2024! (it’s January… I can still say that. Right?!?)
Cheers
Pierre
Microsoft Tech Community – Latest Blogs –Read More
ICYMI | Great article on Azure Cognitive Services & Azure Machine Learning Cost Analysis
Azure Cognitive Services & Azure Machine Learning Cost Analysis
This document serves as an essential guide for Independent Software Vendors (ISVs) to navigate the complexities of cost management associated with Azure Cognitive Services, focusing on Azure OpenAI and Azure Machine Learning. It adopts a structured approach, examining costs across different project phases—Development, Testing, and Production—to provide a comprehensive view of financial implications at each stage. More than just listing prices, this research explains them, linking to official Azure documentation for accuracy, and offering practical tips and strategies for cost optimization. It’s crafted to assist both developers and CTOs in making informed decisions, balancing technological innovation with budget constraints. This is your go-to resource for understanding and managing the costs of Azure’s advanced cognitive services.
Microsoft Tech Community – Latest Blogs –Read More
ICYMI | Great article on Azure Cognitive Services & Azure Machine Learning Cost Analysis
Azure Cognitive Services & Azure Machine Learning Cost Analysis
This document serves as an essential guide for Independent Software Vendors (ISVs) to navigate the complexities of cost management associated with Azure Cognitive Services, focusing on Azure OpenAI and Azure Machine Learning. It adopts a structured approach, examining costs across different project phases—Development, Testing, and Production—to provide a comprehensive view of financial implications at each stage. More than just listing prices, this research explains them, linking to official Azure documentation for accuracy, and offering practical tips and strategies for cost optimization. It’s crafted to assist both developers and CTOs in making informed decisions, balancing technological innovation with budget constraints. This is your go-to resource for understanding and managing the costs of Azure’s advanced cognitive services.
Microsoft Tech Community – Latest Blogs –Read More
ICYMI | Great article on Azure Cognitive Services & Azure Machine Learning Cost Analysis
Azure Cognitive Services & Azure Machine Learning Cost Analysis
This document serves as an essential guide for Independent Software Vendors (ISVs) to navigate the complexities of cost management associated with Azure Cognitive Services, focusing on Azure OpenAI and Azure Machine Learning. It adopts a structured approach, examining costs across different project phases—Development, Testing, and Production—to provide a comprehensive view of financial implications at each stage. More than just listing prices, this research explains them, linking to official Azure documentation for accuracy, and offering practical tips and strategies for cost optimization. It’s crafted to assist both developers and CTOs in making informed decisions, balancing technological innovation with budget constraints. This is your go-to resource for understanding and managing the costs of Azure’s advanced cognitive services.
Microsoft Tech Community – Latest Blogs –Read More
ICYMI | Great article on Azure Cognitive Services & Azure Machine Learning Cost Analysis
Azure Cognitive Services & Azure Machine Learning Cost Analysis
This document serves as an essential guide for Independent Software Vendors (ISVs) to navigate the complexities of cost management associated with Azure Cognitive Services, focusing on Azure OpenAI and Azure Machine Learning. It adopts a structured approach, examining costs across different project phases—Development, Testing, and Production—to provide a comprehensive view of financial implications at each stage. More than just listing prices, this research explains them, linking to official Azure documentation for accuracy, and offering practical tips and strategies for cost optimization. It’s crafted to assist both developers and CTOs in making informed decisions, balancing technological innovation with budget constraints. This is your go-to resource for understanding and managing the costs of Azure’s advanced cognitive services.
Microsoft Tech Community – Latest Blogs –Read More
ICYMI | Great article on Azure Cognitive Services & Azure Machine Learning Cost Analysis
Azure Cognitive Services & Azure Machine Learning Cost Analysis
This document serves as an essential guide for Independent Software Vendors (ISVs) to navigate the complexities of cost management associated with Azure Cognitive Services, focusing on Azure OpenAI and Azure Machine Learning. It adopts a structured approach, examining costs across different project phases—Development, Testing, and Production—to provide a comprehensive view of financial implications at each stage. More than just listing prices, this research explains them, linking to official Azure documentation for accuracy, and offering practical tips and strategies for cost optimization. It’s crafted to assist both developers and CTOs in making informed decisions, balancing technological innovation with budget constraints. This is your go-to resource for understanding and managing the costs of Azure’s advanced cognitive services.
Microsoft Tech Community – Latest Blogs –Read More
ICYMI | Great article on Azure Cognitive Services & Azure Machine Learning Cost Analysis
Azure Cognitive Services & Azure Machine Learning Cost Analysis
This document serves as an essential guide for Independent Software Vendors (ISVs) to navigate the complexities of cost management associated with Azure Cognitive Services, focusing on Azure OpenAI and Azure Machine Learning. It adopts a structured approach, examining costs across different project phases—Development, Testing, and Production—to provide a comprehensive view of financial implications at each stage. More than just listing prices, this research explains them, linking to official Azure documentation for accuracy, and offering practical tips and strategies for cost optimization. It’s crafted to assist both developers and CTOs in making informed decisions, balancing technological innovation with budget constraints. This is your go-to resource for understanding and managing the costs of Azure’s advanced cognitive services.
Microsoft Tech Community – Latest Blogs –Read More
ICYMI | Great article on Azure Cognitive Services & Azure Machine Learning Cost Analysis
Azure Cognitive Services & Azure Machine Learning Cost Analysis
This document serves as an essential guide for Independent Software Vendors (ISVs) to navigate the complexities of cost management associated with Azure Cognitive Services, focusing on Azure OpenAI and Azure Machine Learning. It adopts a structured approach, examining costs across different project phases—Development, Testing, and Production—to provide a comprehensive view of financial implications at each stage. More than just listing prices, this research explains them, linking to official Azure documentation for accuracy, and offering practical tips and strategies for cost optimization. It’s crafted to assist both developers and CTOs in making informed decisions, balancing technological innovation with budget constraints. This is your go-to resource for understanding and managing the costs of Azure’s advanced cognitive services.
Microsoft Tech Community – Latest Blogs –Read More