들어가며

AWS Site-to-Site VPN은 온프레미스와 AWS VPC를 연결하는 가장 빠르고 간편한 방법입니다. 하지만 운영을 하다 보면 한 번쯤은 이런 경험을 하게 됩니다.

“새벽에 갑자기 VPN 터널이 끊기면서 온프레미스-AWS 간 통신이 중단되었습니다. AWS 측에서 예정된 유지보수라고 하는데, 이걸 왜 미리 몰랐을까요?”

실제로 많은 고객이 AWS Site-to-Site VPN 사용 중 터널 유지보수(Tunnel Endpoint Maintenance)로 인한 서비스 장애를 반복적으로 겪고 있습니다. 그리고 이런 장애의 대부분은 두 가지 공통된 원인에서 비롯됩니다.

1. BGP(Border Gateway Protocol) 대신 Static 라우팅을 사용 중

2. VPN Tunnel Endpoint Lifecycle Control 기능을 활용하고 있지 않음

이 글에서는 AWS Site-to-Site VPN의 터널 동작 방식과 유지보수 메커니즘을 살펴보고, 왜 위 두 가지 원인이 장애로 이어지는지, 그리고 어떻게 예방할 수 있는지 설명합니다.

1. AWS Site-to-Site VPN 터널 구조 다시 보기

AWS Site-to-Site VPN은 하나의 VPN Connection 당 2개의 IPsec 터널을 제공합니다. 이는 단일 터널 장애 시 서비스 연속성을 확보하기 위한 기본 고가용성 설계입니다.

각 터널 엔드포인트는 서로 다른 가용 영역(AZ)에 위치한 독립적인 물리 호스트에서 실행됩니다. AWS는 이 터널 엔드포인트들의 성능과 보안을 개선하기 위해서 지속적으로 유지보수(패치, 업그레이드, 하드웨어 교체 등)하고 있습니다.

2. 왜 Static 라우팅 환경에서는 VPN 터널 유지보수시에 장애가 자주 발생하는가?

VPN 터널 유지보수시에 장애를 자주 경험하는 고객사의 환경을 들여다보면 Site-to-Site VPN을 Static 라우팅으로 운영하는 경우가 상당히 많습니다. Static 라우팅을 사용하는 경우에는 주로 “BGP는 적용이 복잡하다” 거나 “우리 환경은 경로가 단순하다”는 이유로 Static을 선택하게 됩니다. 하지만 터널 유지보수 관점에서는 Static 라우팅이 장애의 주요 원인이 됩니다.

2.1 Static 라우팅의 동작 방식

Static 라우팅은 터널의 실제 상태(UP/DOWN)를 인지하지 못합니다. 이로 인해 라우팅 테이블에 Static으로 명시된 경로는 터널이 다운되었는지 여부와 무관하게 항시 유효하다고 간주되게 됩니다.

이로 인해 터널 유지보수 상황에서 아래와 같은 순서로 트래픽에 영향을 받을 수 있습니다.

• AWS에서 Tunnel 1에 유지보수를 시작하면 Tunnel 1은 DOWN 상태가 됩니다.

• AWS 측에서는 Tunnel 1을 유지보수 하기 이전에 미리 자동으로 트래픽을 Tunnel 2로 전환하여 트래픽 손실이 없도록 하지만, 온프레미스 → AWS 으로 향하는 트래픽은 Static 경로로 인해 Tunnel 1으로 계속 전달되면서 블랙홀(Blackhole) 상태에 놓이게 됩니다.

2.2 BGP 라우팅이라면?

BGP는 VPN 터널 위에서 동작하는 동적 라우팅 프로토콜입니다. BGP를 사용한다면, 예상하지 못한 갑작스러운 연결 장애 상황에서 터널이 다운되면 BGP hold timer(기본 값 30초)에 의해서 최대 30초 이내에 장애가 감지되고 경로가 자동 전환됩니다.

하지만, VPN 터널 유지 보수와 같이 예정된 작업의 경우라면 AWS 측에서는 유지보수를 수행하려고하는 터널의 엔드포인트를 경유하는 트래픽을 다른 가용 터널로 전환하는 과정을 선제적으로 수행합니다. 이를 통해 AWS에서 VPN 터널 유지보수를 수행하더라도 서비스 중인 트래픽 손실을 최소화할 수 있게 됩니다. (참조: Routing during VPN tunnel endpoint updates )

2.3 Static vs BGP Failover 비교

AWS Site-to-Site VPN 서비스에서 가능한 높은 수준의 가용성을 확보하기 위해서는 Static 라우팅보다는 동적 라우팅(BGP)의 사용이 필수적이라고 할 수 있겠습니다.

3. 인프라 운영자가 놓치기 쉬운 Tunnel Endpoint Lifecycle Control

AWS Site-to-Site VPN에서 동적 라우팅(BGP)을 사용하면 온프레미스와 AWS 간에 안정적인 연결성을 확보할 수 있습니다. 다만 고객이 AWS의 유지보수 시점을 직접 제어할 수는 없으므로, 유지보수 과정에서 발생할 수 있는 예기치 못한 영향까지 완벽히 대비하기는 어렵습니다.

이러한 한계를 보완하기 위해 AWS는 VPN Tunnel Endpoint Lifecycle Control 기능을 제공합니다. 아직 많은 고객이 인지하지 못하고 있지만, 이 기능을 활용하면 유지보수 시점을 고객이 직접 제어할 수 있습니다.

3.1 Tunnel Endpoint Lifecycle Control이란?

기본적으로 AWS는 터널 엔드포인트의 유지보수를 정해진 스케줄에 따라 자동으로 수행하며, 고객은 이 시점을 직접 선택할 수 없습니다.

1. AWS Site-to-Site VPN 의 유지 보수 절차(Tunnel Endpoint Lifecycle Control 미적용시)

