Back in March, AWS quietly shipped something that I think deserves way more attention than it got: Lambda now exposes Availability Zone metadata.
That means your function can finally know which AZ it's running in. And once you know that, you can start making much smarter routing decisions — the kind that cut latency and save you money.
Here's the announcement if you missed it: AWS Lambda now supports Availability Zone metadata
How it works
There's a new metadata endpoint available inside the Lambda execution environment. You hit it, and you get back the AZ ID (something like use1-az1).
If you're already using Powertools for AWS Lambda, it's literally one line of code:
const { AvailabilityZoneID: azId } = await getMetadata()
That's it. No custom hacks. No environment variable gymnastics. Just a clean metadata call.
It works across all runtimes — Node, Python, Java, custom runtimes, container images, you name it. It also plays nicely with SnapStart and provisioned concurrency, and it doesn't matter whether your function lives inside a VPC or not.
OK, but why should I care?
Here's the thing. If your Lambda function talks to ElastiCache, RDS, or any other service that has AZ-specific endpoints, this changes the game.
When your function routes to a node in the same AZ, two things happen:
- Latency drops significantly. Cross-AZ hops add real milliseconds. For most workloads, that's fine, but if you're chasing p99 latency, those extra milliseconds hurt.
- You stop paying cross-AZ data transfer fees. Traffic that stays within the same AZ is cheaper. At scale, this adds up fast.
So if you're running a high-throughput workload where your Lambda functions are constantly hitting a cache or database, same-AZ routing is basically free performance and cost savings.
A practical example
Let's say you have an ElastiCache Redis cluster spread across three AZs. Before this update, your Lambda function had no idea which AZ it was in, so it just connected to... whatever endpoint you configured. Maybe that was in the same AZ, maybe it wasn't. Pure luck.
Now you can do something like this:
const { AvailabilityZoneID: azId } = await getMetadata()
// Pick the Redis endpoint in the same AZ
const redisEndpoint = redisEndpoints[azId] || redisEndpoints.default
const client = createRedisClient(redisEndpoint)
Simple. Deterministic. No more rolling the dice on network hops.
Chaos engineering gets easier too
Here's a bonus use case that I'm genuinely excited about: AZ fault injection.
If you want to simulate what happens when a single AZ goes down, you now have the info you need. Your function knows its AZ, so you can selectively fail or reroute traffic from a specific AZ and watch what happens.
Before this, testing AZ-level resilience in a serverless setup was painful. Now it's just... a metadata call and some conditional logic.
Conclusion
This is one of those small features that won't make headlines but quietly makes serverless architectures more capable. For teams operating at scale or optimising for tail latency, it's a meaningful improvement.
No extra cost. Works everywhere Lambda runs. And if you're using Powertools, it's one line of code.
