Что именно открылось канадским организациям в Amazon Bedrock
Канадские организации могут вызывать модели OpenAI GPT-5.6 (Sol, Terra, Luna), GPT-6 (Astra, Sol, Luna) и GPT-6.1 Sol в Amazon Bedrock из регионов Canada (Central) и Canada West (Calgary). Механизм доступа называется cross-Region inference: приложение отправляет запрос на endpoint bedrock-runtime в своём регионе, Bedrock маршрутизирует его в поддерживаемый регион обработки и возвращает ответ обратно. Об этом говорится в анонсе AWS от 20 октября 2026 года.
Практический смысл в двух вещах. Маршрутизацию держит сервис, а не ваш код: не нужно прописывать несколько регионов в конфиге, писать обвязку на случай недоступной площадки и переучивать SDK. Пропускная способность распределяется по более широкому пулу мощностей, поэтому пики проходят мягче.
Модели принимают текст и изображения, возвращают текст, поддерживают контекстное окно в 1 млн токенов, режим рассуждения и вызов инструментов. У GPT-6.1 Sol набор входных и выходных модальностей шире, детали приведены в её model card. Вызов идёт через OpenAI Responses API, OpenAI Chat Completions API или Amazon Bedrock Converse API на том же endpoint bedrock-runtime.
Кому и зачем это нужно: сценарии канадских команд
- Продакшен с требованием держать данные в Канаде. Данные at rest остаются в исходном регионе, обработка идёт в Северной Америке. Это ограничение обсуждают с комплаенсом до, а не после запуска.
- Агентные пайплайны. GPT-6 Astra позиционируется под сложные end-to-end рассуждения и агентные задачи, GPT-6.1 Sol под рассуждения и кодинг там, где важны и производительность, и стоимость.
- Массовые повторяющиеся операции. Извлечение полей, классификация, суммаризация: GPT-6 Luna даёт быстрый и недорогой инференс с настраиваемым reasoning effort на каждый запрос.
- Кодинг-ассистенты. GPT-5.6 Sol закрывает высокие нагрузки рассуждения, кодинга и агентных задач, GPT-6.1 Sol подходит для регулярной работы с балансом цены и качества.
Ограничение стоит проговорить прямо: инференс обрабатывается в Северной Америке, а не внутри канадского региона. Если внутренняя политика требует, чтобы запросы физически не покидали страну, CRIS такой сценарий не закрывает. Тогда отдельно проверяйте, какие модели доступны в вашем регионе без кросс-региональной маршрутизации, и держите в уме локальный контур для чувствительных данных.
Как работает cross-Region inference: endpoint в Канаде, обработка в поддерживаемом регионе
Последовательность вызова выглядит так:
- Приложение обращается к bedrock-runtime в ca-central-1 или ca-west-1.
- В запросе указывается inference-профиль: именованный объект с ARN, который задаёт правила маршрутизации.
- Bedrock выбирает поддерживаемый регион обработки из пула профиля и передаёт запрос туда.
- Ответ возвращается в исходный регион в том же соединении.
Приложению не нужно знать, где именно обработан запрос. Отсюда следует и обратное: география обработки определяется выбранным профилем, а не кодом. Поэтому профиль становится единицей контроля и для комплаенса, и для IAM.
US geographic (us.) vs Global (global.) inference-профили
В анонсе упоминаются два типа профилей. US geographic (префикс us.) держит обработку в Канаде и США. Global (префикс global.) маршрутизирует запросы в поддерживаемые коммерческие регионы AWS, то есть география шире. Отдельный нюанс: глобальный профиль для GPT-5.6, по описанию обновления, доступен только из ca-central-1.
Практическая разница сводится к двум пунктам. Первый — data residency: us. оставляет обработку в Северной Америке, global расширяет список площадок. Второй — набор ARN, которые попадут в IAM-условие. Если политика разрешает только us.-профили, вызов global. упадёт с отказом доступа, и это нормальное поведение guardrail, а не баг.
Критерий выбора короткий. Комплаенс требует Северной Америки: берите us. Политика допускает более широкую географию, а вам нужен максимум мощностей в пик: берите global. Промежуточных вариантов нет. Точный список регионов обработки по каждому профилю смотрите в консоли Bedrock и документации: публичный фрагмент анонса обрывается ровно на разделе о профилях, поэтому префиксы и ограничения проверяйте по актуальному Bedrock User Guide перед планированием.
Настройка доступа: IAM-политики и SCP с условием bedrock:InferenceProfileArn
Права настраиваются в исходном регионе, откуда приложение вызывает bedrock-runtime. Минимальный набор действий: bedrock:InvokeModel и bedrock:InvokeModelWithResponseStream. Ключевая деталь — условие bedrock:InferenceProfileArn: оно привязывает разрешение к конкретному профилю и не даёт обойти маршрутизацию, обратившись к модели напрямую в другом регионе.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "InvokeViaApprovedInferenceProfiles",
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": [
"arn:aws:bedrock:ca-central-1:ACCOUNT_ID:inference-profile/PROFILE_ID"
],
"Condition": {
"StringEquals": {
"bedrock:InferenceProfileArn": "arn:aws:bedrock:ca-central-1:ACCOUNT_ID:inference-profile/PROFILE_ID"
}
}
}
]
}
Что важно в этом фрагменте. Resource и Condition ссылаются на один и тот же ARN профиля: одного Resource мало, потому что вызовы через CRIS проверяются ещё и по условию на профиль. Плейсхолдеры ACCOUNT_ID и PROFILE_ID замените значениями из вывода get-inference-profile. Формат ARN и номер аккаунта зависят от типа профиля, поэтому копируйте строку целиком, а не собирайте по памяти.
Тот же condition переносится в SCP на уровне AWS Organizations, где он ограничивает набор разрешённых профилей сразу для всех аккаунтов подразделения:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyInvokeOutsideApprovedProfiles",
"Effect": "Deny",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"bedrock:InferenceProfileArn": [
"arn:aws:bedrock:ca-central-1:ACCOUNT_ID:inference-profile/PROFILE_US_ID",
"arn:aws:bedrock:ca-central-1:ACCOUNT_ID:inference-profile/PROFILE_GLOBAL_ID"
]
}
}
}
]
}
У Deny есть побочный эффект. Условие срабатывает и тогда, когда ключ bedrock:InferenceProfileArn в запросе отсутствует, поэтому политика заблокирует любые вызовы bedrock:InvokeModel без профиля, включая чужие модели в том же аккаунте. Если такие вызовы нужны, сузьте Resource до ARN конкретных моделей или вынесите Deny на отдельный OU. SCP не заменяет IAM: он задаёт верхнюю границу, а разрешение всё равно выдаётся ролью или пользователем в исходном регионе.
Проверка доступных профилей через AWS CLI и консоль
Перед написанием кода убедитесь, что профиль виден в регионе, из которого вы собираетесь вызывать модель.
aws bedrock list-inference-profiles --region ca-central-1
aws bedrock list-inference-profiles --region ca-west-1
aws bedrock get-inference-profile --region ca-central-1 --inference-profile-identifier PROFILE_ARN
В консоли Bedrock тот же список открывается в разделе inference profiles. Проверяйте три вещи: регион в правом верхнем углу совпадает с исходным, префикс профиля (us. или global.) соответствует вашей политике data residency, ARN скопирован целиком. ARN понадобится дважды: в запросе и в IAM-условии.
Отдельно проверьте, что нужная модель есть в списке поддерживаемых для выбранного профиля. Набор моделей по регионам меняется, и расхождение между статьёй и консолью чаще всего означает именно это.
Вызов моделей: Responses API, Chat Completions API и Converse API
Все три пути работают на endpoint bedrock-runtime. В поле model (в Converse это modelId) передаётся ARN или идентификатор inference-профиля, а не имя модели: именно профиль включает маршрутизацию. Если подставить имя модели напрямую, вызов либо не найдёт провайдера, либо уйдёт мимо нужного пула мощностей.
- OpenAI Responses API. Агентные сценарии, вызов инструментов, стриминг. В анонсе для него приведены примеры и стриминга, и tool use.
- OpenAI Chat Completions API. Когда в проекте уже есть OpenAI-совместимый код и хочется поменять только адрес и идентификатор модели.
- Amazon Bedrock Converse API. Нативный Bedrock-стек, единый формат сообщений и инструментов для разных моделей, удобно при мультипровайдерной архитектуре.
Пример на Converse API из ca-central-1:
import boto3
client = boto3.client("bedrock-runtime", region_name="ca-central-1")
arn = "arn:aws:bedrock:ca-central-1:ACCOUNT_ID:inference-profile/PROFILE_ID"
resp = client.converse(
modelId=arn,
messages=[
{"role": "user", "content": [{"text": "Суммаризируй тикет и выдели главный риск"}]}
],
inferenceConfig={"maxTokens": 800, "temperature": 0.2},
)
print(resp["output"]["message"]["content"][0]["text"])
Контекст до 1 млн токенов и режим рассуждения доступны через все три API, но параметры рассуждения и формата ответа у OpenAI-совместимых вызовов и у Converse различаются. Точные поля и пути запросов смотрите в документации Bedrock Runtime: набор параметров у моделей OpenAI на Bedrock шире, чем в типовом примере выше.
Стриминг ответов
Стриминг сокращает время до первого токена и нужен там, где ответ читает человек или агент принимает решение по ходу генерации. Требуется отдельное разрешение bedrock:InvokeModelWithResponseStream. При CRIS поток идёт через исходный регион, приложению не нужно знать destination.
stream = client.converse_stream(
modelId=arn,
messages=[{"role": "user", "content": [{"text": "Разбери инцидент по шагам"}]}],
inferenceConfig={"maxTokens": 1500},
)["stream"]
for event in stream:
if "contentBlockDelta" in event:
print(event["contentBlockDelta"]["delta"].get("text", ""), end="")
Практический нюанс: обрыв клиентского соединения не отменяет списание токенов, которые модель уже сгенерировала. Ставьте таймауты и лимит maxTokens осознанно.
Tool use и агентные сценарии
Схема одинаковая во всех трёх API: вы объявляете инструменты (имя, назначение, JSON-схема аргументов), модель возвращает вызов с аргументами, приложение выполняет функцию и отправляет результат обратно в диалог, после чего получает финальный ответ. В Converse инструменты передаются в toolConfig, в Responses API используется собственный формат объявления и собственные события для вызовов.
Под агентные сценарии в линейке есть два разных профиля. GPT-6 Astra рассчитана на сложные end-to-end рассуждения и многошаговые агентные цепочки, GPT-6.1 Sol даёт сильные рассуждения и кодинг с балансом производительности и стоимости. Логика выбора и ограничения подробно разобраны в материале про GPT-6 Astra и корпоративных агентов.
Какую модель выбрать: GPT-5.6, GPT-6 или GPT-6.1 Sol
Позиционирование по данным анонса:
| Модель | Позиционирование | Когда подходит |
|---|---|---|
| GPT-5.6 Sol | Высокие нагрузки рассуждения, кодинга и агентных задач | Сложные шаги, где качество важнее задержки |
| GPT-5.6 Terra | Баланс производительности и стоимости для повседневного продакшена | Основной рабочий профиль для регулярных запросов |
| GPT-5.6 Luna | Быстро и доступно для высоконагруженных приложений, чувствительных к задержке | Массовые операции с жёстким SLA по времени ответа |
| GPT-6 Astra | Сложные end-to-end рассуждения и агентные задачи | Многошаговые агенты, где цепочка должна дойти до результата |
| GPT-6 Sol | Рассуждения и кодинг для повторяющихся задач с подходящей экономикой | Регулярная разработка, отладка, анализ данных |
| GPT-6 Luna | Быстрый и недорогой инференс для высоконагруженных повторяющихся задач, reasoning effort настраивается на запрос | Извлечение, классификация, суммаризация большими объёмами |
| GPT-6.1 Sol | Сильные рассуждения и кодинг при балансе производительности и стоимости | Кодинг-ассистенты и анализ, где важны и качество, и бюджет |
Цены и результаты бенчмарков здесь не приводятся: в исходном анонсе их нет, а цифры из сторонних обзоров плохо переносятся на чужой профиль нагрузки. Сравнение GPT-6 Sol и Luna по экономике запроса разобрано отдельно в материале про выбор между GPT-6 Sol и GPT-6 Luna.
Рабочая эвристика для пайплайна: Luna на маршрутизацию и извлечение, Terra или GPT-6 Sol на типовые производственные задачи, Astra на шаги, где ошибка дороже токенов, GPT-6.1 Sol на кодинг. Проверять гипотезу стоит на своём наборе запросов, а не на общем лидерборде.
Квоты, prompt caching и стоимость владения
Квоты на Bedrock считаются в токенах в минуту. Выходные токены расходуют лимит быстрее входных: это и есть burndown rate, из-за которого длинная генерация упирается в потолок раньше, чем позволяет прикидка по размеру промпта. Планируйте лимит по худшему сценарию (maxTokens в запросе), а не по среднему размеру ответа. Стартовые значения по каждой модели и региону смотрите в Service Quotas AWS, там же оформляется запрос на увеличение. Конкретные коэффициенты в доступном фрагменте анонса не приведены, поэтому сверяйтесь с консолью перед тем, как обещать заказчику пропускную способность.
Prompt caching поддерживается у GPT-5.6, GPT-6 и GPT-6.1 в Amazon Bedrock. Кэш окупается там, где между запросами повторяется большой статический префикс: системная инструкция, описание инструментов, справочник, схема данных. При уникальном промпте на каждый вызов он не даёт ничего. Как это устроено на практике и какие есть подводные камни, разобрано в гайде по GPT-5.6 на Bedrock.
Стоимость владения складывается из трёх частей: токены, повторные попытки при ошибках и инженерное время на маршрутизацию. CRIS снимает третью почти полностью, но не отменяет первых двух. Ретраи с длинным контекстом после таймаута оплачиваются как новый запрос.
Data residency: что остаётся в Канаде, а что уходит
Разделяйте две сущности. Данные at rest остаются в исходном регионе, то есть в вашем ca-central-1 или ca-west-1: сюда относятся запросы, сохранённые в сервисах вокруг Bedrock, и ваши собственные хранилища. Сам инференс обрабатывается в Северной Америке (профиль us.) или в поддерживаемых коммерческих регионах AWS (профиль global.).
Отдельный пункт, который чаще всего всплывает в юридических обсуждениях: контент, помеченный классификаторами злоупотреблений, может храниться до 30 дней в регионе обработки. Публичный фрагмент анонса обрывается до раздела о data residency, поэтому сроки и точную географию хранения подтверждайте в документации Bedrock и у своего аккаунт-менеджера AWS, прежде чем ссылаться на них в политике.
Вывод для комплаенса. Если внутренние правила запрещают хранение даже помеченного контента за пределами Канады, это нужно согласовать с юристами явно, а global-профиль использовать с осторожностью: он расширяет географию обработки. Гарантий здесь никто дать не может, решение принимает ваша служба комплаенса на основе документации и договора.
Observability: CloudTrail и CloudWatch в исходном регионе
Сигналы наблюдаемости доступны в исходном регионе, и это заметное удобство: не нужно собирать логи из нескольких destination-регионов и склеивать их по request-id. CloudTrail фиксирует вызовы API, включая отказы по IAM и SCP, CloudWatch отдаёт метрики по запросам и ошибкам.
Настройте алерты на throttling и на долю ошибок доступа. При CRIS лимиты и burndown rate проявляются на стороне профиля, поэтому всплеск throttling часто означает не аварию, а упор в квоту в пиковый момент. Полезно держать отдельную метрику по каждому профилю и модели: агрегированный график скрывает, что один сценарий съедает весь запас токенов в минуту.
После экспериментов уберите за собой: временные роли, тестовые политики, неиспользуемые профили в приложении. Забытая широкая политика переживёт эксперимент на месяцы.
Чек-лист внедрения и типичные ошибки
- Выберите исходный регион: ca-central-1 или ca-west-1.
- Проверьте доступные профили через list-inference-profiles и get-inference-profile, скопируйте ARN.
- Определитесь с префиксом us. или global. по политике data residency. Помните, что глобальный профиль GPT-5.6 доступен только из ca-central-1.
- Настройте IAM-политику и SCP с условием bedrock:InferenceProfileArn, проверьте, что Deny не блокирует другие модели в аккаунте.
- Выберите API: Responses для агентных сценариев, Chat Completions для совместимости с существующим кодом, Converse для нативного Bedrock-стека.
- Включите prompt caching для статических промптов и описаний инструментов.
- Запросите увеличение квот с учётом burndown rate по выходным токенам.
- Настройте CloudTrail и алерты CloudWatch в исходном регионе.
Типичные ошибки, которые ломают запуск:
- Политика без условия на профиль: доступ есть, контроля над географией обработки нет.
- Попытка вызвать модель напрямую в другом регионе в обход профиля: отказ доступа либо обход guardrail.
- Ожидание, что данные вообще не покидают Канаду: инференс идёт в Северной Америке, а помеченный контент может храниться в регионе обработки.
- Планирование квот по среднему размеру ответа без учёта burndown rate.
- Расчёт бюджета только по цене за токен без ретраев и повторной отправки длинного контекста.
Следующий шаг простой: поднимите тестовую роль в ca-central-1, вызовите нужную модель через Converse с ARN профиля и снимите метрики за сутки. Так вы получите свои цифры по задержке и расходу токенов до того, как решение уйдёт в продакшен.