Hello readers,
You might have noticed the supportability for any existing commitment tier, including the small 100, 200, 300, 400 GB/Day ones, for Azure Monitor Logs Dedicated Cluster have been announced by the Azure Monitor product group. The official announcement went live on January 25, 2024 and can be found HERE.
As short recap, an Azure Monitor Logs Dedicated Cluster might be required if you would like to use one or more of the capabilities reported below:
- Customer-managed keys - Encrypt cluster data using keys that you provide and control.
- Lockbox - Control Microsoft Support engineer access requests to your data.
- Double encryption - Protect against a scenario where one of the encryption algorithms or keys may be compromised. In this case, the extra layer of encryption continues to protect your data.
- Cross-query optimization - Cross-workspace queries run faster when workspaces are on the same cluster.
- Cost optimization - Link your workspaces in the same region to cluster to get commitment tier discount to all workspaces, even to ones with low ingestion that are eligible for commitment tier discount.
- Availability zones - Protect your data from datacenter failures by relying on datacenters in different physical locations, equipped with independent power, cooling, and networking. The physical separation in zones and independent infrastructure makes an incident far less likely since the workspace can rely on the resources from any of the zones. Azure Monitor availability zones covers broader parts of the service and when available in your region, extends your Azure Monitor resilience automatically. Azure Monitor creates dedicated clusters as availability-zone-enabled (isAvailabilityZonesEnabled: 'true') by default in supported regions. Dedicated clusters Availability zones aren't supported in all regions currently.
- Ingest from Azure Event Hubs - Lets you ingest data directly from an event hub into a Log Analytics workspace. Dedicated cluster lets you use capability when ingestion from all linked workspaces combined meet commitment tier.
As per the announcement, configuration is first available the Clusters - Create Or Update REST API. There are also good examples in Microsoft documentation, including methods like Azure portal, Azure CLI, PowerShell, and REST API, about cluster provisioning.
Trying to make your life easier I created a PowerShell script that allows you to use PowerShell to leverage REST API calls which allow you to create a Dedicated Cluster using any commitment tier starting with the lowest level of 100 GB/Day.
Let’s have a look at the information you need to have at first before running the script:
- An account with at least the Log Analytics Contributor built-in role permissions
- The SKU capacity or Commitment tier you would like to use
- The subscription where you want to create the cluster
- The location in which the cluster will be created. Remember that you can log analytics workspaces to a dedicated cluster only if they are in the same region
- The resource group where to create the dedicated cluster
With this information in your hand, you can start creating the PowerShell script that:
- Ask for all the above information
- Make the connection to Azure
- Retrieve the authentication token
- Create the cluster
Not really happy with creating the above-mentioned PowerShell script? Don’t worry, I have one created for you. Here is the source code:
<#
.SYNOPSIS
This sample script is designed to ease the creation of Azure Monitor Logs Dedicated Cluster using any supported/available tier.
.DESCRIPTION
This sample script is designed to ease the creation of Azure Monitor Logs Dedicated Cluster using any supported/available tier.
It will ask for the following information during the execution:
- Subscription Id
- Resource group
- Azure Monitor Logs Dedicated Cluster name
- Azure Monitor Logs Dedicated Cluster commitment tier
Once all the necessary information has been entered, the script will log you in and retrieve a list of Azure location to deploy
the resource in. Select your preferred location from the grid to continue with the execution and resource creation.
.REQUIREMENTS
The following PowerShell modules are required:
- AZ.ACCOUNTS
- AZ.RESOURCES
.NOTES
AUTHOR: Bruno Gabrielli
LASTEDIT: March 5th, 2024
- VERSION: 1.0 // March 5th, 2024
- First version
#>
# Forcing use of TLS protocol
[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12
# Reaing input values
[string]$subscriptionId = Read-Host "Enter the subscription id"
[string]$resourceGroup = Read-Host "Enter the resource group name"
[string]$clusterName = Read-Host "Enter the Dedicated cluster name"
[string]$sku = Read-Host "Enter the Dedicated cluster commitment tier (only the size number)"
# Authenticating to Azure and setting the contex on the selected subscription
Connect-AzAccount
Set-AzContext -subscriptionId "$subscriptionId"
# Getting Azure Location where to deploy the cluster
$selectedLocation = (Get-AzLocation | Select-Object -Property DisplayName, Location | Out-GridView -OutputMode Single -Title "Select the region to deploy the resource in").Location
# Retrieving bearer token to be used for REST API call authentication
$bearerToken = (Get-AzAccessToken).Token
# Assembling body based on the input values
$body = @"
{
"identity": {
"type" : "systemAssigned"
},
"sku": {
"name" : "capacityReservation",
"Capacity" : $sku
},
"properties" : {
"billingType" : "Cluster"
},
"location" : "$selectedLocation"
}
"@
# Setting variables and costants
$method = "PUT"
$contentType = "application/json"
$headers = @{"Authorization" = "Bearer $bearerToken"}
$uri = "https://management.azure.com/subscriptions/$subscriptionId/resourcegroups/$resourceGroup/providers/Microsoft.OperationalInsights/clusters/$($clusterName)?api-version=2022-10-01"
# Create Cluster
$createResponse = Invoke-WebRequest -Uri $uri -Method $method -ContentType $contentType -Headers $headers -Body $body -UseBasicParsing
return $createResponse.StatusCode
<#
## USE THESE LINE BELOW TO CHECK FOR RESOURCE PROVISIONING STATUS
#Get cluster provisioning state
$getClusterProvisioningState = Invoke-WebRequest -Uri $uri -Method "GET" -Headers $headers -UseBasicParsing
$getClusterProvisioningStateDetails = $getClusterProvisioningState | ConvertFrom-JSON
Write-Host "Resource provisioning status == $($getClusterProvisioningStateDetails.Properties.provisioningState)"
#>
Run the script and provide the necessary information as prompted by PowerShell (in this example I am going to create a 100GB/Day instance):
Once all the information has been entered, the script will present a grid view with all the Azure regions so you can select the one you would like to use and click OK:
Script will continue with the execution and once done, return HTTP code 202 which means request accepted.
Provisioning this type of resource will require a considerable amount of time (few hours) so, from this point on, you just have to sit, relax, and wait 
. Of course, you can check every now and then the provisioning status by running the following commands from the same PowerShell prompt you just used to invoke the cluster creation:
#Get cluster provisioning state
$getClusterProvisioningState = Invoke-WebRequest -Uri $uri -Method "GET" -Headers $headers -UseBasicParsing
$getClusterProvisioningStateDetails = $getClusterProvisioningState | ConvertFrom-JSON
Write-Host "Resource provisioning status = $($getClusterProvisioningStateDetails.Properties.provisioningState)"
Once the value of provisioningState changes to Succeeded, it means that your cluster has been successfully created and you can start linking your workspaces.
REMEMBER: this script is provided AS IS, so do not forget to test it thoroughly.
Curious to see all details about your cluster including linked workspaces with their setting, data ingested by each of them, total daily ingestion for the cluster and an estimation of chargeback? We have a nice workbook for you in the Azure Monitor Workbook gallery
This is an example of how the workbook will look like:
With that said, I can only close by saying: happy linking and good saving 
Disclaimer
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.