AWS 네트워크 계층으로 읽기

시리즈 소개
AWS EC2 Auto Scaling 실습 하나를 OSI 7계층 / TCP/IP 4계층 관점으로 한 챕터씩 뜯어보는 5부작입니다.
"버튼을 어디 누르는가"가 아니라 "이건 어느 계층에서, 무엇을 보고 동작하는가"를 기준으로 클라우드 네트워크를 이해하는 것이 목표입니다.

1 (이번 편) VPC·서브넷·라우팅 — L3 토대 ← 현재 위치
2 보안 그룹 vs NACL — L4 방화벽의 원리
3 ALB 완전 분석 — L7 로드밸런서는 왜 URL을 읽는가 (vs NLB)
4 Auto Scaling Group + Launch Template — 자동 증감의 본체
5 CloudWatch 동적 스케일링 + 부하 테스트로 증명하기

실습 환경: 서울 리전(ap-northeast-2) · CloudFormation(ASG_LAB.yaml) 기반

0. 공통 지도 — OSI 7계층 / TCP/IP 4계층 (매 편 반복)

이 시리즈를 관통하는 두 장의 지도입니다.

매 편 상단에 그대로 둡니다. 외울 필요는 없고, "지금 보는 서비스가 이 표의 어디에 찍히는가"만 짚으면 됩니다.

 

OSI 7계층 TCP/IP 4계층 핵심 단위(PDU) 대표 예시 이 시리즈에서
7. 응용 4. 응용 데이터 HTTP, DNS, SSH ALB, 헬스체크 경로, ApacheBench
6. 표현 4. 응용 데이터 TLS, 인코딩 (HTTPS 쓸 때)
5. 세션 4. 응용 데이터 세션 관리 ALB 세션 유지
4. 전송 3. 전송 세그먼트 TCP, UDP 보안그룹 포트, NLB
3. 네트워크 2. 인터넷 패킷 IP, ICMP, 라우팅 ★이번 편: VPC·서브넷·라우팅·IGW
2. 데이터링크 1. 네트워크 접근 프레임 MAC, 스위치 ENI(가상 NIC)
1. 물리 1. 네트워크 접근 비트 케이블 AWS 데이터센터

 

 

이번 편의 자리: 빨갛게 칠한 L3(네트워크 계층) = TCP/IP의 인터넷 계층입니다. IP 주소, 패킷, 라우팅이 사는 곳이죠. 클라우드에서 가장 먼저 깔아야 하는 "땅"이 바로 여기입니다.

OSI 7계층과 TCP/IP 4계층 지도 — 1편 L3 강조

1. 왜 L3부터 시작하는가

집을 지을 때 가장 먼저 하는 일은 땅을 사고 길을 내는 것입니다.

클라우드 네트워크도 똑같습니다. 서버(EC2)를 올리기 전에, 그 서버들이 살 사설 네트워크(VPC)를 만들고, 주소 체계(IP/CIDR)를 정하고, 길(라우팅)을 내야 합니다. 이 모든 것이 L3(네트워크 계층)의 일입니다.

 

L3의 핵심 질문은 단 하나입니다. "이 패킷을 어느 IP로, 어떤 경로로 보낼 것인가?"

이번 편에 나오는 VPC·서브넷·라우팅 테이블·인터넷 게이트웨이는 전부 이 질문에 답하기 위한 장치입니다.

이번 편의 모든 L3 리소스는 CloudFormation 템플릿(ASG_LAB.yaml) 한 장을 업로드하는 것으로 한 번에 생성됩니다.

이것이 이 실습의 출발점입니다.

 

CloudFormation 스택 생성 — ASG_Lab.yaml 템플릿 업로드


▲ 그림 1. CloudFormation에 ASG_Lab.yaml을 업로드하면 VPC·서브넷·라우팅·IGW가 코드로 한 번에 만들어진다(IaC).

이번 편에서 만드는 토대를 그림으로 보면:

L3 네트워크 토대 구조도 — 인터넷·IGW·VPC·서브넷·라우팅

2. VPC — 내 전용 사설 네트워크 그리기

2-1. 무엇인가

VPC(Virtual Private Cloud)는 AWS 클라우드 안에 그리는 나만의 격리된 가상 네트워크입니다.

다른 사용자와 논리적으로 완전히 분리되어 있고, 그 안의 IP 주소 체계를 내가 정합니다.

실습의 ASG_LAB.yaml은 VPC를 이렇게 정의합니다.

