Migrate to Innovate Summit:
Learn how migrating and modernizing to Azure can boost your business's performance, resilience, and security, enabling you to fully embrace AI.Register now
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Applies to: ✔️ Linux VMs ✔️ Windows VMs ✔️ Flexible scale sets
The Azure Instance Metadata Service (IMDS) provides information about currently running virtual machine instances. You can use it to manage and configure your virtual machines.
This information includes the SKU, storage, network configurations, and upcoming maintenance events. For a complete list of the data available, see the Endpoint Categories Summary.
IMDS is available for running instances of virtual machines (VMs) and scale set instances. All endpoints support VMs created and managed by using Azure Resource Manager. Only the Attested category and Network portion of the Instance category support VMs created by using the classic deployment model. The Attested endpoint does so only to a limited extent.
IMDS is a REST API that's available at a well-known, non-routable IP address (169.254.169.254). You can only access it from within the VM. Communication between the VM and IMDS never leaves the host.
Have your HTTP clients bypass web proxies within the VM when querying IMDS.
Here's sample code to retrieve all metadata for an instance. To access a specific data source, see Endpoint Categories for an overview of all available features.
Request
Important
This example bypasses proxies. You must bypass proxies when querying IMDS. See Proxies for additional information.
Note
IMDS requests must be sent using VM's primary NIC and primary IP, and DHCP must be enabled.
The Instance Metadata Service is only accessible from within a running virtual machine instance on a non-routable IP address. VMs can only interact with their own metadata/functionality. The API is HTTP only and never leaves the host.
In order to ensure that requests are directly intended for IMDS and prevent unintended or unwanted redirection of requests, requests:
Must contain the header Metadata: true
Must not contain an X-Forwarded-For header
Any request that doesn't meet both of these requirements are rejected by the service.
Important
IMDS is not a channel for sensitive data. The API is unauthenticated and open to all processes on the VM. Information exposed through this service should be considered as shared information to all applications running inside the VM.
If it isn't necessary for every process on the VM to access IMDS endpoint, you can set local firewall rules to limit the access.
For example, if only a known system service needs to access instance metadata service, you can set a firewall rule on IMDS endpoint, only allowing the specific process(es) to access, or denying access for the rest of the processes.
Proxies
IMDS is not intended to be used behind a proxy and doing so is unsupported. Most HTTP clients provide an option for you to disable proxies on your requests, and this functionality must be utilized when communicating with IMDS. Consult your client's documentation for details.
Important
Even if you don't know of any proxy configuration in your environment, you still must override any default client proxy settings. Proxy configurations can be automatically discovered, and failing to bypass such configurations exposes you to outage risks should the machine's configuration be changed in the future.
Rate limiting
In general, requests to IMDS are limited to 5 requests per second (on a per VM basis). Requests exceeding this threshold will be rejected with 429 responses. Requests to the Managed Identity category are limited to 20 requests per second and 5 concurrent requests (on a per VM basis).
HTTP verbs
The following HTTP verbs are currently supported:
Verb
Description
GET
Retrieve the requested resource
Parameters
Endpoints may support required and/or optional parameters. See Schema and the documentation for the specific endpoint in question for details.
Query parameters
IMDS endpoints support HTTP query string parameters. For example:
Requests with duplicate query parameter names will be rejected.
Route parameters
For some endpoints that return larger json blobs, we support appending route parameters to the request endpoint to filter down to a subset of the response:
When filtering to a leaf node, format=json doesn't work. For these queries format=text needs to be explicitly specified since the default format is json.
Schema
Data format
By default, IMDS returns data in JSON format (Content-Type: application/json). However, endpoints that support response filtering (see Route Parameters) also support the format text.
To access a non-default response format, specify the requested format as a query string parameter in the request. For example:
In json responses, all primitives will be of type string, and missing or inapplicable values are always included but will be set to an empty string.
Versioning
IMDS is versioned and specifying the API version in the HTTP request is mandatory. The only exception to this requirement is the versions endpoint, which can be used to dynamically retrieve the available API versions.
As newer versions are added, older versions can still be accessed for compatibility if your scripts have dependencies on specific data formats.
When you don't specify a version, you get an error with a list of the newest supported versions:
JSON
{
"error": "Bad request. api-version was not specified in the request. For more information refer to aka.ms/azureimds",
"newest-versions": [
"2020-10-01",
"2020-09-01",
"2020-07-15"
]
}
Supported API versions
Note
Version 2023-11-15 is still being rolled out, it may not be available in some regions.
The service is generally available in all Azure clouds.
Root endpoint
The root endpoint is http://169.254.169.254/metadata.
Endpoint categories
The IMDS API contains multiple endpoint categories representing different data sources, each of which contains one or more endpoints. See each category for details.
Unique identifier for the VM. The blog referenced only suits for VMs that have SMBIOS < 2.6. For VMs that have SMBIOS >= 2.6, the UUID from DMI is displayed in little-endian format, thus, there's no requirement to switch bytes.
† This version isn't fully available yet and may not be supported in all regions.
Storage profile
The storage profile of a VM is divided into three categories: image reference, OS disk, and data disks, plus an additional object for the local temporary disk.
The image reference object contains the following information about the OS image, please note that an image could come either from the platform, marketplace, community gallery, or direct shared gallery but not both:
Data
Description
Version introduced
id
Resource ID
2019-06-01
offer
Offer of the platform or marketplace image
2019-06-01
publisher
Publisher of the platform or marketplace image
2019-06-01
sku
Sku of the platform or marketplace image
2019-06-01
version
Version of the image
2019-06-01
communityGalleryImageId
Resource ID of the community image, empty otherwise
2023-07-01
sharedGalleryImageId
Resource ID o direct shared image, empty otherwise
2023-07-01
exactVersion
Version of the community or direct shared image
2023-07-01
The OS disk object contains the following information about the OS disk used by the VM:
Data
Description
caching
Caching requirements
createOption
Information about how the VM was created
diffDiskSettings
Ephemeral disk settings
diskSizeGB
Size of the disk in GB
image
Source user image virtual hard disk
managedDisk
Managed disk parameters
name
Disk name
vhd
Virtual hard disk
writeAcceleratorEnabled
Whether or not writeAccelerator is enabled on the disk
The data disks array contains a list of data disks attached to the VM. Each data disk object contains the following information:
Data
Description
Version introduced
bytesPerSecondThrottle*
Disk read/write quota in bytes
2021-05-01
caching
Caching requirements
2019-06-01
createOption
Information about how the VM was created
2019-06-01
diffDiskSettings
Ephemeral disk settings
2019-06-01
diskCapacityBytes*
Size of disk in bytes
2021-05-01
diskSizeGB
Size of the disk in GB
2019-06-01
encryptionSettings
Encryption settings for the disk
2019-06-01
image
Source user image virtual hard disk
2019-06-01
isSharedDisk*
Identifies if the disk is shared between resources
2021-05-01
isUltraDisk
Identifies if the data disk is an Ultra Disk
2021-05-01
lun
Logical unit number of the disk
2019-06-01
managedDisk
Managed disk parameters
2019-06-01
name
Disk name
2019-06-01
opsPerSecondThrottle*
Disk read/write quota in IOPS
2021-05-01
osType
Type of OS included in the disk
2019-06-01
vhd
Virtual hard disk
2019-06-01
writeAcceleratorEnabled
Whether or not writeAccelerator is enabled on the disk
2019-06-01
*These fields are only populated for Ultra Disks; they are empty strings from non-Ultra Disks.
The encryption settings blob contains data about how the disk is encrypted (if it's encrypted):
The nics returned by the network call are not guaranteed to be in order.
Get user data
When creating a new VM, you can specify a set of data to be used during or after the VM provision, and retrieve it through IMDS. Check the end to end user data experience here.
To set up user data, utilize the quickstart template here. The sample below shows how to retrieve this data through IMDS. This feature is released with version 2021-01-01 and above.
Note
Security notice: IMDS is open to all applications on the VM, sensitive data should not be placed in the user data.
As a service provider, you may require to track the number of VMs running your software or have agents that need to track uniqueness of the VM. To be able to get a unique ID for a VM, use the vmId field from Instance Metadata Service.
For certain scenarios, placement of different data replicas is of prime importance. For example, HDFS replica placement
or container placement via an orchestrator might require you to know the platformFaultDomain and platformUpdateDomain the VM is running on.
You can also use Availability Zones for the instances to make these decisions.
You can query this data directly via IMDS.
VM tags are included the instance API under instance/compute/tags endpoint.
Tags may have been applied to your Azure VM to logically organize them into a taxonomy. The tags assigned to a VM can be retrieved by using the request below.
The tags field is a string with the tags delimited by semicolons. This output can be a problem if semicolons are used in the tags themselves. If a parser is written to programmatically extract the tags, you should rely on the tagsList field. The tagsList field is a JSON array with no delimiters, and consequently, easier to parse. The tagsList assigned to a VM can be retrieved by using the request below.
Sample 4: Get more information about the VM during support case
As a service provider, you may get a support call where you would like to know more information about the VM. Asking the customer to share the compute metadata can provide basic information for the support professional to know about the kind of VM on Azure.
Sample 5: Get the Azure Environment where the VM is running
Azure has various sovereign clouds like Azure Government. Sometimes you need the Azure Environment to make some runtime decisions. The following sample shows you how you can achieve this behavior.
If you're looking to retrieve IMDS information for Standard SKU Public IP address, review Load Balancer Metadata API for more infomration.
Attested data
Get Attested data
IMDS helps to provide guarantees that the data provided is coming from Azure. Microsoft signs part of this information, so you can confirm that an image in Azure Marketplace is the one you're running on Azure.
GET /metadata/attested/document
Parameters
Name
Required/Optional
Description
api-version
Required
The version used to service the request.
nonce
Optional
A 10-digit string that serves as a cryptographic nonce. If no value is provided, IMDS uses the current UTC timestamp.
The signature blob is a pkcs7-signed version of document. It contains the certificate used for signing along with certain VM-specific details.
For VMs created by using Azure Resource Manager, the document includes vmId, sku, nonce, subscriptionId, timeStamp for creation and expiry of the document, and the plan information about the image. The plan information is only populated for Azure Marketplace images.
For VMs created by using the classic deployment model, only the vmId and subscriptionId are guaranteed to be populated. You can extract the certificate from the response, and use it to confirm that the response is valid and is coming from Azure.
The decoded document contains the following fields:
Data
Description
Version introduced
licenseType
Type of license for Azure Hybrid Benefit. This is only present for AHB-enabled VMs.
2020-09-01
nonce
A string that can be optionally provided with the request. If no nonce was supplied, the current Coordinated Universal Time timestamp is used.
2018-10-01
plan
The Azure Marketplace Image plan. Contains the plan ID (name), product image or offer (product), and publisher ID (publisher).
2018-10-01
timestamp.createdOn
The UTC timestamp for when the signed document was created
2018-20-01
timestamp.expiresOn
The UTC timestamp for when the signed document expires
When validating the signature, you should confirm that the signature was created with a certificate from Azure. This is done by validating the certificate Subject Alternative Name (SAN).
Example SAN DNS Name=eastus.metadata.azure.com, DNS Name=metadata.azure.com
Note
The domain for the public cloud and each sovereign cloud will be different.
The certificates might not have an exact match for the domain. For this reason, the certification validation should accept any subdomain (for example, in public cloud general availability regions accept *.metadata.azure.com).
We don't recommend certificate pinning for intermediate certs. For further guidance, see Certificate pinning - Certificate pinning and Azure services.
Please note that the Azure Instance Metadata Service will NOT offer notifications for future Certificate Authority changes.
Instead, you must follow the centralized Azure Certificate Authority details article for all future updates.
Sample 1: Validate that the VM is running in Azure
Vendors in Azure Marketplace want to ensure that their software is licensed to run only in Azure. If someone copies the VHD to an on-premises environment, the vendor needs to be able to detect that. Through IMDS, these vendors can get signed data that guarantees response only from Azure.
Note
This sample requires the jq utility to be installed.
# Get the signature$attestedDoc = Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET -NoProxy -Uri http://169.254.169.254/metadata/attested/document?api-version=2020-09-01# Decode the signature$signature = [System.Convert]::FromBase64String($attestedDoc.signature)
Verify that the signature is from Microsoft Azure and checks the certificate chain for errors.
PowerShell
# Get certificate chain$cert = [System.Security.Cryptography.X509Certificates.X509Certificate2]($signature)
$chain = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Chain
$chain.Build($cert)
# Print the Subject of each certificate in the chainforeach($elementin$chain.ChainElements)
{
Write-Host$element.Certificate.Subject
}
# Get the content of the signed documentAdd-Type -AssemblyName System.Security
$signedCms = New-Object -TypeName System.Security.Cryptography.Pkcs.SignedCms
$signedCms.Decode($signature);
$content = [System.Text.Encoding]::UTF8.GetString($signedCms.ContentInfo.Content)
Write-Host"Attested data: "$content$json = $content | ConvertFrom-Json# Do additional validation here
Bash
# Get the signature
curl --silent -H Metadata:True --noproxy "*""http://169.254.169.254/metadata/attested/document?api-version=2020-09-01" | jq -r '.["signature"]' > signature
# Decode the signature
base64 -d signature > decodedsignature
# Get PKCS7 format
openssl pkcs7 -in decodedsignature -inform DER -out sign.pk7
# Get Public key out of pkc7
openssl pkcs7 -in decodedsignature -inform DER -print_certs -out signer.pem
# Get the intermediate certificate
curl -s -o intermediate.cer "$(openssl x509 -in signer.pem -text -noout | grep " CA Issuers -" | awk -FURI: '{print $2}')"
openssl x509 -inform der -in intermediate.cer -out intermediate.pem
# Verify the contents
openssl smime -verify -in sign.pk7 -inform pem -noverify
Verify that the signature is from Microsoft Azure, and check the certificate chain for errors.
Bash
# Verify the subject name for the main certificate
openssl x509 -noout -subject -in signer.pem
# Verify the issuer for the main certificate
openssl x509 -noout -issuer -in signer.pem
#Validate the subject name for intermediate certificate
openssl x509 -noout -subject -in intermediate.pem
# Verify the issuer for the intermediate certificate
openssl x509 -noout -issuer -in intermediate.pem
# Verify the certificate chain, for Microsoft Azure operated by 21Vianet the intermediate certificate will be from DigiCert Global Root CA
openssl verify -verbose -CAfile /etc/ssl/certs/DigiCert_Global_Root.pem -untrusted intermediate.pem signer.pem
The nonce in the signed document can be compared if you provided a nonce parameter in the initial request.
Managed identity
A managed identity, assigned by the system, can be enabled on the VM. You can also assign one or more user-assigned managed identities to the VM.
You can then request tokens for managed identities from IMDS. Use these tokens to authenticate with other Azure services, such as Azure Key Vault.
When you place virtual machine or virtual machine set instances behind an Azure Standard Load Balancer, you can use IMDS to retrieve metadata related to the load balancer and the instances. For more information, see Retrieve load balancer information.
Scheduled events
You can obtain the status of the scheduled events by using IMDS. Then the user can specify a set of actions to run upon these events. For more information, see Scheduled events for Linux or Scheduled events for Windows.
Sample code in different languages
The following table lists samples of calling IMDS by using different languages inside the VM:
I'm getting the error 400 Bad Request, Required metadata header not specified. What does this mean?
IMDS requires the header Metadata: true to be passed in the request. Passing this header in the REST call allows access to IMDS.
Why am I not getting compute information for my VM?
Currently, IMDS only supports instances created with Azure Resource Manager.
I created my VM through Azure Resource Manager some time ago. Why am I not seeing compute metadata information?
If you created your VM after September 2016, add a tag to start seeing compute metadata. If you created your VM before September 2016, add or remove extensions or data disks to the VM instance to refresh metadata.
Is user data the same as custom data?
User data offers the similar functionality to custom data, allowing you to pass your own metadata to the VM instance. The difference is, user data is retrieved through IMDS, and is persistent throughout the lifetime of the VM instance. Existing custom data feature will continue to work as described in this article. However you can only get custom data through local system folder, not through IMDS.
Why am I not seeing all data populated for a new version?
If you created your VM after September 2016, add a tag to start seeing compute metadata. If you created your VM before September 2016, add or remove extensions or data disks to the VM instance to refresh metadata.
Why am I getting the error 500 Internal Server Error or 410 Resource Gone?
Retry your request. For more information, see Transient fault handling. If the problem persists, create a support issue in the Azure portal for the VM.
Would this work for scale set instances?
Yes, IMDS is available for scale set instances.
I updated my tags in my scale sets, but they don't appear in the instances (unlike single instance VMs). Am I doing something wrong?
Currently tags for scale sets only show to the VM on a reboot, reimage, or disk change to the instance.
Why am I'm not seeing the SKU information for my VM in instance/compute details?
For custom images created from Azure Marketplace, Azure platform doesn't retain the SKU information for the custom image and the details for any VMs created from the custom image. This is by design and hence not surfaced in the VM instance/compute details.
Why is my request timed out (or failed to connect) for my call to the service?
Metadata calls must be made from the primary IP address assigned to the primary network card of the VM. Additionally, if you've changed your routes, there must be a route for the 169.254.169.254/32 address in your VM's local routing table.
Verify that a route exists for 169.254.169.254, and note the corresponding network interface (for example, 172.16.69.7).
Dump the interface configuration and find the interface that corresponds to the one referenced in the routing table, noting the MAC (physical) address.
Confirm that the interface corresponds to the VM's primary NIC and primary IP. You can find the primary NIC and IP by looking at the network configuration in the Azure portal, or by looking it up with the Azure CLI. Note the private IPs (and the MAC address if you're using the CLI). Here's a PowerShell CLI example:
Azure PowerShell
$ResourceGroup = '<Resource_Group>'$VmName = '<VM_Name>'$NicNames = az vm nic list --resource-group$ResourceGroup --vm-name$VmName | ConvertFrom-Json | Foreach-Object { $_.id.Split('/')[-1] }
foreach($NicNamein$NicNames)
{
$Nic = az vm nic show --resource-group$ResourceGroup --vm-name$VmName --nic$NicName | ConvertFrom-JsonWrite-Host$NicName, $Nic.primary, $Nic.macAddress
}
Output
wintest767 True 00-0D-3A-E5-1C-C0
If they don't match, update the routing table so that the primary NIC and IP are targeted.
Dump your local routing table with a command such as netstat -r and look for the IMDS entry (e.g.):
If you're using a dynamic IP, note the MAC address. If you're using a static IP, you may note the listed IP(s) and/or the MAC address.
Confirm that the interface corresponds to the VM's primary NIC and primary IP. You can find the primary NIC and IP by looking at the network configuration in the Azure portal, or by looking it up with the Azure CLI. Note the private IPs (and the MAC address if you're using the CLI). Here's a PowerShell CLI example:
Azure PowerShell
$ResourceGroup = '<Resource_Group>'$VmName = '<VM_Name>'$NicNames = az vm nic list --resource-group$ResourceGroup --vm-name$VmName | ConvertFrom-Json | Foreach-Object { $_.id.Split('/')[-1] }
foreach($NicNamein$NicNames)
{
$Nic = az vm nic show --resource-group$ResourceGroup --vm-name$VmName --nic$NicName | ConvertFrom-JsonWrite-Host$NicName, $Nic.primary, $Nic.macAddress
}
Output
ipexample606 True 00-0D-3A-E4-C7-2E
If they don't match, update the routing table such that the primary NIC/IP are targeted.
Fail over clustering in Windows Server
When you're querying IMDS with failover clustering, it's sometimes necessary to add a route to the routing table. Here's how:
Open a command prompt with administrator privileges.
Run the following command, and note the address of the Interface for Network Destination (0.0.0.0) in the IPv4 Route Table.
bat
route print
Note
The following example output is from a Windows Server VM with failover cluster enabled. For simplicity, the output contains only the IPv4 Route Table.
Overview of common error codes and corresponding mitigation methods for Azure Instance Metadata Service (IMDS) when retrieving load balancer information.
Hariharan Jayaraman joins Scott Hanselman to talk about the Azure Instance Metadata Service, which provides information about running virtual machine instances that you can use to manage and configure your virtual machines. Use the service to get information such as SKU, network configuration, and upcoming maintenance events. For more information, see: Azure Instance Metadata service (docs) General Availability of Instance Metadata Service in Global Azure Regions (blog post) Leverage Azure instance metadat