Inferência de IA generativa chega à Nova Zelândia
A AWS ampliou seus serviços de IA generativa ao anunciar a disponibilidade do Amazon Bedrock na região do Pacífico Asiático, especificamente em Auckland (ap-southeast-6). Essa expansão responde a uma demanda crescente de clientes neozelandeses que buscavam acessar modelos de fundação diretamente de sua região local, sem necessidade de roteamento complexo ou latência adicional.
Com esse lançamento, clientes em Auckland ganham acesso imediato aos modelos Anthropic Claude (incluindo Opus 4.5, Opus 4.6, Sonnet 4.5, Sonnet 4.6 e Haiku 4.5) e aos modelos Amazon Nova 2 Lite. A grande novidade é que essa capacidade agora funciona através de roteamento entre regiões diretamente da Nova Zelândia, eliminando a necessidade de chamadas de API de fora do país.
Como funciona o roteamento entre regiões
O conceito de roteamento entre regiões (cross-region inference) é central para entender como o serviço opera. Trata-se de um recurso do Amazon Bedrock que distribui o processamento de inferência entre múltiplas regiões AWS para alcançar maior throughput em larga escala.
O fluxo de requisições
Quando você invoca um perfil de inferência entre regiões, o Amazon Bedrock roteia sua requisição da região de origem (onde você faz a chamada de API) para uma região de destino (onde o processamento de inferência ocorre). Todo dado transmitido durante essas operações permanece exclusivamente na rede privada AWS, sem passar pela internet pública. Além disso, todos os dados são criptografados em trânsito entre as regiões.
Todas as requisições de inferência entre regiões são registradas no AWS CloudTrail na região de origem. Se você configurar o registro de invocação de modelos, os logs são publicados no Amazon CloudWatch Logs ou Amazon Simple Storage Service (S3), sempre na mesma região.
Dois tipos de perfis de roteamento
A AWS oferece duas abordagens diferentes para roteamento entre regiões:
- Roteamento geográfico (AU): Roteia requisições dentro de um limite geográfico específico. No caso do perfil AU com Auckland como origem, as requisições são roteadas para Auckland, Sydney e Melbourne. Essa abordagem é ideal para organizações com requisitos de residência de dados que precisam manter o processamento de inferência dentro da Austrália e Nova Zelândia.
- Roteamento global: Roteia requisições para todas as regiões AWS comerciais suportadas no mundo, fornecendo o throughput mais alto disponível. Essa opção é apropriada para organizações sem requisitos rigorosos de residência de dados.
A Nova Zelândia como região de origem
Com este lançamento, Auckland torna-se uma nova região de origem para ambos os perfis de roteamento entre regiões: o geográfico AU e o global. Isso significa que você pode fazer chamadas de API do Amazon Bedrock diretamente da região neozelandesa, com as requisições sendo roteadas para as regiões de destino onde os modelos de fundação processam a inferência.
Configuração do roteamento geográfico AU
O perfil AU agora abrange três regiões distribuídas pela Austrália e Nova Zelândia. A estrutura de roteamento funciona da seguinte forma:
- De Auckland (ap-southeast-6): Requisições podem ser roteadas para Auckland, Sydney (ap-southeast-2) e Melbourne (ap-southeast-4)
- De Sydney (ap-southeast-2): Requisições continuam sendo roteadas apenas para Sydney ou Melbourne
- De Melbourne (ap-southeast-4): Requisições continuam sendo roteadas apenas para Sydney ou Melbourne
Um detalhe importante: os perfis de roteamento AU que já existiam para Sydney e Melbourne continuam funcionando apenas entre essas duas cidades. A adição de Auckland não altera os destinos existentes para clientes nessas regiões. No entanto, requisições originando de Auckland têm três regiões de destino disponíveis, permitindo maior distribuição de carga.
Roteamento global a partir da Nova Zelândia
Para organizações sem requisitos rigorosos de residência de dados, o roteamento global oferece acesso à capacidade de inferência em todas as regiões AWS comerciais suportadas. Essa abordagem entrega dois benefícios principais:
- Maior throughput: O roteamento inteligente distribui o tráfego dinamicamente entre todas as regiões suportadas, reduzindo a probabilidade de limitação durante picos de demanda
- Resiliência integrada: Requisições são automaticamente roteadas para regiões com capacidade disponível, ajudando suas aplicações a manter continuidade operacional à medida que padrões de demanda mudam
Modelos suportados e IDs de perfis de inferência
O roteamento entre regiões a partir da Nova Zelândia oferece suporte a modelos de fundação de múltiplos fornecedores. Os modelos Anthropic Claude mais recentes incluem Opus 4.6, Sonnet 4.6, Sonnet 4.5 e Haiku 4.5, disponíveis através tanto do roteamento AU quanto global.
Para usar um perfil de roteamento entre regiões, você substitui o ID do modelo de fundação original adicionando um prefixo geográfico (au.) ou global (global.). Por exemplo, o modelo anthropic.claude-sonnet-4-6 torna-se au.anthropic.claude-sonnet-4-6 ou global.anthropic.claude-sonnet-4-6.
Para obter a lista completa e atualizada de modelos suportados e IDs de perfis de inferência, consulte a documentação sobre Regiões suportadas e modelos para perfis de inferência.
Os perfis de roteamento entre regiões funcionam com as APIs InvokeModel, InvokeModelWithResponseStream, Converse e ConverseStream. A API Converse é especialmente útil pois oferece um formato consistente de requisição e resposta entre diferentes modelos de fundação, facilitando a troca entre modelos sem reescrever código de integração.
Configuração de permissões de acesso
Para invocar modelos de fundação através do roteamento geográfico AU a partir de Auckland, sua política de AWS Identity and Access Management (IAM) precisa de dois elementos:
- Permissão para acessar o perfil de inferência na região de origem
- Permissão para acessar o modelo de fundação em todas as regiões de destino do perfil AU
Aqui está um exemplo de política IAM que concede permissão para invocar o Anthropic Claude Sonnet 4.6 através do roteamento geográfico AU a partir de Auckland:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAuCrisInferenceProfile",
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": "arn:aws:bedrock:ap-southeast-6::inference-profile/au.anthropic.claude-sonnet-4-6"
},
{
"Sid": "AllowFoundationModelViaAuCris",
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": [
"arn:aws:bedrock:ap-southeast-2::foundation-model/anthropic.claude-sonnet-4-6",
"arn:aws:bedrock:ap-southeast-4::foundation-model/anthropic.claude-sonnet-4-6",
"arn:aws:bedrock:ap-southeast-6::foundation-model/anthropic.claude-sonnet-4-6"
],
"Condition": {
"StringLike": {
"bedrock:InferenceProfileArn": "arn:aws:bedrock:ap-southeast-6::inference-profile/au.anthropic.claude-sonnet-4-6"
}
}
}
]
} A primeira declaração permite invocar o perfil de inferência AU a partir da região de origem Auckland. A segunda declaração permite que o modelo de fundação seja invocado nas três regiões de destino, mas apenas quando a requisição é roteada através do perfil de inferência AU. Isso segue o princípio do menor privilégio, impedindo invocação direta do modelo nessas regiões.
O mesmo padrão de duas declarações aplica-se a qualquer modelo no perfil de roteamento AU. Simplesmente substitua o ID do modelo nos ARNs de recurso. Para políticas IAM de roteamento global e padrões avançados de segurança, consulte a documentação sobre Segurança do roteamento entre regiões do Amazon Bedrock.
Segurança e conformidade
O roteamento entre regiões é projetado com segurança como núcleo central. Todas as requisições viajam exclusivamente pela Rede Global AWS com criptografia ponta a ponta, e seus dados em repouso permanecem na região de origem.
Considerações com Service Control Policies
Para organizações que usam Service Control Policies (SCP) para restringir acesso a regiões AWS específicas, há pontos importantes a considerar ao chamar a partir de Auckland (ap-southeast-6):
- O roteamento geográfico AU requer que você permita ap-southeast-2, ap-southeast-4 e ap-southeast-6 para ações do Amazon Bedrock em suas SCPs, pois o perfil AU de Auckland roteia para todas as três regiões ANZ
- O roteamento global requer adicionalmente que você permita um valor de região não especificado para ações do Amazon Bedrock, já que regiões de destino são determinadas dinamicamente
A seguir, um exemplo de SCP que restringe serviços à região Auckland, com exceções para Amazon Bedrock e serviços globais como IAM:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyNonBedrockServicesOutsideAuckland",
"Effect": "Deny",
"NotAction": [
"bedrock:*",
"iam:*",
"organizations:*",
"support:*"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": ["ap-southeast-6"]
}
}
},
{
"Sid": "DenyBedrockOutsideANZRegions",
"Effect": "Deny",
"Action": "bedrock:*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [
"ap-southeast-2",
"ap-southeast-4",
"ap-southeast-6"
]
}
}
},
{
"Sid": "DenyDirectBedrockInDestinationRegions",
"Effect": "Deny",
"Action": "bedrock:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": [
"ap-southeast-2",
"ap-southeast-4"
]
},
"Null": {
"bedrock:InferenceProfileArn": "true"
}
}
}
]
}Nessa política de exemplo: a primeira declaração restringe todos os serviços à região Auckland, exceto Amazon Bedrock e serviços globais como IAM, AWS Organizations e AWS Support. A segunda declaração restringe Amazon Bedrock às três regiões ANZ, necessária para que o roteamento AU rotear requisições de Auckland para Sydney e Melbourne. A terceira utiliza a condição Null em bedrock:InferenceProfileArn para negar qualquer requisição do Amazon Bedrock em Sydney ou Melbourne que não seja roteada através de um perfil de roteamento entre regiões.
Auditoria e monitoramento
AWS CloudTrail registra todas as chamadas de inferência entre regiões na região de origem. O campo additionalEventData.inferenceRegion registra onde cada requisição foi processada, permitindo que você audite exatamente onde a inferência ocorreu.
Para monitoramento operacional em tempo real, Amazon CloudWatch fornece métricas para requisições de inferência entre regiões em sua região de origem. As métricas principais incluem:
- InvocationCount: Número total de requisições de inferência
- InvocationLatency: Tempo de resposta ponta a ponta incluindo roteamento entre regiões
- InvocationClientErrors: Requisições falhadas, incluindo limitação (picos indicam que você está se aproximando dos limites de quota)
- InputTokenCount e OutputTokenCount: Consumo de tokens para rastreamento de quota
Gerenciamento de quotas
As quotas de serviço do Amazon Bedrock são gerenciadas no nível da região de origem. Aumentos de quota solicitados a partir da região Auckland (ap-southeast-6) aplicam-se apenas a requisições originando de Auckland.
As quotas são medidas em duas dimensões:
- Tokens por minuto (TPM): Número máximo de tokens (entrada + saída) processados por minuto
- Requisições por minuto (RPM): Número máximo de requisições de inferência por minuto
Ao calcular sua quota necessária, leve em conta a taxa de consumo de tokens. Para Anthropic Claude Opus 4.6, Sonnet 4.6 e Sonnet 4.5, tokens de saída consomem cinco vezes mais quota que tokens de entrada (taxa 5:1). Para Claude Haiku 4.5 e modelos Amazon Nova, a taxa é 1:1.
A fórmula de consumo de quota é: Consumo de quota = Tokens de entrada + Tokens de cache de escrita + (Tokens de saída × Taxa de consumo)
Para solicitar aumentos de quota, navegue até o console de Quotas de Serviço AWS em sua região de origem, selecione Amazon Bedrock e procure pela quota de roteamento entre regiões relevante para seu modelo.
Primeiros passos
Para começar a usar roteamento entre regiões a partir da Nova Zelândia, siga estes passos:
- Entre no console do Amazon Bedrock na região Auckland (ap-southeast-6)
- Configure permissões de IAM e SCP usando os exemplos de política fornecidos
- Faça sua primeira chamada de API usando o ID de perfil de inferência au.
- Solicite aumentos de quota através do console de Quotas de Serviço com base em sua carga de trabalho esperada
Conclusão
A expansão do Amazon Bedrock para Auckland representa um marco importante na disponibilidade de IA generativa no Pacífico Asiático. Os pontos principais dessa novidade são:
- Auckland torna-se agora uma região de origem para roteamento entre regiões, permitindo que clientes neozelandeses façam chamadas de API do Amazon Bedrock localmente
- O roteamento geográfico AU mantém dados dentro da zona ANZ, com requisições de Auckland roteadas para três destinos (Auckland, Sydney e Melbourne)
- O roteamento global expande o acesso a modelos, oferecendo o throughput mais alto disponível ao rotear requisições para regiões AWS comerciais em todo o mundo
- As configurações de roteamento existentes para Sydney e Melbourne permanecem inalteradas, garantindo continuidade para clientes australianos
Para mais informações, consulte documentação do Amazon Bedrock, o Guia do Usuário de Roteamento Entre Regiões, Regiões suportadas e modelos para perfis de inferência e Segurança do roteamento entre regiões do Amazon Bedrock.
Fonte
Run Generative AI inference with Amazon Bedrock in Asia Pacific (New Zealand) (https://aws.amazon.com/blogs/machine-learning/run-generative-ai-inference-with-amazon-bedrock-in-asia-pacific-new-zealand/)
Leave a Reply