AWS SAA 해설 332~

파일을 Amazon FSx for Windows File Server 파일 시스템으로 마이그레이션합니다. Amazon FSx 파일 시스템을 온프레미스 Active Directory와 통합합니다. AWS 클라이언트 VPN을 구성합니다.

핵심 요약

• 요구 사항 분석:

1. 소스: 온프레미스 Windows 파일 서버 (SMB 프로토콜 사용).
2. 보안: 기밀 파일, 권한 있는 사용자만 액세스 (ACL 필요), 보안 전송.
3. 문제: 원격 사용 증가, 용량 부족.

• 해결책 (FSx for Windows + VPN):
  • Amazon FSx for Windows File Server: 기존 윈도우 파일 서버와 완벽하게 호환되는 완전 관리형 서비스입니다. 용량 확장이 자유로워 "용량 부족" 문제를 해결합니다.
  • Active Directory 통합: 기존의 온프레미스 AD 사용자 계정과 권한(ACL)을 그대로 사용하여 "권한 있는 사용자만 액세스"하도록 제어할 수 있습니다.
  • AWS Client VPN: 원격 근무자가 인터넷을 통해 안전하게 AWS VPC 내부의 파일 시스템에 접근할 수 있도록 암호화된 터널을 제공합니다. 이는 "직원 기기로의 안전한 다운로드"를 보장합니다.

오답 노트

• A (EC2 in Public Subnet): 파일 서버를 퍼블릭 서브넷에 두는 것은 보안상 매우 위험합니다. 또한 직원들의 가정용 유동 IP를 일일이 보안 그룹에 등록/관리하는 것은 운영상 불가능에 가깝습니다.
• C, D (Amazon S3): S3는 객체 스토리지로, Windows 파일 서버(SMB)와는 동작 방식이 다릅니다. 기존의 폴더 권한(NTFS ACL)을 그대로 유지하거나 파일 탐색기로 드라이브를 매핑하여 사용하는 사용자 경험을 제공하기 어렵습니다.

Amazon FSx for Windows File Server

• 정의: 업계 표준 SMB(Server Message Block) 프로토콜을 기반으로 하는 완전 관리형 Microsoft Windows 파일 시스템.
• 주요 기능:
  • Windows 호환성: AD 통합, 파일 액세스 제어 목록(ACL), 섀도 복사본 등 지원.
  • 사용 사례: 홈 디렉터리, 비즈니스 애플리케이션 파일 공유, 웹 서빙 등.

• 액세스 방법: AWS Direct Connect나 VPN을 통해 온프레미스에서, 또는 AWS 내의 EC2, WorkSpaces 등에서 접근 가능.

---

월별 일정에 따라 EC2 자동 확장 예약된 확장 정책을 구성합니다.

• 요구 사항 분석:

1. 패턴: 매월 1일 자정이라는 예측 가능한(Predictable) 시점.
2. 증상: 작업 시작과 동시에 CPU가 "즉시 100%"로 치솟아 시스템 중단.
3. 목표: 다운타임 방지.

• 해결책 (Scheduled Scaling):
  • 선제적 대응: 트래픽이 언제 몰릴지 정확히 알고 있으므로, 예약된 조정(Scheduled Scaling)을 설정합니다.
  • 작동 방식: 배치 작업이 시작되기 전(예: 11시 50분)에 미리 오토 스케일링 그룹의 최소/원하는 용량을 늘려 인스턴스를 확보해 둡니다. 이렇게 하면 부하가 시작될 때 이미 충분한 컴퓨팅 파워가 준비되어 있어 중단을 막을 수 있습니다.

오답 노트

