Projet Pratique : Déploiement d'une Application Web Complète et Scalable sur AWS

Introduction

Bienvenue à cette leçon pratique, où nous allons concrétiser nos connaissances sur AWS en déployant une application web complète, robuste et surtout scalable. Dans le cadre de notre cours "Maîtriser le Développement Web sur AWS : Déploiement, Scalabilité et Services Cloud", ce projet nous permettra de naviguer à travers les services clés d'Amazon Web Services pour architecturer une solution de production.

L'objectif est de comprendre comment assembler plusieurs briques AWS (calcul, stockage, bases de données, réseau, distribution de contenu) pour qu'elles fonctionnent en harmonie, offrant une expérience utilisateur fluide et une résilience face à des charges variables. Nous ne nous contenterons pas de "mettre en ligne" une application, mais nous construirons une architecture capable de grandir avec son succès, de résister aux pannes et de délivrer du contenu rapidement partout dans le monde.

À la fin de cette leçon, vous aurez non seulement les bases théoriques mais aussi une feuille de route pratique pour déployer vos propres applications web sur AWS en suivant les meilleures pratiques de l'industrie.

1. Comprendre l'Architecture Cible : Une Application Web Scalable

Avant de plonger dans les configurations, il est crucial de visualiser l'architecture que nous visons. Une application web moderne et scalable est généralement décomposée en plusieurs couches, chacune gérée par un service AWS adapté.

1.1. Les Composants Clés de notre Architecture

Frontend Statique (SPA/SSR) : Les fichiers de votre interface utilisateur (HTML, CSS, JavaScript, images) sont servis de manière optimisée.
Backend API : La logique métier de l'application, exposée via des API RESTful ou GraphQL. Elle doit être capable de gérer un nombre variable de requêtes.
Base de Données : Le cœur persistant de notre application, stockant toutes les données essentielles.
Distribution de Contenu (CDN) : Pour servir le frontend et d'autres assets rapidement aux utilisateurs du monde entier.
Mise en réseau sécurisée : Un environnement isolé et contrôlé pour nos ressources.
Gestion des noms de domaine : Pour rendre notre application accessible via une URL personnalisée.

1.2. Mappage aux Services AWS

Voici comment les composants s'alignent avec les services AWS que nous allons utiliser :

Frontend Statique : Amazon S3 (pour le stockage) + Amazon CloudFront (pour la distribution CDN).
Backend API : Amazon EC2 (instances de calcul) + Elastic Load Balancing (ALB) (pour la répartition de charge) + Auto Scaling Group (ASG) (pour la scalabilité automatique).
Base de Données : Amazon RDS (Relational Database Service), généralement PostgreSQL ou MySQL.
Mise en réseau sécurisée : Amazon VPC (Virtual Private Cloud) + Security Groups.
Gestion des noms de domaine : Amazon Route 53.
Gestion des identités et accès : AWS IAM (Identity and Access Management).
Surveillance et journalisation : Amazon CloudWatch.

Cette architecture est un exemple classique de déploiement "production-ready" sur AWS.

Diagramme simplifié d'architecture AWS Note : Le diagramme ci-dessus est une illustration générale. Notre architecture sera plus spécifique avec ALB, ASG, RDS, CloudFront, etc.

2. Prérequis pour ce Projet Pratique

Pour suivre cette leçon, vous aurez besoin de :

Un compte AWS actif avec les permissions nécessaires (administrateur ou un rôle avec des droits suffisants pour créer les ressources mentionnées).
Des connaissances de base en ligne de commande (CLI) et git.
Une application web prête à être déployée :
- Un frontend statique (ex: React, Vue, Angular) compilé en fichiers HTML, CSS, JS.
- Un backend (ex: Node.js Express, Python Flask/Django, PHP Laravel) avec une API RESTful et une configuration pour se connecter à une base de données.
- (Optionnel mais recommandé) Un dépôt git pour votre code.

Pour les besoins de cette leçon, nous utiliserons un backend Node.js avec une base de données PostgreSQL comme exemples, mais les principes restent les mêmes pour d'autres technologies.

3. Étape 1 : Préparation de l'Application

Avant de déployer sur AWS, votre application doit être prête.

3.1. Préparation du Frontend Statique

La plupart des frameworks frontend modernes (React, Vue, Angular) ont une commande build qui génère un dossier optimisé de fichiers statiques.

