AWS Lake Formation 알아보기 - IAM 위의 데이터 접근 권한

Posted Jun 9, 2026 Updated Jul 2, 2026

By KKamJi

views 25 min read

앞선 S3 Tables & Catalog Federation 글에서 관리형 Iceberg 레이크하우스가 s3tablescatalog 아래에 어떻게 중첩되는지, 그래서 ARN이 왜 깊어지는지를 정리했습니다. 이번 글에서는 이 federated 데이터에 한 겹 더 얹히는 권한 계층, AWS Lake Formation을 알아봅니다.

Lake Formation이 까다로운 이유는, IAM 정책에서 모든 권한을 Allow로 열어 줘도 쿼리가 AccessDenied로 막힐 수 있기 때문입니다. IAM 위에 데이터 접근을 따로 통제하는 게이트가 하나 더 있고, 그 게이트는 IAM과 전혀 다른 방식(grant)으로 동작합니다. 이번 글에서는 그 두 번째 게이트가 무엇이고, IAM과 어떻게 결합해 동작하는지를 정리합니다.

TL;DR
Lake Formation(LF)은 Glue Data Catalog 리소스와 그 실데이터에 대한 중앙 집중 fine-grained 접근 권한 서비스입니다.
LF는 IAM을 대체하지 않습니다. IAM(API 권한) + LF(데이터 권한) 두 게이트를 모두 통과해야 LF 등록 데이터를 쿼리할 수 있습니다.
권한은 IAM 정책이 아니라 grant 모델(principal에게 DB/Table에 SELECT/DESCRIBE 등을 부여)로 관리합니다.
쿼리마다 LF가 권한을 검증하고, 통과하면 등록된 role을 assume해 임시 자격증명을 vending합니다. 이때 호출자에게는 lakeformation:GetDataAccess IAM 권한이 필요합니다.

1. AWS Lake Formation이란

Lake Formation은 데이터 레이크의 접근 권한을 한 곳에서 fine-grained로 관리하는 서비스입니다. Glue Data Catalog의 데이터베이스, 테이블, 컬럼, 행 같은 리소스와 그것이 가리키는 S3 위치의 실데이터에 대해, 누가 무엇을 할 수 있는지를 중앙에서 통제합니다.

1.1. 왜 IAM만으로는 부족한가

IAM은 AWS API 호출 권한을 다루는 데 강력하지만, 데이터 레이크의 거버넌스 요구를 그대로 담기에는 결이 맞지 않는 부분이 있습니다.

테이블/컬럼/행 단위 통제: IAM 정책으로 특정 테이블의 일부 컬럼만, 또는 특정 조건의 행만 허용하려면 정책이 복잡해지고 관리가 어렵습니다.
중앙 집중 거버넌스: 데이터 자산이 여러 데이터베이스와 계정에 흩어져 있을 때, 권한을 자산 중심으로 한곳에서 부여하고 회수하는 모델이 필요합니다.
분석 엔진과의 통합: Athena, Redshift Spectrum, EMR 등 여러 엔진이 동일한 권한 모델을 공유해야 일관성이 유지됩니다.

Lake Formation은 이 요구를 데이터베이스의 GRANT / REVOKE와 유사한 grant 모델로 풀어냅니다.

1.2. 정책이 아니라 grant

IAM이 “이 principal에게 이런 action을 허용한다”는 정책(policy) 으로 권한을 표현한다면, Lake Formation은 “이 principal에게 이 데이터베이스/테이블에 SELECT를 부여한다”는 grant 로 표현합니다.

  
# IAM (정책 기반): identity-based policy의 한 statement
#   "Effect": "Allow",
#   "Action": "glue:GetTable",
#   "Resource": "arn:aws:glue:...:table/sales_db/orders"

# Lake Formation (grant 기반): grant-permissions API/CLI
aws lakeformation grant-permissions \
  --principal DataLakePrincipalIdentifier=arn:aws:iam::<account-id>:role/analytics-workload-role \
  --permissions "SELECT" "DESCRIBE" \
  --resource '{ "Table": {"DatabaseName":"sales_db", "Name":"orders"}}'

LF grant는 SQL의 GRANT ... ON ... TO ...와 개념은 비슷하지만, 실제 인터페이스는 SQL 문이 아니라 grant-permissions API/CLI(또는 콘솔)입니다. --permissions에는 위 표의 토큰(SELECT/DESCRIBE/ALL 등)을, --resource에는 대상 리소스를 JSON으로 지정합니다.

