VPC 네트워크의 연결, VPC Peering & Transit Gateway

클라우드 환경에서 네트워크 구조를 구성할 때, VPC와 같은 가상 네트워크 서비스를 이용한다. 서비스 운영 범위가 방대해지거나 다른 리전 등의 네트워크 망과 통신을 해야하는 경우가 발생하게 된다. 이러한 상황에 AWS VPC의 VPC Peering과 Transit Gateway라는 솔루션을 이용할 수 있다.

이번에는 VPC Peering과 Transit Gateway를 알아보고 간단한 활용 아키텍쳐를 구축해보도록 한다.

 

VPC Peering

VPC의 프라이빗 IP주소를 사용해, 두 VPC 간에 트래픽을 라우팅할 수 있도록 일대일 연결한 네트워킹 구조

 

이러한 VPC Peering은 같은 리전, AZ의 VPC 뿐만 아니라, 다른 AZ, 리전, 계정의 VPC와 연결할 수 있다. 당연하게도 연결하려는 두 VPC의 Network CIDR이 겹치는 구간이 존재해서는 Peering을 생성할 수 없다.

Peering을 통한 모든 트래픽은 인터넷을 타지 않는 프라이빗 연결로 이루어진다. 

 

VPC Peering은 VPC 간의 일대일 연결이다.

다수의 VPC를 모두 연결하고자 하는 경우, 아래와 같이 모든 VPC를 각각 Peering 연결해주어야 한다.

 

위와 같이 다수의 VPC와 연결하게 되면, 맺어야할 Peering의 갯수가 증가하게 된다.

(VPC n개의 연결 → n(n-1) / 2 개의 Peering)

 

Peering에서의 라우팅은 각 VPC의 서브넷의 라우팅 테이블을 통해 연결된 다른 VPC의 Peering으로 전송하여 구성한다. 

 

Peering에는 Requester와 Accepter의 개념이 존재한다. Peering을 맺기 위해서는 요청자(Requester)가 연결하고자 하는 대상(Accepter)에게 요청을 먼저 보낸다. Accepter는 이 요청을 수락해야 Peering 연결이 활성화되는 구조이다.

 

 

Transit Gateway

중앙 Hub 형식으로 VPC와 온프레미스 네트워크를 연결하기 위한 솔루션, 클라우드 환경에서의 라우터로 볼 수 있다.

Transit Gateway는 리전 단위의 리소스로, Transit Gateway 하나로 리전 내의 모든 VPC에 연결할 수 있다.

 

VPC Peering과 마찬가지로 Transit Gateway를 통하는 트래픽은 모두 프라이빗 연결로, Transit Gateway는 서브넷의 라우팅 테이블이 아닌 Transit Gateway 라우팅 테이블을 사용해 모든 연결 간 트래픽을 라우팅해준다. 

패킷의 대상 IP주소를 기반으로 라우팅을 하기에 L3 계층에서 동작하는 것을 알 수 있다.

 

또한, Transit Gateway 간의 Peering을 구성해 두 Gateway간의 트래픽 라우팅, 리전-리전 간의 통신을 구현할 수 있다. Transit Gateway와 연결할 수 있는 대상은 VPC와 Transit gateway외에도 VPN, Direct Connect도 존재한다.  

 

Transit Gateway를 통해 VPC를 연결하기 위해서는 Transit Gateway를 생성한 뒤, Transit Gateway의 라우팅 테이블에 각 VPC로 연결될 수 있도록 라우팅을 추가해주어야한다.

 

예시 아키텍쳐 구축

이번 실습도 Terraform을 통해 VPC Peering과 Transit Gateway 아키텍쳐를 간단하게 구축해보도록 한다.

VPC Peering

서울과 오사카 리전에 각각 VPC를 하나씩 생성 후, Peering으로 연결해보도록 한다.

Requester는 서울 VPC, Peering을 수락하는 Accepter는 오사카 VPC로 한다.

 

아키텍쳐 구성이 완료되면 각 인스턴스에서 Peering된 다른 VPC의 인스턴스의 프라이빗 IP로 접근을 시도해본다.

간단하게 Ping을 통해 연결성을 테스트해 보았다. (물론 각 인스턴스의 보안그룹 중 ICMP에 대한 설정이 필요)

각 리전의 인스턴스에서 Peering 연결된 다른 리전의 인스턴스로 통신

 

이렇게 VPC Peering을 통해 각 인스턴스의 프라이빗 IP에 접근 가능한 것을 확인할 수 있다.

 

Transit Gateway

