Lambda 핵심 정리 — SAA-C03 8편 컨테이너·서버리스

이 글은 AWS Certified Solutions Architect Associate(SAA-C03) 스터디 노트 시리즈의 여덟 번째 편입니다. 이 단원을 처음 펼치면 솔직히 좀 막막해요. ECS·EKS·Fargate·Lambda·API Gateway·Step Functions·Cognito… 이름이 비슷비슷한 서비스가 한꺼번에 쏟아지고, 각 서비스마다 또 IAM Role이 두세 개씩 나와서 "이게 다 외워지나?" 싶거든요. 이 단원에서 가장 시험 비중이 큰 주인공이 Lambda라서, 이 글도 Lambda를 중심에 두고 풀어 갑니다.

그런데 한 발 떨어져서 보면 단순합니다. 이 단원의 핵심 질문은 단 하나예요 — "내 코드를 어디에 어떻게 띄울 것인가". 서버를 직접 굴릴 거냐(EC2), 컨테이너로 띄울 거냐(ECS·EKS·Fargate), 아예 함수만 올릴 거냐(Lambda) — 이 세 갈림길을 중심으로 나머지 서비스들이 가지처럼 붙어있는 구조입니다. 이 큰 줄기만 머리에 잡아두면 키워드 매칭이 한결 쉬워져요.

이번 글에선 컨테이너 비유를 자주 쓸 겁니다. 컨테이너는 진짜 "표준 화물 박스" 거든요. 1960년대에 해운업계가 화물 모양과 크기를 표준화한 박스(컨테이너) 덕에 배·트럭·기차 어디든 같은 박스로 옮길 수 있게 됐듯이, Docker 컨테이너도 "이 안에 무엇이 들어있든, 어느 OS·어느 클라우드든 같은 방식으로 띄울 수 있는 표준 박스"입니다. 그래서 ECS도 EKS도 결국 그 박스를 어디에 어떻게 쌓느냐의 이야기예요.

Lambda는 또 다른 비유로 — "주문하면 그때 켜지는 자판기" 같은 서비스입니다. 평소엔 꺼져 있다가 누가 버튼을 누르면 그제서야 켜져서 음료를 내주고, 끝나면 다시 꺼져요. 그래서 안 쓸 땐 돈도 안 들고, 갑자기 100명이 몰려도 자판기가 100대로 자동 복제됩니다. 단점은 — 처음 켤 때 약간 시간이 걸린다는 것(콜드 스타트). 이 비유 하나만 머리에 있어도 Lambda 단원의 절반이 풀려요. 공식 문서가 필요할 땐 Lambda 개발자 가이드를 곁에 두고 보면 됩니다.

자, 천천히 풀어 갑시다.

서버리스와 Lambda란 도대체 뭔가요

"서버리스(Serverless)"라는 단어를 처음 들으면 — "서버가 없다고? 그럼 코드는 어디서 돌지?" 하는 생각이 들죠. 풀어 쓰면 서버가 없는 게 아니라, 우리가 서버를 프로비저닝하거나 관리할 필요가 없다는 뜻입니다. 식당에 비유하자면 — 직원을 고용해서 주방을 직접 굴리는 게 아니라, 배달 앱에 메뉴(코드)만 등록해 두면 주문이 들어올 때마다 누군가가 알아서 만들어 주는 거예요.

서버리스의 핵심 특징은 세 가지입니다.

• 인프라 관리 0 — OS 패치도, 디스크 용량도 신경 안 씁니다
• 자동 확장 — 트래픽이 늘면 알아서 늘고 줄면 알아서 줄어요
• 사용량 기반 과금 — 안 쓰면 돈이 안 나갑니다

전형적인 AWS 서버리스 웹 아키텍처는 이 다섯 줄로 요약됩니다.

정적 콘텐츠: S3 + CloudFront
사용자 인증: Cognito
REST API:   API Gateway
컴퓨팅:     Lambda
데이터베이스: DynamoDB

이 그림이 시험에 가장 자주 나오는 표준 조합이에요. 외워둘 가치가 있습니다.

AWS의 서버리스 서비스 목록도 한 번 정리하고 갑니다.

분류	서비스
컴퓨팅	Lambda, Fargate
컨테이너 오케스트레이션	ECS, EKS
API	API Gateway
데이터베이스	DynamoDB, Aurora Serverless
인증	Cognito
워크플로우	Step Functions
메시징	SNS, SQS, Kinesis

여기서 한 가지 짚어둘 게 — Fargate와 ECS·EKS가 같이 들어있는 이유입니다. ECS·EKS는 "컨테이너를 어떻게 오케스트레이션할 것인가"를 책임지고, Fargate는 "그 컨테이너를 굴릴 서버를 우리가 안 보게 숨겨주는 실행 엔진"이에요. 그래서 Fargate는 서버리스 컴퓨팅이고, ECS·EKS와 합쳐 쓰는 식입니다. 이 부분은 ECS 단락에서 다시 정리할게요.

ECS — 컨테이너를 굴리는 두 가지 방식

ECS(Elastic Container Service) 는 AWS가 만든 컨테이너 오케스트레이션 서비스입니다. 컨테이너를 "어디에 몇 개 띄우고, 죽으면 다시 띄우고, 트래픽 따라 늘리고 줄이는" 일을 자동으로 해 줘요. 회사 비유로 치면 물류 창고 관리자 같은 역할이에요. 화물 박스(컨테이너)를 몇 개 들여놓을지, 어느 선반에 놓을지, 박스가 망가지면 새로 가져올지를 책임지는 사람.

