인터넷 게이트웨이와 퍼블릭 라우팅 설정 완벽 가이드

AWS VPC에서 인터넷과 통신하기 위한 핵심 구성요소인 인터넷 게이트웨이와 퍼블릭 라우팅 설정을 단계별로 학습합니다. 초급 개발자도 쉽게 따라할 수 있도록 실무 예제와 함께 설명합니다.

---

목차

1. 인터넷_게이트웨이의_역할
2. IGW_생성_및_VPC_연결
3. 라우팅_테이블의_개념
4. 퍼블릭_라우팅_테이블_생성
5. 기본_라우트_설정
6. 퍼블릭_서브넷에_EC2_배치_실습

---

1. 인터넷 게이트웨이의 역할

어느 날 김개발 씨는 회사에서 첫 AWS 프로젝트를 맡게 되었습니다. VPC 안에 EC2 인스턴스를 만들었는데, 아무리 해도 인터넷에 접속이 되지 않았습니다.

"분명히 인스턴스는 잘 만들어졌는데 왜 외부와 통신이 안 되는 거지?"

**인터넷 게이트웨이(Internet Gateway, IGW)**는 VPC와 인터넷 사이를 연결해주는 관문입니다. 마치 아파트 단지의 정문과 같습니다.

정문이 없으면 외부 손님이 들어올 수도, 주민이 나갈 수도 없듯이, IGW가 없으면 VPC 내부의 리소스들이 인터넷과 통신할 수 없습니다.

다음 코드를 살펴봅시다.

import boto3

# AWS EC2 클라이언트 생성
ec2 = boto3.client('ec2', region_name='ap-northeast-2')

# 인터넷 게이트웨이 생성
response = ec2.create_internet_gateway(
    TagSpecifications=[{
        'ResourceType': 'internet-gateway',
        'Tags': [{'Key': 'Name', 'Value': 'my-igw'}]
    }]
)

# 생성된 IGW ID 확인
igw_id = response['InternetGateway']['InternetGatewayId']
print(f"생성된 인터넷 게이트웨이: {igw_id}")

김개발 씨는 입사 2개월 차 클라우드 엔지니어입니다. 오늘 처음으로 AWS VPC를 직접 구성하는 업무를 맡았습니다.

열심히 VPC를 만들고, 서브넷도 생성하고, EC2 인스턴스까지 배포했습니다. 그런데 이상합니다.

인스턴스에 SSH로 접속해서 ping google.com을 실행했는데, 응답이 오지 않습니다. 선배 개발자 박시니어 씨가 다가와 물었습니다.

"혹시 인터넷 게이트웨이 설정했어요?" 김개발 씨는 고개를 갸우뚱했습니다. "인터넷 게이트웨이요?

그게 뭔가요?" 그렇다면 인터넷 게이트웨이란 정확히 무엇일까요? 쉽게 비유하자면, VPC는 하나의 폐쇄된 아파트 단지와 같습니다.

높은 담장으로 둘러싸여 있어서 외부와 완전히 격리되어 있습니다. 이 단지 안에는 여러 동의 아파트가 있고, 각 동이 바로 서브넷입니다.

그리고 각 세대가 EC2 인스턴스라고 생각하면 됩니다. 그런데 문제가 있습니다.

담장만 있고 정문이 없다면 어떻게 될까요? 택배 기사님이 물건을 배달할 수도 없고, 주민들이 외출할 수도 없습니다.

바로 이 정문 역할을 하는 것이 인터넷 게이트웨이입니다. 인터넷 게이트웨이가 없던 시절, 정확히 말하면 IGW를 연결하지 않은 VPC에서는 어땠을까요?

내부 리소스들끼리는 자유롭게 통신할 수 있습니다. 같은 VPC 안의 EC2끼리, RDS와 EC2 사이에는 문제없이 데이터가 오갑니다.

