AWS 서버리스 (Lambda, DynamoDB, API Gateway)

Siyun·2025년 3월 3일

AWS

목록 보기

23/37

서버리스

EC2 인스턴스를 하나도 관리하지 않고 워크로드와 애플리케이션을 배포하고 싶다면 AWS에서 서버리스 컴퓨팅을 사용하면 된다.

서버리스 컴퓨팅을 사용하면 가용성을 보장하고, 크기를 조정하고, 서버를 관리하는 데 시간을 할애하는 대신 애플리케이션을 차별화하는 작업에 시간을 할애할 수 있다. 서버리스의 모든 정의에서 다음 4가지 측면을 언급한다.

프로비저닝하거나 관리할 서버가 없다.
사용량에 따라 크기가 조정된다.
유휴 리소스에 대해서는 비용을 지불하지 않는다.
가용성 및 내결함성이 내장되어 있다.

AWS 서버리스 리소스

AWS Lambda

Lambda는 이벤트 기반 서버리스 컴퓨팅 서비스로, 특정 트리거가 발생하면 자동으로 실행된다.

Lambda의 특징

트리거 이벤트 발생 시 코드 실행
실행되지 않는 동안에는 비용이 부과되지 않음
자동 확장 (수십 개 ~ 수천 개의 요청 처리 가능)
최대 실행 시간 15분 (장기 실행 프로세스에는 부적합)
함수 호출 횟수와 컴퓨팅 시간에 따라 비용이 청구됨
매달 100만 건의 요청과 40만 GBs의 컴퓨팅 시간은 무료
CloudWatch를 통한 매우 쉬운 모니터링 통합이 가능함
함수당 최대 10GB의 RAM을 프로비저닝 할 수 있다.
그래서 AWS Lambda는 JavaScript를 위한 Node.js, Python, Java, C#, dotnet core 또는 PowerShell, Ruby와 같은 다양한 언어를 실행 가능.
커스텀 런타임 API라는 것을 통해 많은 다른 언어(Rust, Golang 등)도 지원
컨테이너도 사용 가능. Lambda 런타임 API를 구현해야 함.

요금 참고 : https://aws.amazon.com/ko/lambda/pricing/

Lambda의 한도

실행 한도

메모리 할당량: 128MB ~ 10GB (1MB 단위 증가)
vCPU 증가: 메모리 증가에 따라 자동 증가
최대 실행 시간: 900초 (15분) 초과 시 실행 불가
환경변수 크기: 최대 4KB
임시 저장소: /tmp 폴더 사용 가능 (최대 10GB)
람다함수를 생성하는 동안 큰 파일을 가져올 때 사용함.
동시 실행 한도: 기본 1,000개 (요청 시 증가 가능, 미리 예약 권장)

배포 한도

배포 패키지 크기:
- 압축 시: 최대 50MB
- 압축 해제 시: 최대 250MB
  한도를 넘은 파일의 경우 /tmp 디렉터리 활용
환경변수 크기: 배포 시에도 최대 4KB

판단 기준 예시

Lambda 함수가 적합하지 않은 경우:

30GB RAM 필요
30분 이상의 실행 시간 필요
3GB 이상의 대형 파일 처리 필요

이런 경우 Lambda 대신 EC2, ECS, Batch 같은 다른 서비스를 고려해야 함.

Lambda 트리거 예시

S3 파일 업로드 시 자동 실행
API Gateway를 통한 HTTP 요청 처리
CloudWatch 이벤트 감지 후 실행

Lambda 함수 실습 예제

S3에 업로드된 이미지를 리사이징하는 Lambda 함수

S3의 input/ 경로에 이미지가 업로드되면, Lambda 함수가 실행되어 이미지를 리사이징한 후 output/ 경로에 저장한다.

1️⃣ Lambda 함수 생성

AWS Lambda 콘솔에서 Create function 클릭
런타임(파이썬, 자바 등) 선택
S3 접근 권한이 있는 IAM Role 부여

2️⃣ 트리거 추가

Add trigger → 트리거 소스로 S3 선택
이벤트 타입: PUT (파일 업로드 시 실행)
input/ 경로에 업로드된 파일만 감지

3️⃣ Lambda 코드 작성

직접 코드 작성 또는 .zip 파일 업로드

Python에서 Lambda 핸들러 예시:

import boto3

def lambda_handler(event, context):
    s3 = boto3.client('s3')
    
    # 이벤트에서 S3 버킷과 파일 정보 가져오기
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']
    
    # 파일 다운로드 및 리사이징 (생략)
    
    return {"status": "success"}

Test하기

코드 옆의 테스트를 눌러 실행하면 결과값과 처리기간, 사용된 메모리 양, 초기화 시간도 확인할 수 있다.

Runtime settings

핸들러의 이름이 lambda_function.lambda_handler면
파일명 lambda_function.py를 참고하라는 뜻이고
함수명이 lambda_handler라는 뜻이다.

로그 확인

