고정비 폭탄 피하는 서버리스 비용 절감 가이드: Functions와 DB 설계를 한 방에!

서버리스 비용 절감의 핵심은 “서버를 없애서 싸진다”가 아닙니다. 유휴 시간(Idle)에 돈이 새는 구조를 끊어내는 것입니다. 그런데 여기서 많은 팀이 한 번 삐끗합니다.

Functions(서버리스 컴퓨트)만 서버리스로 바꾸고,
DB는 여전히 “항상 켜진(Always-on)” 관리형 DB를 두면…
고정비는 그대로라서 “생각보다 안 싸집니다.”

그래서 오늘은 Functions + Managed DB(가능하면 서버리스 DB/오토스케일/오토일시정지) 조합으로 고정비를 줄이는 설계를, “바로 써먹을 수 있는 예시”로 정리해보겠습니다.

---

1) 먼저 숫자 감부터: Functions 과금 구조(3대 클라우드 공통)

서버리스 컴퓨트 과금은 크게 아래 두 축입니다.

• 요청 수(Invoke/Execution/Request)
• 실행 시간 × 리소스(메모리/CPU) = GB-s 또는 vCPU-s, GiB-s

AWS Lambda

Lambda는 요청 수 + 실행 시간(GB-s) 기준이고, 무료 티어로 월 100만 요청 + 400,000 GB-s가 포함됩니다. (Amazon Web Services, Inc.) 가격 예시로는 컴퓨트 $0.0000166667/GB-s, 요청 $0.20/100만 요청 같은 계산 예시가 공식 페이지에 제시돼 있습니다. (Amazon Web Services, Inc.)

Azure Functions

Azure Functions의 Consumption(소비) 플랜은 초 단위 리소스 소비 + 실행 횟수로 과금되고, 무료 그랜트로 월 100만 실행 + 400,000 GB-s가 포함됩니다. (Microsoft Azure)
또한 Microsoft Learn에서는 “메모리(GB) × 실행 시간(초) = GB-s”로 계산한다고 명확히 안내합니다. (Microsoft Learn)

Google Cloud Run(서비스/잡)

Cloud Run은 vCPU-seconds + GiB-seconds + Requests(요청 기반 과금의 경우)로 보는 게 기본입니다. 무료 티어로 예를 들어 요청 200만/월 + CPU/RAM 무료 구간이 안내돼 있습니다. (Google Cloud)

즉, “코드가 잠깐만 실행되고, 평소엔 0에 가깝다”면 서버리스는 강합니다.

---

2) 그런데 왜 DB에서 돈이 새나? (서버리스 절감의 현실)

서버리스로 바꿨는데 청구서가 안 줄어드는 1등 원인은 이겁니다.

• Function 비용은 줄었는데
• DB 비용이 ‘항상 켜짐’으로 남아 고정비가 된다

그래서 DB도 워크로드 패턴에 맞게 선택해야 합니다.

---

3) Managed DB 선택 매트릭스: “고정비를 줄일 수 있는가?”가 기준

트래픽 패턴	추천 DB 타입	대표 예시	왜 비용에 유리한가
스파이크/간헐(평소 0에 가깝고 가끔 폭주)	요청 기반(서버리스/온디맨드) NoSQL	DynamoDB On-Demand (Amazon Web Services, Inc.) / Firestore (Google Cloud) / Cosmos DB Serverless(개념) (Microsoft Azure)	유휴 시간 고정비 최소화(“쓴 만큼”)
간헐적이지만 트랜잭션/조인이 필요	서버리스/오토일시정지 가능한 RDB	Aurora Serverless(ACU, 유휴 시 중단 언급) (Amazon Web Services, Inc.) / Azure SQL Serverless(자동 일시정지) (Microsoft Learn)	DB 고정비를 “스토리지 비용 수준”까지 내릴 여지
24/7 꾸준(항상 트래픽 있음)	프로비저닝 + 예약/세이빙 플랜	(각 클라우드 예약 옵션)	서버리스는 단가가 더 비싸질 수 있음(특히 RDB) (Microsoft Learn)

---

4) 설계 예시 1: “CRUD API(회원/예약/문의)” — Functions + 요청 기반 NoSQL

