kyungs

2026 하계 모각코 2주차

K0ngs — Sun, 12 Jul 2026 23:07:42 +0900

2주차는 시험 비중이 가장 큰 도메인 1(보안 아키텍처)에 몰아 썼다. 1주차에 IAM 뼈대를 잡아둔 상태라 이번 주는 그 위에 얹히는 것들을 다뤘다. 페더레이션(엔터프라이즈 로그인), KMS 기반 암호화, S3 암호화 옵션, 보안 그룹과 NACL, WAF/Shield/GuardDuty 같은 관리형 보안 서비스, 그리고 Secrets Manager와 Parameter Store 비교까지. 개별 서비스 자체는 어렵지 않은데 서로 뭘 언제 쓰는지가 시나리오형 문제에서 계속 헷갈렸다.

참고 자료

이번 주에도 노션 "SAA 관련 자료" 페이지에 걸어둔 링크들을 그대로 활용했다. KMS와 네트워크 보안 부분은 Tutorials Dojo cheat sheet가 특히 도움이 됐다.

Charlie Kim - AWS Certified Solutions Architect – Associate 자격증 준비 과정 및 시험 후기
루이3 - AWS Certified – Associate 덤프 문제 사이트 (문제 풀이용)
velog G.log - 시리즈 [TIL] AWS Certified 준비 (SAA-C03, DVA-C02)
velog kyj311.log - 시리즈 Architecting on AWS 정리 (SAA 대비)
Tutorials Dojo - "KMS cheat sheet", "Security Group NACL cheat sheet" 검색
AWS 공식 문서 - KMS 개발자 가이드 (Envelope Encryption 부분)

1. 페더레이션과 IAM Identity Center

1주차에 STS/AssumeRole 개념까지 봤으니 이번 주는 그 확장판. 시험에서 "기업 내 AD 사용자가 AWS 콘솔에 접근" 같은 시나리오가 나오면 이 파트다.

SAML 2.0 페더레이션

사내 IdP(ADFS, Okta 등)와 AWS를 SAML로 연결
사용자가 IdP에 로그인 → IdP가 SAML Assertion 발급 → AWS STS의 AssumeRoleWithSAML로 임시 자격 증명 획득
AWS 계정 안에 별도 IAM User를 만들 필요가 없어서 관리 부담이 줄어든다

Web Identity Federation

Google, Facebook, Amazon 같은 OIDC 공급자로 로그인한 사용자에게 AWS 리소스 접근 부여
AssumeRoleWithWebIdentity 사용
실제로는 이걸 직접 다루기보다 Cognito로 감싸는 게 훨씬 흔함

Amazon Cognito

헷갈리기 쉬운 두 컴포넌트가 있다.

User Pool: 사용자 로그인 자체를 관리 (회원가입, 로그인, MFA, 소셜 로그인). 결과물은 JWT 토큰
Identity Pool: 로그인한 사용자에게 AWS 임시 자격 증명 발급. 결과물은 STS 자격 증명

앱 사용자가 S3에 직접 업로드하는 시나리오라면:
User Pool로 로그인 → Identity Pool로 임시 자격 증명 받음 → S3에 직접 요청

IAM Identity Center (구 AWS SSO)

여러 AWS 계정 + 사내 사용자를 한 곳에서 관리
Organizations와 연동해 계정별 권한 세트를 통합 관리
시나리오에 "여러 계정에 대한 단일 로그인" 나오면 이 서비스

시험 힌트 정리:

사내 AD → SAML 페더레이션 or IAM Identity Center
모바일 앱 사용자 → Cognito Identity Pool
소셜 로그인 → Cognito User Pool
여러 AWS 계정 통합 로그인 → IAM Identity Center

2. KMS와 데이터 암호화

이번 주에 가장 시간을 많이 쓴 파트. 시험에 "저장 데이터 암호화(Encryption at Rest)" 관련 문제가 계속 나온다.

2.1 대칭키 vs 비대칭키

대칭 CMK: 하나의 키로 암/복호화. 대부분의 AWS 서비스 통합 (S3, EBS, RDS 등). 성능 좋음
비대칭 CMK: 공개키/개인키 쌍. 서명 검증이나 외부에 공개키만 배포해야 하는 경우

시험에선 대부분 대칭키를 쓴다고 보면 된다. 비대칭은 "외부에 키를 노출하지 않고 서명"류 문제.

2.2 KMS 키 종류

종류 관리 주체 특징

AWS Owned Key	AWS	여러 계정이 공유. 보이지 않고 로그도 없음
AWS Managed Key	AWS	aws/서비스명 형식. 확인은 가능, 무료
Customer Managed Key (CMK)	고객	정책/순환/삭제 직접 제어. 월 $1 + API 호출 요금

