Déployer Dify sur AWS pour une Scalabilité Maximale de l'IA

Déployer Dify sur AWS dans une architecture conçue pour la production nécessite bien plus qu'une simple instance EC2. Pour atteindre une scalabilité maximale, la documentation officielle Dify recommande une combinaison de services AWS managés orchestrés via Kubernetes. Voici comment construire cette infrastructure de façon rigoureuse.

Pourquoi EKS est la brique centrale

L'architecture de référence Dify sur AWS repose sur Amazon EKS (Elastic Kubernetes Service). Contrairement à un déploiement monolithique sur une seule machine virtuelle, EKS permet :

• L'auto-scaling horizontal des nœuds workers selon la charge
• La répartition des composants sur plusieurs zones de disponibilité
• Une résilience accrue grâce à la supervision Kubernetes native
• Un déploiement reproductible via Terraform et charts Helm

Pour comprendre pourquoi cette approche surpasse un déploiement Docker Compose classique, consultez notre guide sur Déployer Dify sur un Serveur Dédié avec Docker Compose : Le Guide Ultime.

Les services AWS recommandés pour Dify

La documentation Dify Enterprise identifie sept services AWS à coupler avec EKS pour une infrastructure découplée et évolutive :

Service AWS	Rôle dans l'architecture Dify
Amazon EKS	Orchestration des conteneurs Dify
Amazon S3	Stockage persistant des fichiers et artefacts
Amazon ECR	Registre des images Docker, plugins et charts Helm
Aurora PostgreSQL	Base relationnelle pour les données applicatives
Amazon OpenSearch	Base vectorielle pour les fonctionnalités RAG
ElastiCache Redis	Cache managé pour réduire la latence
ALB (Application Load Balancer)	Exposition publique sur domaine avec haute disponibilité

Chaque couche est indépendante : si le trafic explose, on scale EKS sans toucher à la base de données, et inversement.

Dimensionnement : ce que les chiffres indiquent

La documentation Dify précise qu'une configuration prête pour la production peut supporter 3 000 utilisateurs actifs quotidiens avec 6 nœuds workers de 8 cœurs CPU et 32 Go de RAM chacun, associés à PostgreSQL, Redis et un cluster vectoriel dimensionnés pour la charge.

L'architecture de référence AWS open source propose un point de départ plus léger :

• Un task API/worker et un task web
• Un nœud Redis t4g.micro
• Aurora Serverless v2 plafonné à 2 ACU

Ce socle minimal est extensible. Pour des workloads IA lourds ou des applications multi-conteneurs, un t3.medium minimum est recommandé, le t3.micro étant explicitement déconseillé.

Dify utilise cette architecture en interne pour sa plateforme SaaS : Amazon EKS, EC2, Lambda et API Gateway gèrent plus de 2 300 fonctions Lambda et des millions d'appels par mois, ce qui valide la robustesse du modèle.

Infrastructure as Code : Terraform en priorité

Pour les déploiements Enterprise sur AWS, Terraform est la méthode officielle recommandée. Le CDK est indiqué comme déprécié dans la documentation actuelle. Terraform permet :

• Des déploiements reproductibles et versionables
• Une gestion contrôlée des évolutions d'infrastructure
• Une intégration native avec les modules EKS et les services managés AWS

Les nœuds EKS doivent disposer d'un accès Internet ou d'un NAT Gateway pour les dépendances et les opérations d'installation initiales.

Déploiement rapide vs scalabilité maximale

Deux approches coexistent selon les objectifs :

Dify Premium via AWS Marketplace : déploiement sur l'instance EC2 de votre choix dans votre VPC. Plus simple, adapté à une preuve de concept ou un usage limité. Moins élastique qu'un cluster multi-nœuds.

Dify Enterprise sur EKS : architecture complète avec ALB, Aurora, Redis, S3, ECR et OpenSearch. Recommandée pour la production, la conformité, l'isolation réseau et la résidence des données.

Si vous hésitez encore entre les modèles de déploiement, notre comparatif Dify Cloud vs Dify Self-Hosted : Le Comparatif Complet pour Vos Projets IA vous aidera à trancher selon vos contraintes.

OpenSearch et la couche RAG

Pour les usages IA avancés impliquant du RAG (Retrieval-Augmented Generation), Amazon OpenSearch joue un rôle critique. Une couche vectorielle non dimensionnée correctement devient rapidement un goulot d'étranglement. OpenSearch managé sur AWS offre :

• Scalabilité des index vectoriels sans gestion de serveur
• Intégration native avec les autres services AWS
• Support des recherches sémantiques à grande échelle

Pour les équipes qui souhaitent explorer d'autres hébergeurs cloud avant de s'engager sur AWS, le guide Installer Dify en Self-Hosted sur OVHcloud : Le Guide Complet offre une alternative européenne intéressante.

Principes à retenir pour une architecture durable

• Scalabilité horizontale : ajouter des nœuds plutôt que surdimensionner une seule machine
• Séparation des couches : calcul, stockage, cache, base relationnelle et recherche vectorielle découplés
• Haute disponibilité : composants répartis sur plusieurs zones AWS
• Infra as Code : Terraform pour des déploiements contrôlés et évolutifs

---

FAQ

Quels services AWS sont indispensables pour déployer Dify en production ?

La documentation Dify recommande EKS, S3, Aurora PostgreSQL, ElastiCache Redis, Amazon OpenSearch, ECR et un ALB. Ces services couvrent respectivement l'orchestration, le stockage, la base de données, le cache, la recherche vectorielle, les images et l'exposition réseau.

Combien d'utilisateurs peut supporter une architecture Dify sur AWS correctement dimensionnée ?

Selon la documentation Dify, une configuration avec 6 nœuds workers de 8 cœurs et 32 Go de RAM, associée à PostgreSQL, Redis et un cluster vectoriel, peut supporter 3 000 utilisateurs actifs quotidiens.

Pourquoi utiliser EKS plutôt qu'une instance EC2 unique pour Dify ?

EKS permet l'auto-scaling horizontal, la haute disponibilité multi-zones et un déploiement Kubernetes natif. Une instance EC2 unique est limitée en élasticité et représente un point de défaillance unique, contrairement à un cluster multi-nœuds.

Terraform ou CDK pour déployer Dify Enterprise sur AWS ?

La documentation Dify Enterprise recommande Terraform. Le CDK est indiqué comme déprécié dans la version actuelle de la documentation officielle.

Quelle instance EC2 minimum pour Dify sur AWS Marketplace ?

Le t3.micro est explicitement déconseillé pour les applications multi-conteneurs et mémoire intensive. Un t3.medium est le minimum recommandé, et les workloads GPU nécessitent des instances adaptées.