출처: Dev.to

AWS Lake Formation 사용 방법 정리

안녕하세요, 저는 AWS Community Builder인 Aki(@jitepengin)입니다.
이전에 “AWS Glue Data Catalog가 데이터 카탈로그로 충분한가? 설계, 제한 사항 및 보완 전략 정리”라는 글을 썼었습니다. 그 글에서 “데이터 거버넌스를 보완하기 위해 AWS Lake Formation이 필요하다”는 점을 언급했지만, 범위를 벗어나 자세히 다루지는 못했습니다.

이번에는 Lake Formation에 대한 생각을 정리해 보겠습니다. 기본 개념부터 실제 사용 패턴까지 모두 다룹니다.

Lake Formation은 “조금 어렵다”거나 “IAM만 있으면 충분하다”는 인식이 종종 있습니다. 이 글이 여러분의 환경에서 Lake Formation을 도입할 가치가 있는지 판단하는 데 도움이 되길 바랍니다.

Lake Formation이란?

AWS Lake Formation은 데이터 레이크에 대한 접근 관리와 거버넌스를 제공하는 서비스입니다.
누가 어떤 데이터에, 어떤 수준으로 접근할 수 있는지를 중앙에서 관리할 수 있습니다.

서비스 역할 구분

Amazon S3 (실제 데이터)
        ↓
Glue Data Catalog (메타데이터 관리)
        ↓
Lake Formation (접근 제어)
        ↓
Athena / Glue Job / Redshift Spectrum

즉, 데이터는 S3에 저장되고, Glue Data Catalog가 메타데이터를 관리하며, Lake Formation은 그 메타데이터 위에 접근 제어를 입히는 구조입니다.

IAM만으로 S3 데이터 레이크를 관리할 때의 문제점

• 세분화된 권한 부여 어려움: IAM은 주로 버킷·프리픽스 수준에서 동작하므로 테이블·컬럼·행 수준의 제어가 힘듭니다.
• 운영 복잡성: 사용자·역할이 늘어날수록 S3 버킷 정책·IAM 정책을 관리하기가 점점 어려워집니다.
• 계정 간 공유: IAM만으로 다른 AWS 계정에 데이터를 공유하면 설계가 복잡해집니다.
• 감사 가시성 부족: 누가 어떤 테이블에 접근 가능한지 한눈에 파악하기 어렵습니다.

전형적인 사례

• 10명 이상의 Athena 사용자가 서로 다른 수준의 접근 권한이 필요해 권한 관리가 복잡해지는 경우
• 부서별로 서로 다른 데이터 서브셋을 보여줘야 하는 경우 (예: 영업팀은 동일본 매출만, 임원은 전체 데이터)
• 이메일 주소·신용카드 번호 등 PII를 분석가에게 숨겨야 하는 경우
• 다른 AWS 계정과 데이터를 공유해야 하는 경우

Lake Formation은 이러한 문제들을 해결합니다.

Lake Formation이 제공하는 기능

• 테이블·컬럼·행 수준의 세분화된 접근 제어
• Glue Data Catalog 데이터베이스·테이블 수준 권한 관리
• 대규모 환경을 위한 태그 기반 접근 제어(LF‑TBAC)
• AWS RAM을 통한 계정 간 데이터 공유
• CloudTrail 연동을 통한 중앙 집중식 감사

Lake Formation은 IAM을 대체하지 않습니다. IAM 위에 추가적인 레이어로 동작합니다.

쿼리가 실행될 때(예: Athena) 두 조건이 모두 만족해야 접근이 허용됩니다.

IAM Permission
        AND
Lake Formation Permission
        ↓
Access Allowed

• Lake Formation에서 권한이 부여돼도 IAM이 차단하면 접근이 거부됩니다.
• 반대로 IAM에서 허용돼도 Lake Formation에 해당 권한이 없으면 거부됩니다.

이 AND 관계를 이해하는 것이 권한 설계의 기본입니다.

권한 관리 레벨

권한은 콘솔, CLI, SDK를 통해 부여·취소할 수 있습니다.

예시: 테이블에 SELECT 권한 부여

aws lakeformation grant-permissions \
  --principal DataLakePrincipalIdentifier=arn:aws:iam::123456789:role/analyst-role \
  --permissions SELECT \
  --resource '{
    "Table": {
      "DatabaseName": "mydb",
      "Name": "sales_table"
    }
  }'

