VPC 아키텍처 설계 완벽 가이드

AWS VPC 아키텍처 설계의 핵심 원칙부터 실전 설계 패턴까지, 초급 개발자를 위한 완벽한 가이드입니다. 멀티 AZ 구성부터 서브넷 설계, CIDR 블록 계획까지 실무에 바로 적용할 수 있는 모든 것을 담았습니다.

1. VPC 설계 원칙

어느 날 김개발 씨가 첫 AWS 프로젝트를 맡게 되었습니다. 팀장님이 말했습니다.

"우리 서비스를 위한 VPC를 설계해 보세요." 김개발 씨는 당황했습니다. VPC가 뭔지는 알겠는데, 어떻게 설계해야 할지 막막했습니다.

VPC 설계 원칙은 안전하고 확장 가능한 네트워크 인프라를 만들기 위한 기본 지침입니다. 마치 건물을 지을 때 설계도를 그리는 것처럼, 클라우드 네트워크도 체계적인 계획이 필요합니다.

올바른 설계 원칙을 따르면 보안성과 확장성을 동시에 확보할 수 있습니다.

다음 코드를 살펴봅시다.

import boto3

# VPC 생성 - 설계 원칙에 따른 기본 구조
ec2 = boto3.resource('ec2')

# 원칙 1: 충분한 IP 주소 공간 확보 (/16 권장)
vpc = ec2.create_vpc(CidrBlock='10.0.0.0/16')
vpc.create_tags(Tags=[{"Key": "Name", "Value": "production-vpc"}])

# 원칙 2: DNS 지원 활성화
vpc.modify_attribute(EnableDnsSupport={'Value': True})
vpc.modify_attribute(EnableDnsHostnames={'Value': True})

# 원칙 3: 적절한 태깅으로 리소스 관리
print(f"VPC 생성 완료: {vpc.id}")

김개발 씨는 선배 개발자인 박시니어 씨에게 도움을 청했습니다. "VPC 설계가 처음이라 어떻게 시작해야 할지 모르겠어요." 박시니어 씨는 화이트보드 앞으로 다가가며 말했습니다.

"좋아요, 기초부터 차근차근 알려드릴게요." VPC란 무엇일까요? 쉽게 비유하자면, VPC는 마치 아파트 단지와 같습니다.

아파트 단지 안에는 여러 동이 있고, 각 동마다 보안 시스템과 출입구가 있습니다. 단지 밖과 연결되는 정문도 있죠.

VPC도 마찬가지입니다. AWS 클라우드 안에 여러분만의 독립된 네트워크 공간을 만드는 것입니다.

설계를 시작하기 전에 왜 체계적인 계획이 필요한지 이해해야 합니다. VPC 설계가 제대로 되지 않으면 어떤 일이 벌어질까요?

김개발 씨의 선배인 이실수 씨의 경험담을 들어봅시다. 이실수 씨는 급하게 프로젝트를 진행하느라 VPC를 대충 만들었습니다.

IP 주소 공간을 너무 작게 잡아서 나중에 서버를 추가할 수 없었습니다. 결국 새로운 VPC를 만들고 모든 리소스를 이전하는 데 일주일이 걸렸습니다.

이런 문제를 방지하기 위해 몇 가지 핵심 원칙을 지켜야 합니다. 첫 번째 원칙은 충분한 IP 주소 공간을 확보하는 것입니다.

박시니어 씨가 설명합니다. "처음에는 서버가 몇 대 안 될 것 같아도, 서비스가 성장하면 수백 대가 필요할 수 있어요." 일반적으로 /16 CIDR 블록을 권장합니다.

이는 약 65,000개의 IP 주소를 제공합니다. "너무 많은 거 아니에요?"라고 김개발 씨가 물었습니다.

"아니요, IP 주소는 공짜예요. 넉넉하게 잡는 게 나중에 후회하지 않습니다." 두 번째 원칙은 DNS 지원을 반드시 활성화하는 것입니다.

DNS가 없으면 어떻게 될까요? IP 주소로만 통신해야 합니다.

데이터베이스 서버의 IP가 바뀌면 모든 애플리케이션 코드를 수정해야 하죠. DNS를 활성화하면 도메인 이름으로 통신할 수 있습니다.

훨씬 편리하고 유지보수하기 쉽습니다. 세 번째 원칙은 처음부터 리소스를 체계적으로 관리하는 것입니다.

위의 코드를 살펴보겠습니다. 먼저 boto3 라이브러리를 사용해 AWS와 통신합니다.

create_vpc 함수로 VPC를 생성하는데, CidrBlock='10.0.0.0/16'이 핵심입니다. 이것이 우리가 사용할 IP 주소 범위입니다.

그 다음 create_tags로 이름을 지정합니다. 태그는 나중에 수십 개의 VPC 중에서 원하는 것을 찾을 때 매우 중요합니다.

modify_attribute 함수로 DNS 관련 설정을 활성화합니다. EnableDnsSupport는 AWS가 제공하는 DNS 서버를 사용하겠다는 의미입니다.

EnableDnsHostnames는 EC2 인스턴스에 자동으로 DNS 이름을 부여하는 기능입니다. 이 두 가지를 모두 켜두면 나중에 편리합니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 쇼핑몰 서비스를 개발한다고 가정해봅시다.

처음에는 웹 서버 2대, 데이터베이스 1대로 시작합니다. 하지만 블랙프라이데이 세일 기간에는 웹 서버 50대, 캐시 서버 10대가 필요할 수 있습니다.

충분한 IP 공간을 확보해두면 이런 확장이 자연스럽게 가능합니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수는 CIDR 블록을 너무 작게 잡는 것입니다. "/24나 /25면 충분하겠지"라고 생각하지만, 나중에 후회하게 됩니다.

VPC의 CIDR 블록은 생성 후 수정할 수 없습니다. 추가는 가능하지만 복잡합니다.

처음부터 넉넉하게 잡는 것이 정답입니다. 또 다른 실수는 여러 환경을 하나의 VPC에 섞는 것입니다.

개발 환경, 스테이징 환경, 운영 환경은 반드시 분리해야 합니다. 김개발 씨가 물었습니다.

"왜 꼭 분리해야 하나요?" 박시니어 씨가 답했습니다. "개발 환경에서 실수로 운영 데이터베이스를 건드리면 큰 사고가 나요.

네트워크 레벨에서 아예 분리하는 게 안전합니다." 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 화이트보드에 적힌 설계 원칙을 노트에 정리했습니다.

"이제 어떻게 시작해야 할지 알겠어요!" VPC 설계 원칙을 제대로 이해하면 안정적이고 확장 가능한 인프라를 구축할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - CIDR 블록은 /16으로 시작하되, 나중에 필요하면 추가 블록을 연결할 수 있습니다

환경별로 VPC를 분리하고, 명확한 네이밍 규칙을 정하세요 (예: dev-vpc, staging-vpc, prod-vpc)
태그를 체계적으로 관리하면 비용 추적과 리소스 관리가 훨씬 쉬워집니다

2. 멀티 AZ 아키텍처

VPC 기본 설계를 마친 김개발 씨에게 팀장님이 새로운 요구사항을 주었습니다. "고가용성을 확보해야 해요.

한 데이터센터에 문제가 생겨도 서비스는 계속 돌아가야 합니다." 김개발 씨는 고개를 갸우뚱했습니다. 어떻게 그게 가능할까요?

멀티 AZ 아키텍처는 여러 가용 영역에 리소스를 분산 배치하여 장애에 대비하는 설계 패턴입니다. 마치 중요한 서류를 여러 곳에 백업해두는 것처럼, 서버도 여러 위치에 분산시켜 안정성을 높입니다.

AWS의 가장 기본적이면서도 강력한 고가용성 전략입니다.

다음 코드를 살펴봅시다.

import boto3

ec2 = boto3.resource('ec2')
vpc = ec2.Vpc('vpc-xxxxx')  # 기존 VPC ID

# 각 AZ에 서브넷 생성 - 고가용성의 핵심
availability_zones = ['ap-northeast-2a', 'ap-northeast-2b', 'ap-northeast-2c']

subnets = []
for idx, az in enumerate(availability_zones):
    # 각 AZ마다 /24 서브넷 생성 (256개 IP)
    cidr = f'10.0.{idx}.0/24'
    subnet = vpc.create_subnet(CidrBlock=cidr, AvailabilityZone=az)
    subnet.create_tags(Tags=[{"Key": "Name", "Value": f"public-{az}"}])
    subnets.append(subnet)
    print(f"{az}에 서브넷 생성: {cidr}")

박시니어 씨가 김개발 씨를 회의실로 데려갔습니다. "고가용성 이야기를 해볼까요?" 박시니어 씨는 노트북을 열어 AWS 콘솔을 보여주었습니다.

"서울 리전에는 4개의 가용 영역이 있어요. 각각이 독립된 데이터센터입니다." 가용 영역이란 무엇일까요?

쉽게 비유하자면, 가용 영역은 마치 다른 건물에 있는 은행 지점과 같습니다. 강남 지점에 불이 나도 서초 지점은 정상 영업합니다.

고객은 다른 지점을 이용하면 됩니다. AWS도 마찬가지입니다.

하나의 데이터센터에 문제가 생겨도 다른 데이터센터는 정상 작동합니다. 멀티 AZ가 없던 시절에는 어땠을까요?

박시니어 씨가 옛날 이야기를 꺼냈습니다. "제가 신입일 때 겪은 일이에요.

모든 서버를 하나의 데이터센터에 두었는데, 그곳에 정전이 발생했습니다." 서비스가 완전히 중단되었습니다. 고객들은 화를 냈고, 회사는 큰 손실을 입었습니다.

그날 밤 전 직원이 사무실에 모여 긴급 대응을 했던 기억이 생생합니다. 바로 이런 문제를 해결하기 위해 멀티 AZ 아키텍처가 등장했습니다.

멀티 AZ를 사용하면 자동 장애 조치가 가능해집니다. 하나의 AZ에 문제가 생기면 트래픽이 자동으로 다른 AZ로 전환됩니다.

사용자는 아무것도 모릅니다. 서비스는 계속 정상 작동하죠.

또한 계획된 유지보수도 쉬워집니다. A 영역을 업데이트하는 동안 B 영역이 트래픽을 처리합니다.

세 번째 장점은 성능 향상입니다. 사용자의 요청을 가장 가까운 AZ에서 처리하면 응답 속도가 빨라집니다.

로드 밸런서가 자동으로 최적의 AZ를 선택해줍니다. 박시니어 씨가 덧붙였습니다.

"특히 데이터베이스는 반드시 멀티 AZ로 구성해야 해요." 위의 코드를 단계별로 살펴보겠습니다. 먼저 서울 리전의 가용 영역 목록을 정의합니다.

ap-northeast-2a, 2b, 2c는 각각 독립된 데이터센터입니다. 그 다음 for 루프로 각 AZ마다 서브넷을 생성합니다.

중요한 점은 CIDR 블록을 겹치지 않게 나누는 것입니다. 첫 번째 AZ는 10.0.0.0/24, 두 번째는 10.0.1.0/24를 사용합니다.

create_subnet 함수의 AvailabilityZone 파라미터가 핵심입니다. 이 파라미터로 서브넷이 어느 AZ에 생성될지 결정됩니다.

명시적으로 지정하지 않으면 AWS가 임의로 선택하는데, 이는 좋지 않습니다. 항상 명시적으로 지정해야 나중에 관리하기 쉽습니다.

태그에 AZ 이름을 포함시키는 것도 모범 사례입니다. 실제 현업에서는 어떻게 활용할까요?

대형 이커머스 사이트를 예로 들어봅시다. 웹 서버는 3개 AZ에 분산 배치됩니다.

Application Load Balancer가 트래픽을 균등하게 분배하죠. 데이터베이스는 RDS Multi-AZ로 구성합니다.

마스터 DB가 한 AZ에 있고, 스탠바이 DB가 다른 AZ에 있습니다. 마스터에 문제가 생기면 자동으로 스탠바이가 승격됩니다.

하지만 주의할 점이 있습니다. 초보 개발자들이 흔히 하는 실수는 모든 리소스를 한 AZ에 몰아넣는 것입니다.

"귀찮으니까 일단 하나에 다 만들고, 나중에 분산시키자." 하지만 나중은 오지 않습니다. 처음부터 제대로 설계하는 것이 중요합니다.

또 다른 실수는 홀수 개의 AZ를 사용하지 않는 것입니다. 왜 홀수일까요?

박시니어 씨가 설명합니다. "2개 AZ만 사용하면 네트워크 분할 문제가 생길 수 있어요.

3개를 사용하면 과반수 합의가 가능해서 더 안전합니다." 특히 Kafka, Elasticsearch 같은 분산 시스템은 3개 이상의 AZ를 권장합니다. 비용도 고려해야 합니다.

