AWS 청구서의 80%를 차지하는 EC2·RDS·S3·Lambda 4개 영역을 체계적으로 줄이는 방법. Savings Plans vs Reserved Instance 선택 기준, gp2→gp3 전환, VPC Gateway Endpoint로 NAT 비용 제거, CloudFront Egress 절감, Lambda Power Tuning까지 실전 전략을 정리했다.
한 줄 요약: AWS 청구서가 예상보다 2~5배 높게 나왔다면, EC2·RDS·S3·Lambda 네 영역을 순서대로 최적화하는 것만으로 50% 이상 절감할 수 있다.
※ 기준: 2026년 4월 AWS 공개 요금 기준(us-east-1, ap-northeast-2). 리전별 차이 있음.
AWS 청구서에는 200개가 넘는 과금 항목이 있지만 스타트업 비용의 80%는 실제로 4개 영역에서 나온다.
| 항목 | 평균 비중 | 최적화 난이도 |
|---|---|---|
| EC2 (컴퓨팅) | 35~45% | 낮음 — Savings Plans만으로 30% 절감 |
| RDS (데이터베이스) | 20~30% | 중간 — Reserved Instance + 스토리지 최적화 |
| 데이터 전송 (Egress) | 10~25% | 높음 — 아키텍처 변경 필요 |
| S3 (스토리지) | 5~15% | 낮음 — 스토리지 클래스 자동 전환 |
최적화 첫 단계는 Cost Explorer에서 지난 3~6개월 비용을 서비스별로 내려받는 것이다. 숫자를 보기 전까지는 어디서 시작해야 할지 알 수 없다.
EC2 구매 옵션은 3가지다. 잘못 선택하면 On-Demand 대비 비용 차이가 최대 90%까지 벌어진다.
2026년 기준 권장 전략은 베이스라인 부하에 Compute Savings Plans(1년, no-upfront) + 배치·CI는 Spot + 피크 대응은 On-Demand 조합이다.
EC2 인스턴스 CPU 사용률 확인 (AWS CLI)# 인스턴스별 지난 30일 평균 CPU 사용률 조회 aws cloudwatch get-metric-statistics \ --namespace AWS/EC2 \ --metric-name CPUUtilization \ --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \ --start-time 2026-03-17T00:00:00Z \ --end-time 2026-04-17T00:00:00Z \ --period 86400 \ --statistics Average \ --output table # 활성 Savings Plans 조회 aws savingsplans describe-savings-plans \ --filters name=state,values=active \ --query 'savingsPlans[].{ID:savingsPlanId,Type:savingsPlanType,Commitment:commitment}' \ --output table
Auto Scaling 그룹에서 On-Demand와 Spot을 혼합하는 Mixed Instances Policy를 활용하면 프로덕션 웹 서버에도 Spot을 안전하게 적용할 수 있다. On-Demand 20% + Spot 80% 비율로 구성하면 Spot 인터럽션 시 On-Demand로 자동 전환되면서 비용은 On-Demand 단일 구성 대비 55~65% 절감된다. AWS Terraform 프로바이더에서 mixed_instances_policy 블록으로 선언할 수 있다.
RDS는 인스턴스 비용 외에 스토리지, I/O, 백업 스토리지, 데이터 전송이 각각 별도 과금된다. 인스턴스 비용만 보면 전체 RDS 비용의 절반도 안 잡힌다.
| 최적화 항목 | 방법 | 절감 수준 |
|---|---|---|
| 인스턴스 과금 | 1년 Reserved Instance | 40~43% |
| gp2 스토리지 | gp3로 전환 (성능 동일) | 20% 절감 |
| 개발환경 Multi-AZ | Single-AZ로 전환 | 50% 절감 |
| 백업 보관 기간 | 35일 → 7일 단축 | 백업비 80% 절감 |
| 개발·스테이징 DB | 야간·주말 자동 정지 | 월 비용 60% 절감 |
gp2 → gp3 스토리지 전환 (무중단)# 현재 스토리지 타입 확인 aws rds describe-db-instances \ --query 'DBInstances[*].{ID:DBInstanceIdentifier,Storage:StorageType,SizeGB:AllocatedStorage}' \ --output table # gp3로 전환 (다운타임 없음, I/O 성능 기본 3,000 IOPS / 125 MB/s) aws rds modify-db-instance \ --db-instance-identifier my-prod-db \ --storage-type gp3 \ --iops 3000 \ --storage-throughput 125 \ --apply-immediately # 개발환경 RDS 야간 자동 정지 (EventBridge + Lambda 대안: AWS Instance Scheduler) aws rds stop-db-instance \ --db-instance-identifier my-dev-db
Aurora Serverless v2는 간헐적 트래픽 환경에서 유리하다. ACU(Aurora Capacity Unit) 단위로 0.5~128 ACU 사이에서 자동 스케일링되며, 최솟값을 0.5 ACU로 설정하면 미사용 시간에 비용이 거의 발생하지 않는다. 단, 콜드 스타트 latency가 1~3초 발생할 수 있어 항상 트래픽이 있는 프로덕션보다 내부 툴·스테이징 환경에 적합하다.
개발·스테이징 RDS 인스턴스는 EventBridge + Lambda 또는 AWS Instance Scheduler로 야간·주말 자동 정지를 설정하면 해당 인스턴스 월 비용의 60% 이상을 절감할 수 있다.
데이터 전송(Egress) 비용은 스타트업에서 가장 자주 예상을 초과하는 항목이다. AWS에서 인터넷으로 나가는 트래픽은 GB당 $0.09(첫 10TB/월)가 부과된다.
Egress 비용이 급증하는 패턴 3가지:
VPC S3 Gateway Endpoint 생성 — NAT 비용 제거 (Terraform)# S3 Gateway Endpoint — 동일 리전 S3 트래픽이 NAT를 우회한다 resource "aws_vpc_endpoint" "s3" { vpc_id = aws_vpc.main.id service_name = "com.amazonaws.${var.region}.s3" vpc_endpoint_type = "Gateway" route_table_ids = [aws_route_table.private.id] tags = { Name = "s3-gateway-endpoint" } } # DynamoDB도 Gateway Endpoint 지원 — 동일하게 적용 resource "aws_vpc_endpoint" "dynamodb" { vpc_id = aws_vpc.main.id service_name = "com.amazonaws.${var.region}.dynamodb" vpc_endpoint_type = "Gateway" route_table_ids = [aws_route_table.private.id] }
S3 스토리지 클래스 최적화는 Intelligent-Tiering을 라이프사이클 정책으로 한 번만 설정하면 이후 자동 관리된다. 30일 이상 미접근 객체는 IA(Infrequent Access) 티어로, 90일 이상은 Glacier Instant Retrieval로 이동한다. 단, 128KB 미만 소형 파일이 매우 많다면 Intelligent-Tiering 관리 비용($0.0025/1,000 객체)이 오히려 더 나올 수 있어 파일 크기 분포를 먼저 확인해야 한다.
Lambda 요금은 GB-초 단위다. 메모리를 128MB에서 1024MB로 높여도 실행 시간이 그 이상 줄면 총 비용이 오히려 내려간다. AWS Lambda Power Tuning 도구를 쓰면 실제 함수로 다양한 메모리 크기를 테스트해 최적값을 찾아준다.
| 메모리 | 실행 시간 | GB-초 | 비용(100만 호출) |
|---|---|---|---|
| 128 MB | 800 ms | 0.100 | $1.67 |
| 512 MB | 200 ms | 0.100 | $1.67 |
| 1024 MB | 80 ms | 0.082 | $1.37 (최적) |
Lambda Power Tuning 실행 (Step Functions 기반)# AWS Lambda Power Tuning은 SAR에서 1클릭 배포 가능 # https://serverlessrepo.aws.amazon.com/applications/arn:aws:serverlessrepo:us-east-1:451282441545:applications~aws-lambda-power-tuning # 최적 메모리 탐색 실행 aws stepfunctions start-execution \ --state-machine-arn arn:aws:states:ap-northeast-2:ACCOUNT_ID:stateMachine:powerTuningStateMachine \ --input '{ "lambdaARN": "arn:aws:lambda:ap-northeast-2:ACCOUNT_ID:function:my-function", "powerValues": [128, 256, 512, 1024, 1536, 3008], "num": 10, "parallelInvocation": true, "strategy": "cost" }' # 결과 확인 후 최적 메모리로 함수 업데이트 aws lambda update-function-configuration \ --function-name my-function \ --memory-size 1024
Lambda에서 자주 놓치는 비용 항목이 하나 더 있다. Provisioned Concurrency는 콜드 스타트를 없애주지만 대기 시간에도 비용이 발생한다. 실제로 콜드 스타트 문제가 있는지 먼저 측정하고, 있다면 Provisioned Concurrency 대신 SnapStart(Java), 또는 함수 최적화(패키지 크기 축소, 레이어 분리)를 먼저 시도하는 것이 비용 효율적이다.
비용 최적화보다 더 중요한 것은 이상 징후를 즉시 알아채는 것이다. 아래 3가지 알림은 무료로 설정할 수 있으며 세팅에 10분이 걸리지 않는다.
이 사례는 MAU 10만 명 규모 B2B SaaS 스타트업이 6주 동안 수행한 최적화 결과다. 수치는 익명 처리했다.
최적화 전 구성
6주 동안 적용한 변경사항
결과: 월 $8,200 → $3,600 (56% 절감). 엔지니어 2명이 총 6주, 실제 작업 시간은 80시간 미만이었다.
