Verschillende diensten niet bereikbaar door problemen met Amazon Web Services

Problemen met Amazon Web Services zorgen er dinsdagavond voor dat verschillende diensten niet of niet goed bereikbaar zijn. Wereldwijd melden gebruikers problemen met diensten als Amazon Prime, Ring en games als League of Legends en Valorant.

Amazon Web Services, afgekort AWS, kampt dinsdagavond met problemen, waardoor veel diensten die gebruikmaken van AWS niet goed werken. Op allestoringen.nl melden ook Nederlandse gebruikers problemen met AWS en games en diensten die daar gebruik van maken.

Amazon heeft bevestigd dat er inderdaad problemen zijn. Daarin schrijft het bedrijf dat het problemen heeft ontdekt in de oostelijke regio van de Verenigde Staten, maar dit lijkt ook effect te hebben op diensten en gebruikers buiten deze regio. Het is niet bekend hoelang de storing gaat duren. Op de statuspagina is te zien wat de huidige stand van zaken is.

Reacties (77)

[Moartn]

Ben een grote AWS fan, maar die afhankelijkheid van alle regions op us-east-1 is wel eng. Root account logins in alle regions werken nu bijvoorbeeld niet.

En ik vind het ook raar dat us-east-1 over meerdere availability zones heen problemen heeft. Het lijkt in de control pane (management layer) te zitten, en niet in de services zelf.

[Reactie gewijzigd door Moartn op 22 juli 2024 18:35]

[djwice]

Ben een grote AWS fan, maar die afhankelijkheid van alle regions op us-east-1 is wel eng. Root account logins in alle regions werken nu bijvoorbeeld niet.

En ik vind het ook raar dat us-east-1 over meerdere availability zones heen problemen heeft. Het lijkt in de control pane (management layer) te zitten, en niet in de services zelf.

Ik vrees een wijziging aan de S3 core infra, er waren gister al redirect issues van global naar regionale domeinnamen. Ik vermoed dat die wellicht behoorlijk wat extra load hebben geleverd en dus op een gegeven moment cascades hebben veroorzaakt.
Speculatie: Wellicht toen de lifecycle policies werden geëffectueerd om middernacht. De rechten worden dan behoorlijk anders als AIM op domein staat en dat redirect naar een ander domein dat niet in AIM staat. Geen idee hoe dat gerecoverd zou worden - blijven proberen? Connecties vast houden?

[Reactie gewijzigd door djwice op 22 juli 2024 18:35]

[SunnieNL]

Ik merkte het zelf op toen ik thuiskwam en Alexa wel begreep wat ik zei alleen niet antwoordde wat ik verwachte en geen acties kon uitvoeren terwijl de lampen en smartplugs wel allemaal werken via de losse apps. Na het roepen ‘computer, it is xmas’, kreeg ik ipv een hohoho en een volledig huis in kerstverlichting de melding ‘xmas is not responding’
Gelukkig heb ik Google als backup om niet telkens de apps te moeten pakken.

Wel vreemd dat vrijwel alle Alexa skills blijkbaar over 1 punt lopen en daarom niet reageren. Je zou verwachten dat dat soort zaken HA over meerdere regio’s is uitgevoerd.

[Arfman]

Dit is echt iets voor internet of shit Twitter.

[Robbaman]

Wat een wereld leven we in dat een storing in een datacentrum in America ervoor zorgt dat bij jou thuis de lampen niet meer goed werken

[wiert.tweakers]

https://status.aws.amazon.com/

<<
API Error Rates in US-EAST-1
[9:37 AM PST] We are seeing impact to multiple AWS APIs in the US-EAST-1 Region. This issue is also affecting some of our monitoring and incident response tooling, which is delaying our ability to provide updates. We have identified the root cause and are actively working towards recovery.

[10:12 AM PST] We are seeing impact to multiple AWS APIs in the US-EAST-1 Region. This issue is also affecting some of our monitoring and incident response tooling, which is delaying our ability to provide updates. We have identified root cause of the issue causing service API and console issues in the US-EAST-1 Region, and are starting to see some signs of recovery. We do not have an ETA for full recovery at this time.