VPC1:
  Type: AWS::EC2::VPC
  Properties:
    CidrBlock: 10.9.0.0/16          # ← 이게 핵심: IP 대역 = L3
    EnableDnsSupport: true
    EnableDnsHostnames: true
    Tags:
      - Key: Name
        Value: ASG-VPC

 

2-2. CIDR 10.9.0.0/16 읽는 법 (입문자용)

10.9.0.0/16에서 /16이 핵심입니다. 이건 "앞에서 16비트는 고정, 나머지 16비트는 자유"라는 뜻입니다.

  • IP는 32비트(예: 10.9.0.0 = 00001010.00001001.00000000.00000000)
  • /16 = 앞 16비트(10.9)는 네트워크 주소로 고정
  • 남은 16비트(뒤 0.0 부분)는 호스트 자리 → 2^16 ≈ 65,536개의 IP를 담는 울타리

쉽게 말해 /16은 "10.9.으로 시작하는 모든 IP가 내 땅"이라는 선언입니다. 숫자가 작을수록(/16) 넓고, 클수록(/24) 좁습니다.

CIDR 자유 비트 IP 개수(대략) 비유
/16 16 65,536 큰 동네
/24 8 256 한 골목
/28 4 16 집 몇 채

CIDR 표기법 — 10.9.0.0/16과 10.9.1.0/24의 네트워크·호스트 비트


▲ 그림 2. /숫자는 앞에서 고정되는 네트워크 비트 수다. /16은 앞 16비트(2개 옥텟)가 고정되어 약 6.5만 IP, /24는 앞 24비트(3개 옥텟)가 고정되어 약 256 IP를 담는다.

왜 하필 사설 IP(10.x)인가?
10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16은 RFC1918이 정한 사설 대역으로, 인터넷에 직접 노출되지 않습니다.
모든 서버에 공인 IP를 직접 붙이면 IP 낭비·보안 노출이 커지므로, 안에서는 사설 IP를 쓰고 필요한 것만 골라 인터넷에 노출하는 게 표준입니다.

2-3. 대안과 선택

방법 설명 한계
기본 VPC(Default VPC) 계정 생성 시 AWS가 자동 제공 대역·구조가 고정, 학습/운영 통제 불가
커스텀 VPC(이 실습) 내가 CIDR·서브넷 직접 설계 직접 설계해야 함(=학습 효과)

실습이 커스텀 VPC를 만드는 이유는 명확합니다.

네트워크가 어떻게 구성되는지 직접 손으로 깔아봐야 L3가 체득되기 때문입니다.

운영 환경에서도 기본 VPC는 거의 쓰지 않고 커스텀 VPC를 설계합니다.

참고로 이 실습은 VPC를 두 개 만듭니다.
MyVPC(10.0.0.0/16)는 점프박스(MyEC2)용 관리망이고, ASG-VPC(10.9.0.0/16)가 실제 오토스케일링 무대입니다. 대역을 일부러 다르게(10.0 vs 10.9) 잡아 IP 충돌을 피한 점도 눈여겨볼 만합니다.

스택 생성이 끝나면 VPC 콘솔에서 두 VPC가 실제로 만들어졌는지 확인할 수 있습니다.

VPC 콘솔 — MyVPC(10.0.0.0/16)와 ASG-VPC(10.9.0.0/16)


▲ 그림 3. YAML의 CidrBlock이 그대로 반영되어 MyVPC(10.0.0.0/16)와 ASG-VPC(10.9.0.0/16) 두 개의 L3 울타리가 생성됐다.

3. Subnet — 가용영역(AZ)으로 땅을 쪼개기

3-1. 무엇인가

VPC라는 큰 울타리(/16)를 그대로 쓰지 않고, 더 작은 칸(서브넷)으로 나눕니다. 그리고 각 서브넷을 서로 다른 가용영역(AZ, 물리적으로 떨어진 데이터센터)에 배치합니다.

VPC1PublicSN1:
  Type: AWS::EC2::Subnet
  Properties:
    MapPublicIpOnLaunch: true
    VpcId: !Ref VPC1
    AvailabilityZone: !Select [ 0, !GetAZs '' ]   # 인덱스 0 → ap-northeast-2a
    CidrBlock: 10.9.1.0/24

VPC1PublicSN2:
  Properties:
    AvailabilityZone: !Select [ 2, !GetAZs '' ]   # 인덱스 2 → ap-northeast-2c
    CidrBlock: 10.9.2.0/24

 

!GetAZs ''는 "이 리전의 AZ 목록을 가져와라"는 함수이고, !Select [0, ...]은 그중 첫 번째(2a),

!Select [2, ...]은 세 번째(2c)를 고른다는 뜻입니다.

