Verschillende webdiensten waaronder Slack hebben last van AWS-storing

Amazon Web Services heeft last van een storing waardoor verschillende diensten niet goed werken. Onder andere Slack en de Epic Game Store zijn slecht bereikbaar, net zoals andere games, diensten en iot-services.

Op DownDetector is te zien hoe verschillende apps zoals Life360, Grindr en Imgur last hebben van de storing. Ook Epic Games en Slack lijken moeilijk te werken. Op Twitter zegt Epic dat gebruikers niet kunnen inloggen en niet bij hun bibliotheek kunnen. Bij Slack lijken er vooral problemen met specifieke functies zoals het uploaden van afbeeldingen of het doorsturen van e-mails. Het bedrijf zegt te werken aan een oplossing.

De storing lijkt te zitten in AWS, dat last heeft van een storing in een EC2-cluster. Dat probleem zit in een us-east-1-cluster. Op de serverpagina staat dat alle Europese diensten zouden moeten werken. Het is de derde keer in korte tijd dat AWS last heeft van een storing. Dat gebeurde ook al begin december, toen gebruikers ongeveer twee uur geen gebruik konden maken van veel games. Ook toen leek het probleem te zitten in api-error-rates in us-east-1, maar het is niet bekend of er een verband is tussen de twee storingen.

Reacties (61)

[Giant87]

"Server"
US-East-1 bestaat uit 60 datacenters
https://baxtel.com/data-center/aws-us-east-n-virginia

[thePiett]

Dat probleem zit in een us-east-1-server.

Het lijkt me sterk dat dit veroorzaakt wordt door één server

[HollowGamer]

Er staat ook niet één, maar een.

Maar de term server is misschien hier vreemd, het is namelijk een regio die weer verbinding maakt met meerdere servers aan de achterkant. Dus wellicht is loadbalancer hier de juiste benaming (wat overigens ook gewoon een server is).

Het is wel de zoveelste storing met AWS in een zeer korte tijd. Helaas zijn er veel diensten afhankelijk van, waardoor al snel je complete stack eruit gaat. Geen idee wat hier de oplossing zou kunnen zijn, dan wellicht een fail-safe storage?

[Keypunchie]

Niet alle ballen op US-East, maar je (virtuele) infra over meerdere regions verspreiden.

Het kost wat om op te zetten, maar anno 2022 (bijna!) is het ook weer niet zo heel moeilijk om je heel infra as-code te hebben, dus deployen en managen met terraform o.i.d., je applicaties er ook geautomatiseerd uitrollen (moet je pipelines natuurlijk ook ergens betrouwbaar/stabiel staan, desnoods lokale server) en op de achtergrond ook een oplossing om je data te repliceren.

Brengt enige complexiteit met zich mee, maar het *kan*. Of je ook bereid bent om er voor te betalen is een andere vraag.

@Moartn Goeie toevoeging. Multi-AZ is inderdaad een stuk makkelijker dan multi-region.

[Reactie gewijzigd door Keypunchie op 22 juli 2024 14:31]

[Moartn]

In het geval van deze storing is niet eens verspreiden over meerdere regions nodig. Het gaat in dit geval om 1 availability zone die eruit ligt/lag (USE1-AZ4 om precies te zijn). De us-east-1 region heeft 6 van die zones. Je hoeft dus alleen maar een multi AZ setup te hebben om geen last te hebben van dit probleem. En dat is binnen AWS toch vrij eenvoudig te regelen. Eenvoudiger dan een multi-region setup iig.

[supersnathan94]

Het probleem is alleen dat AWS zelf voor een aantal services geen multiAZ setup lijkt te gebruiken. IAM draait bijvoorbeeld single AZ in alleen USE1-AZ1 dacht ik. Daarom was daar de vorige keer degraded performance. Overigens is dat dan de service die wereldwijd de boel regelt. Niet bepaald handig.

[thePiett]

Ik denk dat je onderschat uit wat voor infrastructuur bijvoorbeeld US-East-1 bestaat. Zie ook Giant87 in 'nieuws: Verschillende webdiensten waaronder Slack hebben last van... .

[Anonymoussaurus]

Wat ik mij eerder afvraag is waarom ik als EU-user getroffen wordt door een Slack-storing terwijl Slack ook datacenters in de EU heeft.

