AWS Builder Center
Computação de Borda (Edge Computing): Personalização Dinâmica em Tempo Real com Amazon CloudFront e Lambda@Edge

Computação de Borda (Edge Computing): Personalização Dinâmica em Tempo Real com Amazon CloudFront e Lambda@Edge

O artigo detalha a supressão da latência intercontinental na entrega de conteúdo dinâmico através da integração do Amazon CloudFront com funções Lambda@Edge. Direcionado a engenheiros de software seniores, o material orienta a construção de motores de personalização e testes A/B globais ancorados no Amazon DynamoDB Global Tables, garantindo taxas massivas de acerto de cache (cache hit ratio) sem sacrificar a individualização da experiência do usuário.

Systems Architect na NTT DATA, Estudante Doutorado na MUST University, 12x AWS e ASD & ADHD
Redes de Entrega de Conteúdo (CDNs) mitigam a latência global com extrema eficácia ao armazenar em cache ativos estáticos próximos aos usuários finais. Quando a arquitetura exige conteúdo dinâmico e estritamente personalizado, como vitrines de e-commerce individualizadas ou testes A/B baseados em identidade, o modelo tradicional de cache entra em colapso. O tráfego é forçado a contornar a borda da rede (cache bypass) e viajar até os servidores de origem centralizados para computação, destruindo a latência e multiplicando os custos de transferência de dados (egress). A implementação do paradigma de Computação de Borda (Edge Computing) utilizando o Amazon CloudFront associado ao AWS Lambda@Edge resolve essa ineficiência estrutural. Ao deslocar a execução da lógica de negócios diretamente para os Pontos de Presença (PoPs) da AWS espalhados pelo globo, os arquitetos interceptam as requisições antes que elas atinjam o cache. Esta topologia permite reescrever chaves de cache, validar tokens de autenticação e injetar conteúdo personalizado em latências sub-milissegundo, preservando a carga na infraestrutura central e maximizando a retenção de usuários.

Pré-requisitos

O provisionamento desta topologia de borda exige um domínio profundo sobre o ciclo de vida das requisições HTTP e as mecânicas de invalidação de cache. A infraestrutura deve ser orquestrada deterministicamente através do Terraform versão 1.7.0 ou superior e o provedor HashiCorp AWS versão 5.40.0. A camada de computação efêmera necessita do Python 3.12, configurado com empacotamento rigoroso para respeitar os limites de tamanho de implantação da borda. Privilégios administrativos no AWS IAM são vitais para estabelecer a relação de confiança com o serviço edgelambda.amazonaws.com, permitindo que a infraestrutura da AWS replique o código da função para centenas de zonas geográficas simultaneamente.

Passo a Passo

Topologia de Distribuição Global com Amazon CloudFront

A construção da arquitetura de borda inicia com o provisionamento de uma distribuição do Amazon CloudFront operando como a interface pública imutável do sistema. A justificativa técnica para ancorar todo o tráfego corporativo nesta camada reside na aceleração do aperto de mão (handshake) TLS e na proteção contra ataques de negação de serviço (DDoS) absorvidos pelo AWS Shield Standard nativo. Configuramos os comportamentos de cache (Cache Behaviors) para agir de forma agressiva, mas delegamos o controle de granularidade a variáveis de cabeçalho específicas e cookies de sessão. Em vez de declarar o caminho /api/recommendations como dinâmico e impossível de armazenar em cache, configuramos o CloudFront para incluir um cabeçalho customizado (como X-User-Segment) na Chave de Cache (Cache Key). Isso permite que a mesma URL retorne respostas armazenadas fisicamente no cache distintas dependendo do perfil do usuário solicitante, reduzindo drasticamente as viagens de ida e volta (round trips) para a origem.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
resource "aws_cloudfront_distribution" "enterprise_edge" {
origin {
domain_name = aws_lb.core_alb.dns_name
origin_id = "CoreBackendOrigin"

custom_origin_config {
http_port = 80
https_port = 443
origin_protocol_policy = "https-only"
origin_ssl_protocols = ["TLSv1.2"]
}
}

enabled = true

default_cache_behavior {
allowed_methods = ["GET", "HEAD", "OPTIONS"]
cached_methods = ["GET", "HEAD"]
target_origin_id = "CoreBackendOrigin"

forwarded_values {
query_string = true
headers = ["X-User-Segment"]
cookies {
forward = "whitelist"
whitelisted_names = ["SessionToken"]
}
}

viewer_protocol_policy = "redirect-to-https"
min_ttl = 0
default_ttl = 3600
max_ttl = 86400
}

restrictions {
geo_restriction {
restriction_type = "none"
}
}

viewer_certificate {
cloudfront_default_certificate = true
}
}
Como injetamos lógica computacional dinâmica para avaliar o perfil do usuário e alterar a requisição em pleno voo sem forçar o pacote a abandonar o continente de origem do cliente?

