실제 서비스를 퍼블릭 IP로 배포하면 누구나 접근할 수 있기 때문에 보안적으로 위험하다.
그래서 이번엔 외부에서는 접근 불가능하지만, 내부에서는 관리 가능한 EC2를 프라이빗하게 구성해봤다.
VPC 사이드탭 [서브넷] → [서브넷 생성]
퍼블릭 서브넷을 추가할 때와 마찬가지로 추가하고자 하는 VPC를 선택한다.
가용 영역 a, b에 각각 프라이빗 서브넷 생성
10.0.3.0/24
→ private-a10.0.4.0/24
→ private-bVPC 리소스 맵에서 프라이빗 서브넷이 잘 추가된 걸 확인할 수 있다.
키 페어를 설정 후,
EC2 인스턴스를 생성할 때
퍼블릭 IP가 없으니 콘솔에서도 접근할 수 없다는 경고가 뜬다.
그럼 프라이빗 서브넷에 있는 EC2는 어떻게 접근해야 할까?
VPC 내부는 기본적으로 CIDR 기준으로 local 라우팅되어 있기 때문에, 같은 VPC 내부의 EC2끼리는 통신이 가능하다.
✅ 퍼블릭 서브넷 EC2 → 프라이빗 서브넷 EC2 = 접근 가능
❌ 로컬 컴퓨터 → 프라이빗 EC2 = 접근 불가
그래서 퍼블릭 EC2를 경유하는 방식으로 프라이빗 EC2에 접근해보도록 하겠다.
ssh -i "key-pair.pem" ubuntu@3.xx.xxx.xxx
윈도우 기준 cmd, scp 사용
scp -i key-pair.pem key-pair.pem ubuntu@3.xx.xxx.xxx:~/
-i
: 퍼블릭 EC2 접근용 키key-pair.pem
: 프라이빗 EC2 접근용 키~/
: 프라이빗 EC2 내부 복사할 경로
퍼블릭 EC2로 들어와 ls
로 키가 제대로 옮겨진 걸 확인
해당 방법대로
chmod 400 "key-pair.pem"
ssh -i "key-pair.pem" ubuntu@10.0.4.188
정상적으로 프라이빗 EC2 접속 완료!
퍼블릭 EC2를 통해 프라이빗 리소스에 접속할 때,
→ 이 퍼블릭 EC2를 Bastion Host라고 부른다.
특징 | 설명 |
---|---|
위치 | 퍼블릭 서브넷 |
역할 | 외부 접근 허용, 내부 리소스 접속 관문 |
사용 이유 | 프라이빗 자원에 대한 SSH 통신용 중계 서버 |
📌 참고: Bastion Host는 프라이빗 리소스와 같은 AZ에 두는 걸 추천
- 같은 AZ: 지연 최소 + 데이터 전송 무료
- 다른 AZ: 가능은 하지만 비용 발생 가능
기본 hostname
이 IP 기반이라 구분이 어려우므로 이름을 바꿔준다.
sudo vi /etc/hostname
엔터 후 sudo reboot
운영 중 apt update
, pip install
등을 위해 프라이빗 EC2에서 인터넷 연결이 필요할 수 있다.
당연히 실패한다.
→ 퍼블릭 IP도 없고, IGW도 연결되어 있지 않기 때문
그렇지만 IGW를 연결할 수는 없다.
IGW는 양방향 통신이 가능하다.
즉, 프라이빗 EC2가 인터넷으로 나갈 수 있을 뿐 아니라, 외부에서도 이 EC2로 접근할 수 있게 된다.
→ 그럼 프라이빗 서브넷이 아니게 되는 것
그래서 NAT Gateway라는 걸 이용한다.
NAT Gateway
프라이빗 서브넷에 있는 인스턴스가 인터넷으로 나갈 수 있도록 해주는 장치
단, 외부에서 해당 인스턴스로 들어오는 것은 불가능하다.
즉, 아웃바운드(Outbound) 전용 통신을 허용하는 안전한 방식이다.❗ NAT Gateway는 IGW처럼 퍼블릭 서브넷에 위치해야 하고, 퍼블릭 IP (탄력적 IP)를 가지고 있어야 외부로 통신 가능하다.
사이드바 [NAT 게이트웨이] 클릭 후 [NAT 게이트웨이 생성]
b
영역 선택 (이번 글에서는 public b에만 둘 예정)❗ 프라이빗으로 설정하면 통신 자체가 안 됨 (외부랑 끊김)
[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/16 | local |
0.0.0.0/0 | NAT Gateway 선택 |
local
: VPC 내부 통신0.0.0.0/0
: 모든 IPv4 트래픽 → 외부로 나가는 요청 → NAT GW를 통해 처리VPC 리소스 맵에서 프라이빗 서브넷이 NAT GW와 연결된 라우팅 테이블을 사용 중인지 확인 가능하다.
(기본 라우팅 테이블과 혼동되지 않도록 private-rt
를 기본 테이블로 설정하거나, 기존 default는 삭제해도 됨)
다시 프라이빗 EC2에서 sudo apt update
를 시도해보면,
정상적으로 업데이트됨을 확인할 수 있다.
프라이빗 서브넷, NAT Gateway까지 추가한 전체 구조를 시각화하면 아래와 같다.