Pourquoi ne devrais-je pas utiliser Amazon S3 pour l'hébergement d'une page Web statique
Je me souviens avoir lu quelque part qu'il était très difficile d'utiliser Amazon S3 pour héberger un site Web statique. J'ai oublié ce que c'était. Pour moi, S3 semble être une option parfaite. Super rapide, super évolutif et payant au fur et à mesure.
Quels sont les inconvénients de l'utilisation de S3 pour héberger un site web statique?
Je suis toujours sous le choc de lire que les gens partent du principe que les réseaux de distribution de contenu coûtent cher, la plupart ne coûtant que 0,20 centimes par Go.
Servir des sites Web statiques sur des CDN est incroyable: vous obtenez les performances d'un serveur dédié sans en payer le prix, de plus, vous disposez d'un serveur dans toutes les grandes régions du monde, si efficace qu'il vaut mieux qu'un serveur dédié pour la vitesse et l'évolutivité.
Il y a quelques problèmes majeurs lors de l'hébergement sur CDN, à savoir:
Aucun fichier PHP
Support PHP (vous auriez besoin d’utiliser des formulaires de contact via Ajax pour récupérer un contact.php d’ailleurs, les méthodes HTML sont nulles - si vous n’avez pas besoin de formulaire de contact, alors (génial!) Pour des commentaires comme ceux que vous pouvez utiliser, Disqus, qui est JavaScript.)
questions CNAME
Malheureusement, la plupart des CDN ne prennent pas en charge les CNAME non www, vous ne pouvez donc pas résoudre le domaine lorsque quelqu'un oublie www, ce n'est pas un problème majeur, mais vous pouvez contourner ce problème. Vous configurez un EC2 ou un hébergement partagé et vous le laissez gérer le non-www avec une redirection. Donc, chaque fois que quelqu'un oublie le www, il communique avec le serveur, puis redirige correctement vers le CDN. Une autre méthode consiste à choisir un CDN prenant en charge cette opération (mais je pense que Limelight le fait, mais pas Amazon et Rackspace). J'ai entendu dire que Limelight hébergeait le DNS et apportait des modifications manuellement sur son système. Je ne l'ai jamais fait moi-même, je ne peux donc pas confirmer si c'est le cas.
Mise à jour du conten
L’autre inconvénient est que vous devez purger le contenu ou les fichiers que vous avez modifiés. Par exemple, si vous apportez des ajouts à index.html, vous devez soit configurer une expiration courte sur le conteneur, soit purger manuellement ce fichier. le cache donc il se met à jour partout dans le monde.
Résumé
L'hébergement d'un site statique sur un CDN est une véritable fanatique - je gère une poignée de sites statiques sur un CDN et ils sont fanatiques, je n'utilise que 1 à 2 Go sur chaque site et je reçois une facture de 0,24 £ pour chaque site, ce qui est moins cher que hébergement mutualisé, et vous donne les performances d'un serveur dédié. Si vous allez configurer un petit VPS autre qu'un EC2 pour la redirection, tout VPS de 128 Mo le fera. Vous pouvez en obtenir un bon marché pour un dollar par mois. VPS Google 128 Mo ou VPS inférieur à 5 dollars par mois - des centaines d’entreprises utilisent des systèmes VPS à faible spécification pour les cacahuètes, ce qui fera l'affaire.
S3 n'est pas censé être le SEUL outil d'AWS pour l'hébergement de sites Web statiques. L'approche recommandée consiste à placer CloudFront devant l'instance S3 afin que CloudFront puisse gérer la mise en cache. Je pense que cela éliminera également votre problème de payer beaucoup pour une augmentation du trafic puisque CloudFront utilisera son cache pour servir les fichiers et non pour frapper S3. Bien sûr, vous devez payer CloudFront, mais le coût sera moindre (je pense).
Voici un article sur l'ajout de CloudFront à votre site S3:
http://docs.aws.Amazon.com/gettingstarted/latest/swh/getting-started-create-cfdist.html
Le problème réside dans la partie "paiement au fur et à mesure".
Si vous obtenez des tonnes de trafic (par exemple: une attaque DOS ou un article ou un fichier de blog très populaire), vous devrez payer pour cela.
Autant que je sache, il n’ya pas encore de fonction pour mettre un plafond à ce que vous payez. Vous pouvez définir des alertes de facturation, mais si votre facture atteint votre budget maximum, la seule option que vous avez est de fermer le site ou de payer pour tout le trafic que vous obtenez.
C'est en fait un peu cher en termes de bande passante. Jusqu'à récemment, ils avaient également un problème: vous ne pouviez pas mapper votre enregistrement @ et votre enregistrement wwwA sur votre site (vous avez donc accès à mydomain.com ou à www.mydomain.com). Ceci a cependant été corrigé dans une mise à jour très récente.
Personnellement, je pense qu'ils sont un peu trop chers et qu'il vous manque beaucoup de fonctionnalités de Nice (redirections, htaccess, etc.). S3 fonctionne bien pour l'hébergement de gros fichiers et d'images.