AWS Network

2SEONGA·2025년 2월 14일
awsnetwork

AWS

목록 보기
3/6
post-thumbnail

1. 네트워크 개요: CIDR, OSI

(1) 네트워크를 배워야 하는 이유

클라우드 환경에서도 여전히 네트워크 구성을 해야 하며, IP 주소 체계를 이해하기 위해 CIDR을, 네트워크 장비 및 데이터 흐름을 이해하기 위해 OSI 7 계층 모델을 알아야 한다.

(2) CIDR (Classless Inter-Domain Routing)

CIDR은 IP 주소 범위를 표현하는 방식으로, 두 가지 요소로 구성
1. Base IP : 사용 가능한 첫 번째 IP 주소
2. Subnet Mask : 고정된 주소 영역을 나타내며, 보통 /24처럼 간단히 표기

  • 사전 지식 :
    네트워크 주소 구성 = 4개의 옥텟(1바이트 = 8비트) = 총 4바이트 (32비트)

    10.0.0.0 ~ 10.0.0.255 →10.0.0.0/24
    기존 네트워크는 A, B, C 클래스로 나뉘었으나,
    CIDR 방식에서는 Classless (클래스 구분 없음)으로 표현 가능

💡 AWS 네트워크의 시작 = VPC 설정

  • AWS에서 네트워크를 구성하려면 먼저 VPC의 CIDR 정의
  • 서브넷을 설정하여 네트워크를 세분화하는 데 사용

사용 사례

  1. VPC 및 서브넷 구성: 사용할 가용 IP 대역 정의 = 몇 개의 IP 를 사용할 것 인지
    ex) AWS VPC 에서 네트워크를 설정하고 (몇개 쓸게요) 서브넷으로 네트워크 영역을 나눌때 CIDR 사용

  2. 라우팅 규칙 설정: Route Table 규칙 내 특정 서브넷에 대한 트래픽을 어디로 보낼지 Destination 정의 및 서브넷 명시
    ex ) 본 Route Table 은 10.1.10.0/24 서브넷에 적용하고, 0.0.0.0/0 에 대한 요청은 IGW 로 보낸다.

  • VPC 설정 : 10.1.0.0/16 (전체 네트워크)
  • 서브넷 분할 : 10.1.1.0/24, 10.1.2.0/24
  • 라우팅 테이블 : 10.1.10.0/24 서브넷에서 0.0.0.0/0 (인터넷 전송)

(3) OSI 7 계층 (Open System Interconnect)

OSI 7 계층을 배우는 이유

네트워크 장비(스위치, 라우터 등)는 OSI 모델의 특정 계층에서 동작하며, 이 계층을 이해하면 네트워크 구성 및 트러블슈팅이 쉬워진다.

L3 장비 (라우터): IP 주소 기반 네트워크 경로 결정
L2 장비 (스위치): MAC 주소 기반 내부 네트워크 연결
L1 장비 (케이블, 신호 전송)

OSI 주요 4 계층

[ 사진 출처 : What is OSI Model | Real World Examples ]

계층이름주요 역할예시
7Application (응용 계층)HTTP 요청 처리HTTP, SMTP, WebSocket, OAuth
4Transport (전송 계층)IP + Port 기반 통신TCP (신뢰성), UDP (비신뢰성)
3Network (네트워크 계층)IP 기반 패킷 전송IP, ICMP
2Data Link (데이터 링크 계층)MAC 주소 기반 전달Ethernet, ARP

TCP vs UDP
TCP 는 잘받았는지 여부를 SYN 로 서버가 확인하는데, UDP 는 확인하지 않는다 (만약 확인한다면 역 DDoS)

  • TCP : 신뢰성 높은 데이터 전송 (예: 웹사이트 접속)
  • UDP : 빠른 전송, 신뢰성 없음 (예: 유튜브 영상 스트리밍)

OSI 계층 기반 네트워크 장비


