Perguntas frequentes sobre o Amazon CloudFront

O Amazon CloudFront é um serviço Web que oferece às empresas e aos desenvolvedores de aplicações Web uma maneira fácil e de baixo custo de distribuir conteúdo com baixa latência e altas velocidades de transferência de dados. Como outros serviços da AWS, o Amazon CloudFront é uma oferta de autosserviço, cobrada pelo uso, sem a exigência de compromissos a longo prazo ou taxas mínimas. Com o CloudFront, seus arquivos são entregues aos usuários finais usando uma rede global de locais da borda.

O Amazon CloudFront fornece uma API simples, permitindo que você:

• Distribua conteúdo com alta velocidade de transferência de dados e baixa latência, ao atender às solicitações usando uma rede de pontos de presença ao redor do mundo.
• Comece a utilizar o serviço sem negociar contratos e gastos mínimos.

Clique no botão “Criar conta gratuita” na página de detalhes do Amazon CloudFront. Caso opte por usar outro serviço da AWS como a origem dos arquivos fornecidos por meio do Amazon CloudFront, você deve se cadastrar para esse serviço antes de criar distribuições do CloudFront.

É fácil utilizar o Amazon CloudFront:

• Para arquivos estáticos, armazene as versões definitivas de seus arquivos em um ou mais servidores de origem. Esses podem ser buckets do Amazon S3. Para seu conteúdo gerado dinamicamente, que seja personalizado, você poderá usar o Amazon EC2 – ou qualquer outro servidor web – como o servidor de origem. Esses servidores de origem armazenarão ou gerarão seu conteúdo, que será distribuído através do Amazon CloudFront.
• Registre seus servidores de origem com o Amazon CloudFront com uma simples chamada API. Essa chamada retornará um nome de domínio CloudFront.net que você pode usar para distribuir o conteúdo de seus servidores de origem pelo serviço Amazon CloudFront. Por exemplo, você pode registrar o bucket do Amazon S3 “bucketname.s3.amazonaws.com” como a origem de todo seu conteúdo estático e uma instância do Amazon EC2 “dynamic.myoriginserver.com” para todo seu conteúdo dinâmico. Em seguida, usando a API ou Console de Gerenciamento da AWS, você poderá criar uma distribuição do Amazon CloudFront, que poderá retornar “abc123.cloudfront.net” como o nome de domínio de distribuição.
• Inclua o nome de domínio cloudfront.net ou um alias CNAME que você criar, em seu aplicativo web, media player ou site. Cada solicitação feita usando o nome de domínio cloudfront.net (ou o CNAME que você configurar) é roteada para o ponto de presença mais adequado para distribuir o conteúdo com a mais alta performance. O ponto de presença tentará atender à solicitação com uma cópia local do arquivo. Se uma cópia local não estiver disponível, o Amazon CloudFront obterá uma cópia a partir da origem. Esta cópia estará disponível nesse local da borda para futuras solicitações.

O Amazon CloudFront usa uma rede global de locais da borda e pontos e caches de borda regionais que armazenam em cache cópias de conteúdo perto dos visualizadores. O Amazon CloudFront garante que as solicitações de usuários finais serão atendidas pelo ponto de presença mais próximo. Como resultado, as solicitações dos visualizadores percorrem uma pequena distância, o que aumenta a performance para eles. Para arquivos não armazenados em cache nos pontos de presença e nos pontos de presença de caches regionais, o Amazon CloudFront mantém conexões persistentes com os servidores de origem para que esses arquivos possam ser recuperados dos servidores de origem o mais rapidamente possível. Por fim, o Amazon CloudFront usa otimizações adicionais como, por exemplo, uma janela mais ampla de congestionamento inicial de TCP, para fornecer performance superior na entrega de conteúdo aos visualizadores.

Como outros serviços da AWS, o Amazon CloudFront não exige taxas mínimas e cobra apenas pelo que você utilizar. Em relação à auto-hospedagem, o Amazon CloudFront o poupa da despesa e da complexidade de operar uma rede de servidores de cache em vários sites na Internet e elimina a necessidade de aumentar o provisionamento da capacidade para atender a potenciais repiques no tráfego. O Amazon CloudFront também usa técnicas como recolher solicitações simultâneas de visualizador em um ponto de presença, para o mesmo arquivo, em uma única solicitação para seu servidor de origem. Isso reduz a carga nos servidores de origem e a necessidade de escalar a infraestrutura de origem, o que pode gerar ainda mais economias.

Além disso, se você estiver usando uma origem da AWS (p. ex., Amazon S3, Amazon EC2 etc.), desde 1.º de dezembro de 2014 que deixamos de cobrar pela transferência de dados da AWS para o Amazon CloudFront. Isso se aplica à transferência de dados de todas as regiões da AWS para todos os locais da borda globais do CloudFront.

O Amazon CloudFront usa cabeçalhos de controle de cache padrão que você define em seus arquivos para identificar conteúdo estático e dinâmico. O fornecimento de todo o seu conteúdo usando uma única distribuição do Amazon CloudFront ajuda você a garantir que otimizações de performance sejam aplicadas a todo o seu site ou aplicativo web. Ao usar as origens da AWS, você se beneficia de melhor performance, confiabilidade e facilidade de uso como resultado da capacidade da AWS de controlar e ajustar rotas de origem, monitorar a integridade do sistema, responder rapidamente quando quaisquer problemas ocorrerem e a integração do Amazon CloudFront com outros serviços da AWS. Você também pode se beneficiar do uso de diferentes origens para diferentes tipos de conteúdo em um único site, p. ex., Amazon S3 para objetos estáticos, Amazon EC2 para conteúdo dinâmico e origens personalizadas para conteúdo de terceiros, pagando somente pelo que você usar.

O Amazon CloudFront é uma boa escolha para distribuição de conteúdo estático frequentemente acessado que se beneficia da entrega em bordas, como imagens, vídeos, arquivos de mídia ou downloads de software de sites populares.

O Amazon CloudFront permite que você tire proveito rapidamente da entrega de conteúdo de alta performance sem contratos negociados ou preços elevados. O Amazon CloudFront disponibiliza a todos os desenvolvedores preços acessíveis e definição de preço de pagamento conforme o uso, com um modelo de autosserviço. Os desenvolvedores também se beneficiam de uma total integração com outros serviços da Amazon Web Services. A solução é simples de usar com o Amazon S3, Amazon EC2 e Elastic Load Balancing como servidores de origem, oferecendo aos desenvolvedores uma poderosa combinação de armazenamento resiliente e entrega de alta performance. O Amazon CloudFront também se integra ao Amazon Route 53 e ao AWS CloudFormation para oferecer ainda mais benefícios de performance e facilidade de configuração.

O Amazon CloudFront é compatível com conteúdo que possa ser enviado usando os protocolos HTTP ou WebSocket. Isso inclui páginas dinâmicas da web e aplicações, como páginas HTML ou PHP, ou aplicações baseadas em WebSocket, além de quaisquer arquivos estáticos populares que façam parte de sua aplicação Web, como imagens de site, arquivos de áudio, vídeo, mídia ou downloads de software. O Amazon CloudFront também aceita a entrega de streaming de mídia ao vivo ou sob demanda por HTTP.

Sim. O Amazon CloudFront funciona com qualquer servidor de origem que tenha as versões originais e definitivas de seu conteúdo, seja estático ou dinâmico. Não há despesas adicionais para o uso de uma origem personalizada.

Para cada origem que você adiciona a uma distribuição do CloudFront, é possível atribuir uma origem de backup que poderá ser usada para atender automaticamente ao seu tráfego se a origem principal não estiver disponível. Você pode escolher uma combinação de códigos de status HTTP 4xx/5xx que, quando retornados da origem principal, acionam o failover para a origem do backup. As duas origens podem ser qualquer combinação de origens da AWS e não da AWS.

Sim. O SLA do Amazon CloudFront disponibiliza um serviço de crédito se a porcentagem mensal de tempo de atividade do cliente ficar abaixo de nosso compromisso de serviço em qualquer ciclo de faturamento. Você pode obter mais informações aqui.

Sim. Você pode utilizar o Console de Gerenciamento da AWS para configurar e gerenciar o Amazon CloudFront através de uma interface baseada na web do tipo apontar-e-clicar. O Console de Gerenciamento da AWS é compatível com a maioria dos recursos do Amazon CloudFront, permitindo que você obtenha a distribuição de baixa latência do Amazon CloudFront sem gravar nenhum código ou instalar nenhum software. O acesso ao Console de Gerenciamento da AWS é disponibilizado gratuitamente em https://console.aws.amazon.com.

Há uma variedade de ferramentas para gerenciar sua distribuição e suas bibliotecas do Amazon CloudFront para várias linguagens de programação disponíveis em nosso centro de recursos.

Sim. Você pode apontar seu ápex da zona (exemplo.com) para sua distribuição do Amazon CloudFront de duas maneiras.

Usando o Amazon Route 53, o serviço de DNS oficial da AWS, você pode configurar um registro de ALIAS que permite mapear o apex ou a raiz (examplo.com) do seu nome DNS para sua distribuição do Amazon CloudFront. Então, o Amazon Route 53 responderá a cada solicitação de um registro de ALIAS com os endereços IP corretos para sua distribuição do CloudFront. O Route 53 não cobra consultas aos registros de ALIAS mapeados para uma distribuição do CloudFront.

Como alternativa, com os IPs estáticos Anycast do CloudFront, você pode direcionar seu domínio apex para sua distribuição do CloudFront usando qualquer provedor de DNS. Basta criar registros A padrão usando os três endereços IP estáticos fornecidos pelo CloudFront. Esse recurso estende o suporte ao domínio apex além do Route 53, enquanto seu tráfego ainda é automaticamente direcionado para os locais da borda mais próximos para entrega de conteúdo de alta performance no mundo todo.

O CloudFront distribui o conteúdo por meio de uma rede global de data centers denominados locais da borda. Os pontos de presença de caches regionais estão localizados entre o servidor web de origem e os pontos de presença globais que enviam conteúdo diretamente aos visualizadores. Isso ajuda a aumentar a performance para os visualizadores e, ao mesmo tempo, reduzir a sobrecarga operacional e o custo da escalabilidade dos recursos da origem.

O Amazon CloudFront tem vários caches de borda regionais (ou RECs) globalmente dispersos, proporcionando uma camada adicional de armazenamento em cache perto dos seus usuários finais. Eles ficam entre o servidor Web de origem e os locais da borda da AWS que enviam o conteúdo diretamente para seus usuários. À medida que os objetos em cache se tornam menos populares, locais da borda individuais podem remover esses objetos para liberar espaço para conteúdo mais solicitado. Os caches de borda regionais têm um cache com uma maior largura do que qualquer local da borda individual. Portanto, os objetos permanecem no cache por mais tempo. Isso ajuda a manter mais conteúdo perto dos visualizadores, reduzindo a necessidade de acesso ao servidor Web original pelo CloudFront e aumentando a performance geral para os visualizadores. Por exemplo, os locais da borda do CloudFront na Europa atualmente acessam o cache de borda regional em Frankfurt para recuperar um objeto antes de acessar o servidor Web de origem. Os locais do cache de borda regional podem ser usados com qualquer origem, como S3, EC2 ou origens personalizadas. Os RECs são ignorados em regiões que, atualmente, hospedam as origens das suas aplicações.

Sim. Não é preciso fazer nenhuma mudança nas distribuições do CloudFront. Esse recurso é habilitado por padrão em todas as distribuições novas e já existentes do CloudFront. Não há cobranças adicionais por esse recurso.

O Amazon CloudFront utiliza uma rede global de locais da borda e caches de borda regionais para entregar conteúdo. Veja uma lista completa dos locais do Amazon CloudFront aqui.

Sim, o recurso Restrição de Geo permite que você especifique uma lista de países em que os usuários podem acessar seu conteúdo. Como alternativa, você pode especificar os países em que os usuários não podem acessar seu conteúdo. Em ambos os casos, o CloudFront responde a uma solicitação de um usuário em um país restrito com um código de status HTTP 403 (Proibido).

A precisão do endereço IP para o banco de dados de pesquisa do país varia por região. Com base em testes recentes, nossa precisão geral do endereço IP para mapeamento de país é de 99,8%.

Sim, você pode criar mensagens de erro personalizadas (por exemplo, um arquivo HTML ou uma imagem .jpg) com sua própria marca e conteúdo para uma variedade de respostas a erro HTTP 4xx e 5xx. Em seguida, você pode configurar o Amazon CloudFront para retornar suas mensagens de erro personalizadas para o espectador quando sua origem retornar um dos erros especificados para o CloudFront.

