정답 · 해설

해설

【핵심 용어】 ▸ 종단 간(end-to-end) 전송 암호화 — 뷰어→CloudFront→오리진(ALB/EC2) 전 구간 HTTPS ▸ ACM 퍼블릭 인증서 — CloudFront·ALB 등 통합 서비스에만 연결, EC2에 직접 설치 불가 ▸ CloudFront Viewer Protocol Policy — HTTP를 HTTPS로 리디렉션 【정답 포인트】 ▸ "뷰어 구간 HTTPS 강제" → CloudFront가 HTTP를 HTTPS로 리디렉션 (C) ▸ "CloudFront→ALB 구간" → ALB 리스너를 퍼블릭 ACM 인증서로 HTTPS 리스닝, CloudFront가 HTTPS 리스너로 연결 (E) ▸ "ALB→EC2 구간" → 별도 TLS 인증서 생성해 웹 서버 HTTPS 전용 구성, ALB가 타깃 그룹에 HTTPS 연결 (F) 【오답 체크】 (A) 오리진 연결을 "선택적(optional) HTTPS"로 두면 종단 간 강제가 안 됨(HTTPS 필수여야 함). (B) DynamoDB 연결 문구가 모순(HTTPS→HTTPS)이며 CloudFront 경유 웹 트래픽 종단 암호화와 직접 무관. (D) 퍼블릭 ACM 인증서는 EC2 웹 서버에 직접 설치할 수 없어 백엔드 구간에는 자체 인증서(F)가 필요. 【시험 포인트】 종단 간 전송 암호화 = 뷰어 HTTPS 리디렉트 + ALB(ACM HTTPS) + EC2는 별도 인증서로 백엔드 HTTPS.

해설

【핵심 용어】 ▸ CloudTrail 이벤트 기록(Event History) — trail 없이도 최근 90일 관리 이벤트 조회 가능(항상 활성) ▸ STS 임시 액세스 키 — IAM 역할에 속함, 세션 폐기로 무효화 ▸ 역할 활성 세션 폐기(Revoke Sessions) — 발급된 임시 자격 증명 즉시 무효화 【정답 포인트】 ▸ "탈취 키 사용 중지 + 지금까지 활동 파악" → CloudTrail 이벤트 기록에서 액세스 키로 검색(새 trail 불필요) ▸ 연관 이벤트로 키가 속한 IAM 역할 식별 → 해당 역할의 활성 세션 폐기 (D) 【오답 체크】 (A) 세션 폐기 대상을 IAM 사용자로 봤으나 STS 키는 역할에 속하므로 부정확. (B) STS 키는 사용자가 아닌 역할 소유이고, 이벤트 기록이 이미 있어 새 trail 생성 불필요. (C) 역할 삭제는 과도하며(다른 워크로드 영향), 이미 이벤트 기록으로 조회 가능해 새 trail도 불필요. 【시험 포인트】 STS 키 탈취 대응 = CloudTrail 이벤트 기록으로 역할 식별 + 역할 활성 세션 폐기(새 trail 불필요).

해설

【핵심 용어】 ▸ Amazon EBS 암호화 — KMS 기반 볼륨 암호화, 주로 저장 데이터(at rest) 대상 ▸ 전송 중 암호화(in transit) — TLS 기반, 인증서로 보호 ▸ AWS Certificate Manager(ACM) — TLS 인증서 저장·관리 【정답 포인트】 ▸ 요구는 EC2와 EBS 간 "전송 중" 데이터 암호화 → TLS 기반 암호화 구성 ▸ 보기 중 TLS/인증서(ACM) 기반 전송 암호화를 명시한 항목이 해당 (D) 【오답 체크】 (A) EC2 네트워크 인터페이스 속성에 "암호화 활성화" 옵션은 존재하지 않음. (B) EBS 볼륨 KMS 암호화는 저장 데이터(at rest) 대상으로 요구된 전송 중 암호화와 초점이 다름. (C) EBS 볼륨 구성에 "TLS 암호화" 속성 옵션은 존재하지 않음. 【시험 포인트】 "in transit(전송 중)" 키워드 = TLS 기반 암호화(인증서). at rest는 KMS 볼륨 암호화.

해설

