Amazon SAA-C03: 컴퓨팅, Auto Scaling 및 인스턴스 관리 — 학습 가이드

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

다음의 일부입니다: AWS SAA-C03 — 완벽 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

EC2 인스턴스 유형 및 AMI

적절한 EC2 인스턴스 패밀리를 선택하는 것은 잘 설계된 컴퓨팅 계층의 기반이 됩니다. 패밀리, 세대, 크기가 함께 CPU 아키텍처, 메모리 대 vCPU 비율, 네트워크 대역폭, 사용 가능한 가속기를 결정하기 때문입니다. 범용(M6i, M7g, T-시리즈)은 균형 잡힌 웹 티어와 혼합 워크로드에 적합합니다. 컴퓨팅 최적화(C7i, C7gn)는 CPU 집약적인 시뮬레이션, 인코딩, 배치, 웹 프런트엔드에 적합합니다. 메모리 최적화(R7i, X2idn)는 인메모리 데이터베이스와 캐시를 대상으로 합니다. 스토리지 최적화(I4i, D3)는 NoSQL, HDFS, 데이터 웨어하우징을 대상으로 합니다. 가속(P5, G5, Trn1, Inf)은 GPU 또는 ML 실리콘을 제공합니다. Graviton(g 접미사) 인스턴스는 일반적으로 ARM64로 깔끔하게 컴파일되는 스케일 아웃 워크로드에 대해 20-40% 더 나은 가격 대비 성능을 제공합니다.

T-패밀리는 버스트 가능하며 기본적으로 표준 모드로 설정됩니다. 이 모드에서는 유휴 상태일 때 CPU 크레딧이 축적되고 버스트 중에 소모됩니다. 크레딧이 모두 소진되면 성능은 기준선으로 조절됩니다. 예측할 수 없는 스파이크가 있는 워크로드(소규모 웹 티어, 개발/테스트 환경 또는 스파이크가 심한 프런트엔드를 지원하는 Elastic Beanstalk 환경)의 경우, 무제한 모드의 T-인스턴스는 인스턴스가 크레딧을 빌려 초과 사용량에 대해 vCPU-시간당 약간의 추가 요금을 청구하도록 하여 사용자가 체감하는 성능 저하를 방지합니다. 이것이 바로 짧은 시간 동안 CPU 포화 상태가 발생하는 Beanstalk 환경이 더 비싼 컴퓨팅 최적화 패밀리로 업그레이드하는 대신 무제한 모드를 활성화하여 문제를 해결하는 이유입니다. T-시리즈를 진정으로 스파이크가 심하고 평균 사용량이 낮은 워크로드에 사용하는 것이 중요합니다. 표준 모드에서 CPU를 지속적으로 사용하면 몇 분 내에 크레딧이 소진됩니다.

수직적 확장(패밀리 내에서 더 큰 크기로 이동)은 사용 가능한 가장 큰 인스턴스에 의해 제한되고, 변경 시 다운타임을 유발하며, 단일 장애 지점을 만들고, 가용 영역에 걸쳐 워크로드를 분산할 수 없습니다. 부하가 크게 변동할 때는 Auto Scaling 그룹을 사용한 수평적 확장이 올바른 해답입니다.

골든 AMI는 애플리케이션 코드, 런타임, 종속성을 루트 스냅샷에 구워 넣어 빠르고 결정론적인 시작을 가능하게 합니다. 이는 Auto Scaling이 스파이크에 대응할 때 매우 중요합니다. 매번 시작할 때마다 사용자 데이터를 통해 부트스트래핑하는 것은 가장 중요한 순간에 수 분의 지연 시간을 추가합니다.

스토리지 선택: 인스턴스 스토어 vs EBS, 스냅샷, 빠른 스냅샷 복원

인스턴스는 두 가지 스토리지 기반을 제공합니다: 인스턴스 스토어(물리적 호스트에 연결된 임시 NVMe)와 Amazon EBS(네트워크 연결 블록). 인스턴스 스토어는 가능한 가장 낮은 지연 시간을 제공하지만 중지, 최대 절전, 종료 또는 하드웨어 장애 시 데이터가 파괴됩니다. 이를 내구성 있는 스토리지로 취급하는 것은 흔하고 위험한 실수입니다. 이는 스크래치 공간, 버퍼, 캐시 또는 다른 노드에 복제본이 존재하는 HDFS 데이터 노드와 같은 복제된 데이터에만 적합합니다. 내구성이 필요한 데이터는 S3에 저장된 스냅샷으로 백업되는 EBS에 저장해야 합니다.

