마이그레이션 중 앱은 클라우드로, DB는 아직 온프레에 남겼습니다. 처음엔 잘 되는 듯했지만, 페이지마다 DB를 수십 번 호출하면서 온프레↔클라우드 왕복 지연이 쌓여 응답이 3배 느려졌습니다. 어느 날 VPN이 잠깐 끊기자 클라우드 앱이 통째로 멈췄습니다. 온프레와 클라우드를 어떻게 잇느냐가 하이브리드 구간의 성능·안정성을 좌우합니다.
- 1VPN과 전용선(Direct Connect)의 트레이드오프를 비교할 수 있다
- 2VPC 피어링/Transit Gateway로 사설 내부 통신을 구성하는 법을 안다
- 3프라이빗 엔드포인트로 인터넷을 거치지 않고 서비스에 접근하는 이점을 안다
- 4하이브리드 구간의 지연·연결 끊김 함정을 피할 수 있다
- 5연결 방식을 요구 지연·대역폭·보안으로 선택할 수 있다
무엇으로 이을 것인가
VPN vs 전용선 — 빠른 시작 vs 안정적 회선
온프레미스와 클라우드를 잇는 두 가지 방식:
- 사이트 간 VPN: 공용 인터넷 위에 IPsec 암호화 터널. 빠르고 싸게 시작하지만 지연·대역폭이 인터넷에 좌우됨. 빠른 시작·백업 경로에 적합.
- 전용선(Direct Connect/Interconnect): 통신사 물리 회선으로 직접 연결. 지연이 일정하고 대역폭이 크지만 구축에 수 주~수 개월·회선 비용. 안정성이 중요한 운영 트래픽에 적합.
흔한 구성: 전용선을 주 경로로, VPN을 백업 경로로 함께 둬 회선 장애에 대비합니다.
확대
위 그림은 VPN·전용선·VPC 피어링·엔드포인트 네 가지 하이브리드 연결 방식을 한눈에 비교합니다. 보안 요건과 대역폭에 따라 적합한 방식을 선택해야 합니다.
확대
위 그림처럼 VPN은 온프레 Customer Gateway와 AWS Virtual Private Gateway 사이에 IPSec 터널을 만들어 통신합니다. 빠르게 연결할 수 있지만 인터넷 품질에 성능이 좌우됩니다.
확대
위 그림처럼 TGW는 허브 역할을 해 각 VPC와 온프레가 스포크로 연결됩니다. VPC 피어링이 쌍으로 늘어나는 것과 달리, TGW는 연결 수를 선형으로 유지할 수 있습니다.
온프레와 클라우드가 실제로 연결되는 흐름 — 방식 선택부터 트래픽까지 5단계
"VPN으로 이었다"는 말 뒤에는 터널 협상·경로 광고·라우팅 반영이 순서대로 있습니다. 이 단계를 알면 "터널은 UP인데 왜 통신이 안 되는지", "왜 CIDR이 겹치면 아예 못 잇는지"를 단계로 좁혀 진단할 수 있습니다. 온프레와 클라우드의 사설 통신은 아래 흐름이 모두 성립해야 열립니다.
[온프레 데이터센터] ←───────────────────────→ [클라우드 VPC]
│
① 연결 방식 선택 → VPN(인터넷 위 IPsec) 또는 전용선(Direct Connect 물리 회선)
│
② 터널·회선 수립 → VPN: 양쪽 게이트웨이가 IKE 협상해 IPsec 터널 UP
│ 전용선: 통신사 회선 프로비저닝 + 가상 인터페이스(VIF)
│
③ 라우팅 교환(BGP) → 양쪽이 자기 대역을 BGP로 광고
│ 온프레 "10.10.0.0/16은 나" ↔ 클라우드 "10.20.0.0/16은 나"
│
④ 서브넷 간 트래픽 → 라우팅 테이블이 상대 대역을 이 연결로 보냄
│ (앱→온프레 DB 같은 사설 IP 통신이 사설 경로로)
│
⑤ 암호화·대역 → VPN은 터널 구간 암호화, 실효 대역·MTU가 성능을 좌우
▼
[사설 IP로 양방향 통신 성립]
각 단계에서 무슨 일이 일어나고, 막히면 어떤 증상인가:
| 단계 | 하는 일 | 여기서 막히면 |
|---|---|---|
| ① 방식 선택 | 빠른 시작·백업 경로면 VPN, 안정적 지연·대용량이면 전용선 | VPN은 인터넷 품질에 지연이 좌우돼 혼잡 시 응답이 튐 |
| ② 터널·회선 수립 | VPN은 IKE로 IPsec 터널 협상, 전용선은 회선·VIF 프로비저닝 | 사전 공유 키·피어 IP 불일치 → 터널이 UP 안 됨 |
| ③ BGP 광고 | 양쪽이 자기 CIDR을 BGP로 광고해 서로의 경로를 학습 | 한쪽이 대역을 광고 안 하면 라우팅이 성립 안 됨(BGP 미광고) |
| ④ 서브넷 간 트래픽 | 라우팅 테이블이 상대 대역을 이 연결로 보냄 | 양쪽 CIDR이 겹치면(10.0.0.0/16 충돌) 어디로 보낼지 모호 → 연결 불가 |
| ⑤ 암호화·대역 | VPN은 터널 구간을 암호화, 대역·MTU가 성능을 결정 | 대역 포화·MTU 축소(IPsec 캡슐화) → 큰 패킷만 지연·유실 |
즉 "연결됐다"는 ①~⑤가 모두 참이라는 뜻입니다. 터널은 UP인데 통신이 안 되면 ③(BGP 광고)·④(CIDR 충돌)를, 작은 요청은 되는데 큰 것만 멈추면 ⑤(MTU)를, 응답이 전반적으로 느리면 ①(VPN 인터넷 지연)·대역 포화를 의심합니다. 특히 ④의 CIDR 충돌은 연결하는 순간이 아니라 VPC를 만들 때 이미 결정되므로, 주소 계획이 연결 설계보다 먼저 와야 합니다(아래 심화에서 IPAM으로 이어집니다).
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를 같은 쪽으로 모으거나(함께 이전 마이그레이션 전략), 결합을 비동기 큐로 느슨하게(메시지 큐와 이벤트). 하이브리드 구간은 '영구 상태'가 아니라 '짧게 끝낼 과도기'로 설계합니다.
심화 — 잇기 전의 설계, 이은 뒤의 함정
심화: IP 대역이 겹치면 이을 수 없다 — 조직 차원의 주소 계획
하이브리드·멀티VPC 연결에는 숨은 전제가 있습니다. 양쪽 사설 IP 대역이 겹치지 않아야 한다는 것입니다. 온프레가 10.0.0.0/16을 쓰는데 VPC도 10.0.0.0/16이면, 피어링은 아예 맺어지지 않고 VPN을 이어도 '10.0.0.x로 가라'는 라우팅이 성립하지 않습니다 — 어느 쪽의 10.0.0.x인지 구분할 수 없기 때문입니다.
문제는 VPC CIDR이 한 번 정하면 사실상 못 바꾸는 값이라는 점입니다(보조 CIDR 추가는 가능하나 제약이 많음). 연결 계획이 없던 시절 '기본값 그대로' 만든 VPC들이, 몇 년 뒤 온프레 연결·계열사 통합·인수합병(M&A)에서 대역 충돌로 발목을 잡습니다. 겹친 뒤의 우회는 전부 비쌉니다 — 프라이빗 NAT 게이트웨이로 주소를 변환해 잇거나, 한쪽 네트워크를 재구축하는 수준의 일이 됩니다.
정석은 처음부터 조직 차원의 IP 주소 계획(IPAM) 을 두는 것입니다. RFC1918 사설 공간을 환경별·리전별·팀별 블록으로 미리 쪼개 할당하고, 새 VPC는 반드시 할당받은 블록 안에서만 만들게 합니다(VPC와 서브넷). '연결할 계획이 없는 네트워크'도 언젠가 연결된다고 가정하는 것이 하이브리드 시대의 주소 설계입니다.
상황: 모니터링은 온통 초록불입니다 — 터널 UP, 헬스체크 통과, 소형 요청 정상. 그런데 특정 기능만 골라서 실패하고, 재시도해도 같은 요청은 계속 멈춥니다.
원인: IPsec 터널은 캡슐화 헤더 때문에 실효 MTU가 1500보다 작습니다. 원래는 경로 MTU 탐색(PMTUD)이 '더 작게 쪼개 보내라'는 ICMP 신호로 이를 조율하지만, 중간 방화벽이 ICMP를 차단하면 큰 패킷이 아무 응답 없이 버려지는 'MTU 블랙홀' 이 됩니다. 그래서 작은 패킷(헬스체크·조회)은 통과하고, 실효 MTU를 넘는 큰 패킷(업로드·대량 응답)만 멈춥니다.
진단: 단편화를 금지한 채 크기를 늘려가며 어디서 끊기는지 찾습니다 — ping -M do -s 1400 10.10.0.5가 실패하고 -s 1300이 성공하면 실효 MTU는 그 사이입니다. tracepath로 경로 MTU도 확인합니다(Networking).
해결: 터널 구간에 TCP MSS 클램핑을 걸어(예: 1350) 세그먼트가 터널 MTU를 넘지 않게 강제하거나, 양쪽 장비의 터널 MTU를 명시 설정하고, 방화벽에서 ICMP 'fragmentation needed'(Type 3 Code 4)를 허용합니다. '작은 건 되는데 큰 것만 멈춘다'는 증상을 만나면 애플리케이션보다 MTU를 먼저 의심하는 것이 하이브리드 구간의 요령입니다.
하이브리드 연결은 마이그레이션·멀티계정 운영의 현실적 핵심입니다. "온프레와 클라우드를 어떻게 연결했나요?"에 "운영 트래픽은 전용선, 백업은 VPN, 내부 VPC는 Transit Gateway 허브, 서비스 접근은 프라이빗 엔드포인트"라 답하면 성숙합니다.
실무 핵심: ① 하이브리드 구간은 짧게 — 강결합을 양쪽에 오래 두지 않는다, ② 연결은 이중화(전용선+VPN, 이중 터널)로 단일 장애점 제거, ③ 내부·서비스 트래픽은 사설망(피어링·엔드포인트)으로 인터넷 노출 최소화(계정과 IAM의 최소 노출 원칙). 온프레 네트워크 지식(Networking)이 클라우드 연결 설계로 그대로 이어집니다.
다음으로는 이렇게 연결한 하이브리드·멀티VPC 구성을 코드로 선언·재현하는 IaC와 Terraform, 전체를 Well-Architected 신뢰성 기둥으로 점검해 보세요.