Unique Life

일론 머스크의 일하는 방식

호레 — Thu, 30 Oct 2025 14:17:41 +0900

엘론 머스카가 일하는 법

호레 — Wed, 29 Oct 2025 13:08:41 +0900

1. 언제나 미션이 제일 중요하다.

2. 후퇴는 선택지에 없다.

3. 언제나 광적으로 긴박하게 일한다. 이게 우리 운영 원칙이다.

4. 제품 디자인은 엔지니어가 한다.

5. 엔지니어링과 디자인은 하나다. 절대 분리하지 마라.

6. 디자인팀 따로, 생산팀 따로는 헛소리다. 모든 걸 한 곳에 두고 피드백은 즉시 오가야 한다.

7. 리더는 최전선에 있어야 한다. 뒤에서 지시히지 말고 전장에 나서라.

8. 장군이 전장에 나가 있는 걸 봐야 병사들이 동기부여된다.

9. 아래 알고리즘을 반복해서 적용하라.

(1) 모든 당연한 전제들을 의심해라.

(2) 삭제 가능한 절차는 모두 삭제하라.

(3) 단순화하고 최적화 하라.

(4) 사이클을 더 빠르게 해라

(5) 자동화 하라.

10. 지겹도록 반복해야 한다. 짜증날 정도로 반복하는게 도움이 된다. 그 정도 해야 한다.

11. 삭제와 단순화는 정말 미친 수준으로 해야 한다.

12. 동료애는 위험하다. 서로의 일을 피판하기 어렵게 만든다.

13.자신이 하지 않을 일을 부하에게 시키지 마라.

14. 태도로 사람을 뽑아라. 기술은 가르칠 수 있지만, 태도를 바꾸려먼 뇌를 갈아야 한다.

15. 좋은 태도란 미친 듯이 일하려는 열정이다.

16. 유일한 규칙은 물리 법칙이다. 나머지는 전부 권장사항 일 뿐이다.

17. 회사 전체가 하나의 목표에 헌신하게 만들어라

18. 일이 잘 안 되면 기존 설계를 버려라. 1원칙 사고로 돌아가서 물리적 근거로 모든 요구사항을 다시 질문하라.

19. 삭제한 것 중 최소 10%를 나중에 다시 추가해야 한다면, 그건 충분히 잘 삭제했다는 뜻이다.

20. 통제권을 유지하라. 합작 투자는 피하고, 중간 단계를 없애라.

21. 모든 기본 전레를 끝없이 의심하라

22. 일을 위한 일은 하지 마라. 그냥 일해라

23. 문제가 있으면 현장으로 가라. 비행기를 타고 공장으로 가서 문제 지점에 머물러라. 해결될 때까지 떠나지 마라.

24. 최고의 부품은 존재하지 않는 부품이다.

25. 전쟁을 대비한 사람처럼 살아라.

26. 패배를 두려워하지 마라. 처음 50번은 아프지만, 그 다음부터는 감정에 휘둘리지 않고 더 큰 위험을 감수할 수 있다.

27. 문명에 유용한 일에 집중하라.

28. 급한 일이면 24시간마다 회의를 열어라. 알고리즘을 실행하고 전날의 진척을 확인하라. 얼마나 빨라지는지 놀라게 될 것이다.

29. 삶은 흥미롭고 모서리가 살아 있어야 한다.

30. 삭제하고 또 삭제하고 , 계속 삭제하라

VPC엔드포인트, Gateway 엔드포인트, Interface 엔드포인트 구별

호레 — Wed, 22 Oct 2025 22:42:42 +0900

VPC 엔드포인트(VPC Endpoint) 는 **VPC와 AWS 서비스 간의 프라이빗 통신을 위한 “집합 개념”**이고,
그 안에 Gateway Endpoint와 Interface Endpoint(PrivateLink)가 포함되어 있습니다.

VPC Endpoint
 ├─ Gateway Endpoint     → 라우트 기반 (S3, DynamoDB 전용)
 ├─ Interface Endpoint   → ENI 기반 (대부분의 AWS 서비스)
 └─ Gateway Load Balancer Endpoint → 트래픽 미러링/보안장비용

즉,
➡️ VPC Endpoint = Gateway Endpoint + Interface Endpoint (+ GWLB Endpoint)
라고 보면 정확합니다.

각 유형 비교 요약

