AWS 07-2 이벤트로 잇고 흐름을 짠다 — EventBridge·Scheduler·Pipes·Step Functions

주문 하나가 들어오면 할 일이 줄줄이 붙습니다. 재고를 빼고, 결제하고, 배송을 요청하고, 메일을 보내고, 포인트를 쌓습니다. 이 다섯 단계를 AWS 의 흐름 서비스 Step Functions 에 맡겨 서울에서 하루 10만 번 돌리면, 같은 흐름인데 고르는 방식에 따라 한 달 값이 $568.99 과 $6.13(로그 요금 제외)으로 약 93배 차이 납니다. 싼 쪽을 고르면 끝일 것 같지만, 싼 쪽은 같은 주문을 드물게 두 번 처리할 수 있다는 조건을 붙입니다. 재고가 두 번 빠져도 되는 가게는 없습니다.

이 편은 그 계산까지 가는 길에 서비스 넷을 봅니다. 서비스끼리 직접 부르지 않고 「주문이 들어왔다」 같은 사건을 흘려 잇는 EventBridge 이벤트 버스, 정해진 시각에 무언가를 부르는 EventBridge Scheduler, 큐 하나를 대상 하나에 곧장 잇는 EventBridge Pipes, 그리고 여러 단계의 순서·재시도·분기를 코드 밖으로 빼는 Step Functions 입니다. 요금과 한도는 전부 2026-09-27 서울(ap-northeast-2) 기준입니다. 큐와 알림(SQS·SNS)은 07-1편에서 봤고, 이 편에서는 SNS 와 이벤트 버스가 갈리는 지점만 다시 짚습니다.

지도

flowchart TD
    START["서비스 사이를<br/>무엇으로 잇나"] --> Q1{"하려는 일"}
    Q1 -- "사건을 여러 곳에<br/>골라 보낸다" --> Q2{"받는 쪽이<br/>1,500곳을 넘나"}
    Q2 -- "아니다" --> EB["EventBridge<br/>이벤트 버스"]
    Q2 -- "그렇다" --> SNS["SNS<br/>07-1편"]
    Q1 -- "정해진 시각에<br/>부른다" --> SCH["EventBridge<br/>Scheduler"]
    Q1 -- "큐·스트림 하나를<br/>대상 하나에 잇는다" --> PIPE["EventBridge<br/>Pipes"]
    Q1 -- "여러 단계를<br/>순서대로 돌린다" --> SFN["Step Functions"]

앞의 셋은 EventBridge 라는 이름을 나눠 쓰지만 하는 일이 다릅니다. 이벤트 버스는 여러 곳에서 오는 이벤트(「무엇이 일어났다」를 담은 JSON 문서)를 규칙에 따라 여러 곳으로 나눠 보내고, Scheduler 는 정해진 시각에 대상을 부르며, Pipes 는 출발지 하나와 도착지 하나를 잇는 관입니다. Step Functions 는 이들과 달리 단계의 순서를 쥡니다. 절마다 다시 풉니다.

1. EventBridge 이벤트 버스 — 규칙이 이벤트를 골라 보낸다

주문 서비스가 배송·메일·포인트 서비스를 차례로 직접 부르면, 받는 쪽이 하나 늘 때마다 주문 서비스 코드를 고쳐야 하고 하나가 느려지면 주문 전체가 느려집니다. 이벤트 버스는 이 관계를 뒤집습니다. 주문 서비스는 「주문이 들어왔다」는 이벤트를 버스(event bus, 이벤트를 받아 나눠 보내는 중계기)에 던지고 끝냅니다. 누가 그 이벤트를 받을지는 버스에 걸린 규칙(rule)이 정합니다.

이벤트는 이런 JSON 입니다. source 는 누가 보냈나, detail-type 은 무슨 종류의 사건인가, detail 은 내용입니다.

{
  "source": "shop.orders",
  "detail-type": "OrderPlaced",
  "detail": { "orderId": "o-1024", "amount": 1250000 }
}

규칙은 이벤트 패턴(event pattern)으로 이벤트를 거릅니다. 패턴은 이벤트와 같은 모양의 JSON 이고, 맞추고 싶은 값을 배열에 적습니다. 아래 패턴은 금액이 100만 이상인 주문만 고릅니다.

