기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 계정 간 데이터 공유 모범 사례 및 고려 사항
<a name="cross-account-notes"></a>

 Lake Formation 교차 계정 기능을 사용하면 사용자가 여러 AWS 계정 AWS 조직 간에 분산된 데이터 레이크를 안전하게 공유하거나 다른 계정의 IAM 보안 주체와 직접 공유하여 데이터 카탈로그 메타데이터 및 기본 데이터에 대한 세분화된 액세스를 제공할 수 있습니다.

Lake Formation 계정 간 데이터 공유를 사용할 때는 다음 모범 사례를 고려하십시오.
+ 본인 AWS 계정의 보안 주체에게 부여할 수 있는 Lake Formation 권한 부여 수에는 제한이 없습니다. 그러나 Lake Formation은 계정에서 명명된 리소스 메서드로 수행할 수 있는 교차 계정 권한 부여에 AWS Resource Access Manager (AWS RAM) 용량을 사용합니다. AWS RAM 용량을 극대화하려면 명명된 리소스 메서드에 대한 다음 모범 사례를 따르세요.
  +  새 교차 계정 권한 부여 모드(**교차 계정 버전 설정의 버전** **3** 이상)를 사용하여 리소스를 외부와 공유합니다 AWS 계정. 자세한 내용은 [교차 계정 데이터 공유 버전 설정 업데이트](optimize-ram.md) 단원을 참조하십시오.
  + 조직에 AWS 계정을 정렬하고 조직 또는 조직 단위에 권한을 부여합니다. 조직 또는 조직 단위에 대한 권한 부여는 한 번의 부여로 간주됩니다.

    조직 또는 조직 단위에 권한을 부여하면 권한 부여에 대한 AWS Resource Access Manager (AWS RAM) 리소스 공유 초대를 수락할 필요도 없습니다. 자세한 내용은 [공유 데이터 카탈로그 테이블 및 데이터베이스 액세스 및 보기](viewing-shared-resources.md) 단원을 참조하십시오.
  + 데이터베이스의 많은 개별 테이블에 권한을 부여하는 대신 특수한 **모든 테이블** 와일드카드를 사용하여 데이터베이스의 모든 테이블에 권한을 부여합니다. **모든 테이블**에 권한을 부여하는 것은 단일 권한 부여로 간주됩니다. 자세한 내용은 [데이터 카탈로그 리소스에 대한 권한 부여](granting-catalog-permissions.md) 단원을 참조하십시오.
**참고**  
의 리소스 공유 수에 대한 더 높은 제한을 요청하는 방법에 대한 자세한 내용은의 서비스 할당량을 AWS RAM참조하세요*AWS 일반 참조*. [AWS](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  Amazon Athena 및 Amazon Redshift Spectrum 쿼리 편집기에 해당 데이터베이스를 표시하려면 공유 데이터베이스에 대한 리소스 링크를 생성해야 합니다. 마찬가지로, Athena 및 Redshift Spectrum을 사용하여 공유 테이블을 쿼리하려면 테이블에 대한 리소스 링크를 만들어야 합니다. 그러면 리소스 링크가 쿼리 편집기의 테이블 목록에 나타납니다.

  쿼리를 위해 많은 개별 테이블에 대한 리소스 링크를 만드는 대신, **모든 테이블** 와일드카드를 사용하여 데이터베이스의 모든 테이블에 대한 권한을 부여할 수 있습니다. 그런 다음 해당 데이터베이스의 리소스 링크를 만들고 쿼리 편집기에서 해당 데이터베이스 리소스 링크를 선택하면 쿼리를 위해 해당 데이터베이스의 모든 테이블에 액세스할 수 있습니다. 자세한 내용은 [리소스 링크 생성](creating-resource-links.md) 단원을 참조하십시오.
+ 다른 계정의 보안 주체와 직접 리소스를 공유하는 경우, 수신자 계정의 IAM 보안 주체는 Athena와 Amazon Redshift Spectrum을 사용하여 공유 테이블을 쿼리할 수 있는 리소스 링크를 생성할 권한이 없을 수 있습니다. 데이터 레이크 관리자는 공유되는 각 테이블에 대해 리소스 링크를 생성하는 대신, 자리 표시자 데이터베이스를 만들고 `ALLIAMPrincipal` 그룹에 `CREATE_TABLE` 권한을 부여할 수 있습니다. 그러면 수신자 계정의 모든 IAM 보안 주체가 자리 표시자 데이터베이스에 리소스 링크를 생성하고 공유 테이블에 대한 쿼리를 시작할 수 있습니다.

   [Granting database permissions using the named resource method](granting-database-permissions.md)에서 `ALLIAMPrincipals`에 권한을 부여하는 예제 CLI 명령을 참조하세요.
+ 계정 간 권한이 보안 주체에 직접 부여되면 권한 부여 수신자만 해당 권한을 볼 수 있습니다. 수신자 AWS 계정의 데이터 레이크 관리자는 이렇게 직접 부여된 권한을 볼 수 없습니다.
+ Athena와 Redshift Spectrum은 열 수준의 액세스 제어를 지원하지만 포함만 지원하며 제외는 지원하지 않습니다. 열 수준의 액세스 제어는 AWS Glue ETL 작업에서 지원되지 않습니다.
+ 리소스가 AWS 계정과 공유되면 계정의 사용자에게만 리소스에 대한 권한을 부여할 수 있습니다. 리소스에 대한 권한을 다른 AWS 계정, 조직(자체 조직도 아님) 또는 `IAMAllowedPrincipals` 그룹에 부여할 수 없습니다.
+ 외부 계정에 데이터베이스의 `DROP` 또는 `Super`를 부여할 수 없습니다.
+ 데이터베이스 또는 테이블을 삭제하기 전에 교차 계정 권한을 취소하세요. 그렇지 않으면 분리된 리소스 공유를 삭제해야 합니다 AWS Resource Access Manager.

**다음 사항도 참조하세요.**  
[Lake Formation 태그 기반 액세스 제어 모범 사례 및 고려 사항](lf-tag-considerations.md)
더 많은 교차 계정 액세스 규칙 및 제한 사항은 [Lake Formation 권한 참조](lf-permissions-reference.md)의 [`CREATE_TABLE`](lf-permissions-reference.md#perm-create-table)를 참조하세요.