서론
상황에 따라 하나의 서비스를 만드는데 단일 VPC가 아닌 여러 VPC를 합쳐서 만들어야 하는 경우도 있을 것이다.
AWS로 서비스를 천천히 이전하면서 기존 온프레미스 환경과 AWS 환경을 통합하여 사용하고 싶은 경우도 있을 것이다.
민감한 데이터를 이용하는 서비스를 만들어야 하는데 보안상 이유로 별도의 온프레미스 데이터센터에 보관하며 서비스를 구축해야 하는 경우도 있을 것이다.
그런데, 어차피 인터넷 연결이 되어있을거고 그러면 그냥 인터넷 망을 타고 서로 접속하게 해도 되지 않을까?
물론 가능하다. 하지만, 매우 비효율적이다.
AWS의 트래픽 요금 (23년도 5월 서울 리전, EC2, 최저요금 기준)
모든 데이터 수신 : 무료
인터넷으로 데이터 송신 : GB당 0.108 USD
동일 가용영역간 데이터 전송 : 무료
동일 리전 내 다른 가용영역간 데이터 전송 : 0.01 USD
추가적으로 Direct Connect를 이용한다면 전용 연결을 통해 AWS 리전에 직접 연결되므로, 데이터 전송 비용 및 인터넷 대역폭 요금을 줄일 수 있다.
물론 가용영역끼리 또한 전용 연결이 사용된다.
이말인 즉슨, 그냥 인터넷 망을 통해서 통신하는 것은 비용적으로나 효율성으로나 매우 손해를 보는 일이라는 것이다.
비용이 얼마 발생하지 않는 소규모 서비스는 몰라도 실제 수익을 내는 대규모의 서비스는 이런 차이가 크게 다가올 것이다.
VPC Peering
용어 그대로다. VPC간의 연결을 의미한다.
VPC간의 피어링은 계정이나 리전의 영향을 받지 않는다. 서로 피어링 승인만 된다면 연결할 수 있다.
다만, 한가지 제약사항이 존재한다.
VPC의 CIDR이 겹치지 않을 것.
VPC 피어링은 그냥 피어링 생성만 한다면 바로 적용되는 아주 간단한 방법이다.
두개의 VPC를 연결하는 제일 간편한 수단이라고 할 수 있다.
하지만 VPC 피어링도 단점이 있다.
VPC 피어링을 구성하면 생성되는 Peering Connection(이하 PCX)은 서로 피어링이 설정된 두 VPC의 트래픽이 아니라면 전부 차단한다.
아래의 예시를 보자.
VPC 내의 인스턴스나 서브넷 등은 생략했다.
VPC 1 - VPC 2와 VPC 2 - VPC 3 간의 피어링이 맺어져 있는 것을 확인할 수 있다.
그렇기 때문에 연결된 VPC 끼리는 통신이 아주 잘 될것이라고 예측할 수 있다.
그런데 VPC 1 - VPC 3간의 통신을 시도하면 어떻게 될까?
VPC 2의 라우팅 테이블 규칙만 잘 설정 되어 있다면 VPC 2가 트래픽을 중계하면서 통신에 문제가 없을 듯 하다.
하지만 이것은 불가능 하다.
PCX는 연결된 두 VPC의 트래픽을 제외하고는 전부 거부하기 때문이다. 따라서 VPC 1과 VPC 3의 직접적인 통신은 불가능하다.
그래서 만약 VPC 1과 VPC 3의 직접 통신을 구성하고 싶다면 아래와 같이 새로운 VPC 피어링을 맺어야 한다.
뭐 3개 정도의 VPC라면 그냥 3개의 PCX를 생성하는게 편할 수 있다.
하지만 만약, VPC가 10개, 20개 이렇게 늘어나면 어떨까?
20개의 VPC가 전부 서로 통신이 되게 하려면 190개의 PCX가 필요하다.
아... 이건 좀 그렇다.
이런 문제를 해결할 수 있는것이 바로 조금 있다 설명할 Transit Gateway이다.
Transit Gateway는 VPC만 연결할 수 있는것이 아니다.
그래서 일단 VPN과 Direct Connection을 이용한 온프레미스와의 연결을 우선 설명 한뒤 Transit Gateway를 설명하겠다.
VPN
VPN (Virtual Private Network)
가상 사설망
공중망(주로,인터넷)을 통해 가상으로 구현된(확장시킨) 사설 네트워크
공중망을 마치 확장된 전용 사설망 처럼 사용
공중망을 통해 사적인 트래픽을 비교적 안전하게 통과시키게 됨
네트워크를 공부했다면 VPN에 대한 개념은 잘 알고 있을 것이다.
AWS도 온프레미스 네트워크를 VPC에 연결하기 위한 VPN을 제공한다.
인터넷을 기반으로 물리적으로 분리된 두 네트워크를 마치 하나의 네트워크처럼 이어준다.
아래는 AWS VPC와 온프레미스 네트워크를 VPN을 통해 연결한 토폴로지이다.
AWS에서 VPN을 구성하기 위해서는 VPC에 VGW(Virtual private Gateway)를 생성해야 한다.
그리고 온프레미스 환경에 적절한 환경설정을 수행한 뒤 VPN 커넥션을 맺으면 된다.
상세한 구축 방법은 AWS 공식 문서를 참고하는게 좋을 것이다.
작은 팁으로 하나 짚고 넘어갈 사항이 있다.
VPN 연결은 비록 인터넷망을 타고 이루어지는 통신이지만, IGW를 통해서 트래픽이 오가는것이 아닌 VGW를 통해서 별도로 통신이 이루어 진다.
생각보다 중요한 차이점이니 잘 기억하자.
Direct Connect
Direct Connect
AWS로 전용 네트워크 연결 생성
AWS에 직접 연결하고 퍼블릭 인터넷을 우회하여 애플리케이션 성능 개선 가능
여러 암호화 옵션 제공 및 네트워킹 비용 절감 가능
Direct Connect(이하 DX)도 VPN처럼 온프레미스 환경과 AWS를 연결하기 위한 서비스 중 하나이다.
직역하자면 '직접 연결'이다.
이름에 걸맞게 VPN과는 결정적인 차이점이 있다.
바로 DX는 AWS에서 사전에 구축해놓은 '전용선'을 이용한다는 것이다.
그리고 이 DX의 전용선을 이용하기 위한 접속 지점인 DX Location이 세계 곳곳에 구성되어 있다.
아래의 토폴로지는 온프레미스와 AWS간 DX를 구축한 하나의 예시이다.
DX의 특징은, AWS Cloud와 DX Location간 전용선으로 프라이빗 네트워크가 구성되어 있다는 것이다.
AWS는 자신들의 전용 DX Router를 DX Location의 AWS 전용 Cage에 구축해놨다.
DX Location 내의 Customer Router와 DX Router 또한 크로스 커넥트 되며, 회선 사업자를 통해 온프레미스와 전용선을 구축하게 된다.
이러한 네트워크 연결은 인터넷을 사용하지 않는 전용선이기 때문에 비용이 적게 들고 대역폭이 늘어나며 좀 더 일관된 네트워크 경험을 제공한다.
현재 국내의 DX Location은 KINX 데이터센터와 LG U+ 평촌 데이터 센터에 존재한다.
일관된 품질과 상대적으로 적은 트래픽 비용이라는 장점이 있지만, 별도로 전용선을 구축해야 하기 때문에 손익을 잘 비교한 뒤 도입하는것이 좋을 것이다.
Transit Gateway
VPC 피어링은 1:1 연결만 가능하고, VPN과 DX는 온프레미스와 클라우드를 연결하는데 사용된다.
AWS에서는 이러한 연결을 전부 통합하여 사용할 수 있도록 Transit Gateway를 제공하고 있다.
Transit Gateway
VPC와 온프레미스 네트워크를 연결하는 데 사용하는 네트워크 전송 허브
Transit Gateway(이하 TGW)에 연결할 수 있는 대상은 다음과 같다.
- 하나 이상의 VPC
- Connect SD-WAN/서드 파티 네트워크 어플라이언스
- AWS Direct Connect 게이트웨이
- 다른 Transit Gateway와의 피어링 연결
- Transit Gateway에 대한 VPN 연결
TGW를 사용한다면 VPC를 포함안 여러 네트워크를 중앙 집중식으로 관리할 수 있으며, 그 트래픽 또한 제어 가능하다.
이러한 트래픽은 자동으로 암호화되며 전용선을 사용하기 때문에 퍼블릭 인터넷을 통해 전송되지 않는다.
따라서, 보안 및 네트워크 관리 작업을 단순화하고 전체 네트워크 비용을 절감할 수 있다.
대규모의 네트워크가 구성되는 경우 TGW를 사용하는 것을 고려할 수 있을 것이다.
VPN과 DX의 상호보완
이 내용은 내가 AWS SAA 자격증을 공부하다가 알게된 것이다.
VPN과 DX는 둘 다 AWS 클라우드와 온프레미스 네트워크를 연결하는데 사용된다.
대규모 트래픽이 발생하는 환경이면 VPN보다는 DX를 구성하는 것이 좀 더 효율적일 것이다.
그런데 예기치 못한 사유로 DX에 장애가 발생할 수 있다.
예를 들어 DX Location에 문제가 생긴다던가, DX를 담당하는 Router에 문제가 생긴다던가 하는 경우일 것이다.
이러한 상황에서 네트워크 마비를 막기 위해 VPN도 미리 구성해놓는다면 비록 DX에 비해 속도나 안정성은 떨어지더라도 네트워크가 완전히 마비되는 상황은 방지할 수 있을 것이다.
즉, DX 장애에 대한 대응을 위해 VPN을 사용할 수 있다는 것이다.
