<aside> 🔵
AWS SAA 학습 시리즈 · 2/10 · 약 5분 · AWS SAA 학습 기록: 서비스 선택 기준을 연결하다
</aside>
2025.09~10 학습 기록을 다시 읽으며, 이 주제는 용어를 많이 아는 것보다 요구 사항을 먼저 읽는 습관과 연결된다고 느꼈다. 같은 기능처럼 보이는 서비스도 데이터의 형태, 장애 허용 범위, 운영 책임에 따라 답이 달라진다. 이 글은 특정 구성의 정답을 단정하기보다 선택의 출발점을 정리한다.
EC2 인스턴스 선택은 이름을 외우는 일이 아니라 병목을 먼저 찾는 일이다. CPU 사용이 지배적인 작업은 컴퓨팅 최적화, 큰 데이터 집합을 메모리에 올려 처리하는 작업은 메모리 최적화, 로컬 스토리지의 높은 처리량이나 IOPS가 중요한 작업은 스토리지 최적화를 검토한다. 어느 하나가 뚜렷하지 않은 웹·애플리케이션 서버는 균형 잡힌 범용 계열부터 측정하며 시작할 수 있다.
구매 옵션은 실행 시간의 예측 가능성과 중단 허용 여부로 나눈다. 유연성과 짧은 기간이 우선이면 온디맨드, 일정한 사용 약속을 할 수 있는 지속 워크로드면 Savings Plans 또는 예약 인스턴스를 검토한다. 중단되어도 재시도 가능한 배치성 작업은 스팟을 후보로 둘 수 있다. 특정 가용 영역에서 반드시 필요한 용량이 핵심이면 용량 예약도 별도 판단 대상이다.
| 질문 | 판단할 신호 |
|---|---|
| 가용성 | 장애가 나도 서비스가 계속되어야 하는 범위 |
| 운영 부담 | 직접 관리할 구성과 자동화할 구성의 경계 |
| 보안 | 접근 주체, 네트워크 경계, 권한 최소화 |
서비스 이름만 보고 선택하면 비슷한 기능이 모두 정답처럼 보인다. 하지만 ‘반드시 여러 위치에 분산해야 하는가’, ‘중단을 받아들일 수 있는가’, ‘공유 파일 경로가 필요한가’처럼 문장에 있는 제약을 표시하면 후보를 줄일 수 있다. 관리형이라는 표현도 아무것도 설정하지 않아도 된다는 뜻이 아니라, 내가 책임질 운영 영역이 달라진다는 뜻으로 읽어야 한다.
설계 리뷰에서는 요구 사항을 가용성·성능·비용·운영 부담·일관성·보안으로 나누어 적어 본다. 그다음 각 후보가 충족하지 못하는 조건을 한 줄씩 적는다. 이 기록은 선택의 이유를 남기고, 나중에 트래픽이나 데이터 특성이 바뀌었을 때 재검토할 기준이 된다.
서비스를 외우기보다, 먼저 제약을 읽고 그 제약을 가장 적게 훼손하는 선택을 찾는다.