AWS Emulator on ilmainen paikallinen työkalu AWS-sovellusten kehittämiseen ja testaamiseen. Se ottaa vastaan AWS CLI:n ja ohjelmistokehityskirjastojen eli SDK:iden pyyntöjä, joten kehittäjä voi kokeilla sovelluksen toimintaa omalla koneella, kehityspalvelimella tai jatkuvan integraation (CI) testiputkessa. Pyyntöjä ei tarvitse lähettää AWS:ään, eikä käyttöön tarvita AWS-tiliä.
8
Amazon julkaisi emulaattorin 11. marraskuuta 2026. Sen Rust-toteutus on muodostettu 438 julkisesta AWS-rajapintamallista, jotka kattavat yli 200 palvelua.
4
14 Laaja mallimäärä kertoo rajapintojen kattavuudesta, mutta ei siitä, että jokainen toiminto tai poikkeustilanne vastaisi pilvipalvelua täysin.
Tekoälyagentit rakensivat ja testaavat työkalua
Amazonin mukaan autonomiset tekoälyagentit kirjoittivat emulaattorin koodin, eikä yhtiön tiimi kirjoittanut tai tarkastanut sitä.
3
5 Tämä on Amazonin kuvaus kehitysprosessista, ei riippumattoman tahon tekemä arvio.
Amazon kertoo jakaneensa agenttien työn kolmeen osaan: yksi ryhmä laatii oikeassa AWS:ssä tarkistettavia testejä, toinen etsii emulaattorin ja AWS:n välisiä eroja, ja kolmas korjaa havaittuja ongelmia.
5 Erään raportin mukaan työnkulku pyörii Amazon Bedrock AgentCore -ympäristössä.
11 Amazonin mukaan tuhannet agentit ovat osallistuneet kehitykseen ja ylläpitoon; sadat voivat työskennellä samanaikaisesti.
5 Saatavilla olevat lähteet eivät kuitenkaan vahvista väitettä, että agentit korjaisivat päivittäin tuhansia ongelmia.
Koodi on julkaistu CC0-julkisena luovutuksena. Amazonin mukaan agentit myös ylläpitävät projektia; käyttäjät voivat raportoida ongelmista, mutta projekti ei ota vastaan koodimuutoksia eli pull requesteja.
11 The New Stack -julkaisun mukaan CC0-valintaan vaikutti epävarmuus siitä, voiko tekoälyn tuottamaan koodiin kohdistua tekijänoikeus.
Ensimmäiset bugit ja käyttöoikeuksien tärkeä raja
Varhaisessa uutisoinnissa emulaattorin GitHub-seurantaan oli kertynyt yli 70 ongelmaraporttia. Niistä monet koskivat DynamoDB:tä ja Lambdaa, ja eräs kehittäjä kuvaili työkalua sanalla ”arvoton”. Samassa raportissa tulosta kuvattiin toimivaksi mutta keskeneräiseksi.
17 Havaittujen virheiden perusteella ei kuitenkaan voi yksin päätellä, johtuivatko puutteet siitä, että koodin kirjoittivat agentit.
Erityisen tärkeä rajoitus liittyy käyttöoikeuksiin. Emulaattori ei arvioi IAM-käytäntöjä eikä resurssikohtaisia käytäntöjä samalla tavalla kuin AWS. Pyyntö voi siis onnistua paikallisessa testissä, vaikka AWS hylkäisi sen – tai päinvastoin.
19
21 Paikallisen testin läpäisy ei siten ole näyttö siitä, että tuotantoympäristön käyttöoikeudet ovat oikein.
Hyödyllinen kehityksessä, ei tuotantoympäristön korvike
AWS:n dokumentaation mukaan emulaattori vastaa tarkimmin resurssien luontiin, kuvailuun, päivitykseen ja poistoon liittyvissä pyynnöissä. Sen vastaavuus AWS:n kanssa vaihtelee palvelun ja toiminnon mukaan, ja AWS rajaa työkalun kehitykseen ja testaukseen – ei tuotantokäyttöön tai tietoturva-asetusten testaamiseen.
Emulaattori säilyttää luotujen resurssien tilan muistissa siihen asti, että se pysäytetään.
8 Lisäksi riippumattomassa teknisessä kuvauksessa tuodaan esiin, ettei alue- ja tilitunnusten erottelu vastaa oikean AWS:n eristystä.
18
19 Tämä voi olla olennainen ero esimerkiksi alueiden tai tilien välisiä työnkulkuja testattaessa.
Yksi AWS Builder -sivustolla julkaistu esimerkki havainnollistaa myös kapasiteetin rajoja: kirjoittaja kohtasi Step Functions -suoritustietovaraston 64 MiB:n rajan, minkä jälkeen EventBridge-kutsut epäonnistuivat virheeseen ExecutionLimitExceeded. Tapaus koskee kyseistä testiä, eikä yksin kerro, miten emulaattori suoriutuu kaikista kuormista.
Emulaattorin testituloksia kannattaa siis käyttää nopeana palautteena kehitystyössä, ei pilven toimintaa koskevana takuuna. Tarkista kriittiset käyttöoikeudet, palvelujen väliset integraatiot ja tuotannon kannalta tärkeä toiminta myös oikeassa AWS-ympäristössä. Saatavilla olevat lähteet eivät vahvista erillisiä lupauksia pitkien kuormitustestien tuesta tai suunnitelmaa esitellä aihetta tarkemmin re:Invent-tapahtumassa.