O que é um proxy aberto e por que isso importa na AWS

Um proxy aberto é um servidor que encaminha tráfego de internet em nome de usuários sem exigir nenhum tipo de autenticação. Em teoria, proxies têm usos legítimos — balanceamento de carga, cache de conteúdo, filtragem de tráfego. O problema começa quando esses serviços ficam expostos sem controles de acesso: qualquer pessoa na internet pode utilizá-los, inclusive agentes mal-intencionados que querem esconder sua identidade ou origem.

No contexto da Amazon Web Services (AWS), proxies abertos surgem com frequência a partir de configurações incorretas em instâncias do Amazon Elastic Compute Cloud (Amazon EC2), containers ou recursos de computação como funções do AWS Lambda. Esses recursos acabam expondo funcionalidades de proxy sem os devidos controles — muitas vezes sem que o time de infraestrutura perceba.

Tipos comuns de proxy aberto

Entender as variações de proxy ajuda a identificar onde a exposição pode ocorrer. Os tipos mais comuns são:

• Proxies HTTP: encaminham requisições HTTP para servidores web. São úteis para gerenciamento de tráfego web, mas se ficarem desprotegidos, tornam-se uma porta de entrada fácil.
• Proxies SOCKS: suportam uma gama mais ampla de tipos de tráfego, o que também amplia o potencial de uso indevido.
• Proxies transparentes: interceptam tráfego sem que o cliente saiba, geralmente usados para filtragem de conteúdo. Quando mal configurados, viram um passivo de segurança.
• Proxies reversos: auxiliam no roteamento interno. Se expostos indevidamente, podem ser explorados por usuários não autorizados.

Riscos concretos para o seu ambiente AWS

Quando a infraestrutura AWS hospeda um proxy aberto, as consequências vão além de um simples problema técnico. A AWS aponta os principais riscos:

• Reputação do IP comprometida: agentes maliciosos podem usar seus recursos para atividades como envio de spam, tentativas de intrusão e ataques de negação de serviço (DoS — Denial of Service). Isso pode resultar na inclusão do seu endereço IP em listas de bloqueio de serviços de segurança e sistemas de reputação, afetando diretamente suas operações legítimas.
• Custos inesperados: quando terceiros utilizam sua largura de banda e capacidade computacional sem autorização, a conta no final do mês pode surpreender negativamente.
• Alertas e sobrecarga operacional: os padrões de tráfego gerados pelo abuso de proxies podem acionar os sistemas de monitoramento de segurança da AWS, criando trabalho extra para investigar e responder a esses alertas.
• Instabilidade nos workloads legítimos: o tráfego não autorizado compete por recursos com suas aplicações críticas, podendo degradar a performance ou causar problemas de disponibilidade para seus clientes.

Como implementar controles de segurança

A AWS apresenta uma abordagem abrangente para proteger a infraestrutura de proxy. As recomendações estão organizadas em cinco frentes principais.

Controle de acesso

O primeiro passo é restringir quem pode se conectar ao proxy. Isso significa configurar os serviços para aceitar conexões apenas de faixas de endereços IP conhecidos e confiáveis.

• Para o Elastic Load Balancing (ELB), limite o acesso por IP de origem e adicione autenticação aos proxies posicionados atrás dos balanceadores.
• No Amazon Elastic Kubernetes Service (Amazon EKS), ao criar novas instâncias, restrinja o acesso ao balanceador em cada instância. Se as instâncias não tiverem IPs públicos, basta limitar o acesso ao balanceador. Se tiverem IPs públicos, é preciso restringir o acesso a esses endereços diretamente.
• Sempre que possível, use os endpoints de Nuvem Privada Virtual (VPC — Virtual Private Cloud) do AWS PrivateLink para fornecer conectividade privada aos serviços AWS sem expô-los à internet.
• Implante os serviços de proxy em sub-redes privadas com acesso de saída controlado via gateways NAT ou outros canais gerenciados.
• Para recursos do Amazon EC2 e do Amazon Lightsail, atualize o grupo de segurança associado para bloquear o acesso público à internet. A proteção do proxy exige que você limite o acesso a IPs específicos ou implemente autenticação no endpoint.

Autenticação e autorização

Ative a autenticação no software de proxy e use credenciais fortes, certificados ou integração com o AWS Identity and Access Management (IAM) e o AWS Directory Service. Aplique políticas de IAM com o princípio do menor privilégio, garantindo que cada usuário tenha acesso apenas ao que precisa para realizar suas tarefas. Essa abordagem reduz o impacto potencial de um comprometimento de credenciais e mantém a rastreabilidade dos acessos.

