Author: Make.com Service User

  • Amazon Bedrock AgentCore Memory agora suporta controle de acesso refinado

    O que foi anunciado

    A AWS anunciou que o Amazon Bedrock AgentCore Memory passou a suportar Controle de Acesso Refinado (FGAC — Fine-Grained Access Control). Com essa novidade, equipes que desenvolvem agentes de Inteligência Artificial (IA) conseguem aplicar isolamento de memória por usuário e por tenant de forma nativa, sem precisar construir lógica de autorização customizada dentro do código da aplicação.

    Como funciona o FGAC no AgentCore Memory

    Para habilitar o FGAC, a AWS orienta que o recurso de memória seja exposto por meio do AgentCore Gateway, configurado com autenticação OAuth (JWT). A partir daí, é possível anexar políticas Cedar que restringem o acesso com base na identidade do chamador autenticado.

    Na prática, isso significa que cada usuário só consegue acessar os dados do seu próprio ator dentro da memória. Além disso, os registros de memória podem ser restritos a namespaces derivados diretamente das claims do token do usuário, e operações específicas de memória podem ser permitidas ou negadas por chamador.

    O resultado prático é significativo: o controle de acesso deixa de viver no código da aplicação e passa a ser aplicado na camada de infraestrutura, usando prova criptográfica de identidade.

    Arquitetura por trás do recurso

    O FGAC para o AgentCore Memory é construído sobre o AgentCore Memory connector, um conector de gateway gerenciado que conecta um alvo de gateway ao plano de dados do Memory. Esse conector expõe 12 operações de memória como ações Cedar, com seus atributos de requisição disponíveis para uso em condições de política.

    Essa abordagem torna a configuração de controle de acesso mais declarativa e auditável, já que as políticas Cedar descrevem explicitamente quem pode fazer o quê — sem depender de validações espalhadas pelo código da aplicação.

    Por que isso importa para times de IA

    Em cenários de agentes de IA com múltiplos usuários ou múltiplos tenants, garantir que cada entidade acesse apenas a sua própria memória é um requisito crítico de segurança e privacidade. Antes desse recurso, essa responsabilidade recaía inteiramente sobre o desenvolvedor, que precisava implementar e manter a lógica de autorização manualmente. Com o FGAC, essa camada passa a ser gerenciada pela própria infraestrutura do AgentCore.

    Como começar

    Para equipes que queiram implementar o FGAC no Amazon Bedrock AgentCore Memory, a AWS disponibiliza documentação detalhada no Guia do Desenvolvedor do AgentCore. Confira o ponto de partida recomendado: Controle de acesso refinado para Memory no Guia do Desenvolvedor do Amazon Bedrock AgentCore.

    Fonte

    Amazon Bedrock AgentCore Memory now supports fine-grained access control (https://aws.amazon.com/about-aws/whats-new/2026/08/agentcorememory-fine-grained-access-control)

  • Instâncias Amazon EC2 C8gn já disponíveis na região AWS Europa (Paris)

    Graviton4 chega a Paris: o que muda para workloads de rede

    A AWS expandiu a disponibilidade das instâncias Amazon EC2 C8gn para a região Europa (Paris). Movidas pelos processadores AWS Graviton4 de última geração, essas instâncias entregam até 30% mais desempenho computacional em comparação com as C7gn, que eram baseadas no Graviton3.

    Principais capacidades técnicas

    As instâncias C8gn se destacam especialmente no quesito conectividade. Elas utilizam as Nitro Cards de 6ª geração e oferecem até 600 Gbps de largura de banda de rede — o maior valor disponível entre todas as instâncias EC2 voltadas para cargas de trabalho intensivas em rede.

    Em termos de escalabilidade, as C8gn chegam ao tamanho 48xlarge, com até 384 GiB de memória e até 120 Gbps de banda para o Amazon Elastic Block Store (EBS).

    Para clusters de alto desempenho, os tamanhos 16xlarge, 24xlarge, 48xlarge, metal-24xl e metal-48xl contam com suporte ao Elastic Fabric Adapter (EFA), o que reduz a latência e melhora o desempenho em ambientes com nós fortemente acoplados.

    Casos de uso recomendados

    A AWS posiciona as instâncias C8gn para cenários que exigem alto throughput de rede combinado com eficiência de custo, como:

    • Appliances virtuais de rede (network virtual appliances)
    • Análise de dados em larga escala
    • Inferência de inteligência artificial e aprendizado de máquina (IA/ML) baseada em CPU

    Disponibilidade global

    Com a adição de Paris, as instâncias C8gn estão agora disponíveis em um conjunto amplo de regiões AWS ao redor do mundo:

    • América do Norte: Leste dos EUA (N. Virgínia, Ohio), Oeste dos EUA (Oregon, N. Califórnia), Canadá Oeste (Calgary, Central)
    • Europa: Frankfurt, Estocolmo, Irlanda, Londres, Espanha, Zurique, Milão e Paris
    • Ásia-Pacífico: Singapura, Malásia, Sydney, Tailândia, Mumbai, Seul, Melbourne, Jacarta, Hyderabad, Tóquio, Hong Kong
    • Oriente Médio: EAU
    • África: Cidade do Cabo
    • América do Sul: São Paulo
    • AWS GovCloud: Leste e Oeste dos EUA

    Como começar

    Para quem quiser se aprofundar nas especificações e começar a usar as instâncias C8gn, a AWS disponibiliza documentação e recursos de acesso direto:

    Fonte

    Amazon EC2 C8gn instances are now available in AWS Europe (Paris) region (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-ec2-c8gn-europe-paris/)

  • Instâncias Amazon EC2 P6-B300 chegam a novas regiões AWS, incluindo São Paulo

    Expansão regional das instâncias P6-B300

    A AWS anunciou a disponibilidade das instâncias Amazon EC2 P6-B300 em novas regiões, incluindo Ásia-Pacífico (Hyderabad) e América do Sul (São Paulo). Para equipes brasileiras que trabalham com cargas de trabalho intensivas de Inteligência Artificial (IA), essa é uma novidade relevante: agora é possível acessar esse hardware de ponta sem precisar rotear tráfego para regiões fora do país.

    O que são as instâncias P6-B300?

    As instâncias P6-B300 são voltadas para workloads de IA de alta demanda — especialmente treinamento e inferência de modelos de fundação (FMs) e Modelos de Linguagem de Grande Escala (LLMs) com trilhões de parâmetros. Cada instância é equipada com:

    • 8 GPUs NVIDIA Blackwell Ultra
    • 2,1 TB de memória de GPU de alta largura de banda
    • 6,4 Tbps de rede EFA (Elastic Fabric Adapter — adaptador de malha elástica para comunicação de baixa latência entre instâncias)
    • 300 Gbps de throughput dedicado ENA (Elastic Network Adapter — adaptador de rede elástica)
    • 4 TB de memória de sistema

    O que muda em relação à geração anterior?

    Comparando com as instâncias P6-B200, a nova geração P6-B300 entrega ganhos expressivos:

    • 2x mais largura de banda de rede
    • 1,5x mais memória de GPU
    • 1,5x mais TFLOPS de GPU (medido em FP4, sem esparsidade)

    Na prática, isso se traduz em tempos de treinamento mais rápidos e maior throughput de tokens para workloads de IA — dois fatores críticos para quem lida com modelos de grande porte em produção.

    Regiões disponíveis

    As instâncias P6-B300 estão disponíveis no tamanho p6-b300.48xlarge nas seguintes regiões AWS:

    • US West (Oregon)
    • AWS GovCloud (US-East)
    • US East (N. Virginia)
    • Ásia-Pacífico (Hyderabad e Seul)
    • América do Sul (São Paulo)

    Por que isso importa para o Brasil?

    A chegada das instâncias P6-B300 à região de São Paulo é um sinal claro de que a AWS está apostando no mercado brasileiro como destino relevante para workloads de IA de alto desempenho. Equipes locais que antes precisavam usar regiões nos EUA para acessar hardware de última geração agora podem operar com menor latência, dentro da jurisdição brasileira — o que também pode facilitar o atendimento a requisitos de conformidade e soberania de dados.

    Para saber mais sobre as instâncias P6-B300 e suas especificações completas, a AWS disponibiliza a documentação oficial em Amazon EC2 instâncias P6.

    Fonte

    Amazon EC2 P6-B300 instances are now available in additional AWS Regions (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-ec2-p6-b300-instances-available-additional-regions)

  • Amazon Redshift agora se integra ao Agent Toolkit for AWS para gerenciamento de data warehouse com IA

    O que foi anunciado

    A AWS anunciou que o Amazon Redshift passou a se integrar com o Agent Toolkit for AWS, abrindo caminho para que agentes de IA como Claude Code, Kiro e Cursor consigam construir, consultar, fazer troubleshooting e migrar data warehouses e data lakes no Redshift diretamente — sem que o usuário precise sair do ambiente do agente para executar essas tarefas.

    Como a integração funciona

    A integração combina dois componentes principais. O primeiro é o servidor MCP (Model Context Protocol) da AWS, responsável por executar chamadas autenticadas às APIs da AWS em nome do usuário. O segundo são as Redshift skills — pacotes curados de procedimentos testados e materiais de referência que orientam os agentes de IA a concluírem tarefas no Redshift com mais precisão e eficiência.

    O que as Redshift Skills cobrem

    As Redshift skills abrangem uma série de capacidades práticas para o dia a dia de quem trabalha com o serviço:

    • Referências de sintaxe SQL para reduzir erros na geração de consultas
    • Descoberta de metadados para explorar schemas e dados sem precisar escrever SQL manualmente
    • Padrões de carregamento de dados
    • Boas práticas para materialized views
    • Orientações sobre funções e tipos de dados
    • Extensões como Qualify, Pivot e Super

    Além disso, as skills também guiam migrações completas de data warehouses para o Amazon Redshift, cobrindo as etapas de descoberta, conversão de schema e SQL, movimentação de dados, validação e comparação de performance.

    Disponibilidade e requisitos

    As skills funcionam tanto com clusters provisionados quanto com workgroups do Serverless, não exigem nenhuma alteração na infraestrutura existente e estão disponíveis sem custo adicional em todas as regiões da AWS onde o Amazon Redshift e o servidor MCP da AWS estão disponíveis. A AWS também indicou que continuará expandindo essas habilidades com novas capacidades ao longo do tempo.

    Como começar a usar

    Para dar os primeiros passos, basta instalar o plugin aws-data-analytics no seu agente. Esse plugin já agrupa a configuração do servidor MCP e as Redshift skills em uma única etapa de instalação. Agentes que já possuem acesso ao servidor MCP também conseguem descobrir e carregar as skills em tempo de execução, sem necessidade de pré-instalação.

    Para instruções de configuração, a AWS disponibiliza a documentação do Agent Toolkit e a documentação das Amazon Redshift skills.

    Fonte

    Amazon Redshift integrates with Agent Toolkit for AWS for AI-assisted data warehouse management (https://aws.amazon.com/about-aws/whats-new/2026/08/redshift-agenttoolkit-for-ai-assisted-datawarehouse-mgmt)

  • Modelos Muse-Glimmer-30B e Qwen 3.8-27B agora disponíveis no Amazon SageMaker JumpStart

    Novos modelos de fundação chegam ao SageMaker JumpStart

    A AWS anunciou a disponibilidade de dois novos modelos de fundação no Amazon SageMaker JumpStart: o Muse-Glimmer-30B, desenvolvido pela Meta, e o Qwen 3.8-27B, da Alibaba. A adição amplia o portfólio de modelos prontos para uso na plataforma, oferecendo aos clientes AWS mais opções para construir soluções de IA de alta performance em infraestrutura escalável.

    Cada modelo foi projetado para responder a desafios distintos dentro do ecossistema de IA empresarial, com capacidades especializadas que se complementam bem dependendo do caso de uso.

    Muse-Glimmer-30B: agentes autônomos com raciocínio local

    O Muse-Glimmer-30B é um modelo denso de 30 bilhões de parâmetros desenvolvido pelo Meta Superintelligence Lab, projetado especificamente para tarefas agênticas autônomas — ou seja, fluxos de trabalho em que o modelo precisa tomar decisões sequenciais, usar ferramentas externas e se recuperar de falhas sem intervenção humana constante.

    Entre suas características técnicas mais relevantes:

    • Encoder de percepção visual dedicado (~1,8B parâmetros, ViT-G/14), com suporte a entradas intercaladas de texto e imagem
    • Janela de contexto superior a 131 mil tokens
    • Níveis de raciocínio ajustáveis, de baixo a extra-alto
    • Capacidade de executar chamadas sequenciais a ferramentas e se recuperar de falhas
    • Operação completamente local, sem dependência de infraestrutura em nuvem — ideal para agentes empresariais sempre ativos

    O modelo é disponibilizado sob licença Apache 2.0.

    Qwen 3.8-27B: codificação, raciocínio e compreensão multimodal

    O Qwen 3.8-27B é um modelo de linguagem e visão nativo (VLM — Vision-Language Model) com 27 bilhões de parâmetros densos, desenvolvido pela Alibaba. Ele se destaca em tarefas de codificação, raciocínio em múltiplas etapas e compreensão multimodal envolvendo texto, imagens e vídeo.

    Destaques técnicos do modelo:

    • Janela de contexto de 262 mil tokens, expansível a aproximadamente 1 milhão via escalonamento YaRN
    • Níveis de esforço de raciocínio ajustáveis
    • Pontuação de 61,7 no benchmark SWE-bench Pro
    • Tamanho de aproximadamente 17 GB quantizado
    • Ganhos substanciais de desempenho em relação à versão anterior, com maior confiabilidade na conclusão de tarefas complexas

    Como implantar os modelos no SageMaker JumpStart

    A AWS destaca que a implantação de ambos os modelos pode ser feita com poucos cliques. Os clientes podem acessar o catálogo de modelos do SageMaker JumpStart diretamente pelo console do SageMaker ou utilizar o SDK Python do SageMaker para implantar os modelos em sua conta AWS.

    Para quem quiser se aprofundar nos detalhes de implantação e uso de modelos de fundação no SageMaker JumpStart, a AWS disponibiliza a documentação oficial do Amazon SageMaker JumpStart.

    Fonte

    Muse-Glimmer-30B and Qwen 3.8-27B models now available on Amazon SageMaker JumpStart (https://aws.amazon.com/about-aws/whats-new/2026/01/muse-glimmer-30b-qwen-3.8-27b-on-sagemaker-jumpstart/)

  • Modelos Cosmos3-Edge, Cosmos3-Nano e Cosmos3-Super já estão disponíveis no Amazon SageMaker JumpStart

    Família Cosmos 3 chega ao SageMaker JumpStart

    A AWS anunciou a disponibilidade dos modelos Cosmos3-Edge, Cosmos3-Nano e Cosmos3-Super — da NVIDIA — no Amazon SageMaker JumpStart, expandindo o portfólio de modelos de fundação acessíveis aos clientes da plataforma. Os três modelos formam a família Cosmos 3, uma linha de modelos omnimodais de fronteira para IA física, projetados para capacitar robôs, veículos autônomos e sistemas de visão artificial que precisam perceber, raciocinar, planejar e agir no mundo físico.

    Três modelos, três propósitos

    Cada modelo da família Cosmos 3 foi desenvolvido para endereçar desafios específicos dentro do universo da IA física. Veja o que cada um oferece:

    Cosmos3-Edge — IA física na borda

    O Cosmos3-Edge foi projetado para controle de robôs diretamente no dispositivo e raciocínio visual em tempo real em hardware de borda (edge). Com 4 bilhões de parâmetros (mais um raciocínio baseado em Nemotron de 2B), o modelo opera na resolução de controle robótico (640×360), gerando 32 ações por inferência a 15 Hz no NVIDIA Jetson Thor. Ele suporta vídeo em 256p e 480p a 12–30 quadros por segundo, trazendo capacidades de IA física de fronteira diretamente para sistemas embarcados.

    Cosmos3-Nano — raciocínio físico compacto

    O Cosmos3-Nano se destaca na geração de mundos com consciência física e no raciocínio sobre o mundo real. Com 16 bilhões de parâmetros, este modelo omnimodal compacto processa combinações de texto, imagem, vídeo, áudio e trajetórias de ação para produzir saídas correspondentes. Isso permite que robôs e agentes de visão artificial raciocinem com base em conhecimento prévio, compreensão de física e senso comum. O modelo suporta raciocínio em cadeia de pensamento (chain-of-thought) sobre texto, imagens e vídeo, com resoluções de até 720p.

    Cosmos3-Super — simulação de alta fidelidade

    O Cosmos3-Super oferece a geração e simulação de mundos com a maior fidelidade da família Cosmos 3, com 64 bilhões de parâmetros. Ele processa e gera conjuntamente linguagem, imagens, vídeo, áudio e sequências de ação dentro de uma arquitetura unificada de Mistura de Transformadores (Mixture-of-Transformers), suportando resoluções de até 720p em múltiplas proporções de tela. É o modelo ideal para fluxos de trabalho de simulação em larga escala, geração de dados sintéticos e aprendizado de políticas.

    Como implantar os modelos

    Com o SageMaker JumpStart, os clientes AWS podem implantar qualquer um desses modelos com poucos cliques para atender aos seus casos de uso específicos de IA. Para começar, basta acessar o catálogo de modelos do SageMaker JumpStart pelo console do SageMaker ou utilizar o SDK Python do SageMaker para implantar os modelos na sua conta AWS. Para mais detalhes sobre como implantar e utilizar modelos de fundação no SageMaker JumpStart, consulte a documentação oficial do Amazon SageMaker JumpStart.

    Fonte

    Cosmos3-Edge, Cosmos3-Nano, and Cosmos3-Super models now available on Amazon SageMaker JumpStart (https://aws.amazon.com/about-aws/whats-new/2026/01/cosmos3-edge-cosmos3-nano-cosmos3-super-on-sagemaker-jumpstart/)

  • Estendendo o Amazon Bedrock Guardrails para Interações com Ferramentas Usando o Strands Agents SDK

    O problema: guardrails de modelo não cobrem tudo

    Quem já colocou agentes de IA em produção sabe que o Amazon Bedrock Guardrails protege o que acontece na fronteira do modelo — valida o prompt antes da inferência e a resposta depois. Mas agentes fazem muito mais do que chamar modelos. Eles invocam ferramentas, buscam dados em fontes externas, se comunicam com servidores via Protocolo de Contexto de Modelo (MCP) e retornam resultados para usuários ou sistemas downstream.

    Todo esse fluxo acontece fora da fronteira do modelo, onde os guardrails de nível de modelo simplesmente não chegam. A AWS identificou quatro exposições concretas que surgem dessa lacuna:

    • Parâmetros de ferramentas passam sem verificação. O modelo decide qual ferramenta usar e quais parâmetros enviar. Se esses parâmetros contiverem Informações de Identificação Pessoal (PII) ou conteúdo que viola políticas, a ferramenta executa com esse conteúdo sem nenhuma barreira.
    • Dados externos entram sem validação. Respostas de ferramentas, saídas de servidores MCP e retornos de APIs chegam ao agente sem passar por nenhum guardrail, podendo influenciar o comportamento do modelo antes de qualquer avaliação.
    • Conteúdo enganoso afeta o raciocínio. Um agente que consome dados imprecisos de uma fonte externa pode tratá-los como autoritativos, gerando recomendações distorcidas em áreas críticas como crédito, saúde ou assessoria jurídica.
    • Sistemas multi-agente propagam dados problemáticos. Em arquiteturas com múltiplos agentes, um componente mal configurado pode passar conteúdo que viola políticas para agentes downstream — e os guardrails de cada agente individualmente não inspecionam o que trafega entre eles na camada de ferramentas.

    A solução: três pontos de validação com lifecycle hooks

    Para fechar essas lacunas, a abordagem proposta pela AWS adiciona três pontos de validação em cada fronteira de confiança onde dados entram ou saem do agente. Esses pontos são implementados com os lifecycle hooks do Strands Agents SDK, sem exigir nenhuma alteração nas ferramentas existentes ou na lógica do agente.

    Figura 1: Os três pontos de validação estendem o Amazon Bedrock Guardrails da fronteira do modelo até a fronteira das ferramentas. Imagem original — fonte: Aws

    Ponto 1 — Validação de dados de entrada (BeforeInvocationEvent)

    O primeiro ponto verifica os dados antes de chegarem ao modelo: entrada do usuário, dados vindos de outros agentes, servidores MCP e pipelines de Geração Aumentada por Recuperação (RAG). O hook BeforeInvocationEvent dispara antes da inferência ou da execução de qualquer ferramenta. Se o conteúdo violar políticas, a requisição é bloqueada e o modelo nunca vê esse conteúdo.

    Ponto 2 — Supervisão de interação com ferramentas (BeforeToolCallEvent)

    O segundo ponto age antes de o agente chamar uma ferramenta, verificando os parâmetros que seriam enviados. É exatamente a lacuna que os guardrails de nível de modelo não cobrem: o modelo já decidiu o que enviar, mas nada verificou se esse conteúdo é seguro para ser executado. O hook BeforeToolCallEvent cancela a chamada se os parâmetros forem problemáticos, antes que qualquer ação real aconteça.

    Ponto 3 — Validação de dados de saída (AfterToolCallEvent)

    O terceiro ponto valida os resultados antes de retorná-los ao usuário ou repassá-los a sistemas downstream. É especialmente importante para ferramentas que consomem conteúdo externo, como uma ferramenta de busca na web que traz páginas de sites fora do seu controle. O hook AfterToolCallEvent valida o retorno da ferramenta e o substitui por uma mensagem de bloqueio se o conteúdo violar políticas.

    A intensidade de validação de cada ponto pode ser ajustada de forma independente. No Ponto 1, faz sentido usar um guardrail completo com detecção de PII, filtragem de conteúdo e aplicação de tópicos. O Ponto 2 pode ser mais leve — um guardrail separado com regras específicas para a ferramenta em questão, ou verificações locais como validação de expressão regular ou de schema. O Ponto 3 deve focar na detecção de conteúdo indesejado nas saídas que trazem dados externos. Combinar verificações determinísticas rápidas (regex, validação de schema, listas de permissão) com avaliações baseadas em IA mantém a latência baixa.

    Implementação passo a passo

    A implementação usa o boto3, o SDK da AWS para Python, para chamar a API ApplyGuardrail. O Strands Agents SDK expõe um evento de lifecycle por ponto de validação.

    Pré-requisitos

    Antes de implementar a abordagem com múltiplos pontos de validação, você precisará de:

    • Uma conta AWS com acesso ao Amazon Bedrock
    • Amazon Bedrock Guardrails configurado
    • Python 3.11 ou superior instalado
    • Strands Agents SDK instalado: pip install strands-agents
    • Credenciais AWS configuradas com permissões para bedrock:ApplyGuardrail e bedrock:InvokeModel
    • O ID e a versão do seu guardrail, obtidos no console do Amazon Bedrock (navegue até Guardrails, selecione seu guardrail e copie o ID)

    Este guia pressupõe que você já tem um agente Strands funcionando com acesso mínimo privilegiado às ferramentas, prompts de sistema com escopo definido e lógica de negócios validada. Se estiver começando do zero, a AWS recomenda consultar o artigo Strands Agents SDK: A technical deep dive into agent architectures and observability para um passo a passo completo de construção e implantação com o Amazon Bedrock Agent Core.

    Criando o hook de validação de guardrail

    A classe GuardrailHook é um HookProvider do Strands. Ela registra três callbacks, um para cada evento de lifecycle. Quando o Strands dispara um evento, o callback correspondente executa: validate_inbound verifica mensagens do usuário, validate_input verifica parâmetros de ferramentas antes da execução e validate_output verifica os resultados das ferramentas. Os três usam o método compartilhado _check, que chama a API ApplyGuardrail do Amazon Bedrock.

    Crie um arquivo guardrail_hook.py e adicione a implementação abaixo. Use o parâmetro opcional tool_names para restringir o hook a ferramentas específicas, ou passe None para aplicar em todas:

    import boto3
    from strands.hooks import HookProvider, HookRegistry
    from strands.hooks.events import (
        BeforeInvocationEvent,
        BeforeToolCallEvent,
        AfterToolCallEvent,
    )
    
    class GuardrailHook(HookProvider):
        def __init__(self, guardrail_id, guardrail_version, region_name, tool_names=None):
            self.client = boto3.client("bedrock-runtime", region_name=region_name)
            self.guardrail_id = guardrail_id
            self.guardrail_version = guardrail_version
            self.tool_names = tool_names  # None = apply to all tools
    
        def register_hooks(self, registry: HookRegistry, **kwargs):
            registry.add_callback(BeforeInvocationEvent, self.validate_inbound)
            registry.add_callback(BeforeToolCallEvent, self.validate_input)
            registry.add_callback(AfterToolCallEvent, self.validate_output)
    
        def _check(self, content, source="INPUT"):
            """Call Bedrock ApplyGuardrail. Returns True if content is safe."""
            response = self.client.apply_guardrail(
                guardrailIdentifier=self.guardrail_id,
                guardrailVersion=self.guardrail_version,
                source=source,  # "INPUT" applies input policies; "OUTPUT" applies output policies
                content=[{"text": {"text": content}}],
            )
            return response["action"] != "GUARDRAIL_INTERVENED"
    
        # Checkpoint 1 — BeforeInvocationEvent
        # Validates user input before model inference or tool execution occurs.
        # The model does not see blocked content.
        async def validate_inbound(self, event: BeforeInvocationEvent):
            for msg in reversed(event.messages):
                if msg.get("role") == "user":
                    for block in msg.get("content", []):
                        text = block.get("text", "")
                        if text and not self._check(text):
                            event.messages.clear()
                            event.messages.append({
                                "role": "user",
                                "content": [{"text": "Request blocked by safety guardrail."}],
                            })
                            return
                    break
    
        # Checkpoint 2 — BeforeToolCallEvent
        # Validates tool input parameters before the tool executes.
        # Skips tools not in tool_names (if a filter is set).
        async def validate_input(self, event: BeforeToolCallEvent):
            if self.tool_names and event.tool_use.get("name") not in self.tool_names:
                return
            tool_input = event.tool_use.get("input", {})
            for param_value in tool_input.values():
                if isinstance(param_value, str) and not self._check(param_value):
                    event.cancel_tool = "This request was blocked by a safety guardrail."
                    return
    
        # Checkpoint 3 — AfterToolCallEvent
        # Validates tool output before it reaches the agent.
        # Skips tools not in tool_names (if a filter is set).
        async def validate_output(self, event: AfterToolCallEvent):
            if self.tool_names and event.tool_use.get("name") not in self.tool_names:
                return
            content_parts = [
                block["text"]
                for block in event.result.get("content", [])
                if "text" in block
            ]
            content = "\n".join(content_parts)
            if content and not self._check(content, source="OUTPUT"):
                event.result = {
                    "toolUseId": event.result["toolUseId"],
                    "status": "error",
                    "content": [{"text": "Content blocked by safety guardrail."}],
                }

    Definindo ferramentas

    O Strands descobre ferramentas pelo decorator @tool, que transforma uma função Python comum em uma ferramenta que o modelo pode chamar, usando a docstring e as type hints como contrato da ferramenta. Abaixo estão dois exemplos simples usados nas seções de registro:

    from strands import tool
    
    @tool
    def web_search(query: str) -> str:
        """Search the web and return a result snippet."""
        # Replace with your actual search implementation
        return f"Search results for: {query}"
    
    @tool
    def get_customer_data(customer_id: str) -> str:
        """Retrieve customer record by ID."""
        # Replace with your actual data lookup implementation
        return f"Customer record for: {customer_id}"

    Registrando o hook

    O Strands ativa hooks pelo parâmetro hooks no construtor do Agent. Após o registro, os callbacks do hook executam automaticamente em cada evento de lifecycle correspondente, sem nenhuma alteração nas ferramentas ou na lógica do agente.

    Para um único guardrail aplicado a todas as ferramentas, crie uma instância do hook e passe-a ao agente:

    from strands import Agent
    from strands.models import BedrockModel
    from guardrail_hook import GuardrailHook
    from tools import web_search, get_customer_data  # Example tools - replace with your tools
    
    # Example model and region selection
    model = BedrockModel(
        model_id="us.anthropic.claude-sonnet-4-5",
        region_name="us-east-1",
    )
    
    guardrail_hook = GuardrailHook(
        guardrail_id="your-guardrail-id",  # Copy it from the Amazon Bedrock console > Guardrails
        guardrail_version="1",  # Use "DRAFT" for testing
        region_name="us-east-1",  # Region where the guardrails are defined
    )
    
    agent = Agent(
        model=model,
        tools=[web_search, get_customer_data],  # Example tools
        system_prompt="You are a helpful assistant.",  # Example system prompt
        hooks=[guardrail_hook],  # Applied to all tool calls
    )

    Usando guardrails diferentes por ferramenta

    Ferramentas diferentes carregam riscos diferentes. Uma ferramenta de busca na web traz conteúdo externo de sites não confiáveis e precisa de filtragem de saída rigorosa. Uma ferramenta de dados de clientes retorna registros internos e pode precisar de detecção de PII configurada de forma diferente.

    O parâmetro tool_names restringe um hook a ferramentas específicas. O Strands ainda executa todos os hooks registrados em cada evento, mas os hooks ignoram a chamada quando o nome da ferramenta não corresponde. Registre um hook por guardrail:

    from strands import Agent
    from strands.models import BedrockModel
    from guardrail_hook import GuardrailHook
    from tools import web_search, get_customer_data  # Example tools - replace with your tools
    
    # Example model and region selection
    model = BedrockModel(
        model_id="us.anthropic.claude-sonnet-4-5",
        region_name="us-east-1",
    )
    
    # Strict content filtering and PII detection for web search results
    web_search_hook = GuardrailHook(
        guardrail_id="gr-websearch-id",  # Guardrail ID with content filtering + PII detection
        guardrail_version="1",  # Or set to DRAFT
        region_name="us-east-1",  # Change to your region
        tool_names={"web_search"},  # Only applies to the web_search tool
    )
    
    # PII detection for customer data — prevents sensitive records from leaking into tool parameters
    customer_data_hook = GuardrailHook(
        guardrail_id="gr-customerdata-id",  # Guardrail ID with PII detection
        guardrail_version="1",  # Or set to DRAFT
        region_name="us-east-1",  # Change to your region
        tool_names={"get_customer_data"},  # Only applies to the get_customer_data tool
    )
    
    agent = Agent(
        model=model,
        tools=[web_search, get_customer_data],  # Example tools
        system_prompt="You are a helpful assistant.",  # Example system prompt
        hooks=[web_search_hook, customer_data_hook],  # Each hook runs only for its assigned tools
    )

    Cada guardrail é configurado de forma independente no console do Amazon Bedrock, permitindo ajustar a rigidez da validação ao nível de risco de cada ferramenta, em vez de aplicar uma política única para todo o agente.

    Testando a implementação

    Para validar o funcionamento, crie uma pasta de projeto com os seguintes arquivos:

    • guardrail_hook.py — a classe GuardrailHook
    • tools.py — as definições das ferramentas web_search e get_customer_data
    • agent.py — a configuração do agente da seção de registro do hook

    Em agent.py, adicione um prompt de teste ao final:

    # Send a test prompt
    response = agent("Search the web for the latest news on AI security.")
    print(response)

    Atualize os IDs de guardrail, a região AWS e o ID do modelo em agent.py para corresponder à sua configuração. Execute o agente a partir da pasta do projeto:

    python agent.py

    O hook de guardrail executa em cada ponto de validação. Se o prompt ou qualquer saída de ferramenta for sinalizado, você verá a mensagem de bloqueio na resposta em vez do resultado da ferramenta.

    Reutilizando o hook em toda a organização

    A classe GuardrailHook é um HookProvider independente. Construída uma vez, ela pode ser anexada a agentes Strands passando-a no parâmetro hooks. O mesmo pacote de hook pode ser publicado como uma biblioteca interna e consumido por:

    É possível trocar configurações de guardrail ou adicionar verificações como regex ou validação de schema sem tocar no código do agente ou das ferramentas.

    Conclusão

    O Amazon Bedrock Guardrails protege a fronteira do modelo, mas agentes também chamam ferramentas, consomem dados externos e retornam resultados que nunca passam pelas verificações de nível de modelo. Os três pontos de validação apresentados neste guia fecham essa lacuna usando os lifecycle hooks do Strands Agents SDK: BeforeInvocationEvent valida a entrada do usuário, BeforeToolCallEvent valida os parâmetros das ferramentas e AfterToolCallEvent valida a saída das ferramentas.

    A mesma classe GuardrailHook suporta tanto um guardrail compartilhado quanto guardrails diferentes com escopo por ferramenta, e pode ser implantada sem alterações desde o teste local até o Amazon Bedrock Agent Core Runtime.

    Para se aprofundar no tema, a AWS recomenda consultar também o OWASP Top 10 para Aplicações Agênticas, que traz as principais vulnerabilidades a considerar nesse tipo de arquitetura.

    Fonte

    Extend Amazon Bedrock Guardrails to Tool Interactions Using the Strands Agents SDK (https://aws.amazon.com/blogs/security/extend-amazon-bedrock-guardrails-to-tool-interactions-using-the-strands-agents-sdk/)

  • Workflows criativos agênticos com Amazon Quick e fal: storyboards e vídeos musicais com IA

    O problema de produção criativa que a IA sozinha não resolve

    Equipes criativas vivem sob pressão crescente: mais assets, mais formatos, mais revisões — e os recursos não crescem no mesmo ritmo. 78% dos líderes criativos afirmam que a demanda supera a capacidade de suas equipes. Mas gerar conteúdo mais rápido por si só não resolve o problema central: os roteiros, referências, modelos e resultados ficam espalhados entre ferramentas diferentes, e o contexto precisa ser remontado manualmente a cada etapa.

    Para endereçar esse desafio, a AWS publicou uma demonstração de como construir um harness agêntico reutilizável — uma estrutura que preserva contexto, suporta tarefas de mídia de longa duração e introduz revisão humana em momentos críticos do processo criativo. A solução combina o Amazon Quick, a plataforma fal e o Protocolo de Contexto de Modelo (MCP) como interface padrão de integração.

    Os quatro componentes do harness criativo

    A arquitetura proposta é dividida em quatro camadas reutilizáveis que trabalham juntas para cobrir todo o ciclo criativo:

    Amazon Quick

    O Amazon Quick é um workspace de IA agêntica voltado para pesquisa, insights de negócio, automação de fluxos e criação de aplicações sem código. Nessa solução, ele atua como a camada de orquestração: interpreta a solicitação do criador, planeja as etapas, retém as decisões aprovadas e aciona as ferramentas externas adequadas para apresentar os resultados para revisão.

    Skills (Habilidades)

    As Skills são processos repetíveis capturados como instruções reutilizáveis dentro do Amazon Quick. Uma Skill pode codificar regras como “confirmar a direção de arte antes de gerar imagens”, “criar referências de personagem antes de produzir cenas” e “pausar para aprovação em checkpoints de qualidade definidos”. Isso permite que equipes reutilizem um processo criativo em vez de reconstruí-lo do zero a cada campanha.

    fal

    A fal é uma plataforma de mídia generativa para desenvolvedores e empresas, com acesso a mais de 1.000 modelos para geração de imagem, vídeo, áudio, 3D e outras modalidades. Esses modelos cobrem exploração de personagens, geração de imagens guiada por referência, produção de áudio e criação de vídeo.

    Protocolo de Contexto de Modelo (MCP)

    O Protocolo de Contexto de Modelo (MCP) é um padrão aberto que permite que aplicações de IA se conectem a ferramentas externas e fontes de dados por meio de uma interface consistente. A fal disponibiliza suas capacidades generativas via servidor MCP, e o Amazon Quick usa seu cliente MCP para descobrir e invocar essas ferramentas.

    Benefícios da integração para equipes criativas

    Conectar o Amazon Quick à fal via MCP oferece vantagens práticas para times de produção:

    • Workspace criativo unificado: planejamento, geração, comparação e refinamento de assets acontecem em um só lugar, sem alternar entre ferramentas para cada modalidade.
    • Contexto preservado entre etapas: escolhas de estilo aprovadas, referências de personagem, beats narrativos e requisitos de formato permanecem no contexto de trabalho ao longo de todo o projeto.
    • Julgamento humano nos gates criativos: o agente pode pausar após etapas-chave para que o criador escolha uma direção antes de gerar os assets seguintes.
    • Acesso a múltiplos modelos generativos: equipes usam modelos diferentes para imagem, áudio e vídeo por meio de uma única conexão MCP.
    • Práticas de produção repetíveis: as Skills do Amazon Quick codificam as etapas preferidas da equipe, permitindo que outros membros sigam o mesmo processo com os mesmos checkpoints de qualidade.
    • Validação de conceito mais rápida: é possível avaliar um storyboard ou conceito de vídeo antes de comprometer recursos com uma produção completa.

    Visão geral da arquitetura

    A arquitetura separa a orquestração do fluxo de trabalho da geração de mídia. O Amazon Quick funciona como workspace agêntico e cliente MCP, enquanto a fal hospeda o servidor MCP e fornece as ferramentas generativas. As Skills capturam instruções de fluxo reutilizáveis, e o MCP oferece a interface consistente para descobrir e invocar as capacidades da fal em diferentes workflows de mídia.

    O criador descreve o resultado desejado no Amazon Quick, que aciona as ferramentas apropriadas via conector MCP da fal. A fal processa cada solicitação e retorna o asset gerado para revisão. O criador pode então aprovar o resultado, solicitar revisões ou gerar assets adicionais.

    Como configurar a integração

    Pré-requisitos

    • Acesso ao Amazon Quick com o aplicativo desktop instalado e autenticado.
    • Conta na fal e uma chave de API disponível para a integração.
    • Permissão para adicionar e configurar um conector remoto de Protocolo de Contexto de Modelo (MCP) no Amazon Quick.

    Passo 1: Obter a chave de API da fal

    Acesse o painel da fal, crie uma nova chave de API para a integração ou recupere uma existente. Armazene a chave com segurança e não a inclua em capturas de tela, arquivos de código ou documentos compartilhados.

    Passo 2: Conectar o servidor MCP da fal ao Amazon Quick

    No aplicativo desktop do Amazon Quick, acesse Settings → Capabilities → Connectors e escolha Add MCP Server: Remote. Para a URL, informe https://mcp.fal.ai/mcp. No campo de cabeçalho, insira Authorization: Key SUA_CHAVE_API_FAL.

    Passo 3: Validar as ferramentas da fal

    Salve o conector e confirme que o Amazon Quick consegue descobrir as ferramentas expostas pelo servidor MCP da fal. Após a conexão estar ativa, inicie uma nova conversa no Amazon Quick para verificar o funcionamento.

    Workflow 1: Produção de storyboard em oito painéis

    O primeiro exemplo mostra como uma equipe de marketing pode criar um storyboard de oito painéis para o lançamento de um produto. Em um processo tradicional, isso envolveria briefing, designer, três rodadas de feedback e uma semana de trabalho. Com o Amazon Quick, o mesmo trabalho acontece em uma sessão interativa como um loop agêntico: o Quick planeja, gera, apresenta opções, aguarda aprovação e continua.

    O prompt utilizado no exemplo é:

    Create an 8-panel storyboard for a futuristic racing-prototype launch. Use an anime style and comic-grid layout. The story follows a young racer from pre-test preparation and the prototype reveal through a high-speed test drive. Follow this sequence:
    1. Lock the creative direction: Confirm the art style, comic-grid format, aspect ratio, and restrictions.
    2. Approve the story plan: Draft eight story beats, a shot list, and the character description.
    3. Lock the character design: After approval, inspect the available fal models and generate two labeled character options for comparison. Once I select one, create its multi-view reference sheet and wait for approval before generating storyboard panels.

    Etapa 1: Definir estilo, formato e plano narrativo

    O Quick confirma o estilo anime, o layout de grid de quadrinhos, a proporção e as restrições visuais, transportando essas definições para todas as chamadas seguintes. Em seguida, produz um esboço escrito com oito beats narrativos, lista de planos e descrição do personagem — sem gerar imagens nessa etapa. O criador pode revisar a história, o ritmo, o tratamento do personagem ou a direção visual antes de aprovar o plano.

    Etapa 2: Explorar e definir o design do personagem

    Após a aprovação do plano escrito, o Quick inspeciona os modelos disponíveis na fal e gera dois designs alternativos de personagem para comparação. O criador seleciona a opção que melhor corresponde à campanha pretendida. Em seguida, o Quick cria um pacote de referência mostrando o personagem selecionado de frente e de costas, em múltiplas poses com capacete e em close-up facial. Nenhum painel do storyboard é gerado até que essa referência seja aprovada.

    Etapa 3: Geração de painéis guiada por referência

    Com o design do personagem aprovado, o Quick usa o modelo FLUX.1 Kontext para gerar cada painel, fornecendo as referências aprovadas do personagem em cada chamada para preservar a identidade visual ao longo das cenas.

    Etapa 4: Renderização final

    Após os oito painéis serem aprovados, o Quick os organiza na ordem da lista de planos e adiciona legendas para criar um visualizador interativo de storyboard. O criador pode revisar e ajustar painéis individuais antes de apresentar o storyboard no formato grid de quadrinhos, scroll ou slideshow — sem regenerar as imagens já aprovadas.

    Etapa 5: Converter o workflow em uma Skill reutilizável

    Após validar o processo, o criador pode pedir ao Quick para criar uma Skill chamada “AI Storybuilding” a partir da conversa. A Skill captura todas as etapas: confirmação da direção criativa, planejamento narrativo escrito, comparação A/B de designs de personagem, criação de folha de referência multi-ângulo, aprovação antes da geração de painéis, geração guiada por referência e revisão final. As Skills no Amazon Quick são fluxos compartilháveis — uma pessoa captura o processo validado e outros membros da equipe o executam com os mesmos checkpoints de qualidade.

    Workflow 2: Prototipagem de conceito de videoclipe

    O segundo workflow reutiliza uma Skill salva para levar um conceito de videoclipe do briefing até um preview com lip-sync.

    Etapa 1: Ativar a Skill existente

    A equipe já possui uma Skill compartilhada de “Music Video Prototyping” no Amazon Quick, que codifica coleta de briefing, planejamento de planos, geração de música, referências de personagem, gates de aprovação criativa, testes de movimento e lip-sync, aprovação de substituição de modelo e entrega de assets. O criador inicia com o prompt:

    Use the Music Video Prototyping Skill to create a 60-second country music video concept. Generate the song, design the characters, and produce a lip-synced video preview.

    O Quick ativa a Skill, coleta os requisitos ausentes e segue o fluxo e os gates de aprovação salvos.

    Etapa 2: Planejar a produção

    O Quick decompõe o conceito em planos individuais, identificando os close-ups de performance que precisam de lip-sync, os planos de estabelecimento e B-roll, as referências de personagem necessárias e o áudio para cada sequência. O criador revisa o plano de planos antes de iniciar a geração de mídia.

    Etapa 3: Gerar música e referências visuais

    Após a aprovação, o Quick gera uma trilha de música country com os modelos de áudio disponíveis via fal, cria referências de personagem para consistência visual e produz os stills de cena e trechos de áudio necessários para os planos planejados.

    Etapa 4: Produzir e revisar um teste de lip-sync

    Antes de gerar o vídeo completo, o Quick produz um clipe curto de performance com lip-sync. O criador pode avaliar o movimento facial, o timing, a qualidade da performance e a consistência visual antes de continuar.

    Etapa 5: Avançar para o preview completo do conceito

    Após validar a música, a direção do personagem e o teste de lip-sync, o criador pode continuar prototipando o vídeo. O Quick pode criar o storyboard da sequência restante, gerar stills de cena, testar um plano com movimento animado e salvar os assets aprovados. O criador então monta esses assets em um preview mais longo do conceito.

    Considerações operacionais

    • Prefira saída em JPEG quando transparência e qualidade lossless não forem necessárias, pois assets menores reduzem os dados transferidos pela conexão MCP.
    • Monitore o uso e os custos da fal durante workflows com geração intensiva.
    • Em sessões longas, salve os assets aprovados externamente e processe o trabalho em lotes gerenciáveis.
    • Trate a chave de API da fal como um segredo: armazene-a apenas na configuração do conector, restrinja o acesso, faça rotação se for exposta e não a inclua em prompts, arquivos, capturas de tela ou logs.
    • Como a fal é um serviço de terceiros, envie apenas conteúdo aprovado, siga os requisitos de tratamento de dados da sua organização e revise os resultados antes de compartilhá-los.

    Conclusão

    A integração entre Amazon Quick e fal demonstra um padrão de harness agêntico voltado para produção de mídia. O Amazon Quick orquestra o fluxo e captura a lógica reutilizável em Skills; o MCP fornece o contrato de ferramentas compartilhado; e a fal disponibiliza as capacidades de imagem, áudio e vídeo. O valor da integração não está apenas em produzir um asset isolado — está em coordenar o loop criativo completo: estabelecer direção, gerar alternativas, preservar referências aprovadas, pausar para julgamento humano e montar um protótipo.

    Para experimentar esse padrão, a AWS recomenda seguir o guia de integração MCP do Amazon Quick para configurar o conector da fal, validar as ferramentas disponíveis e iniciar com um workflow criativo com gates de aprovação.

    Fonte

    Build agentic creative workflows with Amazon Quick and fal (https://aws.amazon.com/blogs/machine-learning/build-agentic-creative-workflows-with-amazon-quick-and-fal/)

  • Deepgram amplia observabilidade de IA no Amazon SageMaker com métricas aprimoradas

    O problema clássico de observabilidade em IA de fala auto-hospedada

    Quem já operou modelos de inteligência artificial em infraestrutura própria conhece bem um limite frustrante: as métricas padrão de endpoint dizem que o serviço está de pé e quantas requisições foram atendidas, mas as perguntas que realmente importam para planejamento de capacidade e gestão de custos ficam escondidas dentro do contêiner do fornecedor. O que exatamente está sendo cobrado? Quais funcionalidades o tráfego está usando? O que o motor de inferência está fazendo em cada Unidade de Processamento Gráfico (GPU)?

    A Deepgram anunciou duas inovações para fechar exatamente essa lacuna em deployments dos seus modelos de fala no Amazon SageMaker AI. As novidades chegam disponíveis hoje para quem utiliza os modelos de Reconhecimento de Fala para Texto (STT) e Síntese de Fala a partir de Texto (TTS) da Deepgram no SageMaker AI.

    Como a Deepgram opera no Amazon SageMaker AI

    Os modelos de fala da Deepgram estão disponíveis como pacotes de modelo no AWS Marketplace e são implantados como endpoints em tempo real no SageMaker AI, dentro da conta do próprio cliente. Essa arquitetura significa que o áudio e as transcrições ficam dentro da conta AWS do cliente, o que pode apoiar requisitos de residência de dados e conformidade regulatória — sem abrir mão de um plano de controle gerenciado para deploy, escalonamento e monitoramento.

    O SageMaker AI já entrega observabilidade básica automaticamente: métricas de invocação como ConcurrentRequestsPerModel e FirstChunkLatency no CloudWatch, logs de contêiner no Amazon CloudWatch Logs e escalonamento automático via alarmes. Os pacotes de modelo do AWS Marketplace rodam com isolamento de rede — o contêiner não faz conexões de saída, o que é justamente o motivo pelo qual clientes com requisitos de segurança mais rígidos escolhem esse modelo de implantação.

    O desafio é que esse mesmo isolamento costuma dificultar a telemetria do fornecedor: o contêiner não consegue enviar métricas para um coletor externo, e não há como enxergar o que acontece dentro dele. As duas novidades da Deepgram foram projetadas para funcionar dentro dessa restrição — nenhuma delas exige que o contêiner abra um caminho de rede, e ambas entregam os dados na própria conta CloudWatch do cliente.

    Inovação 1 — Transparência de faturamento e uso com Deepgram Enhanced Metrics

    As Deepgram Enhanced Metrics respondem duas perguntas que nenhuma métrica padrão de endpoint consegue responder: exatamente o que está sendo cobrado e como o tráfego utiliza as funcionalidades da Deepgram.

    Como funciona: métricas que viajam pelo caminho de log

    O contêiner da Deepgram escreve registros no formato Formato de Métrica Embarcada do CloudWatch (EMF) no stdout do contêiner. O SageMaker AI já encaminha a saída do contêiner para o grupo de logs do CloudWatch do endpoint, e o CloudWatch Logs extrai os registros EMF em métricas automaticamente.

    Esse caminho via EMF traz vantagens práticas importantes:

    • Nenhum agente, sidecar ou coletor adicional para implantar.
    • Nenhuma permissão de Gerenciamento de Identidade e Acesso (IAM) adicional além do que o endpoint já possui para logging.
    • Funciona sob o isolamento de rede do AWS Marketplace, porque as métricas trafegam pelo caminho de logging já existente entre o SageMaker e o CloudWatch.
    • São métricas CloudWatch convencionais — aparecem no aws cloudwatch list-metrics e funcionam com dashboards, alarmes e operações matemáticas sobre métricas, sem nenhuma configuração adicional no endpoint.

    Todas as dimensões são de baixa cardinalidade e não contêm Informações de Identificação Pessoal (PII): nenhuma transcrição, entrada de TTS ou identificador por requisição. As métricas são agregadas pelos endpoints da Deepgram na conta e região AWS do cliente — as dimensões cobrem categoria, modelo e transporte, mas não o nome do endpoint ou ID da instância.

    Reconciliar a fatura do AWS Marketplace: o namespace Deepgram/SageMakerInference

    O namespace de faturamento emite um registro por requisição concluída, cobrindo cada sessão de streaming, requisição de áudio pré-gravado e requisição de TTS. A métrica ConsumedUnits carrega os mesmos valores de unidades faturáveis que alimentam o faturamento medido do AWS Marketplace.

    As métricas publicadas nesse namespace são:

    • ConsumedUnits — Unidades de inferência faturáveis para a requisição. A soma em um período representa o volume total cobrado.
    • AudioDurationSeconds — Duração do áudio processado (STT).
    • CharCount — Caracteres sintetizados (TTS).

    As dimensões são publicadas em três granularidades ([Category], [Category, Model] e [Category, Model, Transport]), permitindo responder tanto “quanto o STT em streaming custou este mês” quanto “quanto disso foi com o modelo nova-3”.

    Exemplo de consulta para total de unidades consumidas por hora no STT em streaming:

    aws cloudwatch get-metric-statistics \
      --namespace Deepgram/SageMakerInference \
      --metric-name ConsumedUnits \
      --dimensions Name=Category,Value=stt_streaming \
      --start-time $(date -u -d '24 hours ago' +%Y-%m-%dT%H:%M:%S) \
      --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
      --period 3600 \
      --statistics Sum SampleCount \
      --region YOUR_AWS_REGION

    O SampleCount representa o número de requisições faturadas. Por serem métricas CloudWatch convencionais, é possível construir um dashboard de faturamento para times financeiros ou configurar um alarme de orçamento sobre as unidades consumidas.

    Entender como o endpoint é utilizado: o namespace Deepgram/SelfHosted

    Um segundo fluxo de métricas, emitido pelo próprio servidor da API Deepgram, detalha o uso bruto por método, nível de modelo e funcionalidade habilitada — independente do faturamento. Ele responde perguntas de produto: quanto do tráfego é streaming versus pré-gravado, quais camadas de modelo processam mais áudio, e quais funcionalidades (diarização, formatação inteligente, redação, prompting por termos-chave) as aplicações realmente habilitam.

    As métricas desse namespace incluem:

    • AudioMs, Requests — Volume por streaming comparado a pré-gravado.
    • TierAudioMs — Áudio processado por nível de modelo (ex: nova-3, flux).
    • FeatureAudioMs, FeatureTokens — Utilização por funcionalidade habilitada (ex: diarize, smart_format, redact).
    • TtsCharacters, Tokens, VoiceAgentMs — Volume de TTS, funcionalidades de inteligência e agente de voz.

    Exemplo: quanto áudio rodou com diarização habilitada nas últimas 24 horas:

    aws cloudwatch get-metric-statistics \
      --namespace Deepgram/SelfHosted \
      --metric-name FeatureAudioMs \
      --dimensions Name=Deployment,Value=sagemaker Name=Feature,Value=diarize \
      --start-time $(date -u -d '24 hours ago' +%Y-%m-%dT%H:%M:%S) \
      --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
      --period 3600 \
      --statistics Sum \
      --region YOUR_AWS_REGION

    O fluxo de uso está habilitado por padrão e pode ser desativado com uma variável de ambiente na configuração do endpoint (DEEPGRAM_API_01: emf.enabled=false). O fluxo de faturamento não pode ser desativado — ele faz parte do pipeline de medição.

    Inovação 2 — Visibilidade em nível de engine e por GPU com Prometheus e OpenTelemetry

    Os contêineres da Deepgram servem um endpoint de métricas Prometheus, e a observabilidade detalhada do SageMaker AI executa um Coletor OpenTelemetry gerenciado pela AWS em cada instância que sustenta o endpoint. Esse coletor faz o scrape do contêiner e exporta os resultados para o CloudWatch, além de exportar métricas por GPU e do host.

    Com a observabilidade detalhada habilitada, três fontes de métricas publicam no armazenamento de métricas compatível com OpenTelemetry (OTel) do CloudWatch:

    • GPU (exportador DCGM) — Métricas como DCGM_FI_DEV_GPU_UTIL e DCGM_FI_DEV_FB_USED. Em instâncias com múltiplas GPUs, cada GPU reporta separadamente — um dispositivo saturado não consegue se esconder por trás de um número de utilização somado ou médio.
    • Host (node exporter) — Métricas padrão do node-exporter Prometheus, como node_cpu_seconds_total e node_memory_MemTotal_bytes, para cada instância.
    • Engine Deepgram — O coletor faz scrape diretamente do endpoint Prometheus do contêiner Deepgram. Exemplos: engine_active_requests{kind="stream"} e engine_estimated_stream_capacity. São as mesmas métricas de API e Engine que os clientes self-hosted da Deepgram usam para planejamento de capacidade, agora disponíveis no SageMaker AI sem precisar rodar nenhum coletor próprio. Consulte o Guia de Métricas da Deepgram para a referência completa.

    A métrica engine_estimated_stream_capacity é a estimativa do próprio motor Deepgram de quantos streams simultâneos a instância consegue sustentar. Comparar esse valor com engine_active_requests fornece um sinal de headroom reportado pelo engine para decisões de escalonamento.

    Cada série carrega rótulos de recurso do SageMaker, incluindo aws.sagemaker.endpoint.name, o nome da variante e o ID da instância — o que permite filtrar por endpoint específico, isolar uma instância em uma frota escalada ou comparar GPUs dentro de uma mesma instância. Como o coletor roda no host, fora do contêiner do modelo, isso funciona mesmo sob o isolamento de rede do AWS Marketplace.

    Como habilitar a observabilidade detalhada

    A observabilidade detalhada vem habilitada por padrão em endpoints criados recentemente, publicando a cada 60 segundos. Para configurar explicitamente — por exemplo, em um endpoint criado antes do lançamento do recurso, ou para alterar a frequência de publicação — use o MetricsConfig na configuração do endpoint:

    aws sagemaker create-endpoint-config \
      --endpoint-config-name YOUR_CONFIG_NAME \
      --production-variants file://production-variants.json \
      --metrics-config '{"EnableDetailedObservability": true, "MetricPublishFrequencyInSeconds": 60}' \
      --region YOUR_AWS_REGION

    Para um endpoint já em serviço, basta criar uma nova configuração de endpoint e executar update-endpoint. A atualização é um deploy blue/green — o endpoint permanece em serviço durante a transição.

    Consultas com PromQL a partir do CloudWatch, Grafana ou qualquer ferramenta compatível

    As métricas ficam no armazenamento de métricas OTel do CloudWatch e são consultadas com PromQL. No editor PromQL do console do CloudWatch, é possível filtrar a utilização por GPU para um endpoint específico:

    DCGM_FI_DEV_GPU_UTIL{"aws.sagemaker.endpoint.name"="YOUR_ENDPOINT_NAME"}

    O CloudWatch também expõe uma API HTTP padrão compatível com Prometheus para essas métricas, autenticada com SigV4:

    awscurl --service monitoring --region YOUR_AWS_REGION \
      "https://monitoring.YOUR_AWS_REGION.amazonaws.com/api/v1/query?query=engine_active_requests"

    Para equipes que já padronizaram em Grafana ou outra stack de observabilidade nativa do Prometheus, é possível apontar as ferramentas existentes para a frota do SageMaker AI — sem uma stack de monitoramento paralela, sem pipeline de exportação.

    Qual fluxo de métricas usar para cada situação

    As duas inovações complementam as métricas nativas do SageMaker AI, sem substituí-las. O mapeamento de perguntas para o fluxo correto é o seguinte:

    • O endpoint está saudável? As requisições estão com erro ou lentidão no início? → Métricas padrão do SageMaker (ConcurrentRequestsPerModel, FirstChunkLatency, Invocation5XXErrors).
    • Qual será minha fatura no Marketplace e quais modelos a geraram? → Deepgram Enhanced Metrics (namespace Deepgram/SageMakerInference, nível de conta).
    • Quais funcionalidades e camadas de modelo meu tráfego realmente usa? → Deepgram Enhanced Metrics (namespace Deepgram/SelfHosted, nível de conta).
    • Qual é a saturação de cada GPU? Quanto de capacidade de stream resta em cada instância de um endpoint específico? → Prometheus/OTel via observabilidade detalhada (métricas DCGM e engine Deepgram, por endpoint/instância/GPU).

    Como começar

    As Deepgram Enhanced Metrics não exigem nenhuma configuração: elas fluem para a conta CloudWatch do cliente a partir do momento em que um endpoint Deepgram no SageMaker AI começa a servir tráfego. A observabilidade detalhada já vem habilitada por padrão em novos endpoints e requer apenas uma mudança na configuração do endpoint para ser adicionada aos existentes.

    Para começar, os recursos disponíveis são:

    Vale destacar que rodar modelos Deepgram no SageMaker AI gera cobranças pela hospedagem do endpoint (incluindo instâncias GPU), pelos logs e métricas do Amazon CloudWatch e pelos recursos de rede associados. O trial de 14 dias dos modelos Deepgram não tem custo adicional, mas os custos de infraestrutura AWS se aplicam desde o início do deploy. Recomenda-se revisar a precificação do SageMaker AI e usar o AWS Cost Explorer para monitorar os gastos.

    Conclusão

    A Deepgram fecha uma lacuna que existia há muito tempo: a distância entre os contadores de requisição do serviço e a fatura do fornecedor. Com as Enhanced Metrics, os valores exatos que alimentam o faturamento do AWS Marketplace chegam diretamente na conta CloudWatch do cliente, sem infraestrutura adicional. O detalhamento de uso por funcionalidade também fica disponível no mesmo lugar.

    Com o suporte a Prometheus e OpenTelemetry via observabilidade detalhada do SageMaker AI, as métricas de capacidade e carga do próprio motor Deepgram — junto com a utilização por GPU — ficam a uma consulta PromQL de distância, nas ferramentas que o time já utiliza. Essas capacidades seguem o investimento da Deepgram no SageMaker AI como opção preferencial de deploy para IA de fala auto-hospedada, após a introdução da Delegação Temporária IAM para acesso de suporte.

    Fonte

    Deepgram deepens Amazon SageMaker AI observability with Enhanced Metrics (https://aws.amazon.com/blogs/machine-learning/deepgram-deepens-amazon-sagemaker-ai-observability-with-enhanced-metrics/)

  • Modelos OpenAI no Amazon Bedrock com inferência local na Índia

    O que foi anunciado

    A AWS anunciou suporte aos modelos OpenAI GPT-5.6 Terra e Luna no Amazon Bedrock com inferência geográfica restrita à Índia. Isso significa que organizações com requisitos de processamento local de dados — como instituições financeiras, empresas de saúde e órgãos do setor público — podem usar esses modelos em escala sem que nenhum dado saia do território indiano.

    Ambos os modelos oferecem uma janela de contexto de 1 milhão de tokens, aceitam entrada de texto e imagem, e produzem saída em texto. Com essa capacidade, uma única requisição pode processar documentos longos, bases de código extensas ou cargas de trabalho mistas com texto e imagem.

    Como funciona a inferência geográfica na Índia

    O Amazon Bedrock já oferece inferência entre regiões (cross-Region inference) como mecanismo de capacidade: em vez de ficar limitado à capacidade de uma única região, as requisições são distribuídas automaticamente por um pool maior de computação. Isso ajuda a manter a taxa de transferência e o desempenho consistente, especialmente em picos de tráfego.

    No caso da Índia, o roteamento acontece exclusivamente entre as regiões Ásia-Pacífico (Mumbai) ap-south-1 e Ásia-Pacífico (Hyderabad) ap-south-2. Você pode fazer chamadas a partir de qualquer uma das duas regiões como origem, e o Bedrock decide qual região de destino atende a requisição com base na capacidade disponível.

    Para consultar a disponibilidade atualizada por modelo e região, a AWS disponibiliza a documentação de disponibilidade regional por modelos no Guia do Usuário do Amazon Bedrock.

    Perfis de inferência geográfica

    A inferência entre regiões funciona por meio de perfis de inferência. Você passa o ID do perfil como parâmetro de modelo na chamada de API, e ele define tanto o modelo quanto as regiões para as quais o Bedrock pode rotear a requisição. Os dois perfis disponíveis para a Índia são:

    • in.openai.gpt-5.6-terra — para o GPT-5.6 Terra
    • in.openai.gpt-5.6-luna — para o GPT-5.6 Luna

    Com esses perfis, a cobrança e o consumo de cotas são contabilizados na conta da região de origem, independentemente de qual região de backend processou a requisição. Logs do Amazon CloudWatch e do AWS CloudTrail também são registrados apenas na região de origem, o que simplifica o monitoramento.

    Endpoint recomendado: bedrock-runtime

    Para novas aplicações, a AWS recomenda o uso do endpoint bedrock-runtime. Ele suporta as APIs nativas do Bedrock — InvokeModel e Converse — além das APIs compatíveis com OpenAI (Responses e Chat Completions) e a API Messages da Anthropic. É também nesse endpoint que recursos como Guardrails, roteamento inteligente de prompts e inferência entre regiões estão disponíveis.

    Residência de dados e segurança

    O perfil geográfico da Índia garante que a inferência permaneça dentro do país: as requisições só trafegam entre ap-south-1 e ap-south-2, com criptografia em trânsito pela rede da Amazon.

    O Amazon Bedrock adota um modelo de segurança de dados com retenção zero (ZDR — Zero Data Retention): por padrão, entradas e saídas dos modelos não são armazenadas. No entanto, para determinados modelos, incluindo o GPT-5.6, conteúdo sinalizado pelos classificadores automáticos de detecção de abuso do Bedrock pode ser retido para análise offline. Para mais detalhes, consulte a documentação sobre detecção de abuso no Guia do Usuário do Amazon Bedrock.

    Inferência global também disponível

    Além dos perfis geográficos da Índia, o Bedrock oferece perfis de inferência global (prefixo global.) que roteiam requisições para regiões comerciais da AWS ao redor do mundo, maximizando a capacidade disponível. Esses perfis suportam os modelos GPT-5.6, incluindo Sol, Terra e Luna. Porém, se o seu workload tiver requisitos de processamento local de dados, use os perfis com prefixo in., que mantêm a inferência dentro da Índia. Para saber mais sobre inferência global, consulte o post Introdução à inferência entre regiões para modelos OpenAI GPT-5.6 no Amazon Bedrock.

    Como chamar os modelos GPT-5.6

    Via OpenAI Responses API

    Os modelos GPT-5.6 no Amazon Bedrock suportam nativamente o formato da OpenAI Responses API. Se sua aplicação já utiliza o SDK da OpenAI, basta apontar o cliente para o endpoint do Bedrock em uma das regiões da Índia e passar o ID do perfil de inferência geográfica como parâmetro de modelo.

    Para autenticação, o Bedrock aceita credenciais AWS padrão ou uma chave de API do Amazon Bedrock. Para produção, a recomendação é gerar chaves de curta duração programaticamente com o pacote aws-bedrock-token-generator. O exemplo abaixo usa o endpoint de Mumbai (ap-south-1) com o perfil geográfico do GPT-5.6 Terra:

    from aws_bedrock_token_generator import provide_token
    from openai import OpenAI
    
    # Point the OpenAI SDK at the Amazon Bedrock OpenAI-compatible
    # endpoint in the Asia Pacific (Mumbai) Region.
    client = OpenAI(
        base_url="https://bedrock-runtime.ap-south-1.amazonaws.com/openai/v1",
        api_key=provide_token(region="ap-south-1"), # short-term Amazon Bedrock API key, valid up to 12 hours
    )
    
    # Geographic (India) inference profile ID for GPT-5.6 Terra.
    model_id = "in.openai.gpt-5.6-terra" # "in.openai.gpt-5.6-luna" for luna
    
    response = client.responses.create(
        model=model_id,
        input="Extract the payment due date and total amount from the invoice text that follows, and return them as JSON. <invoice text>",
        max_output_tokens=512,
    )
    print(response.output_text)

    Controlando a profundidade de raciocínio

    Para controlar a profundidade de raciocínio, utilize o parâmetro opcional reasoning, por exemplo reasoning={"effort": "low"}. Os modelos GPT-5.6 no Bedrock suportam os seguintes níveis de esforço: none, low, medium, high, xhigh e max. Para mais informações, consulte o post Introdução aos modelos OpenAI GPT-5.6 Sol, Terra e Luna no Amazon Bedrock. Omitir o parâmetro usa o padrão do modelo.

    response = client.responses.create(
        model="in.openai.gpt-5.6-terra",
        input="Extract the payment due date and total amount from the invoice text that follows, and return them as JSON. <invoice text>",
        reasoning={"effort": "high"}, # none | low | medium | high | xhigh | max
        max_output_tokens=512,
    )

    Para a lista completa de parâmetros suportados, consulte a documentação dos modelos OpenAI no Guia do Usuário do Amazon Bedrock.

    Conversas multi-turno com estado no servidor

    Defina store=True para que o Bedrock retenha a resposta no servidor. Em seguida, referencie-a no próximo turno com previous_response_id. Assim, você envia apenas o novo turno, sem precisar reenviar o histórico completo da conversa:

    first = client.responses.create(
        model="in.openai.gpt-5.6-terra",
        input="Remember this: my favorite number is 42. Reply with just 'stored'..",
        max_output_tokens=50,
        store=True,
    )
    
    second = client.responses.create(
        model="in.openai.gpt-5.6-terra",
        previous_response_id=first.id, # the model recalls the earlier turn
        input="what is my favourite number?",
        max_output_tokens=50,
        store=True,
    )
    print(second.output_text)

    Importante: se você encadear com previous_response_id, a resposta referenciada deve ter sido criada com store=True. Encadear a partir de uma resposta não armazenada retorna erro.

    Respostas em streaming

    stream = client.responses.create(
        model="in.openai.gpt-5.6-terra",
        input="Draft a short status update for a delayed shipment, in a polite and direct tone.",
        max_output_tokens=512,
        stream=True,
    )
    
    for event in stream:
        if event.type == "response.output_text.delta":
            print(event.delta, end="")

    Via Amazon Bedrock Converse API

    Se você preferir o SDK da AWS com autenticação SigV4 em vez de uma chave de API, a Converse API do Amazon Bedrock também suporta os modelos GPT-5.6 com a mesma interface unificada disponível para outros modelos no Bedrock:

    import boto3
    
    # Standard AWS credentials (SigV4), no API key needed.
    client = boto3.client("bedrock-runtime", region_name="ap-south-1")
    model_id = "in.openai.gpt-5.6-terra" # India Geo inference profile
    
    response = client.converse(
        modelId=model_id,
        messages=[
            {
                "role": "user",
                "content": [{"text": "Classify this support ticket as billing, technical, or account: <ticket text>"}],
            }
        ],
        inferenceConfig={"maxTokens": 512},
    )
    print(response["output"]["message"]["content"]

    Cache de prompts

    Quando os prompts compartilham um prefixo longo e estável — como instruções de sistema, trechos de base de conhecimento ou exemplos de few-shot — os modelos GPT-5.6 no Bedrock suportam cache de prompts. Leituras em cache são cobradas com 90% de desconto em relação aos tokens de entrada não cacheados, o que representa economia significativa em workloads de Geração Aumentada por Recuperação (RAG — Retrieval Augmented Generation) e agentes que repetem o mesmo contexto em muitos turnos. Mais detalhes estão disponíveis na documentação de cache de prompts do Amazon Bedrock.

    O cache de prompts funciona com os perfis de inferência geográfica da Índia, mantendo a economia dentro do limite de residência de dados do país. Ele opera em dois modos: implícito (o Bedrock define os pontos de cache automaticamente, com prefixo mínimo de 1.024 tokens) e explícito (você marca o limite de cache manualmente, e o prefixo cacheado permanece ativo por pelo menos 30 minutos).

    response = client.responses.create(
        model="in.openai.gpt-5.6-terra",
        prompt_cache_key="ticket-agent-ver123", # same key across all requests
        input=[
            {
                "type": "message",
                "role": "developer",
                "content": [{
                    "type": "input_text",
                    "text": SYSTEM_INSTRUCTIONS, # long, static: guidelines, KB excerpts (>= 1,024 tokens)
                    "prompt_cache_breakpoint": {"mode": "explicit"},
                }],
            },
            {
                "type": "message",
                "role": "user",
                "content": [{
                    "type": "input_text",
                    "text": user_question, # changes on every request
                }],
            },
        ],
        extra_body={"prompt_cache_options": {"mode": "explicit"}},
    )

    Cada resposta informa o que o cache fez, em usage.input_tokens_details:

    details = response.usage.input_tokens_details
    print(f"cached: {details.cached_tokens}, written: {details.cache_write_tokens}")

    Na primeira chamada, cache_write_tokens será preenchido à medida que o prefixo é armazenado. Nas chamadas seguintes, os mesmos tokens retornam como cached_tokens, cobrados à taxa de leitura de cache.

    Permissões do IAM para inferência geográfica na Índia

    Para permitir que uma função do Gerenciamento de Identidade e Acesso da AWS (IAM — Identity and Access Management) invoque os modelos GPT-5.6 pelo perfil de inferência geográfica da Índia, é necessário conceder acesso a três recursos: o próprio perfil de inferência geográfica, o modelo de fundação (FM — Foundation Model) na região de origem e o FM em cada região de destino listada no perfil (ap-south-1 e ap-south-2). Você pode usar a política gerenciada AmazonBedrockLimitedAccess ou criar a sua própria.

    O exemplo abaixo concede permissão para usar o modelo GPT-5.6 Terra pelo perfil de inferência geográfica da Índia. A região de origem é ap-south-1 e as regiões de destino são ap-south-1 e ap-south-2. Substitua <ACCOUNT> pelo ID da sua conta e duplique os recursos para in.openai.gpt-5.6-luna se a função precisar de ambos os modelos. Se você originar de Hyderabad, use o ARN do perfil de inferência de ap-south-2 no primeiro statement:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "GrantGeoCrisInferenceProfileAccess",
          "Effect": "Allow",
          "Action": [
            "bedrock:InvokeModel*"
          ],
          "Resource": [
            "arn:aws:bedrock:ap-south-1:<ACCOUNT>:inference-profile/in.openai.gpt-5.6-terra",
            "arn:aws:bedrock:ap-south-1:<ACCOUNT>:project/default"
          ]
        },
        {
          "Sid": "GrantGeoCrisModelAccess",
          "Effect": "Allow",
          "Action": [
            "bedrock:InvokeModel*"
          ],
          "Resource": [
            "arn:aws:bedrock:ap-south-1::foundation-model/openai.gpt-5.6-terra",
            "arn:aws:bedrock:ap-south-2::foundation-model/openai.gpt-5.6-terra"
          ],
          "Condition": {
            "StringEquals": {
              "bedrock:InferenceProfileArn": "arn:aws:bedrock:ap-south-1:<ACCOUNT>:inference-profile/in.openai.gpt-5.6-terra"
            }
          }
        },
        {
          "Sid": "AllowBearerTokenAuth",
          "Effect": "Allow",
          "Action": ["bedrock:CallWithBearerToken"],
          "Resource": "*"
        }
      ]
    }

    Se sua organização usa Políticas de Controle de Serviço (SCP — Service Control Policies) para bloquear regiões não utilizadas, as condições específicas de região do SCP devem permitir todas as regiões de destino listadas no perfil de inferência geográfica. Para o perfil da Índia, tanto ap-south-1 quanto ap-south-2 devem estar liberadas. Bloquear qualquer região de destino fará a inferência entre regiões falhar, mesmo que a região de origem permaneça acessível.

    Configurando o Codex com GPT-5.6 no Amazon Bedrock

    O Codex pode usar os perfis de inferência geográfica via Amazon Bedrock Runtime. Para isso, instale a versão mais recente do Codex CLI (codex-cli 0.149.1 ou superior). Para organizações cujo provedor de identidade é Okta, Auth0, Microsoft Entra ID, Amazon Cognito ou AWS IAM Identity Center, o repositório AWS OIDC Auth Helper fornece um helper de credenciais de exemplo.

    Após configurar o provedor de identidade e o perfil AWS correspondente, crie ou atualize o arquivo ~/.codex/config.toml referenciando o perfil AWS. Consulte a referência de configuração do Codex para outras configurações suportadas:

    model = "in.openai.gpt-5.6-terra"
    model_provider = "amazon-bedrock-runtime"
    model_reasoning_effort = "high"
    
    [model_providers.amazon-bedrock-runtime.aws]
    profile = "<AWS_OIDC_PROFILE>"
    region = "ap-south-1"

    Para usar na região Ásia-Pacífico (Hyderabad), defina a região como ap-south-2 no perfil AWS e na configuração do Codex. Se você já tiver credenciais AWS configuradas localmente, o Codex pode usá-las diretamente — basta apontar o provedor Amazon Bedrock Runtime para um perfil AWS e uma região da Índia, definindo o modelo como um ID de perfil de inferência geográfica da Índia.

    Monitoramento e logs

    Os perfis de inferência geográfica da Índia funcionam com os mesmos controles de nível de conta já utilizados para outros modelos no Amazon Bedrock. As requisições aparecem no log de invocação de modelos do Amazon Bedrock da mesma forma que requisições sob demanda. Esses logs podem ser entregues ao Amazon Simple Storage Service (Amazon S3) ou ao Amazon CloudWatch Logs.

    Métricas do CloudWatch para contagem de invocações, contagem de tokens, latência, throttles e erros são publicadas por perfil de inferência. Você pode acompanhar o uso dos modelos GPT-5.6 a partir de Mumbai ou Hyderabad sem precisar correlacionar logs entre regiões. Para verificar qual região de destino processou uma determinada requisição, os eventos do CloudTrail incluem um campo additionalEventData com a chave inferenceRegion — para o perfil da Índia, esse valor será sempre ap-south-1 ou ap-south-2, fornecendo um registro auditável de que a inferência permaneceu dentro da Índia.

    Próximos passos

    Para começar, revise os model cards do GPT-5.6 Terra e Luna e a seção de inferência entre regiões no Guia do Usuário do Amazon Bedrock. Experimente um prompt no playground do console do Amazon Bedrock em Mumbai ou Hyderabad e, em seguida, integre os exemplos de código apresentados neste artigo.

    Antes de dimensionar um workload de produção, consulte a página de preços do Amazon Bedrock para verificar as tarifas atuais do GPT-5.6. Em caso de dúvidas ou para interagir com a comunidade, o AWS re:Post é um bom lugar para buscar respostas ou postar perguntas.

    Fonte

    Introducing OpenAI models on Amazon Bedrock for in-country inferencing in India (https://aws.amazon.com/blogs/machine-learning/introducing-openai-models-on-amazon-bedrock-for-in-country-inferencing-in-india/)