SAA-C03 시험에서 데이터베이스 비용 최적화는 "워크로드 패턴에 맞는 용량 모드를 선택하고, 캐싱으로 DB 부하를 줄이는 것"입니다. 인스턴스를 항상 켜두는 것이 최선이 아니며, 실제 사용 패턴에 맞게 과금 방식을 선택하면 상당한 비용을 절감할 수 있습니다.
Aurora Serverless v2란 무엇인가요?
왜 존재하나요? 전통적인 데이터베이스는 인스턴스를 켜두면 아무도 쓰지 않아도 요금이 나옵니다. 트래픽이 예측 불가능하거나 간헐적인 서비스에는 이 비용이 큰 낭비입니다.
무엇인가요? 전기 계량기처럼 생각해보세요. 전기를 많이 쓰면 계량기 숫자가 빨리 올라가고, 아무도 안 쓰면 거의 멈춥니다. Aurora Serverless v2도 마찬가지입니다. 트래픽이 몰리면 용량이 자동으로 늘어나고(스케일 아웃), 한가해지면 거의 0에 가깝게 줄어듭니다(스케일 인). 사용한 컴퓨팅 용량만큼만 과금합니다.
어떻게 작동하나요? ACU(Aurora Capacity Unit)라는 단위로 용량을 측정합니다. 최소 ACU와 최대 ACU를 설정하면, 그 범위 안에서 Aurora가 자동으로 용량을 조절합니다. 최소를 0.5 ACU로 설정하면 유휴 시간에는 거의 비용이 발생하지 않습니다.
언제 씁니까? 개발·테스트 환경 (밤·주말에는 사용 없음) 사용자가 많지 않은 소규모 SaaS 서비스 간헐적으로 큰 부하가 오는 보고서 생성, 이벤트성 서비스
프로비저닝된 Aurora vs Aurora Serverless 비교
| 항목 | 프로비저닝 Aurora | Aurora Serverless v2 | |------|-----------------|---------------------| | 과금 방식 | 인스턴스 크기(시간당) | ACU 사용량(초 단위) | | 트래픽 패턴 | 예측 가능·안정적 | 간헐적·예측 불가 | | 유휴 비용 | 항상 발생 | 거의 0 | | 자동 스케일 | 수동 설정 필요 | 자동 |
팁: 트래픽이 안정적이고 예측 가능하다면 프로비저닝 + 예약 인스턴스가 더 저렴합니다.
!프로비저닝형 Aurora vs Aurora Serverless v2
DynamoDB 용량 모드
왜 존재하나요? DynamoDB는 읽기/쓰기 처리량을 어떻게 할당하느냐에 따라 비용이 크게 달라집니다. 트래픽 패턴을 알면 최적 모드를 고를 수 있습니다.
무엇인가요? DynamoDB는 두 가지 용량 모드를 제공합니다.
프로비저닝 모드 (Provisioned Capacity): 미리 읽기 유닛(RCU)과 쓰기 유닛(WCU)을 설정합니다. 마치 인터넷 요금제처럼 "월 100GB 요금제"를 고르는 것과 같습니다. 안정적이고 예측 가능한 트래픽에 적합합니다. Auto Scaling과 함께 쓰면 트래픽 변동에 자동 대응하면서도 비용 절감. 예약 용량(Reserved Capacity) 구매 시 최대 76% 할인.
온디맨드 모드 (On-Demand Capacity): 실제 요청 수에 따라 과금합니다. 마치 데이터 종량제처럼 "쓴 만큼만 냅니다." 트래픽이 예측 불가능하거나 새로운 서비스 초기에 적합합니다. 용량 계획이 필요 없지만 단가가 프로비저닝보다 높습니다.
| 모드 | 적합한 상황 | 단가 | 비용 예측 | |------|-----------|------|---------| | 프로비저닝 + 예약 용량 | 안정적·예측 가능 트래픽 | 낮음 | 쉬움 | | 프로비저닝 + Auto Scaling | 변동 있지만 예측 가능 | 낮음~중간 | 중간 | | 온디맨드 | 불규칙·간헐적 트래픽 | 높음 | 어려움 |
캐싱으로 데이터베이스 비용 줄이기
왜 존재하나요? 데이터베이스의 비용은 읽기·쓰기 요청 수에 비례합니다. 같은 데이터를 반복해서 DB에 물어보는 것은 낭비입니다. 자주 읽는 데이터를 빠른 캐시에 보관하면 DB 요청이 줄고 비용도 줄어듭니다.
아이스크림 가게를 예로 들어봅시다. 손님이 "오늘의 인기 메뉴가 뭔가요?"라고 물을 때마다 주방에 들어가 재고를 확인하면 힘들고 느립니다. 하지만 카운터에 "오늘의 인기 메뉴: 초코 아이스크림"이라고 써둔 칠판이 있다면, 주방에 들어갈 필요 없이 바로 답할 수 있습니다. 이 칠판이 캐시입니다.
ElastiCache for Redis
무엇인가요? 고성능 인메모리 데이터 저장소입니다. 데이터베이스에서 자주 조회되는 결과를 메모리에 저장해두고, 같은 요청이 오면 DB 대신 캐시에서 즉시 응답합니다.
언제 씁니까? 세션 데이터 관리 (로그인 상태 유지) 복잡한 쿼리 결과 캐싱 실시간 순위표, 카운터 복제(Replication)와 클러스터 구성이 필요한 고가용성 환경
ElastiCache for Memcached
무엇인가요? 단순한 키-값 캐시입니다. Redis보다 기능이 단순하지만 멀티스레드 아키텍처로 단순 캐시에서는 높은 처리량을 보입니다.
언제 씁니까? 단순한 객체 캐싱 멀티스레드 처리가 필요한 고처리량 환경 복제나 지속성(persistence)이 필요 없을 때
DynamoDB DAX (DynamoDB Accelerator)
왜 존재하나요? DynamoDB를 쓰는데 읽기 요청이 너무 많아서 비용이 크거나 응답이 느릴 때, 코드를 거의 바꾸지 않고 캐시를 추가할 수 있습니다.
무엇인가요? DynamoDB 앞단에 투명하게 붙는 인메모리 캐시입니다. 애플리케이션은 DAX 엔드포인트를 호출하고, DAX는 캐시 히트이면 즉시 응답, 미스이면 DynamoDB를 조회하여 결과를 캐시에 저장합니다.
핵심 특성: DynamoDB 전용 — 다른 DB에는 사용 불가 코드 변경 최소화 (엔드포인트만 교체) 마이크로초 응답 시간 (DynamoDB의 밀리초 대비)
RDS 비용 최적화
캐싱 외에도 RDS 자체를 최적화할 수 있습니다.
인스턴스 라이트사이징: AWS Compute Optimizer로 RDS 인스턴스의 실제 사용률 확인 CPU 20%만 쓰는 db.r5.xlarge라면 db.r5.large로 다운사이징 가능
예약 인스턴스: 1년 약정: 최대 40% 할인 3년 약정: 최대 60% 할인 RDS는 안정적으로 장기 운영하는 경우가 많으므로 예약 인스턴스 효과가 큼
멀티 AZ 재검토: 멀티 AZ는 고가용성을 위해 자동으로 대기 인스턴스를 유지하므로 비용이 2배 개발·테스트 환경에서는 고가용성이 필요 없으므로 단일 AZ로 전환하면 비용 절반
Read Replica와 캐시 조합: Read Replica를 여러 개 운영하는 대신, 캐시(ElastiCache)를 도입하면 Read Replica 수를 줄일 수 있어 이중 절감
시험 핵심 정리
"간헐적·예측 불가 DB 트래픽, 유휴 비용 최소화" -- Aurora Serverless v2
"전기 계량기처럼 쓴 만큼만 과금" -- Aurora Serverless의 핵심 특성
"안정적 트래픽, DynamoDB 최저 비용" -- 프로비저닝 + 예약 용량
"불규칙 트래픽, DynamoDB 용량 계획 불필요" -- 온디맨드 모드
"DB 읽기 부하를 캐시로 줄이기" -- ElastiCache (Redis 또는 Memcached)
"DynamoDB 전용 캐시, 코드 변경 최소" -- DAX
"Redis vs Memcached: 복제·세션 필요" -- Redis / "단순 키-값, 멀티스레드" -- Memcached
"개발 환경 DB 비용 절감" -- 단일 AZ RDS (멀티 AZ 불필요)
"RDS 인스턴스 크기 최적화" -- AWS Compute Optimizer
캐시를 도입하면 Read Replica를 줄일 수 있어 이중 절감 효과