정답 · 해설

해설

【핵심 용어】 ▸ AWS Organizations + 서비스 제어 정책(SCP) — 모든 계정에 걸쳐 대형 EC2 시작을 예방적으로 차단 ▸ 다계정 일괄 제어 — SCP로 최소 운영 부담 ▸ 계정별 IAM 정책/역할/RAM — 운영 부담·용도 불일치 【정답 포인트】 ▸ "모든 계정에서 대형 EC2 시작 방지 + 최소 운영" → Organizations의 SCP로 대형 인스턴스 시작을 거부하고 계정에 적용 【오답 체크】 (A) 사용자마다 IAM 정책 적용은 계정 전반 관리 부담이 큼. (B) RAM은 리소스 공유용으로 시작 제한 기능이 아님. (C) 계정마다 역할 생성은 운영 부담이 큼. 【시험 포인트】 "다계정 일괄 예방 제어" → Organizations SCP.

해설

【핵심 용어】 ▸ AWS Systems Manager Patch Manager — OS 인벤토리·패치 자동화(Windows/Linux 혼합) ▸ Amazon Inspector — 공통 취약점(CVE) 스캔 + 월간 보고 ▸ Security Hub/Shield/GuardDuty/Config — 통합 표시·DDoS·위협 탐지·구성(취약점 요약·패치 자동화 부적합) 【정답 포인트】 ▸ "OS 인벤토리·업데이트 자동화 + 인스턴스별 공통 취약점 월간 요약" → Patch Manager로 패치 관리, Inspector로 취약점 스캔·월간 보고 【오답 체크】 (A) Security Hub는 결과 집계용이며 취약점 출처는 Inspector, 요건상 Inspector가 적합. (C) Shield는 DDoS 방어, Config는 패치 설치 기능 없음. (D) GuardDuty는 위협 탐지, Config는 패치 설치를 수행하지 않음. 【시험 포인트】 "패치 자동화 + 취약점 요약" → Patch Manager + Amazon Inspector.

해설

【핵심 용어】 ▸ 웜 스탠바이(warm standby) — DR 리전에 ASG + ELB 사전 프로비저닝으로 다운타임 최소화 ▸ DynamoDB 글로벌 테이블 — 다중 리전 능동-능동 복제 ▸ DNS 장애 조치(Route 53 failover) — 정상 리전으로 자동 전환 【정답 포인트】 ▸ "다른 리전에서 최소 다운타임으로 가용" → DR 리전에 ASG·ELB를 미리 생성하고 DynamoDB를 글로벌 테이블로, DNS 장애 조치로 DR 리전 ELB를 가리킴 【오답 체크】 (B) CloudFormation으로 필요 시 EC2·ELB·DynamoDB를 생성하면 기동 시간만큼 다운타임 발생. (C) 필요 시 EC2·ELB 생성 역시 기동 시간으로 다운타임 발생. (D) CloudWatch 10분 평가 + Lambda로 Route 53 갱신은 DNS 장애 조치보다 전환이 느림. 【시험 포인트】 "최소 다운타임 DR" → 사전 프로비저닝(웜 스탠바이) + 글로벌 테이블 + DNS 장애 조치.

해설

【핵심 용어】 ▸ S3 Gateway Endpoint — VPC 라우팅 테이블에 경로 추가, S3/DynamoDB를 프라이빗 연결, 추가 비용 없음(무료) ▸ S3 Interface Endpoint — PrivateLink(ENI) 기반, 시간당·데이터 처리 요금 발생 ▸ NAT Gateway — 프라이빗 서브넷의 아웃바운드 인터넷 경로, 시간·데이터 요금 + 공용 인터넷 경유 ▸ AWS Storage Gateway — 온프레미스↔클라우드 스토리지 브리지, 본 시나리오와 무관 【정답 포인트】 ▸ "데이터가 공용 인터넷을 거치면 안 됨" + "가장 비용 효율적" → 무료인 S3 Gateway Endpoint가 프라이빗 경로 제공 ▸ 게이트웨이 엔드포인트는 요금이 없어 인터페이스 엔드포인트보다 저렴 【오답 체크】 (A) NAT Gateway는 트래픽이 공용 인터넷을 경유하고 시간·처리 요금까지 발생. (B) Storage Gateway는 온프레미스 하이브리드 스토리지용으로 요구사항과 무관. (C) Interface Endpoint도 프라이빗이지만 ENI 시간·데이터 요금이 있어 게이트웨이 엔드포인트보다 비쌈. 【시험 포인트】 VPC에서 S3/DynamoDB 프라이빗 접근 + 최저 비용 → Gateway Endpoint(무료). 프라이빗 필요하지만 타 서비스거나 온프레미스면 Interface Endpoint.