장비OSI 계층주요 기능
Switch (스위치)L2 (Data Link)MAC 주소 기반 내부 네트워크 연결
Router (라우터)L3 (Network)IP 주소 기반 외부 네트워크 연결
L4 Load BalancerL4 (Transport)IP + Port 기반 트래픽 분산
L7 Load BalancerL7 (Application)HTTP 요청 기반 트래픽 분산, DDoS 방어

💡 클라우드 환경에서도 네트워크 장비 개념이 그대로 적용

  • AWS에서는 실제 물리 장비가 없어도 라우팅 테이블, VPC, 서브넷, 로드 밸런서 설정을 통해 네트워크를 구성

2. AWS VPC에서 시작하는 네트워크 구성 + Bastion / NAT Instance

(1) AWS에서 네트워크를 구성하는 이유

AWS 클라우드 서버를 사용하려면 먼저 IP 주소를 할당할 네트워크를 만들어야 한다.
이를 위해 AWS VPC (Virtual Private Cloud)를 생성하며, 이는 서버들이 사용할 IP 대역을 결정하는 과정이다.

VPC는 기본적으로 Private Network이므로, 외부와 연결하려면 IGW (Internet Gateway) 및 Route Table 설정이 필요하다.
또한, 내부 서버가 외부와 통신하려면 NAT Gateway/Instance를, 외부에서 내부 서버에 접근하려면 Bastion 서버를 활용해야 한다.

(2) 물리 서버 vs AWS 네트워크

  • 과거 물리 서버 환경
    90년대에는 물리적 공간에 서버를 배치하고, 직접 네트워크를 구성해야 했다.
  1. 물리적 공간
  2. 물리적 서버 (서버 개수만큼 직접 설치)
  3. 물리적 네트워크 관리 (라우터, 스위치 설정)
  • AWS 환경
    AWS에서는 위의 과정이 모두 가상화되어 VPC를 생성하는 것만으로 논리적 네트워크를 쉽게 구성할 수 있다.
  1. 논리적 서버 (EC2 인스턴스)
  2. 논리적 네트워크 (VPC, 서브넷)

(3) VPC (Virtual Private Cloud) : 클라우드 인트라넷 + 서브넷 구성

먼저 VPC를 생성하고, 네트워크를 서브넷(Subnet)으로 나눈다.

  1. 가장 먼저 저는 IP 약 1000개 쓸겁니다. 주십시오! 열심히 해보겠습니다. 하며 AWS VPC 생성하고,
  2. 그 이후에 AWS VPC 이란 케익을 조각케익으로 자르듯이 세부적으로 서브넷들로 나눈다.

일반적으로 하나의 VPC에 4개의 서브넷을 구성한다.

  • Private Subnet : 내부 네트워크 전용

    • Private “Server” Subnet
    • Private “Database” Subnet

  • Public Subnet : 내부 네트워크 전용

  • Private, Public Subnet 각각 2개 (Multi-AZ 고려)

    • Private 서브넷 1번 → ap-northeast-2a
    • Private 서브넷 2번 → ap-northeast-2b
    • Public 서브넷 1번 → ap-northeast-2a
    • Public 서브넷 2번 → ap-northeast-2b

⚠️ 주의 : 서브넷의 이름만으로 Public/Private이 결정되지 않으며, Route Table 설정이 필요하다.

AWS VPC 네트워크를 1.0.0.0/24 로 정의하고 서브넷을 4개로 쪼개어 사용한다면 아래와 같다.

(4) IGW (Internet Gateway) 설정

IGW : VPC 내부 서버가 외부와 통신할 수 있게

인스턴스 단위 외부 IP 할당 (외부 IP ↔ 단일 내부 IP 주소변환)

  • VPC 내부 서버가 외부와 양방향으로 접근 가능하도록 열어주는 말 그대로의 Gateway
    • 내부 IP 가 외부 IP 로 변경되는 NAT 주소 변환 제공
  • IGW가 VPC에 연결되었더라도, Route Table에서 IGW를 목적지로 지정해야 한다.

Route Table 예

  • 모든 트래픽(0.0.0.0/0)은 IGW를 통해 나가도록 설정

