Category: Uncategorized

O Futuro da IA em Tempo Real: Comunicação Bidirecional Contínua

Em 2025, a inteligência artificial generativa transcendeu a simples geração de texto. As aplicações modernas demandam muito mais do que respostas transacionais isoladas. Elas exigem capacidades multimodais abrangentes — desde transcrição e tradução de áudio até agentes de voz sofisticados — e, sobretudo, necessitam de comunicação contínua e fluida em tempo real.

O diferencial está em um requisito essencial: os dados precisam fluir simultaneamente em ambas as direções, através de uma única conexão persistente. Imagine um cenário de conversão de fala para texto onde o áudio é transmitido de forma contínua enquanto, ao mesmo tempo, o modelo processa e retorna a transcrição em tempo real, palavra por palavra. Esses casos de uso demandam exatamente essa capacidade bidirecional.

A AWS anunciou a transmissão bidirecional para Amazon SageMaker AI Inference, transformando fundamentalmente o paradigma de inferência — de uma troca transacional isolada para uma conversa contínua e natural. A experiência de fala flui naturalmente quando não há interrupções. Com transmissão bidirecional, a conversão de fala para texto torna-se imediata: o modelo escuta e transcreve simultaneamente, fazendo as palavras aparecerem no exato momento em que são pronunciadas.

Considere o caso prático de um centro de atendimento ao cliente. Conforme o cliente descreve seu problema, a transcrição ao vivo aparece instantaneamente na tela do atendente, fornecendo contexto imediato e permitindo que ele responda sem esperar o cliente terminar de falar. Esse tipo de troca contínua torna as experiências de voz mais fluidas, responsivas e genuinamente humanas.

Como Funciona a Transmissão Bidirecional

O Paradigma Tradicional versus Bidirecional

Na abordagem tradicional de requisições de inferência, existe um padrão bem definido: o cliente envia uma pergunta completa e aguarda, enquanto o modelo processa e retorna uma resposta completa antes que o cliente possa enviar a próxima pergunta. É um ciclo de espera e resposta.

Com transmissão bidirecional, esse fluxo é radicalmente diferente. A pergunta começa a fluir do cliente enquanto o modelo simultaneamente inicia o processamento e começa a retornar a resposta imediatamente. O cliente pode continuar refinando sua entrada enquanto o modelo adapta sua resposta em tempo real. Os resultados aparecem assim que o modelo os gera — palavra por palavra para texto, frame por frame para vídeo, amostra por amostra para áudio.

Esse padrão também oferece benefícios infraestruturais significativos: manter uma única conexão persistente elimina a necessidade de centenas de conexões de curta duração. Isso reduz consideravelmente a sobrecarga de gerenciamento de rede, handshakes TLS e administração de conexões. Além disso, os modelos conseguem manter contexto ao longo de um fluxo contínuo, possibilitando interações multi-turnos sem a necessidade de reenviar o histórico de conversa a cada requisição.

Arquitetura de Três Camadas do SageMaker AI Inference

A implementação técnica da transmissão bidirecional no SageMaker AI Inference combina dois protocolos complementares: HTTP/2 e WebSocket, criando um canal robusto de comunicação bidirecional em tempo real entre cliente e modelo. O fluxo ocorre em três camadas:

Cliente para Roteador SageMaker AI: Sua aplicação se conecta ao endpoint de tempo de execução do Amazon SageMaker AI usando HTTP/2, estabelecendo uma conexão eficiente e multiplexada que suporta transmissão bidirecional.

Roteador para Contêiner do Modelo: O roteador encaminha a requisição para um Sidecar — um proxy leve executando ao lado de seu contêiner de modelo — que estabelece uma conexão WebSocket com o contêiner em ws://localhost:8080/invocations-bidirectional-stream. Uma vez estabelecida, os dados fluem livremente em ambas as direções.

Fluxo de Requisição e Resposta: Sua aplicação envia entrada como uma série de blocos de dados via HTTP/2. A infraestrutura do SageMaker AI converte esses blocos em frames de dados WebSocket — texto (para dados UTF-8) ou binário — e os encaminha ao contêiner. O modelo recebe esses frames em tempo real e começa a processar imediatamente, antes mesmo da chegada da entrada completa. Na direção oposta, o modelo gera saída e a envia como frames WebSocket. O SageMaker AI encapsula cada frame em um payload de resposta e o transmite diretamente à sua aplicação via HTTP/2.

A conexão WebSocket entre o Sidecar e o contêiner permanece aberta pela duração da sessão, com monitoramento de saúde integrado. Para manter a integridade da conexão, o SageMaker AI envia frames de ping a cada 60 segundos para verificar se a conexão está ativa. Seu contêiner responde com pong frames para confirmar que está saudável. Se 5 pings consecutivos não receberem resposta, a conexão é fechada de forma controlada.

Construindo seu Próprio Contêiner com Transmissão Bidirecional

Pré-requisitos e Preparação

Se você deseja utilizar modelos de código aberto ou seus próprios modelos, é possível customizar seu contêiner para suportar transmissão bidirecional. Seu contêiner deve implementar o protocolo WebSocket para lidar com frames de dados recebidos e enviar frames de resposta de volta ao SageMaker AI.

Para começar, você precisará de:

• Uma conta AWS com permissões no SageMaker AI
• A política de acesso gerenciado AmazonSageMakerFullAccess IAM Managed Policy para permitir criação de endpoints
• Permissões de IAM que permitam explicitamente a ação sagemaker:InvokeEndpoint* para invocação de endpoints
• Docker instalado localmente
• Python 3.12 ou superior
• Instalar aws-sdk-python para a API InvokeEndpointWithBidirectionalStream do tempo de execução do SageMaker AI

Construindo e Implantando o Contêiner

O processo começa clonando o repositório de demonstração e configurando seu ambiente conforme definido no README.md. Os passos a seguir criarão uma imagem Docker simples de demonstração e a enviarão para seu repositório de ECR na AWS.

# As variáveis de ambiente devem ser definidas para autenticação AWS
# export AWS_ACCESS_KEY_ID="sua-chave-de-acesso"
# export AWS_SECRET_ACCESS_KEY="sua-chave-secreta"
# export AWS_DEFAULT_REGION="us-west-2"

container_name="sagemaker-bidirectional-streaming"
container_tag="latest"
cd container
account=$(aws sts get-caller-identity --query Account --output text)
region=$(aws configure get region)
region=${region:-us-west-2}
container_image_uri="${account}.dkr.ecr.${region}.amazonaws.com/${container_name}:${container_tag}"

# Se o repositório não existe no ECR, crie-o
aws ecr describe-repositories --repository-names "${container_name}" --region "${region}" > /dev/null 2>&1
if [ $? -ne 0 ]
then
  aws ecr create-repository --repository-name "${container_name}" --region "${region}" > /dev/null
fi

# Obtenha o comando de login do ECR e execute-o
aws ecr get-login-password --region ${region} | docker login --username AWS --password-stdin ${account}.dkr.ecr.${region}.amazonaws.com/${container_name}

# Construa a imagem Docker localmente e envie-a para o ECR
docker build --platform linux/amd64 --provenance=false -t ${container_name} .
docker tag ${container_name} ${container_image_uri}
docker push ${container_image_uri}

Este processo cria um contêiner com um rótulo Docker indicando ao SageMaker AI que o suporte a transmissão bidirecional está habilitado: com.amazonaws.sagemaker.capabilities.bidirectional-streaming=true.

Após criar a imagem, você pode implantar o contêiner em um endpoint do SageMaker AI através de um script Python que cria o modelo, a configuração do endpoint e finalmente o endpoint propriamente dito.

Invocando o Endpoint com a Nova API

Uma vez que o endpoint do SageMaker AI esteja em estado InService, você pode proceder à invocação do endpoint para testar a funcionalidade de transmissão bidirecional. O cliente Python conecta-se ao endpoint do SageMaker AI e envia dados em chunks, recebendo respostas simultâneas.

#!/usr/bin/env python3
"""
Script Python para Transmissão Bidirecional no SageMaker AI.
Conecta-se a um endpoint do SageMaker AI para comunicação bidirecional.
"""

import argparse
import asyncio
import sys
from aws_sdk_sagemaker_runtime_http2.client import SageMakerRuntimeHTTP2Client
from aws_sdk_sagemaker_runtime_http2.config import Config, HTTPAuthSchemeResolver
from aws_sdk_sagemaker_runtime_http2.models import InvokeEndpointWithBidirectionalStreamInput, RequestStreamEventPayloadPart, RequestPayloadPart
from smithy_aws_core.identity import EnvironmentCredentialsResolver
from smithy_aws_core.auth.sigv4 import SigV4AuthScheme
import logging

def parse_arguments():
    """Analisa argumentos da linha de comando."""
    parser = argparse.ArgumentParser(
        description="Conecta-se a um endpoint do SageMaker AI para transmissão bidirecional"
    )
    parser.add_argument(
        "ENDPOINT_NAME",
        help="Nome do endpoint do SageMaker AI para conectar"
    )
    return parser.parse_args()

AWS_REGION = "us-west-2"
BIDI_ENDPOINT = f"https://runtime.sagemaker.{AWS_REGION}.amazonaws.com:8443"
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

class SimpleClient:
    def __init__(self, endpoint_name, region=AWS_REGION):
        self.endpoint_name = endpoint_name
        self.region = region
        self.client = None
        self.stream = None
        self.response = None
        self.is_active = False

    def _initialize_client(self):
        config = Config(
            endpoint_uri=BIDI_ENDPOINT,
            region=self.region,
            aws_credentials_identity_resolver=EnvironmentCredentialsResolver(),
            auth_scheme_resolver=HTTPAuthSchemeResolver(),
            auth_schemes={"aws.auth#sigv4": SigV4AuthScheme(service="sagemaker")}
        )
        self.client = SageMakerRuntimeHTTP2Client(config=config)

    async def start_session(self):
        if not self.client:
            self._initialize_client()
        logger.info(f"Iniciando sessão com endpoint: {self.endpoint_name}")
        self.stream = await self.client.invoke_endpoint_with_bidirectional_stream(
            InvokeEndpointWithBidirectionalStreamInput(endpoint_name=self.endpoint_name)
        )
        self.is_active = True
        self.response = asyncio.create_task(self._process_responses())

    async def send_words(self, words):
        for i, word in enumerate(words):
            logger.info(f"Enviando payload: {word}")
            await self.send_event(word.encode('utf-8'))
            await asyncio.sleep(1)

    async def send_event(self, data_bytes):
        payload = RequestPayloadPart(bytes_=data_bytes)
        event = RequestStreamEventPayloadPart(value=payload)
        await self.stream.input_stream.send(event)

    async def end_session(self):
        if not self.is_active:
            return
        await self.stream.input_stream.close()
        logger.info("Stream fechado")

    async def _process_responses(self):
        try:
            output = await self.stream.await_output()
            output_stream = output[1]
            while self.is_active:
                result = await output_stream.receive()
                if result is None:
                    logger.info("Sem mais respostas")
                    break
                if result.value and result.value.bytes_:
                    response_data = result.value.bytes_.decode('utf-8')
                    logger.info(f"Recebido: {response_data}")
        except Exception as e:
            logger.error(f"Erro ao processar respostas: {e}")

