SAA-CO3 – Fiche de révision Amazon EC2

1. Définition d’Amazon EC2

• Amazon EC2 signifie Elastic Compute Cloud.
• EC2 est un service IaaS permettant de louer des machines virtuelles dans le Cloud AWS.
• Ces machines virtuelles sont appelées instances EC2.
• EC2 permet de choisir :
  • Le système d’exploitation
  • Le type d’instance
  • Le nombre de vCPU
  • La quantité de mémoire RAM
  • Le type de stockage
  • Les performances réseau
  • Les règles de sécurité
  • Les options d’achat

2. EC2 comme service IaaS

• EC2 est l’un des meilleurs exemples d’Infrastructure as a Service dans AWS.
• AWS gère :
  • Les datacenters
  • Le matériel physique
  • L’alimentation
  • Le réseau physique
  • La virtualisation
• Vous gérez :
  • Le système d’exploitation
  • Les mises à jour logicielles
  • Les applications
  • Les packages installés
  • La configuration réseau de l’instance
  • La sécurité de l’OS
  • Les données applicatives

3. Composants clés autour d’EC2

• Instance EC2
  • Machine virtuelle provisionnée dans AWS.
• AMI – Amazon Machine Image
  • Modèle utilisé pour lancer une instance EC2.
  • Contient généralement un OS, des logiciels et une configuration initiale.
• EBS – Elastic Block Store
  • Stockage bloc persistant attaché à une instance EC2.
  • Les données peuvent survivre à l’arrêt de l’instance si le volume n’est pas supprimé.
• Instance Store
  • Stockage temporaire physiquement attaché à l’hôte.
  • Très performant mais non persistant.
  • Les données sont perdues si l’instance est arrêtée, terminée ou si l’hôte sous-jacent échoue.
• Security Group
  • Pare-feu virtuel associé à une instance EC2 ou à une interface réseau.
• Elastic Load Balancer
  • Répartit le trafic entre plusieurs instances EC2.
• Auto Scaling Group
  • Permet d’ajuster automatiquement le nombre d’instances EC2 selon la demande.
• EC2 User Data
  • Script exécuté au premier démarrage d’une instance.
  • Utilisé pour automatiser la configuration initiale.
• Elastic IP
  • Adresse IPv4 publique statique pouvant être associée à une instance ou à une interface réseau.
• ENI – Elastic Network Interface
  • Interface réseau virtuelle attachée à une instance EC2.

4. Configuration d’une instance EC2

• Lors du lancement d’une instance EC2, il faut choisir :
  • Une AMI
  • Un type d’instance
  • Une paire de clés SSH, si nécessaire
  • Un VPC
  • Un subnet
  • Une adresse IP publique ou privée
  • Un ou plusieurs Security Groups
  • Un volume de stockage
  • Un rôle IAM, si l’instance doit accéder à d’autres services AWS
  • Un script User Data, si besoin

5. Systèmes d’exploitation supportés

• EC2 permet de lancer plusieurs types d’OS :
  • Amazon Linux
  • Ubuntu
  • Red Hat Enterprise Linux
  • SUSE Linux
  • Debian
  • Windows Server
  • macOS, selon les types d’instances compatibles

6. EC2 User Data

Définition

• EC2 User Data permet d’exécuter un script au premier démarrage de l’instance.
• Il est souvent utilisé pour automatiser les tâches de configuration initiale.
• On parle aussi de bootstrapping.

Caractéristiques

• Le script est exécuté au premier démarrage.
• Sur Linux, il est généralement exécuté avec les privilèges root.
• Il peut être utilisé pour installer et configurer automatiquement une application.
• Il évite les configurations manuelles répétitives.

Cas d’usage

• Mettre à jour le système.
• Installer des packages.
• Installer un serveur web.
• Télécharger du code depuis un dépôt.
• Configurer des variables d’environnement.
• Démarrer une application.
• Enregistrer l’instance auprès d’un système de monitoring.

Exemple de User Data Linux

#!/bin/bash
yum update -y
yum install -y httpd
systemctl enable httpd
systemctl start httpd
echo "Hello from EC2" > /var/www/html/index.html

À retenir pour l’examen

• User Data sert à automatiser la configuration initiale d’une instance.
• User Data est exécuté au premier démarrage.
• Pour donner des permissions AWS à une instance, ne pas utiliser User Data avec des clés d’accès.
• La bonne pratique est d’attacher un rôle IAM à l’instance EC2.

7. AMI – Amazon Machine Image

Définition

• Une AMI est un modèle utilisé pour lancer une instance EC2.
• Elle contient :
  • Un système d’exploitation
  • Une configuration logicielle
  • Des permissions de lancement
  • Une configuration de volumes de stockage

Types d’AMI

• AMI fournies par AWS
• AMI du Marketplace AWS
• AMI communautaires
• AMI personnalisées créées par l’utilisateur

Cas d’usage

• Standardiser les déploiements.
• Préinstaller des logiciels.
• Accélérer le lancement d’instances.
• Créer des environnements identiques.
• Faire une image de référence pour une application.

À retenir pour l’examen

• Une AMI permet de lancer rapidement plusieurs instances identiques.
• Une AMI est régionale.
• Pour utiliser une AMI dans une autre région, il faut la copier vers cette région.

8. Types d’instances EC2

Principe

