AWS-meddelande om en enda tunnel: när det faktiskt spelar roll

Ett AWS Health-meddelande om att en tunnel ligger nere kommer vanligtvis när ingenting verkar trasigt. Det är just därför det avfärdas. Meddelandet beskriver inte ett avbrott; det beskriver ett redundantstillstånd som har pågått längre än AWS observationsfönster. Om du agerar beror på vad din design klarar, inte på hur instrumentpanelen känns.

Vad meddelandet faktiskt mätte

Varje Site-to-Site-anslutning har två tunnlar som terminerar på olika AWS-slutpunkter. AWS dokumentation för övervakning rekommenderar att båda konfigureras för redundans och höjer aviseringen när en ligger nere under den dokumenterade perioden. Den perioden spelar roll, eftersom ett kort flimmer och en permanent förlust ser identiska ut i en enda graf.

Läs telemetri per tunnel i stället för anslutningens övergripande tillstånd. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' returnerar status och meddelande för varje tunnel, och det är beviset som meddelandet bygger på.

Tre villkor som avgör din reaktion

Gå igenom de tre innan du bestämmer om detta är ett ärende eller en axelryckning.

För det första, kan den överlevande tunneln bära lasten, inklusive eventuellt bandbreddstak och de prefix den annonserar? För det andra, sker redundansväxlingen verkligen, med tanke på att en andra tunnel som legat nere sedan skapandet aldrig har bevisats komma upp? För det tredje, skulle din nästa planerade ändring ta ner båda tunnlarna samtidigt, vilket gör en kosmetisk varning till ett underhållsfönsterproblem. Om något svar är nej eller okänt är meddelandet ett verkligt fynd.

Om alla tre är bevisligen i ordning, skriv ner varför det är tolerabelt och gå vidare. Den anteckningen är värd mer än diskussionen nästa kvartal.

Vad en standby-peer inte bevisar

En kundgateway med konfigurerad reservpeer är inte bevis för att AWS ser två friska tunnlar. Kundsidan kan hålla en kall peer som behöver en ny förhandling, och det kan vara en legitim design. Det är ändå inte samma observation som två levande tunnlar.

Två fysiska routrar löser inte heller det motsatta fallet. När båda tunnlarna terminerar på en enda enhet eller går ut genom en enda uplänk finns redundansen bara på papperet.

Anpassa ändringen till dess påverkansradie

AWS dokumentation om byte av slutpunkter skiljer på fallen, och skillnaden är lätt att missa. AWS-hanterade uppdateringar tillämpas på en tunnel i taget. Kundinitierade ändringar av mål-gatewayen, kundgatewayen eller anslutningsalternativen gör båda tunnlarna otillgängliga medan ersättningsslutpunkter tillhandahålls.

Att ändra alternativ på en enda tunnel är ett tredje fall med sin egen angivna påverkan: den tunneln är otillgänglig under sin egen uppdatering och den andra fortsätter att köra.

Bevisa alternativet innan du behöver det

Schemalägg testet i stället för att vänta på händelsen. Ta ner den friska tunneln inom ett underhållsfönster, bekräfta att alternativet förhandlar och bekräfta sedan att verklig trafik passerar genom det i båda riktningarna. Kontrollera returrutningen samt tunnelstatusen, eftersom en missmatchning i fas två lämnar tunneln uppe och arbetslasten död. Mät övergången medan du är där.

Förvara meddelandet, telemetriutskriften och ändringsplanen i en enda post. Den posten gör nästa kvartals meddelande till en genomgång på två minuter i stället för en debatt om huruvida någon någonsin har testat reserven.