Por padrão, se nenhum cabeçalho de controle de cache estiver definido, cada local da borda verificará se há uma versão atualizada do seu arquivo sempre que receber uma solicitação de mais de 24 horas após a última vez que a origem foi verificada por alterações nesse arquivo. Isso é chamado do “período de expiração”. Você pode definir este período de expiração tão curto quanto 0 segundos, ou pelo tempo que você desejar, definindo os cabeçalhos de controle de cache em seus arquivos na sua origem. O Amazon CloudFront usa esses cabeçalhos de controle de cache para determinar a frequência com que ele precisa verificar a origem de uma versão atualizada desse arquivo. Para o período de expiração definido como 0 segundo, o Amazon CloudFront revalidará a solicitação com o servidor de origem. Se seus arquivos não mudam muito frequentemente, é recomendável definir um período de expiração longo e implementar um sistema de versionamento para gerenciar atualizações para seus arquivos.

Existem várias opções para remover um arquivo de locais da borda. Você pode simplesmente excluir o arquivo de sua origem e assim que o conteúdo em pontos de presença atingir seu período de expiração definido no cabeçalho HTTP de cada objeto, ele será removido. Caso algum material ofensivo ou potencialmente prejudicial necessite ser removido antes do período de expiração especificado, você pode usar a API de anulação para remover o objeto de todos os pontos de presença do Amazon CloudFront. Você pode verificar a cobrança para fazer solicitações de invalidação aqui.

Se você anular objetos individualmente, poderá ter solicitações de anulação para até 3 mil objetos por distribuição em andamento por vez. Isso significa uma solicitação de anulação para até 3.000 objetos, até 3.000 solicitações com um objeto por solicitação ou qualquer outra combinação que não exceda o total de 3.000 objetos.

Se você usar o curinga *, pode ter solicitações de até 15 caminhos de anulação em andamento por vez. Você também pode ter solicitações de anulação para até 3.000 objetos individuais por distribuição em progresso por vez. O limite de solicitações de anulação com curinga independe do limite de anulação individual de objetos. Se você exceder esse limite, as soluções de anulação subsequentes receberão uma resposta de erro até que uma das solicitações anteriores seja concluída.

Você deve usar a anulação apenas em circunstâncias inesperadas. Se você souber antecipadamente que seus arquivos precisarão ser removidos do cache com frequência, recomendamos que implemente um sistema de versionamento para seus arquivos e defina um período de expiração mais curto.

Os pontos de presença (POPs) incorporados do CloudFront são um tipo de infraestrutura do CloudFront implantada mais perto dos visualizadores finais, em redes de provedores de serviços de Internet (ISP) e operadoras de rede móvel (MNO). Os POPs incorporados são personalizados para oferecer eventos streaming ao vivo, vídeo sob demanda (VOD) e downloads de jogos em grande escala. Esses POPs incorporados são de propriedade e operados pela Amazon e implantados na última milha das redes ISP/MNO para evitar gargalos de capacidade em redes congestionadas que conectam os visualizadores finais às fontes de conteúdo, melhorando a performance.

Os POPs incorporados do CloudFront diferem dos POPs do CloudFront com base no local em que são implantados e no conteúdo que fornecem. Os POPs incorporados do CloudFront são implantados diretamente nas redes ISP e MNO, diferentemente dos POPs do CloudFront que são implantados na rede da AWS. Os POPs incorporados são criados especificamente para fornecer tráfego armazenável em cache em grande escala, como streams de vídeo e downloads de jogos, enquanto os POPs do CloudFront são projetados para fornecer uma variedade de workloads, incluindo conteúdo dinâmico e armazenável em cache.

Os POPs incorporados do CloudFront são projetados para fornecer conteúdo armazenável em cache que é acessado por muitos espectadores finais simultaneamente, como streaming de vídeo ao vivo em grande escala, vídeo sob demanda e downloads de jogos.

Não, não há cobrança adicional pelo uso dos POPs incorporados do CloudFront.

Os POPs incorporados são um recurso opcional destinado à entrega de tráfego armazenável em cache em grande escala. Entre em contato com seu representante de vendas da AWS para avaliar se os POPs incorporados são adequados para suas workloads.

Não, você não precisa criar uma nova distribuição especificamente para POPs incorporados. Se sua workload for elegível, o CloudFront habilitará POPs incorporados para sua distribuição existente mediante solicitação.

Você não precisa escolher entre POPs incorporados do CloudFront ou os POPs do CloudFront para entrega de conteúdo. Depois que sua distribuição do CloudFront estiver habilitada para POPs incorporados, o sistema de roteamento do CloudFront utilizará dinamicamente os POPs do CloudFront e os POPs incorporados para fornecer conteúdo, garantindo a performance ideal para os usuários finais.

Entre em contato conosco para começar a implantar POPs incorporados na rede.

Você pode usar o portal POP incorporado para gerenciar POPs incorporados implantados em sua rede. O portal POP incorporado é integrado ao AWS Interconnect Portal e fornece uma interface unificada para autoatendimento fácil de uma variedade de tarefas associadas a todo o ciclo de vida desses POPs. Isso inclui solicitar novos dispositivos, acompanhar o andamento da solicitação, monitorar estatísticas de performance e solicitar suporte. Você pode acessar o portal com autenticação única (SSO) usando sua conta PeeringDB.

O Amazon CloudFront [com exceção da entrega de conteúdo via POPs incorporados do CloudFront] está incluído no conjunto de serviços em conformidade com o Payment Card Industry Data Security Standard (PCI DSS) no nível Merchant Level 1, o mais alto grau de conformidade para provedores de serviços. Consulte o nosso guia do desenvolvedor para obter mais informações.

A AWS expandiu seu programa de conformidade com a HIPAA para incluir o Amazon CloudFront [com exceção da entrega de conteúdo via POPs incorporados do CloudFront] como um serviço elegível para a HIPAA. Se você assinou um Acordo de Associado Comercial (BAA) com a AWS, poderá usar o Amazon CloudFront [com exceção da entrega de conteúdo via POPs incorporados do CloudFront] para acelerar a entrega de informações de saúde protegidas (PHI). Para obter mais informações, consulte sobre a conformidade com a HIPAA e nosso guia do desenvolvedor.

O Amazon CloudFront [com exceção da entrega de conteúdo via POPs incorporados do CloudFront] está em conformidade com as medidas de SOC (System & Organization Control). Os relatórios de SOC são relatórios de exames terceirizados e independentes que demonstram como a AWS satisfaz os principais controles e objetivos de conformidade. Para obter mais informações, consulte sobre a conformidade da AWS com o SOC e o guia do desenvolvedor.

Os relatórios SOC 1 e SOC 2 da AWS estão disponíveis para os clientes por meio do AWS Artifact, um portal de autoatendimento para acesso sob demanda a relatórios de conformidade da AWS. Faça login no AWS Artifact no Console de Gerenciamento da AWS ou saiba mais em Conceitos básicos do AWS Artifact. O relatório SOC 3 da AWS mais recente está disponível publicamente no site da AWS.

O Amazon CloudFront atualmente tem suporte para solicitações GET, HEAD, POST, PUT, PATCH, DELETE e OPTIONS.

O Amazon CloudFront não armazena em cache respostas para solicitações POST, PUT, DELETE e PATCH. Essas solicitações são representadas de volta pelo proxy para o servidor de origem. É possível habilitar o armazenamento em cache para as respostas às solicitações OPTIONS.

Se você tiver uma distribuição atual do Amazon CloudFront, poderá ativar o HTTP/2 usando a API ou o Console de Gerenciamento. No Console, acesse a página “Distribution Configuration” e navegue até a seção “Supported HTTP Versions”. Lá, você pode selecionar a opção “HTTP/2, HTTP/1.1, or HTTP/1.0”. O HTTP/2 é habilitado automaticamente para todas as novas distribuições do CloudFront.

No momento, o Amazon CloudFront é compatível com o HTTP/2 para a entrega de conteúdo aos clientes e navegadores dos seus visualizadores. Para realizar a comunicação entre o local da borda e seus servidores de origem, o Amazon CloudFront continuará usando o HTTP/1.1.

Não no momento. No entanto, a maioria dos navegadores atuais só é compatível com o HTTP/2 por meio de uma conexão criptografada. Você pode saber mais sobre o uso do SSL com o Amazon CloudFront aqui.

HTTP/3 é a terceira principal versão do Hypertext Transfer Protocol (Protocolo de transferência de hipertexto). O HTTP/3 usa o QUIC, um protocolo de transporte seguro baseado no User Datagram Protocol (UDP – Protocolo de datagrama do usuário) e multiplexado em streams, que combina e aprimora os recursos do Transmission Control Protocol (TCP – Protocolo de controle de transmissão), TLS e HTTP/2. O HTTP/3 oferece diversos benefícios em relação às versões anteriores de HTTP, como tempos de resposta mais rápidos e melhor segurança.

O HTTP/3 conta com a tecnologia QUIC, um novo protocolo de transporte de internet seguro, resiliente e com alta performance. O suporte do CloudFront ao HTTP/3 é baseado no s2n-quic, uma nova implementação do protocolo QUIC de código aberto no Rust. Para saber mais sobre o QUIC, consulte o blog “Introducing s2n-quic”. 

Os clientes estão sempre procurando maneiras de fornecer aplicações mais rápidas e seguras aos usuários. Com a crescente disseminação global da Internet e o maior número de usuários online em dispositivos móveis e redes remotas, a necessidade de maior performance e confiabilidade é maior do que nunca. O HTTP/3 proporciona isso, com vários aprimoramentos de performance em relação às versões anteriores do HTTP:

1. Conexões mais rápidas e confiáveis: o CloudFront usa o 1-RTT para o handshake TLS no HTTP/3, reduzindo o tempo para o estabelecimento da conexão e uma redução correspondente nas falhas do handshake em comparação às versões anteriores do HTTP.
2. Melhor performance na Web: a implementação do HTTP/3 do CloudFront é compatível com as migrações da conexão do lado do cliente, permitindo que as aplicações do cliente se recuperem de conexões fracas com o mínimo de interrupção. Ao contrário do TCP, o QUIC não é uma estrutura sem perdas, tornando-o mais adequado às redes congestionadas com alta perda de pacotes. Além disso, o QUIC permite conexões mais rápidas durante as transferências de tarefas via celular ou Wi-Fi.
3. Segurança: o HTTP/3 oferece segurança mais abrangente comparada às versões anteriores do HTTP, com a criptografia de pacotes transferidos durante os handshakes do TLS. Isso dificulta a inspeção por middleboxes, proporcionando mais privacidade e reduzindo ataques do tipo man-in-the-middle. O suporte do CloudFront ao HTTP/3 é baseado no s2n-quic e no Rust, ambos com forte ênfase na eficiência e performance.
    

Ative o HTTP/3 para distribuições novas e existentes do Amazon CloudFront usando o console do CloudFront, a ação da API UpdateDistribution ou o modelo Cloudformation. No Console, acesse a página “Distribution Configuration” (Configurações de distribuição) e navegue até a seção “Supported HTTP Versions” (Versões com suporte a HTTP). Lá, você poderá selecionar a opção “HTTP/3, HTTP/2, HTTP/1.1 ou HTTP/1.0”.

Ao habilitar o HTTP/3 na sua distribuição do CloudFront, ele adicionará automaticamente o cabeçalho Alt-Svc, que é usado para anunciar que o suporte ao HTTP/3 está disponível. Não será necessário adicionar o cabeçalho Alt-Svc manualmente. Esperamos que você habilite o suporte para vários protocolos em suas aplicações, de modo que se a aplicação não conseguir estabelecer uma conexão HTTP/3, ela tentará a HTTP /1.1 ou HTTP/2. Por exemplo, os clientes sem suporte ao HTTP/3 poderão se comunicar com as distribuições do CloudFront ativadas pelo HTTP/3, usando o HTTP/1.1 ou HTTP/2. O suporte alternativo é uma parte obrigatória da especificação do HTTP/3 e é implementado por todos os principais navegadores com suporte ao HTTP/3.

O CloudFront atualmente tem suporte ao HTTP/3 para a comunicação entre os clientes/navegadores dos seus visualizadores e os locais da borda do CloudFront. Para realizar a comunicação entre o local da borda e seus servidores de origem, o CloudFront continuará usando o HTTP/1.1.

O HTTP/3 usa o QUIC, que exige o TLSv1.3. Portanto, independentemente das política de segurança que você tenha selecionado, somente o TLSv1.3 e os pacotes de criptografia TLSv1.3 com suporte podem ser usados para estabelecer conexões HTTP/3. Para obter mais detalhes, consulte os protocolos compatíveis e as criptografias entre visualizadores e a seção do CloudFront no guia do desenvolvedor.

Não. Nenhuma cobrança separada para habilitar o HTTP/3 nas distribuições do Amazon CloudFront será feita. As solicitações do HTTP/3 serão cobradas de acordo com as tarifas de preços, seguindo seu plano de preços.

