[AWS] 인프라 구축 Subnet / Route Table / Internet Gateway

백엔드·2025년 9월 28일

AWS 네트워크

목록 보기

4/4

1.1. VPC 생성: 나만의 격리된 클라우드 공간

네트워크 구축의 첫 단계는 모든 구성 요소를 담을 논리적인 컨테이너, 즉 VPC를 생성하는 것입니다.

AWS 관리 콘솔에 로그인하여 서비스 검색창에 'VPC'를 입력하고 VPC 대시보드로 이동합니다.
'VPC 생성' 버튼을 클릭합니다. VPC 설정 화면에서 'VPC만' 옵션을 선택하여 마법사의 도움 없이 수동으로 생성 프로세스를 시작합니다. 이 선택은 서브넷이나 라우팅 테이블 같은 부가적인 리소스 없이 순수한 VPC 경계만을 정의하겠다는 의미입니다.
이름 태그 필드에 my-vpc를 입력합니다. 태그는 AWS 리소스를 식별하고, 비용을 추적하며, 접근 제어를 관리하는 데 필수적인 모범 사례입니다.
IPv4 CIDR 블록 필드에 10.0.0.0/16을 입력합니다. CIDR(Classless Inter-Domain Routing)은 IP 주소 범위를 표현하는 방식으로, 10.0.0.0/16은 10.0.0.0부터 10.0.255.255까지 총 65,536개의 IP 주소를 포함하는 거대한 주소 공간을 의미합니다. 이 대역은 RFC 1918에 정의된 사설 IP 대역으로, 인터넷을 통해 직접 라우팅되지 않아 내부 네트워크용으로 안전하게 사용할 수 있습니다.
테넌시 옵션은 '기본값'으로 유지합니다. 이는 VPC 내에 생성될 인스턴스들이 다른 AWS 고객과 물리적 하드웨어를 공유하는 멀티테넌트 환경에서 실행됨을 의미합니다.
'VPC 생성' 버튼을 클릭하여 완료합니다.

VPC와 서브넷의 CIDR 블록을 정의하는 것은 단순히 IP 주소를 할당하는 기술적 절차를 넘어섭니다. 이는 미래의 확장성, 서비스 간의 네트워크 분리, 보안 정책 적용의 기반을 마련하는 근본적인 아키텍처 설계 행위입니다. 예를 들어, 10.0.0.0/16이라는 넓은 주소 공간을 선택하는 것은 향후 더 많은 서브넷이나 IP 주소를 대량으로 필요로 하는 서비스(예: Kubernetes 클러스터)를 추가할 때 발생할 수 있는 IP 고갈 문제를 미연에 방지하는 전략적 결정입니다. VPC의 CIDR 블록은 한번 생성되면 변경이 불가능하므로, 초기의 신중한 계획은 미래에 발생할 수 있는 값비싼 마이그레이션 작업을 예방하는 중요한 설계 과정입니다.

1.2. 서브넷 분할: 네트워크 구획 나누기

VPC라는 큰 땅을 확보했으니, 이제 용도에 맞게 구획을 나누는 서브넷 생성 단계로 넘어갑니다.