실습 콘솔 캡처에서도 apne2-az1(2a)과 apne2-az3(2c)로 확인됩니다.

3-2. 왜 두 AZ에 나누는가 — 이번 시리즈 전체를 떠받치는 설계

이게 가장 중요한 설계 결정입니다.

서브넷을 두 AZ에 두는 이유는 고가용성(High Availability) 때문입니다.

  • 한 AZ(데이터센터)에 정전·화재 같은 장애가 나도, 다른 AZ의 서버가 살아남아 서비스가 죽지 않습니다.
  • 뒤 편에서 다룰 ALB도, Auto Scaling Group도 반드시 2개 이상의 AZ에 걸쳐 배치됩니다.
    그 토대가 바로 여기서 만든 두 서브넷입니다.

만약 서브넷을 한 AZ에만 뒀다면, 그 AZ가 죽는 순간 오토스케일링이 아무리 서버를 늘려도 전부 같은 죽은 데이터센터 안이라 무용지물입니다. L3 설계 단계의 결정이 상위 계층의 가용성을 결정하는 것이죠.

3-3. MapPublicIpOnLaunch: true의 의미

이 옵션은 "이 서브넷에서 뜨는 인스턴스에 공인 IP를 자동 부여하라"는 뜻입니다.

그래서 이 서브넷을 퍼블릭 서브넷이라 부릅니다.

(정확히는, 공인 IP가 있고 + 라우팅이 IGW로 향해야 진짜 퍼블릭입니다 — 다음 장 참고.)

 

대안: 퍼블릭 vs 프라이빗 서브넷 실무에서는 보통 웹/로드밸런서는 퍼블릭 서브넷에, DB·내부 서버는 프라이빗 서브넷(IGW 라우팅 없음)에 둬서 보안을 강화합니다. 이 실습은 학습 단순화를 위해 모두 퍼블릭으로 뒀습니다.

 

 서브넷 목록


VPC 콘솔 > 서브넷에서
ASG-Public-SN1(10.9.1.0/24, ap-northeast-2a),
ASG-Public-SN2(10.9.2.0/24, ap-northeast-2c)가 서로 다른 AZ에 생성된 화면을 캡처해 넣으면,
"두 AZ 분산" 설계가 한눈에 드러납니다.

 

4. 라우팅 테이블 + 인터넷 게이트웨이 — 길 내기

4-1. 인터넷 게이트웨이(IGW)

IGW는 VPC와 인터넷을 연결하는 단 하나의 관문입니다. VPC에 붙여(attach)두기만 해서는 아무 일도 안 일어나고, 라우팅 테이블이 "인터넷행 트래픽을 IGW로 보내라"고 지시해야 비로소 통로가 열립니다.

VPC1IGW:
  Type: AWS::EC2::InternetGateway

VPCIGWAttachment:
  Type: AWS::EC2::VPCGatewayAttachment   # IGW를 VPC에 부착
  Properties:
    InternetGatewayId: !Ref VPC1IGW
    VpcId: !Ref VPC1

4-2. 라우팅 테이블 — L3 이정표

라우팅 테이블은 "이 목적지 IP 대역으로 가는 패킷은 어디로 보낼지"를 적은 표입니다.

VPC1DefaultPublicRoute:
  Type: AWS::EC2::Route
  DependsOn: VPCIGWAttachment
  Properties:
    RouteTableId: !Ref VPC1PublicRT
    DestinationCidrBlock: 0.0.0.0/0   # "전 세계 모든 IP(=인터넷)는"
    GatewayId: !Ref VPC1IGW           # "이 IGW로 내보내라"

 

0.0.0.0/0은 "모든 목적지"를 뜻하는 와일드카드입니다.

이 한 줄이 "VPC 내부 대역(10.9.x)이 아닌 모든 트래픽은 인터넷으로 나가라"는 규칙을 만듭니다.

패킷의 목적지 IP를 보고 경로를 정하는 일 — 이것이 L3 라우팅의 본질입니다.

4-3. 서브넷 ↔ 라우팅 테이블 연결

라우팅 테이블은 만들어 두는 것만으로는 부족하고, 어떤 서브넷에 적용할지 연결(association)해야 합니다.

VPC1PublicSN1RouteTableAssociation:
  Type: AWS::EC2::SubnetRouteTableAssociation
  Properties:
    RouteTableId: !Ref VPC1PublicRT
    SubnetId: !Ref VPC1PublicSN1

 