람다 함수의 Role에서 CloudWatch Logs에 Write하는 권한을 줘야 한다.

Lambda Snap Start

Java11 이상에서 실행되는 Lambda함수들을 추가 비용 없이 성능을 최대 10배 높여준다.
원래 Java 람다 함수를 호출하면 초기화 - 호출 - 종료(Shutdown)된다.
하지만 이 기능을 활성화하면 함수가 미리 초기화된 상태에서 호출되기 때문에 호출 - 종료가 된다.
작동 원리 : 새 Lambda 버전을 발행할 때 람다가 함수를 초기화하고 메모리와 초기화된 함수의 디스크 상태의 스냅샷을 생성하고 캐시하여 저지연 액세스가 가능하다.

사용자 지정 Edge

보통 함수와 애플리케이션을 특정 리전에서 배포하지만 CloudFront를 사용할 때는 엣지 로케이션을 통해 콘텐츠를 배포한다. 모던 애플리케이션에서는 애플리케이션에 도달하기 전에 엣지에서 로직을 실행하도록 요구하기도 한다.

엣지 함수

: CloudFront 배포에 연결하는 코드. 사용자 근처에서 실행하여 지연 시간을 최소화하는 것이 목적이다. 엣지 함수를 사용하면 전역으로 배포되기 때문에 서버를 관리할 필요가 없다.

📍 사용 사례:

CloudFront의 CDN 콘텐츠를 사용자 지정하는 경우
웹사이트 보안과 프라이버시
엣지에서의 동적 웹 애플리케이션
검색 엔진 최적화(SEO)
오리진 및 데이터 센터 간 지능형 경로
엣지에서의 봇 완화
엣지에서의 실시간 이미지 변환
A/B테스트 사용자 인증 및 권한 부여
사용자 우선순위 지정 사용자 추적 및 분석

CloudFront에는 두 종류의 함수가 있다.

1. CloudFront 함수 :

일반적으로 CloudFront의 요청 처리 과정은 다음과 같다.
😉클라이언트 --뷰어 요청--> 💻CloudFront --오리진 요청--> 🖥오리진 서버 --오리진 응답--> 💻CloudFront --뷰어 응답--> 😉클라이언트

CloudFront 함수는 JavaScript로 작성된 경량 함수로 뷰어 요청과 응답을 수정한다.
확장성이 높고 지연 시간에 민감한 CDN 사용자 지정에 사용된다.
시작 시간은 1밀리초 미만이며 초당 백만 개의 요청을 처리한다.
뷰어 요청과 뷰어 응답을 수정할 때만 사용한다.

📍 사용 사례:

캐시 키 정규화: 요청 속성을 변환해 최적의 캐시 키 생성
헤더 조작: 요청이나 응답에 HTTP 헤더를 삽입, 수정, 삭제
URL 재작성 or 리디렉션
요청 인증&인가 : JWT를 생성하거나 검증

2. Lambda@Edge : Node.js나 Python으로 작성하며 초당 수천 개의 요청을 처리할 수 있다.
모든 CloudFront 요청 및 응답을 변경할 수 있다.
오리진 요청은 CloudFront가 오리진에 요청을 전송하기 전에 수정할 수 있다.
오리진 응답은 CloudFront가 오리진에서 응답을 받은 후에 수정된다.
뷰어 응답은 CloudFront가 뷰어에게 응답을 보내기 전에 수정된다.
함수는 us-east-1리전에만 작성할 수 있다.
CloudFront배포를 관리하는 리전과 같은 리전이다.

📍 사용 사례:

타사 라이브러리에 코드 의존: CPU, 메모리가 증가하므로 여러 라이브러리 로드 가능. AWS SDK사용해서 다른 AWS서비스 액세스도 가능
네트워크 액세스를 통해 외부 서비스에서 데이터를 처리할 수 있어 대규모 데이터 통합 수행 가능
파일 시스템이나 HTTP 요청 본문에도 바로 액세스 가능
다양한 사용자 지정

CloudFront 와 Lambda@Edge 차이 표

Lambda 네트워킹