O Gerente de SaaS do CloudFront é um novo recurso do Amazon CloudFront que ajuda provedores de plataformas de desenvolvimento na Web e software como serviço (SaaS) a gerenciar com eficiência a entrega de conteúdo em vários sites. O Gerente de SaaS do CloudFront simplifica a forma como as organizações entregam e protegem aplicações multilocatárias, em grande escala. Ao introduzir configurações e parâmetros reutilizáveis, o Gerente de SaaS do CloudFront reduz a sobrecarga operacional. Ele elimina o trabalho de configuração redundante e permite que os clientes mantenham configurações consistentes em seus sites. Além disso, o Gerente de SaaS do CloudFront oferece a flexibilidade opcional de personalizar as configurações de segurança e automatizar as renovações de certificados para cada site, quando necessário.

O Gerente de SaaS do CloudFront foi projetado para organizações que enfrentam o desafio de gerenciar vários sites com eficiência. Os provedores de plataformas de software como serviço (SaaS) e de desenvolvimento na Web acharão isso particularmente valioso, pois permite que eles mantenham configurações consistentes nos sites de seus locatários. Da mesma forma, as empresas que gerenciam vários sites corporativos podem usá-lo para padronizar sua presença na Web, preservando a flexibilidade de personalizar sites individuais. Se você tiver apenas alguns sites ou se cada site contiver configurações diferentes do CloudFront, a distribuição de locatário único (tradicional) provavelmente será mais adequada.

O CloudFront está disponível como uma opção por meio do Console e das APIs da AWS para clientes que desejam gerenciar configurações compartilhadas em grupos de domínios. Veja como começar: 1/Defina as configurações compartilhadas: crie uma distribuição multilocatária que contenha configurações compartilhadas que funcionarão como modelo para grupos de domínios. 2/Crie locatários de distribuição: crie locatários de distribuição que permitam associar os domínios e seus certificados TLS a uma distribuição multilocatária. 3/Controle de ajuste fino: opcionalmente, personalize as configurações para locatários de distribuição aplicando substituições.

Uma distribuição multilocatária define a configuração básica que será compartilhada entre os domínios. Ela contém configurações compartilhadas, como configurações de origem, comportamentos de cache e configurações de segurança. Diferentemente de uma distribuição padrão, uma distribuição multilocatária não pode fornecer tráfego diretamente. Ela oferece campos personalizáveis e parametrizados para atender às necessidades exclusivas de cada domínio. Por exemplo: caminhos de origem específicos do domínio ou nomes de domínio de origem.

Um locatário de distribuição representa um domínio específico usando uma distribuição multilocatária. Ele herda a configuração básica da distribuição multilocatária e deve ter pelo menos um domínio ou subdomínio com um certificado TLS válido.
Cada locatário de distribuição pode incluir as seguintes personalizações:

• Caminhos de origem exclusivos e nomes de domínio de origem (definidos por meio de valores de parâmetros na distribuição multilocatária)
• Certificados TLS personalizados
• Substituições de Web ACL
• Substituições de restrição geográfica
  

Sim. No entanto, o CloudFront trabalha com o AWS Certificate Manager (ACM) para fornecer uma experiência perfeita de validação do controle de domínio. A integração com o ACM elimina a carga da emissão e do gerenciamento de certificados e fornece gerenciamento automatizado do ciclo de vida de seus certificados SSL/TLS emitidos pela Amazon. Se você usa outra CA para emitir certificados, o ACM oferece suporte a certificados emitidos por CAs terceiras. Nesses casos, você será responsável pelo ciclo de vida do certificado (upload inicial, renovação e carregamento subsequente) e o ACM fornecerá notificações ao proprietário da conta da AWS à medida que os certificados se aproximarem da expiração via CloudWatch e e-mail. Para obter mais detalhes, você pode acessar https://aws.amazon.com/certificate-manager/faqs/.

Sim, o CloudFront permite suporte para domínios apex ou raiz (p. ex., exemplo.com versus www.exemplo.com). Os clientes podem usar o Route 53 para gerenciar o DNS e adicionar um registro ALIAS para seu domínio apex para apontar para um domínio fornecido pelo CloudFront. Para clientes que não podem usar o Route53 para gerenciar domínios personalizados, os IPs estáticos do Anycast podem fornecer um conjunto dedicado de endereços IP que podem ser usados no lugar dos registros CNAME/ALIAS. Saiba mais aqui.

Sim. O CloudFront cobra com base no número de recursos do locatário de distribuição que você cria. Os locatários de distribuição são novos recursos que herdam as definições de configuração de uma distribuição multilocatária do CloudFront. Consulte a página de preços do CloudFront para obter detalhes.

O WebSocket é um protocolo de comunicação em tempo real que disponibiliza comunicação bidirecional entre um cliente e um servidor por meio de uma conexão TCP de longa execução. Utilizando uma conexão aberta persistente, o cliente e o servidor podem trocar dados em tempo real sem que o cliente precise reiniciar as conexões frequentemente para verificar se há novos dados a serem trocados. As conexões WebSocket são frequentemente usadas em aplicações de chat, plataformas de colaboração, jogos multijogador e plataformas de transações financeiras. Consulte a nossa documentação para saber mais sobre o uso do protocolo WebSocket com o Amazon CloudFront. 

Você pode usar WebSockets globalmente. Nenhuma outra configuração é necessária para habilitar o protocolo WebSocket no seu recurso do CloudFront, pois agora a compatibilidade é padrão.

O Amazon CloudFront estabelece conexões WebSocket somente quando o cliente inclui o cabeçalho “Upgrade: websocket” e o servidor responde com o código de status HTTP 101 confirmando que ele pode alternar para o protocolo WebSocket.

Sim. O Amazon CloudFront é compatível com conexões WebSocket criptografadas (WSS) usando o protocolo SSL/TLS.

O gRPC é uma estrutura moderna de chamada de procedimento remoto (RPC) de código aberto que permite a comunicação bidirecional entre um cliente e um servidor por meio de uma conexão HTTP/2 de longa duração. Ao usar uma conexão aberta persistente, o cliente e o servidor podem enviar dados em tempo real um para o outro sem que o cliente precise reiniciar as conexões com frequência para verificar a troca de novos dados. O gRPC é adequado para casos de uso em que baixa latência e altas velocidades de transferência são cruciais, como aplicações de comunicação em tempo real e jogos on-line.

O gRPC é habilitado em cada comportamento de cache nas distribuições do CloudFront. Habilitar o gRPC garantirá que tanto o HTTP/2 quanto o suporte para solicitações POST também estejam habilitados na distribuição. O gRPC só é compatível com o método POST em HTTP/2.

O Amazon CloudFront se comunica por gRPC quando as seguintes condições são atendidas:

1. O HTTP/2 está habilitado na sua distribuição
2. As solicitações POST e o gRPC estão habilitados em um comportamento de cache
3. Um cliente envia um cabeçalho “content-type” com o valor de “application/grpc” por meio de uma conexão HTTP/2

1. Segurança: o gRPC usa HTTP/2, garantindo que o tráfego seja criptografado de ponta a ponta do cliente aos servidores de origem. Além disso, ao usar o gRPC, você obtém o AWS Shield Básico sem custo adicional, e o AWS WAF pode ser configurado para ajudar a proteger o tráfego do gRPC contra ataques.
2. Melhor performance: o gRPC utiliza um formato de mensagem binária, chamado buffers de protocolo, que são menores do que as cargas úteis tradicionais, como o JSON usado com APIs RESTful. A análise de buffers de protocolo consome menos CPU porque os dados estão em formato binário, o que significa que as mensagens são trocadas mais rapidamente. Isso resulta em uma melhor performance geral.
3. Suporte a streaming integrado: o streaming é uma parte incorporada da estrutura gRPC, compatível com a semântica de streaming do lado do cliente e do lado do servidor. Isso simplifica muito a criação de serviços ou clientes de streaming. O gRPC no CloudFront é compatível com as seguintes combinações de streaming:
   • Unário (sem streaming)
   • Streaming de cliente para servidor
   • Streaming de servidor para cliente
   • Streaming bidirecional

Não no momento. O CloudFront só é compatível com o gRPC em HTTP/2.

Por padrão, o conteúdo pode ser fornecido aos visualizadores via HTTPS com o uso do nome de domínio da sua distribuição do CloudFront nos URLs. Por exemplo: https://dxxxxx.cloudfront.net/image.jpg. Se você deseja fornecer seu conteúdo via HTTPS usando o seu próprio nome de domínio e certificado SSL, pode usar um dos nossos recursos de suporte a certificados SSL customizados. Saiba mais.

A criptografia de campos é um recurso do CloudFront que permite fazer upload seguro de dados enviados pelo usuário, como números de cartão de crédito, para os servidores de origem. Usando essa funcionalidade, você pode criptografa ainda mais os dados confidenciais em um formulário HTTPS usando chaves de criptografia específicas de campos (que você fornece) antes de encaminhar uma solicitação de PUT/POST para a origem. Isso garante que os dados sensíveis possam ser descriptografados e exibidos somente por certos componentes e serviços em sua pilha de aplicações. Para saber mais sobre a criptografia no nível de campo, consulte criptografia no nível de campo em nossa documentação.

Muitas aplicações Web coletam dados sensíveis de usuários, como números de cartão de crédito. Esses dados são então processados pelos serviços de aplicações em execução na infraestrutura de origem. Todos esses aplicativos web usam a criptografia SSL/TLS entre o usuário final e o CloudFront, e entre o CloudFront e sua origem. Agora, a sua origem pode ter vários microsserviços que executam operações essenciais baseadas na entrada do usuário. No entanto, as informações confidenciais geralmente são usadas por um pequeno subconjunto desses microsserviços, o que significa que a maioria dos componentes tem acesso direto a esses dados sem motivo. Um simples engano de programação, como registrar a variável errada, pode causar a gravação do número do cartão de crédito do cliente em um arquivo.

Com a criptografia de campos, os pontos de presença do CloudFront podem criptografar os dados do cartão de crédito. A partir desse ponto, somente os aplicativos que têm chaves privadas podem descriptografar os campos confidenciais. Portanto, o serviço de atendimento de pedidos pode visualizar somente números do cartão de crédito criptografados, mas os serviços de pagamento podem descriptografar os dados do cartão de crédito. Isso garante um nível mais alto de segurança, pois mesmo que um dos serviços da aplicação vaze texto codificado, os dados permanecerão protegidos criptograficamente.

O IP dedicado SSL personalizado aloca endereços IP dedicados para atender ao seu conteúdo SSL em cada local da borda do CloudFront. Como existe um mapeamento individual entre os endereços IP e certificados SSL, o IP dedicado SSL personalizado funciona com navegadores e outros clientes que não são compatíveis com o SNI. Devido aos custos atuais de endereço IP, o SSL personalizado com IP dedicado custa USD 600/mês pro rata por hora.

O SNI SSL personalizado usa a extensão SNI do protocolo Transport Layer Security, o que permite que vários domínios enviem tráfego SSL usando o mesmo endereço IP por meio da inclusão do nome do host ao qual os visualizadores estão tentando se conectar. Da mesma forma que o SSL personalizado com IP dedicado, o CloudFront oferece o conteúdo de cada local da borda do Amazon CloudFront e com a mesma segurança que o recurso SSL personalizado com IP dedicado. O SNI SSL personalizado funciona com a maioria dos navegadores modernos, incluindo Chrome versão 6 e posterior (sendo executado no Windows XP e posterior ou OS X 10.5.7 e posterior), Safari versão 3 e posterior (sendo executado no Windows Vista e posterior ou Mac OS X 10.5.6. e posterior), Firefox 2.0 e posterior e Internet Explorer 7 e posterior (sendo executado no Windows Vista e posterior). Navegadores mais antigos que não suportam SNI não conseguem estabelecer uma conexão com o CloudFront para carregar a versão em HTTPS do seu conteúdo. O SNI SSL personalizado está disponível sem nenhum custo adicional além das taxas de transferência de dados e solicitação do CloudFront.

Server Name Indication (SNI) é uma extensão do protocolo Transport Layer Security (TLS). Este mecanismo identifica o domínio (nome do servidor) da solicitação SSL associada para que o certificado adequado possa ser usado na apresentação SSL. Isso faz com que seja possível usar um único endereço IP em vários servidores. O SNI precisa ser compatível com o navegador para adicionar o nome do servidor e, enquanto a maioria dos navegadores modernos oferece essa compatibilidade, existem alguns navegadores legados que não oferecem. Para obter mais detalhes, consulte a seção sobre SNI do Guia do desenvolvedor do CloudFront ou o artigo da Wikipedia sobre SNI.

Sim, agora você pode provisionar certificados SSL/TLS e associá-los a distribuições do CloudFront em minutos. Basta provisionar um certificado usando o novo AWS Certificate Manager (ACM) e implantá-lo na distribuição do CloudFront com alguns cliques. O ACM gerenciará as renovações de certificados por você. O ACM permite provisionar, implantar e gerenciar o certificado sem encargos adicionais.

Observe que o CloudFront continua a ser compatível com certificados obtidos de autoridades de certificação terceiras e carregados para o repositório de certificados do IAM.