스냅샷은 일단 생성되면 증분적이고 독립적이므로, 새 볼륨으로 복원해도 원본에는 전혀 영향을 미치지 않습니다. 대규모 프로덕션 데이터셋을 테스트 환경으로 복제하는 일반적인 방법은 원본 볼륨의 스냅샷을 만들고 그 스냅샷에서 새 볼륨을 생성하는 것입니다. 그러나 스냅샷에서 복원된 볼륨은 첫 읽기 시 **S3에서 블록을 지연 로딩(lazy-load)**하므로 각 블록이 채워질 때까지 상당한 I/O 지연이 발생합니다. 동일한 지연 로딩은 루트 스냅샷이 큰 AMI에서 시작된 새 인스턴스에도 영향을 미칩니다. 이러한 인스턴스는 시작 후 몇 분 동안 느리게 보일 수 있습니다.

**EBS 빠른 스냅샷 복원(FSR)**은 이러한 페널티를 제거합니다. ASG가 인스턴스를 시작하는 AZ에 대해 스냅샷에서 FSR을 활성화하면, 해당 스냅샷에서 생성된 볼륨은 즉시 프로비저닝된 전체 성능을 제공합니다:

aws ec2 enable-fast-snapshot-restores \
  --availability-zones us-east-1a us-east-1b \
  --source-snapshot-ids snap-0123456789abcdef0

스케일 아웃 이벤트가 몇 분이 아닌 몇 초 만에 용량을 추가해야 할 때 이것은 필수적입니다.

ENA 및 EFA를 사용한 향상된 네트워킹

광고된 네트워크 처리량은 인스턴스 크기에 따라 확장되지만 Elastic Network Adapter(ENA) 드라이버가 있을 때만 달성할 수 있습니다. ENA는 SR-IOV 기반의 향상된 네트워킹을 제공하며, 최신 인스턴스에서 최대 200Gbps를 지원합니다. 최신 AMI(Amazon Linux 2, 최신 Ubuntu, Windows)는 ENA가 활성화된 상태로 제공됩니다. 다음 명령으로 확인할 수 있습니다:

aws ec2 describe-instances --instance-ids i-0abc \
  --query 'Reservations[].Instances[].EnaSupport'

modinfo ena | grep version
ethtool -i eth0

ENA가 없으면 인스턴스는 조용히 더 낮은 처리량과 더 높은 지터로 대체되어, 배치 그룹 선택과 관계없이 모든 저지연 설계를 저해합니다.

마이크로초 단위의 집합적 통신(CFD, 기상 모델링, 분자 동역학, 대규모 모델 훈련)을 위해서는 **Elastic Fabric Adapter(EFA)**를 추가하십시오. EFA는 MPI 및 NCCL에 OS-bypass 전송(Libfabric)을 노출하여 커널 네트워크 스택을 완전히 우회합니다. EFA는 지원되는 인스턴스 유형(c7gn, hpc7a, p5)의 클러스터 배치 그룹 내에서만 이점을 제공하며, EFA 드라이버와 호환되는 MPI(Open MPI, Intel MPI) 또는 NCCL 빌드가 필요합니다.

aws ec2 create-placement-group --group-name hpc-cg --strategy cluster
aws ec2 run-instances --instance-type hpc7a.96xlarge \
  --placement GroupName=hpc-cg \
  --network-interfaces InterfaceType=efa,DeviceIndex=0,SubnetId=subnet-abc

배치 그룹(Placement Groups)

배치 그룹은 인스턴스의 물리적 토폴로지를 제어합니다.

잘못 선택하면 이 기능을 낭비하게 됩니다. 클러스터 그룹은 AZ를 가로지를 수 없으며, 설계상 단일 AZ 내에서만 작동합니다. 분산 그룹은 AZ당 7개라는 상한 때문에 수백 개의 웹 서버를 호스팅할 수 없습니다. 40개 노드로 구성된 Kafka 클러스터에는 분산 배치가 아닌 파티션 배치가 올바른 도구입니다. 이는 복제본 배치를 장애 도메인과 일치시키기 때문입니다. 일반적인 고가용성을 위해서는 ASG를 하나의 AZ에 있는 하나의 배치 그룹에 국한시키지 말고, 여러 AZ에 걸쳐 ASG를 분산시켜야 합니다.

노드 간 지연 시간을 최소화해야 하는 스트리밍 분석이나 MPI 워크로드의 경우, 클러스터 배치 그룹과 ENA 활성화 인스턴스의 조합이 올바릅니다. 클러스터는 홉 수를 줄이고 ENA는 그 지연 시간 이점을 실현하는 데 필요한 초당 패킷 처리 용량을 제공합니다.

Auto Scaling 그룹 및 시작 템플릿

