AWS SAA(Serverless, Lambda, DynamoDB, API Gateway, Cognito)

서버리스(Serverless) 컴퓨팅

서버리스는 개발자가 더 이상 서버를 직접 프로비저닝하거나 관리할 필요가 없는 새로운 개발 패러다임임 서버가 실제로 없는 것이 아니라, 클라우드 제공업체(AWS)가 서버 관리를 대신 해주므로 개발자는 코드(함수) 배포에만 집중할 수 있음

 

초기에는 **FaaS(Function as a Service)**와 동일한 의미로 사용되었으며 AWS Lambda가 그 시작이었지만, 현재는 S3, DynamoDB, API Gateway처럼 서버를 직접 관리하지 않는 모든 관리형 서비스를 포괄하는 넓은 개념으로 사용됨

서버리스의 핵심 장점

• 비용 효율성: 요청이 있을 때만 코드가 실행되고, 사용한 만큼만 비용을 지불함 유휴 상태의 서버에 대한 비용이 발생하지 않아 매우 경제적임
• 탄력적 확장성: 사용자가 0명일 때부터 갑자기 수백만 명이 몰려드는 상황까지, 트래픽에 맞춰 자동으로 확장 및 축소됨 별도의 스케일링 설정이 필요 없음
• 개발 속도 향상: 개발자가 인프라 구성 및 관리가 아닌, 비즈니스 로직 개발에만 집중할 수 있어 제품 출시 속도(Time-to-market)를 크게 단축시킬 수 있음

서버리스 사용 시 고려사항

• 콜드 스타트(Cold Start): 함수가 처음 호출되거나 오랜만에 호출될 때, 실행 환경을 준비하는 데 약간의 지연 시간이 발생할 수 있음
• 실행 시간 제한: 서버리스 함수(Lambda 등)는 장시간 실행되는 작업이 아닌, 단기 실행(short executions)을 위해 설계되었음 (예: Lambda는 최대 15분)

AWS의 주요 서버리스 서비스

AWS 생태계에서 서버리스 아키텍처를 구성하는 핵심 서비스들은 다음과 같음

• 컴퓨팅: AWS Lambda, AWS Fargate
• 데이터베이스: Amazon DynamoDB, Aurora Serverless
• API 게이트웨이: Amazon API Gateway
• 스토리지: Amazon S3
• 메시징 및 이벤트: Amazon SNS, Amazon SQS, Amazon EventBridge
• 워크플로우: AWS Step Functions
• 인증: Amazon Cognito

참조 아키텍처 예시: 사용자는 S3에 호스팅된 정적 웹사이트에 접속하고, Cognito를 통해 로그인함 웹사이트는 API Gateway를 통해 REST API를 호출하고, API Gateway는 Lambda 함수를 트리거하여 DynamoDB의 데이터를 읽고 쓰는 구조는 가장 대표적인 서버리스 패턴임

 

AWS Lambda: 서버리스 컴퓨팅의 핵심

Lambda는 서버 관리 없이 코드를 실행하게 해주는 이벤트 기반 컴퓨팅 서비스임

 

EC2와의 비교

구분	Amazon EC2 (서버 기반)	AWS Lambda (서버리스)
관리 단위	가상 서버	가상 함수
실행 방식	지속적으로 실행 (24/7)	필요할 때만 실행 (On-demand)
확장 방식	Auto Scaling Group 등 별도 설정 필요	자동 확장
실행 시간	제한 없음	최대 15분

 

지원언어 및 런타임

Node.js(JavaScript), Python, Java, C#, Ruby 등 다양한 언어를 지원하며, Custom Runtime API를 통해 Go, Rust 등 다른 언어도 사용 가능함 또한, Lambda 런타임 API를 구현한 컨테이너 이미지를 배포할 수도 있지만, 일반적인 Docker 이미지를 실행하는 데는 ECS나 Fargate가 더 적합함

 

핵심 통합 및 활용 패턴

