FAQ AWS : EC2, S3, EBS, ELB et Auto Scaling (guide FR)
À la fin de cette page, vous aurez des réponses concrètes (examen SAA + lab) aux questions fréquentes sur EC2, S3, EBS, ELB et Auto Scaling, en Region
ca-central-1, sans supprimer la liste historique live du site.Niveau : Débutant → Intermediate · Temps estimé : 35–45 min · Versions testées : AWS Console / CLI v2 (2026) · Dernière vérification : 2026-09-11 · Region lab :
ca-central-1← Hub : Démarrer avec AWS · Révision série : Quiz & FAQ SA · Aussi : IAM
Publish : HOLD · Post live : #1348
Prérequis
- Compte AWS de lab (Free Tier) et profil CLI
lab— voir Démarrer avec AWS - Notions IAM (users, groupes, rôles, politiques)
- Optionnel : EC2 + SSM ou S3 sécurisé
- Lecture seule pour valider la Region :
ec2:DescribeRegions,sts:GetCallerIdentity
export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
Coût estimé : 0 € — FAQ de lecture / révision. Aucune ressource facturable créée ici. Si vous reproduisez un lab lié, supprimez EC2 / ALB / ASG / volumes / buckets en fin de session.
Contenu d’origine conservé (AWS — FAQs)
Le live historique listait cinq thèmes sous AWS- FAQs. On conserve ces cinq puces et on les transforme en sections FAQ détaillées :
(Sommaire — alt : « Cinq thèmes FAQ AWS P1 : EC2, S3, EBS, ELB, Auto Scaling ».)
Chaque section ci-dessous reprend le thème live (EC2, S3, EBS, ELB, Autoscaling) avec 4 à 6 questions/réponses orientées Solutions Architect Associate et labs en ca-central-1. Utilisez-la comme aide-mémoire avant un quiz ou un lab ; pour la clôture complète de la série P1, enchaînez sur Quiz & FAQ SA.
EC2 – FAQs
Qu’est-ce qu’une instance EC2 et où la placer en lab ?
Une instance EC2 est une machine virtuelle (compute) placée dans une Availability Zone d’une Region. Pour la série : toujours ca-central-1, profil lab, et un rôle d’instance minimal. Préférez SSM Session Manager plutôt que d’ouvrir le SSH public — guide : lancer une instance avec SSM. Pensez aussi à taguer Project=lab pour le nettoyage Cost Explorer.
Instance store vs EBS : données persistantes ?
EBS survit (même AZ) au stop/start si le root n’est pas détruit ; l’instance store est éphémère (perdu au stop / terminate / host failure). Lab et prod classiques : EBS. Store = cache / scratch.
Quels types retenir pour le SAA ?
Familles T/M (général), C (compute), R (mémoire), I/D (stockage). Lab Free Tier : t3.micro / t2.micro. Spot = moins cher, interruptible — types & Spot.
Security Group vs NACL ?
SG = stateful, sur l’ENI : entrée autorisée, retour implicite. NACL = stateless, au subnet. Lab : SG restrictifs + SSM (éviter 0.0.0.0/0 sur SSH).
User data et AMI ?
User data = bootstrap au boot. AMI = image réutilisable. Pour scaler : AMI ou Launch Template + Auto Scaling, pas un script fragile recopié à la main.
Coût d’une instance oubliée ?
Même une micro hors Free Tier facture à l’heure + EBS. Activez un budget (≥ 1 USD), terminez les labs, vérifiez EIP et volumes orphelins.
S3 – FAQs
Bucket : régional ou global ?
Le nom est globalement unique ; le bucket est régional. Créez-le en ca-central-1 avec LocationConstraint=ca-central-1. Guide : bucket S3 sécurisé.
Block Public Access remplace-t-il IAM ?
Non. BPA est un filet anti-fuite publique (ACL / policies publiques). Vous devez toujours concevoir des politiques IAM identity-based et, si besoin, des bucket policies. Deny explicite + BPA = défense en profondeur — BPA ne remplace ni le moindre privilège ni le chiffrement.
SSE-S3 ou SSE-KMS en lab ?
SSE-S3 (AES256) suffit (chiffrement au repos sans gérer de clé). SSE-KMS = contrôle fin + audit CloudTrail — prod / conformité. Activez le chiffrement par défaut.
Versioning : quand ?
Contre suppressions / overwrite accidentels ; chaque version coûte. En fin de lab : videz versions + delete markers avant delete-bucket.
Pourquoi AccessDenied en admin-lab ?
Mauvaise Region CLI, BPA bloquant une policy publique, Deny aws:SecureTransport, ou policy trop stricte sur le préfixe. Vérifiez get-bucket-policy et AWS_DEFAULT_REGION=ca-central-1.
Durabilité vs disponibilité (SAA) ?
S3 Standard : durabilité ≈ 11 neuf multi-AZ ; disponibilité conception ~99,99 %. Ce n’est pas un backup hors compte : versioning + réplication selon le besoin.
EBS – FAQs
EBS est lié à quelle AZ ?
Un volume EBS vit dans une seule AZ ; l’instance doit être dans la même. Multi-AZ : snapshots → nouveaux volumes, ou EFS / bases managées. Lab : volumes & snapshots.
gp3 vs io2 en lab ?
gp3 = usage général (IOPS/throughput réglables). io2 = IOPS provisionnés élevés. Lab SAA : gp3 sauf scénario IOPS explicite.
Snapshot = backup portable ?
Snapshot = copie incrémentale dans S3 géré AWS (bucket invisible), régional. Copiez pour une autre Region. Restaurez en volume (autre AZ) ou créez une AMI depuis le root.
Delete on termination ?
Si coché sur le root, terminate détruit le volume (sauf snapshot préalable). Volumes détachés continuent de facturer.
Chiffrement après coup ?
Pas de bascule « en place » : snapshot → copie chiffrée → nouveau volume. Activez le chiffrement par défaut compte/Region pour les nouveaux volumes.
EBS vs store vs EFS
| Besoin | Service |
|---|---|
| Disque bloc AZ (souvent 1 instance) | EBS |
| Scratch local éphémère | Instance store |
| Partage multi-AZ / multi-instances NFS | EFS |
ELB – FAQs
ALB, NLB, CLB en 2026 ?
ALB (L7 HTTP/HTTPS) = défaut web/API. NLB (L4) = perf, IP statiques. CLB = legacy. Lab : ALB & équilibrage.
ALB multi-AZ ?
Oui pour la haute disponibilité : sous-réseaux publics (ou privés + schéma adapté) dans au moins deux AZ, avec des targets répartis. Une ALB mono-AZ n’est pas un design exam / prod sérieux : une panne AZ coupe tout le front.
Health checks HTTP ou TCP ?
Pour une app HTTP : check HTTP/HTTPS sur /health plutôt que TCP seul (port ouvert ≠ app OK). Target unhealthy sort du pool.
SG : ALB → instances ?
SG ALB : 80/443 depuis Internet (ou CloudFront). SG instances : port app uniquement depuis le SG ALB — pas 0.0.0.0/0. Pattern SAA récurrent.
Sticky sessions ?
Utile si état en mémoire locale. Préférez stateless + store (Redis, cookie, JWT). Stickiness ALB complique le scale-in.
Coût ALB oubliée ?
Facturation horaire + LCU. ALB + EC2 oubliés = surprise Cost Explorer — supprimez avec le lab.
Autoscaling – FAQs
Rôle d’un ASG ?
L’Auto Scaling Group maintient un effectif min / desired / max, remplace les instances unhealthy, et applique des politiques de scale (CPU, ALB request count, métriques custom). En 2026, couplez toujours un Launch Template versionné — lab : ASG + Launch Template.
Launch Template vs Launch Configuration ?
Launch Template = moderne (versions, mix On-Demand/Spot). Launch Configuration = legacy. Nouveau design : Launch Template.
Scale-out / scale-in : métriques ?
Classiques : CPUAverage, ALBRequestCountPerTarget, NetworkOut. Pas de scale CPU seul si le goulot est la base. Prévoyez un cooldown.
Health check ASG : EC2 ou ELB ?
Derrière une ALB : health check ELB pour remplacer une instance qui répond mal à l’ALB (pas seulement le status EC2).
Combien d’AZ ?
≥ 2 AZ (aligné sur l’ALB). Mono-AZ ne protège pas d’une panne AZ.
Spot dans un ASG ?
Interruption possible : stratégie de capacité + workloads tolérants. Lab débutant : On-Demand ; avancé : types & Spot.
Erreurs fréquentes
| Symptôme | Cause probable | Correction |
|---|---|---|
| Instance inaccessible en SSH | SG / pas de SSM | Préférer SSM ; pas de 22 public |
| Bucket « introuvable » | Mauvaise Region CLI | AWS_DEFAULT_REGION=ca-central-1 |
| Volume EBS non attachable | AZ différente | Même AZ ; sinon snapshot → restore |
Targets ALB unhealthy |
Port / path / SG | Aligner listener, SG ASG←ALB, /health |
| ASG ne scale pas | Alarme / policy / cooldown | Métrique, IAM, desired/max |
| Facture surprise | ALB / EIP / EBS orphelins | Budgets + nettoyage fin de lab |
Confusion faqs vs quiz série |
Mauvais slug | Ici #1348 faqs ; révision = aws-sa-quiz-faq |
Mini-quiz (5 questions — style SAA)
1. Un volume EBS est disponible :
– A. Dans toutes les Regions du compte
– B. Dans une seule Availability Zone
– C. Uniquement via Internet Gateway
2. Block Public Access sur S3 :
– A. Remplace complètement IAM
– B. Empêche surtout une exposition publique accidentelle
– C. Active automatiquement CloudFront
3. Pour une API HTTP moderne, le load balancer par défaut est :
– A. Classic Load Balancer
– B. Network Load Balancer uniquement
– C. Application Load Balancer
4. ASG derrière ALB — health check pour remplacer les instances applicatives défaillantes :
– A. Uniquement EC2 status checks
– B. Health check de type ELB / ALB
– C. Ping ICMP depuis le bastion
5. Données sur instance store après un stop :
– A. Conservées comme un snapshot EBS
– B. Perdues (stockage éphémère)
– C. Répliquées automatiquement multi-AZ
Réponses : 1‑B · 2‑B · 3‑C · 4‑B · 5‑B
Pour aller plus loin
Relisez d’abord les cinq thèmes de cette FAQ à voix haute (sans notes), puis validez avec le mini-quiz. Ensuite :
- Docs AWS : EC2 · S3 · EBS · ELB · Auto Scaling
- Révision globale : Quiz & FAQ Solutions Architect
Maillage série AWS (P1)
| ← Hub | Démarrer avec AWS |
| Compute | EC2 + SSM · Types & Spot |
| Stockage | S3 sécurité · EBS volumes & snapshots |
| HA | ALB · ASG + Launch Template |
| Identité | IAM |
| Clôture P1 | Quiz & FAQ SA |
Retour parcours AWS — hub de la série et leçons sœurs.
