타사 클라우드 데이터베이스에 대한 네트워크 액세스를 위한 AWS VPC 피어링과 PrivateLink 비교

타사 클라우드 데이터베이스에 대한 네트워크 액세스를 위한 AWS VPC 피어링과 PrivateLink 비교

여기 AWS가 있습니다. ALB(애플리케이션 로드 밸런서)가 앞에 있는 자동 크기 조정("대상") 그룹에 있는 EC2 인스턴스에서 실행되는 간단한 앱 서버가 있습니다. ALB의 도메인 이름은 DNS에서 내 개발 하위 도메인(예: dev.myapp.example.com. 따라서 curl, wget, PostMan 등을 사용하여 HTTP 요청을 실행 http://dev.myapp.example.com하고 응답을 받을 수 있으며, 이러한 요청은 ALB(자동 확장 그룹 내) 뒤에 있는 모든 EC2 인스턴스에 걸쳐 로드 밸런싱됩니다.

해당 EC2 인스턴스에서 실행되는 앱 서버는 타사 Database-as-a-Service에 연결해야 합니다. MyCloudDB이 질문의 목적에 맞게 이 클라우드 DB를 " "라고 부르겠습니다 .

EC2 인스턴스를 수동으로 프로비저닝하고 거기에 앱 서버를 배포할 때 웹 콘솔 MyCloudDB에 로그인 MyCloudDB하고 /32 서브넷이 있는 EC2 인스턴스의 퍼블릭 IP 목록에 액세스해야 합니다(솔직히 왜 /32 서브넷에 있는지 잘 모르겠습니다.). 예를 들어 AWS가 인스턴스에 대한 퍼블릭 IP를 로 할당하는 경우 1.2.3.4로그인하여 MyCloudDB에 대한 액세스 목록 항목을 추가 해야 합니다 1.2.3.4/32. 그런 다음에만 새 EC2 인스턴스에서 실행되는 앱 서버가 MyCloudDB.

이 허용/액세스 목록 설정을 내 ALB 및 해당 자동 크기 조정 그룹과 호환되게 만드는 방법을 알아내려고 노력 중입니다. 분명히 Auto Scaling 그룹의 EC2 인스턴스는 임시적이며 Auto Scaling 규칙에 따라 회전 및 해체됩니다. 이는 동적/탄력적이어야 하므로 MyCloudDBALB 뒤의 EC2 인스턴스에서 오는 모든 요청을 "신뢰"하도록 지시하는 방법이 필요합니다. 그리고 분명히 보안을 너무 완화해서 나 자신에게 골치 아픈 일이 생기지 않도록 하십시오.

MyCloudDB3가지 유형의 네트워크 액세스 옵션을 제공합니다 .

  • IP 액세스 목록(_현재 내가 현재 사용하고 있는 것, 독점적으로 사용하는 것)
  • VPC 피어링
    • 이를 통해 내 앱 VPC를 MyCloudDBVPC 와 피어링할 수 있습니다.
  • 프라이빗 엔드포인트
    • AWS PrivateLink가 다음에 연결할 수 있도록 허용합니다.MyCloudDB
  • 관리 REST API
    • IP 액세스 목록을 관리할 수 있지만 RESTful(웹 서비스) API를 통해 관리할 수 있습니다.
    • MyCloudDB그래서 EC2 인스턴스 수명 주기 후크를 생성하여 인스턴스 IP 주소를 IP 액세스 목록 에 추가하는 스크립트를 실행 하거나 curl다른 도구를 사용할 수 있습니다.

따라서 자동화의 관점에서 볼 때 제가 가지고 있는 3가지 옵션은 VPC 피어링, 프라이빗 엔드포인트(PrivateLink) 또는 API 호출입니다. API 호출 옵션의 장단점을 분석할 수 있지만 "나무를 통해 숲을 보다"VPC 피어링 및 PrivateLink 옵션에 대해 설명합니다.

주요 호출최종적으로는 이 ALB를 새로운(임시) 환경으로 롤아웃하는 작업을 관리하는 CloudFormation 템플릿을 갖게 될 것입니다. 따라서 ALB 뒤에 있는 EC2 인스턴스에서 작동하려면 이 연결 솔루션이 필요할 뿐만 아니라 CloudFormation을 통해 프로비저닝될 ALB에서도 작동하려면 이 연결 솔루션이 필요합니다.

내 상황, 컨텍스트 및 요구 사항을 고려할 때 VPC 피어링과 PrivateLink의 장점/단점은 무엇입니까?

답변1

이것이 바로 PrivateLink가 만들어진 이유입니다. VPC에 네트워크 인터페이스를 효과적으로 배치하면 액세스할 수 있습니다. 측에서는 NLB에 도달한 다음 데이터베이스로 이동합니다. 이것은 최소한의 권한이며 내가 할 일입니다.

VPC 피어링은 더 많은 네트워크에 더 많은 네트워크를 개방합니다. IP 범위가 충돌하면 더 어려워집니다. 이 상황에서는 아무런 이점이 없습니다.

IP 액세스 목록이 유일한 옵션인 경우 Auto Scaling 그룹에 고정 IP가 필요합니다. 각 서브넷에 NAT 게이트웨이를 생성하고 탄력적 IP를 화이트리스트에 추가하면 이를 달성할 수 있습니다.

관련 정보