AWS lanserar lokal emulator som helt har skrivits av autonoma AI-agenter

AWS lanserade AWS Emulator den 11 november 2026. Det är en lokalt körbar emulator som nu är allmänt tillgänglig och bygger på 438 AWS API-modeller som täcker fler än 200 tjänster. Autonoma AI-agenter skrev och testade koden, vilket ger utvecklare och kodningsagenter möjlighet att testa AWS API:er på sina egna datorer utan ett AWS-konto.

AWS CLI, AWS SDK:er och kodningsagenter ansluter via en lokal HTTPS-slutpunkt och använder samma API:er som i molnet. Miljövariabler omdirigerar verktygen till användarens dator, så att programkoden förblir oförändrad. I AWS lanseringsinlägg beskrivs RPM- och Debian-paket för Linux, Docker på macOS och Windows samt ett inbäddat läge för Rust-tester. Ingen extra serviceavgift tillkommer, men kunderna betalar fortfarande för AWS-resurser som de driftsätter i molnet.

För kodningsagenter placerar emulatorn AWS-infrastrukturen i en skriv-kör-läs-loop: en agent kan skapa en resurs, granska resultatet och ändra sin kod utan att behöva vänta på driftsättning i en AWS-region. I AWS dokumentation anges även utvecklingsservrar och kontinuerlig integrering som miljöer där emulatorn kan användas, med förfrågningar riktade till emulerade resurser i stället för AWS.

Tre agentteam bygger och underhåller koden

Matthew Goldberg, chefsingenjör på högsta nivå på AWS, uppgav i en teknisk redogörelse att hans team varken skrev eller granskade emulatorns kod. I stället byggde människor upp strukturen runt arbetet, bland annat specifikationerna, testmekanismen, spärrarna för kodsammanslagning och lanseringspipelinen. Projektet började när kodningsagenten Kiro på ungefär 15 minuter tog fram en fungerande Amazon SQS-emulator utifrån en instruktion om att skriva tester, validera dem mot verkliga AWS och bygga en minnesbaserad implementation som klarade testerna. Goldberg lät sedan Kiro vidareutveckla prototypen under en helg. För att göra den till en robust produkt krävdes de omkringliggande skyddsmekanismerna.

Arbetet är nu fördelat mellan tre agentteam med tydligt avgränsade uppgifter. Testförfattare utformar scenarier utifrån offentliga API-modeller och verifierar dem mot verkliga AWS. Ärendeidentifierare kör om testerna och grupperar fel som kan ha samma grundorsak, medan åtgärdsagenter tar sig an ett ärende var. Goldberg uppger att det finns tiotusentals fidelitetstester och att tusentals ärenden åtgärdas varje dag, samtidigt som hundratals agenter arbetar parallellt.

Varje föreslagen korrigering måste gå att kompilera och klara automatiserade kontroller av kodningsstandarder, säkerhet och fidelitet innan den slås samman. En oberoende säkerhetsagent granskar ändringarna kritiskt både under utvecklingen och på nytt i lanseringspipelinen. ”Utan den här spärren för kodsammanslagning skulle vi inte lita på det som våra agenter bygger”, skrev Goldberg.

Därefter går ändringarna via AWS CodeCommit och CodePipeline innan de publiceras på GitHub. Det offentliga kodarkivet visar ändringshistoriken och separata mappar för lösta respektive olösta fidelitetsproblem. AWS publicerade koden under CC0, en överlåtelse till allmän egendom, med undantag för leverantörskod som omfattas av Apache 2.0. Kodarkivet tar inte emot pull-förfrågningar, men användare kan rapportera buggar och brister i fideliteten via GitHub Issues.

Fidelitetspoäng visar var gränserna går

Ett fidelitetstest är ett kort arbetsflöde som kontrolleras mot verkliga AWS. För att klara testet måste emulatorn ge samma svar på varje anrop, inklusive statuskod, svarsinnehåll samt exakt felkod och felmeddelande, och skapa samma resurser och data som arbetsflödet. Åtgärder som inte har implementerats returnerar HTTP 501 (Not Implemented), så fel blir omedelbart synliga. Varje version redovisar antalet godkända tester för varje tjänst, och AWS påpekar att poängen kan sjunka när tester läggs till, även om emulatorn förbättras.

Varje test i den offentliga utvärderingssviten har verifierats mot minst två AWS-konton i sandlådemiljöer, och i kodarkivet framgår det tydligt att beteenden som inte täcks av ett test inte är verifierade.

Poängen innebär inte att emulatorn lämpar sig som miljö för säkerhetstester. Den utvärderar inte AWS Identity and Access Management (IAM) eller resursbaserade policyer på samma sätt som AWS, så en förfrågan som AWS skulle neka kan lyckas lokalt. Emulatorn är avsedd för utveckling och testning; produktionsarbetsbelastningar och säkerhetstester av program ligger utanför användningsområdet. Varje instans är avsedd för ett konto och en region, lagrar resurser i minnet och raderar dem när den stoppas.

Ingenjörsarbetet skiftar mot specifikationer och tester

I lanseringsinlägget beskrev Swaminathan Sivasubramanian ingenjörens roll som att avgöra vad som ska byggas och utforma specifikationerna, testerna och spärrarna för kodsammanslagning som avgör om resultatet är korrekt, medan agenterna skriver och kontrollerar koden.

Hans jämförelse med Alf, en tidig distribuerad låstjänst från Amazon, ger ett konkret exempel. Det tog ungefär fyra månader att bygga den ursprungliga replikeringsmotorn. Sivasubramanian sade att en ombyggnad med Kiro först tog fyra nätter under övervakning, eftersom agenten saknade möjlighet att kontrollera sina resultat. När han sedan försåg den med en specifikation och en testmiljö tog ombyggnaden ungefär två timmar.

AWS Emulator omsätter den lärdomen i en lanserad produkt: agenter genererar och reparerar implementationen, medan ingenjörerna definierar vilket beteende som är godtagbart och automatiserar kontrollen av att det upprätthålls. Hur användbar produkten är i praktiken beror nu på den växande offentliga testsviten och de kvarstående fidelitetsbristerna, medan säkerhetsvalidering och validering för produktionsbruk fortfarande kräver verkliga AWS.