def main():
    """Função principal para analisar argumentos e executar o cliente de streaming."""
    args = parse_arguments()
    print("=" * 60)
    print("Cliente de Transmissão Bidirecional SageMaker AI")
    print("=" * 60)
    print(f"Nome do Endpoint: {args.ENDPOINT_NAME}")
    print(f"Região AWS: {AWS_REGION}")
    print("=" * 60)

    async def run_client():
        sagemaker_client = SimpleClient(endpoint_name=args.ENDPOINT_NAME)
        try:
            await sagemaker_client.start_session()
            words = ["Preciso de ajuda com", "meu saldo da conta", "Posso ajudar com isso", "e cobranças recentes"]
            await sagemaker_client.send_words(words)
            await asyncio.sleep(2)
            await sagemaker_client.end_session()
            sagemaker_client.is_active = False
            if sagemaker_client.response and not sagemaker_client.response.done():
                sagemaker_client.response.cancel()
            logger.info("Sessão encerrada com sucesso")
            return 0
        except Exception as e:
            logger.error(f"Erro no cliente: {e}")
            return 1

    try:
        exit_code = asyncio.run(run_client())
        sys.exit(exit_code)
    except KeyboardInterrupt:
        logger.info("Interrompido pelo usuário")
        sys.exit(1)
    except Exception as e:
        logger.error(f"Erro inesperado: {e}")
        sys.exit(1)

if __name__ == "__main__":
    main()

Integração com Modelos Deepgram no SageMaker AI

Parceria e Capacidades

A AWS e a Deepgram colaboraram para construir suporte de transmissão bidirecional especificamente para endpoints do SageMaker AI. A Deepgram, parceira de Tier Avançado da AWS, oferece modelos de IA de voz em nível empresarial com precisão e velocidade líderes do setor. Seus modelos alimentam aplicações de transcrição em tempo real, conversão de texto para fala e agentes de voz para contact centers, plataformas de mídia e aplicações de IA conversacional.

Para clientes com requisitos rigorosos de conformidade que exigem que o processamento de áudio nunca saia de sua Nuvem Privada Virtual (VPC) na AWS, as opções tradicionais auto-hospedadas demandavam sobrecarga operacional considerável para configuração e manutenção. A transmissão bidirecional do Amazon SageMaker transforma completamente essa experiência, permitindo que os clientes implantem e escalem aplicações de IA em tempo real com apenas alguns poucos cliques no Console de Gerenciamento da AWS.

O modelo de fala para texto Deepgram Nova-3 está disponível atualmente no AWS Marketplace para implantação como um endpoint do SageMaker AI, com modelos adicionais chegando em breve. As capacidades incluem transcrição multilíngue, desempenho em escala empresarial e reconhecimento específico de domínio. A Deepgram oferece um período de avaliação gratuita de 14 dias no Amazon SageMaker AI para desenvolvedores prototiparem aplicações sem incorrer em custos de licença de software. As cobranças de infraestrutura do tipo de máquina escolhido ainda serão incorridas durante esse período. Para mais detalhes, consulte a documentação de preços do Amazon SageMaker AI.

Configurando um Endpoint Deepgram no SageMaker AI

Para configurar um endpoint Deepgram no SageMaker AI, navegue até a seção de pacotes de modelos do AWS Marketplace dentro do console do Amazon SageMaker AI e procure por Deepgram. Inscreva-se no produto e proceda ao assistente de lançamento na página do produto. Continue fornecendo detalhes no assistente de criação de endpoint de inferência em tempo real do Amazon SageMaker AI. Certifique-se de editar a variante de produção para incluir um tipo de instância válido ao criar sua configuração de endpoint. O botão de edição pode estar oculto até que você role a direita na tabela de variantes de produção. O ml.g6.2xlarge é um tipo de instância preferido para testes iniciais. Consulte a documentação Deepgram para requisitos específicos de hardware e orientação de seleção. Na página de resumo do endpoint, anote o nome do endpoint que você forneceu, pois será necessário na seção seguinte.

Usando o Endpoint Deepgram no SageMaker AI

Uma aplicação TypeScript de exemplo mostra como transmitir um arquivo de áudio para o modelo Deepgram hospedado em um endpoint de inferência em tempo real do SageMaker AI e imprimir uma transcrição transmitida em tempo real. A função cria um fluxo do arquivo WAV abrindo um arquivo de áudio local e enviando-o para o Amazon SageMaker AI Inference em pequenos blocos binários.

import * as fs from "fs";
import * as path from "path";
import { RequestStreamEvent } from '@aws-sdk/client-sagemaker-runtime-http2';

function sleep(ms: number): Promise {
  return new Promise(resolve => setTimeout(resolve, ms));
}

async function* streamWavFile(filePath: string): AsyncIterable {
  const full = path.resolve(filePath);
  if (!fs.existsSync(full)) {
    throw new Error(`Arquivo de áudio não encontrado: ${full}`);
  }
  console.log(`Transmitindo áudio: ${full}`);
  const readStream = fs.createReadStream(full, { highWaterMark: 512_000 }); // 512 KB
  for await (const chunk of readStream) {
    yield { PayloadPart: { Bytes: chunk, DataType: "BINARY" } };
  }
  // Mantenha o stream ativo para receber respostas de transcrição após todo arquivo ser enviado
  console.log("Áudio enviado, aguardando conclusão da transcrição...");
  await sleep(15000); // Aguarde 15 segundos para processamento do bloco final de áudio
  // Avise ao contêiner que terminamos
  yield { PayloadPart: { Bytes: new TextEncoder().encode('{"type":"CloseStream"}'), DataType: "UTF8" } };
}

O cliente de tempo de execução do AWS SageMaker AI é configurado especificando a região AWS, o nome do endpoint do SageMaker AI e a rota do modelo Deepgram dentro do contêiner. Você precisa atualizar esses valores conforme necessário.

import { SageMakerRuntimeHTTP2Client, InvokeEndpointWithBidirectionalStreamCommand } from '@aws-sdk/client-sagemaker-runtime-http2';

const region = "us-east-1"; // Região AWS
const endpointName = "REPLACEME"; // Nome do seu endpoint Deepgram SageMaker
const audioFile = "test.wav"; // Arquivo de áudio local
const modelInvocationPath = "v1/listen"; // Caminho WebSocket dentro do contêiner do modelo
const modelQueryString = "model=nova-3";
const client = new SageMakerRuntimeHTTP2Client({ region });

O trecho final envia o fluxo de áudio ao endpoint do SageMaker AI e imprime os eventos JSON de transmissão da Deepgram conforme chegam. A aplicação exibe a saída de fala para texto ao vivo sendo gerada.

async function run() {
  console.log("Enviando áudio para Deepgram via SageMaker...");
  const command = new InvokeEndpointWithBidirectionalStreamCommand({
    EndpointName: endpointName,
    Body: streamWavFile(audioFile),
    ModelInvocationPath: modelInvocationPath,
    ModelQueryString: modelQueryString
  });
  const response = await client.send(command);
  if (!response.Body) {
    console.log("Nenhuma resposta de streaming recebida.");
    return;
  }
  const decoder = new TextDecoder();
  for await (const msg of response.Body) {
    if (msg.PayloadPart?.Bytes) {
      const text = decoder.decode(msg.PayloadPart.Bytes);
      try {
        const parsed = JSON.parse(text);
        // Extraia e exiba a transcrição
        if (parsed.channel?.alternatives?.[0]?.transcript) {
          const transcript = parsed.channel.alternatives[0].transcript;
          if (transcript.trim()) {
            console.log("Transcrição:", transcript);
          }
        }
        console.debug("Deepgram (bruto):", parsed);
      } catch {
        console.error("Deepgram (erro):", text);
      }
    }
  }
}
console.log("Streaming concluído.");
}
run().catch(console.error);

Para informações mais detalhadas e exemplos adicionais, consulte a página de documentação Deepgram. Se precisar de suporte adicional com a configuração, conecte-se com a Comunidade de Desenvolvedores Deepgram.

Conclusão

A transmissão bidirecional no Amazon SageMaker AI Inference representa um avanço significativo na forma como os desenvolvedores podem construir aplicações de IA em tempo real. Ao eliminar as limitações das interações transacionais tradicionais, essa capacidade abre possibilidades para experiências de usuário genuinamente conversacionais e responsivas.

Com suporte para contêineres customizados e integração pronta com modelos parceiros como o Deepgram, a plataforma oferece flexibilidade tanto para quem deseja trazer seus próprios modelos quanto para quem busca soluções prontas para produção. A infraestrutura de três camadas garante eficiência, enquanto o monitoramento automático de conexão assegura confiabilidade.

Developers podem começar a construir aplicações de transmissão bidirecional com Modelos de Linguagem Grande (LLMs) e SageMaker AI hoje mesmo, abrindo novos horizontes para agentes de voz, assistentes conversacionais e qualquer aplicação que se beneficie de comunicação em tempo real verdadeiramente bidirecional.

Fonte

