Как использовать AWS AppConfig с EKS без стресса и изменения кода приложений

Viacheslav Romanov, AWS
Mikhail Ishenin, AWS

Постановка задачи

Недавно к нам обратился клиент с запросом: нужно предоставить возможность управлять конфигурациями внутри Kubernetes-приложений разным членам команды — разработчикам, тестировщикам, аналитикам — при этом обеспечить безопасность, версионирование и автоматическое распространение изменений. Он столкнулся с ограничениями стандартных решений AWS и хотел найти архитектурный подход, который можно внедрить в масштабируемом виде. Мы изучили задачу и сформировали архитектуру, которую описываем в этой статье, она выступает как prescriptive guidance — если вы построите систему именно так, она закроет все заявленные требования.

Многие инженерные команды сталкиваются с необходимостью делегировать управление конфигурациями не только DevOps-инженерам, но и другим участникам разработки: backend- и frontend-разработчикам, аналитикам, специалистам по тестированию. Это логичный тренд: конфигурации всё чаще становятся частью логики приложения, а не исключительно инфраструктуры. Однако, как только речь заходит о вложенных структурах, версионировании, ограничении прав доступа и редактировании без непосредственного доступа к кластеру — возникают серьёзные сложности.

AWS предлагает несколько решений для хранения конфигураций: Parameter Store и SecretsManager. Первый прост в использовании, но ограничен по размеру и не рассчитан на сложные вложенные структуры. Второй больше подходит для хранения чувствительной информации (например, API-ключей). В итоге команды начинают изобретать собственные велосипеды: от самописных контроллеров до хранения JSON-файлов в S3 с доступом по IAM. Но это либо неудобно, либо небезопасно.

Преимущества AppConfig

На этом фоне AWS AppConfig выглядит как более зрелое и подходящее решение. Он позволяет хранить конфигурации в формате JSON, валидировать их перед применением, управлять версиями и просматривать историю изменений. Интерфейс редактирования через AWS Console делает его доступным для пользователей без глубоких знаний инфраструктуры. Это позволяет DevOps-команде сфокусироваться на построении платформы, а разработчикам — на логике приложения.

Особенно стоит выделить несколько ключевых преимуществ AppConfig перед Parameter Store:

Поэтапное развертывание (phased deployment) - возможность выкатывать новую конфигурацию постепенно: сначала на 5% серверов, затем на 25%, и так далее. Это позволяет обнаружить проблемы на ранней стадии и предотвратить полный отказ системы.
Валидация через Lambda - можно подключить Lambda-функцию, которая будет проверять корректность конфигурации перед её применением. Это позволяет реализовать сложную валидацию: проверку схемы, соответствие бизнес-правилам, зависимости между параметрами.
Feature Flags и A/B тестирование - встроенная поддержка флагов функциональности позволяет легко включать/выключать определенные возможности приложения без редеплоя. Это идеально подходит для проведения экспериментов и постепенного внедрения новых фич.
Мониторинг и автоматический откат - AppConfig предоставляет метрики развертывания конфигураций и может автоматически отменить развертывание при обнаружении аномалий.
Детальное управление доступом - тонкие настройки IAM-политик позволяют дать разным командам различные права: одни могут только просматривать конфигурации, другие - редактировать конкретные профили или только для определённых окружений.

Однако с интеграцией в Kubernetes всё не так просто. В отличие от Secrets или ConfigMap, AppConfig нельзя напрямую подключить к поду. У него нет механизма монтирования в виде volume или использования через переменные окружения. Доступ к AWS AppConfig может быть осуществлен либо через прямое обращение к API data plane сервиса, либо через AWS AppConfig agent. В контейнерном окружении агент реализован как sidecar-контейнер запускающий локальный HTTP сервер.

Решение по интеграции AWS AppConfig и Amazon EKS

Мы подошли к задаче иначе: решили не внедрять AppConfig напрямую в под, а построить над ним событийно-реактивную инфраструктуру. В центре решения — EventBridge, Lambda и External Secrets Operator. При изменении конфигурации в AppConfig срабатывает событие, которое улавливает EventBridge. Затем запускается Lambda-функция, которая обновляет соответствующее значение в SecretsManager. Это обновление замечает External Secrets Operator и синхронизирует его с Kubernetes Secret. Далее в дело вступает Reloader, который отслеживает изменение в Secret и инициирует rolling update соответствующих подов.

