Bien architecturer sur AWS : performance, haute disponibilité, coûts maîtrisés… et IA

Voici un retour d'expérience concret sur les briques AWS que nous mettons réellement en production, les arbitrages qui les justifient, et — c'est là que se joue la valeur — la manière dont on les exploite au quotidien : automatisation de la remédiation, ChatOps, et diagnostic d'incident assisté par l'IA. On part des fondations (CDN, base de données, répartition de charge, coûts), puis on monte vers l'IA générative et l'AIOps tels que nous les pratiquons chez VOID.

CloudFront est le CDN (Content Delivery Network) d'AWS. Il met en cache vos contenus sur un réseau mondial de points de présence (edge locations) au plus près des internautes. Concrètement, un visiteur à Casablanca, Paris ou Dakar récupère vos images, fichiers JS/CSS et pages mises en cache depuis le serveur le plus proche, pas depuis votre origine à l'autre bout de la planète.

Ce que CloudFront apporte vraiment :

Le revers du cache : invalider proprement

L'erreur miroir est tout aussi fréquente : mettre en cache ce qui ne devrait pas l'être. Une page personnalisée (panier, espace connecté), une réponse d'API ou un contenu fraîchement publié servi depuis l'edge, et l'utilisateur voit une version périmée — parfois celle d'un autre visiteur si la clé de cache ignore les cookies de session. La règle : ne cacher que ce qui est réellement public et stable, séparer les cache behaviors (statique long TTL vs. dynamique non caché), et varier la clé de cache sur les bons critères seulement.

Quand un contenu change, deux stratégies pour rafraîchir l'edge :

Côté Drupal, on évite l'invalidation manuelle : le module Purge couplé à un connecteur CloudFront émet automatiquement les invalidations quand un nœud est modifié, en s'appuyant sur les tags de cache de Drupal — l'éditeur publie, le CDN se met à jour seul. Côté Next.js, on s'appuie d'abord sur le versioning des assets, puis, pour les pages rendues, sur la revalidation (ISR / revalidatePath) ; une invalidation CloudFront ciblée n'intervient qu'en complément, déclenchée depuis le pipeline de déploiement.

Gérer soi-même une base de données en production — sauvegardes, patchs de sécurité, réplication, bascule en cas de panne — est un métier à temps plein. Amazon RDS (Relational Database Service) prend tout cela en charge pour PostgreSQL, MySQL, MariaDB, SQL Server et Oracle.

Les capacités qui changent la donne :

Pour des charges très variables, Aurora Serverless v2 pousse la logique plus loin en ajustant la capacité à la demande. Le bon réflexe : ne pas administrer une base sur EC2 « pour économiser » — le coût caché en temps d'ingénierie et en risque dépasse vite la différence de prix.

Un load balancer répartit le trafic entrant sur plusieurs instances, vérifie leur santé (health checks) et retire automatiquement celles qui ne répondent plus. C'est la pièce qui permet de survivre à la panne d'une instance — voire d'une zone entière — sans interruption de service.

Comment le trafic est réparti : round robin & alternatives

Une fois la cible choisie, reste à décider comment répartir les requêtes entre les instances saines d'un target group. C'est l'algorithme de routage :

Un mot sur les sticky sessions : l'ALB peut, via un cookie, renvoyer un même utilisateur toujours sur la même instance. C'est parfois nécessaire (état en mémoire), mais cela nuit à la répartition — mieux vaut rendre l'application stateless (session dans Redis/ElastiCache ou base) et laisser round robin / LOR équilibrer librement.

Couplé à un Auto Scaling Group, le load balancer permet d'ajouter ou retirer des instances selon la charge réelle. Deux raffinements font la différence en production : le predictive scaling (qui anticipe les montées en charge récurrentes à partir de l'historique) et les warm pools (instances pré-initialisées pour absorber un pic instantané sans subir le temps de démarrage). On paie la capacité quand on en a besoin, et on encaisse les pics sans sur-provisionner en permanence.

Le tarif On-Demand est flexible mais c'est le plus cher. Dès qu'une charge devient stable et prévisible, les Savings Plans permettent de s'engager sur un volume de consommation (exprimé en $/heure) pendant 1 ou 3 ans, en échange d'une remise pouvant atteindre ~72 %.

Au-delà des engagements, le FinOps se joue aussi sur l'architecture elle-même :

Les quatre briques précédentes ne tiennent que sur un socle solide — celui qu'on ne voit pas tant qu'il fonctionne :

Amazon Bedrock : l'IA managée, à l'usage

Amazon Bedrock donne accès, via une seule API, à des modèles de fondation de plusieurs éditeurs (Meta Llama, Mistral, Amazon Nova, Cohere, DeepSeek…) sans gérer la moindre GPU. On paie à l'usage (tokens), on change de modèle en une ligne, et les données ne servent pas à ré-entraîner les modèles. Quatre capacités sortent du lot pour des applications réelles :

SageMaker et le matériel : quand héberger ses propres modèles