항목	Gateway Endpoint	Interface Endpoint	GWLB Endpoint
통신 방식	라우팅 테이블 기반	ENI(Elastic Network Interface) 기반	GENEVE 터널 기반
주요 대상 서비스	S3, DynamoDB	CloudWatch, SSM, ECR, KMS, SQS, SNS, Lambda 등 대부분	방화벽, IDS/IPS 등 보안 장비용
비용	무료	시간당 + 데이터 전송 요금 발생	시간당 + 데이터 전송 요금 발생
구성 요소	라우트 테이블 + 정책	ENI + Security Group + DNS	GWLB + Endpoint Service
사용 목적	단순 프라이빗 액세스	서비스 전용 프라이빗 링크	네트워크 트래픽 인라인 분석

정리

“VPC Endpoint”는 개념상 상위 그룹
“Gateway / Interface / GWLB Endpoint”는 구현 방식별 세부 유형
따라서 “VPC 엔드포인트 안에 Gateway Endpoint와 Interface Endpoint가 포함되어 있다”고 이해하면 완전히 맞습니다 ✅

AWS Security Specialty 헷갈리기 쉬운 개념쌍 TOP 10

호레 — Wed, 22 Oct 2025 13:57:37 +0900

# 개념쌍 혼동 포인트 구분 기준 & 핵심 문장 예시 문제 포인트

1	Service Catalog CloudFormation StackSets	둘 다 표준 인프라 배포로 보임	Service Catalog → 개발자가 “무엇을 실행할 수 있는지 제한” (승인된 제품만) StackSets → 관리자가 “어디에 배포할지 자동화” (조직 전체 배포)	“승인된 소프트웨어만 실행하게 제한해야 한다” → Service Catalog
2	SCP IAM Policy	둘 다 권한 제어 정책	SCP → “최대 허용 한도” (deny는 강제) IAM Policy → “개별 권한 부여”	“조직 전체에서 특정 서비스 사용 금지” → SCP
3	IAM Permission Policy Trust Policy	둘 다 Role에 붙는 JSON이라 헷갈림	Trust Policy → “누가 역할을 맡을 수 있는가” Permission Policy → “맡은 역할로 무엇을 할 수 있는가”	“MFA 인증 후만 AssumeRole 허용” → Trust Policy
4	VPC Endpoint NAT Gateway	둘 다 Private Subnet에서 외부 접근용	VPC Endpoint → AWS 내부 서비스(S3, STS 등) 전용 NAT Gateway → 인터넷 외부로 나가는 트래픽	“S3 접근은 내부망에서만 허용” → VPC Endpoint
5	KMS Auto Rotation Imported Key Manual Rotation	둘 다 키 교체 관련	Managed Key → 1년 주기 자동 회전 가능 Imported Key → 수동 교체만 가능, alias 변경으로 대체	“Imported key를 자동 회전 설정” → ❌
6	CloudWatch Alarm EventBridge Rule	둘 다 이벤트 기반	Alarm → “Metric 기반 감지” EventBridge → “Event 기반 자동화”	“EC2 Stop 이벤트 발생 시 자동 Lambda 실행” → EventBridge
7	Config Rule Security Hub	둘 다 규정 준수 모니터링	Config Rule → 리소스의 구성 상태 점검 Security Hub → 여러 서비스의 보안 결과 통합 대시보드	“S3 공개 버킷 탐지 후 자동 알림” → Config Rule
8	GuardDuty Security Hub	둘 다 보안 탐지 서비스	GuardDuty → 위협 탐지 (비정상 트래픽, API 호출 등) Security Hub → GuardDuty 등 여러 탐지 결과 통합 및 규정 준수 평가	“조직 전체 위협 탐지 통합” → Security Hub + GuardDuty 조합
9	CloudTrail CloudWatch Logs	둘 다 로그 관련	CloudTrail → “누가, 언제, 무엇을 했는가” (API 로그) CloudWatch Logs → “어떤 일이 일어났는가” (시스템 로그, 애플리케이션 로그)	“API 호출 이력 추적” → CloudTrail
10	Detective Config / CloudTrail	둘 다 관계 그래프 분석처럼 보임	Detective → CloudTrail, VPC Flow Logs, GuardDuty 데이터를 분석해 보안 관계 추적 Config → 단순히 리소스 구성 상태 추적	“이상 트래픽과 연관된 계정 활동을 시각화” → Detective

빠른 암기 팁 — “문제 문장 속 단서 단어”로 구분하기

단서 단어정답 경향

