KMS 핵심 정리 — SAA-C03 보안·암호화 한 번에

이 글은 AWS Certified Solutions Architect Associate(SAA-C03) 스터디 노트 시리즈의 열한 번째 편입니다. 보안 도메인은 시험에서 출제 비중 1위(30%) 영역이라, "여기서 점수를 못 받으면 합격이 흔들린다"고 봐도 과언이 아니에요. 그래서 학습량도 가장 많고, 처음 펼치면 KMS·CloudHSM·Secrets Manager·Parameter Store·ACM·Shield·WAF·Firewall Manager·GuardDuty·Inspector·Macie — 이름부터 다 비슷비슷한 서비스가 줄지어 등장합니다. 그중에서도 거의 모든 암호화의 뒤에 깔리는 게 KMS라, 이 한 서비스만 정확히 잡아도 보안 단원의 절반은 풀린 셈이에요.

처음 들으면 "왜 이렇게 비슷한 서비스가 많지?" 하는 생각이 들기 마련인데, 한 발 떨어져서 보면 이 단원의 모든 서비스는 결국 세 가지 큰 질문의 변형이에요.

1. 비밀(키·비밀번호·인증서)을 어디에 어떻게 저장하느냐
2. 서비스 간에 권한을 어떻게 주고받느냐
3. 언제·어디서 데이터를 암호화하고 누구로부터 보호하느냐

이 세 줄을 머리에 박아두고 각 서비스가 "이 셋 중 어디에 자리 잡는가" 만 따져보면, 시험 시나리오가 와도 어디 칸인지 바로 잡힙니다. 이 글은 처음 보는 분도 따라올 수 있게 회사 금고와 마스터키 같은 비유를 자주 쓸 거고, 시험 함정도 그때그때 짚어 드릴게요. 깊이 있게 더 보고 싶다면 AWS 공식 KMS 개발자 가이드를 함께 펼쳐 두면 좋습니다.

암호화 3방식 — 누가 키를 가지느냐

본격적으로 시작하기 전에 큰 그림 한 장만 잡고 갑니다. AWS에서 데이터를 암호화하는 방식은 셋이에요.

방식	암호화 주체	키 관리	AWS가 평문 봄?
In-transit (전송 중)	클라이언트·서버	인증서 (TLS)	도착 후 가능
SSE (서버 측)	AWS	AWS 또는 KMS	O
CSE (클라이언트 측)	고객	고객	X (못 봄)

비유로 풀면 이래요. 전송 중 암호화는 "택배 트럭에 자물쇠 채워서 보내기" 같은 거예요. 트럭이 도착하면 자물쇠를 풀고 내용물을 받습니다. 받는 사람(서버)은 평문을 봐요.

서버 측 암호화(SSE) 는 "받는 회사(AWS) 안에서 보관할 때만 금고에 넣어두기"입니다. 받을 때는 평문으로 받고, 저장할 때 AWS가 자기 금고에 넣어줘요. 꺼낼 때는 다시 풀어서 보내 주고요. AWS가 평문을 보긴 합니다.

클라이언트 측 암호화(CSE) 는 "보내기 전부터 내가 직접 자물쇠 채워서 보내고, 자물쇠 열쇠는 나만 갖기"입니다. AWS는 자물쇠 잠긴 형태만 받아서 그대로 저장해요. AWS도 평문을 못 봅니다. "AWS를 신뢰하지 않을 때" 쓰는 카드라고 보면 됩니다.

여기서 시험에 자주 나오는 함정 — "AWS도 평문에 접근 불가"라는 조건이 나오면 답은 무조건 CSE입니다. SSE 보기는 함정이에요.

KMS — AWS 암호화의 표준이자 출발점

거의 모든 AWS 암호화의 뒤에는 KMS(Key Management Service) 가 있습니다. 회사 비유로 치면 회사 금고와 마스터키를 관리해 주는 보안실이에요. 직원들은 마스터키를 직접 만지지 않고, 보안실에 "이 문서 잠가 주세요" / "이 문서 풀어 주세요"라고 요청만 합니다. 보안실이 마스터키로 알아서 처리해 주고, 누가 언제 무슨 요청을 했는지 전부 로그로 남겨요.

KMS의 핵심 특징을 정리하면:

• IAM 완전 통합 — 누가 키를 쓸 수 있는지 IAM 정책으로 제어
• CloudTrail 자동 연동 — KMS 모든 API 호출이 기록돼 감사·추적 가능
• 거의 모든 AWS 서비스에 통합 — EBS·S3·RDS·SSM 등
• CLI/SDK/API로 앱 코드 안에서 직접 데이터 암호화도 가능

CMK 타입 4종 — 누가 만들고 누가 관리하느냐

KMS에서 제일 먼저 마주치는 게 CMK(Customer Master Key) 타입 4종입니다. 헷갈리지만 본질은 단순해요 — 누가 만들었고 누가 관리하느냐.

키 타입	관리 주체	비용	특징
AWS Owned Key	AWS	무료	SSE-S3·DynamoDB 기본 암호화 백그라운드용
AWS Managed Key	AWS	무료	aws/ebs·aws/rds 형태, 해당 서비스 내부에서만 사용
Customer Managed Key (CMK)	고객	월 $1	키 정책·회전·삭제까지 직접 제어
Imported Key (BYOK)	고객	월 $1	온프레미스에서 만든 키를 가져와 사용

