Amazon Bedrock добавил India geographic cross-Region inference для GPT-5.6 Terra и Luna. Для индийских команд это прежде всего способ получить общий пул мощности в Mumbai и Hyderabad без собственного межрегионального роутинга. Но слово geographic здесь важнее слова cross-Region: данные остаются в стране, а не в конкретном регионе.
Что именно запустил AWS
Как пишет AWS Machine Learning Blog, запрос можно отправить в Bedrock из Asia Pacific (Mumbai), ap-south-1, или Asia Pacific (Hyderabad), ap-south-2. Bedrock сам выберет, в каком из этих двух регионов исполнить запрос, исходя из доступной мощности.
Для этого используются два inference profile: in.openai.gpt-5.6-terra для GPT-5.6 Terra и in.openai.gpt-5.6-luna для GPT-5.6 Luna. Обе модели принимают текст и изображения, возвращают текст и поддерживают контекст до 1 млн токенов.
GPT-5.6 Sol в индийский профиль не входит. Он доступен вместе с Terra и Luna через глобальные профили с префиксом global., но такой режим может отправить запрос в поддерживаемый коммерческий AWS Region за пределами Индии. Для задач с локальной обработкой AWS прямо рекомендует профили in..
Вызовы доступны через OpenAI Responses API, OpenAI Chat Completions API и Bedrock Converse API. AWS рекомендует новым приложениям endpoint bedrock-runtime: именно там работают cross-Region inference, Guardrails и другие функции Bedrock.
Это общий пул мощности, а не магия отказоустойчивости
AWS называет cross-Region inference прежде всего механизмом управления capacity. До этого приложение было ограничено мощностью одного региона или команда должна была сама распределять запросы. Теперь профиль получает доступ к объединённому пулу Mumbai и Hyderabad, что должно помогать сохранять throughput во время пиков.
Это логичное продолжение запуска GPT-5.6 Sol, Terra и Luna в Bedrock и появления cross-Region inference более чем в 25 регионах AWS. Индия получила отдельный контур, который сочетает дополнительную ёмкость с обработкой внутри страны.
Для оператора выгода вполне земная: меньше кода для маршрутизации, меньше ручного планирования capacity и одна точка наблюдения. Billing и расход квот учитываются в исходном регионе, откуда приложение вызвало профиль, даже если модель фактически отработала во втором. Записи Amazon CloudWatch и AWS CloudTrail тоже остаются только в исходном регионе.
Но считать эту функцию готовой заменой собственной схеме disaster recovery я бы не стал. AWS обещает маршрутизацию по доступной мощности и более стабильный throughput под нагрузкой, а не фиксированный регион исполнения или отдельный SLA на межрегиональное переключение.
Цена и задержка пока остаются задачей клиента
В анонсе нет нового тарифа для индийских профилей и нет обещания, что cross-Region inference снизит стоимость одного запроса. Поэтому экономический эффект возникает не из скидки, а из потенциального отказа от собственного роутера и резервирования capacity. Его придётся считать на своей архитектуре.
С задержкой та же история. Запрос, отправленный в Mumbai, может быть исполнен в Hyderabad, и наоборот. AWS говорит о consistent performance под нагрузкой, но не обещает меньшую latency для каждого вызова. На спокойном трафике локальный маршрут может оказаться быстрее, а на пике общий пул может выиграть за счёт меньшего дефицита мощности. Без замеров p95 и p99 это просто две правдоподобные гипотезы.
Резидентность тоже требует точной формулировки. Prompts и результаты не покидают Индию, но могут перемещаться между ap-south-1 и ap-south-2. Данные шифруются при передаче по сети Amazon. Bedrock использует zero data retention по умолчанию, однако для GPT-5.6 контент, отмеченный автоматическими классификаторами злоупотреблений, может сохраняться для последующей проверки. Значит, требование «обработка только в Индии» профиль закрывает, а требование «обработка только в Mumbai» уже нет.
Практический тест простой: после перехода на профиль in. нужно сравнить долю throttling, throughput и p95/p99 latency на пиковом трафике, а также проверить, допускает ли политика данных перемещение между Mumbai и Hyderabad. Если throttling снижается без неприемлемого роста задержки, AWS действительно снял проблему capacity. Если аудит требует одного региона, автоматический роутинг решает не ту задачу.