기본적인 서버리스 아키텍쳐

클라이언트 → Cognito → api gateway → lambda → DAX → DynamoDB → S3 접근

글로벌 서버리스 아키텍쳐 + 이벤트 시 이메일 전송

정적 파일 : S3(CloudFront로만 인바운드 Policy 부여) → CloudFront

동적 파일: api gateway → Lambda → DAX → DynamoDB (global Tables) ⇒ DynamoDB Stream → Lambda → Amazon Simple Email Service(SES)

MSA (마이크로 서비스 아키텍쳐)

→ 참고사항

→ MSA에서는 api gateway → lambda || ALB → ECS 의 구조. 아래는 MSA에서 ELB, ASG를 적용한 아키텍쳐 정리본

[API Gateway]
   ↓ VPC Link (1개)
[ALB 1개]
   │
   ├── Listener Rule: /orders/* → Target Group A (ALB의 라우팅 기법 사용)
   │        ↑ (등록/해제)
   │    [ECS Service A] ← CloudWatch 지표 보고 Auto Scaling (EC2의 ASG같은)
   │        └── Task 1, 2, 3, 4, 5...
   │
   ├── Listener Rule: /payments/* → Target Group B
   │        ↑
   │    [ECS Service B] ← 독립적으로 Auto Scaling
   │        └── Task 1, 2, 3...
   │
   └── Listener Rule: /notify/* → Target Group C
            ↑
        [ECS Service C] ← 독립적으로 Auto Scaling
            └── Task 1, 2...
            
            
  -> 즉, ALB는 N개의 Target Group을 도메인 기준으로 라우팅함.
  -> ASG를 위해 각 TG마다 CloudWatch를 모니터링함
  -> Api Gateway는 입구 (+ api제한, Cognito 등 부가 기능)

SW updates offloading

문제상황

"우리 회사가 만든 소프트웨어(예: 게임, 앱, 펌웨어)를 
 전 세계 수백만 명의 사용자에게 배포해야 함"

예: 
   "새 게임 패치가 나옴 → 전 세계 100만 명이 동시에 다운로드 시도"
   "IoT 기기 100만 대가 새벽에 동시에 펌웨어 업데이트 확인"

CloudFront를 사용한다면?

[CloudFront 없이]
사용자 100만 명 → 전부 서울의 S3/서버로 직접 요청
   → S3/서버가 100만 번의 요청을 전부 직접 처리해야 함

[CloudFront 사용]
사용자 100만 명 → 각자 가까운 엣지 로케이션(도쿄, 뉴욕, 런던 등)에서 다운로드
   → 각 엣지 로케이션은 캐시에 없으면 S3에 "딱 1번만" 요청해서 캐싱
   → S3는 실제로는 "엣지 로케이션 개수(수백 개)"만큼만 요청받음
   → 100만 개의 요청 대부분이 S3까지 도달하지 않고 엣지에서 처리됨

참고 (정적 파일 vs 동적 파일)

정적 파일 (CloudFront 캐싱에 적합):
   - 소프트웨어 설치 파일(.exe, .apk, .zip)
   - 게임 패치 파일
   - 이미지, 동영상
   - CSS, JavaScript, HTML (웹사이트의 고정된 자원)
   - PDF 문서

동적 콘텐츠 (캐싱이 어렵거나 별도 전략 필요):
   - "내 계정 정보 조회 API" (사용자마다 다름)
   - "실시간 채팅 메시지"
   - "장바구니 상태"
   - 로그인 상태에 따라 달라지는 페이지