You’ve been chasing a latency bug for three days. You’ve gone through every layer of your stack like a detective rifling through filing cabinets. Traces, metrics, profiler, database query plans. Everything checks out. Your logic is clean. Your indexes are pristine. Your queries return in microseconds. And yet your API feels like it’s wading through mud.
I’ve been there. That feeling when you’ve exhausted every optimization in the playbook and your P99 latency is still making you look bad in the weekly performance review. You’ve tried paging. You’ve considered swapping protocols. Maybe gRPC instead of REST? But then you remember your frontend needs to consume this data and you’re not about to introduce a proxy layer for the sake of shaving off a few milliseconds. So you sit there, staring at your CloudWatch dashboard, wondering what you’re missing.
Here’s what you’re missing. Network hops between availability zones.
The problem nobody talks about
Let’s break this down to first principles. When your Lambda function talks to your RDS instance or your DynamoDB table, that traffic has to go somewhere physically. It goes over the wire, through routers, across availability zone boundaries. And every time it crosses an AZ boundary, you pay a tax. Not a huge one. We’re talking 2 to 5 milliseconds per round trip.
„Two milliseconds? That’s nothing.“ I hear you. But let’s do the math.
Say you have a write request that involves 5 transactional steps. Each step needs a round trip to the database. That’s 10 to 25 milliseconds of pure network overhead just because your compute and your storage happen to be sitting in different data centers. And that’s the happy path. Under load, when the network gets congested, those numbers get worse. Way worse.
Now look at your P99. Not your median. Your P99. That’s where this stuff really hurts. I’ve seen cross-AZ latency spikes in the range of 200 to 400 milliseconds at the tail. That’s not a small hiccup. That’s the difference between your user thinking „this app is snappy“ and „this app is broken.“
Same AZ, same party
When your Lambda function and your database live in the same availability zone, they share the local data center network. And that local network is absurdly fast. We’re talking 0.05 milliseconds or less per hop. It’s not even in the same ballpark. It’s not even the same sport.
So those 5 transactional steps? Instead of 10 to 25 milliseconds of network overhead, you’re looking at maybe 0.25 milliseconds total. That’s a 40x to 100x improvement on the network layer alone. And at the P99, the difference is even more dramatic because you’re no longer subject to the variance of cross-AZ traffic.
Why this was impossible before
Here’s the thing that frustrated me about AWS Lambda for years. You had zero control over where your function ran. AWS would spin it up in whatever AZ it felt like, and you just had to deal with it. Your database is in us-east-1a? Cool, your Lambda might run in us-east-1c. Enjoy your cross-AZ round trips.
This meant that even if you architected everything perfectly, even if your queries were optimized to hell and back, even if your code was the most efficient thing ever written, you were still at the mercy of the network topology. And you couldn’t do a damn thing about it.
That changes now.
What AWS actually shipped
AWS Lambda functions are now availability zone aware. You can configure your function to run in a specific AZ, or more practically, in the same AZ as your data layer. That’s it. That’s the feature. A configuration change.
And honestly, the simplicity is what makes this so good. You don’t need to refactor your code. You don’t need to change your architecture. You don’t need to migrate anything. You flip a config, and suddenly your Lambda is co-located with your database, sharing the same local network, cutting out all that cross-AZ overhead.
The cascade effect
This isn’t just about latency though. Think about what happens when your responses are faster.
Your Lambda runs for less time. You pay for Lambda by the millisecond. Less time means less money. That’s a direct cost reduction without changing a single line of code.
Your connections to the database are shorter-lived. That means less connection pool pressure. Less chance of connection exhaustion under load. Fewer timeout errors. Fewer retries.
Fewer retries means less load on your database. Less load means better performance for everyone else. It’s a virtuous cycle.
And on the reliability side, keeping traffic within a single AZ means fewer failure points. Cross-AZ traffic has to traverse more infrastructure. More infrastructure means more things that can fail. Staying local reduces your blast radius.
The part nobody wants to hear
Here’s the honest take. If you’re running Lambda functions that talk to databases and you haven’t been thinking about AZ placement, you’ve been leaving performance and money on the table. Not because you’re bad at your job. Because the tooling didn’t let you do anything about it until now.
But now it does. And it’s just a configuration change. No excuses anymore.
Go check your cross-AZ data transfer costs while you’re at it. I bet they’re higher than you think. AWS charges for cross-AZ traffic, and if your Lambda has been bouncing between zones on every invocation, those charges add up fast.
What you should do right now
Seriously, go look at your Lambda configurations. If you have functions that are latency-sensitive and talk to RDS, DynamoDB, ElastiCache, or any data store with a fixed AZ placement, pin your Lambda to the same zone. It takes five minutes. The improvement shows up immediately in your metrics.
The best performance optimizations are the ones that don’t require you to rewrite anything. This is one of those rare wins where you get faster responses, lower costs, better reliability, and all you had to do was update a config.
Sometimes the biggest wins aren’t clever algorithms or architectural breakthroughs. Sometimes it’s just putting two things in the same room so they can talk without shouting across the building.
Peace, nerds.