Aller au contenu

AWS Mis à jour le 2026-07-04

Erreurs NAT Gateway et épuisement de l'allocation de ports : symptômes et correctifs

Des délais sortants intermittents à travers une NAT Gateway signifient habituellement ErrorPortAllocation : trop de connexions simultanées vers la même destination. Comment le confirmer et les quatre façons de le régler.

Quand les connexions sortantes à travers une NAT Gateway se mettent à échouer par intermittence sous charge — des délais d’attente, pas des refus, souvent vers une API ou une base de données précise —, la première métrique à consulter est ErrorPortAllocation. Une NAT Gateway peut tenir environ 55 000 connexions simultanées vers chaque destination unique (combinaison IP, port et protocole); au-delà, les nouvelles connexions vers cette destination n’obtiennent aucun port source et meurent en silence. Les correctifs : plus d’adresses IP sources sur la passerelle, plus de passerelles, moins de connexions inactives, ou retirer carrément ce trafic de la NAT avec des points de terminaison VPC.

Ce qui se passe

Une NAT Gateway réécrit chaque connexion sortante pour qu’elle provienne de sa propre Elastic IP, en choisissant un port source libre par connexion. Les ports sont une ressource finie par tuple de destination : pour une IP et un port de destination donnés, une IP source de NAT offre environ 55 000 ports utilisables. Une flotte qui s’éparpille vers des milliers de destinations différentes n’y touche à peu près jamais; cinq cents pods applicatifs qui martèlent un seul point d’API tiers ou une base de données externe, absolument. Quand aucun port n’est libre, la passerelle incrémente ErrorPortAllocation et laisse tomber la tentative — le client ne voit qu’un délai de connexion.

Deux autres modes de défaillance partagent les mêmes symptômes. IdleTimeoutCount monte quand des connexions restent silencieuses au-delà de 350 secondes et que la passerelle les coupe — les applications à connexions longues et surtout inactives (pools de base de données, consommateurs de messages) voient « connection reset by peer » après les périodes creuses, à moins d’envoyer des keepalives plus souvent que ça. Et un PacketsDropCount qui grimpe sans erreurs de ports pointe vers le plafond de bande passante ou une passerelle en mauvais état, pas vers l’épuisement.

Côté capacité, une NAT Gateway s’ajuste automatiquement jusqu’à 100 Gbps et des millions de paquets par seconde, donc le débit brut est rarement la contrainte — la concurrence vers une seule destination, oui. Le levier d’AWS pour ça, ce sont les adresses IPv4 secondaires : une passerelle peut porter plusieurs EIP (jusqu’à huit), et chaque adresse additionnelle multiplie le bassin de ports par destination. La mécanique des coûts compte aussi : vous payez à l’heure par passerelle et au Go traité, donc le même trafic à travers trois passerelles locales à leur AZ coûte le même traitement mais trois frais horaires — et le trafic inter-AZ vers une passerelle unique ajoute des frais de transfert par-dessus; les compromis sont détaillés dans NAT Gateway vs instance NAT.

Quoi vérifier en premier

  • La métrique ErrorPortAllocation — toute valeur non nulle pendant la fenêtre de panne est votre confirmation.
  • IdleTimeoutCount — si les réinitialisations surviennent après des périodes calmes plutôt que sous charge, c’est le minuteur d’inactivité de 350 secondes, pas l’épuisement.
  • La concentration des destinations — le trafic en échec vise-t-il surtout un seul IP:port? Les flow logs répondent vite.
  • Le nombre d’EIP de la passerelle — une seule adresse veut dire un seul bassin de 55 k par destination.
  • Quelles AZ routent par quelle passerelle — une passerelle unique servant trois AZ concentre toute la charge et ajoute des frais inter-AZ.

Comment vérifier

Console : VPC > NAT gateways > sélectionner la passerelle > Monitoring. CLI :

# Erreurs d'allocation de ports sur la fenêtre de l'incident
aws cloudwatch get-metric-statistics \
  --namespace AWS/NATGateway \
  --metric-name ErrorPortAllocation \
  --dimensions Name=NatGatewayId,Value=nat-0abc123 \
  --start-time 2026-07-03T12:00:00Z --end-time 2026-07-03T18:00:00Z \
  --period 300 --statistics Sum

