CDN (Content Delivery Network - CloudFront, Akamai)

Uma CDN é uma rede distribuída de pontos de presença espalhados pelo mundo que armazenam conteúdo em cache próximo ao usuário, reduzindo latência, absorvendo picos de tráfego e descarregando a origem. A relevância em produção vai além do download de arquivos estáticos: CDNs modernas terminam TLS na borda, aplicam regras de segurança, comprimem respostas, aceleram APIs dinâmicas e servem de escudo contra ataques volumétricos de DDoS, tornando-se a primeira camada real da arquitetura de entrega. Para usuários distantes da origem, a diferença entre acesso à borda e acesso direto à origem é percebida em toda transação, e para o negócio a CDN muda a curva de custo, porque entrega a maioria das respostas com infraestrutura barata e otimizada. CloudFront, da AWS, e Akamai, o pioneiro e maior player do mercado, representam duas abordagens: integração profunda com o ecossistema de nuvem contra rede global proprietária com serviços de otimização e segurança de ponta. Dominar cache key, TTL e invalidação é o núcleo técnico do tema, porque é neles que se concentram os erros que anular o benefício da CDN.

Conceito e problema que resolvem

O problema físico é a velocidade da luz em fibra: cada ida e volta entre o usuário e a origem acumula latência de rede, e distâncias continentais somam dezenas a centenas de milissegundos por requisição. Uma página carrega dezenas de objetos, e cada um herda esse custo quando a origem é única e central. A CDN resolve ao posicionar caches em centenas de edge locations, e o objeto solicitado, se já está em cache na borda, é entregue com latência local, independentemente de onde a origem esteja.

O problema de escala é a origem dimensionada para o pico: sem CDN, todo pico de tráfego chega à infraestrutura própria, e dimensionar para o pico é caro. Com CDN, a maior parte do tráfego é absorvida na borda, e a origem vê só o que precisa, o que reduz custo de saída de dados da nuvem, porque o tráfego de saída da CDN tem preço menor que o de saída direta.

O problema de disponibilidade e segurança é a exposição da origem: a CDN pode esconder a origem atrás da borda, absorver ataques volumétricos de DDoS na camada de rede e na camada de aplicação, e aplicar WAF em escala global. O ataque que derrubaria a aplicação atinge a borda, que foi projetada para suportar o tráfego de milhões de clientes simultâneos.

Edge locations e cache geográfico

A rede de borda é organizada em pontos de presença, com diferentes profundidades de cache conforme o produto. O CloudFront distribui edge locations e regional edge caches: a borda regional é um cache de nível intermediário que serve as edges de uma região, e o conteúdo popular fica mais próximo do usuário, enquanto o menos popular ainda é servido do cache regional, evitando a viagem à origem. A Akamai opera uma rede maior em número de pontos e profundidade de distribuição, com hierarquias internas de cache ajustadas por tipo de conteúdo, o que é um dos seus diferenciais históricos.

O fluxo de um cache miss é transparente para o usuário: a borda sem o objeto consulta o cache regional, que consulta a origem, e a resposta volta preenchendo todos os níveis. O objeto passa a ser servido localmente nas requisições seguintes, e a origem não vê a segunda requisição. Esse comportamento de preenchimento em cascata é o que transforma a CDN em proteção de origem real sob pico, desde que o conteúdo seja cacheável e o TTL coerente.

A distribuição geográfica também é instrumento de negócio: a mesma URL entrega conteúdo diferente por região, por preço, por idioma e por exigência legal de residência de dados, e as CDNs expõem isso por header de região, por CNAME configurado por país e por regras de comportamento na borda.

Cache key, TTL e invalidação

O cache key é a definição de identidade do objeto na borda: é a combinação de parâmetros que determina se duas requisições são o mesmo objeto. A chave mínima é método, host e path, e cada componente adicional, query string, header, cookie, expande a chave e fragmenta o cache. O erro clássico é incluir header de usuário autenticado na chave: cada usuário gera sua própria cópia do objeto, a taxa de hit despenca, e a CDN vira um proxy caro que não cacheia nada.

O TTL define o tempo de vida do objeto em cache, e o desenho correto é em camadas de mutabilidade: estático com hash no nome do arquivo leva TTL de um ano; HTML e JSON de página levam TTL curto, de segundos a minutos; APIs dinâmicas de resposta individual não devem ser cacheadas, mas ainda podem ser aceleradas na rota. Os headers da origem, Cache-Control e Expires, orientam a CDN, e a distribuição pode sobrescrever com comportamento próprio por path.