하지만 외부 API를 호출하거나, 소프트웨어 패키지를 다운로드하거나, 사용자가 웹 서버에 접속하는 것이 불가능합니다. 바로 이런 문제를 해결하기 위해 인터넷 게이트웨이가 존재합니다.

IGW는 두 가지 핵심 기능을 수행합니다. 첫째, 아웃바운드 트래픽을 처리합니다.

VPC 내부에서 인터넷으로 나가는 트래픽을 외부로 전달합니다. 둘째, 인바운드 트래픽을 처리합니다.

인터넷에서 들어오는 요청을 VPC 내부의 적절한 리소스로 라우팅합니다. 위의 코드를 살펴보겠습니다.

boto3 라이브러리를 사용하여 AWS와 통신합니다. create_internet_gateway 메서드를 호출하면 새로운 IGW가 생성됩니다.

TagSpecifications를 통해 이름 태그를 붙여서 나중에 쉽게 식별할 수 있게 합니다. 실제 현업에서는 어떻게 활용할까요?

웹 서비스를 운영한다고 가정해봅시다. 사용자들이 브라우저를 통해 여러분의 서비스에 접속하려면 반드시 인터넷 게이트웨이가 필요합니다.

또한 서버에서 외부 결제 API를 호출하거나, 이메일을 발송하려면 IGW를 통해 외부와 통신해야 합니다. 하지만 주의할 점도 있습니다.

IGW를 생성했다고 해서 바로 인터넷 통신이 되는 것은 아닙니다. IGW를 VPC에 연결하고, 라우팅 테이블을 설정하고, 보안 그룹까지 적절히 구성해야 비로소 통신이 가능해집니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 비로소 이해했습니다.

"아, VPC만 만들면 끝이 아니라 인터넷과 연결하는 문이 따로 필요하군요!"

실전 팁

💡 - IGW는 VPC당 하나만 연결할 수 있습니다

• IGW 자체는 가용성이 보장되어 별도의 이중화가 필요 없습니다
• IGW는 생성 비용이 무료이며, 데이터 전송 비용만 발생합니다

---

2. IGW 생성 및 VPC 연결

김개발 씨는 인터넷 게이트웨이가 무엇인지 이해했습니다. 이제 직접 만들어볼 차례입니다.

"그런데 선배님, IGW를 만들기만 하면 되는 건가요?" 박시니어 씨가 고개를 저었습니다. "아니요, 만들고 나서 VPC에 연결하는 과정이 필요해요."

인터넷 게이트웨이를 생성한 후에는 반드시 VPC에 **연결(Attach)**해야 합니다. 마치 문을 만들었으면 담장에 설치해야 하는 것과 같습니다.

연결되지 않은 IGW는 어디에도 속하지 않은 고아 상태가 됩니다.

다음 코드를 살펴봅시다.

import boto3

ec2 = boto3.client('ec2', region_name='ap-northeast-2')

# 기존 VPC ID (미리 생성되어 있어야 함)
vpc_id = 'vpc-0123456789abcdef0'

# 인터넷 게이트웨이 생성
igw_response = ec2.create_internet_gateway(
    TagSpecifications=[{
        'ResourceType': 'internet-gateway',
        'Tags': [{'Key': 'Name', 'Value': 'production-igw'}]
    }]
)
igw_id = igw_response['InternetGateway']['InternetGatewayId']

# IGW를 VPC에 연결
ec2.attach_internet_gateway(
    InternetGatewayId=igw_id,
    VpcId=vpc_id
)
print(f"IGW {igw_id}가 VPC {vpc_id}에 연결되었습니다")

김개발 씨는 이제 실제로 인터넷 게이트웨이를 만들어보기로 했습니다. AWS 콘솔을 열고 VPC 서비스로 이동합니다.

왼쪽 메뉴에서 "인터넷 게이트웨이"를 클릭하고 "인터넷 게이트웨이 생성" 버튼을 눌렀습니다. 이름을 입력하고 생성 버튼을 누르니 순식간에 IGW가 만들어졌습니다.

