PostgreSQL 데이터베이스를 Amazon RDS for PostgreSQL DB 인스턴스로 마이그레이션합니다. 다른 Region에 읽기 복제본을 만듭니다.
핵심 요약
- 요구 사항 분석:
- 여러 AWS 지역(Multi-Region) 가용성: 데이터가 단일 리전이 아닌 여러 리전에 존재해야 함.
- 항상 온라인(Always Online): 재해 발생 시 즉시 사용할 수 있는 상태여야 함 (백업 파일 형태가 아님).
- 운영 오버헤드 최소화: 관리형 서비스(RDS) 사용 필수.
- 해결책 (Cross-Region Read Replica):
- 리전 간 복제: Amazon RDS는 다른 리전(Region)에 읽기 전용 복제본(Read Replica)을 생성하는 기능을 지원합니다.
- 재해 복구(DR): 기본 리전에 장애가 발생하면, 다른 리전의 읽기 복제본을 즉시 마스터로 승격(Promote)하여 서비스를 재개할 수 있습니다. 이는 스냅샷 복구보다 훨씬 빠르며(RTO 단축), 데이터가 실시간에 가깝게 유지됩니다.
오답 노트
- A (EC2): EC2에 DB를 직접 설치/운영하는 것은 패치, 백업, 고가용성 구성을 모두 직접 해야 하므로 운영 오버헤드가 가장 큽니다.
- B (Multi-AZ): Multi-AZ는 단일 리전 내의 고가용성(AZ 간 장애 대비)을 위한 기능입니다. 문제에서 요구하는 "여러 AWS 지역" 요구 사항을 충족하지 못합니다.
- D (스냅샷 복사): 스냅샷은 파일 형태의 백업입니다. 장애 시 스냅샷을 기반으로 새 DB 인스턴스를 복원(Restore)해야 하므로, 복구에 시간이 걸리며 "항상 온라인" 상태라고 볼 수 없습니다.
RDS Multi-AZ vs Cross-Region Read Replica
| 기능 | Multi-AZ (다중 AZ) | Read Replica (읽기 복제본) |
|---|---|---|
| 목적 | 고가용성 (HA) & 자동 장애 조치 | 성능 확장 (읽기 분산) & 재해 복구 (DR) |
| 위치 | 동일 리전 내 다른 AZ | 동일 리전 또는 다른 리전 (Cross-Region) |
| 동기화 | 동기식 (Synchronous) - 데이터 손실 없음 | 비동기식 (Asynchronous) - 약간의 지연(Lag) 가능 |
| 사용 가능 여부 | 평소에는 접속 불가 (Standby) | 평소에도 읽기 전용으로 접속 가능 |
각 클리닉의 온프레미스에 AWS Storage Gateway 파일 게이트웨이(S3 File Gateway)를 가상 머신(VM)으로 배포합니다.
핵심 요약
- 요구 사항:
- 환경: 온프레미스 클리닉 + 파일 기반 애플리케이션.
- 데이터 소스: Amazon S3 (객체 스토리지).
- 핵심 제약: 최소한의 지연 시간(Low Latency)으로 데이터 제공.
- 해결책 (S3 File Gateway):
- 프로토콜 변환: S3 File Gateway는 S3의 객체를 온프레미스 애플리케이션에 표준 파일 프로토콜(NFS 또는 SMB)로 노출시킴. (별도의 앱 수정 불필요).
- 로컬 캐싱(Local Caching): 자주 액세스하는 데이터를 클리닉의 온프레미스 VM(게이트웨이)에 캐시하여, 인터넷을 거치지 않고 LAN 속도로 빠르게 제공함. (지연 시간 문제 해결).
오답 노트
- B (DataSync): 대량 데이터의 이동/마이그레이션 도구임. 실시간 애플리케이션 액세스용 게이트웨이가 아니며, 로컬 캐싱을 통한 지속적인 저지연 액세스를 제공하지 않음.
- C (Volume Gateway): 이는 블록 스토리지(iSCSI)를 제공하는 방식임. "S3 버킷에 있는 객체(파일)"를 파일 형태로 애플리케이션에 보여주는 것이 아니라, 가상 하드디스크(Volume)를 제공하는 것이므로 용도가 다름.
- D (EFS 연결): 데이터가 현재 S3에 있으므로 EFS는 적합하지 않음(데이터를 EFS로 또 옮겨야 함). 또한, 온프레미스에서 인터넷을 통해 EFS를 직접 마운트하면 네트워크 지연 시간이 발생할 수 있음(로컬 캐시 없음).
AWS Storage Gateway 유형 비교 (빈출)
| 유형 | S3 File Gateway (정답) | Volume Gateway | Tape Gateway |
|---|---|---|---|
| 인터페이스 | NFS, SMB (파일 공유) | iSCSI (블록 스토리지/디스크) | iSCSI-VTL (가상 테이프) |
| 백엔드 | Amazon S3 (객체 1:1 매핑) | S3 (EBS 스냅샷 형태) | S3 Glacier (아카이브) |
| 주 용도 | 온프레미스 앱이 S3 파일을 읽/쓰기, 데이터 레이크 수집 | 온프레미스 서버의 디스크 확장, 백업 | 기존 테이프 백업 시스템 대체 |
| 캐싱 | 지원 (자주 쓰는 파일 로컬 저장) | Stored(전체) / Cached(자주 쓰는 데이터) 모드 지원 | - |
다른 가용성 영역에 읽기 복제본이 있는 Amazon Aurora로 데이터베이스를 이동합니다. EC2 인스턴스에서 Amazon Machine Image(AMI)를 만듭니다. 두 가용성 영역에 Application Load Balancer를 구성합니다. 두 가용성 영역에 걸쳐 AMI를 사용하는 자동 확장 그룹을 연결합니다.
핵심 요약
- 문제 상황: 단일 EC2에 웹 서버와 DB가 같이 있어 확장성과 가용성이 모두 떨어짐.
- 해결책 (3-Tier Architecture & Multi-AZ):
- 계층 분리 (Decoupling): 웹 서버와 데이터베이스를 분리해야 각각 독립적으로 확장할 수 있습니다.
- 데이터베이스 (Aurora Cross-AZ): 관리형 DB인 Amazon Aurora로 마이그레이션하고, 다른 가용 영역(AZ)에 읽기 복제본을 둡니다. 이는 읽기 성능을 확장할 뿐만 아니라, 주 인스턴스 장애 시 복제본이 승격(Failover)되어 고가용성(HA)을 보장합니다.
- 웹 계층 (ASG + ALB): 웹 서버 설정을 담은 AMI(이미지)를 생성하고, Auto Scaling Group(ASG)을 사용하여 트래픽에 따라 인스턴스를 자동 증감(Scalability)시킵니다. 이때 여러 가용 영역(Multi-AZ)에 걸쳐 배포하고 ALB로 트래픽을 분산해야 진정한 고가용성을 달성할 수 있습니다.
오답 노트
- A, B (단일 가용 영역): "동일한 가용성 영역(Same AZ)"에 인스턴스를 추가하거나 로드 밸런서를 두는 것은 해당 데이터 센터(AZ) 전체 장애 시 서비스가 중단되므로 고가용성(High Availability) 요건을 충족하지 못합니다. 또한 EC2를 '수동'으로 시작하는 것은 확장성(Auto Scaling)이 없는 방식입니다.
- D (DB on EC2): 데이터베이스를 별도의 EC2로 옮기는 것은 관리가 어렵고(패치, 백업 직접 수행), 단일 EC2 DB는 여전히 단일 장애 지점(SPOF)이 됩니다. 관리형 서비스(RDS/Aurora)를 사용하는 것이 훨씬 운영 효율적입니다.
고가용성(HA)을 위한 표준 아키텍처
- Multi-AZ (다중 가용 영역): 최소 2개 이상의 AZ에 리소스를 분산 배치.
- Auto Scaling Group (ASG): 수요에 따라 EC2 인스턴스 자동 추가/삭제 및 비정상 인스턴스 자동 교체.
- ELB (Elastic Load Balancer): 들어오는 트래픽을 여러 AZ의 인스턴스로 균등하게 분산.
- Managed Database (RDS/Aurora): 자동 백업, 패치, 그리고 Multi-AZ/Read Replica를 통한 자동 장애 조치 지원.
개발 환경에서 대상 그룹을 재구성하여 대상으로 EC2 인스턴스를 하나만 갖도록 합니다.
핵심 요약
- 비용 효율성 분석:
- 프로덕션 환경: 고가용성(HA)을 위해 최소 2개 이상의 인스턴스가 필요하며, 트래픽이 많으므로 성능을 유지해야 함.
- 개발 환경: 실제 사용자가 접속하는 곳이 아니므로 고가용성이 필수 요구 사항이 아님.
- 해결책 (인스턴스 수 축소):
- ALB는 단일 대상(인스턴스 1개)으로도 정상 작동함.
- 개발 환경의 최소 인스턴스 수를 2개에서 1개로 줄이면 컴퓨팅 비용을 즉시 50% 절감할 수 있음.
비용 최적화: 개발 vs 프로덕션
- 프로덕션(Production): 안정성, 고가용성(Multi-AZ), 성능이 최우선. 비용보다 가동 시간이 중요.
- 개발(Development): 비용 절감이 최우선.
- 최소화: 인스턴스 1개 (Single AZ).
- 중단 가능: 스팟 인스턴스 사용 권장.
- 근무 시간 외 중지: Instance Scheduler를 사용해 밤/주말에는 꺼둠.
각 가용성 영역에 퍼블릭 서브넷을 만듭니다. 퍼블릭 서브넷을 ALB와 연결합니다. (경로 테이블 설정 등을 통해 인터넷 게이트웨이와 연결되도록 구성합니다.)
- 문제 상황:
- EC2 인스턴스는 보안을 위해 프라이빗 서브넷에 위치함 (올바른 구성).
- 인터넷 연결(Internet-facing) ALB를 사용 중이지만 트래픽이 도달하지 않음.
- 원인: ALB가 인터넷 트래픽을 받으려면 반드시 퍼블릭 서브넷(인터넷 게이트웨이가 있는 서브넷)에 위치해야 하는데, 현재 구성에서는 ALB도 프라이빗 서브넷에 있거나 올바른 서브넷 연결이 누락되었을 가능성이 큼.
- 해결책 (Standard 2-Tier Architecture):
- 퍼블릭 서브넷 생성: ALB가 위치할 퍼블릭 서브넷을 각 가용 영역(AZ)마다 생성함.
- ALB 배치: ALB를 방금 만든 퍼블릭 서브넷에 연결함.
- 트래픽 흐름:
클라이언트(인터넷)->ALB(퍼블릭 서브넷)->EC2(프라이빗 서브넷)순서로 트래픽이 전달됨.
VPC 서브넷 아키텍처 (2-Tier)
| 구성 요소 | 위치(서브넷) | 역할 | 네트워크 설정 |
|---|---|---|---|
| Internet-facing ALB | Public Subnet | 외부 트래픽 수신 및 분산 | 라우팅 테이블에 IGW(인터넷 게이트웨이) 필요 |
| Backend EC2 | Private Subnet | 애플리케이션 로직 처리 | 외부 직접 접속 불가, ALB 또는 NAT를 통해서만 통신 |
| NAT Gateway | Public Subnet | 프라이빗 EC2의 패치 다운로드 등 아웃바운드 지원 | (인바운드 트래픽과는 무관) |
- 요구 사항 분석: Amazon RDS for MySQL에서 읽기 복제본(Read Replica)을 생성하기 위한 사전 요구 사항을 묻고 있습니다.
- 필수 조치 1 (자동 백업 활성화):
- RDS에서 읽기 복제본을 생성하려면 소스 DB 인스턴스에서 자동 백업(Automatic Backups)이 반드시 활성화되어 있어야 합니다.
- 백업 보존 기간을 0이 아닌 값(예: 1일 이상)으로 설정하면, RDS가 자동으로 MySQL의 바이너리 로그(Binary Log) 기능을 활성화합니다. 이 바이너리 로그가 복제의 핵심 메커니즘이기 때문입니다.
- 필수 조치 2 (장기 트랜잭션 관리):
- 읽기 복제본 생성 시 RDS는 소스 DB의 스냅샷을 생성합니다. 이때 장기 실행 트랜잭션(Long-running transaction)이 수행 중이면 스냅샷 생성이 지연되거나 완료되지 않을 수 있습니다.
- 따라서 복제본 생성을 시작하기 전에 실행 시간이 긴 트랜잭션이 완료되도록 기다리거나 종료해야 원활하게 복제본을 구축할 수 있습니다.
오답 노트
- A (Binlog 복제 활성화): RDS에서는 사용자가 직접
binlog설정을 켜는 것이 아니라, E(자동 백업 활성화)를 통해 간접적으로 바이너리 로깅을 활성화합니다. 따라서 AWS 관리형 서비스인 RDS의 맥락에서는 E가 더 정확한 설정 방법입니다. - B (장애 조치 우선 순위): 이는 Multi-AZ 배포에서 주 인스턴스 장애 시 어떤 예비 인스턴스가 승격될지 결정하는 설정입니다. 읽기 복제본 생성과는 무관합니다.
- D (글로벌 테이블): Amazon DynamoDB의 기능입니다. RDS와는 관련이 없습니다.
Amazon RDS 읽기 복제본 (Read Replica)
- 목적: 읽기 중심의 트래픽을 분산하여 기본 DB 인스턴스의 부하를 줄이고 성능을 향상시킴.
- 작동 방식: 기본 인스턴스의 스냅샷을 기반으로 생성되며, 이후 비동기식(Asynchronous)으로 데이터 변경 사항(Binary Log)을 복제함.
- 전제 조건:
- 자동 백업 활성화 (Backup Retention Period > 0).
- 장기 트랜잭션이 없을 것 (생성 속도 및 초기 지연 방지).
들어오는 요청을 Amazon Simple Queue Service(Amazon SQS)로 라우팅합니다. 대기열 크기에 따라 EC2 자동 확장 그룹을 구성합니다. 대기열에서 읽도록 소프트웨어를 업데이트합니다.
- 문제점:
- 데이터 손실: 트래픽 폭주 시 EC2가 처리하지 못하고 요청을 누락함.
- 성능 병목: CPU 사용률 100% 지속 (동기식 처리의 한계).
- 해결책 (비동기 아키텍처 도입 - Decoupling):
- SQS (버퍼링): 들어오는 요청을 처리하기 전에 SQS 대기열에 먼저 저장합니다. 이렇게 하면 EC2가 바쁘더라도 요청은 대기열에 안전하게 보관되므로 데이터 손실이 방지됩니다.
- Auto Scaling (확장): 대기열에 쌓인 메시지 수(Queue Depth)를 기준으로 EC2 인스턴스를 자동으로 늘리거나 줄이는 Auto Scaling을 구성합니다.
- 결과: 시스템은 들어오는 부하를 탄력적으로 처리하며, 처리 용량을 초과하는 요청은 잠시 대기할 뿐 사라지지 않습니다.
오답 노트
- A (ELB + 사본): 로드 밸런서는 트래픽을 분산시키지만, 백엔드 서버가 모두 바쁜 경우(CPU 100%) 여전히 요청이 실패하거나 타임아웃될 수 있습니다. "버퍼"가 없기 때문입니다.
- B (VPC 엔드포인트): 네트워크 보안 및 경로 최적화 도구일 뿐, CPU 과부하나 요청 누락 문제를 해결하는 컴퓨팅 확장 솔루션이 아닙니다.
- C (수직 확장 - Scale Up): 더 큰 인스턴스로 바꾸면 일시적으로 해결될 수 있지만, 트래픽이 더 늘어나면 결국 다시 한계에 부딪힙니다. 또한 인스턴스를 중지/시작하는 동안 다운타임이 발생합니다.
1. 비동기식 결합 해제 (Decoupling)
- 개념: 컴포넌트 간의 직접적인 연결을 끊고 중간에 큐(Queue)를 두는 아키텍처.
- 장점:
- 생산자(Producer)와 소비자(Consumer)의 속도 차이를 완충.
- 장애 격리 (소비자가 죽어도 요청은 큐에 남음).
- 확장성 확보.
2. SQS 기반 오토 스케일링 (Scaling based on SQS)
- 지표:
ApproximateNumberOfMessagesVisible(대기열에 쌓인 처리 가능한 메시지 수). - 방식: "메시지 1000개당 인스턴스 1대 추가"와 같은 정책(Target Tracking Policy)을 설정하여 부하에 따라 유동적으로 인프라를 운영.
Amazon FSx for Windows File Server 파일 시스템을 만듭니다. 파일 시스템을 원본 서버에 연결합니다. 애플리케이션 서버를 파일 시스템에 연결합니다.
- 요구 사항 분석:
- 프로토콜: SMB (Server Message Block) 지원 필수.
- 관리 유형: 완전 관리형 (Fully Managed) 서비스여야 함.
- 환경: AWS 클라우드 내부의 애플리케이션 (Hybrid 아님).
- 해결책 (FSx for Windows File Server):
- 네이티브 호환성: 실제 Windows Server를 기반으로 구축되어 SMB 프로토콜을 완벽하게 지원함.
- 완전 관리형: 하드웨어 프로비저닝, 패치 적용, 백업 등을 AWS가 관리함.
- 공유 스토리지: 수천 개의 EC2 인스턴스에서 동시에 액세스 가능.
프로토콜별 AWS 파일 스토리지 선택 가이드 (빈출):
- SMB (Windows) + Active Directory 통합: Amazon FSx for Windows File Server.
- NFS (Linux): Amazon EFS.
- Lustre (HPC, 고성능 컴퓨팅): Amazon FSx for Lustre.
- iSCSI (온프레미스 연동): Storage Gateway (Volume Gateway).
죄송합니다. 방금 문제에 대한 [관련 핵심 용어 및 개념 정리] 섹션을 누락했습니다. 바로 보충해 드리겠습니다.
1. AWS 파일 스토리지 서비스 비교 (프로토콜 기준)
| 서비스 | Amazon FSx for Windows | Amazon EFS | Amazon FSx for Lustre |
|---|---|---|---|
| 프로토콜 | SMB (Server Message Block) | NFS (Network File System) | Lustre (고성능 병렬) |
| 운영 체제 | Windows (Linux도 마운트 가능) | Linux (Windows 미지원) | Linux |
| 주요 특징 | Active Directory(AD) 통합, 완전 관리형 Windows 파일 서버 | 자동 확장, POSIX 호환, Lambda/Fargate 연결 용이 | S3와 연동하여 초고속 처리(HPC, 머신러닝) |
| 시험 포인트 | "SMB", "Windows", "AD 통합" 키워드 등장 시 1순위 정답. | "Linux", "NFS", "여러 AZ 공유" 키워드 등장 시 정답. | "HPC", "S3 데이터 가속", "병렬 처리" 키워드 등장 시 정답. |
2. AWS Storage Gateway (하이브리드 스토리지)
- 목적: 온프레미스 환경과 AWS 클라우드 스토리지를 연결하는 가교 역할. (문제에서는 "AWS 클라우드에 호스팅된 애플리케이션"이라고 했으므로 온프레미스용인 게이트웨이는 부적합).
- 유형:
- File Gateway: S3를 NFS/SMB로 온프레미스에 제공.
- Volume Gateway: S3를 iSCSI 블록 스토리지(디스크)로 제공.
- Tape Gateway: 가상 테이프 라이브러리(VTL)로 백업 데이터 저장.
Amazon S3를 대상으로 사용합니다. S3 Lifecycle 정책을 활성화하여 90일 후에 로그를 S3 Standard-Infrequent Access(S3 Standard-IA)로 전환합니다.
- 요구 사항 분석:
- 로그 대상: VPC Flow Logs (네트워크 트래픽).
- 액세스 패턴: 처음 90일은 빈번(Frequently), 그 이후는 간헐적(Intermittently).
- 장기 보관: 90일 이후에도 데이터가 삭제되면 안 됨.
- 해결책 (S3 + 수명 주기 정책):
- S3로 전송: VPC Flow Logs는 로그를 Amazon S3로 직접 전송할 수 있습니다.
- 비용 최적화: 처음 90일은 기본 스토리지(Standard)에 저장하여 빈번한 액세스를 처리하고, 90일이 지나면 수명 주기 정책(Lifecycle Policy)을 통해 저장 비용이 더 저렴한 S3 Standard-IA(Infrequent Access) 계층으로 자동 이동시키는 것이 가장 적절합니다.
1. Amazon S3 스토리지 클래스 (빈출 패턴)
- S3 Standard: 자주 액세스하는 데이터, 짧은 지연 시간, 높은 처리량. (기본값)
- S3 Standard-IA (Infrequent Access): 자주 액세스하지 않지만 필요할 때 즉시 액세스해야 하는 데이터. 저장 비용은 저렴하지만 검색 비용이 발생. (최소 보관 기간 30일).
- S3 Intelligent-Tiering: 액세스 패턴을 알 수 없거나 자주 바뀌는 경우 사용. (모니터링 비용 발생).
- S3 Glacier: 아카이브(백업) 데이터. 저장 비용은 가장 저렴하지만 데이터를 꺼내는 데 시간(분~시간)이 걸림.
2. VPC Flow Logs 대상
- CloudWatch Logs: 로그 검색, 필터링, 지표 생성 및 알람 설정에 유리. (저장 비용이 S3보다 비쌈).
- Amazon S3: 대량의 로그를 저렴하게 장기 보관, Athena를 사용한 쿼리 분석, 다른 계정으로 로그 전달 시 유리.
- Kinesis Data Firehose: 실시간 분석 도구(Splunk, Datadog 등)로 로그를 스트리밍할 때 사용.
- 요구 사항 분석:
- 동시 액세스 (Simultaneous Access): 여러 EC2 인스턴스가 동시에 파일을 읽고 써야 함.
- 기본 제공 중복성 (Built-in Redundancy): 중요 자산이므로 장애 대비가 되어 있어야 함.
- 확장성: 파일 수 증가에 따라 자동 확장 필요.
- 해결책 (Amazon EFS):
- 공유 파일 스토리지: EFS는 표준 NFS 프로토콜을 사용하여 수천 개의 EC2 인스턴스가 동시에 연결할 수 있는 완전 관리형 파일 시스템임.
- 고가용성: 데이터가 기본적으로 여러 가용 영역(Multi-AZ)에 자동으로 복제되어 저장되므로 단일 데이터 센터 장애 시에도 데이터가 보존됨.
- 자동 확장: 파일을 추가하거나 삭제하면 스토리지 용량이 자동으로 늘어나거나 줄어듦 (프로비저닝 불필요).
AWS 스토리지 서비스 사용 사례 구분 (빈출)
| 특징 | Amazon EBS (Block) | Amazon EFS (File) | Amazon S3 (Object) |
|---|---|---|---|
| 액세스 방식 | 단일 인스턴스 연결 (R/W) | 수천 개 인스턴스 동시 연결 (NFS) | HTTP/HTTPS 웹 API (어디서나 접근) |
| 주요 용도 | OS 부팅 볼륨, 고성능 DB, 미션 크리티컬 앱 | 콘텐츠 관리(CMS), 웹 서빙, 홈 디렉토리 공유 | 정적 웹 호스팅, 백업, 미디어 저장, 데이터 레이크 |
| OS 지원 | 모든 OS | Linux (Windows 미지원) | OS 무관 |
| 가용성 | 단일 AZ 내 복제 | Multi-AZ 복제 (리전 레벨) | Multi-AZ 복제 (리전 레벨) |
- 시험 팁: "여러 EC2 인스턴스", "동시 액세스", "Linux", "공유 스토리지" 키워드가 나오면 EFS가 정답일 확률이 매우 높습니다. (Windows일 경우 FSx for Windows).
- IAM 정책 평가 로직:
- 기본 거부(Implicit Deny): 명시적으로 허용되지 않은 모든 작업은 거부됩니다.
- 명시적 허용(Explicit Allow):
Allow정책이 있으면 작업이 허용됩니다. - 명시적 거부(Explicit Deny):
Deny정책은 어떤Allow정책보다 우선합니다. (최우선 순위)
- 정책 분석:
- Policy 1 (Allow):
ec2:*: 모든 EC2 작업 허용 (생성, 삭제, 시작, 중지 등 포함).ds:*: 모든 Directory Service 작업 허용.iam,logs: 읽기(Get, List, Describe) 권한만 허용.
- Policy 2 (Deny):
ds:Delete*: Directory Service의 모든 삭제 작업 거부.
보기 분석
- A. IAM 사용자 삭제 (거부됨):
- Policy 1에서
iam:Get*,iam:List*만 허용했습니다.iam:DeleteUser권한이 없으므로 암시적 거부(Implicit Deny) 상태입니다.
- B. 디렉토리 삭제 (거부됨):
- Policy 1에서
ds:*로 허용했지만, Policy 2에서ds:Delete*를 명시적으로 거부(Explicit Deny)했습니다. 명시적 거부가 우선하므로 삭제할 수 없습니다.
- C. Amazon EC2 인스턴스 삭제 (허용됨):
- Policy 1에서
ec2:*를 통해 모든 EC2 권한을 허용했습니다. - Policy 2에는 EC2와 관련된 거부 정책이 없습니다.
- 따라서 EC2 인스턴스 종료(Terminate) 작업이 가능합니다.
- D. Amazon CloudWatch Logs에서 로그 삭제 (거부됨):
- Policy 1에서
logs:Get*,logs:Describe*만 허용했습니다.logs:Delete*권한이 없으므로 암시적 거부 상태입니다.
IAM 정책 평가 순서
- Deny 평가: 명시적
Deny가 하나라도 있으면 즉시 거부(Deny). - Allow 평가: 명시적
Deny가 없고, 명시적Allow가 있으면 허용(Allow). - 기본값: 위 두 조건에 해당하지 않으면 거부(Deny) (암시적 거부).
보안 그룹 ID를 소스 또는 대상으로 사용하여 보안 그룹 규칙을 만듭니다.
- 문제 원인: 현재 규칙이 VPC CIDR나 서브넷 CIDR처럼 너무 광범위하게 열려 있어 '최소 권한 원칙'을 위배함.
- 해결책 (Security Group Referencing):
- 상호 참조: 3계층 아키텍처(Web → App → DB)에서 하위 계층(예: DB)의 인바운드 규칙 소스(Source)로 상위 계층(예: App)의 보안 그룹 ID(sg-xxxxx)를 직접 지정해야 합니다.
- 동적 환경 대응: Auto Scaling으로 인해 상위 계층 인스턴스의 IP가 계속 바뀌거나 개수가 늘어나도, 보안 그룹 ID를 참조하면 별도의 규칙 수정 없이 자동으로 허용됩니다.
- 최소 권한: 같은 서브넷에 있는 다른 서버(예: Bastion, Dev 서버)의 접근을 차단하고, 오직 지정된 보안 그룹에 속한 인스턴스만 접근을 허용하므로 보안성이 가장 높습니다.
오답 노트
- 인스턴스 ID: 인스턴스는 수시로 생성/삭제될 수 있습니다(특히 Auto Scaling 환경). 그때마다 규칙을 수동으로 업데이트하는 것은 운영상 불가능합니다.
- VPC/서브넷 CIDR: CIDR 블록을 허용하면, 해당 네트워크 대역에 있는 모든 인스턴스(해킹된 인스턴스나 테스트 서버 포함)가 접근할 수 있게 되므로 '최소 권한 원칙'에 위배됩니다.
Security Group Referencing (보안 그룹 참조)
- 정의: 방화벽 규칙의 소스/대상에 IP 주소 대신 보안 그룹 ID를 입력하는 기능.
- 장점:
- 유동 IP 관리: 클라우드 환경의 동적 IP 변화에 완벽 대응.
- 논리적 그룹핑: "App 서버들은 DB에 접속 가능"과 같이 역할 기반의 접근 제어 구현.
B. 버킷에서 버전 관리를 활성화합니다.
D. 버킷에서 MFA 삭제를 활성화합니다.
- 요구 사항 분석:
- 실수 방지: 문서를 실수로 삭제하는 것을 막아야 함.
- 모든 버전 가용성: 문서의 수정 이력을 모두 보존하고 복구할 수 있어야 함.
- 작업 허용: 사용자는 다운로드(Read), 수정(Modify), 업로드(Write)가 가능해야 함.
- 해결책 (Versioning + MFA Delete):
- 버전 관리(Versioning): 이 기능을 켜면 같은 이름의 파일을 덮어쓰거나 삭제해도 기존 데이터가 사라지지 않고 이전 버전으로 보관됩니다. 이는 "모든 버전의 문서를 사용"하게 해주며, 실수로 삭제 시 복구할 수 있는 기본 메커니즘을 제공합니다.
- MFA Delete: 버전 관리가 활성화된 버킷에 추가적인 안전장치를 거는 기능입니다. 객체의 버전을 영구 삭제하거나 버킷의 버전 관리 기능을 끄려 할 때, 반드시 MFA(다중 요소 인증) 코드를 입력하도록 강제합니다. 이를 통해 관리자 실수나 계정 탈취로 인한 데이터 영구 손실을 강력하게 방지할 수 있습니다.
1. S3 Versioning (버전 관리)
- 기능: 동일한 키(파일 이름)를 가진 객체의 여러 변형을 보존.
- 삭제 시 동작: 파일을 '삭제'하면 실제 데이터가 지워지는 것이 아니라 '삭제 마커(Delete Marker)'가 최신 버전으로 올라가고, 기존 데이터는 이전 버전으로 남음. (언제든 복구 가능).
- 덮어쓰기 시 동작: 새로운 데이터가 최신 버전이 되고, 기존 데이터는 이전 버전으로 보관됨.
2. MFA Delete
- 기능: 다음 두 가지 작업 수행 시 MFA(OTP 등) 인증을 강제함.
- 객체의 특정 버전을 영구 삭제.
- 버킷의 버전 관리(Versioning) 기능을 중지(Suspend).
- 설정 방법: AWS Management Console에서는 설정 불가하며, 반드시 AWS CLI를 통해서만 루트 계정(Root User) 권한으로 설정 가능.
Amazon CloudWatch 메트릭 스트림을 사용하여 EC2 자동 확장 상태 데이터를 Amazon Kinesis Data Firehose로 전송합니다. Amazon S3에 데이터를 저장합니다.
- 요구 사항 분석:
- 서버리스 솔루션: 인프라 관리가 필요 없는 관리형 서비스여야 함.
- 데이터 저장소: Amazon S3.
- 거의 실시간(Near Real-time): 대시보드 업데이트를 위해 데이터가 지속적으로 흘러야 함.
- 시작 속도 영향 없음: EC2 인스턴스 내부에서 무언가를 설치하거나 실행하면 안 됨.
- 해결책 (CloudWatch Metric Streams + Kinesis Data Firehose):
- 서버리스 & 실시간: CloudWatch Metric Streams는 CloudWatch 지표(Auto Scaling 그룹의 상태 데이터 포함)를 거의 실시간으로 목적지로 스트리밍하는 완전 관리형 기능입니다. Kinesis Data Firehose 역시 서버리스 서비스로, 스트리밍 데이터를 받아 S3로 자동 전송(Delivery)합니다.
- 성능 영향 없음: 이 프로세스는 AWS 인프라 레벨(Control Plane)에서 이루어지므로, 개별 EC2 인스턴스의 부팅이나 동작에 전혀 영향을 주지 않습니다.
오답 노트
- EMR 클러스터: EMR은 빅데이터 처리를 위한 관리형 하둡 프레임워크로, 단순히 지표를 수집하여 옮기는 작업에는 과도한 비용과 관리가 필요한 솔루션입니다(Not Serverless).
- EventBridge 일정 + Lambda: "일정에 따라(On a schedule)" Lambda를 호출하는 것은 폴링(Polling) 방식입니다. 이는 실시간 요구 사항을 충족하기 어려우며, 데이터 수집 시차(Latency)가 발생합니다.
- 부트스트랩 스크립트 + Kinesis Agent: EC2가 시작될 때마다 스크립트를 실행해 에이전트를 설치하는 방식은 인스턴스의 부팅 시간(Launch Speed)을 지연시킵니다. 문제의 "시작 속도에 영향을 미쳐서는 안 된다"는 요건에 정면으로 위배됩니다.
Amazon CloudWatch Metric Streams
- 기능: CloudWatch 지표를 Kinesis Data Firehose나 타사 서비스(Datadog, Splunk 등)로 지속적으로 스트리밍하는 기능.
- 장점:
- 속도: 1분 단위의 지표가 아닌, 더 빠른 주기로 데이터를 전송하여 거의 실시간 대시보드 구현 가능.
- 통합: Kinesis Data Firehose와 결합하여 S3, Redshift, Elasticsearch 등으로 데이터를 손쉽게 파이프라이닝.
AWS Glue 추출, 변환 및 로드(ETL) 작업을 생성하여 .csv 파일을 Parquet 형식으로 변환하고 출력 파일을 S3 버킷에 넣습니다. 각 S3 PUT 이벤트에 대해 ETL 작업을 호출하기 위한 AWS Lambda 함수를 생성합니다.
핵심 요약
- 요구 사항 분석:
- 대용량 파일: 1GB 크기의 CSV 파일 (메모리 집약적).
- 빈도: 매시간 수백 개 (높은 처리량 필요).
- 변환: CSV → Parquet.
- 제약 사항: 가장 적은 운영 오버헤드 (Least Operational Overhead).
- 해결책 (AWS Glue ETL):
- 관리형 서비스: AWS Glue는 서버를 관리할 필요가 없는 완전 관리형 서버리스 ETL 서비스입니다.
- 대용량 처리: Glue는 내부적으로 Apache Spark를 사용하여 분산 처리를 수행하므로, 1GB 이상의 대용량 파일도 메모리 오류 없이 안정적으로 변환할 수 있습니다.
- 자동화: S3 이벤트(PUT) 발생 시 Lambda를 통해 Glue 작업을 트리거하는 패턴은 이벤트 기반 데이터 파이프라인의 표준 아키텍처입니다. (최신 기능으로는 S3 이벤트 알림이 직접 Glue를 트리거할 수도 있지만, 시험 문맥상 Lambda 중계가 정답인 경우가 많습니다).
오답 노트
- Lambda 직접 변환:
- AWS Lambda는 최대 메모리가 10GB(이전에는 3GB)이고 실행 시간이 15분으로 제한됩니다.
- 1GB CSV 파일을 메모리에 로드하여 변환하려면 파일 크기의 몇 배에 달하는 메모리가 필요할 수 있어 OOM(Out of Memory) 오류나 타임아웃이 발생할 위험이 매우 큽니다. 대용량 배치 처리에는 적합하지 않습니다.
- Apache Spark 작업 직접 생성:
- "Spark 작업"을 만든다는 것은 일반적으로 Amazon EMR 클러스터를 프로비저닝하거나 관리해야 함을 의미합니다. 이는 AWS Glue(Serverless Spark)를 사용하는 것보다 운영 오버헤드가 훨씬 큽니다.
- Glue Crawler + Athena + 예약:
- 실시간성 부족: "예약(Scheduled)" 방식은 파일을 업로드할 때마다 즉시 변환하는 요구 사항(Event-driven)에 비해 지연이 발생합니다.
- 복잡성: 크롤러, 아테나 쿼리, 람다 등을 모두 오케스트레이션해야 하므로 구성이 복잡합니다.
1. AWS Glue
- 정의: 분석, 머신 러닝 및 애플리케이션 개발을 위해 데이터를 쉽게 탐색, 준비, 그리고 결합할 수 있도록 지원하는 완전 관리형 ETL(Extract, Transform, Load) 서비스.
- 특징:
- Serverless: 인프라 프로비저닝 불필요.
- 용도: CSV, JSON 등을 Parquet/ORC로 변환, 데이터 정제, 스키마 변경.
- 기반 기술: Apache Spark.
2. Apache Parquet
- 정의: 하둡(Hadoop) 생태계에서 사용되는 열 지향(Columnar) 스토리지 포맷.
- 장점:
- 압축률: 같은 데이터라도 CSV보다 용량이 훨씬 작음 (비용 절감).
- 성능: Athena, Redshift Spectrum 등으로 쿼리할 때 필요한 열만 읽으므로 속도가 매우 빠르고 스캔 비용이 절약됨.
3. ETL 아키텍처 패턴
- S3 Event -> Lambda -> Glue Job: 파일이 S3에 들어오자마자(Event) Lambda가 감지하여 무거운 작업(Glue)을 실행시키는 전형적인 이벤트 기반 데이터 처리 패턴.
AWS Backup에서 백업 볼트를 만들어 RDS 백업을 보관합니다. 일일 일정과 생성 후 2년의 만료 기간이 있는 새 백업 계획을 만듭니다. RDS DB 인스턴스를 백업 계획에 할당합니다.
- 요구 사항 분석:
- 대상: Amazon RDS 데이터베이스.
- 보존 기간: 최소 2년 (장기 보관).
- 빈도: 매일(Daily).
- 특성: 일관성 있고 복원 가능해야 함.
- 해결책 (AWS Backup):
- RDS 자동 백업의 한계: Amazon RDS의 기본 자동 백업 기능은 최대 보존 기간이 35일로 제한되어 있습니다. 따라서 2년 보관 요구 사항을 충족할 수 없습니다.
- AWS Backup: 여러 AWS 서비스(RDS, EBS, DynamoDB, EFS 등)의 백업을 중앙에서 관리하고 정책을 자동화하는 서비스입니다.
- 장기 보관: AWS Backup을 사용하면 수년 이상의 장기 보존 정책을 설정할 수 있으며, 일일 백업 일정과 만료(Lifecycle) 규칙을 통해 2년 후 자동 삭제되도록 구성할 수 있습니다. 이는 RDS 스냅샷을 생성하여 안전하게 관리하므로 일관성과 복원 가능성을 보장합니다.
오답 노트
- RDS 백업 윈도우 + DLM:
- 앞서 언급했듯 RDS 기본 설정으로는 35일까지만 스냅샷을 보존할 수 있어 2년 설정이 불가능합니다.
- Amazon DLM(Data Lifecycle Manager)은 주로 EBS 볼륨의 스냅샷 수명 주기를 관리하는 데 사용됩니다. RDS 장기 백업에는 AWS Backup이 표준 솔루션입니다.
- CloudWatch Logs:
- 로그는 데이터베이스의 트랜잭션 기록일 뿐, 데이터베이스 전체를 복원할 수 있는 전체 백업(Full Backup)이 아닙니다. 로그만으로 2년 전 데이터를 복구하는 것은 매우 비효율적이며 사실상 불가능에 가깝습니다.
- AWS DMS + S3:
- DMS CDC(변경 데이터 캡처)는 데이터 변경 사항을 스트리밍하여 데이터 레이크(Data Lake)를 구축하거나 분석하는 용도에 적합합니다.
- 이를 통해 특정 시점의 데이터베이스를 통째로 복원(Restore)하는 것은 스냅샷 방식에 비해 복구 시간(RTO)이 매우 길고 복잡성이 높아 백업 솔루션으로 적합하지 않습니다.
AWS Backup
- 정의: 클라우드 내 및 온프레미스(Storage Gateway 경유)의 AWS 서비스 전체에 대한 데이터 보호를 중앙 집중화하고 자동화하는 완전 관리형 서비스.
- 주요 기능:
- 중앙 집중식 정책 관리: 백업 계획(Plan)을 생성하여 빈도, 백업 윈도우, 보존 기간(Lifecycle) 등을 설정.
- 지원 서비스: EC2, EBS, RDS, DynamoDB, EFS, FSx, Aurora, Storage Gateway 등.
- 규정 준수: 백업 정책이 규정 준수 요구 사항(예: 2년 보관)을 충족하는지 모니터링 가능.
파일 시스템을 Active Directory에 가입(Join)하여 액세스를 제한합니다.
- 요구 사항:
- Amazon FSx for Windows File Server 사용.
- 온프레미스 Active Directory 그룹을 사용하여 파일/폴더 접근 제어 (SMB).
- 해결책 (Active Directory Join):
- Windows 네이티브 통합: FSx for Windows는 실제 Windows Server 기반입니다. 따라서 Windows 파일 서버와 똑같이 Active Directory(AD) 도메인에 조인해야 AD 사용자 및 그룹을 인식할 수 있습니다.
- 권한 관리 (ACL): 도메인에 가입되면 표준 Windows ACL(액세스 제어 목록)을 사용하여 폴더 및 파일에 대한 권한을 온프레미스 AD 그룹에 직접 부여할 수 있습니다. (IAM은 관여하지 않습니다).
Amazon FSx for Windows File Server의 권한 관리
- 관리 액세스 (AWS API): 파일 시스템 생성/삭제, 백업 관리 등 → AWS IAM 사용.
- 데이터 액세스 (SMB): 파일 읽기/쓰기, 폴더 권한 → Windows ACL (Active Directory) 사용.
- Self-managed AD: 온프레미스 AD 또는 EC2에 설치된 AD (VPN/Direct Connect 필요).
- AWS Managed Microsoft AD: AWS에서 관리하는 AD 서비스.
`•.¸¸.•´´¯`••._.• 🎀 𝒸𝓇𝒶𝓏𝓎 𝓅𝓈𝓎𝒸𝒽💞𝓅𝒶𝓉𝒽 🎀 •._.••`¯´´•.¸¸.•`