“승인된 리소스만 실행”	✅ Service Catalog
“조직 전체에 배포”	✅ StackSets
“모든 계정에 제한 적용”	✅ SCP
“특정 이벤트 발생 시 자동 대응”	✅ EventBridge
“규정 위반 탐지 / 검사”	✅ Config Rule
“민감 데이터 식별”	✅ Macie
“키 자동 회전 설정”	✅ KMS Managed Key
“MFA 인증 시에만 Role Assume 가능”	✅ Trust Policy
“위협 감지” / “탐지 결과 통합”	✅ GuardDuty / Security Hub
“행동 경로 분석”	✅ Detective

요약 문장 1줄씩 (시험 직전용)

1️⃣ Service Catalog → 승인된 것만
2️⃣ StackSets → 조직 전체 배포
3️⃣ SCP → 최대 허용 한도
4️⃣ IAM Policy → 실제 권한
5️⃣ Trust Policy → 역할 맡기 조건
6️⃣ VPC Endpoint → AWS 내부
7️⃣ NAT Gateway → 외부 인터넷
8️⃣ Config → 상태 점검
9️⃣ GuardDuty → 위협 탐지
Security Hub → 결과 통합

Amazon Inspector vs ECR 기본 스캔

호레 — Tue, 21 Oct 2025 13:09:58 +0900

✅ Amazon Inspector의 역할

현재(2023 이후 기준) Amazon Inspector는
- ECR 이미지 푸시 시 자동 스캔 (push scanning)
- ECR 내 모든 이미지에 대한 주기적 스캔 (continuous scanning)
  을 자동으로 수행합니다.
ECR의 기본 스캐닝(ECR Basic Scanning) 은 단순히 푸시 시점 1회성 검사였지만,
Inspector는 지속적 스캔 + 취약점 심각도별 결과를 중앙집중화합니다.
결과는 Security Hub로 자동 연동되어, 다른 보안 서비스 결과(GuardDuty, Macie 등)와 함께 통합 대시보드에서 볼 수 있습니다.

핵심 포인트 요약

항목 Amazon Inspector ECR 기본 스캔

스캔 주기	지속적(Continuous) + 푸시 시 자동	푸시 시 1회
결과 연동	Security Hub 자동 통합	없음 (별도 설정 필요)
스캔 제외 설정	포함/제외 규칙(Include/Exclude filters) 설정 가능	제한적
중앙 대시보드 통합	지원 (Security Hub)	불가능
운영 오버헤드	자동 관리	수동 관리 필요

✅ ① ECR 기본 스캔이 정답인 문제 예시

문제 1

한 스타트업은 Amazon ECS를 사용하여 컨테이너 기반 웹 애플리케이션을 운영합니다.
보안팀은 새로 푸시되는 컨테이너 이미지에 대해 자동으로 취약점을 검사해야 합니다.
회사는 추가 비용을 최소화해야 하며, 보안 결과는 개발팀이 ECR 콘솔에서 직접 확인할 예정입니다.
어떤 솔루션이 가장 적합합니까?

A. Amazon Inspector를 사용하여 모든 ECR 리포지토리에 대한 지속적 스캔을 구성합니다.
B. ECR 리포지토리에서 기본 스캐닝(Basic Scanning) 을 활성화하여 푸시 시 자동 스캔을 수행합니다.
C. AWS Config 규칙을 만들어 컨테이너 이미지의 취약점을 감시합니다.
D. ECR 이미지를 S3로 내보내고 Amazon Macie를 사용해 검사합니다.

✅ 정답: B

이유:
“추가 비용 최소화”, “푸시 시 자동 검사”, “ECR 콘솔에서 직접 확인” →
ECR 기본 스캔의 전형적 케이스. Inspector는 불필요하게 과도함.

문제 2

한 회사는 내부용 테스트 환경에서만 컨테이너 이미지를 사용합니다.
보안팀은 새 이미지가 리포지토리에 푸시될 때마다 취약점이 있는지 한 번만 확인하려고 합니다.
결과를 중앙집중식으로 관리할 필요는 없습니다.
어떤 솔루션을 사용해야 합니까?

A. ECR 기본 스캔을 활성화합니다.
B. Amazon Inspector에서 지속적인 스캔을 설정합니다.
C. Security Hub로 결과를 전송하도록 Amazon Inspector를 구성합니다.
D. Amazon GuardDuty를 활성화하여 컨테이너 이미지를 검사합니다.

✅ 정답: A

이유:
“한 번만 검사”, “중앙 관리 필요 없음”, “테스트 환경” →
기본 스캔이면 충분, Inspector는 과도한 구성.