A invalidação é a operação de remover objeto do cache antes do TTL, e tem custo e latência de propagação: no CloudFront, as invalidações por path são cobradas acima da cota mensal e levam minutos; na Akamai, a limpeza é rápida e de amplo alcance. A alternativa arquitetural superior à invalidação é o versionamento: publicar o novo conteúdo com novo nome ou nova chave e trocar a referência, o que nunca exige invalidar nada.

Configuração prática no CloudFront

A unidade de configuração do CloudFront é a distribuição, composta por origens e comportamentos, e o comportamento é onde a política de cache, a chave e o TTL se materializam por path. O exemplo abaixo mostra o desenho típico de uma aplicação que separa estáticos com hash, HTML dinâmico e APIs.

# Distribuicao CloudFront declarada em CloudFormation (trecho conceitual)
DistributionAplicacao:
  Type: AWS::CloudFront::Distribution
  Properties:
    DistributionConfig:
      Enabled: true
      Comment: "Distribuicao de aplicacao web com API e estaticos"
      DefaultRootObject: index.html
      # Origens: bucket de estaticos e ALB da aplicacao
      Origins:
        - Id: origem-estaticos
          DomainName: !GetAtt BucketEstaticos.RegionalDomainName
          S3OriginConfig:
            OriginAccessIdentity: !Sub "origin-access-identity/cloudfront/${OaiEstaticos}"
        - Id: origem-api
          DomainName: !GetAtt AlbAplicacao.DNSName
          CustomOriginConfig:
            OriginProtocolPolicy: https-only       # origem so aceita TLS
      DefaultCacheBehavior:
        TargetOriginId: origem-estaticos
        ViewerProtocolPolicy: redirect-to-https   # forca HTTPS na borda
        Compress: true                             # gzip e Brotli automaticos
        # Politica de cache gerenciada: otimizada para estaticos com hash
        CachePolicyId: 4135ea2d-6df8-44a3-9df3-4b5a84be39ad
      CacheBehaviors:
        # HTML: cache curto na borda, origem decide revalidacao
        - PathPattern: "*.html"
          TargetOriginId: origem-api
          ViewerProtocolPolicy: redirect-to-https
          CachePolicyId: 4135ea2d-6df8-44a3-9df3-4b5a84be39ad
        # API: nada cacheado, apenas aceleracao e TLS no edge
        - PathPattern: "/api/*"
          TargetOriginId: origem-api
          ViewerProtocolPolicy: https-only
          CachePolicyId: 4135ea2d-6df8-44a3-9df3-4b5a84be39ad
      ViewerCertificate:
        AcmCertificateArn: !Ref CertificadoBorda
        SslSupportMethod: sni-only
      Logging:
        Bucket: !GetAtt BucketLogs.DomainName
        IncludeCookies: false

A política de cache gerenciada referenciada controla o que entra na chave, e a regra de ouro é revisar a política de cada comportamento antes de publicar, porque o valor default pode incluir query strings que fragmentam o cache. O logging com cookies desligados reduz volume e custo, e o header X-Cache na resposta conta hit e miss para monitoração direta.

Aceleração de conteúdo dinâmico

Conteúdo que não pode ser cacheado ainda se beneficia da CDN, e essa é a parte menos compreendida do tema. A borda termina a conexão do usuário próximo a ele, mantém conexões persistentes pré-estabelecidas com a origem e evita o custo do handshake TCP e TLS em rede lenta, o que reduz o tempo total mesmo com a resposta sendo gerada na hora. Protocolos modernos, HTTP/2 e HTTP/3 com QUIC, negociados na borda, recuperam perdas de pacote com menos bloqueio de fila e melhoram a experiência em redes móveis.

A rota interna da CDN entre borda e origem é otimizada pela rede troncal do provedor, e não pelo caminho público da internet: roteamento dinâmico, pré-estabelecimento de conexão e agregação de pacotes reduzem a variância de latência, e é nessa otimização que a Akamai historicamente se diferencia, com aceleração dedicada para APIs e transações. Em arquiteturas serverless, a presença da borda também distribui a terminação TLS, e funções na borda, como Lambda@Edge e CloudFront Functions, executam lógica leve de manipulação de header e roteamento sem tocar a origem.

A compressão é parte integral dessa camada: Brotli oferece razão de compressão maior que gzip em HTML, CSS e JavaScript, tipicamente 15 a 20% menor no tamanho final, e a negociação acontece na borda, que aceita o encoding do cliente e descompacta ou recompacta o conteúdo da origem conforme necessário. A regra prática é comprimir texto com Brotli na borda, deixar imagens e vídeos já comprimidos fora da compressão HTTP e servir formatos modernos de imagem pelo próprio pipeline da CDN.