• 유지보수 시점을 AWS가 결정하며 사전 스케줄 조정 불가 (업무 시간, 트래픽 피크 시간에도 발생 가능)

• 운영자는 장애 알람이 울린 후에야 유지보수 사실을 인지

b. Lifecycle Control을 활성화 했을 경우, AWS Site-to-Site VPN 의 유지 보수 절차

• 유지보수 사전 알림 수신 → 운영자가 시점을 선택하여 교체

• BGP와 함께 사용 시 서비스 영향 없이 투명하게 교체 가능

• 일정 기간 내 미조치 시 AWS가 강제 교체하므로 유지보수 자체가 누락되지는 않음

3.2 Tunnel Endpoint Lifecycle Control은 어떻게 활성화하나요?

Site-to-Site VPN Connection 생성 시 또는 기존 Connection에서 각 터널 별로 설정할 수 있습니다.

a. AWS Console 설정 예시

Step 1. VPC → Site-to-Site VPN Connections

Step 2. 대상 VPN Connection 선택 → Modify VPN tunnel options

Step 3. 각 터널에 대해 Enable tunnel endpoint lifecycle control 체크

Tunnel maintenance 세부 옵션

Modify VPN tunnel options 화면 하단의 Tunnel maintenance 섹션에는 아래 두 가지 옵션이 제공됩니다.

옵션	설명	동작
Tunnel endpoint lifecycle control (Turn on)	터널 엔드포인트 교체 일정을 고객이 제어	ON: 유지보수 사전 알림 수신 + 수동 교체 가능 OFF: AWS 스케줄에 따라 임의 시점에 자동 교체
Skip tunnel replacement	이번 옵션 변경을 즉시 터널 교체 없이 적용할지 여부	ON: 설정만 저장, 실제 엔드포인트 교체는 다음 유지보수 주기 또는 수동 교체 시점으로 연기 OFF: 설정 저장과 동시에 엔드포인트를 즉시 재생성 → 순간적 터널 Down 발생

ℹ️

언제 Skip tunnel replacement를 체크해야 하나?

VPN 터널 설정 변경 API(ModifyVpnTunnelOptions)로 터널 속성(PSK, IKE/IPsec 알고리즘, DPD Timeout, Lifecycle Control 설정 자체 등)을 변경할 시에는 기본적으로 AWS는 해당 터널 엔드포인트를 즉시 교체하여 새 구성을 적용합니다.

• 운영 중인 VPN에서 Lifecycle Control을 사후에 켜는 경우 → Skip tunnel replacement 체크 권장 ; 설정만 저장되고 실제 교체는 다음 유지보수(또는 운영자가 선택한 시점)로 미뤄지므로 서비스 영향이 없습니다.

• PSK 회전, 암호화 알고리즘 강화 등 “지금 당장 적용되어야 하는” 보안 변경 → 체크 해제 즉시 새 구성으로 교체되며, 이 경우에도 BGP가 구성되어 있다면 반대편 터널로 Failover되어 영향이 최소화됩니다.

⚠️

Skip tunnel replacement 는 정기 유지보수를 영구히 건너뛰는 기능이 아닙니다.

AWS가 수행하는 터널 엔드포인트 교체 자체를 거부할 수는 없으며, 어디까지나 “이번 옵션 변경에 수반되는 교체”를 연기하는 스위치입니다.

b. AWS CLI 예시

aws ec2 describe-vpn-connections \
  --vpn-connection-ids <vpn-id> \
  --query 'VpnConnections[0].Options.TunnelOptions[*].{OutsideIp:OutsideIpAddress,Lifecycle:EnableTunnelLifecycleControl}' \
  --output table

aws ec2 modify-vpn-tunnel-options \
  --vpn-connection-id <vpn-id> \
  --vpn-tunnel-outside-ip-address <tunnel-endpoint-ip> \
  --tunnel-options '{"EnableTunnelLifecycleControl": true}' \
  --skip-tunnel-replacement

3.3 Tunnel Endpoint Lifecycle Control을 통해 유지 보수 알림은 어떻게 받나요?

Lifecycle Control을 활성화한 이후에는 아래 경로로 유지보수 이벤트를 수신할 수 있습니다.

• AWS Console
  • AWS Console에서 [ AWS Health Dashboard > Your account health ] 을 통해 VPN 터널 유지보수에 대한 이벤트 알람을 수신할 수 있습니다.
  • Affected resources에서 해당 알람에 영향을 받는 리소스 id를 확인 할 수 있습니다.

    

• AWS CLI
  • AWS CLI에서 get-vpn-tunnel-replacement-status 명령을 사용하면 해당 터널의 예정된 유지 보수 시점을 확인할 수 있습니다.

  aws ec2 get-vpn-tunnel-replacement-status \
      --vpn-connection-id <vpn-id> \
      --vpn-tunnel-outside-ip-address <tunnel-endpoint-ip>

3.4 Tunnel Endpoint Lifecycle Control 을 사용한 유지보수 작업 수행

알림을 수신한 후, 운영자는 서비스 영향이 적은 시간대에 다음과 같이 터널을 한 쪽씩 순차적으로 교체합니다.

수동 VPN 터널 유지 보수 절차

BGP가 구성되어 있다면 AWS에서는 VPN 터널을 하나씩 교체하는 동안 다른 쪽 터널로 트래픽을 전환한 이후에 해당 터널을 교체하기 때문에 서비스 영향을 최소화할 수 있습니다. 반대로, Static 라우팅 상태에서는 트래픽에 대한 사전 전환 조치가 이루어지지 않기 때문에 서비스 중단없이 터널 교체를 수행하기 어렵고 대부분 장시간 서비스 장애로 이어집니다. 이것이 BGP와 Lifecycle Control을 함께 사용해야 하는 이유입니다.