김개발 씨가 물었습니다. "멀티 AZ는 비용이 더 들지 않나요?" 맞습니다.

서버가 여러 대 필요하니 비용이 증가합니다. 하지만 박시니어 씨는 반문했습니다.

"서비스 중단으로 인한 손실이 더 클까요, 아니면 멀티 AZ 비용이 더 클까요?" 대부분의 경우 답은 명확합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 이해했습니다. "아, 그래서 넷플릭스 같은 서비스는 절대 안 멈추는구나!" 멀티 AZ 아키텍처를 제대로 구현하면 99.99% 이상의 가용성을 달성할 수 있습니다.

여러분의 서비스도 멀티 AZ로 한 단계 업그레이드해 보세요.

실전 팁

💡 - 최소 3개의 AZ를 사용하되, 서울 리전은 4개 모두 활용할 수 있습니다

RDS, ElastiCache, EKS 등 관리형 서비스는 멀티 AZ 옵션을 반드시 활성화하세요
크로스 AZ 데이터 전송 비용이 발생하므로, 같은 AZ 내에서 통신하도록 최적화하세요

3. 퍼블릭 서브넷 설계

멀티 AZ 구성을 이해한 김개발 씨가 다음 단계로 넘어갔습니다. "서브넷을 퍼블릭과 프라이빗으로 나눠야 한다는데, 무슨 차이인가요?" 박시니어 씨가 웃으며 대답했습니다.

"좋은 질문이에요. 보안의 기본이거든요."

퍼블릭 서브넷은 인터넷과 직접 통신할 수 있는 서브넷입니다. 마치 건물의 1층 로비처럼, 외부 방문객이 접근할 수 있는 공간입니다.

웹 서버, 로드 밸런서 등 외부와 통신해야 하는 리소스를 배치합니다. 인터넷 게이트웨이와 라우팅 테이블로 연결됩니다.

다음 코드를 살펴봅시다.

import boto3

ec2 = boto3.resource('ec2')
ec2_client = boto3.client('ec2')
vpc = ec2.Vpc('vpc-xxxxx')

# 1. 인터넷 게이트웨이 생성 - 외부 통신의 관문
igw = ec2_client.create_internet_gateway()
igw_id = igw['InternetGateway']['InternetGatewayId']
vpc.attach_internet_gateway(InternetGatewayId=igw_id)

# 2. 퍼블릭 라우팅 테이블 생성
route_table = vpc.create_route_table()
route_table.create_tags(Tags=[{"Key": "Name", "Value": "public-rt"}])

# 3. 인터넷으로 가는 기본 경로 추가 (핵심!)
route_table.create_route(DestinationCidrBlock='0.0.0.0/0', GatewayId=igw_id)

# 4. 서브넷에 라우팅 테이블 연결
subnet = ec2.Subnet('subnet-xxxxx')
route_table.associate_with_subnet(SubnetId=subnet.id)

print(f"퍼블릭 서브넷 구성 완료: {subnet.id}")

박시니어 씨가 화이트보드에 그림을 그리기 시작했습니다. "VPC는 기본적으로 외부와 완전히 격리된 공간이에요.

마치 울타리로 둘러싸인 정원 같죠." 김개발 씨가 끄덕였습니다. "그럼 외부와 어떻게 통신하나요?" 퍼블릭 서브넷의 개념을 이해해봅시다.

쉽게 비유하자면, 퍼블릭 서브넷은 마치 호텔의 프런트 데스크와 같습니다. 외부 손님이 가장 먼저 만나는 곳이죠.

객실(프라이빗 서브넷)에는 아무나 들어갈 수 없지만, 프런트는 누구나 접근할 수 있습니다. 웹 서비스도 마찬가지입니다.

사용자의 요청을 받는 웹 서버는 퍼블릭 서브넷에 둡니다. 퍼블릭 서브넷이 없으면 어떻게 될까요?

박시니어 씨의 후배인 최신입 씨의 실수담을 들어봅시다. 최신입 씨는 모든 서버를 프라이빗 서브넷에 배치했습니다.

웹사이트를 열었는데 아무것도 나오지 않았습니다. 당연합니다.

외부에서 접근할 수 없으니까요. 결국 처음부터 다시 설계해야 했습니다.

바로 이런 문제를 해결하기 위해 퍼블릭 서브넷 설계가 필요합니다. 퍼블릭 서브넷을 만들면 외부 트래픽을 수신할 수 있습니다.

사용자가 브라우저에 URL을 입력하면 로드 밸런서가 요청을 받습니다. 그 다음 웹 서버가 처리하죠.

또한 NAT 게이트웨이 배치 위치로도 사용됩니다. 프라이빗 서브넷의 서버들이 외부와 통신하려면 NAT 게이트웨이를 거쳐야 하는데, 이것이 퍼블릭 서브넷에 있어야 합니다.

세 번째 역할은 Bastion 호스트입니다. 관리자가 프라이빗 서브넷의 서버에 SSH로 접속하려면 점프 서버가 필요합니다.

이 Bastion 호스트를 퍼블릭 서브넷에 배치합니다. 박시니어 씨가 강조했습니다.

"하지만 요즘은 AWS Systems Manager Session Manager를 사용하는 추세예요. 더 안전하거든요." 위의 코드를 자세히 살펴보겠습니다.

첫 번째 단계는 인터넷 게이트웨이 생성입니다. create_internet_gateway 함수로 IGW를 만들고, attach_internet_gateway로 VPC에 연결합니다.

IGW는 VPC당 하나만 필요합니다. 여러 퍼블릭 서브넷이 하나의 IGW를 공유합니다.

이것이 외부 세계로 나가는 유일한 통로입니다. 두 번째 단계는 라우팅 테이블 생성입니다.

라우팅 테이블은 네트워크 트래픽의 경로를 정의합니다. 마치 도로의 이정표와 같죠.

create_route_table로 새 테이블을 만듭니다. VPC에는 기본 라우팅 테이블이 있지만, 퍼블릭과 프라이빗을 분리하려면 별도로 만들어야 합니다.

세 번째 단계가 가장 중요합니다. create_route 함수로 인터넷으로 가는 경로를 추가합니다.

DestinationCidrBlock='0.0.0.0/0'은 "모든 외부 주소"를 의미합니다. GatewayId=igw_id는 그 경로가 인터넷 게이트웨이를 통한다는 뜻이죠.

이 한 줄이 일반 서브넷을 퍼블릭 서브넷으로 바꿔줍니다. 마지막 단계는 서브넷과 라우팅 테이블을 연결하는 것입니다.

associate_with_subnet 함수로 특정 서브넷에 라우팅 규칙을 적용합니다. 하나의 라우팅 테이블을 여러 서브넷에 연결할 수 있습니다.

보통 각 AZ의 퍼블릭 서브넷들이 같은 라우팅 테이블을 공유합니다. 실제 현업에서는 어떻게 활용할까요?

전형적인 3-tier 아키텍처를 생각해봅시다. 맨 앞단의 Application Load Balancer가 퍼블릭 서브넷에 있습니다.

사용자의 HTTPS 요청을 받아서 뒷단의 웹 서버로 전달합니다. 웹 서버는 프라이빗 서브넷에 있지만, ALB가 중간에서 연결해줍니다.

CloudFront를 사용한다면 더 간단합니다. 정적 컨텐츠는 CloudFront가 서빙하고, 동적 요청만 ALB로 전달됩니다.

하지만 주의할 점이 있습니다. 초보 개발자들이 흔히 하는 실수는 데이터베이스를 퍼블릭 서브넷에 두는 것입니다.

"RDS에 접속이 안 돼서 퍼블릭으로 바꿨어요." 절대 안 됩니다. 데이터베이스는 반드시 프라이빗 서브넷에 두고, 웹 서버를 통해서만 접근해야 합니다.

외부에 직접 노출되면 보안 사고의 위험이 커집니다. 또 다른 실수는 퍼블릭 IP 자동 할당을 안 하는 것입니다.

김개발 씨가 물었습니다. "서브넷 설정에서 'Auto-assign Public IP'를 켜야 하나요?" 박시니어 씨가 답했습니다.

"퍼블릭 서브넷이라면 반드시 켜야 해요. 안 그러면 EC2 인스턴스가 외부와 통신할 수 없습니다." 물론 Elastic IP를 수동으로 할당할 수도 있지만, 자동 할당이 편리합니다.

보안 그룹 설정도 신경 써야 합니다. 퍼블릭 서브넷에 있다고 해서 모든 포트를 열어두면 안 됩니다.

웹 서버라면 80번(HTTP), 443번(HTTPS)만 열어둡니다. SSH(22번)는 특정 IP에서만 접근 가능하도록 제한합니다.

박시니어 씨가 덧붙였습니다. "요즘은 SSH 접근도 Systems Manager로 대체하는 추세예요." 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 노트에 정리했습니다. "퍼블릭 서브넷 = IGW + 라우팅 테이블 + 0.0.0.0/0 경로!" 퍼블릭 서브넷을 제대로 설계하면 안전하면서도 외부 접근이 가능한 인프라를 만들 수 있습니다.

여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - 퍼블릭 서브넷은 각 AZ마다 하나씩 만들되, CIDR 블록 크기는 /24면 충분합니다

Auto-assign Public IP 옵션을 활성화하여 인스턴스가 자동으로 공인 IP를 받도록 설정하세요
민감한 리소스(DB, 애플리케이션 서버)는 절대 퍼블릭 서브넷에 두지 마세요

4. 프라이빗 서브넷 설계

퍼블릭 서브넷을 이해한 김개발 씨가 다음 질문을 던졌습니다. "그럼 프라이빗 서브넷은 외부와 아예 통신을 못 하나요?

패키지 업데이트는 어떻게 하죠?" 박시니어 씨가 미소 지으며 답했습니다. "바로 NAT 게이트웨이가 그 해답이에요."

프라이빗 서브넷은 외부에서 직접 접근할 수 없는 안전한 서브넷입니다. 마치 건물의 내부 사무실처럼, 승인된 사람만 들어갈 수 있습니다.

데이터베이스, 애플리케이션 서버 등 민감한 리소스를 배치합니다. NAT 게이트웨이를 통해 외부로 나가는 통신만 가능합니다.

다음 코드를 살펴봅시다.

import boto3

ec2 = boto3.resource('ec2')
ec2_client = boto3.client('ec2')

# 1. NAT 게이트웨이용 Elastic IP 할당
eip = ec2_client.allocate_address(Domain='vpc')
eip_id = eip['AllocationId']

# 2. 퍼블릭 서브넷에 NAT 게이트웨이 생성 (중요!)
public_subnet = ec2.Subnet('subnet-public-xxxxx')
nat_gw = ec2_client.create_nat_gateway(
    SubnetId=public_subnet.id,
    AllocationId=eip_id
)
nat_gw_id = nat_gw['NatGateway']['NatGatewayId']

# 3. 프라이빗 라우팅 테이블 생성
vpc = ec2.Vpc('vpc-xxxxx')
private_rt = vpc.create_route_table()
private_rt.create_tags(Tags=[{"Key": "Name", "Value": "private-rt"}])

# 4. NAT 게이트웨이로 가는 기본 경로 추가
private_rt.create_route(DestinationCidrBlock='0.0.0.0/0', NatGatewayId=nat_gw_id)

# 5. 프라이빗 서브넷에 연결
private_subnet = ec2.Subnet('subnet-private-xxxxx')
private_rt.associate_with_subnet(SubnetId=private_subnet.id)

print(f"프라이빗 서브넷 구성 완료: {private_subnet.id}")

박시니어 씨가 보안의 중요성을 강조하며 이야기를 시작했습니다. "작년에 큰 보안 사고가 있었어요.

한 스타트업이 데이터베이스를 퍼블릭 서브넷에 뒀다가 해킹당했죠." 김개발 씨는 긴장했습니다. "어떻게 방지할 수 있나요?" 프라이빗 서브넷이란 무엇일까요?

쉽게 비유하자면, 프라이빗 서브넷은 마치 은행 금고와 같습니다. 외부에서는 절대 직접 접근할 수 없습니다.

승인된 직원만 특정 경로를 통해 들어갈 수 있죠. 데이터베이스, 애플리케이션 서버, 캐시 서버 등 중요한 자산을 여기에 보관합니다.

외부 공격자가 직접 접근할 방법이 없으니 훨씬 안전합니다. 프라이빗 서브넷 없이 모든 것을 퍼블릭에 두면 어떻게 될까요?

박시니어 씨의 친구 회사에서 일어난 일입니다. 개발 편의성을 위해 모든 서버를 퍼블릭 서브넷에 배치했습니다.

