최근 AWS 비용을 다시 보면서, 어디서 먼저 줄여야 하는지 하나씩 확인해봤다. 결론부터 말하면, 이번에 가장 먼저 손댄 건 EC2 인스턴스 다운사이징이었다.
처음 비용 항목을 usage type 기준으로 보니 가장 큰 비중은 다음 세 가지였다.
APN2-BoxUsage:t3.smallAPN2-PublicIPv4:InUseAddressAPN2-EBS:VolumeUsage.gp3
이 중에서 가장 직접적으로 줄일 수 있는 건 역시 EC2 본체 비용이었다. 퍼블릭 IPv4나 EBS도 비용 원인이긴 했지만, 절감 효과만 보면 인스턴스 타입 조정이 우선이었다.
내 백엔드 서버는 서울 리전 EC2 한 대에서 다음을 같이 돌리고 있다.
- FastAPI API
- RQ worker
- Postgres
- Redis
처음에는 t3.small로 운영하고 있었는데, 이 구조에서 바로 다운사이징해도 되는지 먼저 확인이 필요했다.
무턱대고 줄였다가 메모리 부족이나 CPU 크레딧 문제로 서버가 불안정해지면 오히려 더 귀찮아지기 때문이다.
먼저 EC2 콘솔의 모니터링 탭에서 CPU 지표를 확인했다.
여기서 본 건 주로 아래 항목들이다.
- CPU 사용률
- CPU 크레딧 사용량
- CPU 크레딧 밸런스
며칠치 그래프를 봤을 때 CPU 사용률은 낮았고, CPU 크레딧 밸런스도 안정적으로 높게 유지되고 있었다. 즉, 적어도 CPU 때문에 t3.small을 유지할 이유는 크지 않아 보였다.
다음은 메모리였다.
EC2 기본 모니터링에는 메모리가 바로 안 보이기 때문에, CloudWatch Agent를 붙여 mem_used_percent를 확인했다.
이 과정에서 SSM 권한과 CloudWatch Agent 권한도 같이 정리했다.
추가로 붙인 IAM 정책은 다음 두 가지였다.
AmazonSSMManagedInstanceCoreCloudWatchAgentServerPolicy
메모리 지표는 CWAgent 네임스페이스에서 확인했고, 다운사이징 판단용으로는 mem_used_percent 하나만 수집하도록 최소 구성으로 설정했다.
직접 확인해보니 메모리 사용률은 대체로 27~28% 수준에서 안정적으로 유지되고 있었다.
여기까지 보고 나서는 판단이 꽤 명확해졌다.
- CPU 여유 있음
- CPU 크레딧 충분함
- 메모리 사용률도 낮음
그래서 t3.small에서 t3.micro로 한 단계 내리기로 결정했다.
실제로 인스턴스를 중지한 뒤 유형을 변경하고 다시 시작했는데, 여기서 한 가지 바로 체감한 점이 있었다. 퍼블릭 IPv4가 바뀐다는 것이다. 기존 IP는 바뀌었지만, 서버는 정상적으로 잘 올라왔다.
처음에는 “IP가 바뀌었는데 왜 서비스가 계속 잘 되지?” 싶었는데, 이유는 간단했다.
이미 백엔드 접속 주소를 **구매한 도메인 api.hahbr88.site**로 잡아두고 DNS를 연결해둔 상태였기 때문이다.
즉, 직접 IP를 쓰는 구조가 아니라 도메인을 통해 접근하고 있었기 때문에, 퍼블릭 IP가 바뀌어도 DNS만 올바르게 새 IP를 가리키면 서비스는 그대로 동작할 수 있었다.
이 과정에서 SSH 접속 문제도 한 번 있었다.
ssh: connect to host ... port 22: Operation timed out가 떴는데, 원인은 키 문제가 아니라 보안 그룹의 SSH 인바운드 규칙이 특정 공인 IP만 허용하고 있었기 때문이었다.
집과 학원처럼 접속 장소가 바뀌면 공인 IP도 달라질 수 있기 때문에, SSH 규칙은 내 IP 기준으로 다시 잡아주거나 장소별 공인 IP를 각각 허용해야 한다는 점도 다시 한번 확인했다.
디스크 사용량도 같이 확인했다.
df -h, docker system df, Docker volume 확인 결과를 보면 루트 볼륨 24GB 중 실제 사용량은 약 4.5GB 수준이었다.
Postgres 데이터 볼륨도 48MB 정도로 매우 작았고, Docker 이미지와 캐시를 합쳐도 전체 사용량은 많지 않았다.
이걸 보면 24GB EBS는 현재 상태에선 꽤 넉넉한 편이 맞다. 다만 여기서 바로 EBS 축소까지 진행하진 않기로 했다. 이유는 두 가지다.
- gp3 볼륨 비용 절감 효과는 인스턴스 다운사이징보다 작음
- EBS 축소는 확장보다 번거롭고, 작업 대비 이득이 크지 않음
그래서 우선순위는 이렇게 정리했다.
- EC2 인스턴스 다운사이징
- 운영 상태 모니터링
- 이후 배포 구조와 Docker 구성 정리
- 마지막에 필요하면 EBS 축소 검토
특히 EBS를 바로 줄이기보다는, 먼저 docker-compose.prod.yml, Dockerfile, 배포 흐름, 나중의 CI/CD 구조를 정리해서 운영 서버에 불필요한 이미지나 캐시가 쌓이지 않게 만드는 쪽이 더 본질적인 최적화라고 판단했다.
이번 작업을 통해 느낀 건, 비용 최적화는 단순히 “무조건 줄이기”가 아니라 실제 지표를 보고 줄일 수 있는 근거를 만든 다음 움직이는 게 맞다는 점이었다.
이번 경우엔 CPU와 메모리 모두 여유가 확인됐기 때문에, t3.micro로의 다운사이징은 꽤 자신 있게 진행할 수 있었다.
지금 단계의 결론은 이렇다.
- EC2는 한 단계 다운사이징 가능
- 퍼블릭 IP 변경은 도메인 사용 중이면 큰 문제 아닐 수 있음
- EBS 24GB는 다소 넉넉하지만, 지금 당장 줄일 우선순위는 낮음
- 다음 최적화 포인트는 인프라 축소보다 배포 구조와 CI/CD 정리