Azure CDN Endpoint Has No Diagnostic Logging: Why It Matters and How to Fix It

Azure CDN endpoints sit at the edge of your application, handling traffic before it ever reaches your origin. They cache content, terminate TLS, and absorb a large share of inbound requests. That makes them one of the most valuable sources of observability in your environment, and also one of the most commonly overlooked. The cdn_nologging check catches CDN endpoints that have no diagnostic settings configured at all, meaning none of that traffic data is being recorded.

If an endpoint has no diagnostic logging, you are flying blind. You have no record of who requested what, no visibility into cache hit ratios, and no audit trail when something goes wrong. This post explains what the check looks for, why an unlogged CDN is a real problem, and how to fix and prevent it.

---

What this check detects

The check inspects each Azure CDN endpoint and verifies whether a diagnostic setting is attached. Diagnostic settings are the mechanism Azure uses to route platform logs and metrics to a destination. For a CDN endpoint, these include access logs (every request that hits the endpoint), health probe logs, and metrics like request count, byte count, and response status distribution.

When no diagnostic setting exists, Azure still serves traffic normally, but it discards the telemetry. There is no default retention, no backfill, and no way to recover logs for a period when logging was off. The check fails for any endpoint where the diagnostic settings collection is empty.

---

Why it matters

A CDN endpoint without logs creates gaps across security, operations, and compliance. Here is where it actually hurts.

You cannot investigate an attack

CDN endpoints are a frequent target for layer 7 attacks: credential stuffing against login paths, scraping, and HTTP floods. When an attack happens, the first question is always "what did the traffic look like?" Access logs tell you the source IPs, requested paths, user agents, and response codes. Without them, you cannot tell a legitimate traffic spike from a distributed attack, and you cannot build a blocklist or a WAF rule based on real patterns.

You lose your incident audit trail

If your application served a malicious response, leaked content from a misconfigured cache, or had an origin breach, the CDN logs are often the only place that captures the full request history at the edge. Origin logs miss everything served from cache. No CDN logging means no answer to "was this data accessed, and by whom?"

You cannot tune performance or cost

Cache hit ratio is the single biggest lever for CDN cost and performance. Without metrics and logs you cannot see which paths bypass the cache, which content is being re-fetched from origin unnecessarily, or where you are paying for egress that a cache rule could eliminate.

---

How to fix it

The fix is to attach a diagnostic setting that routes the endpoint's logs and metrics to a destination. You have three destination options, and you can use more than one at the same time:

• Log Analytics workspace for querying with KQL and alerting. This is the right choice for active investigation.
• Storage account for cheap long-term archival to meet retention requirements.
• Event Hub for streaming to a SIEM or third-party platform.

Option 1: Azure Portal

1. Open your CDN profile and select the endpoint.
2. Under Monitoring, choose Diagnostic settings.
3. Click Add diagnostic setting.
4. Give it a name, then tick the log categories (CoreAnalytics / AzureCdnAccessLog depending on the SKU) and AllMetrics.
5. Select a destination, for example Send to Log Analytics workspace, and pick the workspace.
6. Save.

Option 2: Azure CLI

First grab the resource IDs you need. Replace the placeholder names with your own.

RG="my-resource-group"
PROFILE="my-cdn-profile"
ENDPOINT="my-endpoint"
WORKSPACE="my-log-analytics-workspace"

# Endpoint resource ID
ENDPOINT_ID=$(az cdn endpoint show \
  --resource-group "$RG" \
  --profile-name "$PROFILE" \
  --name "$ENDPOINT" \
  --query id -o tsv)

# Log Analytics workspace resource ID
WORKSPACE_ID=$(az monitor log-analytics workspace show \
  --resource-group "$RG" \
  --workspace-name "$WORKSPACE" \
  --query id -o tsv)

Now create the diagnostic setting:

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

Option 3: Terraform

If you manage your CDN in Terraform, define the diagnostic setting alongside the endpoint so it is created and tracked as code.

resource "azurerm_monitor_diagnostic_setting" "cdn" {
  name                       = "cdn-diagnostics"
  target_resource_id         = azurerm_cdn_endpoint.this.id
  log_analytics_workspace_id = azurerm_log_analytics_workspace.this.id

  enabled_log {
    category = "CoreAnalytics"
  }

  metric {
    category = "AllMetrics"
    enabled  = true
  }
}

---

How to prevent it from happening again

Fixing one endpoint by hand does not stop the next one from shipping without logging. Make the control enforce itself.

Azure Policy

Azure ships a built-in policy, "Configure diagnostic settings for CDN endpoints to Log Analytics workspace", with a DeployIfNotExists effect. Assigned at the subscription or management group level, it automatically attaches a diagnostic setting to any CDN endpoint that lacks one, including new ones.

az policy assignment create \
  --name "cdn-diag-logging" \
  --display-name "CDN endpoints must have diagnostic logging" \
  --policy "" \
  --scope "/subscriptions/" \
  --location "eastus" \
  --mi-system-assigned \
  --params '{"logAnalytics":{"value":""}}'

CI/CD gate

If you provision infrastructure through pipelines, block any CDN endpoint that is missing a diagnostic setting before it merges. Tools like Checkov, tfsec, or a custom OPA policy can scan Terraform plans. A simple gate: fail the build if an azurerm_cdn_endpoint resource has no associated azurerm_monitor_diagnostic_setting pointing at it.

Continuous detection

Policy and pipeline checks cover the resources you create. Console-created endpoints, resources from acquired teams, or drift from manual changes slip through. Running the cdn_nologging check continuously in Lensix surfaces any endpoint that loses its diagnostic setting, regardless of how it was created.

---

Best practices

• Log every internet-facing edge resource by default. CDN endpoints, Front Door, Application Gateway, and load balancers should all have diagnostic settings as part of their baseline, not as an afterthought.
• Centralize destinations. Send logs to a small number of well-governed Log Analytics workspaces rather than one per resource. It makes cross-resource queries and alerting far easier.
• Set retention deliberately. Match your retention to the longest requirement you are bound by, whether that is a regulatory mandate or your own incident response window, and use storage tiering to keep the cost reasonable.
• Alert on the signal, not just the storage. Logs you never look at help no one. Build at least a couple of alerts on top of CDN metrics, for example a sudden spike in 4xx or 5xx responses, or a collapse in cache hit ratio.
• Review log coverage periodically. SKUs change, endpoints get recreated, and policies get unassigned. Treat logging coverage as something you verify on a schedule, not set once and forget.

Diagnostic logging on a CDN endpoint is cheap to enable and impossible to backfill. Turn it on everywhere, enforce it with policy, and you will have the data you need on the day you actually need it.