본문 바로가기
IT/Cloud

[Cloud] AWS 클라우드 비용 폭탄 피하기: 1년 운영 회고와 절감 전략

by 수누다 2026. 5. 30.

AWS 클라우드 비용 폭탄 피하기: 1년 운영 회고와 절감 전략

안녕하세요, 13년차 서버실 지킴이입니다. 😅 오늘은 클라우드, 특히 AWS 비용 절감에 대한 제 경험을 좀 풀어보려 합니다. 클라우드가 참 편리하잖아요? 필요한 만큼 쓰고, 안 쓰면 돈 나갈 일 없고… 처음엔 그렇게 생각했죠. 근데 말입니다, 이게 생각보다 AWS 비용 폭탄으로 돌아올 때가 많더라고요. 저도 홈랩을 운영하면서 이것저것 실험하다가 "헉, 이게 뭐야?!" 하면서 요금 명세서를 받아 든 적이 한두 번이 아니거든요.

특히 작은 프로젝트나 개인 홈랩에서 아무 생각 없이 자원을 굴리다 보면, 어느새 월말에 등골이 오싹해지는 경험, 혹시 있으신가요? 오늘은 제가 1년 동안 AWS를 운영하면서 겪었던 삽질과, 그 과정에서 얻은 클라우드 비용 관리 노하우, 그리고 실질적인 AWS 비용 최적화 전략들을 솔직하게 공유해 보려고 합니다. 이 글이 여러분의 클라우드 운영에 작은 멘토가 되기를 바랍니다!

AWS 서비스들이 복잡하게 연결되어 있고, 비용이 상승하는 모습을 나타내는 다이어그램

클라우드 환경에서 다양한 AWS 서비스들이 상호 연결되어 있고, 예상치 못한 비용 상승을 보여주는 개략적인 다이어그램입니다. 각 서비스의 비용 발생 요소를 시각적으로 이해하는 데 도움이 됩니다.

왜 클라우드 비용은 예상보다 많이 나올까요? (비용 폭탄의 주범들)

사실 클라우드의 Pay-as-you-go (사용한 만큼 지불) 모델은 양날의 검입니다. 유연하다는 장점은 있지만, 사용량 예측을 잘못하거나 불필요한 자원을 방치하면 그대로 비용으로 직결되죠. 제가 겪었던 주요 비용 폭탄의 주범들을 몇 가지 꼽아볼게요.

  • 잊혀진 EC2 인스턴스 (Forgotten EC2 Instances): 개발/테스트용으로 잠깐 띄워놓고 끄는 걸 깜빡한 인스턴스들이 생각보다 많습니다. 특히 Free Tier 기간이 끝난 후에도 계속 돌아가고 있으면… 💸
  • EBS 볼륨 및 스냅샷 (EBS Volumes & Snapshots): EC2를 삭제해도 EBS 볼륨이 남아있는 경우가 많고, 오래된 스냅샷들이 계속 쌓여서 비용을 잡아먹는 경우가 꽤 흔합니다.
  • 데이터 전송 비용 (Data Transfer Costs): 특히 AWS 외부로 나가는 Egress (이그레스, 외부 트래픽 송신) 트래픽은 비용이 비쌉니다. S3에서 대량의 데이터를 다운로드하거나, CDN을 사용하지 않고 직접 서비스를 외부에 노출할 때 폭탄을 맞을 수 있습니다.
  • NAT Gateway (NAT 게이트웨이): Private Subnet (프라이빗 서브넷)의 인스턴스가 인터넷에 접속할 때 사용하는 NAT Gateway는 인스턴스 시간당 요금과 처리되는 데이터 양에 따라 비용이 발생합니다. 작은 규모에서는 무시할 수 없더라고요.
  • 관리형 서비스의 숨겨진 비용: RDS, ElastiCache 같은 관리형 서비스는 편리하지만, 인스턴스 유형과 저장 공간, 백업 정책 등에 따라 비용이 크게 달라질 수 있습니다.

13년차 인프라 엔지니어의 AWS 1년 운영 회고 (삽질 기록)

