Débutant

Fondations Cloud

IAM, réseau VPC, calcul EC2 et stockage S3 : les fondations indispensables avant toute architecture

Module 1

IAM et sécurité du compte

Utilisateurs, groupes, rôles, politiques : qui peut faire quoi sur quelles ressources.

1. Le compte root : à verrouiller en premier

Le compte root possède tous les droits sans restriction. Dès la création du compte : supprimez ses clés d'accès, activez le MFA (authentification multifacteur), créez un utilisateur administrateur IAM pour l'usage quotidien et ne réutilisez le root que pour les tâches qui l'exigent (changement de support, fermeture du compte).

Pourquoi c'est important : Un stagiaire utilise une clé administrateur retrouvée dans un wiki, supprime un bucket de production et expose des clés sur GitHub. Le lendemain, des instances de minage tournent dans trois régions et la facture explose. En tant qu'architecte, verrouiller le root avec MFA et appliquer le moindre privilège via IAM, c'est ce qui sépare un incident mineur d'une panne et d'une facture incontrôlable.
L'analogie qui aide : Pensez à IAM comme au trousseau d'un gardien d'hôtel : le root est le passe général coffré au bureau, les groupes sont les trousseaux par étage (ménage, réception, maintenance) et les rôles sont les badges temporaires remis à un prestataire, valables deux heures puis désactivés.

2. Utilisateurs, groupes et rôles

  • Utilisateur IAM : identité permanente (humaine ou applicative) avec mot de passe console et/ou clés d'accès.
  • Groupe IAM : on n'attache jamais une politique directement à un utilisateur en production, on l'ajoute à un groupe (ex. : Dev, Ops, Compta).
  • Rôle IAM : identité temporaire sans identifiants permanents. Une instance EC2 ou une fonction Lambda assume un rôle via STS pour obtenir des droits : c'est la méthode examen pour « donner des droits à une application sans stocker de clés ».

3. Politiques : le langage des permissions

Document JSON avec Effect (Allow/Deny), Action et Resource. Un Deny explicite l'emporte toujours sur un Allow. Politiques gérées par AWS (ex. : ReadOnlyAccess), gérées par le client, et inline. Principe du moindre privilège : n'accorder que les actions strictement nécessaires.

Démonstration pas à pas : Besoin : une application sur EC2 doit lire des objets S3 sans stocker de secret. Étape 1 : créez un rôle IAM avec la politique AmazonS3ReadOnlyAccess restreinte au bucket voulu. Étape 2 : attachez ce rôle à l'instance via un profil d'instance. Étape 3 : l'application récupère des identifiants temporaires via STS. Pourquoi pas un utilisateur IAM avec clés en dur : rotation manuelle, fuite dans le code, aucun audit fin. Le rôle supprime ces risques d'un coup.
aws iam create-user --user-name alice
aws iam create-group --group-name dev
aws iam add-user-to-group --user-name alice --group-name dev
aws iam attach-group-policy --group-name dev --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess
aws iam create-role --role-name ec2-s3-read --assume-role-policy-document file://trust.json
aws iam attach-role-policy --role-name ec2-s3-read --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
aws iam list-users
aws iam get-role --role-name ec2-s3-read
Points d'examen :
  • Root : MFA + pas de clés + usage minimal.
  • Application sur EC2 qui accède à S3 : rôle IAM (jamais de clés en dur dans le code).
  • Deny explicite prioritaire ; IAM est global (non régional).
  • STS AssumeRole pour l'accès inter-comptes et les identités fédérées.
Pièges classiques : Un Deny explicite écrase toujours un Allow, même administrateur. IAM est global, pas régional : une erreur de politique s'applique partout. Ne créez jamais de clés pour le root et ne mettez jamais de clés en dur dans le code ou dans une AMI : à l'examen, toute réponse avec clés en dur pour une application EC2 est fausse.
À vous de jouer : Une application sur EC2 doit écrire dans DynamoDB avec le minimum de droits. Quelle approche choisissez-vous ?
Voir la réponse

Créez un rôle IAM avec une politique qui n'autorise que PutItem et UpdateItem sur la table visée, attachez-le à l'instance via un profil d'instance. Aucune clé stockée, droits limités, rotation automatique par STS.

Module 2

VPC : sous-réseaux, sécurité et passerelles

Votre réseau privé dans le cloud : CIDR, sous-réseaux publics/privés, NACL contre Security Groups.

1. Anatomie d'un VPC