Lambda는 다양한 AWS 서비스와 통합되어 이벤트에 반응하는 자동화된 아키텍처를 구축하는 데 핵심적인 역할을 함

• 주요 통합 서비스: API Gateway, S3, DynamoDB, SQS, SNS, EventBridge, Kinesis, Cognito 등
• 활용 패턴 1: 서버리스 썸네일 생성 (S3 연동)
  • S3 버킷에 이미지가 업로드되면, 이 이벤트가 Lambda 함수를 트리거함
  • Lambda 함수는 원본 이미지로 썸네일을 생성하여 다른 S3 버킷에 저장하고, 관련 메타데이터를 DynamoDB에 기록함
• 활용 패턴 2: 서버리스 CRON 작업 (EventBridge 연동)
  • EC2 인스턴스를 항상 켜놓고 CRON을 실행하는 대신, EventBridge 스케줄 규칙을 사용하여 '매시간' 또는 '매일 자정'에 Lambda 함수를 트리거함
  • 이를 통해 주기적인 배치(Batch) 작업을 서버 없이 비용 효율적으로 수행할 수 있음

 

Lambda 심층 분석

비용 구조 Lambda 비용은 요청 수와 컴퓨팅 시간 두 가지로 결정됨

• GB-초 단위 과금: 컴퓨팅 시간은 할당된 메모리(GB) × 실행 시간(초)으로 계산됨 예를 들어, 512MB 함수가 2초 실행되면 1GB-초의 비용이 발생함
• 무료 티어: 매월 100만 건의 요청과 40만 GB-초의 컴퓨팅 시간이 무료로 제공되며, 두 조건 중 하나라도 초과하면 과금이 시작됨
• 프로비저닝된 동시성: 콜드 스타트를 없애기 위해 이 기능을 사용하면, 함수가 유휴 상태일 때도 할당된 동시성 수준에 따라 비용이 부과됨

실행 환경 및 제약

• 임시 스토리지: 함수 컨테이너 내에 /tmp 디렉토리로 512MB에서 최대 10GB까지의 임시 저장 공간을 사용할 수 있음
• 배포 패키지: .zip 파일로 직접 업로드 시 50MB, S3를 통해 배포 시 압축 해제 기준 250MB의 용량 제한이 있음
• Lambda Layer: 여러 함수에서 공통으로 사용하는 라이브러리나 종속성을 Layer로 분리하여 재사용하고, 배포 패키지 용량을 줄일 수 있음
• 환경 변수: 최대 4KB까지 설정할 수 있음

VPC 연동 및 성능

기본 네트워크 환경

기본적으로 Lambda 함수는 사용자의 VPC 외부, 즉 AWS가 관리하는 VPC 내에서 실행됨 이 때문에 DynamoDB나 외부 API처럼 인터넷을 통해 접근 가능한 퍼블릭 리소스에는 접근할 수 있지만, 사용자의 VPC 내부에 격리된 프라이빗 리소스(RDS 데이터베이스, ElastiCache 등)에는 접근할 수 없음

 

VPC 연동

Lambda가 프라이빗 리소스에 접근해야 할 경우, Lambda 함수를 사용자의 VPC 내 특정 서브넷에 배포해야 함 이렇게 구성하면 Lambda는 VPC 내에 ENI(Elastic Network Interface)를 생성하여 RDS DB와 같은 내부 서비스와 안전하게 통신할 수 있게 됨

 

VPC 연동 시 고려사항: RDS 커넥션 문제와 RDS Proxy

Lambda 함수는 트래픽에 따라 수백, 수천 개로 순식간에 확장될 수 있음 이렇게 확장된 각각의 Lambda 함수가 데이터베이스에 직접 연결을 시도하면, 데이터베이스가 감당할 수 있는 최대 커넥션 수를 초과하여 성능이 저하되거나 장애가 발생할 수 있음

 

이 문제를 해결하기 위한 최적의 솔루션이 RDS Proxy임

