[AWS SAA] 비용 최적화

 

비용 최적화 핵심 개념

• AWS 비용 최적화는 필요한 성능과 가용성을 유지하면서 불필요한 비용을 줄이는 것
• 사용량이 일정한 워크로드는 약정 기반 할인 옵션을 고려
• 중단 가능한 워크로드는 Spot Instance를 고려
• 사용하지 않는 리소스는 중지하거나 삭제
• 과도하게 큰 인스턴스, 볼륨, 데이터베이스는 실제 사용량에 맞게 조정
• S3 데이터는 접근 패턴에 맞는 스토리지 클래스를 사용
• NAT Gateway, 데이터 전송, 미완료 멀티파트 업로드처럼 눈에 잘 보이지 않는 비용도 확인 필요
• 비용 분석은 Cost Explorer, 예산 알림은 AWS Budgets, 이상 지출 탐지는 Cost Anomaly Detection을 사용

EC2 구매 옵션 비교

옵션	특징	사용 시나리오
On-Demand	약정 없이 필요한 만큼 사용. 비용은 상대적으로 높음	단기 테스트, 예측 불가 워크로드, 갑작스러운 확장
Reserved Instance	1년 또는 3년 약정으로 비용 절감	상시 실행 워크로드, DB, 안정적인 사용량
Spot Instance	AWS의 남는 용량을 저렴하게 사용. 중단 가능	배치, 시뮬레이션, CI/CD, 중단 감내 가능 워크로드
Dedicated Host	물리 서버 단위 전용 호스트 할당	BYOL, 라이선스 호환성, 규제 준수
Savings Plans	일정 사용량을 약정하고 비용 절감	장기적으로 안정적인 컴퓨팅 사용량

• On-Demand는 약정이 없고 유연하지만 비용이 높음
• Reserved Instance는 특정 인스턴스나 DB처럼 장기 상시 실행되는 워크로드에 적합
• Spot Instance는 최대 90%까지 할인될 수 있지만 중단 가능성을 감수해야 함
• Dedicated Host는 전용 호스트를 구매하는 것이 아니라, 물리 호스트 단위로 전용 용량을 할당받는 옵션
• 라이선스 BYOL, 소켓/코어 단위 라이선스 관리, 강한 물리적 격리 요구사항이 있으면 Dedicated Host 고려
• 장기적으로 항상 필요한 기본 용량은 Reserved Instance 또는 Savings Plans로 커버하고, 피크 부하는 On-Demand 또는 Spot Instance로 처리하는 조합이 비용 효율적
• 중단을 감내할 수 있는 피크 부하, 배치, 분석 작업은 Spot Instance를 적극 고려
• 중단되면 안 되는 핵심 서비스의 갑작스러운 피크 부하는 On-Demand가 더 적합할 수 있음

Savings Plans

핵심 개념

• Savings Plans는 일정 사용량을 약정하고 할인받는 비용 절감 모델
• 1년 또는 3년 약정을 선택할 수 있음
• 시간당 일정 금액 사용을 약정하는 방식
• 사용량 약정 범위 안에서 할인 적용
• 사용량이 안정적으로 발생하는 컴퓨팅 워크로드에 적합
• Reserved Instance보다 더 유연한 비용 절감 옵션으로 사용되는 경우가 많음

Savings Plans 유형

유형	특징
Compute Savings Plans	EC2, Lambda, Fargate 사용량에 적용. 인스턴스 패밀리, 크기, AZ, 리전, OS 변경에 유연
EC2 Instance Savings Plans	특정 리전과 특정 EC2 인스턴스 패밀리에 적용. Compute Savings Plans보다 할인율이 높을 수 있음
Database Savings Plans	지원되는 AWS 데이터베이스 사용량에 적용
SageMaker AI Savings Plans	SageMaker AI 워크로드에 적용

• Compute Savings Plans는 EC2뿐 아니라 Lambda와 Fargate에도 적용 가능
• EC2 Instance Savings Plans는 특정 리전과 인스턴스 패밀리에 묶이는 대신 더 높은 할인율을 제공할 수 있음
• 사용 패턴이 안정적이면 Savings Plans를 고려
• 인스턴스 패밀리나 리전을 자주 바꿀 가능성이 있으면 Compute Savings Plans가 더 유연
• 특정 리전과 특정 EC2 패밀리를 장기간 사용할 것이 확실하면 EC2 Instance Savings Plans가 더 비용 효율적일 수 있음

