[AWS] VPC Endpoint (Gateway Endpoint, Interface Endpoint 및 S3 연결)

VPC Endpoint란

VPC Endpoint는 VPC와 AWS 서비스 사이의 통신을 비공개로 연결할 수 있도록 해주는 서비스며 Pubilc IP 주소를 필요로 하지 않게 한다. VPC와 기타 서비스 간의 트래픽은 AWS 네트워크를 벗어나지 않는다. 리소스 통신간 외부 유출을 꺼려할 때 사용하는 서비스로 보인다.

 

 

VPC Endpoint가 왜 필요할까

예를 들면 보자. VPC Endpoint가 없다면 EC2 인스턴스에서 S3로 액세스 할 때, EC2는 NAT와 Internet Gateway를 통해 외부로 나가 S3에 접속한다. (EC2와 S3 둘 다 AWS 서비스라고 둘이 내부 통신한다고 생각하면 안 된다) EC2, RDS 등의 서비스는 ENI를 탑재하고 이 ENI에 Public 혹은 Private IP를 부여으며 VPC안에 존재한다.

 

그렇다면 S3는 어떨까? AWS Region 안에 위치하는 건 맞지만 VPC 내부에 위치하지 않고 공인 IP를 통해 외부에서 접근하는 방식이다. 즉, S3 등의 서비스를 이용하기 위해서는 외부 인터넷을 이용해야 한다. 그래서 중요 정보가 외부 인터넷을 타는 것을 꺼린다면 VPC Endpoint를 고려해볼 수 있다.

직접 확인해 보자. 미리 생성해 둔 EC2와 S3가 있어 다음과 같이 테스트해봤다. S3의 URL 주소를 nslookup 해보니 공인 IP 주소 '52.21x.xx.xx'를 반환했다. 이로서 S3가 공인 IP를 갖고 있다는 게 증명됐다. 이는 개인의 로컬 디바이스를 이용하건 VPC내에 위치해 있는 EC2에 실행하건 결과는 똑같다.

정리하자면 기본 구성 시, EC2가 S3에 접근할 때 이동하는 경로는 다음과 같다. 결국 외부 인터넷망을 통해 접근을 하는 것이고 트래픽이 외부에 노출된다는 것을 의미한다. 보안이 중요하다면 대책이 필요한 거다. 여기서 VPC Ednpoint가 나온다. 그리고 VPC Endpint에는 두 가지가 있다.

 

VPC Endpiont 없이 EC2에서 S3로의 접근 경로:

EC2 Instance (10.0.0.154) -> NAT Gateway (Private EC2라면) -> Internet Gateway -> 외부망 -> S3 

 

S3 URL 주소:
https://<your-bucket-name>.s3.<your-region>.amazonaws.com

 

 

VPC Ednpoint 종류

1. Interface Endpoint (ENI 기반)

      - Private IP 주소를 생성해 서비스를 연결시켜준다.

      - ENI (Eliastic Network Interface)는 랜카드라고 생각하면 된다.

      - SQS, SNS 등 여러 서비스를 지원

Private Subnet에 위치하고 있는 EC2가 Interface Endpoint를 이용해 S3로 접근할 때의 통신 경로다. EC2가 S3 관련 API를 호출했다. Interface Endpoint는 Private Subnet 안에 위치하고 있다. EC2는 Private IP로 S3로 바로 통신한다.

 

2. Gateway Endpoint 기반

      - S3 및 DyanmoDb 등을 지원

Private Subnet에 위치하고 있는 EC2가 Gateway Endpoint를 이용해 S3로 접근할 때의 통신 경로다. Gateway Endpoint는 Private Subnet 밖에 위치하고 있다. EC2가 S3 관련 API를 호출했다. EC2는 Subnet 밖으로 나와 NACL을 거쳐 Route Table은 호출을 인터셉트하고 Router가 EC2를 Gateway Endpoint를 통해 S3로 이어주고 있다.

 

3. 각 Endpoint의 차이 및 Limitation