{
  "source": ["shop.orders"],
  "detail-type": ["OrderPlaced"],
  "detail": { "amount": [{ "numeric": [">=", 1000000] }] }
}

• numeric 은 숫자 범위를 비교합니다. 이 밖에 앞글자(prefix)·뒷글자(suffix)·「이것만 빼고」(anything-but)·필드 존재 여부(exists)·와일드카드 비교가 있습니다(Comparison operators for use in event patterns)

패턴에 맞은 이벤트는 규칙의 대상(target)으로 갑니다. 대상은 Lambda 함수, SQS 큐, Step Functions 같은 AWS 서비스이거나, 외부 HTTPS 주소로 보내 주는 API 대상(API destination)입니다. 한 버스에 규칙과 대상을 여럿 걸면 이렇게 퍼집니다.

flowchart TD
    O["주문 서비스<br/>PutEvents"] --> B["주문 이벤트 버스"]
    B --> R1{"규칙 1<br/>모든 주문"}
    B --> R2{"규칙 2<br/>100만 원 이상"}
    R1 --> T1["SQS<br/>배송 대기열"]
    R1 --> T2["Lambda<br/>확인 메일"]
    R2 --> T3["Step Functions<br/>이상 거래 검토"]

버스는 세 종류입니다. 계정마다 처음부터 있는 기본 버스(default bus)에는 AWS 서비스가 알아서 이벤트를 흘립니다. EC2 인스턴스가 멈췄다, 보안 그룹이 바뀌었다 같은 사건을 200개가 넘는 서비스(요금 페이지는 250개 넘게)가 보내고, 이렇게 리소스를 관리하는 조작에서 나온 AWS 관리 이벤트는 받는 데 요금이 없습니다. S3 객체 업로드처럼 데이터를 다루는 이벤트는 켜야 들어오고 사용자 지정 이벤트와 같은 값을 받습니다. 내 애플리케이션의 이벤트는 PutEvents API 로 사용자 지정 버스(custom bus, 지금 이름은 「Custom event bus - classic」)에 넣습니다. 위 그림의 주문 이벤트 버스가 이것입니다. 요청 하나에 이벤트 10개, 합쳐 1 MB 미만까지입니다(PutEvents). 세 번째인 파트너 버스는 EventBridge 와 연동한 외부 SaaS 가 보내는 이벤트를 받습니다.

규칙 하나에 대상은 최대 5개, 버스 하나에 규칙은 기본 300개(늘릴 수 있음)입니다. 서울에서 PutEvents 는 기본 초당 600건 요청까지 받고, 넘치면 스로틀링됩니다(Amazon EventBridge quotas). 대상에 전달이 실패하면 EventBridge 는 지수 백오프로 기본 24시간 동안 최대 185번 재시도하고, 그래도 안 되면 이벤트를 버립니다. 버리지 않으려면 DLQ(dead-letter queue, 끝내 전달 못 한 이벤트를 모아 두는 SQS 큐)를 걸어 둡니다(How EventBridge retries delivering events). 이벤트가 보내진 뒤 대상에 닿기까지는 보통 0.5초쯤 걸립니다.

DLQ 가 전달 못 한 이벤트를 붙잡는다면, 이미 전달한 이벤트를 다시 쓰는 기능도 있습니다. 아카이브는 버스를 지난 이벤트를 저장해 두고, 재생(replay)은 저장한 이벤트를 버스에 다시 흘려 새로 만든 서비스를 채우거나 장애 뒤를 복구합니다. 스키마 레지스트리는 이벤트의 모양(스키마)을 모아 두고, 버스에 흐르는 이벤트에서 스키마를 알아내 코드용 타입까지 만들어 줍니다.

2026-09-24 에는 새 사용자 지정 버스(Custom event bus)가 나왔습니다. 순서 보장, 버스 하나에 구독자 1만 개, 최대 1년 보관을 내세우고 요금을 이벤트 수가 아니라 GB 로 받습니다. 원래 버스는 「Custom event bus - classic」으로 이름만 바뀌어 그대로 돕니다. 새 버스는 처음 14개 리전에서만 열렸고 서울은 빠져 있습니다(Amazon EventBridge relaunches event buses for enterprise scale). 그래서 이 편의 요금은 전부 classic 기준입니다. classic 버스는 들어오는 이벤트 수로 받고, 이벤트를 64 KB 씩 끊어 하나로 셉니다. 256 KB 짜리 이벤트는 4개입니다.