RDS도 퍼블릭 엑세스를 켰습니다. 어느 날 갑자기 데이터베이스가 이상해졌습니다.

로그를 확인해보니 중국 IP에서 무차별 대입 공격을 시도한 흔적이 있었습니다. 다행히 강력한 비밀번호 덕분에 뚫리진 않았지만, 식은땀이 났습니다.

바로 이런 위험을 방지하기 위해 프라이빗 서브넷을 사용합니다. 프라이빗 서브넷의 첫 번째 장점은 외부 공격으로부터 차단된다는 점입니다.

인터넷에서 직접 접근할 수 없으니, 해커가 데이터베이스를 공격하려면 먼저 웹 서버를 뚫어야 합니다. 방어선이 하나 더 생기는 셈이죠.

두 번째 장점은 네트워크 격리입니다. 각 계층을 분리하면 보안 정책을 더 세밀하게 관리할 수 있습니다.

세 번째 장점은 규정 준수입니다. 김개발 씨가 물었습니다.

"왜 규정이 중요한가요?" 박시니어 씨가 설명했습니다. "금융이나 의료 서비스는 개인정보보호법을 지켜야 해요.

민감한 데이터는 반드시 외부 접근이 차단된 곳에 보관해야 합니다." 프라이빗 서브넷이 바로 그런 요구사항을 만족시킵니다. 하지만 문제가 하나 있습니다.

프라이빗 서브넷의 서버도 외부와 통신해야 할 때가 있습니다. 소프트웨어 업데이트, API 호출, 이메일 발송 등이죠.

그럼 어떻게 해야 할까요? 바로 NAT 게이트웨이가 해답입니다.

위의 코드를 단계별로 분석해봅시다. 첫 번째 단계는 Elastic IP 할당입니다.

NAT 게이트웨이는 고정 IP 주소가 필요합니다. allocate_address 함수로 EIP를 받습니다.

이 IP는 프라이빗 서브넷의 서버들이 외부와 통신할 때 사용하는 공인 IP입니다. 외부에서 보면 모든 요청이 이 하나의 IP에서 나오는 것처럼 보입니다.

두 번째 단계는 NAT 게이트웨이 생성입니다. 중요한 점은 NAT 게이트웨이를 퍼블릭 서브넷에 만든다는 것입니다.

SubnetId=public_subnet.id를 주목하세요. 왜 퍼블릭일까요?

NAT 게이트웨이 자체가 인터넷과 통신해야 하기 때문입니다. 프라이빗 서브넷에 두면 외부로 나갈 수 없습니다.

세 번째 단계는 프라이빗용 라우팅 테이블을 만드는 것입니다. 퍼블릭 서브넷의 라우팅 테이블과는 다릅니다.

create_route_table로 새로 만들고, "private-rt"라는 이름을 붙입니다. 명확한 네이밍이 나중에 관리할 때 중요합니다.

프로젝트가 커지면 라우팅 테이블이 수십 개가 될 수 있습니다. 네 번째 단계가 핵심입니다.

create_route로 기본 경로를 추가하는데, 목적지는 NAT 게이트웨이입니다. DestinationCidrBlock='0.0.0.0/0'은 "모든 외부 주소"를, NatGatewayId=nat_gw_id는 NAT 게이트웨이를 통해 나간다는 뜻입니다.

퍼블릭 서브넷과의 차이점은 IGW 대신 NAT를 사용한다는 것입니다. 마지막으로 프라이빗 서브넷에 라우팅 테이블을 연결합니다.

associate_with_subnet으로 연결하면 모든 설정이 완료됩니다. 이제 프라이빗 서브넷의 EC2 인스턴스가 yum update나 apt-get update를 실행하면 NAT 게이트웨이를 통해 외부 패키지 저장소에 접근합니다.

하지만 외부에서는 절대 해당 인스턴스에 직접 접근할 수 없습니다. 실제 현업에서는 어떻게 활용할까요?

전형적인 웹 서비스 아키텍처를 봅시다. 퍼블릭 서브넷에는 ALB만 있습니다.

웹 서버(EC2 또는 ECS)는 프라이빗 서브넷에 있습니다. 데이터베이스(RDS)도 프라이빗 서브넷에 있죠.

ElastiCache도 마찬가지입니다. 외부에서는 ALB만 볼 수 있고, 나머지는 모두 숨겨져 있습니다.

훨씬 안전한 구조입니다. 하지만 주의할 점이 있습니다.

초보 개발자들이 흔히 하는 실수는 NAT 게이트웨이를 하나만 만드는 것입니다. "비용이 아까워서 하나만 만들었어요." 문제는 고가용성입니다.

해당 AZ에 장애가 나면 다른 AZ의 프라이빗 서브넷도 외부와 통신할 수 없게 됩니다. 각 AZ마다 NAT 게이트웨이를 하나씩 만드는 것이 모범 사례입니다.

또 다른 실수는 NAT 게이트웨이 비용을 간과하는 것입니다. 김개발 씨가 놀라며 물었습니다.

"NAT 게이트웨이가 비싸다고요?" 박시니어 씨가 답했습니다. "시간당 요금과 데이터 처리 요금이 모두 발생해요.

한 달이면 몇십 달러가 나갑니다." 대안으로 NAT 인스턴스를 사용할 수도 있지만, 관리 부담이 있습니다. 서비스 규모와 비용을 고려해서 선택해야 합니다.

VPC 엔드포인트도 고려해야 합니다. S3나 DynamoDB처럼 AWS 서비스와 통신할 때는 VPC 엔드포인트를 사용하면 NAT 게이트웨이를 거치지 않아도 됩니다.

비용도 절감되고 속도도 빨라집니다. 박시니어 씨가 덧붙였습니다.

"요즘은 PrivateLink로 다른 AWS 서비스와도 프라이빗 통신이 가능해요." 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 보안의 중요성을 깨달았습니다.

"민감한 데이터는 반드시 프라이빗 서브넷에!" 프라이빗 서브넷을 제대로 설계하면 보안성과 규정 준수를 동시에 달성할 수 있습니다. 여러분의 인프라도 프라이빗 서브넷으로 한층 더 안전하게 만들어보세요.

실전 팁

💡 - 각 AZ마다 NAT 게이트웨이를 하나씩 배치하여 고가용성을 확보하세요

AWS 서비스 접근은 VPC 엔드포인트를 사용하여 NAT 비용을 절감하세요
DB 서브넷 그룹은 반드시 프라이빗 서브넷으로만 구성해야 합니다

5. CIDR 블록 계획

서브넷 설계를 배운 김개발 씨가 실제로 구현하려다 막혔습니다. "10.0.0.0/16, 10.0.1.0/24...

이 숫자들이 도대체 뭐예요?" 박시니어 씨가 웃으며 답했습니다. "아, CIDR 표기법이군요.

네트워크의 기본이에요."

CIDR 블록 계획은 IP 주소 공간을 효율적으로 나누는 설계 기법입니다. 마치 토지를 구획 정리하듯, VPC의 IP 주소를 논리적으로 분할합니다.

/16, /24 같은 서브넷 마스크로 크기를 조절하며, 미래의 확장을 고려한 설계가 필수입니다.

다음 코드를 살펴봅시다.

import ipaddress

# CIDR 계산을 위한 도우미 함수
def plan_vpc_cidr(vpc_cidr, azs_count=3):
    """VPC CIDR을 여러 서브넷으로 분할"""
    vpc_network = ipaddress.ip_network(vpc_cidr)

    # /16 VPC를 /18 단위로 나눔 (AZ당 하나)
    # 각 /18은 16,384개 IP 제공
    az_blocks = list(vpc_network.subnets(new_prefix=18))[:azs_count]

    subnets = {}
    for idx, az_block in enumerate(az_blocks):
        az_name = f"az-{idx+1}"
        # 각 AZ를 다시 /24로 나눔 (서브넷당 256개 IP)
        az_subnets = list(az_block.subnets(new_prefix=24))

        subnets[az_name] = {
            'public': str(az_subnets[0]),      # 첫 번째 /24
            'private_app': str(az_subnets[1]), # 두 번째 /24
            'private_db': str(az_subnets[2]),  # 세 번째 /24
            # 나머지는 미래 확장용으로 예약
        }

    return subnets

# 실제 사용 예시
vpc_plan = plan_vpc_cidr('10.0.0.0/16', azs_count=3)
for az, subnets in vpc_plan.items():
    print(f"\n{az}:")
    for subnet_type, cidr in subnets.items():
        print(f"  {subnet_type}: {cidr}")

박시니어 씨가 화이트보드에 큰 네모를 그렸습니다. "이게 10.0.0.0/16 VPC라고 생각해봅시다." 김개발 씨가 고개를 갸우뚱했습니다.

"왜 하필 /16이에요?" CIDR 표기법부터 이해해봅시다. 쉽게 비유하자면, CIDR은 마치 아파트 주소 체계와 같습니다.

"서울시 강남구"는 넓은 지역이고, "서울시 강남구 역삼동"은 더 좁은 지역이죠. "서울시 강남구 역삼동 123번지"는 가장 구체적입니다.

IP 주소도 마찬가지입니다. 10.0.0.0/16은 넓은 범위를, 10.0.1.0/24는 그 안의 작은 구역을 나타냅니다.

/16이 무슨 뜻일까요? 박시니어 씨가 설명했습니다. "IP 주소는 32비트예요.

/16은 앞의 16비트가 네트워크 주소라는 뜻입니다." 나머지 16비트가 호스트 주소가 되므로, 2의 16승 = 65,536개의 IP 주소를 사용할 수 있습니다. "하지만 AWS는 각 서브넷에서 5개를 예약해요.

실제로는 조금 적습니다." CIDR 계획 없이 마구잡이로 만들면 어떻게 될까요? 박시니어 씨의 전 직장에서 일어난 일입니다.

처음 VPC를 만들 때 "일단 /24면 충분하겠지"라고 생각했습니다. 서비스가 성공하면서 서버가 급격히 늘어났습니다.

IP 주소가 부족해졌습니다. VPC CIDR을 확장하려 했지만, 겹치지 않는 범위를 찾기가 어려웠습니다.

결국 새 VPC를 만들고 VPC 피어링으로 연결하는 복잡한 구조가 되었습니다. 바로 이런 문제를 방지하기 위해 체계적인 CIDR 계획이 필요합니다.

첫 번째 원칙은 넉넉하게 시작하는 것입니다. VPC는 /16으로 시작하는 것이 일반적입니다.

10.0.0.0/16이나 172.16.0.0/16을 많이 사용합니다. "너무 큰 거 아니에요?"라고 김개발 씨가 물었습니다.

"IP 주소는 공짜예요. 나중에 모자라는 것보다 처음에 넉넉한 게 낫습니다." 두 번째 원칙은 계층적으로 분할하는 것입니다.

/16 VPC를 바로 /24 서브넷으로 나누지 않습니다. 먼저 /18로 나눠서 각 AZ에 할당합니다.

그 다음 각 /18을 다시 /24로 나눠서 퍼블릭, 프라이빗 앱, 프라이빗 DB 서브넷으로 만듭니다. 이렇게 하면 나중에 확장할 여지가 남습니다.

세 번째 원칙은 예약 공간을 남기는 것입니다. 김개발 씨가 물었습니다.

"모든 공간을 다 할당하면 안 되나요?" 박시니어 씨가 답했습니다. "미래를 위해 여유를 둬야 해요.

나중에 Kubernetes 클러스터를 추가하거나, 새로운 계층이 필요할 수 있습니다." 보통 전체 공간의 30-40%는 미래를 위해 예약해둡니다. 위의 코드를 자세히 분석해봅시다.

먼저 Python의 ipaddress 모듈을 사용합니다. 이 모듈은 CIDR 계산을 쉽게 해줍니다.

ip_network 함수로 VPC CIDR을 파싱합니다. 그 다음 subnets(new_prefix=18) 함수로 /16을 여러 개의 /18로 나눕니다.

각 /18은 16,384개의 IP를 제공하며, 하나의 AZ에 할당됩니다. 각 AZ 블록을 다시 /24로 나눕니다.

new_prefix=24는 256개 IP를 가진 서브넷을 만듭니다. 첫 번째는 퍼블릭 서브넷, 두 번째는 프라이빗 애플리케이션 서브넷, 세 번째는 프라이빗 DB 서브넷으로 사용합니다.

나머지 서브넷들은 할당하지 않고 남겨둡니다. 이것이 미래 확장을 위한 예약 공간입니다.

출력 결과를 보면 체계적인 구조를 알 수 있습니다. AZ-1은 10.0.0.0/24, 10.0.1.0/24, 10.0.2.0/24를 사용합니다.

AZ-2는 10.0.64.0/24로 시작합니다. 완전히 겹치지 않는 독립된 공간입니다.

