AWS Lambda 비용 구조 완전 이해하기

개발자라면 예측 불가능한 서버 비용, 밤샘 트래픽 모니터링, 그리고 예산 초과 고지서에 진저리 난 경험 있으신가요? AWS Lambda는 단순히 서버 관리의 고통을 완전히 지워주는 마법 같은 서비스가 아닙니다. 코드를 올리면, 끝! AWS가 알아서 모든 인프라를 관리해주는 이 서버리스 혁명은 여러분에게 비용 효율성과 무한한 확장성이라는 꿈을 선사합니다.

하지만 이 꿈같은 서비스에도 '숨겨진 숫자'들이 있습니다. Lambda는 사용한 만큼만 요금을 내는 '페이-퍼-유즈(Pay-per-use)' 모델 덕분에 비용 효율적이라고 알려져 있지만, 요청 수, 실행 시간, 그리고 곳곳에 숨어 있는 간접 비용들을 제대로 이해하지 못하면 예상치 못한 청구서에 놀랄 수 있습니다.

이 글은 Lambda의 핵심 개념을 간략하게 짚어보고, 특히 복잡해 보이는 Lambda의 비용 구조를 명확하게 해부해보도록 하겠습니다. 여러분이 불필요한 지출을 줄이고 비용을 '내 손 안'에 통제하기 위해 필요한 중요한 사전 지식이 될 것입니다.

Lambda란 무엇인가?

AWS Lambda는 서버 없이 코드를 실행할 수 있게 해주는 서버리스(Serverless) 컴퓨팅 서비스입니다. 즉, 개발자가 서버를 직접 프로비저닝하거나 관리할 필요 없이 코드를 올리면, AWS가 알아서 코드를 실행하고 확장해주는 서비스입니다.

AWS Lambda는 특정 이벤트에 반응하여 코드를 실행하고, 필요한 컴퓨팅 리소스를 자동으로 관리해주는 서비스입니다. "서버리스"라는 이름 때문에 서버가 아예 없다고 오해할 수 있지만, 사실은 AWS가 모든 서버 인프라를 대신 관리해준다는 의미입니다. 개발자는 오직 코드에만 집중할 수 있게 됩니다.

서버리스(Serverless)의 의미

기존에는 웹사이트나 애플리케이션을 운영하려면 서버를 직접 설정하고, 업데이트하고, 보안 패치를 적용하는 등 복잡한 관리 작업이 필요했습니다. Lambda를 사용하면 이런 서버 관련 작업(운영 체제, 네트워크, 하드웨어 등)을 모두 AWS가 담당하게 됩니다.

또한 사용량 기반으로 과금되기 때문에 코드가 실행될 때만 요금이 발생합니다. 함수가 유휴 상태일 때는 비용이 전혀 부과되지 않습니다. 사용한 컴퓨팅 자원(요청 수, 실행 시간, 메모리 사용량)에 대해서만 정확히 비용을 지불합니다.

AWS Lambda는 어떻게 작동하나요?

Lambda는 이벤트 기반(Event-Driven)으로 작동합니다. 특정 '이벤트'가 발생했을 때만 설정된 코드를 실행하는 방식입니다.

이벤트 트리거

파일 업로드: S3 버킷에 새로운 이미지가 업로드되면 Lambda 함수가 자동으로 실행되어 이미지를 리사이징하거나 분석할 수 있습니다.

데이터 변경: DynamoDB 같은 데이터베이스에 새로운 데이터가 추가될 때 Lambda가 실행되어 알림을 보내거나 다른 작업을 시작할 수 있습니다.

API 호출: API Gateway를 통해 HTTP 요청이 들어오면 Lambda 함수가 실행되어 웹 API 요청을 처리할 수 있습니다.

예약 실행: 특정 시간(예: 매일 자정)에 Lambda 함수를 실행하여 배치 작업을 수행할 수도 있습니다.

코드 실행 및 확장

이벤트가 발생하면 Lambda는 코드를 실행할 임시 컴퓨팅 환경을 즉시 프로비저닝하고 코드를 실행합니다. 만약 동시에 수많은 이벤트가 발생하더라도, Lambda는 자동으로 여러 인스턴스를 생성하여 모든 요청을 처리할 수 있도록 확장(Scaling)됩니다.