VPC 대시보드의 왼쪽 탐색 창에서 '서브넷'을 선택하고 '서브넷 생성' 버튼을 클릭합니다.
VPC ID 드롭다운 메뉴에서 방금 생성한 my-vpc를 선택하여 이 서브넷이 속할 VPC를 지정합니다.
퍼블릭 서브넷 (my-public-subnet) 생성:
- 서브넷 이름: my-public-subnet
- 가용 영역(Availability Zone): 목록에서 특정 가용 영역(예: us-east-1a)을 선택합니다. 가용 영역은 물리적으로 분리된 데이터 센터로, 여러 가용 영역에 리소스를 분산 배치하는 것은 고가용성 아키텍처의 기본입니다.
- IPv4 CIDR 블록: 10.0.1.0/24를 입력합니다. 이 주소 범위는 VPC의 전체 CIDR 블록(10.0.0.0/16)에 반드시 포함되어야 합니다. /24 접미사는 256개의 IP 주소를 제공합니다 (AWS 예약 주소 제외 시 251개 사용 가능).
화면 하단의 '새 서브넷 추가' 버튼을 클릭하여 동일한 페이지에서 프라이빗 서브넷 생성을 계속합니다.
프라이빗 서브넷 (my-private-subnet) 생성:
- 서브넷 이름: my-private-subnet
- 가용 영역: 고가용성을 위해 다른 가용 영역(예: us-east-1b)을 선택하는 것이 권장되지만, 이 가이드의 목적상 동일한 가용 영역을 선택해도 무방합니다.
- IPv4 CIDR 블록: 10.0.2.0/24를 입력합니다. 이 범위는 이전에 생성한 서브넷의 범위와 겹치지 않아야 합니다.
모든 정보를 확인한 후 '서브넷 생성' 버튼을 클릭하여 두 개의 서브넷 생성을 완료합니다.

2.1. 인터넷 게이트웨이(IGW): 세상으로 통하는 문

VPC와 서브넷은 기본적으로 격리된 공간입니다. 인터넷과 통신하기 위해서는 '문' 역할을 하는 인터넷 게이트웨이를 생성하고 VPC에 연결해야 합니다.

VPC 대시보드의 '인터넷 게이트웨이' 섹션으로 이동하여 '인터넷 게이트웨이 생성'을 클릭합니다.
이름 태그에 my-igw를 입력하고 게이트웨이를 생성합니다.
생성 직후 IGW의 상태는 'detached'(분리됨)로 표시됩니다. 새로 생성된 my-igw를 선택한 상태에서 우측 상단의 '작업' 드롭다운 메뉴를 열고 'VPC에 연결'을 선택합니다.
사용 가능한 VPC 목록에서 my-vpc를 선택하고 '인터넷 게이트웨이 연결' 버튼을 클릭합니다. 이제 IGW는 my-vpc의 가상 경계에 부착되어 인터넷 트래픽을 처리할 준비가 되었습니다. IGW는 VPC와 인터넷 간의 양방향 통신을 가능하게 하는 고가용성의 완전 관리형 VPC 구성 요소입니다.

2.2. 퍼블릭 라우팅 테이블: 인터넷 트래픽 라우팅

인터넷 게이트웨이가 설치되었지만, 서브넷의 트래픽이 그곳으로 가야 한다는 것을 알려주지 않으면 아무 소용이 없습니다. 이 '교통 규칙'을 정의하는 것이 라우팅 테이블입니다.

VPC 대시보드의 '라우팅 테이블'로 이동합니다. VPC를 생성하면 기본적으로 '기본(Main)' 라우팅 테이블이 하나 생성되어 있지만, 역할을 명확히 구분하고 관리하기 위해 퍼블릭 서브넷 전용 라우팅 테이블을 새로 생성합니다.
'라우팅 테이블 생성'을 클릭합니다.
- 이름: my-public-rtb
- VPC: my-vpc를 선택하고 생성합니다.
생성된 my-public-rtb를 선택하고, 화면 하단의 '경로(Routes)' 탭으로 이동하여 '경로 편집' 버튼을 클릭합니다.
'경로 추가'를 클릭하고 다음 정보를 입력합니다:
- 대상(Destination): 0.0.0.0/0. 이 표기법은 '모든 IP 주소'를 의미하며, 구체적으로는 VPC 내부 CIDR(10.0.0.0/16)에 해당하지 않는 모든 외부 트래픽을 지칭합니다.
- 대상(Target): 드롭다운 메뉴에서 '인터넷 게이트웨이'를 선택한 후, 나타나는 목록에서 my-igw를 선택합니다.
'변경 사항 저장'을 클릭합니다. 이 0.0.0.0/0 -> igw-... 경로 규칙이 바로 이 라우팅 테이블과 연결된 서브넷을 '퍼블릭'으로 만드는 핵심 정의입니다.
이제 이 라우팅 테이블을 퍼블릭 서브넷에 연결합니다. '서브넷 연결(Subnet Associations)' 탭으로 이동하여 '서브넷 연결 편집'을 클릭합니다.
서브넷 목록에서 my-public-subnet 앞의 체크박스를 선택하고 '연결 저장'을 클릭합니다. 이제 my-public-subnet 내에서 발생하는 모든 외부행 트래픽은 IGW를 통해 인터넷으로 전달됩니다.

