AWS Client VPN 네이티브 Transit Gateway 연결 검증

AWS Client VPN 네이티브 Transit Gateway 연결: 기능 정리

AWS 공식 문서가 아닙니다. 개인 실습 기록이며 AWS의 입장을 대변하지 않습니다(기준일 2026-10-25). 정확한 정보는 AWS 공식 문서를 확인하세요. 작성 2026-10-24, 실습 결과 반영 2026-10-25. 출처는 AWS 공식 문서, AWS 블로그, What’s New로 한정했고, 실습으로 확인한 내용에는 [실측] 표시를 달았습니다. 상세 결과는 테스트 결과를 참고하세요.

1. 개요

2026년 4월 23일 AWS는 AWS Client VPN 엔드포인트를 AWS Transit Gateway(TGW)에 직접 연결하는 기능을 발표했습니다. [W1] 이 문서에서는 보안 그룹을 SG로 줄여 씁니다.

2. 기존 방식과의 비교

VPC 연결 방식과 Transit Gateway 연결 방식 비교

항목 VPC 연결(기존) Transit Gateway 연결(신규)
연결 대상 한 VPC의 서브넷(AZ당 1개) Transit Gateway(AZ를 지정, 최대 5개)
엔드포인트 ENI 호스팅 VPC 서브넷에 생성 고객 VPC에 없음(client-vpn 연결)
IPv4 소스 주소 Client VPN ENI IP로 SNAT. 동시 사용자가 같은 대상에 접속하면 PAT [D2] 클라이언트 CIDR 주소와 포트 그대로(SNAT 없음) [D1][실측]
보안 그룹 엔드포인트에 SG 적용, 워크로드 SG에서 참조 가능 엔드포인트 SG 미지원, 워크로드 SG에서 클라이언트 CIDR로 허용 [D1][B1]
Client VPN 라우트 연결 시 VPC 로컬 라우트 자동 추가, 라우트에 대상 서브넷 지정 자동 라우트 없음, 대상 서브넷 없이 목적지 CIDR만 지정 [D1][B1]
다중 VPC 접근 호스팅 VPC에서 피어링 또는 TGW 추가 구성 TGW 라우팅 테이블로 바로
가시성 목적지에서 사용자를 구분하기 어려움 TGW 흐름 로그에 실제 클라이언트 IP 기록 [W1][B1][D3]. VPC 흐름 로그에도 기록 [실측]
전환 - 기존 엔드포인트를 바꿀 수 없음, 새 엔드포인트를 만들어 병행 후 전환 [B1]

3. 동작 아키텍처

공식 문서가 설명하는 동작 순서는 다음과 같습니다. [D1]

  1. 엔드포인트 생성: Client VPN 엔드포인트를 만들면서 Transit Gateway ID를 지정합니다. 문서는 생성 직후 엔드포인트 상태가 pending-associate라고 하지만, [실측] 상태 코드는 pending이었고 available까지 약 20분 걸렸습니다.
  2. 연결 자동 생성: AWS가 client-vpn 타입의 Transit Gateway 연결을 만듭니다. [실측] 이 연결은 약 1.5분 만에 available이 됐습니다.
  3. AZ 선택: 사용할 AZ를 지정합니다. 지정하지 않으면 AWS가 2개를 고릅니다.
  4. 라우트 구성: Client VPN 라우팅 테이블에 목적지 CIDR을 추가합니다(대상 서브넷 없음).
  5. 트래픽 흐름: 클라이언트 → Client VPN 엔드포인트 → Transit Gateway → Transit Gateway 라우팅 테이블에 따라 목적지 네트워크로 전달됩니다.

라우팅은 세 곳에서 맞아야 합니다. [D1][B1]

위치 필요한 설정
Client VPN 라우팅 테이블 목적지 CIDR별 라우트(자동 추가 없음, 대상 서브넷 없음). 블로그는 전체 터널이면 권한 부여 규칙만 있으면 된다고 하지만, [실측] 전체 터널에도 0.0.0.0/0 라우트가 필요했습니다
Transit Gateway 라우팅 테이블 client-vpn 연결이 연결된 라우팅 테이블에 목적지 라우트(전파 또는 정적). 다른 연결의 라우팅 테이블에는 client-vpn 연결을 전파해 클라이언트 CIDR 복귀 경로를 만든다
목적지 VPC 라우팅 테이블 클라이언트 CIDR → Transit Gateway 복귀 라우트(이미 0.0.0.0/0 → TGW가 있으면 불필요)

client-vpn 연결은 IPv4·IPv6 클라이언트 CIDR을 Transit Gateway 라우팅 테이블에 전파합니다. 반대로 Transit Gateway의 라우트가 클라이언트에 자동으로 내려가지는 않습니다. [B1] [실측] 10.100.0.0/22와 함께 /25 5개가 전파됐고, 클라이언트는 /27 단위로 주소를 받았습니다.

4. 주요 특징

5. 제약 사항과 고려 사항

