Maintaining Azure Public IP Inventory by Retrieving Exact Deleted Public IP Using Activity Logs

Azure Activity Logs provide strong visibility into resource lifecycle operations across a subscription. Among these are lifecycle events related to Azure Public IP addresses, including creation and deletion. 

However, when a Public IP address is deleted, the corresponding delete operation in Azure Activity Logs includes only the Resource ID of the Public IP — not the actual IP address that was assigned to the resource. 

Once deletion is complete: 

• The Public IP resource no longer exists 

• The Resource ID cannot be resolved 

• The assigned Public IP address is permanently unretrievable through Azure APIs 

For organisations that rely on accurate IP inventory data for: 

• Security monitoring 

• Compliance audits 

• Incident response 

• Network forensics 

This blog presents a production‑ready implementation approach that enables organisations to reliably capture and retain the assigned Public IP address of Azure Public IP resources — even after they are deleted — using Azure Activity Log alerts, Azure Automation, and a persistent resource mapping cache. 

The Core Challenge 

When a Public IP resource is deleted, Azure emits an Activity Log event like: 

--- 

OperationName: Microsoft.Network/publicIPAddresses/delete 

ResourceId: 

 /subscriptions/<subscription-id>/resourceGroups/<rg-name>/providers/Microsoft.Network/publicIPAddresses/<pip-name> 

--- 

The alert correctly identifies the operation and the affected resource. 

However: 

• The Activity Log does not include the assigned Public IP address. 
• After deletion, the associated Resource ID no longer resolves to a live Azure resource.  

Maintaining Accurate IP Inventory 

Enterprises rely on centralised Public IP inventories mapped to workloads and ownership. Since delete Activity Log events emit the Resource ID, inventory systems require the exact Public IP address associated with the deleted resource.

Preventing False Security Investigations 

Azure Public IP addresses are globally reused. If a deleted IP remains recorded as owned internally, it may later be assigned to another tenant. This can lead to threat intelligence alerts and internal investigations against an IP address no longer under organisational ownership. 

Supporting High‑Churn Dynamic Workloads 

Ephemeral workloads such as Azure Machine Learning, CI/CD pipelines, and autoscaling deployments frequently create and delete Public IPs. In such environments, manual lifecycle tracking of assigned IP addresses is not operationally feasible.

Solution Overview 

The recommended approach is based on the following principle: 

Capture and persist the assigned Public IP address while the resource still exists and retrieve the stored value later when only the Resource ID is available. 

This can be implemented using: 

• Azure Activity Logs 
• Log Analytics alerts 
• Azure Automation Runbooks 
• Persistent mapping cache of Resource ID to IP address 

The solution comprises four primary components: 

1. Azure Activity Logs routed to Log Analytics 
2. Log Analytics alert rules detecting Public IP lifecycle operations 
3. Azure Automation Runbooks triggered through webhook actions 
4. Persistent cache storing Resource ID → IP address mappings 

Implementation Guide 

 Step 1: Route Activity Logs to Log Analytics 

Public IP lifecycle events are published through the Azure Activity Log under the Administrative category. 

To enable lifecycle detection through KQL queries: 

1. Navigate to:  Azure Monitor → Activity Log → Diagnostic Settings 
2. Select:  Add Diagnostic Setting 
3. Configure the following: 

• Category: Administrative 
• Destination: Send to Log Analytics Workspace 

      4.Select your target Log Analytics Workspace. 

      5.Click Save. 

This allows lifecycle operations to be queried by alert rules from Log Analytics.

Step 2: Deploy an Azure Automation Account 

Azure Automation will be used to execute runbooks that process Activity Log alerts and resolve Public IP address details during resource lifecycle operations. 

To begin: 

1. Navigate to the Azure Portal. 
2. In the search bar, search for Automation Accounts.
3. Select Create, provide the following details and Select "Review + Create" to complete the deployment.  

• Subscription 
• Resource Group 
• Automation Account Name 
• Region             

Once the Automation Account has been created: 

• Navigate to the Automation Account. 
• Go to Identity under the Account Settings section. 
• Enable System‑assigned Managed Identity. 
• Click Save.  

This Managed Identity will later be used by the runbooks to securely retrieve Public IP metadata from Azure Resource Manager during alert execution. 

 Step 3: Assign Managed Identity Permissions 

The Automation Account requires read‑only permissions to resolve Public IP resource information securely. 

Navigate to: 

• Subscription → Access Control (IAM) → Add Role Assignment 

Assign the following roles to the Automation Account Managed Identity: 

This ensures the runbooks are able to: 

• Query Public IP resources 

• Resolve resource metadata 

• Interpret Activity Log–driven lifecycle operations 

 Step 4: Create a Persistent Cache Variable 