• B (CPU 기반 단순 확장): 이는 반응형(Reactive) 방식입니다. 모니터링 시스템이 CPU 100%를 감지하고 새 인스턴스를 띄우는 데 수 분이 걸립니다. 문제에서 "즉시" CPU가 찼다고 했으므로, 새 서버가 뜨기 전에 이미 서비스는 죽습니다.
• A (CloudFront): CDN은 이미지나 비디오 같은 정적 콘텐츠 전송 속도를 높이는 데 쓰입니다. 백엔드에서 수행하는 '재무 계산'의 CPU 부하를 줄여주지 못합니다.
• D (ElastiCache): 데이터베이스 쿼리 부하를 줄이는 데 효과적이지만, CPU 연산이 주가 되는 배치 작업의 부하를 직접적으로 해결하지 못합니다. 또한 애플리케이션 코드 수정이 필요할 수 있습니다.

Auto Scaling 정책 비교

정책 유형	예약된 조정 (Scheduled)	동적 조정 (Dynamic - Target Tracking/Simple)	예측 조정 (Predictive)
작동 시점	지정된 시간에 미리 실행	지표(CPU 등)가 변한 후에 실행	과거 데이터를 머신러닝으로 분석해 미리 실행
사용 사례	월말 정산, 블랙 프라이데이 등 알려진 이벤트	평소 트래픽 변화 대응	주기적인 패턴이 있는 일상 트래픽
장점	"즉시" 발생하는 폭증(Spike)에 완벽 대비 가능	설정이 간편함	자동화된 사전 대응

---

Amazon S3에 대한 SFTP로 AWS Transfer Family를 설정합니다. 통합 Active Directory 인증을 구성합니다.

• 요구 사항 분석:

1. 프로토콜: SFTP (고객 앱 변경 불가).
2. 저장소: Amazon S3.
3. 인증: 온프레미스 Microsoft Active Directory.
4. 목표: 최소한의 운영 오버헤드.

• 해결책 (AWS Transfer Family):
  • 완전 관리형 서비스: 서버를 직접 구축하거나 관리할 필요 없이 SFTP 엔드포인트를 제공합니다. S3 버킷을 백엔드 스토리지로 직접 연결합니다.
  • 호환성: 표준 SFTP 프로토콜을 사용하므로 클라이언트 애플리케이션을 전혀 수정할 필요가 없습니다.
  • 인증 통합: AWS Directory Service를 통해 온프레미스 Active Directory와 연동하여 기존 자격 증명으로 사용자를 인증할 수 있습니다.

오답 노트

• B (AWS DMS): 데이터베이스 마이그레이션 도구입니다. SFTP 파일 전송 서버로 사용할 수 없습니다.
• C (AWS DataSync): 대량의 데이터를 스토리지 간에 동기화/이동하는 데 사용되는 도구입니다. 최종 사용자가 SFTP 클라이언트로 접속하여 파일을 다운로드하는 용도가 아닙니다.
• D (EC2에 SFTP 구축): EC2 인스턴스를 관리(패치, 보안, 가용성 등)해야 하므로 운영 오버헤드가 큽니다. 완전 관리형 서비스인 Transfer Family가 더 효율적입니다.

AWS Transfer Family

• 정의: S3 또는 EFS로 파일을 송수신할 수 있도록 SFTP, FTPS, FTP 프로토콜을 제공하는 완전 관리형 서비스.
• 주요 기능:
• 스토리지: S3 객체를 파일처럼 보이게 함.
• 인증: AD, LDAP, Okta 등 다양한 ID 공급자(IdP)와 통합 가능.
• 사용 사례: "기존 SFTP 서버를 클라우드로 마이그레이션", "파트너사와의 파일 교환".

---

스냅샷에서 Amazon Elastic Block Store(Amazon EBS) 빠른 스냅샷 복원(Fast Snapshot Restore)을 활성화합니다. 스냅샷을 사용하여 AMI를 프로비저닝합니다. 자동 확장 그룹의 AMI를 새 AMI로 바꿉니다.