CMK만 KMS Key Policy를 세밀하게 편집 가능. 시험에서 "키 정책 편집", "감사 로그 필요", "삭제 지연 필요"가 요건이면 무조건 CMK.

2.3 자동 키 순환

AWS Managed Key: 매년 자동 순환 (변경 불가)
CMK: 옵션으로 매년 자동 순환. 기본은 꺼져 있음
순환 후에도 예전 키 소재는 남아 있어서 이전에 암호화된 데이터도 복호화 가능

2.4 Envelope Encryption (반드시 이해)

https://medium.com/@dipandergoyal/aws-kms-envelop-encryption-explained-9db3bd56542b

KMS 자체는 4KB 이상 데이터를 직접 암호화하지 못한다. 그래서 실제 데이터는 Data Key로 암호화하고, Data Key를 KMS CMK로 암호화하는 방식.

평문 데이터 ──[Data Key로 암호화]──> 암호문
Data Key ──[CMK로 암호화]──> 암호화된 Data Key (암호문 옆에 함께 저장)

주요 API:

GenerateDataKey: 평문 Data Key + 암호화된 Data Key 함께 반환
GenerateDataKeyWithoutPlaintext: 나중에 복호화용으로 저장할 때
Decrypt: 암호화된 Data Key를 KMS에 보내 평문 Data Key 획득

시험 문제 힌트: "4KB보다 큰 데이터를 KMS로 암호화" → Envelope Encryption / GenerateDataKey.

2.5 CloudHSM

하드웨어 보안 모듈(HSM) 을 고객 전용으로 제공
FIPS 140-2 Level 3 준수. 규제 요건이 KMS로 부족할 때
키 관리를 AWS도 못 보게 완전히 고객이 통제해야 하는 경우
KMS와 달리 서비스 통합이 자동으로 안 됨. 애플리케이션 레벨에서 붙여야 함

3. S3 암호화 옵션

https://digitalcloud.training/amazon-s3-and-glacier/

시험에 자주 나오는 옵션들. 이름이 비슷해서 반드시 정리해둬야 한다.

옵션 키 소유 키 관리 사용 예

SSE-S3	AWS	AWS 완전 관리, AES-256	기본, 별 요건 없을 때
SSE-KMS	AWS/고객	KMS CMK로 관리, 감사 로그	감사/규제 요건, 키 정책 필요
DSSE-KMS	AWS/고객	이중 계층 암호화	국방/정부급 규제 요건
SSE-C	고객	고객이 키 직접 제공, AWS는 보관 안 함	키를 AWS 밖에서 관리해야 할 때
Client-Side Encryption	고객	업로드 전 클라이언트에서 암호화	AWS를 완전히 신뢰 못 할 때

2023년부터 S3 신규 객체는 SSE-S3가 기본 활성화된다. 이거 놓치면 안 됨.

시험 힌트:

"감사 로그로 누가 언제 키 썼는지 추적" → SSE-KMS
"AWS에 키를 절대 저장하지 않음" → SSE-C or Client-Side
"규제상 이중 암호화" → DSSE-KMS

S3 Bucket Key: SSE-KMS에서 KMS API 호출을 대폭 줄여주는 옵션. 대용량 요청에서 비용 최대 99% 절감. 시나리오에 "SSE-KMS 비용이 너무 높음" 나오면 답은 이거.

4. Security Group vs NACL

https://cloudviz.io/blog/aws-security-group-vs-nacl

이 두 개 비교는 시험 단골. 표로 정리.

항목 Security Group NACL

적용 대상	ENI (인스턴스 레벨)	서브넷 레벨
상태(State)	Stateful (반환 트래픽 자동 허용)	Stateless (양방향 규칙 필요)
규칙 종류	Allow만 가능	Allow 및 Deny 가능
규칙 평가	전부 평가 후 하나라도 매치되면 허용	번호 순서대로 평가, 매치되면 즉시 결정
기본 정책	모든 인바운드 차단, 모든 아웃바운드 허용	기본 NACL은 모두 허용, 커스텀 NACL은 모두 차단

실제로 헷갈리는 포인트

Stateful의 의미: SG에서 인바운드 80 포트만 열어도, 그에 대한 응답은 아웃바운드 규칙과 무관하게 자동으로 나간다. NACL은 반대로 아웃바운드 응답 포트(에페메랄 포트 1024–65535)를 별도로 열어줘야 한다.

Deny가 필요할 때: SG에는 Deny 규칙이 없다. 특정 IP만 차단해야 하면 NACL을 써야 한다. 시나리오에 "특정 악성 IP 차단" 나오면 SG가 아니라 NACL이 답.

