빗썸의 AWS Service Endpoint 통합 아키텍처를 통한 비용 및 관리 효율 최적화

빗썸(Bithumb)은 대한민국을 대표하는 가상자산 거래소 중 하나로, 안정적이고 확장 가능한 서비스를 제공하기 위해 AWS(Amazon Web Services)의 다양한 인프라 서비스를 적극 활용하고 있습니다. 글로벌 수준의 보안성과 고가용성을 확보하기 위해 다양한 클라우드 기반 아키텍처를 채택하고 있으며, 이러한 기술적 기반 위에 수많은 사용자에게 빠르고 안정적인 거래 환경을 제공합니다.

빗썸은 단순한 암호화폐 거래소를 넘어 디지털 자산의 미래 가치를 선도하는 기업으로 자리매김하고 있으며, 블록체인 기술과 금융 서비스를 융합해 지속적인 혁신을 이어가고 있습니다.

빗썸의 클라우드 인프라 확장과 함께, 안정적이고 안전한 네트워크 구성을 위해 생성된 여러 Amazon VPC와 AWS 서비스 간 연결은 AWS PrivateLink를 통해 데이터를 인터넷에 노출하지 않고 안전하게 연결됩니다. 이와 함께 사용하는 AWS 서비스 종류와 규모가 커짐에 따라 VPC 수가 많아지고 각 VPC에서 PrivateLink를 이용하여 AWS 서비스에 접속하기 위하여 서비스별 Service Endpoint 또한 많아지고 있으며, 이는 Service Endpoint 수의 증가에 따른 비용 증가와 구성 및 관리에 대한 복잡도를 증가시키고 있습니다.

해당 포스팅에서는 빗썸이 이러한 문제를 해결하기 위해 많은 VPC에 대한 각 Service Endpoint를 생성하고 관리하는 것이 아닌 AWS Transit Gateway로 연결된 VPC 환경에서 하나의 허브 VPC에서 AWS 서비스에 대한 인터페이스 VPC 엔드포인트를 생성하고 Transit Gateway와 DNS 규칙을 사용하여 연결된 VPC 전체에서 엔드포인트의 프라이빗 IP 주소로 요청을 해결하는 허브앤스포크 구조의 AWS Service Endpoint 통합 아키텍처 패턴 적용 사례를 공유합니다.

※Service Endpoint: 서비스를 위한 Interface Endpoint의 의미로 해당 포스팅에서 사용되었습니다.

기존 아키텍처

기존의 개별 VPC에 Interface Endpoint 구성 시 고려해야 할 비용 및 운영 이슈

기존에 AWS Systems Manager(SSM)의 ssm, ec2messages, ssmmessages 등 필수 API에 접근하기 위해 각 VPC마다 SSM 서비스에 대한 Interface Endpoint를 개별적으로 구성하게 되면, 여러 가지 부담이 발생했습니다.

• 첫째, 비용 증가입니다. VPC 및 사용하는 AZ마다 Interface Endpoint가 생성되면 그에 따라 비용이 누적됩니다. (*Interface Endpoint 요금)
• 둘째, 운영 관리의 복잡성이 커집니다. Interface Endpoint마다 보안 그룹, 라우팅 테이블, 프라이빗 DNS 설정 등을 별도로 관리해야 하므로, 인프라 변경 시 작업량이 늘어나고 그에 따른 오류 발생 가능성도 높아집니다.
• 셋째, IP 주소 고갈 문제도 무시할 수 없습니다. Interface Endpoint는 해당 VPC의 서브넷 내에서 ENI를 소비하기 때문에, 서비스 수가 늘어날수록 서브넷 내에서 사용할 수 있는 IP가 부족해질 가능성이 생깁니다. 특히 IP 할당이 촘촘하게 이루어진 환경이라면 이 문제는 더욱 심각해질 수 있습니다.

이처럼 단일 VPC가 아닌 다수의 계정과 그안의 VPC별 AZ에서 많은 수의 Interface Endpoint를 운용하는 경우에 비용 효율성과 운영 효율성을 동시에 고려한 아키텍처 설계가 필요했습니다.