• 문제 상황: 갑작스러운 수요 증가로 대규모 인스턴스를 빠르게 띄워야 함. 그러나 EBS 스냅샷으로 만든 볼륨은 처음 액세스할 때 S3에서 데이터를 가져오는 지연 로딩(Lazy Loading) 현상이 발생하여 초기 성능이 떨어짐.
• 해결책 (FSR - Fast Snapshot Restore):
  • 기능: 스냅샷에 FSR을 활성화하면, 해당 스냅샷으로 볼륨을 생성할 때 블록이 미리 초기화(Pre-warmed)된 상태로 생성됩니다.
  • 효과: 볼륨 생성 즉시 최대 성능을 낼 수 있어, 초기화 지연 시간(Latnecy)을 제거합니다. 대규모 트래픽 처리를 위해 즉시 투입되어야 하는 인스턴스에 필수적입니다.

오답 노트

• A (register-image): 단순히 이미지를 등록하는 명령어입니다. 스냅샷의 물리적 초기화 속도(I/O 성능)를 개선하지 않습니다.
• C (DLM), D (AWS Backup): 백업 정책을 자동화하는 관리 도구입니다. "인스턴스 부팅 속도"나 "데이터 액세스 속도"를 높여주는 성능 최적화 기능이 아닙니다.

EBS 지연 로딩(Lazy Loading) vs FSR

구분	일반 스냅샷 복원 (Lazy Loading)	빠른 스냅샷 복원 (FSR)
작동 방식	볼륨 생성 후, 데이터를 읽을 때 S3에서 다운로드함.	볼륨 생성 시 미리 모든 블록을 준비해 둠.
성능	첫 액세스 시 I/O 대기 시간(Latency) 발생.	즉시 최대 성능 발휘.
비용	스토리지 비용만 발생.	추가 요금(DSU - Data Services Unit) 발생.
사용 사례	일반적인 백업 복구, 개발 환경.	긴급 스케일 아웃, VDI 부팅, 고성능 DB 복구.

---

새로운 AWS Key Management Service(AWS KMS) 암호화 키를 만듭니다. AWS Secrets Manager를 사용하여 적절한 자격 증명과 함께 KMS 키를 사용하는 새로운 비밀을 만듭니다. 비밀을 Aurora DB 클러스터와 연결합니다. 14일의 사용자 지정 로테이션 기간을 구성합니다.

• 요구 사항 분석:

1. 보안: 데이터베이스 자격 증명 암호화.
2. 규정 준수: 14일마다 자격 증명 순환(Rotation).
3. 목표: 최소한의 운영 노력.

• 해결책 (AWS Secrets Manager):
  • 완전 관리형 순환: AWS Secrets Manager는 Amazon RDS 및 Aurora와 기본적으로 통합되어 있어, 별도의 복잡한 코드를 작성하지 않고도 구성 설정만으로 비밀번호를 자동으로 교체할 수 있습니다.
  • 자동화: 지정된 일정(14일)에 따라 Lambda 함수를 트리거하여 데이터베이스의 비밀번호를 변경하고, 비밀(Secret)의 메타데이터를 업데이트하는 작업을 자동으로 수행합니다.
  • 보안: KMS를 통해 비밀을 암호화하여 안전하게 저장합니다.

오답 노트

• B (SSM Parameter Store): Parameter Store도 자격 증명을 저장할 수 있지만, 자동 순환(Auto Rotation) 기능이 내장되어 있지 않습니다. 순환 로직을 수행하는 Lambda 함수를 직접 작성하고 CloudWatch Events로 스케줄링해야 하므로 운영 노력이 더 듭니다.
• C, D (EFS / S3): 자격 증명을 파일 형태로 저장하는 것은 애플리케이션 보안 모범 사례가 아닙니다. 또한 비밀번호 변경 시 파일을 업데이트하고 애플리케이션이 이를 다시 읽어오게 하는 동기화 로직을 직접 구현해야 하므로 운영 오버헤드가 매우 큽니다.

AWS Secrets Manager vs Systems Manager Parameter Store

특징	AWS Secrets Manager	SSM Parameter Store
주요 기능	비밀번호 자동 순환 (Rotation)	계층적 구성 데이터 관리
비용	비밀당 과금 (약간 비쌈)	표준 매개변수 무료 (API 호출 비용 별도)
통합	RDS, Aurora, Redshift, DocumentDB	일반적인 문자열/비밀 저장
사용 사례	DB 자격 증명, OAuth 토큰	환경 변수, 설정값, 라이선스 키

