Perguntas frequentes sobre o Amazon CloudFront

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 ao URL 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 de VPC com o CloudFront

Se as soluções gerenciadas do CloudFront não atenderem aos seus requisitos de caso de uso, abaixo estão 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.thinkwithwp.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 nome 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 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 de 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 VPC de entrada (ingresso) e saída (egresso) 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, onde 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 de VPC privada. Com origens da VPC, você precisa de endereços IPv4 privados, que são gratuitos e não incorrem em cobranças de IPv4.

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, 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.

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 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.

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 Edge function logs.
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 real-time logs.
• 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.

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 Elasticsearch 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.