Auto Scaling 그룹(ASG)은 하나 이상의 AZ에 걸쳐 원하는 수의 EC2 인스턴스를 유지하는 런타임 단위이며, MinSize, DesiredCapacity, MaxSize라는 세 개의 정수와 서브넷 목록으로 정의됩니다. ASG 자체는 무엇을 시작할지 기술하지 않습니다. 이는 시작 구성(launch configuration)을 대체하는 최신 기능인 **시작 템플릿(launch template)**의 역할입니다. 시작 템플릿은 버전 관리, 혼합 인스턴스 정책, 스팟/온디맨드 혼합, IMDSv2 강제 적용, 용량 예약, 무제한 모드 T-인스턴스를 지원합니다. 시작 템플릿은 AMI, 인스턴스 유형, 보안 그룹, IAM 인스턴스 프로파일, 사용자 데이터, 블록 디바이스 매핑을 참조합니다.

표준적인 무상태(stateless) 웹 패턴은 AMI + 시작 템플릿 + ASG + ALB입니다. AMI는 빠른 부팅을 제공하고, ALB(TCP/UDP의 경우 NLB)는 트래픽을 분산하고 상태 확인을 수행하며, ASG는 새 인스턴스를 대상 그룹에 자동으로 등록하고 비정상 인스턴스를 종료합니다. 다중 AZ 배포(최소 2개 AZ, 쿼럼 시스템의 경우 3개)는 필수입니다. 단일 서브넷에 연결된 ASG는 AZ 장애 발생 시 ASG 자체가 대체 인스턴스를 시작할 수 없으므로 AZ 중단을 견딜 수 없습니다.

MyASG:
  Type: AWS::AutoScaling::AutoScalingGroup
  Properties:
    MinSize: 2
    MaxSize: 20
    DesiredCapacity: 4
    VPCZoneIdentifier: [subnet-a, subnet-b]
    TargetGroupARNs: [!Ref AppTargetGroup]
    LaunchTemplate:
      LaunchTemplateId: !Ref AppLT
      Version: !GetAtt AppLT.LatestVersionNumber
    HealthCheckType: ELB
    HealthCheckGracePeriod: 120

조정 정책: 대상 추적, 단계, 예약, 예측

ASG 스케일링에는 네 가지 모드가 있으며, 각각 다른 문제를 해결합니다.

• **대상 추적(Target tracking)**은 지표를 선택하고 설정값(예: ASGAverageCPUUtilization = 50%, ALBRequestCountPerTarget = 1000) 근처로 유지합니다. 이는 자동 튜닝 방식으로, AWS가 경보를 관리하고 지표가 벗어남에 따라 속도를 조절합니다. 이것이 기본 선택이 되어야 합니다.
• **단계 조정(Step scaling)**은 지표가 범위를 벗어난 정도에 따라 용량을 단계적으로 추가하거나 제거하며, 경보 심각도에 따라 대응 규모를 조절해야 할 때 유용합니다.
• **단순 조정(Simple scaling)**은 레거시 방식입니다. 경보당 단일 조정만 수행하고, 조정 후 휴지 기간(cooldown) 동안 차단되므로 새로운 설계에는 선택하지 않아야 합니다.
• **예약 조정(Scheduled scaling)**은 cron 시간에 MinSize/DesiredCapacity/MaxSize를 변경합니다.
• **예측 조정(Predictive scaling)**은 최대 14일의 기록을 기반으로 머신러닝을 사용하여 다음 48시간을 예측하고, 급증 전에 용량을 미리 프로비저닝합니다.

동적 조정은 본질적으로 지연이 발생합니다. 지표가 임계값을 초과한 후에만 반응하며, 새 인스턴스가 부팅, 등록, 워밍업되는 데 수 분이 걸립니다. 모든 사용자가 09:00에 접속하여 ASG가 부하를 따라잡는 동안 2~3시간의 느림을 경험하는 업무용 앱의 경우, 동적 조정만으로는 잘못된 해결책입니다. 수요가 도달하기 전에 예약된 작업을 계층화하여 피크 시간 이전에 MinSize와 DesiredCapacity를 높이십시오:

ScheduledAction:
  AutoScalingGroupName: web-asg
  ScheduledActionName: pre-sale-warmup
  Recurrence: "0 8 * * *"
  MinSize: 20
  DesiredCapacity: 30
  MaxSize: 200