【핵심 용어】 ▸ DynamoDB Encryption Client — 테이블 항목의 클라이언트 측 암호화 + 항목 서명으로 무결성/변조 탐지 ▸ 종단 간 데이터 보호 — 클라이언트에서 암호화해 저장까지 보호 ▸ 항목 서명(Sign items) — 무단 데이터 변경 탐지 제공 【정답 포인트】 ▸ "종단 간 보호 + 무단 변경 탐지" → DynamoDB Encryption Client 사용 ▸ 클라이언트 측 암호화로 항목 보호 + 항목 서명으로 변조 탐지 (C) 【오답 체크】 (A) KMS로 저장 암호화만으로는 클라이언트 종단 보호·항목 변조 탐지를 제공하지 않음. (B) ACM 프라이빗 CA는 전송 암호화용으로 항목 무결성·변조 탐지 요건과 무관. (D) AWS Encryption SDK는 범용 암호화 라이브러리로 DynamoDB 항목 서명·검증 통합을 제공하지 않아 요건 충족에 부적합. 【시험 포인트】 DynamoDB 항목의 종단 암호화 + 변조 탐지 = DynamoDB Encryption Client(클라이언트 암호화 + 서명).

해설

【핵심 용어】 ▸ IAM Access Analyzer(정책 검증) — IAM 정책이 의도한 권한을 부여하는지 검사·진단 ▸ 역할 assume 검증 — 애플리케이션이 역할을 올바르게 수임하는지 확인 ▸ 보안 저하 없는 문제 해결 — 버킷 개방/공개 차단 해제 없이 정책 진단 【정답 포인트】 ▸ "AccessDenied + 보안 저하 없이 해결" → IAM Access Analyzer로 IAM 정책 권한 점검 ▸ 애플리케이션이 역할을 올바르게 수임하는지 검증해 원인 규명 (C) 【오답 체크】 (A) 버킷 리소스 정책으로 역할에 읽기 허용은 접근 범위를 넓혀 보안 저하 가능. (B) 다른 리전 재배포는 AccessDenied 원인과 무관한 무의미한 조치. (D) Block Public Access 비활성화는 버킷 보안을 저하시키므로 요건 위배. 【시험 포인트】 권한 오류를 보안 저하 없이 진단 = IAM Access Analyzer로 정책 검증 + 역할 수임 확인.

해설

【핵심 용어】 ▸ IAM 자격 증명 보고서 — 최대 4시간에 1회 생성, 그 사이 요청은 캐시된 이전 보고서 반환 ▸ Config IAM 규칙(access-key-rotated 등) — 자격 증명 보고서 데이터를 기반으로 평가 ▸ 캐시된 보고서 — 방금 키를 로테이션해도 4시간 내 재생성 시 옛 데이터로 비준수 표시 【정답 포인트】 ▸ "키 로테이션 후 GenerateCredentialReport 호출했는데 모두 비준수" → 보고서가 최근 4시간 내 이미 생성됨 ▸ 캐시된 이전(로테이션 전) 보고서가 반환되어 규칙이 옛 데이터로 비준수 판정 (A) 【오답 체크】 (B) 권한이 없으면 보고서 생성 자체가 실패하지 API가 비준수 결과를 만들지 않음. (C) GetCredentialReport 권한 부재도 조회 실패로 이어질 뿐 "모두 비준수" 원인이 아님. (D) MaximumExecutionFrequency는 평가 주기일 뿐 방금 로테이션 결과가 옛 보고서로 나오는 원인이 아님. 【시험 포인트】 IAM 자격 증명 보고서는 4시간 캐시 → 방금 생성 시 옛 데이터 반환으로 비준수 오탐.

해설

【핵심 용어】 ▸ AWS Organizations — 다중 계정 중앙 관리, 조직 ID로 소속 계정 식별 ▸ aws:PrincipalOrgID 조건 키 — 조직 소속 계정의 주체만 허용, 외부 접근 차단 ▸ S3 리소스 정책 — 버킷 정책에 PrincipalOrgID 조건으로 조직 외 접근 방지 【정답 포인트】 ▸ "중앙 계정 관리 + 회사 소유 계정 외 S3 접근 차단 + 오버헤드 최소" → Organizations 조직 구성 ▸ 계정을 조직에 초대, 버킷 정책에 aws:PrincipalOrgID 조건 키로 조직 내부만 허용 (C) 【오답 체크】 (A) CloudTrail 모니터링은 사후 탐지(detective)일 뿐 외부 접근을 사전 차단하지 못함. (B) 계정 목록을 수동 입력하는 버킷 정책은 계정 증가 시 유지보수 오버헤드가 큼. (D) "Control Tower 자동 보호로 외부 사용자 거부"라는 기능은 존재하지 않는 표현. 【시험 포인트】 조직 소속 계정만 S3 허용(최소 오버헤드) = 버킷 정책 aws:PrincipalOrgID 조건 키.

