Estamos veiculando vídeos de um bucket S3 (em Mumbai) para usuários em uma única região (Índia). Esperamos que milhares de usuários acessem esses arquivos apenas na Índia. Vale a pena ter uma distribuição CloudFront? A latência seria reduzida se estivéssemos usando o CloudFront? O S3 pode lidar com a largura de banda se não estivermos usando o CloudFront?
Obrigado pela ajuda.
Responder1
Do ponto de vista do desempenho, sim, provavelmente é útil.
O CloudFront tem atualmente cinco pontos de presença na Índia (Chennai (2), Nova Delhi (1) e Mumbai (2)), portanto, isso sugere que latências mais baixas são possíveis usando o CloudFront simplesmente porque seu conteúdo provavelmente estará mais próximo dos usuários ( dependendo da sua distribuição geográfica)...
No entanto, há um custo premium no CloudFront de US$ 0,17/GB baixado de pontos de presença na Índia, em comparação com US$ 0,1093/GB baixado diretamente do S3 em Mumbai. (Ao usar o CloudFront + S3, a cobrança bamdwidth do S3 não se aplica).
Então, sim, “útil”, mas não é possível dizer se é suficientemente útil para justificar o custo nesta região geográfica específica.
S3 temdiretrizes de melhores práticaspara buckets que antecipam taxas de solicitação superiores a 800 (pico) ou 300 GETsolicitações (mantidas) por segundo quando o CloudFront também não é usado. O serviço será dimensionado além desses valores, mas seguir as diretrizes ajuda a dimensioná-lo de maneira mais eficaz. (As teclas de atalho e os pontos de acesso do índice não são tão facilmente escalonáveis quanto as chaves bem distribuídas). Para taxas de solicitação abaixo de 100 req/s, não são necessárias considerações especiais.
Uma opção adicional éAceleração de transferência S3, que roteia seletivamente solicitações pela "rede Edge" da AWS (em outras palavras, o CloudFrontRede de transporte) sem nenhum cache real. Em Mumbai, isso custa US$ 0,04/GB + US$ 0,1093/GB para downloads. A vantagem aqui é que o navegador está potencialmente se conectando a um servidor em um ponto de presença, que faz o proxy da conexão de lá para o S3. Isso faz com que o tráfego percorra a maior distância possível na rede AWS antes de ser transferido para a Internet pública, o que pode melhorar significativamente os tempos de transferência, otimizando a transferência e lidando com a perda de pacotes em um local intermediário mais próximo do visualizador. Quando o S3 Transfer Acceleration é usado, a lógica DNS que o CloudFront usa para enviar solicitações para a borda mais próxima é usada para determinar a melhor maneira de conectar um determinado visualizador de volta à região S3 – para que ele possa conectar o usuário diretamente ao S3 ( nesse caso, não será cobrada a taxa de largura de banda de US$ 0,04/GB pelo recurso de aceleração dessa solicitação) ou ela poderá ser encaminhada através da Edge Network (nesse caso, você o fará). A ideia aqui é que o recurso se contorne automaticamente para solicitações nas quais provavelmente não ajudará, com base na geolocalização do solicitante em relação à do bucket. Ao ativar isso em um bucket, você também altera o endpoint do bucket para bucket-name.s3-accelerate.amazonaws.com. Ele suporta apenas a interface REST, não o recurso de hospedagem de sites, mas isso é bom se você não estiver usando recursos como redirecionamentos e documentos de índice. Dada a sua geografia e as peculiaridades do preço da largura de banda, este pode ser um bom lugar para começar.