Introducing bidirectional streaming for real-time inference on Amazon SageMaker AI (https://aws.amazon.com/blogs/machine-learning/introducing-bidirectional-streaming-for-real-time-inference-on-amazon-sagemaker-ai/)

Nova camada de proteção contra ameaças de rede

A AWS anunciou o lançamento do Network Firewall Proxy em prévia pública, um novo recurso que reforça significativamente a postura defensiva das organizações contra ameaças de exfiltração de dados e injeção de malware. O serviço foi projetado para funcionar em modo explícito, permitindo que seja configurado em apenas alguns cliques.

O destaque principal do Network Firewall Proxy é sua capacidade de gerenciar e proteger o tráfego de dados que sai das aplicações, bem como as respostas que essas aplicações recebem. Isso oferece um controle muito mais preciso sobre as comunicações de rede que atravessam a infraestrutura corporativa.

Capacidades e controles granulares

Proteção contra spoofing e acesso não autorizado

O Network Firewall Proxy da AWS protege as organizações contra tentativas de falsificação de nomes de domínio ou do índice de nome do servidor (SNI — Server Name Index). Além disso, oferece flexibilidade para implementar controles de acesso muito específicos e adaptados às necessidades de cada ambiente.

Um dos casos de uso mais importantes é a restrição de acesso das aplicações apenas para domínios ou endereços IP confiáveis. O recurso também permite bloquear respostas não intencionais provenientes de servidores externos, criando uma barreira efetiva contra comunicações não autorizadas.

Inspeção de TLS e filtragem avançada

O serviço permite ativar a inspeção de TLS (Transport Layer Security) e estabelecer controles granulares de filtragem baseados em atributos de cabeçalho HTTP. Isso significa que é possível examinar e controlar comunicações mesmo quando criptografadas, ampliando as possibilidades de proteção sem sacrificar a privacidade.

Monitoramento e análise detalhada

O Network Firewall Proxy oferece registros abrangentes para monitoramento contínuo das aplicações. Esses logs podem ser direcionados para o Amazon S3 (Simple Storage Service) e o AWS CloudWatch, permitindo análises detalhadas e facilitando processos de auditoria. Essa rastreabilidade é especialmente importante para organizações que precisam atender requisitos regulatórios rigorosos.

Disponibilidade e próximos passos

O Network Firewall Proxy está disponível em prévia pública na região US East (Ohio) e, durante este período, é oferecido gratuitamente. Organizações interessadas são convidadas a testar o recurso em ambientes de teste para avaliar seu impacto nas estratégias de segurança de rede.

Para maiores detalhes sobre implementação e funcionalidades técnicas, consulte a documentação técnica do AWS Network Firewall Proxy.

Fonte

Introducing AWS Network Firewall Proxy in preview (https://aws.amazon.com/about-aws/whats-new/2025/11/aws-network-firewall-proxy-preview)

Desafios no gerenciamento de credenciais de terceiros

Embora o AWS Secrets Manager se destaque no gerenciamento do ciclo de vida de segredos dos serviços de Amazon Web Services (AWS), o armazenamento de credenciais de provedores de software terceirizados apresenta desafios singulares para organizações que expandem o uso de aplicações em nuvem.

Organizações que utilizam múltiplos serviços de terceiros frequentemente desenvolvem abordagens de segurança distintas para cada provedor, pois não existia uma forma padronizada de gerenciar essas credenciais. Ao armazenar credenciais de terceiros no Secrets Manager, as organizações precisam manter metadados adicionais dentro dos valores dos segredos para facilitar as conexões com os serviços. Essa abordagem exige atualização completa dos valores dos segredos sempre que os metadados mudam, além da implementação de processos de rotação específicos para cada provedor que são manuais e demorados.

Organizações que buscam automatizar a rotação de segredos frequentemente precisam desenvolver funções personalizadas adaptadas a cada provedor de software terceirizado, exigindo conhecimento especializado tanto dos sistemas terceirizados quanto dos sistemas AWS.

Introdução aos segredos externos gerenciados

Para ajudar os clientes a simplificar o gerenciamento de segredos de terceiros, a AWS introduz uma nova funcionalidade no AWS Secrets Manager chamada segredos externos gerenciados. Este novo tipo de segredo estende a experiência contínua do gerenciamento de rotação para aplicações de software terceirizadas como Salesforce, simplificando os desafios de gerenciamento de segredos por meio de formatos padronizados e rotação automática.

A AWS Secrets Manager já possuía um histórico comprovado de ajudar clientes a proteger e gerenciar segredos de serviços AWS como Amazon Relational Database Service (Amazon RDS) ou Amazon DocumentDB por meio de capacidades de rotação gerenciada. Construindo sobre esse sucesso, a funcionalidade de segredos externos gerenciados permite que os clientes armazenem segredos fornecidos por provedores de software terceirizados em formatos predefinidos.

Características principais

Esses formatos foram desenvolvidos em colaboração com parceiros de integração confiáveis para definir tanto a estrutura do segredo quanto os metadados necessários para rotação, eliminando a necessidade de definir estratégias de armazenamento personalizadas. A funcionalidade oferece integração automática com provedores de software, reduzindo a sobrecarga operacional enquanto beneficia de controles de segurança essenciais, incluindo:

• Gerenciamento de permissões granulares usando AWS Identity and Access Management (IAM)
• Monitoramento de acesso a segredos através do Amazon CloudWatch e AWS CloudTrail
• Detecção automática de ameaças específicas de segredos por meio do Amazon GuardDuty

Além disso, os clientes podem implementar práticas centralizadas e consistentes de gerenciamento de segredos tanto para segredos AWS quanto de terceiros a partir de um único serviço, eliminando a necessidade de operar múltiplas soluções de gerenciamento de segredos em suas organizações.

Os segredos externos gerenciados seguem o padrão de precificação do Secrets Manager, sem custos adicionais pelo uso deste novo tipo de segredo.

Pré-requisitos

Para criar um segredo externo gerenciado, você precisa de:

• Uma conta AWS ativa com acesso apropriado ao Secrets Manager
• Permissões suficientes para criar e gerenciar segredos, incluindo acesso ao AWS Management Console ou acesso programático através da AWS Command Line Interface (AWS CLI) ou AWS SDKs
• Permissões mínimas do Identidade e Acesso da AWS (IAM) para as ações: secretsmanager:DescribeSecret, secretsmanager:GetSecretValue, secretsmanager:UpdateSecret, e secretsmanager:UpdateSecretVersionStage
• Credenciais válidas e permissões de acesso necessárias para o provedor de software terceirizado
• Para criptografia de segredos, você deve decidir entre usar uma chave AWS managed ou customer managed do AWS Key Management Service (AWS KMS)
• Para chaves gerenciadas pelo cliente, você deve ter as políticas de chave necessárias configuradas, permitindo que o Secrets Manager use a chave para operações de criptografia e descriptografia

Criando um segredo externo gerenciado

Atualmente, os segredos externos gerenciados suportam três parceiros de integração: Salesforce, Snowflake e BigID. A AWS continua expandindo sua lista de parceiros e mais provedores de software terceirizados serão adicionados ao longo do tempo. Consulte a página de Parceiros de Integração para obter a lista mais recente.

Selecionando o tipo de segredo

Acesse o serviço AWS Secrets Manager no console e selecione “Armazenar um novo segredo”. Na seção de tipo de segredo, escolha “Segredo externo gerenciado”. Na seção de credencial de provedor terceirizado integrado, selecione seu provedor nas opções disponíveis.

Para este exemplo, usaremos as Credenciais de Aplicativo Cliente Externo do Salesforce. Insira suas configurações na seção de detalhes do segredo. As credenciais incluem vários componentes-chave:

• Chave do consumidor (ID do cliente): Serve como identificador de credencial para OAuth 2.0. Você pode recuperá-la diretamente do gerenciador de aplicativos cliente externo Salesforce nas configurações OAuth
• Segredo do consumidor (segredo do cliente): Funciona como senha privada para autenticação OAuth 2.0, recuperável nas mesmas configurações OAuth
• Base URI: A URL base da sua organização Salesforce (formatada como https://MyDomainName.my.salesforce.com), usada para interagir com as APIs Salesforce
• ID da aplicação: Identifica suas Aplicações de Cliente Externo Salesforce (ECAs) e pode ser recuperado chamando o endpoint de uso OAuth Salesforce
• ID do consumidor: Identifica sua ECA Salesforce e pode ser recuperado chamando o endpoint de credenciais OAuth Salesforce por ID da aplicação

Para uma lista completa de comandos, consulte a documentação Salesforce sobre Como Fazer Stage, Girar e Deletar Credenciais OAuth para um Aplicativo de Cliente Externo.

Configurando o segredo

Selecione a chave de criptografia no menu suspenso. Você pode usar uma chave AWS KMS gerenciada ou uma chave AWS KMS gerenciada pelo cliente. Prossiga para a próxima etapa.

Forneça um nome descritivo e, opcionalmente, uma descrição detalhada que ajude a identificar o propósito e uso do segredo. Você também tem opções de configuração adicionais: pode anexar tags para melhor organização de recursos, definir permissões específicas de recurso para controlar o acesso e selecionar a opção de replicar segredo para resiliência em múltiplas regiões.

Configurando rotação e permissões (opcional)

Na etapa opcional de configuração de rotação, o novo tipo de segredo introduz duas seções principais focadas no gerenciamento de metadados, que são armazenados separadamente do valor do segredo propriamente dito.

Sob metadados de rotação, especifique a versão da API que seu aplicativo Salesforce está usando. A versão mínima necessária é v65.0. Você pode encontrar a versão consultando a documentação Salesforce para Listar Versões Disponíveis da API REST.

Selecione um ARN de segredo do administrador, que contém as credenciais OAuth administrativas usadas para girar o segredo do cliente Salesforce. Na seção de permissões de serviço para rotação de segredo, o Secrets Manager cria automaticamente uma função com permissões necessárias para girar seus valores de segredo. Essas permissões padrão são exibidas transparentemente na interface para revisão. Você pode desmarcar as permissões padrão para ter mais controle granular sobre o gerenciamento de rotação de segredo.

Revisando e confirmando

Na etapa final, você receberá um resumo da configuração de seu segredo. Na página de revisão, você pode verificar os parâmetros antes de prosseguir com a criação do segredo. Após confirmar que as configurações estão corretas, selecione “Armazenar” para concluir o processo e criar seu segredo com as configurações especificadas.

Após a criação bem-sucedida, seu segredo aparecerá na aba de segredos. Você pode visualizar, gerenciar e monitorar aspectos do seu segredo, incluindo sua configuração, status de rotação e permissões. Após a criação, revise sua configuração de segredo, incluindo configurações de criptografia e políticas de recursos para acesso entre contas, e examine o código de amostra fornecido para diferentes SDKs AWS para integrar a recuperação de segredo em suas aplicações.

A aba de segredos fornece uma visão geral de seus segredos, permitindo gerenciamento centralizado. Selecione seu segredo para visualizar os detalhes do segredo. Seu segredo externo gerenciado foi criado com sucesso no Secrets Manager. Você pode acessar e gerenciar este segredo através do console do Secrets Manager ou programaticamente usando as APIs AWS.

Para parceiros terceirizados: Integrando com o Secrets Manager

Com o novo tipo de segredo externo gerenciado, provedores de software terceirizados podem se integrar ao Secrets Manager e oferecer aos seus clientes uma forma programática de gerenciar com segurança os segredos fornecidos pelas suas aplicações na AWS. Essa integração fornece aos clientes uma solução centralizada para gerenciar tanto o ciclo de vida de segredos AWS quanto de terceiros, incluindo capacidades de rotação automática a partir do momento da criação do segredo.

Provedores de software como Salesforce já estão usando essa capacidade. Não há custos adicionais para integração como parceiro do Secrets Manager. Para começar, os parceiros devem seguir o processo listado no guia de integração de parceiros. Se você tiver dúvidas sobre se tornar um parceiro de integração, entre em contato com a equipe através do aws-secrets-mgr-partner-onboarding@amazon.com com o assunto: [Nome do Parceiro] Solicitação de Integração.

Conclusão

Os segredos externos gerenciados representam um avanço significativo na forma como as organizações podem gerenciar credenciais de provedores terceirizados. Ao eliminar a necessidade de definir estratégias de armazenamento personalizadas e desenvolver funções de rotação complexas, os clientes agora podem gerenciar consistentemente seus segredos, independentemente de serem de serviços AWS, aplicações personalizadas ou provedores terceirizados, a partir de um único serviço.

A funcionalidade oferece os mesmos recursos de segurança que os segredos padrão do Secrets Manager, incluindo gerenciamento de permissões granulares, observabilidade e controles de conformidade, enquanto adiciona integração integrada com parceiros confiáveis sem custos adicionais. O recurso está disponível em todas as regiões AWS onde o AWS Secrets Manager está disponível.

Para começar, consulte a documentação técnica. Para informações sobre migração de seus segredos de parceiros existentes para segredos externos gerenciados, consulte Migrando segredos existentes. Para uma lista de regiões onde o Secrets Manager está disponível, consulte a tabela de regiões AWS.

Se você tiver dúvidas sobre este artigo, inicie uma nova discussão no Secrets Manager re:Post ou entre em contato com o Suporte AWS.

Fonte

AWS Secrets Manager launches Managed External Secrets for Third-Party Credentials (https://aws.amazon.com/blogs/security/aws-secrets-manager-launches-managed-external-secrets-for-third-party-credentials/)

Gerenciamento simplificado de permissões em múltiplos warehouses

A AWS anunciou o suporte a permissões federadas no Amazon Redshift, uma funcionalidade importante para organizações que adotam arquiteturas multi-warehouse. Muitos clientes estão migrando para modelos baseados em múltiplos data warehouses justamente para escalar suas operações e isolar diferentes cargas de trabalho, mas enfrentavam o desafio de manter a governança de acesso consistente entre essas instâncias.

Com as permissões federadas, os administradores definem as políticas de acesso uma única vez, a partir de qualquer warehouse Redshift, e elas são aplicadas automaticamente em todos os warehouses da conta. Isso elimina a necessidade de replicar configurações de permissão manualmente, reduzindo erros e facilitando manutenção.

Funcionalidades principais

Aplicação automática de controles de acesso

Os warehouses Redshift com permissões federadas são montados automaticamente em cada instância Redshift disponível. Essa integração permite que você aproveite identidades do seu workforce já cadastradas no AWS IAM Identity Center (Centro de Identidade AWS) ou use papéis (IAM roles) existentes para consultar dados entre warehouses.

O controle de acesso funciona em múltiplos níveis: é possível aplicar restrições no nível de linha, no nível de coluna e implementar mascaramento de dados. Independentemente de qual warehouse seja utilizado para fazer a consulta, esses controles permanecem sempre ativos, garantindo conformidade de forma granular e consistente.

Escalabilidade sem complexidade adicional

Um dos benefícios mais relevantes das permissões federadas é a escalabilidade horizontal. Ao adicionar novos warehouses ao ambiente, as políticas de permissão são aplicadas automaticamente, sem que a complexidade de governança aumente proporcionalmente. Analistas e usuários finais já conseguem visualizar imediatamente todos os bancos de dados disponibilizados pelos warehouses registrados, sem necessidade de configurações manuais adicionais.

Como começar

Para iniciar o uso dessa funcionalidade, o primeiro passo é registrar um namespace Redshift Serverless ou um cluster Redshift provisionado com o AWS Glue Data Catalog. Feito isso, é possível começar a realizar consultas entre warehouses usando o Redshift Query Editor V2 ou qualquer cliente SQL compatível.

Disponibilidade e custos

As permissões federadas do Amazon Redshift estão disponíveis sem custo adicional nas regiões suportadas da AWS. Para obter mais detalhes técnicos e explorar as configurações disponíveis, você pode consultar a documentação completa do Amazon Redshift ou verificar as considerações específicas sobre regiões suportadas.

Fonte

Amazon Redshift now supports federated permissions across multi-warehouse architectures (https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-redshift-federated-permissions-multi-warehouse-architectures)

Ambientes de desenvolvimento gerenciados para ciência de dados

A Amazon SageMaker HyperPod com orquestração via Amazon Elastic Kubernetes Service (EKS) agora oferece suporte à criação e gerenciamento de ambientes de desenvolvimento interativos, incluindo JupyterLab e Visual Studio Code de código aberto. Essa integração simplifica o ciclo de vida do desenvolvimento de aprendizado de máquina, fornecendo ambientes gerenciados que trabalham com as ferramentas que os cientistas de dados já conhecem e utilizam.

A novidade central é um novo complemento chamado Amazon SageMaker Spaces, que permite aos desenvolvedores de IA criar e gerenciar ambientes isolados e configuráveis para execução de notebooks e desenvolvimento interativo. A integração permite que as organizações otimizem seus investimentos em GPU ao executar simultaneamente cargas de trabalho interativas e jobs de treinamento na mesma infraestrutura, com suporte para alocações fracionadas de GPU. Isso reduz significativamente a complexidade de gerenciar múltiplos ambientes de desenvolvimento, permitindo que as equipes se concentrem na construção e implantação de modelos de IA e aprendizado de máquina.

Como funcionam os Spaces

Os Spaces operam através de uma arquitetura coordenada entre diferentes componentes. O processo começa quando um administrador de cluster instala o complemento Spaces a partir do console do SageMaker AI, escolhendo entre uma instalação rápida ou uma instalação personalizada.

Uma vez que o cluster está configurado, cientistas de dados e desenvolvedores de IA podem criar Spaces utilizando a Interface de Linha de Comando (CLI) do HyperPod ou kubectl. Após a criação de um Space, os usuários podem se conectar através de duas abordagens principais:

• Acesso via Interface Web: Esta opção requer configuração de um Balanceador de Carga de Aplicação (ALB) da AWS e registro de um domínio personalizado no Amazon Route 53. Com um domínio configurado, os usuários acessam de forma segura JupyterLab ou Code Editor através do navegador usando uma URL pré-assinada.
• Conexão de IDE Remota: Para usuários que preferem trabalhar localmente no Visual Studio Code, a conexão utiliza túneis SSH-over-SSM (Sessions Manager), permitindo acesso seguro aos pods do SageMaker Spaces sem necessidade de gerenciar chaves SSH ou expor portas diretamente.

Pré-requisitos e preparação

Para implementar essa solução, você precisa de uma conta AWS com permissões adequadas para criar funções de Identidade e Acesso (IAM), recursos do SageMaker como HyperPod, e acesso aos recursos de cluster do EKS. Se estiver criando um novo cluster HyperPod, você também necessitará permissões para criar recursos de rede e armazenamento (consulte a documentação sobre permissões de IAM para criação de cluster).

O cluster deve estar orquestrado pelo EKS, executando Kubernetes versão 1.30 ou superior. Se não possuir um cluster existente, você pode criar seguindo as instruções para criar um cluster SageMaker HyperPod com orquestração Amazon EKS. Este fluxo criará o cluster HyperPod, o cluster EKS e os recursos associados, como uma Nuvem Privada Virtual (VPC) da Amazon e um volume Amazon FSx for Lustre para armazenamento.

Você também precisará da CLI do HyperPod instalada (ou kubectl) e de uma IDE local como Visual Studio Code com o AWS Toolkit para VS Code instalado para se conectar aos Spaces.

Instalação do complemento Spaces

O processo de instalação começa acessando o console do SageMaker AI, navegando até a seção de Clusters e selecionando seu cluster HyperPod. Na aba “IDE e Notebooks”, você encontrará a opção de instalação rápida, que representa o caminho mais eficiente para começar. Com um único clique, o SageMaker AI cria e configura automaticamente os recursos AWS necessários com padrões otimizados.

A instalação rápida configura automaticamente as dependências necessárias para o complemento Spaces. Essas incluem funções de IAM específicas para o controller de Spaces (responsável por chamadas de API da AWS e operações do AWS Systems Manager Session Manager), um roteador em cluster para operações de Serviço de Gerenciamento de Chaves (KMS) da AWS e assinatura de JWT, e uma função de instância gerenciada pelo SSM para acesso remoto.

Os complementos dependentes do EKS também são instalados, incluindo Cert-manager para gerenciamento de certificados, o driver de Armazenamento em Bloco Elástico (EBS) da CSI para volumes de armazenamento persistente, e o Controlador de Balanceador de Carga da AWS para gerenciar Balanceadores de Carga Elásticos. Para detalhes completos sobre configurações de permissão, consulte a documentação de configuração de permissões.

A instalação rápida não inclui configurações de interface web como registros de DNS no Route 53 e certificados SSL. Administradores podem usar a opção de instalação personalizada ou configurar essas propriedades após a instalação. Para ambientes de produção, recomenda-se a opção de instalação personalizada, permitindo que os administradores configurem políticas de IAM mais granulares seguindo o princípio de menor privilégio. Consulte a documentação de instalação do operador via helm/Console para orientações sobre acesso via navegador web.

Tipicamente, a instalação completa em 2 a 5 minutos, dependendo da disponibilidade de dependências pré-existentes ou se o complemento Spaces precisará provisionar recursos completamente novos. Após conclusão, administradores conseguem visualizar Spaces criados por cientistas de dados, configurar namespaces para organizar Spaces por equipe ou projeto, e criar templates de Space com configurações pré-definidas para casos de uso comuns.

Configuração de acesso dos usuários

Para conceder acesso aos usuários para criar e gerenciar Spaces, você deve configurar entradas de acesso do EKS. Duas políticas de entrada de acesso são necessárias: AmazonSagemakerHyperpodSpacePolicy e AmazonSagemakerHyperpodSpaceTemplatePolicy. Para instruções detalhadas, consulte a documentação sobre criação de entradas de acesso e atualização de entradas de acesso.

Criação e gerenciamento de Spaces

Cientistas de dados podem criar JupyterLab e Code Editor Spaces no cluster utilizando kubectl ou a CLI do HyperPod. Para criar um Space, você define o contexto do cluster e executa o comando de criação:

hyp set-cluster-context --cluster-name <your-hyperpod-cluster-name>

hyp create hyp-space \
  --name "data-science-space" \
  --display-name "Data Science Workspace" \
  --namespace "default"

Para criar um Space com Code Editor, a sintaxe inclui um template específico:

hyp create hyp-space \
  --name code-editor-demo \
  --display-name "code-editor space" \
  --memory 8Gi \
  --template-ref name=sagemaker-code-editor-template,namespace=jupyter-k8s-system

Você também pode personalizar recursos durante a criação do Space, como memória e volumes persistentes:

hyp create hyp-space \
  --name test-space \
  --display-name "test space" \
  --memory 8Gi \
  --volume name=vol,mountPath=/home/,persistentVolumeClaimName=pvcname

Uma vez criado um Space, você pode acessá-lo de duas maneiras. Para trabalhar com Visual Studio Code local, execute:

hyp create hyp-space-access \
  --name data-science-space \
  --connection-type vscode-remote

Se você configurou um domínio personalizado conforme a documentação, pode obter a URL de acesso para navegador:

hyp create hyp-space-access \
  --name data-science-space \
  --connection-type web-ui

Alternativamente, você pode conectar ao Space usando o toolkit da AWS diretamente do Visual Studio Code local. Abra o painel do AWS Toolkit, navegue até SageMaker AI e HyperPod para listar, iniciar, parar e conectar aos Spaces.

A CLI do HyperPod oferece operações CRUD completas nos Spaces, incluindo atualização, descrição e exclusão. Para uma lista completa de operações, consulte o repositório do HyperPod CLI no Github. Usuários familiarizados com kubectl também podem criar, atualizar e excluir Spaces usando YAML:

kubectl apply -f - <<EOF
apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
  name: training-workspace-1
  namespace: hyperpod-training-team
  labels:
    kueue.x-k8s.io/queue-name: hyperpod-ns-training-team-localqueue
    kueue.x-k8s.io/priority-class: ide-priority
spec:
  displayName: "Training Team Workspace 1"
  image: jupyter/minimal-notebook:latest
  desiredStatus: Running
  resources:
    requests:
      cpu: 3
      memory: 12Gi
    limits:
      cpu: 3
      memory: 12Gi
EOF

Boas práticas de implementação

Gerenciamento de usuários e controle de acesso

Os Spaces utilizam Entradas de Acesso do EKS para identificar usuários, derivadas de suas identidades de IAM. A identidade capturada pelo EKS pode aparecer como um usuário de IAM ou como um ARN de sessão com role assumido. Para roles assumidas, o nome da sessão pode representar o usuário real quando o administrador aplica políticas de IAM que reforçam nomes de sessão únicos. Se os nomes de sessão não forem impostos ou não mapearem exclusivamente para usuários, o controle de acesso dos Spaces recai para controle baseado em papéis. Consulte a documentação para adicionar usuários e configurar contas de serviço.

Spaces podem ser privados (acessíveis apenas pelo criador) ou públicos (acessíveis por qualquer usuário com acesso ao namespace Kubernetes). Por padrão, os Spaces são públicos. O criador e o grupo de administrador mantêm controle total, incluindo capacidade de atualizar ou excluir o Space. Um Space torna-se privado apenas quando o acesso é restrito ao criador e grupo de administrador. Múltiplos usuários podem colaborar no mesmo Space se configurado como compartilhado. Quando habilitado com imagens de SageMaker Distribution para ambientes JupyterLab, há suporte a colaboração em tempo real (RTC), permitindo que múltiplos usuários colaborem em experimentos e cargas de trabalho interativas de aprendizado de máquina.

Templates e controles padrão do administrador

Templates configurados por administradores ajudam cientistas de dados a utilizar rapidamente configurações de Space pré-definidas para seus casos de uso. A AWS fornece dois templates de sistema pré-criados, um para JupyterLab e outro para Code Editor, permitindo que cientistas de dados iniciem sem configurações adicionais. Administradores também podem criar templates customizados com configurações específicas como imagem, armazenamento e computação. Múltiplos templates podem ser criados com base em casos de uso, projetos ou requisitos de dependência específicos.

Customização de Spaces

Administradores e desenvolvedores podem customizar Spaces usando imagens customizadas e scripts de ciclo de vida. Use scripts de ciclo de vida para customizações mínimas como instalar pacotes adicionais, configurar variáveis padrão ou executar tarefas de limpeza, mantendo as capacidades da imagem SageMaker Distribution. Para organizações que possuem imagens padronizadas para desenvolvimento e treinamento, o SageMaker Spaces oferece suporte a imagens customizadas e entry points. Consulte a documentação de customização para especificações de imagens customizadas.

Desligamento automático de computação ociosa

Os Spaces suportam desligamento automático de workspaces ociosos para otimizar o uso de recursos. Quando habilitado, o sistema verifica periodicamente a atividade do Space e, se o workspace permanecer ocioso durante o tempo limite especificado, o workspace para automaticamente, liberando recursos de computação para outras tarefas. Administradores podem configurar timeouts padrão e opcionalmente evitar que usuários substituam esses padrões para reforçar políticas de desligamento automático.

Integração com outros complementos do HyperPod

Para guardrails contra uso excessivo de recursos, configure governança de tarefas do HyperPod, que fornece controles abrangentes de gerenciamento de recursos. Para ajudar a prevenir que workspaces sejam removidos por mudanças em cargas de trabalho não relacionadas, configure a governança de tarefas para definir cargas de trabalho de aprendizado de máquina interativo com prioridade máxima ou agende-as em namespaces da governança de tarefas com remoção desabilitada.

Configure o plugin de Observabilidade do HyperPod para monitorar o uso de recursos dos Spaces em execução no cluster. Com instalação de um clique, o plugin de observabilidade fornece visibilidade sobre quantos recursos os Spaces estão consumindo ao longo do tempo, permitindo que administradores observem e ajustem alocações de computação.

Suporte a GPU fracionada

O SageMaker Spaces suporta configurações de GPU fracionada, especificamente a tecnologia MIG (Multi-Instance GPU) da NVIDIA. O suporte a GPU fracionada significa que usuários podem compartilhar instâncias de GPU, otimizando o uso de computação enquanto mantêm isolamento entre cargas de trabalho. Experimentos executados em um perfil de GPU fracionada são menos propensos a interferir em outras cargas de trabalho executadas na mesma GPU. Para verificar se uma instância no seu cluster suporta GPU fracionada, execute:

hyp list-accelerator-partition-type --instance-type <instance type>

Se seu cluster contiver grupos de instâncias que suportam GPU fracionada, você pode criar um Space com GPU fracionada:

hyp create hyp-space \
  --name test-space \
  --display-name "mig-testing" \
  --accelerator-partition-type mig-3g.20gb \
  --accelerator-partition-count 1 \
  --memory 8Gi \
  --template-ref sagemaker-code-editor-template

Limpeza de recursos

Para evitar custos desnecessários, remova os recursos criados. Exclua todos os Spaces que você criou:

hyp delete hyp-space \
  --name <space-name>

Remova o complemento SageMaker HyperPod Spaces navegando até a página de detalhes do cluster, acessando a aba “IDE e Notebooks” e escolhendo “Remover”. Se criou um cluster HyperPod especificamente para teste, delete-o seguindo as instruções em exclusão de um cluster SageMaker HyperPod. Adicionalmente, se usou o console para criar o cluster, acesse o console do AWS CloudFormation e exclua a stack principal para remover recursos adicionais como armazenamento e recursos de rede. A stack estará no formato: sagemaker-<your-hyperpod-cluster-name>-<unique-id>

Conclusão

Os Spaces no SageMaker HyperPod potencializam a produtividade de cientistas de dados e desenvolvedores de IA ao fornecer ambientes de desenvolvimento mais seguros e gerenciados em computação de propósito específico. A integração entre ambientes familiares como JupyterLab e VS Code com a infraestrutura de cluster gerenciada simplifica significativamente o ciclo de vida do desenvolvimento. As equipes conseguem reduzir o tempo gasto em configuração de ambiente e focar em construção e implantação de modelos, mantendo ambientes de desenvolvimento consistentes. Através de integração com recursos de governança de tarefas do HyperPod, administradores otimizam custos e alocações equitativas de computação em toda a organização.

Fonte

Power up your ML workflows with interactive IDEs on SageMaker HyperPod (https://aws.amazon.com/blogs/machine-learning/power-up-your-ml-workflows-with-interactive-ides-on-sagemaker-hyperpod/)

Claude Opus 4.5 chega ao Amazon Bedrock

O modelo de linguagem mais recente da Anthropic, o Claude Opus 4.5, está agora disponível no Amazon Bedrock, um serviço gerenciado que oferece acesso a modelos de linguagem de alto desempenho de empresas líderes em inteligência artificial. O Opus 4.5 representa um avanço significativo no que os sistemas de inteligência artificial podem realizar e estabelece novos patamares em programação, agentes de IA, interação com computadores e tarefas de produtividade.

Este modelo se destaca por superar tanto o Sonnet 4.5 quanto o Opus 4.1, enquanto oferece capacidades equivalentes às do Opus com um terço do custo anterior. Sua arquitetura foi especificamente projetada para desenvolvedores que constroem agentes de IA sofisticados—sistemas capazes de raciocinar, planejar e executar tarefas complexas com mínima supervisão humana.

O que distingue o Opus 4.5

Engenharia de software e codificação

O Opus 4.5 demonstra desempenho excepcional em desenvolvimento profissional de software, alcançando 80,9% no benchmark SWE-bench Verified. Isso significa que o modelo pode transformar projetos de desenvolvimento que levariam vários dias em tarefas executáveis em horas. O modelo trabalha independentemente e inclui capacidades aprimoradas de codificação multilíngue, gerando código mais eficiente, melhor cobertura de testes e arquiteturas mais limpas.

Produtividade em tarefas empresariais

Para operações corporativas, o Opus 4.5 gerencia projetos complexos do início ao fim. Ele capacita agentes para criar apresentações em PowerPoint, planilhas em Excel e documentos em Word com acabamento profissional, incluindo revisão detalhada de documentos para contratos e acordos de não divulgação. O modelo também produz artefatos de React e HTML de qualidade superior, mantendo consistência e precisão—aspectos críticos para setores como finanças, onde a exatidão é fundamental. Ele preserva contexto entre arquivos durante projetos longos, garantindo coerência nas decisões.

Raciocínio visual avançado

Esta é a melhor capacidade de visão que a Anthropic ofereceu até agora, alcançando 80,7% no benchmark MMMU para fluxos de trabalho que dependem de interpretação visual complexa e navegação em múltiplas etapas. Exemplos incluem análise de mockups de design, processamento de documentos com layouts complexos e automatização de tarefas baseadas em navegação do navegador—com desempenho ainda mais aprimorado em interação com computadores.

Melhorias para desenvolvimento de agentes

O modelo introduz dois aprimoramentos-chave para desenvolvedores que criam agentes. A ferramenta de busca de ferramentas permite que agentes trabalhem com centenas de ferramentas descobrindo e carregando dinamicamente apenas aquelas que precisam, em vez de carregar todas as definições antecipadamente—potencialmente economizando dezenas de milhares de tokens e evitando confusão de esquemas ao escalar para grandes bibliotecas de ferramentas. Os exemplos de uso de ferramentas permitem fornecer chamadas de ferramentas exemplares diretamente na definição da ferramenta, melhorando a precisão para esquemas complexos com objetos ou arrays aninhados.

Casos de uso principais

Desenvolvimento de software

O Opus 4.5 é ideal para construir agentes que escrevem e refatoram código em projetos inteiros, gerenciam arquiteturas completas ou projetam sistemas multiagente que decompõem objetivos de alto nível em passos executáveis. A geração Claude abrange o ciclo completo de desenvolvimento: Opus 4.5 para código de produção e agentes sofisticados que usam 10 ou mais ferramentas em fluxos de trabalho como engenharia de software completa, cibersegurança ou análise financeira; Sonnet 4.5 para iteração rápida e experiências de usuário em escala; Haiku 4.5 para subagentos e produtos de acesso gratuito.

O Opus 4.5 pode analisar documentação técnica, planejar uma implementação de software, escrever o código necessário e refiná-lo iterativamente—mantendo rastreabilidade dos requisitos e contexto arquitetônico durante todo o processo.

Operações empresariais

Para gerenciar projetos complexos do início ao fim, o Opus 4.5 utiliza memória para manter contexto e consistência entre arquivos, com melhorias adicionais na criação de planilhas, slides e documentos. O modelo lida com projetos corporativos contínuos, automatizando fluxos de trabalho manuais.

Análise financeira

O modelo funciona eficientemente em sistemas complexos de informações—arquivos regulatórios, relatórios de mercado, dados internos—possibilitando modelagem preditiva e conformidade proativa. Sua consistência e precisão o tornam valioso para finanças e outros setores onde a exatidão é fundamental.

Cibersegurança

O Opus 4.5 oferece análise de nível profissional em fluxos de trabalho de segurança, correlacionando logs, bancos de dados de problemas de segurança e inteligência de segurança para detecção de eventos de segurança e resposta a incidentes automatizada.

Integração com o Amazon Bedrock AgentCore

A AWS fornece a fundação corporativa para implantar o Opus 4.5 em produção através do Amazon Bedrock AgentCore. O serviço gerenciado oferece uma API unificada para modelos de linguagem com segurança de nível corporativo, conformidade e governança.

O Opus 4.5 se integra ao AgentCore, que fornece infraestrutura e elementos primitivos para construir agentes de produção. O AgentCore inclui memória persistente para manter contexto entre sessões, o Gateway de Ferramentas para converter suas APIs e funções Lambda em ferramentas compatíveis com agentes, e gerenciamento de identidade e acesso integrado para acesso seguro aos recursos.

Você pode implantar e monitorar agentes com isolamento completo de sessão, suporte para fluxos de trabalho de longa duração (até 8 horas) e recursos de observabilidade—permitindo que você se concentre na construção de agentes em vez de gerenciar infraestrutura.

O Gateway de Ferramentas converte suas APIs e funções Lambda existentes em ferramentas compatíveis com agentes com mínimo de código—funcionando junto com o recurso de busca de ferramentas do modelo para orquestrar centenas de ferramentas. A observabilidade integrada através do Amazon CloudWatch rastreia uso de tokens, latência e taxas de erro em seus fluxos de trabalho de agentes.

Como começar

Para começar a usar o Opus 4.5 no Amazon Bedrock, você precisa configurar um cliente Python e importar as bibliotecas necessárias:

# Importar bibliotecas necessárias
import boto3
import json

# Criar uma sessão e cliente Bedrock
session = boto3.Session()
bedrock_client = session.client(
    service_name='bedrock-runtime',
    region_name='us-east-1'
)

Neste exemplo, definimos múltiplas ferramentas com defer_loading para ativar a busca de ferramentas. Isso permite que o modelo descubra e carregue apenas as ferramentas que necessita em vez de carregar todas as definições antecipadamente:

# Definir ferramentas com busca de ferramentas ativada
tools = [
    # Ativar busca de ferramentas - permite descoberta dinâmica de ferramentas
    {
        "type": "tool_search_tool_regex",
        "name": "tool_search_tool_regex"
    },
    # Ferramentas marcadas com defer_loading são descobertas sob demanda
    {
        "name": "get_weather",
        "description": "Obter clima atual para uma localização",
        "input_schema": {
            "type": "object",
            "properties": {
                "location": {"type": "string"},
                "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}
            },
            "required": ["location"]
        },
        "defer_loading": True,
        # Fornecer exemplos de entrada para melhorar precisão de esquemas complexos
        "input_examples": [
            {"location": "San Francisco, CA", "unit": "fahrenheit"},
            {"location": "Tokyo, Japan", "unit": "celsius"}
        ]
    },
    {
        "name": "search_documentation",
        "description": "Pesquisar documentação da AWS",
        "input_schema": {
            "type": "object",
            "properties": {
                "query": {"type": "string"},
                "service": {"type": "string"}
            },
            "required": ["query"]
        },
        "defer_loading": True,
        "input_examples": [
            {"query": "Lambda pricing", "service": "lambda"},
            {"query": "S3 bucket policies"}
        ]
    },
    {
        "name": "analyze_logs",
        "description": "Analisar logs de aplicação para erros",
        "input_schema": {
            "type": "object",
            "properties": {
                "log_file": {"type": "string"},
                "time_range": {"type": "string"}
            },
            "required": ["log_file"]
        },
        "defer_loading": True,
        "input_examples": [
            {"log_file": "/var/log/app.log", "time_range": "last 24 hours"},
            {"log_file": "/var/log/error.log"}
        ]
    }
]

Agora invocamos o modelo usando a Aplicação Programática (API) invoke_model com o parâmetro effort definido como médio:

# Construir a requisição com recursos beta ativados
request_body = {
    "anthropic_version": "bedrock-2023-05-31",
    # Ativar recursos beta: busca de ferramentas, exemplos de ferramentas e parâmetro effort
    "anthropic_beta": ["tool-search-tool-2025-10-19", "tool-examples-2025-10-29", "effort-2025-11-24"],
    "max_tokens": 4096,
    "temperature": 0.7,
    # Definir effort para "medium" para uso equilibrado de tokens
    "output_config": {
        "effort": "medium"
    },
    "messages": [
        {
            "role": "user",
            "content": "What's the weather in Seattle?"
        }
    ],
    "tools": tools
}

# Invocar o modelo
response = bedrock_client.invoke_model(
    modelId="global.anthropic.claude-opus-4-5-20251101-v1:0",
    body=json.dumps(request_body)
)

# Fazer parsing da resposta
response_body = json.loads(response['body'].read())

O modelo utiliza busca de ferramentas para localizar a ferramenta relevante (get_weather) da biblioteca sem carregar todas as definições de ferramentas antecipadamente. O parâmetro effort, disponível em versão beta, controla quanto liberalmente o modelo gasta tokens em raciocínio, chamadas de ferramentas e respostas. Você pode definir effort como alto para melhores resultados, médio para uso equilibrado ou baixo para uso conservador de tokens.

Capacidades principais para desenvolvimento de agentes

O Opus 4.5 possui várias capacidades que o tornam adequado para construir agentes em produção. O modelo mantém coerência em fluxos de trabalho estendidos, permitindo tomada de decisão consistente para agentes que executam processos com múltiplas etapas ao longo de horas ou dias. Melhor manipulação de ferramentas significa que agentes interagem mais confiávelmente com sistemas externos, Aplicações Programáticas (APIs) e interfaces de software—o modelo escolhe as ferramentas certas e interpreta resultados com maior precisão.

O Opus 4.5 também rastreia informações entre conversas e mantém contexto, ajudando agentes a acumular conhecimento ao longo do tempo e tomar decisões baseadas em histórico. O parâmetro effort, disponível em versão beta, oferece controle sobre uso de tokens. Você pode defini-lo como alto para melhores resultados quando qualidade importa mais, médio para desempenho equilibrado ou baixo para uso conservador de tokens. O Opus 4.5 ajusta o gasto de tokens entre raciocínio, chamadas de ferramentas e respostas com base nesta configuração.

Para implantações em produção, o Amazon Bedrock AgentCore oferece monitoramento e observabilidade através da integração com CloudWatch, rastreando uso de tokens em tempo real (útil ao ajustar o parâmetro effort), junto com métricas de latência, duração da sessão e taxas de erro para ajudar a otimizar desempenho do agente e gerenciar custos.

Preços e disponibilidade

O modelo é precificado em $5 por milhão de tokens de entrada e $25 por milhão de tokens de saída, tornando a inteligência em nível Opus acessível a um terço do custo das ofertas anteriores.

O modelo está disponível hoje no Amazon Bedrock através de inferência entre regiões, que roteia automaticamente requisições para capacidade disponível em regiões da AWS para maior throughput durante picos de demanda. Use este modelo para agentes que lidam com tarefas de longa duração, coordenam múltiplas ferramentas ou mantêm contexto em sessões estendidas.

Para informações detalhadas sobre disponibilidade, preços e especificações do modelo, consulte a documentação do Amazon Bedrock.

Próximos passos

Para começar, experimente o modelo no console do Amazon Bedrock, explore a documentação técnica e consulte a página de detalhes do modelo Claude da Anthropic para mais informações sobre suas capacidades.

Para implantar agentes em escala, explore o Opus 4.5 no Amazon Bedrock AgentCore para obter infraestrutura gerenciada com orquestração de ferramentas e monitoramento. O Opus 4.5 se destaca em fluxos de trabalho complexos e de longa duração, como desenvolvimento de software e operações empresariais. Suas capacidades em manipulação de ferramentas, gerenciamento de contexto e tomada de decisão o tornam valioso para construir agentes que operam de forma confiável em ambientes de produção.

Fonte

Claude Opus 4.5 now in Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/claude-opus-4-5-now-in-amazon-bedrock/)

O que é o Amazon Bedrock Custom Model Import?

O Amazon Bedrock Custom Model Import agora amplia seus recursos para incluir modelos OpenAI com pesos abertos, particularmente as variantes GPT-OSS de 20 bilhões e 120 bilhões de parâmetros. Esse serviço permite que as organizações importem modelos customizados diretamente em um ambiente serverless, onde é possível acessar simultaneamente modelos de fundação (FMs) por meio de uma interface unificada.

A principal vantagem dessa abordagem é eliminar a necessidade de gerenciar múltiplos endpoints ou infraestruturas isoladas. Após fazer o upload dos arquivos do modelo para o Amazon S3 (Amazon Simple Storage Service), a AWS assume todas as operações complexas: provisionamento de GPUs (Processadores Gráficos), configuração de servidores de inferência e dimensionamento automático conforme a demanda. Dessa forma, as equipes podem concentrar-se no desenvolvimento de aplicações enquanto a infraestrutura é gerenciada automaticamente.

Compatibilidade com a API do OpenAI

Os modelos GPT-OSS suportam completamente a API de Conclusões de Chat do OpenAI, mantendo compatibilidade integral com aplicações existentes. Isso significa que recursos como matrizes de mensagens, definições de papéis (sistema, usuário ou assistente) e estruturas de resposta padrão — incluindo métricas de uso de tokens — funcionam sem modificações.

Ao apontar suas aplicações para os endpoints do Amazon Bedrock, o código existente requer mudanças mínimas ou nenhuma mudança. Essa continuidade reduz significativamente o esforço de migração e o risco de regressões em produção.

Entendendo os Modelos GPT-OSS

Os modelos GPT-OSS representam os primeiros modelos de linguagem com pesos abertos lançados pela OpenAI desde o GPT-2, distribuídos sob a licença Apache 2.0. Isso significa que qualquer organização pode fazer download, modificar e utilizar esses modelos sem custos adicionais, inclusive para aplicações comerciais.

GPT-OSS-20B (20 Bilhões de Parâmetros)

Este modelo é otimizado para situações onde velocidade e eficiência são críticas. Apesar de possuir 21 bilhões de parâmetros, apenas 3,6 bilhões são ativados por token, permitindo execução em dispositivos com apenas 16 GB de memória. Com 24 camadas, 32 especialistas (4 ativos por token) e janela de contexto de 128k, oferece desempenho comparável ao o3-mini da OpenAI com a vantagem de poder ser implantado localmente para respostas mais rápidas.

GPT-OSS-120B (120 Bilhões de Parâmetros)

Desenvolvido para tarefas complexas de raciocínio — como codificação, matemática e uso de ferramentas em agentes automáticos — este modelo ativa 5,1 bilhões de parâmetros por token. Com 36 camadas, 128 especialistas (4 ativos por token) e janela de contexto de 128k, atinge desempenho equivalente ao o4-mini da OpenAI executando eficientemente em uma única Unidade de Processamento Gráfico (GPU) de 80 GB.

Arquitetura de Mistura de Especialistas

Ambos os modelos utilizam uma arquitetura de Mistura de Especialistas (MoE). Nessa abordagem, diferentes subconjuntos dos componentes do modelo (chamados de especialistas) tratam diferentes tipos de tarefas. Para cada requisição, apenas os especialistas mais relevantes são ativados, oferecendo desempenho potente enquanto mantém os custos computacionais gerenciáveis.

Formato dos Arquivos do Modelo GPT-OSS

Quando você faz download de modelos GPT-OSS do Hugging Face, recebe vários tipos de arquivo que trabalham em conjunto:

• Arquivos de pesos (.safetensors): Contêm os parâmetros reais do modelo
• Arquivos de configuração (config.json): Definem como o modelo funciona
• Arquivos do tokenizador: Realizam o processamento de texto
• Arquivo de índice (model.safetensors.index.json): Mapeia dados de pesos para arquivos específicos

O arquivo de índice exige uma estrutura específica para funcionar com o Amazon Bedrock. Deve incluir um campo de metadados no nível raiz, que pode estar vazio ({}) ou conter o tamanho total do modelo (que precisa estar abaixo de 200 GB para modelos de texto).

Modelos do Hugging Face às vezes incluem campos de metadados extras — como total_parameters — que o Amazon Bedrock não suporta. Esses campos devem ser removidos antes da importação. A estrutura correta deve ser assim:

{
  "metadata": {},
  "weight_map": {
    "lm_head.weight": "model-00009-of-00009.safetensors",
    ...
  }
}

Certifique-se de excluir o diretório .metal antes de iniciar o upload para o S3.

Processo de Implantação

O fluxo de implantação envolve quatro etapas principais:

1. Fazer download dos arquivos do modelo do Hugging Face e prepará-los para AWS
2. Enviar os arquivos do modelo para o Amazon S3
3. Usar o Amazon Bedrock Custom Model Import para trazer o modelo para o Bedrock
4. Invocar o modelo com chamadas à API compatível com OpenAI para testar a implantação

Pré-requisitos

Antes de começar a implantar seu modelo GPT-OSS, certifique-se de ter:

• Uma conta AWS ativa com permissões apropriadas
• Permissões do AWS Identity and Access Management (IAM) para:
  • Criar trabalhos de importação de modelos no Amazon Bedrock
  • Fazer upload de arquivos para o Amazon S3
  • Invocar modelos após implantação
  • Usar a função de serviço do Custom Model Import
• Um bucket S3 na sua região AWS de destino
• Aproximadamente 40 GB de espaço em disco local para download do modelo
• Acesso à Região US East 1 (N. Virginia) — obrigatória para modelos personalizados baseados em GPT-OSS
• Interface de Linha de Comando da AWS (AWS CLI) versão 2.x instalada
• Interface de Linha de Comando do Hugging Face (instale com pip install -U "huggingface_hub[cli]")

Download e Preparação dos Arquivos do Modelo

Para fazer download do modelo GPT-OSS usando a biblioteca Hugging Face Hub com transferência rápida habilitada:

import os
os.environ['HF_HUB_ENABLE_HF_TRANSFER'] = '1'
from huggingface_hub import snapshot_download

local_dir = snapshot_download(
    repo_id="Tonic/med-gpt-oss-20b",
    local_dir="./med-gpt-oss-20b",
)
print(f"Download complete! Model saved to: {local_dir}")

Após o download ser concluído (típicamente entre 10 a 20 minutos para 40 GB), verifique a estrutura do arquivo model.safetensors.index.json. Edite-o se necessário para garantir que o campo de metadados exista (pode estar vazio):

{
  "metadata": {},
  "weight_map": {
    "lm_head.weight": "model-00009-of-00009.safetensors",
    ...
  }
}

Envio dos Arquivos do Modelo para o Amazon S3

Antes de importar seu modelo, você deve armazenar os arquivos em um bucket S3 onde o Amazon Bedrock possa acessá-los.

Usando a Interface de Linha de Comando da AWS (AWS CLI), você pode sincronizar os arquivos diretamente:

aws s3 sync ./med-gpt-oss-20b/ s3://amzn-s3-demo-bucket/med-gpt-oss-20b/

O envio de 40 GB normalmente é concluído em 5 a 10 minutos. Para verificar se os arquivos foram enviados:

aws s3 ls s3://amzn-s3-demo-bucket/med-gpt-oss-20b/ --human-readable

Anote o URI do S3 (por exemplo, s3://amzn-s3-demo-bucket/med-gpt-oss-20b/) para usar no trabalho de importação. Os arquivos de saída são criptografados com as configurações de criptografia do bucket S3, seja com criptografia do lado do servidor SSE-S3 (Criptografia de Lado do Servidor S3) ou AWS Key Management Service (AWS KMS) dependendo de como você configurou o bucket.

Importação do Modelo no Amazon Bedrock

Após fazer upload dos arquivos do modelo para o S3, você pode importá-lo para o Amazon Bedrock, onde será processado e disponibilizado para inferência.

Use o AWS CLI para criar o trabalho de importação:

aws bedrock create-model-import-job \
  --job-name "gpt-oss-20b-import-$(date +%Y%m%d-%H%M%S)" \
  --imported-model-name "gpt-oss-20b" \
  --role-arn "arn:aws:iam::YOUR-ACCOUNT-ID:role/YOUR-ROLE-NAME" \
  --model-data-source "s3DataSource={s3Uri=s3://amzn-s3-demo-bucket/med-gpt-oss-20b/}"

A importação do modelo normalmente é concluída em 10 a 15 minutos para um modelo de 20B de parâmetros. Você pode acompanhar o progresso no console do Amazon Bedrock ou via AWS CLI. Após a conclusão, anote seu importedModelArn, que será usado para invocar o modelo.

Invocação do Modelo com API Compatível com OpenAI

Após a conclusão da importação, você pode testar o modelo usando o formato familiar da API de Conclusões de Chat do OpenAI para verificar se está funcionando corretamente.

Crie um arquivo chamado test-request.json com o seguinte conteúdo:

{
  "messages": [
    {
      "role": "system",
      "content": "You are a helpful AI assistant."
    },
    {
      "role": "user",
      "content": "What are the common symptoms of Type 2 Diabetes?"
    }
  ],
  "max_tokens": 500,
  "temperature": 0.7
}

Use o AWS CLI para enviar a requisição ao seu endpoint de modelo importado:

aws bedrock-runtime invoke-model \
  --model-id "arn:aws:bedrock:us-east-1:YOUR-ACCOUNT-ID:imported-model/MODEL-ID" \
  --body file://test-request.json \
  --cli-binary-format raw-in-base64-out \
  response.json

cat response.json | jq '.'

A resposta retorna no formato padrão do OpenAI:

{
  "id": "chatcmpl-f06adcc78daa49ce9dd2c58f616bad0c",
  "object": "chat.completion",
  "created": 1762807959,
  "model": "YOUR-ACCOUNT-ID-MODEL-ID",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "Type 2 Diabetes often presents with a range of symptoms...",
        "refusal": null,
        "function_call": null,
        "tool_calls": []
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 98,
    "completion_tokens": 499,
    "total_tokens": 597
  }
}

A estrutura da resposta corresponde exatamente ao formato do OpenAI — choices contém a resposta, usage fornece contagens de tokens e finish_reason indica o status de conclusão. O código existente de análise de resposta do OpenAI funciona sem modificações.

Migração do OpenAI para Amazon Bedrock

Migrar do OpenAI requer apenas mudanças mínimas no código — apenas o método de invocação muda, enquanto as estruturas de mensagens permanecem idênticas.

No OpenAI:

import openai
response = openai.ChatCompletion.create(model="....", messages=[...])

No Amazon Bedrock:

import boto3, json
bedrock = boto3.client('bedrock-runtime')
response = bedrock.invoke_model(
    modelId='arn:aws:bedrock:us-east-1:ACCOUNT:imported-model/MODEL-ID',
    body=json.dumps({"messages": [...]})
)

A migração é direta e oferece vantagens significativas: custos previsíveis, melhor privacidade de dados e a capacidade de ajustar modelos para necessidades específicas.

Limpeza de Recursos

Quando terminar, limpe seus recursos para evitar cobranças desnecessárias:

aws bedrock delete-imported-model --model-identifier "arn:aws:bedrock:us-east-1:ACCOUNT:imported-model/MODEL-ID"
aws s3 rm s3://amzn-s3-demo-bucket/med-gpt-oss-20b/ --recursive

Se não precisar mais da função IAM, delete-a usando o console do IAM.

Práticas Recomendadas

Considere as seguintes práticas recomendadas ao trabalhar com importação de modelos:

• Validação de arquivos: Antes de fazer upload, verifique se model.safetensors.index.json tem a estrutura de metadados correta, se os arquivos safetensors referenciados existem e se os tokenizadores são suportados. A validação local economiza tempo em tentativas de importação.
• Segurança: No console do Amazon Bedrock, crie funções IAM automaticamente com permissões de privilégio mínimo. Para múltiplos modelos, use prefixos S3 separados para manter isolamento.
• Versionamento: Use caminhos descritivos no S3 (como gpt-oss-20b-v1.0/) ou nomes de trabalhos de importação com data para rastreamento de implantações.

Custos e Disponibilidade

Você é cobrado pela execução de inferência com modelos customizados que importa no Amazon Bedrock. Para mais detalhes, consulte Calcular o custo de executar um modelo customizado e Preços do Amazon Bedrock.

O Amazon Bedrock Custom Model Import está disponível em múltiplas regiões, com suporte se expandindo para regiões adicionais em breve. Consulte Suporte de recursos por região AWS no Amazon Bedrock para as atualizações mais recentes. Os modelos GPT-OSS estarão inicialmente disponíveis na Região US-East-1 (N. Virginia).

Conclusão

O Amazon Bedrock Custom Model Import oferece às organizações a capacidade de trazer modelos GPT-OSS para um ambiente gerenciado e serverless, mantendo compatibilidade total com a API do OpenAI. Isso reduz significativamente o esforço de migração de aplicações existentes para a AWS.

Os benefícios práticos são evidentes: segurança de nível empresarial, dimensionamento automático, controle de custos previsível, privacidade de dados aprimorada e a possibilidade de ajustar modelos com seus próprios dados proprietários. Tudo isso com mudanças mínimas no código existente.

Tem dúvidas ou feedback? Conecte-se com a comunidade através do AWS re:Post para Amazon Bedrock — eles adorariam ouvir sobre sua experiência.

Fonte

Deploy GPT-OSS models with Amazon Bedrock Custom Model Import (https://aws.amazon.com/blogs/machine-learning/deploy-gpt-oss-models-with-amazon-bedrock-custom-model-import/)

Inovação em IA Generativa no Canadá: Um Novo Horizonte

Organizações canadenses estão descobrindo oportunidades significativas para transformar suas operações e experiências de clientes através de inteligência artificial generativa. A AWS expandiu recentemente suas capacidades nessa região com um anúncio importante: clientes no Canadá agora podem acessar modelos de fundação avançados, incluindo Claude Sonnet 4.5 e Claude Haiku 4.5 da Anthropic, por meio do Amazon Bedrock utilizando perfis de inferência cross-region (CRIS).

Este desenvolvimento abre caminhos para que empresas canadenses implementem soluções de IA em escala, aproveitando os últimos modelos de linguagem disponíveis globalmente, ao mesmo tempo em que mantêm conformidade com requisitos de governança de dados locais. O artigo a seguir explora como organizar essa transição, configurar os permissionamentos necessários e gerenciar a capacidade de forma eficiente.

Entendendo a Inferência Cross-Region: Capacidades e Arquitetura

O que são Perfis de Inferência Cross-Region?

A AWS oferece no Amazon Bedrock os chamados perfis de inferência cross-region (CRIS), um mecanismo poderoso que permite às organizações distribuir requisições de processamento de forma automática entre múltiplas regiões. Esse recurso resolve um desafio fundamental para aplicações de IA em escala: equilibrar a demanda de throughput enquanto mantém a responsividade mesmo sob carga elevada.

A AWS oferece dois tipos principais de perfis de inferência cross-region:

• CRIS Geográfico: A AWS seleciona automaticamente a região comercial ideal dentro de uma determinada geografia para processar sua requisição de inferência.
• CRIS Global: Amplia ainda mais as possibilidades ao rotear requisições para regiões comerciais suportadas em qualquer parte do mundo, otimizando recursos disponíveis e permitindo maior throughput dos modelos.

Segurança e Conformidade: Onde Residem Seus Dados

Um ponto essencial para organizações com requisitos regulatórios rigorosos: a inferência cross-region opera através da rede segura da AWS com criptografia de ponta a ponta, tanto para dados em trânsito quanto em repouso. Quando uma requisição de inferência é enviada da região Canadá (Central), o CRIS a roteia inteligentemente para uma das regiões de destino configuradas no perfil de inferência.

A distinção crítica é esta: enquanto o processamento de inferência (a computação transitória) pode ocorrer em outra região, todos os dados em repouso — incluindo logs de invocação, bases de conhecimento e configurações armazenadas — permanecem exclusivamente dentro da região Canadá (Central). A requisição viaja pela rede global da AWS, sem passar pela internet pública, e as respostas retornam criptografadas para sua aplicação no Canadá.

Vantagens Estratégicas da Inferência Cross-Region para o Canadá

Implementar CRIS oferece ganhos tangíveis para organizações canadenses em múltiplas dimensões:

Acesso Acelerado a Modelos Novos: Com CRIS, organizações canadenses ganham acesso antecipado a modelos de ponta, como Claude Sonnet 4.5 com capacidades aprimoradas de raciocínio. Em vez de esperar meses por disponibilidade regional, o acesso pode ser conquistado em dias.

Capacidade e Performance Aprimoradas: O acesso distribuído a recursos de múltiplas regiões permite maior throughput geral. Durante períodos de pico — como temporada de impostos, Black Friday e compras de final de ano — a capacidade escala automaticamente sem intervenção manual, absorvendo surtos de demanda.

Resiliência Operacional: Servir requisições de um pool maior de recursos aumenta a resiliência geral. Se uma região enfrenta restrições de capacidade, o tráfego é automaticamente distribuído, garantindo que aplicações de IA permaneçam responsivas.

Escolhendo Entre Perfis US e Global

Organizações canadenses podem optar entre dois modelos de perfil de inferência conforme suas necessidades específicas:

• Inferência Cross-Region US: Recomendada para organizações com acordos de processamento de dados existentes com regiões US, requisitos de throughput e resiliência elevados, e ambientes de desenvolvimento e teste.
• Inferência Global: Apropriada quando máxima capacidade é prioritária ou quando restrições geográficas permitem processamento em qualquer região comercial suportada.

Começando com Perfis de Inferência Cross-Region

Etapa 1: Configurar Permissões IAM

Antes de implementar CRIS, é necessário validar que sua função ou usuário IAM possui as permissões corretas para invocar modelos Amazon Bedrock utilizando perfis de inferência cross-region.

Abaixo está um exemplo de política para inferência cross-region US:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel*"
      ],
      "Resource": [
        "arn:aws:bedrock:ca-central-1::inference-profile/us.anthropic.claude-sonnet-4-5-20250929-v1:0"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel*"
      ],
      "Resource": [
        "arn:aws:bedrock:*::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0"
      ],
      "Condition": {
        "StringLike": {
          "bedrock:InferenceProfileArn": "arn:aws:bedrock:ca-central-1::inference-profile/us.anthropic.claude-sonnet-4-5-20250929-v1:0"
        }
      }
    }
  ]
}

Para configurar CRIS global, consulte o artigo dedicado disponível na documentação AWS sobre escalabilidade de inferência global com o Claude Sonnet 4.5.

Etapa 2: Utilizar Perfis de Inferência Cross-Region

Configure sua aplicação para usar os identificadores de perfil de inferência relevantes. Os perfis utilizam prefixos que indicam seu escopo de roteamento:

• Claude Sonnet 4.5 (Regiões US): us.anthropic.claude-sonnet-4-5-20250929-v1:0
• Claude Sonnet 4.5 (Global): global.anthropic.claude-sonnet-4-5-20250929-v1:0
• Claude Haiku 4.5 (Regiões US): us.anthropic.claude-haiku-4-5-20251001-v1:0
• Claude Haiku 4.5 (Global): global.anthropic.claude-haiku-4-5-20251001-v1:0

Exemplo Prático: Utilizando a API Converse

Abaixo está um exemplo de como usar a API Converse do Amazon Bedrock com um perfil de inferência CRIS US a partir do Canadá:

import boto3

# Inicializar cliente Bedrock Runtime
bedrock_runtime = boto3.client(
    service_name="bedrock-runtime",
    region_name="ca-central-1"  # Região Canadá (Central)
)

# Definir o identificador do perfil de inferência
inference_profile_id = "us.anthropic.claude-sonnet-4-5-20250929-v1:0"

# Preparar a conversa
response = bedrock_runtime.converse(
    modelId=inference_profile_id,
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "text": "What are the benefits of using Amazon Bedrock for Canadian organizations?"
                }
            ]
        }
    ],
    inferenceConfig={
        "maxTokens": 512,
        "temperature": 0.7
    }
)

