AWS VPC 설계 (CIDR 설계, 보안 설정, 실전 구성)

VPC(Virtual Private Cloud) 완전 정복

솔직히 저는 처음 VPC를 설계할 때 "그냥 기본값 쓰면 되겠지"라고 생각했습니다. 그게 얼마나 순진한 발상이었는지는, 나중에 CIDR 블록이 겹쳐서 VPC Peering이 먹통이 됐을 때 뼈저리게 깨달았습니다. VPC 설계는 한 번 굳히면 되돌리기 어려운 결정이 많아서, 처음부터 제대로 이해하고 들어가는 것이 결국 시간을 아끼는 길입니다. "나중에 바꾸면 되지"라는 말이 얼마나 위험한 생각인지를 VPC에서 처음으로 실감했습니다.

CIDR 설계, 왜 처음이 중요한가

VPC를 만들 때 가장 먼저 마주치는 것이 CIDR(Classless Inter-Domain Routing) 블록 선택입니다. CIDR이란 IP 주소 범위를 슬래시(/) 뒤의 숫자로 표기하는 방식으로, 예를 들어 10.0.0.0/16은 10.0.0.0부터 10.0.255.255까지 총 65,536개의 IP 주소를 포함한다는 뜻입니다. 저는 첫 설계에서 10.0.0.0/16을 VPC CIDR로 잡았는데, 이 선택 하나가 이후 서브넷 분리와 VPC Peering 전체 구조를 좌우했습니다.

RFC 1918에서 정의한 사설 IP 범위는 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 세 가지입니다. 사설 IP 범위란 공인 인터넷에서는 라우팅되지 않고 내부 네트워크에서만 사용하도록 예약된 주소 대역을 의미합니다. 클라우드 환경에서는 이 범위 안에서 VPC CIDR을 잡는 것이 원칙입니다.

제가 실수를 통해 배운 핵심이 여기 있습니다. CIDR 블록 크기를 너무 작게 잡으면 나중에 서브넷을 추가할 공간이 없고, 너무 크게 잡으면 다른 VPC나 온프레미스 네트워크와 주소 범위가 겹칠 위험이 높아집니다. 특히 멀티 계정 환경에서는 각 VPC의 CIDR이 절대 겹치지 않아야 나중에 연결이 가능합니다. 이 부분을 처음에 문서로 정리해두지 않으면, 조직이 커질수록 주소 충돌 문제가 반드시 터집니다. 저는 이 문서화를 처음에 귀찮아서 미뤘고, 나중에 CIDR 재설계를 해야 하는 상황이 생겨서 몇 배의 시간을 쏟았습니다.

CIDR 설계 시 미리 고려해야 할 사항을 정리하면 다음과 같습니다. 향후 계정 수와 연결 가능성을 고려해 각 VPC에 겹치지 않는 CIDR 대역을 사전 할당해야 하고, 서브넷은 가용 영역(AZ)별로 분리하고 퍼블릭/프라이빗/DB 용도로 나눠서 관리 단위를 명확히 해야 합니다. /16 수준의 여유 있는 블록을 VPC에 할당하고, 서브넷은 /24 단위로 잘게 쪼개는 방식이 유연성이 높습니다.

Security Group과 NACL, 어디서 막아야 할까

보안 설정에서 가장 많이 헷갈리는 부분이 Security Group과 Network ACL(NACL)의 차이입니다. 저도 처음에 둘 다 "방화벽"이라는 개념으로만 이해하다가 NACL에서 아웃바운드 허용을 빠뜨려서 응답이 안 나가는 황당한 상황을 겪었습니다. 분명히 인바운드는 열었는데 왜 응답이 없냐고 한참을 디버깅하다가 NACL의 상태 비저장 특성을 깨달은 순간이 기억납니다.

Security Group은 상태 저장(Stateful) 방식으로 동작합니다. 상태 저장이란 인바운드 트래픽을 허용하면 그에 대한 아웃바운드 응답은 별도 규칙 없이 자동으로 허용된다는 의미입니다. 인스턴스 레벨에서 작동하며, 허용 규칙만 존재하고 거부 규칙은 만들 수 없는 구조입니다. 반면 NACL은 상태 비저장(Stateless) 방식으로 서브넷 레벨에서 작동하며, 인바운드와 아웃바운드를 각각 명시적으로 설정해야 합니다. 규칙 번호가 낮은 것부터 순서대로 평가되기 때문에 규칙 순서 관리도 중요합니다.

AWS 공식 문서에 따르면 Security Group은 인스턴스 단위의 세밀한 접근 제어에, NACL은 서브넷 전체를 대상으로 한 광범위한 차단에 적합하다고 설명하고 있습니다. 직접 써보니 이 설명이 맞기는 한데, 실무에서는 NACL을 너무 촘촘하게 쓰면 디버깅이 몹시 번거로워집니다. 그래서 평소에는 Security Group으로 접근 제어를 주도하고, NACL은 특정 IP 대역 차단처럼 서브넷 수준의 넓은 정책에만 사용하는 방식을 선호하게 됐습니다. 이 둘을 동시에 세밀하게 쓰려 하면 둘 다 헷갈리기 시작합니다. 역할을 명확히 나누는 것이 관리 측면에서 훨씬 낫습니다.