• AWS Console 설정

  Tunnel Endpoint Lifecycle Control이 활성화된 상태에서 AWS Console 메뉴 [ VPC > VPN 연결 > vpn-tunnel-id > VPN 터널 교체 ] 로 진입하여 VPN 터널을 수동으로 교체할 수 있습니다. 한 번에 하나의 터널만 교체하고, BGP 세션 복구와 트래픽 정상 흐름을 확인한 후 다른 터널을 교체해야 서비스 영향을 최소화할 수 있습니다.

  

• AWS CLI 설정

  AWS CLI를 사용할 경우 먼저 VPC 연결 상태와 터널 상태를 조회하고 난뒤 대상 터널을 하나씩 번갈아가면서 수동으로 유지보수를 진행합니다.

  Step 1. 사전 확인 — VPN Connection 및 터널 상태 조회

  터널의 Outside IP, Lifecycle Control 활성화 여부, 현재 터널 UP/DOWN 상태, 보류 중인 유지보수(PendingMaintenance) 유무를 확인합니다.

  # VPN Connection 식별자 및 터널 Outside IP 조회
  aws ec2 describe-vpn-connections \
    --vpn-connection-ids <vpn-id> \
    --query 'VpnConnections[0].Options.TunnelOptions[*].{OutsideIp:OutsideIpAddress,LifecycleControl:EnableTunnelLifecycleControl}' \
    --output table
  
  # 각 터널의 보류중인 유지보수 상태 확인
  aws ec2 get-vpn-tunnel-replacement-status \
      --vpn-connection-id <vpn-id>  \
      --vpn-tunnel-outside-ip-address <tunnel-endpoint-ip> \
      --output table
  

  Step 2. Tunnel 1 엔드포인트 수동 교체

  먼저 교체할 터널(예: Tunnel 1)의 Outside IP를 지정하여 교체를 요청합니다. --apply-pending-maintenance를 지정하면 AWS가 예정한 유지보수를 즉시 적용합니다.

  # AWS Site-to-Site VPN 터널 상태(BGP Status)가 모두 UP된 것을 확인
  aws ec2 describe-vpn-connections \
    --vpn-connection-ids <vpn-id>  \
    --query 'VpnConnections[0].VgwTelemetry[*].{OutsideIp:OutsideIpAddress,Status:Status,LastStatusChange:LastStatusChange,StatusMessage:StatusMessage}' \
    --output table
    
  # AWS Site-to-Site VPN Tunnel1 교체 진행
  aws ec2 replace-vpn-tunnel \
    --vpn-connection-id <vpn-id> \
    --vpn-tunnel-outside-ip-address <tunnel-endpoint-ip> \
    --apply-pending-maintenance

  Step 3. Tunnel 1 엔드 포인트 상태 확인후 Tunnel 2 터널 수동 교체

  Tunnel 1이 UP 상태로 돌아오고 BGP 세션 및 경로가 정상 재수립된 것을 확인하고 난 뒤에 두번째 터널을 교체합니다. (꼭, 터널이 두개가 up 된 것을 먼저 확인하고 나서 두번째 터널 교체를 진행합니다.)

  # AWS Site-to-Site VPN 터널 상태(BGP Status)가 모두 UP된 것을 확인
  aws ec2 describe-vpn-connections \
    --vpn-connection-ids <vpn-id>  \
    --query 'VpnConnections[0].VgwTelemetry[*].{OutsideIp:OutsideIpAddress,Status:Status,LastStatusChange:LastStatusChange,StatusMessage:StatusMessage}' \
    --output table
    
  # AWS Site-to-Site VPN Tunnel2 교체 진행
  aws ec2 replace-vpn-tunnel \
    --vpn-connection-id <vpn-id> \
    --vpn-tunnel-outside-ip-address <tunnel-endpoint-ip> \
    --apply-pending-maintenance

  ⚠️

  주의사항

  • 절대로 두 터널을 동시에 교체하지 마십시오. 반드시 한 터널씩 순차적으로 교체하고, 앞 터널이 완전히 복구된 후 다음 터널로 넘어가야 합니다.

  • Static 라우팅 환경에서는 이 절차 수행 시에도 DPD 감지 지연 동안 블랙홀이 발생할 수 있습니다. BGP 동적 라우팅과 함께 사용할 때에만 무중단 수준의 교체가 가능합니다.

  • 보안 취약점 패치 등 Critical Update의 경우 Lifecycle Control에 의한 고객 주도 교체 기한이 매우 짧거나 AWS가 즉시 강제 교체를 수행할 수 있습니다. AWS Health Dashboard의 마감 기한(deadline)을 반드시 확인하세요.

4. 검증 테스트: Lifecycle Control을 활용한 VPN 터널 무중단 교체

다음은 AWS Site-to-Site VPN을 BGP 프로토콜을 사용하여 운영하는 경우에 Tunnel Endpoint Lifecycle Control을 사용한 터널 유지보수 테스트 결과입니다.

테스트 시나리오 개요

• 목표: BGP + Lifecycle Control 환경에서 사용자 지정 시점 터널 교체 시 트래픽 무중단을 검증

• 환경 구성:
  • AWS 측: Transit Gateway + Site-to-Site VPN (BGP, Lifecycle Control 활성화)
  • On-prem 측 : Customer Gateway에는 Cisco IOS 라우터를 사용하였으며, AWS Console에서 download 한 VPN 연결 설정 파일에서 인터페이스 이름만 변경하여 사용
  • 모니터링: 연속 ping (온프레미스 → AWS EC2)으로 패킷 손실 측정

Step 1: 사전 환경 확인