기본적으로 Lambda 함수를 시작하면 나의 VPC 외부에서 시작된다.
따라서 나는 VPC 내에서 리소스에 액세스 할 권한이 없다.
RDS 데이터베이스, ElastiCache 캐시 내부 로드 밸런서를 시작하면 Lambda 함수가 해당 서비스에 액세스할 수 없다. Lambda 배포의 기본 설정이다.
인터넷의 퍼블릭 API에 액세스하는 것은 가능하다.
DynamoDB에 액세스할 수 있는 것은 DynamoDB가 AWS 클라우드의 퍼블릭 리소스이기 때문이다.
프라이빗 서브넷의 RDS 데이터베이스에 연결하려면 나의 VPC에서 Lambda함수를 시작하면 된다.
이를 위해서는 Lambda함수를 시작하려는 프라이빗 서브넷 지정과 Lambda함수에 보안 그룹을 추가하는 것을 정의하는 VPC ID 을 정의해야 한다.
그럼 Lambda가 해당 프라이빗 서브넷에 엘라스틱 네트워크 인터페이스(ENI)를 생성해 나의 VPC에서 실행되는 RDS에 액세스할 수 있게 된다.
이렇게 하면 VPC 내 프라이빗 서브넷의 모든 항목에 연결할 수 있다.
VPC에서 Lambda를 사용하는 대표적인 사용 사례는 RDS 프록시이다.
Lambda가 프라이빗 서브넷의 RDS로 직접 액세스하면 Lambda함수의 수가 너무 많이 생성되었다 사라지길 반복하기 때문에 RDS 데이터베이스의 로드가 상승해 시간 초과 등의 문제로 이어진다.
👉🏻 이를 해결하기 위해 RDS 프록시를 사용한다.
RDS 프록시가 연결을 한곳으로 모으고 RDS 데이터베이스 인스턴스 연결의 수를 줄인다. Lambda 함수가 RDS 프록시에 연결되고 RDS DB인스턴스로 연결되므로 아키텍처상의 문제가 해결된다.
Lambda 함수가 RDS 프록시에 연결할 수 있으려면 나의 VPC에서 Lambda함수를 시작해야 한다. RDS 프록시는 프라이빗 서브넷에 있기 때문에 퍼블릭 액세스가 불가능하다. Lambda함수를 퍼블릭으로 시작하면 RDS 프록시에 네트워크 연결을 할 수가 없다.

RDS프록시의 세 가지 장점
1. 데이터베이스 연결의 풀링과 공유를 통해 확장성을 향상시킨다.
2. 장애가 발생할 경우 장애 조치 시간을 66%까지 줄여 가용성을 향상시키고 연결을 보존한다.
3. RDS 프록시 수준에서 IAM 인증을 강제하여 보안을 높일 수 있다. 자격 증명은 Secrets Manager에 저장된다.

RDS - 람다 호출 및 이벤트 알림

RDS에서 람다 호출

데이터베이스 인스턴스 안에서 람다 함수를 호출할 수도 있다. 그러면 데이터베이스 안에서 일어나는 데이터 이벤트를 처리할 수 있게 된다.(RDS for PostgreSQL과 Aurora MySQL에 지원된다)

예를 들어 사용자가 이벤트 데이터를 등록 테이블에 삽입하면 RDS는 여분의 람다 함수를 직접 호출하도록 설정된다. 람다 함수는 사용자에게 환영 이메일을 보낼 수 있다.
이것은 RDS 인스턴스에 접속해서 그 안에서 설정해야 한다. (AWS 콘솔에서 설정X)
그래서 RDS 인스턴스로부터 람다 함수로 오는 모든 인바운드 트래픽을 반드시 허용해야 한다.
우리의 람다가 퍼블릭 인터넷에 있는 경우라도 허용해야 한다. 그럼 우리는 호출 또는 NAT 게이트웨이 또는 VPC 엔드포인트 등을 사용할 수 있다.
네트워크 연결성이 중요하다.

DB 인스턴스가 람다 함수를 호출할 수 있게 DB인스턴스가 적절한 IAM Role을 가지게 세팅해야 한다.
RDS 이벤트 알림을 사용하는 경우와 완전히 다르다.

RDS 이벤트 알림

RDS 이벤트 알림들은 데이터베이스 인스턴스 자체에 대한 정보를 알려주지 DB안의 데이터에 대한 정보는 전혀 없다.

RDS 이벤트 알림을 통해 얻는 정보

생성된 시각, 정지된 시각, 시작된 시각

데이터베이스 인스턴스, 데이터 베이스 스냅샷, 파라미터 그룹, 보안 그룹, 프록시 또는 커스텀 엔진 버전에 관한 이벤트
🚨 데이터베이스 안의 데이터에 관한 정보는 없음

RDS 이벤트 알림을 사용하면 전달 시간이 최대 5분인 근 실시간 이벤트를 받는다.
발생한 이벤트는 SNS에 전송하거나 EventBridge에서 가로챌 수도 있다.
그럼 SNS에서 예를들어 SQS 대기열이나 람다 함수로 그것들을 전송할 수 있다.
EventBrige는 아주 다양한 전송 대상이 있다.

Amazon DynamoDB

완전 관리형 데이터베이스로 데이터가 다중 AZ간에 복제되므로 가용성이 높다.
클라우드 네이티브이며 AWS 독점 서비스이다. NoSQL 데이터베이스이다.
RDS나 Aurora같은 관계형 데이터베이스는 아니지만 트랜잭션 지원 기능이 있다.
방대한 워크로드로 확장이 가능하다. 데이터베이스가 내부에서 분산되기 때문이다.
초당 수백만 개의 요청을 처리하고 수조 개의 행, 수백 TB의 스토리지를 갖게 된다.
성능은 한 자릿수 밀리초, 일관성 또한 높다.
보안과 관련된 모든 기능(보안, 권한 부여, 관리)은 IAM과 통합되어 있다.
비용이 적게 들고 오토 스케일링 기능이 탑재되어 있다.
유지 관리나 패치 없이도 항상 사용할 수 있다.
데이터베이스를 프로비저닝할 필요가 없다.
항상 사용할 수 있기 때문에 테이블을 생성하고 해당 테이블의 용량만 설정하면 된다.