가장 돈이 잘 줄어드는 대표 패턴입니다.
웹/앱 API를 함수로 만들고, DB는 ‘요청 기반 과금’으로 고정비를 없애는 방식이에요.

아키텍처(개념)

Client → API Endpoint → Function(검증/비즈로직) → NoSQL(DB)
                         ↘ (비동기) Queue/Topic → Function(후처리)

AWS 조합 예시(비용 절감형)

• API → Lambda
• DB → DynamoDB On-Demand(요청 기반)
• 포인트: DynamoDB 온디맨드는 “pay-per-request + 자동 스케일”을 ‘서버리스 옵션’으로 설명합니다. (Amazon Web Services, Inc.)

비용 절감 레버

• “리스트 전체 조회(Scan)” 같은 쿼리는 요청/읽기 비용을 급격히 올릴 수 있으니
  파티션 키 설계 + 필요한 인덱스만으로 조회를 ‘좁게’ 만드세요. (이건 돈뿐 아니라 성능도 같이 잡습니다.)
• TTL(만료) 데이터를 적극 활용(세션/임시토큰/단기 로그 등)

Azure 조합 예시(비용 절감형)

• API → Azure Functions
• DB → Cosmos DB Serverless(요청 기반, 저트래픽/간헐 트래픽에 적합하다고 설명) (Microsoft Azure)

비용 절감 레버

• Cosmos는 “작은 앱 + 지속 트래픽이 없는 경우에 유리”라는 포지셔닝이 명확합니다. (Microsoft Azure)
• 다만 데이터가 여러 리전에 복제되면 “스토리지 비용도 N배”로 늘 수 있으니(복제 리전 수) 설계 단계에서 선을 정하세요. (Microsoft Azure)

GCP 조합 예시(완전 서버리스 느낌)

• API → Cloud Run functions(Cloud Functions 2nd gen이 Cloud Run functions로 전환됐다는 안내가 있음) (Google Cloud Documentation)
• DB → Firestore(문서 읽기/쓰기/삭제 기준 과금 + 무료 티어 안내) (Google Cloud)

비용 절감 레버

• Firestore는 “쿼리 = 읽는 문서 수”가 비용이 될 수 있습니다. 무료 티어/단가 표도 공식에 명시돼 있으니 쿼리 패턴을 먼저 잡고 가는 게 좋습니다. (Google Cloud)

---

5) 설계 예시 2: “하루 1~2번 도는 배치/정산” — Scheduler + Function/Job + Serverless RDB

이 패턴은 특히 “개발/테스트/소규모 운영”에서 돈이 크게 줄어듭니다.

아키텍처(개념)

Scheduler → Function/Job(배치 실행) → RDB(필요 시) → 결과 저장(스토리지/리포트)

AWS 예시: Lambda + Aurora Serverless

Aurora Serverless는 공식적으로

• 온디맨드 오토스케일
• 유휴 기간에 “shuts down during periods of inactivity”
• ACU(용량 단위) 초 단위 과금
  으로 설명됩니다. (Amazon Web Services, Inc.)

비용 절감 포인트

• “정산/배치가 끝나면 DB도 쉬게(유휴)” 만들 수 있는 구조가 됩니다.
• 단, 배치가 끝나도 앱이 DB 커넥션을 물고 있으면 유휴로 못 들어가는 구조가 생깁니다(아래 ‘커넥션 함정’ 참고).

(옵션) RDS Data API로 “커넥션 관리 부담” 줄이기

AWS는 Data API를 HTTPS API로 SQL 실행하는 방식으로 소개하며, 네트워크/연결 구성 부담을 줄인다는 취지로 설명합니다. (Amazon Web Services, Inc.)
또한 “새로운 Aurora 버전에서는 프로비저닝/Serverless v2 모두에서 Data API가 동작할 수 있다”는 안내가 있습니다(엔진/리전별 지원 확인 필요). (AWS Documentation)

Azure 예시: Timer Trigger Functions + Azure SQL Database Serverless

Azure SQL Database의 serverless compute tier는