회사 비유로 풀면 — Owned Key는 "회사가 알아서 관리하는 백오피스용 마스터키, 직원은 신경 안 씀", Managed Key는 "특정 부서 전용으로 회사가 만들어 놓은 키", Customer Managed Key는 "내가 직접 만들고 내가 책임지는 키", BYOK는 "집에서 가져온 내 자물쇠를 회사 금고에 등록해 쓰기".

API 호출 비용도 알아두면 좋아요 — 10,000건당 $0.03. 가끔 시험에 끼어듭니다.

대칭/비대칭은 — 대칭 키는 모든 AWS 서비스 통합용, 비대칭 키는 KMS API에 접근 못 하는 외부 사용자가 공개 키로 암호화하고 내부에서 개인 키로 복호화하는 시나리오용입니다. 일반적인 SSE 암호화는 다 대칭 키예요.

키 회전 — 누구는 자동, 누구는 수동

키는 정기적으로 새 키로 갈아주는 게 보안 모범 사례입니다. 그런데 키 타입에 따라 자동 회전이 되는 게 있고 안 되는 게 있어요. 이 표가 시험 단골이라 한 번에 외워둡시다.

키	자동 회전	수동 회전
AWS Managed	매년 자동 (주기 변경 X)	불가
Customer Managed	활성화 가능 (90일~2,560일, 기본 1년)	온디맨드 가능
Imported (BYOK)	불가	Alias로 수동만

여기서 시험 함정이 하나 있어요. BYOK(Imported Key)는 자동 회전이 안 됩니다. 직접 가져온 키는 AWS가 "안전하게 새로 만들어 줄게요"를 못 해 주거든요. 그래서 별칭(Alias)을 새 키로 바꾸는 식으로만 수동 회전이 가능합니다. "가져온 키를 자동 회전시켜라" 같은 보기는 무조건 오답이에요.

Multi-Region Keys — 글로벌 데이터의 숙제

KMS 키는 기본적으로 리전에 종속됩니다. 서울 리전에서 만든 키는 서울에서만 동작해요. 그런데 글로벌로 운영하는 앱이라면 — 예를 들어 DynamoDB 글로벌 테이블이나 Aurora 글로벌 DB — 한 리전에서 암호화한 데이터를 다른 리전에서 풀 일이 생깁니다. 매번 리전을 가로질러 KMS를 호출하면 지연이 너무 커요.

이 문제를 푸는 게 Multi-Region Keys입니다. 회사 비유로 — 본사 금고의 마스터키와 동일한 사본을 각 지사 금고에 비치해 두는 거예요. 본사에서 잠근 문서를 지사에서도 같은 키로 풀 수 있게요.

기본 키(Primary)를 다른 리전의 복제 키(Replica)로 복제하면, 두 키가 동일한 Key ID와 Key Material(키 구성 요소) 를 공유합니다. 한 리전에서 암호화한 데이터를 다른 리전에서 재암호화 없이 복제 키로 그대로 복호화할 수 있어요.

여기서 시험 함정 — Multi-Region Keys는 완전한 글로벌 리소스가 아닙니다. 각 리전의 키는 고유한 키 정책을 가지고 독립적으로 관리돼요. "글로벌 리소스라 정책이 자동 동기화된다" 같은 보기는 오답입니다. 자동 회전은 기본 키에서 일어나면 복제 키에 동기화되는 식이고요.

AWS 권장사항도 알아두면 좋아요 — 기본은 단일 리전 격리, Multi-Region Keys는 글로벌 클라이언트 측 암호화·DynamoDB 글로벌 테이블·Aurora 글로벌 DB 같은 특정 유스케이스에만 제한적으로 사용.

Envelope Encryption — 4KB의 벽을 넘는 법

KMS의 결정적 한계 하나 — 4KB를 초과하는 데이터는 직접 암호화할 수 없습니다. 그러면 큰 동영상 파일이나 GB 단위 백업은 어떻게 암호화하느냐? 답이 Envelope Encryption(봉투 암호화) 입니다.

회사 비유로 풀면 정말 간단해요. 큰 짐(대용량 데이터)은 데이터 키로 잠그고, 데이터 키는 마스터키(KMS 키)로 잠근다. 봉투 안에 작은 봉투가 들어 있는 모양이에요. KMS는 작은 봉투(데이터 키)만 책임지고, 큰 짐은 로컬에서 데이터 키로 직접 암호화합니다.

흐름은 이래요.

1. GenerateDataKey API 호출 → KMS가 DEK(Data Encryption Key, 데이터 키) 를 생성해서 평문 DEK + 암호화된 DEK 두 형태로 돌려줍니다
2. 평문 DEK로 대용량 데이터를 로컬에서 암호화 (KMS 호출 없이 빠르게)
3. 암호화된 DEK를 암호화된 데이터 옆에 같이 저장, 평문 DEK는 즉시 메모리에서 삭제
4. 복호화 시 — 암호화된 DEK를 KMS에 보내 평문 DEK를 받고, 그 DEK로 데이터를 푸는 식

이 패턴 덕에 KMS는 작은 키만 다루면 되고, 실제 대용량 데이터 암호화는 로컬에서 빠르게 처리됩니다. AWS의 거의 모든 SSE 구현이 내부적으로 이 패턴을 써요.