Sim, o Amazon CloudFront tem um recurso opcional de conteúdo privado. Quando essa opção estiver habilitada, o Amazon CloudFront apenas distribuirá arquivos quando você confirmar que não há problema em fazê-lo, ao assinar de forma segura as suas solicitações. Saiba mais sobre esse recurso lendo o Guia do desenvolvedor do CloudFront.

Como cliente da AWS, você recebe o AWS Shield Básico sem custo adicional. O AWS Shield é um serviço gerenciado que oferece proteção contra ataques de DDoS para as aplicações Web executadas na AWS. O AWS Shield Básico oferece a todos os clientes da AWS proteção contra ataques comuns e mais frequentes à infraestrutura (camadas 3 e 4), como SYN/UDP floods, ataques de reflexão e outros tipos de ataque, proporcionando alta disponibilidade às aplicações na AWS.

O AWS Shield Avançado é um serviço pago opcional, disponível para clientes do AWS Business Support e do AWS Enterprise Support. O AWS Shield Avançado oferece proteções adicionais contra ataques maiores e mais sofisticados para aplicações executadas nos serviços do Elastic Load Balancing (ELB), Amazon CloudFront e Route 53.

Você pode integrar sua distribuição do CloudFront ao AWS WAF, um firewall de aplicações Web que ajuda a protegê-las contra ataques, permitindo que você configure regras baseadas em endereços IP, cabeçalhos HTTP e strings de URI personalizadas. Usando essas regras, o AWS WAF pode bloquear, permitir ou monitorar (fazer a contagem) solicitações da Web para a sua aplicação. Consulte o Guia do desenvolvedor do AWS WAF para obter mais informações.

O CloudFront oferece duas formas totalmente gerenciadas de proteger suas origens:

1. Controle de acesso de origem (OAC): o controle de acesso de origem (OAC) do CloudFront é um recurso de segurança que restringe o acesso às origens do Amazon Simple Storage Service (S3), às origens do AWS Elemental e aos URLs da função do Lambda, garantindo que somente o CloudFront possa acessar o conteúdo.
2. Origens da VPC: as origens da nuvem privada virtual (VPC) do CloudFront permitem usar o Amazon CloudFront para entregar conteúdo de aplicações hospedadas em uma sub-rede privada da VPC. Você pode usar Application Load Balancers (ALB), Network Load Balancers (NLB) e instâncias do EC2 em sub-redes privadas como origens da VPC com o CloudFront

Se as soluções gerenciadas do CloudFront não atenderem aos seus requisitos de caso de uso, confira abaixo algumas das abordagens alternativas disponíveis:

1. Cabeçalhos de origem personalizados: com o CloudFront, você pode acrescentar cabeçalhos personalizados às solicitações recebidas e, em seguida, configurar sua origem para validar esses valores específicos de cabeçalho, limitando efetivamente o acesso somente às solicitações encaminhadas pelo CloudFront. Esse método cria uma camada adicional de autenticação, reduzindo significativamente o risco de acesso direto não autorizado à origem.
2. Lista de permissões de IP: você pode configurar o grupo de segurança ou o firewall da origem para permitir exclusivamente o tráfego de entrada dos intervalos de IP do CloudFront. A AWS mantém e atualiza regularmente esses intervalos de IP para sua conveniência. Para obter informações detalhadas sobre a implementação da lista de permissões de IP, consulte nossa documentação abrangente em: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html#managed-prefix-list. Esse recurso fornece orientação passo a passo sobre como aproveitar as listas de prefixos gerenciadas da AWS para uma configuração de segurança ideal.
3. Criptografia SSL/TLS: você pode configurar o CloudFront para usar exclusivamente conexões HTTPS com a origem e obter proteção de dados de ponta a ponta por meio da comunicação criptografada entre a distribuição do CloudFront e a origem.

As origens da nuvem privada virtual (VPC) do CloudFront são um novo recurso que permite usar o CloudFront para fornecer conteúdo de aplicações hospedadas em uma sub-rede privada da VPC. Com as origens da VPC, você pode ter suas aplicações em uma sub-rede privada na VPC, acessível somente por meio de distribuições do CloudFront. Isso elimina a exigência de que a origem tenha um nome de serviço de nomes de domínio (DNS) que possa ser resolvido externamente. Você pode configurar origens da VPC com aplicações executadas em instâncias do Application Load Balancer (ALB), Network Load Balancer (NLB) e EC2. As origens da VPC estão disponíveis somente nas regiões comerciais da AWS, e a lista completa das regiões da AWS com suporte está disponível aqui.

Você deve usar as origens da VPC com o CloudFront se quiser aprimorar a segurança das aplicações Web e manter a alta performance e a escalabilidade global. Com as origens da VPC, você pode restringir o acesso às suas origens em uma VPC somente às distribuições do CloudFront sem configurações complexas, como cabeçalhos secretos ou listas de controle de acesso. As origens da VPC também otimizam custos de IPv4, permitindo o encaminhamento para origens em uma sub-rede privada com endereços IP IPv4 internos, gratuitamente. As origens da VPC são perfeitas se você quiser simplificar o gerenciamento de segurança, permitindo que você se concentre mais no crescimento de negócio principal, em vez de gerenciar medidas de segurança complexas.

1. Segurança: com origens da VPC, você pode aprimorar a postura de segurança da aplicação colocando seus balanceadores de carga e as instâncias do EC2 em sub-redes privadas, tornando o CloudFront o único ponto de entrada. As solicitações dos usuários vão do CloudFront às origens da VPC por meio de uma conexão privada e segura, fornecendo segurança adicional para as aplicações.
2. Gerenciamento: as origens da VPC reduzem a sobrecarga operacional necessária para a conectividade segura de origem do CloudFront, permitindo remover suas origens para sub-redes privadas sem acesso público e sem precisar implementar listas de controle de acesso, cabeçalhos secretos compartilhados ou outros mecanismos para restringir o acesso às origens. Isso facilita a proteção das aplicações Web com o CloudFront, sem precisar investir em um trabalho de desenvolvimento rotineiro.
3. Escalável e de alta performance: com as origens da VPC, os clientes podem usar os locais da borda globais do CloudFront e as redes estruturais da AWS, desfrutando de escala e performance semelhantes aos de outros métodos de entrega de conteúdo existentes, ao mesmo tempo em que melhoram a postura de segurança. A solução simplifica o gerenciamento de segurança enquanto fornece aplicações globais aos clientes, facilitando o uso do CloudFront como porta de entrada única para as aplicações.

As origens da nuvem privada virtual (VPC) do CloudFront permitem usar o CloudFront para fornecer conteúdo de aplicações hospedadas em uma sub-rede privada da VPC com Application Load Balancers, Network Load Balancers e instâncias do EC2. O Bloqueio de Acesso Público da Amazon VPC (VPC BPA) é um controle simples e declarativo que bloqueia com autoridade o tráfego de entrada (ingresso) e saída (egresso) da VPC por meio de caminhos de internet fornecidos pela AWS. Quando o VPC BPA é habilitado em uma sub-rede com origem da VPC, as conexões ativas do CloudFront são encerradas em direção a essa sub-rede. Nenhuma nova conexão é enviada para a sub-rede, sendo encaminhada para outra sub-rede na qual a origem da VPC reside, em que o BPA não está habilitado, ou descartada se todas as sub-redes nas quais a origem da VPC reside tiverem o BPA habilitado.

As origens da VPC são compatíveis com Application Load Balancers, Network Load Balancers e instâncias do EC2.

Não, não há suporte para IPv6 com origens privadas da VPC. Com origens da VPC, você precisa de endereços IPv4 privados, que são gratuitos e não incorrem em cobranças de IPv4.

Sim, você pode configurar o Amazon CloudFront para adicionar cabeçalhos personalizados, ou substituir o valor de cabeçalhos atuais, para solicitações encaminhadas para a sua origem. Use esses cabeçalhos para validar que as solicitações feitas para a sua origem sejam enviadas do CloudFront. Inclusive, também é possível configurar a sua origem para permitir apenas solicitações que contenham os valores do cabeçalho personalizado que você especificou. Além disso, se você usar várias distribuições do CloudFront com a mesma origem, será possível usar cabeçalhos personalizados para distinguir solicitações de origem feitas por distribuições individuais diferentes. Finalmente, os cabeçalhos personalizados podem ser usados para ajudar a determinar os cabeçalhos de CORS corretos retornados para as suas solicitações. Você pode configurar cabeçalhos personalizados por meio da API do CloudFront e do Console de Gerenciamento da AWS. Não há cobranças adicionais por este recurso. Para obter mais detalhes sobre como definir cabeçalhos personalizados, leia mais aqui.

O Amazon CloudFront oferece suporte à entrega de conteúdo dinâmico personalizado usando cookies HTTP. Para usar esse recurso, especifique se você deseja que o Amazon CloudFront encaminhe alguns ou todos os seus cookies para seu servidor de origem personalizado. O Amazon CloudFront então considera os valores de cookie encaminhados ao identificar um objeto exclusivo em seu cache. Dessa forma, seus usuários finais obtêm o benefício do conteúdo personalizado apenas para eles com um cookie e os benefícios de performance do Amazon CloudFront. Também é possível optar por registrar os valores dos cookies nos logs de acesso do Amazon CloudFront.

Opcionalmente, uma string de consulta pode ser configurada para fazer parte da chave de cache para identificação de objetos no cache do Amazon CloudFront. Isso ajuda você a criar páginas dinâmicas da Web (p. ex., resultados de pesquisa) que podem ser armazenadas em cache no ponto por algum período de tempo.

Sim, o recurso de lista de permissões de string de consulta permite que você configure facilmente o Amazon CloudFront para usar apenas determinados parâmetros na chave de cache, enquanto continua a encaminhar todos os parâmetros para a origem.

Sim. Você pode configurar o Amazon CloudFront para que ele inclua na lista de permissão até dez parâmetros de consulta.

O Amazon CloudFront é compatível com parâmetros de consulta de URI, conforme está definido na seção 3.4 do RFC3986. Mais especificamente, ele é compatível com parâmetros de consulta incorporados em uma string HTTP GET após o caractere “?” e delimitados pelo caractere “&”.

Sim, o CloudFront pode compactar automaticamente textos ou dados binários. Para usar o recurso, basta especificar nas configurações de comportamento do cache que você deseja que o CloudFront compacte automaticamente os objetos. O cliente deve adicionar Accept-Encoding: gzip no cabeçalho da solicitação (a maioria dos navegadores da Web modernos já faz isso por padrão). Para obter mais informações sobre esse recurso, consulte o nosso guia do desenvolvedor.

Em geral, streaming é a entrega de áudio e vídeo a usuários finais pela internet sem precisar fazer download do arquivo de mídia antes da reprodução. Os protocolos usados para streaming incluem os que usam o HTTP para entrega, como o HTTP Live Streaming (HLS) da Apple, o MPEG Dynamic Adaptive Streaming over HTTP (MPEG-DASH), o HTTP Dynamic Streaming (HDS) da Adobe e o Smooth Streaming da Microsoft. Esses protocolos são diferentes da entrega de páginas da web e outros tipos de conteúdo online porque os protocolos de streaming entregam mídia em tempo real – os visualizadores assistem aos bytes à medida que são entregues. Realizar streaming de conteúdo oferece vários benefícios potenciais para você e para seus usuários finais:

• Streaming pode oferecer aos visualizadores mais controle sobre sua experiência de visualização. Por exemplo, é mais fácil para um visualizador avançar e retroceder um vídeo usando streaming do que utilizando meios tradicionais de download.
• O streaming também pode proporcionar a você maior controle sobre seu conteúdo, já que nenhum arquivo permanece na unidade local ou do cliente do visualizador quando ele termina de assistir a um vídeo.
• O streaming pode ajudar a reduzir custos, pois ele oferece apenas partes de um arquivo de mídia a que os visualizadores realmente assistem. Em contrapartida, com os downloads tradicionais, é comum que o arquivo de mídia completo seja entregue aos espectadores, mesmo se eles só assistirem a uma parte dele.

Sim, o Amazon CloudFront disponibiliza várias opções para entregar conteúdo de vídeo sob demanda. Caso tenha arquivos de mídia que foram convertidos para o formato HLS, MPEG-DASH ou Microsoft Smooth Streaming, por exemplo, usando o AWS Elemental MediaConvert, antes do armazenamento no Amazon S3 (ou uma origem personalizada), você pode usar uma distribuição da Web do Amazon CloudFront para fazer transmissão nesse formato sem precisar executar qualquer servidor de mídia.

Como opção, você também pode executar um servidor de streaming de terceiros (p. ex., o Wowza Media Server, disponível no AWS Marketplace) no Amazon EC2, que pode converter um arquivo de mídia para o formato de streaming HTTP necessário. Esse servidor pode então ser designado como a origem de uma distribuição do Amazon CloudFront na Web.

