I’m working on an Azure Function that integrates with an Event Grid Subscription to receive notifications whenever a new Azure resource is created. I’ve successfully set up the Event Grid Subscription and connected it to the Azure Function. My goal is to filter the events so that I only receive notifications for the creation of resource groups and storage accounts. Here’s what I’ve done so far:
- I created the Event Grid Subscription and used the following event type to capture only write events:
Resource Write Success
- I applied filters to target only the creation of resource groups and storage accounts by using these filters:
Microsoft.Resources/subscriptions/resourceGroups/write
Microsoft.Storage/storageAccounts/write
However, the problem I’m encountering is that the subscription is fetching both create and update events, and they appear identical, both follows the same response as below and described in Microsoft Docs:
[{
"subject": "/subscriptions/{subscription-id}/resourcegroups/{resource-group}/providers/Microsoft.Storage/storageAccounts/{storage-name}",
"topic": "/subscriptions/{subscription-id}",
"type": "Microsoft.Resources.ResourceWriteSuccess",
"time": "2018-07-19T18:38:04.6117357Z",
"id": "4db48cba-50a2-455a-93b4-de41a3b5b7f6",
"data": {
"authorization": {
"scope": "/subscriptions/{subscription-id}/resourcegroups/{resource-group}/providers/Microsoft.Storage/storageAccounts/{storage-name}",
"action": "Microsoft.Storage/storageAccounts/write",
"evidence": {
"role": "Subscription Admin"
}
},
"claims": {
"aud": "{audience-claim}",
"iss": "{issuer-claim}",
"iat": "{issued-at-claim}",
"nbf": "{not-before-claim}",
"exp": "{expiration-claim}",
"_claim_names": "{"groups":"src1"}",
"_claim_sources": "{"src1":{"endpoint":"{URI}"}}",
"http://schemas.microsoft.com/claims/authnclassreference": "1",
"aio": "{token}",
"http://schemas.microsoft.com/claims/authnmethodsreferences": "rsa,mfa",
"appid": "{ID}",
"appidacr": "2",
"http://schemas.microsoft.com/2012/01/devicecontext/claims/identifier": "{ID}",
"e_exp": "{expiration}",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname": "{last-name}",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname": "{first-name}",
"ipaddr": "{IP-address}",
"name": "{full-name}",
"http://schemas.microsoft.com/identity/claims/objectidentifier": "{ID}",
"onprem_sid": "{ID}",
"puid": "{ID}",
"http://schemas.microsoft.com/identity/claims/scope": "user_impersonation",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier": "{ID}",
"http://schemas.microsoft.com/identity/claims/tenantid": "{ID}",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name": "{user-name}",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn": "{user-name}",
"uti": "{ID}",
"ver": "1.0"
},
"correlationId": "{ID}",
"resourceProvider": "Microsoft.Storage",
"resourceUri": "/subscriptions/{subscription-id}/resourcegroups/{resource-group}/providers/Microsoft.Storage/storageAccounts/{storage-name}",
"operationName": "Microsoft.Storage/storageAccounts/write",
"status": "Succeeded",
"subscriptionId": "{subscription-id}",
"tenantId": "{tenant-id}"
},
"specversion": "`1.0"
}]
The challenge I’m facing is understanding how to distinguish between resource creation and updates, given that the event data for both scenarios appears to be the same.
Additionally, I’m curious about why Microsoft might have chosen this design to handle both create and update events under a single ‘write’ operation.