이 둘은 서로를 대체하지 않습니다. 다음 절에서 보듯이, LF 등록 데이터는 두 표현이 모두 충족돼야 접근이 허용됩니다.

2. IAM과 Lake Formation - 2층 게이트

Lake Formation을 이해하는 핵심은, 그것이 IAM 위에 얹히는 별도의 데이터 권한 게이트라는 점입니다. 다음 다이어그램은 쿼리가 두 게이트를 차례로 통과하는 흐름을 보여줍니다.

2.1. 역할 분리

두 게이트는 각각 다른 영역을 책임집니다.

게이트	검사 대상	책임
IAM	Lake Formation / Glue API와 리소스 호출	API authorization
Lake Formation	Data Catalog 리소스와 실데이터 접근	data authorization

즉 IAM은 “이 role이 glue:GetTable API를 호출해도 되는가”를 판단하고, Lake Formation은 “이 role이 sales_db.orders라는 데이터에 실제로 접근해도 되는가”를 판단합니다. 둘은 검사하는 층위가 다릅니다.

2.2. 둘 다 통과해야 한다

LF에 등록된 데이터는 IAM 검사와 LF 검사를 모두 통과해야 접근할 수 있습니다.

IAM은 Allow인데 LF grant가 없으면 -> AccessDenied
LF grant는 있는데 IAM에서 glue:GetTable/glue:GetDatabase 같은 메타데이터 action이나 lakeformation:GetDataAccess가 빠지면 -> AccessDenied

특히 첫 번째 경우가 혼동을 일으킵니다. IAM 정책에서 모든 Glue/Athena 권한을 열어 줬는데도 다음과 같은 에러가 나오면, 그것은 IAM 문제가 아니라 LF 게이트에서 막힌 것입니다.

AccessDeniedException: Insufficient Lake Formation permission(s): Required Describe

이 메시지에 Lake Formation permission(s)가 들어 있다는 점이 단서입니다. IAM이 아니라 LF가 별도의 게이트로 작동하고 있다는 증거입니다.

2.3. LF 미등록 데이터는 IAM만으로 동작

반대로, Lake Formation에 등록되지 않은 데이터(일반 S3 + 일반 Glue 테이블)는 LF 게이트를 거치지 않습니다. 이 경우에는 IAM 정책과 Glue action만으로 접근이 결정되고, LF grant는 무관합니다.

같은 Athena를 쓰더라도, 일반 Glue 테이블은 IAM만으로, LF 등록 테이블(레이크하우스 등)은 IAM + LF grant로 접근이 결정됩니다. 테이블이 어느 쪽인지에 따라 필요한 권한이 달라지므로, 접근이 막혔을 때 가장 먼저 확인할 것은 “이 데이터가 LF에 등록돼 있는가”입니다.

3. Lake Formation 권한 모델

게이트의 구조를 봤으니, Lake Formation이 실제로 어떤 권한을 어떻게 부여하는지를 살펴봅니다.

3.1. 두 종류의 접근 - metadata vs underlying data

Lake Formation 권한은 크게 두 종류로 나뉩니다.

종류	대상	예
Metadata access	Data Catalog의 DB/Table 메타데이터	테이블 목록 조회, 스키마 읽기, DB 생성/삭제
Underlying data access	Catalog가 가리키는 실제 S3 위치의 데이터	행 read/write

분석 쿼리 한 번에는 두 종류가 모두 관여합니다. 테이블의 스키마와 위치를 읽으려면 metadata access가, 그 위치의 데이터를 실제로 스캔하려면 underlying data access가 필요합니다.

3.2. grant 가능한 권한

S3 Tables 같은 카탈로그 객체에 부여할 수 있는 LF 권한은 데이터베이스의 권한과 유사합니다.

권한	의미
`SELECT`	데이터 조회
`INSERT` / `DELETE`	데이터 삽입 / 삭제
`DESCRIBE`	메타데이터(스키마, 테이블 목록) 조회
`ALTER` / `DROP`	테이블 변경 / 삭제
`ALL`	전체 권한 (콘솔에서는 `Super` 라벨로 표기)

