<aside> 🔵
AWS SAA 학습 시리즈 · 1/10 · 약 5분 · AWS SAA 학습 기록: 서비스 선택 기준을 연결하다
</aside>
2025.09~10 학습 기록을 다시 읽으며, 이 주제는 용어를 많이 아는 것보다 요구 사항을 먼저 읽는 습관과 연결된다고 느꼈다. 같은 기능처럼 보이는 서비스도 데이터의 형태, 장애 허용 범위, 운영 책임에 따라 답이 달라진다. 이 글은 특정 구성의 정답을 단정하기보다 선택의 출발점을 정리한다.
글로벌 인프라는 리전, 가용 영역, 엣지 로케이션처럼 서로 다른 목적의 단위로 나뉜다. 리전은 지리적으로 분리된 AWS 영역이고, 가용 영역은 리전 안에서 격리된 위치다. 한 리전에 여러 가용 영역을 두는 이유는 한 위치의 장애를 애플리케이션 전체 장애로 만들지 않기 위해서다. 사용자의 지연 시간과 데이터 위치 요구는 리전 선택의 출발점이며, 고가용성 요구는 리전 내부에서 여러 가용 영역을 쓰는 설계로 이어진다.
리전을 고른 뒤에는 단일 가용 영역에 모든 계층을 두지 않는지 살핀다. 웹 계층과 애플리케이션 계층을 여러 가용 영역에 배치하고, 장애가 난 대상에는 요청을 보내지 않게 만드는 흐름이 핵심이다. 전 세계 사용자를 이유로 무조건 여러 리전을 고르는 것이 아니라, 복구 목표·운영 복잡도·데이터 복제 방식을 함께 판단해야 한다.
| 질문 | 판단할 신호 |
|---|---|
| 가용성 | 장애가 나도 서비스가 계속되어야 하는 범위 |
| 운영 부담 | 직접 관리할 구성과 자동화할 구성의 경계 |
| 보안 | 접근 주체, 네트워크 경계, 권한 최소화 |
서비스 이름만 보고 선택하면 비슷한 기능이 모두 정답처럼 보인다. 하지만 ‘반드시 여러 위치에 분산해야 하는가’, ‘중단을 받아들일 수 있는가’, ‘공유 파일 경로가 필요한가’처럼 문장에 있는 제약을 표시하면 후보를 줄일 수 있다. 관리형이라는 표현도 아무것도 설정하지 않아도 된다는 뜻이 아니라, 내가 책임질 운영 영역이 달라진다는 뜻으로 읽어야 한다.
설계 리뷰에서는 요구 사항을 가용성·성능·비용·운영 부담·일관성·보안으로 나누어 적어 본다. 그다음 각 후보가 충족하지 못하는 조건을 한 줄씩 적는다. 이 기록은 선택의 이유를 남기고, 나중에 트래픽이나 데이터 특성이 바뀌었을 때 재검토할 기준이 된다.
서비스를 외우기보다, 먼저 제약을 읽고 그 제약을 가장 적게 훼손하는 선택을 찾는다.