제가 처음 AWS를 시작했을 때는 Free Tier (프리 티어) 덕분에 참 행복했습니다. EC2 t2.micro로 웹 서버도 띄워보고, S3에 정적 웹사이트도 호스팅 해보고… 근데 홈랩 프로젝트가 점점 커지면서, 저도 모르게 프리 티어 범위를 훌쩍 넘어가더라고요. 처음 AWS 예산 설정 없이 막 쓰다가 첫 요금 명세서를 보고 깜짝 놀랐습니다.

가장 큰 삽질은 역시 "방치된 자원"이었습니다. 개발용 EC2 인스턴스를 주말에 잠깐 켜놓고 작업하다가, 끄는 걸 깜빡하고 퇴근한 적이 여러 번 있었죠. 월요일에 출근해서 정신없이 업무를 보다가 문득 "어? 그 서버 아직 켜져 있나?" 하고 확인해 보면 이미 이틀치 요금이 청구된 상태… 🤦‍♂️ 처음에는 그냥 "에이, 뭐 얼마나 나오겠어?" 했는데, 이런 게 쌓이고 쌓이니 무시 못 할 금액이 되더라고요.

또 하나는 NAT Gateway였습니다. Private Subnet에 있는 제 서버가 외부 패키지를 다운로드하거나 API를 호출할 때 NAT Gateway를 거치는데, 이게 데이터 처리량에 따라 요금이 꽤 나옵니다. "어? 트래픽도 별로 없는데 왜 이렇게 비싸지?" 하고 Cost Explorer (코스트 익스플로러)를 자세히 들여다보니 NAT Gateway가 상위권에 떡하니 버티고 있더라고요. 이때부터 클라우드 비용 관리의 중요성을 절실히 깨달았습니다.

비용 절감을 위한 핵심 전략: 이 세 가지는 꼭 확인하세요!

이런 삽질들을 통해 저는 세 가지 핵심 전략을 세웠습니다. 여러분도 이 세 가지를 먼저 점검해 보시면 좋을 것 같아요.

1. 자원 최적화 (Resource Optimization)

  • EC2 인스턴스:
    • Spot Instances (스팟 인스턴스): 중단되어도 괜찮은 워크로드(배치 처리, CI/CD 등)라면 스팟 인스턴스를 활용하세요. 온디맨드(On-Demand)보다 훨씬 저렴하더라고요.
    • Reserved Instances (RI, 예약 인스턴스) / Savings Plans (세이빙스 플랜): 1년 또는 3년 약정을 통해 온디맨드 대비 30~70%까지 할인받을 수 있어요. 꾸준히 사용할 워크로드에 적합합니다.
    • 인스턴스 스케줄링: 개발/테스트용 인스턴스는 업무 시간 외에 자동으로 중지되도록 스케줄링하는 것이 필수입니다. Lambda와 CloudWatch Events를 활용하면 쉽게 구현할 수 있어요.
  • EBS 볼륨 & 스냅샷:
    • 미사용 볼륨 삭제: EC2 인스턴스 삭제 시 연결된 EBS 볼륨이 자동으로 삭제되는지 확인하고, 미사용 볼륨은 주기적으로 정리하세요.
    • 스냅샷 라이프사이클 관리 (Snapshot Lifecycle Management): 오래된 스냅샷은 삭제하거나, 더 저렴한 스토리지 클래스(예: Amazon S3 Glacier)로 옮기는 정책을 설정하세요.
  • S3 스토리지 클래스 최적화:
    • 데이터 접근 빈도에 따라 S3 Standard, S3 Standard-IA (Infrequent Access), S3 Glacier 등으로 스토리지 클래스를 적절히 선택하세요. IA나 Glacier는 훨씬 저렴하더라고요.

2. 비용 가시성 확보 (Cost Visibility)