• AWS propose plusieurs familles d’instances EC2.
• Chaque famille est optimisée pour un type de workload.
• Il n’est pas nécessaire de mémoriser tous les noms d’instances pour l’examen.
• Il faut surtout savoir associer les familles aux bons cas d’usage.

9. Instances à usage général

Familles courantes

• T
• M

Caractéristiques

• Équilibre entre CPU, mémoire et réseau.
• Adaptées aux workloads généralistes.
• Les instances T sont souvent burstables.
• Les instances M sont adaptées aux charges équilibrées plus régulières.

Cas d’usage

• Serveurs web.
• Petites applications.
• Environnements de développement.
• Petites bases de données.
• Applications métier généralistes.

À retenir pour l’examen

• Usage général = équilibre CPU, RAM et réseau.
• T pour workloads légers ou variables.
• M pour workloads généralistes plus stables.

10. Instances optimisées pour le calcul

Famille courante

• C

Caractéristiques

• Ratio CPU élevé.
• Adaptées aux applications intensives en calcul.

Cas d’usage

• Traitement batch.
• Encodage vidéo.
• Serveurs de jeux.
• Calcul scientifique.
• Modélisation.
• Machine Learning orienté CPU.
• Applications nécessitant beaucoup de puissance processeur.

À retenir pour l’examen

• Besoin CPU élevé = famille C.
• Workload compute-intensive = instances optimisées pour le calcul.

11. Instances optimisées pour la mémoire

Familles courantes

• R
• X
• Z

Caractéristiques

• Très grande quantité de RAM.
• Adaptées aux workloads en mémoire.

Cas d’usage

• Bases de données en mémoire.
• Caches distribués.
• Redis.
• Analyse temps réel.
• Bases de données relationnelles lourdes.
• SAP HANA.
• Applications nécessitant beaucoup de mémoire.

À retenir pour l’examen

• Besoin important en RAM = familles R, X ou Z.
• Bases de données et caches en mémoire = memory optimized.

12. Instances optimisées pour le stockage

Familles courantes

• I
• D
• H

Caractéristiques

• Accès rapide au stockage local.
• Souvent associées à des SSD NVMe ou du stockage local à haut débit.
• Adaptées aux workloads nécessitant beaucoup d’I/O disque.

Cas d’usage

• Bases de données NoSQL.
• OLTP.
• Data warehousing.
• Systèmes de fichiers distribués.
• Elasticsearch ou OpenSearch.
• Workloads nécessitant un accès disque très rapide.

À retenir pour l’examen

• Besoin de stockage local rapide = storage optimized.
• I/O intensif = familles I, D ou H selon le scénario.

13. Instances accélérées

Familles courantes

• P
• G
• Inf
• Trn

Caractéristiques

• Utilisent des accélérateurs matériels.
• Peuvent inclure des GPU ou des puces spécialisées pour l’IA.

Cas d’usage

• Machine Learning.
• Deep Learning.
• Inférence IA.
• Entraînement de modèles.
• Rendu graphique.
• Traitement vidéo.
• Calcul parallèle GPU.

À retenir pour l’examen

• GPU ou IA = instances accélérées.
• Pour Machine Learning intensif, penser aux familles P, G, Inf ou Trn selon le besoin.

14. Convention de nommage des instances EC2

Exemple : c5.4xlarge

• c
  • Famille d’instance.
  • Ici, optimisée pour le calcul.
• 5
  • Génération de l’instance.
  • Plus la génération est récente, plus les performances et l’efficacité sont généralement améliorées.
• 4xlarge
  • Taille de l’instance.
  • Plus la taille augmente, plus il y a généralement de vCPU, de RAM, de réseau et de capacité.

À retenir pour l’examen

• La première lettre indique la famille.
• Le chiffre indique la génération.
• La taille indique la capacité.
• Il faut choisir le type d’instance selon le workload.

15. Groupes de sécurité

Définition

• Un Security Group est un pare-feu virtuel.
• Il contrôle le trafic entrant et sortant d’une instance EC2.
• Il est associé à une ENI, donc indirectement à une instance EC2.
• Il fonctionne au niveau instance/interface réseau.

Caractéristiques

• Les Security Groups sont stateful.
• Si une requête entrante est autorisée, la réponse sortante est automatiquement autorisée.
• Si une requête sortante est autorisée, la réponse entrante est automatiquement autorisée.
• Ils ne supportent que des règles d’autorisation.
• Il n’existe pas de règle explicite de refus dans un Security Group.
• Une instance peut avoir plusieurs Security Groups.
• Un Security Group peut être associé à plusieurs instances.
• Les Security Groups sont liés à un VPC.

Règles par défaut

• Trafic entrant :
  • Bloqué par défaut.
• Trafic sortant :
  • Autorisé par défaut.

Une règle de Security Group contient généralement

• Un protocole.
• Un port ou une plage de ports.
• Une source, pour les règles entrantes.
• Une destination, pour les règles sortantes.
• Une adresse CIDR.
• Un autre Security Group.
• Un préfix list, dans certains cas.

16. Ports importants à connaître

• SSH
  • Port 22
  • Utilisé pour administrer les instances Linux.
• SFTP
  • Port 22
  • Transfert de fichiers sécurisé via SSH.
• FTP
  • Port 21
  • Ancien protocole de transfert de fichiers.
• HTTP
  • Port 80
  • Trafic web non chiffré.
• HTTPS
  • Port 443
  • Trafic web chiffré.