AWS Lambda의 주요 장점

비용 효율성: 사용한 만큼만 지불하므로, 트래픽 변동이 심하거나 간헐적으로 실행되는 애플리케이션에 매우 경제적입니다.

자동 확장성: 갑작스러운 트래픽 급증에도 자동으로 인스턴스를 늘려 안정적으로 서비스를 유지할 수 있습니다. 개발자가 직접 확장 계획을 세울 필요가 없어요.

운영 편의성: 서버 관리 부담이 없어 개발자는 핵심 비즈니스 로직 개발에만 집중할 수 있습니다.

빠른 배포: 코드를 업로드하는 것만으로 바로 기능을 배포할 수 있어 개발 주기가 단축됩니다.

간단히 말해, AWS Lambda는 마치 특정 요청이 올 때만 작동하는 '지능형 자동 판매기'와 같습니다. 자판기 자체(서버)는 누가 관리하든 상관없이, 동전(요청)이 들어오면 설정된 음료(코드)를 자동으로 제공하는 방식입니다. 필요할 때만 작동하고, 사용한 만큼만 비용을 내며, 아무리 많은 사람이 동시에 이용해도 척척 대응해주는 편리하고 효율적인 서비스라고 이해하시면 됩니다.

Lambda 비용 구조 이해

Lambda 요청 수

Lambda의 과금 구조는 두 가지 주요 기준을 중심으로 이루어지는데, 그중 하나가 바로 요청 수(Request Count)입니다.

요청 수 기준 과금

Lambda는 1M(백만) 요청당 $0.20의 요금이 부과됩니다. 이는 단순히 함수 실행 요청의 횟수에 따라 발생하는 기본 비용으로, 예를 들어 하루 100만 건의 요청이 발생하면 하루 Lambda 요청 비용만 약 $0.20, 한 달(30일) 기준 약 $6의 비용이 발생합니다.

요청 수 과금의 특성

단일 Lambda 함수뿐만 아니라 계정 내 모든 Lambda 함수의 총 호출 횟수를 기준으로 집계합니다. 트리거(Event Source) 유형에 따라 요청 수가 급격히 증가할 수 있습니다. (예: S3 이벤트, DynamoDB Streams, Kinesis 등) 100만 건 단위로 과금되기 때문에, 대규모 이벤트 처리 시스템에서는 호출 최적화 전략이 필수입니다.

비용 인식의 중요성

요청 수는 작은 단위의 비용처럼 보이지만, 하루 수백만~수천만 건의 요청이 발생하면 단독 항목으로도 Lambda 전체 비용의 상당 부분을 차지할 수 있습니다. 특히, 불필요한 이벤트 트리거나 테스트/개발 환경의 오남용으로 인해 호출 수가 불필요하게 폭증하는 경우가 많으므로 주의가 필요합니다.

Lambda 요청 수 과금은 단일 요금 모델처럼 단순해 보이지만, 사용량이 누적될수록 전체 비용에 큰 영향을 미칠 수 있는 요소이므로 반드시 주기적인 모니터링과 최적화 전략이 필요합니다.

Lambda 실행 시간

Lambda의 두 번째 핵심 과금 요소는 실행 시간(Duration)입니다. Lambda 함수는 1ms 단위로 실행 시간을 측정하며, 이를 기준으로 요금이 부과됩니다. 실행 시간 과금은 메모리 크기에 따라 단가가 달라지며, 다음과 같은 원리로 계산됩니다.

실행 시간 과금 방식

함수 실행 시, 사용한 메모리 크기(최소 128MB~최대 10,240MB)와 실행 시간(ms 단위)을 곱해 “GB-초(GB-seconds)” 단위로 계산합니다. 예를 들어, 512MB 메모리를 할당받은 Lambda 함수가 1초 동안 실행되면 0.5GB-초(512MB = 0.5GB * 1초)로 계산됩니다. AWS 요금표(서울 리전 기준)에서 GB-초당 요금은 약 $0.00001667로 책정되었습니다.

계산 예시

512MB Lambda 함수 100시간 실행 → 0.5 * 3600초 = 0.5GB-초 → 비용 약 $3.0006

1,000만 건 실행 시: 0.5 * 1초 * 10,000,000 = 5,000,000 GB-초 → 약 $83.35