EventBridge 이벤트 버스(classic) · 서울 · 2026-09-27
  AWS 관리 이벤트 받기         무료
  사용자 지정·파트너·S3 등     100만 건당 $1.00
  같은 계정 서비스로 전달       무료
  다른 계정 서비스로 전달       100만 건당 $0.05(AWS 관리 이벤트는 $1.00)
  다른 버스로 전달             100만 건당 $1.00
  API 대상 호출                100만 건당 $0.24
  아카이브 처리 / 보관          GB 당 $0.13 / GB-월 $0.025
  스키마 알아내기              월 500만 건 무료, 이후 100만 건당 $0.10

• 재생한 이벤트는 다시 이벤트 요금이 붙고, 대상이 된 Lambda·SQS 요금은 따로입니다(Amazon EventBridge pricing)

SNS 와 어디서 갈리나

SNS 도 메시지 하나를 여러 구독자에게 뿌립니다(07-1편). SNS 는 토픽(topic, 메시지를 뿌리는 이름 붙은 채널)에 발행하면 토픽의 구독자 전원에게 보내고, 구독마다 필터 정책을 걸어 거를 수 있습니다. 둘 다 「하나를 받아 여럿에게」라서 헷갈리는데, 닿는 곳의 수, 누가 이벤트를 넣느냐, 지연, 값, 곁가지 기능이 다릅니다(Amazon EventBridge FAQs · Amazon SNS endpoints and quotas).

경계는 숫자로 그을 수 있습니다. 규칙당 대상 5개 × 규칙 300개면 버스 하나로 닿는 곳은 1,500곳이고(규칙 수는 늘릴 수 있습니다), 이를 넘으면 SNS 입니다. 값도 다릅니다. 이벤트 내용으로 행선지를 가를 필요 없이 모두에게 뿌리기만 한다면 SNS 발행이 100만 건당 $0.50 으로 버스의 절반 값입니다. 흔히 쓰는 구성은 둘을 겹치는 것입니다. EventBridge 규칙으로 필요한 이벤트만 골라 SNS 토픽을 대상으로 두고, SNS 가 수천 곳으로 뿌립니다. 결국 이벤트 버스의 값은 내용으로 가르는 기능과 AWS 이벤트를 설정 없이 받는 데 있고, 그 대신 지연과 규칙 설계를 치릅니다.

2. EventBridge Scheduler — 정해진 시각에 API 를 부른다

「주문하고 30분 안에 결제하지 않으면 취소한다」를 짜려면 주문마다 30분 뒤를 기억해 두는 무언가가 필요합니다. 흔한 방법은 1분마다 DB 를 뒤지는 배치이지만, 주문이 없는 새벽에도 1분마다 돌고, 주문마다 제 시각을 기억하는 대신 매번 전체를 훑습니다. EventBridge Scheduler 는 이 기억을 맡는 서버리스 예약 서비스입니다. 주문이 들어올 때 「30분 뒤에 이 API 를 한 번 불러라」는 일정(schedule)을 하나 만들어 두면, 그 시각에 대상을 부릅니다.

일정은 세 가지로 적습니다. 한 번만 부르는 at(2026-09-27T15:30:00), 일정한 간격의 rate(5 minutes), 달력 규칙의 cron(30 8 ? * MON-FRI *)(평일 8시 30분)입니다. cron 과 at 은 UTC 대신 Asia/Seoul 같은 IANA(Internet Assigned Numbers Authority, 시간대 이름 목록을 관리하는 기관) 시간대로 적을 수 있고, 서머타임이 있는 시간대에서는 알아서 맞춰 줍니다. 정밀도는 60초라서, 1시로 잡으면 1:00:00~1:00:59 사이에 부릅니다(Schedule types in EventBridge Scheduler).