테스트를 시작하기 전, VPN 연결이 정상 상태인지 확인합니다. 두 터널이 모두 UP이고, 양쪽에서 BGP 세션이 Established 상태여야 합니다. 또한 Tunnel Endpoint Lifecycle Control이 활성화되어 있는지 반드시 확인합니다. 이 단계에서 비정상이 발견되면 테스트 결과의 신뢰성을 보장할 수 없으므로, 문제를 해결한 후 진행해야 합니다. 특히 CGW 라우터에서 두 터널의 BGP Weight/Local Preference가 동일하게 설정되어 있는지 확인합니다 — 다르게 설정되어 있으면 AWS의 MED 시그널이 무시되어 Failover가 정상 동작하지 않습니다.

1. AWS Console에서의 VPN Connection 상세 체크리스트
   • VPN Connection 상세 – 두 터널 모두 UP 상태 확인
   • 각 터널 옵션에서 Tunnel endpoint lifecycle control = On 확인

   

2. CGW 라우터
   • BGP neighbor 상태 – 두 피어 모두 established 확인

   	$ show ip bgp summary                                                               
     BGP router identifier 172.20.11.1, local AS number 65000                               
     BGP table version is 16, main routing table version 16                                 
     2 network entries using 496 bytes of memory                                            
     3 path entries using 408 bytes of memory                                               
     2/2 BGP path/bestpath attribute entries using 576 bytes of memory                      
     1 BGP AS-PATH entries using 24 bytes of memory                                         
     0 BGP route-map cache entries using 0 bytes of memory                                  
     0 BGP filter-list cache entries using 0 bytes of memory                                
     BGP using 1504 total bytes of memory                                                   
     BGP activity 5/3 prefixes, 16/13 paths, scan interval 60 secs                          
     3 networks peaked at 16:22:29 May 7 2026 KST (3w4d ago)                                
                                                                                            
     Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
     169.254.51.77   4        65001   51439   54005       16    0    0 5d22h           1    
     169.254.227.77  4        65001   51439   54075       16    0    0 5d22h           1  

   • Routing table – 두 터널을 경유하는 BGP 경로 확인 (동일한 weight / LP)

   	$ show ip bgp                                                                
     BGP table version is 16, local router ID is 172.20.11.1                         
     Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
                   r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,  
                   x best-external, a additional-path, c RIB-compressed,             
                   t secondary path, L long-lived-stale,                             
     Origin codes: i - IGP, e - EGP, ? - incomplete                                  
     RPKI validation codes: V valid, I invalid, N Not found                          
                                                                                     
          Network          Next Hop            Metric LocPrf Weight Path             
      *    10.1.1.0/24      169.254.51.77          100             0 65001 i         
      *>                    169.254.227.77         100             0 65001 i         
      *>   172.20.11.0/24   0.0.0.0                  0         32768 i 

Step 2: 정상 상태 확인 및 모니터링 (Baseline)

교체 작업 전 정상 상태의 네트워크 성능을 기록합니다. 온프레미스에서 AWS VPC 내 EC2인스턴스로(10.1.1.10) 연속 ping을 시작하여, 교체 전후의 패킷 손실을 정량적으로 비교할 수 있는 기준선을 확보합니다. ping 간격은 100ms(-i 0.1)로 설정하여 미세한 손실도 감지할 수 있도록 합니다. 또한 현재 트래픽이 어느 터널을 통해 흐르고 있는지 확인합니다.

$ ping -i 0.1 10.1.1.10
PING 10.1.1.10 (10.1.1.10) 56(84) bytes of data.
64 bytes from 10.1.1.10: icmp_seq=1 ttl=124 time=6.87 ms
64 bytes from 10.1.1.10: icmp_seq=2 ttl=124 time=5.88 ms
64 bytes from 10.1.1.10: icmp_seq=3 ttl=124 time=6.67 ms
64 bytes from 10.1.1.10: icmp_seq=4 ttl=124 time=5.42 ms
64 bytes from 10.1.1.10: icmp_seq=5 ttl=124 time=6.21 ms
..<snipped>..
64 bytes from 10.1.1.10: icmp_seq=1091 ttl=124 time=5.54 ms
64 bytes from 10.1.1.10: icmp_seq=1092 ttl=124 time=5.97 ms
64 bytes from 10.1.1.10: icmp_seq=1093 ttl=124 time=6.18 ms
64 bytes from 10.1.1.10: icmp_seq=1094 ttl=124 time=5.69 ms
64 bytes from 10.1.1.10: icmp_seq=1095 ttl=124 time=5.67 ms
64 bytes from 10.1.1.10: icmp_seq=1096 ttl=124 time=6.06 ms
64 bytes from 10.1.1.10: icmp_seq=1097 ttl=124 time=5.87 ms
64 bytes from 10.1.1.10: icmp_seq=1098 ttl=124 time=5.90 ms
64 bytes from 10.1.1.10: icmp_seq=1099 ttl=124 time=5.96 ms
64 bytes from 10.1.1.10: icmp_seq=1100 ttl=124 time=6.10 ms
64 bytes from 10.1.1.10: icmp_seq=1101 ttl=124 time=5.57 ms
^C
--- 10.1.1.10 ping statistics ---
1101 packets transmitted, 1101 received, 0% packet loss, time 110793ms
rtt min/avg/max/mdev = 4.763/5.931/17.604/0.650 ms

온프레미스에서 AWS로 연속 ping을 100ms간격으로 보냈을 때, 패킷 손실이 없는 안정적인 상황임을 확인하였습니다.

show ip route <aws ip range> 를 통해서 현재 어느 터널로 트래픽이 흐르는지 확인합니다. 현재 Tunnel2(169.254.227.77)로 라우팅 경로 설정 및 트래픽이 흐르고 있음을 알 수 있습니다.

