AWS-agenten foreslår skyfikser – bare Business+ slipper inn

AWS åpnet offentlig forhåndsversjon av AWS Well-Architected Agent 1. oktober 2026. Tjenesten sammenholder ressurskonfigurasjoner, bruksmålinger og applikasjonstopologi på tvers av mer enn 65 AWS-tjenester og foreslår endringer innen kostnad, sikkerhet, ytelse og robusthet. Forslagene kan inneholde oppdatert infrastrukturkode eller kommandoer, men et forslag er ennå ingen gjennomført endring.

I AWS’ produktdokumentasjon er Business+ laveste kvalifiserende støtteplan, mens anbefalinger på applikasjonsnivå fortsatt er i beta. AWS ber kundene gjennomgå hver anbefaling før de handler på den. For en norsk virksomhet er derfor både støtteplanen, hvilke kontoer agenten får lese, og hvem som godkjenner en utbedring avgjørende før aktivering.

Støtteplanen avgjør hvem som får tilgang

FactualMinds’ oversikt over tilgangsgrensene viser at Developer og Business ikke gir adgang, mens Business+ tillater to agentprofiler med sju applikasjoner per profil. Én profil kan analysere opptil 100 AWS-kontoer. Enterprise On-Ramp, Enterprise Support og Unified Operations gir også tilgang, med høyere grenser for profiler og applikasjoner. En betalt Business-plan er dermed ikke nok; det er det konkrete støttenivået som avgjør om en profil kan opprettes.

Et betinget regneeksempel gjør grensen tydelig. Har fire norske kunder henholdsvis Developer, Business, Business+ og Enterprise Support, kvalifiserer de to siste til agenten. Resultatet er to av fire, uavhengig av hvor mange kontoer hver kunde har. Innenfor en kvalifisert virksomhet kan profilgrensen også påvirke hvordan produksjon og test, eller applikasjoner med ulike eiere, deles opp. At én profil kan favne mange kontoer, betyr ikke at alle bør samles under samme tilgang og godkjenningsløp.

Agentprofiler opprettes i amerikanske vertsregioner, men kan undersøke ressurser i kommersielle AWS-regioner. En norsk arbeidslast kan altså inngå i analysen selv om profilen ligger i USA. Det skillet er relevant når virksomheten vurderer hvor administrasjonsfunksjonen etableres og hvilke kontoer den skal omfatte. Regionvalget for selve arbeidslasten beskriver ikke alene oppsettet for agenten.

Funnene blir forslag på flere nivåer

Agenten prioriterer funn ut fra virksomhetens oppgitte mål, ikke bare ut fra en teknisk sjekkliste. Den kan foreslå tiltak for en enkelt ressurs, for ressurser som inngår i samme applikasjon, eller for et arkitekturmønster. Anbefalingen viser også avveininger mellom de områdene den vurderer. Et forslag som styrker robustheten, kan derfor måtte vurderes opp mot kostnaden og virkningen på ytelsen før noen bestemmer seg.

Planlagt analyse av eksisterende ressurser og en arkitekturgjennomgang av infrastruktur som kode er forskjellige funksjoner. Gjennomgangen av kode kan startes ved behov før utrulling og gi forslag til endrede maler. Dermed kan et problem i et planlagt oppsett komme til syne før det blir en del av produksjonsmiljøet. Den løpende analysen tar derimot utgangspunkt i ressursene agenten får tilgang til i de valgte kontoene og regionene.

En utbedring kan leveres som trinn i konsollen, CLI-kommandoer eller endret infrastrukturkode, avhengig av anbefalingen. Det gjør forslaget konkret nok til å vurderes i en vanlig endringsprosess. Samtidig kan agenten mangle lokal kunnskap om en applikasjons avhengigheter, driftskrav eller kostnadsramme. Den som eier arbeidslasten, må derfor vurdere både ønsket gevinst og virkningen av den bestemte endringen som foreslås.

Lesetilgangen krever et bevisst kontoomfang

For å analysere miljøet bruker agenten kundeadministrerte IAM-roller som gir tilgang til opplysninger om ressurser, målinger og topologi. Profilen avgrenser hvilke kontoer og regioner som inngår. Det er en sikkerhetsbeslutning: Jo flere kontoer som tas med, desto større del av miljøet kan agenten undersøke. En kontrollert innføring kan begynne med en avgrenset arbeidslast og de kontoene som faktisk hører til den.

Rettighetene for skanning og rettighetene for å gjennomføre en utbedring bør behandles hver for seg. Lesetilgang til en konfigurasjon gir ikke i seg selv grunnlag for å kjøre et generert skript mot produksjon. Ved oppsettet bør ansvarlige kontrollere hvilke IAM-roller agenten får bruke, hvilke kontoer rollene åpner, og om rettighetene er begrenset til det analysen trenger. Den vurderingen blir særlig viktig hvis flere applikasjonseiere deler samme profil.

Et forslag til infrastrukturkode kan følge virksomhetens vanlige løp for kodeendringer: gjennomgang av forskjellen, test i et egnet miljø og godkjenning fra den som eier arbeidslasten før utrulling. Det er en anbefalt kontroll, ikke en automatisk godkjenningsmekanisme i agenten. Slik kan tekniske funn fra forhåndsversjonen brukes uten at formuleringen «klar til implementering» blir tolket som tillatelse til å endre produksjon.

Beta krever kontroll av hver anbefaling

Betamerkingen gjelder særlig anbefalinger som trekker slutninger om en hel applikasjon på tvers av ressurser. Der kan en feil antakelse om sammenhengen mellom komponenter påvirke flere deler av løsningen enn et forslag om én ressursinnstilling. Også andre anbefalinger er generert ved hjelp av KI og kan være ufullstendige. Vurderingen må derfor gjelde det konkrete forslaget og arbeidslasten det skal brukes på, ikke bare typen anbefaling.

For en kvalifisert kunde er den første reelle beslutningen hvor bredt agenten skal få lese, og hvem som får myndighet til å gjennomføre tiltakene den foreslår. Med et avgrenset kontoutvalg kan virksomheten se hvilke funn som kommer, teste eventuelle kodeendringer og la ansvarlig eier avgjøre om de skal rulles ut. Støtteplanen åpner døren til forhåndsversjonen; ansvaret for endringer i skymiljøet ligger fortsatt hos kunden.

Les også:

• MongoDB samler agentminne og styring – men Agent Engine er bare i preview
• Rystad Energy slipper inn Marlin – grunnleggeren beholder kontrollen
• GitHub Actions uten AWS-nøkler: en for bred trust policy åpner kontoen