Acesse a seção sobre Vídeo sob demanda (VOD) na página da AWS para saber mais.

Sim. Você pode usar o streaming ao vivo do Amazon CloudFront com qualquer serviço de origem de vídeo ao vivo que produza streams com base em HTTP, como o AWS Elemental MediaPackage ou o AWS Elemental MediaStore. O MediaPackage é uma origem de vídeo e um serviço de empacotamento just-in-time que permite que distribuidores de vídeo entreguem de modo seguro e confiável conteúdo de streaming em grande escala usando vários padrões de entrega e proteção de conteúdo. O MediaStore é um serviço de origem e armazenamento HTTP que oferece a alta performance, a uniformidade imediata e a baixa latência previsível exigidas para mídia ao vivo combinadas à segurança e à durabilidade do armazenamento da Amazon.

Acesse a página de streaming de vídeo ao vivo da AWS para saber mais.

O Media-Quality Aware Resiliency (MQAR) é um recurso integrado entre o Amazon CloudFront e o AWS Media Services que fornece seleção automática de origem e failover entre regiões de acordo com uma pontuação de qualidade de vídeo gerada de forma dinâmica. Com o MQAR, é possível implantar um fluxo de trabalho redundante de serviços de mídia da AWS, em duas regiões da AWS diferentes, para uma entrega resiliente de eventos ao vivo. Ao ativar o recurso MQAR para sua distribuição, o CloudFront recebe a autorização para selecionar de forma automática a origem considerada com o maior índice de qualidade. O índice de qualidade representa problemas de qualidade de streaming de mídia percebidos desde suas origens, como quadros pretos, quadros congelados ou perdidos ou quadros repetidos. Por exemplo, se as origens do AWS Elemental MediaPackage v2 estiverem implantadas em duas regiões diferentes da AWS e uma delas reportar uma pontuação de qualidade de mídia maior do que a outra, o CloudFront mudará de forma automática para a origem que reporta a pontuação mais alta. Esse atributo simula os “olhos na tela” sempre ativos para oferecer eventos ao vivo e canais de programação 24 horas por dia, 7 dias por semana, e foi projetado para ajudar a oferecer uma experiência de alta qualidade aos espectadores. É possível ler mais detalhes sobre o MQAR no guia do desenvolvedor do CloudFront.

O Origin Shield é uma camada de cache centralizada que ajuda a aumentar a taxa de acertos do cache para reduzir a carga em sua origem. O Origin Shield também diminui seus custos operacionais de origem recolhendo solicitações entre regiões, de forma que apenas uma solicitação vá para sua origem por objeto. Quando habilitado, o CloudFront roteará todas as buscas de origem por meio do Origin Shield e só fará uma solicitação para sua origem se o conteúdo ainda não estiver armazenado no cache do Origin Shield.

O Origin Shield é ideal para workloads com visualizadores espalhados por diferentes regiões geográficas ou workloads que envolvem empacotamento just-in-time para streaming de vídeo, manuseio de imagens em tempo real ou processos semelhantes. Usar o Origin Shield na frente de sua origem reduzirá o número de buscas de origem redundantes, verificando primeiro seu cache central e apenas fazendo uma busca de origem consolidada para conteúdo que ainda não está no cache do Origin Shield. Da mesma forma, o Origin Shield pode ser usado em uma arquitetura multi-CDN para reduzir o número de buscas de origem duplicadas entre CDNs, posicionando o Amazon CloudFront como a origem para outros CDNs. Consulte o Guia do desenvolvedor do Amazon CloudFront para obter mais detalhes sobre estes e outros casos de uso do Origin Shield.

O Amazon CloudFront oferece o Origin Shield nas regiões da AWS onde o CloudFront tem um cache de borda regional. Ao habilitar o Origin Shield, você deve escolher a região da AWS para o Origin Shield que tem a menor latência para sua origem. Você pode usar o Origin Shield com origens que estão em uma região da AWS e com origens que não estão na AWS. Para obter mais informações, consulte Escolher a região da AWS para o Origin Shield no Guia do desenvolvedor do Amazon CloudFront.

Sim. Todas as regiões do Origin Shield são construídas usando uma arquitetura altamente disponível que abrange várias zonas de disponibilidade com frotas de instâncias do Amazon EC2 com Auto Scaling. As conexões de locais do CloudFront com o Origin Shield também usam rastreamento de erro ativo para cada solicitação para encaminhar automaticamente a solicitação para um local secundário do Origin Shield se o local primário do Origin Shield não estiver disponível.

Os IPs estáticos Anycast do Amazon CloudFront são um conjunto de endereços IP estáticos que permitem se conectar a todos os locais da borda do CloudFront globalmente. Eles fornecem uma lista pequena e estática de IPs que podem ser aplicados em casos de uso como cobrança com taxa zero, em que os provedores de rede dispensam cobranças de dados para endereços IP específicos com os acordos apropriados em vigor, e uma listagem de permissões do lado do cliente para melhorar a postura de segurança. Ao usar IPs estáticos Anycast, você elimina o desafio operacional de atualizar constantemente listas de permissões ou mapeamentos de IP, pois o mesmo conjunto de IPs funciona em toda a rede global do CloudFront e ainda se beneficia de todos os recursos do CloudFront.

Para habilitar os IPs estáticos Anycast, você precisa primeiro solicitar e criar uma lista de IPs estáticos Anycast na conta da AWS. Depois que a lista for criada, você poderá associar as distribuições do CloudFront à lista de IPs estáticos Anycast. Isso pode ser feito por meio da seção IP estático Anycast no Console da AWS ou editando cada distribuição e selecionando a lista de IPs estáticos Anycast desejada no menu suspenso. Depois de salvar essas alterações, o conjunto específico de endereços IP estáticos associados às distribuições estará disponível para copiar ou baixar da lista exibida no Console da AWS ou por meio das APIs

Você receberá 21 endereços IP para IPv4 ao habilitar os IPs estáticos Anycast do CloudFront. Você precisará adicionar todos esses endereços IP em qualquer lista de permissão relevante.

Não. O Anycast do CloudFront só estará disponível com IPs espalhados por regiões geográficas.

À medida que o CloudFront adiciona novos locais da borda, sua lista de IPs estáticos Anycast continuará válida. Anunciaremos seus IPs nos novos locais da borda, conforme apropriado.

Todos os recursos do CloudFront funcionam com o Anycast, com três exceções importantes: 1/ os IPs estáticos Anycast não oferecem suporte a clientes legados incompatíveis com a SNI, 2/ você deve usar a classe de preço completa ao utilizar IPs estáticos Anycast e 3/ é necessário desabilitar o IPv6 ao usar IPs estáticos Anycast. Os IPs estáticos Anycast funcionam no estágio de resolução de DNS e, quando a solicitação chegar a um host, todos os recursos e integrações existentes com outros produtos da AWS continuarão disponíveis nas suas distribuições.

Você pode usar os IPs estáticos Anycast com várias distribuições, mas eles devem estar na mesma conta. Os IPs estáticos Anycast do CloudFront podem ser associados a várias distribuições na conta. O IP estático Anycast do CloudFront oferecerá suporte à indicação do nome do servidor (SNI) para que o certificado correto seja retornado de qualquer número de distribuições associadas à política de IP estático Anycast. Caso deseje ter IPs estáticos distintos para várias distribuições em sua conta, você pode criar uma lista adicional de IPs estáticos Anycast e associá-los a distribuições específicas.

Ao criar uma distribuição em uma conta com IPs estáticos Anycast habilitados, você deve associar explicitamente a nova distribuição à lista existente de IPs estáticos Anycast. Por padrão, serão usados endereços IP dinâmicos até que você a vincule à lista de IPs estáticos.

Sim. Preencha nossa solicitação para limites mais altos aqui, e adicionaremos mais capacidade à sua conta no prazo de dois dias úteis.

Para saber mais sobre o limite do número de distribuições que podem ser criadas por conta da AWS, consulte Amazon CloudFront Limits na Referência geral da Amazon Web Services. Para solicitar um limite maior, acesse o formulário de aumento de limite do CloudFront.

O tamanho máximo de um único arquivo que pode ser entregue pelo Amazon CloudFront é 30 GB. Esse limite se aplica a todas as distribuições do Amazon CloudFront.

1. Logs padrão (logs de acesso) Os logs padrão do CloudFront fornecem registros detalhados sobre cada solicitação feita a uma distribuição. Esses logs são úteis em muitos cenários, incluindo auditorias de segurança e acesso.
2. Logs em tempo real Os logs em tempo real do CloudFront fornecem informações sobre solicitações feitas a uma distribuição, em tempo real (os registros de log são entregues em segundos após o recebimento das solicitações). Você pode escolher a taxa de amostragem para os logs em tempo real, ou seja, a porcentagem de solicitações para as quais deseja receber registros de log em tempo real.
3. Funções de borda de registro em log: você pode usar o Amazon CloudWatch Logs para obter logs das funções de borda, tanto do Lambda@Edge quanto do CloudFront Functions. Você pode acessar os logs usando o console do CloudWatch ou a API do CloudWatch Logs. Para obter mais informações, consulte Logs de função de borda.
4. Atividade do serviço de registro em log: você pode usar o AWS CloudTrail para registrar em log a atividade do serviço do CloudFront (atividade da API) na conta da AWS. O CloudTrail fornece um registro das ações de API realizadas por um usuário, perfil ou serviço da AWS no CloudFront. Usando as informações coletadas pelo CloudTrail, você pode determinar a solicitação de API que foi feita ao CloudFront, o endereço IP de origem, quem fez a solicitação, quando ela foi feita e outros detalhes. Para obter mais informações, consulte Registrar em log chamadas de API do Amazon CloudFront usando o AWS CloudTrail.

• Os logs padrão do CloudFront são entregues no bucket do Amazon S3 de sua escolha, no Amazon CloudWatch Logs e no Amazon Data Firehose. Para obter mais informações, consulte Use standard logs (access logs).
• Os logs em tempo real do CloudFront são entregues ao fluxo de dados de sua escolha no Amazon Kinesis Data Streams. O CloudFront cobra por logs em tempo real, além das cobranças que você incorre pelo uso do Kinesis Data Streams. Para obter mais informações, consulte Use logs em tempo real.
• Os logs de funções de borda do CloudFront (Lambda@Edge e CloudFront Functions) são entregues ao Amazon CloudWatch Logs

Os logs de acesso padrão do CloudFront podem ser entregues ao Amazon S3, Amazon CloudWatch e Amazon Data Firehose. Você pode escolher o formato do log de saída (texto simples, w3c, JSON, CSV e Parquet). Você pode selecionar quais campos deseja registrar em log e a ordem na qual esses campos devem ser incluídos nos logs. Para logs entregues ao S3, você também pode habilitar o particionamento de logs entregues ao S3, ou seja, configurar os logs para serem particionados automaticamente a cada hora ou diariamente. Você também pode entregar logs de acesso padrão aos buckets do S3 nas regiões da AWS de entrada. Consulte a seção Standard Access logs do guia do desenvolvedor do CloudFront para saber mais.

O CloudFront não cobra para habilitar logs padrão, embora você receba cobranças pela entrega, armazenamento e acesso aos logs, dependendo do destino da entrega do log. Consulte a seção “Recursos adicionais” da página de preços do CloudFront para saber mais.

Sim. Seja recebendo relatórios de estatísticas detalhadas de cache, monitorando o uso do CloudFront, identificando de onde seus clientes visualizam conteúdo ou definindo alarmes praticamente em tempo real sobre métricas operacionais, o Amazon CloudFront oferece diversas soluções para suas necessidades de relatórios. Você poderá obter todas as opções de relatórios acessando o painel Amazon CloudFront Reporting & Analytics no Console de Gerenciamento da AWS. Além disso, você pode saber mais sobre as diversas opções de relatórios acessando a página de relatórios e analytics do Amazon CloudFront.

Sim. O Amazon CloudFront é compatível com a aplicação de tags de alocação de custos. A aplicação de tags facilita alocar custos e otimizar gastos ao categorizar e agrupar recursos da AWS. Por exemplo, você pode usar tags para agrupar recursos por administrador, nome da aplicação, centro de custo ou um projeto específico. Para saber mais sobre a aplicação de tags de alocação de custos, consulte Using Cost Allocation Tags. Se você estiver pronto para adicionar tags às suas distribuições do CloudFront, consulte a página de adição de tags do Amazon CloudFront.

Sim. Para receber um histórico de todas as chamadas de API do Amazon CloudFront realizadas na sua conta, basta ativar o AWS CloudTrail no console de gerenciamento da AWS do CloudTrail. Para obter mais informações, visite a página inicial do AWS CloudTrail.