[11:26 AM PST] We are seeing impact to multiple AWS APIs in the US-EAST-1 Region. This issue is also affecting some of our monitoring and incident response tooling, which is delaying our ability to provide updates. Services impacted include: EC2, Connect, DynamoDB, Glue, Athena, Timestream, and Chime and other AWS Services in US-EAST-1. The root cause of this issue is an impairment of several network devices in the US-EAST-1 Region. We are pursuing multiple mitigation paths in parallel, and have seen some signs of recovery, but we do not have an ETA for full recovery at this time. Root logins for consoles in all AWS regions are affected by this issue, however customers can login to consoles other than US-EAST-1 by using an IAM role for authentication.

[12:34 PM PST] We continue to experience increased API error rates for multiple AWS Services in the US-EAST-1 Region. The root cause of this issue is an impairment of several network devices. We continue to work toward mitigation, and are actively working on a number of different mitigation and resolution actions. While we have observed some early signs of recovery, we do not have an ETA for full recovery. For customers experiencing issues signing-in to the AWS Management Console in US-EAST-1, we recommend retrying using a separate Management Console endpoint (such as https://us-west-2.console.aws.amazon.com/). Additionally, if you are attempting to login using root login credentials you may be unable to do so, even via console endpoints not in US-EAST-1. If you are impacted by this, we recommend using IAM Users or Roles for authentication. We will continue to provide updates here as we have more information to share.

[2:04 PM PST] We have executed a mitigation which is showing significant recovery in the US-EAST-1 Region. We are continuing to closely monitor the health of the network devices and we expect to continue to make progress towards full recovery. We still do not have an ETA for full recovery at this time.

[2:43 PM PST] We have mitigated the underlying issue that caused some network devices in the US-EAST-1 Region to be impaired. We are seeing improvement in availability across most AWS services. All services are now independently working through service-by-service recovery. We continue to work toward full recovery for all impacted AWS Services and API operations. In order to expedite overall recovery, we have temporarily disabled Event Deliveries for Amazon EventBridge in the US-EAST-1 Region. These events will still be received & accepted, and queued for later delivery.

[3:03 PM PST] Many services have already recovered, however we are working towards full recovery across services. Services like SSO, Connect, API Gateway, ECS/Fargate, and EventBridge are still experiencing impact. Engineers are actively working on resolving impact to these services.

[4:35 PM PST] With the network device issues resolved, we are now working towards recovery of any impaired services. We will provide additional updates for impaired services within the appropriate entry in the Service Health Dashboard.
>>

Enige wat nog niet helemaal werkt is dit:

<<
Amazon Elastic Container Service (N. Virginia) Elevated Fargate task launch failures

3:32 PM PST ECS has recovered from the issue earlier in the day, but we are still investigating task launch failures using the Fargate launch type. Task launches using the EC2 launch type are not impacted.

4:44 PM PST ECS has recovered from the issue earlier in the day. Task launches using the EC2 launch type are fully recovered. We have identified the root cause for the increased Fargate launch failures and are working towards recovery.

5:31 PM PST ECS has recovered from the issue earlier in the day. Task launches using the EC2 launch type are fully recovered. We have identified the root cause for the increased Fargate launch failures and are starting to see recovery. As we work towards full recovery, customers may experience insufficient capacity errors and these are being addressed as well.

7:30 PM PST ECS has recovered from the issue earlier in the day. Task launches using the EC2 launch type are fully recovered. Fargate task launches are currently experiencing increased insufficient capacity errors. We are working on addressing this. In the interim, tasks sizes smaller than 4vCPU are less likely to see insufficient capacity errors.

11:01 PM PST ECS has recovered from the issue earlier in the day. Task launches using the EC2 launch type are fully recovered. Fargate task launches are currently experiencing increased insufficient capacity errors. We are working on addressing this and have recently seen a decrease in these errors while continuing to work towards full recovery. In the interim, tasks sizes smaller than 4vCPU are less likely to see insufficient capacity errors.
>>

-------------------------------------------
Eerder:

Zo is bijvoorbeeld https://aws.amazon.com/marketplace plat (500 error, zie https://archive.md/dACXu)

Hacker News was er al vroeg bij: https://news.ycombinator.com/item?id=29473630 via https://twitter.com/hn_frontpage/status/1468245386326388752

Veel van AWS draait ook in US-EAST-1, dus heeft AWS moeite om status te rapporteren en de boel te fixen (zelfs root accounts doen het niet meer): https://twitter.com/YuzukiHusky/status/1468302440156086281 en https://twitter.com/d_feldman/status/1468265185630687233 en https://twitter.com/ipmb/status/1468245893279363088

Dat was de reden waarom o.a. Hacker News zo vroeg was.

De eerste melding van Amazon zelf (gevonden via de howisthecloud cloud status aggregator op Twitter): https://twitter.com/howisthecloud/status/1468270456981667845 en van een werknemer https://twitter.com/amitkjha_rjn/status/1468270518012891150

Dit was de eerste tweet die het probleem rapporteerde: https://twitter.com/tarparara/status/1468243375631568911

Mooi volgtijdelijk twitter draadje: https://twitter.com/nixcraft/status/1468247487190343687

Voelt op een bepaalde manier als de Facebook outage van laatst: die ene zwakke schakel die niemand in het vizier had.

Hopelijk komt de management console snel weer in de lucht. Die is nu plat: https://us-east-1.console.aws.amazon.com/console/home geeft nu een 504 error en was eerder nog wel een soort van "in de lucht" met een pagina "unavailable": https://archive.md/nadvS

Het regent cynische opmerkingen op Twitter zoals https://twitter.com/PraneetSahgal/status/1468251344876285952, https://twitter.com/rmogull/status/1468285279202996225 en https://twitter.com/regis_alenda/status/1468286588169895941

Maar ook mensen die nu snappen dat eieren in meerdere mandjes handig kan zijn (ook al kost het geld): https://twitter.com/zerodmg/status/1468274651407159301

En Kris (doet indrukwekkende cloud dingen bij Booking) heeft weer wat interessante links in zijn draadje: https://twitter.com/isotopp/status/1468328058289631235

Op zich snap ik dat wel, maar aan de andere kant: zelfs de cloud bedrijven zitten kennelijk nog in een leercurve en ik zou niet graag in de stoel zitten van de mensen die het nu aan het fixen zijn.

Dus ik ben het helemaal met deze #hugops eens: https://twitter.com/theseanodell/status/1468257178754723842

(Anderen zijn vast beter in de Tweakers markup dan ik, dus hou het even op simpele text)

[Reactie gewijzigd door wiert.tweakers op 22 juli 2024 18:35]

[RxTweak]

Wat ik ook fascinerend vind is dat de website van amazon een volledige stacktrace uitspuugt. Dit is wat je ziet op de amazon marketplace: https://pastebin.com/iH9GhuGa ( https://aws.amazon.com/marketplace )

Je kunt er vest veel informatie uithalen, lijkt mij onwenselijk.

[djwice]

Als je je S3 logs aan hebt en je s3 eens bezoekt met diverse services van AWS krijg je ook best veel info

[HitDyl]

Dat is inderdaad gewoon een behoorlijk veiligheidsrisico. Bijzonder dat een bedrijf als AWS die fout nog maakt en dat daar niet meerdere lagen aan controle op zit.

[djwice]

Bij mij was de impact ook op cloudformation in N.Virginia (us-east-1) iets voor 16:30 NL tijd.

En SSO viel iets later ook weg met internal service errors. Deze kwam kort daarna weer beschikbaar op eu-west-1 (Ierland) - recovery - maar viel enkele seconden later weer weg.

CloudFront lijkt in de lucht te zijn gebleven, de Lambda@Edge wordt via us-east-1 gedistribueerd naar de 6 regionale data centra en vanuit daar naar de overige 100+ data centra.

Had daar voor wel al issues dat op S3 de 'Deletion Mark" bleef bestaan als alle file (incl oude versies) al lang weg waren. Direct na dat ik de laatste Mark verwijderde knalde AWS er uit.

En gister dat global S3 urls ineens redirects gingen geven naar regionale S3 domeinen. Ook op configuraties die al maanden foutloos werkten. Was niet zo prettig voor CloudFront distributies die ineens interne bucket namen exposten én uiteraard ontoegankelijke content urls als redirect gaven. Weet niet of dit gerelateerd is. We hebben als mitigatie alle global S3 domeinen in onze configuraties vervangen door regionale names.

Dus wellicht is er iets op de S3 DNS gewijzigd dat meer impact heeft dan bedoeld. Global S3 is immers ook n.virginia.... en S3 is de basis achter de getroffen services voor configuratie of storage...

Bijvoorbeeld als Athena een S3 bron moet query-en en het resultaat moet wegschrijven en deze krijgt een redirect voor de kiezen bij schrijven van de data, geen idee of PrestoDB dat goed afhandeld, zeker niet als de IAM policy op de andere (niet-redirected) bucket name staat ..


Mensen die klagen over beschikbaarheid van AWS op Twitter: https://press.aboutamazon...provider-serve-timelines/

[Reactie gewijzigd door djwice op 22 juli 2024 18:35]

[wiert.tweakers]

Haha, die press release had ik nog niet eerder gezien. Dat lezend hield Twitter zich verbazingwekkend goed tijdens deze AWS outage.

[SunnieNL]

Ik denk dat ik het nieuws ook rond 1700 aan Tweakers had gemeld na een korte zoektocht omdat ik Ff zeker wilde weten of ik de enige was bij wie Alexa het niet deed. Via een snelle search op Twitter was het vrij snel duidelijk dat er meer aan de hand was en TheVerge had net het artikel gepost op twitter toen ik hem doorzette naar Tweakers. Heeft Ff geduurd voor ze hem plaatsten (maar paar uur later is altijd beter dan pas na 2 dagen. En zo te zien hebben ze wat verder onderzoek gedaan al).

Wat ik voornamelijk irritant vind is dat het bericht alleen over de management console gaat op de status pagina van Amazon, terwijl daaronder de statuspaginas in de hele wereld van de Amazon diensten gewoon aangeven dat er niets aan de hand is, terwijl bijna alle Amazon consumentendiensten problemen hiervan ondervinden over de hele wereld.

[wiert.tweakers]

Ja, dat was heel bizar.

Ik schreef al in een ander bericht: ik ben heel benieuwd naar de post mortem.

Ze hebben er uiteindelijk bijna 8 uur over gedaan om de boel weer zo goed en kwaad als mogelijk aan de praat te krijgen. Dat is sneller dan toen bij Facebook, maar ook hier zijn kennelijk de afhankelijkheden op deze regio enorm groot. Daar kunnen we met zijn allen nog best wat van leren.

[djwice]

De consoles waren wel bereikbaar via hun regionale domeinen trouwens.

[casberrypi]

AWS verkoopt een abstractie. Doen alsof er geen computer is waarop een instance draait, maar in plaats daarvan is een een enorme constellatie van processen, software en hardware gecreëerd. En soms gaat daar iets mis.

Hoe kun je als klant een huis bouwen op een fundering waarvan je niet precies weet hoe die in elkaar steekt?

Ik ben nogal ouderwets met mijn eigen hardware in verschillende datacenters, maar zo kan ik tenminste een betrouwbare inschatting maken van de risico's. Ik weet van welke verbindingen, routers, switches en servers ik afhankelijk ben, en wat ik moet doen om te zorgen dat er niets grandioos mis gaat als er iets stuk gaat.

[djwice]

AWS wert de root cause ook .. dus ook van het fundament. Ze zijn het fundament aan het vervangen van centraal naar gedistribueerd. En van Intel naar ARM. Tot nu toe hadden we daar alleen van gemerkt dat het sneller en goedkoper werd.

Een decentralisatie stap had een onverwachte impact een tijdje ná de wereldwijde uitrol.

De services die nog niet goed met decentralisatie om konden gaan zijn omgevallen omdat de centrale fix om viel

[miitjohn]

Mogelijks, maar het is wel zo dat men abstractie op service op abstractie blijft bouwen. Dat blijft amazon doen als geen ander, inzien waar klanten nood aan hebben en dan met iets komen voor de concurentie. Als de concurentie dan wint het hen zo makkelijk mogelijk maken om het ook te gebruiken op aws (bv. eks vs ecs/fargate).

Niks mis mee, maar je moet toch ergens ook de grens gaan bepalen. Want die services zijn ook maar gemaakt door ontwikkelaars en hebben regelmatig problemen. Problemen die je met een eigen implementatie niet had gehad, of, beter onder controle zou hebben. Ze doen zich graag voor als één cloud, maar hoe langer hoe meer gaan die extra services bepaalde mankementen gaan vertonen. Iets dat men nu introduceert kan nooit zo stabiel zijn als bv. s3 ook al pretendeerd men dat.

Zo had aws een tijdje geleden de acknowledge van ssm documenten aangepast. Deze ging altijd direct, dus cloudformation scripts die documenten uitvoeren in hun stack kregen direct een ack en gingen verder. Omwille van scaling heeft aws dit plots aangepast naar "ergens tussen 15min en 2h". Bijgevolg blokkeerde dergelijke cloudformation scripts van de ene op de andere dag. Uiteindelijk is die change teruggedraaid, maar om te zeggen, er zitten toch grote stabiliteits en kwaliteits verschillen tussen de services die men o zo graag geintegreerd onder de cloud koepel aanbiedt

[djwice]

Ja, ze maken steeds meer dingen event driven. Eerder ook met certificaten. Kreeg je 1 ok voor het hele certificaat. Dat hebben ze asynchroon gemaakt. Dus als je op een certificaat twee sub-domeinen hebt kunnen die op verschillende momenten valide zijn.

Dat was ff lastig want gebaseerd op de ack ging mijn stack door met deployen van CloudFront. Maar dat faalde dus omdat het certificaat nog pending niet was.
Idem: oude DNS validatie hoefde geen hosted zone te kennen: de gene die autoriteit is van het domein werd gekozen, dus was er geen custum code daarvoor nodig en geen user input. Nu moet je verplicht een hosted zone ID opgeven, niet beschikbaar is in cft. Dus user input of custum code nodig.

[eilavid]

Bezorger voor de deur... deed onze bel het niet

[Sp3ci3s8472]

Kan je mij misschien uitleggen waarom een deurbel in godsnaam een internet verbinding nodig heeft om af te kunnen gaan? Ik snap prima dat hij andere features heeft, maar bij het verliezen van een internet connectie zou je toch verwachten dat hij minstens nog geluid maakt.

[eilavid]

Ring speelt nog steeds een geluidje als je de knop indrukt naast de voordeur, maar die is niet luid genoeg om ook binnen te kunnen horen. Nu AWS down is komt er geen notificatie op de telefoon en geen geluidje via de smartspeaker in huis. Gaat blijkbaar allemaal via de cloud ondanks op hetzelfde netwerk verbonden.

Overigens werkt het allemaal nog steeds niet. Nu al circa 4 uur downtime, handig zo'n slimme deurbel

[Reactie gewijzigd door eilavid op 22 juli 2024 18:35]

[zx9r_mario]

Afschrijving van 3 euro Ring abonnement werkte wel vandaag

[JeroenED]

Maar als er betaald moet worden werkt altijd alles

[Glashelder]

Je hebt dus niet zo’n chime?

Ben even benieuwd of die er ook uit lagen

[ctrl-tab]

Het gaat inderdaad nergens over hoe makkelijk producenten dependencies op het publieke internet introduceren.
Ik snap het wel, enerzijds gebruiksgemak , anderzijds data gatheren en mensen aan je merk verbinden (door centrale account voor meerdere devices aan te bieden)

Ik verwacht dat er een keerpunt gaat komen. De vele clouddiensten zorgen voor te veel fragmentatie (afname gebruiksgemak) en zoals je nu ook ziet is het ook wel handig om lokale of analoge processen te behouden.

Zelf doe ik alles via zigbee2mqtt , en slechts een paar cloud-based device (electrische verwarming die maar soms aan staat, en een xiaomi stofzuiger - waar een paar maanden terug de lokale api afgesloten is door een firmware upgrade.... )

[djwice]

https://www.action.com/nl-nl/p/draadloze-deurbel/

Werkt prima. Sterker nog je kunt op 1 knop meerdere draadloos aansluiten met elk hun eigen volume en klank naar wens. En dat zonder internet!

[Reactie gewijzigd door djwice op 22 juli 2024 18:35]

[Verwijderd]

Die deed het hier nog prima! En ik heb de Ring op de bestaande draden zitten, dus de oer oude bel rammelt nog gewoon mee als backup!

[wiert.tweakers]

Hier ook weer. De gevelreiniger had er de hogedruikspuit opgezet, maar dat vocht is er met wat moeite uitgegaan.

[Littlemarc]

Koop de ring wired pro want die kan je aansluiten op de gong van je originele bel maar ook uitzetten indien nodig.

[kw_nl]

Ik kan de Wired Pro niet vinden. Wel een Pro, maar daar staat bij dat de gong dan niet meer werkt.

Heb zelf sinds vandaag (echt goed voor de WAF met deze storing) een Ring Wired. Maar die kreeg ik niet werkend met de bestaande gong.

[Littlemarc]

Ring wired pro 2

[Jim80]

Van een Amazon bestelling?

[perry1]

Tijd om je geld terug te vragen voor zo'n ondeugdelijk ontworpen product.
Of stond hier iets over in de disclaimer?

[Verwijderd]

Niet juist aangesloten

[Slavy]

Cloud werkt toch altijd, heeft nooit downtime? Dat vertellen alle consultants altijd aan mij.

[EnigmA-X]

Beetje salty, maar ik zal toch happen

Wat ze je hadden moeten vertellen: "Cloud kán bijna altijd werken". Het grote voordeel van "de cloud" is en blijft scaling en agility (in ieder geval van de hyperscalers) met een "pay as you go"-model. Dat komt heel goed van pas als je iets wil bouwen als uitwijk, wanneer er een region (of twee) down gaat

Om terug te komen op jouw vraag: als jouw bitbucket pipelines (zoals die van @armageddon_2k1 ) echt heel belangrijk voor jou of jouw bedrijf zijn, dan kan je kiezen voor een multi-region architectuur of kies je bijvoorbeeld voor een goed ingerichte/voorbereidde DR locatie in een andere region.

Ik ben het wel met je eens, er loopt heel wat schorem rond bij de consultants/sales engineers die vooral dingen roepen die ofwel niet kloppen, of totaal gebrek aan nuancering hebben.

Echter, er loopt ook schorem rond bij de afnemers van die consultants. Met name de managers die eerst hard roepen: "daar hoeven we ons niet tegen in te dekken, te duur, overkomt ons niet", maar áls het dan gebeurt als haantje de voorste staan te peeuwen dat cloud evil is.

Nogmaals... nuance nodig aan beide kanten :-)

