◇ 공부 기록용으로 작성하였으니 틀린점, 피드백 주시면 감사하겠습니다 ◇

AWS Lake Formation
데이터 레이크(Data Lake)를 쉽고 빠르게 구축·관리할 수 있도록 도와주는 서비스

👩🏫 데이터 레이크(Data Lake)란??
- 데이터 구조(구조화/비구조화) 상관없이 다양한 데이터를 중앙에서 저장·관리하는 저장소
- (데이터 예시: 로그 파일, 이미지, 동영상, 센서 데이터, 데이터베이스 덤프 등)
- 대량의 데이터를 원본 그대로(raw) 변환 없이, 중앙 저장소에 보관하는 시스템
- 사용 목적: 데이터 사이언스, 머신 러닝, 빅데이터 분석

Lake Formation이 필요한 이유

Data Lake 구축 시 고려사항
- 다양한 데이터 소스로부터 데이터 수집
- 데이터를 표준화 및 카탈로그화 (스키마, 메타데이터 관리)
→ 여러 소스(DB, 로그, CSV, JSON 등)에서 들어오는 데이터는 형식이 제각각이기 때문에 분석하기 좋게 공통된 형식으로 맞추는 과정 - 사용자·그룹별 접근 권한 설정 및 보안 관리
Data Lake의 기존 구축 방식
- Amazon S3, AWS Glue, IAM 등을 수동으로 조합해 데이터 레이크 구현
- 구성·권한 관리가 복잡하고 운영 부담이 큼
Lake Formation 사용 시 장점
- 데이터 수집, 표준화, 카탈로그화, 권한 관리를 중앙집중식으로 간소화
- 수동 설정 없이 더 빠르고 쉽게 데이터 레이크 구축 가능

🌊 AWS Lake Formation 특징
- 🏞️데이터 레이크 구축 간소화, 자동
- S3를 기반으로 데이터를 모아 데이터 레이크 만들어줌
- 수동으로 Glue, IAM, S3를 각각 설정할 필요 없음 → Lake Formation가 자동으로 설정해줌
- 🗂️데이터 카탈로그(Data Catalog) 통합
- AWS Glue의 데이터 카탈로그를 그대로 사용한다.
- 데이터 카탈로그는 “데이터에 대한 설명서(메타데이터 저장소)”
- 다양한 소스(RDS, DynamoDB, S3 등)에서 스키마·메타데이터를 추출하고 중앙에서 관리 가능
- Fine-grained Access Control (세분화된 접근 제어)
- S3에 저장된 데이터 중에 특정 데이터 전체에 대해 단순한 “읽기/쓰기” 권한이 아니라,
- 테이블(Table), 열(Column), 행(row) 단위로 세밀하게 접근 권한 설정 가능
- → 특정 🎌국가나 부서별로 접근 제한하도록 만들 수 있음
= IAM User 권한 + Lake Formation의 Table 권한 + Row Filter/Column Filter 조합
Lake Formation 실체 = AWS Glue + S3

※ 🗂️데이터 카탈로그(Data Catalog)란?
= AWS Glue에서 실제 데이터의 메타데이터(속성 정보)의 집합으로, 데이터베이스와 테이블로 구성된다.
>> https://jibinary.tistory.com/833
[AWS] Glue란? ETL 서비스 아주 쉽게 정리 (Crawler, Data Catalog, Job)
AWS Glue란?(AWS Managed) Serverless의 ETL(Extract, Transform, Load) 서비스이다.AWS Glue는 ETL 서비스로서 대규모 데이터 처리에 효과적이다. AWS Glue 특징 정리🔢 ETL(Extract, Transform, Load) 서비스특히 대량의 데이
jibinary.tistory.com
Lake Formation 실체
Lake Formation 실체 = AWS Glue + S3 + Lake Formation 자체 기능

Blueprint (블루프린트) = 데이터 소스에서 데이터 수집과 데이터 카탈로그(Data Catalog) 생성 과정을 자동화하는 템플릿
- 데이터 카탈로그 생성 작업 = AWS Glue Crawler 담당
- 데이터 레이크의 데이터 저장 장소 = S3 Bucket

Lake Formation 주요 기능

1. 🗺️ Blueprint (블루프린트)
Lake Formation에서 데이터 레이크 구축을 자동화하는 템플릿
(= 1)데이터 수집(ingest) 과정과 2)데이터 카탈로그 생성을 자동화)
>> 즉, "어떤 데이터 소스를 가져올지, 어떻게 카탈로그화할지, 어디에 저장할지" 등을 정의할 필요가 있다.
1) 데이터 수집(Ingest)
온프레미스의 DB, RDS DB, CloudTrail 로그, S3 데이터 등 다양한 소스에서 가져오기 가능
2) 데이터 카탈로그 생성
Glue Crawler가 데이터를 스캔 → 스키마/메타데이터 추출 → 데이터 카탈로그 등록
<Blueprint 생성 시 핵심 입력 정보>
- 데이터 소스 정보: DB 종류, 연결 정보(JDBC URL, 사용자/비밀번호 등)
- 대상 저장 위치: S3 버킷 경로 (없으면 만들어야 한다)
- 데이터 카탈로그 정보: 데이터베이스 이름, 테이블 이름 등
- 주기/스케줄: 데이터 수집 빈도(일회성, 주기적)
- 필요 시 ETL 변환: 간단한 변환 규칙이나 Glue Job 연결

