성능 개선과 비용 최적화는 SAP-C02 D3 도메인에서 함께 출제되는 주제입니다. 단순히 더 빠르게 만드는 것이 목적이 아니라, 비용 대비 최적의 성능을 달성하는 아키텍처 결정 능력을 검증합니다.
핵심 질문은 두 가지입니다. "어떤 서비스가 이 시나리오에서 성능 병목을 해소하는가?" 그리고 "어떤 비용 최적화 옵션이 이 워크로드 패턴에 가장 적합한가?"입니다.
Global Accelerator vs CloudFront — 언제 무엇을 쓰는가
두 서비스는 모두 글로벌 성능을 개선하지만, 작동 방식이 근본적으로 다릅니다. 이 구분은 시험에서 가장 자주 출제되는 주제 중 하나입니다.
AWS Global Accelerator는 Anycast IP 기반 TCP/UDP 전송 가속기입니다. 2개의 고정 Anycast IPv4 주소를 사용하며, 사용자 트래픽이 가장 가까운 AWS 엣지 로케이션에 진입한 후 AWS 프라이빗 글로벌 네트워크를 통해 목적지까지 전달됩니다. 공인 인터넷 대신 AWS 내부망을 사용하므로 지연 시간이 60% 이상 개선되는 경우가 많습니다.
CloudFront는 HTTP/HTTPS 캐싱 CDN입니다. 정적·동적 콘텐츠를 400개 이상의 엣지 로케이션에 캐싱하여 사용자 가까이에서 콘텐츠를 제공합니다. DNS TTL 캐싱 문제가 없으며 HTTP 레이어에서 동작합니다.
| 기준 | Global Accelerator | CloudFront | |------|-------------------|-----------| | 프로토콜 | TCP/UDP (모든 프로토콜) | HTTP/HTTPS | | 캐싱 | 없음 (라우팅만) | 있음 (콘텐츠 캐싱) | | IP 주소 | 고정 Anycast IP 2개 | 동적 IP (도메인 사용) | | DNS 캐싱 문제 | 없음 (BGP 라우팅) | TTL 캐싱으로 전환 지연 가능 | | 적합한 케이스 | 게임, IoT, VoIP, 비HTTP 앱 | 웹사이트, API, 미디어 스트리밍 | | 트래픽 다이얼 | 리전 간 즉각 비율 조정 | 불가 |
DNS 캐싱 우회가 필요한 블루/그린 배포, TCP 기반 애플리케이션, 고정 IP가 필요한 경우라면 Global Accelerator가 답입니다.
CloudFront 심화 — Origin Shield, Lambda@Edge, CloudFront Functions
CloudFront의 Origin Shield는 CloudFront 배포와 오리진 사이에 추가 캐싱 계층을 배치합니다. 여러 엣지 로케이션이 오리진에 직접 요청하는 대신 Origin Shield를 경유하므로, 오리진 서버의 부하가 크게 줄어듭니다. 오리진이 온프레미스 서버이거나 처리 비용이 높은 API일 때 특히 유용합니다.
Lambda@Edge와 CloudFront Functions는 엣지에서 코드를 실행하는 두 가지 방법입니다.
Lambda@Edge는 CloudFront의 4가지 이벤트 단계(Viewer Request, Origin Request, Origin Response, Viewer Response)에서 실행됩니다. Node.js와 Python을 지원하며, 실행 시간이 최대 30초로 복잡한 로직도 처리할 수 있습니다. User-Agent 헤더 분석으로 모바일/데스크톱 콘텐츠를 분기하거나, DynamoDB를 조회해 동적으로 리다이렉트하는 패턴이 시험에 자주 나옵니다.
CloudFront Functions는 Viewer Request와 Viewer Response 단계에서만 실행되며 실행 시간이 1밀리초 이내로 제한됩니다. URL 정규화, 쿼리 파라미터 정렬, 헤더 추가처럼 경량 처리에 적합하며 비용이 Lambda@Edge보다 훨씬 저렴합니다. 캐시 키 정규화 패턴에서는 CloudFront Functions가 Viewer Request 단계에서 실행되므로 캐시 확인 전에 요청을 정규화할 수 있습니다.
EC2 배치 그룹(Placement Groups) — 세 가지 유형
배치 그룹은 인스턴스 간 물리적 배치 방식을 제어해 성능이나 가용성을 최적화합니다.
Cluster 배치 그룹은 동일한 AZ 내 근접 랙에 인스턴스를 배치합니다. 인스턴스 간 25~100Gbps의 초저지연 고대역폭 통신이 가능합니다. HPC(고성능 컴퓨팅), 기계 학습 분산 훈련처럼 tightly coupled 워크로드에 최적입니다. FSx for Lustre와 함께 사용하면 병렬 파일 I/O까지 극대화할 수 있습니다.
Spread 배치 그룹은 인스턴스를 서로 다른 물리적 랙에 분산 배치합니다. AZ당 최대 7개 인스턴스라는 제한이 있지만, 하나의 하드웨어 장애가 여러 인스턴스에 영향을 주지 않도록 설계됩니다. 소수의 중요한 인스턴스를 위한 고가용성 패턴입니다.
Partition 배치 그룹은 인스턴스를 파티션으로 나누고 각 파티션이 독립적인 랙 그룹을 사용합니다. AZ당 최대 7개 파티션을 지원하며 파티션당 수백 개의 인스턴스를 배치할 수 있습니다. Hadoop, Cassandra, HDFS처럼 loosely coupled 분산 시스템에 적합합니다.
Auto Scaling 고급 — Predictive Scaling + Warm Pool
기본 Auto Scaling은 현재 CPU나 네트워크 지표에 반응적으로 대응합니다. Predictive Scaling은 ML 기반으로 과거 패턴을 분석해 트래픽 급증 전에 미리 스케일 아웃합니다. 매일 오전 9시에 트래픽이 폭증하는 패턴이 있다면, 8시 50분에 미리 인스턴스를 추가해 실제 급증 시점에 이미 준비된 상태를 유지합니다.
Warm Pool은 미리 시작하고 초기화된 인스턴스를 대기 상태로 유지합니다. 스케일 아웃 이벤트 발생 시 콜드 스타트 없이 즉시 투입할 수 있습니다. 초기화 시간이 긴 애플리케이션(부팅 후 데이터 다운로드, 캐시 워밍 등)에서 응답 시간을 크게 개선합니다.
비용 최적화 — Spot 활용 전략
Spot Instance는 온디맨드 대비 최대 90% 저렴하지만 2분 전 회수 통보가 있습니다. 내결함성(Fault-tolerant)이 있고 중단을 견딜 수 있는 워크로드에 적합합니다.
ECS Fargate Spot은 ECS 워크로드에서 Spot의 비용 절감(최대 70%)을 활용합니다. 상태 비저장 서비스나 배치 처리에 특히 적합하며, 회수 2분 전 SIGTERM이 전송되어 Graceful Shutdown이 가능합니다.
Spot Fleet은 여러 인스턴스 유형과 AZ에 걸쳐 Spot 인스턴스를 다양하게 배분하는 분산 전략입니다. 단일 인스턴스 유형에만 의존할 때보다 회수 위험이 줄어들고 원하는 용량을 안정적으로 유지할 수 있습니다.
RDS Reserved Instances는 1년 또는 3년 약정으로 최대 72%를 할인받습니다. 24시간 7일 일정하게 실행되는 예측 가능한 워크로드에 이상적입니다. RDS Savings Plans는 존재하지 않습니다(EC2/Fargate 전용). Aurora Serverless v2는 가변 워크로드에 최적화되어 있어 항상 실행되는 고정 워크로드에는 비효율적입니다.
Right-sizing — Compute Optimizer 활용
Right-sizing은 실제 사용량에 맞게 인스턴스 크기를 조정해 불필요한 비용을 제거합니다.
AWS Compute Optimizer는 EC2, Auto Scaling Group, EBS, Lambda 함수의 Right-sizing 권장 사항을 제공합니다. Lambda의 경우 14~93일간의 호출 메트릭을 분석해 최적 메모리와 실행 시간을 권장합니다. API로 현재 설정과 권장 설정, 예상 비용 절감액을 조회할 수 있습니다. EventBridge Scheduler와 Lambda를 조합해 정기적으로 S3에 CSV로 저장하는 자동화 패턴도 출제됩니다.
Cost Explorer는 Reserved Instance와 Savings Plans 권장 사항을 제공하지만 Lambda 메모리 최적화는 지원하지 않습니다.
미사용 리소스 제거도 비용 최적화의 핵심입니다. Cost Explorer로 저활용 EC2를 식별하고, Trusted Advisor로 연결되지 않은 EBS 볼륨이나 사용하지 않는 탄력적 IP를 찾아 정리할 수 있습니다.
S3 비용 최적화 — Intelligent-Tiering과 특수 기능
S3 Intelligent-Tiering은 접근 패턴이 예측하기 어려운 데이터에 적합합니다. 30일 이상 접근하지 않으면 자동으로 저빈도 액세스 계층으로, 90일 이상이면 아카이브 즉시 액세스 계층으로 이동합니다. 각 계층 간 데이터 검색 비용이 없어 접근 빈도가 낮은 대용량 데이터 저장에 경제적입니다.
S3 Glacier Instant Retrieval은 분기당 1회 미만으로 접근하지만 즉각적인 검색(밀리초)이 필요한 아카이브 데이터에 최적입니다. S3 Standard 대비 약 68% 저렴합니다. Glacier Flexible Retrieval은 더 저렴하지만 1분~12시간의 복원 시간이 필요합니다.
불완전 멀티파트 업로드 비용도 놓치기 쉬운 낭비 요소입니다. S3 Lifecycle 규칙으로 일정 기간이 지난 불완전 업로드 조각을 자동 삭제할 수 있습니다.
시험 핵심 정리
"비HTTP(TCP/UDP) 프로토콜 글로벌 가속, 고정 IP 필요, DNS 캐싱 우회" -- Global Accelerator
"HTTP 콘텐츠 캐싱, CDN" -- CloudFront
"오리진 서버 부하 감소, 추가 캐싱 계층" -- CloudFront Origin Shield
"뷰어 요청 단계 경량 처리 (URL 정규화, 쿼리 파라미터 정렬)" -- CloudFront Functions (Lambda@Edge 아님)
"HPC 초저지연 고대역폭, tightly coupled" -- Cluster Placement Group
"소수 중요 인스턴스 하드웨어 장애 격리" -- Spread Placement Group
"Hadoop/Cassandra 분산 시스템" -- Partition Placement Group
"상태 비저장 서비스 최대 70% 비용 절감" -- ECS Fargate Spot
"RDS 24/7 일정 워크로드 최대 72% 할인" -- RDS Reserved Instances (RDS Savings Plans는 존재하지 않음)
"Lambda 메모리 Right-sizing 권장 사항" -- AWS Compute Optimizer (Cost Explorer는 Lambda 메모리 미지원)
"접근 패턴 불규칙한 대용량 데이터" -- S3 Intelligent-Tiering