Using the Lambda metadata endpoint
The Lambda metadata endpoint lets your functions discover which Availability Zone (AZ) they are running in, enabling you to optimize latency by routing to same-AZ resources like Amazon ElastiCache and Amazon RDS endpoints, and to implement AZ-aware resilience patterns.
The endpoint returns metadata in a simple JSON format through a localhost HTTP API within the execution environment and is accessible to both runtimes and extensions.
Getting started
Powertools for AWS Lambda provides a utility for accessing the Lambda metadata endpoint in Python, TypeScript, Java, and .NET. The utility caches the response after the first call and handles SnapStart cache invalidation automatically.
Use the Powertools for AWS Lambda metadata utility or call the metadata endpoint directly
Understanding Availability Zone IDs
AZ IDs (for example, use1-az1) always refer to the same physical location across all AWS accounts,
while AZ names (for example, us-east-1a) may map to different physical infrastructure in each AWS
account in certain regions. For more information, see
AZ IDs for cross-account consistency.
Converting AZ ID to AZ name:
To convert an AZ ID to an AZ name, use the Amazon EC2
DescribeAvailabilityZones
API. To use this API, add the ec2:DescribeAvailabilityZones permission to your function's execution role.
API reference
Environment variables
Lambda automatically sets the following environment variables in every execution environment:
-
AWS_LAMBDA_METADATA_API– The metadata server address in the format{ipv4_address}:{port}(for example,169.254.100.1:9001). -
AWS_LAMBDA_METADATA_TOKEN– A unique authentication token for the current execution environment. Lambda generates this token automatically at initialization. Include it in all metadata API requests.
Endpoint
GET http://${AWS_LAMBDA_METADATA_API}/2026-01-15/metadata/execution-environment
Request
Required headers:
-
Authorization– The token value from theAWS_LAMBDA_METADATA_TOKENenvironment variable with the Bearer scheme:Bearer <token>. This token-based authentication provides defense in depth protection against Server-Side Request Forgery (SSRF) vulnerabilities. Each execution environment receives a unique, randomly generated token at initialization.
Response
Status: 200 OK
Content-Type: application/json
Cache-Control: private, max-age=43200, immutable
The response is immutable within an execution environment. Clients should cache the response and respect
the Cache-Control TTL. For SnapStart functions, the TTL is reduced during initialization so that
clients refresh metadata after restore when the execution environment may be in a different AZ. If you use
Powertools, caching and SnapStart invalidation are handled automatically.
Body:
{ "AvailabilityZoneID": "use1-az1" }
The AvailabilityZoneID field contains the unique identifier for the Availability Zone
where the execution environment is running.
Note
Additional fields may be added to the response in future updates. Clients should ignore unknown fields and not fail if new fields appear.
Error responses
-
401 Unauthorized – The
Authorizationheader is missing or contains an invalid token. Verify you are passingBearer ${AWS_LAMBDA_METADATA_TOKEN}. -
405 Method Not Allowed – Request method is not
GET. -
500 Internal Server Error – Server-side processing error.