ECS에는 두 가지 시작 유형(Launch Type)이 있어요. 이게 시험 단골이라 표로 정리합니다.

항목	EC2 Launch Type	Fargate Launch Type
인프라 관리	사용자가 EC2 인스턴스 직접 관리	불필요 (서버리스)
ECS Agent	EC2 인스턴스에 설치·실행	불필요
스케일링	EC2 + 용량 공급자(Capacity Provider) 연동	Task 수만 조정
비용	EC2 비용 발생	Task 단위 과금
시험 키워드	세밀한 인프라 제어 필요	"서버리스 컨테이너", "운영 오버헤드 최소화"

비유하자면 — EC2 시작 유형은 "내 창고 건물을 내가 직접 관리한다(전기·청소·경비 다 내가)", Fargate는 "공유 창고에 박스만 맡기고 전기·청소는 회사가 알아서 한다"의 차이예요. 시험에서 "운영 오버헤드 최소화", "서버리스 컨테이너" 같은 키워드가 나오면 무조건 Fargate입니다.

Fargate Spot도 한 번 짚고 갑니다. AWS가 남는 용량을 싸게 풀어 주는 건데, 대신 언제든 회수당할 수 있어요. 그래서 중간에 끊겨도 괜찮은 — 내결함성이 있는 배치 작업에만 써야 합니다. 시험에 "비용 절감 + 중단 허용 배치" 같은 시나리오가 나오면 Fargate Spot이 답.

Task Definition — 컨테이너 실행 청사진

ECS에서 컨테이너 하나를 띄우려면 먼저 Task Definition(작업 정의) 이라는 JSON 문서를 만들어야 합니다. 청사진 같은 거예요. 어떤 Docker 이미지를 쓸지, CPU·메모리는 얼마나 줄지, 포트는 어디로 매핑할지, 어떤 IAM Role을 붙일지, 환경 변수는 뭘지를 적어 둡니다.

여기서 시험 함정이 두 개 있어요.

첫째, Task Definition은 수정하면 새 리비전(버전)이 생깁니다. 기존 것을 덮어쓰지 않아요. v1, v2, v3 이런 식으로 계속 쌓이고, 어느 버전이든 골라서 띄울 수 있습니다.

둘째, Task Definition 자체는 비용이 0원이에요. 그냥 JSON 설정 파일이거든요. 비용은 실제로 컨테이너가 떠 있는 동안만 발생합니다. 그리고 삭제할 땐 Delete가 아니라 Deregister(등록 취소) 라는 표현을 씁니다.

ECS의 IAM Role 셋 — 시험에서 가장 헷갈리는 부분

여기가 ECS 단원에서 가장 함정이 많은 영역이에요. ECS와 관련된 IAM Role이 세 개나 있는데 이름이 다 비슷해서 헷갈립니다. 한 번에 정리하고 갑시다.

역할	누구에게 붙이나	용도
EC2 Instance Profile	EC2 시작 유형의 EC2 인스턴스	ECS 에이전트가 ECS에 인스턴스 등록·ECR Pull·CloudWatch 로그·Secrets Manager 접근
ECS Task Role	Task 단위 (EC2·Fargate 모두)	컨테이너 안의 애플리케이션이 S3·DynamoDB 같은 AWS 서비스 API 호출
Task Execution Role	ECS 에이전트	이미지 Pull(ECR), CloudWatch 로그 전송

가장 헷갈리는 게 Task Role과 Task Execution Role입니다. 회사 비유로 풀면 한 번에 정리돼요.

• Task Role = 택배 박스 안에 들어있는 직원의 사원증. 박스 안에서 일하는 사람(애플리케이션)이 회사(AWS) 다른 부서(S3·DynamoDB)에 가서 일을 처리할 때 쓰는 사원증이에요.
• Task Execution Role = 택배를 옮기는 운송기사의 사원증. 박스 자체를 창고에서 꺼내 오고(ECR Pull), 로그를 어디 보내는(CloudWatch) 등 인프라 작업을 하는 사람의 사원증입니다.

> 한 줄 요약 — 컨테이너 "안의 앱"이 AWS 서비스 접근 → Task Role / 컨테이너를 "굴리는 인프라 작업" → Task Execution Role.

시험 시나리오에서 "컨테이너 안의 애플리케이션이 S3에 파일을 못 올린다, 어디를 고쳐야 하나?" 같은 문제가 나오면 답은 항상 Task Role입니다. "ECR에서 이미지를 못 가져온다, Pull 권한 오류" 같은 문제는 항상 Task Execution Role이고요.

ECS Service와 Auto Scaling

ECS Service는 "이 Task를 항상 N개 띄워둬"라고 관리자에게 말하는 단위입니다. 이걸 원하는 수(Desired Count) 라고 불러요. Task가 죽으면 알아서 새로 띄우고, ALB와 통합되면 컨테이너 IP가 바뀔 때마다 Target Group에 자동 등록·해제도 해 줍니다. 한 AZ에 작업이 몰리지 않게 AZ 리밸런싱도 해 줘요.

ECS Service Auto Scaling은 백엔드로 AWS Application Auto Scaling을 씁니다. 스케일링 지표는 세 가지밖에 안 되니 외워두면 좋아요.

