1. 할인 약정(RI/SP)을 걸어도 청구서가 그대로라면, 단순히 ‘단가’만 낮추고 불필요한 ‘소유’는 그대로 뒀기 때문입니다.
2. 사용하지 않는 EBS 볼륨과 NAT 게이트웨이 경로만 정리해도 비용의 30%는 바로 빠집니다.
청구서를 볼 때마다 한숨부터 나오시죠? “아니, 분명 AWS 예약 인스턴스(RI)도 샀고 Savings Plans(SP) 약정도 걸었는데 왜 총액은 저번 달이랑 똑같지?” 이런 생각, 저만 하는 게 아니더라고요.
결론은 하나였습니다. 우리가 단순히 가격을 깎는 것에만 집중했지, 우리가 이걸 왜 가지고 있어야 하는가에 대한 본질적인 질문을 놓치고 있었기 때문입니다.
단순히 “아껴 쓰자”는 잔소리가 아닙니다. 비용 효율화(Cost Optimization)를 넘어, 우리 인프라가 진짜 가치(Value)를 창출하고 있는지 점검하는 5가지 핵심 방법을 정리해 봤습니다.
사용하지 않는 EBS와 스냅샷 (소유보다는 비움)
프로젝트가 끝나서 EC2 인스턴스는 분명히 꼈는데, 이상하게 스토리지 비용은 계속 나가는 경우가 정말 많습니다. 제가 확인해보니 이게 시스템상의 허점이라기보다는, 우리의 ‘설정 습관’ 때문이더군요.
서버를 삭제할 때 ‘Delete on Termination’ 옵션을 체크하지 않으면, 서버만 사라지고 데이터가 담긴 EBS 볼륨은 그대로 남습니다. 더 이상 쓰지 않는 데이터인데, 마치 창고에 방치된 짐처럼 매달 비용을 발생시키는 거죠. 특히 고성능 IOPS(프로비저닝 된 IOPS SSD) 볼륨이라면 켜두기만 해도 비용이 상당합니다.
□ 미연결 볼륨(Unattached EBS) 삭제: 2주 이상 연결되지 않은 볼륨은 과감하게 지우세요.
□ 스냅샷 수명주기(Lifecycle) 관리: “혹시 몰라” 남겨둔 1년 전 백업 데이터가 현재 어떤 가치를 주나요? 영감을 주지 못하는 데이터는 비워내야 새로운 가치를 담습니다.
네트워크 비용 최적화 (단순하고 명료한 연결)
트래픽은 평소랑 비슷한데 데이터 처리 비용(Data Processing)이 급증했다면, 데이터가 다니는 길이 너무 꼬불꼬불한 건 아닌지 의심해봐야 합니다.
보안 때문에 프라이빗 서브넷(Private Subnet)을 많이 쓰시죠? 그런데 여기서 S3나 DynamoDB 같은 같은 AWS 내부 서비스랑 통신할 때도 굳이 NAT 게이트웨이를 거쳐서 외부로 나갔다 들어오게 구성하는 경우가 많습니다. 이건 마치 옆 방 동료랑 대화하는데 굳이 회사 밖으로 나가서 전화를 거는 것과 같습니다. 불필요한 요금을 내는 셈이죠.
□ VPC Endpoint 사용: 내부 서비스끼리는 VPC 엔드포인트를 뚫어주세요. 비용도 아끼고 보안도 좋아집니다.
□ AZ(가용 영역) 간 통신 최소화: 서울 리전(ap-northeast-2) 안이라도 A존과 C존을 오가면 데이터 전송 비용이 듭니다. 로드밸런서나 DB 구성을 체크해보세요.
오버 프로비저닝 탈피 (두려움 대신 유연함 선택)
온프레미(물리 서버) 시절에는 트래픽 폭주가 무서워서 무조건 큰 서버를 샀습니다.
하지만 클라우드에서도 CPU 사용률이 평생 5%를 넘지 않는 거대 인스턴스를 유지하는 건, 클라우드의 핵심 가치인 유연성(Agility)을 믿지 못하는 것입니다.
m5.xlarge를 쓰고 있는데 평균 사용률이 10% 미만이라면, 그건 안정적인 게 아니라 낭비입니다.
□ 라이트사이징(Rightsizing): AWS Compute Optimizer 같은 도구를 돌려보세요. 현재 워크로드에 딱 맞는 사이즈를 추천해줍니다.
□ 최신 세대 교체: 귀찮다고 구형 인스턴스(m4 등)를 고집하지 마세요. 신형(m6i, m7g)이 가격 대비 성능이 훨씬 좋습니다.
개발 서버 스케줄링 (지속 가능한 리듬 만들기)
개발자분들 퇴근하셨는데, 개발 서버는 왜 새벽 3시에도 켜져 있을까요? 24시간 돌아가는 개발 서버는 가치를 창출하는 게 아니라, 그냥 전기를 태우는 겁니다.
자연에도 낮과 밤이 있듯이, 시스템에도 쉼(Rest)을 줘야 합니다. 이게 단순한 전기세 절약이 아니라, 인프라 운영의 리듬을 만드는 겁니다.
□ 인스턴스 스케줄러(Instance Scheduler): 업무 시간(예: 09:00~19:00)에만 켜지고, 밤과 주말에는 자동으로 꺼지게 설정하세요. 이것만 해도 개발계 비용의 70%가 줄어듭니다.
태깅(Tagging) 정책 (이름과 책임 부여)
청구서를 봤는데 “이 리소스는 누가 만든 거지?”라는 말이 나온다면, 그건 이미 관리 실패입니다. 이름표(Tag)가 없는 리소스는 조직 내에서 책임 소재가 불분명한 상태로 떠돌아다닙니다. 누구 건지 모르니, 인프라 담당자는 혹시나 장애가 날까 봐 삭제도 못 합니다.
□ 태그 강제화(Tag Enforcement): 생성 시 Project, Owner 태그가 없으면 아예 생성이 안 되게 막으세요.
□ 미태깅 리소스 삭제 예고: “주인 없는 리소스는 이번 주 금요일에 일괄 회수합니다”라고 공지하는 것이 가장 확실한 방법입니다.
가치를 만드는 인프라 체크리스트
그냥 “아끼자”가 아니라, “이게 정말 필요한가?”를 기준으로 판단할 수 있게 정리해 드립니다.
□ 스토리지: “삭제하면 나중에 필요할까?” → “과거의 짐을 비워야 새 혁신이 들어온다.” (미사용 EBS 즉시 삭제)
□ 네트워크: “트래픽 비용이 왜 이래?” → “데이터 경로를 직관적으로 뚫었는가?” (VPC Endpoint 도입)
□ 컴퓨팅: “일단 큰 거 사!” → “시스템의 유연함(Auto Scaling)을 믿자.” (과감한 사이즈 축소)
□ 운영: “귀찮으니 켜둬.” → “시스템에도 리듬(On/Off)을 주자.” (업무 시간 외 자동 중지)
관리: “일단 놔둬.” → “모든 자원에 이름(정체성)을 붙이자.” (비용 배분 태그 필수화)
자주 묻는 질문 (Q&A)
제가 글을 쓰면서 주변 개발자분들에게 가장 많이 들었던 질문들을 딱 정리해 드릴게요.
A. Convertible RI(전환형 예약 인스턴스)나 Savings Plans(Compute SP)를 구매하셨다면 가능합니다. 하지만 일반 Standard RI라면 타입 변경이 어렵습니다. 그래서 요즘은 유연한 Savings Plans를 더 선호하는 추세입니다.
A. AWS Tag Editor나 Azure Resource Graph를 쓰면 대량으로 태그를 한 번에 붙일 수 있습니다. 일단 서비스 단위나 팀 단위로 큼직하게 먼저 붙이고 세분화하는 걸 추천합니다.
A. 맞습니다. 그래서 개발 서버라도 DNS를 연결하거나, 고정 IP를 할당해서 쓰는 게 좋습니다. 단, 서버를 껐을 때 고정 IP 비용이 소액 발생할 수 있다는 점은 체크하셔야 합니다.
[관련 자료]