$ show ip route 10.1.1.0
Routing entry for 10.1.1.0/24
  Known via "bgp 65000", distance 20, metric 100
  Tag 65001, type external
  Last update from 169.254.227.77 6d00h ago
  Routing Descriptor Blocks:
  * 169.254.227.77, from 169.254.227.77, 6d00h ago
      Route metric is 100, traffic share count is 1
      AS Hops 1
      Route tag 65001
      MPLS label: none
      MPLS Flags: NSF

Step 3: 첫 번째 터널 수동 교체 실행

Lifecycle Control이 활성화된 상태에서 AWS Console 또는 CLI를 통해 Tunnel2(현재 경로로 설정되어있는 터널)의 엔드포인트를 수동으로 교체합니다. 교체를 실행하면 AWS는 내부적으로 해당 터널의 BGP MED 값을 높여 트래픽을 다른 터널로 선제 전환한 뒤, 터널 엔드포인트를 새 호스트로 교체합니다. 교체가 완료되면 터널에 새로운 Outside IP가 할당됩니다. 이 과정에서 고객은 어떤 터널을 먼저 교체할지 선택할 수 있으며, 업무 시간 외에 진행하여 만일의 영향을 최소화할 수 있습니다. 교체 실행 시점의 타임스탬프를 반드시 기록합니다.

1. 패킷 손실과 교체를 동시에 확인하기 위해서, 온프레미스에서는 ping명령어를, 라우터에서는 디버그 모드를 활성화 합니다.

2. AWS Console에서 터널을 교체합니다. VPC → Site-to-Site VPN 연결 → 해당 VPN 선택 → Actions → “Replace VPN”

   

3. Tunnel2의 Outside IP address를 선택합니다.

   

4. Replace가 진행되며, VPN state는 Modifying 상태가 됩니다.

   

   • AWS CLI

     aws ec2 replace-vpn-tunnel \
     	--vpn-connection-id <vpn-id> \
     	--vpn-tunnel-outside-ip-address <vpn-tunnel-outside-ip>

Step 4: 교체 진행 중 — BGP Failover 동작 확인

교체가 시작되면 Tunnel 2의 IPsec 세션이 종료되고, 그 위에서 동작하던 BGP 세션도 함께 다운됩니다. BGP Hold Timer(기본 30초, 협상에 따라 다름)가 만료되면 해당 경로가 라우팅 테이블에서 철회(withdraw)되어 모든 트래픽이 Tunnel 1로 전환됩니다. 실제로는 AWS가 교체 전에 MED를 조정하므로, Hold Timer 만료 전에 이미 대부분의 트래픽이 전환되어 있을 수 있습니다. 이 단계에서 핵심은 패킷 손실이 얼마나 발생하는지 정량적으로 측정하는 것입니다. BGP 환경에서는 일반적으로 0~2개 패킷 손실(수백 ms 이내)로 Failover가 완료됩니다.

1. 터널 교체 중 라우터에서의 BGP 변경 로그를 확인합니다.

*Jun  2 07:05:42.755: BGP(0): 169.254.227.77 rcvd UPDATE w/ attr: nexthop 169.254.227.77, origin i, metric 200, merged path 65001, AS_PATH 
*Jun  2 07:05:42.755: BGP(0): 169.254.227.77 rcvd 10.1.1.0/24
*Jun  2 07:05:42.755: BGP(0): Revise route installing 1 of 1 routes for 10.1.1.0/24 -> 169.254.51.77(global) to main IP table
*Jun  2 07:05:42.762: BGP(0): 169.254.227.77 NEXT_HOP is on same subnet as the bgp peer 169.254.51.77 and set to 169.254.51.77 for net 10.1.1.0/24, flags 200, sb: A9FEE34C, mask: FFFFFFFC
*Jun  2 07:05:42.762: BGP(0): (base) 169.254.227.77 send UPDATE (format) 10.1.1.0/24, next 169.254.51.77, metric 100, path 65001
*Jun  2 07:07:43.292: %BGP-3-NOTIFICATION: sent to neighbor 169.254.227.77 4/0 (hold time expired) 0 bytes 
*Jun  2 07:07:43.293: %BGP-5-NBR_RESET: Neighbor 169.254.227.77 reset (BGP Notification sent)
*Jun  2 07:07:43.293: BGP(0): (base) 169.254.51.77 send unreachable (format) 10.1.1.0/24
*Jun  2 07:07:43.293: BGP(0): (base) 169.254.51.77 send UPDATE (format) 172.20.11.0/24, next 169.254.51.78, metric 0, path Local
*Jun  2 07:07:43.293: %BGP-5-ADJCHANGE: neighbor 169.254.227.77 Down BGP Notification sent
*Jun  2 07:07:43.294: %BGP_SESSION-5-ADJCHANGE: neighbor 169.254.227.77 IPv4 Unicast topology base removed from session  BGP Notification sent
*Jun  2 07:08:22.784: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to down
*Jun  2 07:08:22.797: BGP(0): redist event (2) request for 169.254.227.76/30
*Jun  2 07:08:59.279: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to up
*Jun  2 07:08:59.287: BGP(0): redist event (1) request for 169.254.227.76/30
*Jun  2 07:09:04.146: %BGP-5-ADJCHANGE: neighbor 169.254.227.77 Up 
*Jun  2 07:09:04.147: BGP(0): 169.254.227.77 NEXT_HOP is on same subnet as the bgp peer 169.254.51.77 and set to 169.254.51.77 for net 10.1.1.0/24, flags 200, sb: A9FEE34C, mask: FFFFFFFC
*Jun  2 07:09:04.147: BGP(0): (base) 169.254.227.77 send UPDATE (format) 10.1.1.0/24, next 169.254.51.77, metric 100, path 65001
*Jun  2 07:09:04.147: BGP(0): (base) 169.254.227.77 send UPDATE (format) 172.20.11.0/24, next 169.254.227.78, metric 0, path Local
*Jun  2 07:09:05.153: BGP(0): 169.254.227.77 rcvd UPDATE w/ attr: nexthop 169.254.227.77, origin i, metric 100, merged path 65001, AS_PATH 
*Jun  2 07:09:05.153: BGP(0): 169.254.227.77 rcvd 10.1.1.0/24

