User's blog

Blog

  • CloudTroop Weekly #005 — 2026-w13





    CloudTroop Weekly #005 — 2026-w13

    29 de março de 2026

    Resumo da Semana

    A semana foi dominada por dois eixos: infraestrutura para IA em produção e segurança de acesso na AWS. No lado de IA, SageMaker ganhou GPU reservada para inferência, o Bedrock passou a suportar fine-tuning com APIs compatíveis OpenAI e o Amazon Nova chegou a 0,03% de alucinações — número que abre portas para setores regulados. Em segurança, políticas IAM e controle de visibilidade no console voltaram ao centro do debate. O EKS subiu o patamar com SLA 99,99% e nova camada 8XL. Semana densa, com impacto direto em arquitetura, custo e compliance.

    O que muda na prática

    • GPU reservada no SageMaker traz previsibilidade de custo e disponibilidade para endpoints de inferência em produção — fim da roleta de capacidade em picos de demanda.
    • EKS agora oferece SLA de 99,99% com camada 8XL: contratos de disponibilidade para workloads críticos em Kubernetes precisam ser revistos à luz dessa nova garantia.
    • Controle de visibilidade de serviços e regiões no Console AWS permite reduzir superfície de ataque sem custo adicional — mudança operacional que reforça menor privilégio de forma imediata.

    Ações da semana

    • Revise as políticas IAM do seu ambiente multi-conta e mapeie quais usuários enxergam serviços e regiões desnecessários no Console — o artigo do rank 4 traz o passo a passo.
    • Se você opera endpoints de inferência com picos previsíveis, avalie agora a capacidade reservada de GPU no SageMaker e compare com o custo atual sob demanda antes do próximo ciclo de orçamento.

    Top 10 da Semana

    1

    Políticas de IAM: como e quando usá-las na sua estratégia

    Dominar os tipos de políticas IAM é base para qualquer estratégia de segurança multi-conta e afeta diretamente decisões de arquitetura e compliance.

    Para quem: Arquitetos de segurança, engenheiros cloud e times de plataforma que gerenciam ambientes multi-conta na AWS.

    Segurança IAM

    2

    Amazon EKS: SLA 99.99% e nova camada 8XL para clusters

    O novo SLA e a camada 8XL mudam o patamar de confiabilidade do EKS para workloads críticos, impactando decisões de arquitetura e contratos de disponibilidade.

    Para quem: Engenheiros de plataforma e arquitetos que operam clusters Kubernetes de grande escala em produção.

    Kubernetes Containers

    3

    IA Agentic em Serviços Financeiros: 7 princípios de segurança

    Com IA autônoma avançando em setores regulados, os sete princípios apresentados oferecem um framework prático para conformidade e accountability que vai além do setor financeiro.

    Para quem: Arquitetos de segurança e líderes técnicos que estão avaliando ou implantando sistemas de IA agentic em ambientes regulados.

    IA Segurança

    4

    AWS Console: controle de visibilidade de serviços e regiões

    Limitar o que usuários enxergam no console reduz superfície de ataque, simplifica onboarding e reforça o princípio do menor privilégio sem custo adicional.

    Para quem: Administradores de nuvem e times de segurança que gerenciam acesso de múltiplos usuários ao AWS Management Console.

    Segurança Governança

    5

    Eliminando alucinações em LLMs com Amazon Nova: 0,03% de erro

    Uma taxa de alucinação de 0,03% via fine-tuning não-generativo abre caminho real para uso de LLMs em saúde e finanças, onde confiabilidade é requisito regulatório.

    Para quem: Cientistas de dados e arquitetos de IA que desenvolvem soluções para setores regulados como saúde, finanças e jurídico.

    IA Confiabilidade

    6

    Aprendizado por Reforço no Bedrock com APIs compatíveis OpenAI

    Suporte a RFT com APIs OpenAI-compatíveis reduz a barreira de entrada para customização avançada de modelos, permitindo reaproveitamento de pipelines existentes.

    Para quem: Engenheiros de ML e times de produto que já usam APIs OpenAI e querem customizar modelos em escala empresarial na AWS.

    IA MLOps

    7

    AWS Neuron DRA: alocação dinâmica de GPUs no EKS

    Separar decisões de infraestrutura de aceleradores das preocupações de ML no Kubernetes reduz fricção operacional e otimiza custos de instâncias Trainium.

    Para quem: Engenheiros de MLOps e plataforma que orquestram workloads de treinamento e inferência de IA em clusters EKS.

    IA Infraestrutura

    8

    SageMaker: capacidade de GPU reservada para inferência

    Reservar GPU para endpoints de inferência traz previsibilidade de custo e disponibilidade, resolvendo um dos maiores pontos de dor em produção de modelos.

    Para quem: Times de MLOps e engenheiros de infraestrutura que gerenciam endpoints de inferência com picos de demanda previsíveis.

    MLOps Custos

    9

    Agent Plugin para AWS Serverless acelera dev com IA

    Integrar assistentes de codificação com IA diretamente ao fluxo serverless reduz erros de configuração e acelera o ciclo de desenvolvimento de funções e APIs.

    Para quem: Desenvolvedores serverless que usam ferramentas como Cursor ou Claude Code e querem produtividade maior no ciclo de build e deploy.

    Serverless Produtividade

    10

    CloudWatch Logs Infrequent Access ganha OpenSearch PPL e SQL

    Consultar logs arquivados com SQL e PPL sem mover dados para outro serviço reduz custo de análise e simplifica investigações de segurança e compliance.

    Para quem: Engenheiros de operações e times de segurança que analisam logs históricos e precisam equilibrar custo e capacidade analítica.

    Observabilidade Custos


  • CloudWatch Logs expande capacidades de análise com suporte a OpenSearch PPL e SQL na classe Infrequent Access

    Novas capacidades de análise no CloudWatch Logs

    A AWS anunciou expansão das funcionalidades de análise e proteção de dados para a classe de ingestão Infrequent Access (Logs IA) do CloudWatch Logs. Com as novidades, o serviço agora suporta proteção de dados, Piped Processing Language (PPL) do OpenSearch e SQL do OpenSearch. Essas melhorias permitem que as organizações realizem análises mais flexíveis e protejam dados sensíveis ao consolidar logs de forma econômica e nativa na plataforma.

    O que é Logs IA e para quem serve

    A classe Infrequent Access foi projetada especificamente para consolidar logs que são consultados ocasionalmente, como investigações forenses ou análises pontuais. Antes dessa atualização, Logs IA oferecia consultas através da Logs Insights Query Language, exportação para S3 e criptografia — tudo com preço menor por GB em comparação à classe Standard.

    Casos de uso ideais

    A classe é particularmente valiosa para troubleshooting ad-hoc e análise forense em logs que não são acessados regularmente, permitindo reduzir custos sem comprometer a capacidade de investigar problemas quando necessário.

    Capacidades recém-adicionadas

    Consultas avançadas com OpenSearch SQL e PPL

    Com o lançamento, os clientes podem agora executar consultas usando OpenSearch SQL e Piped Processing Language (PPL) do OpenSearch. Isso expande significativamente as possibilidades de análise, permitindo que equipes trabalhem com linguagens de consulta mais sofisticadas e familiares, caso já utilizem OpenSearch em seus ambientes.

    Proteção e mascaramento de dados sensíveis

    A funcionalidade de data protection permite que as organizações detectem e mascararem automaticamente informações sensíveis dentro dos logs. Esse recurso auxilia na conformidade com requisitos de segurança e regulamentações de proteção de dados, um passo importante para qualquer empresa que trabalha com informações críticas.

    Próximos passos

    Para quem deseja explorar essas capacidades, a AWS disponibiliza documentação detalhada sobre preços do CloudWatch Logs IA e um guia de usuário. Para conferir disponibilidade regional do recurso, consulte o AWS Builder Center através deste link.

    Fonte

    Amazon CloudWatch Logs now supports data protection, OpenSearch PPL and OpenSearch SQL for the Infrequent Access ingestion class (https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-cloudwatch-infrequent-access-log-class/)

  • AWS Management Console agora permite controlar a visibilidade de serviços e regiões

    Nova funcionalidade de personalização no AWS Management Console

    A AWS anunciou a disponibilidade geral de uma funcionalidade importante para administradores de contas: as configurações de Serviços Visíveis (Visible Services) e Regiões Visíveis (Visible Regions) no AWS Management Console.

    Essa novidade permite que você customize quais serviços e regiões aparecem no Console de Gerenciamento para os usuários autorizados em sua conta. Na prática, isso significa facilitar a navegação dos seus usuários, permitindo que eles vejam apenas o que realmente precisam usar, reduzindo confusão e tornando o ambiente mais intuitivo.

    Como funciona a configuração

    As configurações podem ser ajustadas diretamente no AWS Management Console. Para isso, basta acessar a seção de Configurações Unificadas (Unified Settings) dentro da aba de Configurações da Conta (Account Settings).

    Além da interface gráfica, a AWS oferece formas de configurar essas opções programaticamente. É possível usar a funcionalidade de Personalização da Experiência do Usuário (User Experience Customization — UXC) através de várias ferramentas:

    • Interface de Linha de Comando da AWS (AWS Command Line Interface — CLI)
    • Kits de Desenvolvimento de Software da AWS (AWS Software Development Kits — SDKs)
    • Kit de Desenvolvimento em Nuvem da AWS (AWS Cloud Development Kit — CDK)
    • AWS CloudFormation

    Disponibilidade e custos

    As configurações de Serviços Visíveis e Regiões Visíveis estão disponíveis em todas as Regiões Comerciais da AWS, e não há custo adicional para usar essa funcionalidade.

    Próximos passos

    Para explorar essa nova capacidade em detalhes, a AWS disponibiliza documentação completa. Você pode consultar a documentação sobre Personalização da Experiência do Usuário e o guia de API para implementar essas configurações em suas operações.

    Fonte

    AWS Management Console now supports settings to control service and Region visibility (https://aws.amazon.com/about-aws/whats-new/2026/03/account-customizations-console/)

  • Preparando-se para IA Agentic: Uma Abordagem para Serviços Financeiros

    O Desafio da IA Agentic em Instituições Financeiras

    A implementação de sistemas de inteligência artificial com capacidade autônoma—conhecida como IA agentic—em serviços financeiros apresenta um duplo desafio. Instituições precisam navegar um ambiente regulatório em constante evolução, conformando-se a estruturas como SR 11-7 nos EUA, SS1/23 no Reino Unido e diretrizes do Banco Central Europeu, enquanto lidam simultaneamente com considerações únicas de segurança introduzidas por esses sistemas autônomos.

    Diferentemente de sistemas de software tradicionais, a IA agentic pode tomar decisões autônomas e executar ações que impactam clientes, operações e reputação institucional. Essa autonomia exige uma abordagem de segurança que vai além dos controles convencionais. Organizações que seguem estruturas estabelecidas como ISO 27001 e Estrutura de Cibersegurança do NIST possuem fundação sólida, mas precisam aumentar seus controles tradicionais com medidas específicas para IA.

    Por Que Controles Tradicionais Não são Suficientes

    A natureza não-determinística dos sistemas de IA, sua capacidade de atuar com autonomia significativa e a complexidade das interações entre múltiplos agentes introduzem novas dimensões de risco que devem ser cuidadosamente gerenciadas. Em serviços financeiros, é essencial ter clareza na explicabilidade e accountability para gestão eficaz de risco em modelos.

    Quando agentes de IA tomam decisões ou executam ações em nome da organização, é necessário ter visibilidade clara sobre o que foi feito, por que foi feito e quem—ou o quê—foi responsável. Essa transparência ajuda a manter confiança, cumprir obrigações regulatórias e implementar IA de forma responsável, alinhado com as práticas de IA Responsável da AWS.

    Dois Pilares Essenciais: Observabilidade e Controle de Acesso

    A abordagem proposta pela AWS se concentra em dois habilitadores críticos: observabilidade abrangente dos fluxos de trabalho agentic e controle fino sobre permissões de acesso às ferramentas dos agentes. Juntas, essas capacidades fornecem a fundação para explicabilidade e criam um ambiente de controle que facilita accountability.

    O documento apresenta sete princípios de design que servem a um propósito duplo: orientar arquitetos de solução durante o design de sistemas de IA e fornecer aos times de gestão de risco um framework para identificar fatores críticos de risco.

    Sete Princípios de Design para IA Agentic Segura

    1. Homologia Segurança Humano-IA

    O primeiro princípio estabelece que é necessário compreender os controles humanos e determinar sua aplicabilidade aos agentes e fluxos de trabalho agentic, documentando as personas dos agentes. Isso inclui implementar identidades de agentes além de permissões tradicionais baseadas em papéis e atributos, com logging e monitoramento comportamental.

    Ações críticas devem ter supervisão (agentic ou humana), o escopo do agente deve ser definido nos fluxos de trabalho, e é preciso considerar gerenciamento de mudanças e incidentes, segregação de deveres do agente para ações e uso de ferramentas, verificação maker-checker, logging e monitoramento comportamental.

    2. Arquitetura Modular de Fluxo de Trabalho Agentic

    Usar sub-agentes especializados em fluxos de trabalho reduz o escopo de permissões que cada agente requer, aumenta modularidade e reusabilidade, simplifica manutenção e melhora observabilidade e explicabilidade. Permissões granulares são anexadas aos sub-agentes, focando estreitamente suas responsabilidades.

    3. Logging e Rastreamento de Fluxo de Trabalho e Agentes

    Implementar logging e rastreamento abrangentes para acompanhar decisões, ações, fluxos de atividade, contexto específico do chamador e etapas de raciocínio habilita melhor explicabilidade. Monitorar interações entre agentes, compartilhamento de contexto e comportamentos emergentes permite visibilidade holística das operações e dinâmicas do fluxo de trabalho multi-agente.

    4. Privilégio Mínimo Segregado para IA

    Aplicar o princípio do menor privilégio e segregação de deveres em fluxos de trabalho automatizados através de limites operacionais claramente definidos para agentes de IA. Esses limites devem ser suportados por controles de autorização, vinculados às permissões do chamador com suporte a verificação contextual, e apoiados por circuit breakers como supervisão humana.

    5. Integração de Governança

    Integrar observabilidade de agentes em frameworks de governança existentes através de alinhamento com processos estabelecidos de gerenciamento de risco e conformidade, implementando frameworks de avaliação padronizados e test harnesses que medem desempenho do agente, conformidade e alinhamento com valor de negócio.

    6. Controles Operacionais Agentic

    Fornecer guardrails amigáveis ao negócio para definir e gerenciar políticas de comportamento de agentes, mantendo controles abrangentes de custo através de monitoramento e otimização da utilização de recursos em níveis individual e de fluxo de trabalho. Usuários de negócio conseguem gerenciar restrições de agentes.

    7. Gestão de Risco e Conformidade

    Integrar rastreamento abrangente de atividades com frameworks de governança existentes para apoiar requisitos de auditoria, conformidade regulatória, e alinhamento com processos estabelecidos de gerenciamento de risco. Isso garante supervisão minuciosa e conformidade em todas as atividades de agentes dentro da estrutura de governança existente da organização.

    Implementação Prática dos Princípios

    Monitorando e Compreendendo Comportamento de Agentes IA

    Para implementar os princípios de homologia segurança humano-IA e logging/rastreamento, é necessário primeiro documentar fluxos de trabalho de agentes e personas, implementando rastreamento abrangente que capture entradas, etapas de raciocínio, saídas e uso de ferramentas.

    A Observabilidade do Amazon Bedrock AgentCore oferece soluções específicas para rastreamento, debug, identificação e monitoramento de desempenho de agentes em ambientes de produção. Essa visibilidade fornece dados para compreender como agentes interagem com sistemas financeiros críticos.

    Uma estratégia de tagging para agentes melhora visibilidade, usando nomes de papéis descritivos para casos de uso pretendidos. Esses tags devem ser antecipados para uso em permissões agentic downstream e fluxos de trabalho upstream.

    Dashboards operacionais, implementados com Amazon CloudWatch, devem fornecer visão da saúde operacional dos agentes, rastreando métricas-chave como conclusões bem-sucedidas, falhas, latência e utilização de recursos.

    Integrar telemetria de agentes com sistemas de monitoramento existentes usando padrões comuns como OpenTelemetry, com Distribuição AWS para OpenTelemetry, permite que instituições financeiras mantenham seus investimentos em ferramentas de monitoramento enquanto estendem visibilidade para atividades de agentes.

    É essencial estabelecer verificações padronizadas no servidor (lado da ferramenta) aplicando controles de acesso consistentes para agentes usando ferramentas, seguindo as práticas recomendadas de segurança AWS para integração de ferramentas. Validação e verificações de sanitização devem estar em lugar em entradas no ponto de uso da ferramenta para detectar comportamento não intencional.

    Gerenciando Mudanças em Ambientes de IA Agentic

    Adaptar processos de gerenciamento de mudanças para acomodar a natureza dinâmica dos agentes de IA mantendo controles apropriados. Revisar processos de aprovação integrados em pipelines de deploy de agentes e adaptá-los à natureza iterativa de pequenas melhorias incrementais.

    Implementar pausas human-in-the-loop em operações agentic permite supervisão adequada. Monitorar contínuamente traços de agentes em um test harness usando ferramentas como Amazon CloudWatch e AWS X-Ray para observar mudanças em padrões de comportamento de agentes que possam indicar drift de execução ou aprendizado inesperado.

    Implementando Privilégio Mínimo para Agentes de IA

    Definir limites de permissão granular para ações de agente implementando controles de permissão refinados para limitar permissões àquelas necessárias para funções de agente, usando por exemplo a Política do Amazon Bedrock AgentCore.

    Considerar segregação de deveres para agentes segregando funções e permissões de acesso a ferramentas para reduzir escopo de impacto de ações não intencionais. Garantir que ações dirigidas por prompt de usuário e ações agente-para-agente sejam separadamente identificáveis.

    Implantar monitoramento de autorização usando ferramentas como Observabilidade do Amazon Bedrock AgentCore que monitora continuamente padrões de autorização de agentes e sinaliza tentativas de acesso anômalas.

    Manter trilhas de auditoria abrangentes de ações de agentes que afetam sistemas de produção e dados sensíveis. Essas trilhas devem ser imutáveis e integradas com sistemas existentes de relatório de conformidade, garantindo que ações agente-para-agente e a fonte original e linhagem da requisição sejam preservadas.

    Implementando Guardrails e Controles Comportamentais

    Recomenda-se adotar uma abordagem crawl, walk, run para implementação de controle, começando com o conjunto mínimo necessário de controles e evoluindo ao longo do tempo com feedback do monitoramento.

    Interfaces amigáveis permitem definir políticas de comportamento de agente e regras de conformidade. Através dessas interfaces, times de risco e conformidade conseguem gerenciar guardrails de agentes diretamente sem intervenção técnica.

    Sistemas automatizados validam ações de agentes contra políticas definidas em tempo real. Por exemplo, usar Amazon Bedrock Guardrails para implementar filtragem de conteúdo, detecção de informações pessoalmente identificáveis (PII), e validação de respostas antes que saídas de agentes atinjam sistemas de produção.

    Fluxos de trabalho de revisão implementam pontos de controle para ações críticas de agentes com caminhos de escalação claros. Definir gatilhos para revisão humana e manter mecanismos de coleta de feedback para melhoria contínua.

    Detectando e Recuperando de Falhas em Agentes IA

    Implantar monitoramento abrangente de saúde e desempenho para agentes de IA que detecte tanto falhas hard quanto degradação de desempenho. A Observabilidade do Amazon Bedrock AgentCore oferece capacidades especializadas para compreender saúde de agentes além de métricas de aplicação tradicional.

    Desenvolver e testar procedimentos automatizados de recuperação e modificação comportamental manual para diferentes tipos de falhas de agentes. Esses procedimentos devem incluir circuit breakers apropriados e caminhos de escalação humana para cenários que requerem julgamento.

    Implementar monitoramento para degradação sutil em qualidade de raciocínio de agentes que pode não disparar alertas de falha tradicionais.

    Garantindo Desempenho Consistente de Agentes Através de Ambientes

    Implementar agentes modulares e reusáveis com baselines de desempenho estabelecidos para operações de agentes através de ambientes de desenvolvimento, teste e produção. Monitorar desvios que possam indicar problemas específicos de ambiente.

    Práticas de teste canary para monitoramento de comportamento de agentes e teste de resiliência implementam teste de release em pequena escala com observabilidade abrangente para detectar mudanças de comportamento inesperadas antes de deploy completo e em runtime.

    Usar teste positivo onde entradas válidas produzem saídas esperadas e teste negativo onde entradas inadequadas ainda alcançam a saída desejada. Testar resiliência de agentes sob várias condições de falha. Usar change control para testes canary para garantir rastreamento ao longo do tempo conforme testes expandem e amadurecem.

    Gerenciando Interações de Fluxo de Trabalho Multi-Agente

    Implementar monitoramento para padrões de colaboração de agentes, monitorando comunicações agente-para-agente dentro de fluxos de trabalho pré-definidos e dinâmicos, compartilhamento de contexto e comportamentos coletivos. Rastrear padrões de interação para identificar riscos potenciais ou ineficiências.

    Implantar testes de rastreamento comportamental para identificar padrões ou resultados inesperados surgindo de interações multi-agente. Estabelecer baselines para comportamento colaborativo normal e alertar sobre desvios, incluindo cenários extremos em testes.

    Registrar logs não-repudiáveis e abrangentes de interações de agentes, incluindo trocas de contexto, handoffs e saídas. Garantir que ações agente-para-agente, fonte original e linhagem da requisição sejam preservadas.

    Otimizando Utilização de Recursos e Custos de Agentes IA

    Implantar monitoramento para padrões de consumo de recursos de agentes, incluindo compute, memória, uso de API e custos usando Amazon CloudWatch. Isso habilita otimização de alocação de recursos e gerenciamento de custos.

    Definir e monitorar indicadores-chave de desempenho específicos para operações de agentes, como eficiência de desempenho de etapas de raciocínio, padrões de uso de ferramentas e tempos de conclusão.

    Implantar detecção de anomalia para métricas de desempenho de agentes para identificar problemas potenciais antes que impactem operações de negócio.

    Conclusão

    A adoção de IA agentic em serviços financeiros requer cuidadosamente balancear inovação com controle. Os sete princípios de design apresentados fornecem um framework para implementar sistemas de agentes de IA explicáveis, governáveis e em geral responsáveis que se alinhem com requisitos de segurança e conformidade existentes.

    Tratando agentes de IA com o mesmo rigor de segurança aplicado a funcionários humanos—através de controle de acesso robusto, permissões baseadas em papel e atributo, e monitoramento abrangente—organizações conseguem implementar seguramente esses sistemas mantendo conformidade com frameworks regulatórios-chave.

    As soluções de propósito específico disponíveis da AWS fornecem fundação técnica, mas sucesso também requer políticas claras e mecanismos de supervisão humana. Instituições financeiras que estabelecerem essas capacidades fundamentais de segurança e governança estarão bem posicionadas para aproveitar IA agentic enquanto contribuem para segurança, explicabilidade e conformidade com padrões de indústria de seus sistemas.

    Para perguntas e feedback, você pode acessar a comunidade de segurança, identidade e conformidade da AWS ou contatar o suporte AWS.

    Fonte

    Preparing for agentic AI: A financial services approach (https://aws.amazon.com/blogs/security/preparing-for-agentic-ai-a-financial-services-approach/)

  • Aurora DSQL: Conector para Ruby Simplifica Desenvolvimento de Aplicações

    Um Novo Conector para Facilitar o Desenvolvimento com Ruby

    A AWS anunciou o lançamento do Conector Aurora DSQL para Ruby (gem pg), uma ferramenta que simplifica significativamente a construção de aplicações Ruby no Aurora DSQL. Este conector representa um avanço importante para desenvolvedores que trabalham com a linguagem Ruby, trazendo segurança e praticidade para a autenticação em bancos de dados na nuvem.

    Segurança e Autenticação Automáticas

    A proposta central do conector é eliminar os riscos de segurança relacionados ao gerenciamento tradicional de senhas geradas pelo usuário. Em vez disso, o conector gera automaticamente tokens para cada conexão, garantindo que sempre sejam utilizados tokens válidos. Ao mesmo tempo, mantém total compatibilidade com os recursos existentes da gem pg, permitindo que aplicações legadas funcionem sem necessidade de alterações significativas.

    Funcionalidades Principais

    O conector está equipado para lidar com várias responsabilidades técnicas críticas: geração automática de tokens do IAM (Gerenciamento de Identidade e Acesso), configuração de SSL e gerenciamento de pool de conexões. Essa abordagem permite que os desenvolvedores escalem suas aplicações — desde scripts simples até cargas de trabalho em produção — sem precisar modificar sua estratégia de autenticação durante o processo de crescimento.

    Recursos Avançados e Flexibilidade

    Além das capacidades essenciais, o conector oferece funcionalidades opcionais importantes. Inclui retry com controle de concorrência otimista (OCC) com backoff exponencial, suporte a provedores de credenciais IAM customizados e integração com perfis AWS. Esses recursos conferem aos desenvolvedores a flexibilidade necessária para gerenciar suas credenciais AWS de diferentes maneiras e lidar eficientemente com falhas transientes.

    Primeiros Passos

    Para começar a utilizar o conector, desenvolvedores podem consultar a documentação dos Conectores para Aurora DSQL. Exemplos práticos de código estão disponíveis no repositório GitHub do conector Ruby. Aqueles que desejam explorar o Aurora DSQL sem custos imediatos podem aproveitar a camada gratuita da AWS Free Tier. Para uma compreensão mais aprofundada sobre o Aurora DSQL, a página dedicada do serviço oferece informações completas.

    Implicações Práticas

    Este conector representa um esforço da AWS em reduzir a complexidade operacional para desenvolvedores Ruby. A automação de tarefas críticas como geração de tokens e configuração SSL, combinada com a manutenção de compatibilidade com ferramentas existentes, posiciona a solução como uma opção atrativa para equipes que buscam modernizar sua infraestrutura de autenticação sem reescrever códigos legados.

    Fonte

    Aurora DSQL launches connector that simplifies building Ruby applications (https://aws.amazon.com/about-aws/whats-new/2026/03/aurora-dsql-connector-for-ruby/)

  • Amazon SageMaker Studio agora suporta Kiro e Cursor como IDEs remotas

    Integração entre IDEs locais e infraestrutura em nuvem

    A AWS anunciou uma novidade importante para quem trabalha com ciência de dados e desenvolvimento de modelos de inteligência artificial: agora é possível conectar remotamente as IDEs (Ambientes de Desenvolvimento Integrado) Kiro e Cursor diretamente ao Amazon SageMaker Studio.

    Essa capacidade oferece aos cientistas de dados, engenheiros de aprendizado de máquina e desenvolvedores a oportunidade de aproveitar as características locais de suas ferramentas favoritas — como desenvolvimento orientado por especificações, programação conversacional e geração automática de recursos — enquanto acessam simultaneamente toda a potência computacional escalável do Amazon SageMaker Studio na nuvem.

    Como funciona a integração

    A conexão entre Kiro, Cursor e SageMaker Studio é realizada através da extensão AWS Toolkit, eliminando a necessidade de alternar constantemente entre o editor local e a infraestrutura em nuvem. Dessa forma, é possível manter fluxos de trabalho de desenvolvimento orientados por agentes dentro de um único ambiente, integrando todos os seus serviços de análise e inteligência artificial e aprendizado de máquina da AWS.

    Ambientes de desenvolvimento disponíveis

    O Amazon SageMaker Studio oferecia anteriormente um conjunto abrangente de ambientes de desenvolvimento interativos totalmente gerenciados, incluindo JupyterLab, Code Editor baseado em Code-OSS (Software Livre) e VS Code como IDE remota. A partir de agora, esses ambientes se expandem para incluir as configurações customizadas de Kiro e Cursor — com todas as especificações, arquivos de direcionamento e hooks — enquanto você acessa seus recursos computacionais e dados no SageMaker.

    Autenticação e segurança

    A autenticação pode ser realizada de duas formas: através da extensão AWS Toolkit diretamente no Kiro ou Cursor, ou pela interface web do SageMaker Studio. Após a autenticação, você consegue conectar a qualquer um de seus ambientes de desenvolvimento do SageMaker Studio em poucos cliques.

    Um aspecto importante é que você mantém os mesmos limites de segurança que os ambientes baseados em web do SageMaker Studio oferecem. Isso significa que o desenvolvimento de modelos de inteligência artificial e análise de dados em sua IDE local de preferência — seja Kiro ou Cursor — acontece dentro do mesmo contexto de segurança e conformidade da plataforma.

    Próximos passos

    Para obter mais detalhes sobre como configurar essa integração e explorar todas as funcionalidades disponíveis, consulte a documentação do SageMaker.

    Fonte

    Amazon SageMaker Studio launches support for Kiro and Cursor IDEs as remote IDEs (https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-sagemaker-studio-kiro-cursor/)

  • Construindo IA Responsiva à Idade e Sensível ao Contexto com Amazon Bedrock Guardrails

    O Desafio da Segurança em Aplicações de IA Generativa

    Quando aplicações de IA generativa atendem a grupos diversificados de usuários, surge um desafio crítico que afeta tanto a segurança quanto a confiabilidade: garantir que cada resposta gerada seja apropriada, precisa e segura para o usuário específico. O conteúdo adequado para adultos pode ser inadequado ou confuso para crianças, enquanto explicações voltadas para iniciantes podem ser insuficientes para especialistas do domínio.

    À medida que a adoção de IA se expande por diferentes setores, a necessidade de adaptar respostas conforme a idade, papel profissional e nível de conhecimento do usuário se tornou essencial em ambientes de produção. Muitas organizações tentam resolver esse problema por meio de engenharia de prompts ou lógica no nível da aplicação, mas essas abordagens enfrentam limitações significativas.

    Por Que Controles de Segurança Baseados em Prompts Não São Suficientes

    Os controles de segurança implementados apenas no prompt podem ser contornados por técnicas de manipulação que induzem os modelos a ignorar as instruções de segurança. Conforme os requisitos de personalização crescem, o código da aplicação fica cada vez mais complexo e frágil. A governança se torna inconsistente quando múltiplas aplicações de IA estão em uso.

    Além disso, os riscos de conteúdo inseguro, informações alucinadas e respostas inadequadas se amplificam significativamente quando sistemas de IA interagem com usuários vulneráveis ou operam em domínios sensíveis como educação e saúde. A falta de políticas de segurança centralizadas e obrigatórias cria ineficiências operacionais e riscos de conformidade regulatória.

    A Solução: Guardrails no Coração da Arquitetura

    Para enfrentar esses desafios, a AWS desenvolveu uma abordagem baseada em guardrails que coloca a segurança no centro da arquitetura. Essa solução é totalmente serverless e utiliza Amazon Bedrock Guardrails junto com outros serviços AWS para alinhar-se com as necessidades modernas de segurança e conformidade em IA.

    A arquitetura oferece três componentes principais: seleção dinâmica de guardrails baseada no contexto do usuário, aplicação centralizada de políticas por meio dos guardrails, e APIs seguras com autenticação.

    Capacidades Principais da Solução

    O design serverless permite às organizações entregar respostas de IA personalizadas e seguras sem código complexo, de forma eficiente, segura e em escala. A solução é capaz de:

    • Adaptar respostas de IA de forma inteligente com base na idade, papel profissional e setor do usuário
    • Aplicar políticas de segurança no momento da inferência, prevenindo contornos por manipulação de prompts
    • Oferecer cinco guardrails especializados para diferentes segmentos de usuários: crianças, adolescentes, profissionais de saúde, pacientes e adultos em geral
    • Melhorar a eficiência operacional com governança centralizada e intervenção manual mínima
    • Escalar de acordo com o crescimento de usuários e requisitos de segurança em evolução

    Essa abordagem ajuda organizações a implantar sistemas de IA responsáveis, a se alinhar com requisitos de conformidade para populações vulneráveis, e a manter respostas apropriadas e confiáveis em toda a diversidade de grupos de usuários, sem comprometer desempenho ou governança.

    Visão Geral da Arquitetura

    Componentes Principais

    A solução utiliza Amazon Bedrock, Amazon Bedrock Guardrails, AWS Lambda e Amazon API Gateway como serviços essenciais para geração inteligente de respostas, aplicação centralizada de políticas e acesso seguro. Componentes de suporte como Amazon Cognito, Amazon DynamoDB, AWS WAF e Amazon CloudWatch possibilitam autenticação de usuários, gerenciamento de perfis, segurança e registros abrangentes.

    O Diferencial: Seleção Dinâmica de Guardrails

    O que torna esta abordagem única é a seleção dinâmica de guardrails. O Amazon Bedrock e os Bedrock Guardrails se adaptam automaticamente com base no contexto autenticado do usuário (idade, papel profissional, setor) para aplicar políticas de segurança apropriadas no momento da inferência. Essa abordagem baseada em guardrails funciona junto com medidas de segurança baseadas em prompts para oferecer proteção em camadas.

    A solução oferece cinco guardrails especializados:

    • Proteção Infantil: Compatível com a Lei de Proteção da Privacidade Online das Crianças (Children’s Online Privacy Protection Act – COPPA)
    • Educacional para Adolescentes: Conteúdo apropriado à idade
    • Profissional de Saúde: Conteúdo clínico habilitado
    • Paciente de Saúde: Aconselhamento médico bloqueado
    • Geral para Adultos: Proteção padrão

    Esses guardrails oferecem uma camada de aplicação de políticas autoritária que governa o que o modelo de IA pode dizer, operando independentemente da lógica da aplicação. A solução utiliza escalabilidade serverless, aplica políticas de segurança e adapta respostas com base no contexto do usuário, tornando-a bem adequada para implantações de IA corporativa que atendem populações diversas.

    Estratégia de Segurança em IA Multicontexto

    Como a Solução Funciona

    O fluxo da solução envolve várias etapas bem definidas:

    1. Requisição e Interface do Usuário

    • O usuário acessa a interface web de demonstração local (executada em localhost:8080 para fins de demonstração)
    • Insere uma consulta na interface
    • Seleciona seu perfil (Criança, Adolescente, Adulto, Profissional de Saúde)
    • A interface web prepara uma requisição autenticada com o contexto do usuário

    2. Autenticação do Usuário

    • O Amazon Cognito autentica usuários através de um pool de usuários e gera tokens Tokens de Web JSON (JWT – JSON Web Token)
    • Esses tokens contêm a ID do usuário e a declaração de autenticação
    • Os tokens seguros são passados com as requisições de API

    3. Camada de Segurança AWS WAF

    • O AWS WAF aplica limite de taxa de 2.000 requisições por minuto por IP (ajustável conforme necessário)
    • Bloqueia ameaças web comuns e requisições maliciosas segundo padrões de Projeto de Segurança de Aplicação Web Aberta (OWASP – Open Web Application Security Project)
    • Valida o formato da requisição e bloqueia tráfego suspeito

    4. Processamento pelo API Gateway

    • O Amazon API Gateway valida tokens JWT do Cognito
    • Encaminha requisições autenticadas para funções AWS Lambda
    • Gerencia requisições de Compartilhamento de Recursos entre Origens (CORS – Cross-Origin Resource Sharing)

    5. Execução da Função Lambda

    • O Lambda sanitiza e valida as entradas do usuário
    • Consulta o DynamoDB para recuperar perfis de usuário (idade, papel profissional, setor)
    • Analisa dados demográficos para determinar o guardrail apropriado
    • Prepara entradas de log de auditoria

    6. Seleção Dinâmica de Guardrail

    O Lambda avalia a idade, papel profissional e setor do usuário e seleciona automaticamente entre cinco guardrails especializados:

    • Idade menor que 13 anos → Guardrail de Proteção Infantil (compatível com COPPA)
    • Idade entre 13 e 17 anos → Guardrail Educacional para Adolescentes (conteúdo apropriado à idade)
    • Profissional de Saúde → Guardrail de Profissional de Saúde (conteúdo clínico habilitado)
    • Paciente de Saúde → Guardrail de Paciente (aconselhamento médico bloqueado)
    • Padrão/Adulto → Guardrail Geral para Adultos (proteção padrão)

    Cada requisição deve passar por um guardrail — não há possibilidade de contorno.

    7. Processamento Bedrock com Proteção por Guardrail

    • O Lambda invoca um modelo de fundação no Amazon Bedrock
    • O guardrail selecionado filtra tanto a entrada quanto a saída
    • Políticas customizadas, restrições de tópicos e detecção de Informações de Identificação Pessoal (PII – Personally Identifiable Information) são aplicadas
    • A IA gera respostas filtradas para segurança e apropriadas ao contexto

    8. Processamento de Resposta e Registro de Auditoria

    • Respostas seguras são entregues com metadados dos guardrails
    • Conteúdo inadequado dispara mensagens de segurança específicas do contexto
    • Interações são registradas no Amazon CloudWatch para conformidade
    • Interações dos guardrails são armazenadas em tabelas de auditoria no DynamoDB

    9. Entrega de Resposta ao Usuário

    • O Lambda retorna respostas processadas através do Amazon API Gateway
    • O sistema entrega respostas diretamente aos usuários
    • A interface web de demonstração exibe respostas protegidas e apropriadas ao contexto

    Exemplos de Adaptação de Respostas

    Exemplo 1: Pergunta sobre DNA

    Para a pergunta “O que é DNA?”, o sistema gera respostas diferentes conforme o contexto do usuário:

    Estudante Adolescente (13 anos): “O DNA é como um livro de receitas que diz ao seu corpo como crescer e como você vai parecer! É feito de quatro letras especiais (A, T, G, C) que criam instruções para tudo sobre você.”

    Profissional de Saúde (35 anos): “O DNA consiste de sequências de nucleotídeos que codificam informações genéticas através de complementaridade de pares de bases. A estrutura da dupla hélice contém regiões de codificação (éxons) e sequências regulatórias que controlam a expressão gênica e síntese de proteínas.”

    Adulto Geral (28 anos): “O DNA é uma molécula que contém instruções genéticas para o desenvolvimento e funcionamento de organismos vivos. Tem estrutura de dupla hélice e determina características hereditárias.”

    Exemplo 2: Pergunta sobre Equações Quadráticas

    A mesma pergunta “Como resolver equações quadráticas?” recebe respostas apropriadas à idade:

    Estudante Adolescente (13 anos): Explicação simples, passo a passo, com exemplos básicos e linguagem amigável adequada ao nível de ensino médio.

    Professor de Matemática (39 anos): Abordagem pedagógica abrangente, incluindo múltiplos métodos de solução, estratégias de ensino e conceitos matemáticos avançados.

    Implementação da Solução

    Pré-requisitos

    Antes de implantar a solução, certifique-se de que você tem:

    • Uma conta AWS
    • Permissões AWS apropriadas para Lambda, Amazon Bedrock, Cognito, AWS WAF, DynamoDB, API Gateway e CloudWatch
    • Terraform instalado e configurado

    Passos de Implementação

    1. Clonar o Repositório

    git clone https://github.com/aws-samples/sample-age-responsive-context-aware-ai-bedrock-guardrails.git

    2. Implantar Infraestrutura usando Terraform

    cd sample-age-responsive-context-aware-ai-bedrock-guardrails
./deploy.sh

    Para uma visão abrangente de cada configuração de guardrail, incluindo filtros de conteúdo, restrições de tópicos, tratamento de PII e filtros customizados, consulte os Detalhes de Configuração de Guardrail no repositório de código.

    Testando a Solução

    A solução inclui uma demonstração baseada em web para teste imediato. Para implantações corporativas em produção, você pode hospedar a interface usando AWS Amplify, Amazon S3 com Amazon CloudFront, ou serviços de container como Amazon Elastic Container Service (ECS) e Amazon Elastic Kubernetes Service (EKS).

    Demo Interativa Web:

    cd web-demo
./start_demo.sh

    Abra o navegador e acesse http://localhost:8080. Você pode:

    • Selecionar diferentes perfis de usuário (Criança, Adolescente, Adulto, Papéis de Saúde)
    • Enviar consultas e observar respostas sensíveis ao contexto
    • Visualizar aplicação de guardrails em tempo real
    • Monitorar adaptação de respostas conforme o contexto do usuário

    Teste de API:

    Para teste programático, gere um token JWT:

    cd utils
python3 generate_jwt.py student-123

    Teste o endpoint de API:

    curl -X POST "$(cd ../terraform && terraform output -raw api_url)" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer " \
  -d '{"query": "What is DNA?"}'

    Para cenários detalhados de teste do Amazon Bedrock Guardrails, exemplos de API e procedimentos de validação, consulte o arquivo TESTING_GUIDE.md no repositório clonado.

    Estimativa de Custos

    O custo de executar esta solução depende dos padrões e escala de uso. Para um cenário de uso moderado (1.000 requisições de API por dia), a estimativa mensal fica entre $73 e $320, dependendo do volume de uso e seleção de modelo.

    Os custos reais variam com base no volume de requisições, seleção de modelo, transferência de dados e preços regionais. Use o Calculador de Preços AWS para estimativas customizadas.

    Considerações para Otimização de Custos

    • Tagging de Custos: Implemente tags de alocação de custos AWS nos recursos para rastrear despesas por departamento, projeto ou centro de custos
    • Implantações Multi-Conta: Para implantações corporativas em múltiplas contas AWS, considere usar AWS Organizations com cobrança consolidada e AWS Cost Explorer para visibilidade centralizada
    • Capacidade Reservada: Para cargas de trabalho previsíveis, considere Amazon Bedrock Provisioned Throughput para reduzir custos de inferência
    • Otimização do DynamoDB: Use preço sob demanda para cargas variáveis ou capacidade provisionada com autoscaling para padrões previsíveis
    • Otimização do Lambda: Dimensione apropriadamente a alocação de memória e use AWS Lambda Power Tuning para melhorar a relação custo-desempenho
    • Retenção de Logs CloudWatch: Configure períodos de retenção apropriados para equilibrar necessidades de conformidade com custos de armazenamento

    Limpeza de Recursos

    Para evitar encargos contínuos, remova os recursos AWS criados quando não forem mais necessários:

    cd sample-age-responsive-context-aware-ai-bedrock-guardrails
./cleanup.sh

    Principais Benefícios e Resultados

    Esta solução demonstra uma abordagem baseada em guardrails para construir aplicações de IA sensíveis ao contexto. Os principais benefícios incluem:

    • Segurança Sensível ao Contexto: Diferentes grupos de usuários são protegidos por guardrails específicos sem necessidade de implantar modelos ou aplicações separados
    • Governança Centralizada: Os guardrails aplicam políticas de segurança, restrições de tópicos e controles de alucinação no nível da infraestrutura, em vez de depender apenas de lógica de prompts
    • Filtragem de Conteúdo Gerenciada: Os guardrails oferecem filtros de conteúdo integrados para discurso de ódio, insultos, conteúdo sexual, violência, má conduta e ataques de injeção de prompts, sem necessidade de implementação customizada
    • Personalização Inteligente: Adapta complexidade e apropriação de conteúdo conforme contexto do usuário, entregando explicações apropriadas à idade para crianças e detalhes clínicos para profissionais de saúde
    • Risco Reduzido de Contorno: Políticas são aplicadas no momento da inferência e não podem ser sobrescritas por entrada do usuário
    • Flexibilidade Operacional: Novos segmentos de usuários ou atualizações de política podem ser introduzidos atualizando guardrails em vez de modificar código da aplicação
    • Prontidão Corporativa: Os guardrails oferecem controle de versão, registros de auditoria e suporte à conformidade com clara separação de responsabilidades para manutenção de longo prazo

    Conclusão

    A AWS apresentou uma abordagem totalmente serverless baseada em guardrails para entregar respostas de IA sensíveis à idade e contextualizadas. A solução demonstra como serviços AWS trabalham em conjunto para selecionar dinamicamente guardrails especializados com base no contexto do usuário, aplicar políticas de segurança e entregar respostas personalizadas. A arquitetura foi implantada usando Terraform, tornando-a repetível e pronta para produção.

    Por meio de seleção dinâmica de guardrails e aplicação centralizada de políticas, essa solução personaliza respostas de IA para cada segmento de usuário — desde proteção compatível com COPPA para crianças até conteúdo clínico para profissionais de saúde — mantendo segurança corporativa e escalabilidade. Organizações que atendem populações diversas podem se beneficiar de risco reduzido de contorno, governança centralizada e flexibilidade operacional ao atualizar políticas sem modificar código da aplicação.

    Para começar, clone o repositório e siga as instruções de implantação. Teste a solução usando a demonstração web interativa para ver como respostas se adaptam conforme o contexto do usuário. Para aprender mais sobre Amazon Bedrock Guardrails, visite a documentação do Amazon Bedrock Guardrails.

    Fonte

    Building age-responsive, context-aware AI with Amazon Bedrock Guardrails (https://aws.amazon.com/blogs/machine-learning/building-age-responsive-context-aware-ai-with-amazon-bedrock-guardrails/)

  • Aceleração do Ajuste Fino de Modelos de Linguagem com Dados Não Estruturados usando SageMaker Unified Studio e S3

    Contexto da Integração

    No ano anterior, a AWS anunciou uma integração significativa entre o Amazon SageMaker Unified Studio e os buckets de propósito geral do Amazon S3. Essa conexão simplifica bastante a forma como equipes trabalham com dados não estruturados armazenados no Amazon Simple Storage Service (Amazon S3) para casos de uso em aprendizado de máquina (ML) e análise de dados.

    Este artigo demonstra como conectar buckets S3 ao Amazon SageMaker Catalog para realizar o ajuste fino do modelo Llama 3.2 11B Vision Instruct voltado para tarefas de resposta a perguntas visuais (VQA, sigla em inglês para Visual Question Answering). O fluxo prático mostra como fornecer ao modelo de linguagem uma imagem e uma pergunta para obter uma resposta — por exemplo, identificar a data de uma transação em um recibo itemizado.

    Preparação Inicial e Desempenho Base

    A AWS disponibiliza o modelo Llama 3.2 11B Vision Instruct através do Amazon SageMaker JumpStart. Fora da caixa, esse modelo base alcança uma pontuação ANLS (Similaridade de Levenshtein Normalizada Média — Average Normalized Levenshtein Similarity) de 85,3% no conjunto de dados DocVQA. O ANLS é uma métrica empregada para avaliar o desempenho de modelos em tarefas de resposta a perguntas visuais, medindo a similitude entre a resposta predita e a resposta esperada.

    Embora 85,3% demonstre um desempenho inicial sólido, esse nível pode não ser suficiente para tarefas que exigem maior precisão. Para elevar o desempenho através do ajuste fino, utiliza-se o conjunto de dados DocVQA do Hugging Face, que contém 39.500 linhas de dados de treinamento, cada uma com uma imagem, uma pergunta e a resposta correspondente esperada.

    Estratégia de Experimentação

    O processo envolve a criação de três versões de modelos ajustados utilizando diferentes tamanhos de conjuntos de dados: 1.000, 5.000 e 10.000 imagens. Cada variação é avaliada usando o Amazon SageMaker com suporte a MLflow gerenciado e sem servidor para rastreamento de experimentos e medição de melhorias de acurácia. Todo o fluxo de ingestão de dados, desenvolvimento de modelo e avaliação de métricas é orquestrado pelo Amazon SageMaker Unified Studio.

    Arquitetura da Solução

    A arquitetura construída realiza a ingestão de dados, pré-processamento, treinamento do modelo e avaliação utilizando o Amazon SageMaker Unified Studio. O processo segue estas etapas principais:

    • Criar e configurar um papel de acesso IAM que concede permissões de leitura a um bucket S3 preexistente contendo o conjunto de dados DocVQA bruto e não processado
    • O projeto produtor de dados usa o papel de acesso para descobrir e adicionar o conjunto de dados ao catálogo do projeto
    • O projeto produtor enriquece o conjunto de dados com metadados opcionais e o publica no SageMaker Catalog
    • O projeto consumidor de dados se inscreve no conjunto de dados publicado, disponibilizando-o para a equipe de desenvolvimento de modelos de aprendizado de máquina
    • O projeto consumidor pré-processa os dados e os transforma em três conjuntos de treinamento de tamanhos variados (1k, 5k e 10k imagens)
    • Cada conjunto é utilizado para ajustar o modelo base de linguagem, com o MLflow rastreando experimentos e resultados de avaliação em relação à métrica ANLS

    Pré-requisitos Necessários

    Para preparar uma organização visando usar essa nova integração entre o Amazon SageMaker Unified Studio e buckets S3 de propósito geral, é necessário completar alguns passos em um domínio baseado em Identity Center:

    • Criar uma conta AWS
    • Criar um domínio Amazon SageMaker Unified Studio através de configuração rápida
    • Criar dois projetos dentro do domínio: um para a função de produtor de dados e outro para consumidor de dados
    • Garantir que o projeto consumidor tenha acesso a uma aplicação MLflow gerenciada sem servidor em execução
    • Pré-popular um bucket Amazon S3 com o conjunto de dados bruto
    • Solicitar aumento de cota de serviço para utilizar instâncias de computação p4de.24xlarge em trabalhos de treinamento

    Fluxo de Implementação

    Descoberta e Catalogação de Dados

    Um projeto no Amazon SageMaker Unified Studio funciona como um limite dentro de um domínio onde equipes podem colaborar em casos de uso comerciais. Para trazer dados do S3 para um projeto, é necessário primeiro adicionar acesso aos dados e depois adicioná-los ao projeto. Nesta demonstração, utiliza-se um papel de acesso para facilitar esse processo.

    Após criar o papel de acesso conforme documentado, no projeto produtor de dados, navega-se até Dados → Adicionar dados → Adicionar localização S3, fornecendo o nome do bucket e o prefixo contendo os dados brutos. O papel de acesso necessário aparece em um menu suspenso para seleção.

    Dependendo das necessidades organizacionais, é possível enriquecer ainda mais esse ativo de dados através de junções com outras fontes, aplicação de transformações específicas do negócio, implementação de verificações de qualidade ou criação de características derivadas. Para este exemplo, trabalha-se com o conjunto de dados em sua forma atual para manter o foco na integração.

    Em seguida, publica-se o bucket no SageMaker Catalog, adicionando opcionalmente metadados de negócio como um arquivo README e termos de glossário. Após a publicação através do menu Ações, o ativo de dados fica pronto para ser consumido por outros projetos.

    Consumo e Desenvolvimento do Modelo

    Mudando para a perspectiva do projeto consumidor, é possível agora se inscrever no ativo de dados recém-publicado. Com a inscrição concluída, inicia-se o trabalho com os dados dentro de um ambiente JupyterLab gerenciado no Amazon SageMaker Unified Studio.

    No projeto de desenvolvimento de ML, navegando até Computação → Espaços → Criar espaço e selecionando JupyterLab como tipo de aplicação, inicia-se um novo ambiente de desenvolvimento interativo. Considera-se importante definir o Tempo de Inatividade para 6 horas, permitindo que notebooks rodem completamente sem erros, e o Armazenamento do Espaço para 100 GB para acomodar a ingestão completa do conjunto de dados durante o ajuste fino.

    Acesso aos Dados e Preparação

    Com o espaço em execução, carrega-se o notebook de demonstração. A integração utiliza Amazon S3 Access Grants para facilitar o acesso seguro aos dados sem gerenciamento complexo de permissões.

    Os dados podem ser acessados através da Interface de Linha de Comando AWS (AWS CLI), SDKs AWS e API REST do S3. Adicionalmente, é possível usar plugins Python e Java para chamar o serviço. O notebook utiliza a abordagem AWS CLI para obter credenciais temporárias de acesso ao plano de controle S3 e sincronizar os dados localmente.

    Com o conjunto de dados agora acessível localmente, é necessário transformá-lo no formato requerido para ajuste fino. Criam-se três conjuntos de dados com tamanhos variados, cada um contendo um diretório de treinamento e validação com subdiretórios de imagens e arquivo metadata.jsonl com exemplos de treinamento:

    {"file_name": "images/img_0.jpg", "prompt": "what is the date mentioned in this letter?", "completion": "1/8/93"}
{"file_name": "images/img_1.jpg", "prompt": "what is the contact person name mentioned in letter?", "completion": "P. Carter"}

    Ajuste Fino e Rastreamento de Experimentos

    Com os artefatos enviados para o S3, procede-se ao ajuste fino do modelo através do SageMaker JumpStart para acessar o modelo Llama 3.2 11B Vision Instruct pré-treinado. Criam-se três variantes ajustadas distintas para avaliação.

    Um função de treinamento parametrizada facilita essa execução, manipulando múltiplos aspectos importantes: seleção do modelo com a versão mais recente disponível no JumpStart, obtenção automática de hiperparâmetros padrão usando a API retrieve_default() no SDK SageMaker, configuração de tamanho de lote (batch size) ajustado para 1 por dispositivo dadas as limitações de memória do modelo grande, e utilização de instâncias ml.p4de.24xlarge para trabalhos de treinamento.

    A integração automática com MLflow registra hiperparâmetros, nomes de trabalhos e metadados de treinamento para rastreamento de experimentos, enquanto cada modelo treinado é automaticamente implantado em um ponto de acesso (endpoint) SageMaker para inferência. O processo de treinamento leva algumas horas usando esse tipo de instância.

    Avaliação de Resultados

    Os modelos ajustados são avaliados utilizando a métrica ANLS, que avalia saídas baseadas em texto medindo a similitude entre respostas preditas e esperadas, mesmo com pequenos erros ou variações. Essa métrica é particularmente útil em tarefas de resposta a perguntas visuais por conseguir lidar com pequenas variações nas respostas.

    O MLflow rastreia experimentos e resultados para comparação direta. O fluxo de avaliação inclui funções para codificação de imagens para inferência do modelo, formatação de carga útil, cálculo de ANLS e registro de resultados. Uma função pipeline de treinamento orquestra o fluxo completo com execuções MLflow aninhadas para melhor organização de experimentos.

    Resultados Alcançados

    Após executar o pipeline completo três vezes para os três tamanhos de conjunto de dados diferentes, revisa-se os resultados da métrica ANLS no MLflow. Os dados evidenciam uma relação positiva entre o tamanho do conjunto de dados de treinamento e a pontuação ANLS:

    • Modelo docvqa-1000: 0.886
    • Modelo docvqa-5000: 0.894
    • Modelo docvqa-10000: 0.902
    • Modelo Base: 0.853

    O modelo docvqa-10000 alcançou a maior pontuação ANLS de 0.902, representando um aumento de 4,9 pontos percentuais em relação ao modelo base (0.902 − 0.853 = 0.049). Essa melhoria valida a abordagem para tarefas de resposta a perguntas visuais.

    Benefícios Principais

    A integração entre o Amazon SageMaker Unified Studio e buckets S3 de propósito geral oferece diversos benefícios:

    • Descoberta e catalogação simplificadas de dados através de uma interface unificada
    • Acesso seguro aos dados através de S3 Access Grants sem necessidade de gerenciamento complexo de permissões
    • Colaboração tranquila entre produtores e consumidores de dados em diferentes projetos
    • Rastreamento de experimentos de ponta a ponta com integração gerenciada do MLflow

    As organizações podem agora aproveitar seus ativos de dados S3 existentes de forma mais eficaz para cargas de trabalho de aprendizado de máquina, mantendo controles de governança e segurança.

    Próximos Passos

    Para aprofundar a exploração dessa abordagem, considere investigar técnicas adicionais de pré-processamento de dados, experimentar diferentes arquiteturas de modelos disponíveis através do SageMaker JumpStart, ou aumentar a escala para conjuntos de dados maiores conforme os requisitos de seu caso de uso exigirem.

    O código de solução completo está disponível em um repositório GitHub para referência e implementação prática.

    Fonte

    Accelerating LLM fine-tuning with unstructured data using SageMaker Unified Studio and S3 (https://aws.amazon.com/blogs/machine-learning/accelerating-llm-fine-tuning-with-unstructured-data-using-sagemaker-unified-studio-and-s3/)

  • Amazon Polly com Streaming Bidirecional: Síntese de Voz em Tempo Real para IA Conversacional

    Construindo Experiências Conversacionais Naturais

    Para criar interações de conversação genuinamente naturais, é fundamental contar com síntese de voz que acompanhe o ritmo das trocas em tempo real. A AWS anunciou uma solução inovadora: a nova API de Streaming Bidirecional para o Amazon Polly, que possibilita síntese de texto para voz (TTS) simplificada e em tempo real, permitindo enviar texto e receber áudio simultaneamente.

    Este novo recurso foi desenvolvido especificamente para aplicações de IA conversacional que geram texto ou áudio incrementalmente — como as respostas de modelos de linguagem de grande escala (LLMs) — onde o usuário precisa começar a sintetizar áudio antes mesmo que o texto completo esteja disponível.

    O Amazon Polly já oferecia suporte para transmissão de áudio sintetizado de volta ao usuário. A inovação agora vai além, focando em comunicação bidirecional sobre HTTP/2, que traz ganhos significativos em velocidade, redução de latência e simplificação da implementação.

    O Desafio da Síntese de Voz Tradicional

    As APIs convencionais de conversão de texto para voz seguem um padrão simples: requisição e resposta. Isso obriga o desenvolvedor a ter o texto completo disponível antes de fazer a requisição de síntese. Embora o Amazon Polly transmita áudio de volta de forma incremental, o gargalo estava no lado da entrada — não era possível começar a enviar texto até que ele estivesse totalmente pronto.

    Em aplicações conversacionais alimentadas por LLMs, onde o texto é gerado token por token, isso significava aguardar a resposta completa do modelo antes de iniciar a síntese. Imagine um assistente virtual: o modelo de linguagem gera tokens progressivamente durante vários segundos, e com TTS tradicional, o usuário tinha que esperar por:

    • O LLM terminar de gerar a resposta completa
    • O serviço de TTS sintetizar todo o texto
    • O áudio ser baixado antes da reprodução começar

    A nova API de streaming bidirecional do Amazon Polly foi projetada especificamente para eliminar esses gargalos.

    O Que Mudou: Streaming Bidirecional

    A API StartSpeechSynthesisStream introduz uma abordagem fundamentalmente diferente:

    • Enviar texto incrementalmente: Transmita texto para o Amazon Polly conforme fica disponível — sem necessidade de aguardar sentenças ou parágrafos completos.
    • Receber áudio imediatamente: Obtenha bytes de áudio sintetizados em tempo real conforme são gerados.
    • Controlar o tempo de síntese: Use configuração de flush para disparar síntese imediata do texto em buffer.
    • Comunicação true duplex: Envie e receba simultaneamente através de uma única conexão.

    Componentes-chave da Arquitetura

    A API funciona através de eventos estruturados que trafegam em ambas as direções:

    Componente Direção Finalidade
    TextEvent Entrada (Cliente → Amazon Polly) Enviar texto a ser sintetizado
    CloseStreamEvent Entrada (Cliente → Amazon Polly) Sinalizar fim da entrada de texto
    AudioEvent Saída (Amazon Polly → Cliente) Receber chunks de áudio sintetizado
    StreamClosedEvent Saída (Amazon Polly → Cliente) Confirmação de conclusão do stream

    Comparação: Antes e Depois

    Implementação Tradicional (Separação de Arquivo)

    Alcançar TTS com baixa latência costumava exigir implementações no nível da aplicação:

    • Lógica customizada de separação de texto no servidor
    • Múltiplas chamadas paralelas à API do Amazon Polly
    • Remontagem complexa de áudio

    Nova Abordagem: Streaming Bidirecional Nativo

    Os benefícios agora são diretos:

    • Nenhuma lógica de separação necessária
    • Uma única conexão persistente
    • Streaming nativo em ambas as direções
    • Redução significativa da complexidade infraestrutural

    Resultados de Performance

    Para medir o impacto real, a AWS comparou a API tradicional SynthesizeSpeech com a nova API StartSpeechSynthesisStream usando as mesmas condições:

    • 7.045 caracteres de prosa (970 palavras)
    • Voz Matthew com mecanismo Generative
    • Saída em MP3 a 24kHz na região us-west-2

    Metodologia de Teste

    Ambos os testes simularam um LLM gerando tokens a aproximadamente 30ms por palavra. No teste da API tradicional, palavras foram agrupadas até um limite de sentença, e então a sentença completa foi enviada como uma requisição SynthesizeSpeech, aguardando a resposta de áudio completa antes de continuar. O teste de streaming bidirecional enviou cada palavra conforme chegava, permitindo que o Amazon Polly começasse a síntese antes que o texto estivesse completo.

    Métrica SynthesizeSpeech Tradicional Streaming Bidirecional Melhoria
    Tempo total de processamento 115.226 ms (~115s) 70.071 ms (~70s) 39% mais rápido
    Chamadas à API 27 1 27x menos chamadas
    Sentenças enviadas 27 (sequencial) 27 (transmitidas como tokens chegam) —
    Total de bytes de áudio 2.354.292 2.324.636 —

    A vantagem arquitetural é clara: a API bidirecional permite enviar texto de entrada e receber áudio sintetizado simultaneamente por uma única conexão. Em vez de aguardar cada sentença se acumular antes de solicitar síntese, o texto flui para o Amazon Polly palavra por palavra conforme o LLM o produz. Para IA conversacional, isso significa que o Polly recebe e processa texto incrementalmente durante toda a geração, não tudo de uma vez após o modelo terminar. O resultado é menos tempo em espera pela síntese após a geração ser concluída — a latência de ponta a ponta do prompt até a entrega completa do áudio se reduz significativamente.

    Implementação Técnica

    Começando a Usar

    A API de streaming bidirecional está disponível nos AWS SDKs para Java 2.x, JavaScript v3, .NET v4, C++, Go v2, Kotlin, PHP v3, Ruby v3, Rust e Swift. Suporte para CLIs (AWS Command Line Interface v1 e v2, PowerShell v4 e v5), Python e .NET v3 ainda não estão disponíveis.

    Um exemplo básico de inicialização:

    // Criar o cliente Polly assíncrono
    
PollyAsyncClient pollyClient = PollyAsyncClient.builder()
    
    .region(Region.US_WEST_2)
    
    .credentialsProvider(DefaultCredentialsProvider.create())
    
    .build();
    

    // Criar a requisição de stream
    
StartSpeechSynthesisStreamRequest request = StartSpeechSynthesisStreamRequest.builder()
    
    .voiceId(VoiceId.JOANNA)
    
    .engine(Engine.GENERATIVE)
    
    .outputFormat(OutputFormat.MP3)
    
    .sampleRate("24000")
    
    .build();
    

    Fonte
    

    Introducing Amazon Polly Bidirectional Streaming: Real-time speech synthesis for conversational AI (https://aws.amazon.com/blogs/machine-learning/introducing-amazon-polly-bidirectional-streaming-real-time-speech-synthesis-for-conversational-ai/)

  • Inferência com IA Generativa na Região da Nova Zelândia: Como o Amazon Bedrock Expande sua Cobertura no Pacífico Asiático

    Inferência de IA generativa chega à Nova Zelândia

    A AWS ampliou seus serviços de IA generativa ao anunciar a disponibilidade do Amazon Bedrock na região do Pacífico Asiático, especificamente em Auckland (ap-southeast-6). Essa expansão responde a uma demanda crescente de clientes neozelandeses que buscavam acessar modelos de fundação diretamente de sua região local, sem necessidade de roteamento complexo ou latência adicional.

    Com esse lançamento, clientes em Auckland ganham acesso imediato aos modelos Anthropic Claude (incluindo Opus 4.5, Opus 4.6, Sonnet 4.5, Sonnet 4.6 e Haiku 4.5) e aos modelos Amazon Nova 2 Lite. A grande novidade é que essa capacidade agora funciona através de roteamento entre regiões diretamente da Nova Zelândia, eliminando a necessidade de chamadas de API de fora do país.

    Como funciona o roteamento entre regiões

    O conceito de roteamento entre regiões (cross-region inference) é central para entender como o serviço opera. Trata-se de um recurso do Amazon Bedrock que distribui o processamento de inferência entre múltiplas regiões AWS para alcançar maior throughput em larga escala.

    O fluxo de requisições

    Quando você invoca um perfil de inferência entre regiões, o Amazon Bedrock roteia sua requisição da região de origem (onde você faz a chamada de API) para uma região de destino (onde o processamento de inferência ocorre). Todo dado transmitido durante essas operações permanece exclusivamente na rede privada AWS, sem passar pela internet pública. Além disso, todos os dados são criptografados em trânsito entre as regiões.

    Todas as requisições de inferência entre regiões são registradas no AWS CloudTrail na região de origem. Se você configurar o registro de invocação de modelos, os logs são publicados no Amazon CloudWatch Logs ou Amazon Simple Storage Service (S3), sempre na mesma região.

    Dois tipos de perfis de roteamento

    A AWS oferece duas abordagens diferentes para roteamento entre regiões:

    • Roteamento geográfico (AU): Roteia requisições dentro de um limite geográfico específico. No caso do perfil AU com Auckland como origem, as requisições são roteadas para Auckland, Sydney e Melbourne. Essa abordagem é ideal para organizações com requisitos de residência de dados que precisam manter o processamento de inferência dentro da Austrália e Nova Zelândia.
    • Roteamento global: Roteia requisições para todas as regiões AWS comerciais suportadas no mundo, fornecendo o throughput mais alto disponível. Essa opção é apropriada para organizações sem requisitos rigorosos de residência de dados.

    A Nova Zelândia como região de origem

    Com este lançamento, Auckland torna-se uma nova região de origem para ambos os perfis de roteamento entre regiões: o geográfico AU e o global. Isso significa que você pode fazer chamadas de API do Amazon Bedrock diretamente da região neozelandesa, com as requisições sendo roteadas para as regiões de destino onde os modelos de fundação processam a inferência.

    Configuração do roteamento geográfico AU

    O perfil AU agora abrange três regiões distribuídas pela Austrália e Nova Zelândia. A estrutura de roteamento funciona da seguinte forma:

    • De Auckland (ap-southeast-6): Requisições podem ser roteadas para Auckland, Sydney (ap-southeast-2) e Melbourne (ap-southeast-4)
    • De Sydney (ap-southeast-2): Requisições continuam sendo roteadas apenas para Sydney ou Melbourne
    • De Melbourne (ap-southeast-4): Requisições continuam sendo roteadas apenas para Sydney ou Melbourne

    Um detalhe importante: os perfis de roteamento AU que já existiam para Sydney e Melbourne continuam funcionando apenas entre essas duas cidades. A adição de Auckland não altera os destinos existentes para clientes nessas regiões. No entanto, requisições originando de Auckland têm três regiões de destino disponíveis, permitindo maior distribuição de carga.

    Roteamento global a partir da Nova Zelândia

    Para organizações sem requisitos rigorosos de residência de dados, o roteamento global oferece acesso à capacidade de inferência em todas as regiões AWS comerciais suportadas. Essa abordagem entrega dois benefícios principais:

    • Maior throughput: O roteamento inteligente distribui o tráfego dinamicamente entre todas as regiões suportadas, reduzindo a probabilidade de limitação durante picos de demanda
    • Resiliência integrada: Requisições são automaticamente roteadas para regiões com capacidade disponível, ajudando suas aplicações a manter continuidade operacional à medida que padrões de demanda mudam

    Modelos suportados e IDs de perfis de inferência

    O roteamento entre regiões a partir da Nova Zelândia oferece suporte a modelos de fundação de múltiplos fornecedores. Os modelos Anthropic Claude mais recentes incluem Opus 4.6, Sonnet 4.6, Sonnet 4.5 e Haiku 4.5, disponíveis através tanto do roteamento AU quanto global.

    Para usar um perfil de roteamento entre regiões, você substitui o ID do modelo de fundação original adicionando um prefixo geográfico (au.) ou global (global.). Por exemplo, o modelo anthropic.claude-sonnet-4-6 torna-se au.anthropic.claude-sonnet-4-6 ou global.anthropic.claude-sonnet-4-6.

    Para obter a lista completa e atualizada de modelos suportados e IDs de perfis de inferência, consulte a documentação sobre Regiões suportadas e modelos para perfis de inferência.

    Os perfis de roteamento entre regiões funcionam com as APIs InvokeModel, InvokeModelWithResponseStream, Converse e ConverseStream. A API Converse é especialmente útil pois oferece um formato consistente de requisição e resposta entre diferentes modelos de fundação, facilitando a troca entre modelos sem reescrever código de integração.

    Configuração de permissões de acesso

    Para invocar modelos de fundação através do roteamento geográfico AU a partir de Auckland, sua política de AWS Identity and Access Management (IAM) precisa de dois elementos:

    • Permissão para acessar o perfil de inferência na região de origem
    • Permissão para acessar o modelo de fundação em todas as regiões de destino do perfil AU

    Aqui está um exemplo de política IAM que concede permissão para invocar o Anthropic Claude Sonnet 4.6 através do roteamento geográfico AU a partir de Auckland:

    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAuCrisInferenceProfile",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": "arn:aws:bedrock:ap-southeast-6::inference-profile/au.anthropic.claude-sonnet-4-6"
    },
    {
      "Sid": "AllowFoundationModelViaAuCris",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:ap-southeast-2::foundation-model/anthropic.claude-sonnet-4-6",
        "arn:aws:bedrock:ap-southeast-4::foundation-model/anthropic.claude-sonnet-4-6",
        "arn:aws:bedrock:ap-southeast-6::foundation-model/anthropic.claude-sonnet-4-6"
      ],
      "Condition": {
        "StringLike": {
          "bedrock:InferenceProfileArn": "arn:aws:bedrock:ap-southeast-6::inference-profile/au.anthropic.claude-sonnet-4-6"
        }
      }
    }
  ]
}

    A primeira declaração permite invocar o perfil de inferência AU a partir da região de origem Auckland. A segunda declaração permite que o modelo de fundação seja invocado nas três regiões de destino, mas apenas quando a requisição é roteada através do perfil de inferência AU. Isso segue o princípio do menor privilégio, impedindo invocação direta do modelo nessas regiões.

    O mesmo padrão de duas declarações aplica-se a qualquer modelo no perfil de roteamento AU. Simplesmente substitua o ID do modelo nos ARNs de recurso. Para políticas IAM de roteamento global e padrões avançados de segurança, consulte a documentação sobre Segurança do roteamento entre regiões do Amazon Bedrock.

    Segurança e conformidade

    O roteamento entre regiões é projetado com segurança como núcleo central. Todas as requisições viajam exclusivamente pela Rede Global AWS com criptografia ponta a ponta, e seus dados em repouso permanecem na região de origem.

    Considerações com Service Control Policies

    Para organizações que usam Service Control Policies (SCP) para restringir acesso a regiões AWS específicas, há pontos importantes a considerar ao chamar a partir de Auckland (ap-southeast-6):

    • O roteamento geográfico AU requer que você permita ap-southeast-2, ap-southeast-4 e ap-southeast-6 para ações do Amazon Bedrock em suas SCPs, pois o perfil AU de Auckland roteia para todas as três regiões ANZ
    • O roteamento global requer adicionalmente que você permita um valor de região não especificado para ações do Amazon Bedrock, já que regiões de destino são determinadas dinamicamente

    A seguir, um exemplo de SCP que restringe serviços à região Auckland, com exceções para Amazon Bedrock e serviços globais como IAM:

    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonBedrockServicesOutsideAuckland",
      "Effect": "Deny",
      "NotAction": [
        "bedrock:*",
        "iam:*",
        "organizations:*",
        "support:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["ap-southeast-6"]
        }
      }
    },
    {
      "Sid": "DenyBedrockOutsideANZRegions",
      "Effect": "Deny",
      "Action": "bedrock:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "ap-southeast-2",
            "ap-southeast-4",
            "ap-southeast-6"
          ]
        }
      }
    },
    {
      "Sid": "DenyDirectBedrockInDestinationRegions",
      "Effect": "Deny",
      "Action": "bedrock:*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": [
            "ap-southeast-2",
            "ap-southeast-4"
          ]
        },
        "Null": {
          "bedrock:InferenceProfileArn": "true"
        }
      }
    }
  ]
}

    Nessa política de exemplo: a primeira declaração restringe todos os serviços à região Auckland, exceto Amazon Bedrock e serviços globais como IAM, AWS Organizations e AWS Support. A segunda declaração restringe Amazon Bedrock às três regiões ANZ, necessária para que o roteamento AU rotear requisições de Auckland para Sydney e Melbourne. A terceira utiliza a condição Null em bedrock:InferenceProfileArn para negar qualquer requisição do Amazon Bedrock em Sydney ou Melbourne que não seja roteada através de um perfil de roteamento entre regiões.

    Auditoria e monitoramento

    AWS CloudTrail registra todas as chamadas de inferência entre regiões na região de origem. O campo additionalEventData.inferenceRegion registra onde cada requisição foi processada, permitindo que você audite exatamente onde a inferência ocorreu.

    Para monitoramento operacional em tempo real, Amazon CloudWatch fornece métricas para requisições de inferência entre regiões em sua região de origem. As métricas principais incluem:

    • InvocationCount: Número total de requisições de inferência
    • InvocationLatency: Tempo de resposta ponta a ponta incluindo roteamento entre regiões
    • InvocationClientErrors: Requisições falhadas, incluindo limitação (picos indicam que você está se aproximando dos limites de quota)
    • InputTokenCount e OutputTokenCount: Consumo de tokens para rastreamento de quota

    Gerenciamento de quotas

    As quotas de serviço do Amazon Bedrock são gerenciadas no nível da região de origem. Aumentos de quota solicitados a partir da região Auckland (ap-southeast-6) aplicam-se apenas a requisições originando de Auckland.

    As quotas são medidas em duas dimensões:

    • Tokens por minuto (TPM): Número máximo de tokens (entrada + saída) processados por minuto
    • Requisições por minuto (RPM): Número máximo de requisições de inferência por minuto

    Ao calcular sua quota necessária, leve em conta a taxa de consumo de tokens. Para Anthropic Claude Opus 4.6, Sonnet 4.6 e Sonnet 4.5, tokens de saída consomem cinco vezes mais quota que tokens de entrada (taxa 5:1). Para Claude Haiku 4.5 e modelos Amazon Nova, a taxa é 1:1.

    A fórmula de consumo de quota é: Consumo de quota = Tokens de entrada + Tokens de cache de escrita + (Tokens de saída × Taxa de consumo)

    Para solicitar aumentos de quota, navegue até o console de Quotas de Serviço AWS em sua região de origem, selecione Amazon Bedrock e procure pela quota de roteamento entre regiões relevante para seu modelo.

    Primeiros passos

    Para começar a usar roteamento entre regiões a partir da Nova Zelândia, siga estes passos:

    • Entre no console do Amazon Bedrock na região Auckland (ap-southeast-6)
    • Configure permissões de IAM e SCP usando os exemplos de política fornecidos
    • Faça sua primeira chamada de API usando o ID de perfil de inferência au.
    • Solicite aumentos de quota através do console de Quotas de Serviço com base em sua carga de trabalho esperada

    Conclusão

    A expansão do Amazon Bedrock para Auckland representa um marco importante na disponibilidade de IA generativa no Pacífico Asiático. Os pontos principais dessa novidade são:

    • Auckland torna-se agora uma região de origem para roteamento entre regiões, permitindo que clientes neozelandeses façam chamadas de API do Amazon Bedrock localmente
    • O roteamento geográfico AU mantém dados dentro da zona ANZ, com requisições de Auckland roteadas para três destinos (Auckland, Sydney e Melbourne)
    • O roteamento global expande o acesso a modelos, oferecendo o throughput mais alto disponível ao rotear requisições para regiões AWS comerciais em todo o mundo
    • As configurações de roteamento existentes para Sydney e Melbourne permanecem inalteradas, garantindo continuidade para clientes australianos

    Para mais informações, consulte documentação do Amazon Bedrock, o Guia do Usuário de Roteamento Entre Regiões, Regiões suportadas e modelos para perfis de inferência e Segurança do roteamento entre regiões do Amazon Bedrock.

    Fonte

    Run Generative AI inference with Amazon Bedrock in Asia Pacific (New Zealand) (https://aws.amazon.com/blogs/machine-learning/run-generative-ai-inference-with-amazon-bedrock-in-asia-pacific-new-zealand/)