Edge Computing com AWS: CloudFront, Lambda@Edge e IoT

A premissa do edge computing é direta: mover o processamento para perto de quem consome o dado reduz a distância que os pacotes percorrem e, por consequência, a latência percebida. Na prática, "perto" pode significar coisas bem diferentes. A AWS oferece mecanismos distintos para cada caso: computação nas localizações de borda do CloudFront, para tráfego web, e computação nos próprios dispositivos, via IoT Greengrass.

Antes de entrar nas ferramentas, vale deixar claro o que o CloudFront é: uma CDN (Content Delivery Network) que distribui conteúdo a partir de uma rede de pontos de presença chamados edge locations. O CloudFront armazena em cache respostas de origens (S3, ALB, API Gateway, servidores próprios) e serve requisições subsequentes a partir da localização mais próxima do cliente. Quando o cache não tem a resposta, a requisição sobe para a origem, que pode estar em uma região AWS ou fora dela.

Quando o cache não é suficiente

Servir arquivos estáticos a partir do cache resolve boa parte dos casos de latência. Mas muitas aplicações precisam de lógica no meio do caminho: redirecionar uma URL antiga, validar um token antes de encaminhar a requisição à origem, personalizar a resposta com base na geolocalização ou no tipo de dispositivo. Para isso, a AWS oferece duas opções de computação acopladas ao CloudFront.

CloudFront Functions

CloudFront Functions são funções JavaScript leves que executam nas edge locations do CloudFront, nos eventos de viewer request e viewer response, ou seja, na entrada e na saída do tráfego entre o cliente e o CloudFront. A execução é rápida porque o ambiente é intencionalmente restrito: sem acesso à rede, sem acesso ao corpo da requisição, tempo de execução em submilissegundos e memória máxima de 2 MB.

Casos onde isso funciona bem: redirecionamentos simples (trailing slash, normalização de URL), manipulação de cabeçalhos HTTP, rewrite de caminhos para SPA, validação leve de tokens baseada apenas nos cabeçalhos.

O que não cabe aqui: qualquer coisa que dependa de uma chamada externa, de leitura do corpo da requisição ou de lógica mais pesada. Para esses cenários existe o Lambda@Edge.

Lambda@Edge

Lambda@Edge é a opção mais poderosa. São funções Lambda replicadas automaticamente para as regiões de borda do CloudFront e executadas em quatro pontos do ciclo de vida de uma requisição: viewer request, origin request, origin response e viewer response.

A diferença mais relevante está nos dois eventos de origem (origin request e origin response): eles executam depois que o CloudFront decide encaminhar para a origem e têm acesso ao corpo da requisição, o que abre espaço para personalização mais profunda, transformação de payload e geração de resposta sem precisar chegar à origem.

Lambda@Edge suporta Node.js e Python. Os limites são mais generosos que os do CloudFront Functions (até 128 MB de memória para funções de viewer, até 10 GB para funções de origin; timeouts de 5 s a 30 s), mas o modelo de implantação tem uma particularidade: as funções precisam ser publicadas na região us-east-1 e são replicadas pelo CloudFront para as demais regiões automaticamente.

Casos de uso típicos: autenticação e autorização na borda (validar JWTs antes de a requisição chegar à origem), A/B testing com divisão de tráfego baseada em cookies ou cabeçalhos, personalização por geolocalização, geração de respostas diretas na borda para reduzir carga na origem.

Comparativo direto

A borda do dispositivo: IoT Greengrass

Edge computing na rede de distribuição de conteúdo é um modelo: o código roda em infraestrutura da AWS próxima ao usuário. O modelo de IoT é outro: o código precisa rodar no próprio dispositivo ou em um gateway local, às vezes sem conectividade com a nuvem.

O AWS IoT Greengrass resolve esse problema. É um runtime que roda em hardware local (gateways industriais, Raspberry Pi, servidores de borda) e permite executar código Lambda ou containers localmente, processar dados de sensores antes de enviá-los à nuvem, aplicar modelos de machine learning (via integração com SageMaker Edge Manager) e sincronizar estado com a AWS quando a conectividade estiver disponível.

O caso de uso mais direto é o processamento de telemetria local: um dispositivo IoT industrial que gera muitos eventos por segundo não precisa (e muitas vezes não consegue) enviar cada leitura para a nuvem. O Greengrass filtra, agrega ou transforma os dados localmente e transmite apenas o necessário. Além de reduzir custo de transferência, garante que a lógica continue funcionando em caso de perda de conectividade.

Quando usar cada abordagem

Esses modelos não competem diretamente; cada um responde a uma camada diferente do problema.

• CloudFront Functions: lógica simples, de alta frequência, que precisa de latência mínima e não depende de recursos externos. Redirecionamentos, normalização de URL, headers de segurança.
• Lambda@Edge: lógica que precisa de contexto mais rico, acesso à rede ou ao corpo da requisição. Autenticação, personalização por geolocalização, proxies leves.
• IoT Greengrass: lógica que precisa rodar no dispositivo ou no gateway local, com ou sem conectividade, processando dados de sensores ou controlando atuadores.

A tentação de usar Lambda@Edge para tudo o que parece "na borda" costuma resultar em funções com latência maior do que o necessário e custo mais alto. CloudFront Functions serve para o caso simples por um motivo: elas são deliberadamente limitadas para permanecer baratas e rápidas.

Trade-offs de operar código distribuído

Mover lógica para a borda resolve o problema de latência e cria outros. O mais relevante é observabilidade: funções executando em dezenas de regiões ao mesmo tempo geram logs distribuídos no CloudWatch. O Lambda@Edge grava logs na região de borda onde executou, não necessariamente em us-east-1. Agregar esses logs para depuração exige configuração explícita de assinaturas e, em geral, uma ferramenta centralizada.

Deploys também têm comportamento diferente. Alterar uma função Lambda@Edge requer publicar uma nova versão e associá-la ao comportamento do CloudFront; a propagação leva alguns minutos. Reverter um bug em produção distribuída leva mais tempo do que reverter uma função Lambda regional. CloudFront Functions têm propagação mais rápida, mas o ciclo de debug ainda envolve múltiplas regiões.

Como começar

Para quem ainda não usa computação na borda, o caminho mais direto é começar com CloudFront Functions em um comportamento existente. A AWS oferece um editor no console e logs básicos via CloudWatch. É possível testar com o evento de viewer request para adicionar cabeçalhos de segurança (Content-Security-Policy, Strict-Transport-Security) em todas as respostas, sem tocar na origem.

Lambda@Edge faz sentido quando a função precisar de algo que o CloudFront Functions não suporta: uma chamada a um serviço externo para validar tokens, por exemplo. A recomendação é criar a função como uma Lambda comum primeiro, testá-la em uma região, e só depois associar ao CloudFront e publicar na us-east-1.

Para IoT Greengrass, o ponto de entrada é o console do AWS IoT Core, onde é possível provisionar um grupo Greengrass, instalar o runtime em um dispositivo local e publicar as primeiras funções. A documentação da AWS descreve o processo de instalação por sistema operacional e os requisitos mínimos de hardware.

O que vale ter claro desde o início: código distribuído globalmente exige que observabilidade e estratégia de rollback estejam definidos antes de ir para produção. Não depois do primeiro incidente.