2 ms·

Man, I did not have "AWS us-east-1 will only have TWO 9s this year" on my bingo card.

aurumque 1y ago
For those of us who have been using AWS for almost 20 years now, I can't imagine why anyone would willingly choose us-east-1 for anything. It is the oldest, highest traffic, most critical path region and is subject to turbulence.
- morshu9001 1y ago
  It can make sense to depend on the thing that will attract massive worldwide attention if/when it goes down. Or, more likely, it's just a default people don't change.
- interroboink 1y ago
  By some logic, that would mean it is the most battle-tested and highest-stakes (and therefore most carefully-managed) choice. I.e. reasons in favor. Not that I disagree with you, but maybe not for the reasons you say (:
  - swiftcoder 1y ago
    > By some logic, that would mean it is the most battle-tested and highest-stakes (and therefore most carefully-managed) choice As someone who used to work on the inside, us-east-1 has the biggest pile of legacy workarounds for internal AWS issues, it has a variety of legacy API behaviours that don't exist in other regions, and because everyone picks it as the default, it has significantly more pressure on contested resources (i.e. things like spot instance pools). Plus since it's the default in all the tooling, if you ever decide to go multi-region, you'll find tons of things break right away.
- tlogan 1y ago
  I think it is a little complicated. For example, your service might be using full failover but you use API from other service which are down. Or you might use BART to come to work and you got stuck: https://www.kqed.org/news/12060687/bart-resumes-service-but-delays-remain-after-another-major-disruption https://www.kqed.org/news/12060687/bart-resumes-service-but-...
  - dingnuts 1y ago
    ha! I saw another comment on here talking about how ec2 doesn't need to be held to the same standard as the power company because it's not as important as real infrastructure. wish I'd already had this link in my back pocket. our industry needs to take its job, as a whole, much more seriously.
- captainkrtek 1y ago
  “Global” and “edge” services such as IAM, Route53, CloudFront and so on have dependencies on us-east-1, so even if you don’t think you do, you probably do.
- bongodongobob 1y ago
  Well, we didn't, but some of our third party softwares did. Hard to avoid.
TZubiri 1y ago
Wait, was the whole region affected? Like even if you had an EC2 instance?
- mads_quist 1y ago
  No, we run on US East 1 but only EC2. Everything was running smoothly!
  - mads_quist 1y ago
    Our strategy has always been to use as little higher abstractions from cloud providers as possible. Glad we went this way, saved us quite a bunch of SLA breaches today! I am confident to say that it's "best of both worlds". We get great availability zone redundancy by AWS without having to rely on and pay for all those PaaS stuff the cloud giants offer. Also, we can "fairly easy" migrate to any other cloud provider because we only need Debian instances running.
- bigstrat2003 1y ago
  Yes, it was. We have EC2 instances that we turn on as-needed, and at times were unable to start said instances.

For those of us who have been using AWS for almost 20 years now, I can't imagine why anyone would willingly choose us-east-1 for anything. It is the oldest, highest traffic, most critical path region and is subject to turbulence.

morshu9001 1y ago
It can make sense to depend on the thing that will attract massive worldwide attention if/when it goes down. Or, more likely, it's just a default people don't change.
interroboink 1y ago
By some logic, that would mean it is the most battle-tested and highest-stakes (and therefore most carefully-managed) choice. I.e. reasons in favor. Not that I disagree with you, but maybe not for the reasons you say (:
- swiftcoder 1y ago
  > By some logic, that would mean it is the most battle-tested and highest-stakes (and therefore most carefully-managed) choice As someone who used to work on the inside, us-east-1 has the biggest pile of legacy workarounds for internal AWS issues, it has a variety of legacy API behaviours that don't exist in other regions, and because everyone picks it as the default, it has significantly more pressure on contested resources (i.e. things like spot instance pools). Plus since it's the default in all the tooling, if you ever decide to go multi-region, you'll find tons of things break right away.
tlogan 1y ago
I think it is a little complicated. For example, your service might be using full failover but you use API from other service which are down. Or you might use BART to come to work and you got stuck: https://www.kqed.org/news/12060687/bart-resumes-service-but-delays-remain-after-another-major-disruption https://www.kqed.org/news/12060687/bart-resumes-service-but-...
- dingnuts 1y ago
  ha! I saw another comment on here talking about how ec2 doesn't need to be held to the same standard as the power company because it's not as important as real infrastructure. wish I'd already had this link in my back pocket. our industry needs to take its job, as a whole, much more seriously.
captainkrtek 1y ago
“Global” and “edge” services such as IAM, Route53, CloudFront and so on have dependencies on us-east-1, so even if you don’t think you do, you probably do.
bongodongobob 1y ago
Well, we didn't, but some of our third party softwares did. Hard to avoid.

TZubiri 1y ago

Wait, was the whole region affected? Like even if you had an EC2 instance?

mads_quist 1y ago
No, we run on US East 1 but only EC2. Everything was running smoothly!
- mads_quist 1y ago
  Our strategy has always been to use as little higher abstractions from cloud providers as possible. Glad we went this way, saved us quite a bunch of SLA breaches today! I am confident to say that it's "best of both worlds". We get great availability zone redundancy by AWS without having to rely on and pay for all those PaaS stuff the cloud giants offer. Also, we can "fairly easy" migrate to any other cloud provider because we only need Debian instances running.
bigstrat2003 1y ago
Yes, it was. We have EC2 instances that we turn on as-needed, and at times were unable to start said instances.