# Les délais d'inactivité et les connexions actives racontent le reste
aws cloudwatch get-metric-statistics \
  --namespace AWS/NATGateway \
  --metric-name ActiveConnectionCount \
  --dimensions Name=NatGatewayId,Value=nat-0abc123 \
  --start-time 2026-07-03T12:00:00Z --end-time 2026-07-03T18:00:00Z \
  --period 300 --statistics Maximum

Pour trouver la destination chaude, interrogez les flow logs de l’ENI de la NAT et groupez par adresse et port de destination — les plus gros parleurs en nombre de connexions, pas en octets. Les définitions de métriques sont dans la documentation Amazon VPC.

Le correctif

  1. Ajoutez des adresses IPv4 secondaires à la passerelle. VPC > NAT gateways > Actions > Edit secondary IP address associations, ou aws ec2 assign-private-nat-gateway-address / associer des EIP additionnelles pour une passerelle publique. Chaque adresse ajoute environ 55 k ports de plus par destination — le soulagement le plus rapide quand une destination chauffe.
  2. Répartissez la charge sur une passerelle par AZ. Si une seule passerelle sert tout le VPC, déployez-en une par AZ et pointez chaque table de routage privée vers sa passerelle locale. Cela divise la concurrence par destination, élimine les frais de données inter-AZ et réduit le rayon d’impact d’une panne d’AZ.
  3. Corrigez le comportement de connexion qui crée la pression. Réutilisez les connexions (HTTP keep-alive, canaux gRPC, pools de base de données dimensionnés délibérément) au lieu d’en ouvrir une par requête; fermez ce que vous ouvrez; activez des keepalives TCP sous 350 secondes pour les connexions longues et inactives afin que la passerelle ne les moissonne pas.
  4. Sortez complètement le trafic vers AWS du chemin NAT. S3 et DynamoDB via des points de terminaison de passerelle, gratuits et sans compteur; ECR, CloudWatch, SQS et compagnie via des points de terminaison d’interface, ce qui élimine à la fois la pression sur les ports et les frais au Go — la logique de sélection est dans points de terminaison VPC : passerelle vs interface.
  5. Pour un éventail massif vers une destination unique, fragmentez par destination. Si une API partenaire est le puits, demandez plusieurs IP de point d’accès ou utilisez leurs noms d’hôte régionaux pour que la limite par tuple s’applique par IP plutôt qu’une seule fois.

Quand c’est la mauvaise approche

N’ajoutez pas de passerelles ou d’EIP quand les métriques disent délai d’inactivité — c’est un problème de keepalive applicatif, et plus de ports ne régleront pas des réinitialisations après des périodes calmes. Ne sortez pas une instance NAT pour « reprendre le contrôle des ports » à moins d’avoir réellement besoin de réglage au niveau paquet et d’accepter de devenir l’opérateur de cette boîte. Et si le trafic en échec est entrant, arrêtez : les NAT Gateways sont sortie seulement, et aucun débogage NAT ne réparera un chemin entrant qui devrait être un ALB ou une EIP.

Erreurs fréquentes

  • Diagnostiquer depuis les seuls journaux applicatifs — les chaînes « timeout » sont identiques pour un blocage de groupe de sécurité, un échec DNS ou un épuisement de ports; seules les métriques de la passerelle les séparent.
  • Augmenter le nombre d’instances pendant l’incident, ce qui multiplie les tentatives de connexion et aggrave l’épuisement.
  • Mettre les trois AZ derrière une seule passerelle pour économiser deux frais horaires, puis payer davantage en transfert inter-AZ et partager un seul domaine de panne.
  • Oublier que les connexions longtemps inactives ont été moissonnées à 350 secondes, et blâmer le service de destination.

Prévention

  • Alertez sur ErrorPortAllocation > 0 et sur la tendance de IdleTimeoutCount — deux signaux précoces et sans ambiguïté.
  • Établissez la base de référence d’ActiveConnectionCount par passerelle pour voir la croissance vers le plafond des trimestres à l’avance.
  • Routez le trafic vers les services AWS par des points de terminaison VPC comme posture par défaut, pas comme réponse à incident.
  • Fixez les maximums de pools de connexions et les intervalles de keepalive comme standards de déploiement pour tout ce qui parle à travers la NAT.
  • Revoyez la topologie NAT (une par AZ, IP secondaires où ça chauffe) chaque fois que la flotte double.

L’épuisement de ports est l’un des rares problèmes AWS doté d’une métrique parfaitement nommée — la discipline, c’est de la regarder avant de redémarrer des choses. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.