표준 permission 토큰은 ALL입니다. Lake Formation 문서와 콘솔이 이 전체 권한을 Super라고 부르는 경우가 있어 혼동하기 쉽지만, grant-permissions API/CLI에 넘기는 토큰은 ALL입니다. 공식 reference의 리소스별 권한 목록도 동일하게 표기합니다.

Table
Permission:
ALL (Super)
ALTER
DELETE
DESCRIBE
DROP
INSERT
SELECT

읽기 전용 분석 워크로드에는 보통 SELECT + DESCRIBE 조합이면 충분합니다. DESCRIBE가 빠지면 테이블 자체가 목록에 보이지 않아, 마치 테이블이 존재하지 않는 것처럼 동작하기도 합니다.

3.3. 누가 grant하는가

LF 권한은 아무나 부여할 수 없습니다.

data lake admin(또는 admin이 권한을 위임한 principal)만 grant할 수 있습니다.
LF 권한은 grant한 리전에서만 유효합니다. 다른 리전의 동일 자산에는 별도로 grant해야 합니다.

따라서 운영 현장에서는 보통 인프라/보안 담당자가 IAM 측 권한(API, GetDataAccess)을 보강하고, 데이터 자산을 관리하는 data lake admin이 LF grant를 부여하는 식으로 책임이 나뉩니다. 한쪽만으로는 쿼리가 동작하지 않으므로, 권한 요청 시 두 축을 함께 확인하는 것이 좋습니다.

4. credential vending과 GetDataAccess

마지막으로, LF 게이트를 통과한 뒤 실데이터를 읽는 과정을 봅니다. 여기서 Lake Formation의 가장 독특한 동작인 credential vending이 등장합니다.

4.1. 쿼리마다 검증

principal이 LF 등록 데이터를 쿼리할 때마다, Lake Formation은 그 principal이 해당 DB/Table/데이터 위치에 적절한 LF 권한을 갖는지 매번 검증합니다. 권한이 없으면 그 자리에서 AccessDenied로 막습니다.

4.2. 등록된 role을 assume해 임시 자격증명 발급

권한 검증을 통과하면, Lake Formation은 실데이터에 접근할 임시 자격증명(temporary credentials)을 발급(vending) 해 분석 엔진에 전달합니다. 이 자격증명은 LF가 임의로 만드는 것이 아니라, S3 위치를 LF에 등록할 때 지정한 IAM role을 assume해서 만들어집니다.

여기서 중요한 결과가 따라옵니다.

실데이터가 있는 S3 위치를 읽고 쓰는 권한은 등록된 role(registered role) 이 제공합니다. 따라서 쿼리를 실행하는 호출자(principal)는 그 S3 위치에 대한 직접적인 s3 권한을 가질 필요가 없습니다. LF가 등록 role의 자격증명을 대신 vending하기 때문입니다.

이 구조 덕분에, 분석 사용자에게 데이터 버킷의 S3 권한을 일일이 부여하지 않고도, LF grant만으로 접근을 통제할 수 있습니다. 다이어그램의 4~5번 단계가 바로 이 과정입니다. LF가 registered role을 assume(4)하고, 그 자격증명으로 S3 Tables 데이터를 읽어(5) 결과를 엔진에 돌려줍니다.

4.3. lakeformation:GetDataAccess

credential vending이 동작하려면, 호출자 측에 lakeformation:GetDataAccess IAM 권한이 있어야 합니다. 이 권한이 있어야 LF가 임시 자격증명 발급 요청을 승인합니다. LF grant(SELECT/DESCRIBE)와는 별개의, IAM 측 조건입니다.

Athena의 경우, 이 권한은 쿼리를 실행하는 사용자나 role 본인이 가져야 합니다(다른 통합 서비스는 해당 execution role에 부여). 따라서 LF 등록 데이터를 Athena로 쿼리하려는 role에는 다음 IAM 권한이 함께 필요합니다.

  
{
  "Effect": "Allow",
  "Action": [
    "athena:StartQueryExecution",
    "athena:GetQueryExecution",
    "athena:GetQueryResults",
    "glue:GetCatalog",
    "glue:GetCatalogs",
    "glue:GetDatabase",
    "glue:GetDatabases",
    "glue:GetTable",
    "glue:GetTables",
    "glue:GetPartition",
    "glue:GetPartitions",
    "lakeformation:GetDataAccess"
  ],
  "Resource": "*"
}