Un VPC est un réseau isolé (ex. : 10.0.0.0/16) découpé en sous-réseaux par zone de disponibilité (AZ). Un sous-réseau est public si sa table de routage pointe 0.0.0.0/0 vers une Internet Gateway ; sinon il est privé. Les instances privées sortent vers Internet via une NAT Gateway placée dans un sous-réseau public (avec une EIP).

Pourquoi c'est important : Une base de données placée dans un sous-réseau public avec un Security Group ouvert à 0.0.0.0/0 est attaquée en quelques heures. À l'inverse, des instances privées sans NAT Gateway ne peuvent plus télécharger leurs patchs et tombent en panne de sécurité. Bien découper son VPC entre public et privé, c'est éviter à la fois l'intrusion et l'arrêt de production.
L'analogie qui aide : Voyez le VPC comme un immeuble : le hall et la vitrine sont publics avec une porte sur la rue (Internet Gateway), les bureaux sont privés et sortent par la coursive de service (NAT Gateway). Le Security Group est le vigile à la porte du bureau qui se souvient de vous, la NACL est le règlement d'étage appliqué à tous sans exception ni mémoire.

2. Security Groups contre NACL : le duel classique de l'examen

  • Security Group : pare-feu stateful au niveau de l'instance (ENI). Tout est refusé par défaut, on n'ajoute que des règles Allow. Le trafic retour est automatiquement autorisé.
  • NACL : pare-feu stateless au niveau du sous-réseau. Règles numérotées évaluées dans l'ordre, avec Allow et Deny. Il faut autoriser explicitement le retour (ports éphémères 1024-65535).

