AWS SAP-C02 치트시트

AWS SAP-C02 합격 후기를 준비하며 정리한 요약본이다.

문제 푸는 30초 루틴

1. 마지막 문장부터 읽는다. “가장 비용 효율적인”, “운영 오버헤드 최소”, “최소한의 개발”, “가장 빠른” 키워드 확인

2. 제약 키워드를 확인.

3. 고르기 전에 한 번 고민. 더 단순한 관리형 선택지가 있나?

0. 시험장 들어가기 직전 30초 암기

Cost Explorer의 “14”는 개월이 아니라 일. 시간 단위와 리소스 단위 데이터가 최근 14일치만 남는 것이 실제 출제 포인트고, 이력 기간 12~13개월(설정 시 38개월)은 거의 정답을 가르지 않는다.

1. IAM & 권한 평가

권한 평가 순서

1. 명시적 Deny가 하나라도 있으면 즉시 거부 (모든 것을 이김)
2. SCP나 RCP에서 Allow 여부
3. Resource-based Policy Allow 여부
4. Identity-based Policy Allow 여부
5. Permissions Boundary 범위 안인지 여부
6. Session Policy 범위 안인지 여부

크로스 계정은 양쪽 모두 Allow 필요. 단, 리소스 기반 정책으로 직접 Allow하면 호출 계정의 Identity 정책만으로 충분한 경우도 있음(S3 등).

Identity 종류

• Root, IAM User, IAM Role(로그인과 영구 키 없음)
• IAM Group은 Principal이 아님. 정책의 Principal에 쓸 수 없음
• Permission Boundary는 User와 Role의 상한선, SCP는 OU와 계정의 상한선. 둘 다 권한을 주지 않고 깎기만 함

크로스 계정 IAM Role은 문서 2장 세트

리소스 기반 정책으로 직접 크로스 계정이 가능한 서비스는 S3, KMS, SQS, SNS, Lambda, Secrets Manager, ECR, API Gateway, EventBridge, Glue, OpenSearch.

Secrets Manager도 크로스 계정 가능. 단 반드시 고객 관리형 KMS 키(CMK)로 암호화해야 하고 aws/secretsmanager 기본 키로는 불가.

Confused Deputy와 sts:ExternalId

• B가 A의 Role ARN을 알아내 SaaS에 넣으면 A의 데이터를 읽게 됨
• SaaS가 고객별 랜덤 ExternalId 발급, A는 Trust Policy에 StringEquals: sts:ExternalId 조건 추가
• SaaS만 그 값을 알기 때문에 방어됨

Access Analyzer와 Access Advisor

SAML 페더레이션

• IdP가 SAML Assertion(신원 보증)을 발급하고 sts:AssumeRoleWithSAML 호출
• 필수 3요소는 RoleArn, PrincipalArn(saml-provider), SAMLAssertion
• Assertion 속성은 .../SAML/Attributes/Role(role과 provider 한 쌍)과 RoleSessionName

2. Organizations / 거버넌스

• 기능 세트는 통합 결제만 또는 모든 기능 중 하나
• 서비스 활성화 여부는 SCP로만 관리
• 태그 정책은 Management 계정에서만 생성, 실제 강제는 SCP로

태그 강제 3종 세트

Control Tower 가드레일

SCP는 Control Tower가 아니라 OU에 적용됨.

Budgets Actions 한계

IAM 정책 적용, SCP 적용, EC2와 RDS 인스턴스 중지까지만. 예산 초과 시 전체 서비스 종료는 불가능하고 오답 선택지로 자주 등장.

3. 네트워킹

Direct Connect VIF 매칭표

• 물리 회선 1개 위에 VLAN 태그로 여러 VIF, 각 VIF마다 BGP 세션
• VGW는 DX나 Site-to-Site VPN의 종단점이고 VPC 1개에만 붙음
• VPC끼리 연결까지 필요하면 TGW(리전 서비스), 리전 간은 TGW Peering

VPC Endpoint와 PrivateLink

PrivateLink의 특징.

• 제공자는 Endpoint Service(NLB 앞단), 소비자는 Interface Endpoint(ENI)
• 소스 IP 보존 안 됨. 필요하면 PROXY Protocol
• CIDR 겹쳐도 됨. 피어링이나 TGW 대비 최대 장점
• 기본 단방향. 양방향은 양쪽에 Endpoint를 각각 구성

