> ## Documentation Index
> Fetch the complete documentation index at: https://ai-kb.automationanywhere.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Architecture AWS EKS (Services et Infrastructure)

> Aperçu de l'architecture, descriptions des composants et flux de données pour l'infrastructure des services EKB sur AWS EKS.

Ce document fournit un aperçu complet de l'architecture AWS pour l'infrastructure des services EKB. L'architecture suit les modèles cloud-natifs avec les services gérés d'AWS, l'orchestration Kubernetes et la mise à l'échelle automatique.

***

# Aperçu de l'architecture AWS

L'architecture suit les modèles cloud-natifs avec les services gérés d'AWS, l'orchestration Kubernetes et la mise à l'échelle automatique.

***

## Diagramme d'architecture

```mermaid theme={null}
flowchart TD
    INTERNET[\"🌐 INTERNET\"]
 
    DNS[\"Fournisseur DNS\\n(Route 53 / Cloudflare / etc.)\\n──────────────────────────────\\n• app.your-domain — Web Frontend\\n• api.your-domain — FastAPI Backend\\n• automations.your-domain — Automator\\n• supabase.your-domain — Supabase Kong\\n• signoz.your-domain — SigNoz\"]
 
    ALB[\"APPLICATION LOAD BALANCER\\n──────────────────────────────\\n• Terminaison SSL via ACM\\n• Redirection HTTP → HTTPS\\n• Vérifications de santé et groupes cibles\\n• Routage par nom d'hôte/chemin\"]
 
    subgraph VPC[\"VPC\"]
        subgraph PUB[\"Sous-réseaux publics (3 AZs)\"]
            NAT[\"Passerelle NAT × 3\"]
        end
        subgraph PRIV[\"Sous-réseaux privés (3 AZs)\"]
            NODES[\"Nœuds de travail EKS\"]
        end
    end
 
    subgraph EKS[\"CLUSTER EKS\"]
        KARPENTER[\"KARPENTER — Approvisionnement dynamique des nœuds\\n──────────────────────────────\\n• Priorisation des instances Spot et consolidation\\n• Gestion des interruptions via SQS\\n• Classes de nœuds : général, calcul intensif, base de données\"]
        KEDA[\"KEDA — Mise à l'échelle automatique des pods basée sur les événements\\n──────────────────────────────\\n• Mise à l'échelle du seuil CPU / Mémoire\\n• Stabilisation rapide de la réduction d'échelle\"]
        PODS[\"PODS D'APPLICATION\\n──────────────────────────────\\n• Web Frontend (port 3000)\\n• FastAPI Backend (port 8001)\\n• Travailleurs Celery\\n• Automator (port 80)\\n• Services Supabase (Kong, Auth, Storage…)\\n• PostgreSQL Automator (port 5432)\"]
        SIGNOZ[\"OBSERVABILITÉ — SigNoz (optionnel)\\n──────────────────────────────\\n• Traçage distribué, métriques, journaux\\n• Agent k8s-infra pour les métriques du cluster\"]
    end
 
    subgraph DATA[\"COUCHE DE DONNÉES\"]
        REDIS[\"ELASTICACHE\\n(Redis)\\n──────────\\n• Chiffrement\\n• Multi-AZ\\n• Port 6379\"]
        MQ[\"AMAZON MQ\\n(RabbitMQ)\\n──────────\\n• File d'attente asynchrone\\n• AMQP/SSL\\n• Port 5671\"]
        SUPABASE[\"SUPABASE\\n(DB / Auth)\\n──────────\\nOption A : Cloud\\nOption B : Auto-hébergée\\nvia CNPG HA sur EKS\"]
    end
 
    INTERNET --> DNS
    DNS --> ALB
    ALB --> VPC
    PUB --> PRIV
    PRIV --> EKS
    EKS --> DATA
```

<Info>
  Supabase auto-hébergée utilise un cluster PostgreSQL HA géré par CloudNativePG (`ha-supabase-db`) avec regroupement PgBouncer, MinIO pour le stockage d'objets et la pile d'application Supabase complète déployée via `helm-deployment/supabase-kubernetes-ha`. Supabase Cloud est l'alternative si l'auto-hébergement n'est pas requis.
