Cas pratiques AWS – Fondamentaux & EC2 (Compute)

Contexte Une application déployée sur EC2 nécessite une adresse IP publique fixe. Le Problème Après redémarrage, l’adresse IP publique change, rendant l’accès instable. Contraintes Allouer une Elastic IP et l’associer à l’instance EC2 existante. Vérifier que l’adresse reste identique après redémarrage. Livrable attendu Une instance EC2 accessible via une IP publique statique.

Contexte Une équipe doit lancer plusieurs instances identiques pour un environnement de test. Le Problème Il faut choisir et configurer correctement une Amazon Machine Image (AMI). Contraintes Sélectionner une AMI officielle (ex: Amazon Linux), comprendre son rôle dans le lancement d’instance et expliquer comment créer une AMI personnalisée à partir d’une instance existante. Livrable attendu Une configuration EC2 basée sur une AMI adaptée et réutilisable.

Contexte Un utilisateur confond les états Stop, Terminate et Reboot d’une instance EC2. Le Problème Une instance importante a été supprimée par erreur. Contraintes Expliquer les différences entre stop, reboot et terminate. Proposer une bonne pratique pour éviter la suppression accidentelle (ex: activation de la protection contre la terminaison). Livrable attendu Une configuration EC2 sécurisée évitant les suppressions involontaires.

Contexte Une instance EC2 utilisée pour des tests critiques s’arrête de manière inattendue. Le Problème Elle a été lancée en mode Spot Instance et peut être interrompue. Contraintes Identifier la différence entre On-Demand et Spot. Proposer une solution adaptée pour un environnement stable. Livrable attendu Une configuration EC2 garantissant une disponibilité continue pour les besoins critiques.

Contexte Un administrateur ne parvient pas à se connecter en SSH à une instance EC2. Le Problème La règle du Security Group n’autorise pas le port 22. Contraintes Mettre à jour le Security Group pour autoriser le port 22 uniquement depuis l’adresse IP de l’administrateur. Vérifier la configuration de la paire de clés. Livrable attendu Une connexion SSH fonctionnelle et sécurisée à l’instance EC2.

Contexte Une instance EC2 héberge une application interne accessible uniquement à l’équipe. Le Problème Le Security Group autorise tout le trafic entrant : Type: All Traffic Source: 0.0.0.0/0 Contraintes Restreindre les règles afin de n’autoriser que les ports nécessaires (ex: 22 pour SSH, 80 pour HTTP) et limiter l’accès à des adresses IP spécifiques. Livrable attendu Un Security Group sécurisé respectant le principe du moindre privilège.

Contexte Une application web légère est déployée sur une instance EC2 destinée à un environnement de test. Le Problème L’instance actuelle utilise un type inadapté aux besoins (instance compute intensive) alors que la charge est faible. InstanceType: c5.4xlarge Contraintes Identifier le problème de dimensionnement et proposer un type d’instance plus adapté à une charge légère (ex: usage basique CPU/RAM). Ne pas modifier l’architecture globale. Livrable attendu Une configuration EC2 corrigée avec un type d’instance cohérent avec le besoin.

Contexte Une instance EC2 est lancée dans une région éloignée des utilisateurs finaux. Le Problème La latence est élevée en raison du mauvais choix de région. Contraintes Identifier une région AWS plus proche des utilisateurs et relancer l’instance dans cette région. Livrable attendu Une instance EC2 optimisée pour réduire la latence utilisateur.

Contexte Une équipe souhaite déployer une application simple sur AWS pour un environnement de développement. Le Problème Il faut configurer correctement une instance EC2 de base. Contraintes Créer une instance avec un type adapté (ex: t2.micro ou équivalent), associer une paire de clés, choisir un VPC par défaut et configurer un Security Group autorisant uniquement le port SSH depuis une IP spécifique. Livrable attendu Une instance EC2 fonctionnelle et sécurisée prête à être utilisée.

Contexte Une application nécessite un stockage persistant pour conserver des fichiers après redémarrage. Le Problème Le stockage actuel n’est pas dimensionné correctement. Contraintes Configurer un volume EBS de taille adaptée, l’attacher à l’instance EC2 et vérifier qu’il persiste après redémarrage. Livrable attendu Une instance EC2 disposant d’un stockage persistant correctement configuré.

Contexte Une application hébergée sur EC2 en région us-east-1 est principalement utilisée par des utilisateurs européens. Le Problème Les utilisateurs signalent une latence élevée. Contraintes Identifier la cause probable liée au choix de région. Proposer une solution adaptée impliquant le déploiement dans une région plus proche et éventuellement l’utilisation de plusieurs Availability Zones. Livrable attendu Une analyse technique expliquant l’impact de la région et une proposition d’optimisation.