Interceptação de Tráfego via Lambda@Edge

Injetamos a lógica descentralizada associando uma função AWS Lambda@Edge aos gatilhos (triggers) de interceptação do CloudFront. O CloudFront expõe quatro ganchos no ciclo de vida da requisição: Viewer Request, Origin Request, Origin Response e Viewer Response. Optamos arquiteturalmente por interceptar o fluxo no Viewer Request. Esta decisão é crítica. Ao executar a função Python no exato milissegundo em que o pacote atinge o Ponto de Presença mais próximo do usuário, o código pode extrair o cookie de sessão do pacote HTTP, decodificar a identidade e injetar o cabeçalho X-User-Segment antes que o CloudFront avalie a existência do objeto no cache local. Se o objeto já existir em cache para aquele segmento específico, o CloudFront devolve o payload instantaneamente. A função não consome capacidade computacional da origem. Esta mecânica implementa testes A/B ou personalização global sem impactar a latência, pois a alteração do estado da requisição ocorre puramente na borda.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
resource "aws_iam_role" "edge_lambda_role" {
name = "EdgePersonalizationRole"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Action = "sts:AssumeRole"
Effect = "Allow"
Principal = {
Service = ["lambda.amazonaws.com", "edgelambda.amazonaws.com"]
}
}]
})
}

resource "aws_lambda_function" "viewer_request_interceptor" {
provider = aws.us_east_1 # Lambda@Edge exige implantação estrita em us-east-1
filename = "edge_payload.zip"
function_name = "EdgeSegmentRouter"
role = aws_iam_role.edge_lambda_role.arn
handler = "lambda_function.lambda_handler"
runtime = "python3.12"
publish = true
}

# A associação ocorre dentro do bloco default_cache_behavior no CloudFront
# lambda_function_association {
# event_type = "viewer-request"
# lambda_arn = aws_lambda_function.viewer_request_interceptor.qualified_arn
# include_body = false
# }
Se a função de borda necessitar consultar um mapeamento complexo de segmentos de usuários ou regras de negócios que sofrem mutações constantes, como ela acessa esses dados stateful sem realizar chamadas de rede lentas para o banco de dados primário centralizado?

Estado Geograficamente Distribuído com DynamoDB Global Tables

Provêmos o acesso ao estado distribuindo os dados de negócio fisicamente para todas as regiões críticas através do Amazon DynamoDB Global Tables. O padrão Lambda@Edge executa a função na região AWS mais próxima do cliente. Se um usuário em Tóquio acessar a aplicação, a função executará em ap-northeast-1. Para manter a latência de execução abaixo do limite estrito de 5 segundos exigido pelo gatilho Viewer Request, o adaptador Python dentro da função não deve invocar um banco de dados em us-east-1. O código identifica a região atual de execução através da variável de ambiente AWS_REGION e inicializa o cliente boto3 para consultar a réplica do DynamoDB local. A replicação assíncrona gerida pela AWS garante que a tabela no Japão contenha as preferências do usuário atualizadas com consistência eventual. O código decodifica o token, recupera o segmento de negócio do DynamoDB local em poucos milissegundos e modifica a requisição HTTP.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
import os
import urllib.parse
from typing import Dict, Any
import boto3
from botocore.config import Config

