«Одна подписка, три среды»: AWS показала, как развести доступ к Claude Platform on AWS

Какая задача разбирается

Публикация описывает типовую ситуацию: инференс Claude Platform on AWS (CPonAWS) нужен сразу из трёх мест — продакшен-нагрузок в AWS, ноутбуков разработчиков для локальных прогонов и внешних сервисов на других облаках или в CI/CD на собственных мощностях.

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

Архитектура: выделенный аккаунт AI Services

Основа схемы — отдельный связанный аккаунт AI Services внутри организации: он владеет подпиской, рабочими пространствами, ключами API и кросс-аккаунтными ролями, а рабочие аккаунты не касаются подписки напрямую, а берут роли в AI Services для вызовов инференса.

В результате получается структура из трёх аккаунтов: плательщик (он же управляющий) для биллинга и управления, аккаунт AI Services с подпиской CPonAWS и рабочими пространствами и один или несколько рабочих аккаунтов, потребляющих инференс через кросс-аккаунтные роли.

Три пути доступа

Первый путь — для нагрузок в AWS: под в Amazon EKS в рабочем аккаунте принимает роль в аккаунте AI Services и делает вызовы инференса, подписанные SigV4, без хранения ключей API и без секретов, которые нужно ротировать.

Для этого в аккаунте AI Services создаётся кросс-аккаунтная роль с доверием к роли пода и политикой, где действие CreateInference ограничено ARN продакшен-рабочего-пространства: эта роль не может обратиться ни к рабочему пространству разработки, ни к любому другому в аккаунте.

Второй путь — для ноутбуков разработчиков: долгоживущий ключ API, привязанный к рабочему пространству разработки, который используется локально со стандартным SDK Anthropic.

Здесь есть подвох, о котором AWS предупреждает прямо: по умолчанию у служебного IAM-пользователя сгенерированного ключа (AeaApiKey-*) прикреплена управляемая политика AnthropicLimitedAccess, дающая доступ ко всем рабочим пространствам, поэтому её нужно отозвать и заменить встроенной политикой только на нужное рабочее пространство и на получение токена.

Ключ при этом самодостаточен: он работает из любого аккаунта AWS и вообще из не-AWS окружения, поэтому хранить его следует в защищённом хранилище секретов.

Третий путь — для внешних нагрузок: рабочие процессы в других облаках, кластерах Kubernetes вне AWS и пайплайнах CI/CD аутентифицируются через OIDC, получают временные учётные данные AWS, а из них — короткоживущий токен, и вызовы инференса идут вообще без постоянных учётных данных.

Как проверяется изоляция

AWS предлагает проверять разграничение практикой: разработчику даётся отдельный шаг с попыткой обратиться ключом разработки к продакшен-рабочему-пространству.

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

Детали, которые AWS называет важными

Регион рабочего пространства определяет адрес API, но не то, где выполняется инференс: географию инференса настраивают отдельно в разделе Security консоли Claude, где сейчас доступны варианты «US» и «Global routing».

Короткоживущие ключи привязаны к региональной границе жёстче: токен работает только против того регионального эндпоинта, на котором был сгенерирован, тогда как долгоживущие ключи API регионом не ограничены.

Для OIDC-роли есть отдельная оговорка: действие CallWithBearerToken должно быть разрешено на ресурсе «*», иначе генерация токенов перестанет работать целиком, а ограничение на рабочее пространство остаётся на CreateInference — именно из него сгенерированный токен наследует границы.

Сгенерированный токен живёт один час — срок настраивается, максимум 12 часов, — и после генерации он становится автономным bearer-credential: внешней нагрузке AWS-учётные данные больше не нужны, но для постоянно работающих сервисов авторы советуют обновлять токен заранее.

До и после внедрения

Из предварительных условий: организация в AWS Organizations с аккаунтом плательщика и связанными аккаунтами под подписку и под нагрузку, AWS CLI v2 с именованными профилями для обоих аккаунтов и Python 3.12+ с пакетами anthropic[aws], boto3 и token-generator-for-aws-external-anthropic.

Для тех, кто только оценивает схему, в руководстве есть отдельный раздел с уборкой: удаление ключей API и служебных IAM-пользователей, удаление ролей и OIDC-провайдера, удаление секрета и отмена подписки через AWS Marketplace.

Для продакшена AWS советует два шага: включить события данных AWS CloudTrail для сервиса aws-external-anthropic, чтобы получить аудит каждого вызова с указанием того, кто его сделал, и разметить рабочие пространства тегами вроде team:payments и environment:prod, активировав их как теги распределения затрат, — после активации, на которую уходит 24–48 часов, расходы на Claude можно фильтровать в Cost Explorer по проектам, командам и средам.