Contexte Une base de données interne tourne sur une instance Spot. Le Problème L’instance est régulièrement interrompue, causant des interruptions de service. Contraintes Expliquer pourquoi Spot est inadapté à ce cas et proposer un modèle plus approprié (On-Demand ou Reserved). Justifier techniquement. Livrable attendu Une analyse argumentée du bon modèle de tarification EC2 pour une base critique.

Contexte Plusieurs instances EC2 privées doivent être accessibles uniquement par les administrateurs. Le Problème Actuellement, toutes les instances sont exposées avec une IP publique pour permettre SSH. Contraintes Proposer une architecture utilisant un bastion host dans un subnet public et des instances applicatives dans un subnet privé. Expliquer le rôle des Security Groups. Livrable attendu Une description claire d’une architecture réseau sécurisée basée sur EC2.

Contexte Une application web est déployée sur une seule instance EC2 exposée publiquement. Lors des pics de trafic, le serveur devient lent et parfois indisponible. Le Problème L’architecture actuelle ne permet ni montée en charge automatique ni haute disponibilité. Contraintes Proposer une amélioration basée sur des services EC2 natifs permettant la scalabilité et la tolérance aux pannes. Expliquer le rôle d’un Load Balancer et d’un Auto Scaling Group. Justifier les choix. Livrable attendu Une proposition d’architecture EC2 scalable décrite clairement, avec explication du fonctionnement des composants.

Contexte Une application critique stocke ses données sur le volume root d’une instance EC2. Le Problème En cas de suppression de l’instance, les données risquent d’être perdues. Contraintes Proposer une architecture plus fiable utilisant des volumes EBS séparés et expliquer le comportement des volumes lors du stop ou terminate. Livrable attendu Une explication claire de la solution garantissant la persistance des données.

Contexte Une application web subit des variations importantes de trafic. Le Problème L’infrastructure EC2 actuelle est statique et ne s’adapte pas aux variations de charge. Contraintes Expliquer comment configurer un Auto Scaling Group basé sur une métrique CPU (ex: scale out au-dessus de 70%). Décrire les composants nécessaires. Livrable attendu Une description détaillée du mécanisme d’Auto Scaling EC2 et de son fonctionnement.

Contexte Une application critique tourne sur une seule instance EC2 dans une unique Availability Zone. Le Problème Une panne d’AZ rendrait l’application indisponible. Contraintes Proposer une architecture utilisant plusieurs Availability Zones et expliquer comment EC2 et un Load Balancer peuvent améliorer la résilience. Livrable attendu Une description détaillée d’une architecture EC2 haute disponibilité.

Contexte Une entreprise utilise plusieurs instances EC2 de type m5.large pour des environnements de développement peu utilisés. Le Problème Les coûts AWS sont élevés alors que l’utilisation CPU moyenne est inférieure à 10%. Contraintes Analyser la situation et proposer des optimisations possibles : redimensionnement, instances réservées, arrêt automatique hors heures ouvrées. Justifier les choix. Livrable attendu Une stratégie claire d’optimisation des coûts EC2 avec justification technique.

Contexte Une application stocke des données critiques sur un volume EBS attaché à EC2. Le Problème Aucune stratégie de sauvegarde n’est en place. Contraintes Proposer une stratégie basée sur des snapshots EBS automatisés. Expliquer leur fonctionnement et leur impact sur la restauration des données. Livrable attendu Une stratégie de sauvegarde EC2/EBS décrite clairement avec justification technique.

Contexte Une instance EC2 héberge une API accessible sur le port 80 et autorise actuellement le trafic entrant depuis 0.0.0.0/0 sur plusieurs ports. Le Problème La configuration expose inutilement des services sensibles. Contraintes Proposer une stratégie de sécurisation incluant restriction des Security Groups, séparation des rôles (bastion host si nécessaire) et principe du moindre privilège. Livrable attendu Une explication structurée décrivant les corrections de sécurité à appliquer.

Contexte Une architecture EC2 expose plusieurs instances avec IP publiques et Security Groups permissifs. Le Problème Des audits de sécurité révèlent un risque élevé d’intrusion et de mouvements latéraux internes. Contraintes Proposer une refonte incluant séparation réseau public/privé, bastion host ou service d’accès sécurisé, restriction des Security Groups et principe du moindre privilège. Justifier chaque décision. Livrable attendu Une architecture sécurisée EC2 réduisant significativement la surface d’attaque.

