☁️ AWS (Amazon Web Services)

2. Zone de Disponibilité (AZ - Availability Zone)

C'est la base de la Haute Disponibilité (HA).

Une AZ est un (ou plusieurs) Data Center(s) physique(s) (distincts) à l'intérieur d'une Région.

Exemple (Région Paris eu-west-3) :

• AZ 1 (eu-west-3a) : (Data Center 1, ex: Courbevoie)
• AZ 2 (eu-west-3b) : (Data Center 2, ex: Clichy)
• AZ 3 (eu-west-3c) : (Data Center 3, ex: Vitry)

Caractéristiques :

• Isolation (Pannes) : Les AZs sont physiquement séparées (bâtiments, alimentations, réseaux différents) pour résister aux pannes (incendie, inondation).
• Connexion (Faible Latence) : Reliées par des fibres optiques (redondantes) à très faible latence (< 10ms) (permet la réplication synchrone, ex: RDS Multi-AZ).

Bonne Pratique (HA) : Toujours déployer une application (ex: 2 EC2 + 1 ALB) sur (au moins) 2 AZs (ex: 3a et 3b). Si l'AZ 3a tombe (panne), l'ALB (qui est Multi-AZ) envoie 100% du trafic vers l'EC2 (sain) dans l'AZ 3b.

3. Edge Location (Point de Présence)

Un "Edge Location" (Point de Présence) est un mini Data Center (Cache). Il y en a des centaines dans le monde (dans les grandes villes).

Usage (CDN) : C'est l'infrastructure utilisée par Amazon CloudFront (le CDN d'AWS).

Flux (CloudFront)

1. (Serveur "Origine") Votre site (ex: EC2 ou S3) est à Paris (Région).
2. (Client) Un utilisateur à Sydney demande image.jpg.
3. (CloudFront) La requête est routée vers l'Edge Location de Sydney (le plus proche).
4. (Cache Miss) L'Edge de Sydney demande l'image à Paris (Origine) (1 fois).
5. L'Edge de Sydney met en cache image.jpg et la sert à l'utilisateur (rapide).
6. (Utilisateur 2 à Sydney) Demande image.jpg -> Reçoit la copie (Cache Hit) de Sydney (très rapide).

Coûts (Stockage & Réseau)

Stockage (ex: S3, EBS)

Facturé au Go/Mois (ex: $0.023 / Go / Mois pour S3 Standard).

(Et aux opérations : PUT, GET, LIST).

Réseau (Data Transfer)

Le Piège (Coût caché n°1) :

• Data Transfer IN (Internet -> AWS) = Gratuit (0$).
• Data Transfer Inter-AZ (ex: EC2 (AZ-A) -> EC2 (AZ-B)) = Payant (ex: $0.01/Go).
• Data Transfer OUT (AWS -> Internet) = Très Cher ! (ex: $0.09/Go) (Le "Egress cost").

AWS Free Tier (Niveau Gratuit)

Compte (nouveau) gratuit pendant 12 mois. Inclut (par mois) :

• 750h de t2.micro (EC2)
• 5 Go de S3 (Standard)
• 750h de RDS (t2.micro)
• 1M d'appels Lambda
• ... (Voir la liste complète)

Billing Alarms (Alarmes de Facturation)

Bonne Pratique (Jour 1) : Configurer une Alarme CloudWatch (7.3) sur la Facturation (Billing).

Règle : "SI EstimatedCharges (Coût Total) > 50 USD ALORS envoyer une notification (SNS) à admin@ideolab.com". (Empêche les "factures surprises" de 10k$).

2. Policies (Permissions JSON) (Le "Quoi" sur le "Quoi")

Une "Policy" (Politique) est un document JSON qui définit les permissions (Allow / Deny).

(Exemple : Autoriser (Allow) la lecture (s3:GetObject)
          sur le Bucket (Resource) 'mon-bucket')
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowReadS3",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::mon-bucket-prod",
                "arn:aws:s3:::mon-bucket-prod/*"
            ]
        },
        {
            "Sid": "DenyDelete",
            "Effect": "Deny",
            "Action": "s3:DeleteObject",
            "Resource": "*"
        }
    ]
}