클라이언트 EC2 → Interface Endpoint(ENI) → [PrivateLink 백본] → Endpoint Service → NLB → 서비스 EC2

연결 방식 고르기

CIDR 중복 + 단일 서비스만 노출 → PrivateLink
다수 VPC/계정 전면 연결        → Transit Gateway (+ RAM 공유)
VPC 2개만                    → 피어링 (이미 있으면 TGW 신설은 낭비)
온프레미스 → 여러 리전/VPC     → Direct Connect Gateway
온프레미스 → VPC 하나          → VGW
온프레미스 → AWS 서비스        → 프라이빗 VIF + 인터페이스 엔드포인트

Route 53

• Inbound Resolver는 온프렘에서 AWS 방향으로 가는 질의를 받음
• Outbound Resolver는 AWS에서 온프렘 방향으로 나가는 질의를 보냄
• Private Hosted Zone은 조회해야 하는 모든 VPC에 연결(Association) 필요. TGW나 피어링만으로는 다른 VPC의 PHZ 이름 해석 불가
• Health Check와 Failover 라우팅이 DR 자동 전환 조합

고정 IP와 엣지 가속

고정 IP 허용목록 필요         → NLB + EIP (AZ별)
글로벌 애니캐스트 IP 2개       → Global Accelerator
캐싱, 정적 콘텐츠             → CloudFront
비표준 HTTP 메서드, TCP/UDP   → Global Accelerator (CloudFront는 비표준 메서드 미지원)
업로드 가속                  → S3 Transfer Acceleration (다운로드는 무관)
기존 IP 대역을 그대로 가져옴    → BYOIP

기타

• EIP를 붙일 수 있는 대상은 EC2(ENI), NLB, NAT Gateway, Transfer Family, Redshift, Elastic Beanstalk, Site-to-Site VPN
• Global Accelerator 엔드포인트는 ALB, NLB, EC2, EIP. CloudFront 배포는 지정 불가
• Security Group은 인바운드와 아웃바운드를 둘 다 설정하고 Stateful. NACL은 Stateless라 아웃바운드 임시 포트를 열어줘야 응답이 돌아옴
• 서브넷 CIDR는 생성 후 변경 불가

4. 컴퓨팅

EC2

• Unlimited는 크레딧을 소진한 뒤에도 버스트를 유지하고, 24시간 윈도우 안에 상환하지 못하면 초과 크레딧 과금
• ABIS(속성 기반 인스턴스 선택)는 인스턴스 타입을 나열하는 대신 vCPU 48, 메모리 832GiB, 세대 같은 속성으로 지정해 ASG와 Spot Fleet의 다양성 확보
• 종료 보호로는 ASG 스케일인을 막을 수 없음. ASG의 Terminate 프로세스를 중지해야 함

배치 그룹

Lambda

• 최대 15분, 리전당 기본 동시 실행 1,000
• DB 커넥션은 핸들러 밖에서 생성. 핸들러 안이면 호출마다 커넥션이 늘어나므로 RDS Proxy도 함께 고려
• 15분을 넘는 작업은 Lambda가 답이 아님. Fargate나 ECS로 가거나 SQS 큐 길이(ApproximateNumberOfMessagesVisible) 기반 ASG
• Canary 및 가중치 배포
  • Publish하면 버전 번호와 고유 ARN 생성
  • 고정 Alias(예: PROD)를 두고 가리키는 버전만 교체
  • --routing-config AdditionalVersionWeights={"3"=0.1}은 Alias에만 설정 가능
  • SAM은 AutoPublishAlias: live에 DeploymentPreference: Canary10Percent5Minutes와 Alarms를 함께 사용
  • CodeDeploy의 OneAtATime 등은 EC2와 온프렘용이라 Lambda 카나리아에는 부적합

EMR

상시 EMR 클러스터는 쓰지 않는 시간에도 EC2 비용이 나감. 가끔 쿼리만 한다면 S3와 Athena 조합이고 쿼리 시점에만 과금.

5. 스토리지

S3

• 암호화를 켜도 기존 객체는 암호화되지 않음
  • CLI 재복사는 내 머신이나 EC2에서 실행되고 기본 동시 요청이 10이라 대규모에는 부적합
  • S3 Batch Operations가 관리형이면서 대규모 병렬 처리라 정답은 보통 이쪽