개선된 아키텍처

Centralized Interface Endpoint 구성

기존의 각 VPC마다 개별적으로 생성하여 관리하고 있던 SSM 관련 Interface Endpoint(ssm, ssmmessages, ec2messages)는 기존 아키텍처에서 언급된 것 처럼 VPC 수가 증가함에 따라 Interface Endpoint 비용과 관리 복잡성이 증가하는 문제를 야기했습니다.

이를 해결하기 위해, 해당 아키텍처 패턴을 참고하여 위 아키텍처와 같은 중앙 허브 VPC에 SSM 관련 Interface Endpoint를 통합 구성하고, 이를 AWS Transit Gateway를 통해 여러 스포크 VPC와 연결하는 허브 앤 스포크(Hub-and-Spoke) 아키텍처를 도입했습니다.

DNS 및 보안 설정 최적화

스포크 VPC에서 EC2에 설치된 SSM Agent가 ec2messages와 같은 API를 호출하는 경우, ec2messages.ap-northeast-2.amazonaws.com과 같은 서비스 도메인에 대한 Private DNS 해석이 필요합니다. 기존에는 이 DNS 쿼리가 같은 VPC 내 Interface Endpoint의 Private IP로 해석되었습니다. 하지만 개선된 아키텍처에서는 허브 VPC에 있는 Interface Endpoint의 Private IP로 해석되도록 DNS 포워딩 규칙을 구성해야 합니다.

이 문제를 해결하기 위해 허브 VPC에서 Route 53 Resolver의 포워딩 규칙을 생성했습니다. 그리고 AWS Resource Access Manager(AWS RAM)를 활용하여 이 규칙을 스포크 VPC들과 공유했습니다. 이러한 구성을 통해 스포크 VPC의 리소스들은 SSM 서비스의 Private DNS를 허브 VPC에 위치한 Interface Endpoint의 Private IP로 해석할 수 있게 되었습니다. 또한, 보안 그룹과 라우팅 테이블 등의 설정도 중앙에서 일괄적으로 관리할 수 있어 운영 효율성이 크게 향상되었습니다.

도입 효과

• 비용 절감: 각 VPC마다 개별적으로 Interface Endpoint를 생성하던 방식에서 벗어나 중앙에서 통합 관리함으로써, Interface Endpoint 수를 대폭 줄일 수 있어서, 엔드포인트 비용을 절감할 수 있었습니다.
• 운영 효율성 향상: 보안 그룹, 라우팅 테이블, DNS 설정 등을 중앙에서 일괄적으로 관리할 수 있어, 인프라 변경 시 작업량과 오류 가능성이 감소했습니다.
• IP 주소 고갈 문제 해결: 각 Endpoint가 서브넷 내에서 ENI를 차지하는 구조에서 벗어나, 허브 VPC에서만 ENI를 사용함으로써 스포크 VPC의 IP 주소 고갈 문제를 완화할 수 있었습니다.
• 확장성 및 유연성 확보: 서비스 수요 증가에 따라 스포크 VPC를 추가하더라도, 중앙에서 Endpoint를 관리하므로 확장성이 뛰어나고 운영이 유연해졌습니다.
• 모니터링 및 가시성 향상: CloudWatch 기반의 Endpoint 및 Transit Gateway 모니터링을 도입하여 네트워크 구조에 대한 실시간 인사이트를 확보할 수 있었습니다.

아키텍처 선택 시 고려해야 할 요소

이와 같은 중앙 집중형 VPC Endpoint 아키텍처는 많은 경우에 효과적이지만, 모든 상황에 적합한 것은 아닙니다. 다음은 아키텍처 선택 시 고려해야 할 주요 요소들입니다:

