Today Keys : s3, endpoint, gateway, interface, private link, 엔드포인트, 프라이빗 링크, 보안, eni
이번 포스팅에서는 AWS S3 서비스 접근 시에, 공인망 구간을 경유하지 않고 AWS 내부망을 통해 보다 보안적으로 접근이 가능한 Endpoint에 사용 방법을 알아봅니다. S3의 Endpoint는 Gateway 방식과 Interface에 방식을 모두 지원하는 데 각 방식을 어떻게 사용 할 수 있는지 알아봅니다.
오늘 포스팅에서 다뤄질 AWS S3 Endpoint 사용 방법에 대해서 정리한 구성입니다.
S3는 기본적으로 공인 IP주소를 갖는 Public Service이기 때문에
가상 네트워크인 VPC 내부에서 S3로 접근하기 위해서는 IGW를 통해서 접근해야 합니다.
물론 NAT Gateway를 통해서 접근할 수도 있지만,
결국 NAT Gateway도 IGW를 통하기 때문에 IGW를 통해서 접근합니다.
실제 호출하는 VPC 내에 위치한 EC2가 S3 버킷에 대한 도메인 질의를 하면
공인 IP로 응답을 하고, IGW를 통해서 아래와 같이 접근 할 수 있습니다.
위의 구성에서 Public Subnet에 위치한 10.1.0.4가 이러한 경우입니다.
하지만 아래와 같이 인터넷에 대한 기본 경로(0.0.0.0/0)에 대해서
IGW나 NAT Gateway로 라우팅이 잡히지 않은 서브넷이 있다고 가정할 때,
이 Private Subnet에 있는 EC2에서 S3에 접근하려고 하면,
다음 그림과 같이 도메인 질의는 가능하지만,
S3에 접근하지 못하고 Timeout이 나는 것을 볼 수 있습니다.
위의 구성에서 Private Subnet에 위치한 10.1.1.149가 이러한 경우입니다.
이처럼 S3로 접근하기 위한 인터넷 경로가 포함되지 않은 서브넷은 물론,
IGW를 통해서 인터넷과 통신이 가능한 서브넷에서도
IGW를 통하지 않고 S3로 접근할 수 있도록 도와주는 것이 Endpoint 입니다.
Endpoint는 Routing 방식을 사용하는 Gateway Endpoint와
별도의 Proxy와 같은 역할을 하는 서비스 ENI를 통해 통신하는 Interface Endpoint(Private Link)가 있습니다.
대부분의 서비스는 Interface Endpoint인 Private Link를 지원하고
S3와 Dynamo DB만 Gateway Endpoint를 지원합니다.
S3는 유일하게도 이 두 가지 방식의 Endpoint를 모두 지원합니다.
그럼 S3의 두 가지 Endpoint를 각각 만들어서 어떻게 동작하는지 확인해보겠습니다.
먼저 Gateway Endpoint를 만들어 보겠습니다.
AWS Service로 Service category를 선택하고,
Services에서 S3로 검색한 이후에 Type이 Gateway이 Endpoint를 선택합니다.
그 이후에 S3로 가기 위한 라우팅을 별도로 적용할 서브넷을 선택합니다.
그렇게 Gateway Endpoint를 생성한 이후에
Gateway Endpoint가 적용될 Route Tables에 가서 경로를 확인해 보면,
아래와 같이 Target이 vpce-로 시작하는 Endpoint를 목적지로 하는 경로가 생성된 것을 볼 수 있습니다.
Gateway Endpoint가 적용되었으니,
아까 전에 S3로 접근이 실패한 Private Subnet에 위치한 10.1.1.149 EC2에서 다시 확인해봅니다.
여전히, S3 버킷에 대한 도메인 질의는 공인 IP 주소로 응답 받는 것을 볼 수 있습니다.
하지만, S3 접근은 Gateway Endpoint 적용 전에 발생한 Timeout 대신에 성공적으로 접근한 것을 볼 수 있습니다.
.
이처럼, S3의 Gateway Endpoint를 사용하면,
기존과 동일한 버킷의 도메인을 사용하면서도 IGW를 거치지 않고
AWS의 Private한 네트워크 경로를 통해서 S3에 접근 할 수 있게 됩니다.
또한, VPC 내에서도 원하는 서브넷을 지정하여 라우팅 테이블에 반영 할 수 있습니다.
※ 참고 : 다음 테스트를 위해서 S3 Gateway Endpoint를 삭제 하였습니다.
다음은 S3의 Interface Endpoint(Private Link)를 만들어 보겠습니다.
AWS Service로 Service category를 선택하고,
Services에서 S3로 검색한 이후에 Type이 Interface인 Endpoint를 선택합니다.
그 이후에 Interface Endpoint를 만들 VPC를 지정하고,
ENI가 만들어질 서브넷을 선택합니다.
본 예시에서는 서비스 동작만 테스트하는 것이기 때문에 서브넷을 1개만 선택했습니다.
이 때, 유의할 점은 다른 서비스의 Interface Endpoint와 달리
S3의 Interface Endpoint의 경우에는 Enable DNS name 속성을 지원하지 않기 때문에
Addidional settings에서 해당 속성을 해제해야 합니다.
이제 만들어진 S3의 Interface Endpoint(Private Link)를 확인합니다.
다시 Private Subnet에 위치한 10.1.1.149 EC2에서 S3 버킷에 대한 도메인 질의와 접속을 테스트 합니다.
다른 Interface Endpoint(Private Link)와 달리 서비스에 대한 도메인 질의를 해도
ENI의 IP 주소를 응답하지 않고, 원래의 공인 IP가 응답합니다.
이는 앞서 S3의 Interface Endpoint를 만들 때 얘기했던
S3d의 Interface Endpoint는 Enable DNS name 속성을 지원하지 않기 때문입니다.
따라서, 다른 서비스와 달리 기존과 동일한 S3 버킷 도메인으로 Interface Endpoint(Private Link)를 사용 할 수 없습니다.
그래서 Private Subnet의 10.1.1.149 EC2도 S3에 접근하지 못하고 time out이 나는 것을 볼 수 있습니다.
그럼 S3의 Interface Endpoint를 어떻게 사용할까요?
물론 Interface Endpoint 생성 시에 만들어진 ENI의 IP 주소로 접근 할 수 있습니다.
하지만, S3 Interface Endpoint에 대한 별도 도메인을 이용할 수도 있습니다.
아까 Interface Endpoint(Private Link) 생성 후, 나온 정보에서 확인해 보면
DNS names라는 항목이 있습니다.
이 도메인을 통해서 S3 Interface Endpoint를 사용 할 수 있습니다.
실제 해당 도메인에 대해서 질의해 보면,
아래와 같이 S3 Interface Endpoint 생성 시에 만들어진 ENI의 IP로 응답되는 것을 볼 수 있습니다.
이제 이 도메인 뒤에 bucket명을 Path로 추가하여
다시 S3에 접근을 시도하면 정상적으로 접근 되는 것을 볼 수 있습니다.
정리하면 다음과 같은 구성이 됩니다.
S3 Interface Endpoint(Private Link) 용도로 만들어진 도메인은
VPC 내부, 심지어 AWS 외부에서도 동일하게 도메인 질의가 가능합니다.
따라서, 해당 VPC와 Direct Connect와 같은 전용선이나 VPN을 통해서 접근 가능한
On-Premises에서도 S3 Interface Endpoint를 사용 할 수 있습니다.
외부 DNS에서도 바로 질의가 되기 때문에 Route53 Resolver과 같은 서비스를 추가로 사용하지 않아도 됩니다.
앞서 만들었던, S3 Gateway Endpoint와 Interface Endpoint(Private Link)를 적용한 구성도를 정리하면,
포스팅 제일 앞에 있던 구성도가 됩니다.
각각의 용도에 맞춰서 Gateway Endpoint와 Interface Endpoint를 적절하게 사용하면
Private한 네트워크 환경에서 보다 보안적으로 안정적인 S3 접근을 할 수 있습니다.
