AWS Lambdaが実行AZを返すように：同一AZルーティングの設計と落とし穴

公開日 2026.10.10 更新日 2026.10.10 AWS Lambda Availability Zone ElastiCache レイテンシー

AWS LAMBDA / AZ-AWARE ROUTING

Lambdaは「今いるAZ」を知れる

処理を同じアベイラビリティーゾーン（AZ）の読み取り先へ寄せる。ただし近さよりも、接続の正しさと可用性を優先する。

3行で要約

AWSは2026年10月9日付の公式ブログで、Lambda実行環境からAZ IDを取得するメタデータエンドポイントを紹介した。これは記事の公開日であり、全リージョン一斉の提供開始日を示すものではない。^[1]
認証付きHTTP GETでAvailabilityZoneIDを読み、同じAZにあるキャッシュや読み取りレプリカを優先できる。AWSはAZ間通信の遅延・転送費用を抑える用途を挙げるが、効果は構成と通信量次第だ。^[1][2]
AZ IDで比較し、健全な別AZへの退避経路を残す。 SnapStart利用時は復元先のAZが変わり得るため、初期化時の値を無条件に使い回さない。^[1][2]

背景：Lambdaの実行場所はアプリから見えなかった

AWS Lambdaは可用性のため、実行環境をリージョン内の複数AZに配置する。一方、ElastiCacheのノードやRDSの読み取りレプリカはAZごとに位置が決まる。従来はLambda側の実行AZを確実に取得できず、同一AZに読み取りを寄せる設計が難しかった。AZをまたぐ通信には追加遅延が生じ、料金が発生する場合もある。^[1]

何が新しいのか

Lambdaは各実行環境にAWS_LAMBDA_METADATA_API（接続先）とAWS_LAMBDA_METADATA_TOKEN（認証トークン）を設定する。アプリはBearerトークン付きGETで/2026-01-15/metadata/execution-environmentを呼び、{"AvailabilityZoneID":"use1-az1"}のようなJSONを受け取る。Python、TypeScript、Java、.NETではPowertoolsのユーティリティーも使える。AWSによれば追加料金なしで商用AWSリージョンに提供され、カスタムランタイム、コンテナイメージ、VPC接続、SnapStart、Provisioned Concurrencyにも対応する。^[1][2]

GET + Bearer環境ごとのトークンで認証

AZ IDアカウントをまたいでも同じ物理AZを示す

12時間通常の応答はmax-age=43200

技術的なポイント：名前ではなくIDを使う

us-east-1aのようなAZ名は、アカウントによって異なる物理AZを指す場合がある。use1-az1のようなAZ IDはアカウント間で同じ物理AZを示す。別アカウントのキャッシュやサービスと位置を比べるならIDで照合する。AZ名が必要なAPIには、権限ec2:DescribeAvailabilityZonesを付けて変換できる。^[1][2]

1. 位置を取得Lambda実行環境のAZ ID

2. 健全性を確認同じAZの読み取り先を優先

3. 退避不在・障害なら別AZへ

同一AZ優先が向く経路と注意点
接続先	期待できること	守るべき条件
ElastiCacheノード	頻繁な読み取りのAZ間通信を減らす	障害・再配置時には別ノードへ退避
RDS/Auroraの読み取りレプリカ	同一AZのレプリカを優先	書き込み先はプライマリ。整合性要件を確認
MemoryDBのレプリカ	読み取り中心の処理を局所化	書き込み直後の読み取りは複製遅延に注意

開発者・企業への影響と導入例

影響が大きいのは、キャッシュ参照などを高頻度に繰り返す低遅延ワークロードだ。AWSのブログは同一AZへの誘導で遅延やAZ間転送費用を減らせると説明する。ただし、何ミリ秒・何％改善するかは公式の一律保証値ではない。自社のp95/p99遅延、AZ間転送量、接続失敗率で判断したい。^[1]

まずはルーティングを変えず、Lambda内でAZ IDを読めることを確認する。以下はAWS公式仕様に沿ったPython標準ライブラリの最小例で、トークンをログに出さない。実行環境外では環境変数が存在しない。^[2]

import json
import os
from urllib.request import Request, urlopen

def current_az_id():
    endpoint = "http://" + os.environ["AWS_LAMBDA_METADATA_API"]
    endpoint += "/2026-01-15/metadata/execution-environment"
    request = Request(endpoint, headers={
        "Authorization": "Bearer " + os.environ["AWS_LAMBDA_METADATA_TOKEN"]
    })
    with urlopen(request, timeout=1) as response:
        return json.load(response)["AvailabilityZoneID"]

次に、AZ IDと健全な読み取り先の対応表を用意する。同一AZの接続先が見つからない、またはヘルスチェックで不健全なら、別AZの健全な接続先に切り替える。切替時はコネクションプールの再接続、タイムアウト、再試行上限も試験する。ローカル優先は可用性を犠牲にする強制経路ではない。^[1]

リスクと限界

トークンは実行環境内だけで扱い、ログや外部への転送を避ける。トークンが無い・誤っている場合は401、GET以外は405を返す。^[2]
同一AZの接続先が無い構成もある。フェイルオーバー時に別AZへ到達できることを優先する。
書き込み先や強い整合性が必要な読み取りは、単純に近いレプリカへ送らない。MemoryDB等の非同期複製では読み取り結果が古い場合がある。^[1]
メタデータを毎回呼ばずキャッシュする。ただしSnapStart復元後は更新する。通常応答のmax-age=43200を、復元時にも絶対に有効な値と解釈しない。^[1][2]

今後注目したい点

導入前後のp95/p99、AZ間データ転送量、障害時の成功率を同じ負荷条件で比較したい。AWSの説明から「局所化が効く経路ほど便益が大きい」と推測できるが、実測なしに削減額を断定できない。AZを一つ失った場合にも別AZへ自然に退避するかが、本番投入の判定点になる。

最終確認日：2026年10月10日（日本時間）

参照元

AWS Compute Blog：Reducing cross-AZ latency with the AWS Lambda metadata endpoint — 2026年10月9日付の公式解説。
AWS Lambda Developer Guide：Using the Lambda metadata endpoint — API仕様、環境変数、AZ ID、キャッシュとSnapStartの挙動。

Previous Post Next Post