2.3. NAT 게이트웨이: 안전한 아웃바운드 전용 통로

프라이빗 서브넷의 리소스는 보안을 위해 외부에서 직접 접근할 수 없어야 하지만, OS 업데이트나 외부 서비스 연동을 위해 인터넷으로 나가는 연결은 필요할 수 있습니다. NAT 게이트웨이는 프라이빗 서브넷의 리소스들이 외부 인터넷에 아웃바운드 요청을 보낼 수 있도록 허용하면서, 외부에서 먼저 연결을 시작하는 인바운드 트래픽은 차단하는 역할을 수행합니다.

1단계: 탄력적 IP(Elastic IP) 할당: NAT 게이트웨이는 고정된 공인 IP 주소가 필요합니다. VPC 대시보드의 '탄력적 IP' 섹션으로 이동하여 '탄력적 IP 주소 할당'을 클릭합니다. 기본 설정을 그대로 두고 '할당' 버튼을 누릅니다. 이 EIP는 NAT 게이트웨이를 통해 나가는 모든 트래픽의 소스 IP 주소가 됩니다.

2단계: NAT 게이트웨이 생성:

'NAT 게이트웨이' 섹션으로 이동하여 'NAT 게이트웨이 생성'을 클릭합니다.
이름: my-nat-gw
서브넷: my-public-subnet을 선택합니다. 이는 매우 중요한 설정입니다. NAT 게이트웨이 자체는 인터넷과 통신해야 하므로, 반드시 인터넷 게이트웨이로의 경로가 있는 퍼블릭 서브넷에 위치해야 합니다.
연결 유형: '퍼블릭'으로 유지합니다.
탄력적 IP 할당 ID: 드롭다운 목록에서 방금 생성한 EIP를 선택합니다.
'NAT 게이트웨이 생성'을 클릭합니다. 상태가 'Available'이 될 때까지 몇 분 정도 소요될 수 있습니다.

2.4. 프라이빗 라우팅 테이블: 내부 트래픽 제어

이제 프라이빗 서브넷의 외부행 트래픽을 방금 생성한 NAT 게이트웨이로 보내도록 라우팅 규칙을 설정해야 합니다.

'라우팅 테이블' 섹션에서 '라우팅 테이블 생성'을 다시 클릭합니다.
- 이름: my-private-rtb
- VPC: my-vpc를 선택하고 생성합니다.
생성된 my-private-rtb를 선택하고, '경로(Routes)' 탭에서 '경로 편집'을 클릭합니다.
'경로 추가'를 클릭하고 다음 정보를 입력합니다:
- 대상(Destination): 0.0.0.0/0
- 대상(Target): 드롭다운 메뉴에서 'NAT 게이트웨이'를 선택하고, 목록에서 my-nat-gw를 선택합니다.
'변경 사항 저장'을 클릭합니다.
'서브넷 연결' 탭으로 이동하여 '서브넷 연결 편집'을 클릭하고, my-private-subnet을 선택한 후 '연결 저장'을 클릭합니다.

이 과정에서 AWS 네트워킹의 매우 중요한 원리를 발견할 수 있습니다. '퍼블릭' 또는 '프라이빗' 서브넷은 서브넷 자체에 부여된 고정된 속성이 아닙니다. 서브넷의 정체성은 전적으로 그 서브넷과 연결된 라우팅 테이블의 규칙에 의해 결정되는 동적인 '행동 방식'입니다. 라우팅 테이블에 인터넷 게이트웨이로 향하는 경로가 있으면 그 서브넷은 퍼블릭처럼 행동하고, NAT 게이트웨이로 향하는 경로가 있으면 아웃바운드 통신이 가능한 프라이빗 서브넷처럼 행동합니다.