Monitoramento e detecção

Para detectar atividades suspeitas, a AWS recomenda configurar os Logs de Fluxo do Amazon Virtual Private Cloud (Amazon VPC), o AWS CloudTrail e o Amazon GuardDuty. Além disso, configure alarmes no Amazon CloudWatch para ser notificado sobre padrões de tráfego anormais que possam indicar uso não autorizado dos seus serviços de proxy. Essas ferramentas juntas oferecem visibilidade sobre o tráfego de rede e ajudam a distinguir uso legítimo de atividade suspeita.

Boas práticas de implantação

Algumas práticas complementam os controles anteriores e reduzem ainda mais a superfície de ataque:

• Use HTTPS para o tráfego do ELB, protegendo os dados em trânsito.
• Restrinja os grupos de segurança às portas estritamente necessárias.
• Integre o AWS WAF aos balanceadores para filtrar tráfego web com base em regras definidas por você.
• Utilize o AWS Network Firewall para capacidades avançadas de filtragem de tráfego.
• Para APIs, implante o Amazon API Gateway com controles de autenticação e autorização para gerenciar o acesso aos serviços de backend. Essa abordagem em camadas protege a infraestrutura em múltiplos pontos do fluxo de tráfego.

Avaliações regulares de segurança

Segurança não é uma configuração única — é um processo contínuo. A AWS recomenda executar o Amazon Inspector para identificar configurações incorretas na infraestrutura e usar o AWS Security Hub para centralizar os achados de segurança de todo o ambiente AWS. Testes de penetração realizados conforme a política da AWS também são indicados para descobrir vulnerabilidades antes que possam ser exploradas.

Planejamento de resposta a incidentes

Automatize a remediação com regras do AWS Config e com o recurso de Automação do AWS Systems Manager para responder rapidamente a eventos de segurança. Mantenha runbooks de resposta a incidentes com passos claros para lidar com situações relacionadas a proxies, e descomissione recursos inativos que possam se tornar passivos de segurança. Procedimentos documentados e respostas automatizadas reduzem o tempo entre detecção e remediação, minimizando o impacto de incidentes nas operações.

O que você ganha ao proteger seus proxies corretamente

Implementar essas medidas traz benefícios diretos e tangíveis para o ambiente AWS:

• Proteção da reputação do IP: mantém a confiança dos clientes e evita que serviços de segurança bloqueiem seu tráfego legítimo. Com uma reputação positiva, suas comunicações chegam aos destinatários sem interferência.
• Controle de custos: impede que usuários não autorizados consumam seus recursos AWS e gerem cobranças inesperadas. Restringindo o acesso a usuários e casos de uso legítimos, os custos se tornam previsíveis e alinhados às necessidades do negócio.
• Estabilidade operacional: reduz o risco de interrupções causadas pelo abuso da infraestrutura de proxy. Quando os recursos são dedicados a servir clientes legítimos, é possível entregar performance e disponibilidade consistentes.
• Visibilidade aprimorada: o monitoramento adequado dos padrões de tráfego ajuda a identificar tanto o uso legítimo quanto possíveis ameaças, permitindo decisões mais informadas sobre planejamento de capacidade, melhorias de segurança e otimizações operacionais.

Responsabilidade compartilhada entra em cena

Vale lembrar que, sob o modelo de responsabilidade compartilhada da AWS, a configuração e manutenção desses controles de segurança são responsabilidade do cliente. A AWS fornece a infraestrutura segura subjacente — mas a proteção dos serviços que rodam sobre ela depende de quem os opera. Proxies abertos são, em grande parte, um problema de configuração, e portanto estão no lado do cliente nessa equação.

Seguir as orientações descritas neste guia permite construir uma postura de segurança robusta que protege a infraestrutura de proxy sem comprometer as necessidades legítimas do negócio.

Fonte

