Domain 2의 모든 문항은 결국 "이건 AWS가 해주나, 내가 해야 하나" 한 질문으로 되돌아온다. 그 답을 정하는 것이 공동 책임 모델이다.
데이터와 접근 권한은 어떤 서비스를 쓰든 항상 고객 책임이다. 이 한 줄이 보안 문항의 절반을 풀어 준다.
보안 서비스는 이름을 외우지 말고 "무엇을 막거나 찾아내는가"로 묶으면 된다. 막는 것(WAF·Shield), 찾아내는 것(GuardDuty·Inspector·Macie), 기록하는 것(CloudTrail·Config)으로 갈린다.
Domain 4는 시점(사전/사후), 주체(사람/도구), 목적(분석/알림/제한) 세 축만 잡으면 대부분 정리된다.
오늘도 목표는 읽는 것이 아니라 가리고 말해 보는 것이다.
어제는 클라우드 개념과 기술·서비스를 정리했다. 오늘은 나머지 두 영역, Domain 2 (보안 및 규정 준수, 30%) 와 Domain 4 (청구·요금·지원, 12%) 를 총정리한다. Domain 2는 비중이 두 번째로 큰 만큼 출제가 많고, Domain 4는 작지만 IAM·요금 도구처럼 헷갈리기 쉬운 포인트가 모여 있다.
"고객 데이터 암호화", "IAM 사용자 관리", "EC2 게스트 OS 패치"는 항상 고객 책임이다. 반대로 "데이터센터 물리 보안", "하드웨어 폐기"는 AWS 책임이다. 단, 관리형 서비스(RDS 등)는 OS 패치를 AWS가 담당하는 점에 주의하면 된다.
이 모델이 왜 필요한지는 클라우드 이전과 비교하면 분명해진다. 서버를 직접 사서 전산실에 두던 시절에는 경계선을 그릴 일이 없었다. 건물 출입 통제부터 디스크 폐기, 백업, 방화벽 설정까지 전부 우리 회사 몫이었다. 클라우드로 옮기면 그 일 중 상당수를 AWS가 대신 해 주는데, 문제는 "어디까지"가 눈에 보이지 않는다는 것이다. 그래서 AWS는 경계선을 문서로 명확히 그어 두었고, 그것이 공동 책임 모델이다.
세입자와 건물주로 바꿔 생각하면 쉽다. 건물의 골조·엘리베이터·소방 설비·현관 출입 통제는 건물주(AWS) 몫이다. 하지만 우리 집 현관문을 잠그는 것, 누구에게 열쇠를 복사해 줄지 정하는 것, 집 안의 귀중품을 금고에 넣을지 말지는 세입자(고객) 몫이다. 건물이 아무리 안전해도 내가 문을 열어 두면 소용이 없다. S3 버킷을 공개로 열어 두어 생기는 사고가 정확히 이 경우다.
책임 경계는 서비스 유형에 따라 움직인다. 이 이동을 그림으로 잡아 두면 된다.
관리형 정도 낮음 ───────────────────────────→ 높음
EC2 (IaaS) RDS Lambda / S3
OS 패치 = 고객 OS 패치 = AWS 실행 환경 = AWS
──────────────────────────────────────────────────
데이터 · 접근 권한 · 암호화 설정 = 언제나 고객
⚠️ 함정: "관리형 서비스를 쓰면 보안은 AWS가 다 알아서 한다"는 보기는 오답이다. 관리형으로 갈수록 운영 작업이 AWS로 넘어갈 뿐, 데이터 자체와 누가 접근할 수 있는지는 끝까지 고객 책임이다. 문항에 "데이터", "권한", "접근 제어", "암호화 활성화"라는 말이 있으면 답은 거의 고객 쪽이다.
⚠️ 함정: "EC2에서 도는 애플리케이션이 S3에 접근해야 한다"는 상황에서 액세스 키를 코드에 적어 두는 보기를 고르면 틀린다. 정답은 거의 언제나 IAM 역할(Role)이다. 키를 코드에 넣으면 소스가 유출되는 순간 계정도 함께 털리고, 키를 바꿀 때마다 배포를 다시 해야 한다. 역할은 임시 자격 증명을 자동으로 주고받으므로 이 두 문제가 모두 사라진다.
최소 권한 원칙은 "일단 넓게 주고 나중에 줄이자"의 반대다. 좁게 시작해 필요할 때 넓히는 방향으로 간다. 넓게 준 권한은 아무도 불편해하지 않기 때문에 줄일 계기가 영원히 오지 않는다는 것이 이 원칙이 존재하는 실무적 이유다. 보기에 "모든 사용자에게 관리자 권한", "전체 접근 허용" 같은 표현이 보이면 대개 오답 신호다.
웹 요청의 내용을 검사(SQL 인젝션·XSS 차단) vs 대량 트래픽 공격량을 막음(DDoS)
GuardDuty vs Inspector
계정·네트워크 활동에서 수상한 움직임 탐지 vs 워크로드의 알려진 취약점 점검
Inspector vs Macie
소프트웨어 취약점 vs S3에 담긴 민감 정보(개인정보 등) 탐지
CloudTrail vs Config
누가 무엇을 했나(행위 기록) vs 무엇이 어떻게 설정돼 있나(구성 상태)
CloudTrail vs CloudWatch
감사 로그 vs 성능 지표·모니터링
KMS vs Secrets Manager
암호화 키를 만들고 관리 vs 비밀번호·API 키를 보관하고 자동 교체
세 기록 서비스는 건물 관리로 비유하면 확실히 갈린다. CloudTrail은 출입문 CCTV와 출입 기록부(누가 언제 들어와 무엇을 했나), Config는 시설 점검 대장(소화기가 규정대로 비치돼 있나, 언제 바뀌었나), CloudWatch는 계기판(지금 전력 사용량과 온도가 얼마인가)다.
어느 날 회사의 EC2 인스턴스 하나가 새벽에 갑자기 대량의 외부 통신을 시작했다고 가정한다. 이 수상한 행동 자체를 알아채는 것이 GuardDuty이다. 조사에 들어가 "그 인스턴스가 언제, 어떤 계정으로 생성됐고 누가 보안 그룹을 열었는지" 확인하는 데 쓰는 것이 CloudTrail이다. "우리 회사 규칙상 열려 있으면 안 되는 포트가 열려 있었다"는 사실을 상시로 감지해 주는 것은 Config이고, 그 인스턴스에 오래된 취약점이 남아 있었는지 점검하는 것은 Inspector이다. 하나의 사건에서 네 서비스가 각각 다른 조각을 맡는다.
규정 준수 문항에서 Artifact는 "보고서를 받는 곳"이라는 점만 확실히 하면 된다. 감사 대응이나 고객사 실사에서 "AWS가 특정 인증을 지키고 있음을 증명하는 문서가 필요하다"는 상황이 나오면 답은 Artifact이다. 우리 계정이 규칙을 지키는지 확인하는 것(Config)과 혼동하지 않는 편이 낫다. Artifact는 AWS 쪽 증빙, Config는 우리 쪽 점검이다.
네 가지를 고르는 기준은 결국 "얼마나 오래, 얼마나 확실히 쓰는가" 하나다. 통신 요금제로 바꾸면 온디맨드는 약정 없는 종량제, RI는 조건까지 못 박은 장기 약정, Savings Plans는 "월 얼마 쓰겠다"만 약속하는 장기 약정, 스팟은 출발 직전 남은 좌석 특가다. RI와 Savings Plans가 끝까지 헷갈린다면 "무엇을 약속했는가"만 기억하면 된다 — RI는 자리를, Savings Plans는 금액을 약속한다. 그래서 유형이나 리전을 바꿔도 할인이 따라오는 쪽이 Savings Plans이다.
함정: "비용을 가장 많이 줄이는 방법"이라는 표현만 보고 반사적으로 스팟을 고르면 틀린다. 스팟은 AWS가 언제든 회수할 수 있어 중단을 견딜 수 있는 작업에만 해당한다. 보기나 지문에 "내결함성", "배치", "재시작 가능", "중단돼도 무방" 같은 표현이 함께 있어야 정답 후보가 된다. 상시 서비스되는 웹 서버나 데이터베이스에 스팟을 고르면 오답이다.
"예산을 넘으면 알림을 받고 싶다"면 Budgets, "과거 비용 추세를 분석"하려면 Cost Explorer, "아직 만들지 않은 리소스 견적"은 Pricing Calculator이다.
이 셋은 서 있는 시점이 다르다. 이 축 하나로 대부분의 비용 도구 문항이 갈린다.
과거 ────────────── 현재 ────────────── 미래
Cost Explorer Budgets Pricing Calculator
CUR (넘기 전 알림) (아직 안 만든 것)
(이미 쓴 돈)
가계부로 바꾸면 Cost Explorer는 월별 지출 그래프, Budgets는 카드 한도 초과 알림 문자, CUR은 항목이 전부 찍힌 영수증 원본, 비용 할당 태그는 영수증에 붙이는 '식비/교통비' 스티커다.
함정: Cost Explorer에도 앞으로의 비용을 예측하는 기능이 있어서 "예측"이라는 단어만 보고 이것을 고르는 실수가 잦다. 그 예측은 이미 쓰고 있는 것의 추세를 늘려 그린 선이다. 아직 만들지 않은 구성의 비용을 구하는 것은 Pricing Calculator이다. 지문에 "배포 전", "신규 설계", "아직 생성하지 않은"이 있으면 Cost Explorer가 아니다.
가족 결합 요금제를 떠올리면 그대로다. 가족 각자의 번호(계정)는 따로 있지만 요금은 한 장으로 나오고(통합 결제), 데이터는 가족끼리 나눠 쓴다(할인 공유). 부모가 자녀 회선에 차단을 걸어 두는 것이 SCP이다.
함정: SCP는 권한을 '주는' 도구가 아니라 '한도를 정하는' 도구다. SCP가 허용하더라도 계정 안의 IAM 정책이 허용하지 않으면 여전히 못 하고, IAM에서 관리자 권한을 줬어도 SCP가 막아 두었다면 할 수 없다. 울타리(SCP) 안에서 열쇠(IAM)를 쥐어 준다고 기억하면 된다. 또한 Organizations는 거버넌스, 통합 결제는 절감으로 역할이 다르다. "권한을 중앙에서 제한"이라는 문장에 통합 결제를 고르면 오답이다.
전담 TAM(Technical Account Manager) 이 필요하면 Enterprise 플랜이다. 24/7 전화 지원이 처음 제공되는 것은 Business 플랜부터다.
지원 플랜은 보험 등급으로 보면 이해가 빠르다. 평소에는 차이를 못 느끼지만 사고가 났을 때 누가 얼마나 빨리 오는지가 달라진다. 한 계단 올라갈 때 새로 생기는 것만 기억하면 표를 통째로 외울 필요가 없다.
Basic 문서 · 포럼 · 청구 문의 (기술 케이스 ✕)
└ + 기술 지원(이메일, 업무 시간) → Developer
└ + 24/7 기술 지원, 전체 Trusted Advisor → Business
└ + TAM(전담 사람), 가장 빠른 응답 → Enterprise
함정: "24시간 지원이 필요하다"만 보고 곧장 Enterprise를 고르면 요건을 초과한 오답이 된다. 24/7은 Business부터 제공된다. Enterprise의 결정적 신호는 TAM이나 가장 빠른 응답이다. 또한 TAM은 사람, Trusted Advisor는 도구다. 지문의 "전담", "자문", "담당자"는 사람 쪽이고 "점검", "권고", "자동 검사"는 도구 쪽이다.