• 역할: RDS Proxy는 Lambda 함수와 RDS 데이터베이스 사이에 위치하는 데이터베이스 커넥션 관리자임 Lambda 함수들은 DB가 아닌 RDS Proxy에 연결하고, RDS Proxy는 이 연결들을 효율적으로 풀링(Pooling)하고 공유하여 실제 DB에 연결되는 커넥션 수를 최소화함
• 장점:
  • 확장성: 커넥션 풀링으로 DB 부하를 줄여 확장성을 향상시킴
  • 가용성: DB 장애 조치(Failover) 시 연결을 보존하여 다운타임을 최대 66%까지 줄임
  • 보안: IAM 인증을 강제하고, DB 자격 증명을 Secrets Manager에 안전하게 저장함
• 필수 조건: RDS Proxy는 프라이빗 리소스이므로, 여기에 연결하려는 Lambda 함수 또한 반드시 동일한 VPC 내에 배포되어야 함

성능 및 비용

• 성능: 과거에는 VPC Lambda의 콜드 스타트가 느렸으나, Hyperplane ENI 도입으로 크게 개선되었음
• 비용: VPC 내 Lambda가 외부 인터넷(예: 외부 API 호출)과 통신해야 할 경우, NAT Gateway를 통해야 하며 이때 상당한 데이터 처리 비용이 발생할 수 있음

데이터베이스 연동 심화

1. 데이터 변경 이벤트 처리 (DB가 Lambda를 직접 호출)

• RDS for PostgreSQL이나 Aurora MySQL 데이터베이스 내에서 INSERT 같은 데이터 변경이 일어났을 때, 데이터베이스가 직접 Lambda 함수를 호출(Invoke)하는 기능임
• 예를 들어, 회원가입 테이블에 데이터가 추가되면 DB가 Lambda 함수를 호출하여 환영 이메일을 보내는 패턴에 사용됨 이를 위해서는 DB 인스턴스가 Lambda를 호출할 수 있는 네트워크 경로와 IAM 권한이 필요함

2. 인스턴스 상태 이벤트 처리 (RDS 이벤트 알림)

• DB 인스턴스 자체의 상태(생성, 중지, 스냅샷 완료 등)가 변경되었을 때 SNS나 EventBridge로 알림을 보내는 기능임
• 이 알림을 통해 Lambda 함수를 트리거하여 DB 인프라 변경에 따른 자동화된 운영 작업을 수행할 수 있음
• 핵심 차이점: 이 방식은 DB 인스턴스의 '상태'에 대한 알림일 뿐, DB 내부의 '데이터' 변경(INSERT 등)에 대한 정보는 포함하지 않음

엣지 컴퓨팅: CloudFront Functions & Lambda@Edge

CloudFront CDN 엣지 로케이션에서 코드를 실행하여, 사용자에게 콘텐츠를 전달하기 전에 요청/응답을 동적으로 수정하고 지연 시간을 최소화하는 서버리스 기능임

 

주요 사용 사례

웹사이트 보안 강화, 검색 엔진 최적화(SEO), 이미지 실시간 변환, A/B 테스팅, 사용자 인증/인가 등에 활용됨

 

요청 처리 단계

1. Viewer Request: 사용자의 요청이 CloudFront에 도달한 직후
2. Origin Request: CloudFront가 원본 서버(Origin)로 요청을 보내기 직전
3. Origin Response: CloudFront가 원본 서버로부터 응답을 받은 직후
4. Viewer Response: CloudFront가 사용자에게 최종 응답을 보내기 직전

구분	CloudFront Functions	Lambda@Edge
트리거	Viewer Request/Response	Viewer + Origin Request/Response
실행 시간	1ms 미만	5초 (Viewer), 30초 (Origin)
메모리	2MB	128MB ~ 10GB
네트워크	접근 불가	접근 가능
Request Body	접근 불가	접근 가능
주요 용도	헤더 조작, URL 재작성, 캐시 키 정규화	외부 API 호출, 복잡한 인증, 이미지 리사이징
배포	CloudFront 내에서 관리	리전에 함수 생성 후 연결

---

Amazon DynamoDB: 서버리스 NoSQL 데이터베이스