Tunnel2 교체 과정에 따른 Phase별로 해당 로그를 해석해보면, 아래와 같습니다.

Phase A: AWS가 MED를 올려 트래픽 선제 전환 (07:05:42)

07:05:42.755: 169.254.227.77 rcvd UPDATE … metric 200   ← AWS가 Tunnel 2의 MED를 100→200으로 올림

07:05:42.755: Revise route installing … -> 169.254.51.77  ← best path가 Tunnel 1로 전환됨

→ 해석: AWS가 교체를 시작하기 전에 Tunnel 2의 MED를 200으로 높여서, 라우터가 자동으로 Tunnel 1(MED 100)을 best path로 선택하도록 유도. 이 시점부터 트래픽은 이미 Tunnel 1로 흐르고 있음. 서비스 영향 없음.

────────────────────────────────────────────

Phase B: Tunnel 2 BGP 세션 다운 (07:07:43)

07:07:43.292: NOTIFICATION sent to 169.254.227.77 (hold time expired)

07:07:43.293: neighbor 169.254.227.77 Down

→ 해석: MED 전환 후 약 2분 뒤 BGP Hold Timer(기본 30초 × 미수신)가 만료되어 세션이 공식 종료. 하지만 트래픽은 이미 Phase A에서 Tunnel 1로 전환되었으므로 패킷 손실 없음.

────────────────────────────────────────────

Phase C: Tunnel 2 Interface 다운 & 복구 (07:08:22 ~ 07:08:59)

07:08:22.784: Tunnel2, changed state to down     ← IPsec 터널 완전 다운

07:08:59.279: Tunnel2, changed state to up       ← 새 엔드포인트로 터널 재설정 완료

→ 해석: 터널 다운 → 새 호스트에서 재설정까지 약 37초 소요. 이 동안 Tunnel 1이 모든 트래픽을 처리.

────────────────────────────────────────────

Phase D: BGP 세션 복구 & MED 정상화 (07:09:04 ~ 07:09:05)

07:09:04.146: neighbor 169.254.227.77 Up          ← BGP 세션 재설정

07:09:05.153: 169.254.227.77 rcvd UPDATE … metric 100  ← MED가 다시 100으로 정상화

→ 해석: 새 엔드포인트와 BGP Established 후, AWS가 MED를 다시 100으로 낮춤. 이제 두 터널이 동등한 우선순위로 복원.

2. 교체가 진행되는 동안, 트래픽 손실이 있었는지 확인하고, 무손실로 진행 되었음을 확인합니다.

$ ping -i 0.1 10.1.1.10
PING 10.1.1.10 (10.1.1.10) 56(84) bytes of data.
64 bytes from 10.1.1.10: icmp_seq=1 ttl=124 time=7.87 ms
64 bytes from 10.1.1.10: icmp_seq=2 ttl=124 time=6.62 ms
64 bytes from 10.1.1.10: icmp_seq=3 ttl=124 time=6.41 ms
64 bytes from 10.1.1.10: icmp_seq=4 ttl=124 time=6.75 ms
64 bytes from 10.1.1.10: icmp_seq=5 ttl=124 time=6.50 ms
64 bytes from 10.1.1.10: icmp_seq=6 ttl=124 time=6.67 ms
64 bytes from 10.1.1.10: icmp_seq=7 ttl=124 time=6.54 ms
64 bytes from 10.1.1.10: icmp_seq=8 ttl=124 time=6.65 ms
..<snipped>..
64 bytes from 10.1.1.10: icmp_seq=4128 ttl=124 time=5.70 ms
64 bytes from 10.1.1.10: icmp_seq=4129 ttl=124 time=6.12 ms
64 bytes from 10.1.1.10: icmp_seq=4130 ttl=124 time=12.1 ms
64 bytes from 10.1.1.10: icmp_seq=4131 ttl=124 time=6.47 ms
64 bytes from 10.1.1.10: icmp_seq=4132 ttl=124 time=5.85 ms
64 bytes from 10.1.1.10: icmp_seq=4133 ttl=124 time=6.04 ms
64 bytes from 10.1.1.10: icmp_seq=4134 ttl=124 time=6.02 ms
64 bytes from 10.1.1.10: icmp_seq=4135 ttl=124 time=6.32 ms
^C
--- 10.1.1.10 ping statistics ---
4135 packets transmitted, 4135 received, 0% packet loss, time 416305ms
rtt min/avg/max/mdev = 4.844/6.086/14.669/0.608 ms

터널 교체 타임라인 요약

• 총 소요시간: 약 3분 23초 (07:05:42 → 07:09:05)

• 패킷 손실: 0 (MED 선제 전환 덕분)

Step 5: Tunnel2 교체 완료 — 복구 확인

AWS에서 터널 엔드포인트 교체가 완료되면 Tunnel 2가 다시 UP 상태로 돌아오고, VPN 연결도 Available로 복구됩니다. 이 시점에서 CGW 라우터가 새 피어 IP와 IKE/IPsec SA를 자동으로 재협상하고, BGP 세션을 다시 설정하는지 확인합니다. 정상적으로 복구되면 routing table에 두 경로가 다시 모두 표시됩니다. 양쪽 터널이 모두 UP이고 BGP가 Established인 것을 확인한 후에만 다음 터널 교체를 진행합니다.

1. VPN 콘솔에서, VPN 연결 상태를 확인합니다.

   

