4 astuces AWS que j'aurais aimé connaitre plus tôt

Si vous ne l'avez pas lu, je vous invite à découvrir mon article sur les services AWS que j'utilise le plus au quotidien sorti il y a quelques semaines, juste ici.

Au fil des années, et à force de tomber sur de nouvelles problématique lors de l'hébergement de mes projets, j'ai pris pour habitude de noter les astuces qui m'ont parfois sauvé la vie (en tout cas de nombreuses heures), et j'ai aujourd'hui décidé de vous les partager.

#1 - Du stockage gratuit

Si vous êtes comme moi, et que l'utilisation du Free Tier d'AWS est votre sport national, je sais que vous ne cracherez pas sur quelques Gigas de stockage gratuits.

Car oui, lorsque vous montez une instance EC2 (T2.micro) éligible à l'offre gratuite, Amazon vous incite à laisser la configuration par défaut en lançant l'instance avec un seul clic.

Mais si vous prenez le temps de regarder l'onglet stockage, vous verrez que la taille du volume par défaut est de 8Go, alors qu'il est possible de monter jusqu'à 30 Go tout en restant éligible à l'offre gratuite. C'est cadeau !

#2 - Plus de ram pour le même prix

Il n'est pas rare qu'une installation à l'intérieur d'une instance EC2 Micro soit interrompue pour manque de mémoire vive, notamment en passant par NPM, car oui 1Go de ram pour faire tourner le système et une installation prenant parfois plusieurs Go de stockage c'est trop peu.

La solution est simplement d'utiliser une partie des 22Go de stockage que vous venez de gagner avec l'astuce précédente pour la transformer en un fichier de swap.

Un fichier swap est un fichier d'extension de la mémoire utilisable par le système d'exploitation. Ses performances sont nécessairement moindre que la "vraie" mémoire vive et je ne conseille pas de s'appuyer dessus pour permettre à un programme de tourner de manière robuste, mais le temps d'une installation cela vous évite d'avoir à payer une instance plus performante !

Voilà un tutoriel simple pour mettre en place un fichier de swap sous linux : https://linuxize.com/post/create-a-linux-swap-file/

#3 - Une IP unique pour les gouverner toutes

Lorsque vous utilisez l'url (ou l'IP) fournie par EC2 pour votre instance, vous pouvez pensez que vous êtes à l'abris des ennuis en cas de redémarrage de l'instance... et bien pas du tout.

Si votre instance crash pour une raison quelconque, elle sera relancée oui, mais sous une IP (et donc une url) différente, générée par AWS.

La solution (gratuite) est donc d'assigner une IP fixe (disponible dans le menu EC2) à votre instance après avoir fini de la configurer. Ainsi, plus de problème d'instance inaccessible après un redémarrage intempestif !

#4 - Le bucket ou l'url, telle est la question

L'une de mes fonctionnalité préférée sur AWS est l'hébergement de site statique grâce à AWS S3 + Cloudfront.

Seulement, il arrive parfois que le site hébergé soit parfaitement accessible lors de la première visite, mais que vous tombiez sur une erreur de votre bucket (indiquant que la ressource n'existe pas) lorsque vous raffraichissez la page.

La solution est très simple, il suffit de ne PAS relier votre bucket à votre origine Cloudfront en cliquant sur le nom du bucket dans la liste déroulante, mais bel et bien de copier-coller l'url fournie par S3 lors de l'activation de l'hébergement statique sur le bucket.