My Mental Model of AWS Regions
Usually when I talk about AWS regions and availability zones, it ties back to data transfer pricing or some other model of cloud economics. Today I want to take a different angle: it’s my belief that how I think about AWS regions and how AWS talks about them are somewhat far apart. The reason I’m doing this in blog form instead of as a Twitter stunt or whatnot is that I’m not particularly intending to be funny, and to be transparent, I’m not completely sure whether I’m right or not. Let’s dive in.
Set the (Region) Table
AWS talks about regions a lot. On their global infrastructure page they lay out what a region is. They periodically announce regional expansions of services and features (admittedly, it’s often hard to tell the difference between the two where AWS is concerned) as if they were completely new offerings rather than simply being offered in a new location.
The Technical Perspective
Recently I found myself thinking about regions in a couple of different ways. The first incident that brought the topic to mind was my Last Tweet in AWS Twitter thread client. The thing is completely stateless and, while it works super quickly from us-west-2 in Oregon for me here in San Francisco, folks reported that the further away you got the more degraded the experience was due to latency.
“Aha!” said I. “Since it’s completely stateless aside from a couple of secrets provisioned at deploy-time, I could deploy it to every AWS region at once and just add the resulting APIs Gateway to a Route 53 latency routed record. Boom, done.”
Unfortunately every Solutions Architect I asked about the best way to proceed to do that looked at me as if I’d lost my mind entirely.
It turns out that just because AWS has (at time of this writing) 26 launched regions, it doesn’t mean that AWS envisions any given customer or workload using more than a small handful of them. The idea of deploying something to every region just isn’t a part of their model. While I could do deployments via CodeBuild in series (it would take hours) or via some kind of Step Function state machine (I would need to be at least four times smarter than I am), there’s absolutely nothing out of the box that lets me cross into other regions natively to do deployments. This is pretty clearly derived from the AWS design principle that keeps regions as separate entities so an outage in one (ideally) doesn’t carry over into other regions.
The Business Perspective
The second thing that impacted my perception of regions was a tweet from Colm MacCárthaigh that said “Not to give away our super secret strategy but something that people often under appreciate about AWS is that new regions are by far the biggest needle mover for our business. The speed of light, sovereignty, and data locality all matter!”
While obviously there’s significant business benefit derived from region buildouts (otherwise AWS would, y’know, not build more of them), it hadn’t occurred to me that it would be such a significant driver of growth for AWS’s business. To my mind, the benefits of a new region opening distill down to data residency requirements for customers in that country who can’t have data leave that country, and decreased latency for applications hosted in that region to customers located near it. It hadn’t really occurred to me that it unlocked the cloud for completely new swaths of customers.
And something about that didn’t sit quite right to me, so I did some thinking.
Regions as Alternate Clouds
If you take a look at AWS’s regional services list it purports to show what services are available in a given region. This… doesn’t help you choose a region based upon service maturity, since you’d have to select a region, scroll for days, to check a service, then repeat for a second region. The way it used to look and function was far batter; fortunately Trek10’s interns (not kidding) were able to recreate it at awsservices.info. This lets you show how many services are available in other regions at the same time.
The interesting bit to me about this is that your experience in a relatively mainstream region such as Virginia and/or Oregon is going to be wildly different than the service coverage in Bahrain. What’s worse is that as the webpage states, “note: Just because a service is listed as being available in a region does not mean that every part or every feature of a service is available in that region.” If a service gets a feature or capability, that’s not enough for you if you’re in a “non-primary” region. You’ve gotta wait for that feature to make it all the way to the region that you’re using, and there’s no good way to figure out what features have made it your way without checking on all of them independently.
As a result, I’m starting to realize that using non-primary AWS regions is effectively like using a different cloud provider in some respects. It’s usually more expensive, the capabilities are dminished, and while in theory you have better insight into what’s coming your way, in practice you’re not guaranteed anything resembling a timeline. Heck, Amazon Kendra was released years ago and is still not available in the Northern California AWS region.
The Takeaway
All of this serves to reinforce what I once considered to be a throwaway line, but I’m starting to realize is more insightful than perhaps I gave it credit for being. Specifically “if you’re planning to go multi-cloud, first go multi-region and see if you might learn something.” It’s harder than it looks, you’ll find very-hard-to-predict service differences between regions, and you’ll undoubtedly learn an awful lot about your workload’s dependencies as you go through the process.
This isn’t intended to be overly cynical, and I don’t mean to suggest that AWS is intentionally misleading anybody. I’m simply wondering here if maybe there’s a fundamental disconnect somewhere in the story of how we talk and think about different regions. As always, your region may vary; if you disagree with anything I’m saying here, please reach out–but only after trying it first in us-west-2.