테이블 클래스의 종류

Standard 클래스 : 액세스가 빈번한 데이터에서 사용
IA 테이블 클래스 : 액세스가 빈번하지 않은 데이터에서 사용

DynamoDB 기초

DynamoDB는 테이블로 구성되며 데이터베이스를 생성할 필요가 없다.(데이터베이스가 이미 존재)
테이블을 생성하면 각 테이블에 기본 키가 부여되는데 기본 키는 생성 시 결정된다.
각 테이블에 데이터(행)을 무한히 추가할 수 있다.
속성(열)은 나중에 추가할 수도 있고 null이 될 수도 있다.
DynamoDB 항목(행)의 최대 크기는 400KB이므로 큰 객체를 저장할 때는 적합하지 않다.
다양한 데이터 유형을 지원한다
- 스칼라 유형: String, Number, Binary, Boolean, Null
- 문서 유형: List, Map
스키마를 빠르게 전개해야 할 때 DynamoDB를 선택하면 아주 좋다.

DynamoDB 테이블 예시

예제: 사용자 정보 테이블 (`Users`)

📍 테이블 이름: Users
📍 파티션 키(Primary Key): UserID (해시 키)
📍 정렬 키(Sort Key, 선택 사항): 없음

UserID (PK)	Name	Email	Age	CreatedAt
`U001`	홍길동	gil@example.com	30	2024-03-05 10:00
`U002`	이순신	lee@example.com	45	2024-03-05 11:00
`U003`	김철수	kim@example.com	25	2024-03-05 12:00

예제: 주문 정보 테이블 (`Orders`)

📍 복합 키(Partition Key + Sort Key)를 사용한 예제
정렬키(Sort Key)는 선택 사항

📍 테이블 이름: Orders
📍 파티션 키(Primary Key): OrderID
📍 정렬 키(Sort Key): UserID

OrderID (PK)	UserID (SK)	Item	Amount	Status	OrderDate
`O1001`	`U001`	노트북	150만원	배송 완료	2024-03-05 10:30
`O1002`	`U002`	스마트폰	100만원	배송 중	2024-03-05 11:30
`O1003`	`U001`	마우스	5만원	결제 완료	2024-03-05 12:00

예제: 블로그 게시글 테이블 (`BlogPosts`)

📍 GSI (Global Secondary Index) 사용 예제

📍 테이블 이름: BlogPosts
📍 파티션 키(Primary Key): PostID
📍 정렬 키(Sort Key, 선택 사항): 없음
📍 글로벌 보조 인덱스(GSI): AuthorIndex (Author 필드를 인덱스로 설정)

PostID	Title	Author	Category	CreatedAt
`P001`	DynamoDB 기초	홍길동	데이터베이스	2024-03-05 09:00
`P002`	AWS Lambda 활용	이순신	서버리스	2024-03-05 10:00
`P003`	Python과 AWS	홍길동	프로그래밍	2024-03-05 11:00

🔹 GSI 예시 (AuthorIndex)
이 인덱스를 사용하면 Author(작성자) 기준으로 빠르게 검색할 수 있음.
예를 들어, "홍길동이 작성한 글을 검색"하면 P001과 P003이 조회됨.

DynamoDB에서는 관계형 데이터베이스(RDBMS)와 다르게 JOIN이 불가능하기 때문에,
📌 접근 패턴을 먼저 설계하고, 그에 맞는 테이블 구조를 만드는 것이 중요하다!

DynamoDB 읽기/쓰기 용량모드

테이블 용량 관리 방식을 제어하는 두 가지 모드

1. 프로비저닝 모드(기본):
초당 읽기/쓰기 요청 수를 예측해서 미리 용량을 프로비저닝한다. 프로비저닝된 RCU(읽기용량단위)와 WCU(쓰기용량단위)만큼 비용을 지불한다. 미리 용량을 계획한 경우에도 오토 스케일링 기능이 있으므로 테이블의 로드에 따라 자동으로 RCU와 WCU를 늘리거나 줄일 수 있다.
프로비저닝 모드는 로드를 예측할 수 있고 서서히 전개되며 비용 절감을 원할 때 적합하다.

2. 온디맨드 모드 :
읽기/쓰기 용량이 워크로드에 따라 자동으로 확장된다. 정확히 사용한 만큼의 비용을 지불한다. 모든 읽기와 쓰기에 비용을 지불해야 한다.
프로비저닝 모드보다 2~3배 비싸지만 워크로드를 예측할 수 없거나 급격히 증가하는 경우에 유용하다.

DynamoDB 실습

1. DynamoDB 콘솔 > Create table 선택

