AWS Bedrock keys are now protected by an internal LLM gateway that lets every team in a fintech firm call the models, yet each request is tied to a per-team token budget. The change stops the practice of scattering IAM credentials across repos and notebooks, a habit that had already threatened to drain the company’s AI spend in a single afternoon.

Почему раздача ключей AWS быстро превращается в хаос

Нетехнические подразделения организации запрашивали прямой доступ к языковым моделям компании. На бумаге самым простым решением было включить модели в AWS и предоставить каждой группе разрешение IAM. Десять минут работы, пара правок в политиках — и дело сделано, по крайней мере, в теории.

На практике раздача IAM-учетных данных создает три скрытых издержки:

  • Разрастание учетных данных — ключи оказываются в файлах .env, CI-конвейерах, блокнотах Jupyter и ad-hoc скриптах. Каждая копия становится точкой отказа, когда требуется ротация.
  • Нулевая прозрачность — один общий ключ не дает представления о том, какая команда или какой фрагмент кода генерирует использование. Если запускается бесконечный цикл, весь бюджет может быть исчерпан до того, как кто-то это заметит.
  • Операционные расходы — отслеживание того, у кого какие есть разрешения, отзыв доступа и аудит использования быстро превращаются в ручной процесс, подверженный ошибкам.

Команда финтеха поняла, что это «быстрое решение» вскоре превратится в кошмар для безопасности и бюджета.

Вместо этого — создание шлюза на базе обратного прокси

Решением стало внедрение легкого обратного прокси между каждым внутренним приложением и AWS Bedrock. Прокси хранит реальные учетные данные AWS в одном защищенном хранилище (vault) и выдает вызывающим сторонам краткосрочные, читаемые человеком токены (например, lllkey_9f3c).

Ключевые особенности архитектуры:

  • Учетные данные AWS не покидают шлюз — разработчики и сервисы никогда не видят фактические IAM-ключи.
  • Применение политик на уровне токена — каждый токен может быть ограничен определенным семейством моделей или максимальным количеством токенов.
  • Полный аудит — каждый запрос логируется с указанием имени.

Как шлюз обрабатывает запрос

  1. Получение токена — клиент включает свой токен llmkey_… в HTTP-заголовок.
  2. Валидация токена — шлюз проверяет статус токена (активен, не истек срок действия) и то, не выходит ли запрос за рамки выделенного бюджета.
  3. Белый список моделей — шлюз подтверждает, что запрошенная модель разрешена для данного токена.
  4. Пересылка в Bedrock — запрос отправляется в AWS с использованием сохраненных IAM-учетных данных.
  5. Логирование и тарификация — использование токенов, название модели и оценка стоимости записываются в центральную базу данных для отчетности.

Поскольку финтех-компания обязана держать все данные внутри своей сети, использование сторонних SaaS-решений было исключено.

Что получила компания

  • Контроль моделей — команды, которым нужна только малозатратная модель, могут быть ограничены ею, что предотвращает случайное использование дорогих и более мощных вариантов.
  • Защита бюджета — для токенов установлен жесткий лимит. При достижении лимита шлюз возвращает ошибку, а не продолжает незаметно расходовать средства.
  • Отчетность для финансового отдела — дашборд, построенный на логах использования, показывает точно, какая команда или сервис потратили сколько на ИИ, превращая расплывчатую таблицу в прозрачный отчет.

Операционный процесс также изменился. Больше никаких новых политик IAM, никакой ротации секретов и никакого риска утечки ключей в систему контроля версий.

Контраргумент: почему не использовать управляемый сервис

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