Cours AWS — compte et organisation, IAM, EC2, S3, VPC, facturation et AWS CLI en lecture

Objectifs d'apprentissage

À la fin de ce cours, l'apprenant peut :

1. expliquer ce qu'est un compte AWS, une organisation, une région et une zone de disponibilité ;
2. protéger le compte racine et appliquer le moindre privilège avec IAM ;
3. décrire une instance EC2, son image, son stockage et son groupe de sécurité ;
4. décrire un compartiment S3 et ses protections par défaut ;
5. décrire un VPC, un sous-réseau et leur lien avec les zones ;
6. poser un budget et une alerte avant tout essai, et lire la facturation ;
7. utiliser l'AWS CLI en lecture pour inspecter un compte sans le modifier ;
8. nettoyer les ressources de test.

Prérequis

• Cours « Concepts du cloud » (IaaS, régions, responsabilité partagée, coûts).
• Notions de réseau IP, de pare-feu et de ligne de commande.
• Aucun compte n'est requis pour lire. Pour pratiquer : un compte jetable dédié, aucun lien avec un usage professionnel, des données fictives, un budget posé avant la première ressource.

Parcours et chapitres

1. Compte, organisation, région et zone

• Un compte AWS est la frontière de base pour les permissions, la sécurité, les coûts et les charges de travail (page « What is AWS Organizations »). À la création, on établit les identifiants du compte racine.
• AWS Organizations permet de créer et regrouper des comptes en unités d'organisation (OU), d'appliquer des politiques (SCP, qui fixent des plafonds de permissions) et de recevoir une facture consolidée. Un seul compte suffit pour apprendre ; l'organisation sert dès qu'il y en a plusieurs.
• Une région est un lieu géographique contenant plusieurs zones de disponibilité (centres de données distincts avec alimentation et réseau redondants). On choisit la région d'une ressource pour la latence, le coût et la conformité ; les services ne sont accessibles que dans les régions activées pour le compte.
• Un objet S3 stocké dans une région n'en sort pas sans transfert ou réplication explicite (page S3).

2. Identité et accès : IAM, compte racine, moindre privilège

La page « Security best practices in IAM » recommande notamment :

1. exiger des identités fédérées (IAM Identity Center recommandé) et des identifiants temporaires pour les humains ;
2. faire utiliser des rôles IAM aux applications plutôt que des clés distribuées ;
3. exiger l'authentification multifacteur (MFA), de préférence résistante à l'hameçonnage (clé de sécurité, passkey) ;
4. ne créer des clés d'accès longue durée que si c'est indispensable, et les mettre à jour ou les supprimer quand nécessaire ;
5. protéger le compte racine « comme une donnée personnelle sensible » ;
6. appliquer le moindre privilège : partir de politiques gérées par AWS, puis réduire en s'appuyant sur l'activité réellement observée (IAM Access Analyzer) ;
7. supprimer régulièrement ce qui n'est plus utilisé.

Notions à ne pas confondre :

3. EC2 : machines virtuelles

D'après « What is Amazon EC2 » : une instance EC2 est un serveur virtuel ; son type définit le matériel (calcul, mémoire, réseau, stockage). Éléments à connaître :

Facturation. À la demande : paiement à la seconde (minimum 60 secondes) sans engagement. Autres options : Savings Plans, instances réservées, Spot (interruptible), hôtes dédiés, réservations de capacité. Le détail des prix n'est pas repris (il change) : voir la page de tarification EC2.

4. S3 : stockage objet

D'après « What is Amazon S3 » :