김개발 씨는 뿌듯한 마음으로 EC2 인스턴스에서 다시 ping을 테스트했습니다. 하지만 여전히 응답이 없습니다.

무엇이 문제일까요? 박시니어 씨가 화면을 가리켰습니다.

"상태를 보세요. Detached라고 되어 있죠?

IGW를 만들었지만 아직 VPC에 연결하지 않았어요." 이것은 마치 현관문을 공장에서 주문제작해서 받아놓고, 아직 집에 설치하지 않은 상태와 같습니다. 문은 있지만 담장에 붙어있지 않으니 출입구 역할을 할 수가 없습니다.

IGW를 VPC에 연결하는 과정을 Attach라고 합니다. 위의 코드에서 attach_internet_gateway 메서드가 바로 이 역할을 합니다.

InternetGatewayId와 VpcId 두 개의 파라미터를 전달하면, AWS가 둘 사이의 연결을 수립합니다. 여기서 중요한 규칙이 있습니다.

하나의 VPC에는 하나의 IGW만 연결할 수 있습니다. 반대로 하나의 IGW도 하나의 VPC에만 연결할 수 있습니다. 이것은 1:1 관계입니다. 만약 다른 VPC에 IGW가 필요하다면, 새로운 IGW를 생성해야 합니다.

연결이 완료되면 상태가 Attached로 바뀝니다. 이제 IGW가 VPC의 일부가 되었습니다.

하지만 아직 인터넷 통신이 되지는 않습니다. 왜냐하면 트래픽이 IGW로 향하도록 길을 알려주는 라우팅 테이블이 설정되지 않았기 때문입니다.

실무에서는 보통 VPC를 생성할 때 IGW도 함께 생성하고 바로 연결합니다. Terraform이나 CloudFormation 같은 IaC 도구를 사용하면 이 과정을 한 번에 자동화할 수 있습니다.

주의할 점이 있습니다. IGW를 분리(Detach)하려면 해당 IGW를 참조하는 라우팅 테이블의 라우트를 먼저 삭제해야 합니다.

순서를 지키지 않으면 오류가 발생합니다. 김개발 씨는 IGW를 VPC에 연결했습니다.

상태가 Attached로 바뀌었습니다. "이제 되나요?" 박시니어 씨가 웃으며 말했습니다.

"아직 한 단계 더 남았어요. 라우팅 테이블을 설정해야 해요."

실전 팁

💡 - VPC에 이미 IGW가 연결되어 있으면 새로운 IGW를 연결할 수 없습니다

• IGW를 삭제하려면 먼저 VPC에서 분리해야 합니다
• Terraform에서는 aws_internet_gateway 리소스로 생성과 연결을 한 번에 처리합니다

---

3. 라우팅 테이블의 개념

김개발 씨는 IGW를 VPC에 연결했지만 여전히 인터넷이 되지 않습니다. 박시니어 씨가 설명을 이어갑니다.

"IGW는 문이에요. 그런데 문이 있어도 그 문으로 가는 길을 모르면 어떻게 될까요?

바로 그 길을 알려주는 게 라우팅 테이블이에요."

**라우팅 테이블(Route Table)**은 네트워크 트래픽이 어디로 가야 하는지 알려주는 이정표입니다. 마치 도로의 표지판처럼, 특정 목적지로 가려면 어떤 경로를 타야 하는지 안내합니다.

각 서브넷은 하나의 라우팅 테이블과 연결되어야 합니다.

다음 코드를 살펴봅시다.

import boto3

ec2 = boto3.client('ec2', region_name='ap-northeast-2')

# 라우팅 테이블 조회
response = ec2.describe_route_tables(
    Filters=[
        {'Name': 'vpc-id', 'Values': ['vpc-0123456789abcdef0']}
    ]
)