대상은 SQS·SNS·Lambda·이벤트 버스처럼 자주 쓰는 것은 틀이 준비돼 있고, 그 밖에는 범용 대상(universal target)으로 270개가 넘는 AWS 서비스의 API 6,000여 개를 직접 부를 수 있습니다(What is Amazon EventBridge Scheduler?). 전달은 최소 한 번(at-least-once)이라, 드물게 같은 호출이 두 번 갈 수 있습니다. 일정은 리전당 기본 1,000만 개까지 만들 수 있는데, 다 돈 일회성 일정도 이 수에 들어가므로 끝나면 지우도록 설정해 둡니다(Quotas for Amazon EventBridge Scheduler).

이런 예약 기능은 원래 이벤트 버스에도 있었습니다. EventBridge 의 전신인 CloudWatch Events 시절부터 규칙에 일정을 거는 예약 규칙(scheduled rule)이 있었고, 지금도 돕니다(EventBridge is the evolution of Amazon CloudWatch Events). 다만 AWS 는 이를 옛 기능(legacy)으로 분류하고 Scheduler 를 권합니다. 예약 규칙은 UTC 로만 돌고, 일회성 예약이 없고, 규칙 수 한도(버스당 300개)에 묶입니다(Creating a scheduled rule (legacy)).

Scheduler 의 요금은 호출 수로만 받고, 무료 한도가 큽니다.

EventBridge Scheduler · 서울 · 2026-09-27
  월 무료        호출 1,400만 건(모든 리전 합산, 매달 다시 채워짐)
  초과분         100만 건당 $1.15

대상이 된 Lambda·SQS 요금은 따로 붙지만, 주문 취소 일정을 월 100만 건 만들어도 Scheduler 쪽은 무료 한도 안입니다. 예약이 거의 공짜라서, 고를 때 따질 것은 60초 정밀도, 부르기만 하고 결과는 보지 않는 호출, 최소 한 번 전달 셋입니다.

3. EventBridge Pipes — 큐 하나를 대상 하나에 곧장 잇는다

SQS 큐에 쌓인 주문을 Step Functions 로 넘기기만 하는 Lambda 함수가 있다고 해 봅니다. 메시지를 읽어 몇 개는 버리고, 나머지를 넘기는 스무 줄짜리 코드인데, 그래도 배포하고 권한을 주고 지켜봐야 합니다. EventBridge Pipes 는 이런 연결용 코드를 설정으로 바꿉니다. 출발지(source)를 고르고, 필요하면 거르기(filter)와 보강(enrichment)을 끼우고, 대상(target)을 고르면 파이프 하나가 됩니다.

출발지는 SQS 큐, Kinesis 데이터 스트림(실시간 데이터를 흘려 담는 서비스, 07-3편), DynamoDB(AWS 의 키-값 DB) 테이블의 변경 기록인 DynamoDB 스트림, Amazon MQ 브로커(07-1편), 그리고 관리형 Kafka 인 Amazon MSK 와 직접 운영하는 Apache Kafka 입니다. 파이프가 출발지를 폴링해서 읽고, 출발지가 순서를 지키면 대상까지 그 순서를 지킵니다. 거르기는 1절의 이벤트 패턴과 같은 문법입니다. 보강은 대상으로 보내기 전에 Lambda 함수, Step Functions 의 짧은 흐름용 방식인 Express 워크플로(4절), API Gateway(API 앞에 세우는 관문 서비스), API 대상 가운데 하나를 불러 모자란 정보를 채우는 단계입니다(Amazon EventBridge Pipes · Event enrichment in Amazon EventBridge Pipes). 대상은 Lambda·Step Functions·SQS·SNS·Kinesis·이벤트 버스(같은 계정·같은 리전) 등 15종 안팎으로, 20종이 넘는 이벤트 버스의 대상 목록보다 좁습니다(Amazon EventBridge Pipes targets).

이벤트 버스와의 차이는 연결의 모양입니다. 버스는 여러 출발지에서 여러 대상으로 퍼뜨리고, 파이프는 출발지 하나에서 대상 하나로 갑니다. 01-3편에서 본 Lambda 의 이벤트 소스 매핑(Lambda 가 큐·스트림을 읽어 함수에 넘기는 기능)과 같은 폴링 기능을 쓰는데, 대상이 Lambda 가 아닐 때 파이프가 그 사이 함수를 없애 줍니다.