이 둘의 차이점 및 특징을 찾을 수 있는 대로 나열해 보았다. 조금 정리는 안됐지만 대충 이런 특징이 있다고 보자.

Interface Endpint	Gateway Endpoint
- 네트워크 트래픽은 AWS 네트워크에 남음 (공통)	- 네트워크 트래픽은 AWS 네트워크에 남음 (공통)
- Subnet에 위치하며 가용성을 보장하려면 각각의 AZ에 하나씩 배치해야한다. Region별 AZ당 하나의 Subnet만 선택가능.	- Subnet이 아닌 VPC에 위치한다
- Private IP주소를 사용해 S3에 액세스	- S3 Public IP 주소 사용
- On-premise 액세스 허용	- On-premise 액세스 허용하지 않음
- 다른 Region에서의 액세스 허용	- 다른 Region에서의 액세스 허용하지 않음
- VPC 외부로 연결할 수 있다 (VPC Connection, VPC Peering Connection, DX Connection 을 사용할 수 있다는 소리)	- VPC 외부로 연결할 수 없다 (VPC Connection, VPC Peering Connection, DX Connection은 불가하다는 소리)
- 대부분의 서비스를 지원한다. (S3와 DynamoDB 제외... 였었는데 이제 지원한다고 한다)	- S3와 DynamoDB를 지원한다.
- 라우트 테이블을 사용하지 않는다.	- 라우트 테이블과 연동하면 자동으로 서비스 및 대상 엔드포인트의 Prefix list를 자동으로 업데이트 한다.
- ENI를 사용하며 보안그룹과 연결된다.	- IAM 정책 또는 리소스 정책을 사용하여 액세스를 제한할 수 있다.
- AZ 및 Region을 포함해 고유의 DNS name이 있으며 Route53을 이용해 Private IP주소를 반환할 수 있다.

사실 Interface Endpoin의 경우 S3를 지원하지 않았지만 이제 지원한다고 한다. 그간 Gateway Endpoint만 사용할 수 있었고 endpoint 값 변경 없이 애플리케이션이 바로 적용할 수 있다는 장점이 있었지만 IP 주소가 제공되지 않는다는 단점이 있었다. 이게 왜 단점일까?

 

AWS 클라우드만 사용하는 곳이라면 문제가 없겠지만 IDC와 연동이 필요한 곳이라면 프록시를 써야 하는 문제가 발생한다. 하지만 Interface Gateway의 경우 생성된 S3 Endpiont 값을 어플리케이션에 수정만 하면 설령 그곳이 IDC 센터에 있어도 생성된 ENI에 전용 사설 IP로 트래픽이 향하도록 맵핑된다. 

 

이 글을 쓰게 된 계기도 여러 AWS계정을 운영하는 곳에서 IDC 센터까지 추가해 통신환경을 구축하려고 하는데 IP 대역이 겹쳐 TGW로는 해결이 되지 않는 상황이 발생해 정리하게 되었다.

 

 

Gateway Ednpoint 실습

글이 길어졌다. 각설하고 Gateway Endpoint 실습 먼저 들어가자. 실습을 위한 EC2, S3, 그리고 S3 접근을 위한 Role은 사전에 이미 생성이 되었다는 전자하에 진행하겠다.

 

1. VPC 서비스 콘솔 화면에서 Endpoint를 클릭한다. (Endpoint Service가 아니다) Service에 다음 Gateway Type의 S3를 서비스를 선택한다. 

2. VPC를 선택하고 S3와 연결할 EC2가 속해있는 Route Table을 선택한다. 향후 이 Route Table에 필요 정보가 담겨 EC2가 Gateway Endpoint를 타고 S3를 향하도록 할 것이다.

3. Gateway Endpoint 생성 완료했다.

5. 아까 Gateway Endpoint 생성할 때 넣었던 Route Table에 다음과 같이 추가 Rule이 생성되었다. 이 Rule은 변경되거나 삭제할 수 없다. 이것을 통해 EC2는 S3와 내부 통신을 할 것이다.

6. Gateway Endpoint 생성하기 전 후를 비교해 보았다.