그런 다음 대상 추적이 남은 변동성을 흡수하도록 합니다. 예측 조정은 피크의 형태는 안정적이지만 정확한 시간이 매일 바뀌는 경우에 올바른 선택입니다. 예측 가능한 비프로덕션 환경 종료(야간 및 주말에 개발 환경 끄기)의 경우, 금요일 저녁에 desired=0, min=0으로 설정하고 월요일 아침에 다시 시작하는 예약된 작업이 가장 오버헤드가 적은 해결책입니다. ASG 자체가 스케줄 엔진이므로 Lambda나 EventBridge 같은 접착제 코드가 필요 없습니다.

정책 선택만큼 지표 선택도 중요합니다. CPU는 CPU 바운드 웹 워크로드에 효과적이지만, SQS에서 메시지를 가져오는 백로그 기반 워커의 경우 CPU가 아닌 대기열 깊이를 기준으로 스케일링해야 합니다. I/O에 의해 차단된 워커는 수백만 개의 메시지가 쌓이는 동안 CPU 사용률이 10%에 불과할 수 있습니다. 인스턴스당 ApproximateNumberOfMessagesVisible을 사용하십시오. 이는 사용자 지정 지표로 노출하거나 내장된 SQSQueueBacklogPerInstance 대상을 통해 사용할 수 있습니다:

backlog_per_instance = messages_visible / running_instances
target = acceptable_latency_seconds / avg_processing_seconds_per_msg

TargetTrackingConfiguration:
  CustomizedMetricSpecification:
    MetricName: BacklogPerInstance
    Namespace: MyApp/Scaling
    Statistic: Average
  TargetValue: 100

마찬가지로, 지연 시간에 민감한 HTTP 계층은 TargetResponseTime 또는 RequestCountPerTarget을 추적해야 합니다. 메모리, 디스크 또는 다운스트림 지연 시간 바운드 앱은 실제 병목 현상을 반영하는 사용자 지정 지표를 게시해야 합니다. CPU가 제약 조건이 아닐 때 CPU를 기준으로 스케일링하면 인스턴스가 스케일 아웃되지 않고, 대기열이 무한정 증가하며, ALB가 5xx 오류를 반환하는 실패 모드가 정확히 발생합니다.

상태 확인 및 수명 주기 후크

ASG는 기본적으로 EC2 상태 확인을 사용합니다. 이는 하이퍼바이저 장애는 감지하지만 애플리케이션 장애는 감지하지 못합니다. ASG에서 ELB 상태 확인을 활성화하면 교체 결정을 로드 밸런서의 애플리케이션 레벨 프로브에 위임하게 되며, 이는 OS는 정상이지만 프로세스가 멈춘 경우에 필수적입니다. HealthCheckGracePeriod는 사용자 데이터가 완료될 수 있도록 충분히 길게 설정해야 합니다. 그렇지 않으면 새 인스턴스가 부트스트랩 중간에 종료되는 루프에 빠지게 됩니다.

로드 밸런서 선택은 “정상"의 의미에 영향을 미칩니다.

TCP 상태 확인만 수행하는 NLB 뒤에 있는 HTTP 애플리케이션은, 연결은 수락하지만 500 오류를 반환하는 인스턴스로 계속 트래픽을 보냅니다. 의미 있는 신호를 복원하려면 ALB로 전환하거나 NLB에서 HTTP 상태 확인을 구성해야 합니다.

**수명 주기 후크(Lifecycle hooks)**는 인스턴스를 Pending:Wait 또는 Terminating:Wait 상태에서 일시 중지시켜 외부 자동화가 조치를 취할 수 있도록 합니다. 시작 시 후크를 사용하면 ALB가 트래픽을 보내기 전에 구성 관리 시스템에 등록하거나, 캐시를 준비(warm)하거나, 보안 정보를 가져올 수 있습니다. 종료 시 후크를 사용하면 세션을 드레이닝하고, 로그를 플러시하고, 서비스 메시에서 등록을 해제할 수 있습니다. 후크는 EventBridge 이벤트를 발생시키며, 핸들러는 CompleteLifecycleAction을 호출해야 합니다. 그렇지 않으면 후크가 시간 초과되어 기본값(CONTINUE 또는 ABANDON)으로 처리됩니다.

웜 풀 및 최대 절전 모드

콜드 런치 시간은 대규모 모델을 로드하거나, 캐시를 준비하거나, 서비스를 시작하기 전에 JIT 컴파일을 수행하는 애플리케이션에게 실질적인 문제입니다. **웜 풀(Warm pool)**은 ASG에 연결된 사전 초기화된 예비 인스턴스 그룹입니다. 인스턴스가 시작되고 부트스트랩을 실행한 다음, 중지되거나, 계속 실행되거나, 최대 절전 모드로 전환되어 ASG가 스케일 아웃할 때까지 풀에 보관됩니다. 풀에서 인스턴스를 가져오면 수 분이 걸리는 부팅 시간을 건너뛸 수 있습니다.

