VPC Private link를 이용한 SaaS 개발

Contents

PrivateLink는 VPC 내부에서 외부에 있는 다른 서비스를 연결하기 위한 기술이다. PrivateLink를 이용하면, 퍼블릭 네트워크(인터넷)을 거치지 않고도 AWS의 서비스와 다른 서비스(다른 계정의 네트워크, 다른 VPC에 존재하는)를 호출 할 수 있다.

PrivateLink는 아래와 같은 장점이 있다.

• 트래픽보호 : 인터넷에 자원(EC2 등)을 노출시키지 않고, AWS 서비스 혹은 자신의 다른 VPC에 있는 서비스에 연결 할 수 있다. 인터넷에 노출되지 않기 때문에, DDoS 공격등에 대한 노출이 감소한다. 서비스를 Private subnet에 배치하면, 사설 네트워크에서 호스팅 하는 것처럼 작동한다.
• 간단한 네트워크 구성 : 방화벽 설정, 라우팅 테이블 변경, VPC 피어링 연결등과 같은 복잡한 설정이 필요없다.
• 마이그레이션 : 기존 온프레미스 애플리케이션은 SaaS 형태로 쉽게 마이그레이션 할 수 있다.
• 규제 준수 : 개인식별정보(PII)가 인터넷을 통과하지 않기 때문에 HIPAA, PCI와 같은 규정을 준수 할 수 있다.

대부분의 클라우드 관리자들이 VPC를 구성 할 때, 퍼블릭 서브넷과 프라이빗 서브넷으로 네트워크를 구성을 한다. 퍼블릭 서브넷에는 ELB나 웹 서버등을 배치하고, 프라이빗 서브넷에는 데이터베이스, 웹 애플리케이션 서버 등 인터넷으로 부터 격리가 필요한 자원들을 배치해서 네트워크 보안성을 높인다. 아래와 같이 퍼블릭 서브넷에는 ELB만 두고, 나머지 모든 자원들을 프라이빗 서브넷에 두는 경우도 있다.

인터넷에서 사용하는 서비스라면 문제가 없는 구성이지만, 내부의 다른 서비스가 사용하려고 할 경우 인터넷을 경유해야 한다는 문제가 있다. 쓸데 없는 인터넷 트래픽이 발생한다는 점과 외부에 노출된다는 점이 문제다.

JERP 라는 서비스를 하는 애플리케이션이 있다. 이 애플리케이션을 다른 팀에 제공하고 싶다고 가정해보자. Internet facing ELB로 제공 할 수 있기는 하지만 패킷이 인터넷을 경유하기 때문에 좋은 구조가 아니다. 내부에서 사용 할 경우 IP를 기반으로 접근설정을 해야 할텐데, 해당 서비스를 요구하는 팀이 늘어날 수록 관리하기가 힘들어진다.

Internal ELB를 이용해서 내부에서만 접근하도록 하면 어떨까 ? 다른 VPC에 위치하는 것도 생각해야 하기 때문에 VPC Peering를 이용해야 할 것이다.

보안문제도 해결 할 수 있고 잘 작동하겠지만, 연동해야 하는 VPC가 많을 경우 관리하기 힘들어진다. 같은 조직(회사차원)에서만 사용 할 거라면, 그나마 관리 할 수 있겠지만 SaaS 형태로 퍼블릭하게 서비스하고 싶다면 이 방법을 사용 할 수 없다.

PrivateLink를 이용하면 내가 개발한 애플리케이션을 1. 같은 계정의 다른 VPC, 2.다른 계정의 VPC, 3. AWS의 서비스도 연결해서 사용 할 수 있다. 이때 트래픽은 인터넷을 경유하지 않고, AWS 네트워크에서 처리되기 때문에 안전하고 간단하게 서비스 할 수 있다.

AWS S3 서비스의 경우를 예로 들어보자. S3는 AWS 공융 네트워크에 있기 때문에, Private Subnet에서는 접근 할 수 없는 문제가 있다. PrivateLink를 이용하면 Private Subnet에서도 AWS의 서비스에 접근 할 수 있다. 접근 할 수 있는 AWS 서비스는 아래와 같다.

• cloudtrail
• dynamodb
• ecs & ecr
• elasticloadbalancing
• kinesis-streams
• kms
• s3
• sagemaker
• sns
• sqs
• ssm

VPC PrivateLink의 작동방식은 아래와 같다.

오른쪽 VPC에 서비스 애플리케이션이 올라가 있다. 이 애플리케이션은 DynamoDB 같은 AWS Service, 마켓플레이스 애플리케이션 혹은 내 VPC에 구성한 애플리케이션일 수 있다. 이 문서에서는 내가 구성한 애플리케이션(Own Service on Amazon VPC)를 서비스하는 것을 테스트 해 볼 것이다.

오른쪽 VPC에 내가 만든 서비스를 사용하려는 EC2 인스턴스가 있다.

PrivateLink는 VPC Endpoint와 Network Load Balancer를 이용해서 서비스를 사용 할 수 있게 한다.

VPC Endpoint는 VPC를 AWS 서비스 혹은 다른 VPC의 서비스를 연결하기 위한 종단점(endpoint)다. VPC Endpoint를 이용하면 인터넷 게이트웨이, NAT 디바이스, VPN Peering, AWS Direct Connection없이 연결 할 수 있다.

VPC Endpoint로 부터 내 서비스의 연결을 허용하기 위해서는 Network Load Balancer 타입의 ELB를 전개해야 한다.

