SaaS 트래픽을 올바른 고객 VPN으로 라우팅하는 방법

한 SaaS 플랫폼이 열두 개의 고객 네트워크에 연결되어 있고, 그중 두 고객이 모두 기본 데이터베이스에 10.20.0.10을 사용합니다. 작업에서 그 주소를 받은 워커는 그 작업이 어느 데이터베이스를 뜻하는지 알 방법이 없으며, 공유 라우팅 테이블은 접두사가 가리키는 터널로 기꺼이 보낼 것입니다. 해결책은 터널을 늘리는 것이 아니라 테넌트 ID가 경로의 어디에서 들어오는지, 주소 계획이 어떤 격리 모델을 요구하는지 결정하는 것입니다. 세 가지 조건이 선택을 결정합니다: 고객 접두사가 겹치는지, 실수가 얼마나 멀리 퍼질 수 있는지, 누가 커넥터를 운영하는지입니다.

두 고객 데이터베이스, 하나의 목적지 주소

IP 주소는 위치이지 ID가 아닙니다. 요청은 서버가 검증한 테넌트를 실어야 하며, 그 테넌트는 목적지가 확인되기 전에 네트워크 컨텍스트를 선택해야 합니다.

그렇게 하지 않으면 실패는 조용합니다. 연결은 성공하고 쿼리는 실행되며, 라우팅 테이블에 10.20.0.10에 대한 항목이 하나뿐이었기 때문에 응답은 잘못된 고객의 데이터베이스에서 옵니다. DNS는 상황을 더 나쁘게 만듭니다: 테넌트 A의 컨텍스트에서 확인된 캐시된 이름이 테넌트 B를 위해 실행되는 작업에 의해 재사용될 수 있습니다. 패킷 안의 무엇도 둘을 구분하지 못하므로 어떤 재시도 로직도 이를 고치지 못합니다.

먼저 격리 모델을 결정하십시오

제품을 비교하기 전에 세 가지 조건을 적으십시오. 겹침은 하나의 주소 공간을 공유할 수 있는지 결정하고, 영향 반경은 라우팅 실수가 지원 티켓인지 침해인지 결정하며, 운영 소유권은 테넌트별 커넥터 플릿을 운영할 수 있는지 결정합니다.

접두사가 다르고 정책이 통제된 허브를 허용한다면, 테넌트별 라우팅 테이블을 가진 Transit Gateway 하나가 실행 가능합니다. 어태치먼트 연결은 그 어태치먼트에서 들어오는 트래픽에 사용할 라우팅 테이블을 선택하고, 전파는 어떤 경로가 테이블에 나타나는지 선택합니다. 자신의 테이블에만 연결되고 자신의 접두사만 전파하는 테넌트 어태치먼트는 허브에 도달하고 다른 곳에는 도달하지 않습니다. 이는 라우팅 결정이며, 누구도 공유 테이블에 기본 경로를 추가하지 않는 한 올바르게 유지됩니다.

접두사가 겹친다면 라우팅만으로는 분리할 수 없습니다. 테넌트별로 별도의 네트워크 컨텍스트가 필요하거나, 각 고객의 공간에 명확한 의미를 부여하는 변환 계획이 필요합니다.

Transit Gateway 격리가 실제로 의미하는 것

중요한 두 가지 설정은 연결과 전파이며, 둘을 혼동하기 쉽습니다. 연결은 이 어태치먼트의 패킷을 어느 테이블에서 찾는지 답하고, 전파는 어느 테이블이 이 어태치먼트의 경로를 학습하는지 답합니다. 격리는 둘 다 테넌트별로 만드는 데서 나오며, 어태치먼트를 더 만드는 데서 나오지 않습니다.

기본 모두-대-모두 구성은 편리하지만 격리가 아닙니다. 별도의 라우팅 테이블은 연결성을 제한하지만, 같은 라우팅 컨텍스트 안에서 하나의 불변 목적지 주소에 두 가지 의미를 부여하지는 못합니다. 애플리케이션이 테넌트를 알기 전에 10.20.0.10을 확인하면 라우팅 계층은 필요한 정보를 이미 잃은 것입니다.

AWS는 2026년 시월 23일에 Transit Gateway와 Cloud WAN을 위한 어태치먼트 수준 1:1 NAT를 추가했으며, 이는 지원되는 어태치먼트에 대한 겹침 답변을 바꿉니다. Transit Gateway NAT 문서는 호스트 비트를 보존한 정적이고 상태가 없는 동일 접두사 IPv4 매핑을 설명합니다. 이를 전제로 설계하기 전에 지원되는 어태치먼트 유형과 리전 제약을 확인하십시오.

작업을 검증된 테넌트에 묶으십시오

모든 작업은 서버가 검증한 테넌트 ID를 실어야 하며, 그 ID는 관리자가 소유한 연결 레코드를 선택해야 합니다. 레코드는 승인된 네트워크 컨텍스트, 서비스 주소, 자격 증명 참조, 그리고 그곳에서 허용되는 작업을 명시합니다. 신뢰할 수 없는 요청은 자체 VPN 식별자, 게이트웨이 또는 개인 대상을 제공해서는 안 됩니다, 유효한 로그인은 연결된 모든 고객의 주소 공간을 조사할 권한이 아니기 때문입니다.

격리된 커넥터 설계에서 테넌트 A의 작업은 A의 VPC에서 실행되고 A의 승인된 리소스에만 도달할 수 있는 A 전용 커넥터로 갑니다. 한 호스트의 별도 컨테이너는 그 분리를 스스로 만들지 않습니다 — 네트워크 네임스페이스, 경로, 이그레스 정책이 이를 구현해야 합니다. 커넥터에는 테넌트 범위의 자격 증명과 대기열도 필요합니다, 개인 경로는 공유 비밀이나 공유 작업 항목의 범위를 제한하지 않기 때문입니다. 애플리케이션 워커를 풀링해도 네트워크 컨텍스트와 자격 증명을 호스트가 아니라 테넌트별로 선택하는 한 괜찮습니다.

상태 검사는 테넌트와 단계를 명시해야 합니다: 터널 설정, 경로 존재, 실제 서비스 요청 성공은 세 가지 다른 신호입니다. 활성 터널의 집계 수는 커넥터가 고장 난 단 한 고객을 숨길 것입니다.

실패해야 하는 경로를 테스트하십시오

출시 전에 세 가지 테스트를 실행하십시오. 허용된 A 작업은 성공해야 하고, 허용된 B 작업은 성공해야 하며, 의도적으로 B의 커넥터나 번역된 별칭을 향한 A 작업은 닫힌 방식으로 실패해야 합니다. 그런 다음 터널 하나를 끊고 그 작업이 해당 테넌트에 대해서만 실패하며 다른 고객의 같은 번호 서브넷으로 폴백하지 않는지 확인하십시오. 복구도 테스트해야 합니다, 오래된 경로나 캐시된 자격 증명이 중단보다 오래 살 수 있기 때문입니다.

아키텍처는 격리된 커넥터를 가진 풀링된 워커이거나 완전히 분리된 테넌트 리소스일 수 있습니다. 불변 조건은 같습니다: 검증된 테넌트 컨텍스트가 경로와 자격 증명을 선택하며, 어떤 경로 변경도 테넌트 간 애플리케이션 권한을 부여하지 않습니다.