Where is the request from in Azure app configuration

Hello @Tinney, Xinran [EMR/ENT/AUS]

The Total Requests metric on the portal is an aggregated counter — it records that requests happened, but carries no caller dimension (no IP, no identity). Caller information is available only through diagnostic resource logs, which are disabled by default on every new store and do not collect retroactively. For that reason, those 3 requests already shown cannot be attributed — no record of them was retained.

On a brand-new store with no consuming code deployed, the most likely source is your own portal activity. Opening Configuration explorer or Feature manager reads key-values over the same data-plane API your application would use, so those reads are counted. Three requests is consistent with a few blade loads. Please note this last point is an inference — Microsoft does not publish a figure for portal-generated traffic — but the steps below let you confirm it directly.

Resolution

Step 1 — Enable diagnostic logging Navigate to your App Configuration store → Monitoring → Diagnostic settings → + Add diagnostic setting. Enter a name, select the HTTP Requests and Audit categories, and choose Send to Log Analytics workspace (recommended in the documentation over storage account or event hub). Verification: The new setting is listed on the Diagnostic settings page after saving.

Step 2 — Generate a known request and confirm capture Open the Configuration explorer or Feature manager blade two or three times, wait a few minutes, then run the following in Log Analytics:

AACHttpRequest
| where TimeGenerated > ago(1h)
| project TimeGenerated, Method, RequestURI, StatusCode,
          ClientObjectId, ClientTenantId, AccessKeyId,
          ClientIPAddress, UserAgent, HitCount
| sort by TimeGenerated desc

Verification: Your own IP appears in ClientIPAddress and your browser string in UserAgent, confirming the source of the original 3 requests.

Step 3 — Identify any other consumers Leave logging enabled for 24–72 hours, then run:

AACHttpRequest
| where TimeGenerated > ago(3d)
| summarize requestCount=sum(HitCount) by ClientIPAddress
| order by requestCount desc

Verification: Only IPs you recognise are listed, and the count remains flat during periods when nobody is using the portal.

Additional information

• Caller identity depends on your authentication method. With Microsoft Entra ID, ClientObjectId and ClientTenantId identify the caller. With access keys, AccessKeyId indicates which key was used.
• HTTP Request logs are aggregated (note the HitCount field; some per-request detail is lost in aggregation). Audit logs are not aggregated, so for write operations such as creating your flag, AACAudit provides a cleaner one-row-per-action record including CallerIdentity and CallerIPAddress.
• Once your application is live, the request count will rise — this is expected, as App Configuration clients poll for configuration refresh. The value worth monitoring is HTTP 429 (throttling).

References

• Monitor Azure App Configuration — https://learn.microsoft.com/en-us/azure/azure-app-configuration/monitor-app-configuration
• AACHttpRequest table reference — https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/AACHttpRequest
• AACAudit table reference — https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/AACAudit

If you enable logging and still observe requests you cannot account for, please share the UserAgent and ClientIPAddress values returned by the Step 2 query — the user agent string typically identifies the SDK and language, which usually names the caller directly.

Please let me know if you have any further questions. If this answer was helpful, kindly Accept and Upvote it so that other community members can benefit from it.The Total Requests metric on the portal is an aggregated counter — it records that requests happened, but carries no caller dimension (no IP, no identity). Caller information is available only through diagnostic resource logs, which are disabled by default on every new store and do not collect retroactively. For that reason, those 3 requests already shown cannot be attributed — no record of them was retained.

On a brand-new store with no consuming code deployed, the most likely source is your own portal activity. Opening Configuration explorer or Feature manager reads key-values over the same data-plane API your application would use, so those reads are counted. Three requests is consistent with a few blade loads. Please note this last point is an inference — Microsoft does not publish a figure for portal-generated traffic — but the steps below let you confirm it directly.

Resolution

Step 1 — Enable diagnostic logging Navigate to your App Configuration store → Monitoring → Diagnostic settings → + Add diagnostic setting. Enter a name, select the HTTP Requests and Audit categories, and choose Send to Log Analytics workspace (recommended in the documentation over storage account or event hub). Verification: The new setting is listed on the Diagnostic settings page after saving.

Step 2 — Generate a known request and confirm capture Open the Configuration explorer or Feature manager blade two or three times, wait a few minutes, then run the following in Log Analytics:

AACHttpRequest
| where TimeGenerated > ago(1h)
| project TimeGenerated, Method, RequestURI, StatusCode,
          ClientObjectId, ClientTenantId, AccessKeyId,
          ClientIPAddress, UserAgent, HitCount
| sort by TimeGenerated desc

Verification: Your own IP appears in ClientIPAddress and your browser string in UserAgent, confirming the source of the original 3 requests.

Step 3 — Identify any other consumers Leave logging enabled for 24–72 hours, then run:

AACHttpRequest
| where TimeGenerated > ago(3d)
| summarize requestCount=sum(HitCount) by ClientIPAddress
| order by requestCount desc

Verification: Only IPs you recognise are listed, and the count remains flat during periods when nobody is using the portal.

Additional information

• Caller identity depends on your authentication method. With Microsoft Entra ID, ClientObjectId and ClientTenantId identify the caller. With access keys, AccessKeyId indicates which key was used.
• HTTP Request logs are aggregated (note the HitCount field; some per-request detail is lost in aggregation). Audit logs are not aggregated, so for write operations such as creating your flag, AACAudit provides a cleaner one-row-per-action record including CallerIdentity and CallerIPAddress.
• Once your application is live, the request count will rise — this is expected, as App Configuration clients poll for configuration refresh. The value worth monitoring is HTTP 429 (throttling).

References

• Monitor Azure App Configuration — https://learn.microsoft.com/en-us/azure/azure-app-configuration/monitor-app-configuration
• AACHttpRequest table reference — https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/AACHttpRequest
• AACAudit table reference — https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/AACAudit

If you enable logging and still observe requests you cannot account for, please share the UserAgent and ClientIPAddress over private messages values returned by the Step 2 query — the user agent string typically identifies the SDK and language, which usually names the caller directly.