Public Subnet 성질 부여 : IGW + Route Table

먼저 VPC 에 IGW 를 붙여 톨게이트를 열어준뒤, 그 다음 Route Table 을 통해 IGW 와 Public Subnet 을 연결

  • IGW 만 VPC 에 붙인다고 Public Subnet 이 자동으로 외부와 통신 불가
    • Public Subnet 에 모든 트래픽을 IGW 과 연결하기 위한 Route Table 설정 필요
  • Route Table 이란 무엇인가?
    Public / Private Subnet 에 연결하며, 해당 Subnet 내 서버에서 요청 발생시 어디로 가야하는지를 알려주는 역할
    • Destination, 요청이 향하는 방향에 따라 → Target, 어디로 향해야하는지
      • 비유 : Destination, 여행객이 “비행기” 를 타러간다 → Target, “인천 공항으로 가세요”
      • 실제 : Destination, 서브넷 내 서버가 0.0.0.0/0 에 요청 전달 → Target, “IGW” 로 가시오

  • Route Table 설정 방법 상세

    1. 본 Route Table 을 어떤 Subnet 에 연결 : 본 라우팅 규칙을 어떤 서브넷 대상으로 할것인가?

      • = bootstrap-dev-public-subnet-1 와 bootstrap-dev-public-subnet-0 에 대해

        개발자가 직접 만든 Route Table 을 Subnet 에 직접 명시적 연결 = Explicit Subnet Associations

      • Route Table 은 서브넷에 크게 2개의 방법으로 연결된다.

        • 명시적 연결 : 직접 생성한 Route Table 을 만들어서 → 명시적으로 Subnet 에 할당
        • 비명시적 연결 : 디폴트 Route Table - 를 → 자동(비명시적)으로 Subnet 에 할당

          Route Table 을 따로 정의하지 않고도, VPC 가 동작되어 Route Table 이 정의되어있지 않으면 알아서 라우팅되는줄 알았는데, 그게 아니었다. VPC 기본 Route Table 에 따라 라우팅되고 있던 것

    2. Route 설정 : 경로 정의를 어떻게 할것인가?

      • Destination, 요청이 향하는 방향에 따라 : 모든 요청에 대해 = 0.0.0.0/0
        • 앞서 CIDR 배운것을 기반으로 “모든 트래픽” = 0.0.0.0/0 에 적용할것
      • Target, 어디로 향해야하는지 : IGW 로 보내거라 = igw-0d6d92d318c5b7f71

업로드중..

(5) NAT Gateway/Instance : VPC 내부 서버가 외부로 통신할 수 있게


NAT Gateway / Instance : 서브넷 단위 외부 IP 할당 (외부 IP ← 서브넷 (다수 내부 IP 들) 주소변환)

  • VPC 내부 서브넷 내 모든 서버가 외부와 단방향(아웃바운드)으로 접근 가능하도록 열어주는 Gateway
  • NAT Instance : Public 서브넷 내 인스턴스 두어, Private 서브넷 내 모든 서버들에게 단일 Public IP 할당

Private Subnet 에게 Public IP 부여 : NAT Gateway/Instance + Route Table

Private 서브넷이 외부와 통신을 어쩔수없이 해야하는 경우가 2가지 중 첫번째 : NAT Gateway/Instance

  • NAT Gateway: AWS에서 제공하는 관리형 서비스
  • NAT Instance: EC2 인스턴스를 NAT 역할로 사용 (추가 설정 필요)
  • 사용 사례
    • 내부 서버가 npm install 또는 gradle build를 실행할 때 외부 접속 필요
      • 아웃바운드 : 이때는 NAT Gateway 혹은 Instance 를 통해 밖으로 나갈 단방향(아웃바운드) 문이 필요

NAT Gateway/Instance 동작 원리 : IP Masquerading

