Amazon VPC

웹 서버는 외부에 열어야 하지만 데이터베이스는 닫아야 하는데, 같은 공개 네트워크에 놓으면 어느 리소스가 누구에게 보이는지 설명하기 어려워집니다. 서브넷과 라우팅을 나누지 않으면 외부 노출과 내부 통신 경계가 금방 흐려집니다.

격리 없이 모든 리소스가 같은 네트워크에 놓이면 작은 실수 하나가 큰 문제로 번집니다. 테스트 서버에서 잘못된 설정이 프로덕션 데이터베이스까지 도달하거나, 공개 웹 서버가 뚫리면 같은 네트워크 안의 내부 서비스까지 노출되는 일이 실제로 발생했습니다. 클라우드 초기에는 이런 경계를 명시적으로 설계하는 도구가 없었고, 결과적으로 환경 충돌과 보안 사고가 반복됐습니다. 그 필요에서 논리적 네트워크 경계를 API로 정의하는 VPC가 기본 인프라 레이어로 자리잡았습니다.

VPC에서 퍼블릭/프라이빗 경계는 서브넷 자체의 속성이 아니라 라우트 테이블에 인터넷 게이트웨이(IGW)가 연결되어 있는지 여부로 결정됩니다. IGW를 향하는 라우트가 있는 서브넷이 퍼블릭 서브넷이 되고, 그런 라우트가 없는 서브넷이 프라이빗 서브넷이 됩니다. 프라이빗 서브넷에 있는 리소스가 외부로 나가야 할 때는 NAT Gateway를 통합니다. NAT Gateway는 퍼블릭 서브넷에 위치하면서 프라이빗 리소스의 아웃바운드 요청을 대신 내보내고, 외부에서 먼저 들어오는 인바운드 연결은 차단합니다. 보안 그룹은 인스턴스 레벨에서 동작하며 상태를 기억합니다. 아웃바운드로 나간 연결에 대한 응답은 별도 인바운드 규칙 없이도 허용되는 반면, 네트워크 ACL은 서브넷 레벨에서 상태 없이 동작하므로 인바운드와 아웃바운드 규칙을 각각 설정해야 합니다. 즉 보안 그룹은 인스턴스 간 허용 관계를, ACL은 서브넷 경계의 기본 차단을 담당하는 두 개의 다른 레이어입니다.

VPC와 IAM은 둘 다 보안을 다루지만 층위가 다릅니다. IAM은 누가 어떤 AWS 작업을 할지 통제하고, VPC는 리소스가 어떤 네트워크 경계 안에서 통신할지를 통제합니다. 권한과 자격증명이 문제면 IAM을 보고, 퍼블릭·프라이빗 분리와 통신 경로가 문제면 VPC를 보면 됩니다.

프라이빗 데이터베이스, 인터넷에 노출된 웹 계층, 내부 전용 워커처럼 네트워크 경계를 나눠야 하는 거의 모든 AWS 아키텍처에 적합합니다. 온프레미스와 VPN으로 연결해 기존 데이터센터를 AWS로 연장하는 하이브리드 구성에도 자주 쓰입니다. 다만 누가 어떤 작업을 할 수 있는지 같은 권한 문제 자체를 해결하는 계층은 아닙니다.