만약 my-private-subnet에 연결된 라우팅 테이블을 my-public-rtb로 교체한다면, 그 서브넷은 즉시 퍼블릭 서브넷으로 기능하게 됩니다. 따라서 네트워크 아키텍처와 보안의 핵심은 서브넷 자체가 아니라, 트래픽 흐름을 제어하는 '규칙의 집합'인 라우팅 테이블을 어떻게 구성하고 관리하느냐에 달려 있습니다.

3.1. 퍼블릭 EC2 인스턴스 배포

이제 네트워크 인프라 위에 실제 컴퓨팅 리소스인 EC2 인스턴스를 배치합니다.

AWS 관리 콘솔에서 EC2 대시보드로 이동하여 '인스턴스 시작'을 클릭합니다.
이름: public-web-server
애플리케이션 및 OS 이미지 (AMI): 'Amazon Linux 2023' (또는 최신 Amazon Linux)을 선택합니다.
인스턴스 유형: 프리 티어 사용이 가능한 t2.micro를 선택합니다.
키 페어(로그인): 새 키 페어를 생성하고 .pem 파일을 로컬 컴퓨터의 안전한 곳에 다운로드합니다. 이 파일은 나중에 SSH를 통해 인스턴스에 접속할 때 사용되는 암호화 키입니다.
네트워크 설정: '편집' 버튼을 클릭하여 세부 설정을 엽니다.
- VPC: my-vpc를 선택합니다.
- 서브넷: my-public-subnet을 선택합니다.
- 퍼블릭 IP 자동 할당: '활성화'로 설정합니다. 이 설정은 인스턴스가 시작될 때 인터넷에서 직접 접근 가능한 공인 IP 주소를 할당받도록 합니다.
방화벽(보안 그룹): '새 보안 그룹 생성'을 선택합니다.
- 보안 그룹 이름: public-sg
- 인바운드 보안 그룹 규칙:
  - 규칙 1: 유형 'SSH', 소스 '내 IP' (보안 강화를 위해 현재 사용자의 IP만 허용) 또는 테스트 목적으로 'Anywhere-IPv4' (0.0.0.0/0).
  - 규칙 2: '규칙 추가'를 클릭하고, 유형 'HTTP', 소스 'Anywhere-IPv4' (0.0.0.0/0)를 추가합니다. 이 규칙은 모든 IP 주소로부터의 웹 트래픽(포트 80)을 허용합니다.
고급 세부 정보 섹션을 확장하고 사용자 데이터 필드에 아래 스크립트를 붙여넣습니다. 이 스크립트는 인스턴스가 처음 부팅될 때 자동으로 실행되어 아파치 웹 서버를 설치하고 간단한 테스트 페이지를 생성합니다.
```
#!/bin/bash 
sudo yum update -y
sudo yum install -y httpd
sudo systemctl start httpd
sudo systemctl enable httpd
```
'인스턴스 시작'을 클릭하여 배포를 완료합니다.

3.2. 프라이빗 EC2 인스턴스 배포

다음으로 외부 접근이 차단된 프라이빗 서브넷에 인스턴스를 배포합니다.