✅ ② Amazon Inspector가 정답인 문제 예시

문제 3

한 대기업은 여러 AWS 계정에서 Amazon ECS와 Amazon ECR을 사용합니다.
보안팀은 조직 전체에서 컨테이너 이미지 취약점을 지속적으로 검사해야 하며,
결과를 AWS Security Hub 대시보드에서 다른 보안 결과와 함께 분석하려고 합니다.
비용보다 중앙 관리와 자동화가 더 중요합니다.
어떤 솔루션이 가장 적합합니까?

A. Amazon Inspector를 사용하여 모든 ECR 리포지토리에 대해 지속적 스캔을 구성합니다.
B. 각 ECR 리포지토리에 기본 스캔을 활성화하고, AWS Config를 사용하여 결과를 집계합니다.
C. ECR 이미지를 Amazon Macie로 내보내고 분석합니다.
D. CloudWatch Logs Insights를 사용하여 ECR 푸시 로그를 분석합니다.

✅ 정답: A

이유:
“조직 전체”, “지속적”, “Security Hub 통합” →
Inspector 전형적 키워드 조합.

문제 4

보안팀은 ECS/ECR 환경의 취약점 관리 체계를 자동화해야 합니다.
팀은 스캔 대상 리포지토리 중 일부를 제외하려고 합니다.
또한 스캔 결과를 Security Hub에서 다른 보안 서비스 결과와 함께 보려 합니다.
어떤 솔루션이 이러한 요구사항을 충족합니까?

A. Amazon Inspector를 사용하여 포함/제외 규칙을 생성하고 결과를 Security Hub로 보냅니다.
B. ECR 기본 스캔을 활성화하고 제외할 리포지토리를 수동으로 관리합니다.
C. ECR 이미지 메타데이터를 CloudTrail로 내보내고 Athena로 분석합니다.
D. GuardDuty에서 ECR 관련 탐지를 활성화합니다.

✅ 정답: A

이유:
“제외 규칙(exclusion rules)”, “Security Hub 대시보드”, “자동화” →
→ Inspector가 유일하게 해당 기능을 제공.

정리 요약

조건 정답

소규모 환경 / 푸시 시 1회 검사 / 비용 절감	✅ ECR 기본 스캔
조직 전체 / 지속적 검사 / Security Hub 통합 / 제외 규칙 필요	✅ Amazon Inspector

AWS 직접 푸시 가능한 서비스 vs 불가능한 서비스

호레 — Mon, 20 Oct 2025 14:25:46 +0900

✅ SNS로 직접 푸시 가능한 대표 서비스

Amazon EventBridge: 규칙의 타깃으로 SNS 지정 가능.
Amazon CloudWatch Alarms: 알람의 알림 대상으로 SNS 지정.
Amazon S3 이벤트 알림: 객체 생성/삭제 등 버킷 이벤트를 SNS로 직접 전송.
AWS Config: 규칙/컴플라이언스 변경 알림을 SNS로 직접 전송 가능.
AWS CloudFormation: 스택 이벤트 알림을 SNS로 보낼 수 있음.
Amazon RDS / ElastiCache 등 일부 서비스 이벤트: SNS 구독 기반 이벤트 알림 제공.
Auto Scaling: 스케일링 이벤트 SNS 알림 지원.
AWS CloudTrail(로그 전달 완료 알림 한정): “로그 파일이 S3에 배달되었음”을 SNS로 알림(이건 이벤트별이 아니라 배달 단위 알림).

⛔ SNS로 직접 못 보내는(중간 필요) 대표 케이스

CloudTrail의 개별 API/Signin 이벤트(예: ConsoleLogin)
→ 직접 SNS 불가.
→ 두 가지 표준 경로 중 하나 필요
1. EventBridge 규칙(소스: signin.amazonaws.com, 이벤트: ConsoleLogin) → SNS
2. CloudTrail → CloudWatch Logs → Metric Filter → CloudWatch Alarm → SNS
CloudWatch Logs 자체(로그 스트림/구독 필터)
→ 직접 SNS 불가. (구독은 Lambda/Kinesis/Firehose만)
→ Metric Filter + Alarm을 통해 우회해서 SNS 전송.
Security Hub / GuardDuty / WAF 등 탐지계
→ 직접 SNS 불가. 보통 EventBridge → SNS로 보냄.
IAM Access Analyzer, Trusted Advisor
→ SNS로 실시간 이벤트 직접 푸시 X (목적이 다르거나 주기성 보고 중심).