• RDP
  • Port 3389
  • Administration distante des instances Windows.
• MySQL / MariaDB
  • Port 3306.
• PostgreSQL
  • Port 5432.
• DNS
  • Port 53.

17. Bonnes pratiques Security Groups

• Ne jamais ouvrir SSH à 0.0.0.0/0 en production.
• Restreindre SSH à une IP d’administration connue.
• Utiliser Session Manager lorsque possible pour éviter l’ouverture du port SSH.
• Ouvrir uniquement les ports nécessaires.
• Créer des Security Groups par rôle applicatif.
• Exemple :
  • Un Security Group pour le Load Balancer.
  • Un Security Group pour les serveurs web.
  • Un Security Group pour les serveurs applicatifs.
  • Un Security Group pour la base de données.
• Utiliser le référencement entre Security Groups plutôt que des IP fixes.
• Documenter les règles importantes.
• Supprimer les règles inutilisées.

18. Référencement entre Security Groups

Principe

• Un Security Group peut autoriser le trafic provenant d’un autre Security Group.
• Cela permet d’autoriser les communications entre couches applicatives sans utiliser d’adresses IP fixes.

Exemple architecture 3 tiers

• Load Balancer Security Group :
  • Autorise HTTP/HTTPS depuis Internet.
• Web/App Security Group :
  • Autorise le trafic uniquement depuis le Security Group du Load Balancer.
• Database Security Group :
  • Autorise le trafic uniquement depuis le Security Group applicatif.

À retenir pour l’examen

• Pour une architecture multi-tiers propre, utiliser les Security Groups comme sources.
• Cela permet un design plus flexible et plus sécurisé que des IP codées en dur.

19. Security Groups vs NACLs

Security Groups

• Niveau instance ou ENI.
• Stateful.
• Règles Allow uniquement.
• Toutes les règles sont évaluées ensemble.
• Utilisés pour contrôler finement l’accès aux instances.

Network ACLs

• Niveau subnet.
• Stateless.
• Supportent Allow et Deny.
• Les règles sont évaluées par ordre numérique.
• Utilisés pour ajouter une couche de contrôle réseau au niveau subnet.

À retenir pour l’examen

• Pare-feu instance = Security Group.
• Pare-feu subnet = NACL.
• Besoin d’un Deny explicite au niveau réseau = NACL.
• Besoin d’un contrôle simple et stateful pour EC2 = Security Group.

20. Options d’achat EC2

21. Instances On-Demand

Définition

• Les instances On-Demand sont facturées à l’usage.
• Il n’y a pas d’engagement long terme.
• C’est l’option la plus flexible.

Avantages

• Aucun engagement.
• Démarrage rapide.
• Flexibilité maximale.
• Adapté aux workloads imprévisibles.

Inconvénients

• Coût plus élevé que les options avec engagement.
• Moins optimisé pour les workloads stables sur le long terme.

Cas d’usage

• Environnements de test.
• Développement.
• Applications à trafic imprévisible.
• Workloads temporaires.
• Lancement rapide d’un service.

À retenir pour l’examen

• Besoin de flexibilité sans engagement = On-Demand.
• Workload court ou imprévisible = On-Demand.

22. Reserved Instances

Définition

• Les Reserved Instances permettent de bénéficier d’une réduction en échange d’un engagement.
• L’engagement est généralement de 1 an ou 3 ans.

Types

• Standard Reserved Instances :
  • Réduction plus importante.
  • Moins flexibles.
  • Adaptées aux workloads stables.
• Convertible Reserved Instances :
  • Plus flexibles.
  • Permettent certains changements.
  • Réduction généralement plus faible que Standard.

Options de paiement

• No Upfront.
• Partial Upfront.
• All Upfront.

Cas d’usage

• Applications stables.
• Bases de données utilisées en continu.
• Serveurs applicatifs prévisibles.
• Workloads connus sur 1 ou 3 ans.

À retenir pour l’examen

• Workload stable et prévisible = Reserved Instances.
• Besoin de réduction avec flexibilité limitée = Convertible RI.
• Plus l’engagement est long et payé à l’avance, plus la réduction est élevée.

23. Savings Plans

Définition

• Les Savings Plans permettent d’obtenir des réductions en échange d’un engagement de dépense horaire.
• L’engagement est exprimé en dollars par heure.
• Durée typique : 1 an ou 3 ans.

Types

• Compute Savings Plans :
  • Très flexibles.
  • Peuvent s’appliquer à plusieurs familles d’instances, régions, OS, Fargate et Lambda selon les cas.
  • Recommandés lorsqu’on veut optimiser les coûts avec un maximum de flexibilité.
• EC2 Instance Savings Plans :
  • Moins flexibles que Compute Savings Plans.
  • Liés à une famille d’instances dans une région donnée.
  • Offrent généralement des réductions plus importantes que Compute Savings Plans.

Cas d’usage

• Workloads continus.
• Besoin de réduction sans verrouillage trop strict sur un type précis.
• Environnements de production avec usage régulier.

À retenir pour l’examen

• Besoin d’économies avec plus de flexibilité que les Reserved Instances = Savings Plans.
• Compute Savings Plans = plus flexible.
• EC2 Instance Savings Plans = plus spécifique à une famille/région.

24. Instances Spot

Définition

• Les instances Spot utilisent la capacité EC2 inutilisée d’AWS.
• Elles permettent de réduire fortement les coûts par rapport aux instances On-Demand.
• AWS peut interrompre une instance Spot lorsque la capacité doit être récupérée.