# Exibir a resposta
print(f"Response: {response['output']['message']['content'][0]['text']}")

Gerenciando Quotas de Capacidade para Cargas no Canadá

Como as Quotas Funcionam com CRIS

Ao utilizar CRIS a partir do Canadá, o gerenciamento de quotas é realizado no nível da região de origem (ca-central-1). Isto significa que aumentos de quota solicitados para a região Canadá (Central) aplicam-se a todas as requisições de inferência originadas no Canadá, independentemente de onde são efetivamente processadas.

Entendendo Taxa de Burndown

Um conceito crítico ao calcular aumentos necessários de quota: quando você planeja aumentos, deve levar em conta a taxa de burndown, definida como a velocidade na qual tokens de entrada e saída são convertidos em uso de quota de token para o sistema de throttling.

Os seguintes modelos possuem taxa de burndown de 5x para tokens de saída (1 token de saída consome 5 tokens de sua quota):

• Anthropic Claude Opus 4
• Anthropic Claude Sonnet 4.5
• Anthropic Claude Sonnet 4
• Anthropic Claude 3.7 Sonnet

Para outros modelos, a taxa de burndown é de 1:1 (1 token de saída consome 1 token de sua quota). Para tokens de entrada, a proporção é sempre 1:1.

A fórmula para calcular o total de tokens por requisição é:

Contagem de tokens de entrada + Tokens de entrada em cache escrito + (Contagem de tokens de saída × Taxa de burndown)

Solicitando Aumentos de Quota

Para solicitar aumentos de quota para CRIS no Canadá:

1. Navegue para o console de quotas de serviço da AWS na região Canadá (Central).
2. Procure pela quota de modelo específico (por exemplo, “Claude Sonnet 4.5 tokens por minuto”).
3. Envie uma solicitação de aumento baseada no seu uso projetado.

Migrando de Modelos Claude Anteriores para Claude 4.5

Organizações utilizando versões anteriores de Claude devem considerar uma migração planejada para aproveitar as capacidades do Claude 4.5. Para estruturar essa transição:

Estabeleça Métricas de Baseline: Defina métricas de desempenho inicial para seus modelos existentes, criando um ponto de referência claro.

Teste com Cargas Representativas e Otimize Prompts: Valide o desempenho do Claude 4.5 com seus casos de uso específicos. Ajuste seus prompts para aproveitar as capacidades mais recentes do modelo e utilize a ferramenta de otimização de prompt do Bedrock.

Implemente Rollout Gradual: Transicione tráfego progressivamente em vez de uma mudança brusca, reduzindo risco operacional.

Monitore e Ajuste: Acompanhe métricas de desempenho e ajuste quotas conforme necessário durante o período de transição.