어디서 돈이 나가는지 알아야 절약을 하죠. 저는 다음 도구들을 적극 활용했습니다.

  • AWS Cost Explorer (코스트 익스플로러): 가장 기본적인 도구입니다. 월별, 일별 사용량과 비용을 그래프로 시각화해서 보여줘요. 서비스별, 리전별, 태그별로 필터링해서 볼 수 있어서 어디서 비용이 많이 나오는지 한눈에 파악하기 좋더라고요.
  • AWS Budgets (AWS 예산): 특정 서비스나 계정에 대한 예산 임계값을 설정하고, 이 임계값에 도달하거나 초과할 경우 알림(SNS, 이메일)을 받을 수 있어요. 저처럼 깜빡하는 분들에게는 필수입니다!
  • Cost & Usage Report (CUR, 비용 및 사용 보고서): 가장 상세한 비용 데이터입니다. S3 버킷으로 CSV 파일 형태로 받아볼 수 있는데, 이걸 Athena나 QuickSight 같은 도구와 연동해서 심층 분석할 수 있어요. 처음엔 좀 어려울 수 있지만, 제대로 된 클라우드 비용 관리를 위해서는 결국 CUR을 보게 되더라고요.

3. 아키텍처 개선 (Architectural Refinement)

기술적인 해결책으로 비용을 절감하는 방법입니다.

  • NAT Gateway 대체:
    • S3나 DynamoDB 같은 AWS 서비스에 접속하는 경우, VPC Endpoint (VPC 엔드포인트)를 사용하면 NAT Gateway를 거치지 않고 Private Link (프라이빗 링크)를 통해 직접 연결되어 데이터 전송 비용을 절감할 수 있어요.
    • 아니면 자체적으로 EC2에 NAT 인스턴스를 구성하는 방법도 있지만, 관리 부담이 늘어납니다.
  • 데이터 전송 최적화:
    • 정적 콘텐츠는 Amazon CloudFront (클라우드프론트) 같은 CDN을 사용하세요. 엣지 로케이션에서 사용자에게 콘텐츠를 제공하므로, S3에서 직접 나가는 트래픽보다 훨씬 저렴하고 빠릅니다.
    • 리전 간 데이터 전송(Cross-Region Data Transfer)은 비용이 비싸니, 가능하면 같은 리전 내에서 통신하도록 아키텍처를 설계하는 것이 좋아요.
  • 서버리스 (Serverless) 활용:
    • 간헐적으로 실행되는 백엔드 로직이나 API는 AWS Lambda (람다)를 활용하면 좋습니다. 사용한 만큼만 요금을 내기 때문에, 유휴 시간에 발생하는 비용을 없앨 수 있어요.
    • 정적 웹사이트는 S3 Static Website Hosting (S3 정적 웹사이트 호스팅)과 CloudFront를 조합하면 매우 저렴하게 운영할 수 있습니다.

실전! AWS 비용 절감 설정 따라하기

제가 실제로 효과를 본 두 가지 설정을 예시로 보여드릴게요. 따라 해보시면 바로 효과를 보실 수 있을 겁니다.

1. AWS Budgets 설정하기 (feat. 월별 비용 알림)

이건 정말 필수입니다. 예산을 설정해두면 예상치 못한 비용 폭탄을 미리 방지할 수 있어요.

  1. AWS 콘솔 로그인 후 'Budgets' 검색: Management Console (관리 콘솔)에 로그인해서 검색창에 'Budgets'를 입력하고 이동합니다.
  2. 'Create budget' 클릭: 새 예산을 생성합니다.
  3. 'Cost budget' 선택: 비용 예산을 선택하고 'Next'를 클릭합니다.
  4. 예산 세부 정보 설정:
    • Period (기간): 'Monthly' (월별)
    • Budget type (예산 유형): 'Fixed' (고정) 또는 'Planned' (계획)
    • Budget amount (예산 금액): 여러분이 생각하는 최대 허용 금액을 입력합니다. (예: 50 USD)
    • Scope (범위): 모든 AWS 서비스를 대상으로 할지, 특정 서비스(예: EC2)만 대상으로 할지 선택합니다. 저는 보통 'All AWS services'로 설정해두는 편입니다.
  5. 알림 설정 (Alerts):
    • Threshold (임계값): 'Actual' (실제 비용)이 '80%'에 도달하면 알림을 받도록 설정합니다. (예: 80% of budgeted amount)
    • Email recipients (이메일 수신자): 알림을 받을 이메일 주소를 입력합니다.
    • 'Next'를 클릭하여 마무리합니다.