[wiert.tweakers]

Punt is dat veel andere regions nu ook problemen hebben omdat er wat kritieke dingen door die ene region die nu plat is heen lopen.

Daar komt hopelijk een goede post mortem van.

[EnigmA-X]

Ik zie bij alle andere regions impact op de management console en support center.

Dat kan inderdaad behoorlijk vervelend zijn en riekt naar een SPOF (zou ik niet verwachten bij een hyperscaler van formaat AWS). Aan de andere kant lijkt het erop dat de normale workloads in andere regions gewoon kunnen draaien (althans, volgens de statuspagina). Dus dan is de impact op andere regions er wel, maar beperkt.

Het zou natuurlijk kunnen zijn dat dit een overwogen risico is geweest ala "dat overkomt ons niet, want ..." en dat de maatregelen daartegen niet afdoende zijn gebleken. Inderdaad (overoverover)morgen even checken of er een post mortem van komt...

[Mellow Jack]

Ben geen AWS expert maar kan je wel vertellen dat Azure vergelijkbaar werkt. Bepaalde diensten zijn globaal en zijn helaas afhankelijk van specifieke regio's.

T voelt mij als ontwerp keuze

[wiert.tweakers]

Inderdaad. Ik ben heel benieuwd naar de postmortem.

[Lagonas]

