AWS VPC Endpoint (Interface, Gateway)

개요

오늘 포스팅해볼 내용은 VPC Endpoint에 관한 내용이다. AWS의 서비스와 통신할 때 IGW를 통해 외부로 나가면 안 된다는 요구사항을 만족시키기 위해 VPC Endpoint를 사용했는데, 사용하면서 알게 된 내용들을 정리해보려고 한다.

기본 구조

포스팅을 시작하기에 앞서 기본 구조를 설명하려고 한다. Private Subnet에 배치되어 있는 EC2에서 동일한 계정, 리전에 있는 S3를 호출한다고 하면, EC2에서는 S3 Domain에 대한 IP를 얻기 위해 DNS Query를 실행하게 된다. 이때는 Route 53의 Public DNS를 호출하게 된다.

이걸 실제로 확인해보려면 EC2에 접속해서 nslookup결과를 확인해보면 된다. 반환 결과로 나온 IP들이 AWS의 공인 IP인 것을 확인할 수 있다.

어쨌든 응답을 받은 IP로(52.219.146.23이라고 가정) Route Table을 조회해 본다(Route Table을 어떻게 구성했는지에 따라 다르지만 이번 예시에서는 VPC 내부 IP인 경우에는 local로, 나머지는(0.0.0.0) 모두 IGW를 타게 구성되어 있다고 가정)그러면 52.219.146.23의 경우에는 당연히 VPC 내부 IP가 아니기 때문에 IGW를 타게 된다. 최종적으로 위 그림과 흐름으로 통신이 이루어지게 되는 것이다.

만약 VPC 내부에서 호출한 경우에는 IGW를 타지 않게 변경하고 싶다면 VPC Endpoint를 이용하면 된다. VPC Endpoint에는 두 가지 타입이 있는데, 하나는 Gateway이고 하나는 Interface이다. 사실 Gateway 타입은 서비스가 많이 제한되어 있지만(dynamodb, s3만 가능) S3는 두 타입을 모두 지원하기 때문에 S3를 예시로 하나씩 알아보도록 하겠다.

Gateway

Gateway 방식으로 VPC Endpoint를 만들었을때 구성도이다. 달라진 점이라고는 NAT, IGW가 VPC Endpoint로 변경된 것뿐이다. 그러면 EC2는 어떻게 알고 VPC Endpoint에 요청을 보내는 것일까?

VPC Endpoint를 직접 생성하면 그 비밀에 대해 알게 된다.

AWS 콘솔에서 - PrivateLink and Lattice - Endpoints- - Create endpoints를 선택한다.

Name Tag는 원하는 값으로 임의로 입력하고 Services에서 s3를 입력하면 com.amazonaws.ap-northeast-2.s3 라는 이름으로 Gateway, Interface 타입으로 구분되어 있는 것을 확인할 수 있다. 이 중 타입이 Gateway인 것을 선택한다.

그 뒤에는 생성할 VPC, 적용 대상 Route table을 선택한 후 생성을 완료한다. 생성이 완료되면 EC2 서버에 접속한 뒤 다시 nslookup을 시도한다.

nslookup 결과에는 변화가 없다. 구성도를 봐도 EC2에서는 여전히 Public DNS로 요청을 보내는 것을 확인할 수 있다. EC2는 결과로 반환된 IP 주소(3.5.184.140)를 가지고 Route Table을 조회할 것이다.

그런데 Route Table - Routes를 보면 이전에는 없었던 Destination은 Prefix List로 되어있고, Target은 VPC Endpoint인 새로운 Rule이 추가된 것을 확인할 수 있다.

Prefix list 내용을 살펴보면 S3에서 사용하는 공인 IP들이 들어가 있다. 즉, S3 공인 IP로 요청이 온 경우에는 Route Table에서 VPC Endpoint Gateway로 라우팅 되는 것이다. (NAT의 역할을 대신하는 것)

즉, 지금까지 확인한 VPC Endpoint Gateway의 동작 방식을 요약해보면

• EC2에서 S3 Endpoint로 DNS조회를 하면 여전히 AWS Public IP로 확인된다.
• 하지만 Route Tables의 규칙에 따라 해당 IP(= AWS Public IP)로 향하는 트래픽은 IGW가 아닌 VPC Endpoint를 통해 라우팅 된다.

⇒ DNS 설정을 변경하지 않고 라우팅 규칙만 변경해서 트래픽이 AWS 내트워크 내부에서 처리되도록 한다

Interface

Interface 방식으로 VPC Endpoint를 만들었을 때 구성도이다. 이번에 달라진 점은 Route 53이 기존에는 Public DNS를 조회했다면 이번에는 Private DNS를 조회하도록 변경된 것이다. 이번에도 VPC Endpoint를 생성하여 어떻게 변경되는 것인지 확인해 보자

이번에도 마찬가지로 AWS 콘솔에서 - PrivateLink and Lattice - Endpoints- - Create endpoints를 선택한다.

Name Tag는 원하는 값으로 임의로 입력하고 Services에서 s3를 입력한 뒤, 타입이 Interface인 것을 선택한다.

주의할 점은 [Enable DNS name]을 반드시 활성화해야 한다. 이 옵션을 활성화 해야 프라이빗 호스팅 영역을 VPC와 연결하여, DNS 이름으로 요청을 보낼 때 Private 하게 연결할 수 있는 레코드 세트를 포함하기 때문이다. 또한 [Enable private DNS only for inbound enpoint] 옵션을 활성화하게 되면 Gateway Endpoint를 반드시 만들어줘야 하기 때문에 체크 해제하고 생성한다.

Interface Endpoint는 Gateway보다 생성되는데 시간이 조금 더 걸린다. 상태가 Available이 되면 이번에도 nslookup을 해본다. 그런데 이번에는 nslookup 결과가 Gateway 방식이랑 다르게 내부 IP를 요청하는 것을 알 수 있다. 그렇다면 이 IP는 어디에 존재하는 IP일까?

정답은 Endpoint에서 만들어진 ENI의 IP이다. 서브넷을 선택하면 선택한 서브넷에 각각 IP가 할당된 것을 확인할 수 있다.

또한 VPCE의 Private DNS names을 보면, 어느 DNS에 대해 Private IP를 반환해 줄 건지에 대해 구성되어 있는 것을 확인할 수 있다. 즉, *.s3.ap-northeast-2.amazonaws.com, *. s3-control.ap-northeast-2.amazonaws.com, *. s3-accesspoint.ap-northeast-2.amazonaws.com에 대해서 Private DNS가 구성되어 있다는 것을 확인할 수 있다. (참고로 dualstack은 VPC Endpoint 적용이 안된다)

이번에도 지금까지 확인한 VPC Endpoint Interface의 동작 방식을 요약해 보면

• EC2에서 S3 Endpoint로 DNS조회를 하면 VPC 내부의 Endpoint ENI IP를 반환한다.
• Privatelink(AWS에서 구성한 비공개 네트워크)를 거쳐 S3로 라우팅 한다.

⇒ 지정된 Subnet 내에 ENI를 생성하고, Private DNS 설정을 Enable 할 경우 AWS 서비스 Public DNS 조회를 하면 ENI의 Private IP를 반환한다.

정리

한 줄로 정리하면 Gateway는 라우팅, Interface는 프락시 역할을 한다고 생각하면 된다. VPC 내에서 통신이 아니라 IDC 같은 환경에서의 통신인 경우에도 VPC Endpoint를 사용할 때는 Route53 Resolver를 사용하기도 하던데, 그 경우는 아니라 별도로 다루지는 않았다.