AWS 비용 최적화와 아키텍처 개선 1년 회고: 13년차 엔지니어의 삽질 노트
안녕하세요, 13년차 서버실 지킴이입니다. 오늘은 1년간의 삽질 끝에 얻어낸 소중한 경험, 바로 AWS 비용 최적화와 아키텍처 개선에 대한 회고를 풀어볼게요. 클라우드 사용하시는 분들이라면 한 번쯤은 예상치 못한 AWS 요금 폭탄에 가슴 철렁했을 거거든요. 저도 처음엔 '이게 다 뭐지?' 싶었는데, 1년 동안 끈질기게 파고들면서 실제로 비용을 크게 줄일 수 있었어요.
사실 저도 홈랩을 운영하면서 AWS를 이것저것 써보거든요. 처음에는 '그냥 쓰면 되겠지' 했는데, 시간이 지날수록 청구서가 정말 부담스럽게 다가왔어요. 그래서 '이대로는 안 되겠다!' 싶어서 작년부터 AWS 리소스들을 하나하나 뜯어보며 비용 회고(retrospective)를 시작했어요. 과연 어떤 부분을 개선했고, 어떤 삽질을 겪었는지 지금부터 솔직하게 이야기해볼게요.
캡션: 최적화 전후를 개념적으로 보여주는 아키텍처 다이어그램입니다.
AWS 비용, 왜 자꾸 불어날까요? 핵심 개념 이해하기
클라우드 비용은 땅속에 묻힌 보물찾기 같아요. 잘 찾으면 금덩이를 얻지만, 대충 파다간 시간만 날리죠. AWS 비용이 불어나는 주된 이유는 크게 몇 가지로 나뉘거든요. 컴퓨트(Compute), 스토리지(Storage), 데이터 전송(Data Transfer), 그리고 매니지드 서비스(Managed Services) 등이 대표적이죠. 이 중에서 비용 최적화에 특히 중요한 몇 가지 개념을 쉽게 풀어볼게요.
- Reserved Instances (RI, 예약 인스턴스): 특정 EC2 인스턴스 타입을 1년 또는 3년 약정하여 할인된 가격으로 사용하는 방식이에요. 선결제 방식에 따라 할인율이 달라지죠.
- Savings Plans (SP, 세이빙스 플랜): RI보다 훨씬 유연한 약정 할인 방식입니다. 특정 컴퓨트 사용량(예: 시간당 $X)을 약정하면 EC2, Fargate, Lambda 등 여러 서비스에 할인이 바로 적용돼요. 제가 직접 써보니 RI보다 훨씬 유연해서 좋더라고요.
- Spot Instances (스팟 인스턴스): AWS의 여유 컴퓨트 자원을 매우 저렴하게 사용할 수 있는 방식입니다. 하지만 AWS가 필요하면 언제든 회수해갈 수 있기 때문에, 중단되어도 괜찮은 배치 작업이나 워커 노드 등에 주로 사용해요.
- Auto Scaling (오토 스케일링): 트래픽 변화에 따라 EC2 인스턴스 수를 자동으로 조절하여 비용 효율성을 높이는 기능입니다. 피크 타임에만 인스턴스를 늘리고, 유휴 시간에는 줄여서 불필요한 비용 낭비를 막을 수 있거든요.
- Serverless (서버리스): 서버를 직접 관리할 필요 없이 코드만 실행하고 사용한 만큼만 비용을 지불하는 모델이에요. AWS Lambda가 대표적이죠. 작은 배치 작업이나 이벤트 기반 기능에 정말 유용해요.
- Managed Services (매니지드 서비스): AWS가 직접 운영 및 관리해주는 서비스입니다. RDS(관계형 데이터베이스 서비스), S3(객체 스토리지), ECS/EKS(컨테이너 서비스) 등이 있어요. 운영 부담을 줄여주지만, 서비스별 과금 체계를 잘 이해해야 합니다.
삽질하며 배운 AWS 비용 최적화 실전 전략
이제 제가 직접 겪었던 경험을 바탕으로 실질적인 비용 최적화 전략을 공유해드릴게요. 처음엔 막연하게 '어떻게 줄이지?' 싶었는데, 하나하나 파고드니 길이 보이더라고요.
1. 불필요한 리소스 제거: 시작은 청소부터!
가장 먼저 할 일은 바로 청소예요. 사용하지 않는 EC2 인스턴스, 연결되지 않은 EBS Volume, 오래된 스냅샷 같은 게 생각보다 많더라고요. `AWS Cost Explorer`나 `AWS Trusted Advisor`를 통해 유휴 리소스를 찾아내는 것이 중요해요. ⚠️ 특히 개발 환경에서 테스트용으로 띄워놓고 잊어버린 인스턴스들이 비용의 주범이 되는 경우가 많으니 주의해야 합니다.
제가 직접 해보니, `CloudWatch`를 통해 EC2 인스턴스의 CPU 사용률이 특정 기간 동안 5% 미만인 경우 알람을 받도록 설정해두면 유휴 인스턴스를 빠르게 찾아낼 수 있었어요. 그리고 이런 명령어를 활용해서 사용하지 않는 EBS 볼륨을 주기적으로 확인했죠.
aws ec2 describe-volumes \
--filters "Name=status,Values=available" \
--query 'Volumes[*].{ID:VolumeId,Size:Size,CreateTime:CreateTime}' \
--output table
이 명령어는 상태가 'available'인 EBS 볼륨, 즉 어떤 인스턴스에도 연결 안 된 놈들을 보여줘요. 이걸 보고 불필요한 볼륨은 바로 삭제했어요. 생각보다 꽤 많은 비용이 여기서 새고 있더라고요.
2. 컴퓨트 비용 줄이기: EC2, RDS 똑똑하게 쓰기
컴퓨트 자원이 AWS 비용의 대부분을 차지하거든요. 여기서 제대로 줄여야 비용 절감이 보여요.
- Reserved Instances (RI)와 Savings Plans (SP) 활용: 저희 서비스는 안정적으로 운영되는 코어 시스템이 많아서, 1년 약정 `Savings Plans`를 적극적으로 활용했어요. 제가 직접 써보니까 `Savings Plans`는 특정 인스턴스 타입에 묶이지 않고 컴퓨트 사용량에 따라 할인이 적용돼서, 나중에 인스턴스 타입을 변경해도 할인을 계속 받을 수 있다는 점이 정말 편하더라고요.
- Spot Instances 도입: 배치 처리나 개발/테스트 환경에서는 `Spot Instances`를 도입했어요. 물론 언제든 AWS가 인스턴스를 회수할 수 있지만, 비용 절감 효과가 정말 커서 충분히 감수할 가치가 있더라고요. 특히 `Auto Scaling Group`과 함께 쓰면 가용성 문제도 어느 정도 커버할 수 있거든요.
- Auto Scaling Group (ASG) 최적화: 트래픽 패턴을 분석해서 `ASG`의 최소/최대 인스턴스 개수를 조정하고, 스케일링 정책을 더 정교하게 다듬었어요. 단순히 CPU 사용률에만 의존하기보다, 요청 수나 네트워크 사용량 등 다양한 지표를 활용했죠.
3. 스토리지 및 데이터 전송 최적화: S3, EBS, EFS
스토리지와 데이터 전송 비용도 무시할 수 없거든요. 특히 `Data Transfer Out` 비용은 정말 예측 어려운 복병이 될 수 있어요.
- S3 Intelligent-Tiering (S3 인텔리전트 티어링): 자주 접근하지 않는 데이터를 자동으로 더 저렴한 스토리지 계층으로 이동시켜주는 `S3 Intelligent-Tiering`을 적극 활용했어요. 제가 직접 설정해보니, 데이터 접근 패턴을 일일이 신경 쓰지 않아도 돼서 관리 부담이 확 줄더라고요.
- EBS Snapshot 관리: `EBS Snapshot`은 백업에 중요한데, 오래되거나 불필요한 놈들이 쌓이면 비용이 계속 나가더라고요. Lifecycle Manager를 설정하여 오래된 스냅샷은 자동으로 삭제되도록 했어요.
- CloudFront (클라우드프론트) 활용: 웹 서비스의 정적 콘텐츠는 `CloudFront`를 통해 캐싱했어요. 사용자에게 더 빠르게 콘텐츠를 제공하고, 동시에 AWS 내부망을 통한 데이터 전송을 최적화하여 비용 절감 효과도 얻었죠.
4. 서버리스와 매니지드 서비스 적극 활용: 람다, RDS, ECS/EKS
운영 효율성과 비용 최적화를 동시에 잡을 수 있는 방법이 바로 서버리스와 매니지드 서비스의 활용이거든요. 제가 직접 경험한 사례를 말씀드릴게요.
제가 직접 `EC2`에서 돌리던 배치 작업을 `Lambda`로 마이그레이션했는데, 비용과 운영 부담이 확 줄더라고요. 특정 시간에만 실행되는 작업들은 `Lambda`가 정말 효율적이에요. 데이터베이스는 처음엔 `EC2`에 직접 설치해서 운영했어요. 근데 `RDS`로 전환하니 백업, 패치, 스케일링 같은 운영 부분을 AWS가 다 해주니까 팀 전체 만족도가 높았어요. 비용은 좀 더 들지만, 인력 투입 비용과 안정성을 생각하면 훨씬 이득이더라고요.
캡션: AWS Cost Explorer에서 비용 패턴을 분석하고 Savings Plans를 적용하는 화면 예시입니다.
⚠️ 삽질 대잔치: "이거 왜 이래요?" 해결 과정
비용 최적화 여정에서 삽질은 필수죠! 저도 예상치 못한 부분에서 비용 폭탄을 맞고 멘붕에 빠지기도 했어요. 가장 기억에 남는 몇 가지 사례를 공유할게요.
- Data Transfer Out 비용 폭탄: 가장 당황스러웠던 건 `NAT Gateway`를 통한 `Data Transfer Out` 비용이었어요. 처음엔 VPC Peering만 하면 되는 줄 알았는데, 프라이빗 서브넷에서 외부로 나가는 트래픽이 `NAT Gateway`를 통해 나가니까 생각보다 비용이 많더라고요. 그걸 간과했었네요. 해결책은 불필요한 외부 통신을 줄이고, 가능하다면 `VPC Endpoint`를 활용하여 AWS 내부망을 이용하도록 아키텍처를 개선하는 것이었어요.
- EBS Volume (EBS 볼륨) 관리 부주의: 삭제된 인스턴스에 붙어있던 `EBS Volume`이 `available` 상태로 남아있는 걸 뒤늦게 발견했을 때가 기억나요. '이게 뭔가 싶었는데', 작은 볼륨들이 쌓여서 은근히 비용이 나가고 있더라고요. 주기적인 검토와 자동화된 삭제 스크립트가 답이라는 걸 뼈저리게 배웠어요.
- CloudWatch Logs (클라우드워치 로그) 비용: 처음엔 모든 로그를 `CloudWatch Logs`로 보내고 무기한 보관하도록 설정해뒀어요. 근데 로그량이 늘어나니까 비용이 점점 커지더라고요. 모든 로그를 보관할 필요는 없다는 걸 깨달았고, 중요한 로그만 수집하고 보관 기간을 딱 정해서 비용을 줄였어요.
이런 문제들을 해결하려고 `VPC Flow Logs`를 분석해서 트래픽 흐름을 파악했고, `Cost Anomaly Detection`을 활용해서 평소와 다른 비용 패턴이 감지되면 알람을 받도록 설정했어요. 덕분에 이제 비용 문제가 생겨도 빠르게 대응할 수 있게 됐어요. 휴~ 삽질 좀 했습니다 ㅎㅎ.
🎉 1년 후, AWS 비용 최적화 성과는?!
1년간 노력한 결과, 상당한 비용 절감 효과를 봤어요. 구체적인 수치는 밝히긴 어렵지만, 평균적으로 약 30% 정도 AWS 비용을 줄일 수 있었어요. 단순 비용 절감뿐 아니라 아키텍처 자체의 탄력성과 관리 용이성도 크게 개선됐다는 게 더 큰 성과라고 봐요.
`AWS Cost Explorer`의 월별 리포트를 보면, 들쑥날쑥하던 비용이 점차 안정화되고 계속 내려가는 게 보여요. 특히 `Savings Plans`와 `Spot Instances` 덕분에 컴퓨트 비용이 정말 많이 줄었고, 스토리지와 데이터 전송도 효율적으로 관리할 수 있게 됐어요. 드디어 됐다! 하는 성취감도 컸고요.
캡션: AWS Cost Explorer에서 지난 1년간의 비용 절감 추이를 시각화한 그래프입니다.
클라우드 비용 최적화, 무엇을 얻었나?
1년간의 AWS 비용 최적화 여정을 통해 얻은 가장 큰 배움은 "비용 최적화는 한 번 끝나는 게 아니라 계속 진행되는 과정"이라는 거예요. 클라우드 환경은 끊임없이 변하고, 새 서비스도 자꾸 나오고, 사용 패턴도 자꾸 달라지거든요. 꾸준히 모니터링하고, 새 기술을 적용하고 아키텍처를 개선하려는 노력이 계속 필요해요.
이 과정을 통해 얻은 핵심적인 것들을 정리해볼게요.
- 비용 가시성 확보: `Cost Explorer`, `Billing Dashboard` 같은 도구로 어디서 비용이 발생하는지 명확히 알게 됐어요.
- 아키텍처 개선: 불필요한 리소스를 정리하고, 서버리스와 오토 스케일링을 도입해서 더 탄력적이고 효율적인 아키텍처를 만들었어요.
- 운영 효율성 증대: 매니지드 서비스와 자동화 도입으로 인프라 운영 부담이 확 줄어들었어요.
- 비용 절감: 당연히 가장 중요한 목표였죠! 절감된 비용으로 다른 중요한 곳에 더 투자할 수 있게 됐어요.
캡션: AWS 비용 최적화 전후의 주요 지표와 개선 사항을 요약한 인포그래픽입니다.
마치며: 클라우드 여정은 계속됩니다
13년차 인프라 엔지니어로서, 클라우드는 여전히 새로운 도전과 배움을 주더라고요. `AWS 비용 최적화`와 `아키텍처 개선`은 단지 돈을 아끼는 걸 넘어, 시스템을 더 깊이 이해하고 더 나은 구조를 만들어가는 과정이었어요. 삽질 좀 했지만, 덕분에 저도 한 뼘 더 성장한 것 같네요.
혹시 여러분도 AWS 비용 때문에 고민 중이신가요? 이 글이 클라우드 여정에 조금이라도 도움이 됐으면 좋겠어요. 그리고 혹시 비용 최적화 팁이 있으면 댓글로 나눠주세요! 저도 배우고 싶거든요. 다음 글에서는 FinOps 도입에 대해 더 자세히 다뤄볼 예정이에요. 그때까지 모두 즐거운 삽질(?) 하시길 바랍니다!
'IT > Cloud' 카테고리의 다른 글
| [Cloud] Cloudflare Turnstile, 프라이버시 침해 논란과 봇 방어의 미래 분석 (0) | 2026.06.03 |
|---|---|
| [Cloud] Cloudflare 대규모 감원, 클라우드 보안 시장과 사용자에게 미칠 영향 (0) | 2026.06.02 |
| [Cloud] AWS 클라우드 비용 폭탄 피하기: 1년 운영 회고와 절감 전략 (0) | 2026.05.30 |
| [Cloud] Flux CD 마이그레이션 경험기: Argo CD와 비교하며 (0) | 2026.05.29 |
| [Cloud] AWS IAM 권한 설계 베스트 프랙티스 - CISA GovCloud 키 유출 사건으로 배우는 클라우드 보안 (0) | 2026.05.29 |
| [Cloud] GitLab CI/CD, 월 300달러 린트 비용 낭비 막는 법 (1) | 2026.05.27 |