DynamoDB는 AWS의 완전 관리형 NoSQL 데이터베이스로, 여러 가용 영역(AZ)에 데이터가 자동 복제되어 고가용성을 제공함 한 자릿수 밀리초의 빠르고 일관된 성능을 자랑하며, 트래픽에 따라 자동으로 확장되어 대규모 워크로드에 적합함

 

주요 특징

• 유연한 스키마: 관계형 데이터베이스와 달리 테이블 생성 시 기본 키(Primary Key)만 정의하면, 각 항목(Item, RDB의 행)마다 다른 속성(Attribute, RDB의 열)을 가질 수 있음 이를 통해 애플리케이션 요구사항 변경에 따라 스키마를 빠르고 유연하게 확장할 수 있음
• 테이블 클래스: 자주 액세스하는 데이터에는 Standard 클래스를, 자주 액세스하지 않는 데이터에는 저렴한 Infrequent Access(IA) 클래스를 선택하여 비용을 최적화할 수 있음

고급 기능 및 통합

• DAX (DynamoDB Accelerator): DynamoDB를 위한 완전 관리형 인메모리 캐시로, 읽기 성능을 마이크로초 단위로 향상시킴
• 스트림 처리 (Stream Processing): 테이블의 데이터 변경 내역을 실시간으로 캡처하여 Lambda 함수 호출(예: 신규 유저 가입 시 환영 이메일 발송), 실시간 분석 등 다양한 이벤트 기반 아키텍처를 구현할 수 있음 (24시간 보존되는 DynamoDB Streams 또는 최대 1년 보존되는 Kinesis Data Streams 연동 방식 선택 가능)
• 글로벌 테이블 (Global Tables): 여러 리전에 걸쳐 테이블을 액티브-액티브 형태로 복제하여, 전 세계 사용자에게 낮은 지연 시간의 읽기/쓰기 성능을 제공함
• TTL (Time To Live): 설정된 만료 시간이 지나면 항목을 자동으로 삭제하여, 웹 세션 데이터 관리나 데이터 보관 정책을 손쉽게 구현함
• 백업 및 복구: PITR(최근 35일 내 시점 복구)과 온디맨드 백업(장기 보관)을 지원하며, 복구 시에는 항상 새로운 테이블이 생성됨
• S3와의 통합: 테이블 데이터를 S3로 내보내어(Export) Athena로 분석하거나, S3의 데이터를 가져와(Import) 새로운 테이블을 생성할 수 있음

용량 모드 (Capacity Modes)

테이블의 읽기/쓰기 처리량을 관리하는 두 가지 방식 중 하나를 선택해야 함

1. 프로비저닝 모드 (Provisioned Mode)
   • 개념: 초당 처리할 읽기(RCU) 및 쓰기(WCU) 용량을 미리 예측하여 할당하는 방식임
   • 특징: 예측 가능하고 꾸준한 트래픽에 적합하며, 오토 스케일링을 통해 할당된 용량을 자동으로 조절할 수 있음 일반적으로 온디맨드 모드보다 비용 효율적임
2. 온디맨드 모드 (On-Demand Mode)
   • 개념: 별도의 용량 계획 없이, 실제 발생하는 트래픽에 맞춰 용량이 자동으로 확장 및 축소되는 방식임
   • 특징: 사용한 만큼만 비용을 지불하며, 트래픽을 예측할 수 없거나 갑작스럽게 급증하는 워크로드에 매우 유용함

주요 제약사항 및 고려사항

• 항목(Item) 크기 제한: 단일 항목의 크기는 400KB를 초과할 수 없음
• 핫 파티션(Hot Partition): 파티션 키를 잘못 설계하여 특정 파티션에 읽기/쓰기 요청이 집중되면, 전체 테이블의 성능이 저하되는 '핫 파티션' 문제가 발생할 수 있음
• 인덱스(Index): SQL의 WHERE 절과 유사한 검색 기능을 위해 **GSI(Global Secondary Index)**와 **LSI(Local Secondary Index)**를 사용할 수 있으며, 각각의 특징과 제약이 뚜렷함
• 트랜잭션(Transaction): 여러 항목을 원자적으로 읽거나 쓸 수 있는 트랜잭션 기능을 지원하지만, 일반 작업보다 2배의 용량 유닛을 소모하여 비용이 더 비