NAT Gateway/Instance 는 Private EC2 로부터 온 네트워크 패킷을 재작성(IP 변조)하여, 외부와 대신 통신

  • “외부와 대신 통신을 해준다”는 관점에서 NAT 와 Proxy 가 같은것으로 오해할 수 있지만, 다른것이다.
    • NAT : Layer 3/4 기반 + 다수의 Private IP 들을 Public IP 로 변환 (네트워크 패킷 재작성, IP 변조)
    • Proxy : Layer 7 기반 + 다양한 보안 관련 기능들 제공


사진 출처 : PROXY vs NAT – Understand the Difference

⚠️ NAT Instance 주의점

  • Source/Destination Check 비활성화 필요
  • EC2 성능 제한으로 인해 대역폭이 낮음

(6) VPC 내부 서버로 외부에서 통신할 수 있게 : SSH Tunneling Bastion

SSH Tunneling = Port Forwarding, Jump Box/Host/Server, Bastion : 외부 서버 통한 내부 접근

  • Private 서브넷 내 위치한 서버에 인바운드 접근을 위해 외부 서버 Bastion 통해 단방향(인바운드) 연결

Public 에서 Private Subnet 로 접속 : Bastion + Route Table

Private 서브넷이 외부와 통신을 어쩔수없이 해야하는 경우가 2가지 중 나머지 : SSH Tunneling (Bastion)

  1. Private 서브넷에 외부 개발자 컴퓨터에서 SSH 을 통해 접근이 가능해야할때
    • 인바운드 : 이때는 SSH Tunneling (Bastion) 을 통해 밖에서 안으로 들어올 문을 연다.

SSH Tunneling (= Port Forwarding) : Bastion 동작 원리

SSH Tunneling 을 Jump Box, Jump Host, Jump Server 이라고도 부르는 이유는
외부에서 Private 서브넷 내 서버에 접근하기 위해 Public 서브넷 내 서버를 디딤돌 삼아 점프를 하는 것 같기 때문에

Local → Bastion (Public 서브넷 내 존재) → Server (Private 서브넷 내 존재)

ssh -i "local-to-bastion.pem" -N -L 33322:{target-private-ip}:22 ec2-user@{bastion-host-public-ip}
  • 33322 : 로컬 포트 지정
  • {target-private-ip}:22 : Private 서버의 SSH 포트
  • {bastion-host-public-ip} : Bastion 서버의 공인 IP

⚠️ Bastion 서버를 통해서만 Private 서버로 접근할 수 있도록 보안 설정 필요

SSH Tunneling (Bastion) 동작 원리 : Private Key - Public Key Pair

SSH 접속을 위한 비공개-공개 키 페어 : "local-to-bastion.pem" 와 "local-to-private.pem" 의미

  • (5) local-to-bastion.pem : Local → Bastion (Public 서브넷 내 존재)
  • (2) local-to-private.pem : Local → Server (Private 서브넷 내 존재)

⚠️ 주의 : HTTPS 와 SSH 에서 Secured 로 비대칭키를 활용하나, 공개키와 비공개키를 가진 주체가 반대

  • HTTPS : 클라이언트가 공개키 Public Key, 서버가 비공개키 Private Key 를 가짐
  • SSH : 클라이언트가 비공개키 Private Key(.pem), 서버가 공개키 Public Key(.pub) 를 가짐

두 가지 방법 정리

"Private 서브넷의 인터넷 및 SSH 접근 방식"

  • Outbound (인터넷 접근) - NAT Gateway/Instance 사용
    Private 서브넷의 인스턴스가 외부 인터넷에 접근할 때 NAT Gateway 또는 NAT Instance를 경유
    Public 서브넷에 NAT이 위치하며, IGW(Internet Gateway)를 통해 인터넷과 연결
  • Inbound (SSH 접속) - Bastion Host 사용
    Private 서브넷의 인스턴스는 직접 인터넷에서 접근 불가
    Public 서브넷에 Bastion Host를 두고, SSH 터널링을 통해 Private 서브넷의 인스턴스에 접속
profile
2SEONGA
(와.. 정말 Chill하다..)
이전 포스트

AWS Cloud

다음 포스트

AWS Cloud Service 종류

0개의 댓글