AWS 비용 줄이기: EC2 다운사이징과 실제 확인 과정 정리

최근 AWS 비용을 다시 보면서, 어디서 먼저 줄여야 하는지 하나씩 확인해봤다. 결론부터 말하면, 이번에 가장 먼저 손댄 건 EC2 인스턴스 다운사이징이었다.

처음 비용 항목을 usage type 기준으로 보니 가장 큰 비중은 다음 세 가지였다.

• APN2-BoxUsage:t3.small
• APN2-PublicIPv4:InUseAddress
• APN2-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 정책은 다음 두 가지였다.

• AmazonSSMManagedInstanceCore
• CloudWatchAgentServerPolicy

메모리 지표는 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 축소는 확장보다 번거롭고, 작업 대비 이득이 크지 않음

그래서 우선순위는 이렇게 정리했다.

1. EC2 인스턴스 다운사이징
2. 운영 상태 모니터링
3. 이후 배포 구조와 Docker 구성 정리
4. 마지막에 필요하면 EBS 축소 검토

특히 EBS를 바로 줄이기보다는, 먼저 docker-compose.prod.yml, Dockerfile, 배포 흐름, 나중의 CI/CD 구조를 정리해서 운영 서버에 불필요한 이미지나 캐시가 쌓이지 않게 만드는 쪽이 더 본질적인 최적화라고 판단했다.

이번 작업을 통해 느낀 건, 비용 최적화는 단순히 “무조건 줄이기”가 아니라 실제 지표를 보고 줄일 수 있는 근거를 만든 다음 움직이는 게 맞다는 점이었다. 이번 경우엔 CPU와 메모리 모두 여유가 확인됐기 때문에, t3.micro로의 다운사이징은 꽤 자신 있게 진행할 수 있었다.

지금 단계의 결론은 이렇다.

• EC2는 한 단계 다운사이징 가능
• 퍼블릭 IP 변경은 도메인 사용 중이면 큰 문제 아닐 수 있음
• EBS 24GB는 다소 넉넉하지만, 지금 당장 줄일 우선순위는 낮음
• 다음 최적화 포인트는 인프라 축소보다 배포 구조와 CI/CD 정리