Fonctionnement

• Vous demandez de la capacité Spot.
• AWS lance l’instance si la capacité est disponible.
• L’instance peut être interrompue avec un préavis généralement de 2 minutes.
• Selon la configuration, l’interruption peut entraîner :
  • Terminaison
  • Arrêt
  • Hibernation, si supportée

Bons cas d’usage

• Traitements batch.
• Big Data.
• Rendu vidéo.
• Machine Learning distribué.
• Workers asynchrones.
• CI/CD.
• Calcul scientifique.
• Workloads stateless.
• Jobs pouvant reprendre après interruption.

Mauvais cas d’usage

• Bases de données critiques.
• Applications stateful non résilientes.
• Workloads ne tolérant pas les interruptions.
• Applications nécessitant une capacité garantie.

À retenir pour l’examen

• Spot = économies fortes.
• Spot = interruption possible.
• Spot convient aux workloads tolérants aux pannes.
• Pour un workload critique, éviter Spot seul.

25. Spot Requests

Demande Spot unique

• Lance une instance Spot lorsque la capacité est disponible.
• Une fois l’instance lancée, la demande est satisfaite.
• Si l’instance est interrompue, elle n’est pas automatiquement relancée.

Demande Spot persistante

• La demande reste active.
• Si l’instance est interrompue, AWS peut tenter de la relancer.
• Pour l’annuler proprement :
  • Annuler d’abord la demande Spot.
  • Terminer ensuite l’instance EC2.
• Sinon, AWS peut relancer une nouvelle instance.

26. Spot Fleet

Définition

• Une Spot Fleet permet de demander une capacité cible en utilisant plusieurs pools Spot.
• Un pool Spot correspond à une combinaison :
  • Type d’instance
  • Availability Zone
  • Plateforme
  • Option de capacité

Objectifs

• Réduire les coûts.
• Améliorer la disponibilité.
• Diversifier les types d’instances.
• Utiliser plusieurs Availability Zones.
• Laisser AWS choisir les meilleures options selon la stratégie.

Stratégies d’allocation

• Lowest price :
  • Choisit les pools les moins chers.
  • Optimise le coût.
  • Peut augmenter le risque d’interruption.
• Diversified :
  • Répartit les instances sur plusieurs pools.
  • Réduit le risque d’interruption massive.
• Capacity optimized :
  • Choisit les pools avec le plus de capacité disponible.
  • Réduit le risque d’interruption.
• Price capacity optimized :
  • Équilibre prix et disponibilité de capacité.
  • Souvent recommandé pour les workloads Spot modernes.

À retenir pour l’examen

• Coût minimal = lowest price.
• Résilience par répartition = diversified.
• Moins d’interruptions = capacity optimized.
• Bon équilibre coût/capacité = price capacity optimized.

27. EC2 Fleet

Définition

• EC2 Fleet permet de gérer une flotte d’instances EC2.
• Elle peut combiner :
  • Instances On-Demand
  • Instances Spot
  • Plusieurs types d’instances
  • Plusieurs Availability Zones

Cas d’usage

• Workloads distribués.
• Traitements batch.
• Besoin de combiner capacité garantie et capacité à bas coût.
• Optimisation coût et disponibilité.

À retenir pour l’examen

• EC2 Fleet est plus générale que Spot Fleet.
• EC2 Fleet peut combiner On-Demand et Spot.
• Utile pour atteindre une capacité cible avec plusieurs options d’achat.

28. Capacity Rebalancing

Définition

• Capacity Rebalancing aide à gérer les interruptions Spot.
• AWS peut recommander de remplacer une instance Spot à risque d’interruption.
• Une nouvelle instance peut être lancée avant l’interruption de l’ancienne.

Cas d’usage

• Auto Scaling Group avec instances Spot.
• EC2 Fleet.
• Spot Fleet.
• Workloads distribués nécessitant une meilleure continuité.

À retenir pour l’examen

• Réduire l’impact des interruptions Spot = Capacity Rebalancing.
• Cela ne garantit pas l’absence d’interruption.
• Cela permet d’anticiper et de remplacer plus proprement les instances à risque.

29. Dedicated Hosts

Définition

• Un Dedicated Host est un serveur physique dédié à un seul client AWS.
• Il donne une visibilité sur le placement physique des instances.

Cas d’usage

• Contraintes de conformité.
• Contraintes réglementaires.
• Licences logicielles liées au socket, au cœur ou au serveur physique.
• BYOL, Bring Your Own License.

À retenir pour l’examen

• Besoin de contrôler le serveur physique = Dedicated Host.
• Besoin BYOL avec contraintes de licence = Dedicated Host.

30. Dedicated Instances

Définition

• Les Dedicated Instances s’exécutent sur du matériel dédié à un seul client.
• Mais vous ne contrôlez pas précisément le serveur physique.

Cas d’usage

• Besoin d’isolation matérielle.
• Pas besoin de gérer les contraintes précises de licence serveur.

À retenir pour l’examen

• Isolation matérielle sans contrôle du serveur physique = Dedicated Instances.
• Contrôle plus précis du serveur physique = Dedicated Host.

31. Capacity Reservations

Définition

• Une Capacity Reservation réserve de la capacité EC2 dans une Availability Zone spécifique.
• Elle garantit que la capacité sera disponible lorsque vous en aurez besoin.