• 버킷 정책에 s3:x-amz-server-side-encryption 조건을 걸면 원하는 암호화 방식이 아닐 때 업로드 자체를 거부 가능
• Multipart Upload는 대용량을 청크로 분할. Transfer Acceleration과 조합 가능
• S3 ACL과 버킷 정책의 차이
  • ACL은 버킷이나 개별 객체 단위이고 READ/WRITE/READ_ACP/WRITE_ACP/FULL_CONTROL을 쓰며 Deny 표현 불가
  • 버킷 정책은 버킷 단위지만 API 액션 단위로 세밀하고 Deny 가능
  • Block Public Access는 ACL이나 버킷 정책이 public이어도 무시하고 즉시 차단
• 다중 리전 액세스 포인트는 여러 리전 버킷에 글로벌 엔드포인트 1개를 두고, Global Accelerator 기반으로 지연이 가장 낮은 버킷으로 라우팅
• S3 Select는 단일 객체에 단순 SELECT, WHERE, LIMIT까지. Athena는 경로나 테이블 전체에 JOIN, GROUP BY, 윈도우 함수까지

S3와 KMS 권한

봉투 암호화는 GenerateDataKey가 평문 데이터 키와 암호화된 데이터 키를 함께 반환하고, Decrypt가 암호화된 키를 받아 평문 키를 돌려주는 구조. KMS 마스터 키는 KMS 밖으로 절대 안 나옴.

파일과 블록 스토리지

한 줄 선택 기준. SMB나 Windows, AD면 FSx for Windows. NFS나 Linux, 다중 AZ면 EFS. HPC에 S3 연동이면 FSx for Lustre. 같은 AZ에서 블록을 공유하면 EBS Multi-Attach.

FSx for Lustre와 S3 조합에서 볼 것은 두 가지.

• Lazy Loading은 접근할 때만 S3에서 로드. Preload하면 전체를 끌어와 프로비저닝 용량과 비용 증가
• 조합하는 이유는 Lustre가 서브 ms 지연에 수백 GB/s, 수백만 IOPS를 내기 때문. 계산할 때만 잠깐 붙여 쓰고 결과는 S3로

게이트웨이와 전송

지속적인 하이브리드 파일 접근은 Storage Gateway, 일회성이나 주기 전송은 DataSync.

백업

AWS Backup 지원 대상은 EC2, EBS, S3, EFS, FSx, RDS와 Aurora, DynamoDB, DocumentDB, Neptune, Redshift, Storage Gateway, EKS, CloudFormation, Timestream, SAP HANA on EC2. 미지원은 CodeCommit, Lambda, ECR, SQS와 SNS, EMR, Route 53.

콜드 스토리지는 최소 90일 과금. 7일만 보관할 백업을 콜드로 전환하면 비용이 오히려 늘어난다. 해법은 보관 기간을 늘리는 것이 아니라 콜드 전환 규칙을 없애고 웜으로 유지하는 것. AWS Backup은 볼트 SNS 알림과 EventBridge 이벤트를 기본 제공하므로 Lambda로 만들 필요 없음.

6. 데이터베이스 & 분석

Aurora 엔드포인트

연결 수가 너무 많아 터지는 것은 엔드포인트 문제가 아니라 RDS Proxy 문제. 연결이 폭증하면 Proxy를 떠올리도록 반사를 만들었다. 리더 엔드포인트 직결로는 해결 안 됨.

Aurora Global Database에서 가장 많이 틀린 오개념

• 성능은 RPO 약 1초, RTO 약 1분. 자동 X 승격이 빠름
• 상시 과금이 큼. RPO가 1시간 정도면 크로스 리전 스냅샷이나 백업 복사로 충분하고 글로벌 DB는 과잉. RPO 숫자를 먼저 보고 선택

DynamoDB