Securing open proxies in your AWS environment (https://aws.amazon.com/blogs/security/securing-open-proxies-in-your-aws-environment/)

Nova versão LTS do FreeRTOS chega com foco em segurança e protocolos modernos

A AWS anunciou a disponibilidade do FreeRTOS 202604 LTS, nova versão de Suporte de Longo Prazo (LTS) do sistema operacional de tempo real open-source voltado para dispositivos embarcados. A versão garante estabilidade de funcionalidades, atualizações de segurança e correções de bugs críticos por dois anos, sendo uma referência importante para desenvolvedores de sistemas embarcados e fabricantes de dispositivos de Internet das Coisas (IoT).

A release endereça desafios centrais do ecossistema embarcado: segurança de memória, qualidade de código e suporte a protocolos modernos. A seguir, os principais destaques desta versão.

Kernel FreeRTOS v11.3.0: novos ports e proteção de memória mais flexível

O kernel FreeRTOS na versão v11.3.0 traz novos ports de hardware, hardening de segurança e suporte expandido à Unidade de Proteção de Memória (MPU). Uma mudança relevante é a redução do número de regiões MPU ocupadas pelo próprio FreeRTOS, liberando mais regiões de hardware para que os desenvolvedores possam implementar proteções de memória específicas para suas aplicações. Isso dá mais controle e flexibilidade para quem trabalha com ambientes com recursos limitados.

coreMQTT v5.0.2: suporte ao protocolo MQTT v5.0

O coreMQTT v5.0.2 passa a suportar o protocolo MQTT v5.0, trazendo recursos como topic aliases (aliases de tópico) — úteis para dispositivos com largura de banda restrita — e padrões de requisição/resposta para aplicações IoT interativas. Essa atualização abre caminho para arquiteturas de comunicação mais eficientes e expressivas em projetos embarcados conectados.

coreSNTP v2.0.0: preparado para o ano 2038

O coreSNTP v2.0.0 chega com uma atualização estratégica: preparação para o problema do ano 2038. Dispositivos implantados hoje poderão validar certificados TLS e registrar timestamps de forma correta ao longo de toda a sua vida útil operacional, sem risco de falhas relacionadas ao estouro do contador de tempo Unix de 32 bits.

Bibliotecas verificadas: segurança de memória e conformidade MISRA-C

Esta versão LTS inclui bibliotecas verificadas quanto à segurança de memória e conformidade com o padrão MISRA-C, um conjunto de diretrizes amplamente adotado em sistemas críticos e embarcados. O resultado é maior robustez, portabilidade e confiabilidade nas aplicações desenvolvidas com o FreeRTOS.

Migração e suporte estendido

Para quem precisa atualizar projetos existentes, guias de migração detalhados estão disponíveis para o coreMQTT e o coreSNTP, facilitando a transição para o FreeRTOS 202604 LTS.

Projetos que ainda dependem da versão LTS anterior e precisam de correções críticas após o fim do suporte podem contar com o Plano de Manutenção Estendida do FreeRTOS.

Para saber mais, acesse a página oficial do FreeRTOS LTS ou explore o repositório GitHub do FreeRTOS LTS.

Fonte

FreeRTOS 202604 LTS now available with enhanced security and MQTT v5.0 (https://aws.amazon.com/about-aws/whats-new/2026/04/freertos-lts/)

O que foi anunciado

A AWS anunciou que o OpenSearch UI agora oferece suporte a acesso de dados entre regiões (cross-region), permitindo que usuários acessem domínios OpenSearch hospedados em diferentes Regiões AWS diretamente de uma única aplicação OpenSearch UI. Combinado com o acesso entre contas (cross-account) lançado anteriormente neste ano, agora é possível consultar dados ou construir dashboards em domínios OpenSearch em combinações flexíveis de contas e Regiões — sem precisar trocar de endpoint ou replicar dados.

Configurações suportadas

O acesso cross-region está disponível para domínios OpenSearch hospedados tanto em configurações públicas quanto em configurações de Nuvem Privada Virtual (VPC). Isso garante que equipes com diferentes arquiteturas de rede possam aproveitar o recurso sem restrições de topologia.

Benefícios práticos para equipes distribuídas

Com o acesso cross-region, equipes conseguem construir fluxos de trabalho centralizados de análise, busca e observabilidade em implantações distribuídas globalmente — mantendo os dados no lugar de origem. Isso traz vantagens concretas:

• Atendimento a requisitos de residência de dados (data residency), pois os dados não precisam sair de suas Regiões originais;
• Redução de custos com tráfego de saída entre Regiões (inter-region egress);
• Preservação das características de latência e disponibilidade de cada Região.

Integração com replicação entre clusters

Para quem já utiliza replicação entre clusters (cross-cluster replication), o novo recurso traz uma vantagem adicional: agora é possível consultar tanto o domínio primário quanto o domínio réplica diretamente de uma única aplicação OpenSearch UI, sem precisar alternar entre interfaces.

Combinação com acesso entre contas

O acesso cross-region pode ser combinado com o acesso cross-account, o que significa que uma única aplicação OpenSearch UI consegue se conectar a domínios em contas diferentes, em Regiões diferentes, ou nas duas situações ao mesmo tempo — oferecendo máxima flexibilidade para arquiteturas complexas e ambientes multi-conta.

Autenticação suportada

O recurso é compatível com dois mecanismos de autenticação de usuários finais: IAM (Gerenciamento de Identidade e Acesso — Identity and Access Management) e IAM Identity Center, garantindo integração com os fluxos de controle de acesso já existentes nas organizações.

Disponibilidade

O acesso cross-region a domínios OpenSearch já está disponível em todas as Regiões AWS onde o OpenSearch UI está presente. Para aprofundar o entendimento técnico, a AWS disponibiliza a documentação completa no Guia do Desenvolvedor do Amazon OpenSearch Service: Acesso cross-region a domínios OpenSearch.

Fonte

OpenSearch UI supports cross-region data access to OpenSearch domains (https://aws.amazon.com/about-aws/whats-new/2026/05/opensearch-ui-cross-region-data-access-domains/)

O contexto: IA acelerou o jogo, mas os fundamentos continuam sendo a base

Há poucas semanas, a Anthropic anunciou o modelo Claude Mythos Preview e lançou o Project Glasswing em parceria com a AWS e outras organizações de referência no setor. O movimento gerou bastante debate sobre o futuro da cibersegurança e o que o avanço contínuo dos modelos de fundação significa para as empresas na prática.

Nesse contexto, a AWS publicou um artigo destacando um ponto central: independentemente de onde a IA vai chegar, as organizações que não tiverem os fundamentos de segurança bem estabelecidos simplesmente não conseguirão reagir com agilidade às mudanças. E velocidade de resposta, na segurança, é tudo.

Para quem quiser se aprofundar na visão da AWS sobre como construir defesas de IA em escala, vale conferir o post Construindo defesas de IA em escala: antes das ameaças emergirem.

O problema real: a lacuna de higiene de segurança

É tentador achar que os elementos básicos de segurança já estão cobertos. Mas, na prática, casos de uso fundamentais — como gestão de identidade, detecção de ameaças, gestão de vulnerabilidades, proteção de dados e segurança de rede — costumam ser implementados de forma inconsistente em ambientes de nuvem.

A AWS reforça que, enquanto a IA redesenha o cenário de segurança, os fundamentos continuam sendo essenciais para qualquer organização, independentemente do tamanho ou setor. São eles:

• Aplicar patches de forma consistente
• Enforçar acesso com privilégio mínimo
• Habilitar logging e monitoramento
• Criptografar dados em repouso e em trânsito
• Revisar configurações de segurança regularmente

Com esses fundamentos estabelecidos, a organização fica muito melhor posicionada para aproveitar ferramentas orientadas por IA e responder rapidamente a vulnerabilidades recém-descobertas.

Para ajudar nessa jornada, a AWS disponibiliza gratuitamente materiais como o AWS Well-Architected Framework, que orienta as perguntas certas e ajuda a implementar melhorias no ambiente. Além disso, existe um programa específico para isso: o SHIP.

O que é o SHIP?

O Programa de Melhoria de Saúde em Segurança (SHIP) é um programa gratuito disponível para todos os clientes AWS, independentemente do nível de suporte contratado. Ele oferece uma metodologia comprovada e orientada por dados para:

• Avaliar a postura de segurança atual usando dados do próprio ambiente AWS do cliente
• Identificar oportunidades específicas de melhoria em 10 casos de uso principais de segurança
• Construir um plano de ação priorizado e adequado ao contexto da organização
• Estabelecer um mecanismo de melhoria contínua de segurança

O programa é conduzido por Arquitetos de Soluções e Gerentes Técnicos de Conta da AWS, que guiam o cliente por um relatório personalizado, contextualizam as descobertas para o ambiente específico e ajudam a montar um plano de ação com prioridades claras.

Por que o SHIP importa na era da IA?

O Project Glasswing evidencia uma mudança importante: ferramentas com IA estão acelerando o ritmo de descoberta de vulnerabilidades. Isso significa que as organizações precisam estar preparadas para avaliar e responder a novas descobertas muito mais rápido do que antes.

Além dos fatores externos, à medida que as empresas adotam IA — seja implantando modelos de fundação, construindo fluxos de trabalho agênticos ou usando serviços com IA embutida — a forma como implementam seus controles de segurança também precisa evoluir. Uma base sólida de segurança é o que torna a adoção confiante de IA possível.

Corrigir lacunas de segurança de forma proativa

O SHIP utiliza metodologia orientada por dados para identificar oportunidades de melhoria em 10 casos de uso principais de segurança: detecção de ameaças, gestão de postura de segurança em nuvem, testes de segurança de aplicações, gestão de configuração, governança de acesso, gestão de vulnerabilidades, proteção de aplicações, segurança de rede, criptografia e gestão de segredos.

O programa inclui uma avaliação SHIP para identificar descobertas críticas relacionadas à postura de segurança atual, permitindo que a equipe construa um roteiro de melhoria priorizado e adequado ao ambiente.

Estabelecer a linha de base de segurança que workloads de IA exigem

Antes de implantar o primeiro modelo no Amazon Bedrock ou construir fluxos de trabalho agênticos com o Amazon Bedrock AgentCore, é necessário ter confiança de que a infraestrutura subjacente segue as boas práticas de segurança. O SHIP usa dados reais do ambiente do cliente para fornecer orientações prescritivas e específicas, em vez de recomendações genéricas.

Isso é especialmente relevante à medida que ferramentas de descoberta de vulnerabilidades baseadas em IA se tornam mais amplamente disponíveis: organizações com bases sólidas conseguirão agir sobre novas descobertas de forma rápida e eficaz.

Construir um mecanismo de melhoria contínua de segurança

À medida que as capacidades de IA evoluem, as organizações se beneficiam de ter um processo repetível para avaliar e fortalecer sua postura de segurança ao longo do tempo. O SHIP estabelece a metodologia e os mecanismos para que a equipe avalie, priorize e melhore continuamente. Ao construir essa capacidade operacional, a organização fortalece sua habilidade de se adaptar e contribui para a resiliência mais ampla do setor.

Como começar com o SHIP

O programa está disponível hoje, sem custo, para todos os clientes AWS. Há três caminhos para dar o primeiro passo:

• Fale com o time de conta AWS. Solicite o agendamento de um engajamento SHIP diretamente ou acesse a página do SHIP para fazer a solicitação.
• Participe de um SHIP Activation Day. A AWS realiza regularmente workshops práticos onde é possível executar a avaliação SHIP com Arquitetos de Soluções e começar a construir o plano de melhoria.
• Explore a documentação prescritiva. Consulte o AWS Well-Architected Framework – Security Lens para documentação, arquiteturas de referência e guias de implementação disponíveis para uso imediato.

Conclusão

O recado da AWS é claro: a IA está acelerando tanto as capacidades de ataque quanto as de defesa, e as organizações que já tiverem seus fundamentos de segurança bem estabelecidos sairão na frente. O SHIP é uma oportunidade concreta — e gratuita — de fazer essa avaliação com apoio especializado, construir um plano priorizado e criar um ciclo de melhoria contínua.

Para quem está pensando em adotar workloads de IA na AWS, esse é um passo que vale ser dado antes, não depois. Acesse a página de recursos do SHIP para saber mais.

Fonte

Security posture improvement in the AI era (https://aws.amazon.com/blogs/security/security-posture-improvement-in-the-ai-era/)

O que foi anunciado

O AWS Security Assurance Services acaba de publicar um novo guia de conformidade: o ISO 31000:2018 Risk Management on AWS Compliance Guide. O material foi desenvolvido para ajudar organizações que desejam estruturar ou aprimorar seus programas de gestão de riscos em ambientes AWS, seguindo os princípios da norma ISO 31000:2018.

Trata-se de um recurso prático — não apenas teórico — que mostra como integrar os serviços AWS aos processos de gestão de riscos já existentes nas empresas.

O que o guia cobre

O documento está estruturado em torno dos componentes centrais da ISO 31000:2018 e explica como os recursos da AWS podem dar suporte a cada um deles:

• Estabelecimento de contexto e critérios: como definir o escopo e os parâmetros do programa de riscos dentro do ambiente AWS.
• Avaliação de riscos: como usar os serviços da AWS para identificar, analisar e priorizar riscos.
• Tratamento de riscos: estratégias práticas de mitigação, transferência, aceitação e eliminação de riscos, com apoio das ferramentas disponíveis na plataforma.
• Monitoramento e revisão contínuos: como as capacidades de automação e monitoramento da AWS ajudam a manter a visibilidade operacional e a prontidão para conformidade ao longo do tempo.

Governança e o Modelo de Responsabilidade Compartilhada

Um ponto de destaque do guia é a conexão com o Modelo de Responsabilidade Compartilhada da AWS. O documento apresenta considerações de governança e tratamento de riscos alinhadas a esse modelo, deixando claro o que é responsabilidade da AWS e o que cabe ao cliente gerenciar — algo fundamental para qualquer programa de conformidade bem estruturado.

Por que isso importa para equipes brasileiras

A ISO 31000 é uma norma internacional amplamente adotada por organizações que precisam demonstrar maturidade em gestão de riscos — seja para auditorias internas, exigências regulatórias ou certificações. Ter um guia específico para ambientes AWS simplifica bastante o trabalho de times de segurança, compliance e arquitetura que precisam mapear como os controles da nuvem se encaixam no framework de riscos da empresa.

Ao combinar os princípios da ISO 31000 com os serviços de segurança da AWS, as organizações conseguem construir ambientes escaláveis e automatizados que suportam a identificação contínua de riscos, o tratamento proativo de ameaças e a visibilidade operacional necessária para manter a conformidade.

Como acessar

O guia está disponível gratuitamente para download. Acesse o ISO 31000:2018 Risk Management on AWS Compliance Guide diretamente pelo site da AWS. Para suporte adicional ou dúvidas sobre implementação, o AWS Security Assurance Services pode ser acionado diretamente.

Fonte

Announcing the ISO 31000:2018 Risk Management on AWS Compliance Guide (https://aws.amazon.com/blogs/security/announcing-the-iso-310002018-risk-management-on-aws-compliance-guide/)

O que mudou

A AWS anunciou que o Amazon CloudFront agora suporta tráfego WebSocket através de origens em Nuvem Privada Virtual (VPC — Virtual Private Cloud). Isso significa que aplicações em tempo real hospedadas inteiramente em sub-redes privadas podem usar o CloudFront como único ponto de entrada, sem precisar expor nada à internet diretamente.

Por que isso importa

Antes dessa mudança, quem precisava usar WebSockets tinha um problema claro: as origens precisavam estar em sub-redes públicas. Para proteger esses servidores, as equipes precisavam configurar e manter Listas de Controle de Acesso (ACLs — Access Control Lists) e outros mecanismos de restrição — o que gerava esforço contínuo e complexidade operacional.

Agora, a AWS permite que os clientes coloquem seus recursos — como Balanceadores de Carga de Aplicação (ALB — Application Load Balancer), Balanceadores de Carga de Rede (NLB — Network Load Balancer) e instâncias EC2 — em sub-redes totalmente privadas, acessíveis apenas através das distribuições do CloudFront.

Casos de uso beneficiados

A extensão do suporte a WebSockets para origens VPC é especialmente relevante para aplicações que dependem de conexões persistentes e bidirecionais entre clientes e servidores. Alguns exemplos práticos mencionados pela AWS:

• Plataformas de chat
• Ferramentas de edição colaborativa
• Dashboards ao vivo
• Sistemas de gerenciamento de dispositivos de IoT (Internet das Coisas)

Benefícios de segurança

Com essa novidade, o CloudFront passa a funcionar como a porta de entrada única tanto para tráfego HTTP tradicional quanto para conexões WebSocket em tempo real. Segundo a AWS, isso traz benefícios concretos:

• Redução da superfície de ataque, já que os servidores de origem ficam em sub-redes privadas
• Simplificação do gerenciamento de segurança, centralizando o controle de acesso no CloudFront
• Proteção integrada contra DDoS (Negação de Serviço Distribuída — Distributed Denial of Service), nativa do CloudFront

Disponibilidade e custo

O suporte a WebSockets para origens VPC já está disponível em todas as Regiões Comerciais da AWS onde o recurso de origens VPC é suportado. A AWS informa que não há custo adicional para o tráfego WebSocket através de origens VPC.

Para saber mais sobre como configurar esse recurso, a documentação oficial está disponível em Origens VPC no CloudFront.

Fonte

Amazon CloudFront Announces WebSocket Support for VPC Origins (https://aws.amazon.com/about-aws/whats-new/2026/05/amazon-cloudfront-websockets-vpc-origins/)