[SAP] Serverless & Container Architecture

Date

2026/03/12

AWS Lambda

Lambda 핵심 개념

Lambda는 이벤트 기반 서버리스 컴퓨팅 서비스이다. 서버 프로비저닝이나 관리 없이 코드를 실행한다. 함수는 이벤트에 의해 트리거되며, 실행 시간에 대해서만 비용을 지불한다.

•

Lambda 핵심 제한 — 시험 단골

최대 실행 시간	15분
메모리	128MB ~ 10,240MB
임시 스토리지	/tmp 최대 10,240MB
패키지 크기	.zip 50MB (압축), 250MB (비압축) 컨테이너 이미지 10GB
동시 실행	리전당 기본 1,000개 (Soft Limit)
환경 변수	최대 4KB

Lambda 호출 방식

동기(Synchronoous) 호출

호출자 → Lambda → 응답 대기 → 결과 반환

•

트리거: API Gateway, ALB, Cognito, CloudFront

•

특징: 

◦

에러 발생 시 호출자가 직접 처리

◦

Lambda가 재시도 안 함

비동기(Asynchronous) 호출

호출자 → Lambda → 즉시 200 반환 (결과 기다리지 않음)

•

트리거: S3, SNS, EventBridge, CloudWatch Events

•

특징

◦

자동 재시도 2회 (총 3번 실행)

◦

실패 시 DLQ(Dead Letter Queue) 또는 Lambda Destinations로 라우팅

스트림/폴링(Stream/Polling) 기반

Lambda가 소스를 지속적으로 폴링

•

트리거: SQS, Kinesis, DynamoDB Streams, MSK

•

특징:

◦

Lambda가 배치로 레코드 처리

◦

실패 시 배치 재처리 (SQS: DLQ 설정 권장)

S3 이벤트 → Lambda → 비동기 (자동 재시도 2회)

API Gateway → Lambda → 동기 (재시도 없음)

SQS → Lambda → 폴링 (배치 처리)

Lambda 동시성 & Cold Start

•

Cold Start 발생 조건:

◦

새 실행 환경 초기화 시
→ 컨테이너 시작 + 런타임 초기화 + 핸들러 로드
→ 수백 ms ~ 수 초 지연

•

Cold Start 해결 방법:

◦

Provisioned Concurrency

→ 미리 초기화된 실행 환경 유지 → 즉시 응답 보장 (Cold Start 제거) → 비용 발생 (항상 켜진 상태)

◦

Reserved Concurrency

→ 특정 함수에 최대 동시 실행 수 예약 → 다른 함수가 이 할당량 사용 불가 → Cold Start 해결 (스로틀링 제어용)

•

동시성 계산:

◦

동시 실행 수 = 초당 호출 수 x 평균 실행 시간(초)

◦

예: 초당 1,000번 호출, 실행 시간 0.5초 → 동시 실행 500개 필요

Lambda 응답 지연 (첫 요청만 느림) → Cold Start

Cold Start 완전 제거 → Provisioned Concurrency

특정 Lambda가 모든 동시성 소진 방지 → Reserved Concurrency

AWS LambdaUnderstanding Lambda function scaling - AWS Lambda

Lambda & VPC

•

기본 Lambda (VPC 외부)

◦

인터넷 접근 

◦

VPC 내 RDS 접근 

•

VPC 연결 Lambda:

◦

VPC 내 RDS/ElastiCache 접근 

◦

인터넷 접근  (NAT Gateway 필요)

◦

Cold Start 시간 증가 (ENI 생성)

•

VPC Lambda → 인터넷 접근 구성:

◦

Lambda → Private Subnet → NAT Gateway → Internet Gateway → 인터넷

Lambda 이벤트 소스 & 아키텍처 패턴

서버리스에서는 배치 처리보다 실시간 이벤트 처리가 권장된다. 배치는 더 작은 단위의 증분 업데이트로 대체되어야 한다.

•

Lambda 간 직접 동기 호출 → Anti-Pattern 

◦

이유:

▪

비용: 대기 중인 Lambda도 비용 발생

▪

복잡성: 에러 처리, 롤백 복잡

▪

확장성: 중첩 호출 시 동시성 급증

•

올바른 패턴:

◦

Lambda → SQS → Lambda (비동기 디커플링)

◦

Lambda → Step Functions (복잡한 워크플로우)

◦

Lambda → SNS → 여러 Lambda (팬아웃)

◦

Lambda → EventBridge (이벤트 라우팅)