• 워크로드에 따라 자동 스케일
• 비활성 시 자동 일시정지(이때는 스토리지만 과금)
• 활동 시 자동 재개
• 초 단위 과금
  으로 설명됩니다. (Microsoft Learn)

비용 절감 포인트

• “밤 12시에만 도는 배치” 같은 워크로드는, DB를 24시간 켜둘 이유가 사라집니다.

⚠️ Azure SQL Serverless ‘자동 일시정지’의 함정(실무에서 진짜 많이 터짐)

Microsoft Q&A에서 열려 있는 세션(연결)이 auto-pausing을 막는다고 직접 언급합니다. (Microsoft Learn)
즉, 커넥션 풀을 “항상 유지”하는 앱이면 오히려 절감이 안 됩니다.

---

6) 설계 예시 3: “스파이크 트래픽(이벤트/티켓팅/쿠폰)” — Queue로 완충 + Function + DB

스파이크 트래픽은 서버리스가 잘 맞지만, DB는 스파이크를 그대로 맞으면 망가집니다.
그래서 큐/토픽으로 완충해서 비용과 안정성을 동시에 잡는 설계를 많이 씁니다.

아키텍처(개념)

Client → Function(요청 접수/검증) → Queue/Topic → Function(처리) → DB
                         ↘ 실패/재시도 → DLQ

AWS 예시: Lambda → (Queue) → Lambda → (RDB면) RDS Proxy

Lambda는 동시에 확 늘어날 수 있어서, RDB 연결을 직접 하면 “DB max connections”에 빨리 닿습니다.
AWS는 RDS Proxy가 Lambda의 많은 연결을 웜 커넥션 풀로 관리해주고, DB의 CPU/메모리 요구량을 줄이며 커넥션 관리 로직을 덜어준다고 설명합니다. (Amazon Web Services, Inc.)
또한 Lambda 공식 문서도 “직접 연결은 단순한 경우, 프로덕션은 프록시를 권장”하고, 프록시는 공유 커넥션 풀로 고동시성을 지원한다고 안내합니다. (AWS Documentation)

GCP 예시: Cloud Run/Functions → Cloud SQL(필요 시) 연결 시 주의

Cloud Run에서 Cloud SQL 연결은 Cloud SQL Auth Proxy 메커니즘을 사용하며, 인스턴스 수에 따라 Cloud SQL Admin API 쿼터가 영향을 받는다는 안내가 있습니다. 또한 Cloud Run 인스턴스 수를 cap 해서 쿼터/확장을 조절할 수 있다고 설명합니다. (Google Cloud Documentation)

비용 절감 관점에서의 해석

• “함수/런 인스턴스가 무한정 늘어나는 것”을 그대로 두면
  DB 연결/쿼리 폭주 → DB 비용 폭탄(또는 장애)로 이어질 수 있습니다.
• 그래서 동시성/최대 인스턴스 제한은 비용 통제 장치이기도 합니다.

---

7) 서버리스 절감 체크리스트 12가지 (Functions + DB 실전)

A. Functions 비용을 줄이는 6가지

1. 메모리/CPU 과대 할당 금지: 서버리스는 “크게 잡으면 빨라지지만 단가도 올라갑니다.”
2. 타임아웃 짧게: 무한 대기 = 과금 지속
3. 외부 API 호출은 비동기로 분리: (큐/이벤트)로 떼어내면 평균 실행 시간이 짧아짐
4. 로깅 과다 금지: 개발 때만 verbose, 운영은 샘플링/요약
5. 큰 라이브러리/콜드스타트 줄이기: 함수 패키지 슬림화, 초기화 로직 최소화
6. 동시성 가드레일: “돈 버는 트래픽”이 아니라 “폭주/공격”도 같이 커집니다

B. DB 비용을 줄이는 6가지

7. DB가 고정비가 되지 않게: 가능하면 on-demand/serverless/auto-pause 계열 선택 (Amazon Web Services, Inc.)
8. 쿼리 패턴부터 설계: NoSQL은 스캔/광범위 쿼리가 곧 비용
9. TTL/만료 전략: 임시 데이터는 자동 삭제(저장비+읽기비 감소) (Google Cloud)
10. 배치로 묶어서 쓰기/읽기: 요청 수 자체를 줄이면 즉시 절감
11. RDB 커넥션 폭탄 방지: Lambda→RDS는 프록시/풀링 고려 (Amazon Web Services, Inc.)
12. 서버리스 RDB ‘자동 일시정지’ 방해요인 제거: 연결을 물고 있으면 절감이 안 됩니다 (Microsoft Learn)

