AWS Other Serverless 정리
AWSStep FunctionsAppSyncAmplifyDVA-C02
작성자 : 오예환 | 작성일 : 2026-01-18 | 수정일 : 2026-01-18
1. AWS Step Functions 개요
🤔 Step Functions가 뭔가요?
비유로 이해하기: 자동화된 조립 라인과 같습니다.
- 자동차 공장: 부품 조립 → 페인트 → 검수 → 출고
- Step Functions: Lambda 호출 → DynamoDB 저장 → SNS 알림 → 완료
- 각 단계가 순서대로 자동 실행!
┌─────────────────────────────────────────────────────────────────┐
│ Step Functions 개념 │
│ │
│ 기존 방식 (코드로 직접 연결): │
│ Lambda1 → if 성공 → Lambda2 → if 성공 → Lambda3 → ... │
│ └→ if 실패 → 에러 처리 → 재시도 → ... │
│ ⚠️ 복잡하고 에러 처리 어려움! │
│ │
│ Step Functions 사용: │
│ ┌──────────────────────────────────────────┐ │
│ │ [Start] → [Lambda1] → [Lambda2] → [End] │ │
│ │ ↓ │ │
│ │ [Error Handler] │ │
│ └──────────────────────────────────────────┘ │
│ ✅ 시각적으로 워크플로우 관리, 자동 에러 처리! │
│ │
└─────────────────────────────────────────────────────────────────┘Step Functions 특징
| 특징 | 설명 | 설명 |
|---|---|---|
| State Machine | 워크플로우당 1개 | 작업 흐름도 1개 |
| JSON 정의 | 워크플로우를 JSON으로 작성 | 코드처럼 버전 관리 가능 |
| 시각화 | 실행 과정을 그래프로 | 어디서 멈췄는지 한눈에! |
| 히스토리 | 실행 이력 저장 | 과거 실행 결과 확인 |
사용 사례
| 사례 | 설명 |
|---|---|
| 주문 처리 | 결제 → 재고 확인 → 배송 → 알림 |
| 데이터 처리 | 수집 → 변환 → 저장 → 분석 |
| 사용자 가입 | 이메일 확인 → 계정 생성 → 환영 메일 |
| 승인 워크플로우 | 요청 → 검토 → 승인/거부 → 알림 |
워크플로우 시작 방법
Step Functions 워크플로우 시작 방법:
1. SDK 호출
client.start_execution(stateMachineArn, input)
2. API Gateway
POST /orders → API Gateway → Step Functions
3. EventBridge (CloudWatch Events)
매일 오전 9시 → Step Functions 실행2. Step Functions - Task States
🤔 Task State가 뭔가요?
비유로 이해하기: 실제 일을 하는 단계입니다.
- 회의실 예약 워크플로우에서
- "빈 회의실 찾기" → 실제 DB 조회 (Task)
- "예약하기" → 실제 예약 저장 (Task)
Task로 호출 가능한 서비스
┌─────────────────────────────────────────────────────────────────┐
│ Task State가 할 수 있는 일 │
│ │
│ AWS 서비스 호출: │
│ ├─ Lambda: 함수 실행 │
│ ├─ AWS Batch: 배치 작업 실행 │
│ ├─ ECS: 컨테이너 태스크 실행 (완료까지 대기) │
│ ├─ DynamoDB: 아이템 추가/조회/수정 │
│ ├─ SNS: 알림 발송 │
│ ├─ SQS: 메시지 전송 │
│ └─ 다른 Step Functions: 중첩 워크플로우 │
│ │
│ Activity 실행: │
│ ├─ EC2에서 실행되는 앱 │
│ ├─ ECS 컨테이너 │
│ └─ 온프레미스 서버 │
│ ↓ │
│ Activity는 Step Functions에서 작업을 "가져가서" │
│ 처리하고 결과를 "돌려주는" 방식 │
│ │
└─────────────────────────────────────────────────────────────────┘Lambda 호출 예시 (JSON)
{
"Comment": "주문 처리 워크플로우",
"StartAt": "ProcessOrder",
"States": {
"ProcessOrder": {
"Type": "Task",
"Resource": "arn:aws:lambda:us-east-1:123456789012:function:ProcessOrder",
"Next": "SendNotification"
},
"SendNotification": {
"Type": "Task",
"Resource": "arn:aws:lambda:us-east-1:123456789012:function:SendEmail",
"End": true
}
}
}3. Step Functions - State Types
🤔 어떤 종류의 State가 있나요?
State 종류 한눈에 보기
| State | 설명 | 비유 |
|---|---|---|
| Task | 실제 작업 수행 | 일하는 직원 |
| Choice | 조건 분기 | 갈림길 표지판 |
| Fail/Succeed | 실행 종료 | 결승선 |
| Pass | 데이터 전달만 | 릴레이 바톤 |
| Wait | 대기 | 휴식 시간 |
| Map | 반복 처리 | 대량 생산 라인 |
| Parallel | 동시 실행 | 여러 라인 동시 가동 |
Choice State (조건 분기)
┌─────────────────────────────────────────────────────────────────┐
│ Choice State 예시 │
│ │
│ [주문 금액 확인] │
│ │ │
│ ┌─────────────┼─────────────┐ │
│ ↓ ↓ ↓ │
│ 금액 < 100 100 ≤ 금액 < 1000 금액 ≥ 1000 │
│ │ │ │ │
│ ↓ ↓ ↓ │
│ [일반 배송] [무료 배송] [VIP 배송] │
│ │
└─────────────────────────────────────────────────────────────────┘{
"Type": "Choice",
"Choices": [
{
"Variable": "$.orderAmount",
"NumericLessThan": 100,
"Next": "NormalShipping"
},
{
"Variable": "$.orderAmount",
"NumericGreaterThanEquals": 1000,
"Next": "VIPShipping"
}
],
"Default": "FreeShipping"
}Wait State (대기)
// 10초 대기
{
"Type": "Wait",
"Seconds": 10,
"Next": "NextState"
}
// 특정 시간까지 대기
{
"Type": "Wait",
"Timestamp": "2024-12-31T23:59:59Z",
"Next": "NewYearState"
}Parallel State (병렬 실행)
┌─────────────────────────────────────────────────────────────────┐
│ Parallel State 예시 │
│ │
│ [주문 접수] │
│ │ │
│ ┌───────────┼───────────┐ │
│ ↓ ↓ ↓ │
│ [재고 확인] [결제 처리] [배송 준비] ← 동시 실행! │
│ │ │ │ │
│ └───────────┼───────────┘ │
│ ↓ │
│ [모든 작업 완료] │
│ │ │
│ ↓ │
│ [주문 완료] │
│ │
└─────────────────────────────────────────────────────────────────┘Map State (반복 처리)
┌─────────────────────────────────────────────────────────────────┐
│ Map State 예시 │
│ │
│ 입력: [item1, item2, item3, item4, item5] │
│ │ │
│ ↓ │
│ ┌─── Map State ───┐ │
│ │ │ │
│ │ [Process Item] ← 각 아이템에 대해 반복 실행 │
│ │ │ │
│ └──────────────────┘ │
│ │ │
│ ↓ │
│ 출력: [result1, result2, result3, result4, result5] │
│ │
└─────────────────────────────────────────────────────────────────┘4. Step Functions - Error Handling
🤔 에러 처리가 왜 중요한가요?
비유로 이해하기: 자동차 공장에서 불량품 처리 라인과 같습니다.
- 조립 중 불량 발생 → 수리 라인으로 이동
- 수리 불가 → 폐기 라인으로 이동
- Step Functions도 에러 발생 시 자동으로 처리!
에러 발생 원인
| 원인 | 예시 |
|---|---|
| 정의 오류 | Choice State에 매칭 규칙 없음 |
| 작업 실패 | Lambda 함수에서 예외 발생 |
| 일시적 문제 | 네트워크 장애 |
미리 정의된 에러 코드
| 에러 코드 | 설명 |
|---|---|
States.ALL | 모든 에러 (와일드카드) |
States.Timeout | 타임아웃 |
States.TaskFailed | Task 실행 실패 |
States.Permissions | 권한 부족 |
🔄 Retry (재시도)
{
"Type": "Task",
"Resource": "arn:aws:lambda:...",
"Retry": [
{
"ErrorEquals": ["States.Timeout"],
"IntervalSeconds": 3,
"MaxAttempts": 2,
"BackoffRate": 1.5
},
{
"ErrorEquals": ["States.ALL"],
"IntervalSeconds": 1,
"MaxAttempts": 3,
"BackoffRate": 2.0
}
],
"Next": "NextState"
}Retry 옵션 설명:
| 옵션 | 설명 | 예시 |
|---|---|---|
| ErrorEquals | 어떤 에러에 대해 | ["States.Timeout"] |
| IntervalSeconds | 첫 재시도 대기 시간 | 3초 |
| BackoffRate | 대기 시간 증가율 | 1.5배씩 |
| MaxAttempts | 최대 재시도 횟수 | 3회 (기본값) |
재시도 흐름:
1차 시도 실패 → 3초 대기 → 2차 시도
2차 시도 실패 → 4.5초(3×1.5) 대기 → 3차 시도
3차 시도 실패 → Catch로 이동!🎣 Catch (에러 잡기)
{
"Type": "Task",
"Resource": "arn:aws:lambda:...",
"Catch": [
{
"ErrorEquals": ["CustomError"],
"Next": "CustomErrorHandler"
},
{
"ErrorEquals": ["States.ALL"],
"Next": "DefaultErrorHandler",
"ResultPath": "$.error"
}
],
"Next": "SuccessState"
}Catch 옵션 설명:
| 옵션 | 설명 |
|---|---|
| ErrorEquals | 어떤 에러를 잡을지 |
| Next | 에러 시 이동할 State |
| ResultPath | 에러 정보를 어디에 저장할지 |
ResultPath로 에러 정보 포함
┌─────────────────────────────────────────────────────────────────┐
│ ResultPath 사용 예시 │
│ │
│ 입력 데이터: │
│ { │
│ "orderId": "12345", │
│ "amount": 100 │
│ } │
│ │
│ 에러 발생 + ResultPath: "$.error" │
│ │
│ 출력 데이터: │
│ { │
│ "orderId": "12345", │
│ "amount": 100, │
│ "error": { ← 에러 정보 추가! │
│ "Error": "States.TaskFailed", │
│ "Cause": "Lambda function failed" │
│ } │
│ } │
│ │
└─────────────────────────────────────────────────────────────────┘5. Step Functions - Wait for Task Token
🤔 이게 뭔가요?
비유로 이해하기: 티켓 발급 후 대기와 같습니다.
- 은행에서 번호표(Task Token) 받음
- 직원이 처리하는 동안 대기
- 처리 완료되면 번호 호출 (SendTaskSuccess)
사용 사례
| 사례 | 설명 |
|---|---|
| 사람 승인 | 관리자가 승인 버튼 클릭할 때까지 대기 |
| 외부 시스템 | 3rd Party API 응답 대기 |
| 비동기 처리 | 오래 걸리는 작업 완료 대기 |
동작 방식
┌─────────────────────────────────────────────────────────────────┐
│ Wait for Task Token │
│ │
│ 1. Step Functions가 Task Token과 함께 SQS에 메시지 전송 │
│ ┌───────────┐ │
│ │ Step │ ──TaskToken + 데이터──→ [SQS Queue] │
│ │ Functions │ │
│ └───────────┘ │
│ ⏸️ 대기 중... │
│ │
│ 2. Worker가 SQS에서 메시지 가져와서 처리 │
│ ┌────────────────┐ │
│ [SQS Queue] ──────→ │ Lambda/EC2/ECS │ │
│ │ (Worker) │ │
│ └────────────────┘ │
│ │ │
│ ↓ 처리 완료! │
│ │
│ 3. Worker가 SendTaskSuccess API 호출 │
│ ┌───────────┐ SendTaskSuccess(TaskToken, Result) │
│ │ Step │ ←───────────────────────────────────────── │
│ │ Functions │ │
│ └───────────┘ │
│ ▶️ 다음 단계로! │
│ │
└─────────────────────────────────────────────────────────────────┘코드 예시
Step Functions 정의:
{
"Type": "Task",
"Resource": "arn:aws:states:::sqs:sendMessage.waitForTaskToken",
"Parameters": {
"QueueUrl": "https://sqs.us-east-1.amazonaws.com/123456789/MyQueue",
"MessageBody": {
"Input.$": "$",
"TaskToken.$": "$$.Task.Token"
}
},
"Next": "NextState"
}Worker (Lambda)에서 완료 알림:
import boto3
stepfunctions = boto3.client('stepfunctions')
def lambda_handler(event, context):
task_token = event['TaskToken']
# 작업 처리...
result = process_task(event['Input'])
# 완료 알림!
stepfunctions.send_task_success(
taskToken=task_token,
output=json.dumps(result)
)6. Step Functions - Activity Tasks
🤔 Activity가 뭔가요?
비유로 이해하기: 배달 기사 앱과 같습니다.
- 기사가 앱에서 주문을 가져감 (Poll)
- 배달 완료 후 완료 처리 (SendTaskSuccess)
- Step Functions는 기다리다가 완료되면 다음 단계로
Task Token vs Activity
| 방식 | 동작 | 사용 사례 |
|---|---|---|
| Task Token | Step Functions → Worker로 전송 | Lambda, SQS |
| Activity | Worker → Step Functions에서 가져감 | EC2, 온프레미스 |
Activity 동작 방식
┌─────────────────────────────────────────────────────────────────┐
│ Activity Task 동작 │
│ │
│ 1. Activity Worker가 작업 요청 (Polling) │
│ │
│ ┌────────────────┐ GetActivityTask API ┌───────────┐ │
│ │ EC2 Instance │ ──────────────────────────→ │ Step │ │
│ │ (Activity │ │ Functions │ │
│ │ Worker) │ ←────────────────────────── │ │ │
│ └────────────────┘ Task + TaskToken └───────────┘ │
│ │
│ 2. Worker가 작업 처리 (오래 걸릴 수 있음) │
│ │
│ ┌────────────────┐ SendTaskHeartBeat ┌───────────┐ │
│ │ EC2 Instance │ ──────────────────────────→ │ Step │ │
│ │ (처리 중...) │ "아직 살아있어요!" │ Functions │ │
│ └────────────────┘ └───────────┘ │
│ │
│ 3. 작업 완료 알림 │
│ │
│ ┌────────────────┐ SendTaskSuccess ┌───────────┐ │
│ │ EC2 Instance │ ──────────────────────────→ │ Step │ │
│ │ (완료!) │ + 결과 데이터 │ Functions │ │
│ └────────────────┘ └───────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘Heartbeat (심장박동)
문제: 작업이 오래 걸리면 Step Functions가 "죽었나?" 라고 생각할 수 있음 해결: 주기적으로 "살아있어요!" 신호 전송
| 설정 | 설명 |
|---|---|
| TimeoutSeconds | 최대 대기 시간 |
| HeartBeatSeconds | Heartbeat 전송 간격 |
💡 최대 1년까지 대기 가능! TimeoutSeconds를 길게 + Heartbeat 꾸준히 전송
7. Step Functions - Standard vs Express
🤔 뭐가 다른가요?
비유로 이해하기:
- Standard: 은행 업무 (정확하게, 기록 남기고)
- Express: 편의점 계산 (빠르게, 간단하게)
비교표
| 항목 | Standard | Express |
|---|---|---|
| 최대 시간 | 1년 | 5분 |
| 실행 모델 | Exactly-once | At-least-once / At-most-once |
| 초당 실행 | 2,000+ | 100,000+ |
| 실행 기록 | 90일 저장 | CloudWatch Logs |
| 과금 | State 전환 횟수 | 실행 횟수, 시간, 메모리 |
Express 종류
| 종류 | 설명 | 사용 사례 |
|---|---|---|
| Asynchronous | 결과 기다리지 않음 | 이벤트 처리, IoT |
| Synchronous | 결과 기다림 | API 응답, 마이크로서비스 |
선택 가이드
┌─────────────────────────────────────────────────────────────────┐
│ Standard vs Express 선택 │
│ │
│ Q1. 5분 이상 걸릴 수 있나요? │
│ ├─ Yes → Standard │
│ └─ No → Q2로 │
│ │
│ Q2. 결제, 주문 등 정확히 1번만 실행되어야 하나요? │
│ ├─ Yes → Standard (Exactly-once) │
│ └─ No → Q3로 │
│ │
│ Q3. 초당 수만 건 이상 처리해야 하나요? │
│ ├─ Yes → Express │
│ └─ No → Standard (기본) │
│ │
└─────────────────────────────────────────────────────────────────┘사용 사례
| 유형 | 사례 |
|---|---|
| Standard | 결제 처리, 주문 워크플로우, 승인 프로세스 |
| Express Async | IoT 데이터 수집, 스트리밍 처리 |
| Express Sync | API Gateway 백엔드, 마이크로서비스 오케스트레이션 |
8. AWS AppSync 개요
🤔 AppSync가 뭔가요?
비유로 이해하기: 만능 데이터 웨이터와 같습니다.
- 손님(클라이언트): "스테이크(사용자 정보)랑 와인(주문 내역) 주세요"
- 웨이터(AppSync): 주방A(DynamoDB)에서 스테이크, 주방B(RDS)에서 와인 가져옴
- 한 번의 요청으로 여러 데이터 소스에서 정확히 필요한 것만!
REST API vs GraphQL
┌─────────────────────────────────────────────────────────────────┐
│ REST vs GraphQL │
│ │
│ REST API (기존 방식): │
│ GET /users/123 → 사용자 전체 정보 (불필요한 것도) │
│ GET /users/123/orders → 주문 목록 │
│ GET /orders/456 → 주문 상세 │
│ → 3번 호출, 과다/과소 데이터 문제 │
│ │
│ GraphQL (AppSync): │
│ query { │
│ user(id: "123") { │
│ name ← 이름만! │
│ orders { │
│ id │
│ total ← 필요한 필드만! │
│ } │
│ } │
│ } │
│ → 1번 호출, 정확히 필요한 데이터만! │
│ │
└─────────────────────────────────────────────────────────────────┘AppSync 특징
| 특징 | 설명 |
|---|---|
| GraphQL | 필요한 데이터만 요청 |
| 다중 데이터 소스 | DynamoDB, Aurora, Lambda, HTTP API... |
| 실시간 | WebSocket, MQTT |
| 오프라인 동기화 | 모바일 앱에서 오프라인 → 온라인 시 동기화 |
AppSync 아키텍처
┌─────────────────────────────────────────────────────────────────┐
│ AppSync 아키텍처 │
│ │
│ ┌─────────────┐ │
│ │ Web App │─┐ │
│ └─────────────┘ │ ┌───────────────────┐ │
│ ┌─────────────┐ │ │ │ │
│ │ Mobile App │─┼─────→│ AppSync │ │
│ └─────────────┘ │ │ │ │
│ ┌─────────────┐ │ │ GraphQL Schema │ │
│ │ Real-time │─┘ │ + Resolvers │ │
│ │ Dashboard │ │ │ │
│ └─────────────┘ └─────────┬─────────┘ │
│ │ │
│ ┌─────────────────────────┼───────────────────────┐ │
│ ↓ ↓ ↓ ↓ ↓ │
│ ┌─────────┐ ┌─────────┐ ┌───────────┐ ┌────────┐ ┌──────┐ │
│ │DynamoDB │ │ Aurora │ │OpenSearch │ │ Lambda │ │ HTTP │ │
│ └─────────┘ └─────────┘ └───────────┘ └────────┘ └──────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘AppSync 보안
| 인증 방식 | 설명 | 사용 사례 |
|---|---|---|
| API_KEY | 간단한 API 키 | 퍼블릭 API, 프로토타입 |
| AWS_IAM | IAM 사용자/역할 | AWS 서비스 간 연동 |
| OPENID_CONNECT | OIDC/JWT | 외부 IdP 연동 |
| COGNITO_USER_POOLS | Cognito | 모바일/웹 앱 사용자 |
💡 커스텀 도메인 + HTTPS → CloudFront를 AppSync 앞에 배치
9. AWS Amplify 개요
🤔 Amplify가 뭔가요?
비유로 이해하기: 앱 개발 올인원 패키지입니다.
- 프론트엔드 개발자가 백엔드 걱정 없이 풀스택 앱 만들기
- "모바일/웹 앱을 위한 Elastic Beanstalk"
Amplify 구성 요소
┌─────────────────────────────────────────────────────────────────┐
│ AWS Amplify 구성 요소 │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Amplify Studio │ │
│ │ (시각적 풀스택 앱 빌더) │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ Amplify CLI │ │ Amplify Libraries │ │
│ │ (백엔드 설정 │ │ (React, Vue 등 │ │
│ │ 명령줄 도구) │ │ 프론트엔드 연동) │ │
│ └──────────────────┘ └──────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Amplify Hosting │ │
│ │ (CDN으로 안전하고 빠른 웹 호스팅) │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘Amplify로 뭘 할 수 있나요?
| 기능 | AWS 서비스 | 설명 |
|---|---|---|
| 인증 | Cognito | 로그인, 회원가입, 소셜 로그인 |
| 데이터 | AppSync + DynamoDB | GraphQL API + NoSQL DB |
| 스토리지 | S3 | 파일 업로드/다운로드 |
| 분석 | Pinpoint | 사용자 분석 |
| AI/ML | Rekognition, Translate 등 | 이미지 인식, 번역 |
| 호스팅 | CloudFront + S3 | 웹 앱 배포 |
지원 프레임워크
| 프레임워크 | 지원 |
|---|---|
| React.js | ✅ |
| Vue.js | ✅ |
| Next.js | ✅ |
| Angular | ✅ |
| iOS | ✅ |
| Android | ✅ |
| Flutter | ✅ |
10. Amplify 주요 기능
Authentication (인증)
┌─────────────────────────────────────────────────────────────────┐
│ Amplify Authentication │
│ │
│ ┌───────────────────────────────────────┐ │
│ │ Pre-built UI Components │ │
│ │ │ │
│ │ ┌────────────────────────────────┐ │ │
│ │ │ 로그인 │ │ │
│ │ │ ┌─────────────────────────┐ │ │ │
│ │ │ │ 이메일: _______________ │ │ │ │
│ │ │ │ 비밀번호: _____________ │ │ │ │
│ │ │ │ │ │ │ │
│ │ │ │ [ 로그인 ] │ │ │ │
│ │ │ │ │ │ │ │
│ │ │ │ Google | Facebook │ │ │ │
│ │ │ └─────────────────────────┘ │ │ │
│ │ └────────────────────────────────┘ │ │
│ └───────────────────────────────────────┘ │
│ │ │
│ ↓ │
│ Amazon Cognito │
│ │
│ 기능: 회원가입, 로그인, MFA, 소셜 로그인, 비밀번호 복구 │
│ │
└─────────────────────────────────────────────────────────────────┘React 코드 예시:
import { Authenticator } from "@aws-amplify/ui-react";
function App() {
return (
<Authenticator>
{({ signOut, user }) => (
<div>
<h1>안녕하세요, {user.username}님!</h1>
<button onClick={signOut}>로그아웃</button>
</div>
)}
</Authenticator>
);
}DataStore (데이터 저장)
┌─────────────────────────────────────────────────────────────────┐
│ Amplify DataStore │
│ │
│ ┌──────────────┐ ┌──────────────────┐ │
│ │ Mobile App │ │ AppSync │ │
│ │ │ ← 자동 동기화 → │ + DynamoDB │ │
│ │ Local Data │ │ (클라우드) │ │
│ └──────────────┘ └──────────────────┘ │
│ │
│ 특징: │
│ ✅ 오프라인에서도 작동 │
│ ✅ 온라인 복귀 시 자동 동기화 │
│ ✅ 실시간 업데이트 │
│ ✅ GraphQL 기반 (복잡한 코드 필요 없음!) │
│ │
└─────────────────────────────────────────────────────────────────┘React 코드 예시:
import { DataStore } from "@aws-amplify/datastore";
import { Todo } from "./models";
// 저장
await DataStore.save(
new Todo({
name: "장보기",
completed: false,
}),
);
// 조회
const todos = await DataStore.query(Todo);
// 실시간 구독
DataStore.observe(Todo).subscribe(msg => {
console.log("변경됨:", msg);
});11. Amplify Hosting
🤔 Amplify Hosting이 뭔가요?
비유로 이해하기: Vercel/Netlify의 AWS 버전입니다.
- GitHub Push → 자동 빌드 → 자동 배포
- 커스텀 도메인, HTTPS, CDN 모두 포함!
기능
| 기능 | 설명 |
|---|---|
| CI/CD | 코드 Push → 자동 빌드/테스트/배포 |
| PR Preview | Pull Request마다 미리보기 환경 |
| 커스텀 도메인 | 내 도메인 연결 |
| HTTPS | 자동 SSL 인증서 |
| CDN | CloudFront로 글로벌 배포 |
| 리다이렉트 | URL 리다이렉트 규칙 |
| 비밀번호 보호 | 특정 브랜치에 암호 설정 |
배포 흐름
┌─────────────────────────────────────────────────────────────────┐
│ Amplify Hosting 배포 흐름 │
│ │
│ 1. 코드 Push │
│ ┌────────────────┐ │
│ │ GitHub │ │
│ │ (main 브랜치) │ │
│ └───────┬────────┘ │
│ │ │
│ ↓ Webhook │
│ │
│ 2. Amplify에서 빌드 │
│ ┌─────────────────────────────────────────────┐ │
│ │ Amplify │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │ Build │→│ Test │→│ Deploy │ │ │
│ │ │Frontend │ │ (E2E) │ │ │ │ │
│ │ └─────────┘ └─────────┘ └─────────┘ │ │
│ │ ↓ │ │
│ │ ┌─────────┐ │ │
│ │ │ Build │ (선택적) │ │
│ │ │Backend │ │ │
│ │ └─────────┘ │ │
│ └─────────────────────────────────────────────┘ │
│ │ │
│ ↓ │
│ │
│ 3. CloudFront로 배포 │
│ ┌────────────────┐ │
│ │ CloudFront │ → https://myapp.amplifyapp.com │
│ │ (CDN) │ │
│ └────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘E2E Testing (Cypress)
# amplify.yml
version: 1
frontend:
phases:
preBuild:
commands:
- npm ci
build:
commands:
- npm run build
artifacts:
baseDirectory: build
files:
- "**/*"
cache:
paths:
- node_modules/**/*
test:
phases:
preTest:
commands:
- npm ci
- npx cypress verify
test:
commands:
- npx cypress run # Cypress E2E 테스트 실행!
artifacts:
baseDirectory: cypress
files:
- "**/*.mp4" # 테스트 영상 저장
- "**/*.png" # 스크린샷 저장핵심 요약
서비스 선택 가이드
| 상황 | 추천 서비스 |
|---|---|
| 복잡한 워크플로우 오케스트레이션 | Step Functions |
| GraphQL API 필요 | AppSync |
| 풀스택 앱 빠르게 개발 | Amplify |
| 실시간 데이터 동기화 | AppSync 또는 Amplify DataStore |
Step Functions 요약
| 항목 | Standard | Express |
|---|---|---|
| 시간 | 최대 1년 | 최대 5분 |
| 실행 | Exactly-once | At-least-once |
| 초당 | 2,000+ | 100,000+ |
| 용도 | 결제, 주문 | IoT, 스트리밍 |
AppSync vs REST API
| 항목 | REST API | GraphQL (AppSync) |
|---|---|---|
| 요청 수 | 여러 번 | 1번 |
| 데이터 | 고정된 응답 | 필요한 것만 |
| 실시간 | Polling 필요 | WebSocket 내장 |