«Пока грант не активирован, договорная цена не действует»: AWS показала два способа раздать приватные предложения Bedrock по всей организации

В чём проблема: один договор, сотни аккаунтов

Управление доступом к моделям в десятках и сотнях аккаунтов AWS создаёт операционное трение, когда каждый рабочий аккаунт должен сам подписаться и сам принять предложение AWS Marketplace Private Pricing Offers, то есть MPPO.

С managed entitlements подписка делается один раз из центрального аккаунта, а доступ раздаётся по организации — но остаётся вторая половина задачи. В организации со включёнными всеми возможностями гранты уровня организации принимаются автоматически, однако остаются в состоянии Disabled, пока их не активируют. Пока кто-то не активировал грант, договорная цена не действует, и аккаунт продолжает платить по публичному прайсу.

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

Проверка консоли вручную работает, но она добавляет работы и легко забывается — а пропущенный грант не проявляет себя ничем, кроме счёта.

Два пути: разовый скрипт или событийная автоматизация

AWS предлагает выбрать между двумя способами. Легковесный скрипт нужен для разового исправления без инфраструктуры — когда полученным лицензиям уже доверяют; CDK-автоматизация нужна для постоянной событийной обработки, которая проверяет продавцов, создаёт и активирует распределённые гранты.

Оба пути описаны в репозитории aws-samples, то есть это не схема на словах, а разворачиваемый код.

Путь 1: dry-run, «--apply» и полное отсутствие allowlist

Первый путь — самостоятельный скрипт: он перечисляет полученные лицензии и печатает план в режиме dry-run, а гранты уровня организации создаёт и активирует только при повторном запуске с флагами --apply --confirm-account-id. Ключевая оговорка сделана авторами прямо: allowlist продавцов у этого скрипта нет, поэтому применять его стоит только там, где все полученные лицензии в management-аккаунте уже проверены и вызывают доверие.

Проверка эффекта тоже предусмотрена: данные биллинга в AWS Cost Explorer отстают, поэтому по нему предлагают сравнивать фактическое начисление за покрытое использование Amazon Bedrock уже после того, как расходы появятся. Полезная деталь для воспроизводимой проверки — адаптировать скрипт bedrock_discount_check.py из примеров под конкретного ISV-партнёра и целевой связанный аккаунт.

Путь 2: EventBridge, Lambda и грант с ограниченной целью

Второй путь — событийный. Правило EventBridge слушает события AWS Marketplace в стандартной шине в регионе us-east-1, совпадает по источнику aws.agreement-marketplace и типу события Purchase Agreement Created - Acceptor, после чего вызывает функцию AWS Lambda.

Функция получает событие соглашения, проверяет allowlist продавцов, находит лицензию, создаёт распределённый грант и запрашивает активацию через CreateGrantVersion(Status=ACTIVE). Результат работы уходит в логи CloudWatch, а сам грант может быть нацелен на организацию, выбранные организационные подразделения или отдельные аккаунты.

Активация может быть отложена: договорная цена применяется только после того, как грант активирован и достиг состояния ACTIVE или WORKFLOW_COMPLETED. Это не мгновенный процесс — по тексту AWS, активация и появление биллинговой видимости могут занимать часы или дни.

Что нужно подготовить перед развёртыванием

Предварительные условия перечислены исчерпывающе: разворачивать нужно из management-аккаунта организации, регион — us-east-1, а на машине нужны Python 3.12+, AWS CLI и AWS CDK v2. Отдельный скрипт bootstrap_prereqs.py умеет включать интеграцию License Manager с организацией, trusted access для License Manager и для управления лицензиями AWS Marketplace и создавать необходимые служебные роли — перед применением авторы советуют просмотреть все пункты со статусами APPLY и MANUAL.

Границы применимости обозначены жёстко: предложение должно быть на модель Bedrock с поддержкой License Manager, а продукты SaaS из этой автоматизации исключены. Ограничение объяснено в README: managed entitlements работает через AWS License Manager, который выдаёт лицензии только для типов AMI, Container, Machine Learning и AWS Data Exchange, и подписки на сторонние модели Bedrock попадают в категорию Machine Learning.

Отдельно упомянуты необязательные фильтры productSkus и productNames в скрипте backfill_grants.py — они нужны, чтобы при обработке существующих лицензий не срабатывало широкое совпадение только по эмитенту.

Allowlist продавцов — это граница безопасности, а не формальность

Самое важное предупреждение в посте звучит так: относитесь к allowlist продавцов как к границе безопасности и сверяйте идентификатор каждого продавца с принятым приватным предложением AWS Marketplace или полученной лицензией, прежде чем заполнять таблицу. Широких и непроверенных записей добавлять не следует: подходящий продавец может запустить создание и активацию грантов на всех настроенных целях.

Эксплуатационная часть тоже описана: после развёртывания и заполнения allowlist стек готов обрабатывать события соглашений, а для проверки сквозного сценария предлагается отдельный скрипт e2e_validate. Тестовый стек, если он разворачивался, авторы советуют удалить, чтобы не платить небольшие, но постоянные сборы за Lambda и Amazon EventBridge.

Что здесь проверено, а что остаётся на стороне AWS

Это технический how-to самого вендора: инструкция, а не отчёт об измерениях. AWS не приводит чисел — ни того, сколько времени занимает активация, ни того, сколько аккаунтов обработал стек; сроки даны качественно («часы или дни»), а оценка эффекта отдана читателю через Cost Explorer.

В посте есть и голос клиента, но один: цитата Маркуса Лау, Head of Platform Engineering в Heidi Health, о том, что приватные цены на AWS Marketplace позволяют точно распределять использование и стоимость по аккаунтам и организационным подразделениям и автоматизировать управление грантами по мере подключения новых моделей — чтобы масштабировать управление затратами без масштабирования ручной работы. Это позиция компании, участвовавшей в пилоте, а не независимая проверка. Мы не разворачивали этот стек и не проверяли его в живом аккаунте: приведённые здесь параметры — утверждения авторов поста и README репозитория, опубликованного в день релиза.