CloudFront para aplicações de comércio eletrônico e marketplace
Uma aplicação de comércio eletrônico ou marketplace disponibiliza três tipos distintos de conteúdo por meio de uma única distribuição do CloudFront: ativos estáticos (imagens de produtos, CSS e JavaScript), páginas dinâmicas (listas de produtos e resultados de pesquisa) e respostas de API (carrinho, inventário e preços). Cada tipo de conteúdo exige configurações diferentes de comportamento de cache, TTL e origem para equilibrar a atualização do conteúdo e o desempenho.
Consulte os controles de segurança que se aplicam às distribuições de marketplace e comércio eletrônico em Lista de verificação de segurança para distribuições de marketplace.
Visão geral da arquitetura
Uma distribuição do CloudFront para um marketplace usa vários comportamentos de cache para rotear solicitações à origem correta com base em padrões de caminho de URL. Os ativos estáticos são disponibilizados pelo Amazon Simple Storage Service (Amazon S3), enquanto o conteúdo dinâmico e as solicitações de API são encaminhados para um Elastic Load Balancing (Application Load Balancer) localizado na frente dos servidores de aplicações. Um cluster do ElastiCache (Valkey) fornece um cache no nível da aplicação entre o ALB e o banco de dados para dados de produtos acessados com frequência.
| Componente | Conteúdo disponibilizado | Finalidade |
|---|---|---|
Distribuição do CloudFront |
Todos os conteúdos (domínio único) |
Armazenamento em cache global na borda, terminação de TLS e roteamento de solicitações usando comportamentos de cache |
Origem do Amazon S3 (ativos estáticos) |
Imagens de produtos, CSS, JS e fontes |
Armazenamento durável de objetos com controle de acesso à origem (OAC). Conteúdo imutável com TTLs longos. |
Origem do ALB (conteúdo dinâmico) |
Páginas de produtos, pesquisa e endpoints de API |
Roteia para os servidores de aplicações. TTLs curtos ou nenhum cache para conteúdo personalizado. |
Cluster do ElastiCache (Valkey) |
Catálogo de produtos, contagens de inventário e dados de sessão |
Cache no nível da aplicação entre o ALB e o banco de dados. Leituras em menos de um milissegundo para dados acessados com frequência. |
Comportamentos de cache para comércio eletrônico
Os comportamentos de cache determinam como o CloudFront processa as solicitações com base em padrões de caminho de URL. Para um marketplace, configure comportamentos separados para cada tipo de conteúdo, com as políticas de cache e os TTLs apropriados.
| Padrão de caminho | Origem | TTL | Política de cache | Lógica |
|---|---|---|---|---|
|
Amazon S3 |
365 dias |
CachingOptimized |
Nomes de arquivos com versão (por exemplo, |
|
Amazon S3 |
30 dias |
CachingOptimized |
As imagens de produtos são alteradas com pouca frequência. Use a invalidação por tag de cache quando um vendedor atualizar uma imagem. Use um TTL menor do que o dos ativos estáticos, pois os URLs das imagens podem ser reutilizados. |
|
ALB |
60 segundos |
Personalizado (incluir strings de consulta) |
As APIs de listagem e pesquisa de produtos mudam com frequência, mas toleram conteúdo desatualizado por um curto período. Inclua os parâmetros da string de consulta na chave de cache para paginação e filtros. |
|
ALB |
0 (sem cache) |
CachingDisabled |
As operações do carrinho são específicas de cada usuário e devem sempre chegar à origem. Desative completamente o cache. |
|
ALB |
5 segundos |
Personalizado (incluir strings de consulta) |
As contagens de inventário mudam rapidamente durante eventos de vendas. Um TTL muito curto ajuda a evitar vendas acima do estoque disponível, ao mesmo tempo que reduz a carga na origem. |
|
ALB |
0 (sem cache) |
CachingDisabled |
O comportamento padrão encaminha solicitações não armazenadas em cache para a aplicação para renderização do lado do servidor. As páginas que incluem conteúdo personalizado (recomendações e nome do usuário) não devem ser armazenadas em cache na borda. |
nota
Ordene os comportamentos de cache do mais específico para o menos específico. O CloudFront avalia os padrões de caminho na ordem em que são listados e usa a primeira correspondência. Coloque /api/cart/* antes de /api/* para garantir que as solicitações do carrinho ignorem o armazenamento em cache.
Para obter mais informações sobre os comportamentos de cache, consulte Configurações de comportamento de cache.
Estratégia de TTL para conteúdo de marketplace
A configuração de TTL determina por quanto tempo o CloudFront disponibiliza conteúdo armazenado em cache antes de verificar se há atualizações na origem. As aplicações de comércio eletrônico exigem diferentes estratégias de TTL, dependendo de como a atualização do conteúdo afeta a experiência do cliente.
- Ativos imutáveis (CSS, JS e fontes)
-
Defina o TTL máximo (365 dias). Use nomes de arquivos com hash de conteúdo para que cada implantação crie URLs. Nunca faça invalidações: as versões antigas expiram naturalmente à medida que os usuários carregam os novos nomes de arquivos. Defina
Cache-Control: public, max-age=31536000, immutablena origem. - Imagens de produtos
-
Defina o TTL como 30 dias com invalidação por tag de cache quando houver uma atualização. Quando um vendedor carregar uma nova imagem, invalide usando a tag de cache do produto, em vez do caminho. Isso direciona a invalidação somente aos objetos afetados, sem usar uma invalidação ampla com curingas. Defina
Cache-Control: public, max-age=2592000na origem. - API de catálogo de produtos
-
Defina o TTL como 60 segundos. Listas, descrições e preços de produtos toleram conteúdo desatualizado por um curto período. Isso reduz a carga na origem durante picos de tráfego (vendas relâmpago e lançamentos de produtos), mantendo os dados razoavelmente atualizados. Defina
Cache-Control: public, max-age=60, stale-while-revalidate=30para disponibilizar conteúdo desatualizado enquanto o CloudFront busca uma resposta atualizada em segundo plano. - API de inventário e preços
-
Defina o TTL como 5 segundos. Esses valores mudam com frequência e afetam as decisões de compra. Mesmo um período de cache muito curto reduz significativamente a carga na origem durante picos de tráfego: milhares de usuários simultâneos recebem a mesma resposta armazenada em cache por 5 segundos, em vez de cada um acessar a origem.
- Conteúdo específico do usuário (carrinho e recomendações)
-
Desative o cache (TTL = 0). O conteúdo que varia de acordo com o usuário deve sempre chegar à origem. Se você armazenar conteúdo específico do usuário em cache por engano, o CloudFront poderá disponibilizar os dados de um usuário para outro. Use a política gerenciada
CachingDisabledpara esses comportamentos.
Configuração da origem
Origem do Amazon S3 para ativos estáticos
Use um bucket do Amazon S3 como origem para imagens de produtos e ativos estáticos. Configure o controle de acesso à origem (OAC) para restringir o acesso direto ao bucket: todas as solicitações devem passar pelo CloudFront.
| Configuração | Valor | Lógica |
|---|---|---|
Domínio de origem |
|
Use o endpoint da API REST do Amazon S3 (e não o endpoint do site) para oferecer suporte ao OAC. |
Acesso à origem |
Controle de acesso à origem (OAC) |
Restringe o acesso ao bucket somente ao CloudFront. Impede o acesso direto aos ativos por meio de URLs do S3. |
Origin Shield |
Habilitado (na região mais próxima do bucket) |
Adiciona uma camada de cache centralizada entre os locais da borda e a origem. Reduz os custos de solicitações ao S3 e melhora a taxa de acertos do cache para imagens. |
Tentativas de conexão |
3 |
Padrão. Tenta novamente em caso de erros transitórios do S3. |
Origem do ALB para conteúdo dinâmico
Use um Application Load Balancer como origem para páginas dinâmicas de produtos, pesquisas e endpoints de API. O ALB roteia para os servidores de aplicações (instâncias do Amazon EC2, tarefas do Amazon ECS ou funções do Lambda usando grupos de destino).
| Configuração | Valor | Lógica |
|---|---|---|
Domínio de origem |
Nome DNS do ALB |
Use diretamente o nome DNS do ALB. Não use um endereço IP: os IPs do ALB mudam. |
Protocolo |
HTTPS Only (Somente HTTPS) |
Criptografa o tráfego entre o CloudFront e a origem. Obrigatório para dados sensíveis (sessões de usuários e informações de pagamento). |
Cabeçalho personalizado da origem |
|
Restringe o acesso ao ALB a solicitações provenientes do CloudFront. O ALB verifica esse cabeçalho e rejeita tentativas de acesso direto. |
Tempo limite da conexão |
10 segundos |
Menor que o padrão (30 segundos). Antecipe-se às falhas causadas por problemas na origem, em vez de manter as conexões de borda aguardando. |
Tempo limite de resposta |
30 segundos |
Permite tempo para consultas de pesquisa complexas e operações de catálogo. Aumente-o se a API tiver operações de longa duração. |
Tempo limite de keep-alive |
5 segundos |
Reutiliza conexões com o ALB. Reduz a sobrecarga do handshake TLS para solicitações subsequentes. |
Cache no nível da aplicação com o ElastiCache (Valkey)
O CloudFront armazena conteúdo em cache na borda, mas os dados acessados com frequência que exigem consultas ao banco de dados se beneficiam de um cache adicional no nível da aplicação. Um cluster do ElastiCache executando o Valkey fica entre os servidores de aplicações e o banco de dados, fornecendo leituras em menos de um milissegundo para dados do catálogo de produtos, contagens de inventário e estado da sessão.
| Camada | O que armazena em cache | TTL | Comportamento em caso de ausência no cache |
|---|---|---|---|
Borda do CloudFront |
Respostas HTTP completas (JSON de API, páginas HTML e imagens) |
5 segundos a 365 dias (por comportamento) |
Encaminha a solicitação para a origem do ALB |
ElastiCache (Valkey) |
Objetos de dados da aplicação (registros de produtos, inventário e sessões) |
30 segundos a 5 minutos (por tipo de dado) |
A aplicação consulta o banco de dados e grava o resultado no cache |
Em uma solicitação de página de produto:
O CloudFront verifica o cache na borda. Em caso de acerto, retorna imediatamente a resposta armazenada em cache.
Em caso de ausência, o CloudFront encaminha a solicitação ao ALB.
A aplicação verifica o ElastiCache em busca dos dados do produto. Em caso de acerto, cria a resposta com base nos dados armazenados em cache (em menos de um milissegundo).
Em caso de ausência no ElastiCache, consulta o banco de dados, grava o resultado no ElastiCache e retorna a resposta.
O CloudFront armazena a resposta em cache na borda de acordo com a configuração de TTL do comportamento.
Quando um vendedor atualiza um produto:
A aplicação invalida a chave do produto no ElastiCache.
A aplicação envia uma invalidação por tag de cache ao CloudFront para a tag do produto.
A próxima solicitação aciona uma resposta atualizada por meio das duas camadas de cache.
Perguntas frequentes
As seções a seguir respondem a perguntas comuns sobre estratégias de cache para workloads de comércio eletrônico e marketplace.
Como lidar com conteúdo personalizado usando cache?
Separe os elementos personalizados do conteúdo que pode ser armazenado em cache. Disponibilize o shell da página (detalhes do produto, imagens e descrições) pelo cache do CloudFront e carregue os elementos personalizados (recomendações, contagem de itens no carrinho e nome do usuário) usando chamadas de API no lado do cliente que ignoram o cache. Com essa abordagem, você pode armazenar em cache a renderização dispendiosa da página e manter a personalização atualizada.
Como escolher entre invalidação e TTLs curtos?
Use TTLs curtos (5 a 60 segundos) para conteúdo que muda com frequência e de maneira previsível (inventário e preços). Use a invalidação para conteúdo que muda raramente, mas precisa ser atualizado imediatamente quando isso acontece (imagens de produtos após uma edição do vendedor e descrições de produtos após uma revisão de conformidade). A invalidação tem um custo por solicitação e um limite de simultaneidade; não a utilize como substituta de TTLs apropriados.
Como me preparar para vendas relâmpago e picos de tráfego?
O CloudFront é escalado automaticamente para lidar com picos de tráfego. Para maximizar a taxa de acertos do cache durante uma promoção: pré-aqueça as páginas de produtos solicitando-as antes do início do evento, aumente temporariamente os TTLs das APIs (por exemplo, aumente o TTL do inventário de 5 s para 15 s) para absorver mais tráfego na borda e verifique se o cluster do ElastiCache tem capacidade de memória suficiente para acomodar um aumento nas gravações no cache. Monitore a métrica de taxa de acertos do cache do CloudFront durante o evento.
Devo usar o Origin Shield para meu marketplace?
Sim. O Origin Shield adiciona uma camada de cache centralizada entre os caches de borda regionais e sua origem. Para workloads de comércio eletrônico, ele reduz as solicitações à origem para produtos populares (pois um acerto no cache do Origin Shield atende a todos os locais da borda), reduz os custos de GET do S3 para imagens e suaviza os picos de tráfego para o ALB. Habilite-o na região mais próxima da sua origem. Para obter mais informações, consulte Usar o Amazon CloudFront Origin Shield.