Você pode monitorar, emitir alarmes e receber notificações sobre a performance operacional da distribuição do Amazon CloudFront alguns minutos após a solicitação do visualizador usando o Amazon CloudWatch. O CloudFront publica automaticamente seis métricas operacionais com intervalos de um minuto no Amazon CloudWatch. Você pode usar o CloudWatch para definir alarmes sobre qualquer padrão anormal no tráfego do CloudFront. Para saber como começar a monitorar as atividades do CloudFront e a definir alarmes com o CloudWatch, consulte a demonstração passo a passo no Guia do desenvolvedor do Amazon CloudFront, ou simplesmente navegue até o console de gerenciamento do Amazon CloudFront e selecione Monitoramento e alarmes no painel de navegação.

Você pode escolher um destino, dependendo do seu caso de uso. Se os seus casos de uso forem urgentes e exigirem acesso rápido aos dados do log em apenas alguns segundos, escolha os logs em tempo real. Caso seja necessário que o seu pipeline de log em tempo real seja mais barato, você pode filtrar os dados do log, habilitando logs apenas para comportamentos do cache específicos, ou então escolher uma taxa de amostragem mais baixa. O pipeline de log em tempo real é adequado à entrega de dados rápida. Portanto, os registros do log poderão ser eliminados se houver atrasos nos dados. Por outro lado, se você precisar de uma solução de processamento de logs de baixo custo sem o requisito de dados em tempo real, a opção de log padrão atual será ideal para você. Os logs padrão no S3 são criados para serem completos e os logs em geral ficam disponíveis em apenas alguns minutos. Esses logs podem ser habilitados para toda a distribuição e não para comportamentos do cache específicos. Portanto, se você precisar de logs para investigação, auditoria e análise ad hoc, poderá habilitar apenas os logs padrão no S3. Você pode usar uma combinação dos dois logs. Use uma lista filtrada de logs em tempo real para fins de visibilidade operacional, e depois use os logs padrão para auditoria.
 

Os logs padrão do CloudFront são entregues ao seu bucket do S3. Você também pode usar a integração criada por soluções de terceiros, como DataDog e Sumologic, para criar painéis com base nesses logs.

Os logs em tempo real são entregues ao seu Kinesis Data Streams. Do Kinesis Data Streams, os logs podem ser publicados no Amazon Kinesis Data Firehose. O Amazon Kinesis Data Firehose pode entregar dados de modo fácil ao Amazon S3, Amazon Redshift, Amazon OpenSearch Service e a provedores de serviços como Datadog, New Relic e Splunk. O Kinesis Firehose também aceita a entrega de dados a um endpoint HTTP genérico.

Use as etapas a seguir para estimar o número de fragmentos necessários:

1. Calcule (ou estime) o número de solicitações por segundo recebidas pela sua distribuição do CloudFront. você pode usar os relatórios de uso ou as métricas do CloudFront para ajudá-lo a calcular suas solicitações por segundo.
2. Determine o tamanho típico de um único registro de log em tempo real. Um registro típico que inclua todos os campos disponíveis tem cerca de 1 KB. Caso não tenha certeza do tamanho do seu registro de log, você poderá habilitar logs em tempo real com uma taxa de amostragem baixa (por exemplo, 1%) e depois calcular o tamanho médio do registro usando dados de monitoramento no Kinesis Data Streams (número total de registros dividido pelo total de bytes de entrada).
3. Multiplique o número de solicitações por segundo (da etapa 1) pelo tamanho de um típico registro de log em tempo real (da etapa 2) para determinar o volume de dados por segundo que provavelmente sua configuração de log em tempo real vai enviar ao Kinesis Data Streams.
4. Usando os dados por segundo, calcule o número de fragmentos necessários. Um único fragmento tem capacidade de até 1 MB por segundo e 1.000 solicitações (registros de log) por segundo. Quando você calcular o número de fragmentos necessários, recomendados adicionar até 25% como um buffer.

Por exemplo, vamos supor que sua distribuição recebe 10.000 solicitações por segundo e que o tamanho típico dos seus registros de log em tempo real é de 1 KB. Isso significa que a sua configuração de log em tempo real pode gerar 10.000.000 de bytes (10.000 multiplicados por 1.000), ou 9,53 MB, por segundo. Nesse cenário, você precisaria de apenas 10 fragmentos do Kinesis. Você deve considerar a criação de pelo menos 12 fragmentos para ter um buffer.

O CloudFront Functions é um recurso de computação de borda com tecnologia sem servidor para executar código JavaScript em locais da borda do CloudFront para transformações e manipulações HTTP(s) leves. O Functions foi especialmente criado para proporcionar aos clientes a flexibilidade de um ambiente de programação completo com a performance e segurança que as aplicações Web modernas exigem. A uma fração do preço do AWS Lambda@Edge, os clientes podem dimensionar de maneira instantânea e acessível para ajudar em milhões de solicitações por segundo.

O CloudFront Functions foi criado de maneira nativa no CloudFront, permitindo que o cliente crie, teste e implante com facilidade funções dentro do mesmo serviço. O CloudFront KeyValueStore também pode ser usado com o CloudFront Functions para armazenar e recuperar dados de pesquisa para complementar a lógica da sua função. Nosso repositório do GitHub ajuda os desenvolvedores a começar oferecendo uma ampla coleção de códigos de exemplo que podem ser usados como ponto de partida para criar funções. Você pode criar funções no console do CloudFront utilizando a IDE ou as APIs/CLI do CloudFront. Após a criação do código, você poderá testar a função em relação à distribuição do CloudFront, certificando-se de que ele executa adequadamente após a implantação. A funcionalidade de teste no console oferece um editor visual para criar eventos de teste rapidamente e validar funções. Após a associação com uma distribuição do CloudFront, o código é implantado na rede de distribuição global de locais da borda da AWS para execução em resposta a solicitações do CloudFront.

O CloudFront Functions é ideal para funções leves e curtas, como os exemplos abaixo:

• Normalização de chave de cache: você pode transformar atributos de solicitação HTTP (cabeçalhos, strings de consulta, cookies, até mesmo o caminho relativo do URL de solicitação) para criar uma chave de cache ideal, que pode melhorar a taxa de acertos.
• Manipulação de cabeçalho: você pode inserir, modificar ou excluir cabeçalhos HTTP na solicitação ou resposta. Por exemplo, você pode adicionar cabeçalhos HTTP Strict Transport Security (HSTS) ou Cross-origin resource sharing (CORS) a cada resposta.
• Redirecionamento ou regravações de URL: você pode redirecionar os visualizadores para outras páginas com base nas informações da solicitação ou redirecionar todas as solicitações de um caminho para outro.
• Solicitar autorização: você pode validar tokens de autorização, como JSON web tokens (JWT), por meio da inspeção dos cabeçalhos de autorização ou outros metadados de solicitação.

O CloudFront KeyValueStore é um armazenamento de dados de chave-valor global, com baixa latência e totalmente gerenciado. O KeyValueStore possibilita a recuperação de dados de chave-valor do CloudFront Functions, tornando as funções mais personalizáveis ao permitir atualizações de dados independentes. Os dados de chave-valor estão disponíveis em todos os locais da borda do CloudFront e fornecem um armazenamento de chave-valor na memória altamente eficiente com leituras rápidas do CloudFront Functions.

O CloudFront KeyValueStore é ideal para leituras frequentes em locais da borda e atualizações pouco frequentes, como:

• Mantenha regravações e redirecionamentos de URL: redirecione os usuários para um site de um país específico com base na localização geográfica. Armazenar e atualizar esses URLs com base geográfica no KeyValueStore simplifica o gerenciamento de URLs.
• Teste A/B e sinalizadores de recursos: faça experimentos atribuindo um percentual do tráfego a uma versão do seu site. Você pode atualizar os pesos dos experimentos sem atualizar o código da função ou sua distribuição do CloudFront.
• Autorização de acesso: implemente o controle de acesso e a autorização do conteúdo entregue pelo CloudFront criando e validando tokens gerados pelo usuário, como tokens HMAC ou JSON web tokens (JWT), para permitir ou negar solicitações. 

Não, o CloudFront Functions foi criado para complementar, e não substituir, o Lambda@Edge. A combinação do Lambda@Edge e do CloudFront Functions permite que você escolha a ferramenta certa para a tarefa. Você pode escolher usar o CloudFront Functions e o Lambda@Edge em diferentes gatilhos de evento dentro do mesmo comportamento de cache nas distribuições do CloudFront. Por exemplo, você pode usar o Lambda@Edge para manipular arquivos de manifesto de streaming em tempo real para inserir tokens personalizados para proteger transmissões ao vivo. Você pode usar o CloudFront Functions para validar esses tokens quando um usuário fizer uma solicitação para um segmento do manifesto.

A combinação do CloudFront Functions e do Lambda@Edge proporciona duas opções poderosas e flexíveis para a execução de códigos em resposta a eventos do CloudFront. Ambos oferecem maneiras seguras de executar códigos em resposta aos eventos do CloudFront, sem gerenciar a infraestrutura. O CloudFront foi criado especialmente para transformações e manipulações de solicitações/respostas leves, de grande escala e rigorosos de latência. O Lambda@Edge usa tempos de execução de uso geral que são compatíveis com uma grande variedade de necessidades e personalizações de computação. O Lambda@Edge é ideal para operações com uso intensivo de computação. Por exemplo, computações que demoram mais para terminar (vários milésimos de segundo a segundos), têm dependências em bibliotecas externas de terceiros, precisam de integrações com outros produtos da AWS (p. ex., S3, DynamoDB) ou precisam fazer chamadas de rede para processamento de dados. Alguns dos casos de uso avançados mais populares do Lambda@Edge incluem manipulação de manifesto de streaming HLS, integrações com serviços de detecção de bots e autorização de terceiros, Server-Side Rendering (SSR) para Single-Page Apps (SPA) na borda e muito mais. Consulte a página de casos de uso do Lambda@Edge para obter mais detalhes.

O CloudFront Functions proporciona a performance, o dimensionamento e a economia que você espera, mas com um modelo de segurança exclusivo que oferece limites de isolamento estritos entre os códigos do Functions. Ao rodar um código personalizado em um ambiente de computação compartilhado e multilocatário, é essencial manter um ambiente de execução extremamente seguro. Um agente mal-intencionado pode tentar explorar os bugs presentes no tempo de execução, nas bibliotecas ou nas CPU para vazar dados confidenciais do servidor ou de outras funções do cliente. Sem uma barreira de isolamento rigorosa entre o código da função, essas explorações são possíveis. O AWS Lambda e o Lambda@Edge já alcançam esse isolamento de segurança pelo isolamento de VM baseado no Firecracker. Com o CloudFront Functions, desenvolvemos um modelo de isolamento baseado em processos que fornece a mesma barreira de segurança contra ataques de canal lateral, como Spectre and Meltdown, ataques de temporização ou outras vulnerabilidades no código. O CloudFront Functions não consegue acessar ou modificar dados que pertençam a outros clientes. Isso é possível executando as funções em um processo dedicado em uma CPU dedicada. O CloudFront Functions executa trabalhos de processo que atendem apenas um cliente por vez e todos os dados específicos do cliente são descartados (removidos) entre as execuções.

O CloudFront Functions não usa o V8 como um mecanismo de JavaScript. O modelo de segurança do Functions é diferente e considerado mais seguro do que o modelo baseado em isolados v8 oferecido por alguns outros fornecedores.

Você pode testar qualquer função usando a funcionalidade de teste incorporada. Testar uma função vai executar o código contra a distribuição do CloudFront para validar se a função retorna o resultado previsto. Além de validar a execução do código, você também tem uma métrica de utilização de computação. A métrica de utilização de computação gera uma porcentagem do quão perto a função está do limite de tempo de execução. Por exemplo, uma utilização de computação de 30 significa que a função está usando 30% do tempo de execução total permitido. É possível criar objetos de teste com o editor visual, permitindo que você adicione facilmente sequências de caracteres de consulta, cabeçalhos, URLs e métodos HTTP para cada objeto, ou você pode criar objetos de teste usando uma representação JSON da solicitação ou da resposta. Quando o teste for concluído, os resultados e a métrica de utilização de computação poderão ser visualizados no mesmo estilo do editor visual ou pela visualização da resposta JSON. Se a função for executada com êxito e a métrica de utilização de computação não chegar perto de 100, você sabe que a função funcionará ao associá-la a uma distribuição do CloudFront.

O CloudFront Functions gera logs de métrica e execução para monitorar o uso e a performance de uma função. As métricas são geradas para cada invocação de uma função e você pode visualizá-las para cada função individualmente no console do CloudFront ou do CloudWatch. As métricas incluem o número de invocações, a utilização de computação, os erros de validação e execução. Se a função resultar em um erro de validação ou execução, a mensagem de erro aparecerá nos logs de acesso do CloudFront, proporcionando uma melhor visibilidade sobre como as funções impactam o tráfego do CloudFront. Além das métricas, você também pode gerar logs de execução incluindo uma instrução “console.log()” dentro do código de função. Qualquer instrução de log vai gerar uma entrada de log do CloudWatch que será enviada para o CloudWatch. Os logs e as métricas estão inclusos no preço do CloudFront Functions. 