요금은 거르기를 통과한 요청 수로만 받으므로, 대부분을 버리는 흐름일수록 값이 작아집니다. 묶어 보낸 이벤트는 64 KB 마다 요청 하나로 세고, 보강에 쓴 Lambda·Step Functions 와 대상 서비스의 요금은 따로 붙습니다.

EventBridge Pipes · 서울 · 2026-09-27
  거르기 통과 요청     100만 건당 $0.46

파이프가 없애는 것은 중간 함수 하나이므로, 대상이 무엇이고 몇 개인지, 가공이 얼마나 복잡한지가 판정을 정합니다.

4. Step Functions — 단계의 순서·재시도·분기를 코드 밖으로

주문 처리 다섯 단계를 Lambda 함수 하나에 넣으면, 결제 API 가 가끔 실패할 때의 재시도, 재고가 없을 때의 분기, 메일과 포인트를 동시에 돌리는 코드가 업무 로직 사이에 섞입니다. 함수는 15분을 못 넘고, 중간에 죽으면 어디까지 했는지도 남지 않습니다. Step Functions 는 이 흐름을 상태 기계(state machine), 곧 상태(단계)와 상태 사이의 이동을 적은 정의로 코드 밖에 둡니다. 정의는 Amazon States Language 라는 JSON 형식으로 쓰고, 콘솔에서는 순서도로 보입니다. 상태는 일을 하는 Task, 값에 따라 길을 가르는 Choice, 여러 갈래를 동시에 돌리는 Parallel, 기다리는 Wait 를 주로 쓰고, 그 밖에 몇 가지가 더 있습니다(Discovering workflow states). 상태마다 Retry(실패하면 몇 번, 몇 초 간격으로 다시)와 Catch(끝내 실패하면 어디로)를 붙입니다. 5절에서 셈할 주문 처리는 Task 다섯 개를 차례로 지나는 흐름입니다.

flowchart TD
    S["주문 접수"] --> A["재고 차감<br/>DynamoDB 직접 호출"]
    A --> P["결제<br/>실패 시 3회 재시도"]
    P -- "끝내 실패" --> F["재고 되돌림<br/>주문 실패 처리"]
    P --> D["배송 요청"]
    D --> M["확인 메일"]
    M --> PT["포인트 적립"]
    PT --> E["완료"]

그림의 「재고 차감」은 Lambda 를 거치지 않습니다. Step Functions 는 AWS SDK 통합으로 200개가 넘는 AWS 서비스의 API 9,000개 이상을 Task 상태에서 직접 부릅니다(Integrating services with Step Functions). 재고 차감 상태의 Resource 에 arn:aws:states:::aws-sdk:dynamodb:updateItem 이라고 적으면 DynamoDB 의 UpdateItem API 를 부르라는 뜻이 되고, 서비스 이름과 API 이름만 바꾸면 다른 서비스도 같은 모양으로 부릅니다. 그림의 결제 단계는 결제 Lambda 함수를 부르는 lambda:invoke 로 이렇게 적습니다.

"결제": {
  "Type": "Task",
  "Resource": "arn:aws:states:::lambda:invoke",
  "Parameters": { "FunctionName": "Pay", ... },
  "Retry": [{ "ErrorEquals": ["States.TaskFailed"],
              "MaxAttempts": 3, "BackoffRate": 2 }],
  "Catch": [{ "ErrorEquals": ["States.ALL"], "Next": "재고 되돌림" }],
  "Next": "배송 요청"
}

• BackoffRate 는 재시도 간격을 매번 몇 배로 늘릴지 정합니다(2면 두 배씩). Catch 는 재시도 3회까지 끝내 실패한 실행을 재고 되돌림 으로 보냅니다

사람의 승인을 기다리는 단계도 둘 수 있습니다. .waitForTaskToken 을 붙인 Task 는 작업 토큰(task token, 멈춰 있는 이 단계를 가리키는 식별 문자열)을 승인 시스템에 넘기고 멈춥니다. 누군가 그 토큰으로 SendTaskSuccess API 를 부르면 다음 단계로 가고, 아래의 Standard 방식에서는 실행 한도인 최대 1년까지 기다립니다(Discover service integration patterns).

Standard 와 Express

