Challenge with Azure Log Analytics Workspace (LAW) and LACluster SKU in Automated Workflow

Abhishek Arya 0 Reputation points Microsoft Employee
2025-03-21T16:36:18.1233333+00:00

We are implementing an Azure monitoring solution for one of our customers. The architecture requires that the Log Analytics Workspace (LAW) be configured with the LACluster SKU and linked to a dedicated cluster for log ingestion.

Issue: Initial Deployment Constraints

  1. When provisioning the LAW for the first time with SKU set to LACluster, the deployment fails because the workspace is not yet linked to a cluster.
  2. However, if we initially set the SKU to Pay-As-You-Go (PAYG), the deployment succeeds, allowing us to link the workspace to the dedicated cluster.
  3. After 2-3 hours, the workspace automatically upgrades its SKU from Pay-As-You-Go to LACluster as expected.

Issue: Subsequent Workflow Runs

  1. When running the workflow again, the deployment fails because the LAW is now linked to the cluster.
  2. The error states that the SKU cannot be changed back to Pay-As-You-Go since the workspace is already associated with a cluster.
  3. A workaround is to modify the SKU dynamically in the parameter file before the second run (i.e., set it to LACluster instead of Pay-As-You-Go), but the customer does not want parameter file modifications.

Question

How can we handle this scenario in an automated deployment workflow while ensuring:

  • The initial deployment succeeds without manual intervention.
  • The workflow runs successfully on subsequent deployments without modifying the parameter file.
  • The SKU remains compliant with LACluster without breaking the deployment process.

Would appreciate insights on best practices to handle this within Bicep or Terraform while maintaining idempotency in Azure Infrastructure as Code. 🚀We are implementing an Azure monitoring solution for one of our customers. The architecture requires that the Log Analytics Workspace (LAW) be configured with the LACluster SKU and linked to a dedicated cluster for log ingestion.

Issue: Initial Deployment Constraints

  1. When provisioning the LAW for the first time with SKU set to LACluster, the deployment fails because the workspace is not yet linked to a cluster.
  2. However, if we initially set the SKU to Pay-As-You-Go (PAYG), the deployment succeeds, allowing us to link the workspace to the dedicated cluster.
  3. After 2-3 hours, the workspace automatically upgrades its SKU from Pay-As-You-Go to LACluster as expected.

Issue: Subsequent Workflow Runs

  1. When running the workflow again, the deployment fails because the LAW is now linked to the cluster.
  2. The error states that the SKU cannot be changed back to Pay-As-You-Go since the workspace is already associated with a cluster.
  3. A workaround is to modify the SKU dynamically in the parameter file before the second run (i.e., set it to LACluster instead of Pay-As-You-Go), but the customer does not want parameter file modifications.

Question

How can we handle this scenario in an automated deployment workflow while ensuring:

  • The initial deployment succeeds without manual intervention.
  • The workflow runs successfully on subsequent deployments without modifying the parameter file.
  • The SKU remains compliant with LACluster without breaking the deployment process.

Would appreciate insights on best practices to handle this within Bicep while maintaining idempotency in Azure Infrastructure as Code.

Azure Monitor
Azure Monitor
An Azure service that is used to collect, analyze, and act on telemetry data from Azure and on-premises environments.
3,572 questions
{count} votes

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.