# 각 라우팅 테이블의 라우트 정보 출력
for rt in response['RouteTables']:
    print(f"라우팅 테이블: {rt['RouteTableId']}")
    for route in rt['Routes']:
        destination = route.get('DestinationCidrBlock', 'N/A')
        target = route.get('GatewayId') or route.get('NatGatewayId') or 'local'
        print(f"  {destination} -> {target}")

김개발 씨는 잠시 생각에 잠겼습니다. "라우팅 테이블이요...

네트워크 수업에서 들어본 것 같은데 정확히 기억이 안 나요." 박시니어 씨가 친절하게 설명을 시작했습니다. "서울에서 부산으로 가려고 한다고 생각해보세요.

네비게이션을 켜면 어떤 고속도로를 타야 하는지 알려주죠? 경부고속도로를 타라고 하거나, 중부내륙고속도로를 타라고 하거나요.

라우팅 테이블이 바로 그 네비게이션 역할을 합니다." VPC 안에서 발생하는 모든 네트워크 트래픽은 라우팅 테이블을 참조합니다. 트래픽의 목적지 IP 주소를 확인하고, 라우팅 테이블에서 해당 목적지에 맞는 규칙을 찾아 그 경로로 트래픽을 전송합니다.

라우팅 테이블은 여러 개의 **라우트(Route)**로 구성됩니다. 각 라우트는 두 가지 정보를 담고 있습니다.

첫째는 **목적지(Destination)**입니다. 어디로 가려는 트래픽인지를 CIDR 블록으로 표현합니다.

둘째는 **대상(Target)**입니다. 해당 트래픽을 어디로 보낼지를 지정합니다.

VPC를 생성하면 자동으로 **기본 라우팅 테이블(Main Route Table)**이 만들어집니다. 이 기본 라우팅 테이블에는 하나의 라우트가 이미 포함되어 있습니다.

바로 local 라우트입니다. 예를 들어 VPC의 CIDR이 10.0.0.0/16이라면, "10.0.0.0/16 -> local"이라는 라우트가 있습니다.

이것은 VPC 내부 트래픽은 로컬에서 처리하라는 의미입니다. 그런데 문제는 외부 인터넷으로 나가는 트래픽입니다.

local 라우트는 VPC 내부만 처리합니다. 8.8.8.8(구글 DNS)이나 다른 외부 IP로 가려는 트래픽은 어디로 보내야 할지 모릅니다.

목적지를 찾지 못한 트래픽은 그냥 사라집니다. 바로 여기서 퍼블릭 라우팅 테이블이 필요해집니다.

인터넷으로 나가는 트래픽을 IGW로 보내도록 경로를 추가해야 합니다. 위의 코드는 VPC에 속한 모든 라우팅 테이블을 조회합니다.

describe_route_tables 메서드를 사용하고, VPC ID로 필터링합니다. 각 라우팅 테이블의 라우트 정보를 출력하면 현재 어떤 경로가 설정되어 있는지 확인할 수 있습니다.

실무에서는 최소 두 개의 라우팅 테이블을 운영합니다. 하나는 인터넷과 통신하는 퍼블릭 라우팅 테이블이고, 다른 하나는 내부 통신만 하는 프라이빗 라우팅 테이블입니다.

보안상 중요한 데이터베이스나 내부 서비스는 프라이빗 라우팅 테이블을 사용하는 서브넷에 배치합니다. 김개발 씨가 고개를 끄덕였습니다.

"아, 그러니까 IGW라는 문은 만들었는데, 그 문으로 가라는 이정표가 없었던 거군요!"

실전 팁

💡 - 서브넷은 명시적으로 라우팅 테이블과 연결하지 않으면 기본 라우팅 테이블을 사용합니다

• 라우팅 테이블의 라우트는 가장 구체적인 것(Longest Prefix Match)이 우선 적용됩니다
• local 라우트는 삭제할 수 없으며, VPC 내부 통신에 필수입니다