해설

【핵심 용어】 ▸ KMS Grant 최종 일관성(Eventual Consistency) — CreateGrant 직후 즉시 반영 안 될 수 있어 AccessDenied 발생 ▸ Grant Token — CreateGrant 응답에 반환, 일관성 지연을 우회해 즉시 권한 사용 가능 ▸ 즉시 암호화 필요 — grant 생성 직후 grant token으로 encrypt 호출 【정답 포인트】 ▸ "grant 생성 직후 첫 encrypt 시 간헐적 AccessDenied" → 최종 일관성 지연이 원인 ▸ CreateGrant 응답의 grant token을 사용자에게 전달, 사용자가 encrypt 호출 시 그 grant token 사용 (D): 즉시 권한 적용 【오답 체크】 (A) 2분마다 재시도는 미봉책으로 지연·사용자 경험 저하, 근본 해결(grant token)이 있음. (B) 무작위 grant token을 소비해 CreateGrant에 전달한다는 것은 grant token 사용 방식이 아님. (C) grant 이름을 grant token으로 사용한다는 것은 잘못된 개념(이름≠grant token). 【시험 포인트】 CreateGrant 직후 즉시 사용 = 응답의 grant token을 API 호출에 전달(최종 일관성 우회).

해설

【핵심 용어】 ▸ GuardDuty 관리자-멤버(master-member) 구성 — 위협 목록을 관리자 계정에서 설정해 전체 적용 ▸ 위협 인텔리전스 목록(Threat List) — S3 객체 참조로 관리자 계정에 추가 ▸ 다중 계정 효율 — 개별 계정마다 목록 추가 대신 관리자 계정 중앙 관리 【정답 포인트】 ▸ "모든 회사 계정에서 위협 목록 효율적 사용" → GuardDuty를 관리자-멤버 구성으로 ▸ 위협 목록을 S3 객체 참조로 관리자 계정에 추가하면 멤버 전체에 적용 (B) 【오답 체크】 (A) 버킷 정책 개방 + Lambda로 계정마다 추가는 복잡하고 비효율적. (C) Organizations 소속만으로 GuardDuty 위협 목록이 자동 공유되지 않음(관리자 계정 설정 필요). (D) 위협 목록을 공개(public)로 두는 것은 보안 위험이며 잘못된 접근. 【시험 포인트】 GuardDuty 위협 목록 다중 계정 적용 = 관리자(master) 계정에 목록 추가(멤버 자동 적용).

해설

【핵심 용어】 ▸ GuardDuty 신뢰 IP 목록(Trusted IP List) — 목록의 IP에 대해 findings 생성 억제 ▸ 목록 파일 형식 — 일반 텍스트(plaintext), 한 줄당 IP/CIDR ▸ S3 업로드 참조 — 목록 파일을 S3에 두고 GuardDuty가 해당 파일 참조 【정답 포인트】 ▸ "신뢰 IP에 대해 findings 미생성" → 신뢰 IP를 담은 일반 텍스트(plaintext) 구성 파일 생성 (A) ▸ 파일을 S3에 업로드하고 GuardDuty에 그 파일을 가리키는 신뢰 IP 목록 추가 (D) 【오답 체크】 (B) 신뢰 IP 목록 파일 형식은 JSON이 아닌 일반 텍스트(한 줄당 IP/CIDR). (C) 구성 파일을 GuardDuty에 직접 업로드하는 방식은 지원되지 않음(S3 참조 필요). (E) 목록 데이터를 콘솔에 직접 복사·붙여넣는 방식은 지원 절차가 아님. 【시험 포인트】 신뢰 IP findings 억제 = plaintext 목록 파일을 S3 업로드 후 GuardDuty 신뢰 IP 목록으로 참조.

해설