TLS no edge e proteção contra DDoS

A terminação de TLS na borda é o padrão de produção: o certificado fica na CDN, a renovação é automática, a sessão com o usuário usa a versão mais recente do protocolo, e a conexão até a origem pode ser recriptografada com certificado próprio. O requisito de conformidade com TLS fim a fim é atendido com TLS entre CDN e origem, e a origem só aceita tráfego da distribuição, via header assinado ou ACL de rede.

A proteção contra DDoS é integrada e é um dos maiores ganhos operacionais: ataques volumétricos de camada de rede são absorvidos pela capacidade global da rede, e ataques de camada de aplicação são filtrados por rate limiting, WAF e bot management na borda. O CloudFront integra com AWS Shield Standard sem custo adicional e Shield Advanced para proteção avançada com resposta a incidentes, e a Akamai entrega conjunto equivalente com seu portfólio de segurança, que inclui proteção DDoS, WAF e gerenciamento de bots como serviços maduros da mesma rede.

A ocultação da origem completa a defesa: a origem aceita tráfego apenas da CDN por security group ou ACL, e o endereço real deixa de ser exposto em registros DNS públicos, eliminando o caminho de contornar a borda. Sem essa medida, a proteção da CDN é parcial, porque o atacante pode mirar a origem diretamente.

Observabilidade e custo

A métrica central de uma CDN é a taxa de acerto, e ela é calculada por classe de conteúdo, não no agregado: um hit ratio alto esconde o fato de que as APIs, que são o conteúdo caro, podem estar todas em miss. Os logs de acesso da borda registram cada requisição com resultado de cache, região da borda, tempo de resposta e tamanho, e esse volume de log é a matéria-prima para otimização de chave e de TTL, além de alimentar o rate limiting inteligente.

O custo tem dois componentes dominantes: transferência de dados de saída e requisições, e ambos caem quando a taxa de acerto sobe, porque o objeto servido da borda custa menos que o mesmo objeto vindo da origem mais a entrega. O ponto de atenção de FinOps é o tráfego que a CDN não deveria servir: objetos grandes e únicos, como backups e exports, geram custo alto com taxa de acerto nula, e precisam ser excluídos da distribuição.

A latência percebida se mede com RUM, dados reais de usuário coletados no navegador, e não apenas com sondas sintéticas: sondas medem a borda, e o RUM mede a experiência distribuída, incluindo redes móveis e provedores regionais ruins. A comparação entre RUM antes e depois da CDN é a evidência objetiva do ganho, e é o argumento que sustenta a continuidade do investimento na camada.

CloudFront versus Akamai

A escolha prática se apoia no contexto: arquitetura AWS com time pequeno e ciclo de IaC forte favorece CloudFront, pela integração e pela ausência de contrato; requisitos de segurança de enterprise global, aplicações multi-nuvem e otimização de rede extrema favorecem a Akamai, pelo serviço e pela rede. Ambos resolvem o problema básico com competência, e a diferença aparece nos extremos de escala, no contrato e na maturidade do time de plataforma.

Erros comuns e boas práticas

• Chave de cache com header de sessão: fragmenta o cache e anula a CDN; declare explicitamente o que entra na chave.
• Invalidar como rotina de deploy: custo alto e propagação lenta; versione o conteúdo e troque referências no deploy.
• Cache-Control conflitante entre origem e CDN: a distribuição sobrescreve o header e o time da aplicação não sabe; centralize a política em um lugar.
• Origem exposta publicamente: atacante contorna a CDN; restrinja a origem à distribuição e esconda o DNS real.
• Ignorar headers de resposta da CDN: X-Cache e timing na borda contam se a requisição foi hit ou miss; monitore taxa de hit como métrica de produção.
• Comprimir o que já está comprimido: imagens e vídeos não ganham com gzip ou Brotli e gastam CPU; configure por tipo de conteúdo.
• TTL de um ano sem hash no nome: usuário preso em versão velha; hash no nome de arquivo e TTL longo andam sempre juntos.

A boa prática consolidada é tratar a distribuição da CDN como componente versionado e testado: comportamentos por path declarados em IaC, política de cache central, métrica de hit ratio em painel, testes de purga documentados e revisão periódica da chave de cache. A CDN é a camada onde custo, latência e segurança se encontram, e a decisão mal tomada lá propaga efeito para toda a experiência do usuário.