---

4. 퍼블릭 라우팅 테이블 생성

김개발 씨는 이제 무엇을 해야 할지 감이 잡혔습니다. "인터넷으로 나가는 트래픽을 IGW로 보내는 라우팅 테이블을 만들어야겠군요!" 박시니어 씨가 고개를 끄덕이며 말했습니다.

"맞아요. 그게 바로 퍼블릭 라우팅 테이블이에요.

직접 만들어볼까요?"

퍼블릭 라우팅 테이블은 인터넷 게이트웨이로의 라우트를 포함한 라우팅 테이블입니다. 이 라우팅 테이블과 연결된 서브넷은 퍼블릭 서브넷이 됩니다.

웹 서버나 로드 밸런서처럼 외부와 직접 통신해야 하는 리소스를 배치하는 곳입니다.

다음 코드를 살펴봅시다.

import boto3

ec2 = boto3.client('ec2', region_name='ap-northeast-2')

vpc_id = 'vpc-0123456789abcdef0'

# 퍼블릭 라우팅 테이블 생성
rt_response = ec2.create_route_table(
    VpcId=vpc_id,
    TagSpecifications=[{
        'ResourceType': 'route-table',
        'Tags': [{'Key': 'Name', 'Value': 'public-rt'}]
    }]
)
route_table_id = rt_response['RouteTable']['RouteTableId']
print(f"퍼블릭 라우팅 테이블 생성: {route_table_id}")

# 생성된 라우팅 테이블에는 기본적으로 local 라우트만 존재
# 다음 단계에서 IGW로의 라우트를 추가해야 함

박시니어 씨가 화이트보드에 그림을 그리기 시작했습니다. VPC를 큰 사각형으로 그리고, 그 안에 두 개의 작은 사각형을 그렸습니다.

하나에는 "퍼블릭 서브넷", 다른 하나에는 "프라이빗 서브넷"이라고 썼습니다. "김개발 씨, 이 두 서브넷의 차이가 뭘까요?" 김개발 씨가 대답했습니다.

"퍼블릭 서브넷은 인터넷과 통신할 수 있고, 프라이빗 서브넷은 못하는 거 아닌가요?" 박시니어 씨가 고개를 끄덕였습니다. "맞아요.

그런데 정확히 말하면, 서브넷 자체에 퍼블릭이나 프라이빗이라는 속성이 있는 게 아니에요. 어떤 라우팅 테이블과 연결되느냐에 따라 결정되는 거예요." 이것은 중요한 개념입니다.

서브넷을 만들 때 "퍼블릭" 또는 "프라이빗"을 선택하는 옵션은 없습니다. 서브넷 자체는 그냥 IP 주소 범위일 뿐입니다.

그 서브넷이 IGW로의 라우트를 가진 라우팅 테이블과 연결되면 퍼블릭 서브넷이 되고, 그렇지 않으면 프라이빗 서브넷이 됩니다. 위의 코드에서 create_route_table 메서드로 새로운 라우팅 테이블을 생성합니다.

이때 VpcId를 지정해서 어떤 VPC에 속하는지 명시합니다. 생성된 라우팅 테이블에는 자동으로 local 라우트만 포함됩니다.

여기서 "public-rt"라는 이름을 붙였지만, 아직 이 라우팅 테이블은 퍼블릭이 아닙니다. 왜냐하면 IGW로의 라우트가 없기 때문입니다.

이름은 그냥 식별을 위한 태그일 뿐, 실제 동작에는 영향을 주지 않습니다. 실무에서는 보통 다음과 같은 구조를 사용합니다.

퍼블릭 서브넷에는 ALB(Application Load Balancer), NAT 게이트웨이, Bastion 호스트 등을 배치합니다. 프라이빗 서브넷에는 애플리케이션 서버, 데이터베이스, 캐시 서버 등을 배치합니다.

