Amazon VPC

웹 서버는 외부에서 접근할 수 있어야 하지만 데이터베이스는 외부에 드러나면 안 됩니다. 그런데 모든 리소스를 같은 공개 네트워크 위에 두면, 무엇이 외부에 열려 있고 무엇이 내부에만 있어야 하는지 설명하고 관리하기가 금방 어려워집니다. 서브넷과 라우팅을 나누지 않으면 외부 노출과 내부 통신의 경계도 쉽게 흐려집니다.

격리 없이 모든 리소스를 같은 네트워크에 두면 작은 설정 실수도 큰 문제로 이어질 수 있습니다. 예를 들어 테스트 서버의 잘못된 설정이 프로덕션 데이터베이스까지 영향을 주거나, 외부에 노출된 웹 서버가 침해됐을 때 같은 네트워크 안의 내부 서비스까지 연쇄적으로 위험해질 수 있습니다. 클라우드 초기에 이런 경계를 명시적으로 설계하고 통제하는 도구가 부족했던 시기에는 환경 간 충돌과 보안 사고가 반복해서 발생했습니다. 이런 배경에서 논리적인 네트워크 경계를 API로 정의할 수 있는 VPC가 클라우드 인프라의 기본 레이어로 자리 잡게 됐습니다.

VPC와 IAM은 둘 다 접근을 통제하지만 다루는 질문이 다릅니다. IAM은 누가 어떤 AWS 작업을 할 수 있는지를 정하고, VPC는 리소스가 어떤 네트워크 경로로 누구와 통신할 수 있는지를 정합니다. 사람이나 서비스의 권한 범위가 문제면 IAM을 보고, 퍼블릭·프라이빗 분리나 통신 경계가 문제면 VPC를 보면 됩니다.

가장 흔한 예시는 3계층 분리입니다. 웹 서버나 로드 밸런서는 퍼블릭 서브넷에 두고, 애플리케이션 서버는 프라이빗 서브넷에, 데이터베이스는 그보다 더 안쪽의 프라이빗 서브넷에 배치합니다. 이렇게 하면 외부 트래픽은 퍼블릭 서브넷의 로드 밸런서까지만 도달하고, 애플리케이션 서버와 데이터베이스는 인터넷에 직접 노출되지 않습니다. VPC는 온프레미스 데이터센터와 AWS를 VPN이나 Direct Connect로 연결해 하나의 연장된 네트워크처럼 구성하는 하이브리드 환경에서도 자주 사용됩니다. 또 규정상 특정 데이터가 퍼블릭 인터넷을 지나면 안 되는 경우에는 VPC 엔드포인트를 통해 S3나 DynamoDB 같은 AWS 서비스에 사설 경로로 접근할 수 있습니다. 다만 VPC는 네트워크 경계와 통신 경로를 설계하는 계층이지, 누가 어떤 AWS 작업을 할 수 있는지 같은 권한 문제를 직접 해결하는 계층은 아니므로, 그런 문제는 IAM과 함께 봐야 합니다.