Aller au contenu principal

Lab : Scénarios de Dépannage EC2

Objectifs du Lab​

Ce lab vous met face à des scénarios de panne réalistes. Pour chaque scénario, vous devrez :

  • Analyser les symptômes
  • Formuler des hypothèses
  • Proposer des tests de diagnostic
  • Identifier la solution
Exercice Théorique

Ce lab est un exercice d'analyse. Pas besoin d'accès AWS - travaillez sur papier ou document.

Durée Estimée​

1h30 à 2h

Scénario 1 : Le Site Web Inaccessible​

Contexte​

Situation :
- Instance EC2 lancée il y a 1 heure
- AMI : Amazon Linux 2023
- Type : t3.micro
- Apache installé et démarré
- Vous pouvez vous connecter en SSH
- Mais http://52.1.2.3 ne répond pas (timeout)

Configuration actuelle :
- VPC : vpc-default
- Subnet : public (avec IGW)
- Security Group : sg-web

Informations Disponibles​

État instance : running
Status checks : 2/2 passed

Security Group sg-web :
Inbound Rules:
- SSH (22) : 0.0.0.0/0
- HTTP (80) : 10.0.0.0/8

Outbound Rules:
- All traffic : 0.0.0.0/0

Questions​

  1. Quel est le symptôme précis ?

  2. Listez 3 hypothèses par ordre de probabilité

  3. Quelle est la cause la plus probable ?

  4. Quelle commande/action corrige le problème ?

  5. Comment valider que c'est résolu ?

📋 Voir la solution

1. Symptôme : HTTP timeout vers 52.1.2.3 port 80, alors que SSH fonctionne.

2. Hypothèses :

  1. Security Group n'autorise pas HTTP depuis Internet (HAUTE)
  2. Apache n'écoute pas sur le bon port (MOYENNE)
  3. Firewall iptables sur l'instance (BASSE)

3. Cause : Le Security Group autorise HTTP (port 80) seulement depuis 10.0.0.0/8 (réseau privé), pas depuis Internet (0.0.0.0/0).

4. Correctif :

aws ec2 authorize-security-group-ingress \
    --group-id sg-web \
    --protocol tcp \
    --port 80 \
    --cidr 0.0.0.0/0

5. Validation :

curl http://52.1.2.3
# ou
Ouvrir http://52.1.2.3 dans un navigateur

Scénario 2 : SSH Impossible​

Contexte​

Situation :
- Nouvelle instance lancée
- Vous avez téléchargé la clé .pem
- Instance : running, status checks OK
- IP publique : 52.2.3.4

Commande exécutée :
$ ssh -i cle.pem ec2-user@52.2.3.4
ssh: connect to host 52.2.3.4 port 22: Connection timed out

Informations Disponibles​

Instance details :
- ID : i-0123456789
- State : running
- Public IP : 52.2.3.4
- Subnet : subnet-abc123 (10.0.2.0/24)
- Security Group : sg-default

Security Group sg-default :
Inbound Rules:
- (aucune règle)

Outbound Rules:
- All traffic : 0.0.0.0/0

