AWS lanserer lokal emulator skrevet utelukkende av autonome KI-agenter

AWS lanserte AWS Emulator 11. november 2026, en lokal emulator som er generelt tilgjengelig, bygget på 438 AWS API-modeller som dekker mer enn 200 tjenester. Autonome KI-agenter skrev og testet koden, slik at utviklere og kodeagenter kan prøve ut AWS API-er på sine egne maskiner uten en AWS-konto.

AWS CLI, AWS SDK-er og kodeagenter kobler seg til via et lokalt HTTPS-endepunkt og bruker de samme API-ene som de ville brukt i skyen. Miljøvariabler sender disse verktøyene til brukerens maskin, slik at applikasjonskoden forblir uendret. Et lanseringsinnlegg fra AWS beskriver RPM- og Debian-pakker for Linux, Docker på macOS og Windows samt en innebygd modus for Rust-tester. Det påløper ingen ekstra tjenesteavgift, men kundene betaler fortsatt for AWS-ressurser de distribuerer i skyen.

For kodeagenter legger emulatoren AWS-infrastrukturen inn i en sløyfe der agenten skriver, kjører og leser: Den kan opprette en ressurs, undersøke resultatet og revidere koden uten å vente på distribusjon til en AWS-region. AWS-dokumentasjonen nevner også utviklingsservere og kontinuerlig integrasjon som miljøer emulatoren kan brukes i, der forespørsler sendes til emulerte ressurser i stedet for AWS.

Tre agentteam bygger og vedlikeholder koden

Matthew Goldberg, senior sjefsingeniør i AWS, sa i en beretning om ingeniørarbeidet at teamet hans verken skrev eller gjennomgikk emulatorens kode. I stedet bygget mennesker stillaset rundt arbeidet, blant annet spesifikasjonene, testverktøyene, godkjenningskravene for sammenslåing og utgivelsesløpet. Prosjektet startet da kodeagenten Kiro laget en brukbar Amazon SQS-emulator på omtrent 15 minutter etter å ha fått beskjed om å skrive tester, validere dem mot ekte AWS og bygge en implementasjon i minnet som besto testene. Goldberg lot deretter Kiro videreutvikle prototypen i løpet av en helg; for å gjøre den til et robust produkt måtte de nødvendige sikkerhetsmekanismene rundt arbeidet på plass.

Tre avgrensede agentteam fordeler nå arbeidet mellom seg. Testforfatterne utformer scenarioer basert på offentlige API-modeller og kontrollerer dem mot ekte AWS. Feilsøkingsagenter kjører testene på nytt og grupperer feil som kan ha samme grunnårsak, mens retteagenter tar for seg én sak hver. Goldberg oppgir at det finnes titusenvis av samsvarstester, og at tusenvis av saker rettes daglig mens hundrevis av agenter arbeider parallelt.

Hver foreslåtte retting må kunne kompileres og bestå automatiserte kontroller av kodestandarder, sikkerhet og samsvar før den slås sammen. En uavhengig sikkerhetsagent gjennomgår endringene kritisk under utviklingen og på nytt i utgivelsesløpet. «Uten denne godkjenningsporten ville vi ikke hatt tillit til det agentene våre bygger», skrev Goldberg.

Deretter går endringene gjennom AWS CodeCommit og CodePipeline før de publiseres på GitHub. Det offentlige repositoriet viser historikken over kodeendringer og separate mapper for løste og uløste samsvarsproblemer. AWS publiserte koden under CC0, en erklæring om at den frigis til det offentlige domenet, med unntak av leverandørkode som er underlagt Apache 2.0. Repositoriet tar ikke imot forespørsler om å slå sammen kodeendringer, men brukere kan rapportere feil og mangler i samsvaret via GitHub Issues.

Samsvarspoeng viser begrensningene

En samsvarstest er en kort arbeidsflyt som kontrolleres mot ekte AWS. For å bestå må emulatoren samsvare med svaret på hvert kall, inkludert statuskoden, innholdet og den nøyaktige feilkoden og feilmeldingen, samt ressursene og dataene arbeidsflyten oppretter. Operasjoner som ikke er implementert, returnerer HTTP 501 (Not Implemented), slik at feil blir synlige umiddelbart. Hver utgivelse oppgir antall beståtte tester for hver tjeneste, og AWS advarer om at flere tester kan gi lavere poengsum selv om emulatoren blir bedre.

Hver test i den offentlige evalueringspakken er verifisert mot minst to isolerte AWS-sandkassekontoer, og repositoriet gjør det klart at atferd som ikke er testet, ikke er verifisert.

Disse poengsummene gjør ikke emulatoren til et miljø for sikkerhetstesting. Den evaluerer ikke AWS Identity and Access Management (IAM) eller ressursbaserte policyer på samme måte som AWS, så en forespørsel som AWS avviser, kan lykkes lokalt. Emulatoren er ment for utvikling og testing; produksjonsarbeidsbelastninger og sikkerhetstesting av applikasjoner er utenfor virkeområdet. Hver instans er beregnet på én konto og én region, lagrer ressurser i minnet og sletter dem når den stoppes.

Ingeniørarbeidet dreies mot spesifikasjoner og tester

I lanseringsinnlegget beskrev Swaminathan Sivasubramanian ingeniørens rolle som å avgjøre hva som skal bygges og lage spesifikasjonene, testene og godkjenningskravene for sammenslåing som fastslår hva som regnes som korrekt, mens agenter skriver og kontrollerer koden.

Sammenligningen hans med Alf, en tidlig distribuert låsetjeneste fra Amazon, gir et konkret eksempel. Det tok omtrent fire måneder å bygge den opprinnelige replikeringsmotoren. Sivasubramanian sa at en ny versjon laget med Kiro først krevde fire netter med tilsyn fordi agenten ikke hadde noen måte å kontrollere resultatene sine på. Etter at han ga den en spesifikasjon og et testmiljø, tok det omtrent to timer å bygge den på nytt.

AWS Emulator omsetter denne lærdommen til et ferdig produkt: Agenter genererer og reparerer implementasjonen, mens ingeniørene definerer hvilken atferd som er akseptabel, og automatiserer håndhevingen av kravene. Hvor nyttig emulatoren blir i praksis, avhenger nå av den voksende offentlige testpakken og de gjenværende samsvarsmanglene, mens sikkerhets- og produksjonsvalidering fortsatt krever ekte AWS.