☁️ AWS & Déploiement Cloud
Services vitaux, Pipeline & Architecture
🔥 Mise en situation : Le Délai de Livraison
Année 2005. L'entreprise "OnPremise Corp" vient de signer un gros client et a besoin urgemment d'un nouveau serveur physique pour absorber la charge. Elle doit : demander un budget au DAF (3 semaines), commander le matériel chez Dell (4 semaines de livraison), le rack dans le Datacenter (1 journée), installer l'OS et configurer le réseau (3 jours). Total : Près de 2 mois d'attente. Pendant ce temps, les utilisateurs subissent des lenteurs extrêmes.
Année 2026. La startup "CloudFast", hébergée sur AWS, a le même problème. Le DevOps écrit 5 lignes de Terraform, lance un script, et 45 secondes plus tard, un nouveau serveur flambant neuf est opérationnel en production et absorbe le trafic. Fin de l'histoire.
⚠️ Rappel : Scalabilité VS Élasticité
Ces deux termes sont souvent confondus, mais ils ne veulent pas tout à fait dire la même chose dans l'esprit Cloud :
- Scalabilité (Mise à l'échelle) : La capacité d'agrandir l'infrastructure pour encaisser plus de charge (ex: Ajouter 5 serveurs web pour le Black Friday).
- Élasticité : C'est la nature "caoutchouc" du Cloud. C'est la capacité de scaler, mais surtout de réduire instantanément (Scale-In) l'infrastructure quand le trafic retombe, pour arrêter immédiatement de payer. Le Cloud se paie à la seconde. L'élasticité est financière avant d'être technique.
⚠️ Rappel : IaaS, PaaS, SaaS, quelle différence ?
- IaaS (Infrastructure as a Service) : On vous loue la machine brute (Serveur, Stockage, Réseau). À vous de tout installer et maintenir (OS, Base de données, Sécurité, App). Ex: AWS EC2.
- PaaS (Platform as a Service) : On vous loue un environnement d'exécution (NodeJS, Python). Vous n'apportez que votre code, la machine sous-jacente est gérée pour vous. Ex: Heroku, AWS Elastic Beanstalk.
- SaaS (Software as a Service) : Le logiciel est clé en main pour l'utilisateur final. Ex: Gmail, Office 365.
AWS est avant tout le leader mondial du IaaS. C'est à vous (le DevOps) d'assembler ces briques brutes tel un jeu de Lego pour construire votre architecture sur-mesure.
🚦 Analogie : La Ville Informatique à Louer
Déployer sur AWS, c'est comme construire une entreprise dans une ville flambant neuve :
- Le bâtiment lui-même (l'ordinateur physique) est fourni par le maire (AWS).
- Vous louez des employés à l'heure (Compute : EC2) ou à la seconde (Serverless : Lambda).
- Vous stockez vos archives dans un entrepôt infini (Stockage Objet : S3).
- Un système postal vous relie au monde extérieur (Réseau : VPC & Internet Gateway).
- Vous ne gérez jamais le chauffage ni l'électricité du bâtiment (le DataCenter), vous vous occupez juste de votre Logiciel.
📖 Les 5 Briques Vitales de l'Architecture Cloud
AWS propose plus de 200 services. Les DevOps en utilisent couramment une douzaine en production. Voici l'anatomie d'une application professionnelle type sur AWS :
1. S3 (Simple Storage Service)
Stockage infini de fichiers "objets" (Images, vidéos, backups). Vous le paierez au GB par mois.
2. EC2 (Compute) / EKS
Les machines virtuelles "à louer" (EC2) ou le cluster Kubernetes géré par AWS (EKS) pour exécuter vos conteneurs Docker.
3. RDS (Relational DB Service)
Votre PostgreSQL/MySQL géré par AWS (sauvegarde et patch de sécurité automatiques).
4. VPC (Virtual Private Cloud)
Votre réseau privé sécurisé. Les bases de données s'y trouvent pour ne jamais être exposées sur internet.
💡 Le saviez-vous ? Régions et Zones de Disponibilité (AZ)
Lorsque vous créez un serveur sur AWS, vous devez choisir géographiquement où il sera physiquement situé. AWS divise le monde en Régions (ex: `eu-west-3` pour Paris). Si le datacenter prend feu ? Pas de panique : chaque Région est subdivisée en plusieurs Availability Zones (AZ) (des datacenters isolés de 10 à 100km les uns des autres).
Règle d'or de l'architecte Cloud : Déployez toujours vos applications sur au moins 2 AZ simultanément (mode Multi-AZ) pour survivre au crash d'un datacenter entier.
🔀 A. Workflow Complet : Du Code à l'Utilisateur Final
Comment ça marche ?
- 1. Le développeur fait un `git push` sur GitHub.
- 2. GitHub Actions lance les tests unitaires via (NodeJS/Python).
- 3. Build : Il crée l'image Docker de la nouvelle version de l'application.
- 4. Push : L'image est "uploadée" sur le registre privé sécurisé d'AWS (nommé **ECR** - Elastic Container Registry).
- 5. Deploy : GitHub Actions envoie une commande à l'API AWS (ou à ArgoCD) pour mettre à jour le cluster Kubernetes (**EKS**) avec la nouvelle image conteneurisée.
name: Deploy to Amazon EKS
on:
push:
branches: [ "main" ]
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
# Configurer les credentials AWS temporaires
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v2
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_KEY }}
aws-region: eu-west-3 # Paris
# L'image Docker est uploadée sur AWS ECR
- name: Build, tag, and push image to ECR
run: |
docker build -t my-app .
docker tag my-app:latest 12345.dkr.ecr.eu-west-3.amazonaws.com/my-app:latest
docker push 12345.dkr.ecr.eu-west-3.amazonaws.com/my-app:latest
# K8s est mis à jour
- name: Update kube config & Deploy
run: |
aws eks update-kubeconfig --name my-cluster
kubectl set image deployment/my-app my-app=12345...:latest🏗️ B. Déployer l'Infrastructure elle-même (IaC)
🚜 Les Ops utilisent Terraform / AWS CDK
Le code remplace la souris.
Dans un contexte professionnel, on ne se connecte jamais sur l'interface web d'AWS pour cliquer sur "Créer une Base de données". C'est lent, l'erreur humaine est garantie, et ce n'est pas réplicable.
L'équipe Ops écrit du code Terraform ou AWS CDK. En une commande `terraform apply`, AWS crée 10 serveurs, 2 Load Balancers et la BDD PostgreSQL en moins de 3 minutes. Tout est versionné sur Git.
🛑 Le Danger du FinOps
- Le Problème : Si chaque développeur peut lancer des serveurs avec du code, la facture peut exploser. Un Cloud paresseusement optimisé coûte des milliers d'euros (Serveurs "zombies" allumés la nuit).
- Le Rôle FinOps (Finance Ops) :
Monitorer au centime près les coûts AWS.
- Taguer les ressources (CostCenter=TeamA).
- Supprimer/Automatiser la coupure des environnements de dev à 19h le soir et les week-ends.
- Acheter des serveurs aux enchères AWS (Spot Instances) -90% moins chers pour gérer les pics éphémères de K8s.
⚠️ Rappel Sécurité : Le Modèle de Responsabilité Partagée
On pense souvent à tort que "Le Cloud, c'est automatiquement sécurisé". C'est faux. AWS pratique le modèle de responsabilité partagée :
🛡️ AWS sécurise *LE* Cloud : Les murs du datacenter, les caméras, les câbles réseau, les serveurs physiques, la couche hyperviseur.
🔐 Le Client sécurise *CE QUI EST DANS LE* Cloud : L'OS (Mises à jour Windows/Linux), le pare-feu logiciel, l'authentification (IAM), le chiffrement des données (au repos et en transit).
Si vous laissez votre base de données ouverte à internet avec le mot de passe "admin", AWS n'interviendra pas. Le piratage est 100% de votre responsabilité.
💡 Concept Avancé : Vitesse mondiale avec Route 53 et CloudFront
Déployer l'application à Paris (`eu-west-3`), c'est bien. Mais que se passe-t-il pour un utilisateur au Japon ? La requête mettra 300 millisecondes aller-retour. L'application paraîtra extrêmement lente.
Pour résoudre ce problème physique, on utilise le combo de distribution mondiale :
1. AWS Route 53 : Le service DNS d'Amazon. Il peut faire un routage "basé sur la géolocalisation" (envoyer les Européens sur le serveur de Paris, et les Asiatiques sur un serveur à Tokyo).
2. Amazon CloudFront (CDN) : Réseau de diffusion de contenu. AWS met en cache vos assets statiques (images, CSS, JS, vidéos JS) sur des centaines de serveurs relais ("Edge Locations") répartis dans le monde entier. Le Japonais téléchargera donc les images depuis un serveur à Tokyo (latence: 10ms), ce qui retire une charge monumentale de votre serveur parisien.
Scalabilité : Load Balancer (ELB) et Auto Scaling (ASG)
La force majeure d'AWS, c'est l'élasticité. Le Elastic Load Balancer (ELB) est le répartiteur de trafic placé en façade (sur internet). Il distribue vos milliers de visiteurs entre vos petits serveurs EC2 ou pods Kubernetes. Si le CPU de vos serveurs dépasse 70%, un Auto Scaling Group demande automatiquement à AWS de démarrer 5 nouveaux serveurs. Dès que le traffic chute la nuit, il les éteint. Vous ne payez que le nombre idéal de serveurs requis en temps réel.