5주차에서 다룬 데이터베이스 서비스들은 각각 다른 문제를 풀기 위해 만들어졌다. RDS는 전통적 관계형 DB를 관리 부담 없이, Aurora는 관계형 DB의 한계를 스토리지 재설계로, DynamoDB는 스키마 없이 수억 개의 항목을 밀리초로, ElastiCache는 메모리 속도로 반복 읽기를. 이 서비스들이 시험에서 어떻게 출제되는지 확실히 정리하는 날이다.
시험 문제는 대부분 "이 시나리오에서 무엇을 선택하겠는가"의 형태로 나온다. 여러 선택지 중 하나가 기술적으로 가능해 보이지만 나머지보다 더 나은 이유를 찾는 것이 핵심이다. 그 "더 나은 이유"를 찾으려면 각 서비스의 설계 목적과 제약을 내부에서 이해해야 한다. 기술을 외우는 것이 아니라 왜 그렇게 설계됐는지를 이해해야 하는 이유가 여기에 있다.
RDS의 시험 핵심은 Multi-AZ와 Read Replica의 차이다. 이 두 기능은 완전히 다른 목적으로 만들어졌는데도 자주 혼동된다. Multi-AZ는 동기 복제로 Standby를 유지하며, 장애 시 자동으로 Standby를 Primary로 승격하는 HA(고가용성) 도구다. Read Replica는 비동기 복제로 읽기 전용 복사본을 만들어 읽기 트래픽을 분산하는 도구다.
두 기능이 다른 목적이라는 증거: Standby는 평상시 트래픽을 처리하지 않는다. Primary 장애 시 자동 페일오버(60-120초)를 위해서만 존재한다