Dan zijn dat slechte consultants. Je kan nooit claimen dat iets nooit down gaat. Tenminste, je kunt het wel claimen, maar dan lieg je simpelweg. 100% uptime moet je niet kunnen beloven als hoster. Er kan altijd iets mis gaan.

[Reactie gewijzigd door Lagonas op 22 juli 2024 18:35]

[xMuchux]

Daarom staat er altijd in de SLA 99.9% en geen 100%

[Lagonas]

Als dat in de SLA staat dan moeten de consultants niet vertellen dat het nooit down gaat. Dat is namelijk wat Slavy zegt.

[Isegrimm]

Dat vertellen ze omdat ze jou iets te verkopen hebben, dat heet marketing ;-)

[Verwijderd]

Hebben ze nog gelijk ook!
Alleen niet alle diensten van de cloud, maar er werkt altijd wel een stukje!

[terabyte]

Cloud = andermans computer. Weer andere vorm van vendor-lockin.
Die consultants hebben belang bij vendor-lockin.

Het is een slap aftreksel van Grid computing, wat daadwerkelijk gedecentraliseerd is, maar het om commerciele redenen nooit buiten de acedemische wereld heeft gemaakt

[Scriptkid]

klopt toch ook, cloud heeft nooit downtime voor maintenance ()belangrijke nuance)