**최대 절전 모드(Hibernation)**는 OS를 암호화된 EBS 루트 볼륨에 일시 중단하여 재개 시 JVM 힙, ML 가중치, OS 페이지 캐시가 그대로 복원되도록 합니다. 요구 사항: RAM을 저장할 만큼 충분히 큰 암호화된 루트 볼륨, 지원되는 패밀리에서 인스턴스 RAM ≤ 150GB, 시작 시 HibernationOptions.Configured = true 설정. PoolState: Hibernated 상태의 웜 풀은 이 두 가지를 결합합니다. 인스턴스가 중지된 동안에는 컴퓨팅 비용이 발생하지 않으며, 메모리가 채워진 상태로 몇 초 만에 재개됩니다. 이는 “생산성을 갖추기 전에 메모리를 로드하는 데 오랜 시간이 걸리는” 애플리케이션에 적합한 패턴입니다.

확장 불가능한 워크로드를 위한 자동 복구

모든 워크로드가 수평적으로 확장되는 것은 아닙니다. MAC 주소에 종속된 라이선스, 파일 기반 잠금, 또는 공유 저장소 없는 인메모리 세션 상태를 가진 레거시 애플리케이션은 둘 이상의 인스턴스에서 실행될 수 없습니다. 추가 노드를 가동하면 데이터 손상이나 라이선스 위반이 발생합니다. 이러한 워크로드의 경우, 복원력은 스케일 아웃이 아닌 자동 복구에서 비롯됩니다.

두 가지 패턴이 효과적입니다. EC2 복구 작업과 연결된 StatusCheckFailed_System에 대한 CloudWatch 경보는 기본 호스트 장애 발생 시 인스턴스 ID, 프라이빗 IP, 탄력적 IP(Elastic IP), EBS 연결을 보존합니다. 더 간단한 방법은 여러 AZ에 걸쳐 MinSize=MaxSize=1로 설정된 ASG를 사용하는 것입니다. 이 방법은 실패한 인스턴스를 교체하며, 복구 작업과 달리 AZ 장애에서도 살아남을 수 있습니다. 단, 상태가 루트 볼륨 외부로 관리되거나 AMI를 다시 빌드할 수 있어야 합니다.

로드 밸런서 및 서브넷 배치

ALB는 L7에서 작동하며, HTTP/HTTPS를 종료하고, 호스트/경로/헤더 기반 라우팅, HTTP/2, WebSockets, WAF/Cognito/OIDC 통합을 제공합니다. NLB는 L4에서 작동하며, 클라이언트 IP를 보존하고, 고정 IP 및 TLS 패스스루, PrivateLink를 지원하며, 초당 수백만 개의 연결을 유지할 수 있습니다. Gateway Load Balancer는 트래픽 경로에 서드파티 어플라이언스(방화벽, IDS 등)를 삽입합니다.

서브넷 배치는 아키텍처가 가장 자주 실패하는 지점입니다. 인터넷 경유 ALB는 반드시 퍼블릭 서브넷에 연결되어야 합니다. 퍼블릭 서브넷이란 인터넷 게이트웨이로 향하는 0.0.0.0/0 라우팅이 있는 서브넷을 의미하며, 대상이 있는 각 AZ마다 하나씩 필요합니다. 대상 자체는 프라이빗 서브넷에 위치합니다. 만약 ALB가 프라이빗 서브넷에 배치되거나 “퍼블릭” 서브넷에 IGW 기본 경로가 없으면, 클라이언트는 연결 시간 초과를 겪게 됩니다. 대상에 도달하려면 대상 보안 그룹이 대상 포트에서 ALB의 보안 그룹으로부터의 인바운드를 허용해야 합니다. 동일한 VPC 내의 ALB와 대상 사이에는 NAT가 필요하지 않습니다.

Client → IGW → ALB (public subnets, SG: allow 443 from 0.0.0.0/0)
              → Targets (private subnets, SG: allow 8080 from ALB-SG)

비정상적인 대상이 단순히 등록 취소되는 것이 아니라 교체되도록 ASG에서 ELB 상태 확인을 활성화하십시오. 교차 영역 로드 밸런싱(ALB에서는 기본값, NLB에서는 선택 사항)은 각 AZ의 인스턴스 수에 관계없이 요청 분산을 균등하게 합니다. Route 53은 별칭(alias) 레코드(또는 여러 ALB에 걸친 가중치/지연 시간 정책)를 통해 ALB로 확인되어야 합니다. 절대로 Route 53을 개별 EC2 IP로 직접 지정해서는 안 됩니다. 왜냐하면 실패한 인스턴스는 TTL이 만료될 때까지 계속 트래픽을 받게 되며, ASG가 교체한 인스턴스는 다른 IP를 갖기 때문입니다.

