서론
스터디를 통해 팀 근두운 인프라가 조금씩 단순 기능 구현이 아닌, 운영에 가까운 아키텍처 구조를 갖춰나가고 있다.
현재 우리는 서비스 기능별로 VPC를 분리하는 구조로 인프라를 설계 중에 있으며, 크게 공격용 Kali Linux가 위치하는 VPC(공격 VPC), 플랫폼 서비스를 제공하는 VPC(서비스 VPC), Wazuh와 Velociraptor 보안 도구를 운영하는 VPC(CERT VPC)로 분리할 계획이다. 그리고, 공격 과정에서 발생하는 보안 이벤트 전 과정을 확인하기 위해 Kali Linux와 WEB/WAS 서버에 Agent를 설치 하고자 한다.
이제 여기서 고민이 시작 됐다.
기존 인프라 구성은 하나의 VPC에서 Subnet으로만 기능을 분리했었기 때문에, 각 보안 Agent와 Server 간의 통신을 보안그룹 정책으로만 커버하면 됐다. 하지만, 지금은 VPC가 분리되어 있어 보안그룹 정책만으로는 사설 IP 간 통신을 구현할 수가 없다.
그렇게 방법을 찾아 보던 중 AWS 서비스에서 서로 다른 VPC간의 연결을 지원하는 기능들을 발견하게 되었다.
그런데, 방법이 또 세 가지나 있어 어떤 방식을 근두운 인프라에 적용하는게 좋을지 고민하는 과정을 글로 남기려고 한다.
VPC간 통신 서비스에 대해 살펴보기 전, 현재 팀 근두운 인프라 네트워크 구성을 확인한다.
🏛️ 팀 근두운 아키텍처(네트워크 배치 위주)