데이터베이스와 관계없이 바로 테이블을 만든다.
즉 서버리스 데이터베이스가 된다.
테이블 이름을 입력하고 파티션 키를 선택한다. 선택사항에는 정렬 키도 있다.
이 두 가지를 결합하면 기본 키가 된다.

2. Settings 항목 설정

기본 세팅과 사용자 세팅 중 선택한다.

사용자 세팅을 선택했을 시:
Read/Write capacity settings 옵션은 On-demand 또는 Provisioned을 선택할 수 있다.
- Provisioned를 선택했을 시:
  읽기와 쓰기용량의 오토스케일링 설정 활성화할 수 있고 끌 수도 있다.
  활성화하면 최솟값과 최대값 그리고 목표 사용률을 설정하면 된다.
  적절한 읽기 쓰기 용량을 알고 싶다면 바로 위의 Capacity calculator를 사용한다.
  마지막에 매달 청구되는 가격 예측을 확인할 수 있다.

3. 생성된 테이블에 아이템(행) 추가하기

View items > Create item으로 파티션키와 속성들을 추가해 아이템(행)을 생성할 수 있다.
DynamoDB에서는 모든 아이템에 대해 모든 속성을 지정할 필요가 없고 아이템마다 속성이 달라도 된다.

DynamoDB Accelerator(DAX)

DynamoDB를 위한 고가용성의 완전 관리형 무결절 인메모리 캐시
DynamoDB 테이블에 읽기 작업이 많을 때 DAX 클러스터를 생성하고 데이터를 캐싱하여 읽기 혼잡을 해결한다.
DAX는 캐시 데이터에 마이크로초 수준의 지연 시간을 제공한다.
기존 DynamoDB API와 호환되므로 애플리케이션 로직을 변경할 필요가 없다.
DynamoDB 테이블과 애플리케이션이 있을 때 몇몇 캐시 노드가 연결된 DAX 클러스터를 생성하면 백그라운드에서 DAX 클러스터가 DynamoDB 테이블에 연결된다.
캐시의 기본 TTL은 5분으로 설정되어 있으나 변경할 수 있다.

ElasticCache가 아니라 DAX를 사용하는 이유는?
DAX는 DynamoDB 앞에 있고 개별 객체 캐시와 쿼리와 스캔 태시를 처리하는데 유용하다.
집계 결과를 저장할 때는 ElastiCache가 좋고 DynamoDB는 대용량의 연산을 저장할 때 좋다.
DynamoDB에 캐싱 솔루션을 추가할 때는 보통 DAX를 사용한다.

DynamoDB 스트림 처리

테이블의 모든 수정 사항, 즉 생성, 업데이트, 삭제를 포함한 스트림을 생성할 수 있다.

스트림은 테이블에서 데이터가 변경될 때(추가, 수정, 삭제) 변경 내용을 실시간으로 캡처하는 기능이다. 쉽게 말해서 DynamoDB의 변경 이력을 기록하는 로그 시스템.

📍 사용 사례

사용자 테이블에 새로운 사용자가 등록됐을 때 환영 이메일을 보내는 등 DynamoDB 테이블의 변경 사항에 실시간으로 반응하는 데 활용할 수 있다.
실시간으로 사용 분석을 하거나 파생 테이블을 삽입할 수도 있다.
리전 간 복제를 실행하거나 DynamoDB테이블 변경 사항에 대해 Lambda함수를 실행할 수도 있다.

DynamoDB의 두 가지 스트림 처리

1. DynamoDB Streams

보존 기간이 24시간이고 소비자 수가 제한된다.
Lambda 트리거와 함께 사용하며 좋다.
자체적으로 읽기를 실행하려면 DynamoDB Stream Kinesis 어댑터를 사용한다.

Kinesis Data Streams

Kinesis Data Streams 에 변경 사항을 바로 보내는 방법이다.
보존 기간이 1년
더 많은 수의 소비자를 가질 수 있다.
데이터를 처리하는 방법이 훨씬 많다. (Lambda함수, Kinesis Data Analytics, Kinesis data Firehose Glue 스트리밍 ETL등)

DynamoDB 글로벌 테이블

글로벌 테이블은 여러 리전 간에 복제가 가능한 테이블이다.
테이블을 두 리전에 둘 수 있고 양방향 복제가 가능하다.
글로벌 테이블은 복수의 리전에서 짧은 지연 시간으로 액세스할 수 있게 해준다.
다중 활성 복제가 가능하므로 애플리케이션이 모든 리전에서 테이블을 읽고 쓸 수 있다.
글로벌 테이블을 활성화하려면 DynamoDB 스트림을 활성화해야 리전 간 테이블을 복제할 수 있는 기본 인프라가 구축된다.

DynamoDB 타임 투 리브(TTL)

만료 타임스탬프가 지나면 자동으로 항목을 삭제하는 기능
TTL을 정의한 다음 에포크 타임스탬프에서 현재 시간이 ExpTime열을 넘어설 경우 해당 항목을 만료 처리하고 삭제 처리를 진행하는 개념이다.

