(Stephane Maarek의 Udemy AWS Certified Solutions Architect Associate 강의를 참고했습니다.)
우선 서버리스의 개념부터 정리해보자. 서버리스 서비스를 사용하는 개발자는 서버를 관리할 필요가 없다. 이것이 서버가 없다는 것을 의미하지는 않는다. 서버가 보이지 않거나 서버를 프로비저닝하지 않는 것을 의미한다. 그들은 그저 코드, 즉 함수를 배포하는 것이다. 따라서 본래 서버리스는 FaaS(Function as a Service)를 뜻했지만 지금은 더 많은 내용을 포함한다.
서버리스가 처음 개발된 건 AWS Lambda에서 였는데, 현재는 데이터베이스, 메시징, 스토리지 등 서버를 프로비저닝하지 않는 원격 관리되는 모든 것을 포함한다. AWS에서의 서버리스 서비스는 Lambda, DynamoDB, Cognito, API Gateway, S3, SNS&SQS, Kinesis Data Firehose, Aurora Serverless, Step Functions, Fargate가 있다. 이번 챕터에서는 그동안 다루지 않았던 Lambda, DynamoDB, Cognito, API Gateway에 대해 다뤄보도록 하겠다.
1. AWS Lambda
Lambda는 AWS의 대표적인 서버리스 서비스이다. EC2와 비교해보자면, EC2는 클라우드의 가상 서버로 프로비저닝할 메모리와 CPU의 양에 제한이 있다. 지속적으로 실행되며, 확장을 원한다면 ASG(Auto Scaling Group)를 사용할 수 있다. 즉, 서버를 자동으로 추가 및 제거하기 위해 무언가를 해야 한다.
반면, Lambda는 이러한 것들이 가상 함수이다. 즉, 코드만 준비하면 관리할 서버가 없다. 시간에 제한이 있어 최대 15분까지의 짧은 실행을 지원하며 가장 큰 차이점은 On-demand 방식과 자동 스케일링을 지원한다는 것이다. 연산 시간과 요청에 따른 지불 방식을 지원하며, 프리티어에서는 백만 개의 Lambda 요청과 40만 GBs의 연산 시간을 제공한다. 가격은 매우 저렴하다. 또한 Lambda는 많은 다른 AWS 서비스와 통합되어 있으며, Node.js, Python, Java, Powershell 등 여러 프로그래밍 언어를 지원한다. CloudWatch를 통해 쉽게 모니터링할 수 있고, 함수 당 최대 10GB의 RAM을 지원받을 수 있다. 이때, RAM 용량을 늘리면 CPU와 네트워크의 품질과 성능도 향상된다.
Lambda Runtime API를 구현하여 컨테이너 이미지를 실행할 수도 있는데, 도커 이미지 실행 시에는 Lambda보다 ECS나 Fargate를 사용하는 것이 권장된다.
Lambda의 한도
Lambda는 리전 별로 한도가 존재한다. 한도에는 실행 한도와 배포 한도가 있다.
람다를 실행하면 메모리 할당량은 128MB~10GB이고, 메모리는 1MB씩 증가한다. 그리고 메모리가 증가하면 더 많은 vCPU가 필요하다. 최대 실행 시간은 900초(15분)이며, 이를 초과하면 람다 실행에 적합하지 않다고 볼 수 있다. 환경 변수는 4KB까지 가능하며, 큰 파일을 가져올 때 사용할 수 있는 임시 공간이 있다. 이 공간은 /tmp 폴더에 있으며, 최대 10GB이다. 람다 함수는 최대 1000개까지 동시 실행이 가능하며, 요청 시 증가할 수 있지만 동시성은 예약하는 것이 좋다.
배포 한도를 살펴보면, 압축 시 최대 크기는 50MB, 압축하지 않았을 때 250MB이며, 이를 초과하는 경우 /tmp 경로에 있는 임시 공간을 이용해야 한다. 배포 시 환경변수의 한도는 4KB이다.
Lambda SnapStart
람다 함수의 성능을 높이기 위한 람다의 기능으로, Java, Python, .Net 런타임에서 실행되는 람다 함수들을 추가 비용 없이 최대 10배까지 성능을 높여준다. 기존 람다는 새로운 실행 환경이 필요할 때마다 초기화 과정, 즉 Cold Start를 거친다. SnapStart는 이 초기화 과정을 한 번만 수행하고 저장(snapshot) 해두었다가 이후 바로 복원하여 실행한다.
동작 과정을 살펴보면, 함수의 새로운 버전을 Publish하면 AWS가 먼저 함수를 초기화한다. 메모리 상태, 디스크 상태, 객체 등 초기화가 끝난 시점의 상태를 저장하고, 해당 Snapshot은 AWS에서 빠르게 접근할 수 있도록 캐시에 저장한다. 이후 함수 호출 시 Snapshot을 복원하여 빠른 응답 속도를 가져간다.
Lambda@Edge와 CloudFront Functions
일반적으로 함수와 애플리케이션을 특정 리전에서 배포하지만, 현대의 많은 애플리케이션들에서 몇 가지 로직은 앱에 도달하기 전 엣지에서 실행하도록 요구하기도 한다. 이를 엣지 함수(Edge Function)라 부르며, CloudFront Distribution에 연결하여 엣지 로케이션에서 실행되는 코드로 사용자와 가까운 엣지에서 실행하여 지연 시간을 최소화하는 것이 목적이다. 완전한 서버리스이며, 사용량 기반 요금 정책과 글로벌 배포 자동화를 지원한다.
CloudFront는 CloudFront Functions와 Lambda@Edge 2가지 방식의 엣지 함수를 제공한다. CloudFront Functions는 CloudFront에 내장된 JavaScript 기반 초경량 엣지 함수이며, 간단한 요청과 응답 수정 작업을 매우 빠르게 수행하도록 설계되었다. 1ms 미만 수준의 매우 빠른 시작 시간을 보이며, 초당 수백만 건을 처리할 수 있다. 지연 시간이 매우 중요한 CDN 작업에 적합하다. CloudFront가 사용자와 소통하는 Viewer Request와 Viewer Response 단계에서만 실행된다. 사용 예시는 캐시 키 정규화, HTTP 요청 또는 응답의 헤더 조작, URL 재작성 또는 리다이렉트, 요청 인증 및 권한 부여, JWT 토큰 생성 및 검증 등이다.
Lambda@Edge는 람다를 CloudFront Edge Location에서 실행하는 기능으로, CloudFront Functions보다 훨씬 강력하며 복잡한 비즈니스 로직을 수행할 수 있다. Node.js와 파이썬 기반으로 초당 수천 건 정도의 요청을 처리하며 하나의 AWS 리전에서 작성하면 CloudFront가 전 세계 엣지 로케이션으로 자동 복제한다. CloudFront의 모든 단계, 즉 사용자와 Origin과 통신하는 Viewer Request/Response, Origin Request/Response에서 실행 가능하다. 사용 예시는 더 긴 실행 시간이 필요한 작업, CPU 및 메모리 조정이 필요한 작업, 외부 라이브러리 사용 작업, 네트워크를 통해 접근하여 데이터를 처리하거나 파일 시스템 혹은 HTTP 요청 본문을 읽고 처리하는 작업 등이 있다.
VPC 내의 람다
기본적으로 람다 함수를 시작하면 VPC 외부에서 시작된다. 람다는 VPC 내의 리소스에 액세스할 권한이 없다. 이를 해결하기 위해서는 VPC에서 람다 함수를 시작해야 한다. VPC ID와 서브넷, 보안 그룹을 정의하면, 람다는 ENI(Elastic Network Interface)를 서브넷 안에 생성하여 VPC 내 모든 항목에 비공개로 연결할 수 있다.
2. Dynamo DB
DynamoDB는 AWS에서 제공하는 완전관리형 NoSQL 데이터베이스 서비스이다. 서버를 직접 설치하거나 관리할 필요 없이 AWS가 인프라 운영을 담당하며, 매우 높은 성능과 확장성을 제공한다. 관계형 데이터베이스와 달리 유연한 스키마를 지원하며, 대규모 트래픽을 처리하는 웹 서비스나 모바일 애플리케이션에 많이 사용된다.
DynamoDB는 데이터를 여러 가용 영역에 자동으로 복제하기 때문에 높은 가용성을 제공하며, 초당 수백만 건의 요청 처리 및 수조 개의 데이터 저장, 수백 TB 이상의 데이터 저장을 지원하여 매우 큰 규모의 데이터 처리에 용이하다. 사용량이 증가하면 자동 확장할 수 있어 급증하는 트래픽을 관리하는 데에도 적합하다. 게다가 한 자릿수 밀리초 수준의 응답 시간을 제공하여 빠르고 일관된 성능을 보인다. AWS IAM과 연동되어 사용자나 서비스별 접근 권한을 세밀하게 제어할 수 있으며, 저렴하고 비용 효율적이다. DynamoDB 는 액세스가 빈번한 Standard와 그렇지 않은 Infrequent Access(IA)의 두 가지 테이블 클래스가 있다.
DynamoDB는 Table → Item → Attribute 구조로 데이터를 저장한다. Table은 데이터를 저장하는 기본 단위로, 모든 테이블은 생성 시 기본 키를 반드시 정의해야 한다. Item은 관계형 데이터베이스의 Row(행)에 해당한다. DynamoDB는 사실상 무제한의 Item을 저장할 수 있다. 하나의 Item은 최대 400KB까지 저장 가능하다. Attribute는 관계형 데이터베이스의 Column(열)에 해당하며, 모든 Item이 동일한 Attribute를 가질 필요는 없다. 또한 Attribute는 나중에 추가하거나 값이 null일 수도 있다. 따라서 DynamoDB에서는 새로운 Attribute를 자유롭게 추가할 수 있어 애플리케이션 요구 사항 변화에 빠르게 대응할 수 있다.
DynamoDB가 지원하는 데이터 타입은 Scalar Type(String, Number, Binary, Boolean, Null 등), Document Type(List, Map 등), Set Type(String Set, Number Set, Binary Set 등)이다.
DynamoDB에서는 읽기 및 쓰기 처리 용량을 관리하는 방식으로 두 가지 모두를 제공한다. 읽기 요청 용량의 단위는 RCU(Read Capacity Units), 쓰기 처리 용량의 단위는 WCU(Write Capacity Units)라 한다.
- Provisioned Mode: 기본 모드로, 사용자가 미리 필요한 읽기 및 쓰기 처리량을 설정한다. 예약한 용량만큼 비용이 지불되며, 자동 스케일링이 가능하다.
- On-Demand Mode: 용량을 미리 설정하지 않는 방식으로, DynamoDB가 요청량을 자동으로 분석해 읽기 및 쓰기 용량을 늘리거나 줄인다. 사용한 만큼 지불하며, 비용은 더 비싸다.
DAX (DynamoDB Acclerator)
DAX는 DynamoDB 전용 인메모리 캐시 서비스이다. 자주 조회되는 데이터를 RAM에 저장했다가, 동일 요청이 들어오면 DynamoDB를 직접 조회하지 않고 캐시에서 즉시 반환하여 읽기 성능을 크게 향상시킨다. 즉, DAX는 읽기 성능을 높이고 DynamoDB의 부하를 줄이기 위한 완전관리형 캐시 서비스이다.
DynamoDB가 일반적으로 한 자릿수 밀리초 수준의 응답 시간을 보여주는 반면, DAX는 마이크로초 수준으로 응답한다. 따라서 수십~수백 배 빠른 응답을 기대할 수 있다. 또한 기존 DynamoDB API와 호환되기 때문에 애플리케이션의 비즈니스 로직을 크게 변경하지 않고도 DAX를 사용할 수 있다. 캐시에 저장된 데이터는 영구적으로 보관하는 것이 아닌 TTL(Time To Live)을 따르는데, 기본 시간은 5분이다.
Stream Processing
DynamoDB 테이블에서 발생하는 Create, Update, Delete와 같은 아이템 수준의 데이터 변경 사항을 실시간으로 감지하고 변경이 발생한 순서대로 스트림 저장하는 기능이다. 실시간 이벤트 처리나 실시간 분석, 파생 테이블 생성, 리전 간 테이블 변경사항 반영 등의 사용 사례가 존재하며 테이블 변경 발생 시 람다 함수를 실행하는 용도로 가장 자주 활용된다. 변경 이벤트는 최대 24시간 동안 보관되고, 하나의 스트림을 동시에 읽을 수 있는 Consumer의 수에는 제한이 있다. 주로 Lambda Trigger와 DynamoDB Streams Kinesis Adapter로 처리한다.
최근에는 Kinesis Data Streams(KDS)를 DynamoDB와 연동하여 Stream Processing을 수행하는 경우도 많다. KDS는 DynamoDB Streams보다 더 강력한 스트리밍 기능을 제공한다. 이벤트를 최대 1년까지 저장할 수 있고, 여러 애플리케이션이 동시에 같은 스트림을 읽을 수 있다. 다양한 AWS 서비스와 쉽게 연동된다.
DynamoDB Global Table
하나의 DynamoDB 테이블을 여러 AWS 리전에 복제하여, 전 세계 어디서나 낮은 지연 시간으로 읽기와 쓰기를 할 수 있도록 하는 기능이다. 가장 큰 특징은 Active-Active Replication이다. 즉, 모든 리전이 동시에 활성 상태이며 모든 리전에서 읽기와 쓰기가 가능하다. Global Table은 내부적으로 DynamoDB Streams를 활용해 데이터 변경 사항을 다른 리전으로 전달하기 때문에 반드시 이 기능을 활성화해야 한다.
백업
DynamoDB는 데이터 손실이나 장애 발생 시 데이터를 복구할 수 있도록 백업 및 복원 기능을 제공한다. 백업 방식으로는 두 가지가 있다.
- Continuous Backups (PITR; Point-in-Time Recovery): 지속적으로 데이터를 백업하여 원하는 시점으로 복구할 수 있는 기능으로, 최근 35일 이내의 특정 시점으로 복원 가능하다. PITR로 복구하면 기존 테이블을 덮어쓰는 것이 아닌 새로운 DynamoDB 테이블이 생성된다.
- On-Demand Backups: 사용자가 원하는 시점에 직접 생성하는 테이블 전체 백업으로, 삭제 전까지 장기 보관이 가능하다. AWS 백업 서비스와 통합 관리할 수 있으며, 백업을 생성하더라도 DynamoDB의 성능에는 영향을 주지 않는다. 대규모 데이터 변경 전이나 시스템 업그레이드 전에 적합한 백업 방식이다.
S3와의 통합 기능
DynamoDB는 S3와 연동하여 데이터를 내보내거나 가져오는 기능을 제공한다. 즉, 운영 데이터베이스인 DynamoDB와 데이터 레이크인 S3를 연결하는 기능이라고 이해할 수 있다.
DynamoDB에서 S3로 내보내기 위해서는 PITR 활성화가 필수이다. 왜냐하면 PITR에 저장된 스냅샷을 기반으로 데이터를 내보내기 때문이다. 최근 35일 이내의 원하는 시점 데이터를 S3로 내보낼 수 있으며, 읽기 성능에는 영향을 주지 않는다. 데이터 분석이나 감사, ETL 수행 등으로 활용할 수 있으며 DynamoDB JSON과 Amazon ION 형식을 지원한다.
S3에 저장된 데이터를 새로운 DynamoDB 테이블로 가져올 때에는 CSV, DynamoDB JSON, Amazon ION 형식을 지원하며, 쓰기 성능에 영향을 주지 않는다. 이때, Import를 수행하면 기존 테이블에 데이터를 추가하는 것이 아닌 새로운 DynamoDB 테이블이 생성되는 것이다. 가져오는 과정에서 오류가 발생하면 CloudWatch Logs에 기록되어 어떤 데이터에 문제가 발생했는지 알 수 있다.
3. API Gateway
API Gateway는 클라이언트와 백엔드 사이에서 API를 생성, 관리, 보호하는 완전관리형 서비스이다. 즉, 클라이언트의 요청을 받아 Lambda, EC2, ECS 등의 백엔드에 전달하고, 응답을 다시 클라이언트에게 반환하는 API의 진입점 역할을 수행한다.
API Gateway는 람다와 자연스럽게 통합된다. 둘을 통합한 구조에서는 인프라를 관리하지 않고 API를 구축할 수 있다. 일반적인 REST API뿐만 아니라 클라이언트와 서버가 실시간으로 데이터를 주고받을 수 있는 WebSocket 프로토콜도 지원하며 API 버전 관리 기능을 지원한다. 또한 개발 단계별로 dev, test, prod 등과 같이 API를 분리할 수 있으며, IAM 인증, JWT 인증 등 다양한 인증 및 권한 관리 기능을 제공하여 API 접근을 제어할 수 있다.
API Key를 발급하여 사용자별 접근을 관리할 수 있으며 Throttling(요청 제한) 기능을 통해 과도한 요청을 방지할 수도 있다. Swagger / OpenAPI를 지원하여 빠른 API 생성을 지원하고, 백엔드로 전달하기 전 요청 변환 및 검증, 응답 가공 기능도 제공한다. 또한 정의된 API를 기반으로 SDK 생성 및 API 명세 자동 생성을 지원하며, 자주 요청되는 데이터는 캐시에 저장하여 응답 속도를 향상시킬 수 있다.
API Gateway는 요청을 받은 후, 설정된 통합 방식에 따라 적절한 대상으로 요청을 전달하는데, 대표적으로 3가지 대상이 있다. 우선, 람다 함수는 가장 많이 사용하는 대상으로, REST API를 제일 쉽게 구축할 수 있다. 두 번째로는 HTTP 엔드포인트로 온프레미스 HTTP 서버, ALB 등이 백엔드로 가능하다. HTTP 통합을 사용하는 이유는 기존 시스템을 그대로 사용하면서 API Gateway의 캐싱, 사용자 인증, API Key와 같은 다양한 기능을 추가하기 위해서이다. 마지막으로는 API Gateway가 람다를 거치지 않고 AWS 서비스의 API를 직접 호출하는 방식이다. 아키텍처 단순화 및 람다 실행 비용 절감 등의 효과에 더해 사용자 인증, 요청 제한 등과 같은 API Gateway의 기능을 사용하기 위한 방법이다.
API Gateway를 생성할 때는 API를 어떤 방식으로 사용자에게 제공할 것인지를 결정해야 한다. AWS에서는 다음의 3가지 유형을 제공한다.
- Edge-Optimized Endpoint(기본값): 전 세계 사용자를 대상으로 API를 제공할 때 사용하는 엔드포인트이다. API Gateway는 특정 하나의 리전에 존재하지만, 사용자의 요청은 먼저 CloudFront Edge Location으로 전달된 후 API Gateway로 라우팅된다.
- Regional Endpoint: 특정 리전의 사용자를 대상으로 API를 제공할 때 사용하는 엔드포인트이다. 필요 시 직접 CloudFront를 구성하여 연동할 수 있다. 이 경우, CloudFront의 캐시 정책이나 배포 등을 더 세밀하게 제어할 수 있다.
- Private Endpoint: VPC 내부에서만 접근 가능한 API이다. 인터넷에서는 접근 불가하며 ENI를 통해서만 API를 호출할 수 있다. Resource Policy를 이용해 접근 권한을 제어한다.
또한 API Gateway는 다양한 보안 기능을 제공하여 누가 API를 사용할 수 있는지와 무엇을 할 수 있는지를 제어한다. AWS 계정 내부 사용자 인증 시에는 AWS IAM 정책을 사용해 API 접근 권한을 제어하며, 외부 사용자 인증 시 Amazon Cognito를 사용한다. 사용자가 직접 인증 로직을 구현할 수도있으며, 일반적으로 람다 함수를 이용해 인증을 수행한다.
기본적으로 API Gateway는 AWS에서 제공하는 URL을 사용하지만, 실제 서비스에서는 사용자 정의 도메인을 사용하는 것이 일반적이다. 그리고 사용자 정의 도메인을 사용하려면 HTTPS 인증서가 필요하며, AWS Certificate Manager(ACM)을 이용해 인증서를 관리한다. 이때, 사용하는 엔드포인트에 따라 ACM 인증서가 위치해야 하는 리전이 다른데, Edge-Optimized Endpoint의 경우 반드시 us-east-1(North Virginia) 리전에, Regional Endpoint는 API Gateway가 위치한 동일 리전에 인증서를 생성해야 한다.추가로 사용자 정의 도메인을 연결하려면 Route 53에서 CNAME 또는 A Alias Record를 설정하여 도메인을 API Gateway에 연결해야 한다.
4. Step Functions
Step Functions는 서버리스 워크플로우를 시각적으로 구성할 수 있는 기능으로, 주로 람다 함수를 오케스트레이션하는 데 활용한다. 그래프를 생성하여 각 그래프 단계 별로 해당 단계의 결과에 따라 다음에 수행하는 작업이 무엇인지 정의한다. Step Functions는 순차 실행, 병렬 실행, 조건 분기, 타임아웃, 에러 핸들링 등의 기능을 제공하며, 람다뿐 아니라 EC2, ECS, 온프레미스 서버, SQS 대기열, API Gateway 등 다양한 AWS 서비스와 연동할 수 있다.
또한 사람이 승인해야 다음 단계로 진행할 수 있는 Human Approval 워크플로우도 구현할 수 있다. 주문 처리, 데이터 처리, 웹 애플리케이션 및 다양한 업무 프로세스로 활용 가능하다.
5. Amazon Cognito
Cognito는 웹 또는 모바일 애플리케이션의 사용자 인증과 권한 부여를 관리하는 AWS 서비스이다. 쉽게 말해, 회원가입 및 로그인, 사용자 인증을 담당하는 서비스다. Cognito User Pools (CUP)는 회원가입 로그인, 비밀번호 찾기, 이메일 인증 등을 제공하는 사용자 인증 서비스이며, API Gateway나 ALB가 발급된 JWT 토큰을 검사하여 API 접근 허용을 판단하도록 설계할 수 있다. Cognito Identity Pools는 AWS 리소스에 접근할 수 있는 임시 AWS 자격 증명을 사용자에게 발급하는 서비스이다. User Pool과 함께 사용할 수 있으며, Google / Facebook / Naver 등 외부 로그인 서비스와도 연동 가능하다.
Cognito는 IAM보다 훨씬 많은 수천~수백만 명의 사용자를 위한 서비스이기에 모바일 앱 사용자나 웹사이트 회원 등을 위해 활용되며, Active Directory, Azure AD, Okta 등의 SAML 기반 외부 인증 시스템과 연동할 수 있다.
1) Cognito User Pool (CUP)
CUP는 애플리케이션의 사용자를 관리하는 사용자 디렉터리, 즉 사용자 정보를 저장하는 사용자 데이터베이스 역할을 수행한다. 개발자가 직접 회원 테이블을 만들거나 로그인 서버를 구축할 필요 없이 AWS가 사용자 정보를 관리한다.
CUP에서는 아이디(또는 이메일)와 비밀번호를 이용한 기본적인 로그인 기능을 지원하며, 비밀번호 재설정도 가능하다. 회원가입 시에는 이메일이나 휴대폰 번호 검증도 할 수 있으며, MFA(Multi-Factor Authentication)도 지원한다. 구글, 페이스북 등을 활용한 외부 로그인도 연동할 수 있다.
2) Cognito Identity Pools
Identity Pool은 사용자에게 AWS에서 사용할 수 있는 임시 자격 증명(액세스 키, 시크릿 액세스 키, 세션 토큰)을 발급한다. 이 자격 증명을 이용하면 사용자는 일정 시간동안 AWS 리소스를 안전하게 사용할 수 있다. 사용자 인증 정보의 출처는 Cognito User Pool뿐만 아니라 Google 로그인, 페이스북 로그인과 같은 외부 로그인 업체도 가능하다. 자격 증명을 발급받은 사용자는 AWS 서비스에 직접 혹은 API Gateway를 통해 접근할 수 있다.
Identity Pool이 발급하는 자격 증명에는 IAM Role이 연결되어 있으며, 그 IAM Role의 정책에 따라 사용 가능한 AWS 리소스가 결정된다. 이때, 사용자의 ID에 따라 서로 다른 IAM 정책을 적용하여 세밀한 권한 제어를 구현할 수 있다. Identity Pool에서는 기본적으로 두 가지 IAM Role을 제공하는데, Authenticated User, 즉 로그인한 사용자는 더 많은 권한을 가지며 로그인하지 않은 Guest User에게는 제한된 권한이 부여된다.
'클라우드 > AWS' 카테고리의 다른 글
| 데이터 분석을 위한 AWS 서비스 (0) | 2026.07.20 |
|---|---|
| AWS의 데이터베이스 총정리 (0) | 2026.07.20 |
| AWS의 컨테이너: ECS, Fargate, ECR 및 EKS (0) | 2026.07.16 |
| 디커플링 애플리케이션(SQS, SNS, Kinesis) (0) | 2026.07.16 |
| AWS 스토리지 추가 기능 (0) | 2026.07.15 |