08/10 — 실행 모델·확장 신호·과금 단위
이 구간은 실행 단위 → 상태의 위치 → 늘릴 용량과 신호 → 실제 과금 작업 순서로 연결한다.
1. 단순 정의
- EC2: OS와 인스턴스 유형을 선택하는 가상 서버다. 호스트 제어와 특수 하드웨어에 맞는다.
- 표준 Lambda 함수: 이벤트별 코드를 실행한다. 한 invocation은 최대 15분이며 영속 상태는 외부에 둔다.
- ECS task와 service: task는 컨테이너 묶음이고, service는 지정한 수의 task를 계속 실행·교체한다.
- ECS 실행 용량: ECS on EC2는 인스턴스를 직접 운영하고, Fargate는 지정한 task 자원을 관리형 용량에서 실행한다.
- 확장 신호와 경계: 부하 지표가 desired capacity를 바꾸고 min/max가 범위를 정한다. Service Quota는 실제 확장의 상한이다.
- 과금 단위: 비용을 계산하는 작업량이다. 인스턴스 시간, 요청 수·GB-초, task 자원 시간, 스캔 바이트가 해당한다.
2. 결정 축과 관계
첫 번째 축은 패키징·실행 시간·제어 범위다. OS·호스트 에이전트·특정 인스턴스 유형을 직접 제어하면 EC2, 짧은 이벤트 처리와 높은 유휴 비율은 표준 Lambda 함수에 맞는다. 컨테이너 장기 서비스·worker는 ECS를 쓰되, 호스트 운영을 맡기면 Fargate, 인스턴스 유형·AMI·호스트 구성을 직접 정하면 ECS on EC2를 고른다. AWS 컴퓨팅 선택, Fargate와 Lambda
두 번째 축은 상태의 수명이다. Lambda 환경, ECS task, Auto Scaling 인스턴스의 로컬 데이터는 실행 중 cache·scratch로 쓴다. 교체 뒤에도 필요한 세션·진행 상태·결과는 DynamoDB·RDS·S3·EFS나 명시적으로 관리하는 EBS에 둔다.
세 번째 축은 확장 대상과 부하 신호다. EC2 Auto Scaling은 인스턴스, ECS Service Auto Scaling은 task, Lambda는 동시 실행 환경을 늘린다. ECS on EC2는 service의 task 수와 cluster의 EC2 수를 모두 맞춘다. 계산 부하는 평균 CPU, 웹 요청은 ALBRequestCountPerTarget, SQS worker는 backlog ÷ 실행 중 worker 수를 목표 추적한다. 알려진 피크는 scheduled, 반복 패턴은 predictive, 임계 구간별 증분은 step scaling에 맞는다. EC2 목표 추적, ECS 목표 추적
네 번째 축은 정책 범위와 공급 상한이다. ASG·ECS service의 max와 별도로 EC2 vCPU, Fargate vCPU, Lambda concurrency quota를 예상 최대치에 맞춘다. 서브넷 IP와 DB 연결도 함께 확인한다. Lambda reserved concurrency는 함수 몫과 상한을 정하고, provisioned concurrency는 초기화된 환경을 미리 유지하며 별도 과금된다. Service Quotas 개념, Lambda provisioned concurrency
마지막 축은 비용을 만드는 작업량이다. EC2는 실행 시간과 별도 EBS·공인 IPv4를 계산한다. ECS on EC2는 인스턴스, Fargate는 요청 vCPU·메모리·추가 스토리지의 task 시간에 과금한다. Lambda는 요청 수와 메모리 비례 실행 시간(GB-초), Athena per-query는 스캔 바이트에 따라 과금한다. Athena는 압축·파티션·열 형식이 비용과 성능을 함께 개선한다. EC2 On-Demand, ECS·Fargate 요금, Lambda 요금, Athena 요금 방식
3. 아키텍처 적용
사례 A — 짧고 불규칙한 이벤트 처리
S3/EventBridge → Lambda → DynamoDB/S3로 구성한다. 상태는 외부에 두고 reserved concurrency를 하위 저장소 수용량에 맞춘다. 호출 수와 메모리별 실행 시간을 함께 측정한다.
사례 B — 가변 트래픽의 컨테이너 API
ALB → 여러 AZ의 ECS Service on Fargate → RDS/DynamoDB로 구성한다. Service Auto Scaling이 CPU·메모리나 ALB 요청/target으로 task 수를 바꾸고, Fargate가 task 용량을 제공한다.
사례 C — 호스트 제어가 필요한 장기 worker
SQS → 여러 AZ의 EC2 Auto Scaling worker → 결과 저장소로 구성한다. backlog/worker를 목표 추적하고 ASG max와 EC2 vCPU quota를 함께 확보한다. 중단을 견디는 멱등 작업에는 Spot을 섞는다.
4. 정답 구조
- OS·인스턴스·가속기 제어 → EC2 → 가상 서버를 선택·운영
- 짧고 독립적인 이벤트 코드 → 표준 Lambda 함수 → invocation 단위 자동 실행·확장
- 컨테이너와 서버 운영 최소화 → ECS on Fargate → task 자원만 지정
- 컨테이너와 인스턴스·AMI·호스트 제어 → ECS on EC2 → ECS 오케스트레이션과 EC2 용량 결합
- 요청량 비례 웹 확장 → ALBRequestCountPerTarget 목표 추적 → target당 처리량 유지
- 비동기 worker 확장 → backlog/worker 사용자 지표 → 작업 적체를 처리 용량에 정규화
- 계획 최대치 실현 → Service Quota 사전 확보 → 계정·리전 상한 정렬
- Lambda 비용 최적화 → 요청 수 + GB-초 측정 → 메모리와 실행 시간을 함께 조정
- Athena per-query 비용 최적화 → 스캔 바이트 감소 → 압축·파티션·열 형식
5. 긍정형 암기표
| 요구사항의 중심 | 올바른 연결 |
|---|---|
| OS·호스트 에이전트·특수 하드웨어 제어 | EC2 |
| 짧고 불규칙한 이벤트 코드 | 표준 Lambda 함수 |
| 컨테이너 실행, 호스트 운영 최소화 | ECS on Fargate |
| 컨테이너와 인스턴스 유형·AMI·호스트 제어 | ECS on EC2 |
| 요청 비례 웹 계층 확장 | ALBRequestCountPerTarget |
| 비동기 worker 적체 해소 | backlog/worker |
| 알려진 시각의 피크 | scheduled scaling |
| 계획 용량의 계정·리전 상한 | Service Quotas 사전 확보 |
| 함수 호출 비용 | 요청 수 + 메모리 비례 실행 시간 |
| 컨테이너·분석 비용 | Fargate 자원 시간 / Athena 스캔 바이트 |
다음: 09/10 — VPC·하이브리드·글로벌 경로. 연결 대상과 규모, 처리량, 복구, 운영 복잡성, 데이터 전송 비용을 경로 선택과 연결한다.