1°) Introduction

Je commence ici un dossier pour détailler les projets d’hébergements que je réalise sur AWS dans un but personnel. L’idée est d’abord de garder une trace de tout ce que je peux réaliser sur Amazon Web services. Comme je passe parfois de longue période de temps sans manipuler cette environnement, je cherche parfois à refaire ce que j’ai déjà fait auparavant, et c’est une perte de temps.

Ensuite, je voudrais me servir de cette espace pour me challenger et me lancer dans des projets de mises en service par rapport à des problématiques que je peux rencontrer dans mon travail où imaginer.

2°) Architecture de base

Pour les débuts du projet, je pars sur une architecture très classique d’une application web, en mode 3-tiers. On aura donc à minima, une zone frontal, une zone applicative, et une zone pour la base de données. Ca c’est valable pour des ressources qui se trouve sur des instances EC2. Lorsqu’on passe par des services (comme RDS ou DynamoDB pour les bases de données), on n’a pas besoin de s’en préoccuper au départ.

Avant de commencer la création de zone, la première chose à faire est la création d’au moins un VPC (ou Virtual Private Cloud). Il s’agit tout simplement d’une zone logique dédiée ou l’on mettra nos ressources. Pour les besoins de nos projets, un seul VPC suffira largement.

Pour la région du projet j’ai choisi de me positionner en France, sur la région de Paris. Bien que tous les services ne soient pas encore disponible pour notre région, les principaux le sont et me suffisent amplement pour l’instant.

La création d’un VPC est très simple : depuis le tableau de bord, cliquer sur VPC, puis sur « Your VPC’s » (oui je mets les termes anglais, je sais. Va falloir s’habituer ça va pas changer). La plage d’IP que j’ai choisi est 172.30.0.0/24, ce qui devrait me laisser suffisamment de places pour expérimenter, sans prendre direct une plage d’IP démentielle.

Ma liste de VPC une fois le nouveau créé, de son petit nom « Les Faëriens » dans cet exemple.

Attention : Quand je parle ici d’adresse IP, cela correspond à des adresses IP privées. C’est à dire qu’elles ne sont pas accessible directement depuis Internet. Je reviendrais sur ce point plus tard.

Ensuite, pour ‘acter’ ma séparation en tiers, je vais créer trois sous réseaux avec une plage d’adresse IP différente pour chacun, mais qui sera tiré du pool d’IP du VPC.
Pour cela, et toujours dans la partie « VPC Dashboard », cliquer sur « Subnets » et créer les trois sous-réseaux. A ce stade, laisser AWS choisir la zone de disponibilité. Préciser un nom, le VPC que vous avez créé, et le bloc d’adresses IP que vous réservez pour ce sous-réseaux.
Vous devriez obtenir quelque chose comme ceci :

Les trois sous-réseaux sont créés, et on voit l’ensemble des adresses IP disponibles pour chaque zones.

Maintenant que nous avons la base, on va pouvoir créer nos serveurs.

3°) Création d’instance EC2

La création d’une instance EC2 est très simple. Dans notre cas, nous allons créer deux instances « fixes » que nous activerons en cas de besoin où test. Des frais de stockage me seront facturés, mais cela me permet de conserver mes paramétrages et données sur les serveurs, de manière simples. Je détaillerais un peu plus loin l’utilisation d’instances « Spot » qui peuvent s’avérer extrêmement pratique pour monter rapidement des serveurs en plus et à pas cher du tout.

Puisque je parle de frais de stockage, je vais présenter un peu plus le coût estimé au mois de la solution que je veux mettre en place. A ce stade, je souhaite monter 2 instances EC2, une dans la zone front et l’autre dans la zone pour base de données. Je pars sur des instances disponible pour le free-tiers, et plutôt petit serveur, je n’ai absolument pas besoin de performances pour ce que je veux faire. Du coup, on part sur des serveurs t2.micro (2 VCPU, 1Go RAM, 8Gb de stockage, système d’exploitation linux).
Dans un cloud, on paye à l’usage, donc si on ne sert pas des ressources il faut prendre le réflexe de les éteindre pour alléger la facture (sinon ça peut vite monter).

3°2) La calculatrice Amazon

AWS propose un formulaire pour estimer le coût d’une infrastructure par mois en fonction de l’utilisation qu’on va en faire. C’est un outil indispensable pour se faire une idée en amont, mais je vous recommande fortement de garder toujours un œil sur la facturation de votre infrastructure dans le cloud AWS. Un oubli est vite arrivé et à des conséquences directes sur le porte monnaie !

Ici je prévois de faire tourner les serveurs au maximum 8h/jour et 30 jours par mois. Il s’agit de la fourchette haute, puisque je pense que j’utiliserais les ressources nettement moins que cela.
Je me dis aussi que je vais utiliser 2 adresses IP Elastic pour chacun de mes serveurs : problème, les IP Elastic sont facturés lorsqu’elles ne sont pas utilisées. Je vais déjà calculés combien ça va me coûter, on verra après.

NB : Les adresses IP Elastic sont des adresses IP publiques et fixes, que l’on attache à une instance EC2. C’est très utile pour accéder toujours au serveur lorsque celui-ci change d’adresse IP publique à chaque reboot.

On rentre tout ça dans le formulaire :

Saisie du formulaire pour avoir la facturation prévisionnelle

Chaque ajout de ligne ou modification de valeur entraîne la mise à jour de la facture (deuxième onglet en haut à gauche). En cliquant sur l’onglet « Estimate of your billing bills », on obtient le détail :

Détails des types de dépenses pour notre architecture.

Ici, avec la réduction lié au fait qu’on ait sur du free-tiers pour les ressources, on arrive à un total de 17,24$. En examinant la répartition, on voit que la facturation des adresses IP Elastic s’élève à 9.76$, soit plus de la moitié de la facture !!
Si on retire ce point, on arrive à une facture total de 9.92$ par mois pour deux serveurs, ce qui est plutôt correct.

NB: Il existe aujourd’hui (29/03/2019) le AWS Pricing Calculator. Je ne l’ai pas testé encore, mais je ne vois pas trop la différence avec le formulaire en ligne présentés ici. Peut être que ce sera à terme son remplaçant, mais pour l’instant, le service est encore en phase de béta.

(A suivre…..)