Exemple avec React :
```
npm run build
# ou
yarn build
```
Cette commande créera un dossier build/ (ou dist/) contenant les fichiers HTML, CSS, JavaScript et les assets (images, etc.) minifiés et optimisés. C'est ce dossier que nous allons déployer sur S3.

3.2. Préparation du Backend (Exemple Node.js)

Votre application backend doit être configurée pour écouter sur un port spécifique (par exemple, 3000 ou 8080) et potentiellement utiliser des variables d'environnement pour sa configuration (ex: connexion à la base de données).

Voici un exemple simple de serveur Node.js/Express qui écoute sur le port 3000 et répond à une route /api/hello :

// server.js
const express = require('express');
const app = express();
const port = process.env.PORT || 3000;

app.get('/api/hello', (req, res) => {
  res.json({ message: 'Hello from the backend API!' });
});

app.listen(port, () => {
  console.log(`Backend API listening on port ${port}`);
});

Explication du code : Ce script Express minimaliste crée une application web qui répond à une requête GET sur /api/hello avec un message JSON. Il écoute sur le port défini par la variable d'environnement PORT ou par défaut sur le port 3000. L'utilisation de process.env.PORT est cruciale pour la flexibilité de déploiement, notamment avec les services comme Elastic Load Balancing ou ECS qui peuvent attribuer des ports dynamiques.

Assurez-vous que votre package.json a un script start :