구매 모델 및 혼합 인스턴스 플릿

구매 모델 선택은 아키텍처 패턴과 무관하게 EC2 비용을 절감할 수 있는 가장 큰 단일 수단입니다.

합리적인 전략은 기준(baseline) 부하는 Reserved Instances 또는 Savings Plan으로, 급증(burst) 부하는 On-Demand로, 내결함성 작업은 Spot으로 처리하는 것입니다. ASG에서는 이를 혼합 인스턴스 정책으로 표현합니다:

MixedInstancesPolicy:
  LaunchTemplate:
    LaunchTemplateSpecification:
      LaunchTemplateId: lt-0abc123
      Version: $Latest
    Overrides:
      - InstanceType: m5.large
      - InstanceType: m5a.large
      - InstanceType: m6i.large
      - InstanceType: m6a.large
  InstancesDistribution:
    OnDemandBaseCapacity: 4          # covered by Savings Plan
    OnDemandPercentageAboveBaseCapacity: 20
    SpotAllocationStrategy: price-capacity-optimized

인스턴스 유형을 다양화하면 Spot 풀의 깊이를 더하고 연관된 중단을 줄일 수 있습니다. price-capacity-optimized(또는 capacity-optimized)는 가격과 풀 깊이의 균형을 맞추어 인스턴스가 회수될 가능성을 줄입니다.

Spot은 상태 비저장(stateless), 체크포인트 설정 가능(checkpointable), 재시도 가능(retriable) 또는 수평적으로 중복된(horizontally redundant) 워크로드에 적합합니다. 예를 들어 ALB 뒤의 웹 워커, 자동 재시도가 설정된 Batch 작업, Spark 실행자, CI 러너 등이 있습니다. 항상 켜져 있어야 하는 중요한 서비스, 상태 저장 기본 데이터베이스 또는 복구 경로가 없는 리더 노드의 유일한 용량으로는 적합하지 않습니다. 2분 전 알림으로는 안전한 종료를 보장할 수 없으며, 특정 인스턴스 유형의 플릿 전체에 걸친 연관된 회수는 실제 장애 모드입니다. 요구사항에 “중단되어서는 안 된다"는 내용이 있다면 Spot은 부적합합니다.

반대의 함정은 실제로 가변적인 워크로드에 RI나 Savings Plan을 적용하는 것입니다. 사용 여부와 관계없이 시간당 약정 금액을 지불해야 하므로, 168시간 약정 하에 주 40시간 실행되는 워크로드는 예약의 76%를 낭비하게 됩니다. 가격이 아닌 용량 자체가 문제일 때(예: 이벤트 기반 급증, 재해 복구)는 On-Demand Capacity Reservation을 사용합니다. 이는 On-Demand 요금으로 순수한 AZ 범위의 보장을 제공하며, 할인을 위해 Savings Plan과 결합할 수 있습니다.

서버리스 컴퓨팅: Lambda 및 Fargate

서버리스는 용량 관리를 플랫폼으로 이전합니다. Lambda는 이벤트 기반의 단기 작업에 적합합니다. 예를 들어 S3 ObjectCreated 트리거, DynamoDB Streams, 처리량이 적은 SQS 소비자, API Gateway 백엔드, 글루 로직(glue logic) 등이 있습니다. 메모리(128MB – 10,240MB)는 CPU를 비례적으로 프로비저닝하므로, 메모리를 높게 조정하면 실행 시간이 단축되어 오히려 비용이 절감되는 경우가 많습니다. 하드 리밋이 그 범위를 정의합니다: 최대 15분 실행, 10GB 메모리, 10GB /tmp, 압축 해제된 배포 250MB(또는 컨테이너 이미지를 통해 10GB), 동기식 페이로드 6MB. 30분짜리 비디오 트랜스코딩, 몇 시간 걸리는 ETL 또는 GPU 훈련에 Lambda를 사용하는 것은 아키텍처적으로 잘못된 것입니다. 함수가 작업 중간에 시간 초과되고 재시도 로직은 낭비만 가중시킵니다. 지연 시간에 민감한 경로의 경우, Provisioned Concurrency를 사용하여 콜드 스타트와 VPC 연결 ENI 초기화 시간을 완화할 수 있습니다.