해설

【핵심 용어】 ▸ Network Load Balancer — L4(전송 계층, TCP/UDP) 로드밸런서, 초고성능·고가용성 ▸ Auto Scaling group(Multi-AZ) — 여러 AZ에 인스턴스 분산·자동 복구, 헬스 체크로 비정상 교체 ▸ OSI 전송 계층 → TCP/UDP → NLB가 적합(ALB는 L7 HTTP/HTTPS) 【정답 포인트】 ▸ "전송 계층(OSI L4)로 접근" → L4 로드밸런서인 NLB로 트래픽 분산(B) ▸ "단일 AZ → 고가용성 필요" + "가장 비용 효율" → Multi-AZ Auto Scaling group + 헬스 체크로 AZ 장애·인스턴스 장애 대응(D) 【오답 체크】 (A) Route 53로 모든 인스턴스에 라우팅은 헬스 기반 자동 복구·확장이 없어 진정한 HA 미흡. (C) ALB(L7)는 전송 계층 애플리케이션에 불필요, 이중 LB 구성은 비용·복잡도 증가. (E) CloudWatch 재시작 알람은 단일 인스턴스 복구일 뿐 AZ 장애·확장 대응 불가. 【시험 포인트】 전송 계층(TCP/UDP) → NLB. 고가용성 → Multi-AZ Auto Scaling group + 헬스 체크. 조합형이면 LB(분산) + ASG(복구/확장)를 함께 고른다.

해설

【핵심 용어】 ▸ Amazon API Gateway — 관리형 API 엔드포인트, Lambda 통합으로 서버리스 동적 처리 ▸ AWS Lambda — 요청당 과금 서버리스, 월 100회 미만 초저트래픽에 최적(사실상 무료 티어) ▸ Amazon SNS — 이메일 등 구독자에게 알림 발행(폼 제출 시 회사에 메일 통지) 【정답 포인트】 ▸ "월 100회 미만" + "동적 서버측 처리" + "가장 비용 효율" → 유휴 비용 없는 서버리스 API Gateway + Lambda ▸ "폼 제출 시 회사에 이메일 통지" → SNS 토픽에 메시지 발행 → 이메일 구독으로 알림 【오답 체크】 (A) ECS는 상시 컨테이너 유지 비용 발생, 초저트래픽에 과함. (C) Amplify 서버측 스크립트 + SQS는 구성 복잡, SQS는 이메일 알림 수단이 아님. (D) EC2 Windows + IIS + WorkMail은 상시 서버 비용·운영 부담이 커 초저트래픽에 최악의 비용. 【시험 포인트】 초저트래픽 + 동적 처리 + 최저 비용 → API Gateway + Lambda(유휴 0원). 이메일/알림 발행은 SNS.

해설

【핵심 용어】 ▸ AWS 계정 대체 연락처(Alternate Contacts) — 청구·운영·보안 카테고리별로 별도 연락처(배포 리스트) 지정 가능 ▸ Root user 이메일 — 계정당 고유해야 하며 최상위 권한, 중앙 관리·보안 위해 별칭/중앙 메일박스 권장 ▸ 이메일 별칭(alias) → 중앙 메일박스로 root 알림 집중 관리 【정답 포인트】 ▸ "카테고리별(청구/운영/보안)로 다른 담당자에게 알림" → 계정마다 카테고리별 대체 연락처(배포 리스트) 구성 ▸ "가장 안전하게" → root 이메일은 별칭으로 중앙 메일박스에 모아 관리, 카테고리별 알림은 팀 배포 리스트로 분리(D) 【오답 체크】 (A) 모든 계정 소유자가 접근하는 단일 메일 계정은 root 접근 통제가 약해 보안 저하. (B) 계정별 배포 리스트를 root로 쓰면 root 접근자가 늘어 보안·감사 관점 취약. (C) root 이메일을 개인 이메일로 두면 담당자 퇴사·부재 시 root 접근 리스크. 【시험 포인트】 카테고리별 알림 분리 → Alternate Contacts(billing/operations/security). root 이메일은 별칭+중앙 메일박스로 보안 강화.

