Avis AWS d’un seul tunnel : quand il compte vraiment

Un avis AWS Health indiquant qu’un tunnel est en panne arrive généralement quand rien ne semble cassé. C’est exactement pour cela qu’il est ignoré. L’avis ne décrit pas une panne ; il décrit un état de redondance qui a persisté au-delà de la fenêtre d’observation d’AWS. Que vous agissiez ou non dépend de ce que votre conception peut supporter, et non de ce que le tableau de bord suggère.

Ce que l’avis a réellement mesuré

Chaque connexion Site-to-Site possède deux tunnels, terminés sur des points de terminaison AWS différents. La documentation de surveillance d’AWS recommande de configurer les deux pour la redondance et déclenche la notification quand l’un reste en panne pendant la période documentée. Cette période compte, car un flottement et une perte permanente sont identiques sur un seul graphique.

Lisez la télémétrie par tunnel plutôt que l’état global de la connexion. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' renvoie un état et un message pour chaque tunnel, et c’est la preuve sur laquelle repose l’avis.

Trois conditions qui décident de votre réponse

Examinez les trois avant de décider s’il s’agit d’un ticket ou d’un haussement d’épaules.

Premièrement, le tunnel survivant peut-il porter la charge, y compris tout plafond de bande passante et les préfixes qu’il annonce ? Deuxièmement, le basculement se produit-il vraiment, étant donné qu’un second tunnel en panne depuis la création n’a jamais été prouvé comme remontant ? Troisièmement, votre prochaine modification planifiée ferait-elle tomber les deux tunnels à la fois, ce qui transforme un avertissement cosmétique en problème de fenêtre de maintenance. Si une réponse est non ou inconnue, l’avis est une constatation réelle.

Si les trois sont manifestement correctes, notez pourquoi c’est tolérable et passez à la suite. Cette note vaut plus que la discussion du trimestre prochain.

Ce qu’un pair de secours ne prouve pas

Une passerelle client avec un pair de secours configuré n’est pas la preuve qu’AWS voit deux tunnels sains. Le côté client peut conserver un pair froid qui nécessite une nouvelle négociation, et cela peut être une conception légitime. Ce n’est toujours pas la même observation que deux tunnels actifs.

Deux routeurs physiques ne règlent pas non plus le cas inverse. Quand les deux tunnels se terminent sur un seul appareil ou sortent par un seul lien montant, la redondance n’existe que sur le papier.

Adaptez la modification à son rayon d’impact

La documentation sur le remplacement des points de terminaison d’AWS sépare les cas, et la distinction est facile à manquer. Les mises à jour gérées par AWS sont appliquées à un tunnel à la fois. Les modifications initiées par le client sur la passerelle cible, la passerelle client ou les options de connexion rendent les deux tunnels indisponibles pendant que des points de terminaison de remplacement sont provisionnés.

Modifier les options d’un seul tunnel est un troisième cas avec son propre impact déclaré : ce tunnel est indisponible pendant sa propre mise à jour et l’autre continue de fonctionner.

Prouvez l’alternative avant d’en avoir besoin

Planifiez le test au lieu d’attendre l’événement. Faites tomber le tunnel sain dans une fenêtre de maintenance, confirmez que l’alternative négocie, puis confirmez que le trafic réel la traverse dans les deux sens. Vérifiez le routage de retour ainsi que l’état du tunnel, car un désaccord de seconde phase laisse le tunnel actif et la charge de travail morte. Chronométrez la transition pendant que vous y êtes.

Conservez l’avis, la sortie de télémétrie et le plan de changement dans un seul enregistrement. Cet enregistrement transforme l’avis du trimestre prochain en une revue de deux minutes plutôt qu’en un débat sur la question de savoir si quelqu’un a déjà testé le secours.