AWS Lambda는 서버 관리가 필요 없는 ‘서버리스’ 구조로 많은 기업과 개발자들에게 각광받고 있습니다. 사용한 만큼만 과금되는 유연한 요금 체계 덕분에, 초기에는 비용 효율적인 대안처럼 보이기도 합니다. 하지만 하루 1000건 API호출에서는 Lambda의 경우 월 0~2달러 수준이며 EC2의 경우 최소 인스턴스 24시간 실행 비용이 약 8~15달러로 알려져 있습니다. 그럼 Lambda가 무조건 유리한거 아니냐 하실 수 있지만, 하루 100만 건의 이미지 처리의 경우에는 Lambda는 비용이 급증하여 수십~수백달러까지도 가능하고 EC2의 경우 고성능 인스턴스에 워커 구조가 더 경제적으로 느껴집니다. 이렇듯 Lambda 전환 전 고려해야 할 비용 항목들을 아래에서 한번 체크해보시는 것을 추천드립니다.
Lambda 과금 구조의 핵심 이해
- 호출 1백만 건당 $0.20 (무료 100만 건 제공)
- 실행 시간 기준 과금 (ms 단위 × 메모리 × 호출 횟수)
예: 512MB로 설정된 함수가 2초 동안 100만 번 실행되면 약 $17.01 발생
프로비저닝된 동시성(Provisioned Concurrency)
Cold Start를 줄이기 위해 미리 인스턴스를 유지하는 기능으로, 시간 단위로 비용 발생
Lambda 외 트리거 리소스 과금
| 연동 서비스 | 주요 과금 기준 |
|---|---|
| API Gateway | 요청 수, 데이터 전송량 |
| S3 | 이벤트 호출 수, 저장량 |
| DynamoDB | 읽기/쓰기 요청 수 |
| CloudWatch Logs | 로그 저장량 |
| EventBridge | 이벤트 수 |
비용이 급증하는 경우들
1. 과도한 함수 호출
여러 함수를 직렬로 호출하면 총 실행 시간 × 호출 수가 급증하여 비용이 증가합니다.
예: REST API 요청 한 건에 대해 인증 → 로깅 → DB 연결 → 후속 처리 등으로 다수의 Lambda 함수가 연속 실행되는 구조는 비용 증가로 직결됩니다.
2. 비효율적인 메모리 설정
실제 사용량보다 메모리를 과도하게 높이면 낭비되고, 너무 낮으면 실행 시간이 길어져 오히려 손해입니다.
메모리 설정은 실행 시간과 비용의 균형을 맞추는 중요한 요소입니다.
3. 로그 저장 비용 간과
Lambda는 기본적으로 CloudWatch Logs를 통해 로그를 남기는데, 초당 수천 건의 요청 + verbose 로그는 CloudWatch 로그 비용이 급증할 수 있습니다.
불필요한 디버그 로그 또는 `console.log()` 남발은 비용 상승의 주요 원인입니다.
실전 비용 최적화 전략
1. 메모리-속도 최적 지점 찾기
AWS Lambda는 메모리를 늘리면 CPU 성능도 향상되므로 실행 시간이 줄어들 수 있습니다. 이는 오히려 총 비용을 절감할 수 있습니다.
예:
- 512MB, 실행 시간 2초 → $17.01
- 1024MB, 실행 시간 1초 → $13.39
CloudWatch Logs 또는 Lambda Power Tuning 도구를 통해 최적 메모리/시간 조합을 찾아야 합니다.
2. 비동기 처리 전환
실시간 처리가 아닌 작업(예: 이미지 처리, 이메일 발송 등)은 SQS, SNS, EventBridge를 통해 비동기 처리로 전환하면 실시간 호출 수를 줄여 비용을 줄일 수 있습니다.
비동기는 병렬성과 확장성도 함께 개선해 줍니다.
3. Edge 환경에서는 Lambda@Edge 주의
CloudFront + Lambda@Edge 구조는 글로벌 호출 시 편리하지만, 호출 비용이 일반 Lambda보다 빠르게 증가합니다.
대안으로는 CloudFront Functions 또는 정적 캐시 구조를 검토해보는 것이 좋습니다.
4. 로그 정책 정비
불필요한 로그 남발을 줄이고, 로그 수명 주기를 설정하여 저장 비용을 줄일 수 있습니다.
예를 들면, dev 환경은 debug 로그, prod는 error/warning만 출력하도록 제어합니다.
저렴해보이지만 무조건 그런 건 아닌 Lambda
- Lambda는 단일 호출은 저렴하지만, 호출 수 × 실행 시간 × 외부 리소스에 따라 누적 과금이 큽니다.
- CloudWatch Logs, API Gateway, S3 등과의 연동 과금도 무시할 수 없습니다.
- 도입 전 반드시 요금 시뮬레이션 및 구조 설계가 필요합니다.
- 비용 절감에는 부분 도입 + 최적화 + 비동기화 전략이 핵심입니다.
서버리스 구조는 잘 사용하면 막대한 효율과 자동화를 제공하지만, 잘못 설계하면 오히려 EC2보다 비쌀 수 있습니다.
Lambda로 무작정 전환하기보다는 구조와 사용량을 먼저 분석해야 합니다. 그럼 EC2가 무조건 더 저렴한 거 아니야? 번거롭게 왜 그렇게 생각해? 라고 하기엔 또 트래픽이 적거나 관리 리소스가 부족할 경우에는 Lambda가 훨씬 유리할 수 있기에 혼합해서 사용하는 것이 가장 현실적입니다. 핵심 API나 무거운 백엔드는 EC2, 이벤트성 처리나 알림은 Lambda로 구성하는 하이브리드 구조를 추천드립니다.