【핵심 용어】 ▸ CloudFront + OAI(Origin Access Identity) — S3 버킷을 퍼블릭 개방 없이 CloudFront만 접근 허용 ▸ S3 계정 수준 퍼블릭 액세스 차단 — 현재·미래 모든 버킷의 퍼블릭 접근을 일괄 금지 ▸ DNS 전환 — 웹사이트 도메인을 CloudFront로 지정해 무중단 전환 【정답 포인트】 ▸ "현재·미래 모든 퍼블릭 버킷 금지 + 웹사이트 무중단" → OAI로 S3 오리진 구성 ▸ DNS를 CloudFront로 전환 후 계정 수준 퍼블릭 액세스 차단 활성화 (A): 계정 수준이 "모든 현재·미래 버킷" 요건 충족 【오답 체크】 (B) 버킷별 차단은 "현재·미래 모든 버킷 일괄 금지" 요건에 부합하지 않음(계정 수준이 적합). (C) DNS 전환 없이 계정 수준 차단만 하면 아직 CloudFront로 안 옮긴 웹사이트가 중단됨. (D) 버킷 정책만으로 PoP 제한하고 OAI를 안 쓰는 구성은 관리 복잡·부정확, DNS/차단 순서상 A가 정석. 【시험 포인트】 모든 현재·미래 버킷 퍼블릭 금지 = 계정 수준 Block Public Access. 무중단 = OAI + DNS 전환 선행.

해설

【핵심 용어】 ▸ GuardDuty ThreatPurpose — finding 위협 목적 분류, Impact는 시스템·데이터 조작/파괴 시도 ▸ Impact 카테고리 — 공격자가 시스템·데이터를 조작·중단·파괴하려는 활동 패턴 ▸ 다른 카테고리 — Backdoor(C&C), Behavior(기준선 이탈), Discovery(정찰) 등과 구분 【정답 포인트】 ▸ "ThreatPurpose = Impact" → 공격자가 회사 시스템·데이터를 조작/중단/파괴하려는 활동·패턴 탐지 (C) 【오답 체크】 (A) C&C 서버와 통신해 지시를 받는 것은 Backdoor(백도어) 목적에 해당. (B) 기준선(baseline)과 다른 활동 패턴 탐지는 Behavior 목적에 해당. (D) 시스템·내부 네트워크 지식 확장 시도는 Discovery(정찰) 목적에 해당. 【시험 포인트】 GuardDuty Impact = 시스템·데이터 조작/중단/파괴 시도. Backdoor=C&C, Discovery=정찰.

해설

【핵심 용어】 ▸ GuardDuty DNS 로그 검사 — AWS 제공 DNS 리졸버(Route 53 Resolver)를 통한 쿼리만 검사 가능 ▸ AWS DNS 리졸버 — EC2가 기본 VPC 리졸버 사용 시 DNS 로그가 GuardDuty에 노출 ▸ 서드파티 리졸버 — 사용 시 GuardDuty가 DNS 쿼리를 관찰 불가 【정답 포인트】 ▸ "EC2 관련 DNS 로그를 검사" → 모든 EC2가 AWS DNS 리졸버를 사용하도록 구성 ▸ AWS 리졸버 경유 쿼리만 GuardDuty가 로깅·검사 가능 (C) 【오답 체크】 (A) IPv6 호스트명 사용은 DNS 로그 검사 가능 여부와 무관. (B) 외부 DNS 리졸버를 내부처럼 구성한다는 것은 부정확하고 GuardDuty 검사 조건이 아님. (D) 서드파티 DNS 리졸버 사용 시 GuardDuty가 DNS 쿼리를 관찰할 수 없어 요건 미충족. 【시험 포인트】 GuardDuty DNS 로그 검사 = EC2가 AWS(Route 53) DNS 리졸버를 사용해야 함.

해설