[Reactie gewijzigd door Anonymoussaurus op 22 juli 2024 14:31]

[Opperpanter2]

Ik begreep dat je een vrij duur slack abonnement moet hebben voordat je kan kiezen om je data in de EU te hosten. Heb t zelf niet gechecked.

[Anonymoussaurus]

Aha, dat zou het verklaren dan, dankje.

[URSUS]

Dat was een jaar terug inderdaad het geval. Voor het bedrijf waar ik voor werkte destijds was dat de reden om een andere oplossing te gaan gebruiken.

[Blokker_1999]

Omdat een globaal systeem informatie moet kunnen halen van over heel de wereld. Jij verbindt dan wel met een server hier in de EU, maar die server moet informatie van verschillende andere platformen krijgen en heeft dus last van het feit dat er in de VS systemen niet of moeilijk bereikbaar zijn.

[Anonymoussaurus]

Daarom hebben ze alles redundant draaiend in meerdere regions, en niet alles in 1 region, 1 datacenter of 1 cluster. Tenzij ze dat niet hebben (wat ik dus betwijfel).

[Reactie gewijzigd door Anonymoussaurus op 22 juli 2024 14:31]

[sjakie02]

Wel mega-irritant als je net een hotfix naar productie wil pushen maar Jenkins niet wil bouwen omdat BitBucket het niet doet. Steeds vaker worden we met de neus op de feiten gedrukt dat het eigenlijk allemaal een gammel zooitje is.

[wica]

Nergens last van, maar wij draaien ook alles intern tot aan de repo's toe.

Het is een keuze om afhankelijk te zijn.

[Rob]

Als je het zelf draait moet je weer goed de updates in de gaten houden (Log4J)

[coolkil]

Moet je in de cloud ook.

[wica]

Ook al besteed je het beheer uit. Moet je als bedrijf zijnde zelf controleren of updates uitgevoerd zijn.
Vertrouwen in een andere partij is leuk, maar zeker weten is fijner.

[Gamebuster]

Al die cloud meuk is leuk ja, totdat het niet werkt. Verschil is dat je zelf er niets aan hoeft te doen, en dat je er zelf niets aan kan doen.

[david-v]

Al die niet-cloud hosting is leuk ja, totdat het niet werkt. Verschil is wel dat je het probleem (stroomstoring?) dan ook niet zelf kan oplossen, want je bent alsnog afhankelijk van je hosting partij.

Het verschil tussen traditionele hosting en cloud (hosting) is heel dun, maar tegelijk ook heel groot.

[Reactie gewijzigd door david-v op 22 juli 2024 14:31]

[Gwaihir]

En in Trello opzoeken wat dan te gaan doen werkt ook even niet..

[DennusB]

De storing lijkt te zitten in AWS, dat last heeft van een storing in een EC2-cluster.

Het gaat hier om een storing in een AZ (Availability Zone), wat een compleet datacenter is. Niet om een cluster.

[bargh]

us-east-1 is een region, geen AZ. us-east-1a is een AZ. Een region is 2 of meer datacenters.

[DennusB]

I know! Maar op de status pagina staat duidelijk dat er 1 AZ stroom issues heeft

[Johan9711]

Deze AWS locatie heeft echt vaak last van storingen de laatste tijd. Niet eens elke storing is groot in het nieuws geweest, maar ik had vorige week ook al een minuut of 20 downtime.

[Sebazzz]

Tsja, de schermen, net zoals Azure, ermee dat je pas goede betrouwbaarheid krijgt als je multi-region je applicaties deployed.

[Ghostface9000]

Zou dit de reden zijn dat de helft van mijn cloud keys offline zijn op unifi.ui.com ?
Dacht dat er misschien een automatische firmware update fout gelopen was.

[HKLM_]

Die maken inderdaad gebruik van AWS

[donviktor]

Asana en Hubspot hebben ook flinke kuren...

[Dennisweb]

Ik weet niet of het er iets mee te maken heeft, maar in Europa heb ik ook problemen met een aantal sites. Zo staat onder meer het Spaanse MegaStar en zusterstation Cadeona 100 op Amazon, en die zijn beide al de hele middag down.

[Fronkie]

Lijkt er op dat het probleem een stroomstoring was: https://www.reuters.com/m...us-east-coast-2021-12-22/