O S3 oferece excepcionalmente alta durabilidade e baixa sobrecarga de administração. O serviço em si não é tão barato assim (especialmente quando se trata de atender a pedidos), mas na maioria das vezes o custo de mão-de-obra de gerenciar alternativas reduz a economia de água. No entanto, em escalas muito grandes, a economia começa a superar a sobrecarga de gerenciamento.
Por exemplo:
Solicitações GET no S3 custam US $ 0,004 por 10.000 solicitações.
Um T2.micro pode fazer cerca de 180 Mbits / se custa US $ 0,013 / h. Assumindo um tamanho de imagem de 500kB (4000 kbits), isto é cerca de 46 imagens / s. Supondo que você possa saturar essa instância (que um serviço de compartilhamento de imagens em larga escala presumivelmente poderia), são cerca de 165 mil solicitações / hora.
Então, para um T2.micro, você custaria US $ 0,013 / h contra US $ 0,066 no S3. Na prática, você pode atingir outros gargalos em um T2.micro, de modo que o S3 provavelmente acabaria ligeiramente à frente nessa escala.
No entanto, se você pegar um c4.8xlarge (com rede de 10 Gbit), ele custaria US $ 1.763 / h. Com isso você poderia servir cerca de 2620 imagens / s, ou cerca de 9,4m / hora. Isso custaria US $ 3,76 / hora no S3. Adicione descontos para instâncias reservadas etc. e a diferença será ainda maior.
Além disso, você não pode transferir processos como o redimensionamento de imagens para o S3 e também pode querer executar uma camada de proteção contra DDoS ou WAF para reduzir os custos de largura de banda devido a ataques.
Dito isto, uma arquitetura comum é armazenar os originais no S3 (onde raramente serão acessados, mas onde a durabilidade é importante) e armazenar em cache as versões redimensionadas nos servidores front-end. Acredito que o Netflix usou ou não essa técnica (exceto que armazenaram os arquivos em cache em seu próprio hardware de cores). Não me surpreenderia se Imgur fizesse isso também.