Cloud heeft nl gewoon een SLA van vaak 99,9 of 99,99 en heel zelden 99,999 waarbij de cloud dus gewoon per jaar een aantal X tijd stop gezet mag worden zonder contract schending.

[Verwijderd]

Ik vroeg me al af waarom Alexa vandaag wat moeilijk deed...
Maar dat zal het zijn!

[timbe]

Hier doet Alexa niks meer.
Wel grappig om te merken hoe je er aan gewent bent om met je stem alles aan te sturen.

[Verwijderd]

Fietsen in de garage zetten....

*Doet deur open*
"Alexa, lights on"
*komt met fiets aan.... donker!*

"Alexa announce voedertijd!"
Na 2 uur kwamen de pubers hongerig de trap af of ze nog eten kregen...

"Alexa, timer 10 minutes" eten aangebrand!


Hoe deden mensen dat vroeger eigenlijk allemaal?
Want ik moet nog stofzuigen, maar die wil ook niet aan nu!

🤣

[SunnieNL]

Ik zou beginnen met Engels praten tegen Alexa. Ze verstaat nog geen Nederlands en bij een smarthome zou je al niet verder komen bij stap 1. Want die deur zijn controle systeem draait vast ook op AWS en gaat dus niet open

[Reactie gewijzigd door SunnieNL op 22 juli 2024 18:35]

