온프레미스 클라이언트에는 S3 게이트웨이와 인터페이스 엔드포인트 중 무엇인가

사무실 네트워크에서 사이트 VPN을 통해 S3에 도달하는 일은 정적 라우트만으로 해결되는 라우팅 문제가 아닙니다. 게이트웨이 엔드포인트는 라우트 테이블에 연결되어 VPC 내부에서 발생한 요청을 처리합니다. 인터페이스 엔드포인트는 서브넷에 프라이빗 주소를 가진 탄력적 네트워크 인터페이스를 배치하며, 그 주소는 VPN이나 Direct Connect를 통해 온프레미스에서 도달할 수 있습니다. 요청이 어디서 시작되는지가 실제로 둘 중 무엇이 필요한지를 결정하며, DNS, 보안 그룹, 정책 작업은 그 답에서 따라옵니다.

요청이 시작되는 위치로 엔드포인트 유형을 구분합니다

게이트웨이 엔드포인트는 관리형 프리픽스 목록을 가리키는 라우트 테이블 항목으로 나타납니다. 네트워크 인터페이스도, 보안 그룹도, 자체 프라이빗 주소도 없으며, 반대편에 라우팅할 대상이 없기 때문에 온프레미스 호스트는 그쪽으로 라우팅할 수 없습니다. VPC 내부의 트래픽이 S3에 도달하는 것은 서브넷 라우트 테이블이 그 프리픽스를 엔드포인트로 보내기 때문입니다. 다른 곳에서 오는 트래픽에는 따라갈 그런 항목이 없습니다.

인터페이스 엔드포인트는 선택한 서브넷에 있는 네트워크 인터페이스의 집합이며, 각각 해당 서브넷의 프라이빗 주소와 연결된 보안 그룹을 가집니다. 터널이 패킷을 실어 나를 수 있는 평범한 목적지이기 때문에 하이브리드 클라이언트가 사용할 수 있는 형태가 이것입니다. 동시에 엔드포인트가 서브넷의 주소를 소비하며 그 주소가 고갈될 수 있다는 뜻이기도 합니다.

aws ec2 describe-vpc-endpoints --query "VpcEndpoints[].{Id:VpcEndpointId,Type:VpcEndpointType,Service:ServiceName,State:State}" --output table

이름이 아니라 Type 열을 읽습니다. 단일 VPC가 같은 서비스에 두 유형을 함께 두는 경우가 흔하며, 온프레미스 애플리케이션에 필요한 항목은 인터페이스 항목입니다.

S3를 테스트하기 전에 인터페이스 주소까지의 경로를 만듭니다

동시에 성립해야 하는 것은 온프레미스 라우터의 엔드포인트 서브넷으로 가는 라우트, 그 서브넷에서 돌아오는 경로가 클라이언트 네트워크에 도달한다는 것, 그리고 엔드포인트 보안 그룹이 클라이언트 소스 범위를 허용한다는 것입니다. 세 가지가 모두 통과한 뒤에도 서브넷의 네트워크 ACL이 패킷을 버릴 수 있으므로, 나중에 떠올릴 생각이 아니라 네 번째 항목으로 확인합니다.

VPC 안의 어느 EC2 인스턴스로 통하는 경로는 이 중 어느 것도 증명하지 않습니다. 터널이 올라와 있다는 것만 보여 주며, 그것은 이미 알고 있던 경로의 한 부분입니다. 엔드포인트 주소를 따로 증명하고, 그다음 이름이 그 주소로 확인되는지 증명합니다.

ip route get 10.60.4.37
nc -vz 10.60.4.37 443
openssl s_client -connect 10.60.4.37:443 -servername bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com </dev/null

첫 번째 명령은 클라이언트가 어떤 인터페이스를 쓸지 보여 줍니다. 두 번째는 TCP 핸드셰이크를 증명합니다. 세 번째는 엔드포인트 이름에 유효한 인증서로 TLS가 완료됨을 증명하며, 권한을 탓하기 전에 잘못된 주소를 잡아내는 검사가 바로 이것입니다.

애플리케이션이 어떤 DNS 응답을 받는지 정합니다

VPC에 인터페이스 엔드포인트가 있다고 해서 온프레미스 SDK가 저절로 리디렉션되지는 않습니다. 클라이언트는 AWS가 해당 엔드포인트에 공개하는 엔드포인트 전용 이름을 쓰거나, 사무실에서 확인되도록 의도적으로 만든 프라이빗 호스팅 영역을 씁니다.

하이브리드 확인을 위해 온프레미스 리졸버는 VPC의 DNS 뷰로 들어가는 지원되는 경로가 필요하며, 보통 Resolver 인바운드 엔드포인트를 통해 마련합니다. 어떤 쿼리 소스에 영향을 주는지 이해하지 않고 프라이빗 DNS를 켜면, 사무실이 도달할 수 없는 주소를 조회가 돌려주기 시작합니다. 이 설정은 VPC 리졸버를 통해 들어오는 쿼리의 응답을 바꾸며, 어디에 있는 모든 클라이언트의 응답을 바꾸는 것이 아닙니다.

dig +short bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com
aws s3api head-bucket --bucket example-artifacts --endpoint-url https://bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com

둘 다 애플리케이션 호스트에서 실행하고, VPC 안의 점프 박스에서는 실행하지 않습니다. 거기서 응답하는 리졸버가 워크로드가 쓰는 리졸버이며, 다른 호스트에서 다른 응답이 나오는 것이 이 설계에서 가장 흔한 혼란의 원인입니다.

도달 가능성은 권한 부여가 아닙니다

엔드포인트에 도착한 요청에는 여전히 권한이 부여된 주체와 적용되는 버킷 권한이 필요합니다. 엔드포인트 정책은 엔드포인트가 허용하는 범위를 좁힐 수 있고, 버킷 정책은 그것을 다시 좁힐 수 있습니다. 인터페이스에 도달한다고 해서 호출자가 어떤 객체를 읽을 수 있는지는 알 수 없습니다.

의도한 버킷에 대한 무해한 권한 부여 호출 하나와, 정책 밖의 자격 증명이나 리소스에 대해 거부될 것으로 예상되는 호출 하나를 양방향으로 시험합니다. 엔드포인트 이름, 확인된 주소, 정책 맥락을 결과와 함께 남겨 다음 사람이 재현할 수 있게 합니다. 정책 유형을 밝혀 주는 거부는 한 시간의 추측을 아껴 줍니다.

마지막으로 프로비저닝 전에 두 선택지의 비용을 따져 봅니다. 인터페이스 엔드포인트는 인터페이스 시간과 기가바이트 단위로 과금되지만 게이트웨이 엔드포인트는 그렇지 않으며, 이 차이가 VPC 쪽 접근만 필요한 저용량 워크로드 다수에서 답을 결정합니다.