Retrieving instance metadata
Because your instance metadata is available from your running instance, you do not need to use the Amazon EC2 console or the AWS CLI. This can be helpful when you're writing scripts to run from your instance. For example, you can access the local IP address of your instance from instance metadata to manage a connection to an external application.
Instance metadata is divided into categories. For a description of each instance metadata category, see Instance metadata categories.
To view all categories of instance metadata from within a running instance, use the following URI.
http://169.254.169.254/latest/meta-data/The IP address 169.254.169.254 is a link-local address and is valid only
from the instance. For more information, see Link-local address
Note that you are not billed for HTTP requests used to retrieve instance metadata and user data.
The command format is different, depending on whether you use IMDSv1 or IMDSv2. By default, you can use both instance metadata services. To require the use of IMDSv2, see Configuring the instance metadata service.
You can use a tool such as cURL, as shown in the following example.
You can also download the Instance Metadata Query
tool
Responses and error messages
All instance metadata is returned as text (HTTP content type
text/plain).
A request for a specific metadata resource returns the appropriate value, or a
404 - Not Found HTTP error code if the resource is not available.
A request for a general metadata resource (the URI ends with a /) returns a list
of available resources, or a 404 - Not Found HTTP error code if there
is no such resource. The list items are on separate lines, terminated by line
feeds
(ASCII 10).
For requests made using Instance Metadata Service Version 2, the following HTTP error codes can be returned:
-
400 - Missing or Invalid Parameters– ThePUTrequest is not valid. -
401 - Unauthorized– TheGETrequest uses an invalid token. The recommended action is to generate a new token. -
403 - Forbidden– The request is not allowed or the instance metadata service is turned off.
Examples of retrieving instance metadata
Examples
Get the available versions of the instance metadata
This example gets the available versions of the instance metadata. These versions do not necessarily correlate with an Amazon EC2 API version. The earlier versions are available to you in case you have scripts that rely on the structure and information present in a previous version.
Get the top-level metadata items
This example gets the top-level metadata items. For more information, see Instance metadata categories.
The following examples get the values of some of the top-level metadata items that were obtained in the preceding example. The IMDSv2 requests use the stored token that was created in the preceding example command, assuming it has not expired.
Get the list of available public keys
This example gets the list of available public keys.
Show the formats in which public key 0 is available
This example shows the formats in which public key 0 is available.
Get public key 0 (in the OpenSSH key format)
This example gets public key 0 (in the OpenSSH key format).
Get the subnet ID for an instance
This example gets the subnet ID for an instance.
Throttling
We throttle queries to the instance metadata service on a per-instance basis, and we place limits on the number of simultaneous connections from an instance to the instance metadata service.
If you're using the instance metadata service to retrieve AWS security credentials, avoid querying for credentials during every transaction or concurrently from a high number of threads or processes, as this might lead to throttling. Instead, we recommend that you cache the credentials until they start approaching their expiry time.
If you are throttled while accessing the instance metadata service, retry your query with an exponential backoff strategy.
Limiting instance metadata service access
You can consider using local firewall rules to disable access from some or all processes to the instance metadata service.
Using iptables to limit access
The following example uses Linux iptables and its owner module to
prevent the Apache webserver (based on its default installation user ID of
apache) from accessing 169.254.169.254. It uses a deny rule to reject all instance metadata requests
(whether IMDSv1 or IMDSv2) from any process running as that
user.
$sudo iptables --append OUTPUT --proto tcp --destination 169.254.169.254 --match owner --uid-owner apache --jump REJECT
Or, you can consider only allowing access to particular users or groups, by using allow rules. Allow rules might be easier to manage from a security perspective, because they require you to make a decision about what software needs access to instance metadata. If you use allow rules, it's less likely you will accidentally allow software to access the metadata service (that you did not intend to have access) if you later change the software or configuration on an instance. You can also combine group usage with allow rules, so that you can add and remove users from a permitted group without needing to change the firewall rule.
The following example prevents access to the instance metadata service by all
processes, except for processes running in the user account
trustworthy-user.
$sudo iptables --append OUTPUT --proto tcp --destination 169.254.169.254 --match owner ! --uid-ownertrustworthy-user--jump REJECT
-
To use local firewall rules, you need to adapt the preceding example commands to suit your needs.
-
By default, iptables rules are not persistent across system reboots. They can be made to be persistent by using OS features, not described here.
-
The iptables
ownermodule only matches group membership if the group is the primary group of a given local user. Other groups are not matched.
Using PF or IPFW to limit access
If you are using FreeBSD or OpenBSD, you can also consider using PF or IPFW. The following examples limit access to the instance metadata service to just the root user.
PF
$block out inet proto tcp from any to 169.254.169.254
$pass out inet proto tcp from any to 169.254.169.254 user root
IPFW
$allow tcp from any to 169.254.169.254 uid root
$deny tcp from any to 169.254.169.254
The order of the PF and IPFW commands matter. PF defaults to last matching rule and IPFW defaults to first matching rule.