Reserved Instance

• Reserved Instance는 1년 또는 3년 약정 기반 할인 옵션
• EC2, RDS, ElastiCache, OpenSearch Service, Redshift 등 일부 서비스에서 사용
• 장기간 안정적으로 실행되는 워크로드에 적합
• RDS처럼 항상 켜져 있는 데이터베이스 워크로드는 Reserved Instance를 고려할 수 있음
• 사용량이 예측 가능하고 지속적일수록 약정 기반 할인이 유리
• 반대로 사용량이 불규칙하거나 자주 변경되는 워크로드에는 On-Demand 또는 Savings Plans를 더 유연하게 검토

Spot Instance

• Spot Instance는 AWS의 남는 EC2 용량을 저렴하게 사용하는 옵션
• On-Demand 대비 큰 폭의 비용 절감 가능
• 단, AWS가 용량을 회수해야 하면 2분 예고 후 중단될 수 있음
• 중단 가능한 작업에 적합
• 배치 작업, 데이터 분석, 렌더링, 시뮬레이션, CI/CD, 테스트 워크로드에 적합
• 상태를 로컬에만 저장하면 중단 시 데이터가 유실될 수 있으므로 외부 저장소나 체크포인트 설계가 필요
• Auto Scaling Group에서 On-Demand와 Spot을 혼합하여 사용할 수 있음
• 핵심 기본 용량은 On-Demand 또는 Savings Plans로 유지하고, 추가 확장 용량을 Spot으로 구성하는 방식이 비용 효율적

S3 비용 최적화

스토리지 클래스 선택

접근 패턴	최적 클래스
자주 접근	S3 Standard
자주 접근하지 않지만 빠른 접근 필요	S3 Standard-IA
재생 가능하고 중요도가 낮은 비활성 데이터	S3 One Zone-IA
접근 패턴을 예측하기 어려움	S3 Intelligent-Tiering
아카이브지만 즉시 검색 필요	S3 Glacier Instant Retrieval
장기 보관, 수 분~수 시간 검색 허용	S3 Glacier Flexible Retrieval
거의 접근하지 않는 최장기 보관	S3 Glacier Deep Archive

• S3 Standard는 자주 접근하는 데이터에 적합
• Standard-IA는 자주 접근하지 않지만 필요 시 빠르게 검색해야 하는 데이터에 적합
• One Zone-IA는 단일 AZ에 저장되므로 AZ 장애 시 데이터 손실 위험이 있음
• 재생 가능한 데이터나 중요도가 낮은 데이터에 적합
• Intelligent-Tiering은 접근 패턴을 예측하기 어려운 데이터에 적합
• Glacier 계열은 장기 보관 비용을 줄일 수 있지만 검색 시간과 최소 보관 기간을 고려해야 함

Lifecycle 정책

• Lifecycle 정책은 객체를 시간에 따라 더 저렴한 스토리지 클래스로 자동 이동하거나 삭제하는 기능
• 예를 들어 30일 후 Standard-IA, 90일 후 Glacier Flexible Retrieval, 1년 후 Deep Archive로 이동 가능
• 오래된 로그, 백업, 접근 빈도가 낮아지는 데이터의 비용 최적화에 적합
• S3 Versioning을 사용하는 경우 이전 버전도 계속 저장되어 비용이 증가할 수 있음
• Lifecycle 정책으로 이전 버전 만료 또는 이전 버전 스토리지 클래스 전환을 함께 고려

미완료 멀티파트 업로드 비용

• S3 멀티파트 업로드가 완료되지 않고 남아 있으면 업로드된 파트에 대해 스토리지 비용이 발생할 수 있음
• Lifecycle 정책으로 미완료 멀티파트 업로드를 일정 기간 후 자동 삭제할 수 있음
• 대용량 파일 업로드가 많은 환경에서는 미완료 멀티파트 업로드 정리 규칙을 설정하는 것이 비용 절감에 도움
• 완료되지 않은 멀티파트 업로드를 중단하면 업로드된 파트가 삭제되고 해당 파트에 대한 비용이 더 이상 발생하지 않음

NAT Gateway 비용 절감

