If you're having problems accessing the console, the workaround is just to use a different region, eg:
https://ca-central-1.console.aws.amazon.com/console/home
This assumes you don't actually need anything from us-east-1, though :)
AWS us-east-1 down
181–190 of 331 posts
Re: AWS us-east-1 down
#182Earlier quoted context omitted.
AZs don't really help when it's AWS' own services across the entire region that break. Anecdotally, we have had customers accept outages that were out of our control without penalty.
AZs also don't help with natural disasters at all. I believe AWS is the only one doing geographically distributed AZs, for the others it just means different connections and placed somewhere else in the building. edit: turns out AWS is the one with geo distribution, not Azure
Aws azs are also distributed geographically within a region w separate power and network lines. From the docs “ Availability Zones are distinct locations within an AWS Region that are engineered to be isolated from failures in other Availability Zones.”
Re: AWS us-east-1 down
#183For those wondering: Currently PDT is 7 hours behind UTC. AWS can do so many things, reporting critical outage updates in UTC is not one of those things.
Technically PDT is always 7 hours behind UTC. PST is always 8 hours behind. We just change which one we use twice a year. Pacific time makes sense when you realize Fremont is the center of the universe.
True in theory, in practice people often get it wrong and use the incorrect one.
Re: AWS us-east-1 down
#184Earlier quoted context omitted.
It's also usually extremely US-centric. Nobody outside of North America has any idea what "PDT" or "Mountain Time" means.
3 years ago, when I started work for my current employer, I noticed in Slack that everyone was reckoning time in "Standard Time" year-round. Now imagine my chagrin because I live in Arizona, and "Mountain Standard Time" does not change for DST. Therefore, all my coworkers were citing nonsensical, nonexistent time zones and it was messing up my ability to convert back and forth. Come to find out that this was some sor…
This is why I always write ET instead of EDT/EST.
I encourage everyone at my company to do the same. Easy way to eliminate errors while typing 1 less key stroke!
Re: AWS us-east-1 down
#185Earlier quoted context omitted.
It's also usually extremely US-centric. Nobody outside of North America has any idea what "PDT" or "Mountain Time" means.
3 years ago, when I started work for my current employer, I noticed in Slack that everyone was reckoning time in "Standard Time" year-round. Now imagine my chagrin because I live in Arizona, and "Mountain Standard Time" does not change for DST. Therefore, all my coworkers were citing nonsensical, nonexistent time zones and it was messing up my ability to convert back and forth. Come to find out that this was some sor…
One of the saddest pieces of code I ever wrote was to treat "MST" as always meaning America/Denver. I'm sorry.
Re: AWS us-east-1 down
#186Mysterious lack of "AWS is bad for the internet because it is so centralized" dialog up in here. edit: for those that would downvote: HN _just_ yesterday: https://news.ycombinator.com/item?id=36295352 https://news.ycombinator.com/item?id=36295305
[deleted]
Re: AWS us-east-1 down
#187Earlier quoted context omitted.
Semi-related: if you ever feel the need to report times to a global audience, not only make sure to always report the timezone (even if it is the same as the user's), but also use UTC offsets rather than timezone names. Life is too short to remember what each timezone name means and converting to it, UTC offsets are much easier on the mental calculator.
It's also not too complicated to add a few lines of javascript that show the datet/time in the user's local time zone (via Date.getTimezoneOffset) as well.
given how long it took AWS to add support for Ed25519 ssh keys (literally just fix the validation regex), I wouldn't hold your breath
Re: AWS us-east-1 down
#188Why is it always us-east-1 though? I have always stayed away from that region because it seems significantly less reliable than other regions.
It's the: * Largest (DDoS'd most, most complex, scaling issues etc) * Oldest (More time for weird idiosyncrasies to take hold) * Where most testing happens * Where new products are deployed first
Looking forward to Auckland coming online, which should be the opposite to most of these factors, and will make game streaming bearable (for me)
Re: AWS us-east-1 down
#189I wonder if this is a coincidence or if us-east-1 is simply down enough that I'm just experiencing selection bias; but I posted a poll on twitter earlier today: https://twitter.com/dijit/status/1668678588713824257 Contents: > Has anyone ever actually had customers accept an outage because AWS was down; or is this just cloud evangelicalism copium? > [ ] Yeah, outages free pass > [ ] No, they say to use AZ's
it's important to inform customers about the resiliency of their systems and let them pick how far they are going to invest for it. then you get to eat popcorn when stuff explodes. * single server event. $ * multi server event. $$ * single az event. $$$ * multi az event. $$$$ * global provider event. $$$$$ * cross provider event. $$$$$$ * alien invasion. $$$$$$$$$$$$$$
"Briefly describe the '$$$$$$$' through '$$$$$$$$$$$$$' situations. Can't leave money lying on the table."
- memo from Enterprise Sales Dept.
Re: AWS us-east-1 down
#190Earlier quoted context omitted.
Semi-related: if you ever feel the need to report times to a global audience, not only make sure to always report the timezone (even if it is the same as the user's), but also use UTC offsets rather than timezone names. Life is too short to remember what each timezone name means and converting to it, UTC offsets are much easier on the mental calculator.
It's also not too complicated to add a few lines of javascript that show the datet/time in the user's local time zone (via Date.getTimezoneOffset) as well.
As long as you still show which tz it is! :)
GCP's various products have gotten a lot better at this lately, but just a few months ago I could click around between various dashboards and explorers, some showing the time in UTC, some in your browser's tz, and some in your profile's tz (if I recall correctly). Some of them were showing the tz, and for some you had to guess. Sometimes you had multiple tzs on the same page. Sometimes the date picker for a control was in one tz and the widget it was controlling in another (leading to quite a lot of confusion).
The worst offence IMO was not showing the tz at all. Especially given the overall lack of consistency.