3-tier 구조를 기준으로 직접 구성한 방식을 구체적으로 말씀드리면, 퍼블릭 서브넷에는 ALB와 NAT Gateway를 배치하고 Internet Gateway를 연결했습니다. 프라이빗 서브넷의 EC2 애플리케이션 서버는 인터넷 직접 노출 없이 NAT Gateway를 통해서만 외부로 나가도록 라우팅 테이블을 구성했습니다. NAT Gateway란 프라이빗 서브넷의 인스턴스가 인터넷으로 아웃바운드 통신은 할 수 있지만 외부에서 직접 접근은 불가능하게 해주는 관리형 서비스입니다. DB 서브넷의 RDS는 어떤 외부 경로로도 접근 불가능하게 격리했고, 오직 앱 서버 Security Group에서 오는 트래픽만 허용했습니다. 이 구조가 3-tier 웹 애플리케이션의 가장 기본적인 보안 설계라고 볼 수 있습니다.

VPC Peering과 실전 설계에서 놓치기 쉬운 것들

VPC Peering은 두 VPC를 프라이빗으로 연결하는 기능입니다. 개발 VPC와 운영 VPC를 연결할 때 Peering 요청을 수락하는 것으로 끝인 줄 알았습니다. 그런데 트래픽이 전혀 흐르지 않아서 한참을 헤맸고, 결국 양쪽 VPC의 라우팅 테이블에 각각 상대방 CIDR을 추가해야 한다는 것을 그때서야 알았습니다. Peering 연결만 맺는다고 통신이 되는 게 아니라, 라우팅 설정을 수동으로 양쪽 모두 잡아줘야 한다는 점이 처음에는 상당히 직관적이지 않게 느껴졌습니다. 이런 종류의 "왜 되지 않지?"가 쌓이면서 VPC 개념이 물리 네트워크와 얼마나 다른지를 체감하게 됩니다.

VPC가 온프레미스 네트워크 개념을 클라우드로 이식한 것처럼 보이지만, 실제로는 소프트웨어 추상화 계층이라 물리 스위치를 다룰 때의 직관과 맞지 않는 경우가 꽤 있습니다. 라우팅 테이블이 물리 장비가 아니라 VPC 리소스에 붙는 논리적 객체라는 점, Transit Gateway를 쓰면 편리하지만 연결된 VPC 수에 비례해 비용이 급증할 수 있다는 점도 초기 설계 단계에서 반드시 따져봐야 합니다. Transit Gateway란 여러 VPC와 온프레미스 네트워크를 중앙에서 허브처럼 연결해주는 서비스인데, 소규모에서는 Peering이 오히려 비용 면에서 유리한 경우가 많습니다.

일반적으로 멀티 계정 환경에서는 Transit Gateway가 표준처럼 소개되는데, 연결 수가 많지 않은 초기 단계에서는 비용이 예상치 못하게 폭증할 수 있습니다. 처음 설계할 때 "나중에 바꾸면 되지"라는 생각은 VPC에서만큼은 금물입니다. CIDR 재설계나 구조 변경은 운영 중인 환경에서 거의 불가능에 가까운 작업이기 때문입니다. 이 점을 모르고 시작해서 나중에 뼈저리게 배우는 사람들이 생각보다 많습니다. 저도 그 중 하나였습니다.

마치며

VPC 설계를 처음 시작하는 분이라면, 일단 종이에 서브넷 구조와 CIDR 대역, 라우팅 흐름을 손으로 그려보는 것을 강력히 권합니다. 콘솔을 먼저 열기 전에 그 한 장의 그림이 나중에 수십 시간의 디버깅을 줄여줄 수 있습니다. 이미 운영 중이라면 지금이라도 현재 구조를 문서화하고 CIDR 충돌 여지가 없는지 점검해 보시길 바랍니다. 클라우드는 빠르게 바꿀 수 있다는 인식이 오히려 설계를 가볍게 보게 만드는 함정이 있습니다. 빠르게 만들 수 있지만, 잘못 만들면 되돌리는 데는 훨씬 더 많은 시간이 걸립니다.

---

참고 출처

• AWS 공식 문서 - VPC 개요 : https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html
• AWS 공식 문서 - 서브넷 생성 : https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html
• AWS 공식 문서 - 인터넷 게이트웨이 : https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html
• AWS 공식 문서 - NAT 게이트웨이 : https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html
• AWS 공식 문서 - 보안 그룹 : https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html
• AWS 공식 문서 - 라우팅 테이블 : https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html
• AWS 공식 문서 - CIDR 표기법 : https://docs.aws.amazon.com/vpc/latest/userguide/subnet-sizing.html
• AWS CLI 레퍼런스 - ec2 create-vpc : https://docs.aws.amazon.com/cli/latest/reference/ec2/create-vpc.html