AWS Wavelength à Dakar : 5 patterns d’architecture pour déployer vos applications
Dans un article précédent, nous avons expliqué ce qu’est une Wavelength Zone et ce qu’elle apporte concrètement. Cet article va plus loin : il présente cinq architectures de référence pour vous aider à vous projeter. La Wavelength Zone de Dakar — déployée dans le datacenter Sonatel depuis avril 2025, rattachée à la région parente eu-west-3 (Paris) — sert d’illustration concrète tout au long de l’article. Ces patterns s’appliquent à toute Wavelength Zone dans le monde, chacune rattachée à sa propre région parente.
Vue d’ensemble : les 5 patterns en un coup d’œil
Avant d’entrer dans le détail de chaque pattern, ce tableau vous permet d’identifier rapidement celui qui correspond à votre contexte.
| Pattern | Résumé | Complexité |
| 1 — Traitement applicatif local en WLZ | Trafic utilisateur traité dans la WLZ — contrôle toujours en région | Simple |
| 2 — WLZ + Région | Hub & Spoke : edge pour la latence, région pour les données | Intermédiaire |
| 3 — WLZ + Région + On-Premises | WLZ pour la latence, région comme hub et point VPN, on-premises pour les données legacy | Avancé |
| 4 — Haute Disponibilité | Failover automatique WLZ vers Région | Intermédiaire |
| 5 — Disaster Recovery | WLZ production, Région pour PCA/PRA formels | Avancé |
1. Les briques de base
Avant de parcourir les patterns, voici les composants qui constituent toute architecture Wavelength.
| Composant | Rôle | À retenir |
| Wavelength Zone (WLZ) | Infrastructure AWS hébergée dans le datacenter de l’opérateur télécom partenaire. Pour Dakar : datacenter Sonatel. | Extension de votre VPC AWS — pas un cloud séparé. Partage le même VPC que vos ressources en région. |
| Région parente | Région AWS associée à la WLZ. Pour Dakar : eu-west-3 (Paris). | Héberge les services non disponibles en WLZ (RDS, Lambda, S3…), sert de hub central. |
| Carrier Gateway | Point de routage du trafic entre la WLZ et le réseau mobile de l’opérateur. Effectue la NAT des Carrier IP. | Donne accès au réseau Sonatel au sens large (4G/5G et potentiellement IP/MPLS) |
| Carrier IP | Adresse IP assignée par l’opérateur, routable sur son réseau mobile. | Accessible depuis les appareils et équipements connectés au réseau Sonatel — mobile (4G/5G) et potentiellement via boucle locale ou MPLS selon le type d’accès. |
| VPC étendu | Un seul VPC couvre à la fois les subnets en Région et les subnets en WLZ. | Communication interne WLZ ↔ Région via le VPC, sans passer par internet. |
| Services disponibles en WLZ | EC2, EBS, ECS, EKS, EC2 Auto Scaling, Systems Manager, CloudWatch, CloudTrail, CloudFormation. | Par exemple ElastiCache non disponible en WLZ — utiliser Redis via pod EKS/ECS. RDS non disponible — utiliser Redis/PostgreSQL via EKS si persistance locale nécessaire. |
https://docs.aws.amazon.com/fr_fr/wavelength/latest/developerguide/how-wavelengths-work.html
2. Les 5 patterns en détail
| Pattern 1 Traitement applicatif local en WLZ : Le trafic utilisateur reste dans la WLZ — le plan de contrôle passe toujours par la région |
Dans ce pattern, la logique applicative tourne dans la Wavelength Zone et le trafic des données utilisateurs (data plane) ne quitte pas la WLZ pour être traité — c’est ce qui minimise la latence.
La région parente eu-west-3 reste toujours impliquée pour le plan de contrôle : console AWS, API, CLI, CloudFormation, IAM, déploiements, modification des ressources. Ce que “Traitement applicatif local en WLZ” désigne, c’est que le trafic applicatif des utilisateurs ne génère pas nécessairement d’aller-retour vers la région pour être traité — pas que la région est absente.
Quand de la persistance locale est nécessaire, des bases auto-gérées peuvent être déployées en WLZ grâce à Amazon EKS par exemple. Néanmoins ce choix doit être bien considéré : il transfère à l’équipe la responsabilité de la haute disponibilité, des sauvegardes, des mises à jour, de la réplication et des tests de restauration.
Fiche synthèse
| Dimension | Détail |
| Cas d’usage typiques | Gaming mobile temps réel, streaming vidéo, traitement flux IoT, alertes industrielles, AR/VR mobile |
| Services WLZ (data plane) | EC2, ECS, EKS (+ bases de données containerisées si besoin), EBS |
| Région eu-west-3 (control plane) | Console AWS, API, IAM, CloudFormation, CloudWatch, CloudTrail — toujours nécessaires |
| Latence indicative | Faible — ordres de grandeur indicatifs. |
| Avantages | Trafic utilisateur traité localement sans aller-retour région, latence optimisée |
| Limites | Catalogue AWS limité en WLZ, plan de contrôle toujours en région, bases de données auto-gérées via EKS si persistance nécessaire |
| Pour qui | Plateformes gaming, streaming, IoT industriel, use cases sans état complexe |
| Pattern 2 WLZ + Région — Hub & Spoke : Le pattern recommandé par AWS pour la majorité des use cases |
C’est le pattern de référence dans la documentation AWS. La Wavelength Zone héberge la couche applicative latency-sensitive. La région parente (eu-west-3) héberge le backend s’appuyant sur les services managés complets — bases de données, stockage, authentification, analytics. Les deux couches communiquent via le VPC étendu, sans passer par internet.
Ce pattern convient à la majorité des applications qui ont besoin de réactivité (logique traitée en WLZ) et d’un catalogue de services riche (disponible en région). C’est un bon point de départ pour la plupart des projets.
Fiche synthèse
| Dimension | Détail |
| Cas d’usage typiques | API banking mobile, paiement mobile, détection de fraude, télémédecine, e-commerce mobile |
| Services WLZ | EC2, ECS/EKS, EBS |
| Services Région (eu-west-3) | RDS/Aurora, S3, Lambda, Cognito, SQS, CloudWatch, CloudTrail |
| Latence indicative | WLZ : faible pour la logique applicative. Appels région : quelques dizaines de ms supplémentaires. |
| Avantages | Pattern recommandé AWS, accès à un catalogue beaucoup plus riche de services managés en région, bon équilibre performance / fonctionnalité |
| Limites | Les données persistantes sont en région eu-west-3 (Paris) — à auditer si des exigences de résidence s’appliquent |
| Pour qui | Banques, fintechs, e-commerce, santé connectée — point de départ recommandé pour la plupart des projets |
| Pattern 3 WLZ + Région + On-Premises : La région est à la fois hub de services et point d’entrée obligatoire vers l’on-premises |
Ce pattern s’adresse aux organisations qui ont des systèmes critiques on-premises non migrables à court terme — core banking, ERP, dossiers médicaux — et qui veulent bénéficier de la faible latence de la WLZ pour leurs utilisateurs mobiles. C’est une extension du Pattern 2 : la région joue un double rôle.
La région parente est à la fois le hub de services managés et le point de terminaison du VPN. Le trafic on-premises arrive donc en région eu-west-3, puis transite vers la WLZ via le VPC étendu.
Conséquence pratique : le trafic entre l’on-premises et la WLZ fait un détour par la région. Cela n’annule pas l’intérêt du pattern — la WLZ reste le point d’entrée ultra-rapide pour le trafic client — mais attention aux appels synchrones vers le SI legacy. Pour conserver le bénéfice de latence, il faut limiter les échanges on-premises dans le chemin critique : cache local, réplication asynchrone, CQRS, file d’attente ou préchargement des données dans la WLZ ou en région peuvent être nécessaires.
Fiche synthèse
| Dimension | Détail |
| Cas d’usage typiques | Interface mobile pour core banking legacy, accès temps réel à un ERP, hôpitaux avec dossiers médicaux on-premises, administration publique |
| Rôle de la région | Double : hub de services managés + point de terminaison VPN vers l’on-premises |
| Connectivité on-premises | VPN IPSec → se termine en région eu-west-3 (pas dans la WLZ). |
| Latence on-premises → WLZ | Variable — dépend du VPN internet + transit région. À mesurer dans votre contexte. |
| Avantages | Amélioration de l’expérience mobile sans migration forcée du SI legacy, chemin progressif vers le cloud |
| Limites | Le trafic on-premises ↔ WLZ transite obligatoirement par la région — pas de raccourci direct |
| Pour qui | Banques avec core banking legacy, hôpitaux, administrations, grandes entreprises avec SI hybride |
| Pattern 4 Haute Disponibilité — Failover WLZ → Région : Résilience et continuité pour les services à SLA élevé |
Pour les services qui ne peuvent pas se permettre d’interruption — paiement mobile, urgences médicales, infrastructure télécom — une Wavelength Zone unique crée un Single Point of Failure. Ce pattern exploite Route 53 pour basculer automatiquement le trafic vers la région parente si la WLZ devient indisponible.
Dans la configuration actuelle, Dakar dispose d’une seule Wavelength Zone. La haute disponibilité entre deux WLZ dans deux villes différentes deviendra sûrement possible au fur et à mesure que les zones se déploient dans la sous-région. En attendant, la région parente (eu-west-3) constitue le site de secours naturel — avec une latence augmentée pendant le failover, mais une meilleure capacité de continuité si le scénario est régulièrement testé.
Fiche synthèse
| Dimension | Détail |
| Cas d’usage typiques | Paiement mobile critique, services bancaires 24/7, urgences médicales, infrastructure télécom |
| RTO indicatif | RTO cible : de l’ordre de la minute dans une architecture correctement testée, selon TTL DNS, fréquence des health checks, warm-up applicatif et comportement des clients. |
| Services clés | Route 53 (politique Failover), CloudWatch Alarms (health checks), EC2 warm standby en région |
| Avantages | Améliore fortement la continuité de service, réduit le risque lié à une WLZ unique. À valider par tests de basculement réguliers. |
| Limites | Latence augmentée lors du failover vers la région, coût du warm standby |
| Pour qui | Services avec SLA élevé — banques, opérateurs, santé |
| Pattern 5 Disaster Recovery : WLZ production, Région eu-west-3 comme site DR formel |
Dans ce pattern, les données primaires résident dans la WLZ — typiquement dans des pods EKS ou sur des volumes EBS. La région eu-west-3 est le site DR : elle reçoit une réplication régulière depuis la WLZ. Le RPO dépend directement de la fréquence de réplication choisie — snapshots EBS vers S3, exports applicatifs.
Paramètres DR — à spécifier et tester
| Paramètre | Définition | Dépend de |
| RTO | Temps de reprise après incident | TTL DNS Route 53, health check interval, temps de warm-up en région |
| RPO | Perte de données maximale — lié à la fréquence de réplication | Fréquence des snapshots / exports depuis la WLZ vers S3 en région |
| Test DR | Fréquence des tests de basculement | Exigences réglementaires / sectorielles — minimum trimestriel |
Fiche synthèse
| Dimension | Détail |
| Cas d’usage typiques | Établissements financiers, opérateurs d’infrastructure critique |
| Données primaires | Dans la WLZ (EKS/EBS) — la région reçoit la réplication, elle n’est pas le site primaire |
| Réplication WLZ → Région | Snapshots EBS vers S3, exports applicatifs — à concevoir et monitorer explicitement |
| RPO | Dépend de la fréquence de réplication — pas un paramètre automatique |
| Avantages | Contribue à documenter une stratégie PCA/PRA, permet de définir un site primaire en WLZ et un site de reprise en région, avec journalisation CloudTrail à intégrer dans le dispositif d’audit. |
| Point d’attention | Plus complexe à opérer que le Pattern 4 — la réplication doit être conçue, testée et monitorée |
| Pour qui | Tout établissement avec obligations formelles de continuité d’activité |
3. Checklist de décision
Avant de choisir votre pattern, parcourez ces questions dans l’ordre.
| Question | Réponse | Orientation |
| Votre application nécessite-t-elle une latence très faible pour des utilisateurs mobiles Sonatel ? | Non | Région classique — pas de WLZ nécessaire |
| Votre application nécessite-t-elle une latence très faible pour des utilisateurs mobiles ? | Oui | Continuez — une WLZ peut être pertinente |
| Avez-vous des systèmes on-premises critiques non migrables ? | Non | Patterns 1 ou 2 — commencer par le Pattern 2 |
| Avez-vous des systèmes on-premises critiques non migrables ? | Oui | Pattern 3 — la région joue un double rôle : hub services + point VPN vers l’on-premises |
| Votre réglementation exige-t-elle que certaines données restent au Sénégal ? | Oui | Auditer service par service — aucun pattern ne garantit automatiquement la résidence complète |
4. Questions fréquentes
Quelle différence entre AWS Wavelength et une région AWS ?
Une région AWS (comme eu-west-3 à Paris) est une infrastructure complète et autonome : elle héberge l’ensemble des services AWS, dispose de plusieurs zones de disponibilité indépendantes, et peut fonctionner de façon totalement autonome. Une Wavelength Zone est une extension d’une région — elle partage le même VPC, les mêmes APIs, les mêmes outils — mais avec un catalogue de services très réduit (EC2, EBS, ECS, EKS essentiellement) et sans redondance géographique interne. La WLZ ne peut pas fonctionner de façon autonome : elle dépend de sa région parente pour le plan de contrôle (console, IAM, CloudFormation), pour les services managés (RDS, Lambda, S3), et pour la connectivité VPN vers l’on-premises. Penser la WLZ Dakar comme “une région AWS au Sénégal” est la principale source de confusion architecturale — c’est une extension edge de la région Paris, pas une région indépendante.
Quelle est la région parente de la Wavelength Zone de Dakar ?
eu-west-3 (Paris). La page officielle AWS Wavelength Zone locations l’indique explicitement : la zone de Dakar (eu-west-3-dss-wlz-1a) est rattachée à Europe (Paris), code eu-west-3. eu-west-1 est la région Irlande — une région distincte.
Peut-on déployer Kubernetes dans une Wavelength Zone ?
Oui. Amazon EKS est officiellement supporté dans les Wavelength Zones. Cela permet de déployer des workloads containerisés à l’edge — y compris des bases de données comme PostgreSQL ou Redis via des Helm charts. L’avantage est la flexibilité ; la contrepartie est que la haute disponibilité, les sauvegardes et les mises à jour du moteur deviennent de votre responsabilité.
Comment démarrer concrètement avec un premier déploiement ?
Quatre étapes : (1) activer la Wavelength Zone dans votre compte AWS — console EC2 → Zones → opt-in pour eu-west-3-dss-wlz-1a ; (2) créer un VPC étendu avec un subnet en région eu-west-3 et un subnet en WLZ ; (3) créer un Carrier Gateway et configurer la table de routage du subnet WLZ ; (4) lancer une instance EC2 dans le subnet WLZ avec une Carrier IP — votre première ressource est accessible depuis le réseau Sonatel. La documentation AWS Getting Started for Wavelength couvre chaque étape en détail.
AWS Wavelength permet-il d’héberger des données au Sénégal ?
AWS présente explicitement la résidence des données comme l’un des trois cas d’usage officiels de la WLZ Dakar, aux côtés de la faible latence et de la résilience. Les données traitées et stockées dans la WLZ (volumes EBS, bases de données auto-gérées via EKS) sont physiquement localisées dans le datacenter Sonatel à Dakar. En revanche, si votre architecture utilise des services en région parente — RDS, S3, CloudWatch, Cognito, CloudTrail — ces données résident en France (eu-west-3), pas au Sénégal. La règle à retenir : la WLZ peut contribuer à des exigences de résidence, mais l’architecture doit être auditée service par service. Le traitement local ne garantit pas automatiquement la résidence complète de toutes les données.
Wavelength fonctionne-t-il depuis tous les opérateurs mobiles au Sénégal ?
Le gain de latence ultra-faible s’applique aux appareils connectés au réseau Sonatel — mobile (4G/5G) et potentiellement via boucle locale ou MPLS selon le type d’accès.
Peut-on faire de la haute disponibilité entre plusieurs Wavelength Zones ?
Oui — c’est techniquement supporté par AWS. Dakar dispose aujourd’hui d’une seule WLZ. À mesure que d’autres villes africaines rejoignent le programme, une architecture multi-WLZ deviendrait possible, avec Route 53 pour distribuer le trafic entre zones. En attendant, le Pattern 4 de cet article décrit la stratégie HA recommandée : failover automatique vers la région parente eu-west-3, avec un warm standby en région qui prend le relais si la WLZ est indisponible. C’est une architecture éprouvée, documentée par AWS, et testable régulièrement.
5. Conclusion
AWS Wavelength à Dakar ouvre des possibilités intéressantes pour les applications mobiles à faible latence, mais ce n’est pas une mini-région AWS complète au Sénégal. Le bon pattern dépend de trois questions : où se situe le traitement sensible à la latence, où résident les données, et comment l’application se comporte en cas d’indisponibilité de la WLZ. Pour la majorité des projets, le modèle WLZ + Région reste le meilleur point de départ. Les patterns plus avancés — on-premises, haute disponibilité et disaster recovery — doivent être conçus, testés et audités avant tout usage critique.
Sources et références
AWS Wavelength — Zone locations — Dakar : eu-west-3-dss-wlz-1a, Parent Region : Europe (Paris)
AWS VPC User Guide — Subnets in AWS Wavelength — contrainte Transit Gateway sur subnet WLZ, routing WLZ
AWS FAQ — Wavelength Zones (services disponibles) — EC2, EBS, ECS, EKS, CloudFormation… pas ElastiCache
AWS Developer Guide — Carrier Gateway
AWS Developer Guide — Architect apps for Wavelength — Hub & Spoke, workload placement, failover Route 53
AWS Blog — Deploy geo-distributed EKS clusters on AWS Wavelength