규칙 번호: NACL 규칙은 낮은 번호부터 평가되므로, 100번에 Allow가 걸리고 200번에 Deny를 놓으면 200번 규칙은 무시된다. 반대로 100번에 Deny, 200번에 Allow면 Deny가 이김.

NAT Gateway

Private Subnet의 인스턴스가 인터넷을 나가야 할 때 사용
Public Subnet에 배치. Private에 배치하면 아무 의미 없다는 게 시험 함정
NAT Gateway는 관리형/고가용성, NAT Instance는 저렴하지만 직접 관리
최신 시험은 대부분 NAT Gateway가 답

5. 관리형 보안 서비스

https://aws.amazon.com/ko/blogs/korea/aws-heroes-putting-aws-security-services-to-work-for-you/

이름이 다 비슷해서 헷갈리는 것들. 한 문장씩 정리했다.

서비스 역할 사용 시점

AWS WAF	HTTP/HTTPS 계층(L7) 웹 방화벽	SQL Injection, XSS 차단
AWS Shield Standard	무료 L3/L4 DDoS 보호	자동 적용
AWS Shield Advanced	유료 고급 DDoS 보호 + WAF 포함	대규모 서비스
GuardDuty	위협 탐지 (지속적 모니터링)	이상 API 호출, 크립토 마이닝 등
Macie	S3 내 민감 데이터(PII) 자동 발견	개인정보 스캔 요건
Inspector	EC2/ECR/Lambda 취약점 스캔	CVE 자동 검사
Security Hub	여러 보안 서비스 결과 통합 대시보드	중앙 관제
Detective	보안 이벤트 원인 조사 (그래프 분석)	사고 후 포렌식

시나리오 힌트

"SQL Injection 방어" → WAF
"DDoS로 사이트 다운" → Shield Advanced
"S3에 개인정보가 있는지 스캔" → Macie
"EC2 AMI에 알려진 취약점 검사" → Inspector
"이상한 API 호출/암호화폐 마이닝 탐지" → GuardDuty
"여러 보안 서비스 결과를 한 화면에서" → Security Hub

CloudTrail, Config는 보안 서비스는 아니지만 함께 자주 언급된다:

CloudTrail: API 호출 감사 로그
Config: 리소스 구성 변경 이력, 규정 준수 평가

6. Secrets Manager vs Parameter Store

기밀 정보 저장은 이 두 개 중 하나로 좁혀진다.

항목 Secrets Manager SSM Parameter Store

자동 순환	가능 (RDS/Redshift 등 통합)	불가 (직접 구현 필요)
비용	시크릿당 월 $0.40 + API 호출	표준 무료, Advanced $0.05/시크릿
최대 크기	64KB	표준 4KB, Advanced 8KB
KMS 통합	기본 지원	SecureString 타입에서 지원
크로스 계정 공유	리소스 정책으로 가능	불가 (직접 로직 필요)

시험 힌트:

"DB 자격 증명 자동 순환" → Secrets Manager
"비용 최소화" or "환경 변수 대체" → Parameter Store
"설정 값 저장 (기밀 아님)" → Parameter Store

7. 실전 문제 풀이

이번 주도 ExamTopics SAA-C03에서 보안 관련 문제를 골라 풀었다. 유형별로 3개.

문제 1 (S3 암호화 자주 나오는 유형)

한 회사가 S3에 대용량 로그 파일을 SSE-KMS로 암호화하여 저장한다. 최근 KMS API 요청량이 급증하면서 요금이 부담스러워졌다. 데이터 보안은 유지하면서 비용을 줄이는 방법은?

A. 암호화 방식을 SSE-S3로 변경한다
B. S3 Bucket Key를 활성화한다
C. CloudFront를 통해 S3에 접근하도록 변경한다
D. 데이터를 압축하여 저장한다

정답: B

S3 Bucket Key는 버킷 레벨에서 임시 데이터 키를 캐시해 KMS API 호출을 크게 줄인다. 공식 문서에서는 최대 99%까지 요금 절감을 언급한다. 보안 수준은 SSE-KMS와 동일. A는 감사 로그가 사라지고, C는 무관하며, D는 KMS 호출 수와 무관하다.

문제 2 (SG vs NACL 자주 나오는 유형)

한 회사가 EC2 인스턴스에 대해 특정 IP 대역에서 오는 트래픽을 명시적으로 차단해야 한다. 이 인스턴스는 여러 서브넷에 분산되어 있다. 어떻게 구성해야 하는가?

A. 보안 그룹에 해당 IP를 Deny 규칙으로 추가한다
B. 서브넷의 NACL에 해당 IP를 Deny 규칙으로 추가한다
C. VPC의 라우팅 테이블에서 해당 IP를 블랙홀로 라우팅한다
D. IAM 정책에 조건 키를 사용해 IP를 차단한다

