AWS Emulator, безкоштовний локальний симулятор понад 200 сервісів Amazon Web Services, вийшов 11 листопада 2026 року. За словами AWS, весь його код написали автономні агенти, а команда нічого не писала і не ревʼювала.
Для білдера важливіші межі інструмента, ніж історія його створення. Емулятор не оцінює IAM-політики так, як хмара, тож він підходить для циклу «написав, запустив, прочитав», але не для перевірки безпеки.
Що AWS Emulator робить на практиці?
AWS Emulator підміняє хмарні API локальною HTTPS-точкою, тож AWS CLI, SDK і coding-агенти працюють з ним без змін у коді застосунку. Достатньо змінних середовища, які перенаправляють інструменти на вашу машину (за даними Unite.AI). Акаунт AWS не потрібен, а окремої плати за сам емулятор немає. Ресурси, які ви розгортаєте в реальній хмарі, оплачуються як завжди.
Емулятор зібрано з 438 API-моделей, а AWS і GeekWire пишуть «понад 400». Доступні пакети RPM і Debian для Linux, Docker для macOS і Windows та вбудований режим для тестів на Rust. Ресурси лежать у памʼяті й зникають після зупинки, а кожен екземпляр розрахований на один акаунт і один регіон.
Код відкритий під CC0, тобто це суспільне надбання. Виняток становить сторонній код під Apache 2.0. Репозиторій не приймає pull request, але баги й прогалини у точності можна подавати через GitHub Issues.
Серед аналогів найвідоміший LocalStack. Цього року він поставив безкоштовну версію за вимогу акаунта й обмежив її некомерційним використанням (за даними GeekWire). CC0 такого обмеження не має.
Чого емулятор не вміє?
AWS Emulator не оцінює IAM і resource-based політики так, як AWS, тому запит, який хмара відхилила б, локально може пройти. Підтримуваний сценарій використання: розробка й тестування. Продакшн-навантаження і тести безпеки застосунку в AWS названо поза межами призначення.
Аналітик IDC Девін Претт, на якого посилається GeekWire, додає, що емулятор поки не симулює тротлінг, відмови сервісів і регіональні відмінності в доступності функцій. Код, який він запускає, у пісочниці не ізольовано.
Неімплементовані операції повертають HTTP 501, тож прогалини видно одразу. Перелік відомих проблем агенти ведуть у публічній папці «things-that-do-not-work» на GitHub.
Щодо оцінок AWS радить обережність: нові тести можуть знизити показник сервісу, хоча емулятор при цьому покращується. Поведінка без тесту вважається неперевіреною.
Як агенти пишуть і підтримують цей код?
Агенти працюють трьома командами: одна пише «fidelity tests» і звіряє кожен з реальним AWS, друга проганяє їх на емуляторі й заводить issues, третя виправляє, по одному агенту на issue. Усе працює на Amazon Bedrock AgentCore. Кожна зміна проходить автоматичну перевірку стандартів коду та безпеки, а незалежний агент безпеки переглядає її ще й у release-пайплайні.
За тим самим джерелом, fidelity-тестів уже десятки тисяч, а сотні агентів щодня виправляють тисячі issues. Кожен тест у публічному наборі перевірили щонайменше на двох ізольованих акаунтах AWS.
Почалося з вікенду. Matt Goldberg дав Kiro один промпт і приблизно за 15 хвилин отримав придатну першу версію емулятора Amazon SQS (за даними All Things Distributed). Підхід простий: агент виправляє тест, доки той не проходить на реальному AWS, а потім будує емулятор, який проходить той самий тест.
Swami Sivasubramanian наводить схожий приклад. Kiro чотири ночі під наглядом перебудовував рушій реплікації, бо не мав способу перевірити результат. Після того як Swami дав агентові специфікацію і тестове середовище, робота зайняла близько двох годин.
Що робити зараз
- Підключайте емулятор до локального циклу розробки та CI через змінні середовища: ендпоінт стає локальним, код не змінюється.
- Перш ніж покладатися на емулятор, перегляньте папку «things-that-do-not-work» для сервісів, які ви використовуєте. Відповідь HTTP 501 означає, що операцію ще не реалізовано.
- Права доступу перевіряйте лише в реальному AWS. Тест на заборонений доступ, який в емуляторі проходить, нічого не доводить.





