마이그레이션 중 앱은 클라우드로, DB는 아직 온프레에 남겼습니다. 처음엔 잘 되는 듯했지만, 페이지마다 DB를 수십 번 호출하면서 온프레↔클라우드 왕복 지연이 쌓여 응답이 3배 느려졌습니다. 어느 날 VPN이 잠깐 끊기자 클라우드 앱이 통째로 멈췄습니다. 온프레와 클라우드를 어떻게 잇느냐가 하이브리드 구간의 성능·안정성을 좌우합니다.
- 1VPN과 전용선(Direct Connect)의 트레이드오프를 비교할 수 있다
- 2VPC 피어링/Transit Gateway로 사설 내부 통신을 구성하는 법을 안다
- 3프라이빗 엔드포인트로 인터넷을 거치지 않고 서비스에 접근하는 이점을 안다
- 4하이브리드 구간의 지연·연결 끊김 함정을 피할 수 있다
- 5연결 방식을 요구 지연·대역폭·보안으로 선택할 수 있다
무엇으로 이을 것인가
VPN vs 전용선 — 빠른 시작 vs 안정적 회선
온프레미스와 클라우드를 잇는 두 가지 방식:
- 사이트 간 VPN: 공용 인터넷 위에 IPsec 암호화 터널. 빠르고 싸게 시작하지만 지연·대역폭이 인터넷에 좌우됨. 빠른 시작·백업 경로에 적합.
- 전용선(Direct Connect/Interconnect): 통신사 물리 회선으로 직접 연결. 지연이 일정하고 대역폭이 크지만 구축에 수 주~수 개월·회선 비용. 안정성이 중요한 운영 트래픽에 적합.
흔한 구성: 전용선을 주 경로로, VPN을 백업 경로로 함께 둬 회선 장애에 대비합니다.
VPC끼리, 서비스까지 — 사설로 잇기
조직이 커지면 VPC가 여러 개(환경·팀·계정별)가 됩니다.
- VPC 피어링: 두 VPC를 사설로 연결해 인터넷 없이 사설 IP로 통신. VPC가 많아지면 1:1 피어링이 폭증.
- Transit Gateway(허브): 다수 VPC·온프레를 중앙 허브로 잇는다. 멀티계정·멀티VPC에서 표준.
- 프라이빗(VPC) 엔드포인트: 프라이빗 서브넷 자원이 NAT/인터넷 없이 클라우드 서비스(S3 등)에 사설 접근 — 보안·NAT 비용·지연 이점(클라우드 비용 최적화).
핵심은 내부 통신을 공용 인터넷에 노출하지 않고 사설망으로 유지하는 것입니다(VPC와 서브넷).
하이브리드 연결의 생사는 서비스 연속성에 직결됩니다. 터널이 UP인지 확인합니다.
aws ec2 describe-vpn-connections \
--query "VpnConnections[].{Id:VpnConnectionId,State:State,Tunnels:VgwTelemetry[].Status}"
[ { "Id": "vpn-0abc", "State": "available", "Tunnels": ["UP","DOWN"] } ]
aws ec2 describe-vpn-connections하이브리드 구간의 왕복 지연을 측정해, 동기 호출이 많은 설계가 견딜 수 있는지 판단합니다.
# 클라우드 인스턴스에서 온프레 DB로
mtr -rwzbc 20 onprem-db.internal
# 또는 단순 측정
ping -c 10 10.10.0.5 | tail -2
rtt min/avg/max = 22.1/24.8/31.0 ms # 페이지당 50회 호출이면 +1.2초 누적
ping / mtr- VPN 터널 중 하나라도 DOWN — 이중 터널인데 하나만 살아있으면 가용성 저하. 둘 다 UP 유지, 전용선+VPN 백업 구성 검토
- 온프레↔클라우드 왕복 지연(rtt) × 페이지당 호출 수 — 누적 지연이 SLA를 넘으면 강결합을 분리하거나 같은 쪽으로 모아야 함
- 프라이빗 엔드포인트 없이 NAT로 S3 등에 접근 중 — 인터넷 경유 + NAT 데이터 처리비. 프라이빗 엔드포인트로 전환 검토
- VPC 피어링이 다수 1:1로 난립 — 관리·라우팅 복잡도 폭증. Transit Gateway 허브로 통합 검토
상황: 온프레와 클라우드를 VPN으로 이었는데 연결 품질이 서비스 안정성을 떨어뜨림.
원인: ① VPN이 공용 인터넷에 의존해 혼잡 시 지연·끊김, ② 강하게 결합된 앱-DB를 양쪽에 분리해 매 호출이 왕복 지연을 더함, ③ 단일 터널이라 끊기면 통신 두절(Networking의 경로·지연).
진단: VPN 터미네이션의 터널 상태·재협상 로그 확인 → 왕복 지연·패킷 손실 측정 → 앱-DB 호출 빈도가 지연에 민감한지 점검.
해결: 안정성이 중요하면 전용선으로 격상(+VPN 백업), 이중 터널로 가용성 확보. 근본적으로는 강결합을 줄여 — 앱과 DB를 같은 쪽으로 모으거나(함께 이전 마이그레이션 전략), 결합을 비동기 큐로 느슨하게(메시지 큐와 이벤트). 하이브리드 구간은 '영구 상태'가 아니라 '짧게 끝낼 과도기'로 설계합니다.
하이브리드 연결은 마이그레이션·멀티계정 운영의 현실적 핵심입니다. "온프레와 클라우드를 어떻게 연결했나요?"에 "운영 트래픽은 전용선, 백업은 VPN, 내부 VPC는 Transit Gateway 허브, 서비스 접근은 프라이빗 엔드포인트"라 답하면 성숙합니다.
실무 핵심: ① 하이브리드 구간은 짧게 — 강결합을 양쪽에 오래 두지 않는다, ② 연결은 이중화(전용선+VPN, 이중 터널)로 단일 장애점 제거, ③ 내부·서비스 트래픽은 사설망(피어링·엔드포인트)으로 인터넷 노출 최소화(계정과 IAM의 최소 노출 원칙). 온프레 네트워크 지식(Networking)이 클라우드 연결 설계로 그대로 이어집니다.
다음으로는 이렇게 연결한 하이브리드·멀티VPC 구성을 코드로 선언·재현하는 IaC와 Terraform, 전체를 Well-Architected 신뢰성 기둥으로 점검해 보세요.