---

AWS API Gateway: 서버리스 API의 관문

Lambda 함수나 다른 백엔드 서비스를 위한 REST/HTTP API 또는 WebSocket API를 생성, 관리, 보호하는 완전 관리형 서비스임 클라이언트가 백엔드 서비스에 직접 접근하는 대신, API Gateway가 제공하는 단일 엔드포인트를 통해 통신하도록 하는 '관문' 역할을 함

 

주요 기능

• API 관리: API 버전 관리(v1, v2), 개발/테스트/프로덕션 환경(Stage) 분리, API 키 발급 및 사용량 계획(Usage Plan)을 통한 요청 제어(Throttling)가 가능함
• 성능 향상: API 응답을 캐싱하여 반복적인 요청에 대한 지연 시간을 줄일 수 있음
• 개발 편의성: OpenAPI(Swagger) 명세를 통해 API를 신속하게 정의하고 SDK를 생성할 수 있음

통합 유형 (백엔드 연동)

• Lambda 함수 통합: API 요청을 받아 Lambda 함수를 호출하는 가장 대표적인 서버리스 패턴임
• HTTP 통합: 기존에 존재하는 HTTP 엔드포인트(ALB, 온프레미스 API 등)를 백엔드로 지정하여, API Gateway의 인증, 캐싱, 사용량 제어 등의 기능을 추가할 수 있음
• AWS 서비스 통합: SQS에 메시지를 보내거나 Step Functions를 실행하는 등 다른 AWS 서비스의 API를 직접 호출하는 엔드포인트를 생성할 수 있음

엔드포인트 유형 (배포 방식)

• 엣지 최적화 (Edge-Optimized): 기본값. CloudFront를 통해 전 세계 사용자에게 낮은 지연 시간을 제공함
• 리전 (Regional): 특정 리전 내 사용자에게 최적화되어 있음
• 프라이빗 (Private): VPC 내부에서만 접근 가능한 API를 생성함

보안

• 인증: IAM 역할(내부용), Amazon Cognito(외부 사용자용), 사용자 지정 권한 부여(Custom Authorizer)(Lambda 기반 자체 로직) 등 다양한 인증 방식을 제공함
• HTTPS: AWS Certificate Manager(ACM)와 연동하여 사용자 지정 도메인에 HTTPS를 적용함

주요 제약사항

• 통합 제한 시간: 백엔드(Lambda 등)의 최대 실행 시간과 관계없이, API Gateway는 29초 이내에 응답을 받지 못하면 타임아웃 오류를 반환함
• 페이로드 크기: 요청 및 응답의 최대 크기는 10MB로 제한됨

---

AWS Step Functions: 서버리스 워크플로우 오케스트레이션

Step Functions는 여러 Lambda 함수와 AWS 서비스 호출들을 시각적인 워크플로우로 엮어, 복잡한 비즈니스 로직과 데이터 처리 파이프라인을 손쉽게 구성하고 자동화하는 서버리스 오케스트레이션 서비스임

 

주요 기능 및 특징

• 시각적 워크플로우: 각 단계를 순서도처럼 시각적으로 설계하고, 실행 상태를 모니터링할 수 있음
• 워크플로우 제어: 순차 실행, 병렬 실행, 조건부 분기(if/then), 시간제한, 자동 재시도 및 에러 처리 등 정교한 로직 제어가 가능함
• 다양한 서비스 통합: Lambda 함수 외에도 EC2, ECS, API Gateway, SQS 등 거의 모든 AWS 서비스와 통합하여 워크플로우를 구성할 수 있음
• 사람의 승인(Human Approval): 워크플로우 중간에 관리자의 승인을 기다렸다가 다음 단계를 진행하는 등 수동 개입이 필요한 프로세스를 자동화할 수 있음