O Lambda@Edge é uma extensão do AWS Lambda que permite a execução de códigos em locais da borda globais sem o provisionamento ou gerenciamento de servidores. O Lambda@Edge oferece computação sem servidor avançada e flexível para funções complexas e lógica de aplicação completa próxima aos visualizadores. As funções do Lambda@Edge são executadas em um ambiente Node.js ou Python. Você publica funções em uma única região da AWS, e quando você associa a função a uma distribuição do CloudFront, o Lambda@Edge replica automaticamente o código em todo o mundo. O Lambda@Edge escala automaticamente, de algumas solicitações por dia a milhares por segundo.

O Lambda@Edge é executado ao associar funções a comportamentos específicos de cache no CloudFront. Você também pode especificar em qual ponto durante o processamento da solicitação ou resposta do CloudFront a função deve ser executada (ou seja, quando uma solicitação do visualizador for recebida, uma solicitação for encaminhada para a origem, ou recebida de volta dela, e logo antes de a resposta ser enviada de volta para o usuário final). Você pode escrever códigos usando o Node.js ou Python do console ou da API do Lambda, ou usando frameworks como o Serverless Application Model (SAM). Após testar a função, você a associa com o comportamento de cache ou gatilho de evento do CloudFront selecionado. Depois de salva, na próxima solicitação recebida para a distribuição do CloudFront, a função será propagada para o local da borda do CloudFront, ficando disponível para execução e redimensionamento de escala conforme a necessidade. Saiba mais consultando nossa documentação.

As funções do Lambda@Edge serão acionadas automaticamente em resposta aos seguintes eventos do Amazon CloudFront:

• Solicitação do visualizador: este evento ocorre quando um usuário final ou um dispositivo na internet faz uma solicitação de HTTP(S) ao CloudFront e a solicitação chega ao local da borda mais próxima do usuário.
• Resposta do visualizador: este evento ocorre quando o servidor do CloudFront na borda está pronto para responder ao usuário final ou dispositivo que enviou a solicitação.
• Solicitação para a origem: este evento ocorre quando o servidor do CloudFront na borda não tem o objeto solicitado no cache e a solicitação do visualizador está pronta para ser enviada ao servidor Web de origem no backend (por exemplo, Amazon EC2, Application Load Balancer ou Amazon S3).
• Resposta da origem: este evento ocorre quando o servidor do CloudFront na borda recebe uma resposta do servidor Web de origem no backend.

A implantação contínua no CloudFront fornece a capacidade de teste e validação de alterações na configuração de parte do tráfego em execução antes da implantação das alterações para todos os visualizadores.

A implantação contínua com o CloudFront proporciona a você um alto nível de segurança nesse processo. Agora, você pode implantar dois ambientes separados, mas idênticos (azul e verde), integrados de forma simples com pipelines de Continuous Integration and Delivery (CI/CD – Integração e entrega contínuas) para disponibilizar versões gradualmente, sem necessidade de alterar o Sistema de Nomes de Domínio (DNS). Dessa forma, você garante uma experiência consistente aos visualizadores, vinculando suas sessões ao mesmo ambiente por meio da persistência de sessões. Além disso, você pode comparar a performance das alterações, monitorando logs padrão e em tempo real e revertendo rapidamente para a configuração anterior quando uma mudança afetar negativamente um serviço. 

Você pode configurar a implantação contínua associando uma cópia de distribuição a uma distribuição primária por meio do console do CloudFront, do SDK, da interface de linha de comandos (CLI) ou do modelo do CloudFormation. Em seguida, você pode definir as regras para dividir tráfegos através da configuração do cabeçalho do cliente ou através do ajuste da porcentagem de tráfego para testes com a cópia da distribuição. Uma vez definida, você pode atualizar a cópia da configuração com as alterações desejadas. O CloudFront gerenciará a divisão do tráfego para os usuários e fornecerá os dados analíticos associados para ajudar você na decisão de continuar a implantação ou realizar a restauração. Quando os testes com cópias de distribuições forem validados, você poderá incluir as alterações para a distribuição principal.

Acesse a documentação para saber mais sobre o recurso.

Implantações contínuas possibilitam o monitoramento de usuário real por meio do tráfego real na Web. Você pode usar quaisquer métodos de monitoramento disponíveis (console do CloudFront, API do CloudFront, CLI, ou CloudWatch) para medir individualmente as métricas operacionais da cópia da distribuição e da distribuição primária. É possível medir o critério de sucesso de sua aplicação específica ao mensurar e comparar o throughput, a latência e as métricas de disponibilidade entre as duas distribuições.

Sim, você pode usar quaisquer distribuições existentes como base para criar uma cópia de distribuição e conduzir as alterações de teste.

Com a implantação contínua, você pode associar funções diferentes às cópias de distribuições e distribuições primárias. Você também pode usar a mesma função em ambas as distribuições. Se você atualizar uma função que é usada em ambas as distribuições, todas elas receberão a atualização.

Cada recurso em seu CloudFormation é mapeado para um recurso específico da AWS. Uma cópia de distribuição terá seu próprio ID do recurso e funcionará como qualquer outro recurso da AWS. Você pode usar o CloudFormation para criar/atualizar esse recurso.

Quando você usa uma configuração baseada em peso percentual para direcionar o tráfego para uma cópia de distribuição, também é possível ativar a aderência da sessão, o que ajuda a garantir que o CloudFront tratará as requisições do mesmo visualizador como uma única sessão. Quando você habilita a aderência da sessão, o CloudFront define um cookie para que todas as requisições de um mesmo visualizador em uma única sessão sejam correspondidas a uma distribuição, seja ela primária ou uma cópia.

O recurso de implantação contínua está disponível em todos os locais da borda do CloudFront sem custo adicional.

Cada servidor e dispositivo conectado à Internet deve ter um endereço IP (Internet Protocol) numérico. O crescimento exponencial da Internet e do número de pessoas que a usam aumenta a necessidade por endereços IP. O IPv6 é uma nova versão do Internet Protocol que usa um tamanho de endereço maior do que o seu predecessor, o IPv4. No IPv4, cada endereço IP tem 32 bits, o que permite a criação de 4,3 bilhões de endereços exclusivos. Um exemplo de endereço IPv4 é 192.0.2.1. Em comparação, os endereços IPv6 têm 128 bits, o que permite a criação de aproximadamente 340 trilhões de endereços IP exclusivos. Um exemplo de endereço IPv6 é: 2001:0db8:85a3:0:0:8a2e:0370:7334

Ao usar a compatibilidade com o IPv6 do Amazon CloudFront, suas aplicações podem se conectar a locais da borda do Amazon CloudFront sem precisar de nenhum software ou sistema de conversão de IPv6 para IPv4. Você pode atender aos requisitos de adoção do IPv6 definidos pelos governos, inclusive os do governo federal dos EUA, e beneficiar-se da extensibilidade, da simplicidade de gerenciamento de redes e da compatibilidade integrada adicional para segurança do IPv6.

Não. Você obterá a mesma performance ao usar o IPv4 ou o IPv6 com o Amazon CloudFront.

Todos os recursos atuais do Amazon CloudFront continuarão a funcionar no IPv6, embora existam duas alterações necessárias a fazer para o processamento interno do endereço IPv6 antes de ativá-lo para as suas distribuições.

1. Caso tenha ativado o recurso Amazon CloudFront Access Logs, você começará a ver o endereço IPv6 do seu visualizador no campo “c-ip”, e talvez precise verificar se os seus sistemas de processamento de logs continuam a funcionar para o IPv6.
2. Ao habilitar o IPv6 para a sua distribuição do Amazon CloudFront, você obterá endereços IPv6 no cabeçalho X-Forwarded-For enviado às suas origens. Se os seus sistemas de origem só puderem processar endereços IPv4, talvez seja necessário verificar se os seus sistemas de origem continuam a funcionar para o IPv6.

Além disso, se você usar listas brancas de IP para assinantes confiáveis, deverá usar uma distribuição somente de IPv4 para os URLs do seu assinante confiável com listas brancas de IP, além de uma distribuição de IPv4/IPv6 de todo o restante do conteúdo. Este modelo evita um problema que surgiria se a solicitação de assinatura fosse recebida via endereço IPv4 e fosse assinada como tal, o que faria com que a solicitação de conteúdo fosse recebida por meio de um endereço IPv6 diferente que não consta na lista de permissões.

Para saber mais sobre a compatibilidade com o IPv6 no Amazon CloudFront, consulte “IPv6 support on Amazon CloudFront” no Guia do desenvolvedor do Amazon CloudFront.

Não. Se você desejar usar o IPv6 e os URLs de signatário confiável com a lista branca de IP, será necessário usar duas distribuições separadas. Você deve dedicar uma distribuição exclusivamente aos seus URLs de assinante confiável com lista branca de IP e desabilitar o IPv6 para essa distribuição. Depois, use outra distribuição para todo o restante do conteúdo, o que funcionará com o IPv4 e o IPv6.

Sim. Os endereços IPv6 do seu visualizador agora serão exibidos no campo “c-ip” dos logs de acesso, se o recurso Amazon CloudFront Access Logs estiver habilitado. Verifique se os seus sistemas de processamento de logs continuam a funcionar para os endereços IPv6 antes de ativar o IPv6 para as suas distribuições. Entre em contato com o suporte ao desenvolvedor se tiver problemas com o impacto do tráfego do IPv6 na capacidade da sua ferramenta ou do seu software de administrar endereços IPv6 nos logs de acesso. Para obter mais detalhes, consulte a documentação do Amazon CloudFront Access Logs.

Sim. Para distribuições novas e atuais, é possível usar o console do Amazon CloudFront ou a API para habilitar/desabilitar o IPv6 por distribuição.

Durante conversas com os clientes, o único caso comum do qual tivemos conhecimento foi o processamento interno de endereços IP. Ao habilitar o IPv6 para a sua distribuição do Amazon CloudFront, além de obter um endereço IPv6 nos seus logs de acesso detalhados, você obterá endereços IPv6 no cabeçalho X-Forwarded-For enviado para as suas origens. Se os seus sistemas de origem só puderem processar endereços IPv4, verifique se os seus sistemas de origem continuam a funcionar para endereços IPv6 antes de ativá-lo para as suas distribuições.

O Amazon CloudFront tem uma conectividade bastante diversa no mundo inteiro, mas ainda existem algumas redes em a que conectividade IPv6 não está 100% presente. Embora o futuro em longo prazo da Internet seja obviamente o IPv6, no futuro próximo, cada endpoint na Internet terá conectividade IPv4. Quando encontrarmos partes da internet que tenham uma conectividade IPv4 melhor do que a IPv6, nossa preferência será a IPv4.

Sim. Você pode criar registros de alias do Route 53 indicando a sua distribuição do Amazon CloudFront para apoiar o IPv4 e o IPv6 usando os tipos de registro “A” e “AAAA”, respectivamente. Se você desejar habilitar apenas o IPv4, será necessário apenas um registro de alias do tipo “A”. Para obter detalhes sobre os conjuntos de registros de recursos de alias, consulte o Guia do desenvolvedor do Amazon Route 53.

A partir de 1.º de dezembro de 2021, todos os clientes da AWS terão 1 TB de transferência de dados de saída, 10 milhões de solicitações HTTP/HTTPS e 2 milhões de invocações do CloudFront Functions todo mês, gratuitamente. Todos os outros tipos de uso (p. ex., invalidações, solicitações de proxy, Lambda@edge, Origin Shield, transferências de dados para a origem etc.) estão excluídos do nível gratuito.  

Não, os clientes que usam o faturamento consolidado para consolidar o pagamento de várias contas terão acesso a apenas um nível gratuito por organização.

Os limites mensais do nível gratuito são 1 TB de transferência de dados e 10 milhões de solicitações em todos os locais da borda. Se seu uso exceder os limites mensais do nível gratuito, você pagará simplesmente as taxas de serviço da AWS sob demanda padrão em cada região. Consulte a página de preços do AWS CloudFront para obter todos os detalhes de preços.

Para ver a atividade de uso atual e anterior por região, entre na sua conta e vá para o painel do Gerenciamento de Faturamento e Custos. No painel, você pode gerenciar os custos e o uso com o AWS Budgets, visualizar os geradores de custos e as tendências de uso no Explorador de Custos e analisar mais profundamente os custos usando os Relatórios de Custos e Uso. Para saber mais sobre como controlar seus custos na AWS, confira o tutorial Controlar os custos da AWS, que dura dez minutos.

Clientes que assinam o Pacote Promocional de Segurança do CloudFront também terão o benefício do nível gratuito. Se você precisar reduzir seu compromisso com o Pacote Promocional de Segurança do CloudFront em função do nível gratuito, entre em contato com nosso serviço de atendimento ao cliente e avaliaremos seu pedido. Divulgaremos mais detalhes sobre esse tópico em alguns dias. Fique atento. 