이런 구조를 사용하는 이유는 보안 때문입니다. 인터넷에 직접 노출되는 리소스는 최소화하고, 민감한 리소스는 프라이빗 서브넷에 숨깁니다.

외부 요청은 ALB를 통해 들어오고, 프라이빗 서브넷의 서버들은 NAT 게이트웨이를 통해 외부와 통신합니다. 김개발 씨가 질문했습니다.

"그러면 라우팅 테이블을 몇 개나 만들어야 하나요?" 박시니어 씨가 대답했습니다. "상황에 따라 다르지만, 기본적으로는 퍼블릭용 하나, 프라이빗용 하나면 충분해요.

더 세밀한 제어가 필요하면 추가할 수 있고요."

실전 팁

💡 - 라우팅 테이블 이름은 역할을 명확히 알 수 있게 붙이세요 (예: public-rt, private-rt-az-a)

• 하나의 라우팅 테이블을 여러 서브넷에 연결할 수 있습니다
• VPC의 기본 라우팅 테이블을 퍼블릭으로 사용하지 마세요. 실수로 노출될 위험이 있습니다

---

5. 기본 라우트 설정

퍼블릭 라우팅 테이블을 만들었지만 아직 비어있습니다. 박시니어 씨가 말했습니다.

"이제 가장 중요한 단계예요. 0.0.0.0/0 라우트를 추가해서 모든 외부 트래픽이 IGW로 가도록 설정해야 해요." 김개발 씨의 눈이 반짝였습니다.

"0.0.0.0/0이요? 모든 IP를 의미하는 건가요?"

0.0.0.0/0은 모든 IPv4 주소를 의미하는 CIDR 표기법입니다. 이 라우트를 **기본 라우트(Default Route)**라고 부릅니다.

VPC 내부 주소가 아닌 모든 트래픽을 특정 대상으로 보내라는 의미입니다. 퍼블릭 라우팅 테이블에서는 이 기본 라우트의 대상을 IGW로 설정합니다.

다음 코드를 살펴봅시다.

import boto3

ec2 = boto3.client('ec2', region_name='ap-northeast-2')

route_table_id = 'rtb-0123456789abcdef0'
igw_id = 'igw-0123456789abcdef0'
public_subnet_id = 'subnet-0123456789abcdef0'

# 0.0.0.0/0 -> IGW 라우트 추가 (기본 라우트)
ec2.create_route(
    RouteTableId=route_table_id,
    DestinationCidrBlock='0.0.0.0/0',
    GatewayId=igw_id
)
print("기본 라우트(0.0.0.0/0 -> IGW) 추가 완료")

# 라우팅 테이블을 퍼블릭 서브넷에 연결
ec2.associate_route_table(
    RouteTableId=route_table_id,
    SubnetId=public_subnet_id
)
print(f"서브넷 {public_subnet_id}이 퍼블릭 라우팅 테이블과 연결됨")

박시니어 씨가 설명을 이어갔습니다. "CIDR 표기법에서 /0은 모든 IP 주소를 의미해요.

0.0.0.0/0은 0.0.0.0부터 255.255.255.255까지, 즉 존재하는 모든 IPv4 주소를 포함합니다." 김개발 씨가 궁금해했습니다. "그러면 VPC 내부 주소도 포함되는 거 아닌가요?

예를 들어 10.0.0.5로 가는 트래픽도 IGW로 보내지는 건가요?" 좋은 질문입니다. 여기서 Longest Prefix Match 규칙이 적용됩니다.

라우팅 테이블에서 트래픽의 목적지와 일치하는 라우트가 여러 개 있으면, 가장 구체적인(prefix가 긴) 라우트가 선택됩니다. 예를 들어 라우팅 테이블에 다음 두 개의 라우트가 있다고 합시다.

"10.0.0.0/16 -> local"과 "0.0.0.0/0 -> igw"입니다. 10.0.1.5로 가는 트래픽은 어떻게 될까요?