이렇게 설정해두면, 예산에 근접하거나 초과할 때마다 이메일로 알림을 받을 수 있어서 바로 조치를 취할 수 있습니다. 이거 하나만으로도 불필요한 지출을 많이 막았네요. 💡

AWS Budgets 콘솔에서 EC2 서비스에 대한 월별 예산을 설정하고, 임계치에 따른 알림을 구성하는 화면

AWS Budgets 콘솔에서 EC2 서비스에 대한 월별 예산을 설정하고, 실제 비용이 예산의 80%에 도달하면 알림을 받도록 구성하는 화면입니다. 이메일 수신자를 지정하여 즉각적인 대응이 가능하도록 설정할 수 있습니다.

2. 개발/테스트용 EC2 인스턴스 스케줄링 (feat. Lambda & CloudWatch Events)

24시간 돌릴 필요 없는 인스턴스는 자동으로 끄고 켤 수 있게 설정하면 비용을 절반 이상 줄일 수 있습니다.


import boto3

def lambda_handler(event, context):
    ec2 = boto3.client('ec2', region_name='ap-northeast-2') # 본인 리전으로 변경

    # 특정 태그가 있는 인스턴스만 제어 (예: Environment: dev)
    filters = [
        {'Name': 'tag:Environment', 'Values': ['dev']},
        {'Name': 'instance-state-name', 'Values': ['running']} # 현재 실행 중인 인스턴스
    ]
    
    # 인스턴스 중지
    instances = ec2.describe_instances(Filters=filters)
    instance_ids = []
    for reservation in instances['Reservations']:
        for instance in reservation['Instances']:
            instance_ids.append(instance['InstanceId'])

    if instance_ids:
        ec2.stop_instances(InstanceIds=instance_ids)
        print(f"Stopped instances: {instance_ids}")
    else:
        print("No running 'dev' instances found to stop.")

    # 인스턴스 시작 (다른 람다 함수나 다른 이벤트로 분리하는 것이 일반적)
    # filters = [
    #     {'Name': 'tag:Environment', 'Values': ['dev']},
    #     {'Name': 'instance-state-name', 'Values': ['stopped']} # 현재 중지된 인스턴스
    # ]
    # instances_to_start = ec2.describe_instances(Filters=filters)
    # start_instance_ids = []
    # for reservation in instances_to_start['Reservations']:
    #     for instance in reservation['Instances']:
    #         start_instance_ids.append(instance['InstanceId'])
    #
    # if start_instance_ids:
    #     ec2.start_instances(InstanceIds=start_instance_ids)
    #     print(f"Started instances: {start_instance_ids}")
    # else:
    #     print("No stopped 'dev' instances found to start.")

위 Python 코드를 Lambda 함수로 만들고, CloudWatch Events (또는 EventBridge)로 특정 시간에 실행되도록 스케줄링하면 돼요. 예를 들어, 평일 저녁 7시에 중지하고, 평일 아침 9시에 시작하도록 설정하는 거죠. 인스턴스에는 <code>Environment: dev 같은 태그를 붙여서 관리하면 편리합니다. 제가 직접 써보니, 이 방법으로 개발 서버 비용을 정말 많이 아꼈습니다. ✅

⚠️ 삽질 경험 공유: 저도 이런 문제 겪었습니다!

