0.0.1 🎯 Objectifs d’apprentissage

Concevoir un VPC avec subnets publics et privés
Configurer IAM (utilisateurs, rôles, politiques)
Mettre en place CloudWatch pour le monitoring
Architecturer une application multi-services sur AWS
Appliquer les principes du Well-Architected Framework

📚 Prérequis : Modules Technique 5-8 (S3, EC2, RDS, Lambda)

⏱️ Temps estimé : 3 heures

1 VPC : réseau privé virtuel

1.1 Pourquoi un VPC ?

Un VPC (Virtual Private Cloud) est ton réseau privé dans AWS. Il isole tes ressources du reste d’Internet et te donne un contrôle total sur le trafic.

flowchart TD
    subgraph VPC["VPC 10.0.0.0/16"]
        subgraph Public["Subnet Public"]
            ALB[Load Balancer]
            NAT[NAT Gateway]
        end
        subgraph Private["Subnet Privé"]
            EC2[EC2 — API FastAPI]
            Lambda[Lambda — Scoring]
        end
        subgraph Data["Subnet Données"]
            RDS[RDS — PostgreSQL]
            S3[S3 — Data Lake]
        end
    end

    Internet[🌐 Internet] --> ALB
    ALB --> EC2
    ALB --> Lambda
    EC2 --> RDS
    Lambda --> RDS
    EC2 --> S3

Architecture VPC pour le projet de pilotage assurance

Composant	Subnet	Accès Internet
Load Balancer	Public	Oui (entrée)
API (EC2)	Privé	Via NAT (sortie uniquement)
Base de données (RDS)	Données	Non
S3	-	Via VPC Endpoint

💡 Principe de base : les ressources qui n’ont pas besoin d’être accessibles depuis Internet (BDD, services internes) sont dans des subnets privés. Seul le point d’entrée (Load Balancer) est dans un subnet public.

2 IAM : gestion des accès

2.1 Principe du moindre privilège

IAM (Identity and Access Management) contrôle qui peut faire quoi sur quelles ressources :

Concept	Description	Exemple
User	Personne physique	Toi, ton collègue
Group	Ensemble d’utilisateurs	Équipe data science
Role	Identité assumable par un service	Lambda qui accède à S3
Policy	Document JSON de permissions	“Lire S3 bucket X”

2.2 Exemple de policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject"
            ],
            "Resource": "arn:aws:s3:::mon-bucket-assurance/*"
        },
        {
            "Effect": "Allow",
            "Action": "rds:Connect",
            "Resource": "arn:aws:rds:eu-west-1:123456:db:portefeuille"
        }
    ]
}

⚠️ Ne jamais utiliser * en production

"Action": "*" et "Resource": "*" donnent tous les droits sur tout. En cas de fuite de clés, un attaquant peut détruire toute ton infrastructure. Toujours appliquer le moindre privilège : chaque service n’a accès qu’à ce dont il a strictement besoin.

3 CloudWatch : monitoring

3.1 Métriques et alertes

CloudWatch collecte les métriques de tous tes services AWS :

Service	Métriques clés	Seuil d’alerte typique
EC2	CPU, mémoire, réseau	CPU > 80% pendant 5 min
RDS	Connexions, latence, espace disque	Espace < 20%
Lambda	Invocations, erreurs, durée	Taux d’erreur > 5%
S3	Requêtes, taille stockée	Coût > seuil budgétaire

3.2 Alertes de coût

# Créer une alerte si les coûts dépassent 50$/mois
aws cloudwatch put-metric-alarm \
    --alarm-name "budget-alert" \
    --metric-name EstimatedCharges \
    --namespace AWS/Billing \
    --statistic Maximum \
    --period 86400 \
    --threshold 50 \
    --comparison-operator GreaterThanThreshold \
    --evaluation-periods 1 \
    --alarm-actions arn:aws:sns:eu-west-1:123456:alerts

📝 Dashboard CloudWatch pour ton projet

Crée un dashboard qui affiche en temps réel :

Nombre de requêtes API de scoring
Temps de réponse moyen
Taux d’erreur des Lambda
Utilisation CPU/mémoire de l’EC2
Espace disque RDS

4 Well-Architected Framework

4.1 Les 6 piliers

Pilier	Question clé	Exemple projet
Excellence opérationnelle	Comment améliorer les processus ?	CI/CD, monitoring, logs
Sécurité	Comment protéger les données ?	IAM, VPC, chiffrement
Fiabilité	Comment résister aux pannes ?	Multi-AZ, backups, auto-scaling
Performance	Comment optimiser les ressources ?	Bon type d’instance, cache
Optimisation des coûts	Comment réduire les dépenses ?	Spot, reserved, right-sizing
Durabilité	Comment réduire l’impact environnemental ?	Right-sizing, régions vertes

Synthèse

4.1.1 🎯 Les 5 points essentiels

VPC isole ton réseau — Subnets publics/privés, Security Groups
IAM = moindre privilège — Chaque service a le minimum de droits nécessaires
CloudWatch surveille tout — Métriques, logs, alertes, dashboards
Architecture en couches — Public → Privé → Données
Well-Architected — 6 piliers pour une infra solide

Auto-évaluation

Question 1 : Pourquoi mettre RDS dans un subnet privé ?

Réponse : Pour empêcher tout accès direct depuis Internet. La base contient des données sensibles (sinistres, clients). Seules les applications dans le même VPC (EC2, Lambda) doivent pouvoir s’y connecter. C’est le principe de défense en profondeur.

Question 2 : Qu’est-ce qu’un rôle IAM et quand l’utiliser ?

Réponse : Un rôle est une identité assumable par un service (pas par une personne). Exemple : un rôle pour Lambda qui lui permet de lire S3 et écrire dans RDS. Avantage : pas de clés d’accès à gérer, les credentials sont temporaires et automatiquement renouvelées.

Question 3 : Comment être alerté si ton budget AWS dépasse un seuil ?

Réponse : Avec CloudWatch Billing Alarms : créer une alarme sur la métrique EstimatedCharges avec un seuil (ex : 50$). Quand le seuil est dépassé, une notification SNS est envoyée (email, SMS). Aussi possible via AWS Budgets avec plus d’options.

Question 4 : Quels piliers du Well-Architected sont les plus critiques pour un projet data assurance ?

Réponse : Sécurité (données personnelles, RGPD, conformité ACPR) et Fiabilité (le scoring doit être disponible 24/7 pour le front-office). L’optimisation des coûts est aussi importante car les volumes de données peuvent être importants.

← Retour à la Semaine 9 Voir la Fiche de travail →