Timer driven functions run at the top of the hour and iterate through all available subscriptions, so keep in mind that you may end up with resources tagged with an expires tag. Just delete the tag if you don't want it, but as of now there is no explicit white or blacklist for subscriptions, it is driven by principal access.

Created to help me with resource sprawl. I have a mix of demo, poc, test and production stuff strewn about subscriptions and it's annoying to keep up with...especially when the bill comes 💰 I started with Azure Policy, but found I couldn't do evaluations (like created time + 30 days), so decided to build my own tagger.

• Webhook receives notification from Azure Monitor that a new resource group has been created
• Resource group is queued to be tagged by the Tagger
• The tagger generates a series of tags for the resource group. Some are automatically added, others are driven by the resource group name.
  • expires the default expiration time tag. Defaults to 30 days, can be changed via app setting
  • owner the creator of the resource group. Defaults to unknown if the principal isn't known, default name configurable via app setting
  • tagged-by the system doing the tagging. Defaults to azman, default name configurable via app setting
• Hourly, functions run to scan the available subscriptions for both:
  • expired resource groups (e.g., expires tag < DateTime.UtcNow), which are enqueued for deletion, and
  • resource groups missing tags (driven by expires tag not found)
• When a group is enqueued for deletion, you can enable:
  • Notifications, which currently are emails using SendGrid that a resource has been deleted, and
  • Export template, which exports the template via the API to blob storage for archiving

Name-based tagging is driven by the name of the resource group, delimited by dash (-). Right now, position-to-tagname isn't configurable, but it's on the list.

For a sample resource group, named service-msft-prod-azman-main-compute:

When tagging is finished, it looks like this:

todo

todo

Configuration has two parts. First, the Azure Functions configuration, which goes in AppSettings of the function app. There doesn't seem to be support for Azure App Configuration just yet for storing all of the config in App Configuration, so the Function-required settings for bindings are in AppSettings.

Using Azure App Configuration isn't required - as long as these settings are available in AppSettings, environment variables or in App Configuration.

These are mostly related to bindings. You can use different storage accounts for queues or the same one. In most cases a single storage account will be more than sufficient :)

"AzureWebJobsStorage": "UseDevelopmentStorage=true",
"FUNCTIONS_WORKER_RUNTIME": "dotnet",
// storage account connection string with the tagging queue
"TaggingQueueStorageAccount": "UseDevelopmentStorage=true", 
// name of the tagging queue
"TaggingQueueName": "generate-tag-suite", 
// storage account connection string with the deletion queue
"DeleteQueueStorageAccount": "UseDevelopmentStorage=true", 
// name of the deletion queue
"DeleteResourceGroupQueueName": "delete-resource-group", 
// storage account connection string with the outbox queue
"OutboxQueueStorageAccount": "UseDevelopmentStorage=true", 
// name of the outbox queue
"OutboxQueueName": "mailer-outbox", 
// sendgrid key for sending mail
"SendGridKey": ""
// App Configuration connection string
"AZMAN-AAC-CONNECTION": "AAC connection string"

These are related to behavior configuration and not tied to Azure. As this gets refactored out more it will be make more sense to have them split.

  "TaggingOptions": {
    "ExpirationTagKey": "expires", // tag name to set for expiration
    "ExpirationWindowInDays": 30,
    "DefaultOwner": "unknown",
    "DefaultTaggedByName": "azman"
  },
  "DeletionOptions": {
    "Commit": false, // sort of like a 'what-if' switch, does everything except actually delete the resource group
    "NotifyOnDeletion": false, // enables notifications
    "ExportTemplateBeforeDeletion": true, // enables template export before deletion
    "PersistenceStorageContainer": "templates", // container name for storing exported templates
    "RequireExport": true // requires successful export for deletion to proceed. if `true` and the export fails, the deletion will not happen
  }

todo

todo

todo

todo