VPC 엔드포인트는 VPC 내 Resource들이 VPC 외부의 서비스(S3, Dynamo DB, Cloudwatch) 등에 접근할 때 Internet Gateway, NAT Gateway 등의 외부 인터넷 전송 서비스를 타지 않고 내부 네트워크를 통해 접근할 수 있도록 지원하는 서비스이다.
AWS VPC는 사설 네트워크로 이루어진 사용자 정의 네트워크이다.
VPC 내 EC2, RDS, ELB 등을 탑재하고 ENI(Elastic Network Interface)에 사설 IP 혹은 공인 IP를 부여하여 사용한다.
그럼 다른 AWS 서비스 S3, Cloudwatch, Cloudfront, Dynamo DB, API Gateway ..등은 어떨까?
이들은 내가 설정한 AWS의 Region 내에 존재하지만, VPC 내부에 설치하는 서비스들이 아니다.
즉, 따로 공인 IP를 가지고 외부에서 접근하는 서비스들이다.
다음 상황을 가정해보자.
만일 VPC 내의 Private Subnet에 위치한 EC2 인스턴스에서 S3에 대한 api를 부르게 되면 어떻게 될까?
이는 S3에 접속해서 S3의 정보를 얻어와야 되기 때문에 당연히 외부에서의 접근이 필요하게 된다.
따라서 만일 전시간에서 배운 Bastion Host와 NAT 게이트웨이를 설정한 VPC 구성일 경우,
EC2(10.0.3.20, Private Subnet) → NAT Gateway → Router → Internet Gateway → 외부 인터넷 → S3
이런식으로 이동하게 된다.
보기엔 통신에 전혀 문제없어 보이지만, 이는 결국 VPC 내부 Resource와 기타 AWS Service Endpoint(EC2 API 호출, S3 접속 등)와 통신 시 외부 인터넷에 공개적으로 연결되며 트래픽이 노출됨을 의미하게 된다.
만일 내부적으로 은밀하게 처리해야 될 api 호출이라면 보안상으로 썩 좋지 않은 방법인 셈이다.
거기다 VPC 밖에서 들어오는 트래픽에는 과금이 되기 때문에 비용이 늘어난다.
따라서 이를 해결하기 위한 것이 VPC Endpoint인 것이다.
앞서 말했듯이 S3는 외부에서 접근해야 하는 서비스지만,
만일 내부 사용자(관리자)가 사용하는 형태라면, 보안을 위해 외부로 나가지 말고 내부 네트워크로 접근해서 사용하자는 취지인 것이다.
위의 그림을 보면 AWS CLOUD 내에 VPC Endpoint가 있고 바로 S3로 연결되어있다.
말 그대로 VPC 내부에 Endpoint를 형성한 뒤, 이 Enpdoint를 통해 AWS 외부 서비스에 도달할 수 있도록 하는 서비스 인 것이다.
정리하자면, VPC Endpoint는 AWS 여러 서비스들과 VPC를 연결시켜주는 중간 매개체로서, AWS에서 VPC 바깥으로 트래픽이 나가지않고 AWS의 여러 서비스들을 사용할수있게 만들어주는 서비스라 할 수있다.
VPC 엔드포인트는 Interface Endpoint와 라우팅 테이블 기반의 Gateway Endpoint 두가지 종류로 나뉜다.
이 2개 유형의 다른점은 Access 방식이 부분이다.
"Interface Endpoint"가 ENI(Elastic Network Interface)를 이용하여 IP가 할당되고 해당 IP로 Access를 하는 방식이라면, "Gateway Endpoint"는 Route Table을 이용하여 Endpoint에 Access한다는 것이 다른 점이다.
AWS 서비스마다 사용할 수 있는 VPC Endpoint 유형이 정해져 있으므로 확인 후 선택해야 한다.
앞서 소개했던 것처럼 각 서브넷마다 Elastic network interface(ENI)를 생성하여 외부 서비스에 접근하기 위한 VPC 엔드포인트가 바로 인터페이스 엔드포인트(Interface endpoint) 이다.
외부 인터넷을 사용하지 않고 해당 ENI를 통해 외부 서비스로 접근이 가능하게 된다.
위의 그림에서 private EC2에서 나온 트래픽을 사설IP로 통신을 해서 외부 서비스(SQS)와 연결되는 것을 볼수 있다.
Gateway endpoint는 Gateway endpoint를 생성한 후, Subnet에서 Routing만을 추가로 생성한다.
자동으로 생성되므로 변경할 수 없다.
따라서 해당 Routing table 경로를 보고 VPC Endpoint를 통해 S3에 접근 가능하는 형태이다.
VPC 엔드포인트를 구축하기 위해선 기본적으로 Public / Private 서브넷 인프라가 설계 되어있어야 한다.
S3를 이용하기에 앞서 먼저 EC2에서 S3로 접근하는 역할(Role)을 먼저 IAM에서 설정해주어야 한다.
EC2 인스턴스 전용 IAM 역할은 EC2 인스턴스를 생성할 때 설정해줘야 한다.
이미 만들어진 EC2 인스턴스에는 IAM 역할을 설정할 수 없다.
EC2 인스턴스 메뉴에 가서 인스턴스 생성을 하고 AMI와 인스턴스 타입을 설정해준다.
인스턴스 세부 정보 구성 메뉴에 오면 중앙 하단에 IAM 역할을 정할수 있는 항목이 보일 것이다.
IAM role을 설정해주고 인스턴스를 생성해주게 되면, 이제 생성한 이 EC2 인스턴스는 S3에 엑세스 할수있는 권한을 가진 역할(Role)을 얻은 상태가 된다.
만일 미리 만들어둔 private 인스턴스가 있다면, 또 새로 만들지 않고 기존 인스턴스에 IAM 역할을 부여할수도 있다.
S3는 구글드라이브 같이 온라인에 파일을 저장하는 서비스 이고, 버킷은 일종의 파일들을 담아 저장하는 폴더 개념이라고 이해하면 된다.
아직 S3에 대해서 잘 모르는 독자분들도 있으시겠지만, 만드는데 전혀 어렵지 않으니 우선 따라와보자.
게이트웨이 엔드포인트 생성이 완료되었다.
게이트웨이 엔드포인트는 라우팅 테이블을 이용해서 내부 서비스 통신을 한다고 위에서 언급했었다.
실제로 VPC Private 서브넷 라우팅 테이블에 가서 확인해보자.
이와 같이 Gateway Endpoint를 생성하면 Endpoint id(vpce-06bf2f80002a51ba4) 를 부여 받게 된다.
그리고 Route table의 Destination(대상)에는 prefix list id(pl-78a54011)가 등록이 되어 있고 Target에는 내가 방금 생성한 Endpoint의 id(vpce-06bf2f80002a51ba4)가 등록되어 있다.
즉, VPC Gateway Endpoint를 생성하면 자동으로 Route Table에 등록을 해주기 때문에 추가로 작업해 줄 필요는 없다.
❓ prefix list id(pl-78a54011)는 무엇인가
prefix list id는 하나 이상의 CIDR 그룹이라고 생각하면 된다.
위에서 S3를 생성했으므로 해당 prefix list id에는 S3가 사용하는 CIDR 블록들이 정의되어 있다.
그래야 S3로 가고자 하는 트래픽이 Route table에서 prefix list(pl-78a54011)에 포함된 IP인지 검사를 받게 되는데, prefix list에 포함되므로 인터넷이 아닌 VPC Gateway Endpoint(vpce-06bf2f80002a51ba4)로 보내주어 Private한 통신이 가능하게 되는것이다
prefix list는 아래 화면에서 확인이 가능하다.
prefix list id를 보면 Prefix list entries에 S3가 사용하는 CIDR가 포함되어 있는 것을 볼 수 있다.