• CPU 사용률
• 메모리(RAM) 사용률
• ALB 대상당 요청 수(ALB Request Count per Target)

스케일링 정책 종류는 셋:

• Target Tracking — 지표를 목표값에 맞춰 유지 (예: CPU 70%)
• Step Scaling — 지표 변화 크기에 따라 단계적
• Scheduled Scaling — 시간 기준 예약

여기서 시험 함정 하나 — EC2 시작 유형에서 Task가 늘어나려는데 EC2 자체가 부족할 때 ECS 클러스터 용량 공급자(Capacity Provider) 가 ASG를 자동 확장합니다. "ECS Task가 늘어나면 EC2도 같이 늘려야 한다"는 시나리오의 정답이 이쪽이에요.

ECS + EventBridge 패턴

ECS 단원에서 자주 등장하는 아키텍처 패턴 네 가지를 압축해서 적어둡니다. 시험에 시나리오로 자주 등장해요.

1. 이벤트 기반 처리: S3 객체 업로드 → EventBridge → Fargate Task → 처리 → DynamoDB 저장
2. 예약 배치: EventBridge Schedule(Cron) → Fargate Task → S3 일괄 처리
3. 대기열 기반 스케일링: SQS 메시지 증가 → ECS Service Auto Scaling
4. 수명 주기 모니터링: ECS Task 상태 변경 → EventBridge → SNS 알림

ECR — Docker 이미지를 보관하는 창고

ECR(Elastic Container Registry) 은 AWS가 운영하는 Docker 이미지 레지스트리예요. Docker Hub의 AWS 버전이라고 보면 됩니다. 프라이빗·퍼블릭 둘 다 쓸 수 있고, 이미지 데이터의 실제 저장 위치는 S3(EBS 아님!)예요. 이게 시험 함정으로 나옵니다.

기능은 — Push 시 자동 취약점 스캔, 이미지 태그 버전 관리, 오래된 이미지 자동 삭제(Lifecycle), 리전 간 복제. 모든 접근은 IAM으로 제어됩니다.

여기서 시험 함정이 하나 있어요 — ECS에서 ECR Pull 권한 오류가 나면, 정답은 거의 항상 Task Execution Role의 IAM 정책 확인입니다. 컨테이너를 굴리는 인프라 작업이라서 그래요.

ECS 스토리지 — Fargate + EFS가 황금 조합

ECS에서 영구 스토리지가 필요할 땐 EFS(Elastic File System) 를 쓰는 게 정답입니다. 특히 Fargate + EFS 조합이 시험 단골이에요.

이유를 풀어 보면 — Fargate(서버리스 컴퓨팅) + EFS(서버리스 스토리지) 가 만나면 인프라 관리가 완전히 0이 됩니다. 게다가 EFS는 Multi-AZ에서 여러 ECS Task가 동일한 데이터를 공유할 수 있어요. 반면 EBS는 특정 EC2 인스턴스에 묶여 있어서 다중 Task 공유가 안 됩니다.

> 시험에 "Fargate에서 여러 Task가 같은 데이터를 공유해야 한다"가 나오면 답은 항상 EFS.

EKS — 쿠버네티스를 AWS에서

EKS(Elastic Kubernetes Service) 는 AWS가 관리해 주는 Kubernetes 클러스터입니다. 여기서 ECS와의 결정적인 차이를 짚어둘게요.

• ECS = AWS가 만든 독자적인 오케스트레이터 (AWS 안에서만 동작)
• EKS = 오픈소스 표준 Kubernetes (어디서나 동작)
• 컨테이너 단위 이름이 다릅니다 — ECS는 Task, EKS는 Pod

> 시험에서 "Pod"라는 단어가 나오면 무조건 EKS입니다. 단순한 매칭이지만 함정 보기에 자주 끼어 있어요.

언제 EKS를 쓰냐면 — 이미 온프레미스나 다른 클라우드(Azure GCP)에서 Kubernetes를 쓰고 있을 때, 또는 클라우드 종속성(Vendor lock-in)을 피하고 싶을 때입니다. 회사 비유로 — ECS는 AWS 전용 부서 시스템이고, EKS는 ISO 표준 시스템이라 다른 회사로 이직할 때도 그대로 가져갈 수 있는 거예요.

EKS의 노드 타입(워커 노드를 어디에 띄울지)은 세 가지입니다.

타입	설명	특징
Managed Node Groups	AWS가 EC2 워커 노드 생성·관리	ASG 자동, 온디맨드·스팟 지원
Self-Managed Nodes	사용자가 직접 EC2 생성 후 등록	Custom AMI 등 더 많은 제어권
AWS Fargate	서버리스 컨테이너 실행	노드 프로비저닝 불필요

EKS Anywhere는 자체 인프라(온프레미스)에서 EKS를 굴리는 옵션이고, EKS Distro는 EKS가 쓰는 Kubernetes 배포판을 오픈소스로 풀어 놓은 거예요. 시험에 가끔 보기로 나오는 정도라 이름만 알아두면 됩니다.

EKS의 IAM Role도 두 개 있는데 — 클러스터 역할(Service Role) 은 EKS 컨트롤 플레인이 VPC·로드 밸런서 같은 AWS 리소스를 관리할 때 쓰고, 워커 노드 역할(Worker Node Role) 은 EC2 노드가 클러스터에 등록하고 다른 서비스와 통신할 때 씁니다. 워커 노드 역할에 붙는 필수 정책은 AmazonEKSWorkerNodePolicy와 AmazonEC2ContainerRegistryReadOnly예요.

