→ Lambda는 "이벤트 기반(Event-driven)"으로 동작 - 트리거가 발생했을 때만 코드가 실행되고, 실행이 끝나면 사라져요. 사용한 시간만큼만 과금돼요 (실행 안 하면 비용 0).
| 항목 | 제한 |
|---|---|
| 실행 시간(Timeout) | 최대 15분 → 오래걸리는 작업은 서버리스에 부적합 |
| 메모리 | 128MB ~ **10,240MB(10GB) |
| → cpu는 램 비례** | |
| 임시 디스크(/tmp) | 기본 512MB, 최대 10GB까지 설정 가능 |
| 배포 패키지 크기 | 압축 시 50MB, 압축 해제 시 250MB (컨테이너 이미지로는 최대 10GB) |
| 동시 실행(Concurrency) | 계정당 기본 1,000개 (리전별, 증설 요청 가능) |
| 환경 변수 크기 | 4KB |
Lambda 함수가 오랫동안 호출 안 되다가, 갑자기 호출되면:
→ AWS가 그제서야 "새로운 실행 환경(컨테이너 같은 것)"을 처음부터 준비해야 함
→ 코드 다운로드, 런타임 초기화(JVM 시작 등), 함수 초기화 코드 실행
→ 이 과정에서 지연시간(수백ms ~ 몇 초)이 발생 = Cold Start
→ SnapShot: 첫 부팅을 끝내놓고 스냅샷 찍어서 요청 시 빠르게 시작할 수 있는 기능
일반 Cold Start:
요청 도착 → (그제서야) 초기화 시작 → JVM 부팅, 클래스 로딩... → 실행 (느림)
SnapStart:
배포 시점에 미리 → 초기화를 한 번 수행해서 "그 상태 전체(메모리+디스크 상태)"를
스냅샷으로 저장
↓
실제 요청 도착 → 그 스냅샷을 그대로 복원(캐시에서 불러오기)해서 즉시 시작 (훨씬 빠름)
| 구분 | Lambda@Edge | CloudFront Functions |
|---|---|---|
| 실행 시간 | 5~30초 | 1ms 이내 |
| 언어 | Node.js, Python | JavaScript만 |
| 복잡도 | 복잡한 로직 가능 | 단순 작업 (헤더를 바꾸거나, 리다이렉트 등) |
| 비용 | 상대적으로 비쌈 | 훨씬 저렴 |
| 트리거 시점 | 4가지 (오리진 요청/응답 포함) | 2가지 (뷰어 요청/응답만) |
일반 Lambda: 특정 리전 하나에서만 실행됨
Lambda@Edge/CloudFront Functions: 전 세계 엣지 로케이션에서,
사용자와 가장 가까운 곳에서 실행됨 → **지연시간 최소화**
기본적으로 Lambda 함수는 "AWS가 관리하는 별도의 네트워크"에서 실행됨
→ 인터넷(S3, DynamoDB 등 AWS 퍼블릭 서비스)에는 자유롭게 접근 가능
→ 하지만 "특정 VPC 안의 사설 리소스(RDS, ElastiCache 등)"에는 접근 불가
"Lambda 함수가 Private Subnet에 있는 RDS(MySQL)에 접근해야 한다"
→ RDS는 Private IP만 가지고 있어서,
"Lambda가 그 VPC 안에 들어가야만 접근 가능"