Hacker News Reader

Comment by impulser_ | Hacker News Reader

Why does everyone keep deploying their products to this one region when it always seems like the one that fails?

We don't use big cloud were I work, so maybe I'm missing something. Does East-1 offer something other don't?

You generally want to use a region close to your users, so right off the bat, us-east-1 and us-east-2 are the obvious choices for most East Coast companies. If I were starting a new project, I'd probably go us-east-2, but if your company has been on the cloud long enough, us-east-2 might not have existed when your foundational infrastructure was created. And for most companies, going multi-region is an expensive, difficult proposition that might not be worth it.

Plus, as others have noted, there are critical AWS services in their control plan that only run in us-east-1 behind the scenes. So you're kind of out of luck.

There are some services (cloudfront for example) which require this region. Its not that much harder to have multiple regions in your deployment but putting everything in one is simpler for smaller startupy orgs.

It’s not required during an incident. The data for these services is globally replicated. It’s only if you need to make changes that you might be impacted if you’re already successfully operating out of another region.

There's a lot of software, iirc even Amazon's own dashboards, that simply defaults to us-east-1.

That's my favorite part of Amazon's console. That miniature heart attack you have when you ask "WHERE ARE ALL MY LAMBDAS AND DYNAMO INSTANCES?"

Then you realize that they just switched you back to us-east-1 for some reason and a wave of familiar relief washes over you.

Out of curiosity have you been building with the serverless framework? I'm curious what drives people to use dynamodb in particular

No, I really don't like any of the serverless or amplify type of frameworks that AWS produces.

What I needed was a distributed store for managing a large number of small configuration "files" and other state "links" across the infrastructure I built. In particular, I needed the ability for a write conflicts to be detected and managed immediately and for consistent reads to be available in some cases.

Looking at the size of data and number of transactions, DynamoDB on a per-request model was going to be significantly cheaper and easier than standing up a bunch of DB instances or other "fixed" infrastructure.

The ultimate model was to actually implement something like a POSIX filesystem on top of the "nosql" layer. In practice, I've been really happy with that decision, and it makes working on the code that interacts with this system very familiar and easy to understand. It's even got symlinks, acls, and automatically expiring advisory locks.

FWIW, mine defaults to Ohio. Has happened multiple times. IDK if it is geographic or what.

I used it because early on in the project I wanted to use features for IoT that were only available on us-east-1 initially, as well as lambda@edge which was on us-east-1 only at the time.

Instance types, for one. us-east-1 has all the latest instance types and more of them. We could not run some of our workloads in any other region.

Best latency from where almost 90% of my users are?

Features.

For example, do you want your Cloudfront CDN to have a custom (secure) domain?

Then you have to host your ACM cert in us-east-1.

If you’ve already set up your ACM cert, you won’t be impacted during an incident in us-east-1. It’s only if you need to make changes that you could be impacted.

It has the best latency from Chile and I think from other countries of South America

It's dirt cheap.

But I still prefer EU region =).

Anecdotal with n=2 sample, but GPU availability seems better in us-east-1.

Because $$$

Reply on news.ycombinator.com