Bonne Pratique (Moindre Privilège) : Toujours commencer par Deny All (implicite) et n'autoriser (Allow) que les actions (ex: s3:GetObject) sur les ressources (ex: mon-bucket) strictement nécessaires.

3. Cas d'Usage : Rôle EC2 (Le "Best Practice")

Problème (Mauvaise Pratique) : Une application (Python) sur un EC2 (2.2) doit lire un fichier sur S3 (4.3). Le développeur "hardcode" (écrit en dur) les clés (AWS_ACCESS_KEY) d'un "User" (IAM) dans le code (config.ini).

(FAILLE) Si le code (Git) fuite, l'attaquant a les clés (longue durée) de votre compte.

Solution (Rôle IAM)

1. (Admin) Créer une Policy (2) (ex: "AllowReadMonBucket").
2. (Admin) Créer un Rôle (1) (ex: "MonRoleEC2") qui fait confiance au Service EC2.
3. (Admin) Attacher la "Policy" au "Rôle".
4. (Admin) Lancer l'instance EC2 en lui attachant "MonRoleEC2".

Flux (Magique) :

1. L'application (Python/Boto3 SDK) sur l'EC2 fait : boto3.client('s3') (sans clés).
2. Le SDK "voit" qu'il est sur un EC2 avec un Rôle.
3. Il appelle (automatiquement) le "Metadata Service" (local) d'AWS.
4. AWS (STS) génère des clés temporaires (1h) (basées sur la Policy du Rôle).
5. Le SDK utilise ces clés temporaires pour appeler S3.

Résultat : Zéro clé "hardcodée". Sécurité maximale.

2. AMI (Amazon Machine Image)

L'AMI est le "template" (modèle) de disque (OS) utilisé pour démarrer (boot) l'instance.

Elle contient l'OS (Linux, Windows), les patchs, et (optionnellement) vos logiciels pré-installés.

• Marketplace AMIs : Images pré-configurées (ex: Ubuntu 22.04, RHEL, Windows Server).
• Custom AMIs : (Bonne pratique) Vous lancez un Ubuntu, vous installez (apt install) Nginx/Java/Code, et vous créez un Snapshot (backup) de cet état. C'est votre "Golden Image" (AMI) (utilisée par l'ASG (3.2)).

Architecture (ALB)

(Client) -> [ALB (Façade)]
               │ (Règle: Path='/api/*')
               │
               ▼
[ Target Group A (Pool API) ]
   │ (Health Check: Port 8080)
   │
   ├─► [EC2 1 (AZ-A)] (Port 8080)
   └─► [EC2 2 (AZ-B)] (Port 8080)