⭐Tip: 문제에서 "데이터베이스 자격 증명 순환(Rotation)"이라는 키워드가 나오면 AWS Secrets Manager가 정답일 확률이 매우 높습니다.

---

데이터베이스를 Amazon Aurora MySQL로 마이그레이션합니다. 읽기 복제본을 Aurora Replicas로 대체하고 Aurora Auto Scaling을 구성합니다. 저장 프로시저를 Aurora MySQL 네이티브 함수로 대체합니다.

• 문제점: RDS for MySQL의 기존 복제 방식(Binlog 파일 전송 및 재실행)은 트래픽이 몰리면 처리가 지연되어 복제 지연(Replication Lag)이 발생하기 쉽습니다. 특히 "1초 미만"이라는 엄격한 요구 사항을 맞추기 어렵습니다.
• 해결책 (Amazon Aurora):
  • 구조적 해결: Aurora는 스토리지 레벨에서 물리적인 복제를 수행하므로, 리플리카가 기본 인스턴스의 스토리지 볼륨을 공유하는 방식입니다. 이로 인해 복제 지연이 일반적으로 10~20밀리초(ms) 수준으로 매우 낮으며, 부하가 심해도 거의 늘어나지 않습니다.
  • 호환성: Aurora MySQL은 MySQL과 유선 호환(Wire-compatible)되므로 애플리케이션 코드 변경이 거의 필요 없습니다. 저장 프로시저도 그대로 지원합니다.
  • 관리 효율: 완전 관리형 서비스이므로 EC2를 직접 운영하는 것보다 오버헤드가 적습니다.

오답 노트

• B (ElastiCache): 캐시를 도입하면 읽기 부하를 줄일 수는 있지만, 애플리케이션에 캐싱 로직을 추가(코드 변경)해야 합니다. 또한 저장 프로시저를 Lambda로 바꾸는 것은 대규모 리팩토링이므로 "코드 변경 최소화" 요건에 위배됩니다.
• C (EC2의 MySQL): EC2에 MySQL을 설치해서 운영하면 관리 오버헤드가 매우 증가합니다(패치, 백업, HA 구성 등). 또한 표준 MySQL 복제 방식을 그대로 사용하므로 지연 문제를 근본적으로 해결하기 어렵습니다.
• D (DynamoDB): RDBMS(MySQL)에서 NoSQL(DynamoDB)로 마이그레이션하려면 데이터 모델링부터 쿼리 로직까지 애플리케이션을 완전히 새로 작성해야 합니다.

Amazon RDS vs Amazon Aurora 복제 지연

구분	Amazon RDS (MySQL)	Amazon Aurora (MySQL)
복제 방식	바이너리 로그(Binlog) 전송 후 SQL 재실행 (논리적 복제)	공유 스토리지 볼륨의 페이지 업데이트 (물리적 복제)
복제 속도	싱글 스레드 처리로 인해 트래픽 급증 시 지연 발생 쉬움 (수 초 ~ 수 분)	스토리지 레벨 복제로 지연 거의 없음 (100ms 미만)
읽기 전용 복제본	최대 5개 (기본)	최대 15개
적합한 사용 사례	일반적인 웹 워크로드	짧은 지연 시간, 높은 처리량이 필요한 고성능 앱

---

DB 클러스터에 대한 Aurora 글로벌 데이터베이스를 설정합니다. 설정이 완료되면 보조 지역에서 DB 인스턴스를 제거합니다.

• 요구 사항 분석:

1. 대상: Amazon Aurora MySQL.
2. 목표: 재해 복구(DR)를 위한 타 리전 데이터 복제.
3. 핵심 제약: 가장 비용 효율적이어야 함.