AWS KMS 대칭키 vs 비대칭키

호레 — Mon, 20 Oct 2025 13:46:17 +0900

1️⃣ 개념 비교 요약

구분 대칭형 KMS 키 비대칭형 KMS 키

암호화 방식	동일한 키로 암호화/복호화	공개키로 암호화, 개인키로 복호화
대표 알고리즘	AES-256	RSA 2048/3072/4096, ECC
자동 회전	✅ 지원	❌ 지원 안 함
주 사용 목적	데이터 암호화	디지털 서명(Sign/Verify), 암호화 키 교환, 서명 검증
예시 사용처	EBS, S3, RDS, Secrets Manager, Lambda 환경 변수	CodeSigning, TLS 인증서, 데이터 검증용 서명
성능	빠름 (하드웨어 가속 가능)	느림 (비대칭 연산)

2️⃣ AWS 서비스별 KMS 키 유형 정리

✅ 대칭형 키만 지원하는 서비스 (대부분의 “데이터 암호화”)

서비스 키 타입 설명

Amazon EBS	대칭	볼륨 및 스냅샷 암호화
Amazon S3 (SSE-KMS)	대칭	객체 암호화 (서버측 암호화)
Amazon RDS / Aurora	대칭	DB 스토리지 및 백업 암호화
AWS Backup	대칭	백업 볼트 암호화
AWS Secrets Manager	대칭	비밀 값 암호화
AWS Lambda	대칭	환경 변수 암호화
AWS DynamoDB	대칭	테이블 암호화
Amazon SNS / SQS (SSE)	대칭	메시지 암호화
AWS Glue / Athena / EMR	대칭	쿼리 로그, 임시 데이터 암호화
AWS CloudTrail (로그 암호화)	대칭	로그 파일 암호화
AWS ECR / EFS / FSx	대칭	저장 데이터 암호화
AWS Config / CloudWatch Logs	대칭	로그 데이터 암호화
AWS Kinesis / MSK	대칭	스트림 데이터 암호화
AWS Step Functions / SSM Parameter Store (SecureString)	대칭	내부 암호화
AWS Organizations / IAM Access Analyzer (보안 데이터)	대칭	정책 암호화 내부적으로 사용

✅ 비대칭 키를 사용할 수 있는 서비스 (주로 서명 및 검증 목적)

서비스 키 타입 설명

AWS KMS 직접 API	비대칭	Sign/Verify, Encrypt/Decrypt API 사용 가능 (RSA, ECC)
AWS Certificate Manager (ACM)	비대칭	SSL/TLS 인증서용 공개/개인키 쌍 관리
AWS CloudHSM	비대칭	자체 서명, PKI, 키 교환 구현
AWS Code Signing for AWS Lambda	비대칭	Lambda 코드 패키지 서명 및 검증
AWS IoT	비대칭	디바이스 인증서 기반 서명 및 인증
AWS Nitro Enclaves	비대칭	데이터 암호화 키 교환 시 사용 (RSA/ECC)
AWS Signer	비대칭	컨테이너 이미지, 코드 아티팩트 서명

3️⃣ 정리 요약

범주 키 유형 대표 서비스 비고

스토리지 / 데이터 보호	대칭	S3, EBS, RDS, Secrets Manager	빠르고 자동 회전 지원
로그 / 백업 / 메시징	대칭	CloudTrail, Backup, SNS, SQS
서명 / 검증 / 인증서	비대칭	ACM, Signer, IoT, KMS(Sign/Verify)	키 회전 불가, 수동 관리 필요
키 관리 인프라(PKI)	비대칭	CloudHSM	완전 수동 제어 가능

기억 포인트

질문 답변

EBS, S3, RDS, Secrets Manager는 어떤 키?	모두 대칭 키 (AES-256)
Sign/Verify, Encrypt/Decrypt API용 KMS 키는?	비대칭 키
자동 키 회전 가능한가?	대칭 키만 가능
EBS 스냅샷은 비대칭 키로 암호화 가능?	❌ 절대 안 됨

AWS Security Specialty 혼동 개념 총정리 (20세트 ver.)

호레 — Mon, 20 Oct 2025 10:07:51 +0900

A. 조직/정책 관련 혼동