해설

【핵심 용어】 ▸ Amazon SQS — 요청을 큐에 버퍼링해 비동기 디커플링, 피크 부하 흡수로 타임아웃 방지 ▸ Auto Scaling group — 큐 길이/부하에 따라 워커 EC2 수평 확장 ▸ Amazon RDS Proxy — DB 연결 풀링, 다수 커넥션으로 인한 Aurora 부하·타임아웃 완화 【정답 포인트】 ▸ "피크 시 타임아웃" + "확장 필요" + "비용 효율" → 구매 요청을 SQS 큐로 디커플링하고 큐를 읽는 Auto Scaling EC2로 처리(C) ▸ "DB 연결 폭증 완화" → RDS Proxy로 커넥션 풀링, 재시도 처리용 Auto Scaling EC2 조합(A) 【오답 체크】 (B) ElastiCache는 읽기 캐시엔 좋지만 쓰기(구매 저장) 병목·타임아웃 근본 해결이 아님. (D) Lambda 재시도만으로는 DB 커넥션 폭증·피크 처리 용량 문제를 해결 못함. (E) API Gateway 사용량 계획은 스로틀링일 뿐 처리량 확장·타임아웃 해소가 아님. 【시험 포인트】 피크 부하 타임아웃 → SQS로 버퍼링 + Auto Scaling 워커(디커플링). DB 커넥션 폭증 → RDS Proxy.

해설

【핵심 용어】 ▸ AWS Cost and Usage Report(CUR) — 상세 비용/사용 데이터를 S3로 전달, 서비스·리소스 단위 분석 가능 ▸ Amazon Athena — S3 데이터를 SQL로 직접 쿼리(서버리스), CUR 분석의 표준 ▸ Amazon QuickSight — BI 대시보드/테이블 시각화, Athena를 데이터 소스로 사용 【정답 포인트】 ▸ "S3의 CUR 리포트를 쿼리해 대시보드 표 시각화" → Athena로 S3 CUR 쿼리 + QuickSight로 대시보드 공유(B) ▸ NAT gateway 일별 비용 표 → Athena SQL로 필터, QuickSight 테이블 비주얼 【오답 체크】 (A) DataSync는 데이터 전송 서비스로 쿼리 엔진이 아님. (C) CloudWatch 대시보드는 메트릭용이며 S3 CUR 파일을 SQL로 쿼리하는 용도가 아님. (D) CloudWatch는 CUR 표 시각화·비즈니스 사용자 공유용 대시보드에 부적합. 【시험 포인트】 S3의 CUR/로그를 SQL 분석 → Athena. 비즈니스 대시보드 시각화·공유 → QuickSight. DataSync는 데이터 이동 전용.

해설

【핵심 용어】 ▸ CloudFront TTL — 엣지 캐시 유지 시간, 기본 TTL 0이면 매 요청 오리진 확인(캐싱 효과 없음) ▸ Cache-Control max-age — 오브젝트 캐시 유효 기간 지정 헤더 ▸ CloudFront Invalidation — 배포 후 변경 파일을 엣지 캐시에서 즉시 제거 【정답 포인트】 ▸ "캐싱으로 성능 개선" + "배포 후 stale 콘텐츠 몇 분 이내" → CloudFront 기본 TTL을 2분으로 설정(A) ▸ 또는 max-age 24시간 지정으로 캐시하되, 배포 시 Invalidation으로 변경 파일 즉시 갱신(E) — 두 방식 모두 stale 최소화 【오답 체크】 (B) S3 버킷에는 TTL 설정 개념이 없음(캐싱은 CloudFront/헤더로 제어). (C) Cache-Control private는 공유 캐시 저장을 막아 오히려 캐싱 성능 개선 목적에 반함. (D) Lambda@Edge로 Expires 추가는 과도한 구현이며 배포 시 즉시 무효화 요구를 충족 못함. 【시험 포인트】 캐싱+최신성 균형 → 짧은 TTL(2분) 또는 긴 max-age + 배포 시 Invalidation. private 지시자는 캐싱을 막으므로 오답.

해설