EKS 스토리지와 시험 함정

EKS에서 볼륨을 붙이려면 CSI(Container Storage Interface) 드라이버를 써야 합니다. 시험 키워드로 자주 나와요. 지원 스토리지는 EBS·EFS·FSx for Lustre·FSx for NetApp ONTAP인데, 여기서 결정적인 함정 하나가 있어요.

> EKS Fargate에서는 EFS만 지원됩니다. EBS는 사용 불가.

이유를 풀어 보면 — Fargate는 서버리스라 특정 노드에 묶이지 않는데, EBS는 본질적으로 한 인스턴스에 붙는 블록 스토리지라서 안 맞아요. 반면 EFS는 네트워크 파일 시스템이라 어디서든 마운트할 수 있고요.

마지막으로 EKS 리소스 삭제 순서 — 반드시 노드 그룹(또는 Fargate 프로필)을 먼저 삭제하고 그 다음에 클러스터를 삭제해야 합니다. 순서가 거꾸로 가면 안 지워져요.

Lambda — 호출하면 그때 켜지는 자판기

이제 서버리스의 꽃 Lambda입니다. 도입부에서 비유한 것처럼 — 주문하면 그때 켜지는 자판기예요. 이벤트가 들어오면 그때 함수가 실행되고, 끝나면 꺼집니다. 평소엔 비용이 0이고, 트래픽이 갑자기 100배가 돼도 자판기가 100대로 자동 복제돼요.

Lambda의 특징을 한 줄로 요약하면:

• 서버리스 — 프로비저닝·관리 0
• 이벤트 기반 — 이벤트 발생 시에만 실행
• 자동 스케일링 — 요청 늘면 인스턴스 자동 추가
• 과금 — 호출 횟수 + 실행 시간(밀리초 단위), 안 쓰면 비용 0
• 프리티어 — 월 100만 건 호출, 40만 GB-초 무료

Lambda의 한도 — 시험 단골

Lambda는 한도가 명확합니다. 한도가 있다는 건 — 그 한도를 넘는 작업은 Lambda로 못 한다는 시나리오 문제로 출제된다는 뜻이에요.

항목	제한
메모리(RAM)	최소 128MB ~ 최대 10GB
최대 실행 시간(Timeout)	최대 900초 (15분)
동시 실행(Concurrency)	리전당 기본 1,000개 (증설 신청 가능)
/tmp 임시 스토리지	최대 10GB
환경 변수	최대 4KB
배포 패키지	압축 50MB / 압축 해제 250MB
컨테이너 이미지	최대 10GB

> Lambda 사용 불가 시나리오 — 실행 시간 20분 이상, RAM 30GB 이상, 패키지 300MB 이상. 이런 키워드가 나오면 ECS Fargate로 풀어야 합니다.

여기서 시험에 정말 자주 나오는 함정 하나 짚고 갑니다.

지원 언어는 — 기본 제공이 Node.js·Python·Java·C#/.NET·Ruby·PowerShell, 사용자 지정 런타임(Custom Runtime) 으로 Rust·Go도 가능, 컨테이너 이미지로 띄우면 사실상 어떤 언어든 됩니다(최대 10GB).

Lambda Layer는 여러 함수에서 공통으로 쓰는 라이브러리·런타임을 재사용 가능한 형태로 묶어 두는 기능이에요. 100개 함수에 같은 라이브러리를 매번 패키징하지 말고 Layer 하나에 넣어 두면 끝.

Lambda 트리거 — 누가 자판기 버튼을 누르나

Lambda의 매력은 거의 모든 AWS 서비스가 트리거가 될 수 있다는 점이에요. 자주 나오는 것들:

• API Gateway — REST API 호출
• S3 — 객체 업로드/삭제 시 (예: 썸네일 자동 생성)
• DynamoDB Streams — 테이블 변경 감지
• Kinesis Data Streams — 스트림 처리
• SQS — 메시지 처리(폴링 방식)
• ALB — HTTP/HTTPS 요청
• EventBridge / CloudWatch Events — 주기적 실행(서버리스 CRON), 인프라 상태 변경
• SNS — 알림 반응
• Cognito — 사용자 로그인 이벤트

Lambda Destinations도 알아두면 좋아요 — 비동기 호출의 성공/실패 결과를 다른 서비스로 라우팅합니다. 성공 시·실패 시 모두 SQS·SNS·Lambda·EventBridge로 보낼 수 있어요. 실패 라우팅이 DLQ(Dead Letter Queue) 역할을 합니다.

동시성 — 자판기를 몇 대까지 띄울 거냐

Lambda 동시성(Concurrency)은 처음 보면 헷갈리는데 세 가지로 정리하면 끝납니다.

개념	설명
기본 동시성	리전 내 모든 함수가 최대 1,000개 공유
Reserved Concurrency	특정 함수가 사용할 동시성을 할당 + 제한. 다른 함수 보호. 0으로 설정 시 항상 스로틀링(테스트 용도)
Provisioned Concurrency	함수 호출 전에 실행 환경 미리 초기화 → 콜드 스타트 방지, 추가 비용 발생

비유하자면 — 자판기 100대가 한 빌딩(리전)에서 자원을 공유하고 있는데:

• Reserved Concurrency = "이 음료 자판기는 무조건 30대까지만 보장한다 + 30대 넘으면 못 받는다"는 칸막이
• Provisioned Concurrency = "이 자판기는 항상 미리 켜 두고 따뜻하게 데워 둔다"는 옵션

여기서 시험 함정 하나 — Provisioned Concurrency는 $LATEST 버전에 설정 못 합니다. 반드시 게시된 버전(Version) 또는 별칭(Alias)에만 적용돼요.

스로틀링과 콜드 스타트

Lambda가 한도를 넘으면 어떻게 되냐 — 두 가지로 갈립니다.

• 동기 호출(API Gateway 같은 것) → 즉시 429 Too Many Requests 반환
• 비동기 호출(S3 이벤트 같은 것) → 내부 큐에 저장하고 최대 6시간 재시도(지수 백오프 1초~5분), 최종 실패 시 DLQ

콜드 스타트(Cold Start) 는 Lambda 함수가 한참 안 돌다가 갑자기 호출됐을 때 — 자판기 전원이 꺼져 있다가 켜지는 그 순간 — 실행 환경을 새로 띄우느라 첫 요청이 느려지는 현상입니다. 해결책 두 가지:

방법	설명	비용
Provisioned Concurrency	미리 초기화된 환경 유지	추가 비용 발생
Lambda SnapStart	새 버전 발행 시 초기화 상태를 스냅샷으로 저장 → 호출 시 즉시 로드. Java·Python·.NET 지원	추가 비용 없음

> 시험 키워드 — "콜드 스타트 + 추가 비용 없음" → SnapStart / "콜드 스타트 + 일관된 낮은 지연" → Provisioned Concurrency.

Lambda in VPC와 RDS Proxy 패턴

기본적으로 Lambda는 AWS가 소유한 VPC에서 실행됩니다. DynamoDB나 퍼블릭 API는 그대로 접근할 수 있는데, 프라이빗 RDS·ElastiCache 같은 VPC 내부 자원에는 못 들어가요.

이때는 Lambda를 VPC 내부에 배포해야 합니다. VPC ID·서브넷·보안 그룹을 지정하면, Lambda 함수가 호출될 때 해당 서브넷에 ENI(Elastic Network Interface) 가 생기면서 VPC 안 자원에 접근할 수 있게 돼요.

여기서 시험 단골 패턴이 Lambda + RDS Proxy입니다.

문제 상황을 한 번 풀어 봅시다. Lambda가 자동 확장되면 함수 인스턴스가 100개·1,000개씩 늘어나는데, 각 인스턴스가 RDS에 직접 연결을 만들면 — RDS의 연결 한도를 금방 다 써버립니다(연결 고갈). 자판기 1,000대가 동시에 같은 콘센트에 플러그를 꽂는 격이에요.

해결은 RDS Proxy입니다. Lambda ↔ RDS Proxy ↔ RDS 구조로, RDS Proxy가 중간에서 연결을 풀링해 줘요. RDS Proxy가 주는 세 가지 이점:

1. 확장성 — 연결 풀링으로 연결 고갈 방지
2. 가용성 — Failover 시간 최대 66% 단축
3. 보안 — IAM 인증 강제 + 자격 증명을 Secrets Manager에 저장

여기서 결정적인 함정 — RDS Proxy는 퍼블릭 액세스가 안 됩니다. 그래서 Lambda를 반드시 VPC 내부에 배포해야 해요.

Lambda@Edge vs CloudFront Functions

이 둘은 CloudFront 엣지에서 코드를 돌리는 두 가지 방법인데, 비교 표가 시험 단골이에요. 그대로 외워둘 가치가 있습니다.

구분	CloudFront Functions	Lambda@Edge
지원 언어	JavaScript	Node.js, Python
트리거 위치	뷰어 요청, 뷰어 응답 (2곳)	4곳 모두 (뷰어 + 오리진 요청/응답)
최대 실행 시간	1ms 미만	5~10초
확장성	초당 수백만 요청	초당 수천 요청
외부 네트워크 접근	불가	가능 (AWS SDK·서드파티 API)
HTTP Body 접근	불가	가능
배포 위치	CloudFront에서 직접 관리	us-east-1에서 작성 후 글로벌 복제

> 시험 키워드 매칭 — "1ms 미만, 수백만 건, 단순 헤더/URL 변경" → CloudFront Functions / "외부 API 호출, DB 접근, 오리진 요청/응답 수정" → Lambda@Edge / "Lambda@Edge 배포 리전" → 무조건 us-east-1.

API Gateway — Lambda 앞에 세우는 문지기

API Gateway는 외부 클라이언트(브라우저·모바일 앱)와 백엔드(Lambda·HTTP·AWS 서비스) 사이에 서서 요청을 받아 주는 완전 관리형 게이트웨이입니다. 회사 비유로 치면 로비의 안내 데스크예요. 누가 와서 어느 부서로 갈지, 인증 확인은 됐는지, 한 번에 너무 많이 요청하지는 않는지 — 이런 걸 1차로 거르는 곳입니다.

주요 기능 — 인증/권한 부여, 속도 제한(Throttling), 캐싱, 버전 관리, Swagger/OpenAPI 지원, 요청/응답 변환.

API 유형 셋

유형	특징	사용 사례
REST API	풍부한 기능 (캐싱·WAF·사용량 계획)	대부분의 일반 REST API
HTTP API	저비용·저지연·단순	Lambda Proxy, HTTP Proxy
WebSocket API	양방향 실시간 통신	채팅, 스트리밍 대시보드