3. Connexions et passerelles

  • VPC Peering : relie deux VPC (même non transitif : A-B et B-C n'impliquent pas A-C).
  • Endpoints VPC : accès privé aux services AWS sans passer par Internet (Gateway pour S3/DynamoDB, Interface pour les autres).
  • VPN et Direct Connect : relient le réseau local au VPC (hybride).
  • VPC Flow Logs : journalisent le trafic réseau (accept/reject) vers CloudWatch ou S3.
Démonstration pas à pas : Besoin : héberger un site web public avec une base privée. Étape 1 : créez un VPC 10.0.0.0/16 avec deux sous-réseaux publics (10.0.1.0/24 et 10.0.2.0/24) et deux privés (10.0.11.0/24 et 10.0.12.0/24) sur deux AZ. Étape 2 : route 0.0.0.0/0 vers l'Internet Gateway pour les publics, vers la NAT Gateway pour les privés. Étape 3 : placez l'ALB en public, les EC2 et RDS en privé. Pourquoi pas tout en public : exposition directe de la base. Pourquoi pas un peering transitif : il ne l'est jamais, il faut un Transit Gateway.
aws ec2 create-vpc --cidr-block 10.0.0.0/16
aws ec2 create-subnet --vpc-id vpc-1234 --cidr-block 10.0.1.0/24 --availability-zone eu-west-3a
aws ec2 create-internet-gateway
aws ec2 attach-internet-gateway --vpc-id vpc-1234 --internet-gateway-id igw-5678
aws ec2 create-nat-gateway --subnet-id subnet-public --allocation-id eipalloc-9
aws ec2 authorize-security-group-ingress --group-id sg-111 --protocol tcp --port 443 --cidr 0.0.0.0/0
aws ec2 describe-vpcs
aws ec2 describe-subnets --filters Name=vpc-id,Values=vpc-1234
Points d'examen :
  • Public = route vers IGW ; privé + Internet sortant = NAT Gateway.
  • SG stateful (instance, Allow only) ; NACL stateless (sous-réseau, Allow/Deny numérotés).
  • Peering non transitif ; Endpoints = trafic privé vers S3/DynamoDB.
  • 5 adresses IP réservées par sous-réseau (ex. : /24 = 251 utilisables).
Pièges classiques : Security Group stateful au niveau instance avec uniquement des Allow, contre NACL stateless au niveau sous-réseau avec Allow et Deny numérotés et retour à autoriser (ports éphémères). Un sous-réseau n'est public que si sa table de routage envoie 0.0.0.0/0 vers une Internet Gateway. Retenez aussi les 5 IP réservées et le peering non transitif.
À vous de jouer : Une instance en sous-réseau privé doit télécharger des mises à jour sans être joignable depuis Internet. Que mettez-vous en place ?
Voir la réponse

Placez une NAT Gateway avec EIP dans le sous-réseau public et ajoutez une route 0.0.0.0/0 vers cette NAT dans la table du sous-réseau privé. Le Security Group reste fermé en entrée, la sortie vers Internet fonctionne pour les patchs.

Module 3

EC2 et EBS : le calcul et ses disques

Choisir la bonne instance, le bon disque, le bon modèle de prix : le trio gagnant de l'examen.

1. Instances EC2

  • Familles : C (compute), M (généraliste), R/X (mémoire), I/D (stockage), G/P (GPU), T (burstable à crédits CPU).
  • Tarifs : On-Demand (flexible), Spot (jusqu'à -90 %, interruptible), Reserved et Savings Plans (engagement 1-3 ans, -72 %), Dedicated Host (conformité).
  • AMI : image de lancement ; User Data : script exécuté une fois au premier démarrage ; métadonnées via 169.254.169.254.
  • Placement groups : cluster (faible latence), spread (AZ distinctes), partition (racks distincts).
Pourquoi c'est important : Un batch de calcul nocturne tourne en On-Demand à plein tarif alors qu'il supporterait une interruption, et des logs temporaires sont stockés sur des volumes io2 coûteux. Résultat : une facture trois fois trop élevée et un disque Instance Store perdu à chaque arrêt avec ses caches. Choisir le bon type EC2 et le bon volume EBS, c'est l'arbitrage direct entre panne et budget.
L'analogie qui aide : Louez vos EC2 comme des voitures : On-Demand est le taxi sans engagement, Spot est la voiture d'enchères à prix cassé mais reprise à tout moment, Reserved et Savings Plans sont l'abonnement annuel. L'EBS est votre disque dur externe attaché à une seule voiture, l'Instance Store est la boîte à gants vidée à chaque arrêt.

2. Volumes EBS

  • gp3/gp2 : SSD généraliste (gp3 : IOPS et débit réglables).
  • io1/io2 : SSD à IOPS provisionnées (bases critiques, multi-attach io1/io2).
  • st1/sc1 : HDD pour big data et archivage fréquent (ne démarrent pas un OS).
  • Snapshots : sauvegardes incrémentales stockées sur S3, chiffrables, copiables entre régions. Un volume EBS vit dans une seule AZ (le snapshot permet de le recréer ailleurs).
  • Instance Store : stockage éphémère local, perdu à l'arrêt (idéal pour caches).
Démonstration pas à pas : Besoin : un site stable 24/7 plus un batch nocturne de 4 heures. Étape 1 : couvrez le socle avec des Reserved ou Savings Plans (jusqu'à moins 72 pour cent). Étape 2 : lancez le batch sur du Spot avec file d'attente et reprise sur interruption. Étape 3 : système sur gp3 chiffré KMS, données critiques sur io2, AMI dorée via snapshot pour cloner vite. Pourquoi pas tout en On-Demand : surcoût massif. Pourquoi pas l'Instance Store pour la donnée : tout disparaît à l'arrêt.
aws ec2 run-instances --image-id ami-0abc --count 1 --instance-type t3.micro --subnet-id subnet-1 --security-group-ids sg-111
aws ec2 describe-instances --filters Name=instance-state-name,Values=running
aws ec2 stop-instances --instance-ids i-1234
aws ec2 start-instances --instance-ids i-1234
aws ec2 terminate-instances --instance-ids i-1234
aws ec2 create-volume --size 50 --volume-type gp3 --availability-zone eu-west-3a --encrypted
aws ec2 create-snapshot --volume-id vol-2222 --description "sauvegarde avant maj"
aws ec2 create-tags --resources i-1234 vol-2222 --tags Key=Name,Value=web-prod
Points d'examen :
  • Charge interruptible = Spot ; usage stable 24/7 = Reserved/Savings Plans.
  • EBS = une AZ ; snapshot = multi-région et base des AMI personnalisées.
  • Chiffrement EBS via KMS ; io2 multi-attach pour cluster actif-actif.
  • Hibernation et arrêt : les frais EC2 cessent, l'EBS reste facturé.
Pièges classiques : Spot égale interruptible, jamais pour une base critique sans file de reprise. Un volume EBS vit dans une seule AZ, seul son snapshot voyage entre régions. L'Instance Store est éphémère et ne démarre pas toujours un OS comme st1 et sc1. À l'arrêt, EC2 ne coûte plus rien mais l'EBS continue d'être facturé.
À vous de jouer : Un encodage vidéo de 10 heures tolère les reprises mais doit coûter le moins cher possible. Que choisissez-vous ?
Voir la réponse

Des instances Spot avec checkpoint régulier sur S3 ou EBS via snapshot et file SQS pour redécouper le travail. Si Spot récupère la capacité, le job reprend où il s'est arrêté au lieu de tout recommencer.

Module 4

S3 : classes de stockage et cycle de vie

11 neuf de durabilité, un nom de bucket mondial unique, et une classe pour chaque usage.

1. Fondamentaux

Stockage objet (bucket + clé + version) de 0 octet à 5 To par objet, répliqué sur 3 AZ minimum. Nom de bucket globalement unique, flat (pas de vrais dossiers). Durabilité 99,999999999 % (11 neuf). Cohérence forte en lecture après écriture.

Pourquoi c'est important : Des logs gardés trois ans en S3 Standard coûtent dix fois trop cher, un bucket ouvert en public fuite des documents clients, et un site statique servi directement depuis S3 rame à l'autre bout du monde. Bien choisir la classe S3 et verrouiller l'accès, c'est régler d'un geste la facture, la sécurité et la montée en charge.
L'analogie qui aide : Voyez S3 comme un garde-meuble : Standard est le box visité chaque jour près de l'accueil, Standard-IA le box au fond visité une fois par mois, One Zone-IA le box dans un seul bâtiment pour des cartons remplaçables, et Glacier la cave scellée dont l'ouverture prend de quelques minutes à 48 heures.

2. Les classes de stockage (question garantie)

  • Standard : accès fréquent, multi-AZ.
  • Intelligent-Tiering : déplace automatiquement selon l'usage (petits frais de suivi).
  • Standard-IA : accès peu fréquent mais en millisecondes (frais de récupération).
  • One Zone-IA : une seule AZ, moins cher (données reproductibles).
  • Glacier Instant / Flexible / Deep Archive : archivage, de la milliseconde à 48 h, au coût minimal.

3. Gestion du cycle de vie et protection

  • Règles de cycle de vie : transitions automatiques (Standard vers Standard-IA vers Glacier) puis expiration.
  • Versioning : conserve toutes les versions, protège des écrasements (suspendu mais jamais « supprimé » simplement).
  • Réplication CRR/SRR : copie inter-région ou intra-région (exige le versioning).
  • Chiffrement : SSE-S3 (clés AWS), SSE-KMS (contrôle et audit), SSE-C (vos clés), côté client.
  • Accès : Block Public Access, bucket policies, ACL désactivées par défaut, URL pré-signées pour un accès temporaire.
Démonstration pas à pas : Besoin : diffuser un site vitrine dans le monde et archiver des rapports annuels. Étape 1 : bucket privé avec versioning pour le site, servi par CloudFront avec OAC, jamais en public direct. Étape 2 : règle de cycle de vie sur les rapports : 30 jours en Standard, puis Standard-IA, puis Glacier Deep Archive à 180 jours, puis expiration à 7 ans. Pourquoi pas EBS pour le site : pas de diffusion mondiale ni de durabilité 11 neuf. Pourquoi pas du Standard permanent : surcoût inutile.
aws s3 mb s3://mon-bucket-saa-2026 --region eu-west-3
aws s3 ls
aws s3 cp rapport.pdf s3://mon-bucket-saa-2026/
aws s3 sync ./site s3://mon-bucket-saa-2026/site --delete
aws s3api put-bucket-versioning --bucket mon-bucket-saa-2026 --versioning-configuration Status=Enabled
aws s3api put-bucket-lifecycle-configuration --bucket mon-bucket-saa-2026 --lifecycle-configuration file://lifecycle.json
aws s3 presign s3://mon-bucket-saa-2026/rapport.pdf --expires-in 3600
aws s3 rb s3://mon-bucket-saa-2026 --force
Points d'examen :
  • Accès rare + millisecondes = Standard-IA ; archivage = Glacier ; une AZ = One Zone-IA.
  • Versioning + réplication pour la protection ; cycle de vie pour le coût.
  • Site statique : S3 + CloudFront avec OAC, jamais de bucket public direct.
  • S3 Transfer Acceleration et Multipart Upload pour les gros fichiers distants.
Pièges classiques : Accès rare mais en millisecondes égale Standard-IA, archivage égale Glacier, une seule AZ égale One Zone-IA pour données reproductibles. Le nom de bucket est mondialement unique, la réplication exige le versioning, et un site statique passe par CloudFront avec OAC, jamais par un bucket public. Pour un partage temporaire, utilisez une URL pré-signée.
À vous de jouer : Des dossiers médicaux consultés une fois par an doivent rester disponibles en millisecondes avec une durabilité maximale. Quelle classe choisissez-vous ?
Voir la réponse

S3 Standard-IA multi-AZ, pas One Zone-IA qui ne réplique que dans une AZ. Ajoutez un cycle de vie vers Glacier si la réglementation impose un archivage long, et chiffrez en SSE-KMS avec versioning.

Accueil Niveau suivant : Intermédiaire