두 라우트 모두 매칭되지만, 10.0.0.0/16이 더 구체적이므로 local로 라우팅됩니다. 반면 8.8.8.8로 가는 트래픽은 10.0.0.0/16에 매칭되지 않으므로 0.0.0.0/0 라우트를 따라 IGW로 전송됩니다.

위의 코드에서 create_route 메서드로 새 라우트를 추가합니다. DestinationCidrBlock에 0.0.0.0/0을, GatewayId에 IGW ID를 지정합니다.

이제 이 라우팅 테이블은 진정한 퍼블릭 라우팅 테이블이 되었습니다. 그 다음 associate_route_table로 라우팅 테이블을 서브넷에 연결합니다.

이 순간 해당 서브넷은 퍼블릭 서브넷이 됩니다. 이 서브넷에 있는 리소스들은 이제 인터넷과 통신할 수 있습니다.

하지만 주의할 점이 있습니다. 퍼블릭 서브넷에 있다고 해서 자동으로 인터넷 통신이 되는 것은 아닙니다.

EC2 인스턴스의 경우 퍼블릭 IP 또는 Elastic IP가 할당되어야 하고, 보안 그룹에서도 해당 트래픽을 허용해야 합니다. 실무에서 흔히 하는 실수 중 하나가 바로 이것입니다.

퍼블릭 서브넷에 인스턴스를 배치했는데 인터넷이 안 된다면, 퍼블릭 IP 할당 여부와 보안 그룹 설정을 확인해보세요. 김개발 씨가 차근차근 따라했습니다.

라우트를 추가하고, 서브넷과 연결했습니다. "이제 진짜 인터넷이 되는 건가요?" 박시니어 씨가 웃으며 말했습니다.

"거의 다 왔어요. 이제 EC2를 배치하고 테스트해볼까요?"

실전 팁

💡 - IPv6를 사용한다면 ::/0 라우트도 추가해야 합니다

• 라우트를 수정하려면 replace_route 메서드를 사용합니다
• 서브넷의 라우팅 테이블 연결을 변경하면 즉시 적용됩니다 (재부팅 불필요)

---

6. 퍼블릭 서브넷에 EC2 배치 실습

드디어 마지막 단계입니다. 김개발 씨는 지금까지 배운 내용을 종합하여 실제로 인터넷에 접속 가능한 EC2 인스턴스를 배포해볼 것입니다.

"자, 이제 모든 퍼즐 조각을 맞춰봅시다!" 박시니어 씨가 격려했습니다.

퍼블릭 서브넷에 EC2를 배치하려면 세 가지가 필요합니다. 첫째, IGW가 연결된 VPC입니다.

둘째, IGW로의 라우트가 있는 라우팅 테이블과 연결된 서브넷입니다. 셋째, 퍼블릭 IP가 할당된 EC2 인스턴스입니다.

이 세 가지가 갖춰지면 인터넷 통신이 가능해집니다.

다음 코드를 살펴봅시다.

import boto3

ec2 = boto3.resource('ec2', region_name='ap-northeast-2')

# 퍼블릭 서브넷에 EC2 인스턴스 생성
instances = ec2.create_instances(
    ImageId='ami-0c9c942bd7bf113a2',  # Amazon Linux 2023
    InstanceType='t3.micro',
    MinCount=1,
    MaxCount=1,
    NetworkInterfaces=[{
        'DeviceIndex': 0,
        'SubnetId': 'subnet-0123456789abcdef0',  # 퍼블릭 서브넷
        'AssociatePublicIpAddress': True,  # 퍼블릭 IP 자동 할당
        'Groups': ['sg-0123456789abcdef0']  # 보안 그룹
    }],
    TagSpecifications=[{
        'ResourceType': 'instance',
        'Tags': [{'Key': 'Name', 'Value': 'web-server'}]
    }]
)
print(f"인스턴스 생성: {instances[0].id}")