#	개념쌍	헷갈리는 이유	구분 핵심	기억 문장
1	SCP IAM Policy	둘 다 권한 JSON 문법	SCP는 “최대 한도(Guardrail)”, IAM은 “실제 권한”	“SCP는 브레이크, IAM은 엑셀”
2	IAM Permission Policy Trust Policy	둘 다 Role에 붙음	Trust는 AssumeRole 조건, Permission은 행동 권한	“MFA 조건은 Trust에 넣는다”
3	SCP Resource Policy	둘 다 Account 밖 접근 제한 가능해 보임	SCP는 계정 수준 제어, Resource Policy는 리소스 단위 제어	“SCP는 전체 계정, Resource Policy는 버킷 하나”
4	Service Catalog StackSets	둘 다 표준 배포로 보임	Catalog는 무엇을 실행 가능?, StackSets는 어디에 배포할까?	“Catalog는 제한, StackSets는 전파”
5	SCP Config Rule	둘 다 컴플라이언스와 연관	SCP는 사전 제한 (prevent), Config Rule은 사후 감시 (detect)	“Prevent면 SCP, Detect면 Config”
6	Delegated Admin Master Account	둘 다 Organization 내 대표 계정	Delegated는 특정 서비스 위임, Master는 조직 소유자	“Delegated는 서비스별, Master는 전체”

B. 네트워크/접근제어 관련 혼동

#	개념쌍	헷갈리는 이유	구분 핵심	기억 문장
7	VPC Endpoint NAT Gateway	둘 다 Private Subnet에서 외부 접속	Endpoint는 AWS 내부 서비스용, NAT는 인터넷용	“AWS 서비스면 Endpoint, 외부면 NAT”
8	PrivateLink Transit Gateway	둘 다 VPC 연결 기능	PrivateLink는 서비스 단위 연결, TGW는 네트워크 레벨 연결	“서비스면 PrivateLink, 전체망이면 TGW”
9	Security Group NACL	둘 다 트래픽 필터링	SG는 상태 기반, NACL은 비상태	“SG는 Stateful, NACL은 Stateless”
10	VPC Peering VPN	둘 다 네트워크 연결	Peering은 AWS 내부, VPN은 온프레미스 또는 외부	“Peering은 클라우드끼리, VPN은 외부 연결”

C. 암호화/KMS/보안 관리 관련 혼동

#	개념쌍	헷갈리는 이유	구분 핵심	기억 문장
11	Managed Key Imported Key	둘 다 CMK	Managed는 자동 회전 가능, Imported는 수동	“Imported는 내가 넣었으니 내가 돌려야 한다”
12	KMS Key Policy IAM Policy	둘 다 권한 제어	KMS Key Policy는 키 자체의 접근 통제, IAM Policy는 사용자의 권한 통제	“키 접근은 Key Policy, 사람 권한은 IAM Policy”
13	Envelope Encryption SSE-S3/KMS/CMK	모두 암호화 같아 보임	Envelope은 데이터키+마스터키 이중 암호화 구조	“Envelope은 두 번 싸서 보관”
14	Secrets Manager Parameter Store	둘 다 비밀 저장	Secrets는 민감 정보 자동 회전, Parameter는 일반 설정 저장	“비밀번호면 Secrets, 설정값이면 Parameter”
15	KMS Grant Key Policy	둘 다 접근 제어 방식	Grant는 일시적 위임, Policy는 영구 권한	“Grant는 임시, Policy는 고정”

D. 로깅/탐지/경보 관련 혼동

#	개념쌍	헷갈리는 이유	구분 핵심	기억 문장
16	CloudTrail CloudWatch Logs	둘 다 로그 수집	CloudTrail은 API 호출 감사, CloudWatch는 시스템 로그	“누가 뭘 했는가 → Trail, 무슨 일이 일어났는가 → Watch”
17	CloudWatch Alarm EventBridge Rule	둘 다 이벤트 대응	Alarm은 지표 기반, EventBridge는 이벤트 기반	“CPU 90%면 Alarm, EC2 Stop이면 EventBridge”
18	GuardDuty Security Hub	둘 다 탐지 서비스	GuardDuty는 탐지, Security Hub는 통합	“GuardDuty는 눈, Hub는 대시보드”
19	Config Rule Audit Manager	둘 다 규정 준수	Config는 구성 상태 검사, Audit Manager는 증거 수집 리포트	“Config는 검사, Audit은 증명”
20	Detective GuardDuty	둘 다 분석 서비스	Detective는 사후 관계분석, GuardDuty는 실시간 탐지	“GuardDuty는 알람, Detective는 추적”

E. 추가로 오답에서 자주 등장한 “부분 개념 혼동”

