AWS VPC 구성 2 (프라이빗 서브넷, NAT 게이트웨이)

zion·2025년 7월 27일
0

AWS

목록 보기
11/11

실제 서비스를 퍼블릭 IP로 배포하면 누구나 접근할 수 있기 때문에 보안적으로 위험하다.

그래서 이번엔 외부에서는 접근 불가능하지만, 내부에서는 관리 가능한 EC2를 프라이빗하게 구성해봤다.

프라이빗 서브넷 추가

VPC 사이드탭 [서브넷] → [서브넷 생성]

퍼블릭 서브넷을 추가할 때와 마찬가지로 추가하고자 하는 VPC를 선택한다.

가용 영역 a, b에 각각 프라이빗 서브넷 생성

  • 10.0.3.0/24 → private-a
  • 10.0.4.0/24 → private-b

VPC 리소스 맵에서 프라이빗 서브넷이 잘 추가된 걸 확인할 수 있다.

프라이빗 EC2 인스턴스 생성

키 페어를 설정 후,

EC2 인스턴스를 생성할 때

  • 서브넷: 위에서 만든 프라이빗 서브넷
  • 퍼블릭 IP 자동 할당: 비활성화

퍼블릭 IP가 없으니 콘솔에서도 접근할 수 없다는 경고가 뜬다.
그럼 프라이빗 서브넷에 있는 EC2는 어떻게 접근해야 할까?

퍼블릭 EC2 → 프라이빗 EC2로 SSH 접속

VPC 내부는 기본적으로 CIDR 기준으로 local 라우팅되어 있기 때문에, 같은 VPC 내부의 EC2끼리는 통신이 가능하다.

✅ 퍼블릭 서브넷 EC2 → 프라이빗 서브넷 EC2 = 접근 가능
❌ 로컬 컴퓨터 → 프라이빗 EC2 = 접근 불가

그래서 퍼블릭 EC2를 경유하는 방식으로 프라이빗 EC2에 접근해보도록 하겠다.

퍼블릭 EC2에 SSH 접속

ssh -i "key-pair.pem" ubuntu@3.xx.xxx.xxx

프라이빗 EC2 키를 퍼블릭 EC2로 복사

윈도우 기준 cmd, scp 사용

scp -i key-pair.pem key-pair.pem ubuntu@3.xx.xxx.xxx:~/
  • -i : 퍼블릭 EC2 접근용 키
  • key-pair.pem : 프라이빗 EC2 접근용 키
  • ~/ : 프라이빗 EC2 내부 복사할 경로

퍼블릭 EC2로 들어와 ls로 키가 제대로 옮겨진 걸 확인

퍼블릭 EC2 내부에서 프라이빗 EC2 접속

해당 방법대로

chmod 400 "key-pair.pem"
ssh -i "key-pair.pem" ubuntu@10.0.4.188

정상적으로 프라이빗 EC2 접속 완료!

Bastion Host

퍼블릭 EC2를 통해 프라이빗 리소스에 접속할 때,
→ 이 퍼블릭 EC2를 Bastion Host라고 부른다.

특징설명
위치퍼블릭 서브넷
역할외부 접근 허용, 내부 리소스 접속 관문
사용 이유프라이빗 자원에 대한 SSH 통신용 중계 서버

📌 참고: Bastion Host는 프라이빗 리소스와 같은 AZ에 두는 걸 추천

  • 같은 AZ: 지연 최소 + 데이터 전송 무료
  • 다른 AZ: 가능은 하지만 비용 발생 가능

hostname 바꾸기 (선택)

기본 hostname이 IP 기반이라 구분이 어려우므로 이름을 바꿔준다.

sudo vi /etc/hostname

엔터 후 sudo reboot

프라이빗 서브넷에서도 인터넷 접근이 필요할 때는?

운영 중 apt update, pip install 등을 위해 프라이빗 EC2에서 인터넷 연결이 필요할 수 있다.

당연히 실패한다.
→ 퍼블릭 IP도 없고, IGW도 연결되어 있지 않기 때문

그렇지만 IGW를 연결할 수는 없다.

IGW는 양방향 통신이 가능하다.
즉, 프라이빗 EC2가 인터넷으로 나갈 수 있을 뿐 아니라, 외부에서도 이 EC2로 접근할 수 있게 된다.
→ 그럼 프라이빗 서브넷이 아니게 되는 것

그래서 NAT Gateway라는 걸 이용한다.

NAT Gateway 생성

NAT Gateway

프라이빗 서브넷에 있는 인스턴스가 인터넷으로 나갈 수 있도록 해주는 장치
단, 외부에서 해당 인스턴스로 들어오는 것은 불가능하다.

즉, 아웃바운드(Outbound) 전용 통신을 허용하는 안전한 방식이다.

❗ NAT Gateway는 IGW처럼 퍼블릭 서브넷에 위치해야 하고, 퍼블릭 IP (탄력적 IP)를 가지고 있어야 외부로 통신 가능하다.

사이드바 [NAT 게이트웨이] 클릭 후 [NAT 게이트웨이 생성]

  • 서브넷: 퍼블릭 b 영역 선택 (이번 글에서는 public b에만 둘 예정)
  • 연결 유형: 퍼블릭
  • 탄력적 IP: [탄력적 IP 할당] 클릭해서 연결

❗ 프라이빗으로 설정하면 통신 자체가 안 됨 (외부랑 끊김)

[NAT 게이트웨이 생성] 클릭

생성되기까지 기다린다 (조금 오래 걸림)

프라이빗 라우팅 테이블 생성

NAT GW가 생겼으니, 프라이빗 서브넷의 트래픽이 NAT Gateway를 통해 나가도록 라우팅을 잡아줘야 한다.

NAT GW 상태가 Available이 되었으면, 라우팅 테이블로 들어가 프라이빗 서브넷 전용 라우팅 테이블을 생성한다.

라우팅 테이블 생성

라우팅 테이블 - 서브넷 연결까지는 public과 동일하게 진행한다.

참고
해당 글에서는 NAT Gateway를 public-b 하나에만 배치했기 때문에 private-a, b 모두 이 라우팅 테이블에 연결해 하나의 NAT GW를 사용하도록 구성했다.

가용 영역마다 NAT Gateway를 각각 두는 게 FM이지만 비용 비쌈
→ 보통 실습이나 소규모 환경에서는 NAT GW 하나로 충분하다.

라우팅 경로 추가

다른 점은 [라우팅 편집]

기본적으로 이미 10.0.0.0/16 → local 경로가 있다.
여기에 0.0.0.0/0에 대한 라우팅을 추가한다.

대상대상지
10.0.0.0/16local
0.0.0.0/0NAT Gateway 선택
  • local: VPC 내부 통신
  • 0.0.0.0/0: 모든 IPv4 트래픽 → 외부로 나가는 요청 → NAT GW를 통해 처리

VPC 리소스 맵에서 프라이빗 서브넷이 NAT GW와 연결된 라우팅 테이블을 사용 중인지 확인 가능하다.

(기본 라우팅 테이블과 혼동되지 않도록 private-rt를 기본 테이블로 설정하거나, 기존 default는 삭제해도 됨)

다시 프라이빗 EC2에서 sudo apt update를 시도해보면,

정상적으로 업데이트됨을 확인할 수 있다.

정리

프라이빗 서브넷, NAT Gateway까지 추가한 전체 구조를 시각화하면 아래와 같다.

profile
0 w0

0개의 댓글