실행 시간 최적화 중요성

코드 비효율, 과도한 타임아웃 설정, 외부 API 대기시간, 불필요한 연산이 실행 시간을 늘려 전체 비용에 직접적으로 영향을 미치게 됩니다. 반대로, 코드 최적화와 메모리 설정 조정을 통해 실행 시간을 단축하면 비용 절감 효과가 매우 큽니다.

메모리 크기와 실행 시간의 관계

Lambda는 메모리 크기를 늘리면 CPU와 네트워크 대역폭도 함께 증가하므로, 경우에 따라 메모리 크기를 높이면 실행 시간이 줄어들어 총비용이 오히려 감소하는 현상이 발생할 수 있습니다. 이를 최적화하기 위해 AWS에서는 Lambda Power Tuning 도구 사용을 권장하고 있습니다. Lambda Power Tuning은 각 메모리 크기에 따른 실행 시간을 측정하여 최소의 요금으로 실행할 수 있는 인프라를 선택하도록 가이드를 줍니다.

실행 시간 기반 과금은 단순히 코드 실행 속도를 줄이는 문제가 아니라, 전체 비용 최적화를 위한 핵심 변수이므로, 함수별 실행 시간 모니터링 및 개선이 필수적입니다.

프로비저닝된 동시성 비용

AWS Lambda는 기본적으로 요청 발생 시마다 동적으로 인스턴스를 생성(Cold Start)해 함수 실행을 처리합니다. 하지만, 대기 시간 없이 빠른 응답을 보장해야 하는 서비스(예: API Gateway 연계 서비스)에서는 프로비저닝된 동시성(Provisioned Concurrency) 기능을 사용해 미리 실행 가능한 인스턴스를 예약해둘 수 있습니다.

프로비저닝된 동시성을 활성화하면 Cold Start 문제는 해결되지만, 이에 따라 추가적인 요금이 발생합니다.

요금 구조는 다음과 같습니다.

프로비저닝된 동시성 시간 요금

프로비저닝된 동시성 개수 * 유지 시간(초) * GB-초 단가로 계산합니다. 요금 단가는 Lambda의 메모리 크기에 따라 달라지며, 서울 리전 기준으로 x86의 경우 $0.0000051254/GB-초입니다.

실행 요청 요금

프로비저닝된 동시성에서도 실행 요청별 요금(요청 수, 실행 시간)은 별도로 부과합니다.

계산 예시

512MB Lambda를 프로비저닝 10개 설정 → 512MB = 0.5GB

0.5GB * 10개 * 1시간(3600초) = 18,000GB-초

18,000 * 0.0000041667 = 약 $0.075/hour → 한 달 24x7 운영 시 약 $54 추가 비용

비용 최적화 포인트

프로비저닝된 동시성은 반드시 필요한 엔드포인트(API Gateway, ALB)에서만 최소화해 적용

트래픽 패턴에 따라 EventBridge Scheduler 등으로 프로비저닝 예약 시간대를 설정하여 사용

프로비저닝 필요량을 주기적으로 점검 → 필요 없는 시간대에는 동시성 할당 해제

결론적으로, 프로비저닝된 동시성은 빠른 응답을 위한 편리한 옵션이지만, 잘못 사용하면 예상치 못한 숨은 비용의 주범이 될 수 있으므로, 항상 필요성과 트래픽 패턴을 함께 고려해 신중하게 설정해야 합니다.

Lambda 숨겨진 비용

VPC를 구성하여 관리하는 리소스에 Lambda가 접근해야 할 경우가 있습니다. 기본적으로 Lambda는 VPC 외부(=AWS 관리 네트워크) 에서 실행되며 이 경우 ENI를 생성하지 않습니다. 다만 Lambda 함수가 RDS, ElastiCache 등 VPC 내부 리소스에 접근하려면 VPC 구성이 필요하며, 이때 AWS는 Lambda가 사용하는 서브넷 및 보안 그룹을 기반으로 ENI를 자동 생성합니다.

Lambda가 외부 API 호출에 의해 인터넷에 나갈 경우 ENI 생성이 되었다면 VPC 내부에서 NAT Gateway를 경유하여 나가게 됩니다. 그리고 이 때 아웃바운드 데이터 전송 요금이 발생합니다. ENI 자체는 별도 과금 항목으로 요금이 부과되지는 않지만, VPC 연결로 인한 간접 비용이 발생하게 됩니다.