이런 구조 덕분에 나중에 서브넷을 추가해도 충돌이 없습니다. 실제 현업에서는 어떻게 활용할까요?

대규모 서비스를 보면 더 복잡한 계획을 세웁니다. 예를 들어 개발, 스테이징, 운영 환경을 각각 다른 VPC로 분리합니다.

10.0.0.0/16은 개발, 10.1.0.0/16은 스테이징, 10.2.0.0/16은 운영용으로 사용합니다. VPC 피어링이나 Transit Gateway로 연결하면 환경 간 통신도 가능합니다.

하지만 주의할 점이 있습니다. 초보 개발자들이 흔히 하는 실수는 RFC 1918 프라이빗 주소 범위를 벗어나는 것입니다.

공인 IP 주소 범위를 VPC에 사용하면 안 됩니다. 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16만 사용해야 합니다.

다른 주소를 사용하면 인터넷 라우팅에 문제가 생길 수 있습니다. 또 다른 실수는 회사 네트워크와 겹치는 범위를 사용하는 것입니다.

김개발 씨가 물었습니다. "회사 사무실 네트워크가 10.0.0.0/16인데, VPC도 같은 주소를 쓰면 어떻게 되나요?" 박시니어 씨가 답했습니다.

"VPN이나 Direct Connect로 연결할 때 문제가 생겨요. IP 충돌로 통신이 안 됩니다." 사전에 사내 네트워크팀과 조율해서 겹치지 않는 범위를 선택해야 합니다.

/24가 항상 정답은 아닙니다. 서브넷 크기는 용도에 따라 달라져야 합니다. Lambda가 많이 사용되는 서브넷은 /22나 /21로 크게 만들어야 합니다.

Lambda는 ENI를 많이 소비하기 때문입니다. 반면 NAT 게이트웨이만 있는 서브넷은 /28로 작게 만들어도 충분합니다.

도구를 활용하는 것도 좋습니다. 온라인 CIDR 계산기를 사용하면 실수를 줄일 수 있습니다.

AWS VPC Console도 시각적으로 CIDR을 보여줍니다. 박시니어 씨가 덧붙였습니다.

"Terraform이나 CloudFormation을 사용하면 계산을 자동화할 수 있어요. cidrsubnet 함수가 유용합니다." 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 CIDR 계산기를 열어 직접 연습해보았습니다. "이제 /16과 /24의 차이를 알겠어요!" CIDR 블록을 체계적으로 계획하면 확장 가능하고 관리하기 쉬운 네트워크를 만들 수 있습니다.

여러분도 오늘 배운 내용을 실제 프로젝트 설계에 적용해 보세요.

실전 팁

💡 - VPC는 /16으로 시작하되, 환경별로 다른 범위를 사용하세요 (개발: 10.0.x.x, 운영: 10.1.x.x)

전체 IP 공간의 30-40%는 미래 확장을 위해 예약해두세요
온프레미스 네트워크와 겹치지 않도록 사전에 IP 계획을 조율하세요

6. 서브넷 라우팅

CIDR 계획까지 마친 김개발 씨가 실제로 서버를 띄워봤습니다. 그런데 통신이 안 됩니다.

"서브넷도 만들고 게이트웨이도 만들었는데 왜 안 되죠?" 박시니어 씨가 로그를 보며 말했습니다. "라우팅 테이블을 확인해보세요."

서브넷 라우팅은 네트워크 트래픽이 어디로 가야 할지 결정하는 규칙입니다. 마치 도로의 이정표처럼, 패킷이 목적지까지 가는 경로를 안내합니다.

라우팅 테이블로 퍼블릭과 프라이빗을 구분하며, 잘못 설정하면 통신이 완전히 차단됩니다.

다음 코드를 살펴봅시다.

import boto3

ec2 = boto3.resource('ec2')
ec2_client = boto3.client('ec2')
vpc = ec2.Vpc('vpc-xxxxx')

# 라우팅 테이블 분석 함수
def analyze_route_table(route_table_id):
    """라우팅 테이블의 모든 경로 출력"""
    rt = ec2.RouteTable(route_table_id)

    print(f"\n라우팅 테이블: {route_table_id}")
    print("-" * 60)

    for route in rt.routes:
        destination = route.destination_cidr_block or "N/A"

        # 목적지 종류 파악
        if route.gateway_id and route.gateway_id.startswith('igw-'):
            target = f"인터넷 게이트웨이 ({route.gateway_id})"
        elif route.nat_gateway_id:
            target = f"NAT 게이트웨이 ({route.nat_gateway_id})"
        elif route.gateway_id == 'local':
            target = "VPC 로컬"
        else:
            target = "기타"

        print(f"  {destination:20} -> {target}")

    # 연결된 서브넷 확인
    associated = [assoc.subnet_id for assoc in rt.associations if assoc.subnet_id]
    print(f"\n연결된 서브넷: {', '.join(associated) if associated else '없음'}")

# 실제 사용
analyze_route_table('rtb-xxxxx')

김개발 씨는 답답했습니다. 설정을 다 했는데 왜 안 되는 걸까요?

박시니어 씨가 AWS 콘솔을 열어 라우팅 테이블을 보여주었습니다. "여기를 보세요.

라우팅 경로가 없네요." 라우팅 테이블이란 무엇일까요? 쉽게 비유하자면, 라우팅 테이블은 마치 택배 회사의 배송 규칙과 같습니다.

"서울로 가는 물건은 A 차량", "부산으로 가는 물건은 B 차량"처럼 목적지에 따라 경로를 정합니다. 네트워크 패킷도 마찬가지입니다.

IP 주소를 보고 인터넷 게이트웨이로 보낼지, NAT 게이트웨이로 보낼지 결정합니다. 라우팅 설정이 없으면 어떻게 될까요?

박시니어 씨의 후배인 정초보 씨의 경험담입니다. 서브넷을 만들고 EC2를 띄웠는데 인터넷이 안 됐습니다.

ping 8.8.8.8도 실패했습니다. 라우팅 테이블을 확인해보니 기본 경로만 있었습니다.

인터넷 게이트웨이로 가는 경로를 추가하지 않았던 것입니다. 간단한 설정 하나를 놓쳐서 몇 시간을 허비했습니다.

바로 이런 문제를 방지하기 위해 체계적인 라우팅 설계가 필요합니다. 라우팅의 첫 번째 원칙은 명시적 경로 설정입니다.

모든 서브넷은 반드시 라우팅 테이블과 연결되어야 합니다. 연결하지 않으면 기본 라우팅 테이블을 사용하는데, 이는 예측 불가능합니다.

퍼블릭과 프라이빗을 분리하려면 각각 별도의 라우팅 테이블을 만들어야 합니다. 두 번째 원칙은 최소 권한 원칙입니다.

꼭 필요한 경로만 추가합니다. "일단 모든 트래픽을 열어놓고 나중에 좁히자"는 위험한 생각입니다.

처음부터 필요한 경로만 명시적으로 추가해야 합니다. 박시니어 씨가 강조했습니다.

"보안은 처음부터 강하게, 나중에 완화하는 게 안전해요." 세 번째 원칙은 대칭적 라우팅입니다. 김개발 씨가 물었습니다.

"대칭적이란 뭐예요?" 박시니어 씨가 설명했습니다. "요청이 A 경로로 갔으면 응답도 A 경로로 와야 해요." 비대칭 라우팅은 방화벽이나 보안 그룹에서 차단될 수 있습니다.

특히 stateful 방화벽은 같은 경로를 기대합니다. 위의 코드를 단계별로 살펴봅시다.

analyze_route_table 함수는 라우팅 테이블을 분석하는 도구입니다. 실무에서 매우 유용합니다.

RouteTable 객체의 routes 속성으로 모든 경로를 가져옵니다. 각 경로는 목적지(destination_cidr_block)와 타겟을 가집니다.

gateway_id가 igw-로 시작하면 인터넷 게이트웨이입니다. 이것은 퍼블릭 서브넷의 표시입니다.

0.0.0.0/0 -> igw-xxxxx 경로가 있으면 모든 외부 트래픽이 인터넷으로 나갑니다. nat_gateway_id가 있으면 NAT 게이트웨이입니다.

프라이빗 서브넷의 특징이죠. gateway_id == 'local'은 VPC 내부 통신을 의미합니다.

local 경로는 자동으로 생성됩니다. VPC CIDR 범위 내의 모든 트래픽은 VPC 안에서 처리됩니다.

예를 들어 10.0.0.0/16 VPC라면 10.0.0.0/16 -> local 경로가 자동으로 있습니다. 이 경로는 삭제할 수 없고, 수정할 수도 없습니다.

VPC의 기본 동작입니다. associations 속성으로 어느 서브넷과 연결되었는지 확인합니다.

하나의 라우팅 테이블을 여러 서브넷에 연결할 수 있습니다. 예를 들어 3개 AZ의 퍼블릭 서브넷이 모두 같은 라우팅 테이블을 공유할 수 있습니다.

하지만 프라이빗 서브넷은 AZ마다 다른 라우팅 테이블을 사용해야 합니다. 각 AZ의 NAT 게이트웨이가 다르기 때문입니다.

실제 현업에서는 어떻게 활용할까요? 복잡한 아키텍처를 보면 라우팅이 더 정교합니다.

예를 들어 VPC 피어링이 있으면 피어 VPC로 가는 경로가 추가됩니다. Transit Gateway를 사용하면 여러 VPC와 온프레미스로 가는 경로가 하나의 테이블에 있습니다.

VPN 연결이 있으면 Virtual Private Gateway로 가는 경로도 있죠. 하지만 주의할 점이 있습니다.

초보 개발자들이 흔히 하는 실수는 라우팅 우선순위를 모르는 것입니다. 여러 경로가 매칭될 때 가장 구체적인 경로가 선택됩니다.

예를 들어 10.0.1.0/24와 10.0.0.0/16이 모두 있으면 10.0.1.0/24가 우선입니다. 더 좁은 범위가 더 구체적이기 때문입니다.

또 다른 실수는 블랙홀 경로를 만드는 것입니다. 김개발 씨가 물었습니다.

"블랙홀이요?" 박시니어 씨가 설명했습니다. "존재하지 않는 타겟을 가리키는 경로예요.

NAT 게이트웨이를 삭제했는데 라우팅 경로는 남아있으면 트래픽이 사라집니다." AWS 콘솔에서 경로 상태를 확인할 수 있습니다. "blackhole" 상태면 즉시 수정해야 합니다.

경로 전파도 이해해야 합니다. Virtual Private Gateway나 Transit Gateway는 경로를 자동으로 전파할 수 있습니다.

"Route Propagation" 옵션을 켜면 BGP로 학습한 경로가 자동으로 추가됩니다. 편리하지만, 예상치 못한 경로가 생길 수 있으니 주의해야 합니다.

프로덕션 환경에서는 수동으로 관리하는 것이 더 안전합니다. 라우팅 로그를 활용하는 것도 좋습니다.

VPC Flow Logs를 활성화하면 모든 트래픽을 기록할 수 있습니다. 라우팅 문제를 디버깅할 때 매우 유용합니다.

"이 패킷이 왜 안 갔을까?" 싶을 때 Flow Logs를 보면 답이 나옵니다. CloudWatch Logs Insights로 쿼리하면 패턴도 찾을 수 있습니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 도움으로 라우팅 테이블을 수정한 김개발 씨는 드디어 통신이 되는 것을 확인했습니다.

"오! 핑이 가네요!" 서브넷 라우팅을 제대로 이해하면 복잡한 네트워크도 설계하고 문제도 해결할 수 있습니다.

여러분도 오늘 배운 내용을 실제 트러블슈팅에 활용해 보세요.

실전 팁

💡 - 라우팅 테이블은 퍼블릭/프라이빗/DB용으로 분리하여 관리하세요

VPC Flow Logs를 활성화하여 라우팅 문제를 쉽게 디버깅하세요
경로 변경 전 반드시 현재 상태를 문서화하고, 변경 후 테스트를 거쳐야 합니다

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#AWS#VPC#Subnets#CIDR#NetworkArchitecture

VPC 아키텍처 설계 완벽 가이드