주요 사용 사례

• 주문 처리: '주문 접수 → 재고 확인 → 결제 처리 → 배송 요청'과 같은 다단계 프로세스를 자동화함
• 데이터 처리: 여러 단계로 구성된 ETL(Extract, Transform, Load) 파이프라인을 구축함
• 마이크로서비스 오케스트레이션: 여러 마이크로서비스를 조합하여 하나의 비즈니스 로직을 완성함

워크플로우 종류

• Standard: 최대 1년간 실행 가능하며, 모든 실행 단계의 감사 기록을 제공함 신뢰성이 중요한 긴 작업에 적합하지만, 상태 전환당 과금되어 비쌀 수 있음
• Express: 최대 5분간 실행되며, 초당 수만 건의 고속 처리를 위해 설계되었음 실행 로그만 제공되며, 저렴함

 

---

Amazon Cognito: 사용자 인증 및 권한 부여

Cognito는 웹 및 모바일 애플리케이션의 외부 최종 사용자를 위한 인증(Authentication) 및 **권한 부여(Authorization)**를 처리하는 완전 관리형 서비스임 두 가지 핵심 구성 요소로 나뉨

 

1. Cognito User Pools (사용자 풀) - "인증"

역할: "당신은 누구입니까?"를 확인하는, 서버리스 사용자 데이터베이스임

• 주요 기능:
  • 사용자 가입 및 로그인, 비밀번호 관리, 이메일/전화번호 인증, 다중 인증(MFA) 기능을 제공함
  • 구글, 페이스북 등 소셜 로그인을 연동할 수 있음
• 통합: API Gateway나 **Application Load Balancer(ALB)**와 통합하여, 백엔드 애플리케이션에 도달하기 전에 사용자 인증을 미리 처리할 수 있음 인증된 사용자의 정보는 토큰 형태로 백엔드에 전달됨

2. Cognito Identity Pools (자격 증명 풀) - "권한 부여"

역할: "당신은 무엇을 할 수 있습니까?"를 결정하는, 임시 AWS 자격 증명 발급 서비스임

• 주요 기능:
  • User Pool, 소셜 로그인 등을 통해 인증된 사용자에게, 특정 IAM 역할(Role)이 연결된 임시 AWS 자격 증명을 발급해 
  • 사용자는 이 임시 자격 증명을 사용하여 허용된 AWS 리소스(예: S3 버킷의 특정 폴더, DynamoDB 테이블의 특정 항목)에 애플리케이션 백엔드를 거치지 않고 직접 접근할 수 있음
• 활용: DynamoDB의 '행 수준 보안'처럼, 로그인한 사용자가 오직 자신의 데이터에만 접근하도록 하는 세분화된 권한 제어를 구현하는 데 매우 강력함

---

AWS SAA 시험 대비: 서버리스 핵심 패턴 요약

AWS 공인 솔루션스 아키텍트 - 어소시에이트(SAA) 시험은 각 서비스의 단순 기능보다, 특정 문제 상황에 어떤 아키텍처를 적용하여 해결하는지를 묻는 데 중점을 둠, 아래는 시험에 자주 출제되는 서버리스 서비스의 핵심 시나리오와 솔루션 패턴임

1. AWS Lambda: 한계점과 해

결 방안

Lambda의 본질적인 제약을 이해하고, 이를 극복하기 위한 아키텍처를 선택하는 능력을 평가함

• 문제: 콜드 스타트 (Cold Start)
  • 상황: 함수가 처음 호출되거나 오랜만에 호출되어 응답 지연이 발생하는 경우.
  • 해결책: **프로비저닝된 동시성(Provisioned Concurrency)**을 설정하여 함수를 항상 활성화된 상태로 유지함 단, 유휴 시간에도 비용이 발생하는 트레이드오프가 있음을 이해해야 함