[Verwijderd]

Enige Nederlandse tekst die ik riep was de announce. En dat is een geluidsopname die ze over alle speakers afspeelt, dat gaat prima. 👍

En sloten zijn hier nog ‘gewoon’ ouderwets. Wel met een modern type cylinder voor optimale veiligheid 😇

[GeroldM]

Hier is anders een weetje. Hoe beter het slot, des te makkelijker het is om het open te breken. Bij goedkope/brakke sloten werkt het truukje van een sleutel van een soortgelijk slot een klein beetje te bewerken, in het slot te steken en redelijk zachte tik met een hamer niet.

Wanneer het slot van goede materiaalkwaliteit is, dan breekt er niets in het slot en open je deur met gemak. Sloten met een brakke materiaalkwaliteit overleven de hamerslag niet en blijven daardoor op slot. Het is een redelijk oud slotenmakers truukje, dat nog altijd uitstekend werkt.

Veiligheid is een relatief begrip. Helaas..

[armageddon_2k1]

Bitbucket Pipelines ook down. Not fun.

[Isegrimm]

Grappige is dat het iets van een uur duurde voordat er iets op hun eigen status-pagina hierover te zien was.

[The Zep Man]

Want de statuspagina was onbereikbaar?

[wiert.tweakers]

Zo ongeveer hun hele management loopt via die ene zone.