Caractéristiques

• Ne fournit pas de réduction par elle-même.
• Vous payez la capacité réservée, utilisée ou non.
• Peut être combinée avec Savings Plans ou Reserved Instances pour l’optimisation des coûts.

Cas d’usage

• Applications critiques.
• Besoin de capacité garantie dans une AZ précise.
• Événements planifiés.
• Migrations.
• Workloads ne pouvant pas échouer au lancement faute de capacité.

À retenir pour l’examen

• Besoin de garantir de la capacité dans une AZ = Capacity Reservation.
• Besoin de réduction = Savings Plans ou Reserved Instances.
• Capacité garantie et réduction sont deux sujets distincts.

32. Adresses IP dans EC2

33. IPv4 et IPv6

IPv4

• Format classique sur 32 bits.
• Exemple : 192.168.1.10.
• Encore très utilisé.
• Les adresses IPv4 publiques sont limitées.

IPv6

• Format sur 128 bits.
• Exemple : 2001:db8::1.
• Espace d’adressage beaucoup plus large.
• Peut être utilisé dans les VPC et subnets compatibles.

34. IP privée

Définition

• Une IP privée est utilisée pour la communication interne dans un VPC.
• Elle n’est pas directement routable sur Internet.

Cas d’usage

• Communication entre instances.
• Communication entre une application et une base de données.
• Communication interne entre services.
• Accès via VPN ou Direct Connect.

Plages privées courantes

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

À retenir pour l’examen

• IP privée = communication interne au VPC.
• Les ressources privées ne sont pas directement accessibles depuis Internet.

35. IP publique

Définition

• Une IP publique permet à une instance d’être accessible depuis Internet.
• Elle peut être attribuée automatiquement au lancement de l’instance, selon la configuration du subnet.

Caractéristiques

• Une IP publique automatique peut changer après un stop/start de l’instance.
• Elle est utile pour des tests ou des accès temporaires.
• En production, il est souvent préférable d’utiliser un Load Balancer ou un nom DNS.

À retenir pour l’examen

• IP publique automatique = non persistante après stop/start.
• Pour une IP publique fixe, utiliser une Elastic IP.
• Pour exposer une application scalable, préférer un Load Balancer.

36. Elastic IP

Définition

• Une Elastic IP est une adresse IPv4 publique statique.
• Elle reste associée à votre compte AWS tant que vous ne la libérez pas.

Cas d’usage

• Besoin d’une IP publique fixe.
• Basculement manuel entre instances.
• Cas spécifiques nécessitant un allowlist externe sur une IP fixe.

Bonnes pratiques

• Éviter l’usage massif des Elastic IP.
• Préférer un Load Balancer avec un nom DNS pour les architectures scalables.
• Libérer les Elastic IP inutilisées.
• Éviter de dépendre directement d’une IP publique pour une application moderne.

À retenir pour l’examen

• Elastic IP = IPv4 publique fixe.
• Une Elastic IP non utilisée ou mal associée peut générer des coûts.
• Trop d’Elastic IP peut indiquer une architecture peu scalable.
• Pour la haute disponibilité, préférer ELB plutôt qu’une EIP attachée à une seule instance.

37. Accès Internet pour une instance EC2

Instance dans un subnet public

• L’instance doit avoir une IP publique ou une Elastic IP.
• Le subnet doit avoir une route vers une Internet Gateway.
• Le Security Group doit autoriser le trafic nécessaire.
• La NACL doit permettre le trafic.
• L’application doit écouter sur le bon port.

Instance dans un subnet privé

• Elle ne doit généralement pas avoir d’IP publique.
• Elle peut accéder à Internet en sortie via :
  • NAT Gateway
  • NAT Instance
• Elle ne peut pas être directement contactée depuis Internet.

À retenir pour l’examen

• Subnet public + IP publique + Internet Gateway = accès Internet possible.
• Subnet privé + NAT Gateway = accès sortant vers Internet.
• NAT Gateway ne permet pas l’accès entrant depuis Internet vers les instances privées.

38. EC2 Hibernate

Définition

• EC2 Hibernate permet de mettre une instance en veille prolongée.
• Le contenu de la RAM est sauvegardé sur le volume EBS racine.
• Au redémarrage, l’instance reprend son état précédent plus rapidement qu’un démarrage complet.

Fonctionnement

• L’instance passe de l’état running à stopping.
• Le contenu de la RAM est copié sur le volume EBS racine.
• L’instance est arrêtée.
• Au redémarrage, la RAM est restaurée.
• Les processus reprennent à partir de leur état précédent.

Conditions importantes

• Le volume racine doit être un volume EBS.
• Le volume racine doit être suffisamment grand pour stocker le contenu de la RAM.
• Le volume racine doit être chiffré.
• L’AMI et le type d’instance doivent être compatibles avec Hibernate.
• Hibernate n’est pas disponible pour toutes les configurations.

Cas d’usage

• Applications avec long temps de démarrage.
• Applications conservant beaucoup d’état en mémoire.
• Environnements de test.
• Caches lourds.
• Applications nécessitant une reprise rapide.

À retenir pour l’examen

• Stop classique = l’instance redémarre normalement.
• Hibernate = la RAM est sauvegardée puis restaurée.
• Hibernate permet une reprise plus rapide.
• Les données en RAM sont conservées via le volume EBS racine.

