개요
Devops에 관심이 생기며, 서버 구축을 할 때 과거에 구축했던 방식이 너무 허술했다고 생각이 들어 간단한 개념 정리를 한다.
1. VPC 구성
VPC는 AWS의 가상 네트워크이고, 그 안에 여러 서브넷(퍼블릭/프라이빗)을 만드는 과정이다.
VPC는 여러 개의 서브넷으로 나뉘며, 일반적으로 다음과 같이 퍼블릭과 프라이빗 서브넷을 분리한다.
- 퍼블릭 서브넷: 인터넷과 통신이 가능한 서브넷
- 프라이빗 서브넷: 인터넷과 직접 통신이 불가능한 서브넷
2. 일반적인 아키텍처 구성
- 퍼블릭 서브넷:
- 로드 밸런서 (ALB, NLB): 클라이언트로부터 요청을 받아 백엔드 서버로 전달
- NAT Gateway (옵션): 프라이빗 서브넷의 서버가 아웃바운드 인터넷 접속을 가능하게 함
- 프라이빗 서브넷:
- EC2 인스턴스 (애플리케이션 서버): 로드 밸런서로부터 요청을 받아 처리
- RDS 등 데이터베이스: 백엔드 데이터 저장소
3. 네트워크 흐름
- 클라이언트 → 퍼블릭 서브넷의 로드 밸런서
- 로드 밸런서 → 프라이빗 서브넷의 EC2 서버
- EC2 서버 → 필요 시 프라이빗 서브넷 내의 RDS와 통신
4. 보안 그룹 및 라우팅
- 보안 그룹:
- 로드 밸런서는 80/443 포트를 열고 외부 접근을 허용
- EC2 서버는 로드 밸런서에서만 접근 가능하도록 제한
- 라우팅 테이블:
- 퍼블릭 서브넷: 인터넷 게이트웨이(IGW) 연결
- 프라이빗 서브넷: NAT 게이트웨이 연결 (아웃바운드만 허용)
AWS에서는 Elastic Load Balancing (ELB) 서비스를 통해 로드 밸런서를 관리하고 제공한다.
사용자는 몇 개의 설정만 해주면 AWS가 알아서 로드 밸런서를 생성, 운영, 유지보수해준다.
AWS ELB - ALB
NLB, GWLB는 지금 알 필요가 없을 것 같아 정리하지 않겠다.
Application Load Balancer (ALB) - HTTP/HTTPS 레이어 (7계층)
- 웹 애플리케이션용으로 사용
- 호스트 기반 라우팅 지원
- ex) /api 요청은 서버 A로, /admin 요청은 서버 B로
아키텍처 흐름
- Public Subnet (퍼블릭 서브넷)
- ELB(로드 밸런서): 클라이언트의 HTTP/HTTPS 요청을 받음
- 외부에서 접근 가능한 유일한 지점 (DNS 이름 제공)
- Private Subnet (프라이빗 서브넷)
- EC2 서버 (3대): 애플리케이션이 배포된 서버
- 로드 밸런서로부터만 요청을 수락하도록
보안 그룹설정
- 트래픽 흐름
- 클라이언트 → ELB (퍼블릭 서브넷) → EC2 (프라이빗 서브넷)
그렇다면 순서를 한번 되짚어보자.
- 퍼블릭 서브넷에서는 AWS 자체에서 ELB 서비스를 통해서 로드밸런서 기능을 해준다.
- 이 로드 밸런서가 Private Subnet 내의 여러 EC2 인스턴스로 트래픽을 분산시킨다.
세부 작동 방식
- Target Group: ELB는 Target Group을 통해 대상 서버(EC2)를 관리한다.
- Health Check: 로드 밸런서는 주기적으로 서버 상태를 확인하고, 비정상 서버는 트래픽 분산 대상에서 자동으로 제외한다.
- 라우팅 알고리즘: 기본적으로 Round Robin 방식으로 트래픽을 고르게 분산하지만, 가중치 기반, 고정 세션 등도 설정 가능하다.
보안 구성 (보안 그룹 설정)
- 퍼블릭 서브넷: 로드 밸런서에 80/443 포트만 오픈
- 프라이빗 서브넷: EC2는 로드 밸런서만 접근 가능하도록 제한
- NAT Gateway (옵션): 프라이빗 서브넷에서 인터넷으로 아웃바운드 접근 시 필요
여기서 NginX는 어떻게 동작할까?
❓ nginx를 띄운다고 하면 이 nginx는 어디서 어떻게 적용될까?
프라이빗 서브넷의 EC2 내부에서 Nginx 사용 (일반적인 방식)
구성:
- Nginx는 EC2 인스턴스 내에서 애플리케이션과 함께 실행
- ELB가 요청을 받아 프라이빗 서브넷의 Nginx로 전달
역할:
- Reverse Proxy: Nginx가 애플리케이션(예: FastAPI, Spring Boot 등)과 통신
- 로드 밸런싱 (옵션): 내부적으로 여러 애플리케이션 인스턴스로 트래픽 분산
- 보안: SSL 종료(ELB에서도 가능하지만, Nginx에서도 추가 적용 가능)
트래픽 흐름:
- 클라이언트 → ELB (퍼블릭 서브넷)
- ELB → Nginx (프라이빗 서브넷)
- Nginx → 애플리케이션 (127.0.0.1:8000 등)
- 애플리케이션 → Nginx → ELB → 클라이언트
Nginx의 로드 밸런서 역할은 선택 사항
- 보통 ELB가 이미 트래픽을 균등 분산하므로, Nginx가 추가적으로 로드 밸런서 역할을 할 필요는 없다.
- 다만, Nginx가 내부 서버 간 세부적인 트래픽 분산을 수행하게 설정할 수도 있다.
최종 요약
- ELB: 클라이언트와 서버 사이의 1차 로드 밸런싱 (AWS 제공)
- Nginx: EC2 내부에서 Reverse Proxy 역할 (보안, 캐싱, 로깅 등)
- 애플리케이션: FastAPI, Spring Boot 등
💡 결론: ELB가 이미 잘 분산해주기 때문에 Nginx는 주로 Reverse Proxy 역할을 하고, 내부 애플리케이션과의 연결을 최적화하는 역할을 맡는 것이 일반적이다.
ELB 없이 단일 EC2 구성 (간단하지만 비추천)
구성:
- EC2 인스턴스를 퍼블릭 서브넷에 직접 배포
- Nginx가 직접 외부 요청을 수신하고, 내부 애플리케이션으로 전달
트래픽 흐름:
- 클라이언트 → EC2 (퍼블릭 IP)
- Nginx (Reverse Proxy) → 애플리케이션
장점:
- 비용 절감 (ELB 비용 없음)
- 간단한 설정
단점:
- 고가용성 불가능 (EC2 장애 시 서비스 중단)
- 오토 스케일링 및 헬스체크 불가
💡 이 방식은 테스트 환경이나 소규모 서비스에만 적합합니다.
이 방식이 내가 이전에 구축했던 허술한 방식이다.
ELB를 적용하지도 않았고 EC2 인스턴스를 띄운 다음에 Private Subnet를 띄워서 그 안에 서버를 구축하지 않았다.
Public Subnet에서 서버를 띄웠고 거기서 Nginx를 띄워서 로드 밸런싱을 해주었었다.
허술하지만 가장 간단하면서도 많이 볼 수 있는 구축 방식이다.
이때 왜 이랬을까?
그것은 EC2를 생성하고 ELB를 사용하지 않았기 때문이다.
시나리오별 서브넷 구성 방법
1. ELB 없이 단일 EC2 (퍼블릭 서브넷만 사용)
- 구성: EC2를 퍼블릭 서브넷에 직접 배포하고, 퍼블릭 IP를 통해 접근
- 보안: 인터넷과 직접 연결되므로 보안 취약성 증가
- 트래픽 흐름: 클라이언트 → EC2 → Nginx → 애플리케이션
✅ 장점:
- 간단하고 비용 절감
❌ 단점:
- 보안에 취약 (공개된 서버에 직접 접근)
- 고가용성, Auto Scaling 불가
💡 테스트 환경이나 간단한 서비스에만 적합합니다.
2. ELB 없이 다중 EC2 (퍼블릭 + 프라이빗 서브넷 사용)
- 구성:
- 퍼블릭 서브넷: Nginx 리버스 프록시 (퍼블릭 IP 할당)
- 퍼블릭 서브넷에서 Nginx를 구축한다.
- 프라이빗 서브넷: 애플리케이션 서버
- 퍼블릭 서브넷: Nginx 리버스 프록시 (퍼블릭 IP 할당)
- 보안:
- 외부에서 직접 애플리케이션 서버 접근 불가
- Nginx만 외부와 통신하고 내부 서버로 전달
✅ 장점:
- 보안 강화 (EC2는 프라이빗 서브넷에 위치)
- Nginx가 내부 트래픽을 분산
❌ 단점:
- Nginx 장애 시 전체 서비스 중단 (SPOF)
- Auto Scaling 불가
💡 소규모 운영 환경에서 사용할 수 있으나, 고가용성을 확보하기 어렵다.
3. ELB + 퍼블릭/프라이빗 서브넷 (권장 구성)
- 구성:
- 퍼블릭 서브넷: ELB
- 프라이빗 서브넷: Nginx + 애플리케이션 서버
- 보안:
- 외부에서 서버에 직접 접근 불가
- ELB만 외부 접근 허용
✅ 장점:
- 고가용성, Auto Scaling 가능
- 내부 서버 보안 강화
❌ 단점:
- ELB 비용 발생
💡 실무 운영 환경에서는 가장 안정적이고 권장되는 방법이다.
서브넷 구성 비교
| 시나리오 | 퍼블릭 서브넷 | 프라이빗 서브넷 | 보안 수준 | 고가용성 | 권장 환경 |
|---|---|---|---|---|---|
| ELB 없이 단일 EC2 | ✅ | ❌ | 낮음 | ❌ | 테스트, 간단 서비스 |
| ELB 없이 다중 EC2 | ✅ | ✅ | 중간 | ❌ | 소규모 운영 환경 |
| ELB + EC2 (권장) | ✅ | ✅ | 높음 | ✅ | 실무 운영 환경 |
결론: 프라이빗 서브넷을 사용해야 할까?
- ELB 없음 + 단일 EC2: 퍼블릭 서브넷만 사용 (보안 취약)
- ELB 없음 + 다중 EC2: 퍼블릭 + 프라이빗 서브넷 사용 (보안 강화)
- ELB 있음: 퍼블릭(ELB) + 프라이빗(EC2) 구성 (권장)
💡 안정성과 보안을 고려하면, ELB가 없어도 프라이빗 서브넷을 사용하는 것이 좋다.
