Aria Automation ABX actions unexpectedly create resource groups and objects in Microsoft Azure

Products

• VCF Operations/Automation (formerly VMware Aria Suite)

Issue/Introduction

• When executing Extensibility (ABX) actions in VMware Aria Automation, you observe that unexpected resources are automatically created in Microsoft Azure.

• The created resources typically follow a specific naming convention prefix, such as abx<externalId> or abx<random_20_chars>, and include:

  • Resource Groups

  • Storage Accounts

  • Application Insights components

  • Log Analytics Workspaces

  • Function Apps

• These resources are created even if the ABX action’s script does not explicitly target or communicate with Azure.

• ABX action executions may occasionally fail with a 403 status code or RequestDisallowedByPolicy error if strict Azure resource tagging policies or creation limits are enforced in the Azure environment.

Cause

This is the expected behavior by design.

When an ABX action is configured with the FaaS (Function as a Service) provider set to Auto Select, Aria Automation attempts to pick a provider in the following priority order:

1. AWS

2. Azure

3. On-prem

If the project contains an active Azure Cloud Account, Aria Automation will default to executing the function in Azure.

To successfully execute an ABX function in Azure, Aria Automation must provision the minimally required serverless infrastructure. It does so by automatically checking if the required resources exist. If they do not exist, it creates them using the following naming patterns:

• Resource Group: abx<externalId> (e.g., abx820b7f6b2b631bb398af123951649a...)

• Storage Account: abx<random20chars> (lowercase, no reserved words, e.g., abxr4jk2mxqzpwv8ysnl)

• Application Insights: abx<externalId>

• Log Analytics Workspace: abx-workspace<random20digits>

• Function App: <externalId> (no prefix)

These resources are reused on subsequent runs of the same ABX action and are only cleared/deleted from Azure when the associated ABX action itself is deleted from Aria Automation.

Resolution

If the ABX action strictly performs internal tasks—such as dynamically returning subscription names, mapping allowed regions, or interacting with internal endpoints—and does not require execution on Azure's serverless infrastructure, the FaaS provider should be explicitly restricted.

To prevent Aria Automation from automatically creating these Azure resources:

1. Log in to VMware Aria Automation and navigate to Assembler.

2. Go to Design > Extensibility > Actions.

3. Select the affected ABX action (e.g., GetAllowedRegions-VM).

4. Change the FaaS provider setting from Auto Select to On-prem.

5. Save the action.

6. (Optional): To clean up the previously created Azure resources, you can either manually delete the generated Resource Groups in the Azure Portal or delete the respective ABX action within Aria Automation, which will trigger an automatic cleanup of the associated Azure infrastructure.