【핵심 용어】 ▸ Compute Savings Plan — EC2/Lambda/Fargate 전반에 유연 적용되는 비용 절감(가장 넓은 커버리지) ▸ EC2 Instance Savings Plan — 특정 인스턴스 패밀리·리전에 한정, 유연성 낮음 ▸ Lambda VPC 연결 — Lambda를 프라이빗 서브넷에 붙이면 VPC 내 EC2에 직접 네트워크 접근 가능 【정답 포인트】 ▸ "Lambda가 프라이빗 EC2에 직접 네트워크 접근" → Lambda를 EC2가 있는 프라이빗 서브넷에 연결(C) ▸ "EC2 + Lambda 모두 비용 최소화" → 두 서비스 모두 커버하는 Compute Savings Plan 【오답 체크】 (A) EC2 Instance Savings Plan은 Lambda 비용을 커버하지 못함. (B) 퍼블릭 서브넷 연결은 프라이빗 EC2 직접 접근 요구·보안에 부적합. (D) Lambda를 서비스 VPC에 두면 고객 프라이빗 EC2에 직접 접근 불가. 【시험 포인트】 여러 컴퓨트(EC2/Lambda/Fargate) 절감 → Compute Savings Plan. Lambda가 VPC 내부 리소스 접근 → Lambda를 해당 프라이빗 서브넷에 연결.

해설

【핵심 용어】 ▸ AWS Budgets + Budget Actions — 예산 임계 도달 시 IAM 정책(예: DenyAll) 자동 적용으로 리소스 생성 차단 ▸ 예산 알림 — 실제/예측 비용 초과 시 알림 발송 ▸ Control Tower — 멀티 계정 거버넌스 기반 【정답 포인트】 ▸ "개발자별 비용 제한" + "최소 운영 오버헤드" → 계정별 AWS Budgets 예산 설정 + 알림(B) ▸ 예산 도달 시 Budgets Actions로 DenyAll 정책 적용해 추가 리소스 생성 자동 차단 → 코드/Lambda 불필요 【오답 체크】 (A) 태그+Config+Lambda 종료 조합은 커스텀 개발·운영 부담이 큼. (C) Cost Explorer/Anomaly Detection은 모니터링·알림만 하고 지출을 강제 차단하지 못함. (D) Service Catalog + Lambda 시작/중지 스케줄은 구성·유지 오버헤드가 큼. 【시험 포인트】 비용 상한 강제 + 최소 운영 → AWS Budgets + Budget Actions(자동 Deny). Cost Explorer/Anomaly Detection은 가시성만 제공.

해설

【핵심 용어】 ▸ 보안 그룹 참조(SG referencing) — 소스/대상을 IP가 아닌 다른 SG로 지정, 3-tier 최소 권한 구성의 표준 ▸ 인바운드 규칙 — 실제로 트래픽을 허용하는 규칙(SG는 상태 저장이라 응답은 자동 허용) ▸ 3-tier: ALB → Web → App → DB(SQL Server) 【정답 포인트】 ▸ Web tier: ALB의 SG로부터 인바운드 HTTPS 허용(A) ▸ DB tier: App tier의 SG로부터 인바운드 SQL Server 트래픽 허용(C) ▸ App tier: Web tier의 SG로부터 인바운드 HTTPS 허용(E) — 각 계층이 앞 계층 SG만 인바운드 허용 【오답 체크】 (B) Web tier 아웃바운드 HTTPS를 0.0.0.0/0로 여는 것은 계층 통신 요구와 무관·과도 개방. (D) SG는 상태 저장이라 응답 트래픽 아웃바운드 규칙이 불필요, 방향·구성도 잘못됨. (F) App tier 아웃바운드 규칙 명시는 불필요(상태 저장), 최소 권한 인바운드 규칙이 핵심. 【시험 포인트】 3-tier 보안 그룹 → 각 계층은 바로 앞 계층의 SG를 소스로 하는 인바운드만 허용. SG는 상태 저장이라 응답용 아웃바운드 규칙 불필요.

해설

