AWS udostępnia dostęp do GPT-5.6 w Amazon Bedrock z regionów australijskich

Amazon Web Services poinformował 2 września 2026 r., że zespoły w Australii mogą teraz uzyskać dostęp do modeli GPT-5.6 firmy OpenAI na Amazon Bedrock, wywołując warianty Sol, Terra i Luna z regionów Azji i Pacyfiku (Sydney) oraz Azji i Pacyfiku (Melbourne) za pośrednictwem globalnego wnioskowania międzyregionowego.

W ramach tego rozwiązania aplikacja wywołuje punkt końcowy Amazon Bedrock Runtime w Sydney lub Melbourne, a Bedrock kieruje żądanie do obsługiwanego komercyjnego regionu AWS w celu przetworzenia. AWS poinformował, że daje to klientom z Australii dostęp do szerszej puli pojemności bez konieczności zarządzania trasowaniem do regionu docelowego. Trzy globalne profile wnioskowania obejmują modele: global.openai.gpt-5.6-sol, global.openai.gpt-5.6-terra i global.openai.gpt-5.6-luna. Sydney ma kod regionu ap-southeast-2, a Melbourne ap-southeast-4.

Trzy warianty GPT-5.6

AWS opisał trzy warianty jako obsługujące różne profile obciążeń. Według AWS Machine Learning Blog post, GPT-5.6 Sol jest przeznaczony do wymagających zadań rozumowania, kodowania i agentowych; Terra równoważy wydajność i koszt w codziennym użyciu produkcyjnym; a Luna zapewnia szybkie, niedrogie wnioskowanie dla aplikacji o dużej objętości i wrażliwych na opóźnienia. Wszystkie trzy przyjmują dane tekstowe i graficzne, generują tekst oraz obsługują okna kontekstowe do 1 miliona tokenów.

Z dwóch australijskich regionów deweloperzy mogą wywoływać modele za pośrednictwem trzech ścieżek dostępu na punkcie końcowym Bedrock Runtime: OpenAI Responses API, OpenAI Chat Completions API oraz Amazon Bedrock Converse API. API kompatybilne z OpenAI są wywoływane na ścieżkach /openai/v1 punktu końcowego, a nie przez SDK AWS, a punkt końcowy akceptuje zarówno podpisywanie przy użyciu AWS Signature Version 4, jak i klucz API wnioskowania modelu Amazon Bedrock.

Buforowanie podpowiedzi jest dostępne dla GPT-5.6 poprzez obsługiwane API w dwóch trybach. Buforowanie domyślne jest włączone standardowo bez zmian w kodzie, natomiast buforowanie jawne pozwala deweloperom określić wielokrotnego użytku prefiks, granicę bufora i klucz bufora. AWS zauważył, że przynależność do profilu i dostępność modeli mogą ulec zmianie i skierował klientów do cross-Region inference support documentation, aby zweryfikować konfiguracje przed wdrożeniem.

Integracja Codex i uwierzytelnianie OIDC

Agent kodujący Codex firmy OpenAI może korzystać z tych samych globalnych profili wnioskowania poprzez dostawcę modeli Bedrock Runtime wbudowanego w najnowszy Codex CLI. AWS poinformował, że zweryfikował konfigurację przy użyciu codex-cli 0.149.1 uruchamiającego GPT-5.6 Sol z Sydney.

Dla organizacji, które federują tożsamość za pośrednictwem Okta, Auth0, Microsoft Entra ID, Amazon Cognito lub AWS IAM Identity Center, AWS udostępnia przykładowy pomocnik poświadczeń, który wymienia token OpenID Connect na tymczasowe poświadczenia AWS. Codex odczytuje te poświadczenia poprzez standardowy łańcuch poświadczeń AWS, a żądania są podpisywane przy użyciu SigV4, więc w ścieżce wnioskowania nie jest używany klucz API. Gdy profil jest obsługiwany przez IAM Identity Center, poświadczenia są już krótkoterminowe i rotują wraz z sesją jednokrotnego logowania.

Wymagania wstępne dla wdrożeń w Australii obejmują konto AWS z włączonym regionem Sydney lub Melbourne jako regionem źródłowym, rolę lub użytkownika IAM z uprawnieniami do wywoływania globalnych profili wnioskowania GPT-5.6 oraz Pythona 3.9 lub nowszego z zainstalowanymi pakietami openai, boto3 i aws-bedrock-token-generator. Organizacje korzystające z polityk kontroli usług muszą zweryfikować, czy ich polityka zezwala na globalne profile wnioskowania GPT-5.6 w wybranym regionie źródłowym. Administratorzy mogą potwierdzić aktywne profile za pomocą AWS CLI lub widoku profili wnioskowania w konsoli Amazon Bedrock.

Limity, monitorowanie i rejestrowanie

Limity na żądanie GPT-5.6 są mierzone w liczbie żądań na minutę oraz tokenów na minutę, przy czym zużycie tokenów określa, jak każde żądanie zużywa limit tokenów. Dla GPT-5.6 tokeny wejściowe i tokeny zapisu w buforze liczone są w stosunku 1:1, natomiast każdy token wyjściowy zużywa 10 tokenów z limitu, według AWS. Limity są przeglądane i zwiększane poprzez konsolę Service Quotas w regionie źródłowym używanym przez aplikację, a AWS zalecił klientom wnioskowanie o zwiększenia z wyprzedzeniem, monitorowanie wykorzystania oraz testowanie reprezentatywnych podpowiedzi, zachowań strumieniowania, współbieżności i szczytowego ruchu przed wdrożeniem produkcyjnym.

Ponieważ żądania GPT-5.6 korzystają z API Bedrock Runtime, wywołania wykonywane za pośrednictwem globalnych profili wnioskowania pojawiają się w logach wywołań modeli podobnie jak inne żądania na żądanie, zawierając rekordy z identyfikatorem profilu wnioskowania oraz metadanymi wywołania. Codex eksportuje metryki za pośrednictwem protokołu OpenTelemetry, a CloudWatch Coding Agent Insights udostępnia pulpit nawigacyjny dla tych danych telemetrycznych, obejmujący zużycie tokenów, żądania API, aktywnych użytkowników, aktywność konwersacji oraz wskaźnik trafień w buforze.

AWS oferuje dwie ścieżki konfiguracji pulpitu: podejście oparte na tokenie nośnika przy użyciu klucza API metryk CloudWatch oraz wdrożenie korporacyjne, w którym lokalny kolektor podpisuje eksport przy użyciu SigV4 z federowanymi poświadczeniami dewelopera. AWS klasyfikuje klucz API metryk jako poświadczenie długoterminowe i zaleca go wyłącznie w sytuacjach, gdy poświadczenia krótkoterminowe nie są możliwe. Ścieżka korporacyjna jest zalecaną opcją dla organizacji, które federują tożsamość dewelopera poprzez korporacyjne jednokrotne logowanie, poinformował AWS.