여기서 glue:Get* 같은 와일드카드 대신 필요한 action을 단수/복수로 명시하는 것이 최소 권한 관점에서 안전합니다. 단일 객체 조회(GetTable/GetDatabase/GetCatalog)와 목록 조회(GetTables/GetDatabases/GetCatalogs)가 별개의 action이라, 둘 중 하나만 넣으면 카탈로그/데이터베이스 탐색이나 테이블 단건 조회 중 한쪽이 막힐 수 있습니다. 공식 reference의 DESCRIBE permission도 grantee가 추가로 glue:GetTable(테이블),glue:GetDatabase(데이터베이스)를 가져야 한다고 명시합니다.

DESCRIBE DATABASE glue:GetDatabase
DESCRIBE TABLE glue:GetTable

여기에 더해 Lake Formation 측에서 SELECT/DESCRIBE grant가 부여돼야 비로소 쿼리가 성공합니다.

5. Access control mode - IAM vs Lake Formation

지금까지 설명한 “IAM + LF” 모델이 항상 적용되는 것은 아닙니다. S3 Tables를 Glue Data Catalog에 통합할 때 권한 모드를 선택하며, 이 선택에 따라 게이트의 구성이 달라집니다(나중에 전환 가능).

모드	권한 결정	특징
IAM access control	IAM 정책만	S3 Tables 리소스와 Data Catalog 객체 양쪽에 IAM 권한 필요. LF grant 불필요
Lake Formation access control	Glue IAM 권한 + LF grant	principal은 Catalog 상호작용용 IAM 권한을 갖고, 어느 리소스에 접근할지는 LF grant가 결정

Lake Formation access control mode에서는 앞서 본 2층 게이트가 작동합니다. principal은 Data Catalog와 상호작용할 IAM 권한만 가지면 되고, 실제 어떤 DB/Table/Column/Row에 접근할 수 있는지는 LF grant가 통제합니다. coarse-grained(DB/Table)부터 fine-grained(Column/Row)까지 모두 지원합니다.

registered role과 credential vending이 켜져 있으면, principal은 S3 Tables에 대한 IAM 권한을 따로 가질 필요가 없습니다(4.2에서 본 대로 LF가 등록 role로 자격증명을 vending). 서드파티 분석 엔진도 동일하게 vending을 통해 접근할 수 있습니다.

레이크하우스 데이터가 Lake Formation access control mode로 구성돼 있다면, IAM만 아무리 열어도 LF grant 없이는 접근할 수 없습니다. 다음 글의 트러블슈팅이 정확히 이 상황을 다룹니다.

5.1. IAMAllowedPrincipals와 hybrid access mode

여기서 한 가지 함정이 있습니다. Lake Formation은 backward compatibility를 위해, 기본적으로 모든 데이터베이스/테이블에 IAMAllowedPrincipals라는 그룹에 Super(전체) 권한을 부여합니다. 이 그룹 권한이 리소스에 남아 있으면, LF grant를 따로 안 해도 IAM 정책만으로 접근이 열려 버립니다. 즉 “LF가 켜져 있는데 왜 IAM만으로 되지?”의 원인이 보통 이것입니다.

Lake Formation sets Super permission on all databases and tables in the Data Catalog to a group called IAMAllowedPrincipals by default. If this group permission exists on a database or a table, all principals in your account will have access to the resource through the IAM principal policies for AWS Glue. It provides backward compatibility when you start using Lake Formation permissions to secure the Data Catalog resources that were earlier protected by IAM policies for AWS Glue.

따라서 LF grant를 실제 게이트로 작동시키려면 다음 둘 중 하나가 필요합니다.

IAMAllowedPrincipals의 Super 권한을 revoke: 해당 리소스를 완전히 LF 권한으로만 통제. 단, IAM만으로 접근하던 기존 워크로드가 끊길 수 있습니다.
hybrid access mode: S3 location 등록 시 선택하는 모드로, opt-in한 principal만 LF 권한을 적용받고 나머지는 기존 IAM 권한으로 계속 접근합니다. 기존 사용자를 끊지 않고 점진적으로 전환할 때 사용합니다.

