AWS 단일 터널 알림: 실제로 중요해지는 때

터널 하나가 다운되었다는 AWS Health 알림은 보통 아무것도 고장 나 보이지 않을 때 옵니다. 바로 그래서 무시됩니다. 이 알림은 장애를 설명하는 것이 아니라 AWS의 관찰 창을 넘겨 지속된 이중화 상태를 설명합니다. 조치할지 여부는 대시보드가 어떻게 보이는지가 아니라 설계가 무엇을 견딜 수 있는지에 달려 있습니다.

알림이 실제로 측정한 것

모든 Site-to-Site 연결에는 서로 다른 AWS 엔드포인트에서 종료되는 터널 두 개가 있습니다. AWS 모니터링 문서는 이중화를 위해 둘 다 구성할 것을 권장하며, 하나가 문서화된 기간 동안 다운 상태로 남으면 알림을 올립니다. 그 기간이 중요한 이유는 짧은 흔들림과 영구적 상실이 하나의 그래프에서는 똑같아 보이기 때문입니다.

연결의 전체 상태가 아니라 터널별 원격 측정을 읽으세요. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' 는 각 터널의 상태와 메시지를 반환하며, 그것이 알림의 근거가 되는 증거입니다.

대응을 결정하는 세 가지 조건

이것이 티켓인지 어깨를 으쓱할 일인지 정하기 전에 세 가지를 살펴보세요.

첫째, 살아남은 터널이 대역폭 상한과 광고하는 프리픽스를 포함해 부하를 감당할 수 있습니까? 둘째, 생성 이후 계속 다운된 두 번째 터널이 올라온 적이 한 번도 증명되지 않았다면 장애 조치가 실제로 일어납니까? 셋째, 다음에 계획한 변경이 두 터널을 동시에 내린다면 겉모습의 경고가 유지보수 창 문제로 바뀝니다. 어느 하나라도 아니오이거나 알 수 없다면 그 알림은 실제 발견입니다.

세 가지가 모두 입증 가능하게 괜찮다면 왜 허용 가능한지 적고 넘어가세요. 그 메모는 다음 분기 논쟁보다 값집니다.

대기 피어가 증명하지 않는 것

백업 피어가 구성된 고객 게이트웨이는 AWS가 건강한 터널 두 개를 본다는 증거가 아닙니다. 고객 측은 새 협상을 필요로 하는 콜드 피어를 유지할 수 있고, 그것은 정당한 설계일 수 있습니다. 그래도 두 개의 살아 있는 터널과 같은 관찰은 아닙니다.

물리적 라우터 두 대도 반대 경우를 고치지 못합니다. 두 터널이 한 장치에서 종료되거나 하나의 업링크로 나간다면 이중화는 종이 위에만 존재합니다.

변경을 영향 범위에 맞추세요

AWS의 엔드포인트 교체 문서 는 사례를 구분하며 그 차이는 놓치기 쉽습니다. AWS가 관리하는 업데이트는 한 번에 터널 하나에 적용됩니다. 고객이 시작한 대상 게이트웨이, 고객 게이트웨이 또는 연결 옵션 변경은 대체 엔드포인트가 준비되는 동안 두 터널을 모두 사용할 수 없게 만듭니다.

단일 터널의 옵션 변경은 자체적으로 명시된 영향이 있는 세 번째 사례입니다. 그 터널은 자체 업데이트 동안 사용할 수 없고 다른 하나는 계속 동작합니다.

필요해지기 전에 대안을 증명하세요

사건을 기다리는 대신 테스트를 예약하세요. 건강한 터널을 유지보수 창 안에서 내리고, 대안이 협상하는지 확인한 다음 실제 트래픽이 양방향으로 지나가는지 확인하세요. 터널 상태뿐 아니라 반환 라우팅도 점검하세요. 두 번째 단계의 불일치는 터널을 올려 둔 채 워크로드를 죽이기 때문입니다. 그곳에 있는 동안 전환 시간도 측정하세요.

알림, 원격 측정 출력, 변경 계획을 하나의 기록에 보관하세요. 그 기록은 다음 분기 알림을 누군가 백업을 시험한 적이 있는지에 대한 논쟁이 아니라 두어 분짜리 검토로 바꿉니다.