Trabalhando na suposição de que o tempo de download (e, portanto, o uso da largura de banda) é seu fator limitador, eu faria as seguintes sugestões:
Primeiro, escolha instâncias m1.large. Dos três 'níveis' de desempenho de E / S (que inclui largura de banda), as instâncias m1.large e m1.xlarge oferecem desempenho 'alto' de E / S. Como sua tarefa não é vinculada à CPU, a menos cara delas será a escolha preferível.
Em segundo lugar, sua instância poderá fazer o download muito mais rapidamente do que qualquer site pode exibir páginas - não faça o download de uma única página de cada vez em uma determinada instância, execute a tarefa simultaneamente - você poderá fazer pelo menos 20 páginas simultaneamente (embora , Eu acho que você provavelmente pode fazer 50-100 sem dificuldade). (Pegue o exemplo do download de um fórum a partir do seu comentário - que é uma página dinâmica que levará tempo para o servidor gerar - e há outros usuários usando a largura de banda desses sites etc.). Continue aumentando a simultaneidade até atingir os limites da largura de banda da instância. (Obviamente, não faça várias solicitações simultâneas para o mesmo site).
Se você realmente está tentando maximizar o desempenho, considere iniciar instâncias em zonas geograficamente apropriadas para minimizar a latência (mas isso exigiria a localização geográfica de todos os seus URLs, o que pode não ser prático).
Uma coisa a observar é que a largura de banda da instância é variável, às vezes você obtém um desempenho mais alto e, outras vezes, obtém um desempenho mais baixo. Nas instâncias menores, a variação no desempenho é mais significativa porque os links físicos são compartilhados por mais servidores e qualquer um deles pode diminuir a largura de banda disponível. Entre instâncias m1.large, dentro da rede EC2 (mesma zona de disponibilidade), você deve aproximar-se da taxa de transferência teórica de gigabits.
Em geral, com a AWS, é quase sempre mais eficiente usar uma instância maior do que várias instâncias menores (a menos que você esteja olhando especificamente para algo como failover, etc., onde você precisa de várias instâncias).
Não sei o que sua configuração implica, mas quando eu tentei isso anteriormente (entre 1 e 2 milhões de links, atualizado periodicamente), minha abordagem foi manter um banco de dados dos links, adicionando novos links à medida que foram encontrados e processando processos raspar e analisar as páginas. Um URL seria recuperado (aleatoriamente) e marcado como em andamento no banco de dados, o script baixaria a página e, se bem-sucedido, marcaria o URL como baixado no banco de dados e enviaria o conteúdo para outro script que analisasse a página, novos links foram adicionados ao banco de dados à medida que foram encontrados. A vantagem do banco de dados aqui era a centralização - vários scripts podiam consultar o banco de dados simultaneamente e (desde que as transações fossem atômicas), era possível garantir que cada página fosse baixada apenas uma vez.
Alguns pontos adicionais de menção - existem limites (acredito 20) para o número de instâncias sob demanda que você pode executar em uma vez - se você planeja exceder esses limites, precisará solicitar à AWS que aumente sua conta limites. Seria muito mais econômico executar instâncias spot e aumentar seus números quando o preço spot for baixo (talvez uma instância sob demanda para manter tudo organizado e as instâncias spot restantes).
Se o tempo tiver uma prioridade mais alta do que o custo para você, as instâncias de computação do cluster oferecem largura de banda de 10 Gbps - e devem gerar a maior largura de banda de download.
Recapitulando: tente algumas instâncias grandes (em vez de muitas instâncias pequenas) e execute vários downloads simultâneos em cada instância - adicione mais instâncias se a largura de banda for limitada, vá para instâncias maiores se você estiver com CPU / memória ligada.