Transcrição de fala em tempo real: o desafio dos agentes de voz
À medida que empresas expandem o desenvolvimento de agentes de voz com inteligência artificial, surge um desafio crítico: oferecer transcrição de fala em tempo real com o menor atraso possível. O intervalo entre o usuário falar e o agente responder é fundamental para criar experiências naturais e intuitivas. Historicamente, equipes de engenharia precisavam construir soluções customizadas para gerenciar este processamento contínuo, investindo semanas em desenvolvimento e manutenção de infraestrutura específica para protocolos de streaming — tempo que poderia ser dedicado à melhoria da precisão dos modelos.
A solução: streaming bidirecional no SageMaker AI Inference
A AWS introduziu suporte a streaming bidirecional no Amazon SageMaker AI Inference, transformando a forma como modelos de fala são implantados em produção. Esse recurso permite que modelos de transcrição de fala recebam fluxos de áudio contínuos e retornem transcrições parciais simultaneamente enquanto o usuário está falando — eliminando a necessidade de entrada em lotes e processamento aguardando o término da fala.
Como funciona a implementação
O modelo operacional é elegante em sua simplicidade. Cientistas de dados e engenheiros de machine learning podem implantar modelos de fala-para-texto invocando o endpoint através da nova API Bidirectional Stream. O cliente abre uma conexão HTTP/2 com o runtime do SageMaker AI, que automaticamente cria uma conexão WebSocket para o container. Este container processa quadros de áudio em streaming e retorna transcrições parciais conforme são geradas.
O design é agnóstico ao modelo: qualquer container que implemente um handler WebSocket seguindo o contrato do SageMaker AI funciona automaticamente. Modelos de speech em tempo real como o Deepgram funcionam sem necessidade de modificações, demonstrando a flexibilidade da abordagem.
Impacto prático: eliminando meses de desenvolvimento
Essa implementação elimina meses de desenvolvimento de infraestrutura customizada. Equipes que gastavam semanas mantendo protocolos de WebSocket, gerenciando conexões e otimizando latência agora podem concentrar seus esforços onde realmente importa: melhorando a precisão do modelo, refinando as capacidades do agente e criando experiências de usuário superiores.
Disponibilidade global
O recurso de streaming bidirecional está disponível em mais de 30 regiões AWS distribuídas globalmente, incluindo Canada (Central), South America (São Paulo), Africa (Cape Town), Europe (Paris), Asia Pacific (Hyderabad), Asia Pacific (Jakarta), Israel (Tel Aviv), Europe (Zurich), Asia Pacific (Tokyo), AWS GovCloud US (West), AWS GovCloud US (East), Asia Pacific (Mumbai), Middle East (Bahrain), US West (Oregon), China (Ningxia), US West (Northern California), Asia Pacific (Sydney), Europe (London), Asia Pacific (Seoul), US East (N. Virginia), Asia Pacific (Hong Kong), US East (Ohio), China (Beijing), Europe (Stockholm), Europe (Ireland), Middle East (UAE), Asia Pacific (Osaka), Asia Pacific (Melbourne), Europe (Spain), Europe (Frankfurt), Europe (Milan) e Asia Pacific (Singapore).
A AWS anunciou o lançamento do Network Firewall Proxy em prévia pública, um novo recurso que reforça significativamente a postura defensiva das organizações contra ameaças de exfiltração de dados e injeção de malware. O serviço foi projetado para funcionar em modo explícito, permitindo que seja configurado em apenas alguns cliques.
O destaque principal do Network Firewall Proxy é sua capacidade de gerenciar e proteger o tráfego de dados que sai das aplicações, bem como as respostas que essas aplicações recebem. Isso oferece um controle muito mais preciso sobre as comunicações de rede que atravessam a infraestrutura corporativa.
Capacidades e controles granulares
Proteção contra spoofing e acesso não autorizado
O Network Firewall Proxy da AWS protege as organizações contra tentativas de falsificação de nomes de domínio ou do índice de nome do servidor (SNI — Server Name Index). Além disso, oferece flexibilidade para implementar controles de acesso muito específicos e adaptados às necessidades de cada ambiente.
Um dos casos de uso mais importantes é a restrição de acesso das aplicações apenas para domínios ou endereços IP confiáveis. O recurso também permite bloquear respostas não intencionais provenientes de servidores externos, criando uma barreira efetiva contra comunicações não autorizadas.
Inspeção de TLS e filtragem avançada
O serviço permite ativar a inspeção de TLS (Transport Layer Security) e estabelecer controles granulares de filtragem baseados em atributos de cabeçalho HTTP. Isso significa que é possível examinar e controlar comunicações mesmo quando criptografadas, ampliando as possibilidades de proteção sem sacrificar a privacidade.
Monitoramento e análise detalhada
O Network Firewall Proxy oferece registros abrangentes para monitoramento contínuo das aplicações. Esses logs podem ser direcionados para o Amazon S3 (Simple Storage Service) e o AWS CloudWatch, permitindo análises detalhadas e facilitando processos de auditoria. Essa rastreabilidade é especialmente importante para organizações que precisam atender requisitos regulatórios rigorosos.
Disponibilidade e próximos passos
O Network Firewall Proxy está disponível em prévia pública na região US East (Ohio) e, durante este período, é oferecido gratuitamente. Organizações interessadas são convidadas a testar o recurso em ambientes de teste para avaliar seu impacto nas estratégias de segurança de rede.
Desafios no gerenciamento de credenciais de terceiros
Embora o AWS Secrets Manager se destaque no gerenciamento do ciclo de vida de segredos dos serviços de Amazon Web Services (AWS), o armazenamento de credenciais de provedores de software terceirizados apresenta desafios singulares para organizações que expandem o uso de aplicações em nuvem.
Organizações que utilizam múltiplos serviços de terceiros frequentemente desenvolvem abordagens de segurança distintas para cada provedor, pois não existia uma forma padronizada de gerenciar essas credenciais. Ao armazenar credenciais de terceiros no Secrets Manager, as organizações precisam manter metadados adicionais dentro dos valores dos segredos para facilitar as conexões com os serviços. Essa abordagem exige atualização completa dos valores dos segredos sempre que os metadados mudam, além da implementação de processos de rotação específicos para cada provedor que são manuais e demorados.
Organizações que buscam automatizar a rotação de segredos frequentemente precisam desenvolver funções personalizadas adaptadas a cada provedor de software terceirizado, exigindo conhecimento especializado tanto dos sistemas terceirizados quanto dos sistemas AWS.
Introdução aos segredos externos gerenciados
Para ajudar os clientes a simplificar o gerenciamento de segredos de terceiros, a AWS introduz uma nova funcionalidade no AWS Secrets Manager chamada segredos externos gerenciados. Este novo tipo de segredo estende a experiência contínua do gerenciamento de rotação para aplicações de software terceirizadas como Salesforce, simplificando os desafios de gerenciamento de segredos por meio de formatos padronizados e rotação automática.
A AWS Secrets Manager já possuía um histórico comprovado de ajudar clientes a proteger e gerenciar segredos de serviços AWS como Amazon Relational Database Service (Amazon RDS) ou Amazon DocumentDB por meio de capacidades de rotação gerenciada. Construindo sobre esse sucesso, a funcionalidade de segredos externos gerenciados permite que os clientes armazenem segredos fornecidos por provedores de software terceirizados em formatos predefinidos.
Características principais
Esses formatos foram desenvolvidos em colaboração com parceiros de integração confiáveis para definir tanto a estrutura do segredo quanto os metadados necessários para rotação, eliminando a necessidade de definir estratégias de armazenamento personalizadas. A funcionalidade oferece integração automática com provedores de software, reduzindo a sobrecarga operacional enquanto beneficia de controles de segurança essenciais, incluindo:
Detecção automática de ameaças específicas de segredos por meio do Amazon GuardDuty
Além disso, os clientes podem implementar práticas centralizadas e consistentes de gerenciamento de segredos tanto para segredos AWS quanto de terceiros a partir de um único serviço, eliminando a necessidade de operar múltiplas soluções de gerenciamento de segredos em suas organizações.
Os segredos externos gerenciados seguem o padrão de precificação do Secrets Manager, sem custos adicionais pelo uso deste novo tipo de segredo.
Pré-requisitos
Para criar um segredo externo gerenciado, você precisa de:
Uma conta AWS ativa com acesso apropriado ao Secrets Manager
Permissões mínimas do Identidade e Acesso da AWS (IAM) para as ações: secretsmanager:DescribeSecret, secretsmanager:GetSecretValue, secretsmanager:UpdateSecret, e secretsmanager:UpdateSecretVersionStage
Credenciais válidas e permissões de acesso necessárias para o provedor de software terceirizado
Para chaves gerenciadas pelo cliente, você deve ter as políticas de chave necessárias configuradas, permitindo que o Secrets Manager use a chave para operações de criptografia e descriptografia
Criando um segredo externo gerenciado
Atualmente, os segredos externos gerenciados suportam três parceiros de integração: Salesforce, Snowflake e BigID. A AWS continua expandindo sua lista de parceiros e mais provedores de software terceirizados serão adicionados ao longo do tempo. Consulte a página de Parceiros de Integração para obter a lista mais recente.
Selecionando o tipo de segredo
Acesse o serviço AWS Secrets Manager no console e selecione “Armazenar um novo segredo”. Na seção de tipo de segredo, escolha “Segredo externo gerenciado”. Na seção de credencial de provedor terceirizado integrado, selecione seu provedor nas opções disponíveis.
Para este exemplo, usaremos as Credenciais de Aplicativo Cliente Externo do Salesforce. Insira suas configurações na seção de detalhes do segredo. As credenciais incluem vários componentes-chave:
Chave do consumidor (ID do cliente): Serve como identificador de credencial para OAuth 2.0. Você pode recuperá-la diretamente do gerenciador de aplicativos cliente externo Salesforce nas configurações OAuth
Segredo do consumidor (segredo do cliente): Funciona como senha privada para autenticação OAuth 2.0, recuperável nas mesmas configurações OAuth
Base URI: A URL base da sua organização Salesforce (formatada como https://MyDomainName.my.salesforce.com), usada para interagir com as APIs Salesforce
Selecione a chave de criptografia no menu suspenso. Você pode usar uma chave AWS KMS gerenciada ou uma chave AWS KMS gerenciada pelo cliente. Prossiga para a próxima etapa.
Forneça um nome descritivo e, opcionalmente, uma descrição detalhada que ajude a identificar o propósito e uso do segredo. Você também tem opções de configuração adicionais: pode anexar tags para melhor organização de recursos, definir permissões específicas de recurso para controlar o acesso e selecionar a opção de replicar segredo para resiliência em múltiplas regiões.
Configurando rotação e permissões (opcional)
Na etapa opcional de configuração de rotação, o novo tipo de segredo introduz duas seções principais focadas no gerenciamento de metadados, que são armazenados separadamente do valor do segredo propriamente dito.
Sob metadados de rotação, especifique a versão da API que seu aplicativo Salesforce está usando. A versão mínima necessária é v65.0. Você pode encontrar a versão consultando a documentação Salesforce para Listar Versões Disponíveis da API REST.
Selecione um ARN de segredo do administrador, que contém as credenciais OAuth administrativas usadas para girar o segredo do cliente Salesforce. Na seção de permissões de serviço para rotação de segredo, o Secrets Manager cria automaticamente uma função com permissões necessárias para girar seus valores de segredo. Essas permissões padrão são exibidas transparentemente na interface para revisão. Você pode desmarcar as permissões padrão para ter mais controle granular sobre o gerenciamento de rotação de segredo.
Revisando e confirmando
Na etapa final, você receberá um resumo da configuração de seu segredo. Na página de revisão, você pode verificar os parâmetros antes de prosseguir com a criação do segredo. Após confirmar que as configurações estão corretas, selecione “Armazenar” para concluir o processo e criar seu segredo com as configurações especificadas.
Após a criação bem-sucedida, seu segredo aparecerá na aba de segredos. Você pode visualizar, gerenciar e monitorar aspectos do seu segredo, incluindo sua configuração, status de rotação e permissões. Após a criação, revise sua configuração de segredo, incluindo configurações de criptografia e políticas de recursos para acesso entre contas, e examine o código de amostra fornecido para diferentes SDKs AWS para integrar a recuperação de segredo em suas aplicações.
A aba de segredos fornece uma visão geral de seus segredos, permitindo gerenciamento centralizado. Selecione seu segredo para visualizar os detalhes do segredo. Seu segredo externo gerenciado foi criado com sucesso no Secrets Manager. Você pode acessar e gerenciar este segredo através do console do Secrets Manager ou programaticamente usando as APIs AWS.
Para parceiros terceirizados: Integrando com o Secrets Manager
Com o novo tipo de segredo externo gerenciado, provedores de software terceirizados podem se integrar ao Secrets Manager e oferecer aos seus clientes uma forma programática de gerenciar com segurança os segredos fornecidos pelas suas aplicações na AWS. Essa integração fornece aos clientes uma solução centralizada para gerenciar tanto o ciclo de vida de segredos AWS quanto de terceiros, incluindo capacidades de rotação automática a partir do momento da criação do segredo.
Provedores de software como Salesforce já estão usando essa capacidade. Não há custos adicionais para integração como parceiro do Secrets Manager. Para começar, os parceiros devem seguir o processo listado no guia de integração de parceiros. Se você tiver dúvidas sobre se tornar um parceiro de integração, entre em contato com a equipe através do aws-secrets-mgr-partner-onboarding@amazon.com com o assunto: [Nome do Parceiro] Solicitação de Integração.
Conclusão
Os segredos externos gerenciados representam um avanço significativo na forma como as organizações podem gerenciar credenciais de provedores terceirizados. Ao eliminar a necessidade de definir estratégias de armazenamento personalizadas e desenvolver funções de rotação complexas, os clientes agora podem gerenciar consistentemente seus segredos, independentemente de serem de serviços AWS, aplicações personalizadas ou provedores terceirizados, a partir de um único serviço.
A funcionalidade oferece os mesmos recursos de segurança que os segredos padrão do Secrets Manager, incluindo gerenciamento de permissões granulares, observabilidade e controles de conformidade, enquanto adiciona integração integrada com parceiros confiáveis sem custos adicionais. O recurso está disponível em todas as regiões AWS onde o AWS Secrets Manager está disponível.
Para começar, consulte a documentação técnica. Para informações sobre migração de seus segredos de parceiros existentes para segredos externos gerenciados, consulte Migrando segredos existentes. Para uma lista de regiões onde o Secrets Manager está disponível, consulte a tabela de regiões AWS.
Gerenciamento simplificado de permissões em múltiplos warehouses
A AWS anunciou o suporte a permissões federadas no Amazon Redshift, uma funcionalidade importante para organizações que adotam arquiteturas multi-warehouse. Muitos clientes estão migrando para modelos baseados em múltiplos data warehouses justamente para escalar suas operações e isolar diferentes cargas de trabalho, mas enfrentavam o desafio de manter a governança de acesso consistente entre essas instâncias.
Com as permissões federadas, os administradores definem as políticas de acesso uma única vez, a partir de qualquer warehouse Redshift, e elas são aplicadas automaticamente em todos os warehouses da conta. Isso elimina a necessidade de replicar configurações de permissão manualmente, reduzindo erros e facilitando manutenção.
Funcionalidades principais
Aplicação automática de controles de acesso
Os warehouses Redshift com permissões federadas são montados automaticamente em cada instância Redshift disponível. Essa integração permite que você aproveite identidades do seu workforce já cadastradas no AWS IAM Identity Center (Centro de Identidade AWS) ou use papéis (IAM roles) existentes para consultar dados entre warehouses.
O controle de acesso funciona em múltiplos níveis: é possível aplicar restrições no nível de linha, no nível de coluna e implementar mascaramento de dados. Independentemente de qual warehouse seja utilizado para fazer a consulta, esses controles permanecem sempre ativos, garantindo conformidade de forma granular e consistente.
Escalabilidade sem complexidade adicional
Um dos benefícios mais relevantes das permissões federadas é a escalabilidade horizontal. Ao adicionar novos warehouses ao ambiente, as políticas de permissão são aplicadas automaticamente, sem que a complexidade de governança aumente proporcionalmente. Analistas e usuários finais já conseguem visualizar imediatamente todos os bancos de dados disponibilizados pelos warehouses registrados, sem necessidade de configurações manuais adicionais.
Como começar
Para iniciar o uso dessa funcionalidade, o primeiro passo é registrar um namespace Redshift Serverless ou um cluster Redshift provisionado com o AWS Glue Data Catalog. Feito isso, é possível começar a realizar consultas entre warehouses usando o Redshift Query Editor V2 ou qualquer cliente SQL compatível.
Ambientes de desenvolvimento gerenciados para ciência de dados
A Amazon SageMaker HyperPod com orquestração via Amazon Elastic Kubernetes Service (EKS) agora oferece suporte à criação e gerenciamento de ambientes de desenvolvimento interativos, incluindo JupyterLab e Visual Studio Code de código aberto. Essa integração simplifica o ciclo de vida do desenvolvimento de aprendizado de máquina, fornecendo ambientes gerenciados que trabalham com as ferramentas que os cientistas de dados já conhecem e utilizam.
A novidade central é um novo complemento chamado Amazon SageMaker Spaces, que permite aos desenvolvedores de IA criar e gerenciar ambientes isolados e configuráveis para execução de notebooks e desenvolvimento interativo. A integração permite que as organizações otimizem seus investimentos em GPU ao executar simultaneamente cargas de trabalho interativas e jobs de treinamento na mesma infraestrutura, com suporte para alocações fracionadas de GPU. Isso reduz significativamente a complexidade de gerenciar múltiplos ambientes de desenvolvimento, permitindo que as equipes se concentrem na construção e implantação de modelos de IA e aprendizado de máquina.
Como funcionam os Spaces
Os Spaces operam através de uma arquitetura coordenada entre diferentes componentes. O processo começa quando um administrador de cluster instala o complemento Spaces a partir do console do SageMaker AI, escolhendo entre uma instalação rápida ou uma instalação personalizada.
Uma vez que o cluster está configurado, cientistas de dados e desenvolvedores de IA podem criar Spaces utilizando a Interface de Linha de Comando (CLI) do HyperPod ou kubectl. Após a criação de um Space, os usuários podem se conectar através de duas abordagens principais:
Acesso via Interface Web: Esta opção requer configuração de um Balanceador de Carga de Aplicação (ALB) da AWS e registro de um domínio personalizado no Amazon Route 53. Com um domínio configurado, os usuários acessam de forma segura JupyterLab ou Code Editor através do navegador usando uma URL pré-assinada.
Conexão de IDE Remota: Para usuários que preferem trabalhar localmente no Visual Studio Code, a conexão utiliza túneis SSH-over-SSM (Sessions Manager), permitindo acesso seguro aos pods do SageMaker Spaces sem necessidade de gerenciar chaves SSH ou expor portas diretamente.
Pré-requisitos e preparação
Para implementar essa solução, você precisa de uma conta AWS com permissões adequadas para criar funções de Identidade e Acesso (IAM), recursos do SageMaker como HyperPod, e acesso aos recursos de cluster do EKS. Se estiver criando um novo cluster HyperPod, você também necessitará permissões para criar recursos de rede e armazenamento (consulte a documentação sobre permissões de IAM para criação de cluster).
O processo de instalação começa acessando o console do SageMaker AI, navegando até a seção de Clusters e selecionando seu cluster HyperPod. Na aba “IDE e Notebooks”, você encontrará a opção de instalação rápida, que representa o caminho mais eficiente para começar. Com um único clique, o SageMaker AI cria e configura automaticamente os recursos AWS necessários com padrões otimizados.
A instalação rápida configura automaticamente as dependências necessárias para o complemento Spaces. Essas incluem funções de IAM específicas para o controller de Spaces (responsável por chamadas de API da AWS e operações do AWS Systems Manager Session Manager), um roteador em cluster para operações de Serviço de Gerenciamento de Chaves (KMS) da AWS e assinatura de JWT, e uma função de instância gerenciada pelo SSM para acesso remoto.
Os complementos dependentes do EKS também são instalados, incluindo Cert-manager para gerenciamento de certificados, o driver de Armazenamento em Bloco Elástico (EBS) da CSI para volumes de armazenamento persistente, e o Controlador de Balanceador de Carga da AWS para gerenciar Balanceadores de Carga Elásticos. Para detalhes completos sobre configurações de permissão, consulte a documentação de configuração de permissões.
A instalação rápida não inclui configurações de interface web como registros de DNS no Route 53 e certificados SSL. Administradores podem usar a opção de instalação personalizada ou configurar essas propriedades após a instalação. Para ambientes de produção, recomenda-se a opção de instalação personalizada, permitindo que os administradores configurem políticas de IAM mais granulares seguindo o princípio de menor privilégio. Consulte a documentação de instalação do operador via helm/Console para orientações sobre acesso via navegador web.
Tipicamente, a instalação completa em 2 a 5 minutos, dependendo da disponibilidade de dependências pré-existentes ou se o complemento Spaces precisará provisionar recursos completamente novos. Após conclusão, administradores conseguem visualizar Spaces criados por cientistas de dados, configurar namespaces para organizar Spaces por equipe ou projeto, e criar templates de Space com configurações pré-definidas para casos de uso comuns.
Configuração de acesso dos usuários
Para conceder acesso aos usuários para criar e gerenciar Spaces, você deve configurar entradas de acesso do EKS. Duas políticas de entrada de acesso são necessárias: AmazonSagemakerHyperpodSpacePolicy e AmazonSagemakerHyperpodSpaceTemplatePolicy. Para instruções detalhadas, consulte a documentação sobre criação de entradas de acesso e atualização de entradas de acesso.
Criação e gerenciamento de Spaces
Cientistas de dados podem criar JupyterLab e Code Editor Spaces no cluster utilizando kubectl ou a CLI do HyperPod. Para criar um Space, você define o contexto do cluster e executa o comando de criação:
Alternativamente, você pode conectar ao Space usando o toolkit da AWS diretamente do Visual Studio Code local. Abra o painel do AWS Toolkit, navegue até SageMaker AI e HyperPod para listar, iniciar, parar e conectar aos Spaces.
A CLI do HyperPod oferece operações CRUD completas nos Spaces, incluindo atualização, descrição e exclusão. Para uma lista completa de operações, consulte o repositório do HyperPod CLI no Github. Usuários familiarizados com kubectl também podem criar, atualizar e excluir Spaces usando YAML:
Os Spaces utilizam Entradas de Acesso do EKS para identificar usuários, derivadas de suas identidades de IAM. A identidade capturada pelo EKS pode aparecer como um usuário de IAM ou como um ARN de sessão com role assumido. Para roles assumidas, o nome da sessão pode representar o usuário real quando o administrador aplica políticas de IAM que reforçam nomes de sessão únicos. Se os nomes de sessão não forem impostos ou não mapearem exclusivamente para usuários, o controle de acesso dos Spaces recai para controle baseado em papéis. Consulte a documentação para adicionar usuários e configurar contas de serviço.
Spaces podem ser privados (acessíveis apenas pelo criador) ou públicos (acessíveis por qualquer usuário com acesso ao namespace Kubernetes). Por padrão, os Spaces são públicos. O criador e o grupo de administrador mantêm controle total, incluindo capacidade de atualizar ou excluir o Space. Um Space torna-se privado apenas quando o acesso é restrito ao criador e grupo de administrador. Múltiplos usuários podem colaborar no mesmo Space se configurado como compartilhado. Quando habilitado com imagens de SageMaker Distribution para ambientes JupyterLab, há suporte a colaboração em tempo real (RTC), permitindo que múltiplos usuários colaborem em experimentos e cargas de trabalho interativas de aprendizado de máquina.
Templates e controles padrão do administrador
Templates configurados por administradores ajudam cientistas de dados a utilizar rapidamente configurações de Space pré-definidas para seus casos de uso. A AWS fornece dois templates de sistema pré-criados, um para JupyterLab e outro para Code Editor, permitindo que cientistas de dados iniciem sem configurações adicionais. Administradores também podem criar templates customizados com configurações específicas como imagem, armazenamento e computação. Múltiplos templates podem ser criados com base em casos de uso, projetos ou requisitos de dependência específicos.
Customização de Spaces
Administradores e desenvolvedores podem customizar Spaces usando imagens customizadas e scripts de ciclo de vida. Use scripts de ciclo de vida para customizações mínimas como instalar pacotes adicionais, configurar variáveis padrão ou executar tarefas de limpeza, mantendo as capacidades da imagem SageMaker Distribution. Para organizações que possuem imagens padronizadas para desenvolvimento e treinamento, o SageMaker Spaces oferece suporte a imagens customizadas e entry points. Consulte a documentação de customização para especificações de imagens customizadas.
Desligamento automático de computação ociosa
Os Spaces suportam desligamento automático de workspaces ociosos para otimizar o uso de recursos. Quando habilitado, o sistema verifica periodicamente a atividade do Space e, se o workspace permanecer ocioso durante o tempo limite especificado, o workspace para automaticamente, liberando recursos de computação para outras tarefas. Administradores podem configurar timeouts padrão e opcionalmente evitar que usuários substituam esses padrões para reforçar políticas de desligamento automático.
Integração com outros complementos do HyperPod
Para guardrails contra uso excessivo de recursos, configure governança de tarefas do HyperPod, que fornece controles abrangentes de gerenciamento de recursos. Para ajudar a prevenir que workspaces sejam removidos por mudanças em cargas de trabalho não relacionadas, configure a governança de tarefas para definir cargas de trabalho de aprendizado de máquina interativo com prioridade máxima ou agende-as em namespaces da governança de tarefas com remoção desabilitada.
Configure o plugin de Observabilidade do HyperPod para monitorar o uso de recursos dos Spaces em execução no cluster. Com instalação de um clique, o plugin de observabilidade fornece visibilidade sobre quantos recursos os Spaces estão consumindo ao longo do tempo, permitindo que administradores observem e ajustem alocações de computação.
Suporte a GPU fracionada
O SageMaker Spaces suporta configurações de GPU fracionada, especificamente a tecnologia MIG (Multi-Instance GPU) da NVIDIA. O suporte a GPU fracionada significa que usuários podem compartilhar instâncias de GPU, otimizando o uso de computação enquanto mantêm isolamento entre cargas de trabalho. Experimentos executados em um perfil de GPU fracionada são menos propensos a interferir em outras cargas de trabalho executadas na mesma GPU. Para verificar se uma instância no seu cluster suporta GPU fracionada, execute:
Para evitar custos desnecessários, remova os recursos criados. Exclua todos os Spaces que você criou:
hyp delete hyp-space \
--name <space-name>
Remova o complemento SageMaker HyperPod Spaces navegando até a página de detalhes do cluster, acessando a aba “IDE e Notebooks” e escolhendo “Remover”. Se criou um cluster HyperPod especificamente para teste, delete-o seguindo as instruções em exclusão de um cluster SageMaker HyperPod. Adicionalmente, se usou o console para criar o cluster, acesse o console do AWS CloudFormation e exclua a stack principal para remover recursos adicionais como armazenamento e recursos de rede. A stack estará no formato: sagemaker-<your-hyperpod-cluster-name>-<unique-id>
Conclusão
Os Spaces no SageMaker HyperPod potencializam a produtividade de cientistas de dados e desenvolvedores de IA ao fornecer ambientes de desenvolvimento mais seguros e gerenciados em computação de propósito específico. A integração entre ambientes familiares como JupyterLab e VS Code com a infraestrutura de cluster gerenciada simplifica significativamente o ciclo de vida do desenvolvimento. As equipes conseguem reduzir o tempo gasto em configuração de ambiente e focar em construção e implantação de modelos, mantendo ambientes de desenvolvimento consistentes. Através de integração com recursos de governança de tarefas do HyperPod, administradores otimizam custos e alocações equitativas de computação em toda a organização.
O modelo de linguagem mais recente da Anthropic, o Claude Opus 4.5, está agora disponível no Amazon Bedrock, um serviço gerenciado que oferece acesso a modelos de linguagem de alto desempenho de empresas líderes em inteligência artificial. O Opus 4.5 representa um avanço significativo no que os sistemas de inteligência artificial podem realizar e estabelece novos patamares em programação, agentes de IA, interação com computadores e tarefas de produtividade.
Este modelo se destaca por superar tanto o Sonnet 4.5 quanto o Opus 4.1, enquanto oferece capacidades equivalentes às do Opus com um terço do custo anterior. Sua arquitetura foi especificamente projetada para desenvolvedores que constroem agentes de IA sofisticados—sistemas capazes de raciocinar, planejar e executar tarefas complexas com mínima supervisão humana.
O que distingue o Opus 4.5
Engenharia de software e codificação
O Opus 4.5 demonstra desempenho excepcional em desenvolvimento profissional de software, alcançando 80,9% no benchmark SWE-bench Verified. Isso significa que o modelo pode transformar projetos de desenvolvimento que levariam vários dias em tarefas executáveis em horas. O modelo trabalha independentemente e inclui capacidades aprimoradas de codificação multilíngue, gerando código mais eficiente, melhor cobertura de testes e arquiteturas mais limpas.
Produtividade em tarefas empresariais
Para operações corporativas, o Opus 4.5 gerencia projetos complexos do início ao fim. Ele capacita agentes para criar apresentações em PowerPoint, planilhas em Excel e documentos em Word com acabamento profissional, incluindo revisão detalhada de documentos para contratos e acordos de não divulgação. O modelo também produz artefatos de React e HTML de qualidade superior, mantendo consistência e precisão—aspectos críticos para setores como finanças, onde a exatidão é fundamental. Ele preserva contexto entre arquivos durante projetos longos, garantindo coerência nas decisões.
Raciocínio visual avançado
Esta é a melhor capacidade de visão que a Anthropic ofereceu até agora, alcançando 80,7% no benchmark MMMU para fluxos de trabalho que dependem de interpretação visual complexa e navegação em múltiplas etapas. Exemplos incluem análise de mockups de design, processamento de documentos com layouts complexos e automatização de tarefas baseadas em navegação do navegador—com desempenho ainda mais aprimorado em interação com computadores.
Melhorias para desenvolvimento de agentes
O modelo introduz dois aprimoramentos-chave para desenvolvedores que criam agentes. A ferramenta de busca de ferramentas permite que agentes trabalhem com centenas de ferramentas descobrindo e carregando dinamicamente apenas aquelas que precisam, em vez de carregar todas as definições antecipadamente—potencialmente economizando dezenas de milhares de tokens e evitando confusão de esquemas ao escalar para grandes bibliotecas de ferramentas. Os exemplos de uso de ferramentas permitem fornecer chamadas de ferramentas exemplares diretamente na definição da ferramenta, melhorando a precisão para esquemas complexos com objetos ou arrays aninhados.
Benchmarks de desempenho do Claude Opus 4.5 — Fonte: Anthropic
Casos de uso principais
Desenvolvimento de software
O Opus 4.5 é ideal para construir agentes que escrevem e refatoram código em projetos inteiros, gerenciam arquiteturas completas ou projetam sistemas multiagente que decompõem objetivos de alto nível em passos executáveis. A geração Claude abrange o ciclo completo de desenvolvimento: Opus 4.5 para código de produção e agentes sofisticados que usam 10 ou mais ferramentas em fluxos de trabalho como engenharia de software completa, cibersegurança ou análise financeira; Sonnet 4.5 para iteração rápida e experiências de usuário em escala; Haiku 4.5 para subagentos e produtos de acesso gratuito.
O Opus 4.5 pode analisar documentação técnica, planejar uma implementação de software, escrever o código necessário e refiná-lo iterativamente—mantendo rastreabilidade dos requisitos e contexto arquitetônico durante todo o processo.
Operações empresariais
Para gerenciar projetos complexos do início ao fim, o Opus 4.5 utiliza memória para manter contexto e consistência entre arquivos, com melhorias adicionais na criação de planilhas, slides e documentos. O modelo lida com projetos corporativos contínuos, automatizando fluxos de trabalho manuais.
Análise financeira
O modelo funciona eficientemente em sistemas complexos de informações—arquivos regulatórios, relatórios de mercado, dados internos—possibilitando modelagem preditiva e conformidade proativa. Sua consistência e precisão o tornam valioso para finanças e outros setores onde a exatidão é fundamental.
Cibersegurança
O Opus 4.5 oferece análise de nível profissional em fluxos de trabalho de segurança, correlacionando logs, bancos de dados de problemas de segurança e inteligência de segurança para detecção de eventos de segurança e resposta a incidentes automatizada.
Integração com o Amazon Bedrock AgentCore
A AWS fornece a fundação corporativa para implantar o Opus 4.5 em produção através do Amazon Bedrock AgentCore. O serviço gerenciado oferece uma API unificada para modelos de linguagem com segurança de nível corporativo, conformidade e governança.
O Opus 4.5 se integra ao AgentCore, que fornece infraestrutura e elementos primitivos para construir agentes de produção. O AgentCore inclui memória persistente para manter contexto entre sessões, o Gateway de Ferramentas para converter suas APIs e funções Lambda em ferramentas compatíveis com agentes, e gerenciamento de identidade e acesso integrado para acesso seguro aos recursos.
Você pode implantar e monitorar agentes com isolamento completo de sessão, suporte para fluxos de trabalho de longa duração (até 8 horas) e recursos de observabilidade—permitindo que você se concentre na construção de agentes em vez de gerenciar infraestrutura.
O Gateway de Ferramentas converte suas APIs e funções Lambda existentes em ferramentas compatíveis com agentes com mínimo de código—funcionando junto com o recurso de busca de ferramentas do modelo para orquestrar centenas de ferramentas. A observabilidade integrada através do Amazon CloudWatch rastreia uso de tokens, latência e taxas de erro em seus fluxos de trabalho de agentes.
Como começar
Para começar a usar o Opus 4.5 no Amazon Bedrock, você precisa configurar um cliente Python e importar as bibliotecas necessárias:
Neste exemplo, definimos múltiplas ferramentas com defer_loading para ativar a busca de ferramentas. Isso permite que o modelo descubra e carregue apenas as ferramentas que necessita em vez de carregar todas as definições antecipadamente:
Agora invocamos o modelo usando a Aplicação Programática (API) invoke_model com o parâmetro effort definido como médio:
# Construir a requisição com recursos beta ativados
request_body = {
"anthropic_version": "bedrock-2023-05-31",
# Ativar recursos beta: busca de ferramentas, exemplos de ferramentas e parâmetro effort
"anthropic_beta": ["tool-search-tool-2025-10-19", "tool-examples-2025-10-29", "effort-2025-11-24"],
"max_tokens": 4096,
"temperature": 0.7,
# Definir effort para "medium" para uso equilibrado de tokens
"output_config": {
"effort": "medium"
},
"messages": [
{
"role": "user",
"content": "What's the weather in Seattle?"
}
],
"tools": tools
}
# Invocar o modelo
response = bedrock_client.invoke_model(
modelId="global.anthropic.claude-opus-4-5-20251101-v1:0",
body=json.dumps(request_body)
)
# Fazer parsing da resposta
response_body = json.loads(response['body'].read())
O modelo utiliza busca de ferramentas para localizar a ferramenta relevante (get_weather) da biblioteca sem carregar todas as definições de ferramentas antecipadamente. O parâmetro effort, disponível em versão beta, controla quanto liberalmente o modelo gasta tokens em raciocínio, chamadas de ferramentas e respostas. Você pode definir effort como alto para melhores resultados, médio para uso equilibrado ou baixo para uso conservador de tokens.
Capacidades principais para desenvolvimento de agentes
O Opus 4.5 possui várias capacidades que o tornam adequado para construir agentes em produção. O modelo mantém coerência em fluxos de trabalho estendidos, permitindo tomada de decisão consistente para agentes que executam processos com múltiplas etapas ao longo de horas ou dias. Melhor manipulação de ferramentas significa que agentes interagem mais confiávelmente com sistemas externos, Aplicações Programáticas (APIs) e interfaces de software—o modelo escolhe as ferramentas certas e interpreta resultados com maior precisão.
O Opus 4.5 também rastreia informações entre conversas e mantém contexto, ajudando agentes a acumular conhecimento ao longo do tempo e tomar decisões baseadas em histórico. O parâmetro effort, disponível em versão beta, oferece controle sobre uso de tokens. Você pode defini-lo como alto para melhores resultados quando qualidade importa mais, médio para desempenho equilibrado ou baixo para uso conservador de tokens. O Opus 4.5 ajusta o gasto de tokens entre raciocínio, chamadas de ferramentas e respostas com base nesta configuração.
Para implantações em produção, o Amazon Bedrock AgentCore oferece monitoramento e observabilidade através da integração com CloudWatch, rastreando uso de tokens em tempo real (útil ao ajustar o parâmetro effort), junto com métricas de latência, duração da sessão e taxas de erro para ajudar a otimizar desempenho do agente e gerenciar custos.
Preços e disponibilidade
O modelo é precificado em $5 por milhão de tokens de entrada e $25 por milhão de tokens de saída, tornando a inteligência em nível Opus acessível a um terço do custo das ofertas anteriores.
O modelo está disponível hoje no Amazon Bedrock através de inferência entre regiões, que roteia automaticamente requisições para capacidade disponível em regiões da AWS para maior throughput durante picos de demanda. Use este modelo para agentes que lidam com tarefas de longa duração, coordenam múltiplas ferramentas ou mantêm contexto em sessões estendidas.
Para informações detalhadas sobre disponibilidade, preços e especificações do modelo, consulte a documentação do Amazon Bedrock.
Para implantar agentes em escala, explore o Opus 4.5 no Amazon Bedrock AgentCore para obter infraestrutura gerenciada com orquestração de ferramentas e monitoramento. O Opus 4.5 se destaca em fluxos de trabalho complexos e de longa duração, como desenvolvimento de software e operações empresariais. Suas capacidades em manipulação de ferramentas, gerenciamento de contexto e tomada de decisão o tornam valioso para construir agentes que operam de forma confiável em ambientes de produção.
A principal vantagem dessa abordagem é eliminar a necessidade de gerenciar múltiplos endpoints ou infraestruturas isoladas. Após fazer o upload dos arquivos do modelo para o Amazon S3 (Amazon Simple Storage Service), a AWS assume todas as operações complexas: provisionamento de GPUs (Processadores Gráficos), configuração de servidores de inferência e dimensionamento automático conforme a demanda. Dessa forma, as equipes podem concentrar-se no desenvolvimento de aplicações enquanto a infraestrutura é gerenciada automaticamente.
Fluxo de importação: do modelo Hugging Face ao envio do S3, processamento no Bedrock e execução via API compatível com OpenAI — fonte: Aws
Compatibilidade com a API do OpenAI
Os modelos GPT-OSS suportam completamente a API de Conclusões de Chat do OpenAI, mantendo compatibilidade integral com aplicações existentes. Isso significa que recursos como matrizes de mensagens, definições de papéis (sistema, usuário ou assistente) e estruturas de resposta padrão — incluindo métricas de uso de tokens — funcionam sem modificações.
Ao apontar suas aplicações para os endpoints do Amazon Bedrock, o código existente requer mudanças mínimas ou nenhuma mudança. Essa continuidade reduz significativamente o esforço de migração e o risco de regressões em produção.
Entendendo os Modelos GPT-OSS
Os modelos GPT-OSS representam os primeiros modelos de linguagem com pesos abertos lançados pela OpenAI desde o GPT-2, distribuídos sob a licença Apache 2.0. Isso significa que qualquer organização pode fazer download, modificar e utilizar esses modelos sem custos adicionais, inclusive para aplicações comerciais.
GPT-OSS-20B (20 Bilhões de Parâmetros)
Este modelo é otimizado para situações onde velocidade e eficiência são críticas. Apesar de possuir 21 bilhões de parâmetros, apenas 3,6 bilhões são ativados por token, permitindo execução em dispositivos com apenas 16 GB de memória. Com 24 camadas, 32 especialistas (4 ativos por token) e janela de contexto de 128k, oferece desempenho comparável ao o3-mini da OpenAI com a vantagem de poder ser implantado localmente para respostas mais rápidas.
GPT-OSS-120B (120 Bilhões de Parâmetros)
Desenvolvido para tarefas complexas de raciocínio — como codificação, matemática e uso de ferramentas em agentes automáticos — este modelo ativa 5,1 bilhões de parâmetros por token. Com 36 camadas, 128 especialistas (4 ativos por token) e janela de contexto de 128k, atinge desempenho equivalente ao o4-mini da OpenAI executando eficientemente em uma única Unidade de Processamento Gráfico (GPU) de 80 GB.
Arquitetura de Mistura de Especialistas
Ambos os modelos utilizam uma arquitetura de Mistura de Especialistas (MoE). Nessa abordagem, diferentes subconjuntos dos componentes do modelo (chamados de especialistas) tratam diferentes tipos de tarefas. Para cada requisição, apenas os especialistas mais relevantes são ativados, oferecendo desempenho potente enquanto mantém os custos computacionais gerenciáveis.
Formato dos Arquivos do Modelo GPT-OSS
Quando você faz download de modelos GPT-OSS do Hugging Face, recebe vários tipos de arquivo que trabalham em conjunto:
Arquivos de pesos (.safetensors): Contêm os parâmetros reais do modelo
Arquivos de configuração (config.json): Definem como o modelo funciona
Arquivos do tokenizador: Realizam o processamento de texto
Arquivo de índice (model.safetensors.index.json): Mapeia dados de pesos para arquivos específicos
O arquivo de índice exige uma estrutura específica para funcionar com o Amazon Bedrock. Deve incluir um campo de metadados no nível raiz, que pode estar vazio ({}) ou conter o tamanho total do modelo (que precisa estar abaixo de 200 GB para modelos de texto).
Modelos do Hugging Face às vezes incluem campos de metadados extras — como total_parameters — que o Amazon Bedrock não suporta. Esses campos devem ser removidos antes da importação. A estrutura correta deve ser assim:
Criar trabalhos de importação de modelos no Amazon Bedrock
Fazer upload de arquivos para o Amazon S3
Invocar modelos após implantação
Usar a função de serviço do Custom Model Import
Um bucket S3 na sua região AWS de destino
Aproximadamente 40 GB de espaço em disco local para download do modelo
Acesso à Região US East 1 (N. Virginia) — obrigatória para modelos personalizados baseados em GPT-OSS
Interface de Linha de Comando da AWS (AWS CLI) versão 2.x instalada
Interface de Linha de Comando do Hugging Face (instale com pip install -U "huggingface_hub[cli]")
Download e Preparação dos Arquivos do Modelo
Para fazer download do modelo GPT-OSS usando a biblioteca Hugging Face Hub com transferência rápida habilitada:
import os
os.environ['HF_HUB_ENABLE_HF_TRANSFER'] = '1'
from huggingface_hub import snapshot_download
local_dir = snapshot_download(
repo_id="Tonic/med-gpt-oss-20b",
local_dir="./med-gpt-oss-20b",
)
print(f"Download complete! Model saved to: {local_dir}")
Após o download ser concluído (típicamente entre 10 a 20 minutos para 40 GB), verifique a estrutura do arquivo model.safetensors.index.json. Edite-o se necessário para garantir que o campo de metadados exista (pode estar vazio):
O envio de 40 GB normalmente é concluído em 5 a 10 minutos. Para verificar se os arquivos foram enviados:
aws s3 ls s3://amzn-s3-demo-bucket/med-gpt-oss-20b/ --human-readable
Anote o URI do S3 (por exemplo, s3://amzn-s3-demo-bucket/med-gpt-oss-20b/) para usar no trabalho de importação. Os arquivos de saída são criptografados com as configurações de criptografia do bucket S3, seja com criptografia do lado do servidor SSE-S3 (Criptografia de Lado do Servidor S3) ou AWS Key Management Service (AWS KMS) dependendo de como você configurou o bucket.
Exemplo de arquivos do modelo armazenados no bucket S3 — fonte: Aws
Importação do Modelo no Amazon Bedrock
Após fazer upload dos arquivos do modelo para o S3, você pode importá-lo para o Amazon Bedrock, onde será processado e disponibilizado para inferência.
Use o AWS CLI para criar o trabalho de importação:
A importação do modelo normalmente é concluída em 10 a 15 minutos para um modelo de 20B de parâmetros. Você pode acompanhar o progresso no console do Amazon Bedrock ou via AWS CLI. Após a conclusão, anote seu importedModelArn, que será usado para invocar o modelo.
Interface de importação de modelo no console do Amazon Bedrock — fonte: Aws
Invocação do Modelo com API Compatível com OpenAI
Após a conclusão da importação, você pode testar o modelo usando o formato familiar da API de Conclusões de Chat do OpenAI para verificar se está funcionando corretamente.
Crie um arquivo chamado test-request.json com o seguinte conteúdo:
{
"messages": [
{
"role": "system",
"content": "You are a helpful AI assistant."
},
{
"role": "user",
"content": "What are the common symptoms of Type 2 Diabetes?"
}
],
"max_tokens": 500,
"temperature": 0.7
}
Use o AWS CLI para enviar a requisição ao seu endpoint de modelo importado:
{
"id": "chatcmpl-f06adcc78daa49ce9dd2c58f616bad0c",
"object": "chat.completion",
"created": 1762807959,
"model": "YOUR-ACCOUNT-ID-MODEL-ID",
"choices": [
{
"index": 0,
"message": {
"role": "assistant",
"content": "Type 2 Diabetes often presents with a range of symptoms...",
"refusal": null,
"function_call": null,
"tool_calls": []
},
"finish_reason": "stop"
}
],
"usage": {
"prompt_tokens": 98,
"completion_tokens": 499,
"total_tokens": 597
}
}
A estrutura da resposta corresponde exatamente ao formato do OpenAI — choices contém a resposta, usage fornece contagens de tokens e finish_reason indica o status de conclusão. O código existente de análise de resposta do OpenAI funciona sem modificações.
Migração do OpenAI para Amazon Bedrock
Migrar do OpenAI requer apenas mudanças mínimas no código — apenas o método de invocação muda, enquanto as estruturas de mensagens permanecem idênticas.
A migração é direta e oferece vantagens significativas: custos previsíveis, melhor privacidade de dados e a capacidade de ajustar modelos para necessidades específicas.
Limpeza de Recursos
Quando terminar, limpe seus recursos para evitar cobranças desnecessárias:
Se não precisar mais da função IAM, delete-a usando o console do IAM.
Práticas Recomendadas
Considere as seguintes práticas recomendadas ao trabalhar com importação de modelos:
Validação de arquivos: Antes de fazer upload, verifique se model.safetensors.index.json tem a estrutura de metadados correta, se os arquivos safetensors referenciados existem e se os tokenizadores são suportados. A validação local economiza tempo em tentativas de importação.
Segurança: No console do Amazon Bedrock, crie funções IAM automaticamente com permissões de privilégio mínimo. Para múltiplos modelos, use prefixos S3 separados para manter isolamento.
Versionamento: Use caminhos descritivos no S3 (como gpt-oss-20b-v1.0/) ou nomes de trabalhos de importação com data para rastreamento de implantações.
O Amazon Bedrock Custom Model Import está disponível em múltiplas regiões, com suporte se expandindo para regiões adicionais em breve. Consulte Suporte de recursos por região AWS no Amazon Bedrock para as atualizações mais recentes. Os modelos GPT-OSS estarão inicialmente disponíveis na Região US-East-1 (N. Virginia).
Conclusão
O Amazon Bedrock Custom Model Import oferece às organizações a capacidade de trazer modelos GPT-OSS para um ambiente gerenciado e serverless, mantendo compatibilidade total com a API do OpenAI. Isso reduz significativamente o esforço de migração de aplicações existentes para a AWS.
Os benefícios práticos são evidentes: segurança de nível empresarial, dimensionamento automático, controle de custos previsível, privacidade de dados aprimorada e a possibilidade de ajustar modelos com seus próprios dados proprietários. Tudo isso com mudanças mínimas no código existente.
Tem dúvidas ou feedback? Conecte-se com a comunidade através do AWS re:Post para Amazon Bedrock — eles adorariam ouvir sobre sua experiência.
Compartilhamento inteligente de capacidade reservada
A AWS anunciou uma nova funcionalidade para o Amazon EC2 chamada Capacity Reservations Interruptíveis. Este recurso foi desenvolvido para ajudar as organizações a aproveitar melhor sua capacidade computacional reservada, ao mesmo tempo em que reduzem despesas operacionais.
As Capacity Reservations On-Demand (ODCRs) já permitem que você reserve capacidade computacional em uma Zona de Disponibilidade específica por qualquer duração desejada. Com a novidade, quando essa capacidade reservada não está sendo utilizada, ela pode ser disponibilizada temporariamente como ODCR interruptível, permitindo que outras cargas de trabalho dentro da organização façam uso dela.
Como funciona o compartilhamento de capacidade
O maior diferencial dessa abordagem é que o proprietário da reserva mantém total controle: pode recuperar sua capacidade a qualquer momento quando precisar. Enquanto isso, os consumidores da ODCR interruptível têm seus processos interrompidos de forma controlada, recebendo notificação prévia que permite encerramento elegante ou checkpoint antes da finalização.
Aplicações práticas ideais
Essa funcionalidade é especialmente benéfica para cargas de trabalho flexíveis e tolerantes a falhas, como:
Processamento em lote (batch processing)
Análise de dados
Treinamento de modelos de machine learning
Esses tipos de operações conseguem aproveitar a capacidade temporariamente disponível sem serem críticas ao negócio, representando economia significativa de investimento em infraestrutura.
Disponibilidade e custos
As Capacity Reservations Interruptíveis estão disponíveis agora, sem custos adicionais para todos os clientes que já utilizam o serviço de Capacity Reservations. A funcionalidade já está acessível em várias regiões — consulte o site de Capacidades por Região da AWS para verificar a disponibilidade em sua região.
Suporte via CloudFormation será implementado em breve, permitindo integração ainda mais fluida com infraestrutura como código. Para mais detalhes técnicos, recomendamos consultar o guia de usuário sobre Capacity Reservations.
Impacto na estratégia de custos em nuvem
Essa inovação reforça a tendência de otimização de custos na computação em nuvem, permitindo que organizações maximizem o retorno de seus investimentos em reservas de capacidade. A flexibilidade de repurposear capacidade ociosa transforma custos fixos em oportunidades de economia, sem comprometer a disponibilidade de recursos críticos quando necessário.
A AWS anunciou o suporte para Autenticação TLS Mútua (mTLS) no CloudFront, um protocolo de segurança que exige que tanto o servidor quanto o cliente se autentiquem mutuamente utilizando certificados X.509. Com esse recurso, os clientes conseguem validar a identidade dos acessantes nas localizações edge do CloudFront, antes que as conexões cheguem aos servidores de aplicação ou APIs.
Até então, as empresas precisavam investir esforço contínuo para implementar e manter suas próprias soluções de gestão de acesso de clientes — uma tarefa repetitiva e sem agregação de valor diferenciado. Agora, a autenticação mútua TLS simplifica esse processo, garantindo que apenas clientes portadores de certificados confiáveis consigam acessar as distribuições do CloudFront.
Benefícios práticos para sua infraestrutura
Com essa novidade, é possível proteger distribuições contra acessos não autorizados e ameaças de segurança, validando identidades de clientes no edge antes de qualquer conexão ser estabelecida. O uso de autenticação mútua TLS no CloudFront oferece os mesmos benefícios de performance e escala da plataforma, agora aplicados a workloads que demandam autenticação de clientes.
O recurso está disponível para todos os clientes do CloudFront sem custo adicional e pode ser configurado através do Console de Gerenciamento da AWS, CLI, SDK, CDK e CloudFormation.
Casos de uso principais
Integrações seguras de APIs B2B
Para cenários B2B, empresas podem autenticar requisições de API provenientes de parceiros e terceiros confiáveis utilizando autenticação mútua TLS. Isso é especialmente valioso para integrações entre organizações que precisam validar identidades em cada transação.
Autenticação de dispositivos IoT
Em ambientes com Internet das Coisas, é possível validar que apenas dispositivos autorizados recebem conteúdo proprietário, como atualizações de firmware. Dessa forma, garante-se que apenas equipamentos legítimos acessam recursos críticos.
Flexibilidade para escolher certificados
Os clientes podem aproveitar Autoridades de Certificação de terceiros já existentes ou utilizar a Autoridade de Certificados Privada da AWS para assinar certificados X.509. Essa flexibilidade permite que as organizações continuem usando sua infraestrutura de certificados ou adotem a solução gerenciada pela AWS conforme sua necessidade.
Como começar
Para empresas que desejam implementar essa solução, a AWS fornece orientações detalhadas e boas práticas na documentação de autenticação mútua TLS do CloudFront. O processo de configuração é direto e integrado aos fluxos de trabalho já familiares aos usuários da plataforma.
A AWS anunciou recentemente melhorias significativas nas capacidades de análise de logs do Amazon OpenSearch Service. A principal novidade está na transformação do espaço de Observabilidade da interface do OpenSearch, onde a Linguagem de Processamento em Pipe (PPL) e as consultas em linguagem natural agora funcionam como experiência padrão. Essa mudança combina a sintaxe comprovada de pipelines com fluxos de trabalho simplificados, oferecendo aos usuários uma experiência mais intuitiva para monitorar sistemas em escala crescente sem aumentar custos.
Capacidades Expandidas para Análise Profunda
A atualização disponibiliza mais de 35 novos comandos que ampliam as possibilidades de análise. Esses comandos permitem exploração em facetas, consultas em linguagem natural e análise profunda de dados, habilitando times a extrair insights significativos sobre infraestrutura, segurança e métricas de negócio. A solução também incorpora recursos de nível empresarial para correlação avançada de eventos usando linguagem natural, auxiliando equipes a descobrir padrões relevantes de forma mais ágil.
Interface Unificada e Mais Produtiva
Um diferencial importante é a possibilidade de transição perfeita entre consultas e visualizações dentro de uma única interface. Esse design reduz o tempo médio para detectar e resolver problemas, eliminando a necessidade de alternar entre múltiplas ferramentas durante o processo de investigação.
Implementação Facilitada com OpenTelemetry
Para facilitar a adoção, a AWS oferece um fluxo de início rápido no console. Administradores conseguem estruturar uma solução completa baseada em OpenTelemetry usando o workflow “Get Started” do OpenSearch, sem complexidade adicional. O serviço inclui pipelines de ingestão do OpenSearch já configurados para dados de OpenTelemetry, acelerando o processo de onboarding para as equipes.
Disponibilidade Geográfica
A interface do Amazon OpenSearch UI está disponível em múltiplas regiões da AWS, abrangendo os principais polos de infraestrutura global: nos Estados Unidos, América do Sul (incluindo São Paulo), Europa, Ásia Pacífico e Canadá. Essa distribuição garante baixa latência e conformidade com regulamentações regionais para organizações brasileiras e latino-americanas.
Próximos Passos
Para explorar essa nova experiência de análise de logs, a documentação completa sobre observabilidade do OpenSearch Service está disponível. Você pode começar a utilizar essas capacidades aprimoradas diretamente na interface do OpenSearch UI e avaliar como a combinação de PPL e linguagem natural pode beneficiar suas operações.
