CDN Endpoint Has No Diagnostic Settings: Azure Logging Gaps Explained

CDN endpoints sit at the very edge of your application, fielding traffic from users you've never seen and from bots you'd rather never meet. They terminate TLS, cache your content, and absorb the first wave of any traffic spike or attack. Yet they are routinely the least monitored part of the stack. If an Azure CDN endpoint has no diagnostic settings, every request that flows through it vanishes the moment it's served. There is no log to query when something goes wrong, and nothing to feed your alerting.

This Lensix check, monitor_cdnnodiagnostics, catches exactly that gap: an Azure CDN endpoint with no diagnostic settings configured.

---

What this check detects

Azure CDN (and its successor, Azure Front Door, which shares the same diagnostic model) can emit two broad categories of telemetry through diagnostic settings:

• CoreAnalytics metrics, which cover request counts, byte transfers, cache hit ratios, and HTTP status code breakdowns.
• Access logs, which record individual requests with client IP, requested URI, response status, and cache result.

The check looks at each CDN endpoint resource and verifies that at least one diagnostic setting exists, routing those categories to a destination. The valid destinations are a Log Analytics workspace, a storage account, or an event hub. When no diagnostic setting is attached, the endpoint is generating telemetry that goes nowhere and is discarded.

---

Why it matters

The absence of CDN logs becomes a real problem at the exact moment you need them most: during an incident.

You lose visibility into edge attacks

CDNs are a common target and vector for abuse. A credential-stuffing campaign, a scraping bot, or a Layer 7 flood often shows up first as anomalous patterns at the edge: a spike in 403s, a flood of requests to a single URI, or a sudden collapse in cache hit ratio as an attacker forces origin fetches with randomized query strings. Without access logs you cannot see the client IPs, the targeted paths, or the request volume, so you cannot build a blocklist or tune your WAF rules.

Origin overload goes unexplained

When cache hit ratios drop, your origin starts absorbing traffic it was never sized for. CoreAnalytics metrics tell you whether requests are being served from cache or hitting the backend. If you skip diagnostics, an origin outage caused by a cache-busting pattern looks like a mysterious backend failure with no trail leading back to the CDN.

Compliance and forensics gaps

Frameworks like PCI DSS, SOC 2, and ISO 27001 expect you to log access to systems handling sensitive traffic. A CDN that serves authenticated content or sits in front of a payment flow is in scope. If an auditor asks who accessed a resource and when, "we don't log the edge" is not an answer that passes.

---

How to fix it

You need to create a diagnostic setting on the CDN endpoint and point it at a destination. The most common choice is a Log Analytics workspace, because it lets you query the data with KQL and connect it to alerts.

Option 1: Azure portal

1. Open the CDN profile, then select the endpoint you want to configure.
2. In the left menu, under Monitoring, choose Diagnostic settings.
3. Click Add diagnostic setting.
4. Give it a name, for example cdn-to-loganalytics.
5. Under Logs, check CoreAnalytics (and access logs if listed for your SKU).
6. Under Destination details, tick Send to Log Analytics workspace and pick your workspace.
7. Click Save.

Option 2: Azure CLI

First, gather the resource IDs you need. The CDN endpoint ID and the destination workspace ID are both required.

# Get the CDN endpoint resource ID
ENDPOINT_ID=$(az cdn endpoint show \
  --resource-group my-rg \
  --profile-name my-cdn-profile \
  --name my-endpoint \
  --query id -o tsv)

# Get the Log Analytics workspace resource ID
WORKSPACE_ID=$(az monitor log-analytics workspace show \
  --resource-group monitoring-rg \
  --workspace-name central-logs \
  --query id -o tsv)

Now create the diagnostic setting:

az monitor diagnostic-settings create \
  --name cdn-to-loganalytics \
  --resource "$ENDPOINT_ID" \
  --workspace "$WORKSPACE_ID" \
  --logs '[{"category":"CoreAnalytics","enabled":true}]'

Option 3: Terraform

If you manage infrastructure as code, define the diagnostic setting alongside the endpoint so it can never drift out of existence.

resource "azurerm_monitor_diagnostic_setting" "cdn" {
  name                       = "cdn-to-loganalytics"
  target_resource_id         = azurerm_cdn_endpoint.this.id
  log_analytics_workspace_id = azurerm_log_analytics_workspace.central.id

  enabled_log {
    category = "CoreAnalytics"
  }
}

---

How to prevent it from happening again

Fixing one endpoint by hand does not stop the next team from spinning up a CDN without diagnostics. Bake the requirement into your platform so it is enforced automatically.

Azure Policy with DeployIfNotExists

Azure ships built-in policy definitions that deploy diagnostic settings to Log Analytics when they are missing. Assign the relevant one at the subscription or management group scope. The DeployIfNotExists effect will remediate existing endpoints and configure new ones automatically.

az policy assignment create \
  --name cdn-diagnostics-required \
  --scope "/subscriptions/" \
  --policy "" \
  --location eastus \
  --mi-system-assigned \
  --role Contributor \
  --identity-scope "/subscriptions/" \
  --params '{"logAnalytics":{"value":""}}'

CI/CD gates on your IaC

If you provision CDN endpoints through Terraform or Bicep, add a check in your pipeline that rejects any plan creating an azurerm_cdn_endpoint without an accompanying azurerm_monitor_diagnostic_setting. Tools like Checkov, tfsec, and Conftest let you write this as a policy that runs before merge, so the gap never reaches production.

Continuous detection with Lensix

Policy and pipeline gates catch new resources, but settings get deleted, scopes get excluded, and policies get disabled. Lensix runs monitor_cdnnodiagnostics continuously across your subscriptions so a diagnostic setting that disappears tomorrow gets flagged tomorrow, not at the next audit.

---

Best practices

• Send logs to a workspace, not just a storage account. Storage is fine for cheap long-term retention, but you cannot query it directly. Log Analytics gives you KQL, alerts, and dashboards. Many teams send to both: storage for retention, workspace for analysis.
• Set retention deliberately. Decide how long you need CDN data based on your compliance and forensic needs, then configure retention on the workspace or an archive tier. Default retention is rarely long enough for an investigation that starts weeks after the fact.
• Build alerts on top of the data. Logs you never look at are only marginally better than no logs. Create alerts for sudden drops in cache hit ratio, surges in 4xx or 5xx responses, and unusual request volume from single IP ranges.
• Apply the same standard to Front Door. If you are migrating from classic CDN to Azure Front Door, carry the diagnostic settings over. The categories differ, but the principle is identical: no endpoint goes live without its telemetry wired up.
• Treat diagnostics as part of the resource definition. A CDN endpoint without logging is incomplete, the same way a server without monitoring is incomplete. Keep the diagnostic setting in the same IaC module as the endpoint so the two are always deployed and destroyed together.