지점별 ALB와 개발 서버 EC2를 통합해 인프라 비용을 줄인 과정
2026.10.04 · 2분
개요
| 항목 | 내용 |
|---|---|
| 유형 | 인프라 구조 개선·비용 절감 |
| 시점 | 병원별 웹 운영 과정 |
| 상태 | 병원 단위 ALB 통합, 개발 환경 EC2 통합 적용 |
| 관련 영역 | AWS ALB, ECS, EC2, Host-based Routing, 서브도메인 |
1. 상황과 제약
지점마다 UI와 콘텐츠 구성이 달라서 지점별 Next.js 프로젝트를 따로 운영했습니다. 그래서 지점마다 ECS 서비스와 EC2 인스턴스를 두었고, 외부 요청을 받는 ALB도 지점별로 하나씩 만들었습니다.
A 지점: 도메인 → ALB A → ECS A → EC2 A
B 지점: 도메인 → ALB B → ECS B → EC2 B
C 지점: 도메인 → ALB C → ECS C → EC2 C지점끼리 완전히 분리돼 있어 배포와 운영은 단순했습니다. 대신 지점이 하나 늘 때마다 ALB와 EC2도 하나씩 늘었습니다.
2. 검토와 판단
운영해 보니 지점별 트래픽은 크지 않은데 ALB마다 고정 비용이 따로 나가고 있었습니다. 같은 병원의 지점들이 서로 다른 프로젝트로 운영되더라도, 외부 요청을 받는 진입점까지 나눌 필요는 없다고 봤습니다.
| 구분 | 판단 |
|---|---|
| ALB | 같은 병원의 지점은 ALB 하나로 받고, 도메인에 따라 지점별 ECS 서비스로 나눔 |
| 개발 환경 EC2 | 트래픽이 적고 리소스를 엄격히 격리할 필요가 없어 인스턴스 하나로 통합 |
| 운영 환경 EC2 | 장애 영향 범위와 리소스 사용량을 고려해 지점별 인스턴스 유지 |
| Next.js 프로젝트·ECS 서비스 | 지점별로 따로 개발·배포할 수 있도록 그대로 유지 |
3. 실행과 조율
ALB 통합
지점마다 서브도메인이 달랐기 때문에 ALB의 Host-based Routing으로 요청 도메인을 보고 해당 지점의 ECS 서비스로 보내도록 설정했습니다.
a.hospital.com ─┐
b.hospital.com ─┼→ 공용 ALB ─┬→ ECS A
c.hospital.com ─┘ ├→ ECS B
└→ ECS C개발 서버 EC2 통합
개발 환경에서는 여러 지점의 ECS Task를 EC2 인스턴스 하나에서 실행하도록 바꿨습니다. 운영 환경은 지점별 EC2 인스턴스를 그대로 두었습니다.
4. 결과와 확인
[초기]
A → ALB A → ECS A → EC2 A
B → ALB B → ECS B → EC2 B
C → ALB C → ECS C → EC2 C
[개선 후]
운영: A·B·C → 공용 ALB → 지점별 ECS 서비스 → 지점별 EC2
개발: A·B·C → 공용 ALB → 지점별 ECS 서비스 → 공용 EC2지점별로 개발하고 배포하는 방식은 그대로 두고 ALB를 병원당 하나로 줄였습니다. 개발 환경은 EC2도 하나로 합쳐 인스턴스 비용을 더 줄였습니다.