SAP-C02 D2 도메인에서 보안과 신뢰성은 별개가 아닙니다. 안전하게 설계된 시스템이 신뢰성도 높습니다. 이 포스트에서는 WAF, Shield, GuardDuty로 대표되는 보안 계층, NLB와 ALB의 선택 기준, Auto Scaling 정책 유형, 그리고 SQS/SNS 기반 느슨한 결합 아키텍처를 실제 시험 시나리오와 함께 살펴봅니다.
WAF — 규칙 유형과 적용 대상
AWS WAF는 HTTP/HTTPS 레이어(L7)의 웹 공격을 방어하는 방화벽입니다. WebACL을 ALB, API Gateway, CloudFront, AppSync에 연결해서 사용합니다. EC2 인스턴스에 직접 연결하는 것은 불가능합니다.
WAF에서 자주 출제되는 규칙 유형은 세 가지입니다. Rate-based Rules는 특정 IP에서 5분 내에 일정 횟수 이상 요청이 들어오면 자동으로 차단합니다. HTTP Flood 공격 대응에 주로 사용됩니다. Geo Match 조건은 MaxMind GeoIP 데이터베이스를 기반으로 특정 국가에서의 접근을 허용하거나 차단합니다. IP Set 규칙은 명시적으로 허용하거나 차단할 CIDR 대역을 지정합니다.
WAF와 Route 53 Geolocation 라우팅의 차이를 구분해야 합니다. WAF Geo Match는 트래픽을 차단하는 반면, Route 53 Geolocation은 트래픽을 특정 엔드포인트로 라우팅하는 것이지 차단이 아닙니다.
WAF 로그는 Kinesis Data Firehose를 통해 S3에 실시간으로 저장할 수 있습니다. 로그에는 IP 주소, 국가 코드, 매칭된 규칙, 액션(ALLOW/BLOCK)이 포함됩니다. 규제 요건으로 장기 보관이 필요하면 S3 Object Lock(Compliance 모드)을 적용합니다.
Shield Advanced — DDoS L7 방어와 비용 보호
Shield Standard는 모든 AWS 계정에 기본으로 제공되며 L3/L4 볼류메트릭 공격을 자동으로 방어합니다. 추가 비용은 없습니다.
Shield Advanced는 월 3,000달러 이상의 유료 서비스로 다음 기능이 추가됩니다. L7 DDoS 공격 방어를 위한 DRT(DDoS Response Team) 24/7 지원, DDoS 공격으로 인해 발생한 과도한 AWS 요금 환급(비용 보호), 상시 탐지 및 자동 완화가 제공됩니다. 대규모 공격이 예상되거나 금융/게임 서비스처럼 고가용성이 비즈니스 핵심인 경우 Shield Advanced를 고려합니다.
DDoS 다층 방어 아키텍처의 표준 패턴은 Shield(L3/L4) + CloudFront(엣지 트래픽 분산) + WAF(L7 룰 기반 차단)의 조합입니다. 비용을 최소화하면서 기본 방어가 목표라면 Shield Standard(무료) + CloudFront + WAF 조합을 선택합니다.
NLB vs ALB — 선택 기준
| 항목 | NLB | ALB | |------|-----|-----| | 레이어 | L4 (TCP/UDP/TLS) | L7 (HTTP/HTTPS) | | 고정 IP | Elastic IP 지원 | 미지원 | | 소스 IP 보존 | 클라이언트 IP 그대로 전달 | X-Forwarded-For 헤더 필요 | | 보안 그룹 | NLB 자체에는 미지원 (EC2 SG 활용) | 지원 | | 라우팅 | IP:Port 기반 | URL 경로/Host 헤더/쿼리 파라미터 | | WAF 연결 | 미지원 | 지원 |
NLB는 클라이언트 소스 IP를 EC2 인스턴스에 그대로 전달합니다. IP 기반 접근 제어가 필요할 때 NLB 뒤에 있는 EC2의 보안 그룹에서 직접 소스 IP를 제어할 수 있습니다. NLB 자체에는 보안 그룹을 직접 적용할 수 없습니다.
UDP 포트 기반 서비스(게임 서버, DNS 등)나 고정 IP가 필요한 경우에는 NLB를 선택합니다. HTTP 기반 라우팅, WAF 연결, Host 헤더 기반 라우팅이 필요하면 ALB를 선택합니다.
!NLB vs ALB 선택 기준
암호화 — KMS CMK, SSE, TLS, VPC 엔드포인트
저장 데이터 암호화(Encryption at Rest)에서는 KMS CMK(Customer Managed Key)가 핵심입니다. S3에서는 SSE-S3(AWS 관리 키), SSE-KMS(KMS CMK), SSE-C(고객 제공 키) 세 가지 서버 측 암호화 옵션이 있습니다. S3 버킷 정책에 거부 조건을 추가하면 HTTPS가 아닌 전송을 강제로 차단할 수 있습니다.
전송 데이터 암호화(Encryption in Transit)는 TLS를 통해 달성합니다. CloudFront와 오리진 서버 간 HTTPS 통신에서는 오리진 인증서의 CN 또는 SAN이 CloudFront 오리진 도메인명과 반드시 일치해야 합니다. 자체 서명 인증서는 사용할 수 없고 공인 CA 서명 인증서가 필요합니다.
VPC 엔드포인트는 인터넷을 거치지 않고 AWS 서비스에 접근하는 방법입니다. Gateway Endpoint는 S3와 DynamoDB 전용으로 라우팅 테이블 방식이며 추가 비용이 없습니다. Interface Endpoint는 ENI를 생성하며 시간당 요금이 발생합니다. 인터넷 차단 환경에서 S3에 접근해야 할 때는 Gateway VPC Endpoint를 사용합니다.
CloudHSM은 AWS도 접근할 수 없는 전용 하드웨어 보안 모듈을 제공합니다. M of N 쿼럼 인증으로 중요 작업에 복수 관리자의 승인을 요구할 수 있습니다. PCI DSS HSM 요구사항을 충족해야 하는 경우 CloudHSM을 선택합니다.
Auto Scaling 정책 — Target Tracking, Step, Predictive
Auto Scaling에는 세 가지 동적 정책 유형이 있습니다.
Target Tracking 정책은 특정 메트릭을 목표값으로 유지하도록 자동으로 용량을 조정합니다. CPU 사용률 70%, ALB 요청당 타겟 수 1000개처럼 목표를 설정하면 AWS가 스케일링 액션을 자동 계산합니다. 가장 간단하고 권장되는 방식입니다.
Step Scaling은 CloudWatch 알람 조건마다 다른 스케일링 단계를 정의합니다. CPU 70~80%이면 1개 추가, 80~90%이면 2개 추가, 90% 이상이면 4개 추가처럼 단계별 대응이 가능합니다. 트래픽 급증 패턴이 예측 가능한 경우 유용합니다.
Predictive Scaling은 ML을 사용해 과거 트래픽 패턴을 학습하고 미래 수요를 예측해서 사전에 용량을 확장합니다. 매일 점심 시간에 트래픽이 급증하는 패턴처럼 규칙적인 부하 변화에 효과적입니다.
DynamoDB의 Scheduled Action도 비슷한 개념입니다. 특정 시간에 사전 용량을 확장하여 반응적 스케일링의 지연을 우회합니다.
느슨한 결합 — SQS, SNS, Step Functions
느슨한 결합(Loose Coupling)은 시스템 컴포넌트 간 직접 의존성을 줄여서 한 컴포넌트의 장애가 전체로 전파되지 않도록 하는 아키텍처 패턴입니다.
SQS Standard Queue는 최소 1회 전달을 보장하며 처리 순서는 보장되지 않습니다. SQS FIFO Queue는 순서 보장과 정확히 1회 처리를 제공하지만 기본 처리량이 300 TPS로 제한됩니다. 높은 처리량 모드를 활성화하면 최대 70,000 TPS까지 가능합니다.
SNS Fan-out 패턴은 단일 이벤트를 여러 SQS 큐에 동시에 전달합니다. S3 이벤트를 Lambda로 직접 전달하면 동시성 한도 초과 시 이벤트가 유실될 수 있습니다. SNS → 여러 SQS → Lambda 구조로 변경하면 SQS가 버퍼 역할을 하여 처리 불가 메시지를 보존합니다. SQS의 DLQ(Dead Letter Queue)는 처리 실패 메시지를 별도로 보관해서 재처리를 가능하게 합니다.
ASG Lifecycle Hook은 인스턴스 종료 전 진행 중인 작업을 완료할 시간을 확보합니다. Terminating:Wait 상태에서 애플리케이션이 완료 신호를 보내거나 타임아웃이 만료되면 종료가 진행됩니다. 60초가 걸리는 금융 거래를 처리하는 인스턴스라면 heartbeat_timeout을 120초로 설정합니다.
Multi-AZ 고가용성 패턴
RDS Multi-AZ는 동기 복제로 RPO가 거의 0이며 자동 장애 조치가 30초 이내에 완료됩니다. RDS Read Replica는 비동기 복제로 읽기 쿼리 분산이 목적입니다. 두 개념의 목적이 다릅니다. Multi-AZ는 가용성, Read Replica는 성능이 목적입니다.
Aurora Multi-AZ는 3 AZ에 걸쳐 6개의 복사본을 유지하는 스토리지 구조로, Replica가 클러스터 볼륨을 공유하기 때문에 수십 초 내에 Primary로 자동 승격됩니다.
ElastiCache Redis는 Multi-AZ 복제 그룹으로 가용성을 높이고, 분산 세션 저장소로 인스턴스 간 세션을 공유합니다. Sticky Session(세션 고착)을 제거하면 Auto Scaling이 자유롭게 인스턴스를 추가하거나 종료할 수 있습니다.
Route 53 Failover + Calculated Health Check 조합은 자동 DNS 페일오버의 핵심입니다. 세컨더리 레코드에도 Health Check를 설정하지 않으면 항상 Healthy로 간주되어 장애 감지가 불가능합니다.
시험 핵심 정리
"WAF를 EC2에 직접 연결 가능한가" -- 불가능, ALB/CloudFront/API Gateway에만 연결
"특정 국가 트래픽 차단" -- WAF Geo Match (Route 53 Geolocation은 라우팅이지 차단 아님)
"HTTP Flood 자동 차단" -- WAF Rate-based Rules
"Shield Advanced 추가 기능" -- DRT 지원 + 비용 보호 + 상시 탐지 (Standard 대비)
"NLB 소스 IP 보존" -- 클라이언트 IP 그대로 전달 (ALB는 X-Forwarded-For 필요)
"NLB에 보안 그룹 직접 적용" -- 불가능, NLB 뒤 EC2 보안 그룹 활용
"인터넷 차단 환경에서 S3 접근" -- S3 Gateway VPC Endpoint (추가 비용 없음)
"AWS도 접근 불가한 HSM + 쿼럼 인증" -- CloudHSM + M of N 인증
"가장 간단한 Auto Scaling 정책" -- Target Tracking
"사전 확장으로 반응 지연 우회" -- Predictive Scaling / Scheduled Action
"SNS 직접 Lambda 호출 시 동시성 초과 이벤트 유실 방지" -- SNS → SQS 버퍼 → Lambda
"SQS FIFO 기본 처리량" -- 300 TPS (높은 처리량 모드로 70,000 TPS 가능)
"RDS Multi-AZ 목적" -- 가용성 (Read Replica는 성능/읽기 확장)