• 해결책 (Aurora Global Database - Headless Mode):
  • 헤드리스(Headless) 아키텍처: Amazon Aurora Global Database는 스토리지 계층에서 물리적으로 데이터를 복제합니다. 보조 리전에 컴퓨팅 인스턴스(DB 인스턴스)가 없어도 스토리지 볼륨 간에 데이터 복제가 계속 수행됩니다.
  • 비용 절감: DR 상황이 발생하기 전까지는 보조 리전의 비싼 컴퓨팅 비용(EC2/RDS 인스턴스 비용)을 지불할 필요가 없습니다. 스토리지 비용과 복제 I/O 비용만 발생하므로 가장 경제적입니다.
  • 복구: 재해 발생 시 보조 리전에 인스턴스를 추가하고 승격(Promote)하면 됩니다 (RTO는 약간 증가하지만 비용 효율성은 최상).

오답 노트

• A (MySQL 바이너리 로그): Binlog 복제를 수행하려면 보조 리전에 로그를 받아 처리할 실행 중인 DB 인스턴스가 반드시 필요합니다. 컴퓨팅 비용이 계속 발생하므로 B보다 비쌉니다.
• C (AWS DMS): DMS를 사용하려면 복제 인스턴스(Replication Instance)와 대상 DB 인스턴스가 모두 실행 중이어야 합니다. 관리 오버헤드와 비용이 가장 높은 옵션 중 하나입니다.
• D (Global DB + 인스턴스 유지): B와 기술적으로 동일하지만, 보조 리전에 유휴 인스턴스(Compute)를 계속 켜두는 방식입니다. RTO(복구 시간)는 B보다 빠르지만, "비용 효율성" 측면에서는 인스턴스를 끄는 B가 더 우수합니다.

Aurora Global Database "Headless" 패턴

• 개념: 보조 리전에 클러스터 볼륨(스토리지)만 존재하고 DB 인스턴스(컴퓨팅)는 없는 상태.
• 장점: 컴퓨팅 비용 0원.
• 단점: 장애 조치(Failover) 시 인스턴스를 새로 생성해야 하므로 복구 시간(RTO)이 몇 분 정도 더 소요됨. (비용 vs 시간의 트레이드오프)

---

RDS for MySQL 데이터베이스에서 애플리케이션 사용자에 대한 자격 증명을 만들고 AWS Secrets Manager에 자격 증명을 저장합니다. Secrets Manager에서 데이터베이스 자격 증명을 로드하도록 애플리케이션을 구성합니다. Secrets Manager를 사용하여 RDS for MySQL 데이터베이스에서 애플리케이션 사용자에 대한 자격 증명 로테이션 일정을 설정합니다.

• 요구 사항 분석:

1. 보안 강화: 소스 코드에 박혀 있는(Embedded) 자격 증명 제거.
2. 최소한의 노력: 코딩이나 유지 관리 업무를 최대한 줄여야 함.

• 해결책 (AWS Secrets Manager):
  • 자격 증명 중앙 관리: AWS Secrets Manager는 데이터베이스 자격 증명(ID/PW)을 암호화하여 안전하게 저장합니다. 애플리케이션은 소스 코드를 수정하여 하드코딩된 비밀번호 대신 Secrets Manager API를 호출해 자격 증명을 가져오기만 하면 됩니다.
  • 기본 통합 순환(Built-in Rotation): Secrets Manager는 Amazon RDS와 기본적으로 통합되어 있습니다. 사용자가 복잡한 로직을 짤 필요 없이, 콘솔에서 "자격 증명 순환 켜기"를 설정하고 주기(예: 30일)를 정하기만 하면 AWS가 제공하는 회전 로직이 자동으로 비밀번호를 변경합니다. 이것이 "최소한의 노력"의 핵심입니다.

오답 노트