39. Groupes de placement EC2

Définition

• Les Placement Groups permettent de contrôler la manière dont les instances EC2 sont placées sur l’infrastructure physique AWS.
• Ils servent à optimiser :
  • La performance réseau
  • La latence
  • La résilience
  • L’isolation matérielle

Types de Placement Groups

• Cluster Placement Group
• Spread Placement Group
• Partition Placement Group

40. Cluster Placement Group

Définition

• Un Cluster Placement Group place les instances proches les unes des autres dans une même Availability Zone.
• Il est conçu pour fournir une faible latence et un haut débit réseau entre instances.

Avantages

• Très faible latence.
• Haut débit réseau.
• Performances élevées pour les applications fortement couplées.

Limites

• Fonctionne dans une seule Availability Zone.
• Moins résilient face à une panne d’AZ.
• Peut poser un risque si toutes les instances critiques sont regroupées physiquement.

Cas d’usage

• HPC, High Performance Computing.
• Big Data avec forte communication réseau.
• Machine Learning distribué.
• Jeux en ligne multijoueur.
• Applications nécessitant une latence inter-instance très faible.

À retenir pour l’examen

• Faible latence = Cluster.
• Haut débit réseau entre instances = Cluster.
• Workload fortement couplé = Cluster.

41. Spread Placement Group

Définition

• Un Spread Placement Group répartit les instances sur du matériel physique distinct.
• Il vise à réduire le risque que plusieurs instances critiques soient touchées par la même panne matérielle.

Avantages

• Forte isolation matérielle.
• Très bonne résilience.
• Peut s’étendre sur plusieurs Availability Zones.
• Adapté aux petits nombres d’instances critiques.

Limites

• Nombre limité d’instances par Availability Zone.
• Ne convient pas aux déploiements massifs.

Cas d’usage

• Frontends critiques.
• Bases de données hautement disponibles.
• Petits clusters critiques.
• Instances qui doivent être isolées les unes des autres.

À retenir pour l’examen

• Résilience maximale pour peu d’instances = Spread.
• Isolation matérielle forte = Spread.
• Petit nombre d’instances critiques = Spread.

42. Partition Placement Group

Définition

• Un Partition Placement Group répartit les instances dans plusieurs partitions.
• Chaque partition correspond à un ensemble de racks distincts.
• Une panne dans une partition n’affecte pas directement les autres partitions.

Avantages

• Adapté aux très grands clusters.
• Permet de lancer des centaines d’instances.
• Fournit une isolation par partition.
• Les applications peuvent connaître leur partition via les métadonnées EC2.

Cas d’usage

• HDFS.
• HBase.
• Hadoop.
• Cassandra.
• Kafka.
• Big Data.
• Bases distribuées.
• Systèmes nécessitant une isolation par rack logique.

À retenir pour l’examen

• Big Data à grande échelle = Partition.
• Kafka, Cassandra, HDFS = Partition.
• Besoin de centaines d’instances avec isolation = Partition.

43. Résumé mental des Placement Groups

Cluster

• Objectif :
  • Performance réseau.
  • Faible latence.
• Placement :
  • Instances proches.
• Cas typique :
  • HPC, calcul intensif, faible latence.
• Risque :
  • Moins résilient car concentré dans une AZ.

Spread

• Objectif :
  • Résilience maximale.
  • Isolation matérielle.
• Placement :
  • Instances séparées.
• Cas typique :
  • Peu d’instances critiques.
• Risque :
  • Limité en nombre d’instances.

Partition

• Objectif :
  • Scalabilité.
  • Isolation par partition.
• Placement :
  • Instances réparties entre partitions.
• Cas typique :
  • Big Data, Kafka, Cassandra, HDFS.
• Risque :
  • Plus complexe à concevoir.

44. ENI – Elastic Network Interface

Définition

• Une ENI est une interface réseau virtuelle dans un VPC.
• Elle permet de connecter une instance EC2 au réseau.
• Elle fonctionne comme une carte réseau virtuelle.
• Elle est attachée à une instance EC2 dans une Availability Zone.

Une ENI peut contenir

• Une adresse IPv4 privée principale.
• Des adresses IPv4 privées secondaires.
• Une ou plusieurs adresses IPv6 selon la configuration.
• Une adresse MAC.
• Un ou plusieurs Security Groups.
• Une Elastic IP associée à une IPv4 privée.
• Un Source/Destination Check.
• Un ID d’interface réseau.
• Des tags.

45. ENI primaire et ENI secondaire

ENI primaire

• Créée automatiquement avec l’instance EC2.
• Généralement associée à eth0.
• Ne peut pas être détachée d’une instance en cours d’exécution.
• Reste liée à l’instance principale.

ENI secondaire

• Créée et attachée manuellement.
• Peut apparaître comme eth1, eth2, etc.
• Peut être détachée d’une instance et attachée à une autre instance.
• Doit rester dans la même Availability Zone.
• Utile pour le failover, les appliances réseau et la séparation du trafic.

46. Propriétés importantes des ENI

• Une ENI est liée à une Availability Zone.
• Une ENI ne peut être attachée qu’à une instance dans la même AZ.
• Une ENI conserve ses attributs lorsqu’elle est déplacée.
• Les attributs qui la suivent incluent :
  • IP privée
  • Security Groups
  • Adresse MAC
  • Elastic IP associée, le cas échéant