📍 사용사례

최근 항목만 저장하도록 하거나 2년 후 데이터를 삭제해야 한다는 규정을 따라야 할 때
사용자가 웹사이트에 로그인했을 때 세션을 중앙 저장소인 DynamoDB에 두 시간동안 저장하는 것이다. 세션이 갱신되지 않으면 2시간 뒤 삭제된다.

DynamoDB 재해 복구

지정 시간 복구(PITR)를 사용해 지속적인 백업을 할 수 있다.

활성화 하면 35일 동안 지속된다.
백업 기간 내에는 언제든 지정 시간 복구를 실행할 수 있다.
복구를 진행할 경우 새로운 테이블을 생성한다.

온디맨드 백업

더 긴 백업 옵션으로 직접 삭제할 때까지 보존된다.
DynamoDB의 성능이나 지연 시간에 영향을 주지 않는다.
AWS Backup 서비스를 사용하면 백업에 수명 주기 정책을 활성화 할 수 있고 재해 복구 목적으로 리전 간 백업을 복사할 수 있다. 복구 시 새로운 테이블이 생성된다.

Dynamo DB와 Amazon S3간 통합

S3에 테이블을 내보낼 수 있다. 이를 위해서는 지정 시간 복구 기능을 활성화해야 한다.
DynamoDB 테이블을 S3로 내보내고 가령 쿼리를 수행하려면 Amazon Athena 엔진을 사용한다.
지속적인 백업을 활성화한 상태이므로 최근 35일 이내 어떤 시점으로든 테이블을 내보낼 수 있다.
테이블을 내보내도 테이블의 읽기 용량이나 성능에 영향을 주지 않는다.
S3로 테이블을 내보내 데이터 분석을 수행할 수 있다.
감사목적으로 스냅샷을 확보할 수도 있다.
데이터를 DynamoDB로 다시 가져오기 전에 데이터 ETL등 대규모 변경을 실행할 수도 있다.
내보낼 때는 DynamoDB JSON이나 ION 형식을 이용한다.
S3에서 테이블을 가져올 수도 있다. S3에서 CSV, JSON, ION형식으로 내보낸 다음 새로운 DynamoDB 테이블을 생성하는 식이다. 쓰기 용량을 소비하지 않고 새로운 테이블을 생성한다.
가져올 때 발생한 오류는 모두 CloudWatch Logs에 기록된다.

클라이언트가 Lambda 함수를 직접 호출하려면 클라이언트에게 IAM Role이 있어야 한다. 클라이언트와 Lambda 함수 사이에 ALB를 배치하면 Lambda함수가 HTTP 엔트포인트에 노출된다.

API Gateway

Rest API를 생성하고 Lambda 함수에 요청을 프록시한다.
클라이언트가 퍼블릭 액세스할 수 있다.
Lambda와 통합되면 완전 서버리스 애플리케이션이 구축되므로 인프라 관리가 필요없다.
Websocket 프로토콜을 지원하므로 API Gateway로 두 가지 방법의 실시간 스트리밍이 가능하다.
API 버저닝을 핸들링하므로 버전 1,2,3 이 생겨도 클라이언트 연결이 끊기지 않는다.
dev, test, prod 등 여러 환경을 핸들링하고 보안에도 활용할 수 있다.
인증, 권한 부여 등 수많은 보안 기능을 API Gateway에 활성화할 수 있다.
API키를 생성할 수 있고 API Gateway에 클라이언트 요청이 과도할 때 요청을 스로틀링할 수 있다.
Swagger나 Open API 3.0과 같은 공통 표준을 사용해 신속히 API를 정의하여 가져올 수 있다. 내보내기도 가능하다.
요청과 응답을 변형하거나 유효성을 검사해 올바른 호출이 실행되게 할 수 있다.
SDK나 API 스펙을 생성하거나 API 응답을 캐시할 수도 있다.

API Gateway가 지원하는 통합

Lambda 함수
Lambda 함수를 사용하는 REST API를 완전 서버리스 애플리케이션에 노출시키는 일반적이고 간단한 방법
HTTP
백엔드의 HTTP의 엔드포인트를 노출시킬 수 있다.
온프레미스에 HTTP API가 있거나 클라우드 환경에 ALB가 있을 때 API Gateway를 활용하면 속도 제한 기능, 캐싱, 사용자 인증, API 키 등의 기능을 추가할 수 있다.
AWS 서비스
어떤 AWS API라도 노출시킬 수 있다.
단계 함수 워크플로우를 시작할 수 있고 직접 SQS에 메시지를 게시할 수도 있다.
인증을 추가하거나 API를 퍼블릭으로 배포하거나 특정 AWS에 속도 제한을 추가하기 위해 통합한다.

API Gateway 배포 방법 (엔드포인트 유형)

1. 엣지 최적화(Edge-Optimized, 기본):

