AWS DEA-C01 문제로 공부하기 — Day 05
Secrets Manager 자격증명 교체, S3 수명주기 정책, Kinesis 실시간 수집, Lake Formation PII 접근 제어, Glue 데이터 품질 최신성 알림까지 — 5문제 핵심 정리.
AWS Secrets Manager는 DB 자격증명·API 키 등을 안전하게 저장하고 자동으로 교체(Rotation)하는 서비스입니다. 애플리케이션은 코드 변경 없이 API 호출로 최신 자격증명을 가져오므로 운영 부담이 최소화됩니다. DEA-C01 보안 도메인 단골 정답입니다.
한 의료 회사가 환자 기록을 온프레미스 MySQL 데이터베이스에 저장합니다. 이 회사는 MySQL 데이터베이스에 접근하기 위한 애플리케이션을 만듭니다. 회사는 환자 기록을 보호하기 위해 보안 프로토콜을 시행해야 합니다. 이 회사는 현재 무단 접근 위험을 최소화하기 위해 30일마다 데이터베이스 자격 증명을 교체하고 있습니다. 회사에서는 자격 증명 순환마다 애플리케이션 코드를 수정할 필요가 없는 솔루션을 원합니다. 어떤 솔루션이 운영 오버헤드를 최소화하면서 이 요구 사항을 충족할 수 있을까요?
-
AAWS Key Management Service(AWS KMS)를 사용하여 암호화 키를 생성합니다. 자동 키 교체를 구성합니다. 암호화된 자격 증명을 Amazon DynamoDB 테이블에 저장합니다.❌ AWS KMS(Key Management Service) — 암호화 키를 생성·관리하는 서비스. KMS는 암호화 키를 교체하는 것이지 DB 자격증명(ID/PW)을 교체하는 서비스가 아님. DynamoDB에 저장해도 교체 로직을 별도로 구현해야 함.
-
BIAM 역할에 데이터베이스에 대한 액세스 권한을 할당합니다. IAM 역할을 통해 임시 자격 증명을 얻도록 애플리케이션을 구성합니다.❌ IAM 역할 임시 자격증명은 AWS 서비스 접근용. 온프레미스 MySQL은 AWS 서비스가 아니므로 IAM 인증을 사용할 수 없음. AWS RDS IAM 인증과 혼동 주의.
-
C암호화된 Amazon S3 버킷에 자격 증명을 저장합니다. S3 수명 주기 정책을 사용하여 매달 자격 증명을 순환합니다. 버킷 정책을 사용하여 액세스를 제어합니다.❌ S3 수명 주기 정책은 객체를 다른 스토리지 클래스로 이동하거나 삭제하는 기능. 자격증명을 새 값으로 교체하는 기능이 없음. 교체 로직 전체를 수동으로 구현해야 해 운영 부담이 큼.
-
DAWS Secrets Manager를 사용하여 자격 증명을 자동으로 교체합니다. 애플리케이션이 API 호출을 사용하여 자격 증명을 검색하도록 허용합니다.✅ AWS Secrets Manager — 금고 관리인이 주기적으로 열쇠를 자동 교체하고, 직원은 금고에 열쇠 달라고 요청하면 항상 최신 열쇠를 받는 시스템. 자동 교체 주기 설정(30일) + 애플리케이션은 API 호출로 항상 최신 자격증명 조회 → 코드 수정 불필요.
| 서비스 | 주 용도 | 자동 교체 | 코드 수정 불필요 |
|---|---|---|---|
| Secrets Manager | DB 자격증명·API 키 관리 | ✓ 내장 | ✓ |
| KMS | 암호화 키 생성·관리 | 키 교체만 | 자격증명 관리 아님 |
| Parameter Store | 설정값·비밀 저장 | 수동 교체 | 교체 로직 별도 구현 |
| S3 버킷 | 파일 스토리지 | ✗ | ✗ |
"자격증명 자동 교체 + 코드 수정 불필요" → AWS Secrets Manager
KMS = 암호화 키 관리 (자격증명 교체 아님)
온프레미스 DB = IAM 역할 인증 불가
S3 수명주기 정책으로 데이터 접근 빈도에 따라 스토리지 클래스를 자동 전환해 비용을 최적화합니다. 고가용성 조건에서는 단일 AZ인 One Zone-IA를 제외해야 하며, 장기 보관엔 Glacier Deep Archive가 가장 저렴합니다.
현재 한 회사는 S3 Standard 스토리지 클래스를 사용하여 Amazon S3에 모든 데이터를 저장하고 있습니다. 데이터 엔지니어가 데이터 액세스 패턴을 조사하여 추세를 파악했습니다. 처음 6개월 동안 대부분의 데이터 파일은 매일 여러 번 액세스됩니다. 6개월에서 2년 사이에는 대부분의 데이터 파일에 한 달에 한두 번 액세스됩니다. 2년이 지나면 데이터 파일은 1년에 한두 번만 액세스됩니다. 데이터 엔지니어는 S3 수명 주기 정책을 사용하여 새로운 데이터 스토리지 규칙을 개발해야 합니다. 새로운 스토리지 솔루션은 계속해서 고가용성을 제공해야 합니다. 가장 비용 효율적인 방식으로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
-
A6개월 후에 객체를 S3 One Zone-Infrequent Access(S3 One Zone-IA)로 전환합니다. 2년 후에 객체를 S3 Glacier Deep Archive로 전송합니다.❌ S3 One Zone-IA — 단일 가용 영역(AZ)에만 데이터 저장. 고가용성 요건 위반. AZ 장애 시 데이터 손실 가능.
-
B6개월 후에 객체를 S3 One Zone-Infrequent Access(S3 One Zone-IA)로 전환합니다. 2년 후에 객체를 S3 Glacier 유연한 검색으로 전송합니다.❌ One Zone-IA로 인한 고가용성 요건 위반. 추가로 Glacier Flexible Retrieval(유연한 검색)은 Deep Archive보다 비쌈 — 연 1~2회 접근엔 Deep Archive가 더 비용 효율적.
-
C6개월 후에 객체를 S3 Standard-Infrequent Access(S3 Standard-IA)로 전환합니다. 2년 후에 객체를 S3 Glacier 유연한 검색으로 전송합니다.❌ S3 Standard-IA — 다중 AZ 저장으로 고가용성 충족. 하지만 2년 후 단계에서 Glacier Flexible Retrieval보다 Glacier Deep Archive가 약 4배 더 저렴. 연 1~2회 접근 패턴엔 Deep Archive가 최적.
-
D6개월 후에 객체를 S3 Standard-Infrequent Access(S3 Standard-IA)로 전환합니다. 2년 후에 객체를 S3 Glacier Deep Archive로 전송합니다.✅ S3 Standard-IA — 다중 AZ 저장, 고가용성 유지, 월 1~2회 접근에 Standard보다 저렴. S3 Glacier Deep Archive — AWS에서 가장 저렴한 스토리지, 연 1~2회 접근 패턴에 최적. 두 조건 모두 충족.
| 클래스 | 가용성 | AZ 수 | 적합 접근 패턴 | 비용 |
|---|---|---|---|---|
| S3 Standard | 99.99% | 3+ | 매일 여러 번 | 높음 |
| S3 Standard-IA | 99.9% | 3+ | 월 1~2회 | 중간 |
| S3 One Zone-IA | 99.5% | 1 (위험) | 월 1~2회 | 중간(저) |
| Glacier Flexible | 99.99% | 3+ | 분기 1회 | 낮음 |
| Glacier Deep Archive | 99.99% | 3+ | 연 1~2회 | 최저 |
고가용성 요건 → One Zone-IA 제외 (단일 AZ = 위험)
월 1~2회 → Standard-IA (다중 AZ, 고가용성)
연 1~2회 → Glacier Deep Archive (AWS 최저 비용)
Amazon Kinesis Data Streams는 수백만 이벤트를 밀리초 단위로 실시간 수집하는 완전 관리형 스트리밍 서비스입니다. MSK(Kafka)보다 운영 부담이 낮고, 배치보다 지연이 낮아 DEA-C01 실시간 수집 + 비용 효율 조합의 정답 패턴입니다.
한 미디어 회사가 웹사이트와 모바일 앱 전반에 걸쳐 발생하는 고객 활동 이벤트를 실시간으로 처리하는 분석 파이프라인을 구축하고자 합니다. 이 회사는 최소한의 지연 시간으로 수백만 건의 이벤트를 수집할 수 있는 솔루션을 원합니다. 또한, 데이터 손실을 방지하기 위해 확장성과 내구성이 뛰어난 솔루션을 필요로 합니다. 어떤 솔루션이 이러한 요구 사항을 가장 비용 효율적인 방식으로 충족할까요?
-
A데이터를 수집하고, AWS Lambda 함수를 사용하여 데이터를 처리하고, 분석을 위해 결과를 Amazon Redshift에 저장하도록 Amazon Kinesis Data Streams 파이프라인을 설정합니다.✅ Amazon Kinesis Data Streams — 실시간 컨베이어 벨트. 수백만 이벤트를 밀리초 단위로 수집, 자동 샤드 확장, 24시간~365일 데이터 보존으로 내구성 보장. 완전 관리형이라 운영 부담 낮고 Lambda와 직접 연동 가능. 비용 효율적.
-
BAWS Glue 작업을 예약하여 10분마다 Amazon S3에서 사용자 상호 작용 로그를 가져옵니다. AWS Glue 작업이 분석을 위해 데이터를 변환하고 Amazon Redshift에 저장하도록 구성합니다.❌ 10분 배치 주기는 실시간이 아님. 최소 지연 시간 요건과 정반대. 로그가 S3에 쌓이는 동안 지연 발생.
-
CAmazon Managed Streaming for Apache Kafka(Amazon MSK) 클러스터를 배포합니다. 자체 관리형 컨슈머를 사용하여 데이터를 실시간으로 처리하고 배포합니다. 향상된 분석을 위해 Amazon Redshift와 통합합니다.❌ Amazon MSK(Managed Streaming for Kafka) — 완전 관리형 Kafka. 기술적으로 가능하지만 자체 관리형 컨슈머를 별도 구현해야 하고 Kinesis보다 운영 복잡도와 비용이 높음. 기존 Kafka 마이그레이션이 아닌 신규 구축엔 Kinesis가 더 효율적.
-
DAmazon S3 이벤트 알림을 구성하여 새로운 상호 작용 로그 파일이 생성될 때마다 AWS Lambda 함수를 호출합니다. 분석 결과를 Amazon Redshift에 저장합니다.❌ S3 이벤트 알림은 파일 단위 처리. 수백만 건의 개별 이벤트를 실시간으로 수집하는 구조가 아님. 파일이 생성된 후에야 처리 시작 → 실시간이 아닌 준실시간.
| 서비스 | 지연 시간 | 운영 부담 | 비용 효율 | 실시간? |
|---|---|---|---|---|
| Kinesis Data Streams | 밀리초 | 낮음 | ✓ 높음 | ✓ |
| MSK (Kafka) | 밀리초 | 높음 | 중간 | ✓ |
| Glue 배치 | 분 단위 | 낮음 | 높음 | ✗ |
| S3 이벤트 | 초 단위 | 낮음 | 높음 | 준실시간 |
"수백만 이벤트 실시간 + 비용 효율" → Kinesis Data Streams
MSK = 기존 Kafka 마이그레이션 시 선택, 운영 복잡
Kinesis = 신규 실시간 파이프라인, 완전 관리형, 비용 효율
AWS Lake Formation 데이터 필터(Data Filter)는 열(Column)·행(Row) 단위로 접근을 제어하는 기능입니다. PII가 포함된 데이터 레이크에서 사용자 그룹별로 필요한 컬럼만 접근하게 하는 가장 간단한 방법으로 DEA-C01 거버넌스 도메인에서 자주 출제됩니다.
회사는 Amazon S3에 있는 데이터 레이크에 데이터를 저장합니다. 회사가 데이터 레이크에 저장하는 일부 데이터에는 개인 식별 정보(PII)가 포함되어 있습니다. 여러 사용자 그룹이 원시 데이터에 액세스해야 합니다. 회사는 사용자 그룹이 필요한 PII에만 액세스할 수 있도록 해야 합니다. 최소한의 노력으로 이러한 요구 사항을 충족할 수 있는 솔루션은 무엇입니까?
-
A데이터에 액세스하기 위해 백그라운드에서 Athena 쿼리를 실행하는 사용자 지정 쿼리 빌더 UI를 빌드합니다. Amazon Cognito에서 사용자 그룹을 생성합니다. 사용자의 PII 액세스 요구 사항에 따라 사용자 그룹에 액세스 수준을 할당합니다.❌ 사용자 지정 쿼리 빌더 UI를 개발하는 것은 개발 비용이 매우 높고 유지보수 부담도 큼. "최소한의 노력" 요건과 정반대.
-
BAmazon QuickSight를 사용하여 데이터에 액세스합니다. QuickSight의 열 수준 보안 기능을 사용하면 사용자가 Amazon Athena를 통해 Amazon S3에서 검색할 수 있는 PII를 제한할 수 있습니다. 사용자의 PII 액세스 요구 사항을 기반으로 QuickSight 액세스 수준을 정의합니다.❌ Amazon QuickSight — BI(비즈니스 인텔리전스) 시각화 도구. 원시 데이터에 직접 접근하는 게 아니라 시각화 레이어에서만 제어. 원시 데이터 접근 자체를 막지 못하고 QuickSight 밖의 Athena 직접 쿼리는 제어 불가.
-
C다양한 수준의 세부적인 액세스 권한을 가진 IAM 역할을 생성합니다. IAM 사용자 그룹에 IAM 역할을 할당합니다. ID 기반 정책을 사용하여 열 수준에서 사용자 그룹에 액세스 수준을 할당합니다.❌ IAM 정책으로 S3 객체 레벨 접근은 제어 가능하지만 열(Column) 수준 접근 제어는 IAM 정책으로 불가능. 열 수준 보안은 Lake Formation의 기능.
-
DAmazon Athena를 사용하여 데이터를 쿼리합니다. AWS Lake Formation을 설정하고 데이터 필터를 생성하여 회사의 IAM 역할에 대한 액세스 수준을 설정합니다. 사용자의 PII 액세스 요구 사항과 일치하는 IAM 역할에 각 사용자를 할당합니다.✅ Lake Formation 데이터 필터(Data Filter) — 도서관 사서가 특정 회원에게 특정 챕터만 열람 가능하게 설정하는 것. 열(PII 컬럼)·행 단위로 접근 제어. Athena 쿼리 시 자동으로 필터 적용 → 코드 없이 최소 노력으로 구현.
| 방법 | 열 수준 제어? | 구현 노력 | 원시 데이터 보호 |
|---|---|---|---|
| Lake Formation 데이터 필터 | ✓ | 최소 | ✓ |
| IAM 정책 | ✗ (파일 단위) | 중간 | 파일 단위만 |
| QuickSight 열 보안 | BI 레이어만 | 중간 | ✗ |
| 커스텀 쿼리 빌더 | 개발 필요 | 매우 높음 | 조건부 |
"PII 열 수준 접근 제어 + 최소 노력" → Lake Formation 데이터 필터
IAM 정책 = 파일/버킷 단위만 제어 (열 수준 불가)
Lake Formation = 열·행 단위 세밀한 접근 제어
Glue 데이터 품질 + EventBridge + SNS 조합은 데이터 최신성 등 품질 규칙 실패 시 자동으로 알림을 보내는 표준 패턴입니다. 작업 실패(Job Fail)와 데이터 최신성 미달(Data Freshness)은 서로 다른 문제임을 구분하는 것이 핵심입니다.
한 회사가 아마존 S3 버킷의 시계열 데이터를 처리하기 위해 매일 AWS Glue 워크플로우를 실행합니다. 워크플로는 데이터를 Amazon Redshift 서버리스 테이블에 로드합니다. 회사에서는 워크플로의 일부 작업이 간헐적으로 실패하는 것을 확인했습니다. 데이터 엔지니어는 Redshift 테이블에 최신 데이터가 없는 경우 알림을 받아야 합니다. 어떤 솔루션이 운영 효율성을 극대화하면서 이러한 요구 사항을 충족할까요?
-
AAWS Glue 작업 로그를 Amazon S3 버킷에 로드합니다. S3 버킷의 작업 로그에 Job.State=FAILED가 포함될 때 알림을 보내도록 Amazon CloudWatch 알람을 구성합니다.❌ 작업 실패(Job Failed)를 감지하는 것과 데이터 최신성(Freshness) 부재는 다름. 작업이 성공해도 데이터가 최신이 아닐 수 있고, 작업이 실패해도 이전 데이터가 남아있을 수 있음. 요건을 정확히 충족하지 못함.
-
BAWS Glue 데이터 품질 작업을 예약하여 데이터의 최신성을 확인합니다. 데이터 품질 규칙이 실패할 경우 Amazon Simple Notification Service(Amazon SNS) 토픽에 알림을 보내도록 Amazon EventBridge 규칙을 생성합니다.✅ Glue 데이터 품질로 최신성(Freshness) 규칙을 정의 (예: 최근 24시간 내 데이터 존재). 규칙 실패 시 EventBridge — 이벤트 버스(경보 자동 반응 시스템) — 가 감지해 SNS(Simple Notification Service) — 방송 스피커 — 로 알림 전송. 데이터 최신성을 직접 검사하는 유일한 방법.
-
CAmazon EventBridge 스케줄러를 구성하여 Amazon Macie 작업을 실행하고 Redshift 테이블의 데이터 최신성을 검사합니다. AWS Glue 작업이 실패할 경우 Macie가 Amazon Simple Notification Service(Amazon SNS) 토픽에 알림을 보내도록 구성합니다.❌ Amazon Macie — S3의 PII(개인정보) 자동 탐지 및 데이터 보안 서비스. 데이터 최신성 검사 기능이 없음. Macie로 Redshift 검사도 불가. 완전히 용도가 다른 서비스.
-
D지난 하루 동안 발생한 AWS Glue 작업 실패 횟수를 표시하는 '실패한 AWS Glue 작업'이라는 메트릭을 포함하는 Amazon CloudWatch 대시보드를 생성합니다. 해당 메트릭 값이 0을 초과할 때 알림을 보내도록 CloudWatch 알람을 설정합니다.❌ A와 같은 이유. 작업 실패 횟수 = 작업 레벨 모니터링. Redshift 테이블의 데이터 최신성을 직접 검사하는 것이 아님. 작업이 실패해도 이전 배치 데이터가 남아 테이블에 데이터가 있을 수 있음.
| 감지 방법 | 감지 대상 | 데이터 최신성 직접 검사? |
|---|---|---|
| Glue 데이터 품질 최신성 규칙 | 테이블 내 데이터 최신성 | ✓ 직접 |
| CloudWatch Glue 실패 알람 | 작업 실패 여부 | ✗ 간접 |
| Amazon Macie | S3 PII 탐지 | ✗ 무관 |
"Redshift 데이터 최신성 알림"
→ Glue 데이터 품질(Freshness 규칙) + EventBridge + SNS
작업 실패 ≠ 데이터 최신성 미달 → 다른 레이어!
Macie = PII 탐지 도구 (최신성과 무관)
