AWS에서 고가용성과 탄탄한 확장성을 갖춘 네트워크를 설계하는 것은 쉽지 않은 일입니다. 오늘은 “Ping 대시보드”라는 소박한 프로젝트를 통해 네트워크 설계의 기초부터 최적화까지 전 과정을 함께 살펴보겠습니다.

프로젝트 개요

이 프로젝트는 인터넷에서 특정 서버의 응답 속도를 측정해 대시보드로 보여주는 시스템입니다. 목표는 다음과 같습니다:

• 멀티 AZ(Availability Zone) 기반의 탄탄한 네트워크 아키텍처 구축
• 퍼블릭 및 프라이빗 서브넷을 이용한 보안성 강화
• 향후 타 지역으로의 확장 가능성 확보

핵심 설계 원칙

AZ(Availability Zone)란?

• AWS의 AZ는 한 리전 내에 전기, 냉각, 네트워크가 독립된 데이터 센터 단위입니다.
• 한 리전당 최소 3개의 AZ를 제공합니다.

서브넷 설계 원칙

• 하나의 서브넷은 반드시 하나의 AZ에만 속할 수 있습니다.
• 고가용성을 위해 서로 다른 AZ에 서브넷을 나눠서 구성하는 것이 필수입니다.

퍼블릭 vs 프라이빗 서브넷

• 퍼블릭 서브넷: 인터넷 게이트웨이를 통해 외부에서 접근 가능. (예: 웹 서버)
• 프라이빗 서브넷: 인터넷과 직접 연결되지 않음. (예: 데이터베이스, 내부 프로브)

네트워크 구성

• 리전: eu-south-2 (스페인)
• IP 대역: 10.0.0.0/24
• 이를 /28 단위로 나눠 총 16개의 서브넷 생성

AZ 별 서브넷 예시:

• AZ A → 10.0.0.0/28 ~ 10.0.0.64/28
• AZ B → 10.0.0.80/28 ~ 10.0.0.144/28
• AZ C → 10.0.0.160/28 ~ 10.0.0.240/28

서브넷 할당:

• 웹 서버: 퍼블릭 서브넷
• 프로브(VM): 프라이빗 서브넷
• RDS: 프라이빗 서브넷

컴퓨팅 자원

• EC2 (t3.micro): 웹 서버 및 프로브
• Network Load Balancer (NLB): 웹 서버 앞단 트래픽 분산
• Auto Scaling Group: 웹 서버 자동 재배치

데이터베이스

• RDS MySQL Multi-AZ (초기)
• 고가용성을 위한 리플리카 및 자동 페일오버 지원

비용 최적화 전략

1차 최적화: NAT Gateway 축소

• AZ마다 NAT Gateway를 두는 대신 하나만 구성
• 장애 시 Lambda로 라우팅 전환 자동화

2차 최적화: RDS를 Single-AZ로 변경

• SLA는 낮아지지만 비용 절감
• 장애 시 수동 또는 자동 복구 필요

3차 최적화: ARM 기반 인스턴스(t4g.micro) 전환

• 비용 및 탄소 배출량 약 40% 절감

4차 최적화: NAT Gateway → NAT 인스턴스 전환

• 관리 필요성이 증가하지만 비용 절감 효과 큼

최종 비용 정리

• 월간 예상 비용: 약 170 USD → 8 USD까지 절감 가능
• 탄소 배출량: 40kgCO₂eq → 5.3kgCO₂eq까지 절감