최적화 전략

Lambda가 반드시 VPC 내부 리소스(DB, Redis)에 접근해야 하는 경우만 VPC 연결을 유지합니다. 예로 퍼블릭 API 호출만 하는 Lambda는 VPC 연결을 제거합니다.

CloudWatch Logs

Lambda 함수는 실행 중에 발생하는 로그(예: console.log() 출력)를 자동으로 CloudWatch Logs로 전송합니다. 이때 로그 저장과 처리에는 별도의 요금이 부과되며, Lambda 함수의 사용량과 함께 CloudWatch Logs 비용이 예상보다 크게 증가하는 경우가 자주 발생합니다. 이 때문에 Lambda와 CloudWatch Logs의 연계 과금 구조를 이해하는 것은 Lambda 비용 최적화에서 매우 중요합니다.

Logs 과금 구조

CloudWatch Logs의 주요 과금 항목은 다음과 같습니다:

로그 수집(데이터 수집 요금): Lambda에서 출력된 로그(예: console.log)는 CloudWatch Logs로 전송되며, GB 단위로 과금 (서울 리전 기준 $0.76/GB)

로그 저장(데이터 저장 요금): 저장된 로그 데이터의 크기에 따라 월 단위 요금 부과 (서울 리전 기준 $0.033/GB-월)

Logs Insights 쿼리 요금: 로그 분석 시 GB 단위로 별도 과금 (서울 리전 기준 $0.005/GB 스캔)

비용 폭증 포인트

Lambda 함수의 로그 출력 빈도가 높을수록 CloudWatch Logs의 데이터 수집/저장 비용이 비례해 증가

디버깅 단계에서 console.log()를 과도하게 사용하거나, 비즈니스 로직 내 불필요한 로그 출력이 많을 경우 예상치 못한 로그 요금이 발생

로그 Retention 설정을 하지 않으면 기본 30일 무제한 저장 → 오래된 로그 데이터가 계속 쌓여 저장 요금이 누적

최적화 포인트

Lambda 함수의 로그 출력 최소화 (console.log() 최소 사용, DEBUG/INFO 레벨 관리)

CloudWatch Logs Retention 기간 설정 (예: 7일, 14일, 30일)

필요 없는 로그 그룹 삭제 및 로그 수집 비활성화 고려

Logs Insights 쿼리 사용량 주기적 점검

결론적으로, Lambda 사용 비용의 일부는 CloudWatch Logs에서 발생하며, 특히 대량의 로그 출력이 있는 Lambda는 Logs 비용이 전체 Lambda 비용의 상당 부분을 차지할 수 있습니다. 따라서 Lambda와 Logs의 연계 과금 구조를 명확히 이해하고, 불필요한 로그 출력과 저장을 최소화하는 것이 비용 최적화의 핵심입니다.

Q. Lambda에서 프로비저닝된 동시성이 필요한 이유는 무엇인가

모든 Lambda에 필수는 아니며, 특정 상황에서만 유의미한 성능 향상을 제공합니다. 콜드 스타트가 문제인지 확인이 필요합니다. 기본 Lambda는 콜드 스타트 지연(수백 ms ~ 수 초)이 발생할 수 있습니다. 만약 애플리케이션이 실시간성에 민감하다면 이 지연은 사용자 체감 속도 저하나 오류로 이어질 수 있습니다.

콜드 스타트는 반복적으로 발생할 수 있습니다. Lambda 함수는 일정 시간 동안 호출되지 않거나, 새로운 인스턴스가 필요할 경우 다시 콜드 상태로 돌아게 됩니다. 짧게는 수 분에서 길게는 수십 분 동안 유휴 상태를 유지하다가 AWS에서 리소스를 회수하는 방식입니다.

또한 동시에 여러 사용자가 호출하면, 기존 인스턴스만으로는 부족해 추가 인스턴스가 생성됩니다. 이 때에도 추가된 인스턴스는 처음에 콜드 상태입니다. 프로비저닝된 동시성은 이 콜드 스타트가 발생하지 않도록 합니다. 아래 같은 상황이라면 도입에 대한 검토가 필요합니다.