통합 타입

API Gateway가 백엔드와 연결되는 방식이에요.

• Lambda Proxy — 전체 HTTP 요청을 Lambda event 객체로 그대로 전달. Lambda는 {statusCode, headers, body} JSON 반환 필수
• HTTP — 온프레미스/클라우드의 HTTP 엔드포인트와 통합 (기존 API에 캐싱·속도 제한 추가 가능)
• Mock — 백엔드 없이 가짜 응답 (테스트용)
• AWS Service 직접 통합 — Lambda 없이 SQS·Kinesis·Step Functions 같은 AWS 서비스에 직접 데이터 전달
• VPC Link — VPC 내 프라이빗 리소스와 통합

> "Lambda 없이 SQS/Kinesis로 직접" 키워드가 나오면 답은 AWS Service 직접 통합.

엔드포인트 유형 셋

유형	대상	특징
Edge-Optimized(기본값)	글로벌 클라이언트	CloudFront 엣지 활용, 지연 시간 최소화
Regional	동일 리전 클라이언트	자체 CloudFront 연결 가능, 캐싱·라우팅 직접 제어
Private	VPC 내부에서만 접근	Interface VPC Endpoint(ENI) 사용, 리소스 정책으로 접근 제어

Stages·Throttling·Usage Plans

리소스/메서드를 만들거나 수정한 다음에는 반드시 스테이지(Stage)에 배포(Deploy) 해야 실제 URL에 반영됩니다. 스테이지는 dev·test·prod 같은 환경 분리 용도예요. Canary Deployment로 일부 트래픽(예: 5%)만 새 버전으로 보내는 점진적 배포도 가능합니다.

Throttling은 계정 레벨에서 기본 초당 10,000 RPS 제한이고, 초과 시 429 반환. 스테이지·메서드·클라이언트별로 더 세분화할 수도 있어요.

Usage Plans + API Keys는 클라이언트별 접근 제어와 사용량 제한을 위한 거예요. API Key를 발급해서 Usage Plan에 연결하면, "이 클라이언트는 월 10만 요청까지" 같은 제한을 걸 수 있습니다.

CORS는 다른 도메인에서 API 호출할 때 활성화 필요, Preflight 요청에 OPTIONS 응답 필수.

보안 — 세 가지 인증 방식

방식	사용 대상	설명
IAM Authorization	AWS 내부 서비스, EC2, Lambda	Sig v4 서명
Lambda Authorizer (Custom Authorizer)	자체 인증 로직, 서드파티 토큰 검증	Lambda 함수가 토큰 검증 후 IAM 정책 반환
Cognito User Pools	외부 웹/모바일 앱 사용자	Cognito에서 토큰 검증, API GW에서 직접 통합

마지막으로 API Gateway 최대 타임아웃은 29초(하드 리밋) 입니다. Lambda 최대 실행 시간이 15분이라 헷갈리기 쉬운데 — Lambda가 29초 넘게 걸리면 API Gateway가 먼저 504를 반환해 버려요. API Gateway 29초 vs Lambda 15분, 이거 꼭 구분해 두세요.

DynamoDB — 5편에서 다룬 거 서버리스 맥락 보강

DynamoDB는 5편에서 자세히 다뤘으니, 여기선 서버리스 맥락에서 시험에 자주 나오는 핵심만 짚습니다.

• 단일 항목(Item) 최대 크기 — 400KB
• 용량 모드 — Provisioned(예측 가능, 저렴) / On-Demand(예측 불가, 단가 2~3배)
• DAX — 마이크로초 인메모리 캐시, 애플리케이션 코드 변경 X(DynamoDB API 호환), 기본 TTL 5분
• DynamoDB Streams — 변경 캡처, 보존 24시간, Lambda 트리거 가능, Kinesis 통합 시 1년
• Global Tables — Active-Active 멀티 리전, Streams 활성화가 필수 조건
• TTL — 만료된 항목 자동 삭제, 추가 비용 X
• PITR — 최근 35일 시점 복구, 복구는 항상 새 테이블 생성(기존 덮어쓰지 않음)
• S3 Export — PITR 활성화 필요, 성능 영향 X, JSON·ION 형식

> 키워드 매칭 — "예측 불가 트래픽" → On-Demand / "마이크로초 + 코드 변경 X" → DAX / "글로벌 멀티 리전 Active-Active" → Global Tables (Streams 필수) / "오래된 데이터 자동 삭제" → TTL.

Step Functions — Lambda 워크플로우를 그림으로

여러 Lambda 함수를 순서대로 호출하고, 실패하면 재시도하고, 중간에 사람 승인을 받아야 한다면 — Lambda 코드 안에서 다 처리하기엔 복잡합니다. 이걸 시각적인 워크플로우(상태 머신) 로 그려서 관리하는 게 Step Functions예요. 회사 비유로 — 결재 라인 시각화 도구 같은 겁니다.

JSON 기반 상태 머신으로 워크플로우를 정의하고, 각 단계의 성공/실패에 따라 다음 단계가 결정돼요. 주요 기능:

• 시퀀싱 — 작업 순서 지정
• 병렬(Parallel) — 여러 작업 동시 실행
• 조건 분기(Choice) — 조건에 따른 분기
• 타임아웃·에러 처리 — 재시도(Retry), 대체 경로(Catch)
• 수동 승인(Human Approval) — 워크플로우 중간에 사람 개입 단계