• Une instance EC2 peut avoir plusieurs ENI selon son type d’instance.
• Les Security Groups sont associés aux ENI.

47. Cas d’usage des ENI

Failover avec IP privée fixe

• Une ENI secondaire porte une IP privée utilisée par l’application.
• En cas de panne, l’ENI est déplacée vers une instance de secours.
• L’IP privée reste la même.
• Le trafic suit l’ENI vers la nouvelle instance.

Séparation du trafic

• Utiliser plusieurs ENI pour séparer :
  • Trafic public
  • Trafic privé
  • Trafic d’administration
  • Trafic backend
  • Trafic de monitoring

Appliances réseau

• Les ENI sont utiles pour :
  • Firewalls virtuels
  • NAT Instances
  • Proxies
  • IDS/IPS
  • Routeurs virtuels

Architectures multi-homed

• Une instance peut avoir plusieurs interfaces réseau.
• Cela permet de connecter une instance à plusieurs sous-réseaux.
• Ce modèle est fréquent pour les appliances réseau.

48. Source/Destination Check

Définition

• Par défaut, une instance EC2 vérifie que le trafic qu’elle reçoit ou envoie lui est destiné.
• Cette vérification est appelée Source/Destination Check.
• Elle est activée par défaut.

Quand le désactiver

• NAT Instance.
• Firewall virtuel.
• Routeur virtuel.
• Appliance réseau qui relaie du trafic pour d’autres instances.

À retenir pour l’examen

• Instance EC2 standard = Source/Destination Check activé.
• NAT Instance ou routeur virtuel = Source/Destination Check désactivé.

49. ENI vs Elastic IP

ENI

• Carte réseau virtuelle.
• Contient une IP privée.
• Peut avoir des Security Groups.
• Peut être déplacée entre instances dans la même AZ.
• Sert à gérer la connectivité réseau.

Elastic IP

• Adresse IPv4 publique statique.
• Sert à garder une IP publique fixe.
• Peut être associée à une instance ou à une ENI.
• Peut être déplacée entre ressources compatibles.

À retenir

• ENI = interface réseau.
• Elastic IP = IP publique fixe.
• Security Group = pare-feu attaché à l’interface.
• ENI = scoped à une AZ.

50. EC2 et IAM Roles

Principe

• Une instance EC2 peut recevoir un rôle IAM.
• Ce rôle permet à l’instance d’accéder à d’autres services AWS.
• Les permissions sont fournies via des credentials temporaires.
• Ces credentials sont récupérés automatiquement par le SDK ou la CLI AWS via les métadonnées de l’instance.

Cas d’usage

• EC2 doit lire des objets dans S3.
• EC2 doit écrire des logs dans CloudWatch.
• EC2 doit lire un secret dans Secrets Manager.
• EC2 doit accéder à DynamoDB.
• EC2 doit récupérer une image dans ECR.

À retenir pour l’examen

• Ne jamais stocker des access keys dans une instance EC2.
• Utiliser un rôle IAM attaché à l’instance.
• Pour EC2 vers S3, la bonne réponse est généralement : rôle IAM EC2 avec permissions S3.

51. EC2 Instance Metadata Service

Définition

• Instance Metadata Service permet à une instance EC2 de récupérer des informations sur elle-même.
• Il permet aussi de récupérer les credentials temporaires associés au rôle IAM de l’instance.

Informations accessibles

• ID de l’instance.
• Type d’instance.
• Région.
• Availability Zone.
• Adresse IP privée.
• Nom d’hôte.
• Informations du rôle IAM.
• Métadonnées réseau.
• Informations de placement.

IMDSv2

• IMDSv2 est une version plus sécurisée du service de métadonnées.
• Elle utilise un mécanisme basé sur des tokens.
• Elle est recommandée pour renforcer la sécurité.

À retenir pour l’examen

• Pour renforcer la sécurité des métadonnées EC2, utiliser IMDSv2.
• Les credentials du rôle IAM sont accessibles via les métadonnées de l’instance.

52. EC2 Instance Connect et accès aux instances

Méthodes d’accès courantes

• SSH pour Linux.
• RDP pour Windows.
• EC2 Instance Connect.
• AWS Systems Manager Session Manager.

Bonne pratique moderne

• Utiliser Systems Manager Session Manager lorsque possible.
• Cela évite d’ouvrir SSH ou RDP à Internet.
• Cela permet un accès auditable et contrôlé par IAM.

À retenir pour l’examen

• Accès Linux traditionnel = SSH port 22.
• Accès Windows traditionnel = RDP port 3389.
• Accès sécurisé sans ouvrir SSH/RDP = Systems Manager Session Manager.

53. Cas d’examen typiques EC2

Cas 1 : déployer rapidement un serveur web

• Utiliser une instance EC2.
• Choisir une AMI adaptée.
• Utiliser User Data pour installer le serveur web.
• Placer l’instance dans un subnet public si elle doit être accessible directement.
• Autoriser HTTP/HTTPS dans le Security Group.
• Pour une architecture scalable, placer les instances derrière un Load Balancer.

Cas 2 : EC2 doit accéder à S3

• Ne pas stocker d’Access Key sur l’instance.
• Créer un rôle IAM avec les permissions S3 nécessaires.
• Attacher le rôle à l’instance EC2.
• L’application utilise automatiquement les credentials temporaires.

Cas 3 : réduire les coûts pour un traitement batch

