Dans les architectures cloud critiques, la haute disponibilité des appliances réseau (NVA – Network Virtual Appliances) est essentielle. Traditionnellement, les solutions de clustering actif/passif reposent sur des mécanismes plus ou moins complexes où l’appliance primaire doit appeler l’API AWS pour mettre à jour les tables de routage en cas de bascule. Bien que fonctionnelle, cette approche présente plusieurs limitations :
- Dépendance à l’API AWS : L’appliance doit être capable d’interagir directement avec les services AWS.
- Complexité de mise en œuvre : elle nécessite de développer et maintenir des scripts ou des intégrations spécifiques ou bien de prendre des solutions de NVA compatibles.
- Latence potentielle : les appels API peuvent introduire des délais dans la propagation des routes.
Avec l’arrivée du VPC Route Server, AWS propose une solution native qui élimine ces contraintes en permettant une gestion dynamique et centralisée des routes, sans dépendre des capacités des appliances à interagir avec l’API AWS.
Dans cet article, nous explorons comment le VPC Route Server simplifie et améliore la gestion des appliances en mode actif/passif, tout en renforçant la résilience des architectures cloud.
1. Les limites des solutions traditionnelles de clustering actif/passif
1.1. Fonctionnement des solutions existantes
Aujourd’hui, les appliances réseau (pare-feux, routeurs, etc.) en mode actif/passif doivent encore :
- 📡 Détecter une défaillance (via des health checks ou des mécanismes internes).
- 📞Appeler l’API AWS pour mettre à jour les tables de routage.
Cette approche présente plusieurs inconvénients persistants :
- 📈 Complexité accrue : l’appliance doit être conçue pour interagir avec AWS, ce qui n’est pas toujours le cas.
- 🧨 Risque de latence : les appels API peuvent introduire des délais dans la bascule.
- 🛠️ Maintenance lourde : elle nécessite de gérer des scripts ou des intégrations personnalisées.
1.2. Besoin d’une solution plus simple et plus fiable
Pour répondre à ces défis, le VPC Route Server propose :
- ✅ D’éliminer la dépendance aux appels API pour la mise à jour des routes.
- ✅ D’automatiser la propagation des routes sans intervention manuelle ou scriptée.
- ✅ De réduire la latence lors des bascules actif/passif.
2. Le VPC Route Server : une solution native pour le clustering actif/passif
2.1. Fonctionnement du VPC Route Server
Le VPC Route Server agit comme un route reflector BGP. Contrairement aux solutions traditionnelles, il ne nécessite aucune interaction directe avec l’API AWS de la part des appliances.
Voici comment il fonctionne dans un scénario actif/passif :
- L’appliance active annonce ses routes au VPC Route Server via un protocole standard (BGP).
- L’appliance passive annonce les mêmes routes mais avec une priorité inférieure.
- Le VPC Route Server propage les meilleures routes (donc celles de l’appliance active) aux tables de routage du VPC.
- En cas de défaillance de l’appliance active, celle-ci cesse d’annoncer ses routes.
- Les routes de l’appliance passive deviennent actives car les routes de l’appliance primaire disparaissent.
- Le VPC Route Server met à jour automatiquement les tables de routage avec les routes de l’appliance secondaire, assurant une bascule transparente.
2.2 Certains cas d’usages encore non supportés
Très souvent, on retrouve les clusters de pare-feu pour sécuriser le trafic interne mais aussi le trafic venant ou allant d’internet.
Sur AWS, la majorité des architectures NVA en mode actif/passif repose sur la bascule des IP publiques (Elastic IP) sur l’appliance secondaire.
Ce mode de bascule se fait par le biais de call API AWS via un script.
Le VPC Route Server ne couvre malheureusement pas le besoin de basculer les Elastic IP d’une instance à une autre.
Ainsi, les clusters qui sont utilisés pour accéder à internet par le biais d’IP publique statique ne pourront pas encore se passer d’utiliser de scripts.
3. Exemple de déploiement VPC Route Server avec Terraform
Pour ceux qui voudraient déployer VPC Route Server, vous devez utiliser la dernière version du provider Terraform AWS (5.100.0) à l’heure où ces lignes sont écrites.
Voici un exemple de code Terraform :
# Création du VPC Route Server
resource "aws_vpc_route_server" "this" {
amazon_side_asn = 65100
persist_routes = "disable"
tags = {
Name = "route-server"
}
}
# Association du VPC Route Server au VPC
resource "aws_vpc_route_server_vpc_association" "this" {
route_server_id = aws_vpc_route_server.this.route_server_id
vpc_id = data.aws_vpc.this.id
}
# Choisi quelle RT AWS recevra les routes VPC Route Server
resource "aws_vpc_route_server_propagation" "this" {
route_server_id = aws_vpc_route_server.this.route_server_id
route_table_id = aws_route_table.ars.id
}
# Création d'un endpoint pour le Route Server
resource "aws_vpc_route_server_endpoint" "this" {
route_server_id = aws_vpc_route_server.this.route_server_id
subnet_id = aws_subnet.ars.id
tags = {
Name = "RouteServerEndpoint-az1"
}
}
# Création du Route Server Peer (connexion BGP)
resource "aws_vpc_route_server_peer" "this" {
route_server_endpoint_id = aws_vpc_route_server_endpoint.this.route_server_endpoint_id
peer_address = aws_instance.network_appliance.private_ip
bgp_options {
peer_asn = 65200
}
tags = {
Name = "nva1"
}
}
Conclusion
Le VPC Route Server d’AWS représente une avancée pour les entreprises cherchant à simplifier la gestion des appliances réseau en mode actif/passif. En éliminant la dépendance aux appels API et en automatisant la propagation des routes, cette solution améliore la disponibilité, la sécurité et l’efficacité opérationnelle des infrastructures cloud.
En revanche cette fonctionnalité ne pourra pour le moment pas remplacer l’usage de script ou de solution propriétaire.
Il faudra attendre encore un peu pour utiliser cette fonctionnalité sur la région de Paris (eu-west-3) car elle n’est disponible que sur AWS USA Est (Virginie), USA Est (Ohio), USA Ouest (Oregon), Europe (Irlande), Europe (Francfort) et Asie-Pacifique (Tokyo).
Par Florian Lacommare, Tribu Leader Open Cloud, Cloud Network Architect