정답: B

Security Group은 Deny 규칙이 없다. 특정 IP 차단은 무조건 NACL. NACL은 서브넷 레벨이라 여러 서브넷에 각각 적용해야 하지만 요구사항 자체가 서브넷 분산이므로 문제 없음. C는 인바운드 차단에 부적합, D는 AWS API 호출 제한이지 네트워크 계층 차단이 아니다.

문제 3 (관리형 보안 서비스 비교 유형)

한 회사가 AWS 계정에서 발생하는 비정상적인 API 호출과 크립토 마이닝 시도를 탐지하고 싶다. 별도 에이전트 설치 없이 지속적으로 모니터링해야 하며, 여러 계정에 걸쳐 결과를 통합 관리할 수 있어야 한다. 가장 적합한 조합은?

A. GuardDuty를 활성화하고, 여러 계정 결과를 Security Hub에 집계
B. Inspector를 EC2에 설치하고 CloudWatch로 알람 설정
C. Macie로 S3를 스캔하고 SNS로 알림
D. CloudTrail 로그를 Athena로 직접 쿼리

정답: A

GuardDuty는 CloudTrail/VPC Flow Logs/DNS 로그를 기반으로 에이전트 없이 이상 API 호출과 마이닝을 탐지한다. Security Hub는 여러 계정의 GuardDuty 결과를 통합 대시보드로 제공. Inspector(B)는 취약점 스캐너지 이상 행위 탐지가 아님. Macie(C)는 S3 민감 데이터 스캔용. D는 지속적 모니터링에 부적합하다.

8. 이번 주 회고

지난 주 IAM을 정리해뒀던 게 이번 주에 계속 도움이 됐다. 결국 이번 주에 나온 서비스 대부분이 IAM 정책이나 리소스 정책 위에 얹혀 있는 형태였고, S3 암호화 옵션도 SSE-KMS면 어차피 KMS Key Policy가 붙는다. 보안 도메인이 IAM을 축으로 확장된다는 감각이 이제야 잡힌 것 같다.

가장 힘들었던 건 KMS의 Envelope Encryption과 CMK/AWS Managed Key/AWS Owned Key 구분이었다. 처음엔 다 KMS니까 비슷비슷하게 봤는데, 누가 키 정책을 편집할 수 있느냐는 관점으로 다시 보니 CMK만 답이 되는 이유가 명확해졌다. 시나리오형 문제에서 감사 로그 필요, 키 정책 커스터마이징 필요, 삭제 지연 필요 같은 단어가 나오면 자동으로 CMK로 정답이 좁혀진다.

또 다른 큰 수확은 Security Group과 NACL을 완전히 분리해서 이해한 것. 예전에는 대충 "둘 다 방화벽"이라고 뭉뚱그렸는데, Stateful/Stateless 개념을 노트에 그림으로 그려두고 나니 문제에서 어느 쪽을 물어보는지 즉시 판별 가능해졌다. 특히 Deny 규칙 필요가 나오면 무조건 NACL이라는 사실은 앞으로 계속 써먹을 것 같다.

관리형 보안 서비스들은 이름과 역할을 한 문장으로 매핑해서 노션 "SAA Tip"에 옮겨뒀다.

팀원 블로그

정재현 블로그

https://blog.naver.com/jjaehyun__/224344487255

[2026 하계 모각코] 2주차 모임

2주차 목표: LC Part 3~4 + RC Part 5 문법 기초 1주차에서 시험 전체 구조를 훑어봤다면, 2주차는 ...

blog.naver.com

박소윤 블로그

https://coding567.tistory.com/128

[2026 하계모각코] 2차시 결과

coding567.tistory.com

2주차 모임 사진

2026 하계 모각코 1주차

K0ngs — Tue, 7 Jul 2026 20:41:40 +0900

첫 주는 AWS 전반 구조와 IAM에 시간을 몰아 썼다. 학교에서 클라우드 부전공을 하면서 EC2, S3, VPC 정도는 다뤄봤지만 SAA 관점에서 다시 보니 놓쳤던 게 많았다. 특히 IAM은 시험 30% 비중인 보안 도메인의 핵심이고, 사실상 모든 시나리오 문제에 얽혀 나온다고 해서 이번 주는 IAM에 절반 이상을 썼다.

노션에 학습 페이지를 아래처럼 정리해두고, 매주 이 구조로 채워 갈 계획이다.

노션 강의 노트

SSA - 자격증 취득 로드맵
SAA 정리 (주차별 개념 요약)
SAA Tip (문제 풀 때 자주 나오는 함정 정리)

참고 자료

