Nova Camada de Armazenamento Aquecido para Kinesis Video Streams
A AWS ampliou as capacidades de armazenamento do Amazon Kinesis Video Streams com a introdução de uma nova camada de armazenamento econômica, designada como “warm tier”. Essa novidade oferece aos desenvolvedores uma opção mais eficiente em custos para manter vídeos e mídia por períodos prolongados, sem sacrificar a performance.
Entendendo as Duas Camadas de Armazenamento
Anteriormente, o Amazon Kinesis Video Streams operava com uma única camada de armazenamento, agora renomeada como “hot tier”. Essa camada permanece otimizada para acesso em tempo real e armazenamento de curta duração, mantendo todas as suas características de baixa latência.
A nova camada “warm” foi projetada especificamente para cenários que exigem retenção de longa duração de mídia. O diferencial está na manutenção de acesso em sub-segundo — mesmo com custos de armazenamento significativamente reduzidos — tornando-a ideal para aplicações que precisam preservar dados históricos sem manter infraestrutura de acesso instantâneo.
Casos de Uso Práticos
A solução beneficia especialmente dois segmentos:
Segurança residencial: Desenvolvedoras de soluções de monitoramento residencial podem agora oferecer retenção estendida de vídeo, armazenando semanas ou meses de gravações com custos operacionais reduzidos.
Monitoramento empresarial: Organizações com múltiplas câmeras de vigilância conseguem manter históricos longos para auditoria, conformidade regulatória e análise de incidentes, equilibrando retenção com custos.
Maior Flexibilidade na Configuração
Além das duas camadas de armazenamento, a AWS adicionou controle granular sobre o tamanho dos fragmentos de dados. Desenvolvedores podem agora escolher entre:
Fragmentos menores: Para casos de uso que exigem latência ultra-baixa e responsividade imediata.
Fragmentos maiores: Para reduzir custos de ingestão, ideal quando a prioridade é economia de processamento em vez de latência extrema.
Integração com Serviços de IA e Análise
Ambas as camadas (hot e warm) funcionam nativamente com os serviços de visão computacional da AWS. A integração com Amazon Rekognition Video e Amazon SageMaker permite que desenvolvedores construam pipelines contínuos de processamento de vídeo e análise, independente de qual camada de armazenamento estejam utilizando.
Disponibilidade Global
A nova camada warm do Amazon Kinesis Video Streams está disponível em todas as regiões onde o serviço já opera, com a exceção das AWS GovCloud (US) Regions.
A AWS anunciou o suporte a cinco novas versões secundárias do PostgreSQL no Amazon Aurora PostgreSQL-Compatible Edition: versões 17.6, 16.10, 15.14, 14.19 e 13.22. Essas atualizações incorporam as correções de bugs e melhorias de produtos da comunidade PostgreSQL, além de incluir aprimoramentos específicos do Aurora.
Segurança elevada com Mascaramento Dinâmico de Dados
Um dos destaques desta liberação é o Mascaramento Dinâmico de Dados (DDM — Dynamic Data Masking), disponível nas versões 16.10 e 17.6. Esse recurso de segurança em nível de banco de dados oferece proteção para dados sensíveis, como informações de identificação pessoal, ao mascarar valores de coluna dinamicamente durante a execução de consultas. O aspecto mais importante: o mascaramento ocorre em tempo de consulta, com base em políticas de função de acesso, sem alterar os dados armazenados de fato.
Outras melhorias implementadas
Além da segurança, esta versão traz aprimoramentos significativos em desempenho e confiabilidade. A introdução de um compartilhamento de plano de cache melhora a eficiência das operações. Também houve melhoria no objetivo de tempo de recuperação (RTO — Recovery Time Objective), reduzindo o tempo necessário para retomar as operações após uma falha. Para ambientes multi-região, a troca de banco de dados global (Global Database switchovers) agora funciona de forma otimizada.
Como começar com as novas versões
Para utilizar as versões mais recentes, você pode criar um novo banco de dados Aurora PostgreSQL-compatible diretamente pelo Console de Gerenciamento do Amazon RDS em poucos cliques. Caso já possua um banco de dados existente, também é possível fazer uma atualização. A AWS recomenda consultar a documentação do Aurora para compreender melhor o processo de upgrade.
Planejamento de atualizações
Para decidir com qual frequência atualizar e como planejar seu processo de upgrade, consulte a política de versão do Aurora. Esse documento fornece orientações sobre ciclos de suporte e estratégias de migração.
Disponibilidade global
Essas novas versões estão disponíveis em todas as regiões comerciais da AWS, assim como nas regiões do AWS GovCloud (US).
Sobre o Amazon Aurora
O Amazon Aurora é projetado para oferecer desempenho e disponibilidade sem precedentes em escala global, com compatibilidade completa com MySQL e PostgreSQL. A plataforma oferece segurança integrada, backups contínuos, computação serverless, até 15 réplicas de leitura, replicação automatizada entre regiões e integração com outros serviços da AWS. Para dar seus primeiros passos, consulte a página de primeiros passos.
O desafio da infraestrutura de chaves públicas em escala
A Infraestrutura de Chaves Públicas (PKI) é fundamental para garantir a segurança e estabelecer confiança nas comunicações digitais. À medida que as organizações expandem suas operações digitais, precisam emitir e revogar certificados continuamente. A revogação de certificados é especialmente importante quando funcionários se desligam, durante migrações para novas hierarquias de autoridades certificadoras, para atender requisitos de conformidade ou em resposta a incidentes de segurança.
Porém, empresas que enfrentam crescimento significativo encontram limitações ao usar CRLs completas para emitir e revogar mais de 1 milhão de certificados. Simplesmente aumentar o tamanho do arquivo CRL não é uma solução viável, pois muitas aplicações não conseguem processar arquivos CRL grandes — algumas exigem um máximo de 1 MB. Além disso, soluções alternativas como OCSP podem ser rejeitadas por grandes repositórios de confiança e fornecedores de navegadores devido a preocupações com privacidade e requisitos de conformidade. Essas restrições impactam significativamente a capacidade das organizações de escalar sua infraestrutura de PKI de forma eficiente, mantendo segurança e conformidade.
A solução: CRLs particionadas
A AWS Private CA agora oferece CRLs particionadas como resposta a esses desafios. Essa funcionalidade permite a emissão e revogação de até 100 milhões de certificados por CA, distribuindo as informações de revogação em múltiplas partições de CRL menores e gerenciáveis, cada uma mantendo um tamanho máximo de 1 MB para melhor compatibilidade com aplicações.
No momento da emissão, os certificados são automaticamente vinculados a partições CRL específicas através de uma extensão crítica de Ponto de Distribuição do Emissor (IDP), que contém uma URI única identificando a partição. A validação funciona comparando a URI de CRL na extensão de Ponto de Distribuição de CRL (CDP) do certificado contra a extensão IDP da CRL, proporcionando validação precisa.
Capacidades principais da nova funcionalidade
As CRLs particionadas oferecem diversos benefícios operacionais:
Escalabilidade automática do limite de emissão de certificados: de 1 milhão para 100 milhões de certificados por CA
Suporte tanto para novas quanto para autoridades certificadoras existentes
Opções de configuração flexível para nomes e caminhos de CRL
Compatibilidade reversa, preservando a funcionalidade completa de CRL existente enquanto oferece CRL particionada como recurso opcional
Conformidade com padrões da indústria, como o RFC5280, mantendo eficiência operacional e segurança
Configurando CRLs particionadas na AWS Private CA
A configuração de CRLs particionadas em autoridades certificadoras existentes segue um processo estruturado através do console da AWS:
Passos de configuração
Para ativar CRLs particionadas, acesse sua autoridade certificadora privada no console da AWS Private CA. Primeiro, selecione a CA desejada e navegue até a aba de configuração de revogação. Se a distribuição de CRL estiver desabilitada, você precisará ativá-la nos próximos passos.
Ao editar as configurações, marque a opção para ativar distribuição de CRL e selecione um bucket do Amazon S3 existente para armazenar os arquivos de CRL. É importante verificar que o recurso de Bloqueio de Acesso Público está desabilitado para sua conta e para o bucket. Se necessário, você pode consultar a documentação sobre criar uma CA privada na AWS Private CA para obter instruções detalhadas sobre políticas de acesso. Para configurações de segurança mais específicas, consulte o guia sobre políticas de acesso para CRLs no Amazon S3 e aprenda como adicionar uma política de bucket usando o console do Amazon S3.
Na seção de configurações de CRL, marque a caixa para ativar o particionamento. Isso habilitará o uso de CRL particionada. Se você não ativar o particionamento, uma CRL completa será criada e sua CA ficará sujeita ao limite de 1 milhão de certificados emitidos ou revogados. Para informações sobre limites de capacidade, consulte as cotas da AWS Private CA.
Após salvar as alterações, a distribuição de CRL aparecerá como habilitada com CRLs particionadas, e o limite de 1 milhão será automaticamente atualizado para 100 milhões por CA.
Benefícios para segurança, operações e conformidade
As CRLs particionadas da AWS Private CA oferecem benefícios substanciais em múltiplas dimensões organizacionais.
Perspectiva de segurança
A funcionalidade mantém a validação de certificados enquanto suporta capacidades abrangentes de revogação para até 100 milhões de certificados por CA. Isso permite que as organizações respondam efetivamente a incidentes de segurança ou comprometimento de chaves.
Perspectiva operacional
Operacionalmente, o recurso reduz a necessidade de rotação de autoridades certificadoras, diminuindo a sobrecarga administrativa e simplificando o gerenciamento de PKI. Manter os tamanhos de partição de CRL em 1 MB oferece compatibilidade ampla com aplicações, enquanto suporta gerenciamento automático de partições.
Perspectiva de conformidade
Para conformidade regulatória, a solução permite que as organizações atendam a múltiplos requisitos da indústria:
Alinhamento com requisitos de repositórios de confiança de navegadores para suporte tanto a CRL quanto a OCSP
Flexibilidade para padrões emergentes, como Matter
Custo e disponibilidade
Um ponto importante é que você pode maximizar o valor de suas autoridades certificadoras de propósito geral ou vida curta ativando CRL particionada sem custos adicionais, além da AWS Private CA e do Amazon Simple Storage Service (Amazon S3). Todos os certificados continuam sendo revogáveis, proporcionando uma solução completa e econômica para gestão de PKI em escala.
Próximos passos
Organizações interessadas em começar podem criar sua autoridade certificadora através do console de gerenciamento da AWS Private CA. A nova funcionalidade está disponível para configuração imediata em autoridades certificadoras existentes ou novas.
A AWS anunciou um novo provedor para o Secrets Store CSI Driver destinado ao Amazon EKS (Elastic Kubernetes Service), que funciona como um add-on gerenciado para a plataforma. Esse novo componente permite que as equipes de desenvolvimento recuperem secrets do AWS Secrets Manager e parâmetros do AWS Systems Manager Parameter Store, montando-os como arquivos nos pods do Kubernetes. A solução é clara em sua proposta: oferecer uma forma segura, confiável e gerenciada de acessar credenciais dentro de ambientes containerizados.
O novo add-on simplifica significativamente o processo de instalação e configuração, funciona tanto em instâncias de Amazon Elastic Compute Cloud (EC2) quanto em nós híbridos, e é mantido com as correções de segurança e atualizações mais recentes. Para equipes brasileiras que trabalham com Kubernetes em ambientes AWS, isso representa uma redução considerável no tempo necessário para implementar práticas seguras de gestão de credenciais.
Por que isso importa para a segurança
Historicamente, um dos maiores desafios em ambientes Kubernetes é evitar o uso de credenciais hardcoded no código-fonte das aplicações. O Secrets Manager já resolve essa questão no contexto geral da AWS, mas integrá-lo nativamente com Kubernetes exigia passos complexos de instalação e manutenção.
O novo provedor funciona como um DaemonSet do Kubernetes de código aberto, trabalhando em conjunto com o Secrets Store CSI Driver mantido pela comunidade Kubernetes. Essa arquitetura permite que o driver de armazenamento de secrets funcione de forma nativa no cluster, sem necessidade de integração customizada.
Benefícios do add-on gerenciado
Os add-ons do EKS da AWS proporcionam instalação e gerenciamento de um conjunto curado de componentes para clusters EKS. Em vez de depender de métodos legados como Helm ou kubectl, o novo add-on reduz significativamente o tempo de setup e aumenta a estabilidade geral dos clusters. Além disso, o gerenciamento centralizado pela AWS garante que patches de segurança e correções de bugs sejam aplicados de forma automática e consistente.
Considerações de segurança
Como em qualquer solução que envolve gestão de credenciais, a segurança é uma preocupação central. A AWS recomenda armazenar secrets em cache na memória quando possível, reduzindo a frequência de acesso ao Secrets Manager. Para equipes que preferem uma experiência totalmente nativa do Kubernetes, o AWS Secrets Manager Agent oferece uma alternativa complementar.
Do ponto de vista de controle de acesso, qualquer entidade IAM (Identity and Access Management) que precise acessar os secrets deve ter permissões explícitas no Secrets Manager. Se usar Parameter Store, também precisa de permissões específicas para ler parâmetros. As políticas de recurso funcionam como mecanismo adicional de controle de acesso, e é especialmente importante quando se acessa secrets de contas AWS diferentes.
O add-on inclui suporte a endpoints FIPS, alinhando-se com exigências de conformidade em ambientes altamente regulados. A AWS fornece uma política IAM gerenciada chamada AWSSecretsManagerClientReadOnlyAccess, que é a recomendação padrão para uso com esse add-on. Para implementar o princípio do menor privilégio, é possível criar políticas customizadas direcionadas apenas aos secrets específicos que cada aplicação precisa acessar.
Guia prático de implementação
Para equipes que desejam começar, a AWS disponibiliza um fluxo de trabalho completo desde a criação do cluster até a recuperação efetiva de um secret. Abaixo, apresentamos um resumo dos passos principais.
Pré-requisitos
Antes de iniciar, certifique-se de ter:
Credenciais AWS configuradas no seu ambiente para permitir chamadas à API
Um arquivo de deployment Kubernetes disponível no repositório do provedor
Criando o cluster EKS
Comece criando uma variável de shell com o nome do seu cluster:
CLUSTER_NAME="my-test-cluster"
Depois, crie o cluster:
eksctl create cluster $CLUSTER_NAME
O eksctl usará automaticamente uma versão recente do Kubernetes e criará todos os recursos necessários para o funcionamento do cluster. Esse comando geralmente leva cerca de 15 minutos.
Criando um secret de teste
Crie um secret chamado addon_secret no Secrets Manager:
A SecretProviderClass é um arquivo YAML que define quais secrets e parâmetros devem ser montados como arquivos no seu cluster. Crie um arquivo chamado spc.yaml com o seguinte conteúdo:
Embora o add-on gerenciado seja a forma recomendada, a AWS também oferece opções alternativas de instalação usando AWS CloudFormation, AWS Command Line Interface (AWS CLI), console de gerenciamento ou a própria API do EKS.
Conclusão
O novo add-on do Secrets Store CSI Driver para EKS representa um avanço significativo na forma como as equipes podem gerenciar credenciais em ambientes Kubernetes hospedados na AWS. Ao oferecer instalação simplificada, gerenciamento centralizado, atualizações de segurança automáticas e integração estreita com o EKS, a solução reduz tanto a complexidade operacional quanto o risco de segurança associado ao armazenamento inadequado de secrets.
Para organizações brasileiras que trabalham com Kubernetes em escala, esse add-on se posiciona como uma alternativa muito mais prática do que métodos legados de instalação, mantendo a flexibilidade e a conformidade com padrões de segurança internacionais. A documentação técnica completa está disponível para equipes que desejam explorar cenários mais avançados e configurações específicas.
A AWS anunciou uma importante expansão do Block Public Access (Bloqueio de Acesso Público) para o Amazon S3. O serviço agora permite gerenciamento centralizado através do AWS Organizations, possibilitando que organizações padronizem e enforcem configurações de acesso público em todos os accounts de sua estrutura por meio de uma única configuração de política.
Como funciona o Block Public Access em nível organizacional
Propagação automática de políticas
O Block Public Access em nível organizacional opera através de uma configuração única que controla todas as definições de acesso público em todos os accounts dentro da organização. Quando você anexa a política no root ou em uma Unidade Organizacional (OU, do inglês Organizational Unit) da sua organização, ela se propaga automaticamente para todos os sub-accounts dentro desse escopo. Contas-membro novas herdam a política de forma automática, eliminando a necessidade de configuração manual individual.
Flexibilidade de aplicação
Além da abordagem centralizada, você também tem a opção de aplicar a política a accounts específicos quando precisa de um controle mais granular. Essa flexibilidade permite que organizações balanceiem a uniformidade de segurança com necessidades específicas de diferentes times ou departamentos.
Como começar
Configuração através do console
Para iniciar, acesse o console do AWS Organizations e utilize o checkbox “Bloquear todo acesso público” ou use o editor JSON para configurações mais avançadas. A interface permite que você customize exatamente quais tipos de acesso público devem ser bloqueados em toda a sua organização.
Monitoramento e auditoria
A AWS CloudTrail pode ser utilizada para auditar e acompanhar a anexação de políticas, bem como monitorar o enforcement da política em todas as contas-membro. Isso oferece visibilidade completa sobre como as configurações de segurança estão sendo aplicadas e mantidas em toda a organização.
Disponibilidade e acesso
Esse recurso está disponível no console do AWS Organizations, bem como através da AWS CLI (Interface de Linha de Comando, do inglês Command Line Interface) e SDKs (Kits de Desenvolvimento de Software, do inglês Software Development Kits), em todas as regiões AWS onde AWS Organizations e Amazon S3 são suportados. Importante destacar que não há custos adicionais para usar esse recurso.
Controle granular sobre o agendamento de cargas de trabalho
A AWS anunciou um novo recurso no Amazon SageMaker HyperPod que oferece suporte a labels (etiquetas) e taints (repugnâncias) personalizados do Kubernetes. Essa funcionalidade permite aos clientes exercer controle preciso sobre o posicionamento de pods e garantir integração tranquila com infraestruturas Kubernetes já existentes.
Para equipes que implantam cargas de trabalho de inteligência artificial em clusters HyperPod orquestrados com EKS (Elastic Kubernetes Service), esse é um recurso particularmente valioso. A capacidade de controlar exatamente onde cada pod é executado ajuda a evitar que recursos caros, como GPUs, sejam consumidos por pods de sistema ou cargas de trabalho não relacionadas a inteligência artificial, enquanto mantém compatibilidade com plugins de dispositivo personalizados, como o EFA (Elastic Fabric Adapter) e operadores NVIDIA GPU.
Eliminando a sobrecarga operacional
O desafio anterior
Antes deste anúncio, clientes precisavam aplicar manualmente labels e taints usando kubectl, tendo que reaplicá-los após cada substituição de nó, operação de escalonamento ou patch do sistema. Esse processo manual gerava sobrecarga operacional significativa e aumentava o risco de inconsistências.
A solução implementada
O novo recurso permite configurar labels e taints no nível do grupo de instâncias através das APIs CreateCluster e UpdateCluster, oferecendo uma abordagem gerenciada para definir e manter políticas de agendamento ao longo de todo o ciclo de vida dos nós.
Capacidades técnicas
Utilizando o novo parâmetro KubernetesConfig, é possível especificar até 50 labels e 50 taints por grupo de instâncias. As labels habilitam organização de recursos e direcionamento de pods através de seletores de nó, enquanto taints repelem pods que não possuem tolerâncias correspondentes, protegendo nós especializados.
Casos de uso práticos
Um exemplo concreto é aplicar taints do tipo NoSchedule em grupos de instâncias com GPUs, garantindo que apenas trabalhos de treinamento de inteligência artificial com tolerâncias explícitas consumam esses recursos de alto custo. Outra aplicação é adicionar labels personalizados que permitam aos pods de plugins de dispositivo agendar corretamente no ambiente.
Operação simplificada
O HyperPod aplica automaticamente essas configurações durante a criação de nós e as mantém durante substituição, escalonamento e operações de patch. Isso elimina a necessidade de intervenção manual e reduz significativamente a sobrecarga operacional que as equipes enfrentavam anteriormente.
O recurso está disponível em todas as regiões da AWS onde o Amazon SageMaker HyperPod é oferecido. Para aprofundar seus conhecimentos sobre labels e taints personalizados, consulte a documentação técnica completa.
A AWS apresentou um conjunto de diretrizes destinadas às varreduras de rede realizadas em ambientes de clientes. O objetivo? Permitir que ferramentas conformes coletem dados mais precisos, reduzam relatos de abuso e contribuam para elevar o nível de segurança na internet como um todo.
Varreduras de rede são práticas comuns em infraestruturas modernas de TI. No entanto, essa prática enfrenta um dilema fundamental: ela pode servir tanto a propósitos legítimos quanto a atividades maliciosas. Do lado legítimo, equipes de segurança, administradores de sistemas e pesquisadores autorizados utilizam varreduras para manter inventários precisos de ativos, validar configurações de segurança e identificar vulnerabilidades ou versões desatualizadas de software que demandam atenção imediata.
Já do lado malicioso, atores de ameaça realizam varreduras para enumerar sistemas, descobrir fraquezas e coletar inteligência para futuros ataques. Distinguir entre essas duas situações é um desafio constante para operações de segurança.
Por Que Essas Diretrizes Importam
O Crescimento Exponencial de Vulnerabilidades
O cenário atual apresenta pressões significativas. De acordo com o banco de dados de vulnerabilidades da NIST (Banco Nacional de Dados de Vulnerabilidades), o número de vulnerabilidades conhecidas cresce a uma taxa de 21% ao ano nos últimos dez anos. Quando uma vulnerabilidade é descoberta por meio de varredura, a intenção do scanner torna-se crítica. Se um ator de ameaça explorar essa vulnerabilidade antes que seja corrigida, ele poderá obter acesso não autorizado aos sistemas organizacionais.
As organizações precisam gerenciar efetivamente suas vulnerabilidades de software para se protegerem contra ransomware, roubo de dados, problemas operacionais e penalidades regulatórias. Porém, isso só é possível quando os dados de segurança coletados por varreduras permanecem protegidos.
Os Múltiplos Interessados nos Dados de Segurança
Diferentes grupos possuem interesses legítimos mas distintos em relação aos dados de segurança coletados:
Organizações querem entender seus ativos e corrigir vulnerabilidades rapidamente para proteger sua infraestrutura
Auditores de compliance buscam evidências de controles robustos na gestão de infraestrutura
Provedores de seguros cibernéticos precisam avaliar o risco da postura de segurança organizacional
Investidores em avaliação de diligência querem compreender o perfil de risco cibernético de uma organização
Pesquisadores de segurança desejam identificar riscos e notificar organizações para que ajam
Atores de ameaça buscam explorar vulnerabilidades não corrigidas e fraquezas para obter acesso não autorizado
Esse ecossistema complexo de interesses concorrentes exige que dados sensíveis de segurança sejam mantidos com níveis diferentes de acesso. Se esses dados caírem nas mãos erradas, as consequências podem ser severas: comprometimento de sistemas, ransomware, negação de serviço e custos significativos para os proprietários dos sistemas.
Considerando o crescimento exponencial de data centers e cargas de trabalho de software conectadas que fornecem serviços críticos em setores como energia, manufatura, saúde, governo, educação, finanças e transportes, o impacto de dados de segurança em mãos erradas pode ter consequências significativas no mundo real.
A Falta de um Padrão Unificado
Atualmente, não existe um padrão único para identificação de scanners de rede na internet. Proprietários de sistemas geralmente não sabem quem está realizando varreduras em suas infraestruturas. Cada proprietário é independentemente responsável por gerenciar a identificação dessas diferentes partes. Scanners podem usar métodos variados para se identificar — como busca reversa de DNS, agentes de usuário personalizados ou faixas de rede dedicadas. Já atores maliciosos podem tentar evitar identificação completamente.
Esse grau de variação na identidade torna extremamente difícil para os proprietários de sistemas compreender a motivação por trás das varreduras que recebem. É nesse contexto que a AWS apresenta suas diretrizes comportamentais para varreduras de rede, buscando proteger redes e clientes.
Os Benefícios das Diretrizes
Quando scanners em conformidade com essas diretrizes realizam varreduras, eles coletam dados mais confiáveis da infraestrutura AWS. Organizações que executam workloads na AWS recebem um maior grau de confiança em sua gestão de riscos. Quando a varredura segue essas diretrizes, proprietários de sistemas conseguem fortalecer suas defesas e melhorar visibilidade em todo seu ecossistema digital.
Ferramentas como o Amazon Inspector podem detectar vulnerabilidades de software e priorizar esforços de correção enquanto aderem a essas diretrizes. Parceiros do AWS Marketplace utilizam essas orientações para coletar sinais de segurança em toda a internet e ajudar organizações a compreender e gerenciar riscos cibernéticos. Como afirmou um especialista do Bitsight: “Quando organizações têm visibilidade clara orientada por dados sobre sua própria postura de segurança e a de terceiros, conseguem tomar decisões mais rápidas e inteligentes para reduzir riscos cibernéticos em todo o ecossistema.”
Reportando Atividades Abusivas
A segurança funciona melhor quando há colaboração. Clientes da AWS podem reportar varreduras abusivas através do Centro de Confiança e Segurança, selecionando o tipo de relatório como “Atividade de Rede > Varredura de Portas e Tentativas de Intrusão”. Cada relatório contribui para melhorar a proteção coletiva contra o uso malicioso de dados de segurança.
As Diretrizes de Conformidade
Para permitir que scanners legítimos se diferenciem claramente de atores de ameaça, a AWS oferece as seguintes orientações para varredura de workloads. Essas diretrizes complementam as políticas existentes sobre testes de penetração e relatório de vulnerabilidades. A AWS se reserva o direito de limitar ou bloquear tráfego que pareça não estar em conformidade com essas diretrizes.
1. Observacional
Um scanner em conformidade não realiza ações que tentem criar, modificar ou deletar recursos ou dados nos endpoints descobertos. Respeita a integridade dos sistemas-alvo. As varreduras não causam degradação na funcionalidade do sistema e não introduzem mudanças nas configurações.
Exemplos de varredura não-modificadora incluem:
Iniciar e completar um handshake TCP
Recuperar o banner de um serviço SSH
2. Identificável
Um scanner em conformidade oferece transparência ao publicar as fontes de sua atividade de varredura. Implementa um processo verificável para confirmar a autenticidade de atividades de varredura.
Exemplos de varredura identificável incluem:
Suportar buscas reversa de DNS para uma das zonas de DNS públicas de sua organização nos IPs de varredura
Publicar intervalos de IP de varredura, organizados por tipos de requisições (como verificação de existência de serviços, verificações de vulnerabilidades)
Se realizar varreduras HTTP, incluir conteúdo significativo em strings de agente de usuário (como nomes de suas zonas de DNS públicas, URL para opt-out)
3. Cooperativo
Um scanner em conformidade limita taxas de varredura para minimizar impacto nos sistemas-alvo. Oferece um mecanismo de opt-out para proprietários de recursos verificados que desejam solicitar cessação da atividade de varredura. Honra solicitações de opt-out dentro de um período de resposta razoável.
Exemplos de varredura cooperativa incluem:
Limitar varredura a uma transação de serviço por segundo por serviço de destino
Respeitar configurações de site conforme expressos em robots.txt, security.txt e outros padrões da indústria para expressar intenção do proprietário do site
4. Confidencial
Um scanner em conformidade mantém práticas seguras de infraestrutura e manipulação de dados, refletidas em certificações de padrão industrial como SOC2. Garante nenhum acesso não autenticado ou não autorizado aos dados coletados. Implementa processos de identificação e verificação de usuários.
O Caminho Adiante
À medida que mais scanners de rede adotam essas diretrizes, proprietários de sistemas se beneficiarão de riscos reduzidos em relação a confidencialidade, integridade e disponibilidade. Scanners legítimos enviarão um sinal claro de sua intenção e melhorarão a qualidade de visibilidade que conseguem obter. Com o estado em constante mudança do networking, espera-se que essas diretrizes evoluam acompanhando controles técnicos ao longo do tempo.
Transição do Amazon Lookout for Vision para SageMaker
Em outubro de 2024, a AWS anunciou a descontinuação do Amazon Lookout for Vision, com previsão de encerramento em 31 de outubro de 2025. Como parte de sua estratégia de transição, a empresa recomenda que clientes interessados em soluções de inteligência artificial e aprendizado de máquina para visão computacional utilizem as ferramentas do Amazon SageMaker AI.
A boa notícia é que a AWS disponibilizou no AWS Marketplace os modelos subjacentes que alimentavam o serviço descontinuado. Esses modelos podem ser ajustados usando o Amazon SageMaker para casos de uso específicos, oferecendo flexibilidade total de integração com infraestruturas existentes de hardware e software. Quando executados na nuvem, os custos envolvem apenas a infraestrutura necessária para treinamento ou inferência.
Fluxo end-to-end: da aquisição de imagens até a inferência em dispositivos edge — Fonte: Aws
Vantagens da Migração para SageMaker
A transição proporciona ganhos significativos em flexibilidade e controle. Com o SageMaker, é possível treinar modelos em instâncias maiores para reduzir o tempo de processamento. Além disso, usuários podem ajustar hiperparâmetros que antes não eram disponíveis no console do Lookout for Vision. Por exemplo, é possível desabilitar a cabeça do classificador binário em modelos de segmentação semântica, tornando a solução mais tolerante a variações de iluminação e fundo.
Outro destaque é o controle sobre o tempo máximo de treinamento, que no Lookout for Vision era limitado a 24 horas. Agora, organizações podem customizar esse parâmetro conforme suas necessidades.
Recursos e Modelos Disponíveis
A AWS coloca à disposição dois tipos principais de modelos:
Classificação binária: para categorizar imagens como normais ou anômalas
Segmentação semântica: para identificar regiões específicas com defeitos em uma imagem
Ambos podem ser treinados nas contas próprias da AWS para implantação na nuvem ou em dispositivos edge. O repositório GitHub do Amazon Lookout for Vision foi atualizado com um Jupyter Notebook que facilita o treinamento de datasets com esses dois tipos de modelos e seu empacotamento.
Para rotular dados além do conjunto amostral, é possível usar o Amazon SageMaker Ground Truth para crowdsourcing ou permitir que equipes privadas façam a anotação. Alternativas incluem soluções de parceiros como Edge Impulse, Roboflow e SuperbAI.
Pré-Requisitos
Antes de começar, certifique-se de ter em lugar:
Amazon SageMaker Studio ou Amazon SageMaker Unified Studio para desenvolvimento integrado
Função Controle de Identidade e Acesso (IAM) com permissões apropriadas, incluindo acesso ao Amazon S3, operações no SageMaker e subscrição ao AWS Marketplace
Conhecimento básico de criar instâncias Jupyter no SageMaker e executar notebooks
Configuração do Processo de Etiquetagem
O primeiro passo da jornada envolve preparar os dados para treinamento. A AWS oferece o Ground Truth, que possibilita criar equipes privadas de anotadores e organizar o trabalho de rotulação.
No console do SageMaker AI, navegue até Ground Truth e selecione a opção de criar uma equipe privada. Após definir nome e configurações iniciais, você pode convidar membros da sua equipe por e-mail, enviando automaticamente convites com credenciais de acesso.
Etiquetagem com SageMaker Ground Truth — Fonte: Aws
Preparação e Etiquetagem de Datasets
Uma vez que a equipe está pronta, o próximo passo é preparar o dataset. Faça upload das imagens para um bucket Amazon S3 e organize-as em uma estrutura única de diretório, combinando imagens normais e anômalas.
Para automatizar esse processo, você pode usar um script no AWS CloudShell:
#!/bin/bash
# Clone o repositório
git clone https://github.com/aws-samples/amazon-lookout-for-vision.git
cd amazon-lookout-for-vision/aliens-dataset
# Remove diretório anterior se existir
rm -rf all
# Cria novo diretório
mkdir -p all
# Copia imagens normais
cp normal/*.png all/
# Copia imagens anômalas com sufixo
cd "$(dirname "$0")/amazon-lookout-for-vision/aliens-dataset"
for file in anomaly/*.png; do
if [ -f "$file" ]; then
filename=$(basename "$file")
cp "$file" "all/${filename}.anomaly.png"
fi
done
# Verifica contagem
echo "Imagens normais: $(find normal -name "*.png" | wc -l)"
echo "Imagens anômalas: $(find anomaly -name "*.png" | wc -l)"
echo "Total no diretório all: $(find all -type f | wc -l)"
# Upload para S3
aws s3 cp all/ s3://<BUCKET_NAME>/aliens-dataset-all/ --recursive
# Limpeza
cd ../..
rm -rf amazon-lookout-for-vision
Alternativamente, com a CLI da AWS configurada, você pode usar comandos manuais. Depois de fazer upload, acesse o console do SageMaker, navigate para Ground Truth e crie um novo job de etiquetagem. Configure a localização dos dados no S3, escolha “Configuração Automática de Dados” e selecione “Imagem” como tipo de dados.
Para o tipo de tarefa, escolha “Classificação de Imagem (Rótulo Único)” para classificação binária ou “Segmentação Semântica” conforme sua necessidade. Crie dois rótulos: “normal” e “anomalia”. Uma vez que o job é iniciado, trabalhadores acesso o portal de etiquetagem e rotulam cada imagem conforme as instruções fornecidas.
Treinamento do Modelo
Após concluir a etiquetagem, use os dados rotulados para treinar o modelo de detecção de defeitos. Primeiro, subscrevam-se ao modelo no AWS Marketplace. Copie o ARN (Identificador de Recurso da Amazon) do modelo para referência posterior.
Em seguida, crie uma instância Jupyter do SageMaker. Para essa tarefa, uma instância do tipo m5.2xl é adequada, com volume de 128 GB (o padrão de 5 GB é insuficiente). GPU não é obrigatória na instância do notebook, pois o SageMaker ativa automaticamente instâncias habilitadas com GPU durante o treinamento.
Clone o repositório GitHub dentro da instância Jupyter e localize a pasta relevante. No notebook, defina o ARN do modelo que você subscreveu:
# TODO: altere para usar o algoritmo SageMaker subscrito
algorithm_name = "<Especificar nome do algoritmo após subscrição>"
# Inicializa a sessão SageMaker e obtém a função de execução
sagemaker_session = sagemaker.Session()
region = sagemaker_session.boto_region_name
role = get_execution_role()
# Nome do projeto para identificar no S3
project = "ComputerVisionDefectDetection"
O Futuro da IA em Tempo Real: Comunicação Bidirecional Contínua
Em 2025, a inteligência artificial generativa transcendeu a simples geração de texto. As aplicações modernas demandam muito mais do que respostas transacionais isoladas. Elas exigem capacidades multimodais abrangentes — desde transcrição e tradução de áudio até agentes de voz sofisticados — e, sobretudo, necessitam de comunicação contínua e fluida em tempo real.
O diferencial está em um requisito essencial: os dados precisam fluir simultaneamente em ambas as direções, através de uma única conexão persistente. Imagine um cenário de conversão de fala para texto onde o áudio é transmitido de forma contínua enquanto, ao mesmo tempo, o modelo processa e retorna a transcrição em tempo real, palavra por palavra. Esses casos de uso demandam exatamente essa capacidade bidirecional.
A AWS anunciou a transmissão bidirecional para Amazon SageMaker AI Inference, transformando fundamentalmente o paradigma de inferência — de uma troca transacional isolada para uma conversa contínua e natural. A experiência de fala flui naturalmente quando não há interrupções. Com transmissão bidirecional, a conversão de fala para texto torna-se imediata: o modelo escuta e transcreve simultaneamente, fazendo as palavras aparecerem no exato momento em que são pronunciadas.
Considere o caso prático de um centro de atendimento ao cliente. Conforme o cliente descreve seu problema, a transcrição ao vivo aparece instantaneamente na tela do atendente, fornecendo contexto imediato e permitindo que ele responda sem esperar o cliente terminar de falar. Esse tipo de troca contínua torna as experiências de voz mais fluidas, responsivas e genuinamente humanas.
Como Funciona a Transmissão Bidirecional
O Paradigma Tradicional versus Bidirecional
Na abordagem tradicional de requisições de inferência, existe um padrão bem definido: o cliente envia uma pergunta completa e aguarda, enquanto o modelo processa e retorna uma resposta completa antes que o cliente possa enviar a próxima pergunta. É um ciclo de espera e resposta.
Com transmissão bidirecional, esse fluxo é radicalmente diferente. A pergunta começa a fluir do cliente enquanto o modelo simultaneamente inicia o processamento e começa a retornar a resposta imediatamente. O cliente pode continuar refinando sua entrada enquanto o modelo adapta sua resposta em tempo real. Os resultados aparecem assim que o modelo os gera — palavra por palavra para texto, frame por frame para vídeo, amostra por amostra para áudio.
Esse padrão também oferece benefícios infraestruturais significativos: manter uma única conexão persistente elimina a necessidade de centenas de conexões de curta duração. Isso reduz consideravelmente a sobrecarga de gerenciamento de rede, handshakes TLS e administração de conexões. Além disso, os modelos conseguem manter contexto ao longo de um fluxo contínuo, possibilitando interações multi-turnos sem a necessidade de reenviar o histórico de conversa a cada requisição.
Arquitetura de Três Camadas do SageMaker AI Inference
A implementação técnica da transmissão bidirecional no SageMaker AI Inference combina dois protocolos complementares: HTTP/2 e WebSocket, criando um canal robusto de comunicação bidirecional em tempo real entre cliente e modelo. O fluxo ocorre em três camadas:
Cliente para Roteador SageMaker AI: Sua aplicação se conecta ao endpoint de tempo de execução do Amazon SageMaker AI usando HTTP/2, estabelecendo uma conexão eficiente e multiplexada que suporta transmissão bidirecional.
Roteador para Contêiner do Modelo: O roteador encaminha a requisição para um Sidecar — um proxy leve executando ao lado de seu contêiner de modelo — que estabelece uma conexão WebSocket com o contêiner em ws://localhost:8080/invocations-bidirectional-stream. Uma vez estabelecida, os dados fluem livremente em ambas as direções.
Fluxo de Requisição e Resposta: Sua aplicação envia entrada como uma série de blocos de dados via HTTP/2. A infraestrutura do SageMaker AI converte esses blocos em frames de dados WebSocket — texto (para dados UTF-8) ou binário — e os encaminha ao contêiner. O modelo recebe esses frames em tempo real e começa a processar imediatamente, antes mesmo da chegada da entrada completa. Na direção oposta, o modelo gera saída e a envia como frames WebSocket. O SageMaker AI encapsula cada frame em um payload de resposta e o transmite diretamente à sua aplicação via HTTP/2.
A conexão WebSocket entre o Sidecar e o contêiner permanece aberta pela duração da sessão, com monitoramento de saúde integrado. Para manter a integridade da conexão, o SageMaker AI envia frames de ping a cada 60 segundos para verificar se a conexão está ativa. Seu contêiner responde com pong frames para confirmar que está saudável. Se 5 pings consecutivos não receberem resposta, a conexão é fechada de forma controlada.
Construindo seu Próprio Contêiner com Transmissão Bidirecional
Pré-requisitos e Preparação
Se você deseja utilizar modelos de código aberto ou seus próprios modelos, é possível customizar seu contêiner para suportar transmissão bidirecional. Seu contêiner deve implementar o protocolo WebSocket para lidar com frames de dados recebidos e enviar frames de resposta de volta ao SageMaker AI.
Permissões de IAM que permitam explicitamente a ação sagemaker:InvokeEndpoint* para invocação de endpoints
Docker instalado localmente
Python 3.12 ou superior
Instalar aws-sdk-python para a API InvokeEndpointWithBidirectionalStream do tempo de execução do SageMaker AI
Construindo e Implantando o Contêiner
O processo começa clonando o repositório de demonstração e configurando seu ambiente conforme definido no README.md. Os passos a seguir criarão uma imagem Docker simples de demonstração e a enviarão para seu repositório de ECR na AWS.
# As variáveis de ambiente devem ser definidas para autenticação AWS
# export AWS_ACCESS_KEY_ID="sua-chave-de-acesso"
# export AWS_SECRET_ACCESS_KEY="sua-chave-secreta"
# export AWS_DEFAULT_REGION="us-west-2"
container_name="sagemaker-bidirectional-streaming"
container_tag="latest"
cd container
account=$(aws sts get-caller-identity --query Account --output text)
region=$(aws configure get region)
region=${region:-us-west-2}
container_image_uri="${account}.dkr.ecr.${region}.amazonaws.com/${container_name}:${container_tag}"
# Se o repositório não existe no ECR, crie-o
aws ecr describe-repositories --repository-names "${container_name}" --region "${region}" > /dev/null 2>&1
if [ $? -ne 0 ]
then
aws ecr create-repository --repository-name "${container_name}" --region "${region}" > /dev/null
fi
# Obtenha o comando de login do ECR e execute-o
aws ecr get-login-password --region ${region} | docker login --username AWS --password-stdin ${account}.dkr.ecr.${region}.amazonaws.com/${container_name}
# Construa a imagem Docker localmente e envie-a para o ECR
docker build --platform linux/amd64 --provenance=false -t ${container_name} .
docker tag ${container_name} ${container_image_uri}
docker push ${container_image_uri}
Este processo cria um contêiner com um rótulo Docker indicando ao SageMaker AI que o suporte a transmissão bidirecional está habilitado: com.amazonaws.sagemaker.capabilities.bidirectional-streaming=true.
Após criar a imagem, você pode implantar o contêiner em um endpoint do SageMaker AI através de um script Python que cria o modelo, a configuração do endpoint e finalmente o endpoint propriamente dito.
Invocando o Endpoint com a Nova API
Uma vez que o endpoint do SageMaker AI esteja em estado InService, você pode proceder à invocação do endpoint para testar a funcionalidade de transmissão bidirecional. O cliente Python conecta-se ao endpoint do SageMaker AI e envia dados em chunks, recebendo respostas simultâneas.
#!/usr/bin/env python3
"""
Script Python para Transmissão Bidirecional no SageMaker AI.
Conecta-se a um endpoint do SageMaker AI para comunicação bidirecional.
"""
import argparse
import asyncio
import sys
from aws_sdk_sagemaker_runtime_http2.client import SageMakerRuntimeHTTP2Client
from aws_sdk_sagemaker_runtime_http2.config import Config, HTTPAuthSchemeResolver
from aws_sdk_sagemaker_runtime_http2.models import InvokeEndpointWithBidirectionalStreamInput, RequestStreamEventPayloadPart, RequestPayloadPart
from smithy_aws_core.identity import EnvironmentCredentialsResolver
from smithy_aws_core.auth.sigv4 import SigV4AuthScheme
import logging
def parse_arguments():
"""Analisa argumentos da linha de comando."""
parser = argparse.ArgumentParser(
description="Conecta-se a um endpoint do SageMaker AI para transmissão bidirecional"
)
parser.add_argument(
"ENDPOINT_NAME",
help="Nome do endpoint do SageMaker AI para conectar"
)
return parser.parse_args()
AWS_REGION = "us-west-2"
BIDI_ENDPOINT = f"https://runtime.sagemaker.{AWS_REGION}.amazonaws.com:8443"
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)
class SimpleClient:
def __init__(self, endpoint_name, region=AWS_REGION):
self.endpoint_name = endpoint_name
self.region = region
self.client = None
self.stream = None
self.response = None
self.is_active = False
def _initialize_client(self):
config = Config(
endpoint_uri=BIDI_ENDPOINT,
region=self.region,
aws_credentials_identity_resolver=EnvironmentCredentialsResolver(),
auth_scheme_resolver=HTTPAuthSchemeResolver(),
auth_schemes={"aws.auth#sigv4": SigV4AuthScheme(service="sagemaker")}
)
self.client = SageMakerRuntimeHTTP2Client(config=config)
async def start_session(self):
if not self.client:
self._initialize_client()
logger.info(f"Iniciando sessão com endpoint: {self.endpoint_name}")
self.stream = await self.client.invoke_endpoint_with_bidirectional_stream(
InvokeEndpointWithBidirectionalStreamInput(endpoint_name=self.endpoint_name)
)
self.is_active = True
self.response = asyncio.create_task(self._process_responses())
async def send_words(self, words):
for i, word in enumerate(words):
logger.info(f"Enviando payload: {word}")
await self.send_event(word.encode('utf-8'))
await asyncio.sleep(1)
async def send_event(self, data_bytes):
payload = RequestPayloadPart(bytes_=data_bytes)
event = RequestStreamEventPayloadPart(value=payload)
await self.stream.input_stream.send(event)
async def end_session(self):
if not self.is_active:
return
await self.stream.input_stream.close()
logger.info("Stream fechado")
async def _process_responses(self):
try:
output = await self.stream.await_output()
output_stream = output[1]
while self.is_active:
result = await output_stream.receive()
if result is None:
logger.info("Sem mais respostas")
break
if result.value and result.value.bytes_:
response_data = result.value.bytes_.decode('utf-8')
logger.info(f"Recebido: {response_data}")
except Exception as e:
logger.error(f"Erro ao processar respostas: {e}")
def main():
"""Função principal para analisar argumentos e executar o cliente de streaming."""
args = parse_arguments()
print("=" * 60)
print("Cliente de Transmissão Bidirecional SageMaker AI")
print("=" * 60)
print(f"Nome do Endpoint: {args.ENDPOINT_NAME}")
print(f"Região AWS: {AWS_REGION}")
print("=" * 60)
async def run_client():
sagemaker_client = SimpleClient(endpoint_name=args.ENDPOINT_NAME)
try:
await sagemaker_client.start_session()
words = ["Preciso de ajuda com", "meu saldo da conta", "Posso ajudar com isso", "e cobranças recentes"]
await sagemaker_client.send_words(words)
await asyncio.sleep(2)
await sagemaker_client.end_session()
sagemaker_client.is_active = False
if sagemaker_client.response and not sagemaker_client.response.done():
sagemaker_client.response.cancel()
logger.info("Sessão encerrada com sucesso")
return 0
except Exception as e:
logger.error(f"Erro no cliente: {e}")
return 1
try:
exit_code = asyncio.run(run_client())
sys.exit(exit_code)
except KeyboardInterrupt:
logger.info("Interrompido pelo usuário")
sys.exit(1)
except Exception as e:
logger.error(f"Erro inesperado: {e}")
sys.exit(1)
if __name__ == "__main__":
main()
A AWS e a Deepgram colaboraram para construir suporte de transmissão bidirecional especificamente para endpoints do SageMaker AI. A Deepgram, parceira de Tier Avançado da AWS, oferece modelos de IA de voz em nível empresarial com precisão e velocidade líderes do setor. Seus modelos alimentam aplicações de transcrição em tempo real, conversão de texto para fala e agentes de voz para contact centers, plataformas de mídia e aplicações de IA conversacional.
Para clientes com requisitos rigorosos de conformidade que exigem que o processamento de áudio nunca saia de sua Nuvem Privada Virtual (VPC) na AWS, as opções tradicionais auto-hospedadas demandavam sobrecarga operacional considerável para configuração e manutenção. A transmissão bidirecional do Amazon SageMaker transforma completamente essa experiência, permitindo que os clientes implantem e escalem aplicações de IA em tempo real com apenas alguns poucos cliques no Console de Gerenciamento da AWS.
O modelo de fala para texto Deepgram Nova-3 está disponível atualmente no AWS Marketplace para implantação como um endpoint do SageMaker AI, com modelos adicionais chegando em breve. As capacidades incluem transcrição multilíngue, desempenho em escala empresarial e reconhecimento específico de domínio. A Deepgram oferece um período de avaliação gratuita de 14 dias no Amazon SageMaker AI para desenvolvedores prototiparem aplicações sem incorrer em custos de licença de software. As cobranças de infraestrutura do tipo de máquina escolhido ainda serão incorridas durante esse período. Para mais detalhes, consulte a documentação de preços do Amazon SageMaker AI.
Configurando um Endpoint Deepgram no SageMaker AI
Para configurar um endpoint Deepgram no SageMaker AI, navegue até a seção de pacotes de modelos do AWS Marketplace dentro do console do Amazon SageMaker AI e procure por Deepgram. Inscreva-se no produto e proceda ao assistente de lançamento na página do produto. Continue fornecendo detalhes no assistente de criação de endpoint de inferência em tempo real do Amazon SageMaker AI. Certifique-se de editar a variante de produção para incluir um tipo de instância válido ao criar sua configuração de endpoint. O botão de edição pode estar oculto até que você role a direita na tabela de variantes de produção. O ml.g6.2xlarge é um tipo de instância preferido para testes iniciais. Consulte a documentação Deepgram para requisitos específicos de hardware e orientação de seleção. Na página de resumo do endpoint, anote o nome do endpoint que você forneceu, pois será necessário na seção seguinte.
Usando o Endpoint Deepgram no SageMaker AI
Uma aplicação TypeScript de exemplo mostra como transmitir um arquivo de áudio para o modelo Deepgram hospedado em um endpoint de inferência em tempo real do SageMaker AI e imprimir uma transcrição transmitida em tempo real. A função cria um fluxo do arquivo WAV abrindo um arquivo de áudio local e enviando-o para o Amazon SageMaker AI Inference em pequenos blocos binários.
import * as fs from "fs";
import * as path from "path";
import { RequestStreamEvent } from '@aws-sdk/client-sagemaker-runtime-http2';
function sleep(ms: number): Promise {
return new Promise(resolve => setTimeout(resolve, ms));
}
async function* streamWavFile(filePath: string): AsyncIterable {
const full = path.resolve(filePath);
if (!fs.existsSync(full)) {
throw new Error(`Arquivo de áudio não encontrado: ${full}`);
}
console.log(`Transmitindo áudio: ${full}`);
const readStream = fs.createReadStream(full, { highWaterMark: 512_000 }); // 512 KB
for await (const chunk of readStream) {
yield { PayloadPart: { Bytes: chunk, DataType: "BINARY" } };
}
// Mantenha o stream ativo para receber respostas de transcrição após todo arquivo ser enviado
console.log("Áudio enviado, aguardando conclusão da transcrição...");
await sleep(15000); // Aguarde 15 segundos para processamento do bloco final de áudio
// Avise ao contêiner que terminamos
yield { PayloadPart: { Bytes: new TextEncoder().encode('{"type":"CloseStream"}'), DataType: "UTF8" } };
}
O cliente de tempo de execução do AWS SageMaker AI é configurado especificando a região AWS, o nome do endpoint do SageMaker AI e a rota do modelo Deepgram dentro do contêiner. Você precisa atualizar esses valores conforme necessário.
import { SageMakerRuntimeHTTP2Client, InvokeEndpointWithBidirectionalStreamCommand } from '@aws-sdk/client-sagemaker-runtime-http2';
const region = "us-east-1"; // Região AWS
const endpointName = "REPLACEME"; // Nome do seu endpoint Deepgram SageMaker
const audioFile = "test.wav"; // Arquivo de áudio local
const modelInvocationPath = "v1/listen"; // Caminho WebSocket dentro do contêiner do modelo
const modelQueryString = "model=nova-3";
const client = new SageMakerRuntimeHTTP2Client({ region });
O trecho final envia o fluxo de áudio ao endpoint do SageMaker AI e imprime os eventos JSON de transmissão da Deepgram conforme chegam. A aplicação exibe a saída de fala para texto ao vivo sendo gerada.
async function run() {
console.log("Enviando áudio para Deepgram via SageMaker...");
const command = new InvokeEndpointWithBidirectionalStreamCommand({
EndpointName: endpointName,
Body: streamWavFile(audioFile),
ModelInvocationPath: modelInvocationPath,
ModelQueryString: modelQueryString
});
const response = await client.send(command);
if (!response.Body) {
console.log("Nenhuma resposta de streaming recebida.");
return;
}
const decoder = new TextDecoder();
for await (const msg of response.Body) {
if (msg.PayloadPart?.Bytes) {
const text = decoder.decode(msg.PayloadPart.Bytes);
try {
const parsed = JSON.parse(text);
// Extraia e exiba a transcrição
if (parsed.channel?.alternatives?.[0]?.transcript) {
const transcript = parsed.channel.alternatives[0].transcript;
if (transcript.trim()) {
console.log("Transcrição:", transcript);
}
}
console.debug("Deepgram (bruto):", parsed);
} catch {
console.error("Deepgram (erro):", text);
}
}
}
}
console.log("Streaming concluído.");
}
run().catch(console.error);
A transmissão bidirecional no Amazon SageMaker AI Inference representa um avanço significativo na forma como os desenvolvedores podem construir aplicações de IA em tempo real. Ao eliminar as limitações das interações transacionais tradicionais, essa capacidade abre possibilidades para experiências de usuário genuinamente conversacionais e responsivas.
Com suporte para contêineres customizados e integração pronta com modelos parceiros como o Deepgram, a plataforma oferece flexibilidade tanto para quem deseja trazer seus próprios modelos quanto para quem busca soluções prontas para produção. A infraestrutura de três camadas garante eficiência, enquanto o monitoramento automático de conexão assegura confiabilidade.
Developers podem começar a construir aplicações de transmissão bidirecional com Modelos de Linguagem Grande (LLMs) e SageMaker AI hoje mesmo, abrindo novos horizontes para agentes de voz, assistentes conversacionais e qualquer aplicação que se beneficie de comunicação em tempo real verdadeiramente bidirecional.
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.