여기서 시험에 자주 나오는 부수 사실 하나 — Decrypt API 호출 시 키 ID를 명시할 필요가 없습니다. 암호문 blob 안에 메타데이터로 키 ID가 박혀 있어서 KMS가 알아서 찾아갑니다. "복호화하려면 어떤 키 ID를 써야 하는지 어떻게 알아내나요?" 같은 보기가 나오면 답은 "그럴 필요 없다, KMS가 자동으로 식별한다"예요.

키 정책과 교차 계정

KMS 키 정책은 S3 버킷 정책과 비슷한 모양입니다. 한 가지 결정적인 룰 — 키 정책이 없으면 아무도 그 키에 접근 못 합니다. IAM 정책이 아무리 열려 있어도 키 정책이 닫혀 있으면 끝이에요.

기본 키 정책은 IAM 정책에서 허용한 계정 내 사용자에게 접근을 열어주고, 사용자 지정 키 정책으로 특정 사용자/역할만 키를 관리·사용하게 좁힐 수 있어요. 교차 계정 액세스는 반드시 사용자 지정 키 정책을 써야 하고요.

kms:ViaService 조건은 자주 나오는 키 — "이 키는 SQS를 통해서만 사용 가능"처럼 특정 AWS 서비스를 거쳐야만 키에 접근하도록 제한합니다.

교차 계정 KMS 사용은 시험에 거의 매번 나오는 시나리오라 천천히 풀어 갑니다.

EBS 스냅샷을 다른 계정과 공유하려면 — 반드시 Customer Managed Key로 암호화해야 합니다. AWS Managed Key로 암호화한 스냅샷은 교차 계정 공유가 안 돼요. 그리고 키 정책에 대상 계정 접근을 허용한 다음 스냅샷을 공유합니다. 대상 계정은 자기 KMS 키로 재암호화해서 보관하고요.

암호화된 AMI를 다른 계정과 공유하는 건 세 단계예요.

1. AMI 실행 권한(Launch Permissions)에 대상 계정 ID 추가
2. KMS 키 정책에 대상 계정 허용 추가
3. 대상 계정 IAM에 kms:DescribeKey·kms:ReEncrypt*·kms:CreateGrant·kms:Decrypt 권한 부여

그리고 또 하나 — SSE-KMS로 암호화된 객체는 기본적으로 S3 복제 시 복제되지 않습니다. 처음 보면 "왜?" 싶은데, KMS 키가 리전 종속이라 그래요. 복제하려면 복제 설정에서 명시적으로 활성화 + 대상 KMS 키 지정 + 복제 IAM 역할에 소스 키 kms:Decrypt + 대상 키 kms:Encrypt 권한 추가까지 해야 합니다.

대규모 복제를 돌리면 KMS API 한도(스로틀링)에 걸릴 수 있는데, 이 경우 AWS Support에 Service Quotas 증가 요청을 해야 합니다.

SSM Parameter Store vs Secrets Manager — 시험 단골 페어

비밀 정보를 저장하는 옵션이 둘인데, 이게 시험에 정말 자주 나옵니다. 두 서비스의 결정적 차이부터 잡고 시작합시다.

SSM Parameter Store 는 앱의 구성 데이터(URL·플래그)와 비밀 정보를 저장하는 서버리스 저장소입니다. 회사 비유로 — 회사 공용 캐비닛이에요. 누구나 (권한이 있다면) 자기 폴더 만들고 문서를 넣어둘 수 있고, 비밀 문서는 금고(KMS)와 연동된 칸에 보관합니다.