• 속성 단위 접근 제어 가능. dynamodb:Attributes와 dynamodb:Select: SPECIFIC_ATTRIBUTES 조건 사용
• 크로스 계정은 AssumeRole 패턴으로 하고 권한 정책에 위 Condition을 삽입. 다만 2023년 11월부터 리소스 기반 정책도 지원하므로 “DynamoDB에 리소스 정책 없음”으로 외우면 틀린 지식
• 용량 모드는 온디맨드와 프로비저닝(Auto Scaling 포함) 둘 다 존재. 예측 가능한 상시 부하엔 프로비저닝에 예약 용량이 저렴하고 튀는 부하엔 온디맨드
• DocumentDB에는 온디맨드 용량 모드 없음. DynamoDB에만 있음
• 항목 최대 400KB. 큰 문서는 S3와 KMS로
• 삭제나 변경 전파 알림은 DynamoDB Streams에서 Lambda를 거쳐 SNS
• MongoDB API 호환이 필요하면 DynamoDB가 아니라 DocumentDB

분석

• Athena는 S3 위 서버리스 SQL, Macie는 S3만 검사(PII 탐지)
• QuickSight
  • SPICE는 데이터 복사라 원본 변경이 자동 반영 안 됨. 주기적 새로고침 필요
  • Direct Query는 매번 원본 DB 호출
• Kinesis 샤드 한도는 쓰기 1MB/s 또는 1,000 레코드/s, 읽기 2MB/s. 처리량이 모자라면 샤드 수 재조정이나 파티션 키 분산
• 관리형으로 갈수록 정답. 자체 구축 MSK나 상시 EMR, 상시 Redshift Spectrum은 운영 오버헤드와 상시 비용 때문에 탈락하는 경우가 많다

7. 마이그레이션 & DR

디스커버리

둘 다 Migration Hub를 거쳐 S3에 저장. 프로세스나 의존성 매핑 키워드가 나오면 Agent.

• Migration Evaluator는 2~4주 모니터링 후 Quick Insights 비용과 TCO 리포트를 내고 CMDB 생성 지원
• CMDB는 구성 요소와 관계를 기록하는 ITIL 저장소

도구 고르기

TCO, 비즈니스 케이스 (CMDB 있음)    → Migration Evaluator
무엇이 도는지 모름 + 프로세스 의존성  → ADS Discovery Agent (에이전트리스는 프로세스 수집 불가)
서버 통째로 리프트앤시프트           → MGN (블록 수준 연속 복제, 디스크 데이터까지 이동)
DB에서 DB로, 다운타임 최소          → DMS + CDC
관리형 SFTP/FTP                    → Transfer Family

DR 4계층과 RPO/RTO

Elastic Disaster Recovery (DRS)

• 에이전트를 설치해 스테이징 영역으로 연속 복제, 컴퓨팅은 장애 시에만 기동. 복제는 상시, 컴퓨팅은 필요할 때만
• PIT 복구 지점은 기본 7일, 최대 365일
• Drill(훈련)은 운영 복제에 영향 없이 반복 가능. 정리 후 Failback
• 네트워크(VPC, 서브넷, SG)는 복제되지 않음. IaC로 사전 준비
• 기본이 공인 IP로 복제 트래픽 전송. DX나 VPN으로 보내려면 복제 설정에서 데이터 복제에 사설 IP 사용을 체크해야 함

8. 배포 & IaC

CloudFormation

DeletionPolicy는 Delete, Snapshot(스냅샷을 남기고 삭제), Retain(그대로 유지). UpdateReplacePolicy도 같이 기억.

반복해서 틀린 세 쌍.

• 중첩 스택에는 계정과 리전 전환 기능 없음. 다계정이나 다리전은 StackSets
• 스택 정책은 업데이트 보호용. 삭제 방지는 DeletionPolicy: Retain
• CloudFormation 조건(Conditions)은 배포 시점에만 평가됨. 런타임 동작 아님

SAM

• CloudFormation 확장 문법에 서버리스 전용 CLI를 더한 것. 배포 시 CFn으로 변환
• CodeDeploy 연동으로 Canary나 Linear 배포와 CloudWatch Alarm 기반 자동 롤백 가능

9. 비용 관리

커스텀 템플릿, 세밀한 필터링, 리소스 단위 상세를 요구하면 CUR.

팀별 비용 귀속 3단

귀속(무엇에 얼마)   → 비용 할당 태그   (활성화는 관리 계정에서)
그룹핑(팀 단위)     → Cost Categories  ← 태그만으로는 팀 집계가 안 됨
비교와 예측(12개월)  → Cost Explorer

태그만 걸고 끝내는 선택지는 함정. Cost Categories로 묶어야 팀별 청구가 나온다. AWS 생성 태그(aws:)는 사용자가 값을 지정할 수 없음.