다시 '인스턴스 시작'을 클릭합니다.
이름: private-app-server
AMI 및 인스턴스 유형: 퍼블릭 인스턴스와 동일하게 선택합니다.
키 페어(로그인): 이전에 생성한 키 페어를 그대로 선택합니다.
네트워크 설정: '편집'을 클릭합니다.
- VPC: my-vpc
- 서브넷: my-private-subnet
- 퍼블릭 IP 자동 할당: '비활성화'로 설정합니다. 이 설정이 인스턴스를 외부에서 직접 접근할 수 없게 만드는 핵심적인 조치입니다.
방화벽(보안 그룹): '새 보안 그룹 생성'을 선택합니다.
- 보안 그룹 이름: private-sg
- 인바운드 보안 그룹 규칙: 기본적으로 제안되는 모든 인바운드 규칙을 삭제합니다. 우리는 EC2 Instance Connect Endpoint를 통해 접속할 것이므로, 지금 당장 SSH 포트를 열 필요가 없습니다. (다음 단계에서 설정합니다.)
'인스턴스 시작'을 클릭합니다.

3.3. EC2 Instance Connect Endpoint를 통한 프라이빗 접근 설정

프라이빗 인스턴스에 안전하게 접근하기 위해, 인터넷을 거치지 않는 비공개 통로인 EC2 Instance Connect Endpoint를 생성하고 보안 그룹을 설정합니다.

EC2 Instance Connect Endpoint란 무엇인가? 🔗

VPC 엔드포인트는 AWS의 내부 네트워크망을 이용해 여러분의 VPC와 특정 AWS 서비스를 직접 연결하는 비공개 통로입니다. EC2 Instance Connect Endpoint는 이 통로를 이용해, 인터넷에 노출되지 않은 프라이빗 EC2 인스턴스에 브라우저 기반의 SSH 접속을 가능하게 해주는 기능입니다.

동작 방식:

사용자가 AWS 콘솔에서 연결을 요청하면, 요청은 먼저 EC2 Instance Connect 서비스로 갑니다.
이 서비스는 VPC 내부에 생성된 엔드포인트(비공개 통로)를 찾아냅니다.
서비스는 이 엔드포인트를 통해 AWS 내부망 안에서만 작동하는 안전한 암호화 터널을 프라이빗 인스턴스의 22번 포트까지 생성합니다.
결과적으로, 인스턴스는 공인 IP가 전혀 없어도 안전하게 SSH 접속이 가능해집니다.

1단계: EC2 Instance Connect Endpoint 생성

VPC 대시보드로 이동하여 왼쪽 메뉴에서 '엔드포인트(Endpoints)'를 선택합니다.
'엔드포인트 생성(Create Endpoint)' 버튼을 클릭합니다.
'서비스 카테고리'에서 'EC2 Instance Connect Endpoint'를 선택합니다.
VPC는 my-vpc를 선택합니다.
보안 그룹 섹션에서 '새 보안 그룹 생성' 링크를 클릭하여 eic-endpoint-sg 라는 이름의 새 보안 그룹을 만듭니다. (기본 규칙 그대로 생성)
서브넷은 my-private-subnet을 선택하고 '엔드포인트 생성'을 클릭합니다.

2단계: 보안 그룹 규칙 설정 🔐

가장 중요한 단계입니다. private-app-server와 eic-endpoint-sg 보안 그룹이 서로 통신할 수 있도록 규칙을 설정합니다.

프라이빗 인스턴스 보안 그룹 (private-sg) 설정:
1. EC2 대시보드의 '보안 그룹' 메뉴로 이동하여 private-sg를 선택합니다.
2. '인바운드 규칙' 탭 > '인바운드 규칙 편집'을 클릭합니다.
3. '규칙 추가'를 클릭하고 아래와 같이 설정합니다.
  - 유형: SSH
  - 소스: 사용자 지정(Custom)을 선택하고, 방금 생성한 엔드포인트의 보안 그룹 *eic-endpoint-sg를 선택합니다.
4. 규칙을 저장합니다. 이 규칙의 의미는 "오직 EC2 Instance Connect Endpoint를 통해서만 SSH 접속을 허용하겠다"는 뜻입니다.
엔드포인트 보안 그룹 (eic-endpoint-sg) 설정:
1. eic-endpoint-sg 보안 그룹을 선택합니다.
2. '아웃바운드 규칙' 탭 > '아웃바운드 규칙 편집'을 클릭합니다.
3. 기존 규칙을 편집하거나 새 규칙을 추가하여 아래와 같이 설정합니다.
  - 유형: SSH (또는 모든 TCP)
  - 대상: 사용자 지정(Custom)을 선택하고, 프라이빗 인스턴스의 보안 그룹 *private-sg를 선택합니다.