S3의 Public IP 주소는 52.21x.xx.xx로 확인됐다. Gateway Endpoint 설정 전에는 S3로 향할 때 10.0.0.154를 통해 나가고 외부 인터넷을 통해 S3 도달했다. 그렇다면 Gateway Endpoint를 타고 가면 어떨까.

Gateway Endpoint 생성 전

아무것도 보이지 않는다. 일단 NAT나 IGW를 타고 나가는 것은 보이지 않는다. 이유는 모르겠지만 아무것도 출력되지 않는다. 혹시 S3 아예 접근이 안 되는 것일까.

Gateway Endpoint 생성 후

그건 아닌듯하다. S3 Bucket List는 잘 불러오는 듯하다. 물론 이 방법은 외부 인터넷 접속을 아예 차단하고 테스팅해본 것이다. AWS 백본 네트워크는 경로를 출력하지 않는 듯하다.

 

 

Interface Ednpoint 실습

1. 생성하는 것은 아까 전 실습과 비슷하다. 똑같이 Endpoint 생성하는 경로로 접근해 이번에 Service는 'Interface Type'을 고르자. 이번 포스팅은 멀티 리전 실습이 아니니 global을 선택할 필요 없다.

2. VPC를 생성하고 S3와 통신할 EC2 인스턴스가 위치하고 있는 Subnet을 골라주자. 아까 위에도 설명했지만 가용성을 위해 Interface Endpoint는 Region별 AZ당 하나씩 고를 수 있다고 했다.

3. 실험할 EC2 인스턴스와 동일한 서브넷에 엔드포인트 네트워크를 선택했으면 이것에 대한 적절한 보안 그룹을 선택하여 액세스 권한을 만들어주자. 일반적으로 AWS 서비스는 Endpoint 요청을 자동으로 수락한다. 필자는 일단 default로 선택했다. 그리고 생성한다.

만약 여기서 위와 같은 에러가 발생했다면 두 가지를 확인해보자. 해당 VPC의 DNS Hostname 설정을 활성화했는가? Endpoint 생성 화면의 VPC 선택지의 'Additional settings'에서 Enable DNS name 체크가 비활성화되어 있는가? S3는 Private DNS Name을 지원하지 않기 때문이다.

4. Interface Endpoint 생성 완료했다. DNS이름을 자세히 읽어보면 Zone을 위해 한 개가 있고 각각의 AZ를 위해 한 개씩 하여 총 3개가 생성된 것을 알 수 있다. 그리고 'Private DNS names enabled'가 "No"로 되어 있는 것을 볼 수 있는데 이는 VPC Endpoint의 Private DNS name 기능을 비활성화하겠다는 의미다.

 

이것을 활성화하면 애플리케이션에서 API를 호출할 때 Interface Endpoint를 이용하기 위해 DNS 설정 변경할 필요 없이 Public Endpoint를 그대로 이용하여도 Interface Endpoint를 이상 없이 이용할 수 있다는 장점이 있다. 하지만 S3 Interface Endpoint는 다른 Interface Endpoint와 다르게 Private DNS name을 지원하지 않는다. 

Interface Endpoint를 S3에 이용하기 위해서는 S3 API 호출 시, Endpoint URL을 추가로 지정해서 호출해야 하는데 방법은 다음과 같다. 

 

 

Interface Endpoint로 S3 접근하기:

 aws s3 --endpoint-url https://bucket. <your_vpce_dns_name> ls s3://<your_bucket_name>

 

테스트 결과 버킷 안에 있는 객체가 출력되었음을 알 수 있다. 이로서 Interface Endpoint가 정상작동 중임을 확인했다. 혹은 "nslookup bucket. <vpce_dns_name>" 명령어로 VPC Endpoint의 Private IP 주소를 알아낸 뒤 Public Endpoint의 질의응답에 반응하게 Host 파일에 등록하는 방법도 있다. 그게 아니면 콘솔 환경에서 Interface Endpoint의 'Subnet' 탭에 들어가 'Network InterfaceID' 부분에 ENI를 직접 확인하는 방법도 있다.