O que foi anunciado
A Amazon Bedrock passou a oferecer os modelos OpenAI GPT-5.6 com suporte a inferência entre regiões (cross-Region inference, ou CRIS) em mais de 25 regiões AWS. São três variantes de uso geral que suportam esse recurso: Sol, Terra e Luna, cada uma calibrada para um equilíbrio diferente entre capacidade e custo.
Todas as três aceitam entradas de texto e imagem, retornam texto, possuem janela de contexto de 1 milhão de tokens e suportam modo de raciocínio (reasoning mode), chamada de ferramentas no lado do servidor e prompt caching. Elas podem ser chamadas pela OpenAI Responses API, pela OpenAI Chat Completions API e pela Amazon Bedrock Converse API — com suporte a streaming em todas elas.
Como funciona a inferência cross-Region
O CRIS no Amazon Bedrock opera por meio de perfis de inferência (inference profiles), que definem o modelo e as regiões AWS para as quais o Bedrock pode rotear uma requisição. A aplicação chama o perfil a partir de uma região de origem, e o Bedrock roteia a requisição para uma região de destino com capacidade disponível naquele momento.
O objetivo principal do CRIS é ampliar a capacidade. Em vez de depender exclusivamente da capacidade de uma única região, as requisições podem ser distribuídas por um pool mais amplo de computação, o que melhora o throughput e mantém a performance estável sob carga.
Perfil geográfico vs. perfil global
Existem dois tipos de perfis disponíveis para o GPT-5.6:
- Perfil geográfico (prefixo
us., por exemplous.openai.gpt-5.6-terra): roteia requisições dentro de uma geografia específica. As requisições entram pela região de origem e só podem ser direcionadas para regiões de destino dentro dessa mesma geografia. É a escolha certa para workloads com requisitos de residência de dados. - Perfil global (prefixo
global., por exemploglobal.openai.gpt-5.6-terra): pode rotear para qualquer região comercial AWS onde o modelo esteja implantado, com base na capacidade em tempo real. Oferece o maior pool de capacidade e é indicado quando não há restrições geográficas de processamento.
Este lançamento introduz o perfil geográfico US e o perfil global de CRIS para o GPT-5.6. Independentemente do perfil usado, o faturamento e o consumo de cotas são contabilizados na conta do cliente — não importa qual região de backend processou a requisição.
Para workloads com requisitos de residência de dados que restrinjam o processamento a geografias específicas, a AWS recomenda usar o perfil geográfico correspondente ou uma chamada direta a uma única região, em vez do perfil global. A documentação de inferência cross-Region lista quais regiões participam de cada conjunto de perfis.
Regiões de origem e destino
Para o perfil US cross-Region, as regiões de origem incluem US East (N. Virginia), US West (Oregon), US East (Ohio), US West (N. California), Canada (Central) e Canada West (Calgary). As requisições de todas essas origens podem ser roteadas para us-east-1, us-east-2 e us-west-2 — com algumas origens também incluindo sua própria região no pool de destino.
Para o perfil global, as regiões de origem cobrem Estados Unidos, Canadá, Europa, Ásia-Pacífico (incluindo South America (São Paulo) sa-east-1), Oriente Médio e América do Sul. As requisições podem ser roteadas para qualquer região comercial AWS suportada pelo modelo.
Primeiros passos: console e API
A forma mais rápida de experimentar o GPT-5.6 é pelo playground de texto do console do Amazon Bedrock, sem necessidade de código ou configuração de SDK. O seletor de modelos lista tanto os perfis geográficos quanto os globais, permitindo testar as duas opções antes de integrar via API.
Usando o OpenAI SDK com o endpoint do Bedrock
O GPT-5.6 suporta nativamente os formatos da OpenAI Responses API no Amazon Bedrock. Se a aplicação já chama modelos OpenAI, basta apontar o cliente OpenAI SDK para o endpoint compatível do Bedrock e substituir o parâmetro de modelo pelo ID do perfil de inferência (global ou geográfico).
Para autenticação, o Bedrock aceita credenciais AWS padrão ou uma chave de API do Amazon Bedrock. O caminho da chave de API é o mais direto para o OpenAI SDK, que a passa como bearer token. Para produção, a AWS recomenda gerar chaves de curta duração programaticamente com o pacote aws-bedrock-token-generator:
from aws_bedrock_token_generator import provide_token
from openai import OpenAI
region = "us-east-1"
# Point the OpenAI SDK at Amazon Bedrock's OpenAI-compatible endpoint for your Region.
# provide_token() generates a short-term Amazon Bedrock API key from your current AWS credentials (valid up to 12 hours), so no static key needs to be stored.
client = OpenAI(
base_url= f"https://bedrock-runtime.{region}.amazonaws.com/openai/v1",
api_key=provide_token(region=region),
)
# Use the global inference profile ID for GPT-5.6 Terra.
model_id = "global.openai.gpt-5.6-terra"
response = client.responses.create(
model=model_id,
input="Summarize the difference between horizontal and vertical scaling in two sentences.",
max_output_tokens=512,
)
print(response.output_text)Para a lista completa de parâmetros suportados, consulte a página de parâmetros do modelo OpenAI GPT no Guia do Usuário do Amazon Bedrock.
O mesmo cliente também funciona com a Chat Completions API:
response = client.chat.completions.create(
# For US Geo CRIS, use "us.openai.gpt-5.6-terra".
# Other variants: gpt-5.6-sol, gpt-5.6-luna
model="global.openai.gpt-5.6-terra",
messages=[
{
"role": "user",
"content": "In one sentence, what is cross-Region inference in Amazon Bedrock?",
}
],
max_completion_tokens=2000,
reasoning_effort="low",
)
print(response.choices[0].message.content)Usando a Bedrock Converse API
Para quem prefere chamar o Amazon Bedrock diretamente, sem o OpenAI SDK, a Converse API mantém o mesmo formato de requisição já usado para outros modelos no Bedrock:
import boto3
client = boto3.client("bedrock-runtime", region_name="us-east-1")
model_id = "global.openai.gpt-5.6-terra"
response = client.converse(
modelId=model_id,
messages=[{"role": "user", "content": [{"text": "List three common uses for a message queue."}]}],
inferenceConfig={"maxTokens": 512},
)
print(response["output"]["message"]["content"][0]["text"])Para respostas em streaming, basta chamar converse_stream com os mesmos argumentos e iterar sobre o stream de eventos:
stream_response = client.converse_stream(
modelId=model_id,
messages=[{"role": "user", "content": [{"text": "List three common uses for a message queue."}]}],
inferenceConfig={"maxTokens": 512},
)
for event in stream_response["stream"]:
if "contentBlockDelta" in event:
print(event["contentBlockDelta"]["delta"]["text"], end="")Segurança e conformidade
O CRIS usa o mesmo modelo de segurança do Amazon Bedrock que chamadas diretas dentro de uma região. As requisições são autenticadas com credenciais do Controle de Acesso e Identidade da AWS (IAM — Identity and Access Management), e as políticas IAM controlam quais perfis de inferência cada função pode invocar.
O Bedrock adota um modelo de segurança de acesso zero por operador (ZOA — Zero-Operator Access), aplicado no nível do chip, o que impede que operadores da AWS acessem prompts ou respostas. Cada chamada de modelo roda sob as políticas IAM da conta, pode ser acessada de forma privada a partir de uma Nuvem Virtual Privada (VPC — Virtual Private Cloud) via endpoint VPC, e é registrada no AWS CloudTrail.
Para determinados modelos, incluindo o GPT-5.6, conteúdo sinalizado pelos classificadores automáticos de detecção de abuso do Bedrock é retido por até 30 dias para detecção offline. Para entender como isso funciona, consulte a seção de detecção de abuso e a documentação de retenção de dados do Amazon Bedrock.
Requisições de CRIS aparecem no AWS CloudTrail da região de origem, e o campo additionalEventData.inferenceRegion registra qual região processou cada requisição. Se o registro de invocações de modelos (model invocation logging) estiver habilitado, os payloads de requisição e resposta são entregues ao Amazon S3 ou ao Amazon CloudWatch Logs na mesma conta e região.
Configurando permissões IAM para cross-Region inference
Para permitir que uma função invoque o GPT-5.6 via perfil de inferência, é necessário conceder acesso ao perfil de inferência e ao modelo base em todas as regiões para as quais o perfil pode rotear. É possível usar a política gerenciada AmazonBedrockLimitedAccess ou criar uma política própria.
Para um perfil geográfico, a política tem três declarações: acesso ao perfil geográfico e ao projeto padrão na região de origem; acesso ao modelo base na região de origem e em cada região de destino da geografia (com condição que restringe esse acesso a requisições feitas via esse perfil); e autenticação via bearer token para as APIs compatíveis com OpenAI.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "GrantGeoCrisProfileAndProjectAccess",
"Effect": "Allow",
"Action": ["bedrock:InvokeModel"],
"Resource": [
"arn:aws:bedrock:<SOURCE REGION>:<ACCOUNT>:inference-profile/us.openai.gpt-5.6-terra",
"arn:aws:bedrock:<SOURCE REGION>:<ACCOUNT>:project/default"
]
},
{
"Sid": "GrantGeoCrisDestinationModelAccess",
"Effect": "Allow",
"Action": ["bedrock:InvokeModel"],
"Resource": [
"arn:aws:bedrock:us-east-1::foundation-model/openai.gpt-5.6-terra",
"arn:aws:bedrock:us-east-2::foundation-model/openai.gpt-5.6-terra",
"arn:aws:bedrock:us-west-2::foundation-model/openai.gpt-5.6-terra"
],
"Condition": {
"StringLike": {
"bedrock:InferenceProfileArn": "arn:aws:bedrock:<SOURCE REGION>:<ACCOUNT>:inference-profile/us.openai.gpt-5.6-terra"
}
}
},
{
"Sid": "AllowBearerTokenAuth",
"Effect": "Allow",
"Action": ["bedrock:CallWithBearerToken"],
"Resource": "*"
}
]
}Para um perfil global, a política tem quatro declarações: acesso ao perfil global e ao projeto padrão na região de origem; acesso ao modelo base na região de origem; acesso ao modelo base via ARN global (sem especificação de região), que é o que habilita o roteamento cross-Region; e autenticação via bearer token.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "GrantGlobalCrisProfileAndProjectAccess",
"Effect": "Allow",
"Action": ["bedrock:InvokeModel"],
"Resource": [
"arn:aws:bedrock:<REQUESTING REGION>:<ACCOUNT>:inference-profile/global.openai.gpt-5.6-terra",
"arn:aws:bedrock:<REQUESTING REGION>:<ACCOUNT>:project/default"
],
"Condition": {
"StringEquals": {
"aws:RequestedRegion": "<REQUESTING REGION>"
}
}
},
{
"Sid": "GrantGlobalCrisInRegionModelAccess",
"Effect": "Allow",
"Action": ["bedrock:InvokeModel"],
"Resource": ["arn:aws:bedrock:<REQUESTING REGION>::foundation-model/openai.gpt-5.6-terra"],
"Condition": {
"StringEquals": {
"aws:RequestedRegion": "<REQUESTING REGION>",
"bedrock:InferenceProfileArn": "arn:aws:bedrock:<REQUESTING REGION>:<ACCOUNT>:inference-profile/global.openai.gpt-5.6-terra"
}
}
},
{
"Sid": "GrantGlobalCrisGlobalModelAccess",
"Effect": "Allow",
"Action": ["bedrock:InvokeModel"],
"Resource": ["arn:aws:bedrock:::foundation-model/openai.gpt-5.6-terra"],
"Condition": {
"StringEquals": {
"aws:RequestedRegion": "unspecified",
"bedrock:InferenceProfileArn": "arn:aws:bedrock:<REQUESTING REGION>:<ACCOUNT>:inference-profile/global.openai.gpt-5.6-terra"
}
}
},
{
"Sid": "AllowBearerTokenAuth",
"Effect": "Allow",
"Action": ["bedrock:CallWithBearerToken"],
"Resource": "*"
}
]
}Se a aplicação usar a Converse API com streaming (ConverseStream), é necessário adicionar bedrock:InvokeModelWithResponseStream às declarações do perfil de inferência e do modelo base.
Considerações sobre Políticas de Controle de Serviço (SCPs)
Se a organização usar Políticas de Controle de Serviço (SCPs — Service Control Policies) que restrinjam regiões, é importante saber que requisições de CRIS global definem aws:RequestedRegion como unspecified — e não como um nome de região específico. Requisições de CRIS geográfico são avaliadas contra cada região de destino do perfil.
A abordagem recomendada é isentar o CRIS usando a condição bedrock:InferenceProfileArn, em vez de ampliar a lista de regiões permitidas. Para um SCP pronto para uso, consulte o exemplo de SCP de controle de regiões para Bedrock CRIS.
O acesso ao modelo deve estar habilitado para a conta e região em ambos os tipos de perfil. Para a lista completa de pré-requisitos, consulte pré-requisitos para perfis de inferência.
Prompt caching
As três variantes do GPT-5.6 suportam prompt caching no endpoint bedrock-runtime. Quando as requisições compartilham um prefixo longo — como um system prompt ou exemplos few-shot — o Amazon Bedrock armazena esse prefixo em cache. Requisições subsequentes reutilizam o prefixo cacheado em vez de reprocessá-lo, reduzindo custo e latência para a parte cacheada.
Há dois modos de caching disponíveis:
- Caching implícito (padrão): o serviço posiciona um ponto de quebra de cache na última mensagem do usuário ou de ferramenta — adequado para conversas que crescem por acréscimo de mensagens.
- Caching explícito: o desenvolvedor marca o fim do conteúdo estável com um ponto de quebra explícito — indicado quando as requisições compartilham um prefixo estável seguido de conteúdo que muda a cada chamada.
Em ambos os modos, o parâmetro opcional prompt_cache_key garante que requisições com o mesmo prefixo sejam roteadas para o mesmo cache. Cada ponto de quebra exige um prefixo de pelo menos 1.024 tokens. Para mais detalhes, consulte prompt caching para inferência mais rápida.
Exemplo de uso com caching explícito:
# support_policy_manual is a long, stable prefix shared across requests.
# The breakpoint marks the end of the stable content; the user question
# after it changes on every request without invalidating the cached prefix.
completion = client.chat.completions.create(
model=model_id,
messages=[
{
"role": "system",
"content": [
{
"type": "text",
"text": support_policy_manual,
"prompt_cache_breakpoint": {"mode": "explicit"},
}
],
},
{"role": "user", "content": "A customer wants a refund for a damaged laptop. What must I verify first?"},
],
max_completion_tokens=300,
prompt_cache_key="support-policy-v1",
)Para confirmar que o caching está funcionando, basta verificar o objeto usage de cada resposta:
details = completion.usage.prompt_tokens_details
print("Cached tokens:", details.cached_tokens)
print("Written tokens:", details.cache_write_tokens)Gerenciamento de cotas
As cotas sob demanda para o GPT-5.6 são gerenciadas em tokens por minuto (TPM — Tokens Per Minute) e estão vinculadas ao perfil de inferência chamado: um perfil geográfico e um perfil global para o mesmo modelo possuem alocações de cota separadas. Para visualizar as alocações atuais ou solicitar aumento, acesse o console do AWS Service Quotas na região de onde a aplicação chama o Bedrock.
Um ponto importante é a taxa de consumo (burndown rate): tokens de entrada contam 1:1 contra a cota, enquanto tokens de saída consomem cota em um múltiplo mais alto. Para os modelos GPT-5.6, a taxa de consumo de tokens de saída é de 10x — ou seja, um token de saída consome 10 tokens da cota de TPM. O cálculo por requisição é:
Contagem de tokens de entrada + Tokens de escrita em cache + (Contagem de tokens de saída × Taxa de consumo)
Por exemplo: uma requisição com 2.000 tokens de entrada e 1.000 tokens de saída consome 12.000 tokens da cota. Tokens de leitura de cache não entram nesse cálculo — daí a eficácia do prompt caching para gestão de cotas e custos. Para as taxas de consumo atuais por modelo, consulte a página de cotas do Amazon Bedrock.
Três práticas ajudam a evitar surpresas:
- Solicite aumentos antes do deploy. Se a expectativa é de uso intenso, solicite o aumento pelo console de Service Quotas antes do lançamento.
- Monitore a utilização. O Amazon CloudWatch publica métricas de utilização de cota em tempo real por perfil de inferência, permitindo configurar alertas quando o uso se aproximar dos limites.
- Faça testes de carga com tráfego realista (incluindo padrões de pico e prompts do tamanho de produção) antes de colocar um workload em produção — e valide contra o tipo de perfil que será efetivamente usado, pois as cotas geográfica e global são separadas.
Monitoramento e logs
Como as requisições do GPT-5.6 passam pela Bedrock Runtime API, elas aparecem no registro de invocações de modelos do Amazon Bedrock da mesma forma que requisições sob demanda, com o ARN do perfil de inferência registrado junto aos payloads. Os logs podem ser entregues ao Amazon S3 ou ao Amazon CloudWatch Logs.
Independentemente do tipo de perfil usado, logs de invocação e métricas são registrados na região de origem — a observabilidade fica centralizada mesmo quando a requisição é processada em outra região. As métricas do CloudWatch cobrem contagens de invocação, contagens de tokens, latência, throttles e erros, publicadas por perfil de inferência. Como perfis geográficos e globais são recursos distintos, suas métricas são reportadas separadamente.
O uso também é detalhado no AWS Cost Explorer e no Relatório de Custos e Uso da AWS (AWS Cost and Usage Report), permitindo atribuir gastos com GPT-5.6 por modelo e por perfil.
Conclusão
Com este lançamento, a AWS disponibiliza três variantes do OpenAI GPT-5.6 no Amazon Bedrock com suporte a inferência cross-Region. O perfil geográfico é a escolha para workloads com requisitos de residência de dados — escalando entre regiões dentro de uma mesma geografia. O perfil global é indicado quando o objetivo é maximizar a capacidade disponível em todas as regiões comerciais AWS suportadas.
Em ambos os casos, a aplicação interage com um único endpoint e um único ID de perfil, enquanto logs, cotas e faturamento permanecem centralizados na região de origem. Para começar, acesse o console do Amazon Bedrock e envie um prompt de teste para o GPT-5.6 Sol, Terra ou Luna via perfil de inferência. Antes de dimensionar um workload de produção, consulte a página de preços do Amazon Bedrock para as tarifas atuais do GPT-5.6. Para verificar disponibilidade por região, acesse a página de suporte a modelos por região no Amazon Bedrock.
Fonte
Introducing cross-Region inference for OpenAI GPT-5.6 models on Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/introducing-cross-region-inference-for-openai-gpt-5-6-models-on-amazon-bedrock/)