4. 규칙을 저장합니다. 이 규칙의 의미는 "이 엔드포인트는 private-sg를 가진 리소스로 SSH 통신을 시작할 수 있다"는 뜻입니다.

4.1. 퍼블릭 인스턴스 연결성 테스트

public-web-server가 외부 인터넷에서 접근 가능(Inbound)하고, 외부 인터넷으로 나갈 수 있는지(Outbound) 확인합니다.

방법 1 (웹 브라우저를 통한 Inbound 테스트):
1. EC2 콘솔에서 public-web-server를 선택하고, 세부 정보 탭에서 '퍼블릭 IPv4 주소'를 복사합니다.
2. 웹 브라우저 주소창에 http://<복사한_IP_주소>를 입력하고 엔터를 누릅니다.
3. 화면에 "It works!" 메시지가 나타나면, 인터넷 게이트웨이를 통한 인바운드 트래픽과 public-sg 보안 그룹의 HTTP(80) 규칙이 정상적으로 작동함을 의미합니다.
방법 2 (SSH 및 Ping을 통한 Outbound 테스트):
1. 로컬 컴퓨터의 터미널(또는 PowerShell)을 엽니다.
2. 인스턴스 생성 시 다운로드한 .pem 키 파일이 있는 디렉토리에서 다음 명령어를 실행합니다: ssh -i "your-key-name.pem" ec2-user@<복사한_IP_주소>
3. 성공적으로 로그인되면, 셸 프롬프트에서 ping google.com 명령을 실행합니다.
4. 응답 패킷이 성공적으로 수신되면, 인터넷 게이트웨이를 통한 아웃바운드 트래픽이 정상적으로 작동함을 의미합니다. Ctrl+C 키를 눌러 ping을 중지합니다.

4.2. 프라이빗 인스턴스 연결성 테스트 (가장 간단하고 안전한 방법)

private-app-server가 외부에서 직접 접근할 수 없지만, EC2 Instance Connect Endpoint와 NAT 게이트웨이를 통해 연결이 가능한지 확인합니다.

EC2 Instance Connect Endpoint를 통한 접속:

AWS 관리 콘솔에서 EC2 > '인스턴스' 메뉴로 이동합니다.
private-app-server 인스턴스를 선택하고, 페이지 상단의 '연결' 버튼을 클릭합니다.
'EC2 Instance Connect' 탭을 선택합니다.
연결 유형이 '프라이빗 IP 주소를 사용하여 연결'로 선택되었는지 확인합니다.
'EC2 Instance Connect Endpoint' 드롭다운 메뉴에서 방금 생성한 엔드포인트를 선택합니다.
'연결' 버튼을 클릭합니다.
별도의 SSH 클라이언트나 키 파일 없이, 브라우저에 새로운 탭이 열리면서 인스턴스의 셸 프롬프트가 나타납니다. 이것이 바로 공인 IP나 Bastion 호스트 없이 프라이빗 인스턴스에 안전하게 접속하는 방법입니다.

아웃바운드 연결 확인:

새로 열린 터미널에서 ping google.com 명령을 실행합니다.
응답 패킷이 성공적으로 수신되는 것을 확인합니다. 이 트래픽은 private-app-server에서 시작하여 my-private-rtb를 거쳐 my-nat-gw로 전달되고,my-igw를 통해 인터넷으로 나갔다가 돌아온 것입니다.
sudo yum update -y 명령을 실행해 봅니다. 패키지 저장소에서 업데이트 정보를 성공적으로 가져온다면, NAT 게이트웨이를 통한 아웃바운드 통신이 작동함을 최종적으로 검증한 것입니다.