2. 라우터에서 기본 경로가 Tunnel1(169.254.51.77)으로 바뀐 것을 확인 할 수 있습니다.

   $ show ip bgp
   BGP table version is 17, local router ID is 172.20.11.1
   Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
                 r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
                 x best-external, a additional-path, c RIB-compressed, 
                 t secondary path, L long-lived-stale,
   Origin codes: i - IGP, e - EGP, ? - incomplete
   RPKI validation codes: V valid, I invalid, N Not found
   
        Network          Next Hop            Metric LocPrf Weight Path
    *    10.1.1.0/24      169.254.227.77         100             0 65001 i
    *>                    169.254.51.77          100             0 65001 i
    *>   172.20.11.0/24   0.0.0.0                  0         32768 i

Step 6: 두 번째 터널 수동 교체 실행 (반복)

첫 번째 교체한 터널이 완전히 복구된 것을 확인한 후, 동일한 절차를 다른 터널에 대해 반복합니다. 이번에는 Tunnel 1이 다운되면서 트래픽이 방금 교체 완료된 Tunnel 2로 전환됩니다. 두 터널을 동시에 교체하면 양쪽 모두 DOWN이 되어 서비스가 완전 중단되므로, 반드시 한 쪽 교체 완료 후 다른 쪽을 진행해야 합니다. Step 3~5와 동일과정을 진행하여 두 번째 교체의 Failover 시간도 기록하여 첫 번째와 비교합니다.

1. 두 번째 터널(Tunnel 1) 교체 중 라우터에서의 BGP 변경 로그를 확인합니다.

   *Jun  2 07:48:23.770: BGP(0): 169.254.51.77 rcvd UPDATE w/ attr: nexthop 169.254.51.77, origin i, metric 200, merged path 65001, AS_PATH 
   *Jun  2 07:48:23.770: BGP(0): 169.254.51.77 rcvd 10.1.1.0/24
   *Jun  2 07:48:23.770: BGP(0): Revise route installing 1 of 1 routes for 10.1.1.0/24 -> 169.254.227.77(global) to main IP table
   *Jun  2 07:48:23.778: BGP(0): 169.254.227.77 NEXT_HOP is on same subnet as the bgp peer and set to 169.254.227.77 for net 10.1.1.0/24, flags 200, sb: A9FEE34C, mask: FFFFFFFC
   *Jun  2 07:48:23.778: BGP(0): (base) 169.254.227.77 send UPDATE (format) 10.1.1.0/24, next 169.254.227.77, metric 100, path 65001
   *Jun  2 07:50:53.273: %BGP-3-NOTIFICATION: sent to neighbor 169.254.51.77 4/0 (hold time expired) 0 bytes 
   *Jun  2 07:50:53.274: %BGP-5-NBR_RESET: Neighbor 169.254.51.77 reset (BGP Notification sent)
   *Jun  2 07:50:53.275: %BGP-5-ADJCHANGE: neighbor 169.254.51.77 Down BGP Notification sent
   *Jun  2 07:50:53.275: %BGP_SESSION-5-ADJCHANGE: neighbor 169.254.51.77 IPv4 Unicast topology base removed from session  BGP Notification sent
   *Jun  2 07:51:33.289: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
   *Jun  2 07:51:33.297: BGP(0): redist event (2) request for 169.254.51.76/30
   *Jun  2 07:52:17.075: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
   *Jun  2 07:52:17.085: BGP(0): redist event (1) request for 169.254.51.76/30
   *Jun  2 07:52:19.065: %BGP-5-ADJCHANGE: neighbor 169.254.51.77 Up 
   *Jun  2 07:52:19.066: BGP(0): 169.254.227.77 NEXT_HOP is on same subnet as the bgp peer and set to 169.254.227.77 for net 10.1.1.0/24, flags 200, sb: A9FEE34C, mask: FFFFFFFC
   *Jun  2 07:52:19.066: BGP(0): (base) 169.254.227.77 send UPDATE (format) 10.1.1.0/24, next 169.254.227.77, metric 100, path 65001
   *Jun  2 07:52:19.066: BGP(0): (base) 169.254.227.77 send UPDATE (format) 172.20.11.0/24, next 169.254.227.78, metric 0, path Local
   *Jun  2 07:52:20.061: BGP(0): 169.254.51.77 rcvd UPDATE w/ attr: nexthop 169.254.51.77, origin i, metric 100, merged path 65001, AS_PATH 
   *Jun  2 07:52:20.061: BGP(0): 169.254.51.77 rcvd 10.1.1.0/24

   Tunnel 1 교체 과정에 따른 Phase별로 해당 로그를 해석해보면, 아래와 같습니다.

   Phase A: AWS가 MED를 올려 트래픽 선제 전환 (07:48:23)

   07:48:23.770: 169.254.51.77 rcvd UPDATE … metric 200        ← AWS가 Tunnel 1 MED를 100→200으로 올림

   07:48:23.770: Revise route installing … -> 169.254.227.77   ← best path가 Tunnel 2로 즉시 전환

   → 해석: MED 200 수신 즉시 best path가 Tunnel 2(169.254.227.77)로 변경. 이 시점부터 트래픽은 Tunnel 2로 흐름. 패킷 손실 없음.

   ─────────────────────────────────────────

   Phase B: Tunnel 1 BGP 세션 종료 (07:50:53)

   07:50:53.273: NOTIFICATION sent to neighbor 169.254.51.77 (hold time expired)

   07:50:53.275: neighbor 169.254.51.77 Down

   → 해석: MED 전환 후 약 2분 30초 뒤 Hold Timer 만료로 세션 종료. 트래픽은 이미 Tunnel 2에 있으므로 영향 없음.

   ─────────────────────────────────────────

   Phase C: Tunnel 1 Interface 다운 & 복구 (07:51:33 ~ 07:52:17)

   07:51:33.289: Tunnel1, changed state to down

   07:52:17.075: Tunnel1, changed state to up

   → 해석: 엔드포인트 교체 진행. down → up 약 44초 소요.

   ─────────────────────────────────────────

   Phase D: BGP 세션 복구 & MED 정상화 (07:52:19 ~ 07:52:20)

   07:52:19.065: neighbor 169.254.51.77 Up

   07:52:20.061: 169.254.51.77 rcvd UPDATE … metric 100        ← MED 다시 100으로 정상화

   → 해석: 새 엔드포인트와 BGP Established 후 MED 100으로 복원. 양쪽 동등 상태.