# VPC 아키텍처 설계 완벽 가이드 AWS VPC 아키텍처 설계의 핵심 원칙부터 실전 설계 패턴까지, 초급 개발자를 위한 완벽한 가이드입니다. 멀티 AZ 구성부터 서브넷 설계, CIDR 블록 계획까지 실무에 바로 적용할 수 있는 모든 것을 담았습니다. --- ## 목차 1. [VPC_설계_원칙](#vpc-설계-원칙) 2. [멀티_AZ_아키텍처](#멀티-az-아키텍처) 3. [퍼블릭_서브넷_설계](#퍼블릭-서브넷-설계) 4. [프라이빗_서브넷_설계](#프라이빗-서브넷-설계) 5. [CIDR_블록_계획](#cidr-블록-계획) 6. [서브넷_라우팅](#서브넷-라우팅) --- ## 1. VPC_설계_원칙 어느 날 김개발 씨가 첫 AWS 프로젝트를 맡게 되었습니다. 팀장님이 말했습니다. "우리 서비스를 위한 VPC를 설계해 보세요." 김개발 씨는 당황했습니다. VPC가 뭔지는 알겠는데, 어떻게 설계해야 할지 막막했습니다. **VPC 설계 원칙**은 안전하고 확장 가능한 네트워크 인프라를 만들기 위한 기본 지침입니다. 마치 건물을 지을 때 설계도를 그리는 것처럼, 클라우드 네트워크도 체계적인 계획이 필요합니다. 올바른 설계 원칙을 따르면 보안성과 확장성을 동시에 확보할 수 있습니다. 다음 코드를 살펴봅시다. ```python import boto3 # VPC 생성 - 설계 원칙에 따른 기본 구조 ec2 = boto3.resource('ec2') # 원칙 1: 충분한 IP 주소 공간 확보 (/16 권장) vpc = ec2.create_vpc(CidrBlock='10.0.0.0/16') vpc.create_tags(Tags=[{"Key": "Name", "Value": "production-vpc"}]) # 원칙 2: DNS 지원 활성화 vpc.modify_attribute(EnableDnsSupport={'Value': True}) vpc.modify_attribute(EnableDnsHostnames={'Value': True}) # 원칙 3: 적절한 태깅으로 리소스 관리 print(f"VPC 생성 완료: {vpc.id}") ``` 김개발 씨는 선배 개발자인 박시니어 씨에게 도움을 청했습니다. "VPC 설계가 처음이라 어떻게 시작해야 할지 모르겠어요." 박시니어 씨는 화이트보드 앞으로 다가가며 말했습니다. "좋아요, 기초부터 차근차근 알려드릴게요." **VPC**란 무엇일까요? 쉽게 비유하자면, VPC는 마치 아파트 단지와 같습니다. 아파트 단지 안에는 여러 동이 있고, 각 동마다 보안 시스템과 출입구가 있습니다. 단지 밖과 연결되는 정문도 있죠. VPC도 마찬가지입니다. AWS 클라우드 안에 여러분만의 독립된 네트워크 공간을 만드는 것입니다. 설계를 시작하기 전에 왜 체계적인 계획이 필요한지 이해해야 합니다. VPC 설계가 제대로 되지 않으면 어떤 일이 벌어질까요? 김개발 씨의 선배인 이실수 씨의 경험담을 들어봅시다. 이실수 씨는 급하게 프로젝트를 진행하느라 VPC를 대충 만들었습니다. IP 주소 공간을 너무 작게 잡아서 나중에 서버를 추가할 수 없었습니다. 결국 새로운 VPC를 만들고 모든 리소스를 이전하는 데 일주일이 걸렸습니다. 이런 문제를 방지하기 위해 몇 가지 핵심 원칙을 지켜야 합니다. **첫 번째 원칙**은 충분한 IP 주소 공간을 확보하는 것입니다. 박시니어 씨가 설명합니다. "처음에는 서버가 몇 대 안 될 것 같아도, 서비스가 성장하면 수백 대가 필요할 수 있어요." 일반적으로 **/16 CIDR 블록**을 권장합니다. 이는 약 65,000개의 IP 주소를 제공합니다. "너무 많은 거 아니에요?"라고 김개발 씨가 물었습니다. "아니요, IP 주소는 공짜예요. 넉넉하게 잡는 게 나중에 후회하지 않습니다." **두 번째 원칙**은 DNS 지원을 반드시 활성화하는 것입니다. DNS가 없으면 어떻게 될까요? IP 주소로만 통신해야 합니다. 데이터베이스 서버의 IP가 바뀌면 모든 애플리케이션 코드를 수정해야 하죠. DNS를 활성화하면 **도메인 이름**으로 통신할 수 있습니다. 훨씬 편리하고 유지보수하기 쉽습니다. **세 번째 원칙**은 처음부터 리소스를 체계적으로 관리하는 것입니다. 위의 코드를 살펴보겠습니다. 먼저 boto3 라이브러리를 사용해 AWS와 통신합니다. `create_vpc` 함수로 VPC를 생성하는데, `CidrBlock='10.0.0.0/16'`이 핵심입니다. 이것이 우리가 사용할 IP 주소 범위입니다. 그 다음 `create_tags`로 이름을 지정합니다. 태그는 나중에 수십 개의 VPC 중에서 원하는 것을 찾을 때 매우 중요합니다. `modify_attribute` 함수로 DNS 관련 설정을 활성화합니다. `EnableDnsSupport`는 AWS가 제공하는 DNS 서버를 사용하겠다는 의미입니다. `EnableDnsHostnames`는 EC2 인스턴스에 자동으로 DNS 이름을 부여하는 기능입니다. 이 두 가지를 모두 켜두면 나중에 편리합니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 쇼핑몰 서비스를 개발한다고 가정해봅시다. 처음에는 웹 서버 2대, 데이터베이스 1대로 시작합니다. 하지만 블랙프라이데이 세일 기간에는 웹 서버 50대, 캐시 서버 10대가 필요할 수 있습니다. 충분한 IP 공간을 확보해두면 이런 확장이 자연스럽게 가능합니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수는 **CIDR 블록을 너무 작게 잡는 것**입니다. "/24나 /25면 충분하겠지"라고 생각하지만, 나중에 후회하게 됩니다. VPC의 CIDR 블록은 생성 후 수정할 수 없습니다. 추가는 가능하지만 복잡합니다. 처음부터 넉넉하게 잡는 것이 정답입니다. 또 다른 실수는 **여러 환경을 하나의 VPC에 섞는 것**입니다. 개발 환경, 스테이징 환경, 운영 환경은 반드시 분리해야 합니다. 김개발 씨가 물었습니다. "왜 꼭 분리해야 하나요?" 박시니어 씨가 답했습니다. "개발 환경에서 실수로 운영 데이터베이스를 건드리면 큰 사고가 나요. 네트워크 레벨에서 아예 분리하는 게 안전합니다." 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 화이트보드에 적힌 설계 원칙을 노트에 정리했습니다. "이제 어떻게 시작해야 할지 알겠어요!" VPC 설계 원칙을 제대로 이해하면 안정적이고 확장 가능한 인프라를 구축할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요. **실전 팁** 💡 - CIDR 블록은 /16으로 시작하되, 나중에 필요하면 추가 블록을 연결할 수 있습니다 - 환경별로 VPC를 분리하고, 명확한 네이밍 규칙을 정하세요 (예: dev-vpc, staging-vpc, prod-vpc) - 태그를 체계적으로 관리하면 비용 추적과 리소스 관리가 훨씬 쉬워집니다 --- ## 2. 멀티_AZ_아키텍처 VPC 기본 설계를 마친 김개발 씨에게 팀장님이 새로운 요구사항을 주었습니다. "고가용성을 확보해야 해요. 한 데이터센터에 문제가 생겨도 서비스는 계속 돌아가야 합니다." 김개발 씨는 고개를 갸우뚱했습니다. 어떻게 그게 가능할까요? **멀티 AZ 아키텍처**는 여러 가용 영역에 리소스를 분산 배치하여 장애에 대비하는 설계 패턴입니다. 마치 중요한 서류를 여러 곳에 백업해두는 것처럼, 서버도 여러 위치에 분산시켜 안정성을 높입니다. AWS의 가장 기본적이면서도 강력한 고가용성 전략입니다. 다음 코드를 살펴봅시다. ```python import boto3 ec2 = boto3.resource('ec2') vpc = ec2.Vpc('vpc-xxxxx') # 기존 VPC ID # 각 AZ에 서브넷 생성 - 고가용성의 핵심 availability_zones = ['ap-northeast-2a', 'ap-northeast-2b', 'ap-northeast-2c'] subnets = [] for idx, az in enumerate(availability_zones): # 각 AZ마다 /24 서브넷 생성 (256개 IP) cidr = f'10.0.{idx}.0/24' subnet = vpc.create_subnet(CidrBlock=cidr, AvailabilityZone=az) subnet.create_tags(Tags=[{"Key": "Name", "Value": f"public-{az}"}]) subnets.append(subnet) print(f"{az}에 서브넷 생성: {cidr}") ``` 박시니어 씨가 김개발 씨를 회의실로 데려갔습니다. "고가용성 이야기를 해볼까요?" 박시니어 씨는 노트북을 열어 AWS 콘솔을 보여주었습니다. "서울 리전에는 4개의 가용 영역이 있어요. 각각이 독립된 데이터센터입니다." **가용 영역**이란 무엇일까요? 쉽게 비유하자면, 가용 영역은 마치 다른 건물에 있는 은행 지점과 같습니다. 강남 지점에 불이 나도 서초 지점은 정상 영업합니다. 고객은 다른 지점을 이용하면 됩니다. AWS도 마찬가지입니다. 하나의 데이터센터에 문제가 생겨도 다른 데이터센터는 정상 작동합니다. 멀티 AZ가 없던 시절에는 어땠을까요? 박시니어 씨가 옛날 이야기를 꺼냈습니다. "제가 신입일 때 겪은 일이에요. 모든 서버를 하나의 데이터센터에 두었는데, 그곳에 정전이 발생했습니다." 서비스가 완전히 중단되었습니다. 고객들은 화를 냈고, 회사는 큰 손실을 입었습니다. 그날 밤 전 직원이 사무실에 모여 긴급 대응을 했던 기억이 생생합니다. 바로 이런 문제를 해결하기 위해 **멀티 AZ 아키텍처**가 등장했습니다. 멀티 AZ를 사용하면 **자동 장애 조치**가 가능해집니다. 하나의 AZ에 문제가 생기면 트래픽이 자동으로 다른 AZ로 전환됩니다. 사용자는 아무것도 모릅니다. 서비스는 계속 정상 작동하죠. 또한 **계획된 유지보수**도 쉬워집니다. A 영역을 업데이트하는 동안 B 영역이 트래픽을 처리합니다. **세 번째 장점**은 성능 향상입니다. 사용자의 요청을 가장 가까운 AZ에서 처리하면 응답 속도가 빨라집니다. 로드 밸런서가 자동으로 최적의 AZ를 선택해줍니다. 박시니어 씨가 덧붙였습니다. "특히 데이터베이스는 반드시 멀티 AZ로 구성해야 해요." 위의 코드를 단계별로 살펴보겠습니다. 먼저 서울 리전의 가용 영역 목록을 정의합니다. `ap-northeast-2a`, `2b`, `2c`는 각각 독립된 데이터센터입니다. 그 다음 for 루프로 각 AZ마다 서브넷을 생성합니다. 중요한 점은 **CIDR 블록을 겹치지 않게** 나누는 것입니다. 첫 번째 AZ는 `10.0.0.0/24`, 두 번째는 `10.0.1.0/24`를 사용합니다. `create_subnet` 함수의 `AvailabilityZone` 파라미터가 핵심입니다. 이 파라미터로 서브넷이 어느 AZ에 생성될지 결정됩니다. 명시적으로 지정하지 않으면 AWS가 임의로 선택하는데, 이는 좋지 않습니다. 항상 명시적으로 지정해야 나중에 관리하기 쉽습니다. 태그에 AZ 이름을 포함시키는 것도 모범 사례입니다. 실제 현업에서는 어떻게 활용할까요? 대형 이커머스 사이트를 예로 들어봅시다. 웹 서버는 3개 AZ에 분산 배치됩니다. Application Load Balancer가 트래픽을 균등하게 분배하죠. 데이터베이스는 RDS Multi-AZ로 구성합니다. 마스터 DB가 한 AZ에 있고, 스탠바이 DB가 다른 AZ에 있습니다. 마스터에 문제가 생기면 자동으로 스탠바이가 승격됩니다. 하지만 주의할 점이 있습니다. 초보 개발자들이 흔히 하는 실수는 **모든 리소스를 한 AZ에 몰아넣는 것**입니다. "귀찮으니까 일단 하나에 다 만들고, 나중에 분산시키자." 하지만 나중은 오지 않습니다. 처음부터 제대로 설계하는 것이 중요합니다. 또 다른 실수는 **홀수 개의 AZ를 사용하지 않는 것**입니다. 왜 홀수일까요? 박시니어 씨가 설명합니다. "2개 AZ만 사용하면 네트워크 분할 문제가 생길 수 있어요. 3개를 사용하면 과반수 합의가 가능해서 더 안전합니다." 특히 Kafka, Elasticsearch 같은 분산 시스템은 3개 이상의 AZ를 권장합니다. **비용**도 고려해야 합니다. 김개발 씨가 물었습니다. "멀티 AZ는 비용이 더 들지 않나요?" 맞습니다. 서버가 여러 대 필요하니 비용이 증가합니다. 하지만 박시니어 씨는 반문했습니다. "서비스 중단으로 인한 손실이 더 클까요, 아니면 멀티 AZ 비용이 더 클까요?" 대부분의 경우 답은 명확합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 이해했습니다. "아, 그래서 넷플릭스 같은 서비스는 절대 안 멈추는구나!" 멀티 AZ 아키텍처를 제대로 구현하면 99.99% 이상의 가용성을 달성할 수 있습니다. 여러분의 서비스도 멀티 AZ로 한 단계 업그레이드해 보세요. **실전 팁** 💡 - 최소 3개의 AZ를 사용하되, 서울 리전은 4개 모두 활용할 수 있습니다 - RDS, ElastiCache, EKS 등 관리형 서비스는 멀티 AZ 옵션을 반드시 활성화하세요 - 크로스 AZ 데이터 전송 비용이 발생하므로, 같은 AZ 내에서 통신하도록 최적화하세요 --- ## 3. 퍼블릭_서브넷_설계 멀티 AZ 구성을 이해한 김개발 씨가 다음 단계로 넘어갔습니다. "서브넷을 퍼블릭과 프라이빗으로 나눠야 한다는데, 무슨 차이인가요?" 박시니어 씨가 웃으며 대답했습니다. "좋은 질문이에요. 보안의 기본이거든요." **퍼블릭 서브넷**은 인터넷과 직접 통신할 수 있는 서브넷입니다. 마치 건물의 1층 로비처럼, 외부 방문객이 접근할 수 있는 공간입니다. 웹 서버, 로드 밸런서 등 외부와 통신해야 하는 리소스를 배치합니다. 인터넷 게이트웨이와 라우팅 테이블로 연결됩니다. 다음 코드를 살펴봅시다. ```python import boto3 ec2 = boto3.resource('ec2') ec2_client = boto3.client('ec2') vpc = ec2.Vpc('vpc-xxxxx') # 1. 인터넷 게이트웨이 생성 - 외부 통신의 관문 igw = ec2_client.create_internet_gateway() igw_id = igw['InternetGateway']['InternetGatewayId'] vpc.attach_internet_gateway(InternetGatewayId=igw_id) # 2. 퍼블릭 라우팅 테이블 생성 route_table = vpc.create_route_table() route_table.create_tags(Tags=[{"Key": "Name", "Value": "public-rt"}]) # 3. 인터넷으로 가는 기본 경로 추가 (핵심!) route_table.create_route(DestinationCidrBlock='0.0.0.0/0', GatewayId=igw_id) # 4. 서브넷에 라우팅 테이블 연결 subnet = ec2.Subnet('subnet-xxxxx') route_table.associate_with_subnet(SubnetId=subnet.id) print(f"퍼블릭 서브넷 구성 완료: {subnet.id}") ``` 박시니어 씨가 화이트보드에 그림을 그리기 시작했습니다. "VPC는 기본적으로 외부와 완전히 격리된 공간이에요. 마치 울타리로 둘러싸인 정원 같죠." 김개발 씨가 끄덕였습니다. "그럼 외부와 어떻게 통신하나요?" **퍼블릭 서브넷**의 개념을 이해해봅시다. 쉽게 비유하자면, 퍼블릭 서브넷은 마치 호텔의 프런트 데스크와 같습니다. 외부 손님이 가장 먼저 만나는 곳이죠. 객실(프라이빗 서브넷)에는 아무나 들어갈 수 없지만, 프런트는 누구나 접근할 수 있습니다. 웹 서비스도 마찬가지입니다. 사용자의 요청을 받는 웹 서버는 퍼블릭 서브넷에 둡니다. 퍼블릭 서브넷이 없으면 어떻게 될까요? 박시니어 씨의 후배인 최신입 씨의 실수담을 들어봅시다. 최신입 씨는 모든 서버를 프라이빗 서브넷에 배치했습니다. 웹사이트를 열었는데 아무것도 나오지 않았습니다. 당연합니다. 외부에서 접근할 수 없으니까요. 결국 처음부터 다시 설계해야 했습니다. 바로 이런 문제를 해결하기 위해 **퍼블릭 서브넷 설계**가 필요합니다. 퍼블릭 서브넷을 만들면 **외부 트래픽을 수신**할 수 있습니다. 사용자가 브라우저에 URL을 입력하면 로드 밸런서가 요청을 받습니다. 그 다음 웹 서버가 처리하죠. 또한 **NAT 게이트웨이 배치 위치**로도 사용됩니다. 프라이빗 서브넷의 서버들이 외부와 통신하려면 NAT 게이트웨이를 거쳐야 하는데, 이것이 퍼블릭 서브넷에 있어야 합니다. **세 번째 역할**은 Bastion 호스트입니다. 관리자가 프라이빗 서브넷의 서버에 SSH로 접속하려면 점프 서버가 필요합니다. 이 Bastion 호스트를 퍼블릭 서브넷에 배치합니다. 박시니어 씨가 강조했습니다. "하지만 요즘은 AWS Systems Manager Session Manager를 사용하는 추세예요. 더 안전하거든요." 위의 코드를 자세히 살펴보겠습니다. 첫 번째 단계는 **인터넷 게이트웨이 생성**입니다. `create_internet_gateway` 함수로 IGW를 만들고, `attach_internet_gateway`로 VPC에 연결합니다. IGW는 VPC당 하나만 필요합니다. 여러 퍼블릭 서브넷이 하나의 IGW를 공유합니다. 이것이 외부 세계로 나가는 유일한 통로입니다. 두 번째 단계는 **라우팅 테이블 생성**입니다. 라우팅 테이블은 네트워크 트래픽의 경로를 정의합니다. 마치 도로의 이정표와 같죠. `create_route_table`로 새 테이블을 만듭니다. VPC에는 기본 라우팅 테이블이 있지만, 퍼블릭과 프라이빗을 분리하려면 별도로 만들어야 합니다. **세 번째 단계가 가장 중요**합니다. `create_route` 함수로 인터넷으로 가는 경로를 추가합니다. `DestinationCidrBlock='0.0.0.0/0'`은 "모든 외부 주소"를 의미합니다. `GatewayId=igw_id`는 그 경로가 인터넷 게이트웨이를 통한다는 뜻이죠. 이 한 줄이 일반 서브넷을 퍼블릭 서브넷으로 바꿔줍니다. 마지막 단계는 서브넷과 라우팅 테이블을 **연결**하는 것입니다. `associate_with_subnet` 함수로 특정 서브넷에 라우팅 규칙을 적용합니다. 하나의 라우팅 테이블을 여러 서브넷에 연결할 수 있습니다. 보통 각 AZ의 퍼블릭 서브넷들이 같은 라우팅 테이블을 공유합니다. 실제 현업에서는 어떻게 활용할까요? 전형적인 3-tier 아키텍처를 생각해봅시다. 맨 앞단의 Application Load Balancer가 퍼블릭 서브넷에 있습니다. 사용자의 HTTPS 요청을 받아서 뒷단의 웹 서버로 전달합니다. 웹 서버는 프라이빗 서브넷에 있지만, ALB가 중간에서 연결해줍니다. CloudFront를 사용한다면 더 간단합니다. 정적 컨텐츠는 CloudFront가 서빙하고, 동적 요청만 ALB로 전달됩니다. 하지만 주의할 점이 있습니다. 초보 개발자들이 흔히 하는 실수는 **데이터베이스를 퍼블릭 서브넷에 두는 것**입니다. "RDS에 접속이 안 돼서 퍼블릭으로 바꿨어요." 절대 안 됩니다. 데이터베이스는 반드시 프라이빗 서브넷에 두고, 웹 서버를 통해서만 접근해야 합니다. 외부에 직접 노출되면 보안 사고의 위험이 커집니다. 또 다른 실수는 **퍼블릭 IP 자동 할당을 안 하는 것**입니다. 김개발 씨가 물었습니다. "서브넷 설정에서 'Auto-assign Public IP'를 켜야 하나요?" 박시니어 씨가 답했습니다. "퍼블릭 서브넷이라면 반드시 켜야 해요. 안 그러면 EC2 인스턴스가 외부와 통신할 수 없습니다." 물론 Elastic IP를 수동으로 할당할 수도 있지만, 자동 할당이 편리합니다. **보안 그룹 설정**도 신경 써야 합니다. 퍼블릭 서브넷에 있다고 해서 모든 포트를 열어두면 안 됩니다. 웹 서버라면 80번(HTTP), 443번(HTTPS)만 열어둡니다. SSH(22번)는 특정 IP에서만 접근 가능하도록 제한합니다. 박시니어 씨가 덧붙였습니다. "요즘은 SSH 접근도 Systems Manager로 대체하는 추세예요." 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 노트에 정리했습니다. "퍼블릭 서브넷 = IGW + 라우팅 테이블 + 0.0.0.0/0 경로!" 퍼블릭 서브넷을 제대로 설계하면 안전하면서도 외부 접근이 가능한 인프라를 만들 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요. **실전 팁** 💡 - 퍼블릭 서브넷은 각 AZ마다 하나씩 만들되, CIDR 블록 크기는 /24면 충분합니다 - Auto-assign Public IP 옵션을 활성화하여 인스턴스가 자동으로 공인 IP를 받도록 설정하세요 - 민감한 리소스(DB, 애플리케이션 서버)는 절대 퍼블릭 서브넷에 두지 마세요 --- ## 4. 프라이빗_서브넷_설계 퍼블릭 서브넷을 이해한 김개발 씨가 다음 질문을 던졌습니다. "그럼 프라이빗 서브넷은 외부와 아예 통신을 못 하나요? 패키지 업데이트는 어떻게 하죠?" 박시니어 씨가 미소 지으며 답했습니다. "바로 NAT 게이트웨이가 그 해답이에요." **프라이빗 서브넷**은 외부에서 직접 접근할 수 없는 안전한 서브넷입니다. 마치 건물의 내부 사무실처럼, 승인된 사람만 들어갈 수 있습니다. 데이터베이스, 애플리케이션 서버 등 민감한 리소스를 배치합니다. NAT 게이트웨이를 통해 외부로 나가는 통신만 가능합니다. 다음 코드를 살펴봅시다. ```python import boto3 ec2 = boto3.resource('ec2') ec2_client = boto3.client('ec2') # 1. NAT 게이트웨이용 Elastic IP 할당 eip = ec2_client.allocate_address(Domain='vpc') eip_id = eip['AllocationId'] # 2. 퍼블릭 서브넷에 NAT 게이트웨이 생성 (중요!) public_subnet = ec2.Subnet('subnet-public-xxxxx') nat_gw = ec2_client.create_nat_gateway( SubnetId=public_subnet.id, AllocationId=eip_id ) nat_gw_id = nat_gw['NatGateway']['NatGatewayId'] # 3. 프라이빗 라우팅 테이블 생성 vpc = ec2.Vpc('vpc-xxxxx') private_rt = vpc.create_route_table() private_rt.create_tags(Tags=[{"Key": "Name", "Value": "private-rt"}]) # 4. NAT 게이트웨이로 가는 기본 경로 추가 private_rt.create_route(DestinationCidrBlock='0.0.0.0/0', NatGatewayId=nat_gw_id) # 5. 프라이빗 서브넷에 연결 private_subnet = ec2.Subnet('subnet-private-xxxxx') private_rt.associate_with_subnet(SubnetId=private_subnet.id) print(f"프라이빗 서브넷 구성 완료: {private_subnet.id}") ``` 박시니어 씨가 보안의 중요성을 강조하며 이야기를 시작했습니다. "작년에 큰 보안 사고가 있었어요. 한 스타트업이 데이터베이스를 퍼블릭 서브넷에 뒀다가 해킹당했죠." 김개발 씨는 긴장했습니다. "어떻게 방지할 수 있나요?" **프라이빗 서브넷**이란 무엇일까요? 쉽게 비유하자면, 프라이빗 서브넷은 마치 은행 금고와 같습니다. 외부에서는 절대 직접 접근할 수 없습니다. 승인된 직원만 특정 경로를 통해 들어갈 수 있죠. 데이터베이스, 애플리케이션 서버, 캐시 서버 등 중요한 자산을 여기에 보관합니다. 외부 공격자가 직접 접근할 방법이 없으니 훨씬 안전합니다. 프라이빗 서브넷 없이 모든 것을 퍼블릭에 두면 어떻게 될까요? 박시니어 씨의 친구 회사에서 일어난 일입니다. 개발 편의성을 위해 모든 서버를 퍼블릭 서브넷에 배치했습니다. RDS도 퍼블릭 엑세스를 켰습니다. 어느 날 갑자기 데이터베이스가 이상해졌습니다. 로그를 확인해보니 중국 IP에서 무차별 대입 공격을 시도한 흔적이 있었습니다. 다행히 강력한 비밀번호 덕분에 뚫리진 않았지만, 식은땀이 났습니다. 바로 이런 위험을 방지하기 위해 **프라이빗 서브넷**을 사용합니다. 프라이빗 서브넷의 첫 번째 장점은 **외부 공격으로부터 차단**된다는 점입니다. 인터넷에서 직접 접근할 수 없으니, 해커가 데이터베이스를 공격하려면 먼저 웹 서버를 뚫어야 합니다. 방어선이 하나 더 생기는 셈이죠. 두 번째 장점은 **네트워크 격리**입니다. 각 계층을 분리하면 보안 정책을 더 세밀하게 관리할 수 있습니다. **세 번째 장점**은 규정 준수입니다. 김개발 씨가 물었습니다. "왜 규정이 중요한가요?" 박시니어 씨가 설명했습니다. "금융이나 의료 서비스는 개인정보보호법을 지켜야 해요. 민감한 데이터는 반드시 외부 접근이 차단된 곳에 보관해야 합니다." 프라이빗 서브넷이 바로 그런 요구사항을 만족시킵니다. 하지만 문제가 하나 있습니다. 프라이빗 서브넷의 서버도 외부와 통신해야 할 때가 있습니다. 소프트웨어 업데이트, API 호출, 이메일 발송 등이죠. 그럼 어떻게 해야 할까요? 바로 **NAT 게이트웨이**가 해답입니다. 위의 코드를 단계별로 분석해봅시다. 첫 번째 단계는 **Elastic IP 할당**입니다. NAT 게이트웨이는 고정 IP 주소가 필요합니다. `allocate_address` 함수로 EIP를 받습니다. 이 IP는 프라이빗 서브넷의 서버들이 외부와 통신할 때 사용하는 공인 IP입니다. 외부에서 보면 모든 요청이 이 하나의 IP에서 나오는 것처럼 보입니다. 두 번째 단계는 **NAT 게이트웨이 생성**입니다. 중요한 점은 NAT 게이트웨이를 **퍼블릭 서브넷**에 만든다는 것입니다. `SubnetId=public_subnet.id`를 주목하세요. 왜 퍼블릭일까요? NAT 게이트웨이 자체가 인터넷과 통신해야 하기 때문입니다. 프라이빗 서브넷에 두면 외부로 나갈 수 없습니다. **세 번째 단계**는 프라이빗용 라우팅 테이블을 만드는 것입니다. 퍼블릭 서브넷의 라우팅 테이블과는 다릅니다. `create_route_table`로 새로 만들고, "private-rt"라는 이름을 붙입니다. 명확한 네이밍이 나중에 관리할 때 중요합니다. 프로젝트가 커지면 라우팅 테이블이 수십 개가 될 수 있습니다. **네 번째 단계가 핵심**입니다. `create_route`로 기본 경로를 추가하는데, 목적지는 NAT 게이트웨이입니다. `DestinationCidrBlock='0.0.0.0/0'`은 "모든 외부 주소"를, `NatGatewayId=nat_gw_id`는 NAT 게이트웨이를 통해 나간다는 뜻입니다. 퍼블릭 서브넷과의 차이점은 IGW 대신 NAT를 사용한다는 것입니다. 마지막으로 프라이빗 서브넷에 라우팅 테이블을 연결합니다. `associate_with_subnet`으로 연결하면 모든 설정이 완료됩니다. 이제 프라이빗 서브넷의 EC2 인스턴스가 `yum update`나 `apt-get update`를 실행하면 NAT 게이트웨이를 통해 외부 패키지 저장소에 접근합니다. 하지만 외부에서는 절대 해당 인스턴스에 직접 접근할 수 없습니다. 실제 현업에서는 어떻게 활용할까요? 전형적인 웹 서비스 아키텍처를 봅시다. 퍼블릭 서브넷에는 ALB만 있습니다. 웹 서버(EC2 또는 ECS)는 프라이빗 서브넷에 있습니다. 데이터베이스(RDS)도 프라이빗 서브넷에 있죠. ElastiCache도 마찬가지입니다. 외부에서는 ALB만 볼 수 있고, 나머지는 모두 숨겨져 있습니다. 훨씬 안전한 구조입니다. 하지만 주의할 점이 있습니다. 초보 개발자들이 흔히 하는 실수는 **NAT 게이트웨이를 하나만 만드는 것**입니다. "비용이 아까워서 하나만 만들었어요." 문제는 고가용성입니다. 해당 AZ에 장애가 나면 다른 AZ의 프라이빗 서브넷도 외부와 통신할 수 없게 됩니다. 각 AZ마다 NAT 게이트웨이를 하나씩 만드는 것이 모범 사례입니다. 또 다른 실수는 **NAT 게이트웨이 비용을 간과하는 것**입니다. 김개발 씨가 놀라며 물었습니다. "NAT 게이트웨이가 비싸다고요?" 박시니어 씨가 답했습니다. "시간당 요금과 데이터 처리 요금이 모두 발생해요. 한 달이면 몇십 달러가 나갑니다." 대안으로 NAT 인스턴스를 사용할 수도 있지만, 관리 부담이 있습니다. 서비스 규모와 비용을 고려해서 선택해야 합니다. **VPC 엔드포인트**도 고려해야 합니다. S3나 DynamoDB처럼 AWS 서비스와 통신할 때는 VPC 엔드포인트를 사용하면 NAT 게이트웨이를 거치지 않아도 됩니다. 비용도 절감되고 속도도 빨라집니다. 박시니어 씨가 덧붙였습니다. "요즘은 PrivateLink로 다른 AWS 서비스와도 프라이빗 통신이 가능해요." 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 보안의 중요성을 깨달았습니다. "민감한 데이터는 반드시 프라이빗 서브넷에!" 프라이빗 서브넷을 제대로 설계하면 보안성과 규정 준수를 동시에 달성할 수 있습니다. 여러분의 인프라도 프라이빗 서브넷으로 한층 더 안전하게 만들어보세요. **실전 팁** 💡 - 각 AZ마다 NAT 게이트웨이를 하나씩 배치하여 고가용성을 확보하세요 - AWS 서비스 접근은 VPC 엔드포인트를 사용하여 NAT 비용을 절감하세요 - DB 서브넷 그룹은 반드시 프라이빗 서브넷으로만 구성해야 합니다 --- ## 5. CIDR_블록_계획 서브넷 설계를 배운 김개발 씨가 실제로 구현하려다 막혔습니다. "10.0.0.0/16, 10.0.1.0/24... 이 숫자들이 도대체 뭐예요?" 박시니어 씨가 웃으며 답했습니다. "아, CIDR 표기법이군요. 네트워크의 기본이에요." **CIDR 블록 계획**은 IP 주소 공간을 효율적으로 나누는 설계 기법입니다. 마치 토지를 구획 정리하듯, VPC의 IP 주소를 논리적으로 분할합니다. /16, /24 같은 서브넷 마스크로 크기를 조절하며, 미래의 확장을 고려한 설계가 필수입니다. 다음 코드를 살펴봅시다. ```python import ipaddress # CIDR 계산을 위한 도우미 함수 def plan_vpc_cidr(vpc_cidr, azs_count=3): """VPC CIDR을 여러 서브넷으로 분할""" vpc_network = ipaddress.ip_network(vpc_cidr) # /16 VPC를 /18 단위로 나눔 (AZ당 하나) # 각 /18은 16,384개 IP 제공 az_blocks = list(vpc_network.subnets(new_prefix=18))[:azs_count] subnets = {} for idx, az_block in enumerate(az_blocks): az_name = f"az-{idx+1}" # 각 AZ를 다시 /24로 나눔 (서브넷당 256개 IP) az_subnets = list(az_block.subnets(new_prefix=24)) subnets[az_name] = { 'public': str(az_subnets[0]), # 첫 번째 /24 'private_app': str(az_subnets[1]), # 두 번째 /24 'private_db': str(az_subnets[2]), # 세 번째 /24 # 나머지는 미래 확장용으로 예약 } return subnets # 실제 사용 예시 vpc_plan = plan_vpc_cidr('10.0.0.0/16', azs_count=3) for az, subnets in vpc_plan.items(): print(f"\n{az}:") for subnet_type, cidr in subnets.items(): print(f" {subnet_type}: {cidr}") ``` 박시니어 씨가 화이트보드에 큰 네모를 그렸습니다. "이게 10.0.0.0/16 VPC라고 생각해봅시다." 김개발 씨가 고개를 갸우뚱했습니다. "왜 하필 /16이에요?" **CIDR 표기법**부터 이해해봅시다. 쉽게 비유하자면, CIDR은 마치 아파트 주소 체계와 같습니다. "서울시 강남구"는 넓은 지역이고, "서울시 강남구 역삼동"은 더 좁은 지역이죠. "서울시 강남구 역삼동 123번지"는 가장 구체적입니다. IP 주소도 마찬가지입니다. 10.0.0.0/16은 넓은 범위를, 10.0.1.0/24는 그 안의 작은 구역을 나타냅니다. **/16이 무슨 뜻일까요?** 박시니어 씨가 설명했습니다. "IP 주소는 32비트예요. /16은 앞의 16비트가 네트워크 주소라는 뜻입니다." 나머지 16비트가 호스트 주소가 되므로, 2의 16승 = 65,536개의 IP 주소를 사용할 수 있습니다. "하지만 AWS는 각 서브넷에서 5개를 예약해요. 실제로는 조금 적습니다." CIDR 계획 없이 마구잡이로 만들면 어떻게 될까요? 박시니어 씨의 전 직장에서 일어난 일입니다. 처음 VPC를 만들 때 "일단 /24면 충분하겠지"라고 생각했습니다. 서비스가 성공하면서 서버가 급격히 늘어났습니다. IP 주소가 부족해졌습니다. VPC CIDR을 확장하려 했지만, 겹치지 않는 범위를 찾기가 어려웠습니다. 결국 새 VPC를 만들고 VPC 피어링으로 연결하는 복잡한 구조가 되었습니다. 바로 이런 문제를 방지하기 위해 **체계적인 CIDR 계획**이 필요합니다. 첫 번째 원칙은 **넉넉하게 시작**하는 것입니다. VPC는 /16으로 시작하는 것이 일반적입니다. 10.0.0.0/16이나 172.16.0.0/16을 많이 사용합니다. "너무 큰 거 아니에요?"라고 김개발 씨가 물었습니다. "IP 주소는 공짜예요. 나중에 모자라는 것보다 처음에 넉넉한 게 낫습니다." 두 번째 원칙은 **계층적으로 분할**하는 것입니다. /16 VPC를 바로 /24 서브넷으로 나누지 않습니다. 먼저 /18로 나눠서 각 AZ에 할당합니다. 그 다음 각 /18을 다시 /24로 나눠서 퍼블릭, 프라이빗 앱, 프라이빗 DB 서브넷으로 만듭니다. 이렇게 하면 나중에 확장할 여지가 남습니다. **세 번째 원칙**은 예약 공간을 남기는 것입니다. 김개발 씨가 물었습니다. "모든 공간을 다 할당하면 안 되나요?" 박시니어 씨가 답했습니다. "미래를 위해 여유를 둬야 해요. 나중에 Kubernetes 클러스터를 추가하거나, 새로운 계층이 필요할 수 있습니다." 보통 전체 공간의 30-40%는 미래를 위해 예약해둡니다. 위의 코드를 자세히 분석해봅시다. 먼저 Python의 `ipaddress` 모듈을 사용합니다. 이 모듈은 CIDR 계산을 쉽게 해줍니다. `ip_network` 함수로 VPC CIDR을 파싱합니다. 그 다음 `subnets(new_prefix=18)` 함수로 /16을 여러 개의 /18로 나눕니다. 각 /18은 16,384개의 IP를 제공하며, 하나의 AZ에 할당됩니다. 각 AZ 블록을 다시 `/24`로 나눕니다. `new_prefix=24`는 256개 IP를 가진 서브넷을 만듭니다. 첫 번째는 퍼블릭 서브넷, 두 번째는 프라이빗 애플리케이션 서브넷, 세 번째는 프라이빗 DB 서브넷으로 사용합니다. 나머지 서브넷들은 할당하지 않고 남겨둡니다. 이것이 미래 확장을 위한 예약 공간입니다. 출력 결과를 보면 체계적인 구조를 알 수 있습니다. AZ-1은 10.0.0.0/24, 10.0.1.0/24, 10.0.2.0/24를 사용합니다. AZ-2는 10.0.64.0/24로 시작합니다. 완전히 겹치지 않는 독립된 공간입니다. 이런 구조 덕분에 나중에 서브넷을 추가해도 충돌이 없습니다. 실제 현업에서는 어떻게 활용할까요? 대규모 서비스를 보면 더 복잡한 계획을 세웁니다. 예를 들어 개발, 스테이징, 운영 환경을 각각 다른 VPC로 분리합니다. 10.0.0.0/16은 개발, 10.1.0.0/16은 스테이징, 10.2.0.0/16은 운영용으로 사용합니다. VPC 피어링이나 Transit Gateway로 연결하면 환경 간 통신도 가능합니다. 하지만 주의할 점이 있습니다. 초보 개발자들이 흔히 하는 실수는 **RFC 1918 프라이빗 주소 범위를 벗어나는 것**입니다. 공인 IP 주소 범위를 VPC에 사용하면 안 됩니다. 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16만 사용해야 합니다. 다른 주소를 사용하면 인터넷 라우팅에 문제가 생길 수 있습니다. 또 다른 실수는 **회사 네트워크와 겹치는 범위를 사용하는 것**입니다. 김개발 씨가 물었습니다. "회사 사무실 네트워크가 10.0.0.0/16인데, VPC도 같은 주소를 쓰면 어떻게 되나요?" 박시니어 씨가 답했습니다. "VPN이나 Direct Connect로 연결할 때 문제가 생겨요. IP 충돌로 통신이 안 됩니다." 사전에 사내 네트워크팀과 조율해서 겹치지 않는 범위를 선택해야 합니다. **/24가 항상 정답은 아닙니다.** 서브넷 크기는 용도에 따라 달라져야 합니다. Lambda가 많이 사용되는 서브넷은 /22나 /21로 크게 만들어야 합니다. Lambda는 ENI를 많이 소비하기 때문입니다. 반면 NAT 게이트웨이만 있는 서브넷은 /28로 작게 만들어도 충분합니다. **도구를 활용**하는 것도 좋습니다. 온라인 CIDR 계산기를 사용하면 실수를 줄일 수 있습니다. AWS VPC Console도 시각적으로 CIDR을 보여줍니다. 박시니어 씨가 덧붙였습니다. "Terraform이나 CloudFormation을 사용하면 계산을 자동화할 수 있어요. cidrsubnet 함수가 유용합니다." 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 CIDR 계산기를 열어 직접 연습해보았습니다. "이제 /16과 /24의 차이를 알겠어요!" CIDR 블록을 체계적으로 계획하면 확장 가능하고 관리하기 쉬운 네트워크를 만들 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트 설계에 적용해 보세요. **실전 팁** 💡 - VPC는 /16으로 시작하되, 환경별로 다른 범위를 사용하세요 (개발: 10.0.x.x, 운영: 10.1.x.x) - 전체 IP 공간의 30-40%는 미래 확장을 위해 예약해두세요 - 온프레미스 네트워크와 겹치지 않도록 사전에 IP 계획을 조율하세요 --- ## 6. 서브넷_라우팅 CIDR 계획까지 마친 김개발 씨가 실제로 서버를 띄워봤습니다. 그런데 통신이 안 됩니다. "서브넷도 만들고 게이트웨이도 만들었는데 왜 안 되죠?" 박시니어 씨가 로그를 보며 말했습니다. "라우팅 테이블을 확인해보세요." **서브넷 라우팅**은 네트워크 트래픽이 어디로 가야 할지 결정하는 규칙입니다. 마치 도로의 이정표처럼, 패킷이 목적지까지 가는 경로를 안내합니다. 라우팅 테이블로 퍼블릭과 프라이빗을 구분하며, 잘못 설정하면 통신이 완전히 차단됩니다. 다음 코드를 살펴봅시다. ```python import boto3 ec2 = boto3.resource('ec2') ec2_client = boto3.client('ec2') vpc = ec2.Vpc('vpc-xxxxx') # 라우팅 테이블 분석 함수 def analyze_route_table(route_table_id): """라우팅 테이블의 모든 경로 출력""" rt = ec2.RouteTable(route_table_id) print(f"\n라우팅 테이블: {route_table_id}") print("-" * 60) for route in rt.routes: destination = route.destination_cidr_block or "N/A" # 목적지 종류 파악 if route.gateway_id and route.gateway_id.startswith('igw-'): target = f"인터넷 게이트웨이 ({route.gateway_id})" elif route.nat_gateway_id: target = f"NAT 게이트웨이 ({route.nat_gateway_id})" elif route.gateway_id == 'local': target = "VPC 로컬" else: target = "기타" print(f" {destination:20} -> {target}") # 연결된 서브넷 확인 associated = [assoc.subnet_id for assoc in rt.associations if assoc.subnet_id] print(f"\n연결된 서브넷: {', '.join(associated) if associated else '없음'}") # 실제 사용 analyze_route_table('rtb-xxxxx') ``` 김개발 씨는 답답했습니다. 설정을 다 했는데 왜 안 되는 걸까요? 박시니어 씨가 AWS 콘솔을 열어 라우팅 테이블을 보여주었습니다. "여기를 보세요. 라우팅 경로가 없네요." **라우팅 테이블**이란 무엇일까요? 쉽게 비유하자면, 라우팅 테이블은 마치 택배 회사의 배송 규칙과 같습니다. "서울로 가는 물건은 A 차량", "부산으로 가는 물건은 B 차량"처럼 목적지에 따라 경로를 정합니다. 네트워크 패킷도 마찬가지입니다. IP 주소를 보고 인터넷 게이트웨이로 보낼지, NAT 게이트웨이로 보낼지 결정합니다. 라우팅 설정이 없으면 어떻게 될까요? 박시니어 씨의 후배인 정초보 씨의 경험담입니다. 서브넷을 만들고 EC2를 띄웠는데 인터넷이 안 됐습니다. `ping 8.8.8.8`도 실패했습니다. 라우팅 테이블을 확인해보니 기본 경로만 있었습니다. 인터넷 게이트웨이로 가는 경로를 추가하지 않았던 것입니다. 간단한 설정 하나를 놓쳐서 몇 시간을 허비했습니다. 바로 이런 문제를 방지하기 위해 **체계적인 라우팅 설계**가 필요합니다. 라우팅의 첫 번째 원칙은 **명시적 경로 설정**입니다. 모든 서브넷은 반드시 라우팅 테이블과 연결되어야 합니다. 연결하지 않으면 기본 라우팅 테이블을 사용하는데, 이는 예측 불가능합니다. 퍼블릭과 프라이빗을 분리하려면 각각 별도의 라우팅 테이블을 만들어야 합니다. 두 번째 원칙은 **최소 권한 원칙**입니다. 꼭 필요한 경로만 추가합니다. "일단 모든 트래픽을 열어놓고 나중에 좁히자"는 위험한 생각입니다. 처음부터 필요한 경로만 명시적으로 추가해야 합니다. 박시니어 씨가 강조했습니다. "보안은 처음부터 강하게, 나중에 완화하는 게 안전해요." **세 번째 원칙**은 대칭적 라우팅입니다. 김개발 씨가 물었습니다. "대칭적이란 뭐예요?" 박시니어 씨가 설명했습니다. "요청이 A 경로로 갔으면 응답도 A 경로로 와야 해요." 비대칭 라우팅은 방화벽이나 보안 그룹에서 차단될 수 있습니다. 특히 stateful 방화벽은 같은 경로를 기대합니다. 위의 코드를 단계별로 살펴봅시다. `analyze_route_table` 함수는 라우팅 테이블을 분석하는 도구입니다. 실무에서 매우 유용합니다. `RouteTable` 객체의 `routes` 속성으로 모든 경로를 가져옵니다. 각 경로는 목적지(`destination_cidr_block`)와 타겟을 가집니다. `gateway_id`가 `igw-`로 시작하면 인터넷 게이트웨이입니다. 이것은 퍼블릭 서브넷의 표시입니다. `0.0.0.0/0 -> igw-xxxxx` 경로가 있으면 모든 외부 트래픽이 인터넷으로 나갑니다. `nat_gateway_id`가 있으면 NAT 게이트웨이입니다. 프라이빗 서브넷의 특징이죠. `gateway_id == 'local'`은 VPC 내부 통신을 의미합니다. **local 경로**는 자동으로 생성됩니다. VPC CIDR 범위 내의 모든 트래픽은 VPC 안에서 처리됩니다. 예를 들어 10.0.0.0/16 VPC라면 `10.0.0.0/16 -> local` 경로가 자동으로 있습니다. 이 경로는 삭제할 수 없고, 수정할 수도 없습니다. VPC의 기본 동작입니다. `associations` 속성으로 어느 서브넷과 연결되었는지 확인합니다. 하나의 라우팅 테이블을 여러 서브넷에 연결할 수 있습니다. 예를 들어 3개 AZ의 퍼블릭 서브넷이 모두 같은 라우팅 테이블을 공유할 수 있습니다. 하지만 프라이빗 서브넷은 AZ마다 다른 라우팅 테이블을 사용해야 합니다. 각 AZ의 NAT 게이트웨이가 다르기 때문입니다. 실제 현업에서는 어떻게 활용할까요? 복잡한 아키텍처를 보면 라우팅이 더 정교합니다. 예를 들어 VPC 피어링이 있으면 피어 VPC로 가는 경로가 추가됩니다. Transit Gateway를 사용하면 여러 VPC와 온프레미스로 가는 경로가 하나의 테이블에 있습니다. VPN 연결이 있으면 Virtual Private Gateway로 가는 경로도 있죠. 하지만 주의할 점이 있습니다. 초보 개발자들이 흔히 하는 실수는 **라우팅 우선순위를 모르는 것**입니다. 여러 경로가 매칭될 때 가장 구체적인 경로가 선택됩니다. 예를 들어 `10.0.1.0/24`와 `10.0.0.0/16`이 모두 있으면 `10.0.1.0/24`가 우선입니다. 더 좁은 범위가 더 구체적이기 때문입니다. 또 다른 실수는 **블랙홀 경로**를 만드는 것입니다. 김개발 씨가 물었습니다. "블랙홀이요?" 박시니어 씨가 설명했습니다. "존재하지 않는 타겟을 가리키는 경로예요. NAT 게이트웨이를 삭제했는데 라우팅 경로는 남아있으면 트래픽이 사라집니다." AWS 콘솔에서 경로 상태를 확인할 수 있습니다. "blackhole" 상태면 즉시 수정해야 합니다. **경로 전파**도 이해해야 합니다. Virtual Private Gateway나 Transit Gateway는 경로를 자동으로 전파할 수 있습니다. "Route Propagation" 옵션을 켜면 BGP로 학습한 경로가 자동으로 추가됩니다. 편리하지만, 예상치 못한 경로가 생길 수 있으니 주의해야 합니다. 프로덕션 환경에서는 수동으로 관리하는 것이 더 안전합니다. **라우팅 로그**를 활용하는 것도 좋습니다. VPC Flow Logs를 활성화하면 모든 트래픽을 기록할 수 있습니다. 라우팅 문제를 디버깅할 때 매우 유용합니다. "이 패킷이 왜 안 갔을까?" 싶을 때 Flow Logs를 보면 답이 나옵니다. CloudWatch Logs Insights로 쿼리하면 패턴도 찾을 수 있습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 도움으로 라우팅 테이블을 수정한 김개발 씨는 드디어 통신이 되는 것을 확인했습니다. "오! 핑이 가네요!" 서브넷 라우팅을 제대로 이해하면 복잡한 네트워크도 설계하고 문제도 해결할 수 있습니다. 여러분도 오늘 배운 내용을 실제 트러블슈팅에 활용해 보세요. **실전 팁** 💡 - 라우팅 테이블은 퍼블릭/프라이빗/DB용으로 분리하여 관리하세요 - VPC Flow Logs를 활성화하여 라우팅 문제를 쉽게 디버깅하세요 - 경로 변경 전 반드시 현재 상태를 문서화하고, 변경 후 테스트를 거쳐야 합니다 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: AWS

언어: Python

태그: AWS, VPC, Subnets, CIDR, NetworkArchitecture

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

VPC 아키텍처 설계 완벽 가이드

목차

1. VPC 설계 원칙

2. 멀티 AZ 아키텍처

3. 퍼블릭 서브넷 설계

4. 프라이빗 서브넷 설계

5. CIDR 블록 계획

6. 서브넷 라우팅

댓글 (0)

함께 보면 좋은 카드 뉴스

Helm 마이크로서비스 패키징 완벽 가이드

보안 아키텍처 구성 완벽 가이드

AWS Organizations 완벽 가이드

AWS KMS 암호화 완벽 가이드

AWS Secrets Manager 완벽 가이드