【핵심 용어】 ▸ Compute Savings Plan — EC2 + Lambda + Fargate를 한 플랜으로 커버(가장 넓음) ▸ SageMaker Savings Plan — SageMaker는 Compute Savings Plan 대상이 아님, 별도 전용 플랜 필요 ▸ "최소 개수 플랜으로 최다 서비스 커버"가 목표 【정답 포인트】 ▸ 워크로드 = EC2 + Lambda + Fargate + SageMaker ▸ Compute Savings Plan 1개로 EC2/Lambda/Fargate 세 서비스 커버(D) + SageMaker는 전용 SageMaker Savings Plan(C) ▸ 두 플랜으로 네 서비스 모두 커버 → 최소 개수 【오답 체크】 (A) EC2 Instance Savings Plan은 SageMaker를 커버하지 못하며 EC2 패밀리 한정. (B) Compute Savings Plan은 SageMaker에 적용되지 않음. (E) EC2 Instance Savings Plan은 Fargate·SageMaker 커버 불가. 【시험 포인트】 EC2/Lambda/Fargate → Compute Savings Plan(하나로 묶임). SageMaker는 반드시 SageMaker Savings Plan 별도.

해설

【핵심 용어】 ▸ Babelfish for Aurora PostgreSQL — SQL Server의 T-SQL/TDS 프로토콜을 Aurora PostgreSQL에서 실행, 앱 코드 변경 최소화 ▸ AWS SCT — 스키마 변환 도구 ▸ AWS DMS — 데이터 마이그레이션(스키마+데이터 이관) 【정답 포인트】 ▸ "SQL Server → Aurora PostgreSQL, 앱 코드 최소 변경" → Babelfish 활성화로 기존 T-SQL 쿼리 그대로 실행(B) ▸ 스키마·데이터 이관은 SCT + DMS로 수행(C) 【오답 체크】 (A) SCT로 앱의 SQL 쿼리를 재작성하는 것은 "코드 변경 최소화" 목표에 반함. (D) RDS Proxy는 커넥션 풀링일 뿐 SQL Server 호환성/마이그레이션과 무관. (E) DMS는 데이터 이관 도구이지 애플리케이션 SQL 쿼리를 재작성하지 않음. 【시험 포인트】 SQL Server → Aurora PostgreSQL로 코드 변경 최소 → Babelfish. 스키마+데이터 이관 → SCT + DMS.

해설

【핵심 용어】 ▸ EBS 기본 암호화(EC2 account attribute) — 리전 단위로 켜면 신규 EBS 볼륨이 항상 암호화, 미암호화 생성 차단 ▸ AWS KMS — 암호화 키 관리 ▸ AWS Config encrypted-volumes 룰 — 탐지(감사)만 하고 미암호화 생성을 원천 차단하지 못함 【정답 포인트】 ▸ "신규 EBS 볼륨 기본 암호화" + "미암호화 볼륨 생성 방지" → EC2 계정 속성의 EBS 기본 암호화 활성화(A) ▸ 켜면 해당 리전 모든 신규 볼륨이 강제 암호화되어 미암호화 생성 자체가 불가 【오답 체크】 (B) Config 룰은 사후 탐지·평가일 뿐 미암호화 볼륨 생성을 막지 못함. (C) SSM으로 암호화 사본 생성은 기존 볼륨 처리 방식이며 신규 강제 암호화가 아님. (D) KMS CMK + Migration Hub는 마이그레이션 키 지정일 뿐 기본 암호화 강제와 무관. 【시험 포인트】 신규 EBS 강제 암호화 → EC2 계정 속성 "EBS encryption by default"(리전 단위). Config는 탐지만, 예방적 차단이 필요하면 기본 암호화 설정.

해설

【핵심 용어】 ▸ Amazon S3 Storage Lens — 조직·리전 전반 S3 사용/구성 가시성, 버전 관리 등 구성 상태 지표 제공 ▸ 버전 관리(Versioning) 활성 여부 식별 → Storage Lens 지표로 크로스 리전 확인 ▸ IAM Access Analyzer — 리소스 접근 정책 분석(버전 관리 여부와 무관) 【정답 포인트】 ▸ "버전 관리 미활성 S3 버킷을 리전 전반에서 식별" → S3 Storage Lens가 버킷 구성·버전 관리 상태를 조직 단위로 집계 제공(B) 【오답 체크】 (A) CloudTrail은 API 이벤트 기록이며 현재 버전 관리 상태를 일괄 식별하는 용도가 아님. (C) IAM Access Analyzer는 접근 권한 분석용으로 버전 관리 여부 파악 불가. (D) S3 Multi-Region Access Point는 접근 라우팅 기능일 뿐 구성 감사 도구가 아님. 【시험 포인트】 조직/리전 전반 S3 구성·상태 가시성(버전 관리, 암호화 등) → S3 Storage Lens.

