💻 AWS EC2 (Elastic Compute Cloud)

11.2. Serveur d’Applications (Django, Flask, Node.js…)

C'est une spécialisation du (11.1). L'EC2 exécute le runtime applicatif (ex: Gunicorn/uWSGI (Python), PM2 (Node.js), Tomcat (Java)).

Pourquoi EC2 (vs Beanstalk ou Lambda) ?

Vous utilisez EC2 (plutôt qu'un PaaS comme Beanstalk ou FaaS comme Lambda) lorsque vous avez besoin de contrôle total sur l'environnement d'exécution :

• Dépendances OS : L'application (Python/Django) a besoin de apt-get install lib-geospatial-xyz (une librairie C/OS) qui n'est pas incluse dans les runtimes Lambda/Beanstalk.
• Configuration Spécifique : Nécessité de "tuner" (optimiser) le Kernel (sysctl.conf) (ex: net.core.somaxconn) pour des performances réseau (haute connexion) que le PaaS n'expose pas.
• Workers Longue Durée : L'application (Django) utilise Celery (Workers) qui doit tourner (en daemon) 24/7 (pas seulement 15 min comme Lambda).
• Stockage Local : L'application a besoin d'un accès (temporaire) très rapide à un disque local (ex: Instance Store (NVMe)) pour un traitement (que Lambda (/tmp 512MB) ne peut pas offrir).

11.3. Applications "Legacy" (Lift-and-Shift)

C'est la migration "Lift & Shift" (Tel quel). C'est le cas d'usage où EC2 est (souvent) la seule option (car l'application "legacy" (ancienne) ne peut pas être modernisée (container/serverless)).

Scénarios (Migration "P1")

• (OS) Application Windows (ex: .NET 3.5) tournant sur Windows Server 2008 / 2012 (On-Premise).
  • Solution : Lancer une EC2 (Windows) avec une AMI (Windows Server 2012) et y (ré)installer l'application (.exe) (ou utiliser AWS Migration Service (MGN) pour cloner le disque).
• (Logiciel) Application "Monolithique" (ex: Oracle Forms, SAP R/3) qui dépend d'une version spécifique (ex: Java 6) ou de drivers matériels (ex: Clé USB "Dongle" (via VM Import/Export)).
  • Solution : Lancer une EC2 (Linux/Windows) et recréer (manuellement) l'environnement exact.
• (Licence) Application (ex: Oracle DB) dont la licence (BYOL) est liée au matériel (Sockets/Cœurs physiques).
  • Solution : Utiliser EC2 Dedicated Host (Hôte Dédié) (qui vous donne le serveur physique) pour la conformité de la licence.

11.4. Serveur de Bases de Données "Custom" (Self-Managed)

C'est le cas d'usage où vous choisissez EC2 (IaaS) plutôt que RDS (PaaS).

(Règle) : Toujours utiliser RDS (ou Aurora) (managé) d'abord. N'utilisez EC2 (self-managed) que si RDS ne peut (absolument) pas répondre au besoin.

Pourquoi EC2 (vs RDS) ? (Besoin de Contrôle)

