Private Subnet + NAT Gateway + Bastion 도입 배경
- 도입 배경
서비스는 외부 트래픽을 ALB로 받되, 애플리케이션과 DB는 인터넷에 직접 노출되지 않도록 운영해야 했습니다. 동시에 배포, 외부 API 호출 등 아웃바운드 인터넷 접근은 필요하고, 운영을 위한 SSH 접근도 가능해야 했습니다. 인바운드는 차단하면서 아웃바운드는 보장하고, 안전한 운영 접근이 필요한 상황이었습니다.
- 선택지
- 퍼블릭 서브넷에 앱/DB 배치
- 구성이 단순하고 설정이 쉬움
- 인바운드 노출 면적이 커서 보안상 부적절
- 프라이빗 서브넷 + NAT 인스턴스
- 비용이 저렴함
- 단일 장애점이 되고 패치, 스케일링, 헬스체크 등 운영 부담 증가
- 프라이빗 서브넷 + NAT Gateway
- 관리형 아웃바운드로 운영 부담 없음
- AZ 단위 확장성과 복원력 확보
- Bastion Host로 익숙한 네트워크 구조와 고정 IP 접근
- 최종 결정
퍼블릭 서브넷 배치는 보안상 부적절해 제외했습니다. NAT 인스턴스는 단일 장애점과 운영 부담으로 제외했습니다. 따라서 관리형 서비스의 안정성과 보안을 위해 프라이빗 서브넷 + NAT Gateway + Bastion Host로 결정했습니다.