상태 기계를 만들 때 Standard 와 Express 워크플로 가운데 하나를 고르고, 만든 뒤에는 못 바꿉니다. Standard 는 오래 걸리고 한 번만 돌아야 하는 흐름을 위한 방식이고, Express 는 짧고 많은 흐름을 싸게 돌리는 방식입니다(Choosing workflow type in Step Functions).

Express 는 부르는 방식이 둘이고, 보장이 방식마다 다릅니다. 동기 실행은 부른 쪽이 흐름이 끝날 때까지 기다려 결과를 받는 방식이고, 최대 한 번이라 두 번 돌지는 않지만 실패해도 다시 돌려 주지 않습니다. 비동기 실행은 시작만 시키고 바로 돌아오는 방식이고, 최소 한 번이라 드물게 같은 실행이 두 번 돕니다. 이 편의 주문 처리는 주문 접수 이벤트를 받아 뒤에서 도는 흐름이라 비동기 쪽이고, 그래서 Express 로 돌리면 같은 주문의 흐름이 드물게 두 번 돕니다. 두 번 하면 안 되는 일이 멱등하지 않다면 Standard 로, 두 번 돌아도 결과가 같다면 Express 로 돌립니다.

Standard 의 요금 단위인 상태 전이(state transition)는 실행 안의 단계 하나가 끝날 때마다 1회로 셉니다. 공식 요금 예시는 시작과 끝도 한 단계로 셉니다. Retry 로 다시 돈 것도 1회씩 더 붙습니다.

Step Functions · 서울 · 2026-09-27
  Standard   상태 전이 1회당 $0.0000271
             월 4,000회 무료(기한 없음)
  Express    실행 요청 100만 건당 $1.00
             실행 시간  첫 360만 GB-초   GB-초당 $0.00001667
                       다음 1,440만     GB-초당 $0.00000833
                       그 이상          GB-초당 $0.00000456

• Express 의 실행 시간은 100 ms 단위로 올림하고, 메모리는 64 MB 단위로 셉니다. 메모리는 50 MB 에 정의 크기와 입력 데이터 크기를 더한 값이라, 보통의 흐름은 64 MB 한 칸입니다. 흐름 안에서 부른 Lambda·DynamoDB, Express 의 CloudWatch Logs 요금은 따로 붙습니다(AWS Step Functions Pricing)

5. 주문 처리 하루 10만 번 — Standard 와 Express 는 얼마나 차이 나나

4절 그림의 주문 처리를 성공 경로로만 돌린다고 칩니다. 공식 요금 예시처럼 시작과 끝을 넣어 세면, Task 다섯 개에 「주문 접수」와 「완료」를 더해 실행 한 번에 상태 전이는 7회이고, 재시도는 없다고 둡니다. Express 쪽은 한 번 실행이 평균 1초, 메모리는 64 MB(0.0625 GB) 한 칸으로 잡고, CloudWatch Logs 요금은 넣지 않습니다. 한 달은 30일입니다.

주문 처리 · 하루 10만 번 · 서울 · 한 달(30일)
  실행 수    100,000 × 30 = 3,000,000

Standard
  상태 전이  7 × 3,000,000 = 21,000,000
  무료 차감  21,000,000 − 4,000 = 20,996,000
  요금       20,996,000 × $0.0000271 = $568.99

Express(CloudWatch Logs 요금 제외)
  요청       3,000,000 × $0.000001 = $3.00
  GB-초      3,000,000 × 1초 × 0.0625 = 187,500
  시간 요금  187,500 × $0.00001667 = $3.13
  합계                             = $6.13

Standard 는 월 $568.99, Express 는 로그를 빼고 월 $6.13 으로 Standard 가 약 93배 비쌉니다. Standard 는 단계 수에 비례해 오르고 기다리는 시간에는 값을 안 받으며, Express 는 단계 수와 상관없이 걸린 시간에 비례합니다. 그래서 짧고 많은 흐름은 Express 가 압도적으로 싸고, 며칠을 기다리는 흐름은 Express 로는 아예 못 돌립니다(최대 5분).