Q.프로비저닝된 동시성은 기존의 lambda 와 시간, 요청에 따른 비용이 별도로 부과되는가

네. 맞습니다. 정확하게는 프로비저닝된 lambda는 그 수만큼 인스턴스를 유지하는 비용이 발생합니다. 24시간 계속 준비 상태로 유지하기 위한 비용입니다. 자세하게는 아래와 같습니다.

그러나 실행에 대한 비용은 별도로 부과되진 않습니다. 일반 lambda와 마찬가지로 실행 시간에 대한 요금과 요청 수에 대한 요금은 기존대로 과금됩니다. 만약 5개의 요청을 동시에 처리해야 할 때 2개의 프로비저닝된 인스턴스가 있다면 2개는 프로비저닝된 인스턴스에서 처리하고 나머지 3개는 콜드스타트가 이루어진 lambda에서 추가로 발생하게 됩니다.

Lambda Response Streaming

AWS Lambda Response Streaming은 기존의 Lambda 응답 방식과 달리, 함수 실행이 완료되기 전에도 클라이언트에 데이터를 실시간으로 전송할 수 있는 기능입니다. 이를 통해 대용량 데이터를 처리하는 애플리케이션의 성능을 크게 향상시킬 수 있지만, 이와 관련된 비용 및 기술적 특성을 명확히 이해해야 합니다.

기존 Lambda와 API Gateway 통합 방식은 함수 실행이 완전히 끝난 후, 단일 JSON 응답을 반환하는 정적(static) 응답 모델을 따릅니다. 반면, Lambda Response Streaming은 API Gateway HTTP API(v2)와 함께 사용될 때, 함수가 실행되는 동안 응답 본문(response body)을 스트림(stream) 형태로 클라이언트에게 즉시 전송하는 방식입니다. 이는 대용량 파일 다운로드, 실시간 로그 스트리밍, 대규모 데이터셋 생성 등 함수가 한 번에 처리하기 어려운 작업에 특히 유용합니다.

기존 Lambda는 API Gateway와 통합 시, 함수가 끝나고 나서 정적인 JSON 응답을 반환합니다. 스트리밍은 Lambda와 API Gateway HTTP API (v2) 연동 시, 응답 Body를 stream 형태로 쓸 수 있습니다. 즉, Lambda Response Streaming은 “실행 도중 바로 응답할 수 있다”는 점에서 기존 방식과 확연히 다릅니다.

스트리밍은 함수 실행 시간을 단축하지는 않지만, 클라이언트에게는 응답 지연 시간(latency)을 줄여주는 효과가 있습니다. 예를 들어, 10초가 소요되는 함수가 스트리밍을 통해 2초 만에 첫 데이터를 클라이언트에 보내기 시작하면 사용자는 훨씬 빠르게 응답을 받는다고 느낍니다.

Lambda Response Streaming은 실행 시간과 요청 수에 대한 기본적인 Lambda 과금 모델을 따르면서도, 추가적인 비용 발생 가능성이 있습니다. 기본적으로 100만 요청당 $0.20의 기본 요청 요금은 동일하게 부과됩니다. 스트리밍 여부와 관계없이 함수 호출 횟수에 따라 계산됩니다.

또한 함수가 최종적으로 완료될 때까지의 총 실행 시간(duration)에 따라 요금이 부과됩니다. 즉, 기존 방식과 스트리밍 방식 모두 동일한 양의 작업을 처리한다면 총 실행 시간 요금은 동일합니다.

차이점은 Lambda Response Streaming은 API Gateway HTTP API(v2)를 사용합니다. HTTP API는 REST API보다 저렴하며, 데이터 전송에 대한 요금이 별도로 부과됩니다. 기존 Lambda가 6mb의 제한이 있는 반면 Response Streaming은 6mb보다 큰 대용량 데이터를 스트리밍으로 전송할수 있습니다. 즉 관리적인 측면에서 기존의 Lambda보다 더 비싸질 수 있는 가능성이 있습니다.

Lambda Response Streaming은 모든 API에 필요한 기능이 아닙니다. 대부분의 일반 API는 기존의 정적 응답 모델로 충분하며, 불필요하게 스트리밍을 도입하면 설정 복잡성만 커질 수 있습니다.