개념	오답 경향	정리 포인트
Macie vs Config Rule (Q238)	Macie가 공개 여부 감시까지 하는 줄 착각	Macie는 PII 탐지, S3 공개 설정은 Config Rule
Run Command vs Systems Manager State Manager (Q70 연관)	Run Command로 지속 관리 가능하다고 착각	Run Command는 단발성, State Manager는 지속적 구성 유지
CloudFormation Condition vs IAM Condition	Condition 키를 혼동	CloudFormation Condition은 리소스 생성 여부, IAM Condition은 액션 허용 조건
Organizations SCP vs Tag Policy	둘 다 정책 JSON이라 혼동	SCP는 서비스 접근 제한, Tag Policy는 태그 형식 강제
Cross-Account AssumeRole vs Resource-based Policy	접근 위임 구조 혼동	AssumeRole은 역할 기반 접근, Resource Policy는 리소스가 직접 허용
Instance Profile vs Role	둘 다 “Role”로 보임	Instance Profile은 Role을 EC2에 연결하는 껍데기

시험 전략용 판단 기준

문제 문장 속 키워드	해석 방향	정답 경향
“승인된 리소스만 허용”	사전 통제	✅ Service Catalog / SCP
“모든 계정에서 일괄 배포”	중앙 배포	✅ StackSets
“실시간 탐지”	위협 감지	✅ GuardDuty
“위반 시 알림”	규정 감시	✅ Config Rule
“사후 조사/분석”	인시던트 트레이싱	✅ Detective
“감사/증거”	규정 증명	✅ Audit Manager
“자동 키 순환”	관리형 키	✅ AWS Managed Key
“수동으로 교체”	가져온 키	✅ Imported Key
“임시 권한 부여”	Delegation	✅ KMS Grant / STS AssumeRole
“비밀번호 저장소”	자동 회전	✅ Secrets Manager

마무리 요약

AWS Security Specialty 시험에서 헷갈리는 문제의 80%는
“도구의 목적(Prevent / Detect / Respond / Enforce)”을 혼동할 때 발생합니다.

유형	대표 서비스	역할
Prevent (사전 제한)	SCP, IAM Policy, Service Catalog	실행 자체 제한
Detect (탐지/감시)	Config, GuardDuty, CloudTrail	이상 징후/규정 위반 감시
Respond (대응/조치)	EventBridge, Run Command, Lambda	탐지 후 자동 조치
Enforce (통합/표준화)	StackSets, Security Hub, Audit Manager	조직 단위 관리

AWS Cognito ID 풀 vs Cognito 사용자 풀

호레 — Sun, 19 Oct 2025 20:10:25 +0900

{
  "AccessKeyId": "ASIAXXXXX",
  "SecretAccessKey": "XXXXX",
  "SessionToken": "XXXX",
  "Expiration": "2025-10-17T12:00:00Z"
}

요약 한 줄로

구분역할한 줄 설명

사용자 풀 (User Pool)	“로그인 시스템”	사용자의 ID(이메일·비밀번호, Google 로그인 등)를 관리하는 인증(Authentication) 기능
ID 풀 (Identity Pool)	“권한 부여 시스템”	로그인한 사용자가 AWS 리소스(S3, DynamoDB 등)에 접근할 수 있게 권한 부여(Authorization) 해주는 기능

1️⃣ Cognito 사용자 풀 (User Pool)

“사용자가 누구인지 인증(Authenticate)하는 곳”

기능

사용자 계정을 직접 관리 (회원가입, 로그인, 비밀번호 재설정)
Google, Apple, Facebook, SAML, OIDC 같은 소셜/기업 IdP 연동 가능
JWT 토큰 (ID 토큰, Access 토큰, Refresh 토큰) 발급
Lambda 트리거(가입 전 검증, 로그인 후 후처리 등) 가능
MFA, CAPTCHA, 비밀번호 정책 등 내장

예시

사용자가 로그인하면 Cognito가 이런 토큰을 줍니다:

{
  "id_token": "...",      // 사용자 프로필 정보 (이름, 이메일 등)
  "access_token": "...",  // API Gateway 등 접근 시 사용
  "refresh_token": "..."  // 세션 갱신용
}

2️⃣ Cognito ID 풀 (Identity Pool)

“인증된 사용자에게 AWS 리소스에 접근할 자격(Authorization)을 주는 곳”

기능

