Concevoir une architecture AWS 3-tiers hautement disponible et sécurisée

Une application peut fonctionner parfaitement sur une seule instance EC2. C'est meme souvent comme cela que commencent les projets : une VPC, une VM, quelques règles réseau, une base de données et l'application est en ligne. Le problème n'apparait généralement pas le premier jour.

Il apparait lorsqu'une instance tombe pendant une période de forte activité. Lorsqu'une mise à jour rend le backend indisponible. Lorsqu'un pic de trafic arrive plus vite que prévu ou encore lorsqu'une indisponibilité d'une Availability Zone rappelle brutalement que « hébergé sur AWS » ne signifie pas automatiquement « hautement disponible ».

Pour cet article, je suis parti d'un scénario assez classique : une application web exposée sur internet, avec un backend et une base PostgresSQL. Mais je me suis imposé une contrainte supplémentaire : chaque choix devrait pouvoir etre justifié comme s'il devait passer une vraie revue d'architecture.

Le point de départ

Le besoin fonctionnel tient en trois lignes :

Je veux que l'application soit accessible en HTTPS, mais je ne veux pas que ses instances soient publiques. Je veux que la base PostgreSQL soit inaccessible depuis internet. Je veux au moins deux zones de disponibilité. Je veux pouvoir remplacer automatiquement une instance qui ne répond plus et absorder une hausse raisonnable de trafic. Je veux aussi que l'infrastructure soit reproductible.

Pour ce scénario, je reste volontairement sur EC2 plutôt que sur ECS ou EKS. Ce n'est pas parce qu'EC2 serait « meilleur ». C'est parce que cette architecture permet de voir très clairement les mécanismes que je veux étudier : load balancing, health checks, AutoScaling, routage et haute disponibilité. Si le workload était conteneurisé ou si l'entreprise disposait d'une plateforme Kubernetes mature, la décision pourrait être différente.