EC2와 MongoDB Atlas를 연결하며 VPC를 공부한 이유

회사 프로그램은 AWS EC2에서 Node.js 서버를 실행하고, 데이터베이스는 MongoDB Atlas를 사용한다.

처음에는 Atlas의 IP 접근 허용 목록에 서버 IP를 등록하고, 공용 엔드포인트로 연결했다. 필요한 연결은 동작했지만, 보안을 공부하다 보니 이 구조를 조금 더 정확히 이해하고 싶어졌다.

서버와 DB는 어떤 경로로 통신하는지, 사설 연결로 바꾸면 무엇이 달라지는지, 회사 내부에서만 접속하게 하려면 어디까지 설정해야 하는지 궁금했다.

그래서 VPC부터 정리해봤다. 아직 전부 적용한 것은 아니고, 현재 구조와 앞으로 선택할 수 있는 구성을 이해하기 위한 기록이다.

VPC는 네트워크의 범위와 경로를 정하는 공간이다

VPC는 AWS 안에서 IP 주소 범위와 통신 경로를 구성할 수 있는 가상 네트워크다. 그 안을 서브넷으로 나누고, 라우팅과 접근 규칙을 설정한다.

처음에는 Public 서브넷을 “인터넷에 연결된 곳”, Private 서브넷을 “외부에서 접근할 수 없는 곳” 정도로 이해했다. 하지만 이 설명만으로는 부족했다.

구분의 기준은 서브넷의 라우팅 테이블에 인터넷 게이트웨이로 향하는 직접 경로가 있는지다.

Public 서브넷에 있다고 모든 EC2가 인터넷에 공개되는 것은 아니다. IPv4로 직접 통신하려면 공인 IP가 필요하고, 보안 그룹과 네트워크 ACL에서도 해당 트래픽을 허용해야 한다.

반대로 Private 서브넷도 모든 외부 연결이 차단된 공간은 아니다. NAT를 통해 외부로 요청을 보내거나, VPN으로 연결된 사내망과 통신하도록 구성할 수 있다.

서브넷 이름만 볼 것이 아니라, 어떤 경로가 있고 어떤 접근이 허용되어 있는지를 함께 봐야 했다.

현재 구성에서 Atlas의 IP 접근 허용 목록은 접속 가능한 출발지를 제한하는 역할을 한다.

그렇다고 허용 목록만으로 보안을 전부 설명할 수는 없다. Atlas는 DB 연결에 TLS 암호화를 적용하며, DB 사용자 인증과 권한 설정도 함께 필요하다.

각각 해결하는 문제가 다르기 때문이다.

사설 연결을 도입하더라도 이런 보호가 불필요해지는 것은 아니다. 네트워크 경로를 제한하는 것과, 연결 자체를 안전하게 관리하는 것은 함께 가져가야 한다.

애플리케이션이 있는 AWS VPC와 Atlas의 VPC는 서로 다른 네트워크다.

VPC Peering을 구성하면 두 VPC 사이에서 사설 주소를 사용하는 통신 경로를 만들 수 있다. 이 경로의 트래픽은 공용 인터넷을 통과하지 않는다.

다만 연결 요청을 승인하는 것만으로 모든 설정이 끝나는 것은 아니다. 라우팅과 접근 규칙 등 실제 통신에 필요한 설정도 맞춰야 한다.

여기서 중요하게 느낀 것은 Peering의 목적을 과장하지 않는 것이었다.

사설 경로를 사용한다고 해서 데이터를 절대 가로챌 수 없는 것도 아니고, 기존 연결보다 응답 시간이 반드시 줄어드는 것도 아니다. 성능 개선 여부는 실제 환경에서 측정해야 한다.

내가 이해한 핵심은 “더 빠르고 무조건 안전한 연결”이 아니라, 서버와 DB 사이의 통신 경로를 사설 네트워크로 제한할 수 있다는 점이다.

서버와 DB를 사설로 연결하는 것과, 프로그램을 회사 내부에서만 접속하게 만드는 것은 다른 문제다.

만약 사내망에서만 사용해야 한다는 요구사항이 있다면, 다음과 같은 구성을 검토할 수 있다.

이때 사용자는 VPN으로 연결된 경로를 통해 애플리케이션에 접근하고, 애플리케이션은 DB에 접근한다. 사용자와 서버 사이, 서버와 DB 사이를 나눠 보는 것이다.

따라서 “외부에서 접근할 주소가 아예 없다”보다는, “애플리케이션을 인터넷에 직접 공개하지 않고, 허용된 네트워크 경로로 접근하게 한다”고 이해하는 편이 정확하다.

이 구성이 모든 서비스의 정석인 것도 아니다. 실제 사용자가 어디에서 접속해야 하는지에 따라 적합한 구조는 달라진다.

당장 이 구성을 전부 적용하려는 것은 아니다.

Atlas의 Free 클러스터와 Flex 클러스터는 VPC Peering을 지원하지 않는다. Peering을 사용하려면 전용 클러스터가 필요하므로, DB 운영 비용과 설정 부담도 함께 검토해야 한다.

또한 연결 문자열과 DNS 설정도 확인해야 한다. 사설 연결을 구성한다고 애플리케이션에서 DB의 IP 주소를 직접 하드코딩하는 방식으로 바꿔야 하는 것은 아니다.

그렇다고 지금 규모가 작다는 이유만으로 기존 구성이 충분히 안전하다고 단정할 수도 없다. 트래픽뿐 아니라 다루는 데이터, 접근 권한, 운영 환경을 함께 봐야 하기 때문이다.

이번에 공부하면서 얻은 기준은, 보안을 특정 기능 하나의 도입 여부로 판단하지 않는 것이다.

누가, 어디에서, 어떤 경로로 접속하며, 무엇을 할 수 있는지 설명할 수 있어야 한다.

지금 필요한 만큼 구성하되, 요구사항이 달라졌을 때 어디를 바꿔야 하는지는 알고 있기. VPC를 공부하며 정리한 기준이다.