> For the complete documentation index, see [llms.txt](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/integrations/connectivity/insight-point/azure.md).

# Deploy with Azure Container Instances

Instructions for running an Insight Point as a Docker container using an Azure container instance.

Veza recommends deploying an Insight Point within Microsoft Azure for a secure connection to [PostgreSQL for Azure Database](/4yItIzMvkpAvMVFAamTf/integrations/integrations/azure/azure-postgresql.md) resources. This document includes instructions to run an Insight Point with an Azure Container Instance.

{% hint style="info" %}
**Portal vs. YAML deployment:** The Azure portal wizard covers basic container setup. If you need to configure custom DNS servers so the Insight Point can resolve private hostnames in your VNet, you must deploy using a YAML file. This setting is not available in the portal. See [Deploy with YAML](#deploy-with-yaml) below.
{% endhint %}

#### Step 1: Create a Container Instance resource

Log in to your Azure Tenant and go to [Container Instances](https://portal.azure.com/#view/HubsExtension/BrowseResource/resourceType/Microsoft.ContainerInstance%2FcontainerGroups). Create a new resource:

![Click "Create" to add a Container Instance.](https://1967633068-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MZDkWMxox3pekd0NsZJ%2Fuploads%2Fgit-blob-ad7043dacd3ded5f6806d04b50b08adf04ba7ab7%2Fazure-create-resource.png?alt=media)

#### Step 2: Configure the container specifications

In the creation wizard, configure the container to meet the [Insight Point system requirements](/4yItIzMvkpAvMVFAamTf/integrations/connectivity/insight-point.md#system-requirements):

1. **Size**: Ensure the container instance has at least 2 CPU cores and 4 GB memory allocated
2. **Image Source**: Select **Other registry** and add the path to Insight Point image: `public.ecr.aws/veza/insight_point:latest`. To pull from a different registry, such as a mirror or private registry, or your Veza tenant's own registry domain (a mirror hosted by Veza), set this to your image reference instead; see [Pulling Insight Point images from your tenant domain](/4yItIzMvkpAvMVFAamTf/integrations/connectivity/insight-point/insight-point-tenant-registry.md) for options and prerequisites.

![Specify the Veza public repository.](https://1967633068-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MZDkWMxox3pekd0NsZJ%2Fuploads%2Fgit-blob-e8ad2f2c003f1dc65b560f151efffc59a94611d9%2Fazure-create-instance.png?alt=media)

#### Step 3: Assign an appropriate virtual network

Add the Insight Point to the virtual network. Choose **Private** and enter the virtual network assigned to other resources the Insight Point will connect to:

![Configure virtual network.](https://1967633068-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MZDkWMxox3pekd0NsZJ%2Fuploads%2Fgit-blob-b595a3a2256276a7156a8835c49bc3909e6ce990%2Fazure-add-instance-subnet.png?alt=media)

#### Step 3a: Configure VNet DNS (Required for Private Network Integrations)

{% hint style="warning" %}
Azure Container Instances do **not** automatically inherit the DNS server configuration from the attached VNet. The container will use Azure's default resolver (`168.63.129.16`), which cannot resolve private hostnames or internal service endpoints. If your integrations target resources using private DNS names, you must explicitly set the DNS configuration.
{% endhint %}

DNS configuration is not available through the Azure portal. You must deploy the container using a YAML file (via Azure CLI) or an ARM template. See [Deploy with YAML](#deploy-with-yaml) for a complete template.

To add DNS configuration to your YAML deployment file, include a `dnsConfig` section in the container group properties:

```yaml
dnsConfig:
  nameServers:
    - 10.0.0.10        # IP address of your VNet's DNS server or forwarder
  searchDomains: internal.example.com   # Optional: DNS search suffix for short-name resolution
```

**Important:** Configure a single DNS server (your VNet's DNS forwarder), not a list of multiple servers. The Insight Point container uses musl-libc for DNS resolution, which sends queries to all listed nameservers simultaneously and uses the first response. This behavior can produce intermittent failures when multiple servers are listed. If you need fallback to Azure DNS, configure your forwarder to forward unresolved queries to `168.63.129.16`.

**NSG requirement:** The subnet hosting the ACI container must allow outbound TCP and UDP traffic on port 53 to the DNS server address.

#### Step 4: Configure the Registration Key & Instance ID

In the advanced settings, configure the Insight Point registration key:

1. Navigate to the **Advanced** tab.
2. In the **Environment Variables** section, add the Insight Point provisioning key to the `DP_REGISTER_KEY` variable.
3. To generate a new registration key, visit the **Integrations -> Insight Point** page in the Veza console.
4. (Optional) For High Availability deployments, add a unique `DP_INSTANCE_ID` variable to distinguish this instance from others.

![Specify the registration key.](https://1967633068-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MZDkWMxox3pekd0NsZJ%2Fuploads%2Fgit-blob-10f1590daca09acabc770e28b7815346af8ee2a5%2Fazure-add-reg-key.png?alt=media)

#### Step 4a: Configure Webhook Relay (Optional)

If you need to send webhooks to destinations in your private network, you can enable webhook relay. For an overview of webhook relay, when to use it, security considerations, and supported host formats, see [Webhook Relay](/4yItIzMvkpAvMVFAamTf/integrations/connectivity/insight-point.md#webhook-relay) in the main Insight Point documentation.

To configure webhook relay during Azure Container Instance deployment:

1. Still in the **Advanced** tab's **Environment Variables** section, add the following variables:
   * **Name**: `WEBHOOK_RELAY_ENABLED`, **Value**: `true`
   * **Name**: `WEBHOOK_RELAY_ALLOWED_HOSTS`, **Value**: comma-separated list of allowed destinations (e.g., `webhook.site,*.example.com,172.17.0.0/24`)

Confirm your settings by clicking **Review + create**, then deploy the container by selecting **Create**.

#### Step 4b: Configure Tags (Optional)

Tags are custom key-value labels that help organize and categorize your Insight Point instances. For an overview of tags, their use cases, and requirements, see [Tags](/4yItIzMvkpAvMVFAamTf/integrations/connectivity/insight-point.md#tags) in the main Insight Point documentation.

To configure tags during Azure Container Instance deployment:

1. Still in the **Advanced** tab's **Environment Variables** section, add the following variable:
   * **Name**: `INSIGHT_POINT_TAGS`
   * **Value**: comma-separated list of key:value pairs (e.g., `environment:production,datacenter:us-west-1,team:platform-engineering`)

#### Deploy with YAML

For deployments requiring custom DNS or other network configuration, use the Azure CLI with a YAML file. The following template covers a complete Insight Point deployment:

```yaml
apiVersion: "2021-10-01"
location: eastus                          # Replace with your Azure region
name: insight-point                       # Container group name

properties:
  containers:
    - name: insight-point
      properties:
        image: public.ecr.aws/veza/insight_point:latest
        resources:
          requests:
            cpu: 2.0                      # Minimum: 2 CPU cores
            memoryInGB: 4.0               # Minimum: 4 GB memory
        environmentVariables:
          - name: DP_REGISTER_KEY
            secureValue: "<your-registration-key>"   # From Veza console: Integrations > Insight Point
          - name: DP_INSTANCE_ID
            value: "insight-point-prod-1"            # Optional: required for high-availability deployments

  # Assign the container to your private VNet subnet
  subnetIds:
    - id: /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Network/virtualNetworks/<vnet-name>/subnets/<subnet-name>

  # Override DNS: required if integrations target private hostnames
  dnsConfig:
    nameServers:
      - 10.0.0.10                         # Your VNet's DNS forwarder IP
    searchDomains: internal.example.com   # Optional: DNS search suffix

  ipAddress:
    type: Private

  osType: Linux
  restartPolicy: Always
```

Deploy the container group using the Azure CLI:

```bash
az container create --resource-group <resource-group> --file insight-point-aci.yaml
```

To check deployment status:

```bash
az container show --resource-group <resource-group> --name insight-point --query "instanceView.state"
```

#### Step 5: Update the Azure integration to use the Insight Point

Finally, update the integration configuration in Veza so that the connection is made using the new Insight Point, instead of the Veza SaaS platform:

1. Log in to Veza, go to the **Integrations** page, and find the Azure integration on the list of providers.
2. Click **Edit** to open the configuration.
3. Change the **Insight Point** from (default) to the one you created.
4. **Save** the integration.

***

## Troubleshooting

### Integration fails with DNS error after Insight Point shows green

**Symptom:** The Insight Point status shows **OK** in Veza, but running an integration sync fails with a DNS resolution error.

**Cause:** The container is not using your VNet's DNS servers. ACI defaults to Azure's public resolver (`168.63.129.16`), which cannot resolve private hostnames for resources inside your VNet (such as Azure Database for PostgreSQL with private endpoints).

**Fix:** Add a `dnsConfig` block to your YAML deployment file pointing to your VNet's DNS forwarder, then redeploy. See [Step 3a](#step-3a-configure-vnet-dns-required-for-private-network-integrations) for the required YAML structure.

**Verify:** The Insight Point container does not include a shell, so you cannot inspect `/etc/resolv.conf` directly using `az container exec`. To confirm DNS is resolving correctly:

* Deploy a test VM in the same subnet and verify it can resolve the target hostnames using your configured DNS server.
* Check Azure container logs for DNS-related errors: `az container logs --resource-group <RG> --name insight-point`

### Common DNS issues

| Symptom                                      | Likely cause                | Resolution                                                                                |
| -------------------------------------------- | --------------------------- | ----------------------------------------------------------------------------------------- |
| All DNS queries fail                         | NSG blocks port 53          | Allow outbound TCP/UDP port 53 from the ACI subnet to the DNS server                      |
| Private hostnames fail, public names resolve | VNet DNS not configured     | Add `dnsConfig.nameServers` to YAML deployment                                            |
| Azure Private DNS zone names not resolving   | Zone not linked to VNet     | Link the private DNS zone to the VNet: `az network private-dns link vnet create`          |
| Intermittent DNS failures                    | Multiple nameservers listed | Use a single DNS forwarder; configure it to forward unresolved queries to `168.63.129.16` |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/integrations/connectivity/insight-point/azure.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
