Dimensionner un sous-réseau cloud selon les adresses IP réellement utilisables

Un bloc /26 contient 64 adresses IPv4. Cela ne signifie pas que 64 adresses peuvent être attribuées à des ressources cloud. Même le résultat classique de 62 hôtes utilisables peut surestimer la capacité réelle.

Prenons un déploiement hypothétique qui nécessite aujourd'hui 50 adresses pour ses interfaces réseau. L'équipe retient une marge de planification de 20%, soit un objectif de 60 adresses. Le calcul traditionnel indique qu'un /26 offre 62 hôtes utilisables. Pourtant, AWS et Azure rendent chacun cinq adresses indisponibles: il n'en reste que 59. Le bloc manque l'objectif d'une adresse.

Il faut donc distinguer la taille mathématique du bloc de la capacité attribuable chez le fournisseur. La marge de 20% sert uniquement à rendre l'exemple reproductible; ce n'est pas une recommandation universelle.

Calculer d'abord la taille brute du bloc

IPv4 comporte 32 bits. Pour une longueur de préfixe p, le nombre total d'adresses est:

nombre total = 2^(32 - p)

La RFC 4632 définit la notation CIDR et indique 64 adresses pour /26, contre 128 pour /25. Le préfixe décrit un bloc. Il ne contient ni les règles de réservation d'un fournisseur cloud ni les contraintes de capacité d'un service managé.

Saisissez 26 dans le calculateur CIDR de Calquio:

Les 62 hôtes correspondent à la convention IPv4 habituelle: l'adresse réseau et l'adresse de diffusion sont retranchées. Pour planifier un sous-réseau cloud, ajoutez une deuxième opération:

capacité attribuable = adresses totales - adresses réservées par le fournisseur

Le calculateur ne sait pas si le bloc deviendra un sous-réseau AWS VPC, Azure VNet, une plage primaire ou secondaire Google Cloud, ou encore un sous-réseau dédié à un service. Son nombre d'hôtes utilisables est une base technique, pas un quota garanti par le fournisseur.

Retrancher les réservations du fournisseur

Les documentations officielles actuelles donnent trois capacités différentes pour un même /26:

AWS rend indisponibles les quatre premières adresses et la dernière. Azure réserve également les quatre premières et la dernière. Google Cloud utilise les deux premières et les deux dernières adresses d'une plage IPv4 primaire.

Ces règles ne s'appliquent pas indifféremment à toutes les plages. Google Cloud précise que toutes les adresses d'une plage IPv4 secondaire sont utilisables. AWS documente une exception pour BYOIP. Par ailleurs, un pare-feu managé, une passerelle ou une offre Kubernetes peut imposer un préfixe minimal ou consommer davantage d'adresses pendant une mise à l'échelle. Vérifiez le type exact de plage et de service, pas seulement le nom du fournisseur.

Reproduire l'exemple des 50 adresses

L'inventaire hypothétique peut se décomposer ainsi:

• 36 interfaces réseau d'application
• 8 interfaces d'agents de traitement ou de build
• 4 points de terminaison internes
• 2 adresses d'exploitation

Cette répartition n'est pas une architecture conseillée. Elle sert à montrer les entrées du calcul. Dans le système réel, chaque élément qui reçoit une adresse doit être compté une fois.

Avec la marge choisie:

objectif = ceil(50 × 1,20) = 60

Comparons les préfixes:

Chez AWS ou Azure, /26 échoue car 64 - 5 = 59, donc moins que 60. /25 passe avec 128 - 5 = 123.

Dans une plage primaire Google Cloud, /26 atteint exactement 60 puisque 64 - 4 = 60. Mais « exactement » signifie que toute la marge est consommée lorsque la cible est atteinte. Une interface d'équilibreur de charge oubliée, ou la présence simultanée de l'ancienne et de la nouvelle ressource pendant un déploiement progressif, peut alors bloquer une attribution. Si le plan d'adressage global le permet, /25 peut rester le choix le plus robuste.

L'erreur inverse consiste à choisir systématiquement /24 « par sécurité ». Cela mobilise 256 adresses avant réservations. Répété entre plusieurs environnements et couches, ce choix fragmente l'espace privé et complique les futures connexions sans chevauchement par appairage ou VPN. Le bon objectif est le plus petit bloc accepté par le fournisseur qui couvre un besoin documenté et une marge justifiée.

Tester les seuils avant de décider

Une analyse de sensibilité montre où une seule adresse supplémentaire change le préfixe:

Pour une plage primaire Google Cloud, passer de 60 à 61 adresses oblige à passer de /26 à /25: le bloc double, de 64 à 128 adresses. Ce n'est pas une erreur d'arrondi; les tailles CIDR suivent des puissances de deux. Notez dans le dossier d'architecture le pic de demande et la marge qui justifient le bloc supérieur.

Ne modélisez pas seulement le régime permanent. Un remplacement progressif peut faire coexister temporairement les anciennes et les nouvelles interfaces. L'autoscaling, les points de terminaison privés, les équilibreurs de charge et les composants de contrôle des services managés peuvent consommer leurs propres adresses. Transformez le comportement décrit dans la documentation actuelle du service en lignes distinctes de l'inventaire.

Suivre une liste de contrôle adaptée au fournisseur

Avant de créer le sous-réseau, consignez:

1. Le type de plage: fournisseur, IPv4 primaire ou secondaire, BYOIP ou sous-réseau dédié.
2. Le besoin permanent: interfaces, points de terminaison, nœuds et adresses de service.
3. Le besoin de pointe: chevauchement de déploiement, basculement et autoscaling maximal.
4. La marge: pourcentage ou nombre fixe, accompagné de sa justification.
5. La déduction du fournisseur: taille totale moins les réservations du type de plage exact.
6. Les contraintes du service: préfixe minimal et éventuel sous-réseau dédié.
7. La cohérence globale: absence de chevauchement avec les réseaux locaux, VPC/VNet, pairs et réseaux reliés par VPN.

Utilisez ensuite le calculateur CIDR pour vérifier le total et le masque. Conservez la déduction propre au fournisseur juste à côté du résultat. Cette annotation évite que « 62 utilisables » soit interprété à tort comme une capacité AWS ou Azure.

Limites de cette méthode

Cette méthode dimensionne la capacité d'adressage IPv4. Elle ne conçoit ni le routage, ni les frontières de sécurité, ni la répartition entre zones de disponibilité, ni IPv6, ni les plages de Pods Kubernetes. Un sous-réseau plus grand n'est pas automatiquement plus sûr ou plus disponible.

L'inventaire de 50 adresses et la marge de 20% sont hypothétiques. Remplacez-les par des mesures, le comportement de mise à l'échelle documenté et les exigences de reprise de votre organisation. Les règles des fournisseurs et des services peuvent évoluer; contrôlez à nouveau leur documentation officielle avant le déploiement.

Sources

• RFC 4632: Classless Inter-domain Routing (CIDR) — bonne pratique actuelle de l'IETF, août 2006; consultée le 29 juillet 2026.
• AWS: Subnet CIDR blocks — documentation actuelle sur les réservations VPC et les tailles de sous-réseau; la page n'indique pas de date de révision; consultée le 29 juillet 2026.
• Microsoft Azure: Virtual networks and subnets — mise à jour le 22 juin 2026; consultée le 29 juillet 2026.
• Google Cloud: Subnets — mise à jour le 27 juillet 2026 UTC; consultée le 29 juillet 2026.