Fargate는 EC2 호스트를 관리할 필요 없이 컨테이너를 실행합니다. 작업이 15분을 초과하거나, 사용자 지정 런타임이 필요하거나, ECS/EKS 오케스트레이션에 적합하지만 팀이 용량 관리를 원하지 않을 때 올바른 선택입니다. Fargate는 vCPU-시간당 비용이 EC2 Spot보다 비싸므로, 안정 상태의 사용률이 높고 예측 가능할 때는 ECS에서 Spot을 사용하는 혼합 인스턴스 ASG가 더 저렴합니다. 급증하거나 예측 불가능한 트래픽의 경우 Fargate의 초당 과금 방식이 유리합니다.

많은 Lambda 함수를 오케스트레이션하기 위해서는 Step Functions가 SNS/SQS를 통해 연결하는 것보다 선호됩니다. 이는 시각적 실행 기록, 재시도 의미 체계, 중앙 집중식 오류 처리, 영구 상태를 제공하기 때문입니다. 표준 워크플로는 상태 전환당 과금되며 최대 1년까지 실행됩니다. Express 워크플로는 대용량, 단기 이벤트 처리에 최적화되어 있습니다.

유전체학, 몬테카를로 시뮬레이션, ETL과 같이 수천 개의 파라미터화된 컨테이너 작업을 팬아웃(fan-out)하는 경우, AWS Batch가 관리형 EC2, Spot 또는 Fargate 전반에 걸쳐 큐잉, 종속성 해결, 재시도, 프로비저닝을 처리합니다. 작업은 작업 정의(컨테이너 + vCPU/메모리 + IAM 역할)를 참조하며, Batch는 이를 적절한 크기의 인스턴스에 빈 패킹(bin-pack)합니다. Step Functions는 종종 하나의 상태 머신 내에서 Batch, Lambda, ECS를 오케스트레이션합니다.

Elastic Beanstalk

Beanstalk은 애플리케이션 번들로부터 ALB, ASG, EC2 인스턴스 및 선택적으로 RDS를 프로비저닝하는 관리형 PaaS입니다. CloudWatch 통합과 함께 롤링, 추가 배치를 사용한 롤링, 변경 불가(immutable), 블루/그린 배포를 지원합니다. 확장 정책은 환경 옵션(지표, 임계값, 최소/최대)으로 노출됩니다. Beanstalk은 기본적으로 버스트 가능 인스턴스 유형을 사용하므로, 일시적인 CPU 포화 상태

Systems Manager를 사용한 플릿 관리

SSH 및 배스천 패턴은 취약하고 보안 비용이 많이 듭니다. AWS Systems Manager가 이를 대체합니다. Amazon Linux 2, Ubuntu, Windows에 사전 설치된 SSM Agent와 AmazonSSMManagedInstanceCore 권한을 부여하는 인스턴스 프로파일만 있으면 됩니다.

• Run Command는 태그가 지정된 플릿 전반에 걸쳐 셸/PowerShell을 실행하고 출력을 통합합니다.
• Session Manager는 AWS API를 통해 대화형 셸을 엽니다. 인바운드 22번 포트나 배스천 호스트가 필요 없으며, 완전한 IAM 인증을 사용하고 세션은 S3 또는 CloudWatch Logs에 기록됩니다.
• Patch Manager는 유지 관리 기간(maintenance window)을 사용하여 일정에 따라 OS 패치를 적용합니다.

aws ssm send-command \
  --targets Key=tag:Env,Values=prod \
  --document-name AWS-RunShellScript \
  --parameters 'commands=["yum -y update"]'

예약된 시작/중지 자동화

업무 시간 외에 꺼져 있어야 하는 비프로덕션 EC2 및 RDS의 경우, 유지 관리가 거의 필요 없는 패턴은 EventBridge Scheduler → Lambda입니다. cron 규칙(cron(0 19 ? * MON-FRI *))은 태그가 지정된 리소스를 중지하는 Lambda를 호출하고, 두 번째 규칙은 07:00에 리소스를 시작합니다.

import boto3
ec2 = boto3.client('ec2'); rds = boto3.client('rds')

def handler(event, _):
    action = event['action']  # 'start' or 'stop'
    ids = [i['InstanceId'] for r in ec2.describe_instances(
        Filters=[{'Name':'tag:AutoStop','Values':['true']}]
    )['Reservations'] for i in r['Instances']]
    getattr(ec2, f'{action}_instances')(InstanceIds=ids)
    for db in rds.describe_db_instances()['DBInstances']:
        if any(t['Key']=='AutoStop' and t['Value']=='true' for t in db['TagList']):
            getattr(rds, f'{action}_db_instance')(DBInstanceIdentifier=db['DBInstanceIdentifier'])