Net wat linkjes in wiert.tweakers in 'nieuws: Verschillende diensten niet bereikbaar door proble... gepost. Ik probeer die een beetje bij te werken, maar moet zo ook nog wat aan mijn gezondheid werken (zie https://twitter.com/jpluimers)

[miitjohn]

Nog grappiger is dat de console weg was, r53 delegations die failen, ssm issues, kortom grotendeels onbruikbaar. Misschien was de impact op datgene wat al draaide iets minder, maar als je net dan moest uitrollen kraakte het aan alle kanten.

Echter die status pagina's (met spreekwoordelijk 5000 groene vinkjes) daar was alles wel ok hoor, alleen na een tijdje een melding met "wat error rates op de api's". Als je niet meer kan aanmelden en je cloudformation scripts blijven steken dan had ik toch verwacht enkele rode kruisjes te zien, maar ja, amazon is always right, right?

[Reactie gewijzigd door miitjohn op 22 juli 2024 18:35]

[lordawesome]

IMDb was ook plat

[XVI]

Echt vlug is het nog niet en ik krijg ook soms full page 500s. Toch wel slecht hor. Een eigen dienst van de grootste cloudboer werkt niet/slecht bij problemen bij een cloudregio. Uiteraard zegt een enkele outage weinig maar het is ook geen mooi affiche.

[josh-hill]

Het ligt er al uren uit. Probeerde 2 uur geleden goodreads en imdb te laden. Helaas. En ze liggen er nu nog steeds uit.