통합 대상 — Lambda·EC2·ECS Tasks·온프레미스·API Gateway·SQS 등.

워크플로우 종류 두 가지가 시험 단골이에요.

항목	Standard Workflows	Express Workflows
최대 실행 기간	1년	5분
실행 모델	Exactly-once	At-least-once
속도	초당 2,000 실행	초당 100,000 실행
비용	상태 전환 수에 따라	실행 기간·횟수에 따라
사용 사례	주문 처리, 장시간 비즈니스 프로세스	이벤트 처리, 스트리밍, 마이크로서비스

> 시험 키워드 — "시각적 워크플로우, 오케스트레이션, 상태 머신, 여러 Lambda 순서, 수동 승인" → Step Functions.

Cognito — 외부 사용자 인증 전담

IAM은 회사 내부 사람을 관리하는 거였고, Cognito는 회사 밖 일반 사용자(수만~수십만의 모바일 앱·웹 사용자)를 관리하는 서비스입니다. IAM과 Cognito를 헷갈리지 않게 한 줄로 정리하면 — IAM은 사내 직원, Cognito는 외부 고객.

Cognito는 두 가지로 나뉘는데, 이름이 비슷해서 헷갈려요.

서비스	역할	주요 통합	사용 시나리오
User Pools (사용자 풀)	서버리스 사용자 DB + 인증(Authentication) → JWT 토큰 발급	API Gateway, ALB	회원가입·로그인·MFA·소셜 로그인
Identity Pools (자격 증명 풀)	임시 AWS 자격 증명 발급 → AWS 리소스 직접 접근 권한	S3, DynamoDB	모바일 앱에서 S3 직접 업로드, DynamoDB 행 수준 보안

비유하면 — User Pools는 "이 사람이 우리 회원이 맞나" 확인하고 회원증(JWT 토큰)을 발급하는 데스크. Identity Pools는 그 회원증으로 "AWS 회사 내 일부 자원에 접근할 수 있는 임시 출입증(STS 자격 증명)"을 바꿔 주는 데스크예요.

DynamoDB 행 수준 보안이 시험에 단골로 나옵니다 — 사용자가 본인 데이터만 보게 하려면, Identity Pools의 IAM 정책 Condition에 DynamoDB 파티션 키 == Cognito 사용자 ID 를 걸어 두면 됩니다.

> 키워드 매칭 — "모바일 앱 로그인·MFA" → User Pools / "S3·DynamoDB 직접 접근, 임시 자격 증명" → Identity Pools / "DynamoDB 행 수준 보안" → Identity Pools + IAM 정책 조건.

App Runner·App2Container·SAM·AppSync

마지막으로 시험에 가끔 등장하는 보조 서비스들을 짧게 정리하고 갑시다.

App Runner — 소스 코드(GitHub)나 Docker 이미지(ECR)에서 자동 빌드·배포해 주는 완전 관리형 서비스. 로드 밸런서·Auto Scaling·기본 도메인을 자동 프로비저닝해 줘요. Auto Scaling 기준은 인스턴스당 동시 요청 수입니다. VPC 내 RDS·ElastiCache 접근 가능, X-Ray 통합. 시험 키워드 — "인프라 관리 없음, 가장 빠르고 간단한 컨테이너/소스코드 배포" → App Runner.

App2Container(A2C) — 온프레미스의 Java/.NET 웹 앱을 코드 변경 없이 Docker 컨테이너로 마이그레이션하는 CLI 도구. Lift-and-Shift 방식이에요. 생성되는 아티팩트 — Docker 이미지(ECR), CloudFormation, ECS Task 정의, EKS Pod 정의, CI/CD 파이프라인. 배포 대상은 ECS·EKS·App Runner.

SAM(Serverless Application Model) — 서버리스 앱을 정의·배포하는 오픈소스 프레임워크. CloudFormation 위에서 동작하는 간소화된 문법이고, YAML/JSON으로 Lambda·API Gateway·DynamoDB를 한 번에 정의해요. 로컬에서 sam local invoke로 테스트도 됩니다.

AppSync — AWS 관리형 GraphQL API 서비스. 실시간 데이터 동기화·오프라인 데이터 접근 지원, DynamoDB·Lambda·OpenSearch 등과 통합.

ECS·EKS·Lambda 한 번에 모아놓고 보는 비교표 셋

ECS EC2 vs ECS Fargate vs EKS

항목	ECS EC2	ECS Fargate	EKS
인프라 관리	사용자가 EC2 관리	불필요 (서버리스)	노드 그룹 또는 Fargate
컨테이너 단위	Task	Task	Pod
오케스트레이션	AWS 독점	AWS 독점	오픈소스 Kubernetes
기존 K8s 호환	X	X	O
클라우드 독립성	X	X	O
비용	EC2 비용	Task 단위	노드 EC2 또는 Fargate

Lambda vs EC2

항목	Lambda	EC2
서버 관리	불필요	필요
실행 방식	이벤트 기반 (On-demand)	지속 실행
최대 실행 시간	15분	무제한
최대 메모리	10GB	인스턴스 타입에 따라 수백 GB
스케일링	자동 (동시성 기반)	Auto Scaling Group 필요
비용	실행 시에만 과금	실행 중 항상 과금
적합 시나리오	불규칙·짧은·이벤트 기반	장시간·예측 가능 트래픽

API Gateway 3종

