I was reading a blog post by Mark Heath on This resource group will self destruct in 30 minutes which leverages an open source Azure CLI extension to automatically delete resource groups.  This extension accomplishes the deletion by scheduling a logic app in the same resource group.  I was curious if I could accomplish the same effect without the need to leverage the Azure CLI (i.e. for any resource group created via portal, PowerShell, etc.)  In this post I’ll show how to configure a “self destruct” mechanism using an Azure Alert and a Logic App.

Solution

Here are the high level steps to follow.

1. Create Resource Group – Create resource group will host the subsequent resources
2. Create Logic App – Create logic app to trigger on Azure Activity Log HTTP request (will fill out more later)
3. Activity Log alert – Create Azure Activity Log alert to trigger logic app
4. Trigger Alert – Create resource group which triggers Activity Log alert and consequently logic app
5. Gather JSON schema – Get JSON schema for HTTP request sent to logic app
6. Finalize Logic App – Add JSON schema from alert HTTP request and action to remove resource group to logic app

1) Create Resource Group

If you don’t already have one, create a resource group to host the resources for the self destruct solution.

2) Create Logic App

Create a logic app in the resource group from previous step.  Add a trigger for When a HTTP request is received.  We will not fill out any of the details for the trigger at this time.  Click Save.

3) Activity Log alert

Navigate to Azure Monitor (can search from the top search bar or go through All Services) for the subscription where the solution will be deployed.

Click Alerts on the left hand navigation.  Click New Alert Rule.

Define the resource to be monitored:

• Resource:
• Condition:
  • Signal Type: Activity Log
  • Monitor Service: Activity Log – Administrative
  • Signal Name: Create Resource Group (subscriptions/resourceGroups)
  • Alert Logic – Status: Succeeded
• Action Groups:
  • Action Group Name: SelfDestructResourceGroup
  • Short Name: SelfDestruct
  • Subscription:
  • Resource Group:
  • Action Group Action: LogicApp
    • Subscription:
    • Resource Group:
    • Logic App:

4) Trigger Alert

Create a new resource group that will then trigger the alert defined in step 3 and consequently fire the HTTP trigger for the logic app defined in step 2.

5) Gather JSON Schema

Navigate to the logic app defined in step 2.  Assuming the logic app was successfully triggered, under Run history select the successful logic app execution.  On the “logic app run” screen expand the trigger and click on Show raw outputs.

Save this JSON for use in the next step.  If you are unable to collect this JSON schema you can use the sample below which is already coverted to the final format needed.

Note: the resoureceGroupName element is buried many levels deep.  We will query for this when needed.

{
“properties”: {
“body”: {
“properties”: {
“data”: {
“properties”: {
“context”: {
“properties”: {
“activityLog”: {
“properties”: {
“authorization”: {
“properties”: {
“action”: {
“type”: “string”
},
“scope”: {
“type”: “string”
}
},
“type”: “object”
},
“caller”: {
“type”: “string”
},
“channels”: {
“type”: “string”
},
“claims”: {
“type”: “string”
},
“correlationId”: {
“type”: “string”
},
“description”: {
“type”: “string”
},
“eventDataId”: {
“type”: “string”
},
“eventSource”: {
“type”: “string”
},
“eventTimestamp”: {
“type”: “string”
},
“httpRequest”: {
“type”: “string”
},
“level”: {
“type”: “string”
},
“operationId”: {
“type”: “string”
},
“operationName”: {
“type”: “string”
},
“properties”: {
“properties”: {
“responseBody”: {
“type”: “string”
},
“serviceRequestId”: {},
“statusCode”: {
“type”: “string”
}
},
“type”: “object”
},
“resourceGroupName”: {
“type”: “string”
},
“resourceId”: {
“type”: “string”
},
“resourceProviderName”: {
“type”: “string”
},
“resourceType”: {
“type”: “string”
},
“status”: {
“type”: “string”
},
“subStatus”: {
“type”: “string”
},
“submissionTimestamp”: {
“type”: “string”
},
“subscriptionId”: {
“type”: “string”
}
},
“type”: “object”
}
},
“type”: “object”
},
“properties”: {
“properties”: {},
“type”: “object”
},
“status”: {
“type”: “string”
}
},
“type”: “object”
},
“schemaId”: {
“type”: “string”
}
},
“type”: “object”
},
“headers”: {
“properties”: {
“Connection”: {
“type”: “string”
},
“Content-Length”: {
“type”: “string”
},
“Content-Type”: {
“type”: “string”
},
“Expect”: {
“type”: “string”
},
“Host”: {
“type”: “string”
},
“User-Agent”: {
“type”: “string”
},
“X-CorrelationContext”: {
“type”: “string”
}
},
“type”: “object”
}
},
“type”: “object”
}