마찬가지로 서울 리전과 오사카 리전에 VPC를 생성하고 Transit Gateway를 통해 두 리전의 VPC를 연결해 보도록 한다.

두 리전 간의 연결이 필요하므로 각 리전의 Transit Gateway를 Peering 연결하는 과정도 필요한 것을 알 수 있다.

 

앞서 이야기했듯이 Transit Gateway를 생성하고, 두 Gateway 간의 Peering을 생성한 뒤에는 Peering을 Accept해주고 라우팅을 지정해주어야 하는 것을 잊지 말아야한다.

# Transit Gateway Peering
# 두 리전의 Transit GW끼리 연결, 서울(요청) -> 오사카(수락)
resource "aws_ec2_transit_gateway_peering_attachment" "tgw-peering" {
  peer_account_id = aws_ec2_transit_gateway.osaka-tgw.owner_id
  peer_region = "ap-northeast-3"
  peer_transit_gateway_id = aws_ec2_transit_gateway.osaka-tgw.id
  transit_gateway_id = aws_ec2_transit_gateway.seoul-tgw.id
}

# Transit Gateway Peering Accepter
# peer 연결을 받을 Osaka에서 Accept 처리
resource "aws_ec2_transit_gateway_peering_attachment_accepter" "osaka-tgw-peering" {
  provider = aws.osaka
  transit_gateway_attachment_id = aws_ec2_transit_gateway_peering_attachment.tgw-peering.id
}

# Transit Gateway Route
# 서울 <-> 오사카 라우트 지정 필요 (리전을 넘어가는 peering을 생성했기에)
# transit_gateway_attachment_id : peering을 타고 트래픽이 넘어가야하므로 vpc_attachment가 아닌 peering attachment
# transit_gateway_route_table_id : TGW routing table은 별도로 만들어 주지 않았으므로 기본 routing table을 지정
resource "aws_ec2_transit_gateway_route" "seoul-to-osaka" {
  destination_cidr_block = "192.168.0.0/16"
  transit_gateway_attachment_id = aws_ec2_transit_gateway_peering_attachment.tgw-peering.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway.seoul-tgw.association_default_route_table_id
}

resource "aws_ec2_transit_gateway_route" "seoul-to-osaka-2" {
  destination_cidr_block = "192.169.0.0/16"
  transit_gateway_attachment_id = aws_ec2_transit_gateway_vpc_attachment.seoul-tgw-attachment.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway.seoul-tgw.association_default_route_table_id
}

resource "aws_ec2_transit_gateway_route" "osaka-to-seoul" {
  provider = aws.osaka
  destination_cidr_block = "172.10.0.0/16"
  transit_gateway_attachment_id = aws_ec2_transit_gateway_peering_attachment.tgw-peering.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway.osaka-tgw.association_default_route_table_id
}

 

Peering을 통한 Route를 위와 같이 설정해주지 않는 경우, Peering을 타고 넘어가는 라우팅이 없어 트래픽이 도달하지 못한다.

원활한 리전-리전 통신을 위해 routing을 Peering에 대해 생성해주도록 한다.

 

각 VPC의 인스턴스에서 다른 VPC의 인스턴스로 Ping을 이용해 Transit Gateway를 통한 통신이 잘 되는 것을 확인한다.

서울 → 오사카 리전의 VPC들로 연결

오사카 → 서울 리전의 VPC로 연결

 

이렇게 VPC 네트워크 연결에 사용되는 VPC Peering과 Transit Gateway를 알아보았다. 

각 솔루션들을 실제로 도입을 하기 전에 할당량과 솔루션별로 적용되는 요금을 항상 염두에 두어야한다.

 

할당량 & 요금

두 솔루션 모두 Peering, Gateway 생성에 대한 요금은 없다. 다만 Transit Gateway는 Gateway에 생성된 연결의 갯수별로 시간당 $0.05의 요금이 부과된다.

데이터 전송 요금에 대해서는 VPC Peering은 계정과 관계없이 동일한 가용영역 간의 트래픽은 요금 부과가 없고, Transit Gateway는 Gateway를 통하는 모든 트래픽에 대해서는 $0.02/GB 요금이 부과된다.

각 솔루션의 할당량과 요금의 정보는 아래 Docs에서 확인할 수 있다.

VPC 피어링 연결 할당량 - Amazon Virtual Private Cloud

 

Transit Gateway에 대한 할당량 - Amazon VPC

AWS Transit Gateway 요금 – Amazon Web Services

 

 

실습에 사용된 Terraform 코드는 Repo에서 확인할 수 있다.