이 기능은 주로 응답 페이로드 크기가 6MB를 초과하거나, 응답이 즉시 필요한 대용량 데이터 처리 워크로드에 초점을 맞춰야 합니다. 스트리밍을 사용하려면 API Gateway와 클라이언트 측 모두에서 스트리밍 응답을 처리할 수 있도록 추가 설정이 필요합니다. 이는 개발 및 운영의 복잡성을 높일 수 있습니다.

Q. 메모리 선택하는 방법

콘솔에서 생성된 lambda 함수를 선택하고 구성 탭을 클릭합니다. 해당 항목에는 현재 선택된 메모리가 표시되고, 편집 버튼을 눌러서 아래와 같은 화면에서 메모리를 선택할 수 있습니다. 메모리는 디폴트로 128MB이며 메모리를 키우는 이유는 메모리에 따라 비례해서 CPU 및 기타 리소스가 자동 할당되는 구조이기 때문입니다. Lambda가 실행 시간에 따라서도 과금이 되다보니 메모리를 늘리면 실행시간을 더 줄일 수 있게 됩니다.

Q. 비용 측면에서 무조건 그래비톤으로 하는게 좋은게 맞는가?

Lambda 함수에서 사용하는 CPU 아키텍처는 사용자가 선택 가능하며, 선택에 따라 성능과 비용에 영향을 줍니다. 특히 Graviton2(Arm 아키텍처)는 저렴하고 빠른 성능을 제공하는 대안으로 주목받고 있지만, 항상 정답은 아닙니다.

Lambda는 기본적으로 x86 아키텍처로 설정되어 있습니다. Arm(Graviton2) 아키텍처를 사용하려면 lambda 생성 시에 다음 중 하나를 통해 명시적으로 설정해야 합니다.

Lambda에서 Graviton2(arm64) 를 사용하면, 해당 아키텍처에 맞는 라이브러리와 패키지가 필요합니다. Python, Node.js 같은 런타임은 대부분 호환됩니다. 하지만 native binary 또는 Docker 이미지로 빌드한 경우, Arm64로 다시 빌드해야 정상 동작할 수도 있습니다. 그리고 .so, .dll, .node, .a 같은 파일은 아키텍처 종속성이 있으니 확인이 필요합니다.

결론

결국 Lambda는 '코드'만 신경 쓰고 싶은 개발자를 위한 궁극의 솔루션입니다. 마치 특정 버튼을 누를 때만 작동하고, 필요에 따라 알아서 척척 확장되는 '스마트한 자동화 기계'와 같습니다.

하지만 이 모든 혁신과 편리함 뒤에는 정교한 비용 최적화라는 중요한 과제가 숨어 있습니다. Lambda는 사용한 만큼만 지불하는 매력적인 모델을 제공하지만, 이는 동시에 요청 수, 실행 시간, 그리고 숨겨진 간접 비용에 대한 철저한 이해를 요구합니다. 프로비저닝된 동시성과 같은 성능 최적화 기능은 콜드 스타트를 해결해주지만 잘못 사용하면 숨은 비용의 주범이 될 수 있고, CloudWatch Logs는 필수적이지만 과도한 로그 출력으로 예상치 못한 지출을 유발할 수 있습니다. 심지어 CPU 아키텍처(Graviton2) 선택 하나도 비용과 성능에 영향을 미치게 됩니다.

따라서 Lambda를 성공적으로 활용하려면, 단순히 코드를 잘 짜는 것을 넘어, 여러분의 코드가 AWS의 과금 구조와 어떻게 상호작용하는지를 깊이 이해해야 합니다. 각 함수의 요청 수, 실행 시간, 메모리 사용량, 그리고 통합 서비스와의 연결을 주기적으로 모니터링하고, Graviton2 전환, 효율적인 캐싱, 불필요한 로그 최소화와 같은 전략들을 적극적으로 적용해야 합니다.

이 모든 노력이 합쳐질 때 비로소 Lambda는 여러분의 서비스를 혁신적으로 확장하는 동시에, 비용 효율성까지 완벽하게 잡아내는 진정한 '게임 체인저'가 될 것입니다. Lambda를 '비용 최적화의 전장'으로 인지하고 현명하게 관리하는 개발자만이 서버리스 시대의 진정한 승자가 될 수 있습니다.