AWS 자격 증명(AWS Temporary Credentials) 발급 (STS 기반)
사용자 풀 / SAML / 소셜 로그인 / 익명 게스트 로그인 모두 연결 가능
IAM 역할과 연동되어, “어떤 AWS 리소스에 어떤 권한을 줄지” 제어
주로 프론트엔드 앱에서 S3 업로드, DynamoDB 접근 등에 사용

⚙️ 예시

User Pool에서 로그인 성공 → ID Token 발급
↓
Identity Pool이 ID Token을 받아서 → STS AssumeRoleWithWebIdentity 호출
↓
사용자에게 아래 같은 임시 자격 증명 발급:

{
  "AccessKeyId": "ASIAXXXXX",
  "SecretAccessKey": "XXXXX",
  "SessionToken": "XXXX",
  "Expiration": "2025-10-17T12:00:00Z"
}

두 개를 같이 쓰는 이유

단계구성요소역할

①	Cognito User Pool	사용자 로그인 / 인증 수행 (ID Token 발급)
②	Cognito Identity Pool	해당 토큰으로 AWS 자격 증명 발급 (IAM Role 연결)
③	IAM	어떤 AWS 리소스(S3, DynamoDB 등)에 접근 가능한지 제어

[사용자] → 로그인 → [User Pool]
                 ↓
      (ID Token 발급)
                 ↓
         [Identity Pool] → IAM Role 매핑
                 ↓
       [AWS 서비스 접근 (S3 등)]

실무 예제

사용 사례필요한 구성

웹/모바일 앱 로그인만 (토큰 기반 인증)	✅ User Pool만 사용
로그인 후 S3 업로드, DynamoDB 접근 등 AWS API 직접 호출	✅ User Pool + Identity Pool 같이 사용
익명 게스트가 임시로 S3에 접근	✅ Identity Pool만 사용 (Unauthenticated role)

비교표 정리

항목사용자 풀 (User Pool)ID 풀 (Identity Pool)

주요 목적	인증(Authentication)	권한 부여(Authorization)
생성되는 것	JWT 토큰 (ID, Access, Refresh)	AWS 임시 자격 증명 (AccessKey, SecretKey, SessionToken)
주 대상	사용자 (사람)	AWS 리소스 접근 권한
IAM 역할 사용	❌	✅
게스트 로그인 지원	❌	✅
예시 서비스	로그인, MFA, SSO	S3 업로드, DynamoDB 접근

요약

상황사용 방법

앱 로그인/회원가입만 필요	User Pool만 사용
로그인 후 AWS 리소스 접근 필요	User Pool + Identity Pool 조합
인증 없이 임시 접근 허용	Identity Pool만 사용

IAM 역할 내부 구조

호레 — Sat, 18 Oct 2025 12:53:49 +0900

항목 설명

신뢰 정책(Trust Policy)	어떤 주체(Principal)가 이 역할을 Assume할 수 있는지를 정의
권한 정책(Permissions Policy)	역할을 Assume한 엔티티가 어떤 AWS API를 호출할 수 있는지를 정의

IAM 역할(Role)의 두 개의 정책 구조

정책 종류 위치 역할 요약

신뢰 정책 (Trust Policy)	IAM 역할 안의 “신뢰 관계(Trust relationships)” 탭	“누가 이 역할을 사용할 수 있는가?” 정의	역할을 Assume할 수 있는 주체(Principal) 를 지정
권한 정책 (Permissions Policy)	IAM 역할 안의 “권한(Permissions)” 탭	“이 역할이 무엇을 할 수 있는가?” 정의	역할이 AWS 리소스에 대해 호출할 수 있는 API 를 지정

1️⃣ 신뢰 정책 (Trust Policy)

개념

“이 역할을 누가 사용할(Assume할) 수 있느냐?”를 정의.

IAM 역할은 스스로 실행되지 않습니다.
대신 누군가(서비스나 사용자, 다른 역할) 가 sts:AssumeRole 을 통해 “그 역할이 되어” 동작합니다.
신뢰 정책은 바로 이 Assume 권한을 허용하는 대상(Principal) 을 지정하는 정책입니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "lambda.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

2️⃣ 권한 정책 (Permissions Policy)

개념

“이 역할이 어떤 리소스에, 어떤 작업을 수행할 수 있는가?”를 정의.

이건 우리가 흔히 말하는 “IAM 정책(JSON)”의 형태로,
AWS 리소스에 접근할 수 있는 구체적인 액션(Action)과 리소스(Resource)를 명시합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:*:*:*"
    }
  ]
}