1. Serverless 개요
Serverless란?
- 개발자가 서버를 관리하지 않는 새로운 패러다임
- 코드(함수)만 배포
- FaaS (Function as a Service)
- 서버가 없다는 뜻이 아님 → 관리/프로비저닝/보이지 않을 뿐
AWS Serverless 서비스
| 서비스 | 용도 |
|---|---|
| AWS Lambda | 함수 실행 |
| DynamoDB | NoSQL DB |
| API Gateway | REST API |
| S3 | 스토리지 |
| SNS & SQS | 메시징 |
| Kinesis Data Firehose | 스트리밍 |
| Aurora Serverless | 관계형 DB |
| Step Functions | 워크플로우 오케스트레이션 |
| Fargate | 서버리스 컨테이너 |
| Cognito | 인증 |
2. AWS Lambda vs EC2
| 항목 | EC2 | Lambda |
|---|---|---|
| 서버 | 직접 관리 | 관리 불필요 |
| 실행 | 지속 실행 | 온디맨드 실행 |
| 시간 | 무제한 | 최대 15분 |
| 스케일링 | 수동 개입 | 자동 |
| 리소스 | RAM/CPU 제한 | RAM 최대 10GB |
3. Lambda 장점
가격
| 항목 | 무료 티어 | 초과 시 |
|---|---|---|
| 요청 수 | 1,000,000건/월 | $0.20/1M 요청 |
| 컴퓨팅 시간 | 400,000 GB-초/월 | $1.00/600,000 GB-초 |
💡 매우 저렴 → Lambda 인기 비결!
기타 장점
- AWS 서비스와 완전 통합
- 다양한 언어 지원
- CloudWatch로 쉬운 모니터링
- RAM 증가 → CPU/네트워크도 향상
4. 지원 언어 & 통합
지원 언어
| 언어 | 비고 |
|---|---|
| Node.js (JavaScript) | - |
| Python | - |
| Java | - |
| C# (.NET Core) / PowerShell | - |
| Ruby | - |
| Custom Runtime API | Rust, Go 등 |
| Container Image | Lambda Runtime API 구현 필수 |
⚠️ 임의 Docker 이미지는 ECS/Fargate 권장
주요 통합 서비스
S3, DynamoDB, Kinesis, SNS, SQS
API Gateway, CloudFront (Lambda@Edge)
CloudWatch Events/EventBridge, Cognito
CloudWatch Logs5. Lambda 사용 예시
예시 1: S3 썸네일 생성
S3 (이미지 업로드) → Lambda (썸네일 생성) → S3 (썸네일 저장)
→ DynamoDB (메타데이터)예시 2: Serverless CRON Job
EventBridge (매 1시간) → Lambda (작업 수행)6. Lambda 호출 유형
6.1 동기 호출 (Synchronous)
Client → SDK/CLI → Lambda → Response (즉시 반환)
Client → API Gateway → Lambda → Response| 특징 | 설명 |
|---|---|
| 응답 | 즉시 반환 |
| 에러 처리 | 클라이언트 측 (재시도, Exponential Backoff) |
동기 호출 서비스:
- User Invoked: ALB, API Gateway, CloudFront (Lambda@Edge), S3 Batch
- Service Invoked: Cognito, Step Functions
- Other: Lex, Alexa, Kinesis Data Firehose
6.2 비동기 호출 (Asynchronous)
S3 (새 파일) → Event Queue → Lambda → 처리
│
└─→ 실패 시 재시도 (최대 3회)
└─→ DLQ (SNS/SQS)| 특징 | 설명 |
|---|---|
| 재시도 | 3회 (1분 → 2분 대기) |
| 멱등성 | 처리 로직은 idempotent 해야 함 |
| DLQ | SNS 또는 SQS로 실패 처리 |
| 장점 | 결과 대기 불필요 → 대량 처리에 유용 |
비동기 호출 서비스:
- S3, SNS
- CloudWatch Events / EventBridge
- CodeCommit, CodePipeline
- CloudWatch Logs, SES, CloudFormation
- AWS Config, IoT
6.3 Event Source Mapping
Kinesis/DynamoDB Streams/SQS
│
Event Source Mapping (Poll)
│
▼
Lambda (배치로 동기 호출)| 특징 | 설명 |
|---|---|
| 대상 | Kinesis, DynamoDB Streams, SQS |
| 방식 | Polling (Lambda가 소스에서 레코드 가져옴) |
| 호출 | 동기 (배치 단위) |
7. ALB + Lambda 통합
구조
Client → ALB → Target Group → Lambda
(HTTP→JSON) (JSON→HTTP)- Lambda를 Target Group에 등록
- ALB가 HTTP를 JSON으로 변환하여 Lambda 호출
- Lambda 응답을 HTTP로 변환하여 클라이언트에 반환
Multi-Value Headers
URL: http://example.com/path?name=foo&name=bar
→ Lambda Event:
{
"queryStringParameters": {
"name": ["foo", "bar"]
}
}8. S3 Events → Lambda
S3 Event 유형
S3:ObjectCreatedS3:ObjectRemovedS3:ObjectRestoreS3:Replication
특징
| 항목 | 설명 |
|---|---|
| 필터링 | 객체 이름 필터 가능 (*.jpg) |
| 지연 | 보통 초 단위, 간혹 1분 이상 |
| 중복 | 비버저닝 버킷에서 동시 쓰기 시 이벤트 누락 가능 |
💡 모든 쓰기에 이벤트 보장하려면 버전 관리 활성화
메타데이터 동기화 패턴
S3 (새 파일) → Lambda → DynamoDB/RDS (메타데이터 저장)9. Streams & Lambda (Kinesis/DynamoDB)
특징
| 항목 | 설명 |
|---|---|
| Iterator | Shard당 1개 생성 |
| 순서 | Partition Key 기준 순서 보장 |
| 데이터 | 스트림에서 제거 안 됨 (다른 Consumer도 읽기 가능) |
| 병렬 | Shard당 최대 10개 배치 동시 처리 |
에러 처리
| 기본 동작 | 설명 |
|---|---|
| 재처리 | 전체 배치 재처리 (성공 또는 만료까지) |
| Shard 일시정지 | 순서 보장을 위해 에러 해결까지 중지 |
설정 옵션:
- 오래된 이벤트 폐기
- 재시도 횟수 제한
- 에러 시 배치 분할 (Lambda 타임아웃 대응)
- 폐기된 이벤트 → Destination으로 전송
10. SQS & Lambda
특징
| 항목 | 설명 |
|---|---|
| Polling | Long Polling |
| 배치 크기 | 1~10 메시지 |
| Visibility Timeout | Lambda 타임아웃의 6배 권장 |
| DLQ | SQS Queue에 설정 (Lambda DLQ는 비동기 전용) |
스케일링
| Queue 유형 | 스케일링 |
|---|---|
| Standard | 분당 60개 인스턴스 추가, 최대 1000개 동시 배치 |
| FIFO | 활성 Message Group 수만큼 스케일링 |
11. Lambda Event & Context Objects
Event Object
- JSON 형식 문서
- 호출 서비스의 데이터 포함
- 예: 입력 인자, 서비스별 인자
Context Object
- 호출, 함수, 런타임 환경 정보
- 예:
aws_request_id,function_name,memory_limit_in_mb
def lambda_handler(event, context):
print(event) # 입력 데이터
print(context.aws_request_id) # 요청 ID
print(context.function_name) # 함수 이름12. Lambda Destinations
비동기 호출 Destinations
| 결과 | 대상 |
|---|---|
| 성공 | SQS, SNS, Lambda, EventBridge |
| 실패 | SQS, SNS, Lambda, EventBridge |
💡 AWS는 DLQ보다 Destinations 권장 (둘 다 사용 가능)
Event Source Mapping Destinations
- 폐기된 이벤트 → SQS, SNS
13. Lambda IAM
Execution Role (실행 역할)
- Lambda가 AWS 서비스에 접근하는 권한
| 관리형 정책 | 용도 |
|---|---|
AWSLambdaBasicExecutionRole | CloudWatch Logs 업로드 |
AWSLambdaKinesisExecutionRole | Kinesis 읽기 |
AWSLambdaDynamoDBExecutionRole | DynamoDB Streams 읽기 |
AWSLambdaSQSQueueExecutionRole | SQS 읽기 |
AWSLambdaVPCAccessExecutionRole | VPC 배포 |
AWSXRayDaemonWriteAccess | X-Ray 추적 |
💡 함수당 하나의 Execution Role 권장
Resource-based Policy
- 다른 계정/서비스가 Lambda를 호출할 수 있도록 허용
- S3 버킷 정책과 유사
14. Lambda 환경 변수 & 모니터링
환경 변수
- Key/Value 쌍 (String)
- 코드 수정 없이 동작 변경
- KMS로 암호화 가능 (비밀 저장)
CloudWatch Logs
- Lambda 실행 로그 저장
- Execution Role에 CloudWatch 쓰기 권한 필요
CloudWatch Metrics
| 메트릭 | 설명 |
|---|---|
| Invocations | 호출 수 |
| Duration | 실행 시간 |
| Concurrent Executions | 동시 실행 수 |
| Error count | 에러 수 |
| Throttles | 스로틀링 수 |
| Iterator Age | Kinesis/DynamoDB 지연 |
X-Ray 추적
- Lambda 콘솔에서 Active Tracing 활성화
- X-Ray Daemon 자동 실행
AWSXRayDaemonWriteAccess정책 필요
15. Edge Functions (CloudFront)
개요
- CloudFront 배포에 연결하는 코드
- 사용자에게 가까운 위치에서 실행 → 지연시간 최소화
- 서버리스, 전역 배포
CloudFront Functions vs Lambda@Edge
| 항목 | CloudFront Functions | Lambda@Edge |
|---|---|---|
| 언어 | JavaScript | Node.js, Python |
| 처리량 | 수백만 req/s | 수천 req/s |
| 트리거 | Viewer Request/Response | Viewer + Origin Request/Response |
| 실행 시간 | < 1ms | 5~10초 |
| 메모리 | 2MB | 128MB ~ 10GB |
| 패키지 크기 | 10KB | 1~50MB |
| 네트워크/파일 접근 | ❌ | ✅ |
| Request Body 접근 | ❌ | ✅ |
| 비용 | 저렴 (1/6) | 비쌈 |
사용 사례
CloudFront Functions:
- Cache Key 정규화
- 헤더 조작
- URL 리다이렉트
- JWT 검증
Lambda@Edge:
- 긴 실행 시간 필요
- 외부 라이브러리 (AWS SDK 등)
- 네트워크 호출 필요
- HTTP Body 접근 필요
16. Lambda in VPC
기본 동작
Lambda (기본) → AWS 소유 VPC에서 실행
│
├─→ Public Internet ✅
└─→ Private VPC (RDS, ElastiCache) ❌VPC 내 Lambda 배포
┌─────────────────── VPC ───────────────────┐
│ │
│ Private Subnet │
│ ┌─────────────────────────────────────┐ │
│ │ │ │
│ │ Lambda ──(ENI)──→ RDS │ │
│ │ │ │
│ └─────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────┘
필요 설정:
• VPC ID
• Subnet IDs
• Security Group IDs
• AWSLambdaVPCAccessExecutionRoleVPC 내 Lambda → 인터넷 접근
┌─────────────────── VPC ───────────────────┐
│ │
│ Private Subnet Public Subnet │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ Lambda │──────▶│ NAT Gateway │ │
│ └──────────────┘ └──────┬───────┘ │
│ │ │
│ ┌──────▼───────┐ │
│ │ IGW │ │
│ └──────┬───────┘ │
└──────────────────────────────────┼─────────┘
│
▼
Public Internet
• VPC 내 Lambda는 인터넷 접근 불가 (기본)
• Public Subnet에 배포해도 Public IP 없음
• Private Subnet + NAT Gateway 필요
• VPC Endpoint로 AWS 서비스 접근 (NAT 없이)NAT = Network Address Translation (네트워크 주소 변환) Private IP 주소를 Public IP 주소로 변환해주는 기술입니다.
Q: Public Subnet에 Lambda를 배포하면 인터넷 접근 가능?
No - EC2 인스턴스는 Public Subnet에서 Public IP를 받아 인터넷 접근이 가능하지만, Lambda는 Public Subnet에 배포해도 Public IP가 할당되지 않음
Lambda 인터넷 접근 방법
| 구성 요소 | 역할 |
|---|---|
| Private Subnet | Lambda 함수 배포 위치 |
| NAT Gateway | Private → Public 트래픽 변환 (Public Subnet에 위치) |
| Internet Gateway | VPC ↔ 인터넷 연결 |
| Route Table | 트래픽 경로 설정 |
Lambda (Private) → NAT Gateway (Public) → IGW → Internet → 외부 APIAWS 서비스 접근: VPC Endpoint
| 방식 | 경로 | 비용 |
|---|---|---|
| Public 경로 | Lambda → NAT → IGW → DynamoDB (Public) | NAT 비용 발생 |
| Private 경로 | Lambda → VPC Endpoint → DynamoDB | Endpoint 비용만 |
💡 VPC Endpoint를 사용하면 NAT/IGW 없이도 AWS 서비스에 Private 액세스 가능
# DynamoDB 접근 예시
Lambda → VPC Endpoint Gateway → DynamoDB (Private 액세스)💡 CloudWatch Logs는 VPC Endpoint/NAT 없이도 동작
17. Lambda 구성
RAM & CPU
| 항목 | 값 |
|---|---|
| RAM | 128MB ~ 10GB (1MB 단위) |
| vCPU | RAM에 비례 |
| 1 vCPU | 1,792MB RAM |
| 최대 vCPU | 6개 (멀티스레딩 필요) |
💡 CPU 집약적 작업 → RAM 증가
핵심 포인트:
- vCPU 개수를 직접 설정 불가 → RAM을 늘려서 간접적으로 vCPU 획득
- RAM 1,792MB = 1 vCPU
- 1 vCPU 이상 → 멀티스레딩 필요
- CPU 집약적 앱의 성능 개선 = RAM 증가
Timeout
| 항목 | 값 |
|---|---|
| 기본 | 3초 |
| 최대 | 900초 (15분) |
핵심 포인트:
- 0초 ~ 15분: Lambda 적합
- 15분 초과 → Fargate, ECS, EC2 사용 권장
/tmp 디렉토리
- 임시 파일 저장 공간
- 최대 10GB
- Execution Context 동결 시 유지 (캐시 역할)
- 영구 저장 → S3 사용
- 암호화 필요 시 → KMS Data Keys 직접 생성
18. Execution Context
개념
- Lambda 코드의 외부 의존성을 초기화하는 임시 런타임 환경
- 다음 호출에서 재사용 가능 → 초기화 시간 절약
Best Practice
# ❌ BAD - 매 호출마다 연결 생성
def lambda_handler(event, context):
db = connect_to_database() # 매번 새로 연결 → 비효율적
# ...
# ✅ GOOD - 핸들러 외부에서 연결 생성 (재사용)
db = connect_to_database() # 한 번만 초기화
def lambda_handler(event, context):
# db 재사용 → 성능 향상
# ...핵심 포인트:
| 항목 | 설명 |
|---|---|
| 실행 컨텍스트 | Lambda 코드의 외부 의존성을 초기화하는 임시 런타임 환경 |
| 재사용 | 연속 호출 시 DB 연결, HTTP/SDK 클라이언트 등을 재사용 |
| /tmp 디렉토리 | 실행 간 파일 공유 가능한 임시 저장소 |
왜 핸들러 외부 초기화가 중요한가?
# 핸들러 내부 초기화 (BAD)
호출 1: DB 연결 → 처리 → 종료
호출 2: DB 연결 → 처리 → 종료 ← 매번 연결 오버헤드
호출 3: DB 연결 → 처리 → 종료
# 핸들러 외부 초기화 (GOOD)
초기화: DB 연결 (1회)
호출 1: 처리 → 종료
호출 2: 처리 → 종료 ← 연결 재사용
호출 3: 처리 → 종료💡 시험 포인트: 초기화에 오래 걸리는 작업(DB 연결, HTTP 클라이언트, SDK 클라이언트)은 핸들러 외부에서 초기화하여 재사용
19. Lambda Layers
용도
- Custom Runtime (C++, Rust)
- 의존성 외부화 (재사용)
장점
Without Layers:
┌─────────────────────────────┐
│ function.py │
│ + heavy_library (30MB) │
│ = 30.02MB 패키지 │
└─────────────────────────────┘
With Layers:
┌───────────────────┐ ┌─────────────────────┐
│ function.py (20KB)│───▶│ Layer: library (30MB)│
└───────────────────┘ └─────────────────────┘
↑
여러 함수에서 공유제한
- 함수당 최대 5개 Layer
- 총 250MB (압축 해제 후)
20. Lambda Storage 옵션 비교
EFS 파일 시스템 마운팅
Lambda 함수가 VPC에서 실행될 경우 EFS 파일 시스템에 액세스 가능
설정 방법:
1. EFS 파일 시스템 생성
2. EFS Access Point 생성
3. Lambda를 Private Subnet에 배포
4. Lambda 초기화 시 EFS를 로컬 디렉토리에 마운트주의사항:
| 항목 | 설명 |
|---|---|
| 연결 제한 | Lambda 인스턴스마다 EFS에 1회 이상 연결 |
| 버스트 제한 | 급격한 Lambda 스케일링 시 연결 버스트 제한 도달 가능 |
Storage 옵션 상세 비교
| 옵션 | 최대 크기 | 지속성 | 유형 | 콘텐츠 | 속도 | 공유 | 비용 |
|---|---|---|---|---|---|---|---|
| /tmp | 10GB | 임시 | 파일 시스템 | 동적 | 가장 빠름 | 함수 내 ❌ | 512MB 무료, 초과 시 추가 |
| Layers | 250MB | 영구 | 아카이브 | 정적 (불변) | 가장 빠름 | 함수 간 ✅ | Lambda 가격 포함 |
| S3 | 무제한 | 영구 | 객체 | 동적 | 빠름 (네트워크) | 전역 ✅ | 스토리지 + 요청 + 전송 |
| EFS | 무제한 | 영구 | 파일 시스템 | 동적 | 빠름 (네트워크) | 전역 ✅ | 스토리지 + 전송 + 처리량 |
각 옵션별 특징
/tmp (임시 스토리지)
- Lambda 인스턴스 종료 시 데이터 삭제
- 함수 내에서만 접근 가능, 호출 간 공유 안 됨
- 파일 시스템 조작 지원
Lambda Layers
- 불변 (수정 불가)
- 함수당 최대 5개, 총 250MB
- 여러 Lambda 함수에서 공유 가능
- IAM 권한 필요
Amazon S3
- S3 API로 접근 (GET, PUT, POST 등)
- 버저닝 지원
- IAM 권한 필요
- 외부 스토리지로 Lambda 호출 간 공유
Amazon EFS
- VPC 내 Lambda에서만 사용 가능
- 네트워크 파일 시스템으로 마운팅
- Lambda 호출 간 공유
EFS 마운트
- VPC 내 Lambda에서만 사용 가능
- EFS Access Point 필요
- ⚠️ 연결 제한 주의 (함수 인스턴스 1개 = 1 연결)
21. Lambda Concurrency (동시성)
동시성 개념
Lambda 함수 호출이 많아질수록 동시 실행도 증가 (자동 스케일링)
낮은 트래픽: 동시 실행 2개
높은 트래픽: 동시 실행 최대 1,000개 (리전당 기본 제한)Reserved Concurrency (예약 동시성)
함수 수준에서 동시성 제한 설정 가능 (예: 최대 50개)
Throttling 발생 시:
| 호출 유형 | 동작 |
|---|---|
| 동기식 | ThrottleError 429 반환 |
| 비동기식 | 자동 재시도 후 DLQ로 이동 |
💡 1,000개 이상 필요 시 AWS 지원 티켓으로 제한 증가 요청 가능
동시성 미설정 시 문제점
⚠️ 중요: 동시성 제한은 계정의 모든 함수에 공유됨
# 시나리오: 3개의 애플리케이션이 Lambda 사용
App 1: ALB → Lambda (대규모 프로모션 중, 트래픽 폭주)
App 2: API Gateway → Lambda (소규모 사용자)
App 3: SDK/CLI → Lambda
# 문제 발생
App 1이 동시성 1,000개 모두 소진
↓
App 2, App 3도 Throttle 발생!해결책: 각 함수에 Reserved Concurrency 설정으로 동시성 보장
비동기 호출과 동시성
S3 이벤트 예시:
S3 (대량 파일 업로드) → Lambda (동시성 제한 도달)
↓
Throttle 발생
↓
내부 이벤트 대기열로 반환
↓
최대 6시간 동안 재시도
(지수 백오프: 1초 ~ 5분 간격)| 항목 | 설명 |
|---|---|
| 재시도 기간 | 최대 6시간 |
| 재시도 간격 | 지수 백오프 (1초 ~ 5분) |
| 에러 코드 | 429 (Throttle), 5xx (시스템 에러) |
기본 제한
- 리전당 1,000개 동시 실행
Reserved Concurrency (예약 동시성)
- 특정 함수에 동시성 제한/보장
- 다른 함수가 모든 동시성 소진 방지
Throttling
| 호출 유형 | Throttle 동작 |
|---|---|
| 동기 | 429 ThrottleError 반환 |
| 비동기 | 자동 재시도 → DLQ |
Concurrency 문제 예시
ALB/API Gateway (많은 사용자) ──┐
│
SDK/CLI (소수 사용자) ──────────┼──▶ Lambda (1000 동시 실행)
│
THROTTLE!→ Reserved Concurrency로 함수별 제한 설정
22. Cold Start & Provisioned Concurrency
Cold Start
- 새 인스턴스 생성 시 초기화 시간 발생
- 코드, 의존성, SDK 로드
- 첫 요청 지연 발생
Provisioned Concurrency
- 함수 호출 전에 동시성 미리 할당
- Cold Start 완전 방지
- Application Auto Scaling으로 관리 가능
┌─────────────────────────────────────────┐
│ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ Unreserved │ │ Reserved │ │
│ │ Concurrency │ │ Concurrency │ │
│ │ │ │ │ │
│ │ │ │ ┌─────────┐ │ │
│ │ │ │ │Provisioned│ │
│ │ │ │ │Concurrency│ │
│ │ │ │ └─────────┘ │ │
│ └─────────────┘ └─────────────┘ │
│ │
│ Account Concurrency Limit │
└─────────────────────────────────────────┘23. Lambda 배포
의존성 포함
| 언어 | 방법 |
|---|---|
| Node.js | npm + node_modules/ |
| Python | pip --target |
| Java | .jar 파일 포함 |
업로드 방식
| 크기 | 방법 |
|---|---|
| < 50MB | Lambda에 직접 업로드 |
| ≥ 50MB | S3에 업로드 후 참조 |
💡 AWS SDK는 기본 포함 (별도 패키징 불필요)
Container Image
# Lambda Runtime API 구현 이미지 사용
FROM amazon/aws-lambda-nodejs:12
COPY app.js package*.json ./
RUN npm install
CMD ["app.lambdaHandler"]| 항목 | 값 |
|---|---|
| 최대 크기 | 10GB |
| 저장소 | ECR |
| 테스트 | Lambda Runtime Interface Emulator |
CloudFormation 배포
CloudFormation을 사용하여 Lambda 함수를 배포하는 두 가지 방법이 있습니다.
1. Inline 방식 (Code.ZipFile)
Lambda 코드를 CloudFormation 템플릿 내에 직접 작성하는 방법입니다.
| 특징 | 설명 |
|---|---|
| 사용 속성 | Code.ZipFile |
| 적합한 경우 | 아주 단순한 함수 |
| 제한 사항 | ❌ 종속성(dependencies) 포함 불가 |
💡 종속성이 없는 간단한 Lambda 함수만 Inline 방식으로 작성 가능
2. S3 방식 (zip 파일 참조)
Lambda 함수 zip 파일을 S3에 업로드하고, CloudFormation에서 해당 위치를 참조하는 방법입니다.
| 속성 | 설명 |
|---|---|
| S3Bucket | zip 파일이 저장된 버킷 이름 |
| S3Key | zip 파일의 전체 경로 |
| S3ObjectVersion | 버전 ID (버저닝 버킷에서 권장) |
왜 S3ObjectVersion이 중요한가?
# 시나리오: S3에 코드를 업데이트했지만...
S3에 새 코드 업로드 (같은 파일명)
↓
CloudFormation 템플릿의 S3Bucket, S3Key 동일
↓
❌ CloudFormation이 변경 감지 못함 → 업데이트 안 됨!
# 해결책: S3ObjectVersion 사용
버저닝 활성화 → 파일 덮어쓰기 → 새 버전 ID 생성
↓
S3ObjectVersion 값 변경
↓
✅ CloudFormation이 변경 감지 → Lambda 함수 업데이트!크로스 계정 배포 (Cross-Account Deployment)
Lambda 코드를 다수의 계정에 배포하려면 두 가지 설정이 필요합니다.
┌─────────────────────────────────────────────────────────────────┐
│ 계정 1 (소스) │
│ ┌─────────────┐ │
│ │ S3 Bucket │ ← Lambda 코드 저장 │
│ │ (코드 저장) │ │
│ │ │ │
│ │ ┌─────────┐ │ │
│ │ │ Bucket │ │ ← 계정 2, 3에 GetObject 권한 부여 │
│ │ │ Policy │ │ │
│ │ └─────────┘ │ │
│ └──────┬──────┘ │
└─────────┼───────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ 계정 2 (타겟) │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ CloudFormation │─────▶│ Lambda Function │ │
│ │ + Execution Role│ │ (배포됨) │ │
│ └─────────────────┘ └─────────────────┘ │
│ │ │
│ └─ S3 버킷 접근 권한 (계정 1의 버킷 정책 + 실행 역할) │
└─────────────────────────────────────────────────────────────────┘| 필요한 설정 | 위치 | 설명 |
|---|---|---|
| Bucket Policy | 계정 1 (소스) | 타겟 계정의 CloudFormation이 코드 접근 허용 |
| Execution Role | 계정 2, 3 (타겟) | S3 버킷에서 코드를 읽어올 수 있는 IAM 역할 |
두 가지 설정이 조합되면 CloudFormation이 S3 버킷에서 코드를 검색하여 Lambda 함수를 생성
코드 예시
Inline (간단한 함수):
Code:
ZipFile: |
def handler(event, context):
return "Hello"S3 (의존성 포함):
Code:
S3Bucket: my-bucket
S3Key: code.zip
S3ObjectVersion: abc123 # 버전 관리 시⚠️ S3 코드 업데이트 시 S3ObjectVersion 변경 필수 (아니면 CloudFormation이 업데이트 안 함)
24. Lambda Versions & Aliases
Versions
$LATEST (mutable) ← 개발 중
│
├─→ V1 (immutable)
├─→ V2 (immutable)
└─→ V3 (immutable)| 항목 | 설명 |
|---|---|
| $LATEST | 개발 버전 (가변) |
| V1, V2... | 발행된 버전 (불변) |
| ARN | 버전별 고유 ARN |
Aliases
$LATEST ← DEV Alias
V2 ← TEST Alias
V1 (95%) + V2 (5%) ← PROD Alias (Canary)| 항목 | 설명 |
|---|---|
| 용도 | 버전에 대한 포인터 |
| 가변성 | 가변 (버전은 불변) |
| Canary | 가중치로 트래픽 분할 |
| 제한 | Alias는 다른 Alias 참조 불가 |
25. Lambda & CodeDeploy
배포 전략
| 전략 | 설명 |
|---|---|
| Linear | N분마다 X% 증가 |
| Canary | X%로 시작 → 일정 시간 후 100% |
| AllAtOnce | 즉시 100% |
예시:
Linear10PercentEvery3MinutesCanary10Percent5Minutes
AppSpec.yml
version: 0.0
Resources:
- MyFunction:
Type: AWS::Lambda::Function
Properties:
Name: MyFunction
Alias: PROD
CurrentVersion: 1
TargetVersion: 2Pre/Post Traffic Hooks
- 트래픽 전환 전후 Lambda 함수로 헬스 체크
26. Lambda Function URL
개요
- Lambda 전용 HTTP(S) 엔드포인트
- 형식:
https://<url-id>.lambda-url.<region>.on.aws - Public Internet으로만 접근
- PrivateLink 미지원
보안
| AuthType | 설명 |
|---|---|
| NONE | 공개 접근 (Resource Policy로 제어) |
| AWS_IAM | IAM 인증 (lambda:InvokeFunctionUrl 필요) |
Cross-Account 접근:
- Same Account: Identity-based OR Resource-based Allow
- Cross Account: Identity-based AND Resource-based Allow
CORS
- 다른 도메인에서 호출 시 CORS 설정 필요
27. Lambda Limits (리전당)
실행 제한
| 항목 | 값 |
|---|---|
| 메모리 | 128MB ~ 10GB |
| 실행 시간 | 최대 900초 (15분) |
| 환경 변수 | 4KB |
| /tmp | 512MB ~ 10GB |
| 동시 실행 | 1000 (증가 요청 가능) |
배포 제한
| 항목 | 값 |
|---|---|
| 압축 패키지 | 50MB |
| 압축 해제 후 | 250MB |
| 환경 변수 | 4KB |
28. Lambda Best Practices
핸들러 외부에서 초기화
# ✅ 핸들러 외부에서 초기화 (재사용)
import boto3
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('MyTable')
def lambda_handler(event, context):
# table 재사용
return table.get_item(...)환경 변수 활용
- DB 연결 문자열, S3 버킷 이름
- 비밀번호 → KMS 암호화
기타
- 배포 패키지 최소화
- Layers 활용
- Lambda Limits 숙지
- 재귀 호출 금지 (Lambda가 자기 자신 호출 ❌)
핵심 요약
호출 유형
| 유형 | 서비스 | 특징 |
|---|---|---|
| 동기 | ALB, API Gateway, SDK | 즉시 응답 |
| 비동기 | S3, SNS, EventBridge | 재시도 3회, DLQ |
| Event Source Mapping | Kinesis, DynamoDB, SQS | Polling, 배치 |
VPC & 네트워킹
| 상황 | 설정 |
|---|---|
| Private 리소스 접근 | VPC 배포 |
| 인터넷 접근 | NAT Gateway |
| AWS 서비스 접근 | VPC Endpoint |
동시성
| 개념 | 설명 |
|---|---|
| Reserved | 함수별 동시성 제한/보장 |
| Provisioned | Cold Start 방지 |
Edge Functions
| 유형 | 용도 |
|---|---|
| CloudFront Functions | 간단한 Viewer 처리, 저렴 |
| Lambda@Edge | 복잡한 처리, Origin 접근 |