Caso tenha alguma pergunta, acesse https://aws.amazon.com/free/free-tier-faqs/.

As cobranças do Amazon CloudFront consideram o uso efetivo do serviço em cinco áreas: transferência de dados de saída, solicitações HTTP/HTTPS, solicitações de invalidação, solicitações de log em tempo real e certificados SSL personalizados com IP dedicado associados a uma distribuição do CloudFront.

Com o nível de uso gratuito da AWS, você pode começar a usar o Amazon CloudFront gratuitamente e manter os custos baixos à medida que seu uso cresce. Todos os clientes do CloudFront recebem gratuitamente 1 TB de transferência de dados de saída e 10 milhões de solicitações HTTP e HTTPS para o Amazon CloudFront, mesmo quando esses limites são excedidos. Se 

• Transferência de dados para a Internet
  Você é cobrado pelo volume de dados transferidos para fora dos pontos de presença do Amazon CloudFront, medidos em GB. Você pode ver aqui as taxas de transferência de dados do Amazon CloudFront para a Internet. Observe que o seu uso de transferência de dados é totalizado separadamente por regiões geográficas específicas. O custo é calculado de acordo com os níveis de definição de preço em cada área. Se você usar outros serviços da AWS como origem de arquivos, será cobrado separadamente pelo uso desses serviços, inclusive armazenamento e horas de computação. Se você usa uma origem da AWS (como o Amazon S3, Amazon EC2 e assim por diante), desde 1.º de dezembro de 2014 que não cobramos pela transferência de dados da AWS para o Amazon CloudFront. Isso se aplica à transferência de dados de todas as regiões da AWS para todos os locais da borda globais do CloudFront.
• Transferência de dados para fora (origem)
  Você será cobrado pelo volume de dados transferidos, medido em GB, dos locais da borda do Amazon CloudFront para a sua origem (tanto origens da AWS como outros servidores de origem). As taxas de transferência de dados do Amazon CloudFront para a origem podem ser consultadas aqui.
• Solicitações HTTP/HTTPS
  Você será cobrado pelo número de solicitações HTTP/HTTPS feitas ao Amazon CloudFront para o seu conteúdo. Você pode verificar as taxas para solicitações HTTP/HTTPS aqui.
• Solicitações de invalidação
  Você será cobrado por caminho na solicitação de anulação. Um caminho listado na solicitação de anulação representa o URL (ou vários URLs, se o caminho contém um caractere curinga) do objeto que você deseja anular no cache do CloudFront. Você pode solicitar até 1.000 caminhos por mês do Amazon CloudFront sem nenhum custo adicional. Após os primeiros 1.000 caminhos, você será cobrado por caminho listado nas solicitações de anulação. Você pode verificar as taxas das solicitações de invalidação aqui.
• Solicitações de logs em tempo real
  Os logs em tempo real são cobrados de acordo com o número de linhas que forem geradas. Você paga 0,01 USD por cada 1.000.000 de linhas de log que o CloudFront publicar no destino do log.
• IP dedicado SSL personalizado
  Você paga USD 600 por mês para cada certificado SSL personalizado associado com uma ou mais distribuições do CloudFront usando a versão com IP dedicado do suporte de certificado SSL personalizado. Essa tarifa mensal é rateada por hora. Por exemplo, se você tiver um certificado SSL personalizado associado a pelo menos uma distribuição do CloudFront por apenas 24 horas (ou seja, um dia) no mês de junho, seu custo total pelo uso do recurso de certificado SSL personalizado em junho será (1 dia/30 dias) * 600 USD = 20 USD. Para usar o suporte ao certificado SSL customizado com IP dedicado, faça o upload de um certificado SSL e use o Console de Gerenciamento da AWS para associá-lo às suas distribuições do CloudFront. Se você precisar associar mais de dois certificados SSL personalizados à sua distribuição do CloudFront, informe os detalhes do seu caso de uso e o número de certificados SSL personalizados que pretende usar no formulário de aumento de limite do CloudFront.

Os níveis de uso da transferência de dados são medidos separadamente para cada região geográfica. Os preços listados acima não incluem taxas aplicáveis, tarifas ou cobranças governamentais similares, caso exista alguma, salvo indicação em contrário.

Salvo indicação em contrário, nossos preços excluem impostos e taxas aplicáveis, incluindo o IVA e o imposto de vendas aplicável. Para clientes com endereço de pagamento no Japão, o uso da AWS está sujeito ao imposto sobre consumo japonês. Saiba mais.

Se você tiver uma distribuição atendendo a mil solicitações por segundo com um tamanho de log de 1 KB e criar um Kinesis Data Stream no Leste dos EUA (Ohio) com dois fragmentos:

Custo mensal do Kinesis Data Stream: USD 47,74/mês, conforme calculado usando a calculadora do Kinesis aqui.

Custo mensal dos logs em tempo real do CloudFront: solicitações por mês X custo dos logs em tempo real = 1.000 * (60 s * 60 min *24 h * 30 dias) X (USD 0,01/1.000.000) = USD 25,92/mês

304 é uma resposta a uma solicitação GET condicional e resultará em uma cobrança pela solicitação HTTP/HTTPS e pela transferência de dados para a internet. Uma resposta 304 não contém um corpo de mensagem; no entanto, os cabeçalhos HTTP consomem largura de banda, razão pela qual serão cobradas taxas padrão de transferência de dados do CloudFront. O volume de transferência de dados depende dos cabeçalhos associados ao seu objeto.

Sim, as classes de preços fornecem a você uma opção para reduzir os preços que você paga para entregar conteúdo fora do Amazon CloudFront. Por padrão, o Amazon CloudFront minimiza a latência de usuário final ao entregar conteúdo de toda a sua rede global de pontos de presença. No entanto, como cobramos mais onde nossos custos são maiores, isso significa que você pagará mais para entregar seu conteúdo com baixa latência para usuários finais em alguns locais. As classes de preço permitem reduzir os preços da entrega excluindo os pontos de presença do Amazon CloudFront mais caros da sua distribuição do Amazon CloudFront. Nesses casos, o Amazon CloudFront fornecerá seu conteúdo a partir de pontos de presença nos locais na classe de preço que você selecionou e cobrará a definição de preços da transferência e solicitação de dados da região real onde o conteúdo foi entregue.

Se a performance for o mais importante, você não precisará fazer nada; seu conteúdo será entregue por toda a nossa rede de locais. No entanto, se você desejar usar outra classe de preço, poderá configurar sua distribuição por meio da API do Amazon CloudFront ou do Console de Gerenciamento da AWS. Se você selecionar uma classe de preço que não inclua todos os locais, alguns de seus visualizadores, especialmente aqueles em locais geográficos que não estiverem em sua classe de preço, poderão experimentar maior latência do que se seu conteúdo estivesse sendo fornecido de todas as regiões do Amazon CloudFront.

Note que o Amazon CloudFront pode ainda ocasionalmente atender solicitações para seu conteúdo de um ponto de presença em um local não incluído na sua classe de preço. Quando isso ocorrer, serão cobradas apenas as taxas para o local menos caro na sua classe de preço.

Você pode consultar a lista de locais que compõem cada classe de preço aqui.

O Pacote Promocional de Segurança do CloudFront é um plano flexível de preços de autoatendimento que ajuda você a economizar até 30% na sua fatura do CloudFront em troca de um compromisso com uma quantidade consistente de uso mensal (por exemplo, USD 100/mês) por um período de um ano.  Como benefício adicional, está incluído sem custo adicional o AWS WAF (Web Application Firewall), o que representa até 10% do valor investido no plano, para proteger os seus recursos do CloudFront.  Por exemplo, assumir um compromisso de 100 USD de uso do CloudFront por mês cobriria um valor de 142,86 USD de uso do CloudFront, o que representa uma economia de 30% em comparação com as taxas padrão. Além disso, até 10 USD de uso do AWS WAF está incluído para proteger seus recursos do CloudFront sem custo adicional a cada mês (até 10% do seu compromisso com o CloudFront).  As cobranças padrão do CloudFront e do AWS WAF aplicam-se a qualquer uso acima do valor coberto pelo seu compromisso de gastos mensais.  À medida que seu uso crescer, você poderá comprar pacotes de economia adicionais para obter descontos sobre o uso incremental. 

Ao comprar um Pacote Promocional de Segurança do CloudFront, você terá uma economia de 30% que aparecerá na parte de serviços do CloudFront de sua fatura mensal, compensando qualquer tipo de uso faturado pelo CloudFront, incluindo transferência de dados de saída e para a origem, taxas de solicitação de HTTP/S, solicitações de criptografia em nível de campo, Origin Shield, invalidações, IP dedicado, SSL personalizado, IPs estáticos Anycast, Lambda@Edge, CloudFront Functions, logs em tempo real, uso de cache de borda regional, gRPC, suporte ao WebSocket e outros recursos do CloudFront. Você também receberá benefícios adicionais que ajudam a cobrir o uso do AWS WAF associado às suas distribuições do CloudFront.

Você pode começar a usar o Pacote Promocional de Segurança do CloudFront acessando o console do CloudFront para obter recomendações sobre o valor do compromisso com base no histórico do uso do CloudFront e do AWS WAF, ou inserindo seu próprio uso mensal estimado. Você obtém uma comparação entre os custos mensais do Pacote Promocional de Segurança do CloudFront com os custos sob demanda e vê as economias estimadas para ajudar a escolher o plano certo para as suas necessidades.  Depois de se inscrever em um Pacote CloudFront Security Savings, você será cobrado seu compromisso mensal e verá créditos aparecerem compensando suas cobranças de uso do CloudFront e do WAF.  As cobranças de serviços padrão aplicam-se a qualquer uso acima do valor coberto pelo seu compromisso de gastos mensais. 

Quando o período do Pacote Promocional de Segurança do CloudFront expirar, as cobranças de serviço padrão serão aplicadas ao uso do CloudFront e do AWS WAF.   O compromisso mensal do Pacote CloudFront Security Savings não será mais faturado, e seus benefícios não serão mais aplicáveis.  A qualquer momento antes da expiração do período do pacote, você poderá optar por renovar automaticamente o Pacote Promocional de Segurança do CloudFront por outro período de um ano.

O Pacote Promocional de Segurança do CloudFront pode ser adquirido em qualquer conta dentro de uma família AWS Organization/faturamento consolidado.   Os benefícios do Pacote CloudFront Security Savings são aplicados como créditos à sua fatura. Os benefícios fornecidos pelo Pacote Promocional são aplicáveis para uso em todas as contas dentro de uma família AWS Organization/Faturamento Consolidado por padrão (o compartilhamento de crédito está ativado) e depende de quando a conta de assinatura ingressa em uma organização ou sai dela.  Consulte AWS Credits para saber mais como os créditos da AWS se aplicam a contas únicas e múltiplas.

Sim, você poderá comprar Pacotes Promocionais de Segurança do CloudFront adicionais à medida que seu uso aumentar para obter descontos no uso incremental.   Todos os Pacotes Promocionais de Segurança do CloudFront ativos serão levados em consideração ao calcular sua fatura da AWS.

Suas cobranças mensais de compromisso aparecerão em uma seção separada do Pacote de Segurança do CloudFront na sua fatura.  O uso coberto pelo Pacote Promocional de Segurança do CloudFront aparecerá nas partes do CloudFront e do WAF como créditos da sua fatura para compensar suas cobranças de uso padrão.  

Sim, o AWS Budgets permite que você defina limites de custo e uso e receba notificações por e-mail ou tópico do Amazon SNS quando suas cobranças reais ou previstas excederem o limite.  Você pode criar um orçamento personalizado da AWS filtrado para o serviço do CloudFront e definir o limite de orçamento para o uso sob demanda do CloudFront coberto pelo seu Pacote Promocional de Segurança do CloudFront, a fim de ser notificado assim que esse limite for excedido.   Para obter mais informações sobre orçamentos, consulte Managing your costs with AWS Budgets e Creating a budget no Guia do usuário do Gerenciamento de Faturamento e Custos da AWS. 

Como um benefício adicional do Pacote Promocional de Segurança do CloudFront, o uso do AWS WAF, até 10% do valor do plano comprometido para proteger os recursos do CloudFront, está incluído sem custo adicional. As cobranças padrão do CloudFront e do AWS WAF aplicam-se a qualquer uso além do coberto pelo Pacote Promocional de Segurança do CloudFront.  Regras gerenciadas do WAF assinadas por meio do AWS Marketplace não são cobertas pelo Pacote Promocional de Segurança do CloudFront. 

Você só poderá assinar um deles.  Entre em contato com seu gerente de contas da AWS se tiver dúvidas sobre seu contrato de preço personalizado.

Você pode assinar o Pacote Promocional de Segurança do CloudFront somente por meio do console do CloudFront.  Vamos avaliar a possibilidade de disponibilizá-lo via API como um aprimoramento futuro.