VPC간 통신 서비스
VPC 간의 통신을 지원하는 세 가지 방식의 특징에 대해 살펴본다.
VPC Peering
VPC 피어링은 서로 다른 두 개의 VPC를 직접 연결하여, 두 VPC 간의 트래픽을 사설 IP로 전송할 수 있도록 해준다. 한 쌍의 VPC만 피어링 연결을 맺을 수 있어, 여러 VPC 간의 연결이 필요하면 각 VPC마다 별도의 피어링 연결을 설정해 주어야 한다. 그리고, VPC 피어링은 단방향 통신과 양방향 통신 모두 지원하며, 이는 라우팅 테이블과 보안그룹을 어떻게 정의 하느냐에 따라 달라진다.
피어링 연결 설정은 동일 계정 또는 다른 계정, 동일 리전 또는 다른 리전 간의 설정도 가능하며, 피어링 요청자 VPC(Requester)와 수락자 VPC(Accepter)로 구분 된다. 동일 계정 내에서는 내가 요청하고 내가 수락하는 것이기 때문에, 어떤 VPC를 요청자로 정할지는 큰 의미가 없다.
피어링 연결 설정 예시 Terraform 코드를 작성하면, 다음과 같은 구조가 된다.
resource "aws_vpc_peering_connection" "peering" { peer_vpc_id = <수락자 VPC ID> vpc_id = <요청자 VPC ID> auto_accept = true # 자동 수락 여부 }
피어링 생성이 끝나면, 라우트 테이블에서 피어링 경로를 허용해 연결을 완성해야 한다.
즉, VPC 피어링에서 서로 다른 VPC 간 통신을 구성하기 위해서는 연결할 VPC 간의 피어링을 먼저 생성해 주고, 실제 통신할 서브넷 또는 인스턴스 사설 IP주소를 라우트 테이블에 정의해주면 된다.
실제 트래픽이 허용 되려면, 보안그룹 설정도 반드시 필요하다.
지금 팀 근두운 아키텍처에서 서비스 VPC ↔ CERT 피어링을 예시로 구현한다면, 피어링 연결을 먼저 만든 다음 라우트 테이블에 다음과 같은 경로 설정을 해준다.
Route Table | Destination | Target |
서비스 VPC
Public Subnet(10.60.10.0/24) | CERT VPC
Private Subnet(10.50.10.0/24) | 서비스 ↔ CERT 피어링
(pcx-...) |
CERT VPC
Private Subnet(10.50.10.0/24) | 서비스 VPC
Public Subnet(10.60.10.0/24) | 서비스 ↔ CERT 피어링
(pcx-...) |
이를 Terraform 코드로 작성해보면 다음과 같이 작성할 수 있다.
# 서비스 VPC -> CERT VPC resource "aws_route" "SERVICE_to_CERT" { route_table_id = <서비스 VPC Public Subnet의 라우트 테이블> destination_cidr_block = <CERT VPC Private Subnet의 IPv4 CIDR> vpc_peering_connection_id = <서비스 <-> CERT 피어링> } # CERT VPC -> 서비스 VPC resource "aws_route" "CERT_to_SERVICE" { route_table_id = <CERT VPC Private Subnet의 라우트 테이블> destination_cidr_block = <서비스 VPC Public Subnet의 IPv4 CIDR> vpc_peering_connection_id = <서비스 <-> CERT 피어링> }
VPC 피어링은 VPC 간의 통신을 피어링 생성, 라우트 테이블 경로 설정, 보안그룹 허용 만으로 구현할 수 있어 구성이 단순하고 쉽다는 장점이 있다.
비용 구조는 피어링 연결 자체에는 비용이 부과되지 않고 트래픽 발생 시에만 요금이 부과되는 방식인데, 리전과 가용 영역에 따라 차이가 있다.
통신 구조 | 데이터 전송 비용 |
같은 리전, 같은 AZ | 무료 |
같은 리전, 다른 AZ | 송신 측과 수신측 각각 $0.01/GB |
다른 리전 | 리전 간 데이터 전송 요금 적용(AWS 요금 확인) |
PrivateLink
PrivateLink는 다른 VPC에 있는 특정 서비스에 사설 IP로의 연결을 제공하는 AWS 기능이다. 앞의 VPC Peering이 두 VPC 사이에 네트워크 경로를 만들었다면, PrivateLink는 접속하려는 VPC에 서비스 전용 접속 지점(Endpoint)을 생성하고, 이를 통해 다른 VPC와 통신이 가능하게 해주는 것이다.
엄밀히 말하면, PrivateLink는 VPC간 통신의 개념은 아니고 VPC내 특정 서비스를 Endpoint 개념으로 접근할 수 있도록 해주는 기능이다.
PrivateLink 구성을 위해서는 서비스를 사용하는 측(Consumer)에 VPC Endpoint(Interface Endpoint)를 생성하고, 서비스를 제공하는 측(Provider)에 NLB와 VPC Endpoint Service를 생성해야 한다.
여기서 NLB는 VPC Endpoint Service와 매핑되어 타겟 그룹의 서비스로 트래픽을 연결해주는 역할로 VPC Endpoint Service 사용을 위해 반드시 필요로 한다.
그리고 PrivateLink는 VPC Endpoint를 생성한 Consumer 측의 VPC에서 VPC Endpoint Service를 생성한 Provider 방향으로만 새 연결을 시작할 수 있다.(단방향)
동작의 원리를 조금 더 자세하게 찾아보니,
Hyperplane이라는 기술이 자주 언급되었다. Hyperplane은 AWS의 분산 상태 저장(Stateful) 네트워크 가상화 플랫폼으로, AWS 네트워크 인프라 자체에 내장되어 대규모 네트워크 연결과 상태를 고성능으로 처리하기 위해 사용하는 기술이다.쉽게 말하면, AWS가 제공하는 NAT, NLB, PrivateLink 등의 고성능 네트워크 서비스들을 구동시키는 엔진 역할을 하는 기술인 것이다.
PrivateLink 동작에서
Hyperplane은 VPC Endpoint 생성 시, Consumer VPC의 서브넷에 ENI를 생성해주고, 이를 Hyperplane fleet(AWS가 내부적으로 관리하는 네트워크 인프라)에 연결한다. 그리고 ENI로 들어오는 트래픽을 받아서 Provider 측 NLB로 전달함으로 서로 다른 VPC 간의 통신을 구현해준다.팀 근두운 인프라를 기준으로 실제 트래픽 흐름을 살펴 보면, 아래 흐름으로 볼 수 있다.
flowchart TD
subgraph ATT["공격 VPC 10.180.0.0/16"]
DNS1["Route 53 Resolver"]
subgraph Pub1["Public Subnet 10.180.40.0/24"]
Kali["EC2<br/>Kali Linux<br/>Wazuh/Velociraptor Agent"]
end
Kali -->|"1. DNS 조회"| DNS1 -->|"2. Endpoint ENI 사설 IP 반환"| Kali
Kali -->|"3. TCP 1514/8000 요청"| ENI
subgraph Pri1["Private Subnet 10.180.140.0/24"]
ENI["VPC Endpoint ENI<br/>(Interface Endpoint)"]
style ENI fill:#87CEFA,stroke:#0000FF,stroke-width:2px,color:#000
end
end
ENI -->|"4. 트래픽 전달"| Link
subgraph SER["서비스 VPC 10.60.0.0/16"]
DNS2["Route 53 Resolver"]
subgraph Pub2["Public Subnet 10.60.10.0/24"]
WEB["EC2<br/>WEB 서버<br/>Wazuh/Velociraptor Agent"]
WAS["EC2<br/>WAS 서버<br/>Wazuh/Velociraptor Agent"]
end
Pub2 -->|"1. DNS 조회"| DNS2 -->|"2. Endpoint ENI 사설 IP 반환"| Pub2
Pub2 -->|"3. TCP 1514/8000 요청"| ENI2
subgraph Pri2["Private Subnet 10.60.50.0/24"]
ENI2["VPC Endpoint ENI<br/>(Interface Endpoint)"]
style ENI2 fill:#87CEFA,stroke:#0000FF,stroke-width:2px,color:#000
end
end
ENI2 -->|"4. 트래픽 전달"| Link
subgraph Hyp["AWS Hyperplane"]
Link["AWS PrivateLink<br/>ENI 사설 IP -> NLB 사설 IP"]
style Link fill:#FFB6C1,stroke:#FF1493,stroke-width:2px,color:#000
end
Link -->|"5. VPC Endpoint Service 연결"| SERVICE
subgraph CERT["CERT VPC 10.50.0.0/16"]
SERVICE["VPC Endpoint Service"]
style SERVICE fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px,color:#000
SERVICE -->|"6. Listener 수신"| NLB
subgraph Pri3["Private Subnet 10.50.10.0/24"]
NLB["NLB"]
style NLB fill:#FFFFE0,stroke:#FFEB00,stroke-width:2px,color:#000
subgraph TG["Target Group"]
Wazuh["Wazuh SIEM<br/>(1514, 1515)"]
Velociraptor["Velociraptor Server<br/>(8000)"]
end
NLB --> Wazuh
NLB --> Velociraptor
end
end
VPC Endpoint를 생성할 때 생성된 서브넷의 ENI는 사설 IP 주소를 가지며, 보안그룹을 적용할 수 있어 트래픽을 제어할 수 있다.
이 ENI가 Consumer VPC 내부의 트래픽 진입점이 되며, 이를 통해 들어온 모든 트래픽은 PrivateLink를 통해 Provider 서비스로 전달된다.
VPC Endpoint ENI는 HyperPlane으로 연결되는 터널 역할
PrivateLink는 VPC Peering과 비교했을 때, ENI를 통한 사설 IP 연결을 지원하기 때문에, 연결 범위의 폭을 요구사항에 맞춰 최소화 할 수 있고, NLB + ENI 기반 세분화된 보안그룹으로 보안성에 강점이 있다. 그리고, 완전 격리 구조로 CIDR 충돌방지(중복 CIDR 허용) 특징이 있어 멀티 계정 구조에서 활용하기 좋다.
하지만, Consumer → Provider의 단방향 트래픽만을 허용하고, NLB와 VPC Endpoint Service, VPC Endpoint(Interface Endpoint) 구성을 요구하는 단점도 존재한다.
거기에 Interface Endpoint 비용과 NLB 비용까지 고려하면, 팀 근두운 인프라에 적용 할지는 협의가 필요하다.
구분 | 비용 발생(ap-northeast-2 기준) |
Interface Endpoint | VPC Endpoint 생성 AZ마다, 사용 시간만큼 부과 $0.013/Hour |
Endpoint 데이터 처리 비용 | 처리된 데이터양에 따라 부과, $0.01/GB |
NLB | NLB 실행 시간과 NLCU 사용량에 따라 부과,
(NLB $0.0243/Hour, 1NLCU $0.006/Hour) |
Transit Gateway
Transit Gateway(TGW)는 중앙 네트워크 허브로, 여러 VPC를 중앙 허브에 연결해 VPC 간의 라우팅을 지원하는 AWS 가상 라우터이다. 이뿐만 아니라 다양한 연결 방식을 지원하고, 리전 단위로 생성할 수 있다.
연결 방식(Attachment) | 특징 |
VPC | 동일 계정 또는 다른 AWS 계정의 VPC를 연결 |
Site-to-Site VPN | VPN을 통해 온프레미스 IDC를 AWS와 사설로 연결 |
Direct Connect | 고속의 전용선(DX)을 통해 온프레미스와 VPC 간 대용량・고품질 사설 통신을 지원 |
Transit Gateway Peering | 서로 다른 TGW와 1:1 피어링 연결 |
… | … |
가장 일반적으로 사용되는 연결 방식은 VPC Attachment로, 팀 근두운 인프라에 적용한다면 가장 적합한 방식이기도 하다.
flowchart LR
subgraph AWS["AWS 동일 계정 / 동일 리전"]
VPC1["공격 VPC"]
VPC2["서비스 VPC"]
TGW["Transit Gateway"]
VPC3["CERT VPC"]
end
VPC1 <--> TGW
VPC2 <--> TGW
VPC3 <--> TGW 원리를 살펴보면, VPC를 TGW에 붙일 때 AZ별로 서브넷을 하나씩 지정하는데, 이때 Hyperplane 기반의 TGW용 ENI가 생성되면서 VPC 전체와 TGW 간의 통신을 지원한다. 그리고, TGW의 라우트 테이블에서 통신할 VPC 라우팅 경로를 생성해주게 되면, VPC 간의 사설 IP 통신이 가능해진다.
단, 팀 근두운 인프라에서는 공격 VPC와 서비스 VPC간의 사설 IP 통신은 설계 목적상 불필요하기 때문에, TGW 라우트 테이블 경로 설정 시 공격 VPC ↔ 서비스 VPC 라우팅은 제외해야 한다.
공격 VPC는 모의해킹을 위한 네트워크 영역으로, 서비스 VPC의 플랫폼에 공인 IP로 접근
이처럼 TGW는 경유지 역할을 하며, 연결된 VPC들 간의 통신을 TGW 라우트 테이블만으로 관리할 수 있어 연결할 VPC가 많을 수록 효율적인 방법이다.
단, TGW에 연결된 VPC Attachment 개수 별로 비용이 추가 되며, 데이터 전송량에 따라 별도 요금도 부과된다.
구분 | 비용(ap-northeast-2 기준) |
AWS Transit Gateway 연결 요금 | Attachment당 $0.07/Hour |
데이터 전송 요금 | $0.02/GB |
해당 방식은 스케일링과 중앙화된 연결에 강점이 있어 대규모 네트워크에 적합하며, 비용도 VPC Peering과 PrivateLink 방식에 비해 다소 높다.
따라서, TGW를 활용한 VPC 간 통신은 팀 근두운 인프라에서 요구하는 기능에 비해 비용 부담이 크다고 판단된다.

튜토리얼: AWS Transit Gateway 시작하기 - Amazon VPC
Transit Gateway는 가상 프라이빗 클라우드와 온프레미스 네트워크를 상호 연결하는 데 사용할 수 있는 네트워크 전송 허브입니다. Transit Gateway는 가상 프라이빗 클라우드와 온프레미스 네트워크를 상호 연결하는 데 사용할 수 있는 네트워크 전송 허브입니다.
결론
이제 AWS에서 VPC 간 통신 방법을 이해했고, 우리 팀 근두운 인프라에는 어떤 방식을 사용할지 결정해야 한다.
VPC Peering, PrivateLink, Transit Gateway특징을 정리해보면, 다음 표와 같다.
구분 | VPC Peering | PrivateLink | Transit Gateway |
연결 방식 | VPC 간 라우팅 구성 | ENI를 통한 Private 연결 | 중앙 허브에 VPC 연결 |
방향성 | 양방향 | 단방향(Consumer → Provider) | 양방향 |
적합 구조 | 소규모 VPC 간 1:1 연결 | 특정 공통 서비스에 한해서 공유할 경우 | 대규모 멀티 네트워크 |
비용
(월 기준,
팀 근두운 상황) | 무료
(같은 리전, 같은 AZ) | 약 $41 + 데이터 전송 요금
(Interface Endpoint 2개, NLB 1개) | 약 $153 + 데이터 전송 요금
(VPC 3개 연결) |
우선 규모와 비용을 고려했을 때, Transit Gateway는 고민 대상에서 제외를 했고 VPC Peering과 PrivateLink 중에서 어떤 방식이 좋을지 고민이 깊었다.
우리의 목적은 공격 VPC의 Kali EC2와 서비스 VPC의 WEB/WAS EC2에 설치 될 보안 Agent가 수집한 이벤트를 CERT VPC의 Server로 전송하는 것으로 한정되어 있다.
보안 프로젝트임을 고려했을 때, PrivateLink 방식이 위 요구에서 CERT의 노출 범위를 가장 좁히기 쉬워 이 방식을 사용하는게 적절하다고 생각한다.
하지만, 월 고정 비용과 초기 구성 난이도를 생각했을 때, PrivateLink 방식이 부담 되기도 한다.
따라서, 우선 VPC Peering 방식을 채택하여 통신 목적을 달성하고, 이후에 여유가 된다면 PrivateLink 방식으로 전환해 보는 것으로 최종 결정하였다.
VPC Peering 구성 시 라우팅 경로와 보안그룹을 최소 권한 원칙으로 적절히 제한하여 운영하자.
