![[アップデート] AWS Lambda関数の実行環境がどのAZで動作しているかを取得できるメタデータエンドポイントが追加されました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-484d8afca1cbe50513cd4d6738af2960/fa0838fa40f247093d532945fc785e88/aws-lambda?w=3840&fm=webp)
[アップデート] AWS Lambda関数の実行環境がどのAZで動作しているかを取得できるメタデータエンドポイントが追加されました
はじめに
おのやんです。
AWS Lambdaで、関数の実行環境がどのAZで動作しているかを取得できるメタデータエンドポイントが追加されました。
これまでLambda関数では、自身がどのAZで実行されていたかを直接確認する方法がありませんでした。今回のアップデートにより、関数内からHTTPリクエスト1回でAZ IDを取得できます。
今回取得できるようになったのは、AZ名（ap-northeast-1a）ではなくAZ ID（apne1-az1）の方です。AZ名は、裏側ではアカウントごとに異なる物理AZにマッピングされる場合がありますが、AZ IDは全AWSアカウントで同じ物理AZを指します。
EC2インスタンスでは、インスタンスメタデータサービスを使ってcurl http://169.254.169.254/latest/meta-data/placement/availability-zone-idのようにAZ IDを取得できます。ECSやEKSでもコンテナメタデータやNode Labelsから（変換は必要ですが）AZ情報を取得する手段がありました。
しかしLambda関数には、EC2のインスタンスメタデータサービスに相当する仕組みがなく、AZ情報を取得する公式な手段がありませんでした。日本語・英語ともに反映されていないのか、記事執筆時点のAWSホワイトペーパーに、Lambda関数のAZを推定するために以下のような手順が紹介されていました。
Lambda — アベイラビリティーゾーンは関数に直接公開されません。これを見つけるには、いくつかのステップを完了する必要があります。そのために、リクエスタの IP アドレスを返すプライベート API ゲートウェイ REST エンドポイントを構築する必要があります。これにより、関数が使用している Elastic Network Interface に割り当てられたプライベート IP が識別されます。
- Lambda GetFunction API を呼び出して、関数の VPC ID を見つけます。
- API Gateway サービスを呼び出して、関数の IP を取得します。
- IP と VPC ID を使用して、関連するネットワークインターフェイスを見つけ、アベイラビリティーゾーンを抽出します
それが、今回のアップデートによりAZ IDを直接取得できるようになっています。
具体的には、Lambda実行環境に新たに2つの環境変数が自動設定されています。
| 環境変数 | 概要 |
|---|---|
AWS_LAMBDA_METADATA_API |
メタデータサーバーのアドレス（{ipv4}:{port}形式） |
AWS_LAMBDA_METADATA_TOKEN |
実行環境ごとに固有の認証トークン |
このようなHTTPリクエストでAZ IDを取得できます。
GET http://${AWS_LAMBDA_METADATA_API}/2026-01-15/metadata/execution-environment
やってみた
ということで、実際にLambda関数を作成し、メタデータエンドポイントからAZ IDを取得してみます。
まずはLambda関数を作成します。このような感じで、メタデータエンドポイントにHTTPリクエストを送信してAZ IDを取得します。
import json
import os
import urllib.request
def handler(event, context):
metadata_api = os.environ.get("AWS_LAMBDA_METADATA_API")
metadata_token = os.environ.get("AWS_LAMBDA_METADATA_TOKEN")
if not metadata_api or not metadata_token:
return {
"statusCode": 500,
"body": json.dumps({"error": "Metadata environment variables not available"})
}
url = f"http://{metadata_api}/2026-01-15/metadata/execution-environment"
req = urllib.request.Request(
url,
headers={"Authorization": f"Bearer {metadata_token}"}
)
with urllib.request.urlopen(req) as response:
metadata = json.loads(response.read().decode())
return {
"statusCode": 200,
"body": json.dumps({
"availability_zone_id": metadata.get("AvailabilityZoneID"),
"function_name": context.function_name,
"request_id": context.aws_request_id
})
}
デプロイしたLambda関数を実行したら、このようにAZ IDが返ってきました。availability_zone_idにapne1-az1のようなAZ IDが返されていることを確認できます。
{
"statusCode": 200,
"body": "{\"availability_zone_id\": \"apne1-az1\", \"function_name\": \"aws-test-func-lambda-az-metadata\", \"request_id\": \"edfd209a-b926-4bff-a77e-8d75637c3225\"}"
}
数分後に再びLambdaを起動すると、別のAZ ID（apne1-az2）が記録されていました。
{
"statusCode": 200,
"body": "{\"availability_zone_id\": \"apne1-az2\", \"function_name\": \"aws-test-func-lambda-az-metadata\", \"request_id\": \"033cf4b2-d7ad-4816-a471-3c1c06fee826\"}"
}
Lambdaでは、コールドスタート時には実行環境を作成する物理AZが自動的に決定されます。この動きが、今回のメタデータエンドポイント追加で確認できたという形ですね。
Lambda は、複数のアベイラビリティーゾーンで関数を実行し、1 つのゾーンでサービスの中断が発生した場合にも、関数をイベントの処理に使用できることを保証します。
AWS CLI経由でLambda関数を複数回実行して、異なる物理AZに配置されるか確認します。
for i in $(seq 1 10); do
aws lambda invoke \
--function-name "aws-test-func-lambda-az-metadata" \
--region ap-northeast-1 \
--payload '{}' \
/dev/stdout 2>/dev/null | jq -r '.body' | jq -r '.availability_zone_id'
done
同じAZ IDが返りました。同一の実行環境が再利用されていますね（nullは、関数のレスポンスとinvokeのメタデータのうち、'.body'のないinvokeメタデータがjqに引っ掛からなかったための出力です）。
apne1-az2
null
apne1-az2
null
apne1-az2
null
apne1-az2
null
apne1-az2
null
apne1-az2
null
apne1-az2
null
apne1-az2
null
apne1-az2
null
apne1-az2
null
まとめ
これまでLambda関数のAZ情報を取得するには、VPC接続や複数のAPI呼び出し、追加インフラという複雑な手順が必要でした。今回のアップデートにより、VPCの有無にかかわらず、HTTPリクエストでAZ IDを取得できるようになりました。
LambdaをAZ単位で監視したり、AZ障害テストを実施するなどのケースで役に立ちそうですね。では！