2. 🔐 Fine-grained Access Control (데이터 접근 권한 설정)
IAM 권한 외 추가 관리 권한 제공: 세밀한 접근 제어(Fine-grained Access Control) 가능
> 적절한 권한을 가진 사용자만 필요한 데이터에 접근 가능
- 테이블 단위 접근 권한
- 행(Row) 단위 접근 권한
- 열(Column) 단위 접근 권한
- 셀(Cell) 단위 접근 권한
- + LF 태그 기반
Fine-grained Access Control 접근 제어 방법

1. Named Resource Access Control
- 리소스 이름을 직접 지정하여 접근 제어
- 예시: 데이터베이스명, 테이블명, 열(Column) 행 필터(Row-level filter) 등
2. Tag-Based Access Control (TBCA)
- LF 태그(Lake Formation Tag)를 사용하여 접근 제어
- LF 태그는 사전에 생성 후, 리소스에 할당해야 함
- LF 태그는 하위 리소스에 자동 상속 (예: 데이터베이스에 부여 → 해당 데이터베이스 아래 모든 테이블에 자동 적용)
- LF 태그 장점:
- 관리해야하는 권한의 수 감소 → 리소스가 많아도 효율적
- 제어 대상 리소스 증가 하더라도, 태그만 부여하면 제어 가능
- 관리해야하는 리소스가 많은 환경에서 유효 (AWS에서도 공식 권장 방법)
- 핵심 요약
- Named Resource → 개별 리소스 직접 제어
- TBCA → 태그 기반으로 간편하게 다수 리소스 제어


3. 데이터 레이크 공유
- 크로스 계정(Cross-account) 공유 지원
→ Lake Formation에서 관리되는 데이터 레이크는 다른 AWS 계정과 직접 공유 가능 - 리소스 링크(Resource Link) 활용
→ 공유 대상 계정은 리소스 링크로 원본 데이터에 접근 (데이터 복사 없음)

🤔 문제

한 소매 회사가 Amazon S3 버킷에 고객 데이터 허브를 가지고 있습니다. 여러 국가의 직원들이 회사 전체의 분석을 지원하기 위해 이 데이터 허브를 사용합니다. 거버넌스 팀은 회사의 데이터 분석가들이 자신이 속한 국가의 고객 데이터만 접근할 수 있도록 해야 합니다. 최소한의 운영 노력(LEAST operational effort)으로 이 요구사항을 만족시키는 솔루션은 무엇인가요?
- 각 국가의 고객 데이터를 위한 별도의 테이블을 생성합니다. 각 분석가에게 자신이 담당하는 국가에 따라 접근 권한을 제공합니다.
- S3 버킷을 AWS Lake Formation에서 데이터 레이크 위치로 등록합니다. Lake Formation의 행 수준 보안(row-level security) 기능을 사용하여 회사의 접근 정책을 적용합니다.
- 데이터를 고객이 있는 국가와 가까운 AWS 리전으로 이동합니다. 각 분석가에게 자신이 담당하는 국가에 따라 접근 권한을 제공합니다.
- 데이터를 Amazon Redshift로 로드합니다. 각 국가별 뷰(view)를 생성합니다. 국가별로 별도의 IAM 역할을 생성하여 각 국가 데이터를 접근할 수 있도록 합니다. 적절한 역할을 분석가에게 할당합니다.
✅ 정답
✅ 정답. 2
이미 S3에 데이터가 있기 때문에 이 데이터들로 데이터 레이크로 만든 다음 행 수준 보안(row-level security) 기능만 적용시키면 됌. 이 문제에서 가장 최소한의 운영 노력(LEAST operational effort)으로 구현 가능.
❌ 1번 오답
각 국가마다 테이블 만드는 건, 운영 부담이 많고 오히려 복잡해진다. 당연히 틀림
❌ 3번 오답
굳이 다른 국가의 리전에 이동시키는건 오히려 운영 부담 증가
❌ 4번 오답
Redshift 뷰 생성 + IAM 역할 관리 → 가능하긴한데 운영 부담이 크다.
'클라우드(AWS) > DEA-C01' 카테고리의 다른 글
| [AWS] Glue Workflows란? 쉽게 정리 (0) | 2025.10.08 |
|---|---|
| [AWS] Data Mesh란? 아주 쉽게 정리 (Data Lake, Data Warehouse와 차이점) (0) | 2025.10.07 |
| [AWS] Data Exchange란? 아주 쉽게 정리 (외부 데이터를 구독하여 사용하는 서비스) (0) | 2025.10.06 |
| [AWS] Glue job이란? (S3 Bucket에서 데이터 가져오기) (0) | 2025.09.28 |