The hybrid access mode enforces only CREATE_TABLE, CREATE_PARTITION, UPDATE_TABLE permissions by default. When an Amazon S3 location is in the hybrid mode, you can enable Lake Formation permissions by opting in principals for the Data Catalog objects under that location. It means both Lake Formation permissions and IAM permissions can control access to that data. This means that opted in principals will require both Lake Formation permissions and IAM permissions to access the data, while non-opted-in principals will continue to access data using only IAM permissions.

레이크하우스(S3 Tables federated catalog)가 처음부터 LF 권한으로만 통제되도록 설정돼 있다면, IAMAllowedPrincipals 권한이 없으므로 LF grant가 없는 principal은 그대로 막힙니다.

5.2. end-to-end - AccessDenied에서 성공까지

지금까지의 조각을 하나의 시나리오로 이어 봅니다. 분석 role이 LF 등록 테이블 sales_db.orders를 Athena로 조회하려 합니다.

막힘: IAM 정책에 athena:*, glue:Get*, lakeformation:GetDataAccess까지 다 열려 있는데도 쿼리가 실패합니다.

AccessDeniedException: Insufficient Lake Formation permission(s): Required Describe

메시지에 Lake Formation permission(s)가 있으므로 IAM이 아니라 LF 게이트에서 막힌 것입니다(2.2 참고).

현재 grant 확인: data lake admin이 해당 role에 무슨 LF 권한이 있는지 조회합니다.

  
aws lakeformation list-permissions \
  --principal DataLakePrincipalIdentifier=arn:aws:iam::<account-id>:role/analytics-workload-role \
  --resource-type TABLE \
  --resource '{ "Table": {"DatabaseName":"sales_db", "Name":"orders"}}'

반환이 비어 있으면 LF grant가 없는 것이 확정됩니다.

grant 부여: admin이 읽기 전용 권한을 부여합니다.

  
aws lakeformation grant-permissions \
  --principal DataLakePrincipalIdentifier=arn:aws:iam::<account-id>:role/analytics-workload-role \
  --permissions "SELECT" "DESCRIBE" \
  --resource '{ "Table": {"DatabaseName":"sales_db", "Name":"orders"}}'

성공: 같은 Athena 쿼리가 통과합니다. IAM 두 축(메타데이터 action + GetDataAccess)과 LF grant(SELECT+DESCRIBE)가 모두 충족됐기 때문입니다. 실데이터 읽기는 4.2의 credential vending이 등록 role로 처리하므로, 이 role에 데이터 버킷의 S3 권한을 따로 줄 필요는 없습니다.

6. 다음 글

이번 편에서는 Lake Formation이 IAM 위에 얹히는 별도의 데이터 권한 게이트라는 점, grant 모델과 두 종류의 접근(metadata/underlying), credential vending과 GetDataAccess, 그리고 access control mode를 정리했습니다.

다음 글에서는 이 모든 것을 실제 문제 상황에 적용합니다. 레이크하우스의 federated 데이터베이스가 Athena에서 CATALOG_NOT_FOUND / TABLE_NOT_FOUND / AccessDenied로 보이지 않을 때, IAM 두 축과 LF 세 계층(catalog/database/table)을 어떻게 진단하고 단계적으로 해소하는지를 다룹니다.

7. Reference

AWS Lake Formation Developer Guide
Lake Formation - access to underlying data
Using Lake Formation with Amazon Athena
Amazon S3 Tables integration with AWS Glue Data Catalog and Lake Formation
Granting permissions on Data Catalog resources
AWS Lake Formation Developer Guide - Lake Formation permissions reference (리소스별 권한 토큰 ALL (Super)/SELECT/DESCRIBE, IAMAllowedPrincipals, grant CLI 예시): https://docs.aws.amazon.com/lake-formation/latest/dg/lf-permissions-reference.html
AWS Lake Formation Developer Guide - Hybrid access mode (IAM/LF 이중 경로, opt-in): https://docs.aws.amazon.com/lake-formation/latest/dg/hybrid-access-mode.html
AWS CLI Command Reference - lakeformation list-permissions (principal/resource 별 부여 권한 조회): https://docs.aws.amazon.com/cli/latest/reference/lakeformation/list-permissions.html

궁금하신 점이나 추가해야 할 부분은 댓글이나 아래의 링크를 통해 문의해주세요.
Written with KKamJi

Cloud, AWS

This post is licensed under CC BY 4.0 by the author.