[따라하기] Amazon S3 를 위한 AWS PrivateLink (게이트웨이 엔드포인트)


Amazon S3 (https://aws.amazon.com/s3/) 는 AWS 의 VPC 외부에 위치해 있는 일종의 퍼블릭 서비스 입니다. 따라서 VPC 내부에 있는 리소스, 또는 온프레미스에 있는 리소스가 AWS 에서 제공하는 연결 서비스 (예> Direct Connect, Site-to-Site VPN) 를 통해 S3 에 접근하고자 하는 경우, 결국 퍼블릭 인터넷 환경을 통해 연결되어야 하거나 사설 네트워크 연결을 위해서는 매우 복잡한 아키텍처를 필요로 하게 되었습니다.

그러나 Amazon S3 에서도 AWS PrivateLink 지원을 시작하면서 VPC 또는 온프레미스의 리소스로 부터 S3 를 접근하고자 할 때, 퍼블릭 인터넷 환경을 거치지 않고 AWS PrivateLink 서비스 중 하나인 게이트웨이 엔드포인트 를 이용하여 사설 네트워크 연결 구성이 가능해 졌습니다.

이에 구체적으로 기존 환경은 어떠했는지, 그리고 지원하는 새로운 기능을 통해 어떻게 변경 되었는지 알아 보겠습니다.

(** 참고 : 2022년 1월 현재 Amazon S3 의 AWS PrivateLink 는 AWS GovCloud (미국) 리전, Sinnet 에서 운영하는 AWS 중국 (베이징) 리전, NWCD에서 운영하는 AWS 중국(닝샤) 리전을 포함한 모든 AWS 리전에서 제공되고 있습니다.)


| ‘1. 기존 환경’ (Public Subnet 으로부터 S3 접속) 과 ‘2. AWS PrivateLink – VPC Endpoint (Private Subnet 으로부터 S3 접속) 환경’ 의 비교




1. 기존 환경

AWS 자체적으로는 S3 를 사설 네트워크로 연결할 수 있는 기능을 제공하지 않아 기본적으로 사용자는 외부 인터넷 환경을 통해서만 S3 의 접근이 가능했습니다. 그러나 보안 연결이 필요하다는 요구에 의해, 자체 프록시 서버를 구성하는 등의 방법으로 이를 해결할 수 있는 방법이 있었습니다. 다만, 프록시 서버의 경우, 해당 서버의 성능의 제한을 고려해야 하고 추가 장애 지점이 생기며 운영 복잡성도 커질 수 있는 단점이 있었습니다.


2. AWS PrivateLink (VPC Endpoint) 환경

온프레미스 또는 VPC 내 리소스로부터 S3 까지 사설 네트워크를 통한 접근이 필요할 때, AWS PrivateLink 를 이용하여 기존 환경과 비교해서 더 간소화된 연결 구성이 가능 해졌습니다. 특히 기존 환경에서 설명한 것 처럼 사설 네트워크를 위한 별도의 접근 포인트 (예> 프록시 서버) 를 직접 구성하고 관리 해야 할 필요가 없어졌으며, 그에 따라 발생할 수 있는 장애 포인트가 감소하게 되었고 운영 복잡도에 대한 관리자의 추가 노력이 들어갈 필요가 없어지게 되었습니다. 아울러 외부 인터넷을 통해 접근하지 않고 AWS 내부 네트워크를 이용하기 때문에 보안 연결이 가능함과 동시에 비교적 더 많은 비용을 절약할 수도 있게 되었습니다.

** AWS PrivateLink 를 사용하기 위한 VPC Endpoint (AWS 의 퍼블릭 서비스에 대한 사설 네트워크 연결) 의 종류는 크게 게이트웨이 엔드포인트, 인터페이스 엔드포인트, 그리고 엔드포인트 서비스가 있으며 다음과 같은 예시로 구분할 수 있습니다. (엔드포인트 서비스는 사용자의 리소스 측에 연결하는 포인트를 별도로 생성해주는 개념)

[VPC1 : EC2 인스턴스 <-> 게이트웨이 엔드포인트 <-]----> S3 또는 Dynamo DB
[VPC1 : EC2 인스턴스 <-> 인터페이스 엔드포인트 <-]----> S3, Dynamo DB 외 나머지 일부 AWS 서비스
[VPC1 : EC2 인스턴스 <-> 인터페이스 엔드포인트 <-]---[-> 엔드포인트 서비스 <-> EC2 인스턴스, ELB 등 : VPC2]



3. S3 <-> AWS PrivateLink 따라하기

(1) 다음과 같은 사전 준비를 합니다.
– S3 에서 새 버킷을 하나 생성합니다. (** 생성 후, 버킷 내 Permissions 탭에서 Policy 란에 사용하는 계정이 해당 버킷을 접근할 수 있도록 접근 정책을 작성합니다. 정책은 AWS Policy Generator (https://awspolicygen.s3.amazonaws.com/policygen.html) 를 통해서도 쉽게 만들 수 있습니다.)
– VPC 그리고 VPC 내부에 퍼블릭/프라이빗 서브넷들을 생성하고 퍼블릭 서브넷에서는 인터넷 통신이 가능하도록 인터넷 게이트웨이 (IGW) 및 필요한 라우팅을 설정합니다.
– VPC 의 퍼블릿/프라이빗 서브넷에 각각 S3 를 접속하기 위한 퍼블릭/프라이빗 인스턴스들을 1개씩 생성합니다. (** KeyPair 생성 후 Security Group 에서 SSH 접속을 위한 22번 포트의 허용 처리를 해줍니다. 또한, 퍼블릭 서브넷에 위치한 인스턴스에 프라이빗 서브넷에 위치한 인스턴스를 접속하기 위한 KeyPair 도 복사해 둡니다. (예> MacOS 로 부터 인스턴스에 KeyPair 를 복사하는 방법은 본 블로그의 ‘scp 사용 방법‘ 을 참고 하세요.))
(2) SSH 로 퍼블릭 서브넷에 위치한 인스턴스에 접속합니다.

$ ssh -i "MyKeyPair.pem" ec2-user@ec2-3-00-000-000.ap-northeast-2.compute.amazonaws.com

(3) 접속 후 S3 의 특정 Bucket 내부에 있는 객체 리스트를 불러오면 정상적으로 확인이 됩니다.

[ec2-user@ip-10-0-1-123 ~]$ aws s3 ls s3://test-seoulregion
2022-01-03 11:36:09     478809 TestImage1.png

(4) SSH 로 퍼블릭 인스턴스 (Bastion 호스트) 에서 프라이빗 인스턴스에 접속합니다.

$ ssh -i "MyKeyPair.pem" ec2-user@10.0.2.234

(5) 접속 후 S3 의 특정 Bucket 내부에 있는 객체 리스트를 불러오면 시간이 지나도 정상적으로 확인 되지 않습니다.

[ec2-user@ip-10-0-2-234 ~]$ aws s3 ls s3://test-seoulregion

(6) VPC 콘솔 -> Endpoint 로 이동 후 Create Endpoint 를 클릭합니다.

(7) Endpoint 생성 조건을 다음과 같이 설정하고, 설정이 완료되면 맨 아래의 ‘Create Endpoint’ 버튼을 누릅니다.
– Service Category : AWS services
– Service Name : S3 검색 후 ‘Gateway’ 타입 선택
– VPC : 프라이빗 인스턴스가 위치한 VPC 로 선택
– Configure route tables : 프라이빗 인스턴스가 위치한 Subnet 을 선택
– Policy : Full Access 로 선택

(8) 프라이빗 인스턴스에서 다시 S3 의 특정 Bucket 내부에 있는 객체 리스트를 불러오면 정상적으로 확인이 됩니다.

[ec2-user@ip-10-0-2-234 ~]$ aws s3 ls s3://test-seoulregion
2022-01-03 11:36:09     478809 TestImage1.png



4. (참고) 퍼블릭 환경과 프라이빗 환경에서의 S3 접근 과정 비교

한편, S3 Bucket 을 접근할 때 퍼블릭 인스턴스에서 퍼블릭 인터넷 환경을 통한 접근과 Endpoint 를 이용하여 AWS 내부 프라이빗을 통한 접근 과정의 비교를 Traceroute 로 살펴보면 다음과 같습니다.

(1) 퍼블릭 인스턴스와 프라이빗 인스턴스에서 각각 nslookup 을 통해 S3 퍼블릭 주소를 확인해 봅니다. (S3 가 사용하는 퍼블릭 IP 주소 대역대 중 각각의 반환된 주소를 통해 접근이 가능함을 확인)

[ec2-user@ip-10-0-1-123 ~]$ nslookup s3.ap-northeast-2.amazonaws.com
Server:		10.0.0.2
Address:	10.0.0.2#53

Non-authoritative answer:
Name:	s3.ap-northeast-2.amazonaws.com
Address: 52.219.56.25
[ec2-user@ip-10-0-2-234 ~]$ nslookup s3.ap-northeast-2.amazonaws.com
Server:		10.0.0.2
Address:	10.0.0.2#53

Non-authoritative answer:
Name:	s3.ap-northeast-2.amazonaws.com
Address: 3.5.143.161

(2) 퍼블릭 인스턴스에서 Traceroute 결과 값 확인

[ec2-user@ip-10-0-1-123 ~]$ traceroute 52.219.56.25
traceroute to 52.219.56.25 (52.219.56.25), 30 hops max, 60 byte packets
 1  ec2-52-79-0-145.ap-northeast-2.compute.amazonaws.com (52.79.0.145)  0.805 ms ec2-52-79-0-149.ap-northeast-2.compute.amazonaws.com (52.79.0.149)  3.139 ms ec2-52-79-0-139.ap-northeast-2.compute.amazonaws.com (52.79.0.139)  3.532 ms
 2  100.65.19.160 (100.65.19.160)  2.173 ms 100.65.19.0 (100.65.19.0)  1.294 ms 100.65.18.160 (100.65.18.160)  3.221 ms
 3  100.66.8.222 (100.66.8.222)  8.330 ms 100.66.8.248 (100.66.8.248)  7.939 ms 100.66.8.226 (100.66.8.226)  4.550 ms
 4  100.66.11.100 (100.66.11.100)  1.713 ms 100.66.11.224 (100.66.11.224)  5.551 ms 100.66.11.0 (100.66.11.0)  3.479 ms
 5  100.66.2.161 (100.66.2.161)  11.453 ms 100.66.2.7 (100.66.2.7)  19.584 ms 100.66.2.163 (100.66.2.163)  11.409 ms
 6  100.64.2.213 (100.64.2.213)  16.667 ms 100.64.0.145 (100.64.0.145)  20.267 ms 100.64.2.17 (100.64.2.17)  20.235 ms
 7  100.64.21.205 (100.64.21.205)  21.504 ms 100.64.20.77 (100.64.20.77)  21.492 ms 100.64.21.77 (100.64.21.77)  19.659 ms
 8  s3.ap-northeast-2.amazonaws.com (52.219.56.25)  0.232 ms  0.246 ms  0.266 ms

(3) 프라이빗 인스턴스에서 Traceroute 결과 값 확인(경로가 비공개 처리됨)

[ec2-user@ip-10-0-2-234 ~]$ traceroute 3.5.143.161
traceroute to 3.5.143.161 (3.5.143.161), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

따라서, Endpoint 를 이용할 경우에도 같은 퍼블릭 주소를 가지고 S3 를 접근하지만 퍼블릭 환경에서의 접근 경로와는 다른 내부 경로를 사용한다는 것을 추측할 수 있습니다.

한편, 다음과 같이 Endpoint 를 생성하고 나서 설정한 대상 서브넷의 라우팅 테이블에 Endpoint 를 위한 S3 접근용 라우팅 경로가 자동으로 추가 된 것을 확인 할 수 있습니다. 이 라우팅 테이블에 추가되는 해당 목적지는 S3 에 대한 Managed prefix list 로 참조될 수 있음을 아래의 Prefix list entries 에서 확인이 가능합니다.



(** 참고 : 문제 해결 (위와 같은 설정을 하고 나서도 접속이 되지 않을 경우))
– 인스턴스 각각에 S3 버킷의 접근을 허용 하는 IAM 권한이 설정되어 있는지 확인 합니다.
– S3 버킷에 접근 권한이 설정되어 있는지 확인 합니다.



– 참고자료
· Amazon S3용 AWS PrivateLink 정식 출시 – https://aws.amazon.com/ko/blogs/korea/aws-privatelink-for-amazon-s3-now-available/
· Amazon S3에서 AWS PrivateLink 지원 시작 – https://aws.amazon.com/ko/about-aws/whats-new/2021/02/amazon-s3-now-supports-aws-privatelink/
· AWS PrivateLink 및 VPC 엔드포인트 – https://docs.aws.amazon.com/ko_kr/vpc/latest/privatelink/endpoint-services-overview.html
· 게이트웨이 VPC 엔드포인트 – https://docs.aws.amazon.com/ko_kr/vpc/latest/privatelink/vpce-gateway.html
· 인증을 사용하지 않고 Amazon VPC에서 Amazon S3 버킷으로 비공개로 연결하려면 어떻게 해야 합니까? – https://aws.amazon.com/ko/premiumsupport/knowledge-center/s3-private-connection-no-authentication/







#Steven

답글 남기기