해설

【핵심 용어】 ▸ S3 Glacier Instant Retrieval — 밀리초 즉시 접근하는 아카이브 계층, 드물게 접근하지만 즉시성 필요한 장기 보관에 최저 비용 ▸ S3 Standard-IA — 자주 안 쓰는 데이터, GIR보다 스토리지 단가 높음 ▸ S3 One Zone-IA — 단일 AZ, 재생성 불가 데이터엔 내구성 위험 【정답 포인트】 ▸ "재생성 불가" + "30일 후 드물게 접근하나 즉시 사용 가능해야" + "4년 보관 후 삭제" + "최저 비용" → 30일 후 Glacier Instant Retrieval로 전환, 4년 뒤 삭제(A) ▸ GIR은 즉시 접근을 유지하면서 IA보다 저장 단가가 낮아 드문 접근 장기 보관에 최적 【오답 체크】 (B) One Zone-IA는 단일 AZ라 재생성 불가 데이터의 내구성 위험이 큼. (C) Standard-IA는 즉시 접근 가능하나 GIR보다 스토리지 비용이 높음. (D) 4년 후 Glacier Flexible로 전환은 삭제 요구와 어긋나고 즉시성도 손실. 【시험 포인트】 드물게 접근 + 즉시 접근 필요 + 장기 보관 최저가 → S3 Glacier Instant Retrieval. 재생성 불가 데이터엔 One Zone-IA 금지.

해설

【핵심 용어】 ▸ S3 Multi-Region Access Point(MRAP) — 여러 리전 버킷에 단일 글로벌 엔드포인트, 최근접 리전 자동 라우팅 ▸ Active-Active + Cross-Region Replication(CRR) — 양방향 복제로 데이터 동기화·자동 장애 조치 ▸ AWS Global Accelerator 기반 백본 → 공용 인터넷 혼잡 회피 【정답 포인트】 ▸ "최근접 S3 버킷으로 라우팅 + 공용 인터넷 혼잡 없음" → MRAP 단일 글로벌 엔드포인트가 AWS 백본으로 최근접 리전 라우팅(D) ▸ "관리 최소 페일오버" → Active-Active MRAP + CRR로 자동 복제·장애 대응 【오답 체크】 (A) 리전 엔드포인트 직접 사용은 앱이 라우팅·페일오버를 직접 관리해야 해 부담 큼. (B) MRAP는 "글로벌 단일 엔드포인트"이지 리전마다 글로벌 엔드포인트 생성 개념이 아니며 서술이 부정확. (C) 교차 계정 복제 + 리전 엔드포인트 수동 구성은 관리 부담이 큼. 【시험 포인트】 멀티 리전 S3 최근접 라우팅 + 관리 최소 페일오버 → S3 Multi-Region Access Point(단일 글로벌 엔드포인트) + Cross-Region Replication.

해설

【핵심 용어】 ▸ Amazon Machine Image(AMI) — 인스턴스 이미지, 동일 구성 EC2 재생성 ▸ Network Load Balancer — 다중 AZ 인스턴스에 트래픽 분산·헬스 체크로 내결함성 ▸ Multi-AZ 배치 → AZ 장애에도 가용성 유지 【정답 포인트】 ▸ "설계 변경 불가한 레거시" + "신뢰성·내결함성" → 각 앱 AMI 생성 후 서로 다른 AZ에 2개 인스턴스 기동, NLB로 분산(C) ▸ Multi-AZ + LB로 한 AZ/인스턴스 장애 시에도 서비스 지속 【오답 체크】 (A) ASG min=max=1은 인스턴스가 항상 1개뿐이라 다중 AZ 내결함성을 제공하지 못함. (B) 시간별 백업·복원 DR은 복구 시간 지연이 커 실시간 내결함성이 아님. (D) Refactor Spaces로 ECS/Fargate 재설계는 "앱 설계 변경 불가" 제약을 위반. 【시험 포인트】 설계 변경 없이 내결함성 → AMI로 여러 AZ에 인스턴스 복제 + 로드밸런서. min=max=1 ASG는 HA 아님.