김개발 씨는 드디어 모든 준비를 마쳤습니다. VPC, 서브넷, 인터넷 게이트웨이, 라우팅 테이블이 모두 제자리에 있습니다.

이제 실제로 EC2 인스턴스를 배포해서 인터넷 통신이 되는지 확인할 차례입니다. 위의 코드에서 가장 중요한 부분은 NetworkInterfaces 설정입니다.

SubnetId에 앞서 만든 퍼블릭 서브넷의 ID를 지정합니다. 그리고 AssociatePublicIpAddress를 True로 설정합니다.

이 설정이 없으면 인스턴스에 퍼블릭 IP가 할당되지 않아 인터넷 통신이 불가능합니다. 박시니어 씨가 설명을 덧붙였습니다.

"인터넷 통신이 이루어지는 과정을 한번 따라가 볼게요." 먼저 EC2 인스턴스가 8.8.8.8(구글 DNS)에 ping을 보낸다고 가정합니다. 패킷의 출발지는 인스턴스의 프라이빗 IP(예: 10.0.1.50)이고, 목적지는 8.8.8.8입니다.

이 패킷은 서브넷의 라우팅 테이블을 참조합니다. 라우팅 테이블에서 8.8.8.8에 매칭되는 라우트를 찾습니다.

local 라우트(10.0.0.0/16)에는 매칭되지 않고, 0.0.0.0/0 라우트에 매칭됩니다. 따라서 패킷은 IGW로 전달됩니다.

IGW에 도착한 패킷은 여기서 중요한 변환을 거칩니다. 출발지 IP가 프라이빗 IP(10.0.1.50)에서 퍼블릭 IP로 바뀝니다.

이것을 **NAT(Network Address Translation)**라고 합니다. IGW가 이 역할을 수행합니다.

변환된 패킷은 인터넷을 거쳐 8.8.8.8에 도착합니다. 응답 패킷은 반대로 돌아옵니다.

퍼블릭 IP를 목적지로 인터넷을 통해 IGW에 도착하고, IGW에서 다시 프라이빗 IP로 변환되어 인스턴스에 전달됩니다. 김개발 씨가 인스턴스에 SSH로 접속하여 테스트했습니다.

"ping 8.8.8.8" 명령을 실행하자, 드디어 응답이 돌아왔습니다! "64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=3.12 ms" 박시니어 씨가 박수를 치며 말했습니다.

"축하해요! 이제 VPC에서 인터넷 게이트웨이와 퍼블릭 라우팅의 전체 그림을 이해하게 된 거예요." 김개발 씨는 뿌듯한 표정으로 지금까지의 과정을 되돌아보았습니다.

VPC는 격리된 네트워크 공간이고, 서브넷은 그 안의 IP 주소 범위입니다. 인터넷 게이트웨이는 VPC와 인터넷을 연결하는 관문이며, 라우팅 테이블은 트래픽의 경로를 결정하는 이정표입니다.

이 모든 요소가 조화롭게 작동해야 비로소 인터넷 통신이 가능해집니다. 실무에서는 이 구성을 반복적으로 사용합니다.

Terraform이나 CloudFormation으로 템플릿화해두면 새 환경을 빠르게 구성할 수 있습니다. 또한 멀티 AZ 구성을 위해 각 가용 영역에 퍼블릭 서브넷과 프라이빗 서브넷을 만들어 고가용성을 확보합니다.

실전 팁

💡 - 보안 그룹에서 아웃바운드 규칙을 확인하세요. 기본적으로 모든 아웃바운드가 허용되지만, 커스텀 설정 시 주의가 필요합니다

• Elastic IP를 사용하면 인스턴스를 중지/시작해도 같은 퍼블릭 IP를 유지할 수 있습니다
• 퍼블릭 서브넷의 인스턴스라도 보안 그룹에서 인바운드 규칙을 설정해야 외부에서 접근할 수 있습니다

---

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