Как AWS DevOps Agent находит причину сбоев на границе Terraform-стейтов
27 октября 2026 года AWS опубликовала в блоге DevOps & Developer Productivity разбор того, как AWS DevOps Agent трейсит отказы на стыке независимых Terraform-стейтов. Инфраструктурная команда во время планового аудита безопасности ужесточает egress-правило security group, а Lambda в стеке приложения теряет доступ к DynamoDB. Команда, которая видит таймауты, не владеет стеком, где произошла поломка.
Краткий ответ
AWS DevOps Agent подключается к CloudWatch-алармам через webhook, читает состояние нескольких Terraform-стеков через terraform_remote_state и сверяет изменения с CloudTrail. Когда Lambda не достучалась до DynamoDB, агент прослеживает цепочку зависимостей через границу стейтов, находит изменённое правило security group в чужом стеке и формирует mitigation-спецификацию, которую можно передать в Kiro для генерации и применения фикса.
Что изменилось
Проблема, которую разбирает AWS, знакома любой платформенной команде: чем крупнее инфраструктура, тем чаще Terraform делят на независимые стеки с отдельными state-файлами. Это разумное решение — у каждой команды своя зона ответственности и свой темп изменений. Команда инфраструктуры владеет сетью, команда приложения — вычислениями и данными. Рутинные изменения внутри своего стека не требуют согласования с соседями.
Но у этого разделения есть обратная сторона. Когда один стек меняется и ломает приложение в другом, страдающая команда почти никогда не владеет стеком-источником проблемы. Она проверяет свои логи Lambda, свои IAM-политики, метрики своей базы данных — и не находит ничего, потому что в её собственном стеке действительно всё в порядке.
В сценарии из поста AWS именно это и происходит: команда сети сужает egress-правило, и это незаметно для неё самой разрывает связь Lambda приложения с DynamoDB. Алармы срабатывают на стороне приложения и указывают куда угодно, кроме реальной причины. AWS DevOps Agent создан, чтобы закрыть именно этот разрыв видимости между стеками, а не заменить мониторинг внутри одного сервиса.
Как устроена диагностика
Демонстрационная архитектура из поста — небольшое serverless-приложение, разделённое на три независимых Terraform-стека плюс опциональный стек самого агента:
networking— VPC, приватные подсети, security group для Lambda, Gateway VPC endpoint для DynamoDB, VPC Flow Logs (владеет инфраструктурная команда);compute— Lambda в VPC и HTTP API Gateway (владеет команда приложения);data-monitoring— таблица DynamoDB, SNS-топик, CloudWatch-алармы (владеет та же команда приложения);devops-agent— IAM trust role и webhook bridge Lambda, через которую сигналы попадают в агента.
Запрос в здоровом состоянии идёт по цепочке: клиент → API Gateway → Lambda в VPC → security group → Gateway VPC endpoint → DynamoDB. Стек compute не хардкодит параметры сети — он читает их из output networking-стека через terraform_remote_state, то есть границы между командами формальны, а зависимость реальна.
Когда CloudWatch-алармы срабатывают, они публикуются в SNS-топик, оттуда webhook-мост пересылает подписанное сообщение в Agent Space — рабочее пространство AWS DevOps Agent, куда стекаются сигналы от мониторинга и которое хранит построенную топологию ресурсов. Агент коррелирует алармы, восстанавливает цепочку зависимостей через границу стейтов и просматривает CloudTrail, чтобы сузить круг подозреваемых до конкретного изменения в networking-стеке. Дальше инженер может взять сформированную агентом mitigation-спецификацию и передать её в Kiro — ещё один инструмент AWS, упомянутый в том же посте, который по этой спецификации генерирует и применяет исправление кода.
Что это меняет в эксплуатации
До появления такого инструмента маршрут диагностики cross-stack инцидента выглядел так: инженер проверяет собственный сервис, убеждается, что он здоров, и начинает вручную опрашивать соседние команды — кто что менял в последние часы. Это работает, но зависит от того, вспомнит ли кто-то про смежное изменение и быстро ли откликнется владелец чужого стека.
AWS DevOps Agent переносит эту работу на уровень инфраструктуры как графа, а не набора изолированных стеков. Он не отменяет владение стеками — команды по-прежнему разделяют зоны ответственности, — но добавляет слой наблюдаемости, который видит систему целиком и способен указать на стек-источник до того, как туда подключится человек.
По сути меняется сама механика расследования: вместо переклички между владельцами стеков инженер получает одну гипотезу для проверки вместо перебора всех соседних стеков. Это задаёт и новое требование к мониторингу: алармы одной команды должны быть видимы инструменту, который умеет сопоставлять их с чужими state-файлами, а не только с собственными дашбордами.
Что нужно, чтобы это заработало
Пост сопровождается репозиторием на GitHub с Terraform- и Lambda-кодом для этого сценария. AWS прямо указывает: это демонстрационный код, который намеренно внедряет сбой и держит открытым неаутентифицированный API в учебных целях — он не готов к продакшену. Известные пробелы и шаги по усилению защиты перечислены в файле SECURITY.md репозитория.
Для работы самой схемы нужны конкретные вещи: Terraform-стеки с явными terraform_remote_state-ссылками друг на друга, настроенные CloudWatch-алармы с публикацией в SNS, webhook-мост с Lambda-функцией, которая подписывает и пересылает события в Agent Space, и IAM trust role, которая даёт агенту доступ читать state и CloudTrail. Без этой обвязки агент не увидит ни зависимости между стеками, ни историю изменений, которая нужна для вывода о вероятной причине.
Источник не уточняет статус самого сервиса AWS DevOps Agent — доступен ли он как GA-продукт или находится в предварительном доступе, — пост сфокусирован на конкретном сценарии использования, а не на анонсе возможностей.
Кому и когда пробовать
Сценарий полезен в первую очередь командам, у которых Terraform уже разделён по границам владения — отдельно сеть, отдельно вычисления, отдельно данные — и где уже случались инциденты вида «у нас всё зелёно, но приложение не работает». Чем больше таких стеков и чем реже команды синхронизируются напрямую, тем заметнее эффект от автоматического построения цепочки зависимостей.
Начать стоит с демонстрационного репозитория: развернуть три стека, посмотреть, как webhook-мост передаёт алармы, и изучить SECURITY.md, прежде чем переносить что-то похожее на продакшен-окружение. Инъекция сбоя и открытый API в примере сделаны намеренно для обучения — переносить их как есть в боевую инфраструктуру не стоит.
Заключение
История AWS DevOps Agent здесь не про замену ранбуков как жанра, а про то, что сам ранбук перестаёт требовать ручного перебора соседних стеков. Агент читает несколько Terraform-стейтов, сопоставляет их с алармами и CloudTrail и указывает на вероятный стек-источник — а дальше инженер решает, применять ли предложенный фикс через Kiro или разобраться самому. Для команд с развитой multi-stack архитектурой это ещё один инструмент, который стоит оценить на собственных инцидентах, а не воспринимать как готовое решение «из коробки».
FAQ
Что такое Terraform state boundaries и почему они создают проблему?
Это границы между отдельными state-файлами, когда инфраструктуру делят на независимые стеки по владению — например, сеть отдельно от вычислений. Команда, которая видит симптомы сбоя, обычно не владеет стеком, где произошло изменение, вызвавшее проблему, поэтому расследование занимает больше времени.
Как AWS DevOps Agent трейсит зависимости между стеками?
Агент получает CloudWatch-алармы через webhook в Agent Space, читает state нескольких Terraform-стеков через terraform_remote_state и сверяет изменения с историей в CloudTrail. На основе этого он восстанавливает цепочку зависимостей через границу стеков и указывает на вероятный стек-источник отказа.
Чем AWS DevOps Agent отличается от обычного ранбука?
Ранбук описывает заранее известные шаги диагностики внутри своего сервиса. Агент вместо фиксированного сценария строит граф зависимостей на лету и ищет причину за пределами стека, который видит пострадавшая команда, опираясь на реальные изменения в CloudTrail.
Можно ли развернуть демо-репозиторий AWS в продакшене?
Нет. AWS прямо пишет, что код в репозитории демонстрационный: он намеренно внедряет сбой и держит открытым неаутентифицированный API для учебных целей. Известные пробелы и шаги по усилению защиты описаны в файле SECURITY.md репозитория.
Нужен ли Kiro, чтобы использовать агента?
Kiro нужен на шаге применения фикса: агент формирует mitigation-спецификацию с описанием проблемы, а Kiro по этой спецификации генерирует и применяет исправление кода. Саму диагностику агент выполняет без Kiro.