이 방식은 서버리스이며, 패치할 플릿이 없고 태그를 기준으로 확장됩니다. AWS Instance Scheduler 솔루션도 동일하게 작동합니다. 한 가지 미묘한 점은, 중지된 RDS 인스턴스는 7일 후에 자동으로 시작되므로 중지 일정이 반복되어 다시 중지해야 한다는 것입니다. 주말에 용량을 0으로 만드는 예약된 작업을 사용하는 ASG와 결합하면 유휴 시간 비용이 0에 가까워집니다.

확장된 컴퓨팅 환경의 네트워킹 함정

NAT Gateway 배치. NAT 게이트웨이는 하나의 AZ에 위치합니다. 3개의 AZ에 걸쳐 있는 플릿이 us-east-1a의 단일 NAT를 통해 모든 이그레스 트래픽을 라우팅하면 us-east-1b/us-east-1c에서 오는 모든 패킷에 대해 AZ 간 전송 요금을 지불하게 되며, us-east-1a에 장애가 발생하면 이그레스 경로를 완전히 잃게 됩니다. 올바른 패턴은 AZ당 하나의 NAT 게이트웨이를 두고, 각 프라이빗 서브넷의 라우팅 테이블이 자체 AZ에 있는 NAT를 가리키도록 하는 것입니다. 이렇게 하면 트래픽이 해당 AZ 내로 한정되고 단일 AZ 장애 모드가 제거됩니다.

NAT 인스턴스. 단일 EC2 기반 NAT는 플릿이 커짐에 따라 대역폭 및 PPS 병목 현상을 유발하며, 단일 장애 지점(SPOF)이 됩니다. 관리형 NAT Gateway는 게이트웨이당 100Gbps까지 확장됩니다. AWS 서비스 트래픽의 경우 VPC 엔드포인트(S3/DynamoDB용 게이트웨이, 기타 서비스용 인터페이스)를 사용하면 NAT를 완전히 우회하여 비용을 절감하고 스케일 이벤트 중 포화 위험을 제거할 수 있습니다.

반복적으로 나타나는 설계 함정

• 단일 AZ ASG는 AZ 장애에서 살아남을 수 없습니다. 항상 최소 2개 AZ(쿼럼 시스템의 경우 3개)의 서브넷을 연결하고 MinSize ≥ 2를 유지해야 합니다.
• 모든 워크로드가 수평적으로 확장된다고 가정하는 것. 상태를 유지하거나, 단일 쓰기(single-writer)를 하거나, 클러스터링이 불가능한 라이선스를 가진 앱은 ASG 하에서 성능이 저하될 수 있습니다. 자동 복구를 사용하거나 먼저 리팩터링해야 합니다.
• 예측 가능한 피크에 대해 반응형 스케일링을 사용하는 것은 “처음 2~3시간 동안 느려지는” 증상을 유발합니다. 예약된 스케일링이나 예측 스케일링을 사용하여 미리 준비(pre-warm)해야 합니다.
• CPU가 제약 조건이 아닌데 CPU 기준으로 스케일링하는 것. 실제 병목 현상을 반영하는 지표(큐 깊이, 응답 시간, 연결 수)를 게시해야 합니다.
• **단순 스케일링(Simple scaling)**과 **시작 구성(launch configurations)**은 레거시입니다. 대상 추적(target tracking)과 시작 템플릿(launch templates)을 사용하는 것이 좋습니다.
• HTTP 앱에 TCP 전용 상태 확인을 사용하는 것은 고장 난 인스턴스를 로테이션에 남겨둡니다. HTTP 상태 확인(ALB 또는 NLB의 HTTP 모드 확인 사용)을 사용해야 합니다.
• 상태를 저장하거나 중단되어서는 안 되는 워크로드에 스팟 인스턴스를 사용하는 것 — 스팟 인스턴스는 체크포인트 설정이 가능하고 교체 가능한 워커를 필요로 합니다.
• 실제로 변동이 심한 워크로드에 예약 인스턴스나 Savings Plans를 사용하는 것 — 사용되지 않는 약정은 순전히 낭비입니다. 대신 라이트사이징과 스팟 인스턴스로 비용을 절감해야 합니다.
• Route 53을 개별 EC2 IP로 직접 연결하는 것 — DNS가 플릿의 변경(churn)을 반영하도록 ALB 별칭으로 라우팅해야 합니다.
• 인스턴스 스토어를 영구적인 스토리지로 취급하는 것 — 데이터는 중지, 종료 또는 호스트 장애 시 사라집니다.
• 스냅샷 복원 또는 AMI 시작 후의 지연 로딩(lazy-load) 지연 시간을 무시하는 것 — 대상 AZ에서 Fast Snapshot Restore를 활성화해야 합니다.

모든 도메인 · 컨테이너 및 오케스트레이션 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →

Amazon 찾아보기 →