【핵심 용어】 ▸ 크로스 계정 스냅샷 복사 — 별도 계정에 암호화 EBS 스냅샷을 복사해 원 계정 침해로부터 격리 ▸ KMS 키 공유 — 새 계정이 암호화 키에 접근해 스냅샷 복호화·복원 가능 ▸ 계정 침해 대비 — 백업을 별도 계정 경계로 분리해 삭제로부터 보호 【정답 포인트】 ▸ "계정 침해로 EBS 스냅샷 삭제 시에도 복구" → 제한 권한의 새 AWS 계정 생성 ▸ 새 계정이 암호화 KMS 키에 접근하도록 허용하고 암호화 스냅샷을 주기적으로 새 계정에 복사 (C) 【오답 체크】 (A) EBS 스냅샷을 S3로 옮기는 lifecycle 정책은 존재하지 않음(EBS 스냅샷은 S3 객체가 아님). (B) Systems Manager로 로컬 디스크를 S3 백업하는 방식은 스냅샷 삭제 대비 격리 요건과 초점이 다름. (D) AWS Backup으로 스냅샷을 S3에 복사한다는 표현은 부정확하고 계정 침해 격리를 보장하지 않음. 【시험 포인트】 계정 침해 대비 백업 격리 = 별도 계정에 암호화 스냅샷 크로스 계정 복사 + KMS 키 접근 공유.

해설

【핵심 용어】 ▸ AWS PrivateLink 엔드포인트 서비스 — 공급자(SaaS) VPC의 NLB 뒤 서비스를 소비자에게 프라이빗 노출 ▸ Network Load Balancer — 엔드포인트 서비스 프런트, TLS 종료·부하 분산 ▸ 인터페이스 엔드포인트 — 소비자(고객) VPC에 생성해 SaaS 서비스에 프라이빗 접근, 확장성·보안 우수 【정답 포인트】 ▸ "고객 EC2 클라이언트↔SaaS 앱 통신 + 확장성·보안 극대화" → SaaS 계정 VPC에 NLB 생성(TLS 종료·LB, EC2 타깃) (A) ▸ SaaS 계정 VPC에 PrivateLink 엔드포인트 서비스 생성, 고객 VPC에 인터페이스 엔드포인트 생성 (D) 【오답 체크】 (B) NLB를 고객 계정 VPC에 두는 것은 SaaS 앱 백엔드 위치와 맞지 않음(공급자 측에 있어야 함). (C) 엔드포인트 서비스를 고객 VPC에, 인터페이스 엔드포인트를 SaaS VPC에 두는 것은 방향이 반대. (E) VPC 피어링은 다수 고객 계정과 확장성·격리 측면에서 PrivateLink 대비 부적합. 【시험 포인트】 SaaS 다중 고객 프라이빗 접근(확장·보안) = 공급자 VPC의 NLB + PrivateLink 엔드포인트 서비스, 고객 VPC 인터페이스 엔드포인트.

해설

【핵심 용어】 ▸ AWS Secrets Manager — 비밀 저장 + 자동 로테이션 지원, 애플리케이션이 런타임 조회 ▸ IAM 역할(ECS 태스크 역할) — 태스크(컨테이너)별로 비밀 접근 권한 부여 ▸ 자동 로테이션 — 관리 오버헤드 최소로 주기적 자격 증명 교체 【정답 포인트】 ▸ "DB 자격 증명 안전 저장 + 주기적 로테이션 + 앱만 접근 + 오버헤드 최소" → Secrets Manager 사용 ▸ ECS 태스크용 IAM 역할로 특정 컨테이너만 비밀 접근 제한 (D) 【오답 체크】 (A) Parameter Store는 기본적으로 자동 로테이션이 없어 "주기적 로테이션" 요건에 불리, IAM 프로파일 표현도 부정확. (B) 인라인 정책은 관리·재사용성이 떨어지고, 태스크 접근 제어에는 태스크 역할이 표준. (C) Parameter Store는 자동 로테이션 기본 미지원으로 요건 충족에 불리(Secrets Manager가 적합). 【시험 포인트】 DB 자격 증명 자동 로테이션 + 최소 오버헤드 = Secrets Manager + ECS 태스크 IAM 역할.

해설

【핵심 용어】 ▸ IAM SAML 페더레이션 — 외부 IdP와 신뢰 구성, 페더레이션 사용자가 IAM 역할 수임 ▸ IAM 역할 + 정책 — 위임 운영 지원에 필요한 권한 부여 ▸ 오버헤드 최소 — 개별 사용자·자격 증명 배포 대신 IdP 페더레이션 【정답 포인트】 ▸ "외부 업체에 운영 지원 위임 + 오버헤드 최소" → IAM을 외부 업체 IdP와 페더레이션 ▸ 필요한 권한의 정책을 붙인 IAM 역할 생성 (B) 【오답 체크】 (A) Cognito 자격 증명 풀은 앱 사용자 인증용으로 운영 지원 위임 시나리오에 부적합. (C) IAM 그룹 + 장기 자격 증명 공유는 보안 위험이 크고 관리 부담 증가. (D) AWS SSO는 IAM 그룹에 직접 매핑하지 않으며(권한 세트 사용) 해당 구성 표현이 부정확. 【시험 포인트】 외부 업체 운영 지원 위임(오버헤드 최소) = IAM SAML 페더레이션 + IAM 역할.