1. 트래픽 양: 트래픽이 많은 서비스에서는 Transit Gateway를 통한 데이터 전송 비용이 증가할 수 있습니다. 이 경우, 각 VPC에 개별 Endpoint를 생성하는 분산형 아키텍처가 비용 측면에서 유리할 수 있습니다.
2. 서비스 특성: 실시간성이 중요한 서비스나 대용량 데이터를 처리하는 서비스는 지연에 민감하므로, 허브 VPC를 경유하는 구조가 적합하지 않을 수 있습니다.
3. 서비스 Quotas 확인: Interface Endpoint를 통해 사용하는 AWS 서비스에 대한 계정/리전/VPC 별 Quota limit(초당 API 처리 갯수등) 확인이 필요합니다. VPC별 Quota limit이 있는 경우, 중앙 집중형으로 변경 시, API 처리 성능 제한으로 서비스 영향이 발생할 수 있습니다.

참고로, 2025년 4월에 AWS Route 53 Profiles에서 VPC endpoint를 지원하는 기능을 발표했습니다. 이 기능을 이용하게 되면, Spoke VPC에서 허브 VPC에 있는 SSM 서비스 endpoints에 대한 DNS resolving을 하기 위하여 설정이 필요했었던, Route 53 Resolver Inbound 및 Outbound endpoint, Forwarding rule 을 설정하지 않고도 Route 53 Profiles에서 간단한 설정으로 아래와 같은 아키텍처로 구성할 수 있습니다. 이는 SSM의 Private DNS 해석 과정 부분에서 허브 VPC까지 해석 쿼리를 전달하지 않고 AWS RAM을 통해 공유된 Route 53 Profile을 확인하여 바로 Interface Endpoint의 Private IP를 가져오는 형태입니다.

Centralized Interface Endpoint vs Decentralized Interface Endpoint 비용 비교

✅ 서울 리전 기준, Transit Gateway로 전체 VPC간 연결 구성이 되어있음을 가정합니다. 즉, Transit Gateway 연결 비용 ($0.07/시간/연결)은 제외한 비용 비교입니다. Interface Endpoint 데이터 처리 비용은 연결된 각 AWS 서비스와의 데이터 송수신 처리 비용을 의미합니다.

Decentralized 아키텍처가 유리한 시나리오

📊 대용량 데이터 처리 환경

⚡ 소규모 연결된 네트워크 환경

Centralized 아키텍처가 유리한 시나리오

🏢 대규모 기업 환경

🧪 개발/테스트 환경

위 비용 비교표는 기존에 Transit Gateway 연결이 구성되어 있는 환경에서는 데이터 처리량이 매우 많은 특수한 경우를 제외하고는 대부분의 시나리오에서 Centralized 아키텍처가 비용 효율적일 수 있음을 보여줍니다.

결론

이번 포스팅에서는 빗썸이 “Centralized Interface Endpoint 구성”을 통해 AWS Systems Manager(SSM)를 포함한 다양한 Interface Endpoint를 허브 VPC에 통합 구성하는 과정을 설명했습니다. 그 결과, 비용 절감과 운영 관리 효율성 측면에서 매우 만족스러운 성과를 얻을 수 있었습니다.

기존에는 VPC마다 개별적으로 Endpoint를 구성하면서 비용과 운영 부담이 누적되는 문제가 있었습니다. 하지만 중앙에서 Endpoint를 관리함으로써 불필요한 중복 비용을 줄이고, 방화벽 정책이나 보안 그룹, 라우팅 설정 등 반복적인 네트워크 작업도 간소화할 수 있었습니다. 특히 서비스 수요가 빠르게 증가하는 상황에서도 기존 서브넷의 IP 고갈 문제를 해결하고, 보다 유연하게 리소스를 운영할 수 있는 기반을 마련한 점이 가장 큰 변화였습니다.

또한, CloudWatch와 연계한 Endpoint 및 Transit Gateway(TGW) 모니터링 체계를 추가로 도입하면서, 네트워크 흐름과 병목 지점을 실시간으로 파악하고 대응할 수 있는 실전적인 인사이트도 확보할 수 있었습니다. 이를 통해 단순한 구조 변경을 넘어, 운영 전반의 가시성과 안정성을 한층 강화하는 계기가 되었습니다.