AWS VPC 아키텍처 개선
AWS 네트워크 및 모니터링 아키텍처 개선을 통한 보안 및 비용 최적화
기존에는 서버에 공인 IP를 직접 할당하여 SSH를 통해 접근할 수 있는 구조였으나,
보안 강화를 위해 프라이빗 서브넷에 서버를 배치하고, 퍼블릭 서브넷에 배스천(Bastion) 서버를 구성하여 접근을 제한하는 아키텍처로 변경하였다.
또한, 모니터링 서버 역시 프라이빗 서브넷에 배치하여,
대시보드 및 운영 데이터를 조회할 때에도 배스천 서버를 경유하도록 설정함으로써 내부 자원의 보안성을 더욱 강화하였다.
서브넷을 오토스케일링 그룹(Auto Scaling Group, ASG) 으로 구성하여 가용성을 확보하였으나,
AWS CloudWatch + Auto Scaling 조합은 비용 부담이 높아,
Prometheus Alert + AWS Lambda + Auto Scaling 조합으로 변경하여 비용 절감 및 운영 효율성을 극대화하였다.
프라이빗 서브넷 내 인스턴스들은 외부에서 직접 접근할 수 없도록 차단하였지만,
업데이트 및 알림 서비스(예: Prometheus Alert, APT 패키지 설치 등)와 같은 아웃바운드 트래픽이 필요하기 때문에,
NAT Gateway를 추가하여 외부 네트워크로의 통신을 허용하였다.
주요 개선 효과
✅ 보안 강화: 공인 IP를 제거하고, 배스천 서버를 통한 접근 제한
✅ 운영 효율성 개선: 프라이빗 서브넷 기반 모니터링 환경 구축
✅ 비용 최적화: CloudWatch 대신 Prometheus + Lambda를 활용하여 모니터링 비용 절감
✅ 고가용성 확보: 오토스케일링 그룹을 통한 자동 확장 및 트래픽 증가 대응
✅ 필수 아웃바운드 트래픽 허용: NAT Gateway를 통해 업데이트 및 알림 서비스 가능
기존 설정의 주요 문제점
❗️변경 전
💡 변경 후
1️⃣ Default VPC 사용으로 인해 네트워크 구성이 비효율적
🚨문제점
- Default VPC는 CIDR 블록(172.31.0.0/16)이 자동으로 설정되며, 사용자가 변경할 수 없음.
- Default 서브넷의 크기(/20)가 자동으로 지정되어 유연하게 IP를 할당하거나 서브넷을 조정할 수 없음.
- Default VPC는 기본적으로 모든 서브넷이 퍼블릭으로 설정됨 → 보안에 취약.
✅ 해결 방법
새로운 VPC를 생성하여 CIDR 블록을 원하는 대로 지정 (10.0.0.0/16 등)퍼블릭 서브넷과 프라이빗 서브넷을 분리하여 보안 강화- 서브넷 크기를 /24 또는 /26으로 지정하여 유연하게 확장 가능하도록 설정
2️⃣ 모든 서브넷이 퍼블릭 서브넷으로 설정됨 → 보안 문제
🚨 문제점
- 모든 서브넷이 퍼블릭 서브넷으로 설정되어 인터넷 게이트웨이(IGW)와 연결되어 있음.
- 즉, 백엔드 서버, RDS, 모니터링 서버까지 인터넷과 직접 연결됨 → 해킹 및 보안 위협 증가.
- 내부적으로만 사용해야 할 리소스(예: 백엔드 서버, RDS)도 외부에서 접근 가능.
✅ 해결 방법
프라이빗 서브넷을 추가하여 백엔드 서버 및 RDS를 보호- 퍼블릭 서브넷에는 웹 서버, 베스천 서버만 배치
- 프라이빗 서브넷에서는 NAT Gateway를 통해 인터넷 접근을 제한적으로 허용
3️⃣ NAT Gateway가 없음 → 프라이빗 서브넷에서 인터넷 접속 불가능
🚨 문제점
- 모든 서브넷이 퍼블릭 서브넷으로 설정되어 있기 때문에 NAT Gateway가 존재하지 않음.
- 만약 프라이빗 서브넷을 만들 경우, 인터넷을 통한 업데이트 및 외부 API 호출이 불가능함.
✅ 해결 방법
- 퍼블릭 서브넷에
NAT Gateway를 추가하여, 프라이빗 서브넷에서 인터넷에 나갈 수 있도록 설정 - 프라이빗 서브넷에서는 직접 인터넷에 접근할 수 없고, NAT Gateway를 경유하여 접근하도록 구성
4️⃣ VPC 엔드포인트 없음 → AWS 내부 서비스(S3, DynamoDB 등) 접근 시 비용 발생
🚨 문제점
- 현재 설정에서는 VPC 내부에서 AWS 서비스(S3, DynamoDB 등)에 접근할 때 인터넷을 거쳐야 함.
- 인터넷을 통해 AWS 서비스에 접근하면 데이터 전송 비용이 발생하고 보안상 취약.
✅ 해결 방법
- VPC
엔드포인트(VPC Endpoint)를 설정하여, 프라이빗 네트워크 내에서 AWS 서비스에 직접 연결 가능하도록 구성 - 예를 들어, S3 VPC 엔드포인트를 추가하면 프라이빗 서브넷에서도 인터넷 없이 S3 접근 가능.
5️⃣ 하나의 라우팅 테이블만 존재 → 퍼블릭 & 프라이빗 서브넷 구분 불가능
🚨 문제점
- 현재 VPC의 모든 서브넷이 하나의 라우팅 테이블을 공유
- 퍼블릭 서브넷과 프라이빗 서브넷의 라우팅 정책을 다르게 설정할 수 없음.
✅ 해결 방법
- 퍼블릭 서브넷 전용 라우팅 테이블 (IGW 연결)
- 프라이빗 서브넷 전용 라우팅 테이블 (NAT Gateway 연결)
각각 다른 라우팅 테이블을 사용하여 네트워크 트래픽을 효과적으로 관리.
🌟 베스천 서버 (Bastion Server)
베스천 서버는 프라이빗 서브넷에 있는 서버에 외부에서 안전하게 SSH 접속할 수 있도록 중간에서 다리를 놓는 역할을 합니다.
외부 사용자 ───→ [ 웹 서버 ] ───→ [ 백엔드 서버 ]
│ │
(SSH) [ 베스천 서버 ]──→ [ 백엔드/모니터링 서버 ]
베스천 서버를 통해 백엔드 서버에 SSH 접속
SSH 접속 흐름: (사용자) → 베스천 서버 (퍼블릭) → 백엔드 서버 (프라이빗)
* 외부에서 직접 백엔드 서버로 SSH 접속할 수 없음
* 백엔드 서버의 보안 그룹에서 SSH 트래픽을 베스천 서버의 보안 그룹에서만 허용해야 함웹서버는 베스천 서버를 경유하지 않음
웹서버는 베스천 서버를 거칠 필요가 없습니다.
* 웹 서버는 외부 사용자에게 직접 HTTP/HTTPS 서비스를 제공해야 하기 때문에 퍼블릭 서브넷에 위치해야 함
* 따라서, 웹 서버는 베스천 서버 없이도 직접 트래픽을 받을 수 있음 모니터링 서버도 베스천 서버를 통해 SSH 접속
* 모니터링 서버도 백엔드 서버와 마찬가지로 프라이빗 서브넷에 배치됨
* SSH 접속할 때 베스천 서버를 통해서만 접근 가능해야 함
베스천 서버를 사용하지 않으면?
베스천 서버(Bastion Host)는 프라이빗 서브넷에 있는 서버(백엔드, 모니터링 등)에 SSH 접속할 수 있도록 중계 역할을 하는 서버입니다.
그럼 베스천 서버 없이 프라이빗 서브넷 서버에 접속하려면 어떻게 될까요?
1️⃣ 프라이빗 서버에 직접 SSH 접속 불가능
베스천 서버를 사용하지 않으면 프라이빗 서브넷에 있는 서버(백엔드, 모니터링)에는 SSH로 직접 접근할 수 없음
- 프라이빗 서브넷의 인스턴스에는 공인 IP가 없음 → 인터넷을 통해 접근 불가 ❌
- 프라이빗 서브넷에는 인터넷 게이트웨이(IGW)가 없음 → 외부에서 직접 접속 불가 ❌
- 라우팅 테이블 상에서 외부 트래픽을 허용하지 않음 → 직접 연결 불가 ❌
2️⃣ 프라이빗 서버에 공인 IP 할당 (보안 취약)
베스천 서버 없이 백엔드 서버에 접속하려면 프라이빗 서버에도 공인 IP를 할당해야 합니다,
즉, 백엔드 서버를 퍼블릭 서브넷에 배치하거나, 프라이빗 서브넷이더라도 공인 IP를 추가해야 합니다.
하지만 이렇게 하면
- 보안 취약: 외부에서 백엔드 서버로 직접 접근 가능 → 해킹 위험 증가
- DDoS 공격 위험: 외부 IP가 노출되면 공격 대상이 될 가능성이 높아짐
- SSH 공격 대상: 무차별 대입(Brute Force) 공격에 취약해짐
- 보안 규칙 관리 복잡: 보안 그룹 설정이 복잡해지고, 실수로 보안이 허술해질 가능성 큼
