이 글은 Velog에서 이전한 글입니다. Velog 원문 보기
새로운 프로젝트의 인프라를 Terraform으로 구축하면서 여러 가지 선택지를 비교하고 검토했습니다.
이번 글에서는 왜 특정 아키텍처를 선택했는지, 어떤 대안을 고민했는지, 비용과 안정성 사이에서 어떤 결정을 내렸는지를 요구사항 중심으로 정리합니다.
1. 요구사항 정의
프로젝트 초기 단계에서 다음과 같은 요구사항이 있었습니다.
기능적 요구사항
- 외부 사용자 요청을 처리할 웹 서비스 배포
- API 서버는 ECS(EC2 기반)로 운영
- 데이터베이스는 RDS(MySQL) 사용
비기능적 요구사항
- 비용을 가능한 최소화할 것
- 추후 확장을 고려해 Terraform으로 모든 리소스 버전 관리
- 비용 절감을 위해 AWS 프리티어 만료마다 계정 이전 가능성이 있으므로, 인프라 코드화는 필수
- 필요 시 Multi-AZ로 전환할 수 있도록 기본 구조는 유지
제약 조건
- 초기 트래픽은 매우 낮을 것으로 예상
- 개인/소규모 프로젝트 수준의 비용 제한 존재
- NAT Gateway, Fargate처럼 지속적 비용이 큰 구조는 피해야 함
2. 인프라 구성 후보와 비교
초기 구상은 “무조건 Multi-AZ 구성”이었습니다.
그러나 실제 비용, 관리 난이도, 장애 허용도, 프로젝트 규모를 고려하며 다시 검토했습니다.
2-1. AZ 구성 선택지 비교
| 장점 | 단점 | ||
|---|---|---|---|
| 단일 AZ | 비용 최소화, 구성 단순 | 장애 시 복구 시간이 길 수 있음 | 낮음 |
| Multi-AZ | 고가용성 제공 | 비용 증가, 초기 트래픽 대비 과투자 | 높음 |
핵심 판단
- RDS Multi-AZ는 비용이 단일 AZ 대비 약 2배 수준
- ECS(EC2)도 Multi-AZ 구성 시 AZ마다 최소 1개 이상의 인스턴스 필요
- ALB는 활성화된 각 AZ마다 LCU 기반 비용이 발생
→ 멀티 AZ를 고려해 설계는 2개 AZ를 만들었지만 비용 절감을 위해 실제 ALB 활성화 AZ는 하나만 사용했습니다.
결론
- 단일 AZ로 구성하되, 필요 시 Multi-AZ로 확장 가능한 Terraform 구조만 유지
2-2. ECS 구성: Fargate vs EC2 비교
| Fargate | EC2 | |
|---|---|---|
| 비용 | 요청량 대비 지속 비용 발생 | Free Tier 활용 → 거의 0원 |
| 운영 편의성 | 인프라 관리 불필요 | 서버 패치, Auto Scaling 직접 관리 |
| 초기 적합성 | 편리하지만 비용 부담 큼 | 번거롭지만 비용 최저 |
추가 고려사항
- ECS-EC2 Launch Type은 Auto Scaling, Capacity Provider 등을 직접 관리해야 합니다.
- 하지만 Free Tier와 Reserved Instance까지 고려하면 장기적으로 EC2가 가장 비용 효율적인 선택지입니다.
결론
- ECS Launch Type은 EC2로 선택
2-3. Subnet 배치 전략: Public vs Private
| Public Subnet | Private Subnet | |
|---|---|---|
| ECS(EC2) | NAT 없이 인터넷 outbound 가능 | NAT Gateway 필요 |
| RDS | 외부 접근 위험 → 비적합 | 망분리 가능, 가장 안전 |
판단 근거
- NAT Gateway 비용만 약 월 40~50달러
- ECS 인스턴스는 크롤러 서버와의 통신 등 외부 Outbound 요청이 필수적이기 때문에, Private Subnet에 둔다면 NAT가 반드시 필요
- 비용을 최소화하기 위해 ECS를 Public Subnet에 배치하고, 대신 보안 그룹으로 ALB를 통한 접근만 허용하는 방식을 선택
NAT Gateway 비용(월 약 40~50달러)을 줄이기 위해 ECS를 Public Subnet에 배치했습니다.
대신 보안 그룹을 통해 inbound 접근은 ALB에서만 허용합니다.
결론
- ECS: Public Subnet
- RDS: Private Subnet
2-4. 최종 인프라 구조
VPC (10.0.0.0/16)
├── Public Subnet A (10.0.1.0/24)
│ ├── ALB (활성 AZ: A만 사용)
│ └── ECS EC2 Instances
│
├── Private Subnet A (10.0.101.0/24)
│ └── RDS
│
└── Route Tables
├── Public Subnet → IGW
└── Private Subnet → NAT 없음 (Outbound 차단)아직 전체 인프라가 완성된 것은 아니며, 초기 구성 단계입니다.
Terraform tfstate 관리를 위한 S3, Lock용 DynamoDB, 캐시 구조 등은 추후 추가할 예정입니다.
3. 테스트 및 검증
Terraform 배포 후 구성 요소가 의도한 대로 동작하는지 검증했습니다.
3-1. ALB → ECS 트래픽 전달 확인
- ALB DNS로 접근 시 컨테이너 정상 응답
- 보안 그룹:
- Inbound: ALB → ECS만 허용
- Outbound: Public Subnet이므로 IGW 통해 인터넷 사용 가능
3-2. RDS 접근 통제
- ECS에서만
RDS:3306접근 가능 - 외부 PC에서 직접 접근 불가
- Private Subnet이므로 외부로부터 접근 경로 자체가 존재하지 않음
3-3. 장애 시나리오 테스트
- AZ 단일 장애 발생 시 서비스 전체 중단
→ 단일 AZ 구성의 한계 확인 - 초기 트래픽과 리스크를 고려하면 수용 가능한 수준
3-4. 비용 검증
- EC2 Free Tier → ECS 비용 거의 0원
- NAT Gateway 제거 → 월 약 40~50달러 절감
- RDS는 Free Tier(t3.micro + 20GB 스토리지) 내에서 운영 가능
→ 초기 비용을 0원으로 유지할 수 있음
단, S3 import/export, AWS 서비스와의 통신이 필요하면 NAT 환경을 다시 고려해야 합니다.
결론: 왜 이 아키텍처인가?
이번 구성은 기술적 완성도보다 비용 최적화를 우선한 전략입니다.
- 단일 AZ = 비용 최소화
- EC2 Launch Type = Free Tier 활용
- RDS Private Subnet = 보안 강화
- ECS Public Subnet = NAT 비용 절감
- Terraform 기반 = Multi-AZ 전환 가능성 확보
결국 초기 비용 최소화 + 추후 확장 가능성 유지라는 목적을 가장 효율적으로 충족한 구조입니다.