항목	REST API	HTTP API	WebSocket API
기능	풍부 (캐싱·WAF·사용량 계획)	단순·저비용	양방향 실시간
비용	상대적으로 높음	저렴	-
지연 시간	높음	낮음	-
사용 사례	범용 REST API	Lambda/HTTP Proxy	채팅·실시간 알림

시험 직전 한 번 더 — 자주 헷갈리는 함정 모음

여기까지가 컨테이너·서버리스 영역의 핵심입니다. 시험 직전에 다시 펼쳐 볼 압축 노트를 마지막에 박아 둘게요.

ECS·ECR·EKS — 컨테이너 영역

• Pod = EKS, Task = ECS (단순하지만 함정 보기에 자주 끼어 있음)
• ECS — 컨테이너 안의 앱 권한 = Task Role / 인프라 작업(이미지 Pull·로그) = Task Execution Role
• ECS EC2 시작 유형은 EC2 Instance Profile 추가 필요
• Fargate + 공유 영구 스토리지 + Multi-AZ = EFS (EBS 불가)
• "비용 절감 + 중단 허용 배치" = Fargate Spot
• ECR 데이터 실제 저장 위치 = S3 (EBS 아님)
• ECR Pull 권한 오류 → Task Execution Role IAM 확인
• EKS Fargate 유일 스토리지 = EFS만, EKS 스토리지 인터페이스 = CSI 드라이버
• EKS 삭제 순서 — 노드 그룹 먼저, 클러스터 나중

Lambda — 동시성·콜드 스타트·VPC

• Lambda 최대 실행 시간 = 15분, 메모리 = 128MB ~ 10GB
• Lambda CPU 향상 방법 = 메모리(RAM) 증가 (CPU 직접 설정 불가)
• Lambda 15분 초과 작업 → ECS Fargate로 풀기
• 콜드 스타트 — Provisioned Concurrency(추가 비용) / SnapStart(비용 X, Java·Python·.NET)
• Provisioned Concurrency는 $LATEST에 못 붙임 — 게시된 버전·별칭에만
• Reserved Concurrency = 0 → 항상 스로틀링(테스트 용도)
• Lambda 동기 호출 스로틀링 → 429 즉시 / 비동기 → 6시간 재시도 후 DLQ
• Lambda + RDS 연결 고갈 → RDS Proxy + Lambda VPC 배포 필수
• Lambda@Edge 배포 = us-east-1, 4곳 모두 트리거 / CloudFront Functions = JS·1ms·뷰어 2곳만

API Gateway·DynamoDB·Step Functions

• API Gateway 최대 타임아웃 = 29초 (Lambda 15분과 헷갈리지 말기)
• Edge-Optimized ACM = us-east-1 / Regional ACM = 동일 리전
• API Gateway 계정 레벨 Throttling = 10,000 RPS
• "Lambda 없이 SQS/Kinesis로 직접" → API Gateway AWS Service 직접 통합
• DynamoDB 단일 항목 = 400KB, Global Tables 필수 = Streams 활성화
• DAX = 마이크로초 캐시, 코드 변경 X(DynamoDB API 호환)
• DynamoDB 복구 = 항상 새 테이블 생성
• "시각적 워크플로우 + 수동 승인" = Step Functions (Standard 1년 / Express 5분)

Cognito·App Runner·App2Container

• "외부 모바일 앱 로그인, 수만 사용자" = Cognito (IAM 아님)
• User Pools = 인증·JWT·API Gateway/ALB / Identity Pools = 임시 AWS 자격 증명·S3/DynamoDB 직접
• DynamoDB 행 수준 보안 = Identity Pools + IAM 정책 Condition
• "가장 빠르고 간단한 컨테이너/소스 배포" = App Runner
• "Java/.NET 코드 변경 없이 컨테이너 마이그레이션" = App2Container

마무리 한 줄

여기까지가 SAA-C03 컨테이너·서버리스 영역의 전부예요. 이 단원은 키워드 매칭이 가장 명확한 영역이라 한 번 함정만 잘 정리해 두면 시나리오 문제에서 빠르게 점수를 가져갈 수 있습니다. 특히 ECS의 Task Role vs Execution Role, Lambda의 Reserved vs Provisioned Concurrency, API Gateway의 ACM 리전 함정 — 이 셋은 표를 손으로 한 번 더 그려보면서 머리에 새겨두면 시험장에서 1~2초 만에 답이 떠오를 거예요. 추가로 API Gateway 개발자 가이드도 한 번씩 참고하면 도움이 됩니다.

다음 글(9편)에서는 CloudWatch·CloudTrail·Config·X-Ray 같은 모니터링·감사 영역을 정리합니다. SAA에서 운영 시나리오로 자주 출제되는 단원이라, 컨테이너·서버리스로 뭘 만들어 놓고 어떻게 관찰할 것인가 — 그 후속편이라고 보시면 돼요.

시리즈 다른 편

같은 시리즈의 다른 글들도 같은 친절 톤으로 묶어 정리되어 있어요.

• 1편 — IAM
• 2편 — EC2 / Storage
• 3편 — ELB · ASG
• 4편 — S3 (스토리지)
• 5편 — Databases
• 6편 — Networking
• 7편 — Messaging
• 8편 — Containers · Serverless (현재 글)
• 9편 — Monitoring
• 10편 — Analytics · ML
• 11편 — Security
• 12편 — DR · Migration
• 13편 — Architectures
• 14편 — Exam Prep (완)