Contexte Une application utilise un Auto Scaling Group basé sur la CPU, mais les utilisateurs signalent toujours des lenteurs. Le Problème L’augmentation du nombre d’instances ne résout pas totalement le problème. Contraintes Identifier les causes possibles : goulot d’étranglement base de données, mauvaise configuration Load Balancer, type d’instance inadapté. Proposer des améliorations techniques. Livrable attendu Une analyse complète identifiant les causes et proposant des solutions adaptées.

Contexte Une application critique doit rester disponible même en cas de panne complète d’une région AWS. Le Problème L’architecture actuelle est déployée dans une seule région avec plusieurs Availability Zones, ce qui ne protège pas contre une panne régionale majeure. Contraintes Proposer une architecture multi-régions utilisant EC2, Load Balancer et mécanisme de routage global (ex: DNS basé sur la santé). Expliquer la synchronisation des données et les implications en termes de coût et complexité. Livrable attendu Une description détaillée d’une architecture EC2 multi-régions assurant continuité de service et résilience avancée.

Contexte Une application monolithique évolue vers une architecture microservices. Le Problème Il faut assurer isolation, scalabilité indépendante et sécurité entre services. Contraintes Proposer une architecture EC2 adaptée : séparation par Auto Scaling Groups, subnets dédiés, Security Groups spécifiques et Load Balancers internes. Expliquer comment garantir isolation et communication contrôlée. Livrable attendu Une proposition d’architecture EC2 adaptée aux microservices avec justification technique complète.

Contexte Une application interne doit être accessible uniquement via un réseau privé d’entreprise. Le Problème L’architecture actuelle expose des IP publiques pour permettre l’accès distant. Contraintes Proposer une architecture EC2 entièrement privée avec subnets privés, NAT Gateway si nécessaire et accès sécurisé via VPN ou connexion dédiée. Expliquer la circulation du trafic. Livrable attendu Une architecture réseau EC2 garantissant un accès privé sécurisé sans exposition publique.

Contexte Une application critique stocke des données sur plusieurs volumes EBS. Le Problème L’entreprise souhaite garantir restauration rapide et cohérente en cas d’incident majeur. Contraintes Proposer une stratégie combinant snapshots automatisés, réplication inter-région et tests réguliers de restauration. Expliquer l’impact sur coûts et temps de récupération. Livrable attendu Une stratégie complète assurant protection des données et restauration rapide sur EC2.

Contexte Une application comporte une charge de base constante et des pics intermittents importants. Le Problème L’entreprise utilise uniquement des instances On-Demand, entraînant des coûts élevés. Contraintes Proposer une combinaison optimisée d’instances Reserved pour la charge stable, On-Demand pour flexibilité et Spot pour les traitements non critiques. Justifier les choix selon criticité et tolérance aux interruptions. Livrable attendu Une stratégie de tarification EC2 optimisée combinant performance, disponibilité et réduction des coûts.

Contexte Une entreprise utilise des instances x86 classiques pour ses workloads EC2. Le Problème Elle souhaite réduire ses coûts sans compromettre les performances. Contraintes Analyser les avantages et contraintes d’une migration vers des instances basées sur AWS Graviton (ARM). Évaluer compatibilité logicielle, performance et coûts. Livrable attendu Une analyse argumentée permettant de décider si la migration vers Graviton est pertinente.

Contexte Une entreprise doit garantir un RTO de 1 heure et un RPO de 15 minutes pour une application hébergée sur EC2. Le Problème Aucune stratégie de reprise après sinistre n’est formalisée. Contraintes Proposer une stratégie de Disaster Recovery adaptée (backup & restore, pilot light ou warm standby). Expliquer les mécanismes de réplication, snapshots EBS et redéploiement automatisé. Livrable attendu Une stratégie complète de reprise d’activité respectant les objectifs RTO et RPO définis.

Contexte Une plateforme e-commerce subit des pics extrêmes de trafic lors d’événements promotionnels. Le Problème L’infrastructure actuelle ne scale pas assez vite et entraîne des erreurs 503 pendant les pics. Contraintes Proposer une stratégie combinant Auto Scaling avancé, pré-warming, Load Balancer et éventuellement utilisation d’instances Spot en complément. Expliquer comment garantir stabilité et optimisation des coûts. Livrable attendu Une architecture détaillée capable de gérer des charges massives et imprévisibles tout en contrôlant les coûts.