Такой подход даёт несколько преимуществ. Во-первых, мы используем стандартные Kubernetes-механизмы для доставки конфигураций: Secret и ConfigMap. Во-вторых, конфигурация попадает в под автоматически, без необходимости обращаться к внешним API во время выполнения. В-третьих, мы сохраняем изоляцию ролей: AppConfig редактируют разработчики, инфраструктурные компоненты обновляют состояние в кластере, а приложение просто перезапускается с обновлённой конфигурацией.

Реализация работает следующим образом:

Dev или QA редактирует конфигурацию в AppConfig;
Оператор инициирует деплой конфигурации
EventBridge фиксирует событие Update;
Lambda обновляет только хеш конфигурации в SecretsManager (под фиксированным ключом appconfig-version-hash);

External Secrets Operator синхронизирует это хеш-значение в Kubernetes Secret (с тем же именем). Этот оператор реконсилирует значение секретов.
Reloader отслеживает изменение хеша в Secret и инициирует перезапуск нужных подов (см. документацию);
При запуске полная конфигурация может быть получена init container'ом напрямую через AppConfig API, или через обращение к HTTP-API sidecar AWS AppConfig agent который обращается напрямую к AWS AppConfig используя SDK и информацию о нужном приложении/окружении/профиле.

Такой подход отделяет сигнал к обновлению (хеш) от самих данных конфигурации, позволяя использовать стандартные механизмы K8s для перезапуска, но получать конфигурацию из первоисточника.

Пример реализации Lambda-function и CDK Stack

Вот пример Lambda-функции на Python, которая получает событие от AppConfig, вычисляет хеш от конфигурации и сохраняет его в Secrets Manager:

Эта функция не передаёт саму конфигурацию в кластер, а лишь хеш, которого достаточно, чтобы запустить цепочку обновлений через External Secrets Operator и Reloader. Важно понимать, что в событиях EventBridge от AppConfig не содержится сама конфигурация, поэтому функция дополнительно вызывает AppConfig API для её получения. Саму конфигурацию приложение забирает напрямую из AppConfig — через initContainer, sidecar или AppConfig SDK при перезапуске пода. Такое разделение сигнала и данных упрощает архитектуру и повышает безопасность - конфигурации не дублируются в разных местах.

Также мы можем создать всю необходимую инфраструктуру с помощью AWS CDK. Ниже — пример на CDK, создающий Lambda-функцию и привязывающий EventBridge-триггер:

Эта CDK-обёртка создаёт Lambda, настраивает IAM-доступ и подписывает её на события из AppConfig. Достаточно указать нужный конфигурационный профиль в фильтре событий — и всё начнёт работать автоматически.

В этом решении особенно ценно то, что оно даёт предсказуемость и контроль. Все изменения конфигураций можно отследить по версиям в AppConfig. История изменений доступна, откат выполняется одной кнопкой. Разделение ролей делает систему безопасной: никто не получает прямой доступ к прод-кластеру. Всё обновляется через заранее определённые каналы.

Однако стоит помнить: решение не лишено нюансов. Не вся цепочка работает реактивно, от момента изменения конфигурации до её попадания в pod может пройти от нескольких секунд до нескольких минут. Время на изменение конфигурации ограничено периодом обновления конфигурации со стороны External Secrets Operator, он работает не реактивно, а периодически, по расписанию. По умолчанию, время между обновлениями составляет 5 минут (параметр --store-requeue-interval).

Также требуется аккуратная настройка IAM-политик — у Lambda, External Secrets и подов должны быть правильно ограниченные права. Добавьте сюда мониторинг: если где-то в цепочке произошёл сбой, нужно быстро понять, где именно и почему.

Вывод

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

В итоге можно сказать: AWS AppConfig в связке с EventBridge, Lambda, External Secrets и Reloader позволяет построить зрелый процесс управления конфигурациями для приложений в EKS. Он не только снимает нагрузку с инфраструктурной команды, но и даёт бизнесу больше гибкости. Это не просто техническое улучшение — это шаг в сторону настоящей продуктовой платформы, где конфигурации становятся частью диалога между командами, а не закрытым миром DevOps.

Any opinions in this post are those of the individual author and may not reflect the opinions of AWS.

Site Terms, Privacy, and more.