Bedrock couvre la majorité des besoins. Mais dès qu'on veut fine-tuner un modèle sur un corpus propriétaire, servir un modèle open-source spécialisé ou traiter des volumes massifs, Amazon SageMaker prend le relais : entraînement, hébergement d'endpoints, MLOps. Côté matériel, AWS propose ses propres puces — Trainium pour l'entraînement, Inferentia2 pour l'inférence — souvent plus économiques que les GPU classiques (G5, P5) pour un débit donné. C'est aussi sur ce terrain que nous hébergeons des modèles open-weightcomme Qwen sur une infrastructure souveraine, lorsque les données ne doivent jamais quitter notre périmètre. La règle que nous appliquons : commencer en serverless/managé, ne provisionner du GPU dédié que lorsque le volume — ou la souveraineté — le justifie.

Une architecture RAG type sur AWS

Pour un assistant qui répond sur la documentation d'une entreprise, l'architecture que nous déployons ressemble à ceci — et elle s'appuie directement sur les briques du début d'article :

C'est ici que se joue la vraie différence en production. Une bonne architecture, c'est aussi celle qui évite à un ingénieur de se lever à 3 h du matin pour redémarrer un service. Voici, très concrètement, comment nous opérons AWS chez VOID.

ChatOps : AWS parle à Slack

Chaque signal qui compte — alarme CloudWatch, bascule RDS, échec de tâche ECS/Fargate, déploiement, dépassement de budget — est routé vers un canal Slack dédié, par un chemin simple et 100 % managé :

(AWS Chatbot est aujourd'hui intégré à Amazon Q Developer.) L'équipe voit l'incident là où elle travaille déjà, avec le contexte, et peut même lancer des commandes AWS approuvées directement depuis Slack — sans ouvrir la console. Exemple de règle EventBridge qui capte une tâche ECS qui s'arrête anormalement :

{
  "source": ["aws.ecs"],
  "detail-type": ["ECS Task State Change"],
  "detail": {
    "lastStatus": ["STOPPED"],
    "stoppedReason": [{ "anything-but": { "prefix": "Scaling activity" } }]
  }
}

SSM Agent : opérer les serveurs sans ouvrir de porte

Tout cela repose sur une brique discrète mais centrale : le SSM Agent, le composant d' AWS Systems Manager préinstallé sur les AMI Amazon Linux et Ubuntu récentes (et installable sur n'importe quelle instance EC2, voire sur des serveurs on-premise). Une fois l'agent enregistré, l'instance dialogue avec AWS en sortie uniquement — aucun port entrant à ouvrir, aucune clé SSH à distribuer. C'est ce qui débloque, en pratique :

Côté sécurité, l'agent n'a accès qu'à ce que son rôle IAM d'instance autorise (moindre privilège) — supprimer les accès SSH au profit de Session Manager réduit drastiquement la surface d'attaque.

Remédiation automatique : des runbooks en Python

Pour les pannes courantes et bien comprises, on ne réveille personne : l'alarme déclenche une fonction Lambda (Python / boto3) — ou un document SSM Automation — qui applique le correctif et notifie Slack. Redémarrer un service ECS bloqué, purger un disque saturé, recycler des connexions, invalider un cache CloudFront, forcer un failover : autant de gestes que la machine fait mieux et plus vite qu'un humain à moitié réveillé.

Règle d'or : on n'automatise que ce qu'on a diagnostiqué au moins une fois à la main. Les actions destructrices (suppression, restauration, scale down agressif) ne s'exécutent jamais seules — elles passent par une validation humaine dans Slack (bouton d'approbation), et tout est tracé dans CloudTrail.

Diagnostic assisté par l'IA — Qwen sur infra souveraine

Quand l'incident sort des cas connus, l'ingénieur garde le contrôle, mais il est épaulé. Une Lambda rassemble le contexte — extrait de logs (CloudWatch Logs Insights), derniers déploiements, métriques anormales — et l'envoie à Qwen, que nous hébergeons sur notre infrastructure souveraine (modèle open-weight servi via vLLM, données qui restent dans notre périmètre). Qwen renvoie une hypothèse de cause racine et des actions concrètes, postées directement dans le canal de l'incident. L'ingénieur garde la décision, mais démarre avec l'essentiel du diagnostic déjà débroussaillé — ce qui fait chuter le MTTR(temps moyen de résolution).

Ce trio — ChatOps + remédiation automatique + diagnostic IA — transforme l'exploitation : moins d'astreintes subies, un MTTR qui chute, et une connaissance des incidents qui se capitalise (chaque runbook ajouté est un réveil nocturne en moins).

Sur une plateforme web typique que nous opérons, le flux ressemble à ceci :

Résultat : une architecture résiliente (tolérante à la panne d'une zone), performante (latence faible grâce au edge), intelligente (IA intégrée proprement) et économiquement maîtrisée (engagement sur la base, élasticité sur les pics).

Questions fréquentes