다만 이 차이를 두 번 결제를 막는 값으로 읽으면 안 됩니다. 그림의 결제에는 재시도 3회가 걸려 있고, Standard 의 정확히 한 번은 Retry 를 걸지 않은 단계에만 해당합니다. 결제 API 가 돈을 빼고 응답을 주기 전에 끊기면 Standard 도 결제를 다시 부릅니다. 그래서 재시도가 걸린 결제는 Standard 여도 멱등 키가 필요합니다. 주문 번호 같은 멱등성 키를 결제 API 에 넘겨, 같은 결제가 두 번 들어와도 한 번만 처리되게 해야 합니다. 그 키를 갖추면 Express 가 흐름을 두 번 돌려도 결제는 한 번만 나갑니다. 남는 위험은 재시도를 걸지 않은 재고 차감·포인트 적립이 두 번 도는 것입니다. 결국 $568.99 는 이 단계들까지 멱등하게 만들 수 없을 때 치르는 값이고, 주문 번호로 중복을 거를 수 있다면 Express 로 충분합니다.

여러 단계 흐름을 어디에 적느냐로 보면 다른 길도 있습니다. 01-3편에서 본 Lambda durable functions 는 함수 코드 안에 단계와 대기를 적고, 끝난 단계를 체크포인트로 남겨 최대 1년을 잇습니다. 기다리는 동안 실행 요금을 받지 않는 점은 Standard 와 같고, 차이는 흐름을 적는 곳입니다. 흐름을 평소 쓰는 언어로 한 함수 안에 적고 싶으면 durable functions, 여러 AWS 서비스를 코드 없이 엮고 운영자가 진행 상태를 순서도로 봐야 하면 Step Functions 입니다.

Step Functions 안에서는 두 방식 가운데 무엇을 고르느냐가 판정의 대부분이고, 서비스 자체를 고를지는 흐름을 어디에 적느냐로 정합니다.

이럴 땐 무엇

지금까지의 판정을 상황별로 모으면, 받는 쪽 수·시각·연결 모양·단계 수 가운데 무엇이 문제인지가 서비스를 정합니다.

자주 붙는 서비스는 SQS(대상·DLQ·Pipes 출발지), SNS(대량 전달), Lambda(대상·보강), DynamoDB(SDK 통합·스트림), IAM(대상을 부를 역할), CloudWatch Logs(Express 실행 기록)입니다.

한 장 요약

사건을 여러 곳에 나눌 때는 이벤트 버스, 시각에 맞춰 부를 때는 Scheduler, 큐 하나를 대상 하나에 이을 때는 Pipes 를 씁니다. 버스는 받는 쪽이 1,500곳을 넘거나 수십 ms 가 중요하면 SNS 에 넘깁니다. 여러 단계 흐름은 Step Functions 가 맡는데, 5절 주문 처리에서 Standard 는 월 $568.99, Express 는 $6.13(로그 제외)입니다. 재시도가 걸린 결제는 어느 쪽이든 멱등 키가 필요하고, 그 차이는 나머지 단계를 멱등하게 만들 수 없을 때 치르는 값입니다.

관련 항목

이벤트로 잇고 흐름을 짜는 같은 갈래

Amazon EventBridge · EventBridge Scheduler · EventBridge Pipes · AWS Step Functions · Lambda durable functions

이벤트 버스를 이루는 개념

이벤트 · 이벤트 버스 · 이벤트 패턴 · API 대상 · 아카이브와 재생 · 스키마 레지스트리 · 스키마 · CloudWatch Events

같은 일을 다른 방식으로 푸는 메시징

Amazon SNS · Amazon SQS · Amazon MQ · Amazon Kinesis Data Streams · Apache Kafka · 발행-구독

Pipes 가 읽어 오는 출발지

DynamoDB Streams · Amazon MSK · 이벤트 소스 매핑 · 폴링

Step Functions 를 이루는 개념

상태 기계 · Amazon States Language · 상태 전이 · 작업 토큰 · AWS SDK 통합 · 오케스트레이션 · 사가 패턴

전달과 실패를 다루는 장치

재시도 · 지수 백오프 · 데드 레터 큐 · 멱등성 · 최소 한 번 전달 · 정확히 한 번 전달 · 스로틀링

예약을 이루는 개념

cron · UTC · IANA · 서머타임

이 서비스들이 부르고 올라앉는 바탕

AWS Lambda · Amazon DynamoDB · AWS IAM · CloudWatch · 서버리스 · 이벤트 기반 아키텍처 · 마이크로서비스