6) Finalize Logic App

Edit the Logic App.

Inside the HTTP request trigger either…

• click “sample payload to generate schema” paste in your sample JSON payload from step 5.

-or-

• paste the sample I provided into the Schema input.

Next add an action for Delete a resource group (currently in preview at time of writing).

Fill in the following values:

• Subscription:
• Resource Group: Expression = “triggerBody().data.context.activityLog.resourceGroupName”

The final logic app will look similar to the following:

Test Solution

Test out the solution by adding a new resource group to the monitored subscription.  Check the Azure Monitor alerts to see if the Activity Log entry for successful resource group creation triggered the Logic App.

Then verify the logic app execution history shows the resource group deletion was successful.

Next steps

More than likely you will not want to delete the resource group right after you create it.  In that case you can add a Delay action which pauses the logic app for a specified number of minutes (ex. 60 minutes).  Additionally you could apply conditional logic to check if the name of the resource group matches (or doesn’t match) a specific pattern.  There are many additions you can add to personalize this solution to your needs.

Conclusion

In this post I walked through an adaptation of the Azure CLI extension that Mark Heath linked to.  We leveraged an Azure Monitor alert together with a logic app to provide an option to self destruct any resource group no matter where or how it was created.  If you have any feedback or additional suggestions feel free to leave them in the comments.

-Frog Out

In this post I’ll share a set of linked Azure ARM templates (link) that can be used to deploy a number of Azure resources together.  This sample uses externally linked ARM templates using a parent to child relationship as well as including a few “complex” scenarios like conditional logic and assigning permissions through role assignments.  Note there are also two ways to deploy these templates: 1) at the subscription level (owner) and 2) at the resource group level (contributor).

<Update 2019-04-09>After reading this article on ARM template lifecycle management do’s and dont’s I’m rethinking using externally linked ARM templates.  Below example still contains them but I may update to combine into a single ARM template at a later date once I’ve had a chance to test.</Update>

Background

For a recent customer project we had a need to deploy the following resources.

• Resource group
  • Azure Storage Account
  • Azure Function App
    • Azure Application Insights
  • Azure Log Analytics workspace
  • Azure Automation Account

A few of these resources have dependencies on each other such as the Function App requiring a storage account to store solution data into blobs / queues, Automation Account requiring Log Analytics for pushing diagnostic stream data to a workspace, etc.  While it is possible to deploy all of these resources in one (very) large ARM template, we also wanted to be able re-use pieces and parts of this solution in future projects that are going to have a similar (but slightly different) architecture.  We decided to create a set of parent-child ARM templates to mimic the first 2 levels of the above hierarchy.

Solution

The sample files are stored in my Blog-Samples repo under the ARM-External-Templates folder.  There is a brief README file to walk through the necessary steps to update parameter files, upload the linked templates to a storage account, etc.  This is not a fully documented process at the moment but if you wish to submit a PR or open an issue I’ll update more as I have time.

A few key pieces to highlight.

• The “Contributor” scenario assumes that the deployment account has contributor permissions to a specific resource group or subscription (more common for production or similar environments)
• The “Owner” scenario assumes that the deployment account has owner permissions to the entire subscription (ex. development environment)
• The “Owner” scenario optionally deploys role assignments (queue sender, workspace reader, and runbook operator) to various resources only if the corresponding parameter values are not empty (otherwise skip assignment)
• The Automation Account is pre-populated with a PowerShell runbook and also configured to send runbook job and stream output to the provisioned log analytics workspace

Sample output

After running the deployment script the deployment and resource group should look as follows.

Conclusion

The linked ARM templates from this sample are meant for illustration purposes only.  Hopefully you’ll find them helpful in terms of what is possible from a deployment and configuration perspective.  If you have any feedback or suggestions please submit a PR on the repo or open an issue on GitHub.  Good luck with automating your Azure deployments.

-Frog Out