Compute Optimizer

• 예약 내보내기 기능 없음. 온디맨드 Export만 가능
• 주기 실행하려면 EventBridge에서 Lambda를 거쳐 ExportLambdaFunctionRecommendations 같은 API를 호출하도록 구성
• CloudWatch 기본 메트릭에 메모리 사용률 없음. 메모리 기반 권장이 필요하면 CloudWatch Agent 설치
• Trusted Advisor에도 메모리 지표 없음

10. 애플리케이션 통합 & 기타

EventBridge와 SNS

• 실패 건을 보존해야 하면 SQS DLQ
• Step Functions에서 모든 오류를 잡으려면 Catch에 States.ALL을 마지막 규칙으로

API Gateway

• 엔드포인트 유형은 Regional, Edge-optimized(앞에 CloudFront 자동 배치), Private(VPC 내부)
• REST API는 AWS 통합 유형을 지원해서 Lambda 없이 DynamoDB PutItem이나 Query 직접 호출 가능. 콜드 스타트 없음
• HTTP API는 저렴하고 지연이 낮지만 AWS 서비스 통합 범위가 제한적이라 DynamoDB 직접 통합 불가
• Usage Plan (API Key 연결)
  • Throttling은 Rate(정상 속도)와 Burst(순간 허용)
  • Quota는 일, 주, 월 총 요청 수 제한
  • 과다 호출은 에러가 아니라 429 스로틀링으로 처리
• https://{id}.execute-api.{region}.amazonaws.com/prod에 Route 53 사용자 지정 도메인 연결 가능
• CORS 설정 위치는 API Gateway. 브라우저 JS에서 API GW를 호출하는 구조라면 S3 CORS는 무관

원격 접속

모든 명령을 감사하고 싶거나 인터넷과 베스천 없이 접속해야 하면 Session Manager. 대규모 일괄 작업은 SSM Run Command.

종단간 암호화

• ACM 인증서는 ALB, CloudFront, API Gateway 같은 AWS 서비스에만 부착 가능. EC2에는 직접 불가
• ACM 퍼블릭 인증서는 내보내기(export) 불가
• ALB는 TLS를 종료(terminate)하므로 뒷단이 평문. EC2에 자체 서명 인증서나 서드파티 인증서를 설치하고 HTTPS 리스너로 재암호화
• ALB는 백엔드 인증서 유효성을 검증하지 않음. Cloudflare의 Full Strict 같은 검증 없음
• SAN은 인증서 1장에 여러 도메인. 최신 브라우저는 CN을 무시하고 SAN만 검증

SES

• SMTP 인터페이스 또는 SDK와 API(SendEmail, SendTemplatedEmail) 사용
• 프로토콜은 STARTTLS(평문으로 시작한 뒤 전환)와 SMTPS(연결 즉시 TLS)
• SMTP 인증에는 SES SMTP 자격 증명 필요. IAM 액세스 키는 API용이라 부적합
• 샌드박스에서는 검증된 주소로만 발송. 해제 요청 필요
• 템플릿 저장 후 변수만 전달. 평판(Reputation) 관리와 발송 이벤트 추적 제공

RAM (Resource Access Manager)

• 리소스를 복제하지 않고 다른 계정이 그대로 사용. 공유 기능 자체는 무료
• 대상은 VPC 서브넷, Transit Gateway, Prefix List, Route 53 Resolver 규칙, Network Firewall, License Manager, ACM Private CA, Glue 카탈로그, Service Catalog 포트폴리오, Outposts, CodeBuild
• 다른 계정의 API를 호출해야 한다면 RAM이 아니라 크로스 계정 IAM 역할
• RAM으로 시크릿 공유 불가. 리소스 정책과 KMS 키 공유로 해결

그 외 단답