• 문제: 실행 시간 제한 (15분)
  • 상황: 15분을 초과하는 장시간 데이터 처리나 배치 작업이 필요한 경우.
  • 해결책: Lambda 대신 AWS Step Functions로 여러 Lambda를 조합하거나, 컨테이너 기반의 ECS/Fargate, 또는 가상 서버인 EC2를 사용하는 아키텍처를 선택함

2. 비동기 아키텍처 패턴

서비스 간의 결합도를 낮추고 안정성을 높이는 비동기 처리 패턴을 이해하고 있는지 평가함

• 문제: API Gateway 타임아웃 (29초)
  • 상황: API 요청 후 백엔드 작업이 30초 이상 소요되어 API Gateway에서 타임아웃이 발생하는 경우.
  • 해결책: API Gateway는 Lambda를 동기 호출하는 대신, 요청을 즉시 SQS 큐에 전달하고 "요청 접수 완료" 응답을 보냄, 별도의 Lambda 함수가 이 큐를 구독하여 비동기적으로 긴 작업을 처리하는 패턴을 적용함
• 문제: Lambda와 RDS의 직접 연동
  • 상황: 다수의 Lambda 함수가 동시에 실행되어 RDS 데이터베이스의 최대 커넥션 수를 초과시키는 경우.
  • 해결책: Lambda와 RDS 사이에 RDS Proxy를 배치하여 커넥션을 풀링(pooling)하고 공유함으로써, 데이터베이스의 부하를 줄이고 안정성을 높임

3. DynamoDB 설계 핵심

NoSQL 데이터베이스인 DynamoDB의 성능과 비용을 좌우하는 핵심 설계 원칙을 이해하고 있는지 평가함

• 문제: 핫 파티션 (Hot Partition)
  • 상황: 특정 파티션 키에 읽기/쓰기 요청이 집중되어 전체 테이블의 성능이 저하되는 경우.
  • 해결책: 파티션 키를 요청이 고르게 분산될 수 있도록 높은 카디널리티(Cardinality)를 가진 값으로 설계함
• 개념: GSI vs. LSI
  • 핵심 차이: **GSI(글로벌 보조 인덱스)**는 테이블 생성 후에도 언제든지 추가/삭제가 가능하지만, **LSI(로컬 보조 인덱스)**는 테이블을 생성할 때만 정의할 수 있다는 점을 명확히 구분해야 함

4. 서버리스 구성 요소의 역할 구분

각 서비스의 고유한 역할을 명확히 이해하고 올바른 서비스 조합을 선택하는 능력을 평가함

• 개념: Cognito User Pools vs. Identity Pools
  • User Pools: 인증(Authentication) 담당. "당신은 누구입니까?" (사용자 가입, 로그인 기능 제공)
  • Identity Pools: 권한 부여(Authorization) 담당. "당신은 무엇을 할 수 있습니까?" (인증된 사용자에게 임시 AWS 자격 증명 발급)
• 개념: Step Functions Standard vs. Express
  • Standard: 신뢰성이 중요한 장기 실행(최대 1년) 워크플로우. 모든 단계가 기록/감사 가능.
  • Express: 속도와 비용이 중요한 단기 실행(최대 5분) 고속 워크플로우.

5. 서버리스 최적화 방안

Lambda의 효율성과 보안을 높이는 추가적인 방법을 알고 있는지 평가함

• 개념: Lambda Layer
  • 상황: 여러 Lambda 함수에서 공통으로 사용되는 라이브러리나 종속성이 있을 경우.
  • 해결책: 공통 코드를 Lambda Layer로 분리하여 코드 재사용성을 높이고, 개별 함수의 배포 패키지 크기를 줄여 관리 효율성을 높임
• 개념: RDS Proxy의 추가 이점
  • 상황: Lambda-RDS 연동 시 성능뿐만 아니라 가용성도 고려해야 할 경우.
  • 지식: RDS Proxy는 커넥션 풀링 외에도, DB 장애 조치 발생 시 애플리케이션의 연결을 보존하여 다운타임을 최대 66%까지 단축시키는 중요한 가용성 이점을 제공함