• A (AWS KMS): KMS는 데이터를 암호화하는 '키'를 관리하는 서비스이지, 데이터베이스 아이디/비밀번호 자체를 저장하고 주기에 맞춰 변경해 주는 서비스가 아닙니다.
• B (직접 Lambda 생성): Secrets Manager를 사용하는 것은 맞지만, 자격 증명을 순환하는 Lambda 함수를 사용자가 '직접 만드는(Create)' 것은 불필요한 추가 노동입니다. Secrets Manager가 제공하는 자동 순환 기능을 사용하는 것(C)이 더 효율적입니다.
• D (Parameter Store): Parameter Store는 RDS 비밀번호의 자동 순환(Auto Rotation) 기능을 기본적으로 제공하지 않습니다. 이를 구현하려면 Lambda와 EventBridge 등을 엮어 별도 시스템을 구축해야 하므로 프로그래밍 노력이 훨씬 많이 듭니다.

AWS Secrets Manager의 장점

• 하드코딩 제거: 소스 코드에서 비밀번호를 없애 보안 위험(Git 유출 등)을 원천 차단.
• 자동 순환: 보안 규정(예: 90일마다 비밀번호 변경)을 준수하기 위해 관리자가 수동으로 DB 비밀번호를 바꿀 필요가 없음.
• RDS 통합: MySQL, PostgreSQL, Aurora 등 주요 AWS 데이터베이스에 대해 클릭 몇 번으로 순환 구성 가능.

---

ALB 앞에 AWS WAF를 사용합니다. 적절한 웹 ACL을 AWS WAF와 연결합니다.

핵심 요약

• 문제 상황: 웹 애플리케이션이 SQL 주입(SQL Injection) 공격에 취약함.
• 요구 사항: 공격 시도를 탐지하고 차단해야 함.
• 해결책 (AWS WAF):
  • AWS WAF(Web Application Firewall)는 웹 트래픽(HTTP/HTTPS)을 모니터링하여 OWASP Top 10과 같은 일반적인 웹 취약점 공격을 방어하는 서비스입니다.
  • SQL 주입 방어: WAF의 웹 ACL(Web Access Control List)에 "SQL 데이터베이스 관리형 규칙(Managed Rule)"을 추가하면, 요청 본문이나 URI에 악의적인 SQL 구문이 포함되어 있는지 검사하고 자동으로 차단할 수 있습니다.
  • 배포 위치: CloudFront, ALB, API Gateway 앞에 배치되어 애플리케이션에 트래픽이 도달하기 전에 공격을 막습니다.

오답 노트

• B (ALB 리스너 규칙): ALB는 패킷 내부의 악성 코드를 분석하는 보안 장비가 아닙니다. 경로(Path)나 헤더 기반의 단순 라우팅만 가능하며, 복잡한 SQL 패턴 매칭을 수행할 수 없습니다.
• C (AWS Shield Advanced): DDoS(분산 거부 서비스) 공격을 방어하는 데 특화된 서비스입니다. 대용량 트래픽 공격은 막아주지만, 정교한 애플리케이션 계층의 SQL 해킹 시도를 차단하는 것은 WAF의 역할입니다.
• D (Amazon Inspector): EC2 인스턴스 내부의 소프트웨어 취약점(CVE)을 스캔하는 도구입니다. 실시간으로 들어오는 네트워크 공격 패킷을 차단(Block)하는 방화벽 기능은 없습니다.

AWS WAF (Web Application Firewall)

• 정의: 가용성에 영향을 주거나 보안을 위협하거나 리소스를 과도하게 사용하는 일반적인 웹 익스플로잇으로부터 웹 애플리케이션이나 API를 보호하는 데 도움이 되는 웹 애플리케이션 방화벽.
• 주요 차단 대상:
  • SQL Injection (SQLi)
  • Cross-Site Scripting (XSS)
  • 특정 국가(Geo-blocking) 또는 IP 차단

• 핵심 구성 요소:
• Web ACL: 보호 규칙의 집합.
• Rules: 검사 로직 (예: "요청에 SELECT * FROM이 포함되면 차단하라").

• ⭐Tip: 문제에서 "SQL Injection", "XSS(크로스 사이트 스크립팅)", "악성 봇 차단" 키워드가 나오면 AWS WAF가 정답입니다.

---