What you need before deploying the Agent Observability data platform on Azure.

This page walks through everything you need before running the installation: the right tooling, an Azure subscription with sufficient permissions, a deployment path, a DNS zone, and the platform artifacts. Work through the steps in order, then run the preflight check to confirm you are ready.

1. Install the required tooling

Install the following on the machine you will run Terraform from:

Sign in with az login and select the target subscription before continuing. The module's provisioners shell out to az, kubelogin, and kubectl during terraform apply, so all three must be on the PATH of the machine running Terraform — not just installed for interactive use.

2. Prepare your Azure subscription

You deploy into your own Azure subscription. The principal running terraform apply needs two kinds of access on the target scope:

• Resource management — creating and managing the resource group, VNet, AKS cluster, Key Vault, managed identities, DNS records, and the Foundry account (Contributor-level access).
• Authorization writes — Microsoft.Authorization/roleDefinitions/write and Microsoft.Authorization/roleAssignments/write. The module creates a custom least-privilege role definition for the Claude evaluation backend and many role assignments (Workload Identities, Key Vault RBAC, DNS Zone Contributor, and the deployer's own AKS RBAC Cluster Admin grant).

In practice that means Owner, or Contributor plus User Access Administrator, on the subscription or target scope. Contributor alone — or Contributor plus "Role Based Access Control Administrator" — is not enough, because neither can write role definitions.

The principal that runs terraform apply is granted cluster-administrator access on the AKS cluster automatically (an "Azure Kubernetes Service RBAC Cluster Admin" role assignment), so the same credentials you deploy with can administer the cluster afterward.

The platform artifacts are public (Terraform Registry and Docker Hub), so no registry credentials are needed — only outbound access to Docker Hub: the helm provider pulls the ao-data-platform chart during apply, and the AKS nodes pull the ao-llm-worker image at runtime.

Resource providers

Make sure the following resource providers are registered in the subscription (registration is idempotent — running it again is harmless):

az provider register --namespace Microsoft.ContainerService
az provider register --namespace Microsoft.Network
az provider register --namespace Microsoft.KeyVault
az provider register --namespace Microsoft.ManagedIdentity
az provider register --namespace Microsoft.CognitiveServices

No preview-feature registrations are required — the managed Gateway API and application-routing Istio add-ons the platform uses are generally available, and the module enables them declaratively during terraform apply on clusters it creates.

Azure services the deploy uses

The table below lists the Azure services and representative operations the deploy exercises, by category. Treat it as the breadth of access the deploying principal needs, not a hand-minimized least-privilege policy.

3. Choose your deployment path

The Terraform module supports two paths. Decide which applies before configuring it:

Quotas to verify

• vCPU quota for the VM families in your region: the main pool defaults to Standard_D4s_v5 × 2 (autoscaling up to 10), each dedicated ClickHouse node is Standard_E8s_v5, and each Keeper voter is Standard_D2as_v4.
• Claude tokens-per-minute quota: the module provisions three Claude model deployments by default, each at capacity 100 (= 100,000 TPM, GlobalStandard). If that exceeds the Claude quota granted in your subscription, scope it down with helm.llm_worker.foundry.deployments / default_capacity — see the Configuration reference.
• Premium SSD v2 availability varies by region and zone — verify the target region/zone supports it, or point clickhouse_storage_class at a different StorageClass (see Storage).
• Kubernetes version: the module pins kubernetes_version = "1.35" by default — confirm it is available in your region with az aks get-versions --location <region>.

4. Configure domains and DNS

The OpenTelemetry Collector and ClickHouse are exposed as two hostnames on a single managed Gateway backed by an internal load balancer, with publicly-trusted TLS. Decide on:

• A domain for the OpenTelemetry Collector endpoint (e.g. otel.acme.com) — passed as otel_collector_domain
• A domain for the ClickHouse endpoint (e.g. clickhouse.acme.com) — passed as clickhouse_domain
• An existing Azure DNS zone covering those domains — passed as dns_zone (e.g. acme.com), plus dns_zone_resource_group_name when the zone lives in a different resource group than the platform (the common case)

The DNS zone is required whenever the module deploys the chart — there is no manual-DNS or self-signed fallback. cert-manager issues publicly-trusted Let's Encrypt certificates via DNS-01 validation against the zone, and external-dns publishes the two hostnames automatically; the module grants both identities DNS Zone Contributor scoped to the zone. "Publicly trusted" describes the certificate chain (clients need no private CA) — the endpoints themselves stay on a private IP, reached over VNet, peering, or VPN connectivity.

Optionally set gateway.letsencrypt_email as the ACME contact address — omit it for a contactless account (certificates still auto-renew).

5. Get the platform artifacts

All three artifacts are public — no Monte Carlo-issued credentials or registry login are required:

You don't fetch these by hand: terraform init pulls the module from the Registry, the helm provider pulls the chart during terraform apply, and the AKS nodes pull the image at runtime. You set the chart registry and version (and pin the image tag) as module inputs on the installation page.

6. Run the preflight check

Confirm your environment is ready. Each command below should succeed before you proceed to installation:

# Terraform is installed and >= 1.3
terraform version

# Azure credentials resolve to the target subscription
az account show

# kubectl and kubelogin are installed (server check comes after the cluster exists)
kubectl version --client
kubelogin --version

# The DNS zone resolves in its resource group
az network dns zone show --resource-group <dns_zone_resource_group_name> --name <dns_zone>

# The pinned Kubernetes version is available in the region
az aks get-versions --location <region> --output table

# Optional: confirm you can reach the public chart on Docker Hub (no login required)
helm pull oci://registry-1.docker.io/montecarlodata/ao-data-platform --version 4.0.0

If az account show returns the wrong subscription, or terraform version reports below 1.3, fix those before continuing.

Next steps

Continue to Installation.