Mandag morgen kan larme. Ikke kun i Slack. Et enterprise-team på AWS bliver ofte mødt af en strøm af AWS Health-notifikationer om Amazon Linux 2 end-of-life, RDS-versionsudfasninger og EC2-instanser, der står til retirement på tværs af 50+ konti. Det er ikke én alarm, det er et kor. Og det vigtige forsvinder i støjen. Hvad rammer produktion i dag, hvad kan vente, og hvor sidder forretningsrisikoen faktisk?
Her peger AWS selv på et hul. Ifølge et aktuelt blogindlæg beskrives netop scenariet ovenfor, og hvordan teams uden selvbetjent analyse ikke hurtigt kan skelne mellem akutte hændelser og planlægningsstof. Konsekvensen er reaktivt brandværn. Der bruges tid på at spørge andre om at fortolke events, før man træffer beslutninger. Det koster tempo og fokus. Og ja, nogle gange også nattesøvn.
Hvad AWS allerede leverer
AWS Health stiller data til rådighed via AWS Health API og Amazon EventBridge, hvilket blogindlægget også understreger. Det er solide kilder til både historiske og nær-realtids hændelser. Man kan bygge streams, berige med tags og lande i et lager. Men rå data er ikke svar. Når spørgsmålene er flydende og kontekstuelle, bliver faste dashboards for stive.
EventBridge er god til at udløse flows. Health API er god til dybe udtræk. Ingen af delene besvarer af sig selv et praktisk spørgsmål som: “Hvilke RDS-versioner i produktion bliver unsupported inden for 60 dage, og hvilke teams ejer dem.” Her knækker BI-skemaet ofte. Man skal kende tabellen, kolonnen og joinet. Eller spørge en TAM og vente.
Problemet i detalje
Statiske dashboards kan meget, men de forudsætter spørgsmålene på forhånd. Driften gør det omvendt. Spørgsmålene ændrer sig time for time. Det er også et afhængighedsproblem. Blogindlægget nævner eksplicit, at mange teams ender med at vente på Technical Account Managers for fortolkning og konsekvens, hvilket forsinker beslutninger – selv når svaret viser sig at være trivielt i bakspejlet.
Derudover er der spredning på tværs af konti og regioner. Tusindvis af events kræver manuel kategorisering og prioritering, hvilket æder timer. Og fordi der ikke er et centralt, samtalebaseret analysetryk, bliver koordinering og overblik sværere. Man reagerer på det sidste ping frem for det største problem. Det er menneskeligt. Bare ikke optimalt.
Chaplin i korte træk
AWS har derfor frigivet Chaplin, Customer Health and Planned Lifecycle Intelligence Nexus. Det er et open-source eksempelprojekt, beskrevet i blogindlægget og med fuld repo på GitHub. Arkitekturen er agentisk AI via Amazon Bedrock, eksponeret gennem Model Context Protocol, så MCP-klienter kan bruge det som værktøj. Og brugeren taler almindeligt sprog – ikke SQL.
Pointen er ikke et nyt dashboard. Chaplin stiller i stedet værktøjer til rådighed, som en MCP-kompatibel assistent kan kalde. Det giver on-demand rapporter og sammenfatninger. Brugeren kan spørge indtil billedet giver mening og derefter skifte gear fra analyse til plan. Samtalen bliver arbejdsfladen.
Sådan virker Chaplin i praksis
Dataflowet er skitseret i kilderne: AWS Health-eventdata hentes via Health API og EventBridge, landes i S3 og lægges i DynamoDB. Ovenpå kører en MCP-server, der både kan lave hurtige opslag i DynamoDB og mere åben analyse via en agent, der bruger Bedrock-modeller til sammenfatning og prioritering. MCP-klienten er indgangen til det hele.
Fra brugerens stol kan man fx spørge: “Vis EC2-retirement events, der påvirker produktionskonti i eu-west-1 og eu-central-1, sorteret efter dato og forretningskritikalitet.” Svaret er ikke kun en liste. Det kan inkludere kontekst: hvem ejer ressourcen, hvilken SLA er ramt, og hvilken migration eller patchplan der typisk er relevant. Det er en struktur, der gør data anvendelige hurtigere.
Tekniske forudsætninger og krav
For at komme i gang kræver Chaplin tre byggeklodser: en Bedrock-kompatibel model til det sproglige lag, en MCP-server og klienter samt integration til AWS Health via EventBridge og Health API. Ifølge GitHub-repoet består dataindtaget af en pipeline til S3 og DynamoDB, mens MCP-serveren eksponerer tool-interfaces, som assistenter kan kalde. Deployment-vejledning findes i repoet, og blogindlægget peger eksplicit dertil.
Der er begrænsninger. Agentlaget er kun så godt som de data, det får. Ressource-tags, miljøklassifikation og ejerskab skal være på plads for, at svaret bliver brugbart. Og man skal være opmærksom på modelvalg, quota og omkostninger. Et praktisk råd: MCP-klienter varierer i modenhed – test den konkrete klient, I vil bruge, før I ruller bredt ud. Det sparer overraskelser.
Sikkerhed, dataprivatliv og governance
At sende eventmetadata gennem et agentlag rejser fornuftige spørgsmål. Hvad forlader kontoen, hvor bliver det logget, og hvilke roller må kalde hvilke værktøjer. Et minimumsdesign bør inkludere kryptering i hvile og transit, rollebaseret adgang på MCP-serverens værktøjer og central logning af prompts, værktøjskald og svar til revision.
Model-livscyklus hører også til her. Når modeller opdateres, kan svarformat og prioriteringsadfærd ændre sig. Indfør versionsstiftede prompts og regressionstests mod kendte event-sæt, så I opdager ændringer i tide. Derudover bør retention af samtalelogge og datasæt afklares af compliance – især hvis eventmetadata kan kobles til persondata via tags eller bilag.
Hvad ændrer det i driften
Selvbetjent triage flytter arbejdet frem i forløbet. Mindre ventetid på TAM-fortolkninger og færre manuelle hop mellem dashboards. Beslutninger kan lande hurtigere. Men nye roller følger med. Nogen skal eje prompts, værktøjsopsætning og kvalitetssikring. Nogen skal drive datasundhed for tags, konti og ressourcekatalog. Og change management skal forholde sig til, at triagen kan foreslå handling meget hurtigt.
Hverdagen ændrer tempo: flere korte spørgsmål og svar i MCP-klienten, færre møder for at afgøre “hvad er op og ned”. Det er en gevinst, hvis man samtidig strammer op på verifikation, så fejlagtige sammenfatninger ikke glider ind som sandheder. Tillid bygges med tal og tests, ikke med begejstring.
Automatisering og autoremediation
Chaplin er et analyse- og dialoglag, men det peger direkte ind i automations. Blogindlægget nævner, at kvalificerede Health events kan linkes til AWS Transform-templates, så man kan handle direkte. Her ligger potentialet – og risikoen. “Safe by default” bør være udgangspunktet: begynd med read-only checks og advisories, før I udløser ændringer.
Hvad kan automatiseres trygt først: planlagte EOL- og versionsopgraderinger for RDS med prævaliderede runbooks. EC2-retirements med kontrolleret re-provisionering, hvor kapacitetsplanen kendes. Patching med blackout-vinduer og kanarier. Hvad bør ikke automatiseres uden menneskelig review: usikre sikkerhedshændelser, tvetydige påvirkningsanalyser og alt med uklart ejerskabstagging. Politikkerne skal være eksplicitte og testede.
Gevinster vs. risici
Den sandsynlige gevinst er lavere MTTR på kendte hændelsestyper og mindre håndholdt sortering. Men kilderne leverer ingen uafhængige effektmålinger endnu – ingen tal på reduktion i falske positive eller præcise omkostningsbesparelser. Det er værd at notere. Der er også fejlrisici: modelsammenfatninger kan misforstå tags, priority eller afhængigheder. Og der er vedligehold: MCP-server, datastrømme, prompts, regressionstests. Alt skal plejes.
En praktisk afvejning: Brug agentlaget til at skære tiden ned til beslutning, men fasthold en letvægts-review de første måneder. Mål effekten, før I giver agenterne større råderum. Bevidst konservativt.
En køreplan for en PoC
Start med ingestion: træk AWS Health-events via EventBridge og Health API, land i S3 og læg i DynamoDB som i repoets skitse. Etablér et baseline-filter, der mærker konti, miljøer og ejerskab. Sæt MCP-serveren op og peg en Bedrock-model på. Tilføj et model-ask-lag med faste, versionerede prompts til de mest almindelige spørgsmål.
Integrer en MCP-klient, som jeres team kan leve i – CLI eller IDE-assistent. Design et validerings- og tilbagekaldsforløb: hvis svar afviger fra sandhedstabeller, skal modellen eller prompter rulles tilbage og issues logges. Først når svarene er stabile, begynder I at tegne små, policy-drevne automations i read-only. Senere: kontrollerede write-handlinger bag feature flags.
Hvordan teams validerer resultater
Definér KPI’er på forhånd: falske positive i prioritering, tid fra event til beslutning, antal eskalerede hændelser pr. måned, klassifikationsnøjagtighed mod en sandhedsmatrix med håndmærkede events. Kør A\/B i en periode: halvdelen af teamet arbejder med Chaplin-svar, halvdelen uden. Sammenlign tempo og kvalitet.
Lav regressionsæt med historiske Health-events og ønskede outputs. Kør dem ved hver ændring af model, prompt eller datafelt. Dokumentér ændringer i adfærd. Og hold fast i disciplinen: versionsstyring af prompts og politikker, så I altid kan forklare et svar. Når noget går galt, er det guld værd.
Support- og kontraktkonsekvenser
Når triagen bliver selvbetjent, ændrer relationen til AWS Support og TAMs sig. Rutinefortolkning flytter in-house, mens komplekse root cause- og roadmap-spørgsmål fortsat hører til hos AWS. Det kan påvirke SLA’er. Overvej at dreje supportaftaler mod færre reaktive ad hoc-samtaler og mere planlagt sparring på større ændringer og migrationsplaner.
Det kan også lette kommunikationen den anden vej. Et samtaleværktøj, der dokumenterer, hvilke spørgsmål der stilles oftest, giver et bedre udgangspunkt for at bede AWS om produktforbedringer. Små ting, men vigtige i længden.
Kritiske usikkerheder og modsatrettede signaler
Kilderne er klare om arkitekturen og formålet, men leverer ikke kvantitativ dokumentation for nøjagtighed i klassifikation eller reduktion i MTTR. Der er også et åbent spørgsmål om, hvor længe man kan stole på modelsammenfatninger uden menneskelig review. Kort svar: ikke længe i begyndelsen. Lidt længere, når regressionsættet vokser.
Et andet punkt er vendor lock-in. Chaplin lægger sig naturligt i AWS-økosystemet med Bedrock og Health. Det er logisk, men reducerer valgmuligheder. MCP giver dog en standardiseret grænseflade til værktøjer, hvilket kan afbøde noget af bindingen. Ikke alt, men noget. Det bør indgå i beslutningen.
Konklusion og anbefalinger
Chaplin adresserer et reelt problem: ikke flere dashboards, men bedre samtaler over de data, teams allerede har. Arkitekturen, som beskrevet af AWS og vist i GitHub-repoet, er til at gå til: Health ind via EventBridge og API, S3 til DynamoDB, MCP-server, Bedrock-model. Det bringer spørgsmål tættere på svar – og beslutninger tættere på handling.
Hvis man vil prøve det af, er rækkefølgen enkel: få data rent ind, få tagging og ejerskab på plads, sæt MCP og Bedrock op, og mål effekten skarpt. Hold automations i snor med policies, canaries og rollback. “Fuld auto fra dag ét” frister, men disciplinen betaler sig i drift.