Lambda 함수는 동일한 이벤트를 두 번 이상 받을 수 있으므로 멱등성(idempotent)을 갖도록 설계해야 한다. 동일한 이벤트를 여러 번 받아도 첫 번째 처리 이후 결과가 변경되지 않아야 한다. DynamoDB 테이블에 최근 처리된 식별자를 추적해 이미 처리된 트랜잭션인지 확인하는 방식으로 멱등성을 구현할 수 있다.

Idempotency - Powertools for AWS Lambda (Python)

API Gateway

API Gateway 타입

타입	프로토콜	특징
REST API	HTTP/HTTPS	완전한 기능, 캐싱, API Key, 사용량 계획
HTTP API	HTTP/HTTPS	REST보다 저렴(71%), 저지연, 기본 기능만
WebSocket API	WebSocket	양방향 실시간 통신, 채팅/게임

REST API vs HTTP API 선택

•

캐싱 필요 → REST API

•

API Key/사용량 계획 → REST API

•

AWS WAF 연동 → REST API

•

단순 Lambda 프록시 → HTTP API (비용 절감)

•

JWT 인증 → HTTP API (기본 지원)

API Gateway 통합 유형

•

Lambda Proxy integration(통합):

◦

요청 전체(헤더, 쿼리, 바디)를 Lambda에 그대로 전달

◦

Lambda가 응답 형식 직접 제어

→ 가장 일반적인 패턴

•

Lambda Non-Proxy (커스텀):

◦

API Gateway에서 요청/응답 변환 (Mapping Template)

→ VTL(Velocity Template Language)로 변환

→ 레거시 연동 시 사용

•

AWS Service Integration(직접 통합):

◦

API Gateway → Lambda 없이 직접 AWS 서비스 호출

◦

예: API Gateway → DynamoDB Put Item

◦

예: API Gateway → SQS Send Message

→ Lambda 불필요로 비용 절감, 지연 감소

API Gateway에서 Lambda 없이 DynamoDB에 직접 쓰기 → AWS Service 직접 통합

“서버리스 아키텍처 간소화 문제에서 자주 출제”

Amazon API GatewayChoose an API Gateway API integration type - Amazon API Gateway

AWS Step Functions

Step Functions vs SQS vs SNS 선택 기준

•

Step Functions:

◦

복잡한 워크플로우 (조건, 병렬, 재시도, 에러 처리)

◦

Lambda 함수 오케스트레이션

◦

실행 상태 시각화 및 감사

◦

최대 1년 실행 (Standard Workflow)

Standard: 정확히 한 번 실행, 감사 가능, 비쌈

Express: 최소 한 번 실행, 고처리량, 저렴, 5분 제한

•

SQS:

◦

간단한 비동기 디커플링

◦

순서 없는 메시지 처리 (Standard)

◦

순서 보장 (FIFO)

◦

Lambda 직접 트리거 가능

•

SNS:

◦

Pan out (1→N 배포)

◦

여러 구독자에게 동시 전달

◦

SQS + SNS 조합: 팬아웃 + 내구성

Lambda 순차 실행 + 에러 처리 + 재시도 → Step Functions

서비스 간 느슨한 결합, 비동기 → SQS

1:N 이벤트 전파 → SNS

복잡한 주문 처리 워크플로우 → Step Functions

컨테이너 서비스 비교

서비스 계층 구조 이해

┌─────────────────────────────────────────┐
│           컨테이너 이미지 저장소             │
│        Amazon ECR (Elastic Container    │
│              Registry)                  │
└────────────────┬────────────────────────┘
                 │
    ┌────────────┴──────────────┐
    │     오케스트레이션 계층        │
    ├────────────┬──────────────┤
    │  Amazon    │   Amazon     │
    │  ECS       │   EKS        │
    │ (AWS 자체) │ (Kubernetes)  │
    └────┬───────┴──────┬───────┘
         │              │
    ┌────┴──────────────┴────┐
    │       컴퓨팅 계층         │
    ├─────────────┬──────────┤
    │  EC2        │ Fargate  │
    │ (직접 관리)   │ (서버리스) │
    └─────────────┴──────────┘
Plain Text
복사

ECS vs EKS 비교

Fargate는 컨테이너를 위한 서버리스 컴퓨팅 엔진으로, 기본 인프라를 관리하지 않고 컨테이너를 실행할 수 있다. EC2 인스턴스를 프로비저닝하거나 관리할 필요가 없으며, ECS와 EKS 모두에서 사용할 수 있다.

	ECS	EKS
엔진	AWS 자체 오케스트레이터	Kubernetes (오픈소스)
러닝 커브	낮음 (AWS 친화적)	높음 (K8s 지식 필요)
AWS 통합	매우 깊음	좋음 (일부 추가 설정)
멀티 클라우드	AWS 전용	(K8s 표준)
컨트롤 플레인	AWS 완전 관리	AWS 관리 (비용 발생)
비용	컨트롤 플레인 무료	컨트롤 플레인 $0.10/시간
커스터마이징	제한적	매우 높음 (CRD, 플러그인)

