La prémisse de base de votre configuration semble correcte, cependant, il y a quelques éléments que vous voudrez peut-être prendre en compte.
Tout d'abord, la bande passante du réseau EC2 (et I/O) dépend du type d'instance. Si vous espérez utiliser des instances t1.micro, ne vous attendez pas à une "connectivité Internet super rapide" - même avec un m1.small, vous pourriez ne pas obtenir les performances recherchées. Gardez également à l'esprit que vous payez pour la bande passante utilisée sur EC2 (et pas seulement pour le temps d'instance).
En ce qui concerne votre premier point, il ne devrait pas y avoir de réelle difficulté à configurer Python sur une instance EC2. Cependant, la difficulté potentielle réside dans la coordination de vos instances. Par exemple, si vous avez 2 instances en cours d'exécution, comment allez-vous diviser la tâche entre elles? Comment chaque instance 'saura' ce que l'autre a fait (en supposant que vous ne partitionnerez pas manuellement une liste d'URL). De plus, si vous lancez une instance, l'une des instances EC2 sera-t-elle responsable de cela ou votre machine locale s'en chargera-t-elle (si c'est l'une des instances EC2, comment déterminez-vous quelle instance sera responsable de la tâche (c'est-à-dire pour empêcher que la tâche de 'lancement' ne soit exécutée par chaque instance) et comment redistribuer les tâches pour inclure la nouvelle instance? Comment déterminez-vous quelles instances terminer automatiquement?
Indubitablement, tout ce qui précède est possible (corosync/heartbeat, pacemaker, auto-scaling, etc.) mais facile à négliger initialement. Quoi qu'il en soit, si vous cherchez le 'meilleur prix', vous voudrez probablement opter pour des instances spot (par opposition aux instances à la demande), cependant, pour que cela fonctionne, vous avez besoin d'une architecture assez robuste. (Il convient de noter que les prix des instances spot fluctuent considérablement - parfois supérieurs au prix à la demande; en fonction de l'échelle de temps sur laquelle vous travaillez, vous voudrez soit définir un prix spot maximum bas, soit déterminer la meilleure approche (spot / à la demande) régulièrement (horairement) pour minimiser vos coûts.) Même si je ne peux pas le confirmer pour le moment, la solution la plus simple (et la moins chère) pourrait être l'auto-scaling AWS. Vous devez configurer des alarmes Cloudwatch (Cloudwatch fournit 10 alarmes gratuites) et l'auto-scaling lui-même n'a pas de coût associé (autre que le coût des nouvelles instances et les coûts Cloudwatch).
Étant donné que je n'ai vraiment aucune idée de l'ampleur de votre entreprise, je pourrais demander pourquoi ne pas simplement utiliser EC2 pour l'analyse et le traitement. Surtout si l'analyse est complexe, les pages peuvent être récupérées plus rapidement qu'elles ne peuvent être traitées, et vous avez un grand nombre de pages (présumément, sinon vous ne vous donneriez pas la peine de configurer AWS), il pourrait être plus efficace de simplement traiter les pages sur EC2, et quand tout est terminé, télécharger un export de la base de données. On pourrait soutenir que cela simplifierait un peu les choses - avoir une instance exécutant MySQL (avec les données stockées sur un volume EBS), chaque instance interroge l'instance MySQL pour le prochain ensemble d'enregistrements (et peut-être les marque comme réservés), récupère et traite, et enregistre les données dans MySQL.
Si vous n'allez pas exécuter MySQL sur EC2, vous pouvez soit stocker vos fichiers HTML sur S3, comme vous l'avez mentionné, soit choisir de les sauvegarder sur un volume EBS. L'avantage de S3 est que vous n'avez pas besoin de pré-allouer du stockage (particulièrement utile si vous ne connaissez pas la taille des données avec lesquelles vous travaillez) - vous payez pour les PUTs/GETs et le stockage; l'inconvénient est la vitesse - S3 n'est pas conçu pour être utilisé comme un système de fichiers, et (même si vous pouvez le monter comme un système de fichiers) ce serait assez inefficace de sauvegarder chaque fichier individuel sur S3 (vous voudrez rassembler quelques pages avant de les télécharger sur S3). De plus, si vous avez un grand nombre de fichiers (des dizaines de milliers), le traitement de la récupération de tous les noms de fichiers, etc. peut être lent. Les volumes EBS sont conçus pour être utilisés comme stockage attaché à une instance - l'avantage réside dans la vitesse - taux de transfert et le fait qu'il a un 'système de fichiers' (donc la lecture d'une liste de fichiers, etc. est rapide) - les volumes EBS persistent au-delà de la terminaison de l'instance (sauf pour les volumes racine EBS, qui ne le sont pas par défaut (mais peuvent l'être)). Les inconvénients des volumes EBS sont que vous devez pré-allouer une quantité de stockage (qui ne peut pas être modifiée à la volée) - et vous payez pour cette quantité de stockage (peu importe si tout est utilisé); vous payez également pour les opérations I/O (en outre, la performance des volumes EBS dépend de la vitesse du réseau - donc les instances plus grandes obtiennent de meilleures performances EBS). L'autre avantage des EBS est que, étant un système de fichiers, vous pouvez effectuer une tâche comme la compression des fichiers très facilement (et j'imagine que si vous téléchargez beaucoup de pages HTML vous ne voudrez pas récupérer des fichiers individuels de S3 plus tard).
Je ne vais pas vraiment spéculer sur les possibilités (en gardant à l'esprit qu'à très grande échelle, quelque chose comme map-reduce/hadoop serait utilisé pour gérer ce genre de tâche), mais tant que vous avez une approche pour partitionner la tâche (par exemple, instance MySQL) et gérer la mise à l'échelle des instances (par exemple, auto-scaling), l'idée que vous avez devrait bien fonctionner.