The assigned IP address must be captured and persisted in advance before it is deleted.  To maintain this mapping, create a persistent Automation variable to store the following relationship: 

Public IP Resource ID → Assigned IP Address  

Within the Automation Account: 

1. Navigate to: Shared Resources → Variables 
2. Select + Add. 
3. Configure the variable as follows:  

• Name: PipLastKnownIps 
• Type: String 
• Value: {}
• Encryption: Disabled 

     4.Select Create. 

 This variable will act as a persistent cache that is dynamically updated during Public IP lifecycle events. 

Step 5: Create Required Automation Runbooks 

Two Azure Automation Runbooks are required for this implementation. 

 Step 5.1: Create Cache Seeding Runbook 

Create Cache Seeding Runbook 

This runbook will enumerate all currently existing Public IP resources and populate the cache variable with their assigned IP address mappings. 

1. Navigate to: Automation Account → Runbooks 
2. Select Create a runbook. 
3. Provide the following details:  

• Name: CacheSeedingRunbook 
• Runbook Type: PowerShell 
• Runtime Version: 7.2 

    4. After the runbook is created, paste the script here CacheSeedingRunbook. 

• Select Publish. 

 This runbook will initialise the cache by capturing the current state of all Public IP resources prior to enabling lifecycle‑based Activity Log processing. 

Step 5.2: Create Main Lifecycle Runbook 

This runbook will be triggered via webhook whenever a Public IP lifecycle event is detected through Activity Logs. 

1. Navigate to: Automation Account → Runbooks 
2. Select Create a runbook. 
3. Provide the following details:  

• Name: MainLifecycleRunbook 
• Runbook Type: PowerShell 
• Runtime Version: 7.2 
• After the runbook is created, paste the required lifecycle processing script MainLifecycleRunbook 

     4. Select Publish once configuration is complete. 

This runbook will process Activity Log‑based lifecycle events and dynamically update the PipLastKnownIps cache variable in response to Public IP creation or deletion. 

Step 6: Create Runbook Webhook 

Configure Runbook Webhook 

To allow Activity Log alerts to invoke the runbook: 

1. Navigate to: Automation Account → Runbooks → MainLifecycleRunbook 
2. Go to: Resources → Webhooks 
3. Select Add Webhook. 
4. Provide the following details: 

• Webhook Name 
• Expiration Date 

     5. Copy the generated Webhook URL. 

This URL will be used by the Alert Action Group in a later step to trigger the runbook upon detection of Public IP lifecycle events. 

Step 7: Seed Cache with Existing Public IPs 

Before activating the alert‑driven workflow, populate the cache with currently active Public IP resources. 

• Navigate to: CacheSeedingRunbook → Start  and Run the job once. 

This will initialise the PipLastKnownIps mapping with all existing Public IP resources.  Future lifecycle events will update this cache dynamically. 

Step 8: Create Activity Log Alert Rule 

1. Navigate to: Azure Monitor → Alerts → Create Alert Rule 
2. Scope the alert rule to the relevant Log Analytics Workspace. 

Under Condition: 

• Select: Custom Log Search 
• Use the KQL query available here: query.json 
• Configure the following parameters as required: 
  • Evaluation Frequency 
  • Query Time Range 

This alert rule will detect Public IP lifecycle events and trigger the associated Action Group for downstream runbook execution. 

Please find the configuration in the attached screenshot below: 

 

 

Step 9: Configure Action Group to Trigger Runbook 

1. Create an Action Group that invokes the Lifecycle Runbook webhook. 
2. Add a new action. 
3. Configure the action with the following details:  

• Action Type: Webhook 
• Paste the previously generated Runbook Webhook URL 

     3.Enable:  

• Use Common Alert Schema 

(Optional) 
Add an Email Notification action to receive lifecycle alerts for troubleshooting or monitoring purposes. 

     4. Attach this Action Group to the alert rule. 

Step 10: Validate the Implementation 

To validate: 

1. Create a Public IP resource. 
2. Delete the same resource. 
3. Navigate to: Automation Account → Jobs → MainLifecycleRunbook 
4. Observe the runbook execution output related to: 

• Public IP creation 
• Public IP deletion 

Although the delete alert contains only the Resource ID, the runbook retrieves the exact assigned Public IP address from the cache. 

See the sample output below: 

You can extend this workflow using Azure Logic Apps to forward events to Email , SIEM platforms or  CMDB systems. 

Conclusion

In addition to tracking Public IP deletions using Activity Logs, proactively capturing and persisting Resource ID–to–IP mappings through Automation‑driven lifecycle alerts, organisations can maintain an accurate Public IP inventory—ensuring traceability, reducing false‑positive security investigations, and strengthening audit and incident response readiness.