O Cloud CDN é a plataforma de rede de fornecimento de conteúdo de aceleração Web do Google Cloud, que ajuda a armazenar em cache o conteúdo estático acessado regularmente mais próximo dos usuários. O Cloud CDN é otimizado para exibir uma combinação de recursos da Web estáticos e dinâmicos sensíveis à latência, como CSS, JavaScript, HTML e arquivos de imagem.
O Media CDN é a plataforma de CDN de entrega de mídia do Google Cloud que complementa o Cloud CDN. O Media CDN é otimizado para cargas de trabalho de saída de alta capacidade, como streaming de vídeo e downloads de arquivos grandes.
Usar o Cloud CDN e o Media CDN pode melhorar o desempenho dos usuários, reduzir o uso de recursos da infraestrutura de origem e reduzir os custos de entrega de rede.
Os dois produtos oferecem um conjunto semelhante de recursos, mas cada um deles é otimizado para determinados casos de uso. Comparar o Cloud CDN com o Media CDN é semelhante a comparar o Cloud SQL com o BigQuery. O Cloud CDN e o Cloud SQL são destinados a pequenas consultas em escala. O Media CDN e o BigQuery foram projetados para ter capacidade de processamento e escala extrema. Usar o Media CDN para disponibilização de JavaScript ou CSS (cargas de trabalho da Web) é semelhante a tentar usar o BigQuery para tabelas de 5 GB com algumas milhares de linhas. Ele funciona, mas não é otimizado para esse caso de uso.
Casos de uso
A tabela a seguir descreve alguns casos de uso comuns e o produto de CDN recomendado.
| Caso de uso | Produto de CDN recomendado |
|---|---|
| Disponibilizar cargas de trabalho com conteúdo da Web e mídia padrão, como sites de mídias sociais. | É possível ter duas configurações neste cenário:
|
| Oferecer um site rapidamente aos usuários. | O Cloud CDN é a escolha certa para cargas de trabalho que tendem a exibir objetos muito pequenos em taxas altas, como plataformas de adtech e e-commerce. A força dele é veicular conteúdo da Web estático, como JavaScript, CSS, fontes e imagens inline. |
| Disponibilizar downloads grandes de software. | Se você espera uma grande demanda de downloads de software, considere usar o Media CDN. Se os downloads de software forem uma pequena fração da sua carga de trabalho geral da Web, considere o Cloud CDN. |
| Fornecer vídeo por streaming usando HLS e DASH. | Se você tem necessidades de streaming de vídeo em grande escala, o Media CDN é a escolha certa devido à melhoria da blindagem de origem, capacidade em Tbps e geração de registros e métricas detalhadas. |
| Atender às necessidades de compliance para a exibição de downloads de firmware, por exemplo, para órgãos governamentais ou prestadores de cuidados de saúde. |
O Cloud CDN é a escolha certa. O Cloud CDN tem a autorização do Programa Federal de Gerenciamento de Risco e Autorização (FedRAMP, na sigla em inglês) (FedRAMP, na sigla em inglês) e está em uma posição ideal para atender a fortes necessidades de compliance. A menos que você use solicitações assinadas, o conteúdo armazenado em um cache de CDN normalmente é acessível publicamente por URL. Como acontece com qualquer CDN, considere usar seus próprios esquemas de criptografia ou gerenciamento de direitos digitais (DRM) quando necessário. |
| Exibir conteúdo de imagens geradas pelos usuários. | O Cloud CDN é a escolha certa para a maioria das plataformas de exibição de imagens. |
Exceções
A tabela a seguir descreve casos de uso para os quais o Cloud CDN ou o Media CDN não são adequados.
| Caso de uso | Sugestão |
|---|---|
| Enviar vídeo por protocolo de mensagens em tempo real (RTMP, na sigla em inglês). | O CDN de mídia e o Cloud CDN não são compatíveis com a entrega baseada em RTMP para clientes. Configure um balanceador de carga de rede de passagem externo global para fornecer RTMP se você tiver algum serviço legado baseado em RTMP. Você também pode usar a API Live Stream para empacotar streams de origem RTMP em recursos HLS/DASH para envio por meio do Media CDN. |
| Fornecer vídeo de usuário para usuário por WebRTC. |
O Media CDN e o Cloud CDN não são compatíveis com a entrega por WebRTC. É possível configurar um balanceador de carga de rede de passagem externa regional para gerenciar serviços baseados em WebRTC. |
| Usar WebSockets para a comunicação entre servidor e usuário. | Configurar um balanceador de carga de aplicativo externo global. O tráfego do WebSocket não é armazenável em cache e se beneficia da estrutura global que conecta os locais do Google, em que o balanceador de carga de aplicativo externo é executado, aos back-ends. |
| Disponibilizar cargas de trabalho confidenciais, como dados de saúde ou dados específicos do usuário. | Não use o Cloud CDN ou o Media CDN para veicular cargas de trabalho sensíveis ou dados específicos do usuário. |
Começar a usar um produto de CDN
Para começar a trabalhar com um produto de CDN, consulte as seguintes páginas:
Recursos de CDN compatíveis
As tabelas a seguir resumem os recursos disponíveis no Cloud CDN e no Media CDN.
Suporte de origem e de back-end
| Recurso | Cloud CDN | Media CDN |
|---|---|---|
| Buckets do Cloud Storage, incluindo armazenamento multirregional redundante | ✓ | ✓ |
| Instâncias de máquina virtual (VM) do Compute Engine | ✓ | ✓ |
| Instâncias de contêiner do Google Kubernetes Engine (GKE) | ✓ | ✓ |
| Back-ends externos (origens personalizadas): no local, várias nuvens | ✓info | ✓ |
| Serviços do App Engine, do Cloud Run functions ou do Cloud Run | ✓ | ✓ |
| Failover de origem | ✓info | |
| Tempo limite configurável | ✓info | ✓info |
Armazenamento em cache
| Recurso | Cloud CDN | Media CDN |
|---|---|---|
| Solicitar o recolhimento (agrupamento) | ✓info | ✓info |
| Proteção de origem | ✓info | |
| Chaves de cache personalizadas | ✓info | ✓info |
| Substituições de armazenamento em cache configuráveis | ✓info | ✓info |
| Invalidação de cache programático | ✓info | ✓info |
| Invalidação de cache programático por tags de cache | ✓info | |
Diretivas Cache-Control padrão |
✓info | ✓info |
| TTLs configuráveis | ✓info | ✓info |
| Armazenamento em cache negativo | ✓info | ✓info |
| Validação de conteúdo assíncrono | ✓info | |
| Ignorar o cache | ✓info | ✓info |
| Políticas de cache por origem | ✓info | ✓info |
| Políticas de cache por rota | ✓info |
Correspondência de rota e seleção de origem
| Recurso | Cloud CDN | Media CDN |
|---|---|---|
| Seleção de back-end baseada em host e em caminho | ✓info | ✓info |
| Redirecionamentos de URL | ✓info | ✓info |
| Regravações de URL | ✓info | ✓info |
| Correspondência de cabeçalho e parâmetro de consulta | ✓info | ✓info |
| Correspondência de padrão (caractere curinga) | ✓info | ✓info |
| Injeção de cabeçalho dinâmico: localização do cliente, status do cache, versão do TLS | ✓info | ✓info |
| Políticas de compartilhamento de recursos entre origens (CORS) integradas | ✓info |
Protocolos compatíveis
| Recurso | Cloud CDN | Media CDN |
|---|---|---|
| Anycast global: IPv4 e IPv6 | ✓ | ✓ |
| HTTP/3 baseado no IETF QUIC | ✓ | ✓ |
| HTTP/2 | ✓ | ✓ |
| HTTP/1.1 | ✓ | ✓ |
| TLS 1.3 | ✓ | ✓ |
| TLS 1.2 | ✓ | ✓ |
| Compatibilidade com TLS 1.0 e 1.1 para dispositivos legados | ✓ |
Geração de registros e monitoramento
| Recurso | Cloud CDN | Media CDN |
|---|---|---|
| Registros de solicitação detalhados | ✓info | ✓info |
| Entrega de registros quase em tempo real | ✓ | ✓info |
| Relatórios de taxa de ocorrência em cache | ✓ | ✓ |
| Métricas de solicitação e resposta | ✓ | ✓ |
| Exportar para o Cloud Storage, BigQuery ou ferramentas externas | ✓ | ✓ |
| Alertas para produtos com suporte | ✓ | ✓ |
Automation e APIs
| Recurso | Cloud CDN | Media CDN |
|---|---|---|
| APIs REST | ✓info | ✓info |
| Console do Google Cloud | ✓ | ✓ |
| Google Cloud CLI | ✓info | ✓info |
| Compatibilidade com o Terraform | ✓info | ✓info |
Segurança
| Recurso | Cloud CDN | Media CDN |
|---|---|---|
| Certificados SSL (TLS) gerenciados | ✓ | ✓info |
| Certificados SSL (TLS) gerenciados, sem custo adicional | ✓info | |
| Certificados SSL Bring-your-own (TLS), sem custo adicional | ✓info | |
| Políticas de SSL personalizáveis: versões, criptografias | ✓info | ✓info |
| Criptografia em repouso | ✓ | ✓ |
| Registro de auditoria | ✓info | ✓info |
| Suporte do Google Cloud Armor | ✓info | ✓info |
| Identity and Access Management | ✓info | ✓info |
Extensibilidade
| Recurso | Cloud CDN | Media CDN |
|---|---|---|
| Código personalizado usando plug-ins de extensões de serviço | ✓informações (Visualização) |
Autenticação de conteúdo
| Recurso | Cloud CDN | Media CDN |
|---|---|---|
| URLs assinados | ✓info | ✓info |
| Cookies assinados | ✓info | ✓info |
| Tokens assinados | ✓info | |
| Autenticação de dois tokens | ✓info | |
| Autenticação de origem particular | ✓info | ✓info |
| Suporte para atributos de cabeçalho e IP em solicitações assinadas | ✓info | |
| Suporte a HMAC-SHA1 em solicitações assinadas | ✓ | ✓ |
| Suporte para Ed25519 e HMAC-SHA-256 em solicitações assinadas | ✓ |
Compliance
| Padrão de conformidade | Cloud CDN | Media CDN |
|---|---|---|
| HIPAA | ✓ | |
| PCI-DSS | ✓ | ✓ |
| SOC1, SOC2, SOC3 | ✓ | ✓ |
| ISO 27001, ISO 27017, ISO 27018, ISO 27701 | ✓ | ✓ |
| FedRAMP de nível médio | ✓ |
Transição entre os dois produtos
Se você já tem uma implantação de várias CDNs com direcionamento e troca de produtos de CDN, é possível fazer a transição entre elas usando DNS ou configurar uma delas como uma CDN adicional.
As políticas de servidor do Cloud DNS podem ser uma opção para rotear o tráfego entre CDNs ou fazer a transição de uma CDN para outra.
Usar uma estratégia com várias CDNs
Para otimizar o desempenho e reduzir custos, use o Cloud CDN e o CDN de mídia entre si ou com outras CDNs implementando estratégias de implantação com várias CDNs.
As estratégias de várias CDNs, em que seu conteúdo é hospedado com mais de um provedor de CDN, podem ajudar você a otimizar os serviços de CDN por região e recursos de CDN oferecidos por diferentes provedores. Eles também podem ser úteis se você hospedar eventos de alto tráfego e precisar distribuir o tráfego para vários provedores. No caso de falhas temporárias com um provedor, é possível transferir rapidamente o tráfego para outro provedor de CDN.
Uma implantação de CDN com uma CDN primária e uma CDN secundária é um exemplo de uma estratégia de implantação de várias CDNs. A CDN primária exibe a maior parte do tráfego, e a secundária mostra uma minoria. Se houver problemas com a CDN principal, os usuários poderão direcionar o tráfego para a CDN secundária como uma estratégia de failover e não precisarão esperar o período normal para o cache se tornar frequente enquanto já estão veiculando conteúdo.
Para começar, roteie o tráfego para cada CDN ou divida uma parte do tráfego para uma nova CDN usando políticas de servidor DNS ou serviços de redirecionamento de tráfego semelhantes.