• NAT Gateway는 시간당 요금과 데이터 처리 요금이 발생
• 프라이빗 서브넷의 리소스가 S3에 접근할 때 NAT Gateway를 거치면 NAT Gateway 데이터 처리 비용이 발생할 수 있음
• S3 또는 DynamoDB 접근이 많다면 Gateway VPC Endpoint를 사용하여 NAT Gateway 비용을 줄일 수 있음
• Gateway VPC Endpoint는 S3와 DynamoDB에 사용할 수 있음
• Gateway Endpoint는 추가 요금이 없음
• Interface Endpoint는 시간당 요금과 데이터 처리 요금이 발생
• S3 접근만을 위해 NAT Gateway를 사용하고 있다면 S3 Gateway Endpoint를 우선 고려
• SQS, SNS, Secrets Manager, CloudWatch Logs 같은 서비스는 Interface Endpoint를 사용해야 함

Compute Optimizer

• Compute Optimizer는 AWS 리소스의 구성과 사용량 지표를 분석하여 최적화 권장 사항을 제공하는 서비스
• 과도하게 프로비저닝된 리소스나 부족하게 프로비저닝된 리소스를 찾는 데 도움
• 비용 절감뿐 아니라 성능 개선 권장 사항도 제공
• EC2 인스턴스, EC2 Auto Scaling 그룹, EBS 볼륨, Lambda 함수, ECS on Fargate, 일부 RDS/Aurora 리소스 등에 대한 권장 사항을 제공
• Lambda는 메모리 크기 권장 사항을 제공
• ECS on Fargate는 태스크와 컨테이너의 CPU/메모리 크기 권장 사항을 제공
• NAT Gateway 같은 일부 리소스의 유휴 상태 권장도 확인할 수 있음
• 실제 사용 패턴 기반으로 리소스 크기 조정, 인스턴스 타입 변경, 메모리 조정 등을 검토할 수 있음
• Savings Plans나 Reserved Instance를 구매하기 전, 먼저 과도한 리소스를 줄이는 것이 좋음

Cost Explorer

• Cost Explorer는 AWS 비용과 사용량을 분석하는 서비스
• 서비스별, 계정별, 리전별, 태그별 비용 추이를 확인할 수 있음
• 일별, 월별 비용 추이를 시각화할 수 있음
• 과거 사용량 기반 비용 예측을 확인할 수 있음
• Savings Plans와 Reserved Instance의 사용률과 커버리지를 분석할 수 있음
• 비용이 증가한 서비스나 계정을 파악할 때 사용
• 장기 비용 추세와 최적화 후보를 찾는 데 유용

AWS Budgets

• AWS Budgets는 예산 한도와 사용량 기준으로 알림을 설정하는 서비스
• 월별 비용, 사용량, RI/SP 사용률, RI/SP 커버리지 등에 대해 예산 설정 가능
• 예산 초과 또는 초과 예상 시 이메일, SNS, AWS Chatbot 등으로 알림 가능
• 예산 한도를 기준으로 관리해야 할 때 사용
• 비용이 일정 금액을 넘으면 알림을 받고 싶을 때 적합
• Budgets Actions를 사용하면 특정 IAM 정책 적용, SCP 적용, EC2/RDS 중지 같은 자동 조치를 구성할 수 있음
• 단, 자동 조치는 신중하게 설계해야 함

Cost Anomaly Detection

• Cost Anomaly Detection은 비정상적인 지출 패턴을 탐지하고 알림을 보내는 서비스
• 과거 사용 패턴과 비교해 갑작스러운 비용 증가를 찾는 데 적합
• AWS Budgets가 예산 한도 초과 알림이라면, Cost Anomaly Detection은 이상 지출 패턴 탐지에 초점
• 특정 서비스, 계정, 비용 카테고리 단위로 이상 비용을 감지할 수 있음
• 예상하지 못한 비용 급증을 빠르게 발견하는 데 유용

비용 할당 태그

