마이그레이션 프로젝트가 일정에서 밀리는 가장 흔한 이유는 서버 이전 작업 자체가 아니라 네트워크입니다. Direct Connect는 신청부터 개통까지 수 주~수 개월이 걸리고, IP 대역이 겹치면 설계를 처음부터 다시 해야 하며, 복제 대역폭을 잘못 산정하면 웨이브 일정 전체가 무너집니다. 이 글은 온프레미스 시스템을 AWS로 올릴 때 어떤 네트워크 옵션이 있고, 무엇을 기준으로 골라야 하는지를 실무 관점에서 정리한 것입니다.
먼저 정리 — 결정해야 하는 것은 네 가지
"네트워크 옵션"이라는 한 단어 안에는 사실 성격이 다른 네 개의 결정이 섞여 있습니다. 이걸 분리하지 않으면 논의가 계속 겉돕니다.
| 결정 | 질문 | 대표 선택지 |
|---|---|---|
| ① 연결 회선 | 온프레미스와 AWS를 무엇으로 잇는가 | Site-to-Site VPN / Direct Connect / 둘의 조합 / 오프라인 전송 |
| ② 라우팅 구조 | VPC가 여러 개일 때 어떻게 묶는가 | VGW 직결 / Transit Gateway / Cloud WAN / VPC Peering |
| ③ 서비스 접근 | AWS 서비스·SaaS에 어떤 경로로 붙는가 | 인터넷+NAT / VPC 엔드포인트 / PrivateLink |
| ④ 사용자 접근 | 관리자·재택 인력은 어떻게 들어오는가 | Client VPN / 기존 SSL VPN / Verified Access / 배스천 |
[온프레미스 데이터센터]
│
│ ① 연결 회선
│ ├─ Site-to-Site VPN (인터넷 위 IPsec)
│ ├─ Direct Connect (전용 회선)
│ └─ DX + VPN 백업 (권장 이중화)
│
▼
[AWS 엣지 / DX 로케이션]
│
│ ② 라우팅 구조
│ ├─ VGW 직결 (VPC 1~2개, 단순)
│ ├─ Transit Gateway (VPC 다수, 허브&스포크) ← 대부분의 정답
│ └─ Cloud WAN (다중 리전·글로벌)
│
▼
[VPC들] ── ③ VPC 엔드포인트 / PrivateLink ── [S3·KMS·SaaS]
│
└───── ④ Client VPN / Verified Access ── [관리자·재택]① 연결 회선 — 핵심 비교
Site-to-Site VPN
인터넷 위에 IPsec 터널을 올리는 방식입니다. 가장 빨리, 가장 싸게 시작할 수 있는 옵션이고 대부분의 프로젝트는 여기서 출발합니다.
- 개통 속도 — 콘솔에서 만들고 온프레미스 장비에 설정 넣으면 당일 개통이 가능합니다. 리드타임이 사실상 0입니다.
- 대역폭 — 연결마다 두 개의 터널이 생기지만 기본 구성에서는 터널 1개당 약 1.25 Gbps가 상한입니다. 두 터널을 동시에 쓰려면 Transit Gateway + ECMP 구성이 필요하고, 그 이상은 VPN 연결을 여러 개 만들어 묶어야 합니다.
- 품질 — 인터넷 경로를 타므로 지연과 지터가 보장되지 않습니다. 평시에는 멀쩡하다가 특정 시간대에 흔들리는 패턴이 흔합니다.
- 비용 — 연결당 시간 요금 + 아웃바운드 데이터 전송료(인터넷 요율). 회선 임대료가 없어 초기 비용이 낮습니다.
- 보안 — 암호화는 IPsec으로 보장됩니다. "인터넷을 탄다"는 이유만으로 보안이 약한 것은 아니지만, 경로 자체는 통제할 수 없습니다.
Palo Alto 장비 기준 실제 설정 절차는 팔로알토 방화벽과 AWS Site-to-Site VPN 연동에 정리해 두었습니다.
AWS Direct Connect (DX)
통신사 회선으로 AWS와 물리적으로 직결하는 방식입니다. 대역폭이 크거나, 지연이 일정해야 하거나, 규제상 인터넷 경유가 곤란할 때 선택합니다.
- 전용 연결(Dedicated) — 1 / 10 / 100 Gbps 포트를 AWS에서 직접 할당받습니다. 10G·100G 포트는 MACsec 링크 암호화를 지원합니다.
- 호스티드 연결(Hosted) — APN 파트너(국내 통신사·IX 사업자)를 통해 50 Mbps부터 수 Gbps까지 세분화된 대역폭을 받습니다. 국내 중견 규모 프로젝트에서 가장 현실적인 선택지입니다.
- 리드타임 — 회선 신청·실사·크로스커넥트·BGP 구성까지 보통 4~12주. 이 숫자가 마이그레이션 일정의 실질적 시작점입니다.
- 비용 구조 — 포트 시간 요금 + 아웃바운드 데이터 전송료 + 파트너 회선료(AWS 청구서에 안 나옴). 마지막 항목을 빼놓고 견적을 잡는 사고가 자주 납니다.
- 이점 — 아웃바운드 전송 단가가 인터넷 경유보다 낮습니다. 상시 트래픽이 큰 환경에서는 회선료를 상쇄하고도 남는 경우가 있습니다.
DX에서 반드시 구분해야 하는 개념이 가상 인터페이스(VIF)입니다.
| VIF 유형 | 무엇에 붙는가 | 쓰는 경우 |
|---|---|---|
| Private VIF | VGW(VPC 1개) 또는 Direct Connect Gateway | VPC 내부 사설 IP 통신 — 가장 일반적 |
| Transit VIF | Direct Connect Gateway → Transit Gateway | VPC가 여러 개일 때 (허브&스포크) |
| Public VIF | AWS 퍼블릭 엔드포인트 | S3 등 퍼블릭 서비스를 인터넷 아닌 경로로 |
DX + VPN 이중화 (실무 기본값)
DX 단일 회선은 단일 장애점입니다. 현실적인 구성은 다음 세 가지입니다.
| 구성 | 가용성 | 비용 | 적합 |
|---|---|---|---|
| DX 1회선 + VPN 백업 | 중~상 | 낮음 | 대부분의 기업 — 가장 흔한 정답 |
| DX 2회선 (서로 다른 로케이션) | 상 | 높음 | 가용성이 매출과 직결되는 서비스 |
| VPN 다중 터널 + ECMP | 중 | 매우 낮음 | DX 개통 전 임시, 소규모 |
DX+VPN 구성에서는 BGP 경로 우선순위로 평시 DX, 장애 시 VPN 전환이 자동으로 이뤄집니다. 단, VPN으로 폴백했을 때 대역폭이 업무를 감당하는지는 반드시 사전에 계산해 두어야 합니다. DX 10G를 쓰다가 VPN 1.25G로 떨어지면 사실상 장애와 다르지 않은 상황이 됩니다.
오프라인 전송 (Snow Family / DataSync)
초기 대용량 데이터를 옮길 때는 회선으로 밀어 넣는 것이 항상 정답은 아닙니다. 판단 기준은 간단합니다.
전송 소요 시간(일) = 데이터량(TB) × 8000 ÷ (가용대역폭 Gbps × 0.7) ÷ 86400
예) 100 TB를 1 Gbps 회선의 70%로 전송
= 100 × 8000 ÷ 0.7 ÷ 86400 ≈ 13.2일 (24시간 전송 기준)
→ 업무시간 외에만 전송한다면 40일 이상이 값이 1~2주를 넘어가면 Snowball 계열 오프라인 전송이나, 초기 벌크는 오프라인 + 증분은 DataSync로 따라잡는 하이브리드 방식을 검토하는 편이 낫습니다.
회선 옵션 종합 비교
| 항목 | Site-to-Site VPN | Direct Connect | DX + VPN | 오프라인 전송 |
|---|---|---|---|---|
| 개통 리드타임 | 당일 | 4~12주 | 4~12주 | 1~3주(배송 포함) |
| 실효 대역폭 | 터널당 ~1.25 Gbps | 50 Mbps ~ 100 Gbps | DX 기준 | 해당 없음(벌크) |
| 지연 안정성 | 보장 없음 | 일정 | 일정(평시) | — |
| 초기 비용 | 매우 낮음 | 높음 | 높음 | 중간 |
| 전송 단가 | 인터넷 요율 | 낮음 | 낮음 | 디바이스 단위 |
| 암호화 | IPsec 기본 | 기본 없음(MACsec/VPN 추가) | 구간별 | 디바이스 암호화 |
| 주 용도 | 착수·소규모·백업 | 상시 대용량 | 운영 표준 | 초기 벌크 이관 |
② 라우팅 구조 — VPC가 늘어날 것을 전제로
VGW 직결
VPC 하나에 Virtual Private Gateway를 붙여 VPN이나 Private VIF를 연결하는 가장 단순한 형태입니다. VPC가 1~2개이고 앞으로도 늘지 않는다면 충분합니다. 문제는 VPC가 늘어날 때입니다. VPC 간 통신이 필요해지는 순간 Peering 메시가 폭발하고, 온프레미스 경로를 VPC마다 따로 관리해야 합니다.
Transit Gateway (권장 기본값)
리전 단위 라우팅 허브입니다. VPC들과 온프레미스 연결(VPN·DX)을 모두 TGW에 붙이면 라우팅이 한 곳으로 모입니다.
- 라우팅 테이블 분리 — TGW 라우팅 테이블을 여러 개 두어 "운영 VPC는 서로 통신 불가, 공유 서비스 VPC로만 접근" 같은 세그멘테이션을 구현할 수 있습니다. 공공·금융 프로젝트에서 특히 중요합니다.
- VPN ECMP — 여러 VPN 터널을 묶어 대역폭을 늘릴 수 있습니다. DX 개통 전 임시 구간에서 유용합니다.
- 비용 — attachment당 시간 요금 + 통과 데이터 처리 요금(GB당)이 붙습니다. 트래픽이 많은 두 VPC가 TGW를 계속 경유하면 비용이 쌓이므로, 그런 쌍은 VPC Peering으로 직결하는 편이 쌉니다.
Cloud WAN
여러 리전·여러 계정·지사 네트워크를 정책 문서(JSON) 하나로 관리하는 글로벌 광역망 서비스입니다. 세그먼트 정의와 attachment 정책을 중앙에서 선언하면 리전별 코어 네트워크가 자동 구성됩니다.
다만 단일 리전에 VPC 몇 개인 환경에는 과합니다. 다중 리전 + 다수 지사 + 계정 다수라는 조건이 동시에 성립할 때 검토하세요. 그렇지 않다면 Transit Gateway가 더 단순하고 저렴합니다.
VPC Peering
두 VPC를 1:1로 직결합니다. 전이적 라우팅이 안 되고(A-B, B-C를 연결해도 A-C는 통신 불가) VPC 수가 늘면 관리가 불가능해집니다. 다만 대용량 트래픽이 오가는 특정 VPC 쌍은 TGW 데이터 처리 요금을 피할 수 있어 의도적으로 Peering을 병행하는 설계가 유효합니다.
③ IP 대역 설계 — 되돌릴 수 없는 결정
네트워크 설계에서 가장 먼저, 가장 신중하게 확정해야 하는 항목입니다. 나중에 바꾸려면 서비스를 세우고 다시 만드는 수밖에 없습니다.
- 온프레미스 대역과 절대 겹치지 않게 — 겹치면 라우팅이 성립하지 않습니다. 사내에서 이미
10.0.0.0/16을 쓰고 있는데 VPC 기본값을 그대로 만들어 버리는 사고가 정말 흔합니다. - 여유 있게 잡되 낭비는 피하기 — VPC는
/16, 서브넷은 AZ별/20~/24가 일반적인 출발점입니다. - 계정·환경별로 대역을 예약 — 운영/스테이징/개발, 계정별 블록을 표로 먼저 만들고 IPAM으로 관리하세요. 엑셀로 관리하면 반드시 어긋납니다.
- EKS·컨테이너를 쓸 계획이면 IP 소모량 재계산 — Pod마다 VPC IP를 쓰는 구성에서는 예상보다 훨씬 빨리 고갈됩니다.
- 인수·합병·제휴 대비 — 미래에 다른 조직 네트워크와 붙을 가능성이 있다면 대역을 더 넓게 예약해 두세요.
이미 겹쳐 버린 경우의 차선책은 NAT를 통한 주소 변환, 또는 Transit Gateway와 PrivateLink를 조합해 중복 대역을 우회 노출하는 구성입니다. 둘 다 운영 복잡도를 크게 올리므로 어디까지나 응급 처치입니다.
④ DNS — 회선만 뚫고 잊는 항목
회선이 붙어도 이름이 안 풀리면 애플리케이션은 동작하지 않습니다. 하이브리드 환경의 DNS는 양방향으로 설계해야 합니다.
| 방향 | 수단 | 설명 |
|---|---|---|
| 온프레미스 → AWS | Route 53 Resolver 인바운드 엔드포인트 | 사내 DNS가 VPC 내부 이름(프라이빗 호스팅 영역, VPC 엔드포인트 DNS)을 조회 |
| AWS → 온프레미스 | Route 53 Resolver 아웃바운드 엔드포인트 + 전달 규칙 | EC2가 사내 도메인(예: corp.local)을 사내 DNS로 질의 |
| 공통 | 프라이빗 호스팅 영역 | VPC 내부 전용 레코드 관리 |
마이그레이션 컷오버에서 DNS는 롤백 수단이기도 합니다. 컷오버 최소 며칠 전에 TTL을 60초 수준으로 낮춰두는 것은 비용이 거의 들지 않으면서 효과가 가장 확실한 준비 작업입니다.
⑤ 서비스 접근 경로 — 인터넷을 탈 것인가
EC2가 S3나 KMS에 접근할 때 기본 경로는 인터넷(NAT Gateway 경유)입니다. 이건 두 가지 문제를 만듭니다 — NAT 데이터 처리 비용과 "내부 데이터가 인터넷 구간을 지난다"는 감사 지적입니다.
- 게이트웨이 엔드포인트 (S3, DynamoDB) — 라우팅 테이블에 항목만 추가하면 되고 추가 요금이 없습니다. 안 쓸 이유가 없습니다.
- 인터페이스 엔드포인트 / PrivateLink — KMS, Secrets Manager, SSM, ECR 등 대부분의 서비스에 ENI를 통해 사설로 접근합니다. 시간 요금 + 데이터 처리 요금이 붙지만, NAT 비용과 컴플라이언스 요건을 함께 해결합니다.
- SaaS·파트너 서비스 — 상대가 PrivateLink 서비스를 제공하면 인터넷 노출 없이 연결할 수 있습니다.
⑥ 사용자 접근 — 관리자와 재택 인력
서버 간 연결과 별개로 사람이 들어오는 경로를 설계해야 합니다.
- AWS Client VPN — 관리형 OpenVPN 기반. 인증서·AD·SAML 인증을 지원하고 세션 수 기준으로 과금됩니다. 설정 절차는 AWS Client VPN 설정 가이드에, 국내 SSL VPN과의 비교는 AWS Client VPN과 네이버 클라우드 SSL VPN 비교에 정리했습니다.
- 기존 사내 SSL VPN 재활용 — 이미 SSL VPN이 있다면 사내로 들어온 뒤 DX/S2S VPN을 타고 AWS로 가는 경로가 가장 단순합니다. 사용자 경험이 바뀌지 않는 것이 장점입니다.
- SSM Session Manager — SSH 포트를 열지 않고 셸에 접근합니다. 배스천 호스트를 없앨 수 있어 보안 감사에서 유리합니다. 배스천을 새로 만들기 전에 먼저 검토하세요.
- Verified Access — VPN 없이 신원·디바이스 상태 기반으로 애플리케이션 단위 접근을 제어하는 제로 트러스트 방식입니다.
마이그레이션 기간에만 필요한 대역폭
많은 팀이 정상 운영 시 트래픽만 보고 회선을 정합니다. 그런데 마이그레이션 기간에는 복제 트래픽이 별도로 흐릅니다.
- 초기 전체 동기화 — MGN 등 복제 도구가 디스크 전량을 밀어 넣습니다. 여기가 대역폭 피크입니다.
- 지속 증분 복제 — 컷오버까지 변경분이 계속 흐릅니다. 서버 수 × 변경률만큼 상시 점유됩니다.
- 업무 트래픽과의 경합 — 복제가 회선을 다 먹으면 현행 업무가 느려집니다. 복제 대역폭 스로틀링을 반드시 설정하고, 초기 동기화는 야간·주말에 배치하세요.
실무 권장은 이렇습니다. 회선 용량의 60~70%를 복제 상한으로 잡고, 그 조건에서 웨이브별 소요 시간을 역산해 일정을 세우는 것입니다. 반대로 일정을 먼저 정하고 대역폭을 끼워 맞추면 거의 항상 어긋납니다.
선택 결정 트리
Q1. 초기 이관 데이터가 수십 TB 이상이고, 회선 전송이 2주를 넘는가?
└ 예 → Snow Family 등 오프라인 벌크 + 증분은 회선으로
Q2. 상시 온프레미스↔AWS 트래픽이 있는가? (하이브리드 운영 지속)
├ 아니오 (이전 후 온프레미스 폐기) → Site-to-Site VPN으로 충분
└ 예 ↓
Q3. 필요한 상시 대역폭이 1 Gbps를 넘거나, 지연 안정성/규제상 전용 경로가 필요한가?
├ 아니오 → Site-to-Site VPN (필요 시 TGW + ECMP로 확장)
└ 예 → Direct Connect + VPN 백업
※ DX 개통까지 4~12주 → 그동안 VPN으로 선착수
Q4. VPC가 3개 이상이거나 앞으로 늘어날 계획인가?
├ 아니오 → VGW 직결
└ 예 → Transit Gateway (DX면 Transit VIF + DX Gateway)
Q5. 다중 리전 + 다수 지사 + 다계정을 동시에 관리하는가?
└ 예 → Cloud WAN 검토공공기관·규제 산업에서의 추가 고려사항
- 망분리 요건 — 업무망·인터넷망 분리 정책이 AWS 구간에서 어떻게 구현되는지 문서로 설명할 수 있어야 합니다. Transit Gateway 라우팅 테이블 분리와 서브넷 계층이 그 근거가 됩니다.
- 전송 구간 암호화 입증 — DX 구간은 기본 미암호화라는 점을 전제로, MACsec 또는 DX 위 VPN 적용 여부를 심사 문서에 명시해야 합니다.
- 인터넷 구간 최소화 — VPC 엔드포인트·PrivateLink 사용은 "내부 트래픽이 인터넷을 경유하지 않는다"는 근거 자료로 그대로 활용됩니다.
- 리전·AZ 배치 — 국내 데이터 보관 요건이 있다면 서울 리전 고정과 AZ 이중화 구성을 설계 초기에 확정하세요.
- CSAP 범위 — 인증 범위와 서비스 경계는 CSAP 인증 서비스 범위 정리를, 인프라 통제 항목은 ISMS-P 관점의 AWS 인프라 구성을 참고하세요.
- 서브넷 설계 기본 — 퍼블릭·프라이빗 분리 원칙은 AWS 퍼블릭·프라이빗 서브넷 구조에 정리해 두었습니다.
자주 부딪히는 문제와 대응
| 증상 | 원인 | 대응 |
|---|---|---|
| VPN 터널은 UP인데 통신이 안 됨 | 라우팅 테이블 누락, 보안 그룹·NACL 차단 | 양쪽 라우팅 전파(route propagation) 확인, SG 인바운드 규칙 점검 |
| DX 개통 후에도 경로가 VPN으로 흐름 | BGP 속성(AS_PATH·Local Preference) 설정 미흡 | 온프레미스 라우터에서 DX 경로 우선순위 조정 |
| 기대보다 처리량이 안 나옴 | 단일 터널 상한, 단일 흐름 한계 | TGW+ECMP로 다중 터널, 전송은 병렬 세션으로 분산 |
| 온프레미스에서 AWS 내부 도메인 미해석 | Resolver 인바운드 엔드포인트 부재 | 인바운드 엔드포인트 생성 후 사내 DNS 조건부 전달 설정 |
| VPC 생성 후 IP 대역 충돌 발견 | 사전 IP 계획 부재 | 초기라면 VPC 재생성이 최선, 운영 중이면 NAT/PrivateLink 우회 |
| NAT Gateway 요금 급증 | S3·ECR 트래픽이 NAT 경유 | S3 게이트웨이 엔드포인트, ECR·로그용 인터페이스 엔드포인트 추가 |
| 복제 때문에 현행 업무가 느려짐 | 복제 대역폭 무제한 | 복제 스로틀 설정, 초기 동기화 야간 배치, 웨이브 재분할 |
| MTU 문제로 특정 통신만 실패 | IPsec 오버헤드로 인한 단편화 | MSS 클램핑 설정, 경로 MTU 확인 |
설계 체크리스트
- ☐ 온프레미스 전체 IP 대역 목록 확보 및 AWS 대역과 충돌 검증
- ☐ VPC·서브넷 CIDR 계획 문서화 (계정·환경별 예약 포함)
- ☐ 상시 필요 대역폭 산정 (현행 트래픽 실측 기준)
- ☐ 마이그레이션 기간 복제 대역폭 별도 산정 및 스로틀 값 결정
- ☐ 회선 방식 결정 (VPN / DX / DX+VPN / 오프라인 병행)
- ☐ DX 선택 시 파트너·로케이션 확정 및 리드타임을 일정에 반영
- ☐ DX 구간 암호화 방식 결정 (MACsec / DX 위 VPN / 해당 없음)
- ☐ 이중화 구성 및 폴백 시 대역폭 충분성 검증
- ☐ 라우팅 허브 결정 (VGW / Transit Gateway / Cloud WAN)
- ☐ TGW 라우팅 테이블 분리로 세그멘테이션 설계
- ☐ Route 53 Resolver 인바운드·아웃바운드 엔드포인트 및 전달 규칙
- ☐ 컷오버 대상 도메인 TTL 사전 단축
- ☐ VPC 엔드포인트 목록 확정 (S3·KMS·SSM·ECR·CloudWatch Logs 등)
- ☐ 관리자 접근 경로 확정 (Client VPN / 기존 SSL VPN / SSM Session Manager)
- ☐ 대역폭·터널 상태 모니터링 및 알람 구성
- ☐ 데이터 전송·NAT·TGW·엔드포인트 요금을 포함한 월 비용 추정
- ☐ 회선 장애 시 대응 절차와 연락 체계 문서화
맺음말
네트워크 설계에서 되돌리기 어려운 결정은 사실 몇 개 되지 않습니다 — IP 대역, 라우팅 허브 구조, DX 리드타임입니다. 이 셋만 프로젝트 착수 시점에 제대로 잡아두면 나머지는 운영하면서 조정할 수 있습니다. 반대로 이 셋을 미뤄두면, 서버 이전이 아무리 순조로워도 일정은 반드시 밀립니다.
현실적인 진행 순서는 이렇습니다. 착수와 동시에 DX를 신청하고, 그동안 Site-to-Site VPN으로 디스커버리와 파일럿 이전을 시작하며, DX 개통 시점에 본 웨이브를 태우는 것입니다. 회선을 기다리며 아무것도 못 하는 몇 주를 없애는 것만으로도 전체 일정이 크게 달라집니다.
온프레미스 환경 진단(Cloud Readiness Assessment)부터 네트워크 설계, 마이그레이션 실행까지 지원이 필요하시면 JC Cloud로 문의해 주세요.
참고 자료
- AWS Site-to-Site VPN 사용자 가이드
- AWS Direct Connect 사용자 가이드
- Direct Connect — 가상 인터페이스(VIF) 유형
- Direct Connect Gateway
- AWS Direct Connect 로케이션 및 파트너
- AWS Transit Gateway 사용자 가이드
- AWS Cloud WAN 사용자 가이드
- AWS PrivateLink 개요
- Route 53 Resolver — 하이브리드 DNS
- Amazon VPC IP Address Manager (IPAM)
- AWS 백서 — Hybrid Connectivity
- AWS 백서 — Amazon VPC Connectivity Options
- AWS Application Migration Service — 네트워크 요구사항