---

8) “서버리스가 오히려 비싸지는” 흔한 케이스 4가지

1. 트래픽이 24/7 꾸준한데 서버리스로만 운영
2. 함수가 너무 오래 돈다(ETL/대형 변환/긴 AI 추론 등) → 잡/배치/컨테이너로 재검토
3. DB가 RDB인데 커넥션 관리 실패(동시성 증가 = 연결 폭주) (Amazon Web Services, Inc.)
4. Azure SQL serverless 같은 경우 serverless vCore 단가가 provisioned보다 낮지 않을 수 있음(꾸준한 부하라면 프로비저닝이 더 유리할 수 있음) (Microsoft Learn)

---

FAQ (서버리스 비용 절감)

Q1. 서버리스로 바꾸면 무조건 비용이 줄어드나요?

아니요. “유휴 시간이 많고 트래픽이 들쭉날쭉”할 때 유리합니다. AWS Lambda/Azure Functions/Cloud Run 모두 요청/실행 시간 기반 과금 구조라, 계속 돌면 계속 과금됩니다. (Amazon Web Services, Inc.)

Q2. Functions만 서버리스로 바꿨는데 왜 비용이 그대로죠?

DB가 항상 켜져 있으면(프로비저닝 RDB 등) DB가 비용의 바닥(고정비)이 됩니다. 이 경우 DB를 on-demand/serverless/auto-pause 가능한 옵션으로 바꿔야 절감이 체감됩니다. (Microsoft Learn)

Q3. Azure SQL Serverless가 자동으로 안 꺼져요. 왜죠?

열려 있는 세션(연결)이 auto-pausing을 막을 수 있다는 안내가 Microsoft Q&A에 있습니다. 배치/함수가 끝나면 연결을 확실히 끊는 설계가 필요합니다. (Microsoft Learn)

Q4. Lambda가 늘면 RDB 커넥션이 터지는 이유가 뭔가요?

Lambda는 동시 실행이 급격히 늘 수 있어 DB 연결도 폭증합니다. AWS는 이를 해결하기 위해 RDS Proxy가 웜 커넥션 풀을 제공하고, Lambda 문서도 프로덕션에서 프록시 사용을 권장합니다. (Amazon Web Services, Inc.)

Q5. Cloud Run(또는 Cloud Run functions) + Cloud SQL 조합에서 비용/안정성 포인트는?

Cloud Run에서 Cloud SQL 연결은 Auth Proxy 메커니즘을 사용하며, 인스턴스 수에 따라 관련 API 쿼터가 영향을 받을 수 있습니다. 그래서 최대 인스턴스 cap 같은 가드레일이 비용/안정성 모두에 도움이 됩니다. (Google Cloud Documentation)

Q6. 서버리스 RDB로 가장 무난한 예시는?

AWS에서는 Aurora Serverless가 “오토스케일 + 유휴 시 중단 + ACU 초 단위 과금”으로 소개됩니다. Azure는 Azure SQL Database serverless tier가 “자동 일시정지(스토리지만 과금) + 자동 재개 + 초 단위 과금”으로 설명됩니다. (Amazon Web Services, Inc.)

---

원하시면, (1) 트래픽 패턴(평소/피크), (2) 데이터 모델(조인 많은 RDB인지, 문서/키-값인지), (3) 배치 주기(있다면) 딱 3가지만 기준으로
당신 서비스에 맞춘 “Functions + Managed DB” 최적 설계안 2~3개(비용 가정 포함)를 더 구체적으로 그려드릴게요.

AX 100배의 법칙 – 나와 조직의 능력을 100배 높이는 AI 경영의 실제 도서 구매

함께 읽으면 좋은 글:

디지털 트랜스포메이션: 조직의 습관을 바꾸는 일, 도서 구매

. .