가장 큰 강점이 계층적 구조 — /my-app/dev/db-url, /my-app/prod/db-password 같이 경로 기반으로 정리할 수 있어요. IAM 정책에서 와일드카드(arn:aws:ssm:region:account-id:parameter/myapp/dev/*)로 환경별 권한 분리도 깔끔하게 됩니다.

티어가 둘이에요 — Standard와 Advanced.

구분	Standard	Advanced
최대 파라미터 수	10,000	100,000
최대 크기	4 KB	8 KB
교차 계정 공유	불가	가능
파라미터 정책	미지원	지원 (만료·알림)
비용	무료	파라미터당 월 $0.05

파라미터 타입은 셋 — String(일반 텍스트), StringList(쉼표 구분 값), SecureString(KMS 암호화). 이 중 SecureString이 시험에 자주 나와요. SecureString을 읽으려면 권한이 두 개 필요합니다 — ssm:GetParameter + kms:Decrypt 둘 다요. 한쪽만 있으면 안 됩니다. SSM에서 값을 꺼내는 권한과, KMS로 그 값을 푸는 권한이 분리돼 있어서 그래요.

CLI에서 SecureString을 평문으로 받을 때는 --with-decryption 플래그, 하위 계층 전체를 한 번에 가져올 때는 --recursive 플래그.

# 특정 파라미터 가져오기
aws ssm get-parameters --names /my-app/dev/db-url

# 경로 기반으로 가져오기
aws ssm get-parameters-by-path --path /my-app/dev

# 모든 하위 계층 포함
aws ssm get-parameters-by-path --path /my-app --recursive

# SecureString 복호화하여 가져오기
aws ssm get-parameters --names /my-app/prod/db-password --with-decryption

Advanced 티어 전용으로 파라미터 정책이 있어요 — 만료(TTL)로 비밀번호를 강제로 바꾸게 하거나, 만료 N일 전에 EventBridge 알림을 보내거나, N일 동안 변경이 없으면 알리는 식. "주기적으로 비밀번호를 강제 갱신하라" 같은 시나리오에서 끌어다 쓸 수 있습니다.

Secrets Manager — 자동 교체가 핵심

Secrets Manager 는 비밀 정보를 저장·관리할 뿐 아니라 자동 교체(Rotation) 까지 해주는 서비스입니다. 회사 비유로 — 비밀 전용 금고이자, 정해진 주기마다 비밀번호를 알아서 갈아주는 자동 도어락이에요. KMS로 모든 비밀이 암호화되고, 리소스 기반 정책으로 교차 계정 공유도 가능합니다.

요금은 30일 무료 체험, 이후 비밀 1개당 월 $0.40 / API 호출 1만 건당 $0.05.

자동 교체는 지정한 주기(30일·60일 등)마다 비밀번호를 바꿉니다. 교체 로직은 Lambda 함수로 구현돼요. 여기서 결정적 — RDS·Aurora·DocumentDB·Redshift는 기본 통합이 돼 있어서, Secrets Manager에서 암호를 바꾸면 DB의 실제 암호도 자동으로 같이 업데이트됩니다. 따로 코드 짤 필요가 없어요.

기본 통합되지 않은 서드파티 API 키 같은 건 사용자가 교체 로직 Lambda를 직접 작성해 연결하면 됩니다.

Multi-Region Secrets — 기본 리전에서 만든 비밀을 여러 보조 리전에 복제·동기화하는 기능. 기본 리전 장애 시 복제된 비밀을 독립 실행형(Standalone)으로 승격할 수 있고, 다중 리전 앱·다중 리전 RDS에서 같은 자격 증명을 로컬로 빠르게 접근할 수 있어요. Parameter Store에는 없는 기능입니다.

둘 중 어느 걸 골라야 하나 — 키워드 매칭

시험에서 둘 중 하나를 고르라고 나오면 키워드 매칭으로 거의 풀립니다.

비교	Secrets Manager	Parameter Store
주요 목적	비밀 + 자동 교체	구성 + 비밀
자동 교체	지원 (Lambda 연동, RDS 기본)	미지원 (직접 구현)
RDS 통합	기본	수동
계층 구조	없음	있음
비용	비밀당 월 $0.40	Standard 무료
다중 리전 복제	지원	미지원

한 줄 정리 — "자동 교체", "RDS/Aurora 자격 증명 자동 교체" 키워드가 보이면 무조건 Secrets Manager. "계층적 구조", "구성 데이터", "비용 절감" 키워드면 Parameter Store.

Lambda에서 안전하게 비밀번호 쓰기 — 표준 패턴

이 패턴은 시험에도 자주 나오고 실무에서도 표준이에요.

Lambda 함수
  → IAM 실행 역할 (ssm:GetParameter + kms:Decrypt 권한)
    → SSM Parameter Store (SecureString)
      → KMS 복호화
        → 평문 비밀번호 반환
          → RDS 연결

Lambda 실행 역할에 두 권한(SSM 읽기 + KMS 복호화)을 모두 부여하는 게 핵심입니다. "Lambda가 SSM에서 비밀번호 읽는데 안 된다" 시나리오의 90%는 이 둘 중 하나가 빠진 거예요.

ACM — TLS 인증서, us-east-1 함정에 주의

ACM(AWS Certificate Manager) 는 HTTPS/TLS 인증서를 발급·관리·배포해주는 서비스입니다. 공용(Public) TLS 인증서는 무료이고, ACM 발급 공용 인증서는 만료 60일 전에 자동 갱신돼요. 비용 걱정 없이 HTTPS를 적용할 수 있는 거의 표준 도구입니다.

도메인 검증 방식은 둘:

• DNS 검증(권장) — DNS 구성에 CNAME 레코드 하나만 박으면 끝. 자동화·자동 갱신에 가장 적합. Route 53과 자동 통합
• 이메일 검증 — 도메인 등록처 연락처로 이메일 보내 승인

ACM이 지원하는 서비스는 정해져 있어요 — ALB·NLB·CloudFront·API Gateway.

여기서 시험 함정 — EC2 인스턴스에는 ACM에서 발급한 공용 인증서를 직접 설치할 수 없습니다. 추출도 안 돼요. EC2에서 HTTPS를 쓰고 싶으면 별도 인증서를 따로 사거나, ALB를 앞에 두고 ALB에 ACM을 붙이는 게 정석입니다.

가장 큰 함정 — API Gateway 엔드포인트 타입별 리전

이 부분이 ACM 단원에서 가장 자주 출제되는 함정이에요.

• Edge-Optimized 엔드포인트 — 내부적으로 CloudFront를 쓰기 때문에 ACM 인증서가 반드시 us-east-1(버지니아 북부) 리전에 있어야 합니다
• Regional 엔드포인트 — ACM 인증서가 API Gateway와 동일 리전에 있어야 합니다

CloudFront에 직접 붙이는 ACM 인증서도 마찬가지로 us-east-1이어야 하고요. 시험에 "API Gateway에 ACM 인증서 붙였는데 동작 안 한다"는 시나리오가 나오면 답이 거의 매번 이 리전 함정입니다. us-east-1, 외워둡시다.

외부에서 가져온 인증서는 자동 갱신 X

타사에서 발급받은 인증서를 ACM으로 가져올 수 있는데(Imported), 이건 자동 갱신이 안 됩니다. 만료 전에 수동으로 새 인증서를 다시 가져와야 해요.

만료 모니터링 방법이 두 개 — EventBridge(만료 45일 전부터 매일 만료 이벤트 발생, Lambda/SNS/SQS 트리거)와 AWS Config(acm-certificate-expiration-check 관리형 규칙으로 비준수 이벤트 → EventBridge).

내부 서비스용 사설 인증서가 필요하면 ACM Private CA를 씁니다.

CloudHSM — 단일 테넌트, FIPS 140-2 Level 3

CloudHSM 은 KMS와 자주 비교되는 서비스인데, 한 번에 비교 표로 잡고 가는 게 빠릅니다. 일단 본질부터 — AWS가 하드웨어(HSM 장치)를 제공하지만 단일 테넌트(Single-tenant) 전용 환경으로 운영합니다.

회사 비유로 — KMS가 "여러 회사가 공유하는 보안 빌딩 안의 우리 회사 캐비닛"이라면, CloudHSM은 "우리 회사만 쓰는 별도 보안 동(棟)을 통째로 빌리는 것"이에요. 더 비싸지만 더 격리됩니다.

가장 결정적인 차이 — AWS는 하드웨어만 관리하고 암호화 키에는 전혀 접근 불가. 키는 고객이 100% 관리합니다. 규정 준수 수준이 FIPS 140-2 Level 3 — 변조 방지, 물리적 접근 시도 시 자가 차단까지 됩니다.

대칭·비대칭·해싱·SSL/TLS 키 모두 지원하고 VPC 내부에 배포돼요. VPC 피어링/공유로 다른 VPC에서도 접근 가능합니다. 특수 기능으로 로드 밸런서 SSL/TLS 오프로딩, Oracle TDE 가속도 됩니다.

여기서 시험 함정이 하나 있어요. CloudHSM은 기본적으로 단일 HSM 장치라 고가용성이 자동으로 보장되지 않습니다. 다중 AZ에 여러 HSM 장치를 직접 프로비저닝해 클러스터로 구성해야 HA가 확보돼요. KMS는 자동 HA, CloudHSM은 직접 구성 — 이 차이를 외워둬야 합니다.

권한 모델도 달라요. IAM의 역할은 인프라 관리(생성·읽기·수정·삭제)에만 쓰이고, 키 관리 권한은 IAM이 아닌 CloudHSM 자체 클라이언트 소프트웨어의 보안 메커니즘으로 합니다. 시험에서 "CloudHSM 키 자체에 IAM 정책으로 권한을 준다" 같은 보기는 무조건 오답이에요.

KMS와 CloudHSM의 짝꿍 — CloudHSM을 KMS의 Custom Key Store(사용자 지정 키 스토어) 로 등록하면, KMS API의 편한 인터페이스를 그대로 쓰면서 실제 키는 CloudHSM에 두는 패턴이 가능합니다. EBS·S3·RDS 같은 AWS 서비스에서 CloudHSM 키를 투명하게 쓸 수 있어요.

KMS vs CloudHSM 핵심 비교 — 시험 단골

구분	KMS	CloudHSM
테넌시	멀티 테넌트	싱글 테넌트
키 관리	AWS·고객 혼합	고객만 (AWS 접근 불가)
FIPS	Level 2	Level 3
인증/접근	IAM	자체 클라이언트 SW
HA	자동	직접 다중 AZ 구성
VPC 배포	불필요	필요
비용	프리 티어	프리 티어 X

키워드 매칭 — "FIPS 140-2 Level 3", "전용 하드웨어", "AWS 접근 불가" 셋 중 하나만 보여도 답은 CloudHSM.

Shield — Standard와 Advanced의 결정적 차이

AWS Shield 는 DDoS 방어 서비스입니다. 두 가지 티어로 갈려요.

Shield Standard 는 무료이고 모든 AWS 고객에게 자동 활성화됩니다. Layer 3·4 공격(SYN 플러드·UDP 플러드·반사 공격) 방어가 기본 제공돼요. AWS 계정만 있으면 별도 신청 없이 받을 수 있는 보호입니다.

Shield Advanced 는 조직당 월 $3,000 의 유료 서비스예요. 더 정교하고 대규모인 DDoS와 Layer 7 공격까지 방어하고, 보호 대상은 EC2·ELB·CloudFront·Global Accelerator·Route 53.

월 $3,000은 비싸 보이지만 Shield Advanced의 진짜 매력은 세 가지에 있습니다.

1. 24/7 SRT(Shield Response Team) 지원 — 공격 발생 시 AWS 보안 전문가가 즉각 개입해서 같이 대응해 줍니다
2. DDoS 비용 보호(Cost Protection) — 공격으로 인해 리소스가 자동 확장돼 청구된 추가 비용을 면제해 줘요. DDoS는 청구서로도 공격이 되거든요
3. 자동화된 Layer 7 방어 — AWS WAF와 통합돼 Layer 7 공격 완화 WAF 규칙을 자동 생성·평가·배포

키워드 매칭 — "SRT 지원", "DDoS 비용 보호", "자동 WAF 규칙 생성" 셋 중 하나만 보여도 답은 Shield Advanced입니다.

WAF — Layer 7 웹 방화벽

AWS WAF(Web Application Firewall) 는 HTTP/HTTPS 7계층에서 동작하는 방화벽이에요. Shield가 트래픽 양과 인프라 공격에 집중한다면, WAF는 요청 내용 자체를 들여다 보면서 SQL 인젝션·XSS 같은 웹 취약점 공격을 차단합니다.

여기서 시험 함정이 하나 있어요. NLB에는 WAF를 연결할 수 없습니다. NLB는 4계층(TCP/UDP)이라 HTTP 헤더·본문을 들여다 볼 수가 없어요. WAF는 7계층 도구라서 짝이 안 맞습니다. "NLB에 WAF를 붙여 SQL 인젝션을 막는다" 같은 보기는 무조건 오답이에요.

배포 대상은 두 부류예요:

• 글로벌: CloudFront (Web ACL은 us-east-1에서 관리)
• 리전: ALB·API Gateway·AppSync GraphQL API·Cognito 사용자 풀

Web ACL 규칙 유형은 다양합니다 — IP Set으로 IP 차단/허용(IP 세트당 최대 10,000개 IP), HTTP 헤더·본문·URI 문자열 기반 필터링, 크기 제약 조건, 국가 기반 Geo-Match, 속도 기반 규칙(Rate-based Rules) 으로 DDoS 방어, AWS 제공 관리형 규칙(Managed Rules) 으로 IP 평판·익명 IP·봇 제어, 여러 Web ACL에 재사용 가능한 규칙 그룹까지.

Web ACL 자체는 우선순위(평가 순서), 기본 동작(어떤 규칙도 안 맞을 때 허용/차단), 용량(최대 1500 WCU)으로 구성돼요. WAF 로그는 S3·CloudWatch Logs·Kinesis Data Firehose로 보낼 수 있고요.

고정 IP + WAF + 로드 밸런서 — 시험 단골 패턴

이 시나리오는 시험에 거의 매번 한 번씩 나오는 단골이에요. 천천히 풀어 갑니다.

상황 — "고정 IP를 가진 엔드포인트가 필요하고, 동시에 WAF로 Layer 7 보호도 받고 싶다." 이게 의외로 간단치 않아요.

문제는 두 가지입니다.

• ALB는 고정 IP를 제공하지 않아요. 도메인은 있지만 IP는 자동 변동.
• NLB는 고정 IP가 있지만 WAF를 연결할 수 없어요. 4계층이니까.

그러면 둘을 어떻게 동시에 만족시키느냐 — AWS Global Accelerator + ALB + WAF 조합입니다.

1. Global Accelerator 가 고정 Anycast IP 2개를 제공
2. 트래픽을 ALB로 라우팅
3. ALB에 WAF Web ACL 연결 → Layer 7 보호

이 패턴은 표 그대로 외워두는 게 좋아요. "고정 IP가 필요" + "WAF 보호도 필요" → GA + ALB + WAF.

Firewall Manager — 다중 계정 보안 정책

회사가 여러 AWS 계정을 운영하면서 WAF·Shield·SG 정책을 일관되게 관리하고 싶을 때 — AWS Firewall Manager 가 그 자리입니다. AWS Organizations 레벨에서 동작해요.

회사 비유로 — 본사 보안팀이 모든 지사의 출입문 정책·CCTV 설정을 한 곳에서 일괄 관리하는 시스템이에요. 새 지사가 문을 열어도 본사 표준이 자동 적용됩니다.

핵심 특징:

• 중앙 집중식 관리 — 여러 계정에 일관된 보안 정책을 한 번에 적용
• 자동화 — 새 리소스 생성 시 사전 정의된 보안 규칙 자동 적용 (규정 준수 가속)
• 리전 수준 생성 → 조직 내 모든 계정에 적용
• 비용 — 정책당 월 $100

관리하는 정책 종류 — WAF 규칙(ALB·API GW·CloudFront), Shield Advanced 규칙, VPC 보안 그룹(EC2·ALB·ENI), AWS Network Firewall 규칙, Route 53 Resolver DNS Firewall.

키워드 매칭 — "다중 계정", "Organizations", "보안 정책 자동 적용" → Firewall Manager.

위협 탐지 3종 — GuardDuty·Inspector·Macie

이 셋은 이름도 비슷하고 용도도 헷갈리지만, 무엇을 보느냐(데이터 소스) 가 결정적으로 달라요. 한 번에 묶어서 외워두면 시험에서 바로 풀립니다.

GuardDuty — 위협 탐지 (행동 분석)

GuardDuty 는 머신러닝·이상 감지·타사 위협 인텔리전스로 위협 탐지(Threat Detection) 를 합니다. 회사 비유로 — 회사 안에서 평소와 다른 행동을 감지하는 보안 카메라 + AI 분석가예요. 누가 새벽 3시에 갑자기 서버실에 들어가거나, 평소 안 가던 곳에서 데이터를 빼내려 하면 즉각 알림.

핵심 특징 — 에이전트리스(Agentless), 소프트웨어 설치 불필요. 30일 무료 평가판 제공.

분석 데이터 소스가 시험에 자주 나와요. 기본 셋부터 외웁시다:

• CloudTrail 이벤트 로그 — 특이한 API 호출, 승인되지 않은 배포
• VPC Flow Logs — 비정상 트래픽, 특이한 IP 통신
• DNS Logs — DNS 쿼리 안에 인코딩된 데이터 전송 EC2 탐지 (데이터 유출 징후)

선택적으로 EKS 감사 로그·RDS/Aurora 로그인·S3 데이터 이벤트·Lambda 네트워크·EBS 멀웨어·런타임 모니터링까지 켤 수 있고요.

EventBridge 연동이 자동화의 핵심 — Finding이 발생하면 EventBridge → Lambda(자동 조치, 예: 해킹된 EC2 보안 그룹 변경, EC2 격리) 또는 SNS(이메일/SMS 알림)로 흘려보냅니다.

키워드 — "암호화폐 채굴(Cryptojacking) 탐지", "ML 기반 위협 탐지", "비정상 API 호출" → 무조건 GuardDuty.

Inspector — 취약점 관리 (CVE)

Inspector 는 알려진 소프트웨어 취약점(CVE, Common Vulnerabilities and Exposures)과 의도하지 않은 네트워크 노출을 지속적으로 스캔하는 자동화된 취약점 관리 서비스입니다. 회사 비유로 — 건물 안전 점검 업체가 정기적으로 와서 "이 방 자물쇠가 알려진 약점이 있다"고 리포트하는 것.

평가 대상은 셋이에요:

1. EC2 인스턴스 — SSM Agent를 활용해 OS 취약점·의도하지 않은 네트워크 접근성 분석
2. ECR 컨테이너 이미지 — Push된 이미지의 알려진 취약점 분석
3. Lambda 함수 — 배포 시 코드·패키지 종속성 취약점 확인

특징 — 지속적 스캔, CVE 데이터베이스 업데이트 시 자동 재평가, 취약점에 리스크 스코어 부여로 우선순위 매김. Security Hub·EventBridge 통합도 됩니다.

여기서 시험 함정 — EC2를 Inspector로 스캔하려면 SSM Agent가 설치돼 있어야 합니다. "SSM Agent 없이 EC2 OS 취약점을 스캔" 같은 보기는 오답.

키워드 — "CVE 취약점", "EC2/ECR/Lambda 스캔", "알려진 소프트웨어 취약성" → Inspector.

Macie — S3 민감 데이터 탐지

Macie 는 머신러닝과 패턴 매칭으로 S3 버킷의 민감 데이터(PII·신용카드 번호·여권 번호) 를 자동 탐지하는 서비스입니다. 다른 두 서비스와 결정적으로 다른 점 — 대상이 S3에 한정.

회사 비유로 — 공용 캐비닛(S3) 안에 누가 실수로 주민등록번호 적힌 문서를 넣어 두진 않았는지 자동으로 검사해 주는 도구예요.

흐름 — S3에 데이터 업로드 → Macie가 분석해 PII 발견 → Findings를 EventBridge로 전송 → SNS(알림) 또는 Lambda(자동 조치, 예: 해당 객체 격리·삭제).

키워드 — "S3 + 민감 데이터 + PII + 머신러닝" → Macie.

셋 한 번에 정리

구분	GuardDuty	Inspector	Macie
목적	위협 탐지	취약점 관리	민감 데이터 탐지
데이터 소스	CloudTrail·VPC Flow·DNS Logs	EC2 OS·ECR 이미지·Lambda 코드	S3
탐지 기술	ML·이상 감지	CVE DB	ML·패턴 매칭
에이전트	불필요	EC2는 SSM Agent	불필요
대표 키워드	암호화폐 채굴, 비정상 API	CVE, 네트워크 노출	PII, 신용카드

한 줄 암기 — 행동(GuardDuty) / 약점(Inspector) / 내용(Macie).

자주 나오는 보안 아키텍처 패턴

여기까지 본 서비스들이 실제로 어떻게 묶이는지 자주 보는 패턴 몇 개로 정리합니다. 시험에 시나리오로 자주 변형돼서 나와요.

Lambda에서 안전한 DB 자격 증명 사용

Lambda
  → IAM 실행 역할 (ssm:GetParameter + kms:Decrypt)
    → SSM Parameter Store (SecureString)
      → KMS 복호화
        → 평문 비밀번호
          → RDS 연결

DDoS 방어 (글로벌 웹 서비스)

사용자
  → Global Accelerator (고정 IP 2개, Shield Advanced)
    → ALB + WAF (SQL 인젝션·XSS·Rate-based)
      → Auto Scaling Group (EC2)

서버리스 API DDoS 방어

사용자
  → CloudFront (WAF Global, Shield)
    → API Gateway (WAF Regional, Throttling, API Key)
      → Lambda

RDS 자격 증명 자동 교체

Secrets Manager
  → 30일 자동 교체 스케줄
    → Lambda (교체 로직)
      → RDS 새 비밀번호 업데이트
      → Secrets Manager 값 업데이트

위협 탐지 자동 대응

GuardDuty (CloudTrail + VPC Flow Logs + DNS)
  → Finding
    → EventBridge
      ├── SNS → 이메일/SMS 알림
      └── Lambda → 자동 조치 (보안 그룹 변경, EC2 격리)

다중 계정 보안 정책 관리

AWS Organizations (관리 계정)
  → Firewall Manager
    → 모든 멤버 계정에 자동 적용
      ├── WAF Web ACL (ALB·API Gateway·CloudFront)
      ├── Shield Advanced 보호
      └── VPC 보안 그룹 표준화

시험 직전 한 번 더 — KMS 함정 포함 압축 모음

여기까지가 보안·암호화 영역의 핵심입니다. 시험 직전에 다시 펼쳐 볼 압축 노트를 마지막에 박아 둘게요. 이 부분만 시험 전날 한 번 더 읽으면 거의 다 떠오릅니다.

KMS — 키 관리·암호화 함정

• 암호화 3방식 — In-transit / SSE(AWS가 평문 봄) / CSE(AWS도 못 봄)
• KMS는 모든 API 호출이 CloudTrail에 자동 기록
• KMS 복호화 시 Key ID 명시 불필요 (암호문 blob에 메타데이터)
• KMS API 비용 = 10,000건당 $0.03, CMK = 월 $1
• BYOK(Imported Key)는 자동 회전 불가 — Alias로 수동만
• CMK 자동 회전 주기 = 90일~2,560일 (기본 1년)
• Multi-Region Keys = Key ID·Material 공유, 단 키 정책은 리전별 독립
• 교차 계정 KMS = 반드시 Customer Managed Key + 키 정책에 대상 계정 허용
• SSE-KMS 객체는 S3 복제 시 기본 X — 옵션 활성화 + IAM 역할에 Decrypt/Encrypt 권한
• Envelope Encryption — KMS 4KB 한계를 DEK로 우회, 큰 짐은 DEK로 / DEK는 마스터키로

Parameter Store · Secrets Manager · ACM

• Parameter Store SecureString 읽기 = ssm:GetParameter + kms:Decrypt 둘 다 필요
• Parameter Store Standard = 4KB / Advanced = 8KB, 정책(만료·알림)은 Advanced 전용
• 자동 교체 = Secrets Manager / 계층 구조·무료 = Parameter Store
• Secrets Manager는 RDS·Aurora·DocumentDB·Redshift 기본 통합 + Multi-Region Secrets 지원
• API Gateway Edge-Optimized·CloudFront ACM = us-east-1 필수
• ACM은 EC2에 직접 설치 불가, Imported 인증서는 자동 갱신 X
• ACM 공용 인증서 = 무료, 만료 60일 전 자동 갱신 (DNS 검증 권장)

CloudHSM·Shield·WAF·Firewall Manager

• CloudHSM = 단일 테넌트 · FIPS 140-2 Level 3 · AWS 키 접근 불가
• CloudHSM HA는 자동 X — 다중 AZ에 직접 클러스터 구성
• CloudHSM 키 권한 = IAM 아닌 자체 클라이언트 SW
• Shield Advanced = 월 $3,000 + SRT 24/7 + DDoS 비용 보호 + 자동 WAF 규칙
• NLB에는 WAF 연결 불가 (4계층)
• CloudFront WAF Web ACL = us-east-1 글로벌 리소스
• 고정 IP + WAF = Global Accelerator + ALB + WAF
• 다중 계정 보안 정책 자동 적용 = Firewall Manager (Organizations 레벨, 정책당 월 $100)

위협 탐지 3종 — GuardDuty·Inspector·Macie

• GuardDuty = 행동(CloudTrail·VPC Flow·DNS), 암호화폐 채굴 탐지
• Inspector = 약점(CVE), EC2(SSM Agent)·ECR·Lambda
• Macie = 내용(S3 PII·신용카드·여권)

마무리 한 줄

여기까지가 SAA-C03 보안·암호화 영역의 전부예요. 정리하고 보면 결국 다섯 갈래입니다 — 키 관리(KMS·CloudHSM), 비밀 저장(Parameter Store·Secrets Manager), 인증서(ACM), 트래픽 보호(Shield·WAF·Firewall Manager), 위협 탐지(GuardDuty·Inspector·Macie). 이 다섯 칸으로 묶어 외워두면 시험 시나리오가 와도 어디 자리인지 1초 안에 잡힙니다. 그중에서도 KMS의 CMK 4종·Envelope Encryption·교차 계정 키 정책 셋만 잡아도 시험 보기에서 막히는 일이 거의 없어요.

처음에 길어 보이던 단원이 결국 회사 금고와 마스터키, 공용 캐비닛과 자동 도어락, 안전 점검 업체 같은 비유 몇 개로 다 풀려요. 표를 직접 손으로 다시 그려 보면서 머리에 새겨두면 이 단원에서 30%의 점수를 안정적으로 가져갈 수 있습니다.

시리즈 다른 편

같은 시리즈의 다른 글들도 같은 친절 톤으로 묶어 정리되어 있어요.

• 1편 — IAM
• 2편 — EC2 / Storage
• 3편 — ELB · ASG
• 4편 — S3 (스토리지)
• 5편 — Databases
• 6편 — Networking
• 7편 — Messaging
• 8편 — Containers · Serverless
• 9편 — Monitoring
• 10편 — Analytics · ML
• 11편 — Security (현재 글)
• 12편 — DR · Migration
• 13편 — Architectures
• 14편 — Exam Prep (완)