AWS gjør resiliens til AI-styrt porteføljekontroll

AWS har lansert en ny versjon av Resilience Hub som flytter resiliensarbeid fra enkeltteam til porteføljenivå. Tjenesten får ny applikasjonsmodell, avhengighetskartlegging, generativ AI-basert feilmodus-analyse, modulære resilienspolicyer og rapportering på tvers av organisasjonen.

Det høres først ut som en klassisk AWS-produktnotis. Den praktiske betydningen er større. Mange virksomheter har hundrevis av applikasjoner i skyen, men mangler en felles måte å sette mål for tilgjengelighet, teste om systemene tåler feil og dokumentere status for ledelse, revisjon og kunder. AWS prøver nå å gjøre dette til en styrt prosess inne i AWS Organizations.

For CIO, CISO og driftssjefer treffer dette et kjent problem. Resiliens er ofte fordelt på arkitekturtegninger, runbooks, overvåkingsverktøy, manuelle tester og enkeltpersoners erfaring. Når hendelsen først kommer, er det ikke alltid klart hvilke systemer som er avhengige av hverandre, hvilke feilmodi som faktisk er analysert, og hvilke tjenester som bryter egne krav til gjenoppretting.

Den nye Resilience Hub-versjonen samler mer av dette i ett kontrollplan. AWS skriver at team kan evaluere resiliens i skala, finne skjulte avhengigheter, identifisere feilmodi og rapportere fremdrift på tvers av virksomheten. Det er særlig relevant for selskaper som har vokst gjennom mange skyteam, kontoer og produktområder.

Fra SRE-håndverk til styringsdata

SRE-arbeid har lenge vært preget av godt håndverk: service level objectives, chaos testing, incident reviews, øvelser og tekniske forbedringer i arkitekturen. Problemet er at håndverket ofte er vanskelig å sammenligne på tvers av porteføljen. Ett team kan ha sterke testregimer, mens et annet team har høy forretningskritikalitet og svak dokumentasjon.

AWS sin nye retning peker mot en mer industrialisert modell. Resilienspolicyer kan settes modulært. Avhengigheter kan kartlegges som del av vurderingen. Generativ AI kan brukes til å lete etter mulige feilmodi. Organisasjonsrapportering kan gi ledelsen oversikt over hvilke applikasjoner som ligger innenfor og utenfor kravene.

Det gjør ikke systemene robuste av seg selv. Det kan likevel endre tempoet i arbeidet. Hvis analysen av feilmodi blir raskere, og avvik kan rapporteres konsistent, blir det enklere å prioritere teknisk gjeld som faktisk truer tilgjengelighet. Det blir også lettere å forklare for styret hvorfor resiliens ikke bare er et IT-tema, men en operasjonell risiko.

AI som hjelper, men ikke kan eie ansvaret

AI-delen bør leses nøkternt. Generativ AI kan bidra med forslag til feilmodi og mulige sammenhenger mellom komponenter. Den kan også senke terskelen for team som ikke har modne SRE-miljøer. Men den kan ikke erstatte arkitektureierskap, sikkerhetsvurderinger eller realistisk testing.

Risikoen er at organisasjoner begynner å behandle en AI-generert analyse som bevis. Det er den ikke. Den er et forslag som må holdes opp mot faktisk topologi, trafikkmønstre, backupregimer, identitet, nettverk, tredjepartsavhengigheter og hendelseshistorikk.

For regulerte virksomheter er dette poenget viktig. DORA, NIS2 og vanlige kundekrav flytter forventningen fra gode intensjoner til dokumenterbar operasjonell robusthet. En rapport fra et skykontrollplan kan være nyttig, men den må knyttes til testresultater, eierskap, avvikshåndtering og beslutninger om akseptert risiko.

Hva norske virksomheter bør gjøre

Virksomheter som allerede kjører tungt på AWS bør vurdere Resilience Hub som en del av porteføljestyringen, ikke bare som et verktøy for SRE-teamet. Start med de mest forretningskritiske applikasjonene. Kartlegg hvilke kontoer, tjenester og avhengigheter som inngår. Sett konkrete krav til gjenoppretting, testfrekvens og rapportering.

CIO bør samtidig be om to ting: en oversikt over applikasjoner som ikke har testet resiliens mot egne krav, og en plan for hvordan avvik skal prioriteres mot annen utvikling. CISO bør se på identitet, hemmeligheter, nettverk og leverandøravhengigheter i samme løp. CFO bør få synliggjort kostnaden ved både forbedring og nedetid.

Poenget er ikke at alle skal kjøpe mer AWS-funksjonalitet. Poenget er at AI-drevne kontrollplaner er på vei inn i driftsmodellen. De beste virksomhetene vil bruke dem til å få bedre beslutningsgrunnlag. De svakeste vil bruke dem som dokumentasjon på arbeid som ikke er gjort. Den forskjellen blir dyr når neste driftsstans treffer.

Kilder og medier

Primærkilde: AWS News Blog, "Introducing the next generation of AWS Resilience Hub for generative AI-based SRE resilience journey", publisert 28. mai 2026: https://aws.amazon.com/blogs/aws/introducing-the-next-generation-of-aws-resilience-hub-for-generative-ai-based-sre-resilience-journey/

Kildekreditering: AWS.

Thumbnail: OpenAI Image 2 / hogby.ai.