세분화된 접근 제어: Data Filters

Lake Formation의 가장 강력한 기능 중 하나는 테이블 수준을 넘어선 세분화된 제어입니다.
컬럼 수준·행 수준 보안은 Data Filters 라는 메커니즘으로 구현됩니다.

컬럼 필터링

예를 들어 customer 테이블에 다음과 같은 컬럼이 있다고 가정합니다.

분석가에게는 customer_id, name, purchase_amount만 보여주고 email·credit_card는 숨기고 싶다면, Data Filter에 포함/제외 컬럼을 지정하면 됩니다.

행 필터링

행 수준 필터는 특정 조건을 만족하는 행만 접근을 허용합니다.
필터 식은 PartiQL WHERE 절 문법을 사용합니다.

예시: sales 테이블에 region 컬럼이 있고, 동일본 팀은 region = 'east'인 행만 보아야 할 경우:

aws lakeformation create-data-cells-filter \
  --table-data '{
    "TableCatalogId": "123456789012",
    "DatabaseName": "mydb",
    "TableName": "sales",
    "Name": "east-region-filter",
    "RowFilter": {
      "FilterExpression": "region = '\''east'\''"
    },
    "ColumnWildcard": {}
  }'

컬럼 필터와 행 필터를 결합하면 셀 수준 보안이 구현됩니다. 즉, 특정 행의 특정 컬럼만 접근 가능하게 되는 것입니다.

공식 문서에 명시된 제한 사항

• 프린시플당 최대 100개의 필터 지원
• 배열·맵 타입은 필터 식에서 지원되지 않음(구조체 타입은 행 필터에 사용 가능)
• 셀 수준 보안은 중첩 컬럼·뷰·리소스 링크를 지원하지 않음
• Athena Engine Version 3 또는 Redshift Spectrum을 사용할 때 모든 리전에서 셀 수준 보안 사용 가능

활용 사례

• 이메일·신용카드 번호 등 PII 보호
• 부서·지역별 비즈니스 데이터 제한
• 규제 데이터에 대한 컴플라이언스 요구 충족

LF‑TBAC (Lake Formation Tag‑Based Access Control)

데이터베이스·테이블 수가 늘어나면 테이블 단위로 권한을 관리하기가 점점 어려워집니다.
LF‑TBAC는 이 문제를 해결합니다.

• LF‑Tag는 Lake Formation 전용 키‑값 태그이며, S3 리소스 태그·IAM 태그와는 별개로 독립적으로 관리됩니다.

aws lakeformation create-lf-tag \
  --tag-key "sensitivity" \
  --tag-values '["public", "internal", "confidential"]'

LF‑Tag 적용 예시

aws lakeformation add-lf-tags-to-resource \
  --resource '{"Table": {"DatabaseName": "mydb", "Name": "sales"}}' \
  --lf-tags '[{"TagKey": "sensitivity", "TagValues": ["internal"]}]'

태그 기반 권한 부여

aws lakeformation grant-permissions \
  --principal DataLakePrincipalIdentifier=arn:aws:iam::123456789:role/analyst-role \
  --permissions SELECT \
  --resource '{
    "LFTagPolicy": {
      "ResourceType": "TABLE",
      "Expression": [{"TagKey": "sensitivity", "TagValues": ["public", "internal"]}]
    }
  }'

위 명령은 sensitivity=public 또는 sensitivity=internal 태그가 붙은 모든 테이블에 대해 SELECT 권한을 부여합니다.

새 테이블을 만들 때 적절한 LF‑Tag만 지정하면 자동으로 올바른 권한이 적용됩니다.

수십·수백 개 테이블을 운영하는 환경에서는 테이블별 권한 관리가 비현실적이므로, LF‑TBAC가 훨씬 간단한 모델을 제공합니다.

• 역할은 특정 태그가 붙은 데이터에만 접근 가능
• 태그 설계는 처음부터 신중히 해야 함 (sensitivity, domain, owner 등)

Glue Data Catalog와의 연계

Lake Formation은 Glue Data Catalog와 긴밀히 연동됩니다. (이후 내용은 원문이 끊긴 상태이므로 여기까지 번역을 마칩니다.)