2. 교체가 진행되는 동안, 트래픽 손실이 있었는지 확인하고, 무손실로 진행 되었음을 확인합니다.

   ..<snipped>..
   64 bytes from 10.1.1.10: icmp_seq=5474 ttl=124 time=5.75 ms
   64 bytes from 10.1.1.10: icmp_seq=5475 ttl=124 time=6.38 ms
   64 bytes from 10.1.1.10: icmp_seq=5476 ttl=124 time=5.99 ms
   64 bytes from 10.1.1.10: icmp_seq=5477 ttl=124 time=6.39 ms
   64 bytes from 10.1.1.10: icmp_seq=5478 ttl=124 time=11.6 ms
   64 bytes from 10.1.1.10: icmp_seq=5479 ttl=124 time=6.41 ms
   64 bytes from 10.1.1.10: icmp_seq=5480 ttl=124 time=6.15 ms
   ^C
   --- 10.1.1.10 ping statistics ---
   5480 packets transmitted, 5480 received, 0% packet loss, time 552017ms
   rtt min/avg/max/mdev = 4.673/5.799/18.483/0.605 ms

3. 교체 후, 라우터에서 기본 경로가 Tunnel 2(169.254.227.77)로 바뀐 것을 확인 할 수 있습니다.

   $ show ip bgp
   BGP table version is 20, local router ID is 172.20.11.1
   Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
                 r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
                 x best-external, a additional-path, c RIB-compressed, 
                 t secondary path, L long-lived-stale,
   Origin codes: i - IGP, e - EGP, ? - incomplete
   RPKI validation codes: V valid, I invalid, N Not found
   
        Network          Next Hop            Metric LocPrf Weight Path
    *    10.1.1.0/24      169.254.51.77          100             0 65001 i
    *>                    169.254.227.77         100             0 65001 i
    *>   172.20.11.0/24   0.0.0.0                  0         32768 i

Step 7: 최종 결과 정리

두 터널 교체 타임라인에 따른 각 터널의 상태를 정리하면 다음과 같습니다.

BGP + Tunnel Endpoint Lifecycle Control 환경에서 두 터널을 순차적으로 교체한 결과, 총 패킷 손실 0개를 달성했습니다. AWS는 터널 교체 전 MED 값을 200으로 올려 트래픽을 다른 터널로 선제 전환한 뒤 엔드포인트를 교체했으며, 교체 완료 후 MED를 100으로 복원하였습니다. 전체 교체 과정(약 4분/터널)동안 서비스 중단은 발생하지 않는 것을 확인하였습니다.

마치면서

지금까지 AWS Site-to-Site VPN 운영 시 VPN 터널 유지보수로 인한 서비스 장애를 예방하는 방법을 알아보았습니다.

AWS Site-to-Site VPN 아키텍처에 대한 모범 사례를 아래와 같이 요약하고 글을 마치도록 하겠습니다. AWS Site-to-Site VPN 을 운영하고 있거나 구축 계획이 있다면 한번 적용을 고려해보시는 것을 권고드립니다.

AWS Site-to-Site VPN 모범 사례

1. Site-to-Site VPN 터널에서 BGP 사용 (Active-Active 또는 Active-Passive)

   Site-to-Site VPN 터널에서 BGP 사용하고 모든 터널이 항상 활성화(UP)된 상태로 운영하는 것을 권장합니다. 모든 터널에서 BGP 세션이 연결되어 있다면 AWS에서 터널 유지보수가 진행되더라도 트래픽 경로 전환을 통해 서비스 중단이 최소화됩니다.

   • Transit Gateway / Cloud WAN 사용 시: Active-Active 동작 (기본적으로 TGW는 중복으로 연결된 VPN 터널에서 ECMP(Equal-Cost Multi-Path)기반의 트래픽 분산이 이루어집니다.)
   • Virtual Private Gateway 사용 시: Active-Passive 동작 (VGW는 ECMP를 지원하지 않으므로, 한 번에 하나의 터널만 Primary로 사용됩니다.)

   ⚠️

   고객 게이트웨이에서 BGP 설정 시 주의사항

   AWS에서는 Site-to-Site VPN 터널 상에서 경로 제어를 위해서 BGP MED 속성을 사용하기 때문에, 고객 게이트웨이에서 VPN 터널 구간에서 BGP LocalPref, AS-Prepending 과 같은 BGP 속성을 수정하는 것을 권고하지 않습니다.

2. 모든 VPN 터널에 Tunnel Endpoint Lifecycle Control 활성화

   운영자가 터널 유지보수 시점을 직접 제어할 수 있도록 모든 VPN 터널에 Tunnel Endpoint Lifecycle Control 활성화합니다.

   대규모 운영 환경에서는 EventBridge + Lambda/Step Functions 활용하는 것을 검토할 수 있습니다. 이를 통해 AWS Health 이벤트를 EventBridge 규칙으로 캡처하고, Lambda 또는 Step Functions를 통해 유지보수 윈도우 동안 자동으로 업데이트를 수락하는 워크플로 구성합니다.

참고자료

• AWS Site-to-Site VPN 서비스 페이지

• AWS Site-to-Site VPN 공식 문서

• AWS Site-to-Site VPN tunnel endpoint lifecycle control

• Routing during VPN tunnel endpoint updates

• AWS Health Dashboard