Síntese: Conformidade, Velocidade e Escala

A inferência cross-region para Amazon Bedrock representa uma oportunidade para organizações canadenses que desejam implementar IA generativa mantendo rigorosa governança de dados. Ao diferenciar entre processamento de inferência transitório e armazenamento de dados persistente, CRIS oferece acesso acelerado aos últimos modelos de fundação sem comprometer conformidade regulatória.

Com CRIS, organizações canadenses obtêm acesso a novos modelos em dias em vez de meses. O sistema escala automaticamente durante períodos de pico de negócios mantendo trilhas de auditoria completas dentro do Canadá, ajudando a atender requisitos regulatórios enquanto utilizam as mesmas capacidades avançadas de IA disponíveis globalmente.

Para começar, revise seus requisitos de governança de dados e configure os permissionamentos IAM necessários. Depois, teste com o perfil de inferência que melhor se alinha com suas necessidades — US para latência reduzida com regiões americanas, ou Global para máxima capacidade.

Fonte

Accelerate generative AI innovation in Canada with Amazon Bedrock cross-Region inference (https://aws.amazon.com/blogs/machine-learning/accelerate-generative-ai-innovation-in-canada-with-amazon-bedrock-cross-region-inference/)

O que muda no CloudFront

A AWS anunciou o suporte para Autenticação TLS Mútua (mTLS) no CloudFront, um protocolo de segurança que exige que tanto o servidor quanto o cliente se autentiquem mutuamente utilizando certificados X.509. Com esse recurso, os clientes conseguem validar a identidade dos acessantes nas localizações edge do CloudFront, antes que as conexões cheguem aos servidores de aplicação ou APIs.

Até então, as empresas precisavam investir esforço contínuo para implementar e manter suas próprias soluções de gestão de acesso de clientes — uma tarefa repetitiva e sem agregação de valor diferenciado. Agora, a autenticação mútua TLS simplifica esse processo, garantindo que apenas clientes portadores de certificados confiáveis consigam acessar as distribuições do CloudFront.

Benefícios práticos para sua infraestrutura

Com essa novidade, é possível proteger distribuições contra acessos não autorizados e ameaças de segurança, validando identidades de clientes no edge antes de qualquer conexão ser estabelecida. O uso de autenticação mútua TLS no CloudFront oferece os mesmos benefícios de performance e escala da plataforma, agora aplicados a workloads que demandam autenticação de clientes.

O recurso está disponível para todos os clientes do CloudFront sem custo adicional e pode ser configurado através do Console de Gerenciamento da AWS, CLI, SDK, CDK e CloudFormation.

Casos de uso principais

Integrações seguras de APIs B2B

Para cenários B2B, empresas podem autenticar requisições de API provenientes de parceiros e terceiros confiáveis utilizando autenticação mútua TLS. Isso é especialmente valioso para integrações entre organizações que precisam validar identidades em cada transação.

Autenticação de dispositivos IoT

Em ambientes com Internet das Coisas, é possível validar que apenas dispositivos autorizados recebem conteúdo proprietário, como atualizações de firmware. Dessa forma, garante-se que apenas equipamentos legítimos acessam recursos críticos.

Flexibilidade para escolher certificados

Os clientes podem aproveitar Autoridades de Certificação de terceiros já existentes ou utilizar a Autoridade de Certificados Privada da AWS para assinar certificados X.509. Essa flexibilidade permite que as organizações continuem usando sua infraestrutura de certificados ou adotem a solução gerenciada pela AWS conforme sua necessidade.

Como começar

Para empresas que desejam implementar essa solução, a AWS fornece orientações detalhadas e boas práticas na documentação de autenticação mútua TLS do CloudFront. O processo de configuração é direto e integrado aos fluxos de trabalho já familiares aos usuários da plataforma.

Fonte

Amazon CloudFront announces support for mutual TLS authentication (https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-cloudfront-mutual-tls-authentication/)