정리하면 "퍼블릭 서브넷"의 완성 조건은 세 가지입니다.

  1. 서브넷에서 공인 IP 부여(MapPublicIpOnLaunch: true)
  2. VPC에 IGW 부착
  3. 서브넷에 연결된 라우팅 테이블이 0.0.0.0/0 → IGW를 가짐

이 셋이 모두 갖춰져야 서브넷 안의 서버가 인터넷과 양방향 통신을 합니다.

 

퍼블릭 서브넷이 되는 3가지 조건

라우팅 테이블


VPC 콘솔 > 라우팅 테이블 > ASG-Public-RT의 라우팅 탭에서
10.9.0.0/16 → local과 0.0.0.0/0 → igw-xxxx 두 줄이 보이는 화면을 캡처해 넣으면,
"인터넷행 트래픽이 IGW로 향한다"는 L3 라우팅 규칙이 시각적으로 증명됩니다.


마지막으로, 위의 L3 토대가 모두 정상 생성됐는지는 CloudFormation 스택 상태가 CREATE_COMPLETE인 것으로 확인합니다.

CloudFormation 스택 ASG — CREATE_COMPLETE


▲ 그림 4. 스택 ASG가 CREATE_COMPLETE 상태가 되면 VPC·서브넷·라우팅·IGW 등 L3 토대가 모두 생성 완료된 것이다.

 

 

5. 이번 편 계층 종합표

구성요소 YAML 리소스 동작 계층(OSI) TCP/IP 근거 한 줄 역할
VPC AWS::EC2::VPC L3 인터넷 CIDR(IP 대역) 정의 사설 네트워크 울타리
Subnet AWS::EC2::Subnet L3 인터넷 IP 대역 + AZ 분할 AZ별 IP 칸
Internet Gateway AWS::EC2::InternetGateway L3 인터넷 IP 트래픽 관문 VPC↔인터넷 문
Route Table AWS::EC2::RouteTable/Route L3 인터넷 목적지 IP 기반 경로 패킷 이정표
Subnet 연결 SubnetRouteTableAssociation L3 인터넷 라우팅 적용 범위 표↔칸 매칭

 

한 문장 요약: 이번 편에서 만든 것은 전부 L3(IP·라우팅) 입니다. VPC로 주소 공간을 정의하고, 서브넷으로 AZ에 나누고, IGW+라우팅 테이블로 인터넷과의 길을 냈습니다. 아직 "포트"도 "HTTP"도 등장하지 않았다는 점에 주목하세요 — 그건 다음 편들의 몫입니다.

6. 실습 핵심 수치 (이번 편)

  • VPC: ASG-VPC = 10.9.0.0/16 (약 6.5만 IP) + 관리용 MyVPC = 10.0.0.0/16
  • 서브넷: 10.9.1.0/24 @ AZ-a(2a), 10.9.2.0/24 @ AZ-c(2c) — 각 256 IP
  • 라우팅: 0.0.0.0/0 → IGW (퍼블릭)
  • 퍼블릭 서브넷 3요소: 공인 IP 자동부여 + IGW 부착 + 0.0.0.0/0 라우팅

 

다음 편 예고

 

#2에서는 같은 VPC 안에서 한 계층 위로 올라갑니다.

보안 그룹(Security Group)이 어떻게 포트(L4)와 출발지 IP(L3)를 함께 보는 stateful 방화벽으로 동작하는지,

그리고 서브넷 단위의 NACL과 무엇이 다른지를 다룹니다. 키워드는 TCP 22/80 포트와 stateful vs stateless입니다.

이번 편 한 줄 복습: L3은 "어느 IP로, 어떤 길로?"를 정하는 계층 — VPC(울타리) · 서브넷(AZ별 칸) · 라우팅+IGW(길)로 클라우드의 땅을 깔았다.

시리즈 #1 끝 · 다음 편: 보안 그룹 vs NACL — L4 방화벽의 원리

저작자표시 (새창열림)

'클라우드 컴퓨팅 > AWS' 카테고리의 다른 글

[AWS 네트워크 계층으로 읽기 #3] ALB 완전 분석 — L7 로드밸런서는 왜 URL을 읽는가  (0) 2026.06.15
[AWS 네트워크 계층으로 읽기 #2] 보안 그룹 vs NACL — L4 방화벽의 원리  (0) 2026.06.15
실습 2-4 _ ELB 실습 ④편 — 출발지 IP 보존  (1) 2026.06.09
실습 2-2 _ ELB 실습 ②편 — ALB  (0) 2026.06.08
실습 2-1_ ELB 실습 ①편 — 환경 구성  (0) 2026.06.08

티스토리툴바