• un compartiment (bucket) est un conteneur d'objets ; un objet a une clé unique dans le compartiment ;
• on choisit une région à la création ; le nom et la région d'un compartiment ne peuvent pas être modifiés ; les noms de compartiments d'usage général vivent dans un espace de noms global (unicité à l'échelle des comptes), sauf choix d'un espace régional de compte ;
• par défaut, compartiments et objets sont privés ; le blocage de l'accès public est activé par défaut et AWS recommande de le laisser actif ;
• les listes de contrôle d'accès (ACL) sont désactivées par défaut ; privilégier les politiques de compartiment et IAM ;
• le versioning conserve plusieurs versions d'un objet et permet de restaurer après une suppression ou un écrasement ;
• classes de stockage (Standard, accès peu fréquent, archivage Glacier, Intelligent-Tiering...) : le prix baisse quand l'accès devient rare, avec des contreparties (délai, frais de récupération : non vérifiés ici) ;
• cohérence forte en lecture après écriture ;
• le stockage est facturé à l'usage.

5. VPC : réseau virtuel

D'après « What is Amazon VPC » : un VPC est un réseau virtuel logiquement isolé, comparable à un réseau de centre de données. Il contient :

• des sous-réseaux : plage d'adresses, chacun dans une seule zone de disponibilité ;
• des tables de routage : où va le trafic d'un sous-réseau ;
• des passerelles (passerelle Internet, NAT, VPN, passerelle de transit) et des points de terminaison de VPC pour joindre des services AWS sans passer par Internet ;
• l'appairage de VPC et les journaux de flux (VPC Flow Logs) ;
• des groupes de sécurité (pare-feu au niveau de l'instance, vus au chapitre 3).

Faits utiles : chaque région d'un compte comporte un VPC par défaut conçu pour lancer des instances tout de suite ; le VPC lui-même est gratuit, mais certains composants sont facturés (passerelles NAT, adresses IPv4 publiques, analyse de trafic) ; les adresses IPv4 privées ne sont pas facturées. Le détail des règles du VPC par défaut est non vérifié.

6. Facturation, budgets et paliers gratuits

• Free Tier (état consulté le 17 octobre 2026) : à l'inscription, on choisit un plan de compte gratuit ou un plan payant. La page décrit un plan gratuit allant jusqu'à six mois ou l'épuisement des crédits (crédits d'accueil mentionnés), et des offres « toujours gratuites ». Ces conditions changent : relire la page, ne rien considérer comme acquis.
• AWS Budgets : permet des budgets de coût ou d'usage, avec des alertes sur le réel et la prévision, par e-mail ou Amazon SNS. Les données sont mises à jour jusqu'à trois fois par jour, environ toutes les 8 à 12 heures. Un budget ne bloque rien par défaut ; des actions automatiques optionnelles existent (par exemple appliquer une politique IAM restrictive). Il peut y avoir un retard entre la dépense et l'alerte.
• Cost Explorer : analyse du coût et de l'usage sur les 13 derniers mois, prévision sur 12 mois (page EC2).
• Facture consolidée : Organizations regroupe les factures de tous les comptes.

Procédure recommandée, avant toute ressource :

1. activer la MFA du compte racine ;
2. créer un budget mensuel (par exemple un montant très bas) avec alertes à 50 %, 80 % et à la prévision de dépassement ;
3. renseigner une adresse e-mail surveillée ;
4. étiqueter chaque ressource de test (projet=test) ;
5. noter l'heure prévue de suppression de chaque ressource.

7. AWS CLI en lecture seule

L'AWS CLI v2 (installation décrite sur la page consultée ; l'installation modifie le poste et n'est pas détaillée ici). Pour les humains, la page « Configuring IAM Identity Center authentication » recommande une configuration par session SSO : un profil nommé obtient des identifiants temporaires après aws sso login.

Étape 1 — vérifier la version

aws --version

• Contexte : poste de travail ; AWS CLI v2 installé (version de Stéphane inconnue).
• Droits : aucun.
• Effet : lecture seule, affiche la version.
• Vérification : une ligne aws-cli/2... s'affiche.
• Retour arrière : sans objet.

Étape 2 — savoir qui l'on est (avant toute autre commande)

aws sts get-caller-identity --profile <PROFIL>

• Contexte : profil SSO déjà configuré ; session ouverte (aws sso login --profile <PROFIL> ouvre le navigateur et met en cache un jeton local : action à effet local, hors lecture pure).
• Droits : aucun droit particulier requis par l'appel d'identité.
• Effet : lecture. La sortie contient le numéro de compte et l'ARN : ne pas la copier dans un message, un dépôt, une capture ni un prompt.
• Vérification : le compte affiché est bien celui de test ; sinon s'arrêter.
• Retour arrière : aws sso logout supprime les identifiants en cache.

Étape 3 — inspecter (lecture)

aws ec2 describe-regions --profile <PROFIL>aws ec2 describe-instances --profile <PROFIL> --region <REGION>aws ec2 describe-vpcs --profile <PROFIL> --region <REGION>aws s3 ls --profile <PROFIL>aws iam get-account-summary --profile <PROFIL>aws organizations describe-organization --profile <PROFIL>aws budgets describe-budgets --account-id <ID-COMPTE> --profile <PROFIL>

• Contexte : AWS CLI v2, région explicite avec --region (les ressources sont régionales). Noms de sous-commandes d'après la structure de la référence CLI ; syntaxe exacte de chaque commande à confirmer dans la référence officielle de la version installée.
• Droits : permissions de lecture correspondantes (par exemple un rôle de type lecture seule). Une erreur AccessDenied est normale si le rôle est restreint : ne pas élargir le rôle pour « faire marcher ».
• Effet : lecture seule, aucune ressource créée ni modifiée. Les sorties contiennent des identifiants : les traiter comme sensibles.
• Vérification : la liste des instances est vide sur un compte neuf, avec un VPC par défaut par région.
• Retour arrière : sans objet.

8. Création et suppression de ressources (à ne pas lancer sans validation)

Ces commandes sont données pour comprendre l'enchaînement et le retour arrière ; elles ne sont pas à exécuter dans le cadre du cours. Syntaxes à reconfronter à la référence de la version installée : non vérifié.

Attention, effet notable. Cette commande a un effet notable. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

aws ec2 run-instances --image-id <ID-IMAGE> --instance-type <TYPE> --count 1 --profile <PROFIL> --region <REGION>

• Contexte : compte jetable, région explicite, AMI et type connus ; un VPC par défaut présent.
• Droits : permission de lancer des instances (ne pas utiliser le compte racine).
• Effet : crée une machine facturée à la seconde, avec un volume EBS ; elle tourne tant qu'on ne l'arrête pas.
• Vérification : aws ec2 describe-instances la montre à l'état « running ».
• Retour arrière : supprimer l'instance (commande suivante), puis vérifier volumes et adresses restants.

Attention, effet notable. Cette commande a un effet notable. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

aws ec2 terminate-instances --instance-ids <ID-INSTANCE> --profile <PROFIL> --region <REGION>

• Contexte : l'instance de test créée ci-dessus, identifiée sans ambiguïté.
• Droits : permission de supprimer des instances.
• Effet : supprime l'instance ; les données du stockage d'instance sont perdues, et selon la configuration le volume racine aussi.
• Vérification : l'instance passe à « terminated » ; relire la liste des volumes et des snapshots.
• Retour arrière : aucun : prévoir une sauvegarde avant, si les données comptent.

Attention, effet notable. Cette commande a un effet notable. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

aws s3api create-bucket --bucket <NOM-COMPARTIMENT> --region <REGION> --create-bucket-configuration LocationConstraint=<REGION>

• Contexte : compte jetable ; nom de compartiment globalement unique, sans information sensible (il apparaît dans les URL).
• Droits : permission de créer des compartiments.
• Effet : crée un compartiment privé (blocage de l'accès public actif par défaut) ; le stockage est facturé à l'usage.
• Vérification : aws s3 ls le liste.
• Retour arrière : vider puis supprimer le compartiment (aws s3 rb s3://<NOM-COMPARTIMENT> ; l'option de suppression forcée détruit tous les objets : ne pas l'employer sans relecture).

9. Nettoyage des ressources de test

Ordre conseillé en fin d'exercice :

1. instances EC2 supprimées, puis volumes EBS, snapshots et adresses IP élastiques restants ;
2. compartiments S3 vidés (y compris anciennes versions) puis supprimés ;
3. VPC ajoutés pour l'essai supprimés (passerelles NAT en premier : elles sont facturées) ;
4. alertes et budget conservés ;
5. le lendemain, rouvrir la facturation : plus aucune ligne de coût ne doit croître.

Exercices et vérifications de fin de cours

Tous sont sur papier ou en lecture seule.

1. Schéma. Redessiner l'organisation compte, région, VPC, instance, S3 en indiquant ce qui est régional.
2. IAM. Écrire, en français, la politique de lecture seule qu'on voudrait pour un stagiaire (liste d'actions attendues, sans JSON réel).
3. Racine. Dresser la liste des cinq protections du compte racine.
4. Budget. Définir un budget mensuel fictif et trois seuils d'alerte ; dire ce qui se passe quand ils sont dépassés.
5. S3. Expliquer pourquoi le blocage de l'accès public est activé par défaut.
6. VPC. Pourquoi un sous-réseau ne peut-il pas couvrir deux zones ?
7. CLI. Pour chaque commande du chapitre 7, dire ce qu'elle lit et quel droit elle exige.
8. Nettoyage. Établir la liste de contrôle qui suit une instance de test supprimée.

Critères de réussite

• Distinguer compte racine, utilisateur, rôle, politique, SCP.
• Savoir qu'une clé d'accès ne se range ni dans un fichier, ni dans un dépôt, ni dans un prompt.
• Poser un budget et une alerte avant toute ressource, et savoir que l'alerte ne bloque rien.
• Lancer uniquement des commandes de lecture, après get-caller-identity.
• Dire ce qui n'a pas été vérifié.