Ing. Calogero Bono
Amazon Web Services ha presentato AWS Emulator, un emulatore locale delle proprie API che si esegue sul computer dello sviluppatore. AWS CLI, SDK e agenti di codice lo raggiungono con gli stessi comandi usati verso il cloud. Secondo AWS non ha costi aggiuntivi e il sorgente è su GitHub. Conta perché porta i test di infrastruttura dentro il ciclo di lavoro degli agenti, senza passare da un deployment.
Qualche termine, prima di entrare nei fatti. Emulatore è un programma che imita un servizio reale, qui le API di AWS, ma gira in locale. SDK sono le librerie con cui il codice parla con AWS. SigV4 è il metodo di firma delle richieste usato da AWS. Smithy è il formato con cui AWS descrive operazioni, input, output ed errori dei servizi. Fidelity test è un test che verifica se l'emulatore si comporta come AWS.
Che cos'è AWS Emulator e come si installa?
È un programma locale che espone un endpoint HTTPS delle API AWS. Non ha interfaccia grafica e, come spiega il repository ufficiale, non serve un account AWS. Le richieste vanno all'emulatore e non ad AWS, quindi lavori su risorse emulate.
Su Linux si installa da pacchetto RPM o Debian. Su macOS e Windows lo si esegue in Docker, con un Dockerfile breve, perché AWS non pubblica un'immagine già pronta. Il servizio ascolta su 127.0.0.1, porta 9297, con certificato autofirmato, e si raggiunge solo dalla tua macchina.
Come funziona nella pratica?
Avvii l'emulatore e imposti variabili d'ambiente, tra cui l'endpoint, che puntano gli strumenti sul computer. Il codice resta invariato. Nel post di lancio l'autore crea un bucket S3 e poi, con Kiro, una tabella DynamoDB.
A ogni avvio vengono generate nuove credenziali, con chiavi che iniziano per EMULATOR, e le richieste firmate con altre chiavi sono rifiutate. L'account è uno solo, 000000000000. È scritto in Rust per pesare poco su CPU e memoria.
Cos'è la modalità embedded per i test?
È una seconda via, pensata per i test. L'emulatore si istanzia dentro il processo di test e si collega all'SDK tramite il client HTTP, senza server separato. Ogni istanza ha il proprio stato, quindi bucket, tabelle e code non si condividono e puoi eseguire molti test in parallelo.
Al momento è disponibile per l'SDK AWS per Rust, con il crate aws-emulator-embedded da GitHub. Il costo è la compilazione. Il repository avverte che il primo build richiede una cartella target dell'ordine di 100 GB e consiglia di fissare una release e usare una cache in CI. Per chi imposta test automatici, anche la nostra guida alla CI pipeline aiuta a ragionare su questi tempi.
Quanto è fedele ad AWS e come l'hanno costruito?
AWS misura la fedeltà con test verificati sul servizio reale. Un test passa solo se risposta, codice di stato, corpo ed errori coincidono. A ogni release viene pubblicato il punteggio per servizio nella forma k su n, e la suite è pubblica su GitHub, compresi i test che ancora falliscono.
Nel post di Swaminathan Sivasubramanian si legge che tutto il codice è stato scritto e testato da agenti, a partire da più di 400 modelli API che coprono più di 200 servizi. Il codice passa da un merge gate con più agenti di sicurezza. Sono dichiarazioni di AWS.
Limiti da conoscere
Il repository precisa che l'emulatore serve a sviluppare e testare, non per carichi di produzione né per verificare la sicurezza. Non ci sono dati indipendenti sulla fedeltà, i punteggi li pubblica AWS. Alcune API non funzionano ancora e sono elencate nella cartella issues. Alcuni SDK richiedono impostazioni extra per fidarsi del certificato. Non sappiamo quali servizi saranno coperti meglio nel tempo.
Cosa cambia per chi lavora con il digitale
Per chi sviluppa su AWS, i test di integrazione possono girare offline e senza costi di risorse cloud. Un agente di codice può creare risorse, controllare il risultato e riprovare senza attendere un deployment. In CI puoi usare l'emulatore al posto di un account di prova. Se lavori con AWS per sviluppatori, vale una prova su un servizio non critico. Chi usa già Docker Compose in locale può inserire l'emulatore nello stesso schema.
Il nostro parere
L'idea è solida. Un emulatore che nasce dagli stessi modelli degli SDK e viene confrontato con il servizio reale è più credibile di tante imitazioni. Due punti ci lasciano cauti. La fedeltà è un punteggio dichiarato da chi vende il cloud, e la telemetria è attiva di default. Sul resto, il fatto che il repository non accetti pull request limita il contributo esterno. Come per i mock nei test PHP, un doppio è utile finché non lo scambi per la realtà.
Domande frequenti
AWS Emulator è gratuito?
Sì, secondo AWS non ha costi di servizio aggiuntivi. Paghi solo le risorse AWS quando fai il deployment sul cloud. La licenza è CC0, tranne la cartella vendor sotto Apache 2.0.
Serve un account AWS?
No. Le richieste vanno all'emulatore e non ad AWS, quindi non serve un account. Le credenziali sono generate dall'emulatore a ogni avvio.
Funziona su Windows e macOS?
Sì, ma tramite Docker. Costruisci un'immagine da un Dockerfile breve, perché AWS non ne pubblica una pronta. Su Linux c'è il pacchetto RPM o Debian.
Si può usare in produzione?
No. Il repository dice che è per sviluppo e test, non per produzione né per test di sicurezza.
Come si disattiva la telemetria?
Con l'opzione --telemetry off all'avvio, oppure con la variabile EMULATOR_TELEMETRY impostata su off. Si può anche usare il file config.toml. Secondo AWS i dati non includono richieste, codice o credenziali.
I punteggi di fedeltà da seguire a ogni release
Il valore dell'emulatore si deciderà sui numeri pubblicati a ogni versione. Conviene guardare se i servizi che usi salgono.
- Leggi i punteggi k su n dei servizi che usi nella pagina delle release.
- Controlla la cartella issues per vedere se le API che ti servono sono tra quelle che non funzionano ancora.
- Prova la modalità embedded su un progetto Rust piccolo e misura i tempi del primo build.