글로벌 클라이언트 용이다.
모든 요청이 CloudFront 엣지 로케이션을 통해 라우팅되므로 지연 시간이 개선된다.
API Gateway는 여전히 생성된 리전에 위치하지만 모든 엣지 로케이션에서 액세스될 수 있다.

2. 리전 배포(Regional):

모든 사용자는 API Gateway를 생성한 리전과 같은 리전에 있어야 한다.
자체 CloudFront 배포를 생성할 수도 있다. (엣지 최적화 배포와 동일한 결과를 내며 캐싱 전략과 CloudFront 설정에 더 많은 권한을 가질 수 있다.)

3. 프라이빗(Private):

프라이빗 API GAteway는 VPC 내에서만 액세스할 수 있다.
ENI 같은 인터페이스 VPC 엔드포인트를 사용해서 접근한다.

API Gateway의 보안

사용자를 식별하는 방법

IAM Roles 사용하기 : EC2 인스턴스에서 실행되는 내부 애플리케이션에서 유용하다.
API에 액세스할 때 IAM Role을 사용하도록 하는 것이다.
Amazon Cognito : 모바일 애플리케이션이나 웹 애플리케이션의 외부 사용자에 대한 보안 조치로 사용.
자체 로직 사용 : Lambda 함수로 사용

HTTPS 보안

사용자 지정 도메인 이름을 ACM과 통합할 수 있다.
엣지 최적화 엔드포인트를 사용할 경우 인증서는 us-east-1에 있어야 하고 리전 엔드포인트를 사용한다면 인증서는 API Gateway 단계와 동일한 리전에 있어야 한다.
Route 53에 CNAME이나 A-별칭 레코드를 설정해 도메인 및 API Gateway를 가르키도록 해야 한다.

API Gateway 실습

1. API Gateway 콘솔 > 원하는 API 유형 선택해 Build 클릭

여기선 REST API만 다루겠다.

2. 새로운 API를 제작하거나 가져오기

'OpenAPI definition'파일에서 가져오는 것도 가능하다. 이러면 API가 대신 제작을 해준다.
이미 존재하는 API를 복제할 수도 있고 예제 API로 싲가할 수도 있다.

3. 엔드포인트 설정

엔드포인트는 리전별, 엣지 최적화, 프라이빗 중 선택한다.

4. API 선택하고 Create method로 메소드 생성하기

메소드 타입(GET, POST, UPDATE 등)을 선택한다.
통합 유형을 고른다.(람다, HTTP, Mock, AWS service, Vpc link 중 선택)
어느 리전의 어느 서비스도 통합이 가능하다.

람다를 선택했다면 해당 람다함수의 ARN을 복사해서 붙여넣는다.

timeout은 람다는 최대 15분의 시간을 가질 수 있음에도 불구하고 API Gateway에서는 기본설정이 29초이고 이보다 적게 설정할 수도 있다.
Lambda함수가 실행되는 데 얼마나 걸리는 지와는 무관하다.

이렇게 메소드를 생성하면 API gateway에게 자동적으로 Lambda함수를 호출할 권리를 줄 것이다.

5. API Method > Test로 테스트 가능

디버깅은 람다함수에서 event를 출력해보면 API Gateway에서 보낸 패킷을 확인할 수 있다.

6. 리소스 추가하기

API 선택하고 Create Resource를 선택한다.
리소스 경로를 / 로 하고 리소스 이름은 'houses' 원하는 걸로 한다.
그럼 /houses 경로가 생기고 해당 경로 안에 메서드를 만들 수 있다.

7. API 배포하기

API 선택 > Deploy API 를 선택해 스테이지(dev, product, test 등)를 설정한다.
그리고 Deploy를 누른다.
그럼 해당 API에서 Invoke URL을 확인할 수 있다.

AWS Step functions

서버리스 워크플로를 시작적으로 구성할 수 있는 기능
주로 람다 함수를 오케스트레이션 하는 데 활용된다.
그래프를 만들어 각 그래프 단계별로 해당 단계의 결과에 따라 다음으로 수행하는 작업이 뭔지 정의한다.
복잡한 워크플로를 만들어 AWS에서 실행시킬 수 있는 편리한 도구이다.
제공하는 기능 :시퀀싱, 병행 실행, 조건 설정, 타임아웃, 에러 처리
람다 함수만 처리하는 게 아닌 EC2, ECS, 온프레미스 서버, API Gateway, SQS큐 등 다양한 서비스를 워크플로에 넣을 수 있다.
워크플로에 사람이 개입해 승인을 해야만 진행되는 단계를 설정할 수 있다.
즉 어떤 지점에서 사람이 결과를 확인하고 승인을 하면 다음 단계로 넘어가고 아니면 워크플로가 멈춰 실패하게 한다.

사용처 : 주문 이행이나 데이터 처리, 웹 애플리케이션 구성 등 복잡한 워크플로를 시각적으로 구성하려고 할 때 사용한다.

Amazon Cognito