Subnet subnet-abc123 :
- Route Table : rtb-main
- Routes :
  - 10.0.0.0/16 → local
  - (pas d'autre route)

Questions​

  1. Identifiez TOUS les problèmes dans cette configuration

  2. Classez-les par priorité de correction

  3. Proposez les commandes pour corriger chaque problème

📋 Voir la solution

1. Problèmes identifiés :

Problème A - Security Group : Aucune règle inbound = port 22 bloqué

Problème B - Route Table : Pas de route vers Internet Gateway = pas d'accès Internet

2. Priorité :

  1. Route Table (sans route, même avec SG OK, ça ne marchera pas)
  2. Security Group

3. Correctifs :

# 1. Créer/attacher un Internet Gateway (si pas fait)
aws ec2 create-internet-gateway
aws ec2 attach-internet-gateway --vpc-id vpc-xxx --internet-gateway-id igw-xxx

# 2. Ajouter la route vers IGW
aws ec2 create-route \
    --route-table-id rtb-main \
    --destination-cidr-block 0.0.0.0/0 \
    --gateway-id igw-xxx

# 3. Ajouter règle SSH au Security Group
aws ec2 authorize-security-group-ingress \
    --group-id sg-default \
    --protocol tcp \
    --port 22 \
    --cidr 0.0.0.0/0

Scénario 3 : Instance qui Termine Immédiatement​

Contexte​

Situation :
- Vous lancez une instance
- Elle passe de "pending" à "running" puis "terminated"
- Le tout en moins de 30 secondes
- Vous avez essayé 3 fois, même résultat

Configuration :
- AMI : ami-custom-xyz (AMI personnalisée)
- Type : t3.large
- Région : us-east-1

Informations Disponibles​

Console EC2 → State transition reason :
"Client.VolumeLimitExceeded: Volume limit exceeded"

Vos volumes EBS actuels :
- 45 volumes de 100 GB chacun
- Total : 4.5 TB

Votre AMI ami-custom-xyz :
- Créée il y a 6 mois
- Root volume : 200 GB
- Utilise le snapshot snap-olddata

Questions​

  1. Quelle est la cause de la terminaison ?

  2. Comment vérifier les limites de votre compte ?

  3. Quelles sont les solutions possibles ? (au moins 3)

📋 Voir la solution

1. Cause : Le message "Volume limit exceeded" indique que vous avez atteint le quota de stockage EBS pour votre compte.

2. Vérifier les limites :

aws service-quotas get-service-quota \
    --service-code ebs \
    --quota-code L-D18FCD1D

# Ou via la console :
# Service Quotas → Amazon Elastic Block Store (EBS)

3. Solutions :

Solution A - Supprimer des volumes non utilisés :

# Lister les volumes non attachés
aws ec2 describe-volumes \
    --filters "Name=status,Values=available"

# Supprimer
aws ec2 delete-volume --volume-id vol-xxx

Solution B - Demander une augmentation de quota :

aws service-quotas request-service-quota-increase \
    --service-code ebs \
    --quota-code L-D18FCD1D \
    --desired-value 10000

Solution C - Utiliser une autre région : Les quotas sont par région. Lancer dans eu-west-1 par exemple.

Solution D - Utiliser un type d'instance avec instance store : Certaines instances ont du stockage local, pas EBS.

Scénario 4 : Base de Données Injoignable​

Contexte​

Architecture :
- Instance Web (subnet public) : 10.0.1.10
- Instance BDD (subnet privé) : 10.0.2.20
- Les deux dans le même VPC

Problème :
- Depuis l'instance Web, impossible de se connecter à MySQL
- telnet 10.0.2.20 3306 → timeout

L'instance BDD fonctionne :
- Status checks OK
- MySQL est démarré (vérifié via Session Manager)

Informations Disponibles​

Security Group sg-web (instance web) :
Inbound : HTTP 80, SSH 22
Outbound : All traffic 0.0.0.0/0

Security Group sg-database (instance BDD) :
Inbound : MySQL (3306) depuis 0.0.0.0/0
Outbound : All traffic 0.0.0.0/0

NACL du subnet privé (nacl-private) :
Inbound Rules :
  Rule 100 : DENY TCP 3306 from 0.0.0.0/0
  Rule 200 : ALLOW ALL from 0.0.0.0/0
Outbound Rules :
  Rule 100 : ALLOW ALL to 0.0.0.0/0

Questions​

  1. Pourquoi la connexion échoue-t-elle ?

  2. Expliquez pourquoi la règle du Security Group ne suffit pas

  3. Comment corriger le problème ?

📋 Voir la solution

1. Cause : La NACL bloque le port 3306 avec une règle DENY (rule 100) qui est évaluée AVANT la règle ALLOW (rule 200).

2. Explication :

  • Les Security Groups sont évalués ensemble (toutes les règles)
  • Les NACLs sont évaluées dans l'ordre des numéros de règle
  • Rule 100 (DENY 3306) est évaluée avant Rule 200 (ALLOW ALL)
  • Donc le port 3306 est bloqué malgré le SG

3. Correctif : Supprimer ou modifier la règle 100 de la NACL :

# Option A : Supprimer la règle DENY
aws ec2 delete-network-acl-entry \
    --network-acl-id nacl-private \
    --rule-number 100 \
    --ingress

# Option B : Modifier pour autoriser depuis le subnet web
aws ec2 replace-network-acl-entry \
    --network-acl-id nacl-private \
    --rule-number 100 \
    --protocol tcp \
    --port-range From=3306,To=3306 \
    --cidr-block 10.0.1.0/24 \
    --rule-action allow \
    --ingress

Scénario 5 : Permission Denied (Défi)​

Contexte​

Situation :
- Instance Amazon Linux 2023 lancée avec clé "ma-cle"
- Fichier ma-cle.pem présent sur votre machine
- Permission du fichier : 400 (OK)

Commande :
$ ssh -i ma-cle.pem ec2-user@52.5.6.7
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Tests effectués :
- Security Group : port 22 ouvert vers 0.0.0.0/0
- Instance : running, status OK
- Ping : fonctionne

Informations Supplémentaires​

Vous avez deux fichiers de clé dans votre dossier :
- ma-cle.pem (créé hier)
- ma-cle.pem.bak (créé la semaine dernière)

L'instance a été lancée la semaine dernière.

Questions​

  1. Quelle est probablement la cause ?

  2. Comment vérifier votre hypothèse ?

  3. Quelles sont les options pour récupérer l'accès ?

📋 Voir la solution

1. Cause probable : Vous utilisez la mauvaise clé. Le fichier "ma-cle.pem" actuel (créé hier) n'est pas la clé qui a été associée à l'instance (lancée la semaine dernière).

2. Vérification :

# Voir quelle clé est associée à l'instance
aws ec2 describe-instances --instance-ids i-xxx \
    --query 'Reservations[].Instances[].KeyName'

# Comparer l'empreinte de votre clé
ssh-keygen -l -f ma-cle.pem
ssh-keygen -l -f ma-cle.pem.bak

3. Options de récupération :

Option A - Utiliser la bonne clé :

ssh -i ma-cle.pem.bak ec2-user@52.5.6.7

Option B - EC2 Instance Connect (si AMI compatible) : Console → Instance → Connect → EC2 Instance Connect

Option C - Systems Manager Session Manager : Si l'agent SSM est installé et rôle IAM configuré.

Option D - Créer une AMI et relancer :

  1. Créer AMI de l'instance
  2. Lancer nouvelle instance avec nouvelle clé
  3. Monter le volume de l'ancienne instance
  4. Modifier ~/.ssh/authorized_keys

Livrables du Lab​

Rapport de Dépannage (pour 2 scénarios au choix)​

Pour chaque scénario choisi, documentez :

# Scénario X : [Titre]

## 1. Symptôme Identifié
[Description précise]

## 2. Hypothèses Formulées
1. [Hypothèse 1] - Probabilité: Haute/Moyenne/Basse
2. [Hypothèse 2]
3. [Hypothèse 3]

## 3. Tests de Diagnostic
- Test 1 : [Commande/Action] → Résultat attendu
- Test 2 : [Commande/Action] → Résultat attendu

## 4. Cause Racine
[Explication de la vraie cause]

## 5. Solution
[Commandes ou actions pour corriger]

## 6. Validation
[Comment vérifier que c'est résolu]

## 7. Prévention
[Comment éviter ce problème à l'avenir]

Grille d'Évaluation​

CritèrePoints
Symptôme bien défini2
Hypothèses pertinentes et ordonnées3
Tests de diagnostic corrects3
Cause racine identifiée3
Solution correcte3
Validation proposée2
Clarté et structure2
Total par scénario18

Félicitations ! Vous avez complété le lab de dépannage EC2.