Editar

Compartilhar via

Considerations for naming Azure resources

  • Artigo

You shouldn't include sensitive or restricted information in Azure resource names because it may be stored or accessed outside the compliance boundary to facilitate support and troubleshooting. Examples of sensitive information include data subject to:

Data stored or processed in customer VMs, storage accounts, databases, Azure Import/Export, Azure Cache for Redis, ExpressRoute, Azure AI Search, App Service, API Management, and other Azure services suitable for holding, processing, or transmitting customer data can contain sensitive data. However, metadata for these Azure services isn't permitted to contain sensitive or restricted data. This metadata includes all configuration data entered when creating and maintaining an Azure service, including:

  • Subscription names, service names, server names, database names, tenant role names, resource groups, deployment names, resource names, resource tags, circuit name, and so on.
  • All shipping information that is used to transport media for Azure Import/Export, such as carrier name, tracking number, description, return information, drive list, package list, storage account name, container name, and so on.
  • Data in HTTP headers sent to the REST API in search/query strings as part of the API.
  • Device/policy/application and other metadata sent to Intune.

Azure resource names include information provided by you, or on your behalf, that is used to identify or configure cloud service resources, such as software, systems, or containers. However, it does not include customer-created content or metadata inside the resource (for example, database column/table names). Azure resource names include the names you assign to Azure Resource Manager level objects and resources deployed in Azure. Examples include the names of resources such as virtual networks, virtual hard disks, database servers and databases, virtual network interface, network security groups, key vaults, and others.

Note

The above examples are but a subset of the types of resources you can name. This list is not meant to be fully exhaustive and the types of resources could change in the future as new cloud services are added.

Naming convention

The names of Azure resources are part of a larger resource ID as follows:

/subscriptions/<subscriptionID>/resourceGroups/<ResourceGroupName>/providers/<ResourceProvider>/<ResourceType>/<ResourceName>

An example of a virtual machine resource ID is:

/subscriptions/<subscriptionID>/resourceGroups/<ResourceGroupName>/providers/Microsoft.Compute/virtualMachines/<virtualMachineName>

Naming considerations

You should avoid names that are sensitive to business or mission functions. This guidance applies to all names that meet the criteria mentioned previously, from the name of the larger resource group to the name of the end resources within it. You should also avoid names that indicate your regulatory requirements, for example:

Note

Also consider naming of resource tags when reviewing the Resource naming and tagging decision guide.

You should understand and take into account the resource naming convention to help ensure operational security, as Microsoft personnel could use the full resource ID in the following example scenarios:

  • Microsoft support personnel may use the full resource ID of resources during support events to ensure we're identifying the right resource within a customer's subscription.
  • Microsoft product engineering personnel could use full resource IDs during routine monitoring of telemetry data to identify deviations from baseline or average system performance.
  • Proactive communication to customers about impacted resources during internally discovered incidents.

Next steps