// package.json
{
  "name": "my-backend",
  "version": "1.0.0",
  "description": "My scalable backend API",
  "main": "server.js",
  "scripts": {
    "start": "node server.js",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "dependencies": {
    "express": "^4.18.2"
  }
}

4. Étape 2 : Déploiement du Frontend Statique avec S3 et CloudFront

Le déploiement du frontend sur S3 et CloudFront est la méthode standard pour les Single Page Applications (SPA) ou les sites web statiques.

4.1. Création et Configuration du Bucket S3

Créez un bucket S3 :
- Nom du bucket : votre-nom-domaine-frontend (ex: monapp-frontend.com). Le nom doit être globalement unique.
- Région : Choisissez une région proche de vos utilisateurs (ou de vous-même pour les tests).
- Désactivez "Block all public access" (vous devrez confirmer). Nous rendrons le contenu accessible publiquement via CloudFront, mais pour S3 directement, il faut ajuster les permissions.
- Laissez les autres options par défaut pour l'instant.
Activez l'hébergement de site web statique :
- Dans les propriétés du bucket, trouvez "Static website hosting" et cliquez sur "Edit".
- Sélectionnez "Enable".
- "Index document" : index.html
- "Error document" : index.html (pour permettre aux SPA de gérer les routes côté client).
- Notez le "Endpoint du site web du bucket" – c'est l'URL S3 direct.
Définissez une politique de bucket : Pour que S3 puisse servir des fichiers, nous devons définir une politique pour rendre les objets lisibles publiquement.
- Dans les permissions du bucket, cliquez sur "Bucket Policy" et "Edit".
- Ajoutez la politique suivante, en remplaçant ARN_DE_VOTRE_BUCKET par l'ARN de votre bucket (ex: arn:aws:s3:::monapp-frontend.com/* pour la ressource) :
```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": "ARN_DE_VOTRE_BUCKET/*"
        }
    ]
}
```
Explication : Cette politique autorise n'importe quel utilisateur ("Principal": "*") à effectuer l'action s3:GetObject (lire un objet) sur toutes les ressources (/*) de votre bucket.
Téléchargez les fichiers de votre frontend :
- Dans l'onglet "Objects" de votre bucket, cliquez sur "Upload".
- Téléchargez tout le contenu de votre dossier build/ (ou dist/). Assurez-vous que les sous-dossiers sont également téléchargés.

Vous devriez maintenant pouvoir accéder à votre application via l'URL "Endpoint du site web du bucket" que vous avez notée.

4.2. Configuration de CloudFront pour la Distribution CDN et SSL

CloudFront est un réseau de diffusion de contenu (CDN) qui met en cache votre contenu statique aux bords du réseau AWS, réduisant la latence et améliorant les performances. Il est également essentiel pour la gestion du SSL (HTTPS).

Créez une distribution CloudFront :
- Allez au service CloudFront et cliquez sur "Create a CloudFront distribution".
- Origin domain : Sélectionnez l'endpoint de site web statique de votre bucket S3 (pas le S3 REST API endpoint direct !). Il devrait apparaître dans la liste déroulante.
- Viewer protocol policy : Redirect HTTP to HTTPS (toujours utiliser HTTPS).
- Allowed HTTP methods : GET, HEAD, OPTIONS.
- Cache policy : CachingOptimized (par défaut, pour la plupart des cas).
- Alternate domain names (CNAMEs) : Entrez votre nom de domaine personnalisé (ex: www.monapp.com ou monapp.com).
- SSL Certificate : Sélectionnez un certificat SSL existant d'AWS Certificate Manager (ACM) pour votre domaine. Si vous n'en avez pas, vous devrez en demander un pour votre domaine via ACM (le processus est simple et gratuit).
- Default Root Object : index.html.
- Laissez les autres options par défaut pour l'instant. Cliquez sur "Create distribution".
Attendez la propagation : La création et la propagation d'une distribution CloudFront peuvent prendre 10 à 20 minutes. Une fois prête, vous obtiendrez un "Domain name" (ex: d12345abcdef.cloudfront.net).
Configurez Route 53 (Étape 6) : Pour utiliser votre nom de domaine personnalisé, vous devrez créer un enregistrement CNAME ou Alias dans Route 53 pointant vers le "Domain name" de votre distribution CloudFront. Nous verrons cela plus tard.

5. Étape 3 : Mise en Place du Backend Scalable avec EC2, ALB et Auto Scaling

Cette section est le cœur de notre application scalable. Nous allons construire une architecture backend qui peut automatiquement s'adapter à la charge.

5.1. Configuration Réseau (VPC, Subnets, Security Groups)

C'est la base de votre infrastructure sécurisée. Nous partons du principe que vous avez déjà un VPC par défaut ou un VPC personnalisé avec au moins deux subnets publics et deux subnets privés dans des zones de disponibilité différentes.

VPC (Virtual Private Cloud) :
- Utilisez votre VPC par défaut ou créez-en un nouveau avec un CIDR Block (ex: 10.0.0.0/16).
Subnets :
- Créez au moins deux subnets publics (pour l'ALB) et deux subnets privés (pour les instances EC2 du backend et RDS) dans différentes zones de disponibilité. Les subnets privés n'ont pas d'accès direct à Internet, ils doivent passer par un NAT Gateway dans un subnet public pour les requêtes sortantes.
Security Groups (Groupes de sécurité) :
- Security Group pour l'ALB (ex: sg-alb) : Autorisez le trafic entrant sur les ports 80 (HTTP) et 443 (HTTPS) de n'importe quelle source (0.0.0.0/0).
- Security Group pour les instances EC2 du Backend (ex: sg-backend) : Autorisez le trafic entrant sur le port de votre application backend (ex: 3000 pour Node.js) uniquement depuis le Security Group de l'ALB (sg-alb). Cela garantit que seules les requêtes provenant de votre équilibreur de charge peuvent atteindre vos instances.
- Security Group pour RDS (ex: sg-rds) : Autorisez le trafic entrant sur le port de votre base de données (ex: 5432 pour PostgreSQL) uniquement depuis le Security Group de vos instances EC2 du backend (sg-backend).

5.2. Lancement d'une Instance EC2 et Création d'une AMI Personnalisée

Nous allons configurer une instance EC2 "maître", y installer notre application, puis en créer une image (AMI) qui sera utilisée par l'Auto Scaling Group.

Lancez une instance EC2 :

Type d'AMI : Amazon Linux 2 AMI (ou Ubuntu, selon vos préférences).
Type d'instance : t2.micro (suffisant pour le test).
VPC : Votre VPC.
Subnet : Un de vos subnets privés (pour les tests initiaux, un public peut être plus simple pour SSH, mais la bonne pratique est privé).
Security Group : sg-backend (assurez-vous d'ajouter temporairement une règle SSH port 22 depuis votre IP si vous utilisez un subnet privé, ou depuis 0.0.0.0/0 pour un public, mais retirez-le après la configuration).
User data : C'est ici que nous allons automatiser l'installation de Node.js et Nginx, et le lancement de notre application.

#!/bin/bash
yum update -y

# Installer Node.js 18 (ou la version de votre choix)
curl -fsSL https://rpm.nodesource.com/setup_18.x | sudo bash -
yum install -y nodejs

# Installer Nginx (en tant que reverse proxy)
amazon-linux-extras install nginx1 -y

# Créer un répertoire pour l'application
mkdir /app
cd /app

# Cloner l'application depuis votre dépôt Git (remplacez par votre URL)
# Pour un déploiement plus sécurisé, utiliser des clés SSH ou IAM Roles pour accéder au dépôt privé
git clone https://github.com/votre_utilisateur/votre_repo_backend.git .

# Installer les dépendances de l'application
npm install

# Configurer Nginx comme reverse proxy
cat <<EOF > /etc/nginx/conf.d/app.conf
server {
    listen 80;
    server_name localhost;

    location / {
        proxy_pass http://localhost:3000; # Le port de votre application Node.js
        proxy_http_version 1.1;
        proxy_set_header Upgrade \$http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host \$host;
        proxy_cache_bypass \$http_upgrade;
    }
}
EOF

# Démarrer Nginx et le configurer pour démarrer au boot
systemctl start nginx
systemctl enable nginx

# Installer PM2 pour gérer le processus Node.js
npm install pm2 -g
pm2 start server.js --name "my-backend-app"
pm2 startup systemd # Configure PM2 pour démarrer avec le système
pm2 save # Sauvegarder la liste des processus PM2

Explication du script User Data : Ce script shell est exécuté au démarrage de l'instance. Il met à jour le système, installe Node.js et Nginx, clone votre application backend depuis Git, installe ses dépendances, configure Nginx pour agir comme un reverse proxy vers votre application Node.js (qui écoute sur le port 3000), démarre Nginx, et enfin utilise PM2 pour démarrer et gérer votre application Node.js de manière persistante. PM2 est un gestionnaire de processus pour Node.js qui maintient votre application en cours d'exécution et gère les redémarrages en cas de crash.

Vérifiez l'instance :
- Une fois l'instance lancée, connectez-vous en SSH (si possible) et vérifiez que votre application Node.js est en cours d'exécution (ex: pm2 list) et que Nginx est actif (sudo systemctl status nginx).
Créez une AMI (Amazon Machine Image) :
- Lorsque votre instance est correctement configurée et que l'application tourne, arrêtez-la (sans la terminer).
- Sélectionnez l'instance, puis Actions -> Image and templates -> Create image.
- Donnez un nom significatif (ex: monapp-backend-v1).
- Cette AMI sera une image exacte de votre instance configurée, prête à être lancée par l'Auto Scaling Group.

5.3. Configuration de l'Application Load Balancer (ALB)

L'ALB est un point d'entrée pour votre backend, distribuant le trafic sur plusieurs instances EC2.

Créez un Load Balancer :
- Type : Application Load Balancer.
- Nom : monapp-alb.
- Schéma : Internet-facing (pour les applications publiques) ou Internal (pour les backends privés).
- VPC : Votre VPC.
- Mappage : Sélectionnez au moins deux subnets publics dans des zones de disponibilité différentes.
- Security Group : sg-alb (créé précédemment).
- Listeners :
  - HTTP:80 (action : Redirect to HTTPS:443).
  - HTTPS:443 (action : Forward to a new target group). Sélectionnez votre certificat SSL ACM.
Créez un Target Group :
- Type de cible : Instances.
- Nom : monapp-backend-tg.
- Protocole : HTTP ou HTTPS.
- Port : 80 (le port Nginx sur votre EC2).
- VPC : Votre VPC.
- Health checks :
  - Protocole : HTTP.
  - Path : /api/hello (ou une autre route simple de votre API qui répond avec un code 200).
  - Seuil sain : 2.
  - Seuil malsain : 2.
  - Intervalle : 10 secondes.
Le Target Group est ce vers quoi l'ALB envoie le trafic. L'Auto Scaling Group enregistrera automatiquement les instances dans ce Target Group.

5.4. Configuration de l'Auto Scaling Group (ASG)

L'ASG gère automatiquement le lancement et l'arrêt d'instances EC2 en fonction de la demande.

Créez un Launch Template :
- Basé sur l'AMI que vous avez créée.
- Nom : monapp-backend-launch-template.
- AMI : Sélectionnez votre AMI personnalisée (monapp-backend-v1).
- Instance type : t2.micro (ou supérieur).
- Key pair : Sélectionnez votre paire de clés pour l'accès SSH (si besoin).
- Networking :
  - VPC : Votre VPC.
  - Security Groups : sg-backend.
  - Advanced details -> IAM instance profile : (Optionnel) Si votre application a besoin d'accéder à d'autres services AWS (S3, DynamoDB, etc.), attachez un rôle IAM avec les permissions nécessaires.
- User data : Ce champ peut être laissé vide si votre AMI est déjà configurée ou si le script User Data est inclus dans l'AMI elle-même. Si vous avez utilisé le script User Data pour créer l'AMI, il n'est pas nécessaire de le répéter ici, car l'AMI contient déjà l'état post-exécution de ce script.
Créez un Auto Scaling Group :
- Nom : monapp-backend-asg.
- Launch template : Sélectionnez monapp-backend-launch-template.
- VPC : Votre VPC.
- Subnets : Sélectionnez au moins deux subnets privés dans des zones de disponibilité différentes. C'est là que vos instances seront lancées.
- Load balancing :
  - Attachez-le au Target Group existant : monapp-backend-tg.
- Group size :
  - Desired capacity : 1 (nombre d'instances que vous voulez en permanence).
  - Minimum capacity : 1 (ne descendra jamais en dessous de ce nombre).
  - Maximum capacity : 3 (ne dépassera jamais ce nombre).
- Scaling policies :
  - Nom : ScaleOutPolicy.
  - Type de politique : Target tracking scaling policy.
  - Métriques : CPU utilization.
  - Valeur cible : 60 (lorsque l'utilisation CPU moyenne des instances dépasse 60%, lancez de nouvelles instances).
  - Nom : ScaleInPolicy.
  - Type de politique : Target tracking scaling policy.
  - Métriques : CPU utilization.
  - Valeur cible : 30 (lorsque l'utilisation CPU moyenne descend en dessous de 30%, arrêtez des instances).
- Notifications (optionnel) : Pour recevoir des alertes SNS sur les événements de l'ASG.
- Tags : Ajoutez des tags utiles (ex: Name: monapp-backend).

Votre backend est maintenant configuré pour être scalable. L'ALB distribuera le trafic, et l'ASG ajustera le nombre d'instances EC2 en fonction de la charge.

6. Étape 4 : Base de Données Managée avec RDS

RDS simplifie considérablement la gestion des bases de données relationnelles en automatisant les tâches d'administration (sauvegarde, patching, mise à l'échelle).

Créez une instance de base de données RDS :
- Moteur : PostgreSQL (ou MySQL, MariaDB, etc.).
- Version : Choisissez la dernière version stable.
- Modèle de template : Free tier pour les tests, Production pour les environnements réels.
- Identifiant d'instance DB : monapp-db.
- Master username : admin.
- Master password : Choisissez un mot de passe fort.
- Taille d'instance : db.t2.micro (pour le tier gratuit ou les tests).
- Stockage : 20 GiB (pour le tier gratuit).
- Availability & Durability (Multi-AZ) : Pour la production, choisissez Create a standby instance pour une haute disponibilité. Pour les tests, Do not create a standby instance.
- VPC : Votre VPC.
- Subnet group : Créez un nouveau DB Subnet Group en sélectionnant au moins deux de vos subnets privés.
- Publicly accessible : No (votre base de données ne doit pas être accessible directement depuis Internet).
- VPC Security Group : Sélectionnez sg-rds (créé précédemment).
- Port de base de données : 5432 (pour PostgreSQL).
- Authentification de base de données : Password authentication.
- Autres options : Laissez par défaut.
Configuration des variables d'environnement pour le backend :
- Une fois l'instance RDS créée (cela peut prendre quelques minutes), récupérez son "Endpoint" (URL de connexion) depuis la console RDS.
- Votre application backend devra utiliser cet endpoint, le nom d'utilisateur, le mot de passe et le nom de la base de données. Ces informations sont généralement passées via des variables d'environnement (ex: DB_HOST, DB_USER, DB_PASSWORD, DB_NAME).
- Dans un environnement de production, ces variables d'environnement peuvent être gérées via AWS Secrets Manager ou des fichiers de configuration injectés via des processus de CI/CD. Pour notre exemple avec l'AMI, vous pourriez les ajouter à votre script de démarrage ou les configurer dans le launch template (attention aux données sensibles non chiffrées).

7. Étape 5 : Gestion des Noms de Domaine avec Route 53

Route 53 est le service DNS (Domain Name System) d'AWS, permettant de gérer vos noms de domaine.

Enregistrez ou transférez votre domaine :
- Si vous n'avez pas de domaine, vous pouvez l'enregistrer directement via Route 53.
- Si vous avez un domaine existant, vous pouvez le transférer vers Route 53 ou simplement mettre à jour les serveurs de noms de votre registraire actuel pour qu'ils pointent vers les serveurs de noms de Route 53 (disponibles après la création d'une Hosted Zone).
Créez une Hosted Zone :
- Dans la console Route 53, cliquez sur "Hosted zones" et "Create hosted zone".
- "Domain name" : votre-nom-domaine.com.
- Type : Public hosted zone.
Créez des enregistrements DNS :
- Pour le Frontend (CloudFront) :
  - Créez un enregistrement de type A (Alias) pour votre domaine racine (votre-nom-domaine.com) et/ou www.votre-nom-domaine.com.
  - Alias : Yes.
  - "Route traffic to" : Alias to CloudFront distribution et sélectionnez votre distribution CloudFront.
- Pour le Backend (ALB) :
  - Créez un enregistrement de type A (Alias) pour un sous-domaine de votre API (ex: api.votre-nom-domaine.com).
  - Alias : Yes.
  - "Route traffic to" : Alias to Application and Classic Load Balancer et sélectionnez votre ALB.

Une fois ces enregistrements propagés (cela peut prendre quelques minutes à quelques heures), votre application sera accessible via vos noms de domaine personnalisés sécurisés par HTTPS.

8. Étape 6 : Surveillance et Journalisation avec CloudWatch

CloudWatch est le service de surveillance et de gestion des journaux d'AWS. Il est crucial pour observer la santé et les performances de votre application.

Métriques : CloudWatch collecte automatiquement des métriques pour la plupart des services AWS que nous avons utilisés (EC2 CPU utilization, ALB request count, RDS CPU utilization, S3 bucket size, CloudFront requests). Vous pouvez créer des tableaux de bord personnalisés pour visualiser ces métriques importantes.
Alarmes : Vous pouvez définir des alarmes CloudWatch pour être averti (via SNS) lorsque certaines métriques dépassent des seuils (ex: CPU > 80% pendant 5 minutes, erreur 5xx sur l'ALB).
Logs : Configurez vos instances EC2 pour envoyer leurs logs (applications, Nginx, système) à CloudWatch Logs. Cela centralise vos logs et facilite leur analyse et leur recherche. Pour notre exemple Node.js, pm2 peut être configuré pour envoyer ses logs à CloudWatch Logs, ou vous pouvez utiliser le CloudWatch Agent.

Conclusion et Prochaines Étapes

Félicitations ! Vous avez déployé une application web complète et scalable sur AWS en utilisant une architecture robuste. Nous avons couvert :

L'hébergement statique performant : S3 et CloudFront pour votre frontend.
Un backend résilient et auto-scalable : EC2, ALB et Auto Scaling Group pour votre API.
Une base de données managée et sécurisée : RDS pour la persistance des données.
Une mise en réseau sécurisée et contrôlée : VPC et Security Groups.
La gestion des noms de domaine : Route 53.
Les bases de la surveillance : CloudWatch.

Cette architecture vous offre une base solide pour la plupart des applications web. Cependant, le monde du cloud est en constante évolution, et il existe de nombreuses voies pour optimiser et étendre votre déploiement :

Intégration CI/CD : Automatisez le déploiement de votre code en utilisant des services comme AWS CodePipeline, CodeBuild, CodeDeploy ou des outils tiers comme GitLab CI/CD, GitHub Actions.
Conteneurisation : Explorez Amazon ECS (Elastic Container Service) ou Amazon EKS (Elastic Kubernetes Service) avec AWS Fargate pour une gestion encore plus simple de vos conteneurs Docker, remplaçant les instances EC2 individuelles pour votre backend.
Serverless : Pour des composants spécifiques de votre backend, envisagez AWS Lambda avec API Gateway pour une architecture "sans serveur", réduisant les coûts opérationnels et la gestion des serveurs.
Base de données NoSQL : Pour certains besoins, Amazon DynamoDB (base de données NoSQL entièrement gérée) peut offrir des performances et une scalabilité supérieures pour des cas d'utilisation spécifiques.
Mise en cache : Améliorez les performances de votre backend en utilisant Amazon ElastiCache (Redis ou Memcached) pour stocker les données fréquemment accédées.
Sécurité avancée : Explorez AWS WAF (Web Application Firewall) pour protéger votre application contre les attaques web courantes, et AWS Shield pour la protection DDoS.

Continuez à explorer, à construire et à maîtriser les services AWS pour devenir un expert du déploiement cloud !