• IoT Greengrass는 엣지 런타임임. 오프라인에서도 로컬 ML 추론과 동작을 하고 연결되면 동기화
• IoT Core는 디바이스 등록, 인증서 발급, 정책 연결, SDK 연결과 발행, Rule 라우팅 순서. 자체 MQTT 브로커 구축 대신 관리형 MQTT에 디바이스별 X.509가 정답 축
• AppSync는 관리형 GraphQL이자 BFF. 실시간 구독(subscription)이 필요하면 정답 후보
• ElastiCache AUTH는 인증만 수행. AUTH를 켜려면 전송 중 암호화 필수
• WorkSpaces는 Linux 번들이라도 Active Directory(Directory Service) 필요. AppStream 2.0은 자체 사용자 풀 사용 가능해서 최소 개발로 인증이 필요하면 이쪽
• AD Connector는 무료가 아님. 디렉터리 크기별 시간당 과금이고 Simple AD도 동일. 무료라고 적힌 선택지는 의심한다. AD Connector가 답인 진짜 이유는 Managed AD에 양방향 신뢰를 거는 것보다 저렴하고 디렉터리를 복제하지 않기 때문
• CloudFront 커스텀 에러 페이지는 S3를 오리진으로 추가하고 Behavior를 추가한 뒤, Error Pages에서 5xx나 오리진 도달 실패 시 정적 페이지 반환
• CloudFront Functions는 viewer 요청과 응답 전용. 서브 ms에 네트워크 호출 불가한 헤더 조작용. Lambda@Edge는 origin 이벤트까지 가능하고 네트워크 호출과 SDK 호출도 가능
• S3 오리진 장애 조치는 CRR과 CloudFront 오리진 그룹. 애플리케이션이 양쪽에 쓰는 구성은 운영 오버헤드 증가
• Service Catalog는 승인된 아키텍처만 제품으로 배포. 개발 속도를 죽이지 않는 사전 예방 통제

11. 마지막 리스트

없는 기능/불가능한 조합

• Global Accelerator에 CloudFront 연결 불가
• ALB에 고정 IP 없음, NLB와 EIP 또는 GA로 대체
• CloudFront는 비표준 HTTP 메서드(LINK, UNLOCK 등) 미지원, 대안은 GA
• S3 Transfer Acceleration은 업로드 전용, 다운로드 가속 아님
• Gateway Endpoint는 S3와 DynamoDB만 지원, 온프렘에서 사용 불가
• DX Gateway로 VPC끼리 통신 불가, TGW 필요
• Private VIF로 TGW 직결 불가, Transit VIF 필요
• PHZ는 VPC마다 연결해야 해석됨, 피어링이나 TGW로는 불가
• ACM 퍼블릭 인증서 내보내기 불가
• S3 암호화 활성화는 기존 객체 암호화가 아님, Batch Operations 필요
• SSE-S3에 고객 관리형 키 지정 불가, 그것은 SSE-KMS
• EBS Multi-Attach는 동일 AZ에 io1/io2만
• HTTP API로 DynamoDB 직접 통합 불가, REST API만 가능
• Macie는 S3 전용
• DLM은 EBS 전용, 조직 백업은 AWS Backup
• AWS Backup은 CodeCommit, Lambda, ECR, SQS와 SNS, EMR 미지원
• Compute Optimizer 정기 예약 내보내기 없음, EventBridge와 API로 대체
• Compute Optimizer와 Trusted Advisor에 메모리 지표 없음, CloudWatch Agent 필요
• Budgets Action으로 모든 서비스 종료 불가
• CloudTrail에서 SNS 직접 전송 불가, EventBridge 경유
• 중첩 스택은 계정과 리전을 넘지 못함, StackSets 필요
• 스택 정책으로 삭제 방지 불가, DeletionPolicy 필요
• 종료 보호로 ASG 스케일인 차단 불가, Terminate 프로세스 중지 필요
• RAM으로 시크릿 공유 불가
• AD Connector 유료
• OpsWorks 단종
• DocumentDB에 온디맨드 용량 모드 없음, DynamoDB에는 있음
• Aurora Global Database는 Active-Active 아님, 쓰기는 1개 리전
• Aurora 리전 간 장애 조치는 수동

방향이 반대인 것들:

• SCP와 Boundary는 권한을 부여하지 않고 깎기만 함
• Config는 예방적 차단 불가, 탐지 전용
• IAM Group은 Principal이 될 수 없음
• PrivateLink는 제공자가 Endpoint Service, 소비자가 Interface Endpoint
• 온프렘에서 AWS로 가는 질의는 Inbound Resolver
• ASG는 트래픽을 보내지 않음, 보내는 것은 라우트 테이블의 타깃
• 서드파티 SaaS 접근은 ExternalId
• DRS 기본값은 공인 IP 복제, 사설 IP 옵션 체크 필요