Уведомление AWS об одном туннеле: когда оно действительно важно

Уведомление AWS Health о том, что один туннель не работает, обычно приходит, когда ничего не выглядит сломанным. Именно поэтому его игнорируют. Уведомление описывает не сбой, а состояние резервирования, которое длится дольше окна наблюдения AWS. Ваши действия зависят от того, что выдержит ваша архитектура, а не от того, как выглядит панель.

Что уведомление на самом деле измерило

У каждого соединения Site-to-Site два туннеля, которые завершаются на разных конечных точках AWS. Документация AWS по мониторингу рекомендует настраивать оба для резервирования и поднимает уведомление, если один остаётся недоступным в течение документированного периода. Этот период важен, потому что краткое колебание и постоянная потеря выглядят одинаково на одном графике.

Читайте телеметрию каждого туннеля, а не общее состояние соединения. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' возвращает статус и сообщение для каждого туннеля, и это те доказательства, на которых основано уведомление.

Три условия, определяющие вашу реакцию

Пройдите по всем трём, прежде чем решать, это заявка или пожатие плечами.

Во-первых, может ли выживший туннель нести нагрузку, включая любой предел пропускной способности и объявляемые префиксы? Во-вторых, происходит ли переключение на самом деле, учитывая, что второй туннель, недоступный с момента создания, никогда не был доказанно поднят? В-третьих, не отключит ли ваше следующее плановое изменение оба туннеля сразу, что превращает косметическое предупреждение в проблему окна обслуживания. Если хотя бы один ответ — нет или неизвестно, уведомление является реальной находкой.

Если все три доказуемо в порядке, запишите, почему это допустимо, и двигайтесь дальше. Эта заметка ценнее спора в следующем квартале.

Что резервный peer не доказывает

Клиентский шлюз с настроенным резервным peer не является доказательством того, что AWS видит два здоровых туннеля. Клиентская сторона может держать холодный peer, которому нужны новые переговоры, и это может быть законным решением. Но это всё равно не то же наблюдение, что два живых туннеля.

Два физических маршрутизатора тоже не исправляют обратный случай. Когда оба туннеля завершаются на одном устройстве или выходят через один вышестоящий канал, резервирование существует только на бумаге.

Соразмерьте изменение с радиусом его влияния

Документация AWS об документация о замене конечных точек разделяет случаи, и это различие легко пропустить. Обновления под управлением AWS применяются к одному туннелю за раз. Изменения, инициированные клиентом, в целевой шлюзе, клиентском шлюзе или параметрах соединения делают оба туннеля недоступными, пока готовятся заменяющие конечные точки.

Изменение параметров на одном туннеле — третий случай с собственным заявленным влиянием: этот туннель недоступен во время своего обновления, а другой продолжает работать.

Докажите альтернативу, прежде чем она понадобится

Запланируйте тест вместо ожидания события. Отключите здоровый туннель в окне обслуживания, убедитесь, что альтернатива договаривается, затем убедитесь, что реальный трафик проходит через неё в обоих направлениях. Проверьте обратную маршрутизацию и состояние туннеля, потому что несоответствие второй фазы оставляет туннель поднятым, а рабочую нагрузку мёртвой. Измерьте время перехода, пока вы там.

Храните уведомление, вывод телеметрии и план изменений в одной записи. Эта запись превращает уведомление следующего квартала в двухминутный обзор, а не в спор о том, проверял ли кто-нибудь когда-нибудь резерв.