• Utiliser des instances Spot.
• Utiliser plusieurs types d’instances.
• Utiliser plusieurs Availability Zones.
• Utiliser EC2 Fleet, Spot Fleet ou Auto Scaling avec Spot.
• Prévoir la reprise en cas d’interruption.

Cas 4 : base de données critique sur EC2

• Éviter Spot seul.
• Utiliser On-Demand, Reserved Instances ou Savings Plans.
• Utiliser EBS pour le stockage persistant.
• Prévoir snapshots et sauvegardes.
• Prévoir réplication et haute disponibilité si nécessaire.

Cas 5 : application nécessitant une faible latence entre instances

• Utiliser Cluster Placement Group.
• Déployer dans une même Availability Zone.
• Choisir des types d’instances adaptés au réseau.
• Adapter l’application aux contraintes de placement.

Cas 6 : petit nombre d’instances critiques à isoler

• Utiliser Spread Placement Group.
• Répartir les instances sur du matériel physique distinct.
• Utiliser plusieurs AZ si le scénario le demande.

Cas 7 : cluster Kafka, HDFS ou Cassandra

• Utiliser Partition Placement Group.
• Répartir les nœuds sur plusieurs partitions.
• Tirer parti de l’isolation matérielle par partition.
• Concevoir l’application pour tolérer la perte d’une partition.

Cas 8 : basculement rapide d’une IP privée

• Utiliser une ENI secondaire.
• Attacher l’ENI à l’instance active.
• En cas de panne, rattacher l’ENI à une instance de secours dans la même AZ.
• Le trafic suit l’IP privée portée par l’ENI.

Cas 9 : instance EC2 utilisée comme NAT Instance

• Placer la NAT Instance dans un subnet public.
• Lui attribuer une IP publique ou Elastic IP.
• Modifier les routes des subnets privés vers la NAT Instance.
• Désactiver Source/Destination Check.
• En production, préférer souvent NAT Gateway pour la haute disponibilité et la gestion simplifiée.

Cas 10 : garantir de la capacité dans une AZ

• Utiliser une Capacity Reservation.
• La capacité est réservée dans une Availability Zone spécifique.
• À combiner avec Savings Plans ou Reserved Instances si l’objectif inclut aussi une réduction de coût.

54. Pièges fréquents à l’examen

• EC2 est un service régional, mais les instances sont lancées dans une Availability Zone.
• Une AMI est régionale.
• User Data s’exécute au premier démarrage.
• Pour donner des permissions AWS à EC2, utiliser un rôle IAM.
• Ne jamais stocker de clés d’accès AWS dans User Data ou dans le code.
• Les Security Groups sont stateful.
• Les Security Groups n’ont que des règles Allow.
• Les NACLs sont stateless et supportent Allow et Deny.
• Une IP publique automatique change après stop/start.
• Une Elastic IP est une IP publique fixe.
• Une Elastic IP inutilisée peut générer des coûts.
• Un subnet public nécessite une route vers une Internet Gateway.
• Une instance privée accède à Internet via NAT Gateway ou NAT Instance.
• Les instances Spot peuvent être interrompues.
• Spot ne convient pas aux workloads critiques non tolérants aux interruptions.
• Une demande Spot persistante peut relancer une instance si elle n’est pas annulée.
• Cluster Placement Group optimise la performance réseau, pas la haute disponibilité.
• Spread Placement Group est adapté à peu d’instances critiques.
• Partition Placement Group est adapté aux gros clusters distribués.
• Une ENI est liée à une Availability Zone.
• Une ENI secondaire peut être déplacée uniquement dans la même AZ.
• Les Security Groups sont associés aux ENI.
• Source/Destination Check doit être désactivé pour une NAT Instance ou un routeur virtuel.
• Hibernate sauvegarde la RAM sur le volume EBS racine.
• Instance Store est temporaire et non persistant.
• EBS est persistant et attaché au réseau.
• Dedicated Host est utile pour BYOL et contraintes de conformité.
• Capacity Reservation garantit la capacité mais ne donne pas de réduction à elle seule.

55. Résumé ultra-rapide

• EC2 permet de louer des machines virtuelles dans AWS.
• Une instance EC2 est lancée à partir d’une AMI.
• User Data automatise la configuration au premier démarrage.
• Les familles d’instances sont choisies selon le workload.
• T et M = usage général.
• C = calcul intensif.
• R, X, Z = mémoire.
• I, D, H = stockage.
• P, G, Inf, Trn = accélération GPU ou IA.
• Security Group = pare-feu stateful au niveau instance ou ENI.
• On-Demand = flexible sans engagement.
• Reserved Instances = réduction pour workloads stables.
• Savings Plans = réduction avec plus de flexibilité.
• Spot = coût très bas mais interruption possible.
• Dedicated Host = serveur physique dédié, utile pour BYOL.
• Capacity Reservation = capacité garantie dans une AZ.
• IP privée = communication interne.
• IP publique = accès Internet.
• Elastic IP = IP publique fixe.
• Hibernate = sauvegarde de la RAM sur EBS.
• Cluster Placement Group = faible latence.
• Spread Placement Group = isolation forte pour peu d’instances.
• Partition Placement Group = gros clusters Big Data distribués.
• ENI = carte réseau virtuelle.
• Rôle IAM EC2 = meilleure pratique pour accéder aux services AWS.
• IMDSv2 = meilleure sécurité pour les métadonnées d’instance.