• Moteur Non-Supporté : Vous avez besoin d'une BDD que RDS ne propose pas (ex: MongoDB, Cassandra, Neo4j (Graphe), ClickHouse (Analytics)).
• Version Non-Supportée : Vous avez (Legacy) besoin de PostgreSQL 9.6 (que RDS n'offre plus) ou (Bleeding Edge) de PostgreSQL 17 (Beta) (que RDS n'offre pas encore).
• Extension Non-Supportée : Vous avez besoin d'une extension PostgreSQL (ex: timescaledb) qui n'est pas (encore) supportée (approuvée) par RDS.
• Accès OS (Root) : Vous (DBA) avez besoin d'un accès root (SSH) au serveur (OS) pour installer un agent de monitoring (custom), "tuner" (optimiser) sysctl.conf (Kernel) ou postgresql.conf (paramètres avancés "unsafe" que RDS bloque).
  • (Alternative : RDS Custom (pour Oracle/SQL Server) offre l'accès SSH).

(Inconvénient) : VOUS devenez 100% responsable des Patchs, Backups (Snapshots), de la HA (Multi-AZ) (Replication, Failover), et du Scaling (Read Replicas).

11.5. Machine GPU (Intelligence Artificielle / Machine Learning)

EC2 fournit des "Instances Accélérées" (GPU) pour les 2 phases du ML : Training (Entraînement) et Inference (Déploiement).

1. Training (Entraînement de Modèles) (Cher, Puissant)

• Instances (Famille P, Trn) : p4d (GPU Nvidia A100), p5 (GPU Nvidia H100), trn1 (AWS Trainium).
• Usage : Entraîner (calcul matriciel intensif) des modèles (LLM, Vision) de zéro (ex: model.fit() sur des Téraoctets de données).
• Réseau : Nécessite une bande passante réseau extrême (EFA - Elastic Fabric Adapter) pour le "Distributed Training" (ex: 32 instances p5 qui travaillent ensemble).

2. Inference (Inférence / Prédiction) (Moins cher, Rapide)

• Instances (Famille G, Inf) : g5 (GPU Nvidia A10G), inf2 (AWS Inferentia2).
• Usage : Héberger (servir) le modèle (déjà entraîné) (model.predict()) derrière une API (ex: via AWS SageMaker Endpoints, qui utilise ces EC2 en backend).
• Objectif : Coût ($) par inférence le plus bas, Latence (ms) la plus faible. (Inferentia (inf) est souvent le meilleur ratio prix/perf (vs GPU Nvidia) pour l'inférence).

11.6. Rendering (Rendu) Vidéo / 3D (VFX)

Cas d'usage (similaire au 11.5) qui utilise des instances (GPU) pour le calcul graphique (non-ML).

• Instances (Famille G) : g4dn, g5. (GPU Nvidia (ex: T4, A10G) + Drivers GRID (pour le graphique/workstations)).
• Usage :
  • Workstations Virtuelles (Studio) : (Streaming (Protocole NICE DCV)) L'artiste (3D) (à la maison) se connecte (via DCV) à une instance g5 (puissante) (dans le Cloud) qui exécute Maya / Blender / Nuke (sur une AMI Windows/Linux custom).
  • Render Farms (Fermes de Rendu) : (Batch) Lancement de 1000 instances EC2 (Spot (9.4)) (g5 ou c5 (CPU-rendering)) (via un orchestrateur (ex: AWS Thinkbox Deadline)) pour calculer (renderer) les 100 000 "frames" (images) d'un film (VFX).

(Spot (9.4)) : Le "Rendering" (Batch) est le cas d'usage parfait pour les Instances Spot (jusqu'à -90% de réduction), car si l'instance (Frame 50) est interrompue (préavis 2min), l'orchestrateur (Deadline) la relance (simplement) sur une autre instance Spot (Frame 50 - retry).

11.7. HPC (High Performance Computing)

Calcul Scientifique (Météo, Fluides (CFD), Génomique, Simulation (Crash-test)).

Architecture (Tightly-Coupled vs Loosely-Coupled)

1. Tightly-Coupled (MPI) (Ex: Simulation Fluides)

Les Nœuds (EC2) doivent communiquer énormément (et à très faible latence) entre eux (MPI - Message Passing Interface).

• Instances : Hpc7g (Graviton), Hpc6a (AMD).
• Réseau : EFA (Elastic Fabric Adapter) (Bande passante 100/200 Gbps, Latence microsecondes, OS-Bypass (Kernel)).
• Placement : Placement Group (Cluster) (Garantit que les Nœuds sont sur le même Rack physique).
• Stockage (Partagé) : FSx for Lustre (Système de fichiers (parallèle) ultra-performant).

2. Loosely-Coupled (Batch) (Ex: Analyse Génomique)

"Embarrassingly parallel". 1000 Nœuds (EC2) qui font 1000 calculs indépendants (ne communiquent pas entre eux). (Similaire au Rendering (11.6)).

• Instances : Familles C (Compute) (c6g, c7g) ou M (General) (m6g).
• Réseau : ENA (Standard) (Pas besoin d'EFA).
• Placement : (Aucun) (Spread (par défaut)).
• Orchestration : AWS Batch (PaaS) (qui gère la file (Job Queue) et provisionne (automatiquement) des EC2 (Spot ou On-Demand) pour exécuter les jobs (Conteneurs Docker)).

10.2. EC2 Image Builder (Pipeline d'AMI)

C'est la méthode moderne (DevOps) pour automatiser la création d'AMIs "Golden Images" (sécurisées, patchées, et à jour).

Il remplace les scripts packer (legacy) ou les "backups" (Snapshots) manuels d'instances.

Composants d'un Pipeline Image Builder

• 1. Image Recipe (Recette) :
  • Source Image (Source) : L'AMI de base (ex: Ubuntu 22.04 LTS (dernière version)).
  • Components (Ingrédients) : Les scripts d'installation/configuration (ex: yum install nginx, install-cloudwatch-agent, cis-hardening-level-1 (Script de durcissement)).
• 2. Infrastructure Configuration :
  • Où "cuire" (Bake) l'image ? (Type Instance (t3.micro), VPC/Subnet Privé, IAM Role (Build)).
• 3. Distribution Settings :
  • Où "livrer" l'AMI finale ? (ex: Donner le nom mon-app-prod-).
  • (Optionnel) Copier l'AMI (automatiquement) vers d'autres Régions (ex: eu-central-1) (pour la DR).
  • (Optionnel) Partager l'AMI (automatiquement) avec d'autres Comptes AWS (ex: Compte "Prod").
• 4. Pipeline :
  • L'orchestrateur (le "Cron") qui lance la "Recette" (ex: "Tous les 1er du mois" (pour patcher) ou "Après un commit (Git) sur la Recette").

10.3. Infrastructure as Code (IaC)

Le principe de l'IaC est de définir et provisionner votre infrastructure (VPC, EC2, SG, IAM...) en utilisant du code (fichiers texte) (ex: YAML, HCL, Python) plutôt qu'en cliquant (manuel) dans la console AWS.

Avantages : Reproductibilité (Dev=Prod), Audit (Git blame), Peer Review (Pull Requests), Automatisation (CI/CD).

                    # Exemple (Terraform HCL) - Simple et lisible
                    resource "aws_instance" "web" {
                    ami           = "ami-0abcdef123"
                    instance_type = "t3.micro"
                    vpc_security_group_ids = [ aws_security_group.web.id ]

                    tags = { Name = "Serveur-Web-Prod" }
                    }
                

10.4. CI/CD (Déploiement Continu sur EC2)

Comment (automatiquement) déployer votre nouveau code applicatif (ex: app-v2.py) sur votre flotte d'EC2 (v1) (gérée par un ASG) ?

1. AWS CodeDeploy (PaaS de Déploiement)

C'est le service AWS qui gère le "déploiement" (physique) sur la flotte EC2.

• Pré-requis : L'Agent CodeDeploy (codedeploy-agent) doit tourner sur les EC2s.
• appspec.yml : Un fichier (YAML) (dans votre code) qui dit à l'Agent "Quoi faire" (Hooks) :
  • BeforeInstall: (ex: systemctl stop nginx)
  • Install: (ex: Copier les nouveaux fichiers (v2) de /source vers /var/www/html)
  • AfterInstall: (ex: chmod 755 ...)
  • ApplicationStart: (ex: systemctl start nginx)
  • ValidateService: (ex: curl http://localhost/health) (Vérifie si v2 a démarré).

Stratégies de Déploiement (CodeDeploy)

• In-Place (Sur Place) : (Risqué / Downtime) (AllAtOnce ou Rolling). Met à jour les instances existantes (v1 -> v2). (S'il échoue, l'app est cassée).
• Blue/Green (Bleu/Vert) : (Sûr / Zéro Downtime)
  1. (ASG) L'ASG (v1) (Bleu) tourne.
  2. (CodeDeploy) Crée (via l'ASG) un nouveau "Groupe de Remplacement" (Vert) (avec v2).
  3. (CodeDeploy) Teste (fumée) le (Vert).
  4. (CodeDeploy) Demande au Load Balancer (ALB) de basculer (Shift) 100% du trafic (Public) de (Bleu) vers (Vert).
  5. (CodeDeploy) (Après 1h (Wait)) Termine (Tue) l'ancienne flotte (Bleu).

Orchestrateurs (CI/CD)

• AWS CodePipeline : L'orchestrateur 100% Natif AWS. (Source: CodeCommit/S3/GitHub -> Build: CodeBuild -> Deploy: CodeDeploy).
• GitHub Actions / GitLab CI : (Populaire) (Trigger: on push) -> (Runner) 1. Build Image/ZIP -> 2. Push (S3/ECR) -> 3. (CLI) aws deploy create-deployment ... (Déclenche CodeDeploy (Blue/Green)).

10.5. Configuration Management (vs Immutable)

Comment s'assurer que vos 100 EC2 (longue durée) sont (et restent) configurées à l'identique (ex: ntp.conf, sshd_config) ?

Approche 1 : "Mutable" (Gestion de Configuration)

Vous "patchez" (modifiez) les serveurs (Pets) (longue durée) (ex: BDD self-managed, Active Directory).

• Ansible : (Populaire) Agentless (Sans Agent) (Modèle "Push"). (Utilise SSH (ou SSM (10.1)) pour se connecter et "pousser" (push) la configuration (Playbooks YAML)). (Bon pour le "bootstrap" (1er setup) ou tâches ad-hoc).
• Chef / Puppet / SaltStack : (Enterprise / Legacy) Agent-based (Modèle "Pull"). (Un Agent (ex: chef-client) tourne sur chaque EC2, et "pull" (tire) (toutes les 30 min) sa configuration (Recipes) depuis un "Master" (Serveur Chef/Puppet)). (Lourd, mais garantit la convergence de l'état).
• AWS SSM State Manager (10.1) : (Moderne AWS) L'alternative "Agent-based" (Agent SSM) (Pull/Enforce) à Chef/Puppet/Ansible.

Approche 2 : "Immutable Infrastructure" (Moderne)

Vous ne "patchez" jamais un serveur (Cattle) (jetable) en production.

Flux (Blue/Green) :

1. (Code) (Jour 1) Vous trouvez un bug (nginx.conf v1).
2. (Dev) Vous modifiez le Component (10.2) (nginx.conf v2).
3. (Pipeline) EC2 Image Builder (10.2) "Bake" (cuit) une nouvelle AMI (mon-app-v2) (contenant nginx.conf v2).
4. (Pipeline) CodeDeploy (10.4) (Blue/Green) :
   • Démarre une nouvelle flotte (Green) (ASG) (avec l'AMI v2).
   • Bascule le trafic (ALB) sur (Green).
   • Termine (Tue) l'ancienne flotte (Blue) (qui avait nginx.conf v1).

(Résultat) : La configuration est "atomique" (l'AMI). Pas de "drift" (dérive) de configuration. Rollback facile (il suffit de re-scaler l'ASG (Bleu) v1).

Disclaimer & Limitations (Lecture Obligatoire)

ATTENTION : Je suis un assistant IA. Je n'ai pas accès aux API de pricing (tarification) en temps réel d'AWS.

Les prix utilisés dans ce calculateur sont des données fictives (estimations statiques) basées sur des exemples connus, et sont utilisés uniquement pour démontrer le fonctionnement du calculateur JavaScript.

Ce qui est exclu de ce calcul :

• Prix Réels : Les prix AWS (On-Demand) changent constamment.
• Taux de Change : Le taux (USD -> EUR) est fixé (fictif) dans le script (0.92) et n'est pas un taux de change réel.
• Stockage EBS : Le prix du Volume EBS (Disque Dur) (facturé au GB/mois et aux IOPS) n'est PAS inclus.
• Data Transfer : Le coût du transfert de données (Sortant/Egress) (facturé au GB) n'est PAS inclus.
• Autres Coûts : N'inclut pas les EIPs (non-attachées), les Snapshots, le Detailed Monitoring, etc.

Conclusion : Utilisez cet outil pour voir (conceptuellement) comment le prix change (ex: Linux vs Windows, us-east-1 vs eu-west-3), mais utilisez toujours le Calculateur Officiel AWS pour des estimations réelles.

9.2. Reserved Instances (RI) (Modèle "Legacy")

C'est l'ancien modèle d'engagement. Il offre une réduction importante (jusqu'à -72% vs On-Demand) en échange d'un engagement (1 an ou 3 ans) sur une famille d'instance spécifique (ex: m5) dans une Région spécifique (ex: eu-west-3).

(Note) : Les RIs sont (aujourd'hui) largement remplacées par les Savings Plans (9.3) (plus flexibles), mais elles sont toujours utilisées (notamment pour la garantie de capacité).

Garantie de Capacité (Capacity Reservation)

Un avantage (parfois) oublié des RIs (Zonales) : elles garantissent (réservent) la capacité (hardware) pour vous dans une AZ spécifique. (Même si AWS est en "rupture de stock" sur p4d.24xlarge dans us-east-1a, votre RI est garantie).

9.3. Savings Plans (SP) (Modèle Moderne)

C'est le modèle d'engagement moderne (recommandé). Il offre la flexibilité de l'On-Demand avec la réduction des RIs.

Principe : Vous ne réservez pas une "instance" (m5.large). Vous vous engagez à dépenser un montant ($) (ex: $10.00 / heure) en "Compute" (Calcul) pendant 1 ou 3 ans.

Types de Savings Plans

(Flux) : Vous vous engagez ($10/h). AWS facture votre usage (EC2, Fargate, Lambda) au tarif (réduit) Savings Plan (jusqu'à $10/h), puis facture tout surplus (ex: $12/h) au tarif On-Demand (9.1).

9.4. Spot Instances (Enchères)

C'est le modèle "basé enchères". Vous "achetez" la capacité EC2 inutilisée (spare) d'AWS.

Avantages & Inconvénients

• Avantage (Coût) : Réduction massive (jusqu'à -90%) par rapport au prix On-Demand.
• Inconvénient (Risque) : Interruptible. Si AWS a besoin de cette capacité (pour un client On-Demand/RI) ou si le "prix Spot" (enchère) dépasse votre "prix max" (optionnel), AWS termine (tue) votre instance (avec un préavis (Warning) de 2 minutes).

Cas d'Usage (Workloads Tolérants aux Pannes)

(Règle d'Or) : Ne jamais utiliser Spot pour un workload (charge) qui ne peut pas être interrompu (ex: BDD Master, API Web unique).

Idéal pour :

• Batch Processing : (Calcul scientifique, analyse génomique). (Si le job est tué, on le relance plus tard).
• Rendering Farms : (Rendu 3D / VFX).
• CI/CD : (ex: Jenkins Workers, GitLab Runners).
• Big Data (Stateless) : (ex: Nœuds "Worker" Spark / EMR).
• Auto Scaling Group (Mixte) : (Bonne Pratique) Configurer l'ASG (8.1) pour utiliser une "Mixed Instance Policy" (ex: 30% On-Demand (Baseline stable) + 70% Spot (Scaling pas cher)).

9.5. Dedicated Hosts & Dedicated Instances

Ces deux modèles garantissent que vos instances EC2 tournent sur un serveur physique (Hardware) qui vous est dédié (isolé) (pas de "voisins" (multi-tenant)).

Cas d'Usage (Compliance & Licence)

• 1. Compliance (Réglementaire) : Pour des workloads (charges) très sensibles (ex: HDS (Santé France), HIPAA (Santé US), PCI) qui (parfois) exigent une isolation physique (matérielle) (et pas seulement virtuelle (Hyperviseur)).
• 2. Licences (BYOL - Bring Your Own License) : Pour des logiciels "legacy" (anciens) (ex: Oracle DB, Microsoft SQL Server) dont la licence est (stupidement) liée au matériel physique (Sockets, Cœurs).

8.2. Elastic Load Balancing (ELB)

ELB est un service (PaaS) qui distribue (répartit) le trafic (entrant) sur plusieurs cibles (ex: Instances EC2 (ASG)). C'est le point d'entrée (DNS) de votre application.

8.3. Déploiement Multi-AZ (Haute Disponibilité)

(La Règle d'Or de la Résilience) Une Availability Zone (AZ) est un Datacenter (physique) isolé. Pour être "Haute Disponibilité" (HA) (résister à une panne d'un datacenter), une application doit être déployée sur (au minimum) 2 AZs.

Importance du Placement Multi-AZ (ASG)

(Mauvaise Pratique) : Configurer l'ASG (8.1) pour utiliser uniquement subnet-private-a (qui est dans AZ-A).

(Panne) : L'AZ-A (Datacenter) tombe (panne électrique).

(Résultat) : L'ASG (Min=2) veut lancer 2 instances, mais le seul Subnet (subnet-private-a) qu'il connaît est mort. (Downtime Total).

(Bonne Pratique) : Configurer l'ASG (8.1) pour utiliser deux Subnets : subnet-private-a (AZ-A) et subnet-private-b (AZ-B).

(Panne) : L'AZ-A tombe.

(Résultat) : L'ASG détecte que subnet-private-a est inaccessible. Il lance (automatiquement) les 2 instances (Min=2) dans le seul Subnet (sain) qu'il lui reste : subnet-private-b (AZ-B). (Application en ligne).

Policies ASG Cross-Zone

• ASG (Équilibrage) : L'ASG tente (par défaut) de garder un nombre égal d'instances (ex: 3 en AZ-A, 3 en AZ-B). C'est la policy AZRebalance.
• ALB (Cross-Zone Load Balancing) : (Activé par défaut / Payant) Le nœud ALB (en AZ-A) peut (et va) envoyer du trafic vers les EC2 (en AZ-B), et vice-versa. (Garantit une répartition 50/50 du trafic, même si l'ASG (ex: 1 en A, 3 en B) est déséquilibré).

8.4. Architecture Résiliente Typique (Multi-AZ 3-Tiers)

C'est la mise en pratique (complète) de tous les concepts (VPC (9.4) + RDS (3.1) + EC2 (8.3)).

                    (Internet) --> [Route 53 (DNS)]
                    |
                    v
                    [ 🌐 Subnet Public (AZ-A) ]    [ 🌐 Subnet Public (AZ-B) ]
                    |                              |
                    +-- [ ⚖️ ALB (Node 1) ]         +-- [ ⚖️ ALB (Node 2) ]  <-- (Health Checks)
                        | (Cross-Zone)         |
                        +---------- (Trafic) --+
                        |                      |
                        v                      v
                        [ 🔒 Subnet Privé (AZ-A) ]     [ 🔒 Subnet Privé (AZ-B) ]
                        | (Route -> NAT-A)             | (Route -> NAT-B)
                    |                              |
                    +-- [ 💻 EC2 (ASG) ]           +-- [ 💻 EC2 (ASG) ]  <-- (Auto Scaling Group)
                    |                              |
                    +-- [ 💻 EC2 (ASG) ]           +-- [ 💻 EC2 (ASG) ]
                    | (Port 5432)          |
                    v                      v
                    [ 🔑 Subnet Data (AZ-A) ]      [ 🔑 Subnet Data (AZ-B) ]
                    |                              |
                    +-- [ 🐘 RDS Master ] <--(Sync)--> [ 🐘 RDS Standby ] <-- (RDS Multi-AZ)
                    

Checklist de Résilience (Panne AZ-A)

1. (Panne AZ-A) (subnet-public-a, private-a, data-a) tombent.
2. (ALB) Le Nœud 1 (ALB) (AZ-A) tombe. Route 53 (Health Check) arrête d'envoyer du trafic à ce nœud. 100% du trafic DNS va au Nœud 2 (ALB) (AZ-B). (Downtime: Zéro).
3. (ASG) L'ALB (Nœud 2) détecte (Health Check) que les EC2 (AZ-A) sont Unhealthy. L'ASG (8.1) termine les instances (mortes) (AZ-A) et lance (Scale-Out) de nouvelles instances (remplacement) dans le Subnet (sain) (AZ-B). (Downtime: Zéro, charge répartie sur AZ-B).
4. (RDS) RDS (service) détecte (Health Check) que le Master (AZ-A) est mort. RDS (automatiquement) promeut le Standby (AZ-B) en nouveau Master. RDS (automatiquement) bascule le DNS (interne) (...rds.amazonaws.com) vers l'IP (privée) du nouveau Master (AZ-B). (Downtime: 30-60 sec, le temps du failover BDD).
5. (NAT) Les EC2 (AZ-B) (saines) utilisent le NAT-B (sain) (via leur Route Table (AZ-B)) pour les apt update. (Downtime: Zéro).

7.2. CloudWatch Logs (L'Agent)

(Piège) : Contrairement à Lambda, une instance EC2 n'envoie AUCUN log (/var/log/syslog, nginx.log...) à CloudWatch par défaut.

Les logs (par défaut) "vivent" et "meurent" sur le disque EBS de l'instance.

La Solution : L'Agent CloudWatch (CloudWatch Agent)

Pour centraliser vos logs (applicatifs, OS) dans CloudWatch Logs (pour analyse, alerte, rétention), vous devez installer et configurer l'Agent CloudWatch (un logiciel) sur l'OS de l'EC2.

Pré-requis (IAM)

L'instance EC2 doit avoir un IAM Role attaché avec (au minimum) la Policy CloudWatchAgentServerPolicy (qui contient logs:PutLogEvents, logs:CreateLogStream...).

Exemple de Configuration (config.json de l'Agent)

Vous stockez ce JSON (ex: dans SSM Parameter Store) et vous dites à l'Agent de l'utiliser :

                    {
                    "logs": {
                    "logs_collected": {
                    "files": {
                    "collect_list": [
                    {
                    "file_path": "/var/log/nginx/access.log",
                    "log_group_name": "/mon-app/prod/nginx-access",
                    "log_stream_name": "{instance_id}"
                    },
                    {
                    "file_path": "/var/log/auth.log",
                    "log_group_name": "/mon-app/prod/auth",
                    "log_stream_name": "{instance_id}"
                    }
                    ]
                    }
                    }
                    }
                    }
                

(Résultat) : L'Agent "tail" (surveille) ces fichiers (access.log, auth.log) en temps réel et "streame" (envoie) les nouvelles lignes vers les Log Groups spécifiés (/mon-app/prod/...).

7.3. CloudWatch Alarms (Actions)

Une Alarme "surveille" (watch) une Métrique (7.1). Si la Métrique dépasse un "Seuil" (Threshold) (ex: 80%) pendant une "Période" (ex: 15 min), l'Alarme passe à l'état ALARM et déclenche des Actions.

Actions (Que faire en cas d'Alarme ?)

7.4. Monitoring Avancé (APM & Tracing)

CloudWatch (7.1) vous dit : "Le CPU est à 90%" (Le Symptôme).

Le monitoring avancé (APM) vous dit : "Le CPU est à 90% parce que la fonction process_payment() (Java) est bloquée (Lock)". (La Cause Racine).

AWS X-Ray (Tracing Distribué)

X-Ray n'est pas un moniteur de "serveur", c'est un moniteur de "requête" (Trace). Il suit une requête (ex: 1 ID de Trace) à travers plusieurs services (Microservices).

Usage : Indispensable pour les architectures distribuées (ex: API GW -> Lambda -> EC2-API -> RDS).

(Exemple de Trace X-Ray) :

                    Trace (550ms)
                    ├─ API Gateway (10ms)
                    └─ Lambda:FonctionA (540ms)
                    ├─ (Init) (120ms)
                    └─ (Invoke) (420ms)
                    ├─ (Appel HTTP: api.stripe.com) (300ms)
                    └─ (Appel Boto3: dynamodb:PutItem) (120ms)
                

(Analyse) : Le goulot d'étranglement (300ms) est l'API externe (Stripe), pas la BDD (DynamoDB).

(Installation) : Nécessite 1. L'Agent/Daemon X-Ray (sur l'EC2) et 2. Le SDK X-Ray (aws-xray-sdk) (dans votre code Python/Java/Node) pour "instrumenter" (patcher) les appels (boto3, requests).

Intégration Tiers (Datadog, New Relic, Grafana...)

Ce sont des plateformes d'Observabilité (SaaS ou OSS) qui combinent tout (Metrics, Logs, Traces (APM)).

• Datadog / New Relic : (SaaS) Vous installez leur Agent (propriétaire) sur l'EC2. L'Agent collecte (en haute résolution) les Métriques (OS, App), les Logs (fichiers), et les Traces (APM) et les envoie à leur plateforme (Cloud). (Ils utilisent aussi une Intégration IAM (Cross-Account) pour "puller" (tirer) les métriques CloudWatch (7.1) (ex: RDS, ALB)).
• Grafana (OSS) : (Auto-hébergé)
  • (Source 1) Vous installez Prometheus Node Exporter (sur l'EC2) et Prometheus (scrapeur) -> Grafana (Dashboard).
  • (Source 2) Vous donnez (via IAM) à Grafana un accès (API) à CloudWatch, et Grafana "importe" les métriques CloudWatch (7.1) pour les afficher.

6.2. Choisir le Bon Type (Workload vs Coût)

Workload 1 : Volume de Boot (OS) / Serveur Web (Standard)

• Choix : gp3.
• Pourquoi : gp3 (par défaut) offre 3000 IOPS garantis, même pour un petit disque (ex: 30GB).
• (Anti-Pattern) : Utiliser gp2 (Legacy) (30GB * 3 IOPS/GB = 90 IOPS de base). Le système (apt update, logs...) serait extrêmement lent (goulot d'étranglement disque).

Workload 2 : Base de Données (OLTP) (Postgres, MySQL)

• Choix (Prod) : io2 Block Express (ou io1).
• Pourquoi : Les BDD (OLTP) sont sensibles à la latence et nécessitent des IOPS garantis (prévisibles) (accès aléatoires). io2 garantit une latence sub-milliseconde et les IOPS que vous payez (ex: 20 000 IOPS).
• Choix (Dev/Test) : gp3 (avec IOPS/Throughput augmentés manuellement si besoin).

Workload 3 : Data Warehouse / Log Processing (Kafka)

• Choix : st1 (HDD).
• Pourquoi : Ce workload est "Séquentiel" (scan de gros fichiers). Il se moque des IOPS (accès aléatoire), il a besoin de Débit (MB/s). st1 offre un haut débit (jusqu'à 500 MB/s) pour un coût (GB/mois) beaucoup plus bas que gp3.

Alternative (Latence Extrême) : Instance Store

• Choix : (Pas EBS) Instances i4i, c6gd...
• Pourquoi : Si la latence (microsecondes) est reine et que la persistance n'est pas requise (ex: Caches (Redis), Buffers). Les disques NVMe (locaux) sont physiquement sur la machine (pas sur le réseau). (Attention : Données perdues si Stop/Terminate).

6.3. Snapshots (Backups EBS)

Un Snapshot (Instantané) est un backup (une "photographie") d'un volume EBS, stocké (à moindre coût) dans S3 (géré en arrière-plan par AWS).

Caractéristique Clé : Inbound (Incrémentiel)

Les snapshots sont incrémentiels (ils ne copient que les "blocs" (données) modifiés depuis le dernier snapshot).

• Dimanche (Snap A) : Volume (100GB) (10GB utilisés) -> Snapshot A (Taille facturée : 10GB).
• Lundi (Snap B) : (Vous modifiez 2GB de données) -> Snapshot B (Taille facturée : 2GB (le delta)).
• Mardi (Snap C) : (Vous supprimez Snap A) -> (Magie) Snap B (2GB) "absorbe" (garde) les 8GB (de A) dont il dépend. (AWS ne supprime que les 2GB (de A) qui ont été modifiés par B).

Automatisation (AWS Data Lifecycle Manager - DLM)

C'est l'outil (PaaS) recommandé pour gérer les snapshots (plutôt que des scripts cron/boto3).

Exemple de Policy (DLM) : "Backup-Prod-Daily"

• Cible (Target) : (Ressources) (Tag) Backup=Prod-Daily.
• Fréquence (Schedule) : cron(0 2 * * ? *) (Tous les jours à 02:00 UTC).
• Rétention (Retention) : Garder 7 (Type: "Count") snapshots. (DLM supprime automatiquement le 8ème (le plus ancien)).

Chiffrement & Cross-Region Backup (DR)

• Chiffrement (Encryption) : Si le Volume EBS (source) est chiffré (KMS), le Snapshot (backup) est automatiquement chiffré (avec la même clé).
  (Lors d'une "Copie" (Copy) de Snapshot, vous pouvez changer la clé KMS (re-chiffrer) ou chiffrer (un snapshot non-chiffré)).
• Cross-Region Backup (DR) : DLM (ou l'API) permet de Copier (Copy) (automatiquement) le snapshot (créé à Paris eu-west-3) vers une autre Région (ex: Francfort eu-central-1) (pour un Plan de Reprise d'Activité (PRA) en cas de panne "Région").

6.4. Montage & Redimensionnement (Resize) (Linux)

Flux (Montage d'un NOUVEAU Volume)

1. (AWS) Create Volume (EBS) (ex: 100GB).
2. (AWS) Attach Volume (à l'EC2) (ex: Attribue le device /dev/sdf).
3. (EC2 SSH) lsblk (Vérifie que nvme1n1 (Nitro) ou xvdf (Xen) (mappé à /dev/sdf) apparaît).
4. (EC2 SSH) sudo file -s /dev/nvme1n1 (Vérifie "data" (vide)).
5. (EC2 SSH) sudo mkfs -t xfs /dev/nvme1n1 (Formater. XFS (recommandé) ou ext4).
6. (EC2 SSH) sudo mkdir /data (Créer le point de montage).
7. (EC2 SSH) sudo mount /dev/nvme1n1 /data (Monter).
8. (EC2 SSH) sudo blkid (Trouver l'UUID du device (ex: uuid-123...)).
9. (EC2 SSH) (Crucial) sudo vi /etc/fstab (Ajouter UUID=uuid-123... /data xfs defaults,nofail 0 0) (pour le montage au reboot).

Flux (Redimensionnement (Resize) à Chaud)

Pour agrandir (ex: 100GB -> 150GB) un volume existant (monté) (/data).

1. (AWS Console/CLI) Modify Volume (EBS) (Changer 100 -> 150). (Attend Optimizing -> Completed).
2. (EC2 SSH) lsblk (Le Disque (nvme1n1) (150G) est maintenant plus grand que la Partition (nvme1n1p1) (100G)).
3. (EC2 SSH) sudo growpart /dev/nvme1n1 1 (Agrandir la "Partition" 1 (pour /dev/nvme1n1p1)).
4. (EC2 SSH) (Si XFS) sudo xfs_growfs /data
5. (EC2 SSH) (Si EXT4) sudo resize2fs /dev/nvme1n1p1
6. (EC2 SSH) df -h (Vérifie que /data affiche 150G).

(À Chaud) : Ce processus (sur les OS modernes + XFS/EXT4) se fait à chaud (live), sans "unmount" (démonter) le volume (zéro downtime applicatif).

6.5. Performance Tuning (IOPS, Throughput, Burst)

IOPS vs Throughput (Débit)

• IOPS (Input/Output Operations Per Second) : (Nb Opérations/sec). Important pour les petites lectures/écritures aléatoires (ex: BDD OLTP, Boot OS).
• Throughput (Débit) : (Vitesse MB/s). Important pour les grosses lectures/écritures séquentielles (ex: Data Warehouse (st1), Streaming vidéo, Copie de gros fichiers).

Le Piège (Goulot) : Instance vs EBS

(Le Goulot d'Étranglement) : La performance (IOPS/Throughput) que vous obtenez est le MINIMUM de (A) ce que l'Instance (EC2) peut gérer, et (B) ce que le Volume (EBS) peut fournir.

Scénario (Échec) :

1. (EBS) Vous provisionnez un io2 (Volume) capable de 50 000 IOPS.
2. (EC2) Vous l'attachez à une t3.micro (Instance).
3. Problème : L'instance t3.micro a une limite (Baseline) (goulot) de (ex:) 2 000 IOPS (max).
4. Résultat : Vous payez pour 50 000 IOPS (EBS), mais vous n'obtenez (throttling) que 2 000 IOPS (limite EC2).

(Bonne Pratique) : Toujours utiliser des instances "EBS-Optimized" (ex: m6g.large, r6g.xlarge...) (activé par défaut) qui garantissent une bande passante (réseau) dédiée (ex: 10 Gbps / 10 000 IOPS) entre l'EC2 et le service EBS.

Crédits Burst (gp2 / Legacy)

Les volumes gp2 (Legacy) utilisaient un système de "Crédits Burst" (similaire au CPU (3.1)).

• IOPS de base (3 IOPS/GB) (ex: 100GB = 300 IOPS).
• Accumule des crédits (idle).
• "Burst" (Dépense) à 3000 IOPS (pendant 30 min).
• (Crédits Vides) -> Performance s'effondre à 300 IOPS (Baseline).

(Solution gp3) : gp3 n'a pas de crédits Burst. Il offre une performance garantie (Baseline) (Défaut 3000 IOPS) 24/7. (Toujours préférer gp3 à gp2).

5.2. Subnets Publics vs Privés

La distinction (Public/Privé) ne dépend pas du Subnet lui-même, mais de la Table de Routage (Route Table) (5.3) qui lui est attachée.

(Bonne Pratique) : Toujours placer les EC2 (applicatives) dans un Subnet Privé, et mettre un Load Balancer (ALB) (dans un Subnet Public) devant.

5.3. Routage vers Internet (IGW vs NAT)

Option 1 : Internet Gateway (IGW) (Subnet Public)

Pour les ressources (ex: ALB) qui ont besoin d'un accès bidirectionnel (Entrant + Sortant) avec Internet.

• Route Table (Publique) : 0.0.0.0/0 -> igw-123...
• Ressource : Doit avoir une IP Publique/EIP.
• Flux : L'IGW gère le NAT 1:1 (IP Privée <-> IP Publique).

Option 2 : NAT Gateway (Subnet Privé)

Pour les ressources (ex: EC2-App) qui n'ont besoin que d'un accès sortant (Egress-Only) (ex: apt-get update, pip install, appel API Stripe), tout en restant injoignables depuis Internet.

• Composant (PaaS) : Le NAT Gateway (PaaS) est placé dans le Subnet Public (il a besoin d'une EIP (5.4)).
• Route Table (Privée) : 0.0.0.0/0 -> nat-456... (L'ID du NAT GW).
• Ressource : L'EC2 (Privée) n'a pas d'IP Publique.
• Flux (Sortant) : (EC2 10.0.1.50) -> (Route nat-456) -> (NAT GW) -> (NAT GW fait du SNAT : 10.0.1.50 devient EIP_DU_NAT) -> (IGW) -> (Internet).
• Flux (Entrant) : (Internet) -> (NAT GW) -> (Bloqué). Le NAT GW (Stateful) n'accepte que les réponses (Retour) aux connexions qu'il a initiées.

(Coût) : Les NAT Gateways sont facturés $/Heure + $/GB (Data Processed). (Peut coûter très cher).

5.4. Elastic IP (EIP)

Une Adresse IP Élastique (EIP) est une adresse IPv4 publique statique (fixe) que vous "allouez" (réservez) dans votre compte AWS.

EIP (Statique) vs IP Publique (Éphémère)

• IP Publique (Auto-assign) : (Éphémère) Assignée au démarrage (Start) de l'EC2. Perdue (libérée) à l'arrêt (Stop). (Problème pour les DNS).
• Elastic IP (Statique) : (Fixe) Vous l'associez (manuellement) à l'EC2. Elle survit à un Stop/Start. (L'IP ne change pas).

Cas d'Usage

• (Obligatoire) NAT Gateways (5.3) : Un NAT GW requiert 1 EIP pour son IP sortante (fixe).
• (Recommandé) Bastion Hosts (5.6) : Pour avoir une IP (fixe) à (Whitelist) dans vos SGs et à mettre dans votre client SSH.
• (Legacy) Serveurs Uniques : (Anti-Pattern) Un serveur Web (unique) qui ne peut pas être derrière un Load Balancer et nécessite un Record DNS A.

(Piège de Coût FinOps) : Une EIP est GRATUITE si elle est attachée à une instance EC2 Running. Une EIP non-attachée (ou attachée à une instance Stopped) est facturée (cher) (pour éviter la pénurie d'IPv4).

5.5. DNS Interne (AmazonProvidedDNS & Route 53)

1. AWS DNS (Le ".2 Magique")

Par défaut (via DHCP), chaque ressource (EC2/Lambda) dans votre VPC est configurée pour utiliser le DNS Resolver d'AWS.

Il est toujours situé à l'adresse [Base_CIDR] + 2. (Ex: Si VPC = 10.0.0.0/16, le DNS est 10.0.0.2).

Ce DNS est "Split-Horizon" (intelligent) :

• (Public) Il résout les noms publics (ex: google.com) (si l'EC2 a un accès Internet (5.3)).
• (Privé) Il résout les noms DNS privés (ex: ip-10-0-1-50.eu-west-3.compute.internal -> 10.0.1.50).

2. Route 53 (Private Hosted Zones)

C'est la Bonne Pratique (vs IP hardcodées) pour le "Service Discovery" (Découverte de services).

Scénario : L'EC2-App (10.0.1.50) doit appeler l'EC2-API (10.0.1.60).

• (Mauvais) : config.py -> API_HOST = "10.0.1.60". (Si l'EC2-API est remplacée (IP .61), le code est cassé).
• (Bon) :
  1. (Route 53) Créer une "Private Hosted Zone" (Zone DNS Privée) : my-app.internal.
  2. (Route 53) Attacher cette Zone (my-app.internal) au VPC.
  3. (Route 53) Créer un Record (A) : api.my-app.internal -> 10.0.1.60.
  4. (Code) config.py -> API_HOST = "api.my-app.internal".

(Résultat) : L'EC2-App (utilisant le DNS .2) résout api.my-app.internal en 10.0.1.60. Si l'API change d'IP (.61), il suffit de mettre à jour le DNS (pas le code).

5.6. Bastion Hosts (Serveurs de Rebond / Jump Servers)

C'est l'architecture "classique" (Legacy) pour accéder (SSH/RDP) à des instances (EC2, RDS-Tunnel) situées dans un Subnet Privé (5.2).

Un "Bastion" est une (petite) instance EC2 (Linux/Windows) qui "vit" dans le Subnet Public (5.2) et qui est durcie (Harden).

Architecture de Sécurité (Flux SSH)

                    (Admin PC) (Mon IP: 80.1.2.3)
                    |
                    (Port 22) (Autorisé par 'sg-bastion')
                    |
                    v
                    [ 🌐 Subnet Public ]
                    |
                    +-- [ 💻 EC2-Bastion (EIP: 54.1.2.3) ] (SG: 'sg-bastion')
                    |
                    (Port 22) (Autorisé par 'sg-app')
                    |
                    v
                    [ 🔒 Subnet Privé ]
                    |
                    +-- [ 💻 EC2-App (IP: 10.0.1.50) ] (SG: 'sg-app')
                

Configuration des Security Groups (SG)

• sg-bastion (Sur le Bastion) :
  • Inbound : Allow TCP/22 (Source: 80.1.2.3/32 (Mon IP Bureau)).
• sg-app (Sur l'EC2 Privée) :
  • Inbound : Allow TCP/22 (Source: sg-bastion (L'ID du SG du Bastion)).

(Inconvénients) : Nécessite d'ouvrir le Port 22 (même si limité), nécessite de gérer/roter des clés SSH (.pem), nécessite de patcher (apt update) l'OS du Bastion.

(Alternative Moderne) : SSM Session Manager (5.7).

5.7. Alternative : SSM Session Manager (Mode Moderne)

(La Meilleure Pratique 2024) SSM Session Manager est un service AWS (partie de Systems Manager) qui vous donne un accès Shell (bash) ou PowerShell (sécurisé, audité) à vos instances (même privées)... SANS Bastion, SANS Clé SSH (.pem), et SANS ouvrir le Port 22 (SSH).

Pré-requis (3 Conditions)

1. Agent SSM : L'EC2 (Privée) doit avoir l'Agent SSM (installé par défaut sur Amazon Linux, Ubuntu...).
2. IAM Role : L'EC2 (Privée) doit avoir un IAM Role (Instance Profile) attaché, avec la Policy (AWS) AmazonSSMManagedInstanceCore.
3. Routage (Sortant) : L'EC2 (Privée) doit pouvoir contacter (en Sortie, HTTPS/443) l'API (Publique) de SSM.
   • (Option A) via un NAT Gateway (5.3).
   • (Option B) (Plus sécurisé/moins cher) via des VPC Endpoints (Interface) (pour ssm, ssmmessages, ec2messages).

Architecture de Sécurité (Flux SSM)

                    (Admin PC) (Avec Perms IAM 'ssm:StartSession')
                    |
                    (API Call (443))
                    |
                    v
                    [ ☁️ AWS SSM API (Service) ]
                    |
                    (Initie le "Tunnel" (WebSocket))
                    |
                    v
                    [ 🔒 Subnet Privé ]
                    |
                    +-- [ 💻 EC2-App (IP: 10.0.1.50) ] (SG Inbound: VIDE (Port 22 Fermé))
                    |
                    (L'Agent SSM (local) a une connexion (Outbound 443) vers l'API SSM)
                

(Avantages) : Zéro exposition réseau (Pas de Port 22, pas de Bastion). Accès via IAM (pas de clés .pem). Audit complet (toutes les commandes (ls, rm) sont logguées sur S3/CloudWatch).

4.2. Network ACL (NACL) - Le Pare-feu "Stateless"

Le NACL est une couche de défense optionnelle (facultative) qui opère au niveau du Subnet (le "bâtiment" entier).

Caractéristiques Clés (Stateless)

• Niveau : Subnet. (S'applique à toutes les EC2 dans ce Subnet).
• Règles : Allow ET Deny. (Évaluées par N° (100, 200...)).
• État : STATELESS (Amnésique).
  • (Le Piège) : Si vous autorisez (Inbound) le Port 80, vous devez aussi autoriser (Outbound) les ports "éphémères" (1024-65535) (le trafic de réponse).

Meilleure Pratique (Utilisation)

(Bonne Pratique) : Laissez la NACL par Défaut (celle créée avec le VPC), qui est Allow All (In/Out). Ne la touchez pas.

Gérez 100% de votre sécurité réseau "applicative" (Port 80, 5432, 22) via les Security Groups (SG) (4.1) (qui sont Stateful et plus faciles à gérer).

(Seul Cas d'Usage) : N'utilisez une NACL que pour "Blacklister" (Deny) une IP (ou plage d'IP) malveillante (ex: attaque DDoS, scan) au niveau du Subnet (avant même qu'elle n'atteigne vos SGs).

4.3. IAM Roles pour EC2 (L'Identité de la Machine)

(NE JAMAIS FAIRE) : Ne jamais copier des clés (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) (d'un "User IAM") dans le code (config.py) ou les variables d'environnement (.env) de l'instance EC2.

(Risque) : Si l'instance est compromise (via faille Web), l'attaquant vole ces clés (longue durée) et peut (potentiellement) détruire tout votre compte AWS.

La Bonne Pratique : IAM Role (Instance Profile)

C'est l'identité (temporaire) que l'EC2 "assume" (endosse). C'est la seule façon sécurisée de donner des permissions AWS à votre code (Boto3, SDK...).

Flux (Automatique)

1. (Admin) Vous créez un IAM Role (ex: Role-App-Web).
   • (Trust Policy) : Fait confiance à ec2.amazonaws.com.
   • (Permission Policy) : Allow s3:GetObject (sur Bucket-Assets), Allow secretsmanager:GetSecretValue (sur Secret-RDS).
2. (Admin) Vous attachez ce Rôle (via un "Instance Profile") à l'instance EC2.
3. (Code Python/Boto3) (sur l'EC2) Vous faites : client = boto3.client('s3') (sans clés !).
4. (SDK) (Automatique) Le SDK appelle l'IMDS (2.3) (169.254.169.254).
5. (AWS STS) (Automatique) AWS (via IMDS) génère des clés temporaires (1h) (basées sur le Role-App-Web).
6. (SDK) (Automatique) Le SDK utilise ces clés (temporaires) pour appeler s3:GetObject.

(Résultat) : Zéro clé secrète sur la machine. Sécurité maximale (Least Privilege, Clés temporaires).

4.4. AWS Systems Manager (SSM) - Gestion (Sans SSH)

SSM est la "console de gestion" (PaaS) de votre flotte EC2 (et On-Premise).

(Pré-requis) : 1. L'instance EC2 doit avoir l'Agent SSM (installé par défaut sur Amazon Linux, Ubuntu...). 2. L'instance doit avoir un IAM Role (4.3) avec la Policy AmazonSSMManagedInstanceCore.

SSM Session Manager (Le "Tueur" de SSH)

(Bonne Pratique n°1) : C'est un accès Shell (bash) ou PowerShell (sécurisé, audité) à votre instance... SANS ouvrir le Port 22 (SSH) ou 3389 (RDP).

• Réseau : Le Security Group (4.1) (Inbound) peut être 100% fermé (Vide).
• Flux : L'Agent SSM (sur EC2) initie une connexion Sortante (Outbound) (Port 443) vers l'API (Publique) de SSM.
• Accès (Admin) : L'Admin (via Console AWS/CLI) demande à l'API SSM : "Connecte-moi (via ce tunnel) à l'instance i-123".
• Sécurité (IAM) : L'accès est contrôlé par IAM (ssm:StartSession), pas par des clés SSH (.pem).
• Audit : Toutes les commandes (ls, rm) peuvent être logguées (CloudWatch Logs / S3).

Autres Fonctionnalités SSM

• Run Command : Exécuter un script (ex: Restart-Nginx) (asynchrone) sur 1000 serveurs en même temps.
• Patch Manager : (Automatisé) Scanne (Compliance) et déploie (Patche) les mises à jour OS (ex: "Appliquer patchs Critiques (CVE) tous les Dimanches à 2h").
• Inventory : Collecte (automatiquement) l'inventaire (Applications installées, Services, Versions...) de toute la flotte.

4.5. Durcissement OS (Hardening)

Le "Hardening" (Durcissement) est l'action de sécuriser l'OS (Système d'Exploitation) lui-même, en partant du principe que le réseau (SG/NACL) pourrait échouer (Défense en profondeur (6.1)).

CIS Benchmarks

Le CIS (Center for Internet Security) fournit des "Benchmarks" (guides/checklists) (ex: "CIS Benchmark for Ubuntu 22.04 LTS") qui sont le standard de l'industrie.

(Bonne Pratique) : Utiliser (ou acheter sur le Marketplace (2.2)) des "CIS Hardened AMIs" (AMIs pré-durcies).

Exemples d'Actions de Hardening

• Désactivation services inutiles :
  • systemctl disable avahi-daemon (mDNS)
  • systemctl disable cups (Imprimantes)
  • systemctl disable postfix (Serveur Mail)
• Configuration sshd_config (si SSH utilisé) :
  • PermitRootLogin no (Jamais de login root)
  • PasswordAuthentication no (Clés SSH (.pem) uniquement, pas de mot de passe)
• Configuration Système de Fichiers (/etc/fstab) :
  • Monter /tmp (temporaire) et /var/tmp avec les options noexec, nosuid, nodev (empêche l'exécution de binaires (malware) depuis /tmp).
• Audit Logs (OS) :
  • Configurer auditd (Linux) ou Windows Event Forwarding.
  • Installer l'Agent CloudWatch pour "streamer" (envoyer) les logs (ex: /var/log/auth.log, /var/log/secure) vers CloudWatch Logs (pour alerte/rétention).

3.2. Mémoire RAM

La RAM (Mémoire) est fixe (liée au Type d'Instance (2.1)). Elle n'est pas "burstable" (contrairement au CPU (3.1) ou au Disque (gp2)).

Workloads "Memory-Bound" (Gourmands en RAM)

Si votre application est "memory-bound" (limitée par la RAM), utilisez les familles optimisées (Ratio CPU:RAM élevé 1:8+) :

• Famille R : (Standard) (ex: r6g.large) - (Bases de données RDS, Caches In-Memory).
• Famille X : (Ex: x2iedn.xlarge) - (Très haute RAM, pour SAP HANA, Caches In-Memory massifs).
• Famille Z : (Haute fréquence CPU + Haute RAM).

Impact sur le Swap (Linux)

Le Piège : Par défaut, les AMIs (Amazon Linux, Ubuntu...) ne provisionnent PAS de partition SWAP (espace d'échange sur disque).

Conséquence (Manque de RAM) :

1. (App) L'application (Java, Python) consomme toute la RAM (FreeableMemory (CloudWatch) = 0).
2. (OS) Le Kernel Linux (n'ayant pas de SWAP) panique.
3. (OS) L'OOM (Out-of-Memory) Killer se déclenche.
4. (OS) L'OOM Killer "tue" (SIGKILL) un processus (généralement le plus gourmand) pour sauver le système (ex: tue le process postgres ou nginx).

Solution : 1. (Mieux) Monitorer FreeableMemory (CloudWatch) et scaler (Upgrade) l'instance (ex: r6g.large -> r6g.xlarge). 2. (Dépannage) Créer (manuellement) un fichier SWAP (dd if=/dev/zero ..., mkswap) sur le disque EBS (mais ce sera lent).

3.3. Réseau (Bande Passante & Placement)

Bande Passante & Enhanced Networking (ENA)

La bande passante (Débit) est liée à la taille (type) de l'instance.

• t3.micro : "Jusqu'à 5 Gbps" (Burstable).
• m6g.large : "Jusqu'à 10 Gbps".
• m6g.16xlarge : "40 Gbps".

Enhanced Networking (ENA) : C'est le "driver" (interface réseau virtuelle) moderne (basé sur SR-IOV) qui permet d'atteindre ces hautes performances (>10 Gbps). (Activé par défaut sur toutes les instances modernes (ex: M5, M6, C5, C6...)).

Placement Groups (Groupes de Placement)

Vous (Client) pouvez influencer le placement physique (Rack, Datacenter) de vos instances EC2 (pour optimiser la performance réseau ou la résilience).

3.4. Stockage (EBS vs Instance Store)

Instance Store (Stockage Local/Éphémère)

C'est un disque (SSD NVMe) physiquement connecté (PCIe) au serveur (Host) AWS. (Ex: instances i4i, d3, c6gd).

• Avantage (Perf) : Extrêmement rapide (IOPS (Millions) et latence (microsecondes) imbattables).
• Inconvénient (Non-Persistent) : Éphémère (Temporaire). Les données sont PERDUES si l'instance est Stoppée, Terminée, ou en cas de panne matérielle (Host).
• Usage : Caches (Redis/Memcached), Buffers (Kafka), Scratch space (calcul), BDD (NoSQL) qui gèrent la réplication (ex: Cassandra).

EBS (Elastic Block Store) (Stockage Réseau/Persistent)

C'est un volume réseau (SAN) (disque dur "virtuel") qui est attaché (via le réseau) à l'instance EC2. (99% des instances (t3, m5, r6) bootent sur EBS).

• Avantage (Persistent) : Les données survivent à un Stop/Start ou à une panne (le volume peut être détaché/ré-attaché à une autre EC2).
• Inconvénient (Perf) : Plus lent (latence millisecondes) que l'Instance Store (latence microsecondes).

Types d'EBS (SSD vs HDD)

• gp3 (SSD - General Purpose) : (Recommandé) Le meilleur rapport prix/perf. (Base: 3000 IOPS / 125 MB/s). (IOPS/Throughput scalables indépendamment de la taille (GB)).
• gp2 (SSD - Legacy) : (Ancien) IOPS liés à la taille (3 IOPS/GB). (Toujours migrer vers gp3).
• io2 Block Express (SSD - Max IOPS) : (Pour BDD (SAP/Oracle)) Si vous avez besoin de > 16,000 IOPS garantis (jusqu'à 256,000 IOPS). (Très cher).
• st1 (HDD - Throughput) : (Disque dur "ScS") Optimisé Débit (MB/s) (gros blocs séquentiels). Pas IOPS (petits blocs aléatoires). (Usage: Data Warehouse, Logs (ELK)).

Fonctionnalités (EBS)

• EBS Multi-Attach : (Pour io1/io2) Permet d'attacher 1 seul volume EBS à plusieurs (max 16) EC2s (dans la même AZ). (Nécessite un "clustering file system" (GFS2, OCFS2) pour gérer le locking).
• Encryption (Chiffrement) : (Bonne Pratique) Cocher "Encrypt this volume" (At-Rest) (via KMS). (Transparent, impact performance négligeable).

2.2. AMI (Amazon Machine Image)

L'AMI est le template (modèle) utilisé pour démarrer (boot) une instance EC2. C'est l'équivalent d'un .iso ou d'une image VMWare.

Une AMI contient (principalement) :

• Un Snapshot EBS (l'image du disque dur / OS).
• Des métadonnées (ex: Architecture (x86/ARM), Kernel, Mappage des disques).

Sources des AMIs

Création d’une AMI Personnalisée ("Golden Image")

C'est une Bonne Pratique (vs User Data). Au lieu de démarrer (lentement) une instance "nue" (Ubuntu) et d'installer (apt install nginx...) à chaque fois, vous "pré-installez" (Bake) l'AMI.

1. (Jour 1) Lancer 1 EC2 (Ubuntu).
2. (Jour 1) S'y connecter (SSH) : apt update, apt install nginx, apt install cloudwatch-agent...
3. (Jour 1) (Console EC2) Clic Droit -> "Create Image (AMI)". (Nom : mon-app-web-v1.0).
4. (Jour 2) (ASG) L'Auto Scaling Group (ASG) démarre 10 EC2 depuis mon-app-web-v1.0.
5. Résultat : Boot en 30 secondes (Nginx est déjà installé).

2.3. Instance Metadata (IMDS)

Le Service de Métadonnées (IMDS) est une "API" (REST) magique, accessible uniquement depuis l'EC2 elle-même, à une adresse IP fixe (Link-Local) :

http://169.254.169.254

Rôle (Qu'est-ce qu'on y trouve ?)

Il permet à l'instance (EC2) de "savoir qui elle est" (introspection), sans connaître son contexte (via curl ou Boto3) :

• .../latest/meta-data/instance-id (Retourne: i-12345...)
• .../latest/meta-data/local-ipv4 (Retourne: 10.0.1.50)
• .../latest/meta-data/public-ipv4 (Retourne: 54.1.2.3)
• .../latest/meta-data/placement/availability-zone (Retourne: eu-west-3a)
• .../latest/meta-data/iam/info (Info sur le Rôle IAM attaché)

IMDSv1 vs IMDSv2 (Sécurité Cruciale)

IMDSv1 (Legacy) : Un simple curl http://169.../iam/security-credentials/ROLE (requête GET) suffisait.
(Faille) : Si un site (sur l'EC2) avait une faille SSRF (Server-Side Request Forgery), un attaquant (externe) pouvait "tromper" le serveur pour qu'il curl cette URL (interne) et vole les credentials (clés secrètes) du Rôle IAM.

IMDSv2 (Moderne - Défaut) : Oblige l'utilisation d'un Token (Session). (Protège contre SSRF).

                    # (Étape 1) Demander un Token (Session) (via PUT)
                    $ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`

                    # (Étape 2) Utiliser ce Token (Header) pour accéder aux métadonnées
                    $ curl -H "X-aws-ec2-metadata-token: $TOKEN" "http://169.254.169.254/latest/meta-data/instance-id"
                

(Bonne Pratique) : Toujours forcer IMDSv2 (Option "HttpTokens: required") lors du lancement d'EC2.

2.4. Instance Lifecycle (Cycle de Vie)

Une instance EC2 passe par différents états (états facturés en gras).

Pending -> Running (En cours) -> Stopping -> Stopped (Arrêté) -> Pending -> Running ... (ou) ... -> Shutting-down -> Terminated (Terminé)

Différence (Cruciale) : Stop vs Terminate

C'est la différence entre "Éteindre" (Stop) et "Jeter à la poubelle" (Terminate).

Reboot (Redémarrer)

Action Reboot = Redémarrage de l'OS (sudo reboot). L'instance ne s'arrête pas (Running -> Running). Les IPs (Publique/EIP) et le disque (EBS) persistent.

1.2. Pourquoi utiliser EC2 ? (vs PaaS/FaaS)

La réponse principale est : la Liberté (Contrôle Total). Contrairement à RDS (PaaS) ou Lambda (FaaS) (qui sont des "boîtes noires" gérées), avec EC2, vous avez les "clés" (l'accès root ou Administrateur).

Contrôle Total

• OS : Vous choisissez l'OS (Amazon Linux, Ubuntu, Windows Server, RHEL...) et vous êtes responsable des patchs de sécurité (apt update).
• Logiciels : Vous pouvez installer n'importe quel logiciel (apt-get, .exe), drivers spécifiques, ou binaires custom.
• Réseau : Vous contrôlez 100% du réseau (Security Groups, IP Privée/Publique, ENI multiples).
• Stockage : Vous choisissez le type (gp3, io2) et la taille du disque (EBS).

Compatible "Workload Legacy" (Migration)

C'est le cas d'usage "Lift & Shift". Si vous avez une application "legacy" (monolithique, ancienne, ex: un vieil Oracle, une app .NET 3.5) qui tourne sur un serveur physique (On-Premise), vous ne pouvez pas la mettre sur Lambda.

Vous pouvez (quasiment toujours) la "migrer" (Lift & Shift) sur une instance EC2 (Windows/Linux) configurée à l'identique (ex: via AWS Migration Service).

Multi-Usage (Flexibilité)

EC2 est la "brique" de base pour tout type de charge :

• Web : Héberger des serveurs Nginx, Apache, Django (Gunicorn), Node.js...
• Compute/Batch : Calculs scientifiques (HPC), jobs de batch (ex: traitement de fin de mois).
• Data : Héberger des bases de données "self-managed" (ex: Cassandra, MongoDB) (si RDS ne convient pas).
• IA / Machine Learning : Instances G (GPU Nvidia, Inférence) ou P (GPU Nvidia, Training).
• Conteneurs : Les "Worker Nodes" (Nœuds de travail) de vos clusters EKS (Kubernetes) ou ECS sont des instances EC2.

1.3. Rôle d’EC2 dans l’Écosystème AWS

EC2 est l'équivalent cloud d'un serveur physique/On-Premise. Il est au centre de l'IaaS et interagit (directement ou indirectement) avec la quasi-totalité des services AWS.

Interactions Principales (Écosystème)

Où trouver les AMIs ?

Savings Plans (SP) (Recommandé)

Engagement (Flexible) : Vous ne vous engagez pas sur une instance, mais sur un montant ($).

Exemple : "Je m'engage à dépenser $10.00 / heure en Compute (EC2, Fargate, Lambda) pendant 3 ans."

Avantage : Flexibilité totale. La réduction s'applique automatiquement (jusqu'à $10/h) à tous vos types d'instances (t3, m5, c5) et services (EC2, Fargate, Lambda) dans le monde entier.