비용 절감 노력을 하면서도 예상치 못한 문제에 부딪히곤 했습니다. 몇 가지 팁을 드릴게요.

  • 스케줄링 누락: EC2 스케줄링을 설정했더라도, 새로 생성한 인스턴스에 태그를 붙이는 걸 깜빡하거나, 스케줄링 대상에서 누락되는 경우가 있었습니다. 주기적으로 태그를 확인하고, 모든 개발/테스트 인스턴스가 스케줄링 대상인지 점검하는 루틴을 만드세요.
  • Cost Explorer의 함정: Cost Explorer는 편리하지만, 정확한 비용 분석을 위해서는 CUR (Cost & Usage Report)를 보는 게 좋아요. 특히 데이터 전송 비용 같은 세부 항목은 CUR에서 더 명확하게 파악할 수 있거든요. 처음엔 CSV 파일이 너무 방대해서 당황했지만, Athena로 쿼리 해보니 훨씬 유용하더라고요.
  • NAT Gateway 비용의 재발견: VPC Endpoint를 설정해도, 모든 트래픽이 VPC Endpoint로 가는 것은 아닙니다. 특히 외부 인터넷으로 나가는 트래픽은 여전히 NAT Gateway를 거치기 때문에, 네트워크 아키텍처를 잘 이해하고 불필요한 외부 통신을 줄이는 것이 중요합니다.
  • 백업 비용: RDS나 EBS 스냅샷 백업 정책을 무심코 '매일'로 설정해두면, 오래된 백업들이 쌓여서 은근히 비용이 나옵니다. 필요한 보존 기간을 설정하고, 라이프사이클 정책을 꼭 적용해주세요.

비용 절감, 과연 얼마나 효과가 있었을까요? (결과 검증)

이러한 AWS 비용 최적화 전략들을 적용한 결과, 제 홈랩의 월별 AWS 청구서는 이전 대비 평균 40% 이상 감소했습니다. 특히 EC2 인스턴스 스케줄링과 미사용 EBS 볼륨 정리, 그리고 NAT Gateway 트래픽 최적화가 가장 큰 기여를 했어요.

처음에는 "이걸 언제 다 해?" 싶었는데, 하나씩 적용하고 Cost Explorer로 효과를 확인하는 재미가 쏠쏠하더라고요. 특히 AWS Budgets에서 "예산 초과 임박" 알림이 오지 않을 때의 그 뿌듯함이란! 🎉 물론 실시간으로 비용을 0으로 만들 수는 없겠지만, 불필요한 지출을 확실히 줄이고, 꼭 필요한 곳에만 비용을 쓰는 현명한 클라우드 운영이 가능해졌습니다.

AWS 월별 비용이 전략 적용 전후로 크게 감소한 것을 보여주는 대시보드 그래프

AWS 비용 절감 전략 적용 전후의 월별 비용 추이를 보여주는 대시보드 그래프입니다. 전략 적용 이후 비용이 확연히 감소한 것을 확인할 수 있습니다.

마무리하며: 클라우드 비용 관리는 지속적인 여정입니다

클라우드 비용 관리는 한 번 설정하고 끝나는 일이 아닙니다. 서비스가 계속 변하고, 새로운 기능이 추가되며, 우리 워크로드도 진화하기 때문에 꾸준히 모니터링하고 최적화해야 합니다. 마치 홈랩 서버실의 전기 요금을 아끼기 위해 어떤 장비를 끄고 켤지 고민하는 것과 같죠.

제가 오늘 공유해드린 AWS 비용 절감 전략들이 여러분의 클라우드 여정에 도움이 되었기를 바랍니다. 처음부터 모든 걸 완벽하게 하려고 하기보다는, 작은 것부터 하나씩 시작해보는 것을 추천해요. AWS Budgets 설정하고, 안 쓰는 인스턴스부터 끄는 것만으로도 큰 변화를 느낄 수 있을 겁니다!

다음 글에서는 더 심도 있는 Cost & Usage Report (CUR) 분석 방법이나, FinOps (파이놉스) 문화 도입 같은 주제로 찾아올게요. 그때까지 여러분의 클라우드 서버실도 건강하고, 지갑도 건강하시기를!

클라우드 비용 최적화를 위한 세 가지 핵심 전략을 요약한 인포그래픽

클라우드 비용 최적화를 위한 핵심 전략인 자원 최적화, 비용 모니터링, 아키텍처 검토를 시각적으로 요약한 인포그래픽입니다. 각 전략의 중요성을 한눈에 파악할 수 있도록 디자인되었습니다.