AWS만 사용, 단순함, 빠른 시작 → ECS

Kubernetes 기존 사용 중, 멀티 클라우드 → EKS

서버 관리 없이 컨테이너 실행 → Fargate (ECS 또는 EKS와 함께)

EC2 직접 제어, GPU, 특수 인스턴스 필요 → EC2 Launch Type

Fargate vs EC2 Launch Type

•

Fargate Launch Type:

◦

인프라 관리 불필요

◦

태스크별 격리된 실행 환ㄴ경

◦

자동 스케일링

◦

GPU 지원 

◦

Windows 컨테이너 제한적

◦

비용: 사용한 vCPU + 메모리 기준

•

EC2 Launch Type:

◦

EC2 인스턴스 직접 관리

◦

GPU 인스턴스 사용 가능

◦

기존 EC2 예약 인스턴스 활용

◦

더 세밀한 네트워크 제어

◦

비용: EC2 인스턴스 비용

Amazon EventBridge

EventBridge = 서버리스 이벤트 버스

이벤트 소스            EventBridge        대상
──────────          ───────────        ────
AWS 서비스         →   이벤트 버스     →   Lambda
SaaS 앱(Zendesk)  →  (이벤트 라우팅)  →   Step Functions
커스텀 앱          →   규칙 기반 필터   →   SQS/SNS
                      패턴 매칭          API Gateway
                                       ECS Task
Plain Text
복사

EventBridge vs SNS vs SQS 선택

•

EventBridge:

◦

이벤트 라우팅 및 필터링

◦

AWS 서비스 → 다른 서비스 연동

◦

SaaS 이벤트 수신 (Salesforce, Zendesk)

◦

스케줄 기반 트리거 (cron)

◦

크로스 계정 이벤트 전달

•

SNS:

◦

단순 팬아웃 (1:N)

◦

SMS/이메일/HTTP 엔드포인트 지원

◦

메시지 필터링 (구독 필터 정책)

•

SQS:

◦

메시지 큐, 비동기 처리

◦

가시성 타임아웃, DLQ

◦

Lambda 트리거 가능

AWS 이벤트를 다른 서비스로 라우팅 → EventBridge

여러 구독자에게 알림 → SNS

내구성 있는 비동기 처리 → SQS

Amazon EventBridgeWhat Is Amazon EventBridge? - Amazon EventBridge

AWS App Runner

AWS App Runner는 인프라를 관리하거나 커스터마이징 없이 애플리케이션을 인터넷에 배포하는 가장 간단한 경로를 제공한다.

App Runner

•

소스코드 또는 컨테이너 이미지 → 자동으로 웹 서비스 배포

•

인프라 완전 관리 (EC2, ECS, ALB 자동 구성)

•

자동 스케일링 + HTTPS

•

ECS/EKS보다 단순, Beanstalk와 유사

선택 기준

•

App Runner → 가장 단순, 빠른 배포, 컨트롤 불필요

•

Beanstalk → App Runner보다 설정 자유도 높음

•

ECS Fargate → Beanstalk보다 더 세밀한 제어

•

EKS → 가장 높은 제어, K8s 생태계

Summary

개념	한 줄 요약
Lambda 최대 실행 시간	15분
Lambda 동기 호출	API GW/ALB. 재시도 없음. 호출자가 에러 처리
Lambda 비동기 호출	S3/SNS/EventBridge. 자동 재시도 2회. DLQ 설정 가능
Lambda 폴링	SQS/Kinesis/DynamoDB Streams. 배치 처리
Provisioned Concurrency	Cold Start 제거. 항상 초기화 상태 유지. 비용 발생
Reserved Concurrency	동시성 예약. Cold Start 해결 . 스로틀링 제어
Lambda 멱등성	동일 이벤트 중복 처리 방지. DynamoDB 추적
ECS	AWS 자체 오케스트레이터. 컨트롤 플레인 무료
EKS	관리형 Kubernetes. 멀티 클라우드. 컨트롤 플레인 유료
Fargate	서버리스 컨테이너 컴퓨팅. ECS/EKS 모두 사용 가능
Step Functions Standard	정확히 한 번. 최대 1년. 감사 가능
Step Functions Express	최소 한 번. 5분 제한. 고처리량. 저렴
EventBridge	이벤트 버스. AWS 서비스 연동. SaaS 이벤트 수신
API GW REST vs HTTP	REST: 캐싱/WAF/API Key. HTTP: 저렴/저지연