AWS запустила Amazon Bedrock в Новой Зеландии с Claude и межрегиональным инференсом

AWS 26 марта 2026 года запустила Amazon Bedrock в регионе Asia Pacific (New Zealand), то есть в Окленде. Для местных компаний это означает, что запросы к генеративным моделям теперь можно отправлять из новозеландского региона AWS, а Bedrock при необходимости сам распределит инференс между Оклендом и австралийскими площадками.

Как устроен запуск

Новый регион AWS получил идентификатор ap-southeast-6 и стал исходной точкой для cross-Region inference в Bedrock. На практике это значит, что приложение может делать API-вызов из Окленда, а сама обработка запроса уйдёт либо в тот же регион, либо в Сидней, либо в Мельбурн. Для Новой Зеландии AWS добавила отдельную географическую конфигурацию AU, которая удерживает обработку внутри пространства Австралии и Новой Зеландии и даёт бизнесу больше вариантов по пропускной способности.

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

Логи всех cross-Region вызовов при этом остаются в исходном регионе, то есть в Окленде.

Какие модели доступны

На старте новозеландский регион получил доступ к линейке Anthropic Claude: Opus 4.5, Opus 4.6, Sonnet 4.5, Sonnet 4.6 и Haiku 4.5. Для глобального профиля AWS также указывает доступ к Amazon Nova 2 Lite и к более широкому набору моделей от разных провайдеров. Разработчикам не нужно переучивать интеграции с нуля: профили работают через стандартные API Bedrock, включая InvokeModel, InvokeModelWithResponseStream, Converse и ConverseStream.

• Географический профиль AU держит инференс в Окленде, Сиднее и Мельбурне Глобальный профиль даёт больше доступной мощности и шире выбор моделей Идентификаторы моделей меняются через префиксы au. и global.
• Существующая маршрутизация для Сиднея и Мельбурна не меняется * Единый формат Converse упрощает переключение между моделями без переписывания кода Важная деталь: для австралийско-новозеландского профиля сейчас поддерживаются именно модели Claude, тогда как глобальная маршрутизация открывает более широкий набор базовых моделей. Это разделение важно для команд, которые одновременно следят и за соответствием внутренним требованиям, и за доступностью мощности. Если нужна предсказуемая география обработки, логичнее смотреть на AU-профиль. Если критичнее максимальная пропускная способность, тогда полезнее глобальный маршрут с динамическим распределением нагрузки.

Контроль и лимиты Запуск в новом регионе не избавляет от инфраструктурной настройки.

Чтобы вызывать модели через AU-профиль из Окленда, IAM-политика должна разрешать доступ и к профилю инференса в ap-southeast-6, и к самим моделям во всех регионах назначения. AWS рекомендует схему с минимально необходимыми правами: разрешить вызов модели в Сиднее, Мельбурне и Окленде только тогда, когда запрос идёт через inference profile, а не напрямую. Для компаний с Service Control Policies это тоже важно, потому что Bedrock нужно явно разрешить работу сразу в трёх ANZ-регионах.

Есть и операционные нюансы. Квоты считаются на уровне исходного региона, так что увеличение лимита в Окленде распространяется только на запросы, отправленные из ap-southeast-6. AWS измеряет нагрузку по двум осям — tokens per minute и requests per minute, а для части моделей Claude выходные токены списываются по коэффициенту 5:1 относительно входных.

Для Claude Haiku 4.5 и моделей Nova действует коэффициент 1:1. Проверять, где именно отработал запрос, можно через CloudTrail по полю inferenceRegion, а следить за задержками, ошибками и расходом токенов — через метрики CloudWatch.

Что это значит

Для AWS это не просто ещё один регион в списке, а попытка сделать Bedrock ближе к корпоративным клиентам Новой Зеландии, которым важны и задержки, и контроль над географией обработки. Для рынка это хороший сигнал: облачные AI-платформы всё чаще конкурируют не только моделями, но и тем, насколько аккуратно они решают вопросы маршрутизации, квот и комплаенса.