구분 내용 출처
연결 유형 한 엔드포인트에 VPC 서브넷 연결과 TGW 연결을 섞을 수 없음. 생성 시 하나를 고르며 나중에 바꿀 수 없음 [D1][B1]
보안 그룹 엔드포인트 SG와 SG 기반 권한 부여 미지원. 네트워크(CIDR) 기반 권한 부여 규칙만 사용. API에서 TransitGatewayConfiguration과 VpcId/SecurityGroupIds를 함께 지정할 수 없음([실측] 검증 오류가 아니라 InternalError로 거부). 워크로드 SG에서는 client IP /32 단위 제어가 가능하지만 재접속하면 IP가 바뀜 [D1][C1]
라우트 TGW에서 Client VPN으로 라우트 자동 전파 없음. 목적지 라우트를 직접 정의 [D1]
CIDR 클라이언트 CIDR은 /12~/22, 생성 후 변경 불가. TGW 연결 VPC, TGW CIDR 블록, 온프레미스 범위와 겹치지 않아야 함(권고). TGW는 연결된 VPC 간 CIDR 중복을 지원하지 않음. [실측] /23은 거부되지만, VPC나 TGW CIDR과 겹치는 클라이언트 CIDR은 API가 막지 않고 available까지 진행되므로 주소 계획에서 직접 검증해야 함 [D1][D2][B1]
TGW CIDR TGW에 IPv4 CIDR 블록이 있어야 함(IPv6·듀얼 스택은 IPv6 CIDR도). [실측] 없으면 There is no IPv4 or IPv6 CIDR block associated with the Transit Gateway로 거부. 엔드포인트마다 리전의 AZ 수 × 2개 TGW IP를 선택한 AZ와 무관하게 예약(서울 4개 AZ → 8개). 예약 주소는 ENI나 흐름 로그로는 보이지 않음 [D1][B1]
리전 엔드포인트와 TGW는 같은 리전. TGW 리전 간 피어링을 통한 Client VPN 연결 미지원 [D1]
AZ 최대 5개, 미지정 시 2개 자동([실측] apne2-az2·az3가 선택되고 AZ ID로 표시). Client VPN과 TGW가 모두 지원하는 AZ여야 함. 고가용성을 위해 2개 이상 권장 [D1][B1]
복귀 경로 TGW에 연결된 VPC에 클라이언트 CIDR → TGW 라우트가 없으면 접근 불가 [D1]
인터넷 전체 터널로 인터넷을 쓰려면 TGW에 연결된 VPC에 NAT가 있어야 함(IPv4는 NAT 게이트웨이가 client IP를 공인 IP로 변환) [D1]
DNS 블로그는 VPC 리졸버(VPC CIDR +2)가 TGW 연결로 닿지 않으니 Route 53 Resolver 인바운드 엔드포인트나 온프레미스 DNS를 쓰라고 함. [실측] 10.10.0.2가 분할·전체 터널 모두에서 응답했고, 분할 터널에서 사설 이름 해석도 확인함. 지원 여부가 문서와 다르므로 운영 설계는 블로그 권고(인바운드 엔드포인트)를 따르는 편이 안전 [B1]
전환 현장 변환 불가. 겹치지 않는 클라이언트 CIDR로 새 엔드포인트를 만들어 병행 운영. 엔드포인트 SG를 참조하던 규칙은 새 클라이언트 CIDR 규칙으로 바꿔야 함 [B1]

6. 요금(서울 리전)

AWS Price List API 기준(2026-10-24 조회)입니다. [P1]

항목 단가
Client VPN 엔드포인트 연결(AZ당) $0.10/시간
Client VPN 연결 $0.05/시간
Transit Gateway 연결 $0.07/시간
Transit Gateway 데이터 처리 $0.02/GB

7. 운영 시 주의할 동작(실측)

문서에는 없지만 실습에서 확인한 동작입니다.

동작 영향 대응
엔드포인트 available까지 약 20분, 라우트·권한 부여 규칙 하나에 1.5~8분 배포·변경 시간이 깁니다(CloudFormation 스택 44분) 변경 일정을 넉넉히 잡습니다
CloudFormation이 라우트 두 개를 동시에 만들자, 하나가 API 성공 뒤 나타나지 않음(1회 관찰, 원인은 동시 생성으로 추정) 스택이 라우트를 기다리며 멈춤 라우트끼리 DependsOn으로 순서를 정합니다(템플릿 반영, 효과 미검증)
권한 부여 규칙을 추가하거나 라우트를 지우면 접속 중인 세션이 리셋됨(규칙 추가: server-pushed-connection-reset, 라우트 삭제: 핑 타임아웃 뒤 재접속 auth-failure) 사용자가 재접속하고 client IP가 바뀝니다 유지 보수 시간에 변경합니다. 클라이언트는 자동 재시도로 설정합니다
전체 터널에서 0.0.0.0/0 라우트가 없으면 클라이언트의 인터넷이 끊김 클라이언트의 모든 인터넷 통신이 막힙니다 전체 터널 설정(권한 부여 규칙과 라우트)을 먼저 끝내고 사용자를 접속시킵니다
끊긴 세션이 describe-client-vpn-connections에 active로 남음 연결 수 파악에 오차가 생깁니다 연결 로그와 함께 봅니다

8. 실습 결과

테스트별 결과와 문서와 다른 점은 테스트 결과에 정리했습니다.

출처