</Info>

***

## Composants clés

### 1. Couche réseau

#### Fournisseur DNS

* **Objectif :** Résolution des noms de domaine ; fonctionne avec n'importe quel fournisseur (Route 53, Cloudflare, etc.)
* **Domaines** (utilisez votre propre domaine, par ex. `example.com`) :
  * `app.example.com` — Web Frontend
  * `api.example.com` — FastAPI Backend
  * `automations.example.com` — Service Automator
  * `supabase.example.com` — Supabase Kong (auto-hébergée uniquement)
  * `signoz.example.com` — Observabilité SigNoz (optionnel)
* **Validation SSL :** Enregistrements CNAME requis pour la validation DNS d'ACM

#### Application Load Balancer (ALB)

* **Objectif :** Terminaison SSL, équilibrage de charge et routage basé sur le nom d'hôte
* **Fonctionnalités :**
  * Terminaison SSL/TLS avec les certificats ACM (caractère générique ou par service)
  * Redirection HTTP → HTTPS
  * Vérifications de santé pour tous les groupes cibles
* **Géré par :** Contrôleur AWS Load Balancer (graphique Helm dans `helm-deployment/infrastructure`)

#### VPC

* **CIDR :** Spécifique à l'environnement (par ex. `10.x.0.0/16`)
* **Zones de disponibilité :** 3 AZs dans la région choisie
* **Sous-réseaux :** 3 publics (Passerelles NAT) + 3 privés (nœuds EKS)
* **Sortant :** Passerelle NAT par AZ pour la sortie des nœuds

***

### 2. Couche de calcul

#### Cluster EKS