해설

【핵심 용어】 ▸ AWS Secrets Manager — API 키 등 비밀을 KMS로 암호화 저장, 애플리케이션 런타임 조회 ▸ 중앙 보안 계정 — 비밀을 소스 코드와 분리해 보안 팀 관리 계정에 보관 ▸ 교차 계정 접근 — Lambda 역할에 Secrets Manager 조회 권한 부여 【정답 포인트】 ▸ "API 키를 암호화·소스와 분리·보안 계정 중앙 보관" → 보안 계정에 Secrets Manager 비밀 생성(KMS 암호화) ▸ Lambda 사용 IAM 역할에 접근 허용해 런타임에 키 조회·API 호출 (C) 【오답 체크】 (A) 보안 계정에 CodeCommit 리포를 만들어 코드 이전은 API 키를 코드와 분리하지 못함(여전히 코드와 동거). (B) S3 + SSE-S3 + presigned URL 방식은 복잡하고 회사 통제·중앙 관리 측면에서 Secrets Manager 대비 열위. (D) Lambda 환경 변수 저장은 API 키를 함수 구성에 두는 것으로 중앙 보안 계정 분리 요건 위배. 【시험 포인트】 API 키 중앙 보안 계정 분리·암호화 저장 = Secrets Manager(KMS) + Lambda 역할 교차 계정 접근.

해설

【핵심 용어】 ▸ EventBridge(CloudWatch Events) 규칙 — 특정 KMS API 호출을 매칭해 대응 트리거 ▸ ScheduleKeyDeletion — CMK 삭제 예약(대기 기간 후 삭제), 삭제 전 알림 기회 제공 ▸ DisableKey — 키 비활성화, 삭제 전 조치로 함께 모니터링 【정답 포인트】 ▸ "CMK 삭제 전 알림" → EventBridge 규칙으로 DisableKey·ScheduleKeyDeletion API 호출 감지 ▸ Lambda로 SNS 알림 발송, Lambda를 규칙 타깃으로 지정 (C): 삭제 예약 시점에 사전 통지 【오답 체크】 (A) KMS가 삭제 시각 지정 시 CloudWatch 경보를 자동 생성한다는 기능은 존재하지 않음. (B) DeleteAlias는 별칭 삭제 이벤트로 키 삭제 예약과 무관. (D) "SNS 정책이 API 호출을 감지"한다는 것은 부정확(SNS는 알림 전달, 감지는 EventBridge 역할), RevokeGrant도 삭제 알림과 무관. 【시험 포인트】 CMK 삭제 사전 알림 = EventBridge로 ScheduleKeyDeletion(및 DisableKey) 감지 → Lambda → SNS.

해설

【핵심 용어】 ▸ CloudFront 지리적 제한(Geo Restriction) — 특정 국가 차단 기능 내장, 추가 비용 없이 사용 ▸ AWS WAF geo match — 국가 기반 차단 가능하나 WAF 요금 발생 ▸ 비용 효율 — 내장 기능(지리 제한)이 WAF 대비 저렴 【정답 포인트】 ▸ "특정 국가 인바운드 차단 + 가장 비용 효율적" → CloudFront 지리적 제한 기능으로 해당 국가 거부 (C) ▸ 별도 WAF 비용 없이 배포에 내장된 기능으로 처리 【오답 체크】 (A) WAF IP 매치로 국가 IP 범위 거부는 IP 목록 유지가 어렵고 WAF 비용 발생. (B) WAF geo match는 기능상 가능하지만 WAF 요금이 들어 비용 효율에서 열위. (D) "지리 위치 헤더로 거부"는 CloudFront의 표준 국가 차단 방식이 아님. 【시험 포인트】 국가 단위 차단 최저 비용 = CloudFront 내장 Geo Restriction(WAF는 비용 발생).