Vous n'avez probablement pas besoin d'un serveur Web complet comme NGINX fonctionnant sur EC2 pour obtenir votre site web opérationnel. Si vous cherchez simplement à héberger un site Web statique, vous pouvez stocker tout le contenu dans S3 et l'héberger à partir de là.
Attendez, Je n'ai pas besoin d'un serveur ?
Si votre site n'utilise aucun traitement côté serveur (comme PHP), il suffit de stocker les fichiers sur S3, de configurer le compartiment pour héberger le site, et pointer votre DNS vers le bucket remplacera l'utilisation de NGINX ou Apache.
“Traitement côté serveur” est beaucoup moins large qu'il n'y paraît. Tout simplement parce que votre site Web est “statique” ne signifie pas qu'elle ressemble à une page GeoCities des années 90, sans JavaScript. Tout ça “statique” signifie que tous vos actifs (pages HTML, code JS, feuilles de style CSS) ne changent pas en réponse aux demandes. Avec des langages comme PHP, tout le traitement est effectué côté serveur ; si deux utilisateurs demandent leur page de profil, le serveur leur enverra des pages différentes. Cela ne peut pas être fait sur S3, donc si vous utilisez PHP, vous devrez configurer un vrai serveur Web. Cela s'applique notamment à WordPress, qui utilise PHP pour servir le contenu.
Cependant, il est de plus en plus courant que les sites Web soient de grandes applications JavaScript. Avec un framework comme React, tout ce qui doit être livré est un fichier bundle.js. C'est au client, et non au serveur, d'exécuter ce fichier et de lancer l'application. Des applications comme celle-ci peuvent être hébergées sur S3 sans problème. Cela ne supprime pas non plus votre backend, vous pouvez toujours faire communiquer votre application avec un serveur API et parler à une base de données, vous n'aurez plus qu'à authentifier les demandes provenant du client. Combiné avec AWS’s API Gateway et Lambda, vous n'aurez peut-être pas à exécuter un seul serveur EC2.
Ne vous laissez pas berner par la configuration simple pour les petits sites, S3 peut réduire vos coûts à quelques centimes par dollar, et parce qu'il n'y a pas de serveurs à craindre, il s'adapte parfaitement jusqu'à des millions de utilisateurs. Vous payez simplement des frais fixes pour la bande passante entrante et sortante, ainsi que tous les coûts associés pour Lambda, RDS ou tout autre service que vous utilisez avec votre application. Même pour les grandes entreprises déployant des applications de production, l'hébergement à partir de S3 est une option très viable et économique si votre application peut la prendre en charge.
S3 ne prend pas en charge HTTPS pour les sites Web statiques, ce qui constituerait une rupture, mais vous pouvez le placer derrière CloudFront (CDN d'AWS) qui, en plus d'améliorer la mise en cache et les performances, peut utiliser un domaine personnalisé avec HTTPS. . Il propose même un niveau gratuit plus généreux pour le transfert de données de 50 Go au lieu de 1 Go de S3.
CONNEXION : Premiers pas avec CloudFront d'AWS CDN
Configuration
Pour ce didacticiel, plutôt que de déployer une simple page HTML, nous allons déployer le projet de démarrage à partir de create-react-app, car il montre mieux le véritable potentiel de S3.
Après avoir exécuté le fil build, il nous reste les éléments suivants dans le dossier /build :
Ce dossier entier sera copié sur S3. Accédez à la console de gestion S3 et cliquez sur “Créer un compartiment.”
Donnez-lui un nom (il doit être unique parmi tous les comptes AWS) et cliquez sur “Suivant.” Vous pouvez activer la gestion des versions dans les options ici, mais il n'y a pas grand-chose d'autre à considérer. Cliquez sur “Suivant” à nouveau.
CONNEXES : Comment installer et configurer l'AWS CLI
Sur l'écran suivant, vous voudrez décocher “Bloquer tous les accès publics.” Ceci est activé par défaut pour empêcher les objets dans les compartiments d'être visibles sur Internet ouvert, ce qui rendrait votre compartiment inaccessible. AWS affichera un avertissement indiquant de le réactiver, sauf si vous utilisez des cas d'utilisation spécifiques et vérifiés,” tels que l'hébergement de sites Web statiques. Parce que c'est exactement ce que nous faisons, vous pouvez l'ignorer.
< p>Cliquez sur “Créer” sur le seau et ouvrez-le.
Vous pouvez faire glisser manuellement le contenu de votre dossier HTML dans le compartiment, mais une meilleure méthode consiste à utiliser l'AWS CLI pour synchroniser l'intégralité du dossier jusqu'à votre compartiment. La commande est assez simple :
aws s3 sync . s3://bucket-name
Maintenant, vous devriez voir le contenu de votre dossier dans le compartiment :
Une fois que tout est synchronisé, vous pouvez configurer le compartiment pour autoriser l'hébergement de sites Web. Dans l'onglet Propriétés, activez “Hébergement de site Web statique” et sélectionnez votre fichier d'index. Vous pouvez également sélectionner un fichier d'erreur pour montrer aux utilisateurs un 404 plus personnalisé.
Ceci s'active hébergement de site Web statique, mais n'accorde pas explicitement l'accès en lecture. Pour ce faire, vous devez ajouter la stratégie de compartiment suivante sous Autorisations > Règles relatives aux compartiments :
{ “Version”:”2012-10-17″, “Statement”:[{ “Sid”:”PublicReadGetObject”, “Effect”:”Allow”, “Principal”: “*”, “Action”:[“s3:GetObject”], “Resource”:[“arn:aws:s3:::example-bucket/*” ] } ] }
Ceci affichera un autre avertissement vous indiquant que l'accès public est activé. Vous pouvez à nouveau l'ignorer.
Votre bucket sera désormais visible depuis le point de terminaison suivant :
http://BUCKET-NAME.s3-website.REGION.amazonaws.com/
< img src="/wp-content/uploads/8409fc1b9403ee0be0d1f73d82603542.gif" />
Génial! Tout fonctionne correctement. Le client demande le compartiment, qui sert le fichier index.html, qui télécharge tous les actifs JS et CSS requis et affiche le logo React en rotation.
Cependant, ce point de terminaison n'est évidemment pas convivial, vous souhaiterez donc probablement configurer un domaine personnalisé pour votre site S3. La méthode la plus simple consiste à utiliser CloudFront pour traiter les demandes, qui est de toute façon le seul moyen de prendre en charge HTTPS. Si vous ne souhaitez pas utiliser CloudFront, vous pouvez configurer un domaine personnalisé à l'aide de Route 53 pour créer un alias vers le point de terminaison par défaut de votre compartiment.
Rendez-vous sur la console CloudFront. Sélectionnez “Créer une distribution,” et choisissez “Web” comme le genre. Sur l'écran suivant, sous “Nom de domaine d'origine,” sélectionnez votre compartiment S3 dans la liste déroulante. Assurez-vous également de cocher “Redirect HTTP to HTTPS.”
Plus bas, vous souhaiterez configurer votre domaine. Saisissez votre autre nom de domaine et sélectionnez “Custom SSL.” Demandez-en un à ACM ; la vérification peut prendre jusqu'à une demi-heure en fonction de votre fournisseur DNS, mais si vous utilisez Route 53, vous pouvez créer et vérifier l'enregistrement automatiquement en quelques minutes.
Après cela, cliquez sur “Créer une distribution” en bas et attendez environ 15 minutes pour que CloudFront règle tout. Une fois que c'est fait, vous pourrez visiter votre nom de domaine personnalisé et voir votre application servie directement à partir de S3.
Si vous souhaitez faciliter la gestion des versions, vous pouvez définir mettre en place un pipeline de déploiement automatisé avec AWS CodePipeline. Choisissez simplement le déploiement vers S3, et AWS déploiera automatiquement les mises à jour du code source, y compris les artefacts de build.
CONNEXES : Comment configurer un pipeline de déploiement automatisé pour un site Web S3