Le calcul sur AWS

1. Présentation d’Amazon EC2

Amazon EC2 (Elastic Compute Cloud) est un service phare d’Amazon Web Services (AWS), lancé en 2006. Il a apporté une révolution dans le cloud computing en offrant une solution de calcul virtuel à la fois flexible et économique. EC2 permet aux utilisateurs de louer des instances virtuelles, adaptant ainsi leurs ressources informatiques selon leurs besoins spécifiques.

Ce service est conçu pour fournir une puissance de calcul adaptable pour tout, des applications d’entreprise aux traitements de données volumineuses. Avec EC2, les utilisateurs bénéficient d’une grande variété de configurations d’instances, ce qui leur permet de choisir la combinaison optimale de CPU, de mémoire et de stockage pour leurs applications. Les utilisateurs peuvent également choisir leur système d’exploitation préféré, y compris Linux, Windows, et macOS. De plus, Elastic Compute Cloud permet l’attachement de solutions de stockage telles qu’EBS, Instance Store ou EFS pour des systèmes compatibles, et FSx pour Windows, offrant une flexibilité accrue en matière de gestion des données.

La simplicité d’utilisation, couplée à un modèle de tarification flexible, rend EC2 particulièrement attrayant pour...

1. Paires de clés

Les paires de clés, ou « Key Pairs », sont un mécanisme de sécurité permettant l’accès aux instances Amazon EC2. Elles permettent l’authentification et l’assurance que seul le détenteur de la clé privée appropriée peut se connecter aux instances via SSH (Secure Shell).

Une paire de clés est constituée de deux clés complémentaires : une clé publique et une clé privée. Lors de la création d’une instance EC2, l’utilisateur a la possibilité de spécifier une clé publique qui sera installée dans l’instance. Cette clé publique est stockée dans le fichier .ssh/authorized_keys de l’instance conformément aux pratiques standard de SSH, permettant à quiconque possède la clé privée correspondante de s’y connecter sécuritairement.

Pour rappel la différence entre clé publique et privée :

Il est crucial de stocker la clé privée dans un endroit sécurisé. La perte de la clé privée signifie perdre l’accès à l’instance, et si la clé est compromise, cela peut permettre à des utilisateurs non autorisés d’accéder à vos instances. De plus, il ne faut jamais partager votre clé privée à des personnes externes. La sécurité de vos instances EC2 dépend de la confidentialité de vos clés privées.

1. Modèle de tarification à la demande

Le modèle de tarification à la demande d’AWS est conçu pour offrir une flexibilité maximale, permettant aux utilisateurs de payer uniquement pour la capacité de calcul réellement utilisée, sans engagement à long terme ni paiement initial. C’est celui que nous avons utilisé lors du déploiement de nos instances EC2 dans les précédents chapitres. Ce modèle est particulièrement adapté aux charges de travail avec des besoins imprévisibles ou fluctuants, où il est difficile de prévoir à l’avance la quantité exacte de ressources nécessaires.

Avec la tarification à la demande, nous pouvons démarrer, arrêter et redimensionner nos instances selon les besoins de l’application. Les tarifs sont facturés à l’heure ou à la seconde (selon le type d’instance), ce qui permet de maîtriser les coûts en ajustant les ressources en temps réel....

1. Placement Groups

Les Placement Groups sont une fonctionnalité d’AWS EC2 qui permet de contrôler la manière dont les instances sont placées sur le matériel sous-jacent pour optimiser la performance et la résilience des applications. Il existe trois types de placement groups, chacun adapté à des besoins spécifiques.

Le Cluster Placement Group regroupe les instances au sein d’une même zone de disponibilité, sur un cluster de matériel physique unique. Ce type de placement est idéal pour les applications qui nécessitent une faible latence et une bande passante réseau élevée entre les instances, telles que les simulations de calcul intensif, les applications de rendu vidéo, ou les clusters de bases de données. Toutefois, en cas de ressources limitées, AWS pourrait ne pas être en mesure de lancer toutes les instances requises dans le même placement group, ce qui peut poser des défis de capacité.

Le Spread Placement Group, quant à lui, répartit les instances sur différents racks de matériel physique, chaque rack ayant sa propre alimentation et son propre réseau. Ce type de placement est optimisé pour la haute disponibilité, minimisant le risque de défaillance corrélée. Il est particulièrement adapté aux applications critiques qui doivent rester opérationnelles même en cas de panne d’un rack. Cependant, il est important de noter que le nombre d’instances dans un Spread Placement Group est limité à 7 par zone de disponibilité et 21 dans un groupe, ce qui peut être une contrainte pour les très grands déploiements.

1. Passage au site dynamique de l’entreprise French Bakery

Après avoir lancé son site vitrine avec succès, French Bakery a vu une augmentation significative de son activité grâce à sa présence en ligne. D’autres franchises ont même été ouvertes. Cependant, face à une demande croissante de ses clients, l’entreprise souhaite désormais aller plus loin en proposant une fonctionnalité de commande en ligne. Cette évolution nécessitant un traitement dynamique des données, comme la gestion des commandes et des interactions avec une base de données, nous allons ainsi déployer une application web sur une instance Amazon EC2. Ce déploiement permettra de répondre aux besoins croissants de l’entreprise tout en assurant une flexibilité et une scalabilité adaptées à cette nouvelle fonctionnalité.

Voici le schéma d’architecture du site web que nous allons déployer :

Ce schéma illustre une architecture web déployée sur une instance Amazon EC2. L’architecture repose sur un serveur Nginx qui joue à la fois le rôle de serveur web pour le frontend (demandes sur le chemin /) et de reverse proxy pour le backend Node.js (demandes sur le chemin /api). Les utilisateurs accèdent au serveur EC2 via Internet, en envoyant des requêtes HTTP sur le port 80. Ces requêtes sont ensuite redirigées selon leur chemin : soit vers les fichiers statiques du frontend (hébergés sur le serveur Nginx), soit vers le backend Node.js via le proxy configuré. Le backend interagit avec une base de données PostgreSQL pour stocker et récupérer les données.

L’accès administrateur à l’instance EC2 est restreint au port SSH (22) et limité à une adresse IP spécifique (1.2.3.4/32) conformément aux règles du Security Group, tandis que les règles de sortie (outbound) autorisent tout trafic. Cette configuration garantit un accès sécurisé pour l’administration tout en permettant aux utilisateurs finaux d’accéder aux services nécessaires. Une séparation claire entre les différents composants - frontend, backend...