Une intégration B2B passe en production avec un processeur de paiement qui met les IP en liste blanche. L’équipe place l’intégration derrière un ALB, met une passerelle NAT devant l’ALB, et donne au partenaire l’IP de la passerelle NAT. Six mois plus tard, ils remplacent la passerelle NAT lors d’une restructuration de VPC. La nouvelle NAT a une nouvelle Elastic IP. La liste blanche du partenaire n’est pas mise à jour pendant 48 heures parce que la demande de changement passe par leur équipe de conformité. L’intégration est hors ligne deux jours. La leçon est que les passerelles NAT ne sont pas le bon outil pour la tâche « donnez à un partenaire une IP stable » — elles n’ont jamais été conçues pour être des endpoints d’entrée publics. NLB avec Elastic IP, oui. Les IP sont allouées à la création du NLB, épinglées par AZ, et ne tournent jamais pendant la vie du NLB.

Ce qui se passe

NLB supporte deux modes d’IP côté public. Le défaut est des IP gérées par AWS qui peuvent tourner (rare, mais techniquement possible lors d’événements d’AZ). Le mode que vous voulez pour les listes blanches partenaires est Elastic IP, une par zone de disponibilité où le NLB vit. L’Elastic IP est allouée séparément, attachée au NLB à la création, et reste attachée jusqu’à ce que vous supprimiez le NLB. L’IP ne peut pas être changée sur place — pour donner au partenaire une nouvelle IP, vous construisez un nouveau NLB.

Les propriétés que cela vous donne :

Pas de rotation. Les Elastic IP ne changent pour aucune raison opérationnelle à moins du remplacement du NLB. Les instances cibles peuvent aller et venir, les target groups peuvent être recâblés, les groupes de sécurité peuvent être mis à jour — l’IP que le partenaire voit est constante.
Une IP par AZ. Un NLB à trois AZ a trois Elastic IP. La liste blanche du partenaire a besoin des trois. DNS résout vers les trois en round-robin ; le client en choisit une et se connecte.
Pas de SNAT pour les IP client. NLB préserve l’IP source du client de bout en bout par défaut. Le partenaire voit l’IP du client, pas l’IP du NLB, quand la connexion arrive à la cible. C’est l’inverse du problème d’égress statique — pour l’égress, l’IP du NLB est ce que le pare-feu du partenaire voit comme source.
L’équilibrage cross-zone est optionnel. Avec cross-zone désactivé, le trafic qui atterrit sur l’IP de us-east-1a n’atteint que les cibles dans us-east-1a. Avec cross-zone activé, l’IP dans us-east-1a peut atteindre n’importe quelle cible dans n’importe quelle AZ. Le défaut est désactivé ; activez-le pour la plupart des charges applicatives.

Les cas d’usage que cela permet :

Listes blanches partenaires. Intégrations B2B où le pare-feu du partenaire n’autorise que le trafic depuis un ensemble spécifique d’IP source. Vous lui donnez les Elastic IP du NLB au moment de l’intégration et n’y touchez plus jamais.
Règles de pare-feu sur site. Votre application est accessible depuis un réseau sur site via Direct Connect ou VPN, et le pare-feu sur site a une règle clé sur l’IP de destination. Les Elastic IP du NLB rendent cette règle stable.
Contrôles géographiques basés sur IP. Certains régimes de conformité exigent que le trafic atterrisse à une IP spécifique documentée dans le système d’enregistrement. L’IP du NLB vit dans ce document et ne bouge pas.
Intégrations contournant le DNS. Quelques clients hérités se connectent par IP plutôt que par hôte. Les Elastic IP du NLB leur permettent de continuer à fonctionner sans forcer un changement de code côté client.

Ce que cela ne vous donne pas : les fonctions de couche HTTP. NLB est L4. Si l’intégration partenaire est HTTPS et que vous avez aussi besoin de WAF, OIDC, ou routage par chemin, le pattern est chaîne NLB → ALB — le NLB est la couche publique avec Elastic IP, et transfère vers un ALB en tant que cible par IP. ALB fait le travail L7 ; la liste blanche du partenaire pointe vers les IP du NLB.

Comment vérifier

Provisionner d’abord les Elastic IP, puis le NLB :

# Allouer une Elastic IP par AZ que le NLB va utiliser
EIP_A=$(aws ec2 allocate-address --domain vpc --query 'AllocationId' --output text)
EIP_B=$(aws ec2 allocate-address --domain vpc --query 'AllocationId' --output text)
EIP_C=$(aws ec2 allocate-address --domain vpc --query 'AllocationId' --output text)

# Créer le NLB avec ces EIP attachées à des sous-réseaux spécifiques
aws elbv2 create-load-balancer \
  --name partner-nlb-prod \
  --type network \
  --scheme internet-facing \
  --subnet-mappings \
    SubnetId=subnet-aaa,AllocationId=$EIP_A \
    SubnetId=subnet-bbb,AllocationId=$EIP_B \
    SubnetId=subnet-ccc,AllocationId=$EIP_C

Confirmer les IP sur le NLB en cours (c’est ce que vous envoyez au partenaire) :

aws ec2 describe-addresses \
  --allocation-ids "$EIP_A" "$EIP_B" "$EIP_C" \
  --query 'Addresses[].{IP:PublicIp,Allocation:AllocationId}' \
  --output table