* **Version :** Kubernetes 1.33
* **Groupe de nœuds système :** Groupe de nœuds géré exécutant le contrôleur Karpenter (pas sur les nœuds gérés par Karpenter, selon les bonnes pratiques d'AWS)
* **Modules complémentaires :** Pilote CSI EBS, Contrôleur AWS Load Balancer, CoreDNS, kube-proxy

#### Karpenter — Approvisionnement dynamique des nœuds

* **Objectif :** Approvisionnement des nœuds juste à temps et optimisation des coûts
* **Classes de nœuds :**
  * **Usage général :** Instances Spot pour la plupart des charges de travail
  * **Calcul intensif :** Instances haute-CPU pour les tâches liées au CPU
  * **Mémoire intensive :** Instances optimisées pour la mémoire pour les grands ensembles de données
  * **Base de données :** Instances à la demande pour les charges de travail avec état/base de données
  * **GPU :** Instances GPU pour les charges de travail IA/ML (optionnel)
* **Fonctionnalités :** Priorisation des Spot, consolidation automatique, gestion des interruptions basée sur SQS

#### KEDA — Mise à l'échelle automatique des pods basée sur les événements Kubernetes

* **Objectif :** Mise à l'échelle horizontale des pods basée sur les métriques de ressources
* **Cibles :**

| Service             | Répliques | Seuil CPU | Seuil mémoire |
| ------------------- | --------- | --------- | ------------- |
| Web Frontend        | 2–8       | 60%       | 80%           |
| FastAPI Backend     | 2–10      | 70%       | 80%           |
| Travailleurs Celery | 2–8       | 70%       | 80%           |
| Automator           | 2–8       | 70%       | 80%           |

* **Réduction d'échelle :** Fenêtre de stabilisation de 30 s pour une réponse rapide

***

### 3. Services d'application

#### Web Frontend

* **Port :** 3000
* **Répliques :** 2–8 (gérées par KEDA)
* **Objectif :** Application React servant l'interface utilisateur

#### FastAPI Backend

* **Port :** 8001
* **Répliques :** 2–10 (gérées par KEDA)
* **Objectif :** Serveur API REST gérant la logique métier et l'accès aux données

#### Travailleurs Celery

* **Répliques :** 2–8 (gérées par KEDA)
* **Objectif :** Traitement des tâches en arrière-plan (mis en file d'attente via RabbitMQ)

#### Service Automator

* **Port :** 80
* **Répliques :** 2–8 (gérées par KEDA)
* **Objectif :** Automation des flux de travail et orchestration

#### Supabase Kong

* **Port :** 8000 (service de cluster interne)
* **Objectif :** Passerelle API pour tous les services Supabase
* **Routage :** Le trafic externe atteint Kong via l'entrée ALB définie dans `odin-services/main-ingress.yaml`

#### SigNoz (optionnel)

* **Espace de noms :** `monitoring`
* **Composants :** Plateforme SigNoz + agent DaemonSet k8s-infra
* **Objectif :** Traçage distribué, agrégation des métriques, gestion des journaux
* **Activé par :** `ENABLE_SIGNOZ=true`

***

### 4. Couche de données

#### ElastiCache Redis

* **Objectif :** Cache, stockage de session et courtier/backend de résultats Celery
* **Configuration :**
  * Type de nœud : configurable (par ex. `cache.t3.micro`)
  * Port : `6379`
  * Chiffrement au repos et en transit
  * Multi-AZ pour la haute disponibilité
* **Activé par :** `ENABLE_AWS_SERVICES=true`

#### Amazon MQ (RabbitMQ)

* **Objectif :** File d'attente de messages pour le traitement asynchrone des tâches
* **Configuration :**
  * Moteur : RabbitMQ
  * Ports : `5671` (AMQP/SSL), `15671` (Gestion/SSL)
  * Mode de déploiement : instance unique ou active/veille
* **Activé par :** `ENABLE_AWS_SERVICES=true`

#### Supabase — Option A : Cloud (géré)

* **Objectif :** PostgreSQL géré externe, Auth, Storage et Realtime
* **Connexion :** URL du projet Supabase et clé du rôle de service configurées dans `values/odin-services.yaml`

#### Supabase — Option B : Auto-hébergée sur EKS

* **Objectif :** Pile Supabase complète s'exécutant à l'intérieur du cluster
* **Composants :**
  * Opérateur CloudNativePG (`cnpg-system`) — gère le cycle de vie du cluster Postgres
  * Base de données Supabase HA (`ha-supabase-db`) — Ressource Cluster CloudNativePG avec regroupement PgBouncer
  * Application Supabase (`namespace supabase`) — Kong, Auth, Storage (MinIO), Meta, Rest, Realtime, Studio
* **Ordre de déploiement :** CloudNativePG → Base de données Supabase HA → Application Supabase
* **Activé par :** `ENABLE_CNPG=true`, `ENABLE_HA_SUPABASE_DB=true`, `ENABLE_SUPABASE=true`

#### PostgreSQL Automator

* **Objectif :** Base de données PostgreSQL locale pour le service Automator
* **Port :** 5432
* **Stockage :** Volume persistant EBS
* **Affinité des nœuds :** Nœuds dédiés à la base de données

***

### 5. Sécurité et IAM

#### Rôles IAM

| Rôle                                 | Objectif                                                 |
| ------------------------------------ | -------------------------------------------------------- |
| Rôle de cluster EKS                  | Permissions API au niveau du cluster                     |
| Rôle de groupe de nœuds              | Permissions des nœuds EC2 (ECR, SSM, réseau)             |
| Rôle du contrôleur Karpenter         | Approvisionnement EC2, file d'attente d'interruption SQS |
| Rôle du contrôleur AWS Load Balancer | Gestion d'ELBv2 et EC2                                   |
| Rôle du pilote CSI EBS               | Gestion du cycle de vie des volumes EBS                  |

Les noms de rôles suivent le modèle `<env-name>-<component>` et sont créés par le module EKS Terraform.

#### Groupes de sécurité

* **ALB :** Auto-créé par le contrôleur AWS Load Balancer (entrée 80/443)
* **Cluster EKS :** Communication nœud-à-nœud et pod
* **Redis :** Port 6379 uniquement depuis le CIDR VPC
* **RabbitMQ :** Ports 5671, 15671 uniquement depuis le CIDR VPC

#### SSL/TLS

* **Terminaison :** Niveau ALB (les pods voient HTTP en clair en interne)
* **Certificats :** Certificats ACM — soit par service, soit un caractère générique unique
* **Validation :** Validation DNS CNAME via votre fournisseur DNS
* **Protocole minimum :** TLS 1.2

***

### 6. Infrastructure en tant que code

#### Modules Terraform

* **`modules/eks`:** Cluster EKS, VPC, groupes de nœuds, Karpenter, IAM, versions Helm
* **État :** Bucket S3 avec versioning, table de verrouillage DynamoDB

#### Terragrunt

* **Isolation de l'environnement :** Un répertoire par environnement sous `terragrunt/environments/`
* **Modèle :** `env-template-folder` — copier et remplir les espaces réservés pour créer un nouvel environnement
* **Configuration DRY :** `root.hcl` partagée avec les remplacements par environnement
* **Indicateurs d'activation/désactivation :** Services basculés via variables d'environnement (`ENABLE_*`)

#### Graphiques Helm

| Graphique                | Espace de noms   | Description                               |
| ------------------------ | ---------------- | ----------------------------------------- |
| `infrastructure`         | `infrastructure` | Contrôleur ALB                            |
| `odin-services`          | `default`        | Web, API, Travailleurs, Automator, Entrée |
| `aws-ebs-csi-driver`     | `kube-system`    | Approvisionnement des volumes EBS         |
| `keda`                   | `keda`           | Mise à l'échelle automatique des pods     |
| `cloudnative-pg`         | `cnpg-system`    | Opérateur PostgreSQL                      |
| `ha-supabase-db`         | `ha-supabase-db` | Cluster Postgres HA + PgBouncer           |
| `supabase-kubernetes-ha` | `supabase`       | Pile Supabase complète                    |
| `signoz`                 | `monitoring`     | Plateforme d'observabilité                |
| `k8s-infra`              | `monitoring`     | Agent des métriques du cluster            |

***

## Flux de données

### 1. Flux de demande utilisateur

```
Utilisateur → DNS → ALB (terminaison SSL) → Pod EKS (Web Frontend)
                                          → Pod EKS (FastAPI Backend)
                                          → Pod EKS (Supabase Kong)
```

1. L'utilisateur accède à `app.example.com`
2. DNS se résout vers l'ALB
3. ALB termine SSL et route par nom d'hôte vers le groupe cible correct
4. Web Frontend sert l'application React et effectue des appels API vers `api.example.com`
5. FastAPI Backend traite les demandes et lit/écrit dans les services de données

### 2. Flux de demande API

```
Client → ALB → FastAPI Backend → Redis (cache) / RabbitMQ (file d'attente) / Supabase (BD)
```

1. Le client appelle `api.example.com`
2. ALB route vers le pod FastAPI
3. Le backend vérifie le cache Redis ; en cas d'absence, interroge la base de données Supabase
4. Les tâches asynchrones sont mises en file d'attente dans RabbitMQ et traitées par les travailleurs Celery

### 3. Flux de traitement en arrière-plan

```
FastAPI → RabbitMQ → Celery Worker → Base de données Supabase
```

1. FastAPI met une tâche en file d'attente dans RabbitMQ
2. Celery Worker retire de la file d'attente et traite la tâche
3. Les résultats sont réécrits dans la base de données Supabase

### 4. Flux de travail Automator

```
Automator → PostgreSQL (local) → Redis → APIs externes
```

1. Automator reçoit une demande de flux de travail
2. L'état du flux de travail est persistant dans l'instance PostgreSQL locale
3. Redis cache les résultats intermédiaires
4. Les API externes sont appelées dans le cadre de l'automation

### 5. Flux de mise à l'échelle

```
Métriques → KEDA → Mise à l'échelle des pods → Karpenter → Approvisionnement des nœuds
```

1. KEDA évalue les métriques CPU/Mémoire par rapport aux seuils configurés
2. Les pods sont mis à l'échelle horizontalement dans la plage de répliques configurée
3. Si la capacité du cluster est insuffisante, Karpenter provisionne de nouveaux nœuds EC2 (préférant les Spot)
4. Lorsque la charge diminue, KEDA réduit l'échelle des pods ; Karpenter consolide et termine les nœuds inactifs

### 6. Flux de sécurité

```
Internet → ALB (TLS 1.2+, ACM) → Groupes de sécurité → Pods → Rôles IRSA IAM → APIs AWS
```

1. Tout le trafic externe termine TLS à l'ALB
2. Les groupes de sécurité appliquent l'accès réseau à privilège minimal
3. Les pods communiquent avec les services AWS via IRSA (Rôles IAM pour les comptes de service)

***

## Résumé de la haute disponibilité

| Fonctionnalité                         | Implémentation                                                         |
| -------------------------------------- | ---------------------------------------------------------------------- |
| Déploiement multi-AZ                   | 3 AZs pour les nœuds EKS, Redis, sous-réseaux                          |
| Équilibrage de charge                  | ALB avec plusieurs groupes cibles                                      |
| Redondance des pods                    | Minimum 2 répliques par service                                        |
| HA de la base de données               | Cluster CloudNativePG avec PgBouncer (auto-hébergée) ou Supabase Cloud |
| Redondance du cache                    | ElastiCache Multi-AZ                                                   |
| Mise à l'échelle automatique des nœuds | Karpenter avec mélange Spot + À la demande                             |
| Mise à l'échelle automatique des pods  | KEDA basée sur CPU/Mémoire                                             |
| Observabilité                          | SigNoz (optionnel)                                                     |
| Gestion de l'état                      | S3 avec versioning + verrouillage DynamoDB                             |

***

## Optimisation des coûts

* **Instances Spot :** Karpenter priorise les Spot pour toutes les charges de travail non-base de données
* **Consolidation des nœuds :** Karpenter récupère automatiquement les nœuds sous-utilisés
* **Dimensionnement correct des pods :** KEDA réduit l'échelle des pods pendant les périodes calmes
* **À la demande uniquement si nécessaire :** La classe de nœud de base de données utilise À la demande pour la stabilité

***

## Maintenance et opérations

### Processus de déploiement

```bash theme={null}
cd terragrunt/environments/<your-env-name>
# Définir les variables d'environnement ENABLE_* et domaine/certificat requises
terragrunt apply
# Mises à jour roulantes : réappliquer après la mise à jour des balises d'image ou des fichiers de valeurs
```

Voir [Guide de déploiement Terragrunt](/on-premise/kubernetes-deployment/terragrunt-deployment.mdx) pour la séquence de déploiement complète.

### Stratégie de sauvegarde

* **Snapshots EBS :** Snapshots automatisés pour les volumes persistants (Base de données Automator, Supabase MinIO)
* **CloudNativePG :** Archivage WAL continu + sauvegardes de base programmées (si configuré)
* **Supabase Cloud :** Sauvegardes quotidiennes gérées (option cloud)
* **État IaC :** Bucket S3 versionné

### Récupération d'urgence

* **Multi-AZ :** Tous les services avec état s'étendent sur plusieurs zones de disponibilité
* **CloudNativePG HA :** Basculement automatique entre les répliques principales et Postgres
* **Supabase Cloud :** Redondance interrégionale (option cloud)
* **État Terraform :** Le versioning S3 permet de revenir à tout état précédent

***

## Ressources supplémentaires

* [Contrôleur AWS Load Balancer](https://kubernetes-sigs.github.io/aws-load-balancer-controller/)
* [Documentation Karpenter](https://karpenter.sh/docs/)
* [Documentation KEDA](https://keda.sh/docs/)
* [Documentation CloudNativePG](https://cloudnative-pg.io/documentation/)
* [Auto-hébergement Supabase](https://supabase.com/docs/guides/self-hosting)
* [Documentation SigNoz](https://signoz.io/docs/)
* [Guide de déploiement Terragrunt](/on-premise/kubernetes-deployment/terragrunt-deployment.mdx)