Access issue for ADX cluster alert

Ian Joynson-Crosby 0 Reputation points

Good day, I have a set of "Log search alert rules" which run successfully right now. Currently the cluster has "Enabled from all networks" selected under Networking.

I am now tightening up security of the cluster and now have "Enabled from selected IP addresses" selected. I have added the IP addresses I want and included in that list are the service tag ip's. I have also selected the following service tags from the drop down: AzureMonitor, KustoAnalytics, AzureResourceManager, ActionGroup (amongst others to try and fix the issue I am seeing). But essentially, now with the restrictions in place, I am getting a gateway timeout (429) code. If I switch back to "Enabled from all networks" the queries work once more. It's a right head scratcher.

I have been on this issue for a couple of days now and I am getting the feeling I may have to revert back to public access but thought to check here in case there is someone who has come across this issue in the past and managed to solve.

A crude shortened example for one of the alerts is as follows (obviously specific connection details have been amended):

adx('https://clustername.region.kusto.windows.net/DBNAME').TableName
| where Timestamp > ago(1d)
  1. Pilladi Padma Sai Manisha 10,190 Reputation points • Microsoft External Staff • Moderator

    Hi Ian Joynson-Crosby,
    Thankyou for reaching out microsoft Q&A!
    For your scenario, the most reliable way to make alert rules work with restricted network access is to move away from IP-based allow lists and use Private connectivity.

    I’d recommend configuring a Private Endpoint (Private Link) for your ADX cluster and ensuring Azure Monitor can resolve and reach the cluster via private DNS. This setup avoids dependency on changing outbound IP ranges and keeps your alerts working consistently while maintaining a locked-down posture.

    If Private Link isn’t an option right now, the practical alternative is to keep public access enabled and secure the cluster using Azure AD (RBAC) and database-level permissions, rather than relying on IP restrictions.

    You can review the official guidance here:

    https://learn.microsoft.com/azure/data-explorer/security-network-private-endpoint

    https://learn.microsoft.com/azure/azure-monitor/alerts/alerts-log

    This approach tends to be the most stable for alerting scenarios.

  2. Ian Joynson-Crosby 0 Reputation points

    I do have a private endpoint but the queries are still timing out.

Sign in to comment
Sign in to answer

Your answer