Vérifier que ces IP sont bien ce que le partenaire voit réellement, depuis l’extérieur d’AWS :

# Résoudre le nom d'hôte NLB depuis l'extérieur d'AWS et vérifier que chaque réponse est une des EIP
dig +short partner-nlb-prod-abc123.elb.us-east-1.amazonaws.com

La sortie devrait être les trois Elastic IP. Si DNS retourne une IP différente, le NLB utilise des IP gérées par AWS au lieu d’EIP — le subnet-mapping au moment de la création était mauvais.

Pour le cas d’égress (le partenaire voit votre trafic comme venant de ces IP), le NLB fait du SNAT vers ses propres IP quand la cible initie une connexion de retour vers le client. L’IP source que le partenaire voit est une des EIP. Confirmez avec une connexion de test depuis une cible vers l’endpoint partenaire pendant que vous regardez les journaux du partenaire.

Pour le cas d’entrée (trafic partenaire qui atterrit à votre NLB), l’IP client est préservée par le NLB par défaut. Les cibles voient la vraie IP client dans leurs journaux serveur. Si les cibles sont des EC2 avec des groupes de sécurité, les règles de groupe de sécurité doivent autoriser le trafic depuis la plage IP du client, pas depuis l’IP du NLB — c’est une source fréquente de tickets « le NLB est en marche mais mes cibles rejettent la connexion ».

La correction

Le runbook de déploiement pour une nouvelle intégration partenaire :

Allouer les Elastic IP d’abord, comme étape séparée avant le NLB. L’ID d’allocation est un artéfact à long terme ; le NLB est un artéfact à plus court terme. Étiquetez les EIP avec le nom du partenaire et l’environnement.
Construire le NLB avec des subnet-mappings explicites. Ne laissez pas Terraform ou CloudFormation défaillir vers des IP gérées par AWS.
Confirmer que les EIP sont attachées et que DNS résout vers elles. Envoyez les trois IP au partenaire avant toute autre étape d’intégration.
Épingler le côté partenaire. La liste blanche du partenaire va dans les deux directions : entrée (trafic partenaire depuis leurs IP vers votre NLB) et sortie (votre trafic depuis les IP du NLB vers leur endpoint). Le côté sortie est souvent oublié au premier tour et découvert la première fois qu’une cible tend la main.
Documenter les IP comme artéfacts de production. Un README dans le dépôt de déploiement, une ligne dans le runbook d’intégration, une étiquette sur les ressources. Les IP survivent à votre mandat ; la mémoire institutionnelle de pourquoi elles existent doit aussi.

Le plan de migration pour quand vous devez swapper le NLB sous-jacent (migration de compte, changement de région, ou un changement architectural majeur) :

Construire le nouveau NLB avec de nouvelles Elastic IP en parallèle. Ne touchez pas encore à l’ancien.
Pré-avertir le partenaire avec les nouvelles IP. Le changement de leur liste blanche a un délai — généralement 5 à 30 jours ouvrés pour un partenaire réglementé. Soumettez la demande bien avant la date de migration.
Exécuter les deux NLB en parallèle pendant la fenêtre de bascule. Le DNS du côté partenaire détermine lequel il atteint ; avec les deux en liste blanche, la connexion réussit dans tous les cas. Utilisez le DNS pondéré ou un basculement CNAME pour déplacer le trafic.
Décommissionner l’ancien NLB seulement après que le partenaire confirme que le changement de liste blanche est en vigueur. Une entrée en liste blanche orpheline sur les anciennes IP n’est pas un problème ; une entrée manquante sur les nouvelles IP est une panne.
Libérer les anciennes Elastic IP seulement après une période de quarantaine. Une fois libérée, une EIP retourne au pool AWS et peut être réallouée à quelqu’un d’autre. Garder les anciennes IP allouées pendant quelques semaines après la bascule est une assurance bon marché contre un rollback.

Trois règles que nous tenons :

EIP allouées, jamais auto-gérées. Un NLB face partenaire qui n’a pas d’Elastic IP est une future panne. Faites de l’allocation EIP une porte dure dans le gabarit de déploiement.

Trois IP par partenaire, pas une. Envoyer au partenaire une IP et pas les deux autres signifie que la liste blanche du partenaire ne couvre pas une AZ. La connexion atterrit dans cette AZ, le partenaire la rejette, panne intermittente.

Documenter les IP dans le contrat d’intégration. Quand l’intégration est renégociée ou que le partenaire est acquis, les IP font partie de l’artéfact contractuel. Traitez-les comme tout autre identifiant de production à long terme.

Pour les fonctions L7 que vous pouvez aussi vouloir derrière le NLB, voir Règles de listener ALB — routage par hôte et par chemin. Pour la comparaison de quand NLB est le bon choix versus ALB, voir ALB vs NLB vs GWLB.

Stack Harbor conçoit les topologies ALB + NLB et le modèle d’opération autour dans le cadre de l’onboarding Gestion AWS et des Environnements infogérés en continu. Si vos intégrations partenaires sont épinglées à une passerelle NAT qui n’a jamais été conçue pour être en entrée, commencez par une consultation d’infrastructure.