Azure Soft Delete: Recovering Resources and Preventing Accidental Deletions

Earlier this week, I had one of those moments that makes your stomach drop – an Azure API Management instance had been deleted. These things happen; someone clicks the wrong button, a Terraform state gets out of sync, or an automated cleanup script gets a bit too enthusiastic. Whatever the cause, the result is the same: a critical resource is gone, and you need it back.

Fortunately, some Azure services, including API Management, support soft delete. Many Azure services retain deleted resources for a period before permanently removing them, giving you a window to recover from these situations. This post covers my experience recovering the APIM instance and provides a broader look at which Azure services support soft delete and how to use it.

Recovering a Deleted Azure API Management Instance

When an Azure API Management instance is deleted (via the Azure Portal or REST API version 2020-06-01-preview or later), it enters a soft-deleted state for 48 hours before being permanently purged. This gives you a window to recover it.

Finding the Deleted Service

First, let’s confirm the service is in a soft-deleted state and get the details we need. Using the Azure CLI:

az apim deletedservice show \
  --location uksouth \
  --service-name apim-that-was-deleted-uks

This returns something like:

{
  "deletionDate": "2025-12-01T15:04:29.570042+00:00",
  "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/providers/Microsoft.ApiManagement/locations/uksouth/deletedservices/apim-that-was-deleted-uks",
  "location": "UK South",
  "name": "apim-that-was-deleted-uks",
  "scheduledPurgeDate": "2025-12-03T15:02:32.189403+00:00",
  "serviceId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/rg-apim-production-uks/providers/Microsoft.ApiManagement/service/apim-that-was-deleted-uks",
  "type": "Microsoft.ApiManagement/deletedservices"
}

The key things to note here are the scheduledPurgeDate (you have until then to recover) and the serviceId which tells us the original resource group. In my case, the resource group had also been deleted, so I needed to recreate that first.

Restoring the Service

To restore the APIM instance, you need to use the Azure REST API directly – there’s no native Azure CLI command for this yet. Set up your variables:

apimName="apim-that-was-deleted-uks"
subscriptionId=$(az account show --query id --output tsv)
location="uksouth"
resourceGroupName="rg-apim-production-uks"

If your resource group was also deleted, recreate it first:

az group create \
  --name $resourceGroupName \
  --location $location

Now restore the APIM service using the REST API:

az rest \
  --method PUT \
  --header "Accept=application/json" \
  --uri "https://management.azure.com/subscriptions/${subscriptionId}/resourceGroups/${resourceGroupName}/providers/Microsoft.ApiManagement/service/${apimName}?api-version=2021-08-01" \
  --body "{\"location\":\"${location}\",\"properties\": {\"restore\" : true} }"

The restoration process will take several minutes. You’ll see the provisioningState change from Deleted to Activating and eventually to Succeeded. Once complete, your APIM instance is back, complete with all its APIs, policies, and configurations.

Azure API Management Soft-Delete learn.microsoft.com

Soft-delete allows you to recover a recently deleted API Management instance.

Other Azure Services with Soft Delete

My APIM adventure got me thinking about what other Azure services support soft delete. Turns out, quite a few do – and it’s worth knowing about them before you need them.

Azure Key Vault

Key Vault is probably the most well-known example. Soft delete is enabled by default and cannot be disabled. When you delete a secret, key, or certificate, it’s retained for a configurable period (minimum 7 days, up to 90 days) before permanent deletion.

az keyvault secret list-deleted --vault-name my-keyvault

az keyvault secret recover --vault-name my-keyvault --name my-secret

You can also enable purge protection to prevent even administrators from permanently deleting items before the retention period expires – useful in production environments where you really can’t afford to lose things.

Azure Storage

Azure Blob Storage supports soft delete for both blobs and containers, with configurable retention periods from 1 to 365 days.

az storage account blob-service-properties update \
  --account-name mystorageaccount \
  --enable-delete-retention true \
  --delete-retention-days 30

Azure File Shares also support soft delete, allowing you to recover entire file shares and their contents:

az storage share-rm list \
  --storage-account mystorageaccount \
  --include-deleted

Azure SQL Database

Deleted Azure SQL databases can be restored within the backup retention period (up to 35 days depending on your tier). Deleted SQL servers themselves can also be recovered if the backup is still available.

az sql db list-deleted \
  --resource-group myresourcegroup \
  --server myserver

Azure Backup

Azure Backup enforces soft delete by default as part of its “secure by default” posture. When you stop backup and delete data, the recovery points are retained for 14 days (configurable up to 180 days). This applies to VM backups, SQL Server in Azure VM backups, and SAP HANA backups.

Azure Container Registry

Currently in preview, ACR supports soft delete for accidentally deleted container images and tags with retention periods from 1 to 90 days.

Azure Log Analytics Workspace

Deleted workspaces are retained in a soft-deleted state for 14 days, during which they can be recovered with all their data intact.

Microsoft Entra ID (Azure AD)

The Recycle Bin feature retains deleted users, groups, and other directory objects for 30 days before permanent deletion.

Quick Reference Table

Prevention is Better Than Cure: Delete Locks

While soft delete is a great safety net, it’s better to prevent accidental deletions in the first place. Azure Resource Locks allow you to protect resources from accidental modification or deletion.

There are two types of locks:

• CanNotDelete: Resources can be read and modified, but not deleted
• ReadOnly: Resources can only be read, not modified or deleted

Applying a Delete Lock

To protect a critical resource from deletion:

az lock create \
  --name "PreventDeletion" \
  --lock-type CanNotDelete \
  --resource-group rg-production-uks \
  --resource-name apim-production-uks \
  --resource-type Microsoft.ApiManagement/service

Or protect an entire resource group:

az lock create \
  --name "PreventDeletion" \
  --lock-type CanNotDelete \
  --resource-group rg-production-uks

Managing Locks with Infrastructure as Code

If you’re using Terraform, you can apply locks as part of your deployment:

resource "azurerm_management_lock" "apim_lock" {
  name       = "PreventDeletion"
  scope      = azurerm_api_management.main.id
  lock_level = "CanNotDelete"
  notes      = "Protected production resource"
}

For ARM templates or Bicep:

resource apimLock 'Microsoft.Authorization/locks@2020-05-01' = {
  name: 'PreventDeletion'
  scope: apimService
  properties: {
    level: 'CanNotDelete'
    notes: 'Protected production resource'
  }
}

Lock your Azure resources to protect your infrastructure - Azure Resource Manager learn.microsoft.com

Learn how to lock all users and roles to protect your Azure resources from updates or deletions.

Summary

Getting that sinking feeling when a critical resource disappears is never pleasant, but knowing that Azure has soft delete capabilities across many services can turn a potential disaster into a minor inconvenience. The key takeaways:

1. Know your retention periods: Different services have different soft delete windows. API Management gives you 48 hours, while Key Vault can give you up to 90 days.
2. Test recovery procedures before you need them: It’s much less stressful to learn the recovery process in a dev environment than during an incident.
3. Use delete locks on production resources: A few minutes setting up locks can save hours of recovery work and stress.
4. Document your critical resources: Keep a list of resources that would cause significant impact if deleted, along with their soft delete capabilities and recovery procedures.

The next time someone accidentally deletes something important, you’ll know exactly where to look and what to do. And if you put those delete locks in place, hopefully you won’t need to deal with it at all.