이번 주에 참고한 자료들. 노션 "SAA 관련 자료" 페이지에 링크로 걸어뒀다.

SAA 관련 자료

1. AWS 글로벌 인프라 (심화)

기본 개념(Region/AZ/Edge)은 대부분 알고 있어서, 시험에서 헷갈리는 지점 위주로 정리했다.

https://builder.aws.com/content/36pS4SZIOBsB0L0ns0WZb68XBNc/why-aws-stop-fighting-latency-a-deep-dive-into-aws-infrastructure-components

AZ의 실체

AZ는 "물리적으로 분리된 데이터센터" 하나가 아니라, 여러 데이터센터 묶음이다. 각 AZ는 저지연 링크로 연결되어 있지만 물리적, 전원, 네트워킹은 독립적으로 구성된다. 그래서 다중 AZ 배포는 "다른 건물에 복제" 수준이 아니라 실제 재해 격리가 된다.

Region 간 이동은 자동이 아니다

S3, DynamoDB Global Tables, RDS 크로스 리전 복제 등은 명시적으로 설정해야 리전 간 복제가 일어난다. 기본값은 리전 종속이다. 시험 문제에서 "리전 하나가 완전히 다운되어도 서비스 지속" 요건이 나오면 반드시 크로스 리전 아키텍처를 골라야 한다.

확장 인프라 개념 (자주 물어봄)

Local Zone: 특정 대도시에 배치된 소형 인프라. 초저지연이 필요한 워크로드용
Wavelength Zone: 5G 통신사 망 안에 배치. 모바일 엣지 컴퓨팅
Outposts: AWS 하드웨어를 온프레미스에 설치. 하이브리드/데이터 주권 요건
Edge Location: CloudFront/Global Accelerator/Route 53이 사용. 400+개, AZ보다 훨씬 많음

시나리오에 "초저지연", "특정 도시", "모바일", "온프레미스 데이터 유지"가 나오면 이 4개 중 하나가 정답인 경우가 많다.

서울 리전 팩트체크

리전 코드: ap-northeast-2
AZ: 4개 (ap-northeast-2a/b/c/d)
AZ 이름은 계정마다 물리 AZ에 매핑되는 방식이 다르다. 내 계정의 2a와 다른 계정의 2a가 같은 물리 AZ가 아닐 수 있음. 이걸 통일하려면 AZ ID(apne2-az1 등)를 봐야 한다.

2. 공동 책임 모델 (Shared Responsibility Model)

https://aakibkhan1.medium.com/aws-shared-responsibility-model-part-1-65be5ad93453

시험에서 "이 상황은 AWS 책임인가, 고객 책임인가"로 물어보는 문제가 종종 있다.

AWS 책임 ("of the Cloud"): 물리 인프라, 호스트 OS, 하이퍼바이저, 네트워크 백본, 관리형 서비스의 내부 운영
고객 책임 ("in the Cloud"): 게스트 OS 패치, 애플리케이션, IAM 사용자/권한, 방화벽(보안 그룹/NACL) 설정, 데이터 암호화 설정

헷갈리는 케이스

EC2: OS 패치는 고객 책임 (SSM Patch Manager로 자동화 가능하지만 어쨌든 책임 주체는 고객)
RDS: 엔진 패치는 AWS, DB 사용자 계정과 데이터 자체는 고객
Lambda: 런타임 유지보수는 AWS, 함수 코드와 IAM 실행 역할은 고객
S3: 인프라 가용성은 AWS, 버킷 정책과 암호화 설정은 고객. 그래서 S3 데이터 유출 사고가 나면 대부분 고객 잘못이다

3. IAM 심화

이번 주의 메인. 노션 IAM 페이지에 아래처럼 나눠서 정리해뒀다.

3.1 자격 증명 유형 정리

구분자격 증명 방식지속 여부사용 예

Root User	이메일/비밀번호	영구	계정 초기 설정, 결제 정보 변경
IAM User	액세스 키 or 콘솔 비번	영구	사람 or 애플리케이션
IAM Group	자체 자격 증명 없음	-	사용자 묶음, 정책 일괄 부여
IAM Role	STS 통해 임시 발급	임시 (기본 1시간)	서비스/크로스 계정/페더레이션

Group에는 자격 증명이 없다는 점, 그리고 Group을 Group에 중첩 못한다는 점이 시험 함정으로 자주 나온다.

3.2 정책의 6가지 유형

시험은 각 정책을 언제 써야 하는지를 물어본다.