• Listener (Écouteur) : (Sur l'ALB) "J'écoute sur le Port 443 (HTTPS)".
• Rule (Règle) : (Sur l'ALB) "SI Host == api.com ALORS Forward vers Target Group A".
• Target Group (Pool) : Un "pool" de cibles (EC2, IP, Lambda).
• Health Check (Sonde) : Le Target Group teste (ping) (ex: GET /health) les cibles. S'il échoue, il arrête de leur envoyer du trafic.

2. Scalabilité (Scaling Policies)

Configuration : MinSize: 2, Desired: 2, MaxSize: 10.

Politique de Scaling (Exemple) : Target Tracking (Cible)

• "Je veux que l'utilisation CPU moyenne (AVG(CPU)) de mon ASG soit de 50%."

Flux (Scale-Out) :

1. (Pic de trafic) Le CPU moyen des 2 instances passe à 80%.
2. (Alarme CloudWatch) CPU > 50%.
3. L'ASG lance (Launch) de nouvelles instances (ex: +2) (Total = 4).
4. La charge (CPU) se répartit sur 4 instances et redescend à ~40%.

Flux (Scale-In) :

1. (Nuit) Le CPU moyen tombe à 10%.
2. (Alarme) CPU < 50%.
3. L'ASG termine (Terminate) 2 instances (Total = 2) (Retour à MinSize).

3. Launch Template (Modèle de Lancement)

C'est la configuration (le "plan") que l'ASG utilise pour lancer une nouvelle instance.

Il définit :

• AMI (OS) (2.2) : (ex: "ami-mon-app-v2")
• Instance Type (Taille) : (ex: "t3.micro")
• Security Group (Pare-feu) (2.3) : (ex: "sg-webserver")
• IAM Role (Permissions) (2.1) : (ex: "MonRoleEC2")
• Key Pair (Clé SSH) : (ex: "ma-cle.pem")

Subnet Privé

Définition : Un Subnet dont la Route Table n'a pas de route directe vers l'IGW.

Usage : (Sécurité) Ressources "back-end" (ex: Bases de Données (RDS), Workers, EC2 applicatifs).

Route Table (Privé, Sortie via NAT) :

Destination  |  Target
-----------------------------------
10.0.0.0/16  |  local
0.0.0.0/0    |  nat-5678 (NAT Gateway)

Route Table (Privé, Isolé) :

Destination  |  Target
-----------------------------------
10.0.0.0/16  |  local

Règles de Cycle de Vie (Lifecycle Rules)

L'outil d'automatisation (natif S3) pour réduire les coûts.

Exemple de Règle :

• (Jour 0) Upload -> S3 Standard (Chaud).
• (Après 30 jours) Transition -> S3 Standard-IA (Tiède).
• (Après 90 jours) Transition -> S3 Glacier Flexible (Froid/Archive).
• (Après 365 jours) Expiration -> Supprimer (Delete).

Type de Lancement (Cluster) : EC2 vs Fargate

1. Mode EC2 (Legacy/IaaS)

Vous (l'Admin) devez créer et gérer un ASG (3.2) d'instances EC2 (Linux + Agent ECS). ECS "place" (schedule) les Tâches (Containers) sur *vos* EC2.

Inconvénient : Vous gérez l'OS, les patchs, le "bin-packing" (optimisation des VMs).

2. Mode Fargate (Serverless/PaaS)

(Recommandé) Il n'y a pas de cluster EC2. Vous demandez juste au "Service" : "Je veux 3 Tâches (1vCPU, 2Go RAM)".

AWS (Fargate) provisionne (auto) le "Compute" (Micro-VMs) nécessaire (Serverless) pour exécuter ces 3 Tâches.

Avantage : Zéro gestion d'OS/EC2 (Serverless). (Similaire à Lambda).

CloudWatch Logs

Le service de centralisation de logs (similaire à Splunk/ELK, mais plus simple).

• Log Group (Groupe) : (Le "Dossier") (ex: /aws/lambda/ma_fonction, /var/log/syslog).
• Log Stream (Flux) : (Le "Fichier") (ex: 1 flux par instance EC2, 1 flux par conteneur Lambda).

Usage : L'Agent CloudWatch (installé sur EC2) "lit" (tail) /var/log/nginx/access.log et l'envoie (PUSH) vers CloudWatch Logs. Les Lambdas y envoient leur stdout (console.log) nativement.

CloudWatch Alarms (Alarmes)

Le "déclencheur". C'est ce qui surveille une Métrique (Metric) et déclenche une Action.

Exemple (Alerte CPU) :

• Condition (Metric) : SI CPUUtilization (EC2)
• Seuil (Threshold) : EST > 90%
• Période (Period) : PENDANT 5 minutes
• État (State) : ALORS passer en état ALARM

Actions (Déclenchées par l'état ALARM) :

• Action SNS (Notification) : Envoyer un email/SMS (via SNS).
• Action EC2 (Auto-réparation) : Redémarrer (Reboot) l'instance EC2.
• Action ASG (Scaling) : (Voir 3.2) Déclencher la politique de Scale-Out.