# Identifica a região atual onde o Ponto de Presença invocou a função
current_region = os.environ.get('AWS_REGION', 'us-east-1')

# Configura o cliente para atingir estritamente a réplica local do DynamoDB
boto_config = Config(region_name=current_region, retries={'max_attempts': 1})
dynamodb = boto3.resource('dynamodb', config=boto_config)
table = dynamodb.Table('EnterpriseUserSegments')

def extract_session_token(headers: Dict[str, Any]) -> str:
cookie_header = headers.get('cookie')
if not cookie_header:
return ""

for cookie in cookie_header[0]['value'].split(';'):
cookie = cookie.strip()
if cookie.startswith("SessionToken="):
return urllib.parse.unquote(cookie[len("SessionToken="):])
return ""

def lambda_handler(event: Dict[str, Any], context: Any) -> Dict[str, Any]:
request = event['Records'][0]['cf']['request']
headers = request['headers']

token = extract_session_token(headers)
segment = "anonymous"

if token:
try:
# Consulta de latência ultra-baixa na réplica geográfica local
response = table.get_item(Key={'SessionToken': token})
if 'Item' in response:
segment = response['Item'].get('SegmentId', 'default')
except Exception as e:
# Falha tolerante na borda: retorna ao segmento anônimo sem quebrar a requisição
print(f"Falha ao consultar DynamoDB na região {current_region}: {str(e)}")
pass

# Injeta o cabeçalho determinístico para manipular o CloudFront Cache Key
headers['x-user-segment'] = [{'key': 'X-User-Segment', 'value': segment}]

# O CloudFront agora avaliará o cache baseado neste novo cabeçalho
return request

Solução de Problemas Comuns

A implementação de recursos Lambda@Edge gera severa confusão operacional durante a depuração de falhas devido à topologia de registro distribuída. Quando uma função de borda lança uma exceção, os logs não são gravados no Amazon CloudWatch da região primária de implantação (us-east-1). A AWS despeja os fluxos de log no CloudWatch Logs da exata região onde o Ponto de Presença executou a função. Se os clientes europeus relatarem erros 503, o engenheiro deve alterar o escopo do console da AWS para eu-central-1 ou eu-west-1 para localizar os grupos de log /aws/lambda/us-east-1.EdgeSegmentRouter. A automação desse rastreamento exige ferramentas de observabilidade globais que agreguem métricas de múltiplas regiões.
Outro bloqueio de implantação ocorre através do erro InvalidLambdaFunctionAssociation. A infraestrutura do CloudFront proíbe terminantemente a associação de funções Lambda que possuam variáveis de ambiente configuradas via console se o gatilho selecionado for Viewer Request ou Viewer Response. A restrição arquitetônica existe para garantir a replicação global hiper-rápida do pacote de código. Para fornecer dados de configuração dinâmicos a uma função restrita, os engenheiros devem embutir um arquivo JSON no pacote de implantação (Deployment Package) ou consultar rapidamente o AWS Systems Manager Parameter Store replicado na região de execução.

Conclusão

A delegação da lógica de negócios e da avaliação de perfil para a arquitetura Lambda@Edge combinada ao Amazon CloudFront transforma a física da entrega de aplicações corporativas. Ao isolar a tomada de decisão no perímetro geográfico da rede, a arquitetura preserva taxas massivas de retenção de cache sem sacrificar a hiper-personalização exigida pelos usuários. Operações que antes sufocavam as origens centrais são diluídas em centenas de pontos operacionais. A expansão evolutiva deste padrão direciona as equipes de segurança a integrar a proteção estática na borda instanciando o AWS WAF diretamente no CloudFront, bloqueando varreduras de vulnerabilidade e ataques de injeção na camada mais externa da infraestrutura antes de qualquer alocação computacional interna.

Referências

Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (2016). Site reliability engineering: How Google runs production systems. O'Reilly Media.
Amazon Web Services. (2023). Customizing at the edge with Lambda@Edge. AWS Architecture Center. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-at-the-edge.html 
MacCarthaigh, C. (2022). Building well-architected serverless applications. AWS re:Invent Publications.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article