AWS melder sig ind i agent-æraen med AgentWatch, et ambient overvågningslag, der ifølge AWS flytter fokus fra manuel brandbekæmpelse til kontinuerlig, kontekstuel observabilitet. Ambitionen er klar: færre sen-kommende CloudWatch-alarmer, færre skjulte Lambda-fejl og mindre fragmentering på tværs af EC2 og konti. Vi har læst deres gennemgang og holdt den op mod vores egne erfaringer i drift. Det ligner et reelt fremskridt – men også et sæt nye valg, som teams skal træffe for at få reel værdi uden at skabe nye blindgyder.
Mange driftsteams arbejder stadig for reaktivt. Når Slack vibrerer kl. 03.12, er skaden ofte allerede sket. AgentWatch forsøger at fange mønstre før alarmen går, samle hændelser til en meningsfuld historie og kun involvere mennesker, når vurdering er nødvendig. Lovende – men også risikabelt, hvis roller, data og processer ikke er på plads.
Hvad er AgentWatch
Ifølge AWS’ egen gennemgang er AgentWatch en ambient AWS-overvågningsagent designet til DevOps-teams. Agenten observerer kontinuerligt infrastrukturen, analyserer mønstre i metrics og logs og aktiverer mennesker først, når der er brug for handling eller vurdering. Den demonstreres med 15-minutters tjek, hvor den samler CloudWatch-metrics, logs og alarmer på tværs af flere AWS-konti, leverer rapporter direkte i Slack og svarer på naturlige sprogspørgsmål om infrastrukturens tilstand. Det er beskrevet i AWS’ blogpost om AgentWatch.
AWS positionerer AgentWatch som mere end en ny dashboard-widget: en agent, der kører ved siden af infrastrukturen, peger på det væsentlige og foreslår næste skridt. Bloggen viser også “human-in-the-loop”-mønstre, så man kan bevare kontrol, selvom agenten arbejder kontinuerligt i baggrunden. Tekniske læsere vil bemærke, at AWS omtaler Amazon Bedrock AgentCore Runtime som hostingmiljø for selve agenten, hvilket placerer løsningen i deres Bedrock-økosystem.
Hvilket problem forsøger det at løse
Hvis man skal tro AWS’ problemkortlægning, kommer CloudWatch-alarmer ofte for sent, Lambda-fejl kan hobe sig op i det skjulte, og EC2-degradering opdages først, når en kunde brokker sig. Det matcher, hvad vi ofte ser. Tidsrøveren er ikke mangel på data, men overload af signaler uden kontekst. Teamet bruger timer på manuel triage og efterfølgende post mortems, hvor den røde tråd mellem metrics, logs og events først opstår bagefter – ikke undervejs.
AgentWatch går efter hullet imellem: kontinuerlig aggregering, mønstersøgning og opsummeringer, der peger på det, der faktisk betyder noget. AWS siger direkte, at målet er mindre brandslukning og mere forebyggelse. Mindre natlig alarmstøj og hurtigere sammenhæng i hændelsesforløb er præcis det, der batter i hverdagen.
Hvordan virker det i praksis
I den viste implementering kører agenten infrastruktur-tjek cirka hvert 15. minut. Den samler CloudWatch-metrics, logs og alarms fra flere AWS-konti, kondenserer det til en fortolkning og poster en rapport i Slack. Herfra kan on-call spørge i naturligt sprog: “Hvad ser du omkring latency i checkout-tjenesten i prod?” – og få et svar, der inkluderer korrelationer på tværs af de tilknyttede konti. Friktionen ved at hoppe mellem faner og værktøjer for at bygge en incident-historie mindskes markant.
AWS viser tre former for menneske-i-loop, så agenten ikke kører i blinde: foreslå, opsummere og – i nogle mønstre – forberede handlinger, der kræver godkendelse. Det bliver først stærkt, når runbooks og eskalationsregler er afstemt med det.
Hvad kan det forbedre operativt
To gevinster er mest realistiske. For det første tidligere detektion, fordi agenten ikke venter på, at en enkelt alarm krydser en tærskel, men kigger på mønstre på tværs. For det andet bedre prioritering efter forretningspåvirkning, fordi aggregeringen kan koble tekniske symptomer til de services, der betyder mest for kunder og omsætning. Det er sådan noget, der i praksis kan sænke MTTR og reducere falske positiver – hvis korrelationerne er gode nok.
Vi har ikke set uafhængige, kvantificerede tal fra AWS for MTTR-forbedringer, så ingen procenttaler her. Kvalitativt giver det mening: når triage får kontekst med det samme, går mindre tid med at lede i mørket. I en nylig pilot (multi-account, tung Lambda-brug) oplevede vi markant hurtigere berigelse af incident-historier – og til gengæld nye spørgsmål om adgang til produktionslogs.
Begrænsninger og risici
AgentWatch løser ikke governance. Den kræver tværgående læseadgang til metrics og logs – og måske mere, hvis man vil tættere på automation. Uden least privilege-roller, audit-spor og tydelige godkendelsesflows ender man med en uigennemsigtig bot, der kan se for meget. Det er ikke acceptabelt i regulerede miljøer.
Detektionerne er i praksis en black box. AWS beskriver ikke præcist, hvilke modeller eller algoritmer der bruges til mønster- og anomali-detektion. Forklarbarhed betyder noget, når man vil ændre vagtplaner og automatisere reaktioner. Og så er der datakvaliteten: hvis taggingskemaer, logstrukturer og SLA-definitioner ikke er standardiserede, falder hele kortspillet sammen. Vi ser 2 ud af 3 piloter fejle primært på metadata-kaos. Kedeligt – og vigtigt.
Praktiske første skridt
Begynd smalt og målbart. Først: kortlæg signaler og konti – hvilke få services skaber oftest kundeimpact, og hvilke metrics/logs beskriver deres helbred? Andet: kør en pilot med menneske-i-loop-politikker (“observer”, “foreslå”, “handle”) – med klar revert. Tredje: mål baseline MTTR, false positive-rate og hvor ofte on-call vækkes unødigt. Ellers aner I ikke, om agenten gør en forskel eller bare larmer pænere.
Små råd fra felten: hold Slack-rapporter korte og konsekvente i format. Inkludér altid næste bedste handling og ejerskab. Læg et fast sted for “agent notes” i jeres incident tickets, så eftersporet bliver nemmere i post mortems. Og hav en simpel “kill switch” – en IAM-policy eller feature-flag – så teamet kan bremse uønsket adfærd midt om natten.
Governance og sikkerhed
Ambient agenter er sultne efter data. Til produktion kræver det, at least privilege håndhæves kontant: afgrænsede cross-account IAM-roller, tydelige ressource-tags for dataklassifikation og revisionsspor for alle læsninger og forslag til handlinger. Ellers ender man i compliance-gråzoner. Der er også et åbent spørgsmål til AWS: hvordan adresseres dataresidency, retention og sektorregler i AgentWatch-opsætningen? Bloggen uddyber det ikke.
Definér derudover, hvem der godkender hvad. Hvilke typer remediation må agenten foreslå uden godkendelse? Hvilke kræver Change Advisory? Vi ser 60–70 procent af forsinkelser i lignende projekter komme fra governance-afklaringer, ikke fra kode. Få sikkerhed og drift med ind fra start, ellers bliver det en lang eftersnak.
Hvad ændres i teamets hverdag
On-call-rollen får mere kuratering og mindre ren log-gravning. Runbooks skal have “agent-trin”, så forslag kan mappes til kendte handlinger. Post mortems bør udvides med “agentens hypoteser” kontra “menneskets konklusioner”, så man lærer, hvornår korrelationerne holdt. Kompetencemæssigt skal flere kunne læse og udfordre agentens forklaringer – ikke bare følge dem.
Vi havde en sag, hvor agenten foreslog throttling-justering på baggrund af CPU-mønstre. Fornuftigt på papiret, men konteksten var en kampagne med forudset load. Løsningen: en runbook-blok for planlagt spidsbelastning, der midlertidigt justerer følsomheden. Den slags greb afgør, om folk stoler på agenten – eller ignorerer den.
Tjekliste før pilot
Teknisk bør I sikre fem ting. Ét: cross-account-roller og trust policies, der er testet og dokumenteret. To: standardiseret tagging for services, miljøer og kritikalitet. Tre: log-retention og skemaer, så agenten kan sammenligne på tværs. Fire: klare SLA/SLO-mål, så prioritering giver mening. Fem: integration til jeres incident-værktøjer, fx PagerDuty og Jira, så rapporter bliver handlinger – ikke kun pæne beskeder.
Og et ekstra punkt: kapacitet og pris. 15-minutters aggregering og analyser øger ingest og lagring. Sæt et budget-interval for piloten og overvåg månedlige omkostninger. Det er ærgerligt at skære 10 minutter af MTTR og så betale det hele tilbage i regninger.
Hvad skal overvåges først
Prioritér flows, ikke systemer. Hvor gør fem minutters nedetid mest ondt? Start dér. Inkludér også komponenter med historisk høj støj – hvis agenten kan tæmme dem, vinder I hurtigt legitimitet. Compliance-risiko kan være en anden akse: overvåg logs, der bærer adgangs- og transaktionsspor, så uautoriserede mønstre opdages tidligere.
Det kan være fristende at tage “alt med det samme”. Lad være. En til to kritiske kunderejser er rigeligt til at bevise pointen – eller afsløre huller i tagging og roller.
Hvor giver AgentWatch mest værdi
Multi-account SaaS med mange Lambda-funktioner er oplagt. Her er mønstrene ofte spredt, og manuel korrelation sluger tid. Teams med udtalt alert fatigue kan også få en hurtig gevinst, hvis agenten får lov at kuratere og fjerne gentagelser. Miljøer med hyppige release-cadencer kan bruge agentens summarier til at holde øje med regressioner uden at drukne i støj.
Omvendt får små monolitter med simpel alarmopsætning mindre udbytte. Og steder uden et minimum af metadata-disciplin risikerer bare at få endnu et lag af forvirring. Vi har set begge dele på nært hold.
Hvad kan gå galt
Over-automation er det første. Hvis agenten får for brede beføjelser uden klare rulle-tilbage-strategier, skaber den sine egne incidents. Nummer to er uklare eskalationsregler, hvor mennesket tror, agenten har den – og omvendt. Tredje er nye blindzoner: hvis agentens modellogik kun ser “de kendte” signaler, kan den overse langsom forrådnelse i kanterne.
Derfor: bevar friktion nogle steder. Gør det bevidst svært for agenten at ændre produktionsparametre uden en tydelig godkendelse. Det koster få sekunder, men køber tryghed – især de første måneder.
Agent-æraen, kort perspektiv
Det passer ind i et større skifte, hvor langløbende agenter kan tage opgaver over dage og uger, ikke kun sekunder. Branchen taler allerede om det, og eksempler på fler-døgns agentkørsler underbygger tendensen. Pointen for drift er jordnær: et baggrundslag, der samler tråde, som ellers først bindes efter en outage.
Retning er ikke mål. Ambient overvågning er et middel. Værdien kommer først, når opsummeringer kan kobles til klare beslutninger og handlinger i jeres domæne.
Snillds anbefalede næste skridt
Start smalt, mål hårdt, og byg governance først. Vi kører typisk en kort workshop for at tegne signallandskabet, definerer “observer/foreslå/handle” som styringsramme og sætter 6–8 uger af til en pilot med faste KPI’er for MTTR, falske positiver og pager-fatigue. Runbooks får små blokke, som agenten kan støtte sig op ad, i stedet for at opfinde handlinger i farten.
Det er bevidst lavpraktisk. Den slags disciplin slår flotte demos. Forskellen mærkes først, når man sidder med det i hænderne – eller når Slack faktisk er stille kl. 03.12.
Konklusion
AgentWatch er et seriøst bud på proaktiv, kontekstuel overvågning i AWS. AWS’ gennemgang viser et produkt, der kan observere kontinuerligt, samle på tværs af konti, levere Slack-opsummeringer og svare på spørgsmål i naturligt sprog. Det er et skridt frem, ikke en tryllestav. De store gevinster ligger i det grundlæggende: tagging, IAM, runbooks, integrationer og målinger.
Bundlinjen: test det – med hegnspæle. Hvis governance, metadata og eskalationsregler er på plads, kan AgentWatch reducere både støj og tid til klarhed. Hvis ikke, får I bare et nyt lag at administrere. Valget er jeres.
Kilder: AWS’ blogpost om AgentWatch som primær dokumentation for funktioner og demo. Vores praktiske anbefalinger bygger på Snillds rådgivningsarbejde og piloter med ambient overvågning. For agent-paradigmet generelt henviser vi til branchens dækning, men holder fokus på AWS’ annoncering. Tjek i øvrigt jeres egne konti via AWS Console, hvis I vil vurdere jeres nuværende signallandskab – dokumentation findes i AWS’ officielle kanaler.
