AWS выпускает локальный эмулятор, полностью созданный автономными ИИ-агентами

11 ноября 2026 года AWS выпустила AWS Emulator — локальный эмулятор, ставший общедоступным и созданный на основе 438 моделей API AWS, охватывающих более 200 сервисов. Автономные ИИ-агенты написали и протестировали его код, благодаря чему разработчики и агенты для программирования могут работать с API AWS на собственных компьютерах без учетной записи AWS.

AWS CLI, AWS SDK и агенты для программирования подключаются через локальную конечную точку HTTPS, используя те же API, что и в облаке. Переменные среды перенаправляют эти инструменты на компьютер пользователя, поэтому код приложения менять не нужно. В публикации AWS о запуске описаны пакеты RPM и Debian для Linux, Docker для macOS и Windows, а также встроенный режим для тестов на Rust. Дополнительной платы за сервис нет, однако клиенты по-прежнему платят за ресурсы AWS, которые используют в облаке.

Для агентов, работающих с кодом, эмулятор позволяет встроить инфраструктуру AWS в цикл «записать — запустить — прочитать»: агент может создать ресурс, проверить результат и изменить код, не дожидаясь развертывания в регионе AWS. В документации AWS также указаны серверы разработки и среды непрерывной интеграции, в которых можно использовать эмулятор: запросы в них направляются к эмулируемым ресурсам, а не к AWS.

Три команды агентов создают и поддерживают код

Старший главный инженер AWS Мэтью Голдберг рассказал в материале о разработке, что его команда не писала и не проверяла код эмулятора. Вместо этого люди создали всю необходимую для этой работы инфраструктуру: спецификации, средства тестирования, проверки перед слиянием и конвейер выпуска. Проект начался с того, что агент для программирования Kiro примерно за 15 минут создал работоспособный эмулятор Amazon SQS: по заданию он написал тесты, проверил их на реальной AWS и создал реализацию в оперативной памяти, прошедшую эти тесты. Затем Голдберг поручил Kiro расширить прототип за выходные; чтобы превратить его в надежный продукт, потребовались дополнительные защитные механизмы.

Теперь работу распределили между тремя специализированными командами агентов. Авторы тестов составляют сценарии на основе общедоступных моделей API и проверяют их на реальной AWS. Агенты, выявляющие проблемы, повторно запускают тесты и группируют сбои, у которых может быть общая первопричина, а агенты-исправители берутся за каждую проблему по отдельности. По словам Голдберга, уже создано несколько десятков тысяч тестов на соответствие, и ежедневно исправляются тысячи проблем, пока сотни агентов работают параллельно.

Перед слиянием каждое предлагаемое исправление должно компилироваться и проходить автоматические проверки на соответствие стандартам кодирования, требованиям безопасности и точности. Независимый агент по безопасности критически проверяет изменения в ходе разработки, а затем повторно — в конвейере выпуска. «Без такого контрольного этапа слияния мы не доверяли бы тому, что создают наши агенты», — написал Голдберг.

Затем изменения проходят через AWS CodeCommit и CodePipeline, после чего публикуются на GitHub. В общедоступном репозитории доступны история коммитов и отдельные папки с устраненными и неустраненными проблемами соответствия. AWS опубликовала код по лицензии CC0, передающей произведение в общественное достояние; код сторонних поставщиков распространяется по лицензии Apache 2.0. Репозиторий не принимает запросы на включение изменений, однако пользователи могут сообщать об ошибках и пробелах в соответствии через GitHub Issues.

Оценки точности определяют границы возможностей

Тест на точность — это короткий сценарий, проверяемый на реальной AWS. Чтобы пройти его, эмулятор должен точно воспроизвести ответ на каждый вызов, включая код состояния, тело ответа, точные код и текст ошибки, а также ресурсы и данные, созданные в ходе сценария. Нереализованные операции возвращают HTTP 501 (не реализовано), поэтому сбои сразу становятся заметны. В каждом выпуске указывается число пройденных тестов для каждого сервиса, при этом AWS предупреждает: добавление тестов может снизить оценку даже по мере совершенствования эмулятора.

Каждый тест из общедоступного набора для оценки проверили как минимум на двух изолированных учетных записях AWS в тестовой среде; в репозитории также ясно указано, что поведение, для которого нет теста, не проверено.

Однако эти оценки не превращают эмулятор в среду для проверки безопасности. Он не оценивает политики управления идентификацией и доступом AWS (IAM) и политики на основе ресурсов так же, как это делает AWS, поэтому запрос, который AWS отклонила бы, может пройти локально. Эмулятор предназначен для разработки и тестирования; рабочие нагрузки и проверки безопасности приложений в производственной среде не входят в сферу его применения. Каждый экземпляр рассчитан на одну учетную запись и один регион, хранит ресурсы в памяти и удаляет их при остановке.

Инженерная работа смещается в сторону спецификаций и тестов

В публикации о запуске Сვამинатан Сивасубраманиан описал роль инженера как определение того, что нужно создать, и подготовку спецификаций, тестов и контрольных этапов слияния, которые задают критерии правильности, пока агенты пишут и проверяют код.

Сравнение с Alf — одной из ранних распределенных служб блокировок Amazon — служит наглядным примером. На создание исходного движка репликации ушло около четырех месяцев. По словам Сивасубраманиана, первая попытка пересоздать его с помощью Kiro заняла четыре ночи под наблюдением, поскольку агент не мог проверить результаты своей работы. Когда он предоставил спецификацию и тестовую среду, на пересоздание ушло около двух часов.

AWS Emulator воплощает этот подход в готовом продукте: агенты создают и исправляют реализацию, а инженеры определяют приемлемое поведение и автоматизируют проверку его соблюдения. Практическая область применения эмулятора теперь зависит от расширения общедоступного набора тестов и устранения оставшихся пробелов в точности; для проверки безопасности и готовности к производственной эксплуатации по-прежнему требуется настоящая AWS.