Identity-based Policy (자격 증명 기반) — User/Group/Role에 붙임
Resource-based Policy (리소스 기반) — 리소스에 직접 붙임 (S3 버킷 정책, KMS 키 정책, SNS 토픽 정책 등). Principal 필드가 있는 게 특징
Permission Boundary — IAM 엔터티가 가질 수 있는 최대 권한의 상한선. 실제 권한을 주는 게 아니라 "여기까지"라는 울타리
Service Control Policy (SCP) — AWS Organizations에서 계정 전체에 대한 상한선. 관리 계정 하위 계정들의 최대 권한 제한
Session Policy — AssumeRole 할 때 인라인으로 넘겨서 그 세션에만 적용되는 정책
ACL — 오래된 방식 (S3 ACL). 현대 아키텍처에서는 잘 안 씀

3.3 정책 JSON 뜯어보기

기본 구조:

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadOnlyS3",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ],
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}

포인트:

Version은 항상 2012-10-17. 최신 문법 쓰겠다는 뜻
Action은 서비스:작업 형식. 와일드카드(s3:*) 사용 가능
Resource에서 버킷 자체(my-bucket)와 객체(my-bucket/*)는 별개의 ARN. ListBucket은 버킷 대상, GetObject는 객체 대상
Condition은 AND로 묶이고, 같은 조건 안 여러 값은 OR
Resource-based policy에는 Principal 필드가 추가로 들어감 (누가 접근할 수 있는지 명시)

3.4 정책 평가 로직 (제일 헷갈렸던 부분)

한 번의 요청에 여러 정책이 동시에 걸릴 수 있다. AWS는 아래 순서로 판단한다.

기본은 암묵적 거부(Implicit Deny)
명시적 Deny가 하나라도 있으면 → 거부
SCP에서 허용 안 되어 있으면 → 거부 (Organizations 계정인 경우)
Permission Boundary 밖의 권한이면 → 거부
Session Policy 밖의 권한이면 → 거부 (임시 자격 증명일 때)
Identity-based 또는 Resource-based에서 명시적 Allow → 허용
아무 것도 Allow 안 됐으면 → 암묵적 거부

핵심은 Deny가 무조건 이긴다는 것과, Permission Boundary/SCP는 권한을 주지 않고 제한만 한다는 것.

시나리오 예시: 개발자에게 ec2:* 정책을 이미 부여했는데, 큰 인스턴스 타입은 못 쓰게 막고 싶다면?
→ 답은 Permission Boundary. 기존 정책을 수정하지 않고 상한선만 걸면 됨.

https://medium.com/@mehrdadmohsenizadeh/aws-iam-policy-evaluation-logic-0ba377e8fdaf

3.5 STS와 임시 자격 증명

임시 자격 증명이 왜 중요한지 부전공 수업에서는 대충 넘어갔는데, 시험에서는 이게 계속 나온다.

**STS (Security Token Service)**가 임시 자격 증명을 발급
주요 API: AssumeRole, AssumeRoleWithSAML(기업 AD 페더레이션), AssumeRoleWithWebIdentity(구글/페이스북 로그인)
임시 자격 증명 구성: Access Key + Secret Key + Session Token (이 세 번째가 있어야 임시)
기본 만료 15분~12시간, Role Chaining 시 최대 1시간
만료되면 자동 회수 → 유출돼도 피해 최소화

시험 나오는 패턴:

"외부 감사관에게 24시간 읽기 전용 접근 부여" → IAM User 만들지 말고 Role + AssumeRole
"모바일 앱 사용자가 S3에 직접 업로드" → Cognito Identity Pool + 임시 자격 증명
"온프레미스 서버가 AWS 리소스 접근" → IAM Role + AWS STS

3.6 EC2와 Instance Profile

EC2에서 S3 접근할 때 액세스 키 하드코딩하면 안 된다는 건 상식인데, 그 뒤 메커니즘이 정확히 뭐냐고 물어보면 설명이 애매했다.

Role은 EC2에 직접 붙는 게 아니라 Instance Profile이라는 컨테이너를 통해 붙는다
콘솔에서는 자동으로 같이 만들어지지만 CLI/CloudFormation에서는 분리해서 인식해야 함
인스턴스는 **인스턴스 메타데이터 서비스(IMDSv2)**를 통해 임시 자격 증명을 받는다 (http://169.254.169.254/latest/meta-data/iam/security-credentials/)
SSRF 공격 방지를 위해 IMDSv2 강제하는 게 모범 사례. SAA에도 나온다

3.7 크로스 계정 액세스 두 가지 방식

이 두 개 구분이 시험 단골이다.

방식 1: Resource-based Policy로 직접 허용
S3 버킷 정책에 다른 계정의 Principal을 명시. 사용자는 자기 계정 자격 증명 그대로 씀. 심플하지만 리소스 종류가 지원해야 함(S3, SQS, SNS, Lambda, KMS 등)

방식 2: Cross-account Role AssumeRole
대상 계정에 Role을 만들고 Trust Policy에 신뢰할 계정 명시. 사용자는 STS로 역할 전환. 임시 자격 증명 사용 → 더 안전하고 감사 로그도 명확

문제 힌트: "임시 자격 증명", "역할 전환" → Role 방식 / "특정 계정에 직접 접근 허용" → Resource-based

4. 실전 문제 풀이

노션 "덤프 문제 사이트"(ExamTopics 기준)에서 IAM/기초 관련 문제를 골라 풀었다. 문제 번호는 ExamTopics 게시 시점 기준이라 바뀔 수 있음.

문제 1 (ExamTopics SAA-C03 Q66 유형)

한 회사가 여러 AWS 계정을 AWS Organizations로 관리한다. 각 부서 사용자들이 특정 S3 버킷에 접근해야 하는데, 동일 조직에 속한 계정의 IAM Principal만 이 버킷에 접근 가능하도록 제한하려 한다. 가장 적은 운영 오버헤드로 요건을 만족시키는 방법은?

A. S3 버킷 정책에 조직 ID를 참조하는 aws:PrincipalOrgID 전역 조건 키를 추가한다
B. 각 부서별로 OU를 만들고, aws:PrincipalOrgPaths 조건 키를 버킷 정책에 추가한다
C. CloudTrail로 CreateAccount, InviteAccountToOrganization 등 이벤트를 모니터링하여 버킷 정책을 갱신한다
D. 접근이 필요한 사용자마다 태그를 붙이고 aws:PrincipalTag 조건 키를 버킷 정책에 추가한다

정답: A

aws:PrincipalOrgID는 요청 Principal이 특정 Organization에 속하는지 한 줄로 검사한다. 조직 ID 하나만 넣으면 되니 운영 오버헤드가 가장 적다. B는 OU 단위 제어가 필요할 때 쓰고, C는 이벤트마다 정책 갱신하는 방식이라 비효율적. D는 태그 관리 부담이 커진다.

문제 2 (ExamTopics 다수 출제 유형)

한 회사의 EC2 인스턴스에서 실행되는 애플리케이션이 S3 버킷의 로그 파일을 처리해야 한다. 인스턴스는 인터넷을 거치지 않고 S3에 접근해야 한다. 어떤 솔루션이 이 요건을 만족시키는가?

A. S3용 Gateway VPC 엔드포인트를 생성하고 VPC 라우팅 테이블에 추가한다
B. VPC에 NAT Gateway를 배포하고 인스턴스 트래픽을 라우팅한다
C. Direct Connect 연결을 구성한다
D. 인스턴스에 Elastic IP를 부여하고 S3 도메인으로 직접 요청한다

정답: A

S3와 DynamoDB는 Gateway 엔드포인트를 지원하는 두 서비스다. 라우팅 테이블에 엔드포인트 경로를 추가하면 인터넷 게이트웨이를 거치지 않고 AWS 백본 안에서만 통신한다. NAT Gateway(B)는 인터넷을 여전히 거친다. Direct Connect(C)는 온프레미스 연결용. Elastic IP(D)는 오히려 퍼블릭 경로다.

문제 3 (ExamTopics IAM 자주 나오는 유형)

한 개발자가 EC2에서 실행되는 애플리케이션에 IAM User의 액세스 키를 코드에 저장해 S3에 접근하도록 구현했다. 보안 감사에서 지적을 받았고, 자격 증명이 자동으로 순환되며 하드코딩되지 않는 방식으로 바꾸려 한다. 어떤 솔루션이 가장 적절한가?

A. 액세스 키를 EC2 사용자 데이터에 저장한다
B. IAM Role을 만들어 EC2 Instance Profile로 연결한다
C. 액세스 키를 AWS Secrets Manager에 저장하고 애플리케이션에서 호출한다
D. IAM User에 MFA를 강제하고 액세스 키는 그대로 유지한다

정답: B

EC2에 IAM Role을 붙이면 STS가 자동으로 임시 자격 증명을 발급/순환한다. 코드에는 자격 증명이 전혀 남지 않는다. C(Secrets Manager)도 개선이지만 여전히 IAM User 액세스 키를 사용하기 때문에 근본적 해결이 아니다. A는 사용자 데이터도 평문 노출 가능. D는 MFA와 하드코딩은 별개 문제.

5. 마치며

부전공 때는 IAM이 권한 관리 서비스라는 정도로만 이해했었는데, 이번 주에 정책 평가 로직을 정리하고 나서야 왜 IAM이 시험의 30%인지 감이 왔다. 특히 Permission Boundary와 SCP가 권한을 주는 게 아니라 상한선을 정한다는 점, Resource-based policy에는 Principal 필드가 있다는 점은 개념이 서로 얽혀서 여러 번 다시 봐야 했다.

문제를 풀면서 확인한 건 시나리오형 문제의 힌트 단어들이 은근히 정형화되어 있다는 점이다. 임시 자격 증명, 최소 권한, 운영 오버헤드 최소 같은 표현이 나오면 자연스럽게 특정 서비스로 답이 좁혀진다. 다음 주부터는 개념 정리와 함께 문제 풀이 비중을 조금 더 늘려야겠다.

팀원 블로그

정재현 블로그

https://blog.naver.com/jjaehyun__/224337350464

[2026 하계 모각코] 1주차 모임

1주: 토익 구조 파악 + LC Part 1~2 입문 일단 첫 주는 "토익이 어떻게 생긴 시험인지" 감을 ...

blog.naver.com

박소윤 블로그

https://coding567.tistory.com/126

[2026하계모각코] 1차시 결과

1차시: AWS-SAA C03 개념정리(노션) 및 시험 예약 1. 시험 예약https://wsr.pearsonvue.com/testtaker/registration/Dashboard/AWS Pearson VUE - 경고!경고! 보안상의 이유로 인해 세션이 비활성화되었습니다. 일반적으로

coding567.tistory.com

1주차 모임 사진

2026 하계 모각코 계획

K0ngs — Sun, 28 Jun 2026 22:52:28 +0900

이번에 팀원들과 함께 AWS SAA(SAA-C03) 자격증 취득을 목표로 6주간 모각코 스터디를 진행합니다. 주 1회 모여 각자 공부하고, 마지막에 그 주 핵심 개념을 서로 점검하는 방식입니다.

스터디 멤버

정재현
박소윤
박경서

시험 정보 (SAA-C03)

문항 수: 65문항 / 시험 시간 130분
합격 점수: 720점 / 1000점
출제 도메인: 보안(30%), 복원력(26%), 고성능(24%), 비용 최적화(20%)

도메인 비중에 맞춰 6주 계획을 배분했습니다.

주차별 계획

1주차 - AWS 기초 & IAM

AWS 글로벌 인프라(리전, 가용 영역)
IAM 기본(사용자, 그룹, 역할, 정책), MFA 설정
EC2 인스턴스 생성 실습

2주차 - 보안 아키텍처 (도메인 1, 30%)

IAM 심화, STS, Assume Role
암호화(KMS), S3 암호화
보안 그룹 vs NACL, WAF, GuardDuty

3주차 - 복원력 아키텍처 (도메인 2, 26%)

다중 AZ, ELB, Auto Scaling
RDS 다중 AZ / 읽기 전용 복제본
SQS, SNS, Route 53

4주차 - 고성능 아키텍처 (도메인 3, 24%)

컴퓨팅 옵션(EC2, Lambda, ECS/EKS)
스토리지(EBS, EFS, S3 성능)
캐싱(CloudFront, ElastiCache), 데이터베이스 선택

5주차 - 비용 최적화 (도메인 4, 20%) & 복습

EC2 구매 옵션(예약, 스팟, Savings Plans)
S3 스토리지 클래스 & 수명 주기
비용 도구(Cost Explorer, Budgets)
1~4주차 통합 복습

6주차 - 모의고사 & 최종 점검

실전 모의고사 2~3회 (시간 재고 풀기)
오답 정리, 약점 도메인 보강
시험 신청 및 최종 점검

6주 요약

주차주제도메인

1주차	AWS 기초 + IAM	공통
2주차	보안	도메인 1
3주차	복원력	도메인 2
4주차	고성능	도메인 3
5주차	비용 최적화 + 복습	도메인 4
6주차	모의고사 + 점검	전체

마치며

도메인별로 한 주씩 나눠 진행하면 6주 안에 충분히 소화할 수 있는 분량입니다.

다른 팀원들과 함께 완주하는 것이 목표이고, 매주 학습 내용을 블로그에 정리해 이어가겠습니다.

팀원 블로그

정재현 블로그

https://blog.naver.com/jjaehyun__/224329814045

[2026 하계 모각코] 6주간의 계획

1주: 토익 구조 파악 + LC Part 1~2 입문 2주: LC Part 3~4 + RC Part 5 문법 기초 3주: RC Pa...

blog.naver.com

박소윤 블로그

https://coding567.tistory.com/124

[2026하계모각코] 전체학습계획

1차시: AWS-SAA C03 개념정리(노션) 및 시험 예약2차시: 덤프 문제 풀이 및 오답정리3차시: 덤프 문제 풀이 및 오답정리4차시: 덤프 문제 풀이 및 오답정리5차시: 덤프 문제 풀이 및 오답정리6차시: 시

coding567.tistory.com