• 비용 할당 태그는 비용을 프로젝트, 팀, 서비스, 환경별로 나누어 분석할 때 사용
• 리소스에 태그를 적용한 뒤 Cost Allocation Tags에서 활성화해야 비용 분석에 사용할 수 있음
• 사용자 정의 태그는 리소스에 적용한 뒤 비용 할당 태그 페이지에 나타나기까지 최대 24시간이 걸릴 수 있음
• 태그 키를 활성화한 뒤에도 비용 할당 태그로 반영되기까지 최대 24시간이 걸릴 수 있음
• Cost Explorer에서 태그 기준으로 비용을 필터링하거나 그룹화할 수 있음
• 태그가 모든 과거 비용에 소급 적용되는 것은 아님
• 이미 태그를 지원하지 않는 일부 오래된 리소스나 서비스는 태그 기반 비용 분류가 제한될 수 있음
• 비용 관리를 위해 Project, Owner, Environment, CostCenter 같은 표준 태그 체계를 정해두는 것이 좋음

DynamoDB 비용 최적화

• DynamoDB TTL을 사용하면 만료 데이터가 자동 삭제되어 스토리지 비용을 줄일 수 있음
• 트래픽이 예측 불가능하면 온디맨드 모드가 운영상 유리
• 트래픽이 일정하고 예측 가능하면 프로비저닝 모드가 온디맨드보다 비용 효율적일 수 있음
• 프로비저닝 모드에서는 Auto Scaling을 사용하여 읽기/쓰기 용량을 자동 조정 가능
• 장기적으로 일정한 사용량이 있으면 예약 용량을 고려할 수 있음
• 큰 객체는 DynamoDB에 직접 저장하기보다 S3에 저장하고 DynamoDB에는 S3 URL 또는 메타데이터를 저장하는 방식이 비용 효율적

Aurora / RDS 비용 최적화

• 트래픽이 불규칙한 관계형 DB 워크로드는 Aurora Serverless를 고려
• Aurora Serverless v2는 사용량에 따라 ACU 단위로 용량을 조정
• 단, 최소 ACU 설정에 따라 트래픽이 없어도 비용이 발생할 수 있음
• 상시 실행되는 RDS 인스턴스는 Reserved Instance를 고려
• 읽기 부하가 높은 경우 무조건 인스턴스를 키우기보다 Read Replica, ElastiCache, 쿼리 튜닝을 함께 고려
• 스토리지 자동 확장은 용량 부족 장애를 줄이는 데 유용하지만, 확장된 스토리지는 자동으로 줄어들지 않으므로 비용 증가에 주의
• 사용하지 않는 개발/테스트 DB는 중지하거나 삭제 고려
• RDS를 중지해도 스토리지 비용과 백업 비용은 계속 발생할 수 있음

Instance Scheduler

• Instance Scheduler는 업무 시간에만 필요한 EC2와 RDS를 자동으로 시작하고 중지하여 비용을 줄이는 솔루션
• 개발, 테스트, 교육 환경처럼 24시간 실행할 필요가 없는 리소스에 적합
• 야간이나 주말에 사용하지 않는 인스턴스를 중지하면 컴퓨팅 비용을 절감할 수 있음
• 단, 중지해도 EBS 볼륨, 스냅샷, RDS 스토리지 같은 저장 비용은 계속 발생할 수 있음

비용 절감 전략 요약

시나리오	최적 솔루션
상시 실행 구성요소	Reserved Instance 또는 Savings Plans
장기적으로 안정적인 컴퓨팅 사용량	Savings Plans
특정 EC2 패밀리 장기 사용	EC2 Instance Savings Plans
단기 또는 예측 불가 워크로드	On-Demand
중단 허용 워크로드	Spot Instance
서버리스 컴퓨팅 사용량 절감	Compute Savings Plans
오래된 S3 데이터	Lifecycle 정책으로 스토리지 클래스 전환
S3 Versioning으로 인한 이전 버전 비용 증가	Lifecycle 정책으로 이전 버전 만료
미완료 멀티파트 업로드 비용	Lifecycle 정책으로 자동 삭제
S3/DynamoDB 접근으로 인한 NAT Gateway 비용	Gateway VPC Endpoint
비용 한도 알림	AWS Budgets
이상 지출 감지	Cost Anomaly Detection
과도 프로비저닝 탐지	Compute Optimizer
비용 분석	Cost Explorer
프로젝트/팀별 비용 분리	Cost Allocation Tags
업무 시간만 실행	Instance Scheduler
DynamoDB 만료 데이터 삭제	DynamoDB TTL
트래픽 불규칙 관계형 DB	Aurora Serverless