그래서 VPC PrivateLink로 네트워크를 다시 구성하기로 했다. AWS PrivateLink를 이용하면, VPC endpoint network interface를 이용해서, VPC 내부에 있는 서비스를 다른 VPC에 제공할 수 있다. 다른 계정에 있는 VPC의 endpoint network interface를 통해서도 접근 할 수 있기 때문에, SaaS 애플리케이션 처럼 배포 할 수 있다. 실제 AWS Marketplace에도 PrivateLink를 이용한 서비스가 있다. PrivateLink 이전의 Marketplace 서비스들은 애플리케이션이 설치된 EC2 인스턴스를 자동으로 배포하는 정도로 여전히 EC2 인스턴스에 대한 가용성, 확장성, 모니터링등 운영에 신경을 써야 했다. 이제 이런 것들까지 위임할 수 있게 됐다.

나는 VPC PrivateLink를 이용해서 아래와 같이 서비스를 구성하기로 했다.

JERP서비스는 Private Subnet에 전개한다. 그리고 internal facing ELB를 만들었다. JERP 서비스를 사용하고 싶다면 endpoint network interface를 만들어서 ELB에 연결하기만 하면 된다.

실제 VPC PrivateLink를 이용해서 서비스를 구성해 보기로 했다. 먼저 테스트 할 애플리케이션을 준비했다. 두 대의 EC2 인스턴스에 "Hello World"를 출력하는 간단한 웹 애플리케이션을 실행했다. 그리고 internal facing ELB를 이용해서 이들 두 개의 EC2 인스턴스를 묶었다. ELB가 제대로 세팅됐는지 테스트했다. Private IP가 출력되는 걸 보니, 잘 설치된 것 같다. curl로 애플리케이션이 작동하는지 테스트를 했다.

이 애플리케이션의 이름은 JERP다.

서비스 제공자 측 즉 JERP를 만드는 측에서는 Endpoint Service를 만든다. Endpoint Service를 만들면 Service ID가 만들어지는데, 이 Service ID를 통해서 서비스를 사용 할 수 있다.

VPC 대시보드에서 Endpoint Service를 선택한다. 그러면 아래 그림 처럼, Endpoint Service로 만들 수 있는 Network Load Balancer 목록이 뜬다.

JERP를 위해서 만든 privatelink-nlb 네트워크 로드밸런서를 선택했다.

• Included Availability Zones : 로드밸런서가 커버하는 가용성 존
• Require acceptance for endpoint : 우리가 만든 Endpoint Service를 사용하기 위해서 연결 요청/승인과정을 밟게 할 것인지를 설정한다. 체크하지 않는다면 endpoint 연결이 자동으로 승인된다.

이제 EndPoint Services 메뉴에서 지금 만든 서비스 정보를 확인할 수 있다.

• Service ID : 서비스 식별자
• Service name : 외부에 공개되는 서비스이름. 연결하려는 측에서는 Service name으로 연결하려는 서비스를 찾을 수 있다.
• Endpoint Connections : 이 서비스에 연결한 VPC Endpoint 목록을 확인 할 수 있다.

Endpoints 메뉴로 이동 Create Endpoint를 클릭한다.

3개의 서비스 카테고리가 있다.

1. AWS Services : S3, ECR, DynamoDB 등의 AWS 서비스
2. Service name으로 연결할 서비스를 찾을 수 있다.
3. Your AWS Marketplace services : 마켓플레이스 서비스

Endpoint Service에서 만들었던 Service name 으로 서비스를 찾으면 된다.

연결할 VPC를 선택하고, 시큐리티 그룹을 설정하면 endpoint가 만들어진다.

• Status : Pending acceptance, 서비스 제공자의 허가를 기다리고 있는 상태다.
• Endpoint type : VPC Endpoint는 interface endpoint와 gateway endpoints 두 가지 종류가 있다. interface endpoint 타입을 선택하면, 트래픽의 진입점이 되는 ENI(Elastic network interface)가 만들어진다.
• Service name : 연결요청한 Endpoint Service의 Service name
• DNS Name : DNS 이름을 이용해서, Endpoint interface에 접근 할 수 있다.

Endpoint Service로 이동해서 Endpoint Connections를 보면, 요청 대기(Pending Acceptance) 중인 Endpoint가 보인다.

Actions > Accept endpoint connection request를 선택해서 연결을 허가 할 수 있다. 수 분 정도의 시간이 지나면 Accept 상태가 된다.

Endpoint의 Status가 available인 것을 확인하고 테스트를 수행하자. 요청 VPC에 인스턴스를 만들고 Endpoint DNS로 요청을 보냈다.

HIPPA(Health Insurance Portability and Accountability Act)는 1996년 8월 21일 제정되고, 1996년 빌 클린턴 대통령이 서명했다. 여기에는 의료정보의 흐름을 현대화하고, 건강 관리 및 의료보험업계에서 유지/관리하는 개인 식별 정보를 사기와 도난으로 부터 보호하기 위한 규정들을 포함하고 있다.

AWS의 HIPAA 준수에 대해서 확인하고 싶다면 여기 문서를 참고하자.

Payment Card Industry Data Security Standard(PCI DSS)는 카드업체에서 신용카드를 처리하는 조직의 정보보안 표준을 다룬다. 이 표준은 신용 카드 사기를 줄이고, 카드 소유자의 개인정보와 데이터에 대한 통제를 강화하기 위해서 만들어졌다.

AWS의 PCI DSS 준수에 대해서 확인하고 싶다면 여기 문서를 참고하자.