
여기 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 규칙에 따라 회전 및 해체됩니다. 이는 동적/탄력적이어야 하므로 MyCloudDB
ALB 뒤의 EC2 인스턴스에서 오는 모든 요청을 "신뢰"하도록 지시하는 방법이 필요합니다. 그리고 분명히 보안을 너무 완화해서 나 자신에게 골치 아픈 일이 생기지 않도록 하십시오.
MyCloudDB
3가지 유형의 네트워크 액세스 옵션을 제공합니다 .
- IP 액세스 목록(_현재 내가 현재 사용하고 있는 것, 독점적으로 사용하는 것)
- VPC 피어링
- 이를 통해 내 앱 VPC를
MyCloudDB
VPC 와 피어링할 수 있습니다.
- 이를 통해 내 앱 VPC를
- 프라이빗 엔드포인트
- AWS PrivateLink가 다음에 연결할 수 있도록 허용합니다.
MyCloudDB
- AWS PrivateLink가 다음에 연결할 수 있도록 허용합니다.
- 관리 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를 화이트리스트에 추가하면 이를 달성할 수 있습니다.