.png){kind=small}
안녕하세요. 이번 포스팅에서는 멀티 어카운트 환경이나 파트너사와의 연동 시 자주 마주치는 네트워크 연결 문제, 그리고 이를 AWS PrivateLink를 통해 깔끔하게 해결한 경험을 공유하려 합니다.
1. 배경: 왜 PrivateLink인가?
보통 다른 AWS 계정에 있는 내부 서비스(예: EC2의 Apache 웹 서버)에 접근해야 할 때, 가장 먼저 떠올리는 것은 VPC Peering이나 **Transit Gateway(TGW)**입니다. 하지만 실무에서는 다음과 같은 제약 사항 때문에 이 방법들을 쓰기 어려운 경우가 종종 발생합니다.
CIDR 충돌: 양쪽 계정의 VPC 대역이 겹쳐서 라우팅이 불가능한 경우.
보안 규정: 인터넷 게이트웨이(IGW)를 통할 수 없거나, 네트워크 전체를 연결하는 Peering은 부담스러운 경우.
최소 권한 원칙: 딱 특정 포트(예: 80/443)만 열어주고 싶을 때.
이런 상황에서 가장 적합한 솔루션이 바로 AWS PrivateLink입니다.
PrivateLink의 장점
보안성: 트래픽이 퍼블릭 인터넷을 타지 않고 AWS 백본망 내에서만 이동합니다.
유연성: IP 대역(CIDR)이 겹쳐도 상관없고, 라우팅 테이블을 복잡하게 건드릴 필요가 없습니다.
제어 용이성: 계정 단위로 Whitelist 관리가 가능하고, 승인(Acceptance) 절차를 통해 연결을 통제할 수 있습니다.
2. 아키텍처 개요
구성은 **서비스를 제공하는 쪽(Provider, A계정)**과 **서비스를 소비하는 쪽(Consumer, B계정)**으로 나뉩니다.
목표: B 계정(Consumer)에서 A 계정(Provider)의 내부 웹 서비스에 사설로 접근.
핵심 구성:
A 계정: NLB (Network Load Balancer)를 생성하고 이를 Endpoint Service로 노출.
B 계정: Interface VPC Endpoint를 생성하여 A 계정의 서비스와 연결.
이 구성은 단방향(B → A) 호출에 최적화되어 있으며, 보안 그룹(SG)과 NLB만으로 깔끔하게 운영할 수 있다는 장점이 있습니다.
3. 구축 가이드
그럼 실제 구성을 어떻게 진행했는지 단계별로 살펴보겠습니다.
Step 1. A 계정 (Provider) 설정
서비스를 제공하는 쪽입니다. 여기서는 NLB와 Endpoint Service가 핵심입니다.
EC2 및 NLB 준비
먼저 Private Subnet에 웹 서버(HTTPD)가 떠 있는 EC2를 준비합니다. (SG: 80 포트 허용)
Internal NLB를 생성하고, 위 EC2를 Target Group으로 등록합니다.
Endpoint Service 생성
VPC 콘솔 > 'Endpoint Services' > 'Create Endpoint Service'로 이동합니다.
로드 밸런서 유형: 'Network'를 선택하고 앞서 만든 NLB를 연결합니다.
허용 리스트(Allow Principals) 추가
아무나 내 서비스에 연결하면 안 되겠죠? 'Allow principals' 탭에서 연결을 허용할 B 계정의 ARN(arn:aws:iam::<B계정ID>:root)을 추가해 줍니다.
서비스 이름 복사
생성이 완료되면 com.amazonaws.vpce.ap-northeast-2.vpce-svc-*********** 형태의 서비스 이름을 복사해 둡니다.
Step 2. B 계정 (Consumer) 설정
이제 서비스를 사용할 쪽에서 연결을 시도합니다.
Interface Endpoint 생성
VPC 콘솔 > 'Endpoints' > 'Create Endpoint'로 이동합니다.
유형: 'Other endpoint services' (또는 NLB/GWLB 사용 옵션)를 선택합니다.
Service Name: 아까 복사해 둔 A 계정의 서비스 이름을 붙여넣고 'Verify'를 누릅니다.
네트워크 설정
VPC와 서브넷을 선택합니다. (가용성을 위해 멀티 AZ 권장)
보안 그룹(SG): 클라이언트가 80/443 포트로 접근할 수 있도록 인바운드 규칙을 설정하여 연결합니다.
Step 3. 연결 승인 (다시 A 계정)
B 계정에서 엔드포인트를 생성했다고 바로 연결되는 것은 아닙니다.
A 계정의 Endpoint Service 화면으로 돌아가 보면, 'Endpoint connections' 탭에 'Pending acceptance' 상태인 요청이 보일 겁니다.
해당 요청을 선택하고 **'Accept'**를 눌러주면 비로소 연결 파이프라인이 완성됩니다.
4. 접속 테스트
연결이 완료(Available) 상태가 되면 B 계정에서 테스트를 진행합니다.
1) 기본 DNS로 호출 PrivateLink 생성 시 부여된 기본 DNS 이름을 사용합니다.
2) Private DNS 사용 시 (옵션) 만약 app.internal.example.com 처럼 예쁜 도메인을 쓰고 싶다면, Endpoint 설정에서 Private DNS 옵션을 켜고 Route53 설정을 추가하면 됩니다.
Tip: 원본 클라이언트의 IP가 애플리케이션 로그에 꼭 남아야 한다면, NLB의 Proxy Protocol v2를 활성화하거나 NLB 뒤에 ALB를 붙이는 구성을 고려해야 합니다. (PrivateLink를 타면 소스 IP가 NLB IP로 보일 수 있습니다.)
5. 운영 시 체크리스트 (Troubleshooting)
구축 과정에서 연결이 안 된다면 다음 사항들을 꼭 점검해 보세요.
[ ] 리전 일치: 서비스(A)와 엔드포인트(B)가 같은 리전에 있나요?
[ ] 헬스 체크: A 계정의 NLB Target Group이 Healthy 상태인가요?
[ ] 보안 그룹(SG):
B 계정: Interface Endpoint가 가진 SG가 클라이언트의 접근(Inbound)을 허용하고 있나요?
A 계정: EC2의 SG가 NLB의 서브넷 대역 (또는 VPC CIDR)에서의 접근을 허용하고 있나요?
[ ] AZ 배치: NLB와 Endpoint가 생성된 가용 영역(AZ)이 서로 매핑되어 있나요?
6. 비용 및 제약 사항
마지막으로 도입 전 고려해야 할 비용과 제약 사항입니다.
비용: B 계정(Consumer) 쪽에 생성된 Interface Endpoint에 대해 시간당 요금과 데이터 처리 요금이 부과됩니다. 트래픽이 아주 많다면 데이터 처리 비용을 미리 계산해 보는 것이 좋습니다.
제약: 이 구조는 단방향(Client → Server) 통신입니다. 만약 양방향 통신이 필요하다면 반대 방향으로도 PrivateLink를 하나 더 구성해야 합니다. 또한 UDP나 ICMP 프로토콜은 제약이 있을 수 있습니다.
마치며
PrivateLink는 처음 설정할 때 개념이 조금 낯설 수 있지만, 한 번 구성해 두면 네트워크 충돌 걱정 없이 매우 안전하고 깔끔하게 계정 간 연동을 처리할 수 있는 강력한 도구입니다.
보안이 중요한 멀티 계정 환경을 운영 중이라면 꼭 한 번 활용해 보시길 추천합니다.
.jpg)