일반적으로 이 서비스의 사용자들은 AWS 계정 외부에 있다.
웹, 모바일 앱과 상호작용 할 수 있는 자격 증명을 부여한다.

두 종류의 하위 서비스

1. Cognito User Pools

앱 사용자에게 가입 기능을 제공.
API Gateway 및 ALB와 원활히 통합된다.
사용자 이름 또는 이메일, 비밀번호의 조합으로 간단한 로그인 절차를 정의할 수 있다.
비밀번호 재설정 기능, 이메일 및 전화번호 검증 및 MFA 가 가능하다.
소셜 로그인도 가능하다(Facebook, Google 등)
두 가지 사용 방법
- 사용자는 Cognito 사용자 풀에 접속해 토큰을 받고 토큰을 API Gateway에 전달한다. 확인이 끝나면 사용자 자격 증명으로 변환되어 백엔드의 Lambda 함수로 전달된다.
- Cognito 사용자 풀을 ALB 밸런서 아래에 배치한다. 유효한 로그인이면 요청을 백엔드로 리다이렉트하고 사용자의 자격 증명과 함께 추가 헤더를 전송한다.

2. Cognito Identity Pools

앱에 등록된 사용자에게 임시 AWS 자격 증명을 제공해서 일부 AWS 리소스에 직접 액세스할 수 있도록 해주고 User Pool과 원활히 통합된다.
사용자에게 자격 증명을 제공하지만 API Gateway나 ALB를 통하지 않고 임시 AWS 자격 증명을 사용해 액세스하게 한다.
사용자는 Cognito 사용자 풀 내의 사용자가 될 수 있고 타사 로그인이 될 수도 있다.
직접 또는 API Gateway를 통해 서비스에 액세스할 수도 있다.
자격 증명에 적용되는 IAM 정책은 사전 정의되어 있다. user_id를 기반으로 사용자 정의하여 세분화된 제어를 할 수도 있다.
게스트 사용자나 특정 역할이 정의되지 않은 인증된 사용자에게는 기본 IAM 역할을 상속하게 된다.
DynamoDB에 행 수준 보안을 설정해 특정 정책이 적용된 사용자는 이 조건을 통해 액세스를 얻은 항목에서만 액세스할 수 있다.

📍 IAM User와 다른점 : AWS 외부의 수백명의 사용자, 모바일 사용자, SAML을 통한 인증을 제공

Siyun

공부 기록

이전 포스트

AWS SQS, SNS, Kinesis, Active MQ

다음 포스트

AWS 서버리스 (Lambda, DynamoDB, API Gateway)

AWS

서버리스

AWS Lambda

Lambda의 특징

Lambda의 한도

실행 한도

배포 한도

판단 기준 예시

Lambda 트리거 예시

Lambda 함수 실습 예제

S3에 업로드된 이미지를 리사이징하는 Lambda 함수

1️⃣ Lambda 함수 생성

2️⃣ 트리거 추가

3️⃣ Lambda 코드 작성

Python에서 Lambda 핸들러 예시:

Test하기

Runtime settings

로그 확인

Lambda Snap Start

사용자 지정 Edge

엣지 함수

CloudFront 와 Lambda@Edge 차이 표

Lambda 네트워킹

RDS - 람다 호출 및 이벤트 알림

RDS에서 람다 호출

RDS 이벤트 알림

RDS 이벤트 알림을 통해 얻는 정보

Amazon DynamoDB

테이블 클래스의 종류

DynamoDB 기초

DynamoDB 테이블 예시

예제: 사용자 정보 테이블 (Users)

예제: 주문 정보 테이블 (Orders)

예제: 블로그 게시글 테이블 (BlogPosts)

DynamoDB 읽기/쓰기 용량모드

DynamoDB 실습

1. DynamoDB 콘솔 > Create table 선택

2. Settings 항목 설정

3. 생성된 테이블에 아이템(행) 추가하기

DynamoDB Accelerator(DAX)

DynamoDB 스트림 처리

DynamoDB 글로벌 테이블

DynamoDB 타임 투 리브(TTL)

DynamoDB 재해 복구

Dynamo DB와 Amazon S3간 통합

API Gateway

API Gateway가 지원하는 통합

API Gateway 배포 방법 (엔드포인트 유형)

API Gateway의 보안

API Gateway 실습

1. API Gateway 콘솔 > 원하는 API 유형 선택해 Build 클릭

2. 새로운 API를 제작하거나 가져오기

3. 엔드포인트 설정

4. API 선택하고 Create method로 메소드 생성하기

5. API Method > Test로 테스트 가능

6. 리소스 추가하기

7. API 배포하기

AWS Step functions

Amazon Cognito

두 종류의 하위 서비스

AWS SQS, SNS, Kinesis, Active MQ

AWS 생성형 AI 온라인 세미나

0개의 댓글

예제: 사용자 정보 테이블 (`Users`)

예제: 주문 정보 테이블 (`Orders`)

예제: 블로그 게시글 테이블 (`BlogPosts`)