AWS Certified Solutions Architect - Associate (SAA-C03) #5 Domain 1-4 안전한 아키텍처: WAF,Shield,Cognito,Secrets Manager
#4 VPC 보안에서 네트워크 경계를 잡았습니다. 보안 도메인의 마지막인 이번 글은 한 층 더 위로 올라가, **애플리케이션 계층의 공격 방어(WAF,Shield)**와 **사용자 인증,자격 증명 관리(Cognito,Secrets Manager)**를 다룹니다. 이 네 서비스는 시험에서 역할이 헷갈리기 쉬워, “무엇을 푸는 서비스인가"를 정확히 구분하는 것이 핵심입니다.
WAF: 웹 애플리케이션 방화벽 #
AWS WAF는 **계층 7(HTTP/HTTPS)**에서 동작하는 웹 방화벽입니다. **웹 ACL(Web ACL)**에 규칙을 모아 두고, 요청을 검사해 허용,차단,카운트합니다.
규칙 종류 #
- 관리형 규칙 그룹. AWS와 마켓플레이스가 제공하는 사전 정의 규칙(공통 취약점, 알려진 악성 IP 등)
- SQL injection / XSS 매칭. 대표적인 웹 공격 패턴 차단
- IP set 매칭. 특정 IP,대역 허용/차단
- Geo 매칭. 국가 단위 차단/허용
- Rate 기반 규칙. 일정 시간당 요청 수를 초과하는 IP 차단(계층 7 플러딩 완화)
- 문자열/정규식 매칭. 헤더,URI,바디의 패턴 검사
어디에 붙는가 #
WAF는 CloudFront, Application Load Balancer(ALB), API Gateway, AppSync, Cognito User Pool에 연결됩니다. 모두 계층 7 진입점입니다. NLB(Network Load Balancer)는 계층 4라 WAF를 붙일 수 없습니다. 이 구분이 시험에 나옵니다.
Shield: DDoS 방어 #
| 항목 | Shield Standard | Shield Advanced |
|---|---|---|
| 비용 | 무료(자동 적용) | 월 3,000 USD + |
| 방어 계층 | L3/L4 | L3/L4/L7 |
| 대응 지원 | 없음 | DDoS 대응팀(SRT) |
| 비용 보호 | 없음 | DDoS로 인한 확장 비용 환급 |
| WAF | 별도 | WAF 포함 |
Shield Standard는 모든 AWS 고객에게 자동으로, 무료로 적용되는 L3/L4 DDoS 방어입니다. 별도 설정이 필요 없습니다. 여기에 더해 L7 DDoS 방어, 전문 대응팀, DDoS로 인한 자동 확장 비용 환급, 상세 리포트가 필요하면 Shield Advanced(유료)를 씁니다.
시험에서 “추가 비용 없이 기본 DDoS 보호가 되는가?“의 답은 **Shield Standard(예, 자동,무료)**입니다. “대규모 L7 DDoS와 비용 보호, 전문 대응이 필요하다"면 Advanced입니다.
Cognito: User Pool vs Identity Pool #
Cognito는 두 가지 다른 일을 합니다. 이 둘을 섞으면 인증 문항을 거의 틀립니다.
| 구분 | User Pool | Identity Pool (Federated Identities) |
|---|---|---|
| 푸는 문제 | 인증(Authentication). 누구인가, 로그인 | 인가(Authorization). AWS 리소스 접근 |
| 결과물 | JWT 토큰(ID/Access/Refresh) | 임시 AWS 자격 증명(STS) |
| 대표 기능 | 회원가입,로그인,MFA,소셜/SAML 페더레이션 | 인증된 신원을 AWS 자격 증명으로 교환 |
| 한 줄 | “사용자를 로그인시킨다” | “사용자에게 임시 AWS 접근을 준다” |
- User Pool. 사용자 디렉터리이자 인증 서버입니다. 회원가입,로그인,MFA,비밀번호 정책을 제공하고, 소셜(Google,Facebook),SAML,OIDC 페더레이션을 붙일 수 있습니다. 로그인 성공 시 JWT 토큰을 발급합니다.
- Identity Pool. 인증된 신원(User Pool,소셜,SAML)을 받아 STS 임시 AWS 자격 증명으로 교환합니다. 모바일 앱 사용자가 S3에 직접 업로드해야 할 때처럼, 앱에 장기 키를 심지 않고 AWS 리소스에 접근하게 합니다.
둘은 자주 함께 쓰입니다. User Pool로 로그인 → 그 토큰을 Identity Pool에 제시 → 임시 AWS 자격 증명 획득의 흐름입니다.
Secrets Manager vs Parameter Store #
자격 증명,설정값을 코드에 하드코딩하지 않고 안전하게 보관하는 두 서비스입니다.
| 항목 | Secrets Manager | SSM Parameter Store |
|---|---|---|
| 주 용도 | 비밀(DB 자격 증명, API 키) | 설정값 + 비밀(SecureString) |
| 자동 교체(rotation) | 내장 지원(RDS 등) | 없음(Lambda로 직접 구현) |
| 비용 | 비밀당 월 $0.40 + API | 표준 파라미터 무료 |
| 암호화 | KMS | KMS(SecureString) |
| 교차 계정 | 지원 | 제한적 |
핵심 분기점은 **자동 교체(rotation)**입니다. “DB 자격 증명을 주기적으로 자동 교체하라"는 요구사항이면 Secrets Manager가 정답입니다(특히 RDS,Redshift,DocumentDB는 내장 통합). 반대로 “단순 설정값이고 비용을 아끼고 싶다"면 Parameter Store가 적합합니다. Parameter Store도 SecureString으로 비밀을 KMS 암호화해 저장할 수 있지만, 자동 교체는 기본 제공되지 않습니다.
시험 출제 패턴 #
- “SQL injection / XSS 같은 웹 공격을 막아라.” → WAF
- “특정 국가 차단 / IP rate 제한.” → WAF(geo / rate 기반 규칙)
- “WAF를 NLB에 붙일 수 있나?” → 불가(L4). CloudFront/ALB/API GW/AppSync에 연결
- “추가 비용 없이 기본 DDoS 보호가 되는가?” → Shield Standard(자동,무료)
- “L7 DDoS + 비용 보호 + 대응팀.” → Shield Advanced
- “사용자 로그인/회원가입/소셜 로그인.” → Cognito User Pool
- “인증된 사용자에게 임시 AWS 자격 증명.” → Cognito Identity Pool
- “DB 자격 증명 자동 교체.” → Secrets Manager
- “단순 설정값, 비용 절감.” → Parameter Store
자주 만나는 함정 #
1) WAF를 NLB에 붙이려 한다 #
WAF는 계층 7 진입점(CloudFront/ALB/API Gateway/AppSync)에만 붙습니다. NLB는 계층 4라 대상이 아닙니다.
2) Shield Standard가 유료라고 생각 #
Standard는 모든 고객에게 자동,무료입니다. 유료는 Advanced입니다.
3) User Pool이 AWS 자격 증명을 준다고 오해 #
User Pool은 로그인과 JWT 토큰 발급까지를 담당합니다. AWS 자격 증명은 Identity Pool이 STS로 발급합니다.
4) Parameter Store에 자동 교체가 내장됐다고 생각 #
자동 교체 내장은 Secrets Manager입니다. Parameter Store는 직접 구현해야 합니다.
정리 #
이번 글에서 잡은 것:
- WAF. 계층 7 웹 방화벽. SQLi,XSS,geo,rate 규칙. CloudFront/ALB/API GW/AppSync에 연결(NLB 불가)
- Shield. Standard는 자동,무료(L3/L4). Advanced는 유료(L7,대응팀,비용 보호)
- Cognito. User Pool은 인증(JWT), Identity Pool은 임시 AWS 자격 증명. 둘은 함께 쓰임
- Secrets Manager vs Parameter Store. 자동 교체가 필요하면 Secrets Manager, 단순,저비용이면 Parameter Store
이것으로 **보안 도메인(30%)**을 마칩니다. IAM(신원) → KMS(데이터) → VPC(네트워크) → WAF,Cognito(애플리케이션,사용자)로 계층을 따라 내려오며 보안의 큰 그림을 잡았습니다.
다음: Domain 2-1 회복력 있는 아키텍처 #
다음 도메인은 **회복력(26%)**입니다. 장애가 나도 서비스가 멈추지 않게 하는 설계로 넘어갑니다.
#6 Domain 2-1 Multi-AZ,Auto Scaling,ELB에서는 가용 영역(AZ)을 활용한 고가용성, Auto Scaling 그룹의 동작과 정책, ELB의 종류(ALB,NLB,GLB)와 선택 기준, 그리고 헬스 체크로 장애 인스턴스를 걸러내는 구조를 정리하겠습니다.