

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

# 공유 VPC 없이 Amazon Keyspaces에 대한 교차 계정 액세스 구성
<a name="access.cross-account.noVPC.setup"></a>

Amazon Keyspaces 테이블과 프라이빗 VPC 엔드포인트를 서로 다른 계정에서 소유하고 있지만 VPC를 공유하지는 않는 경우에도 애플리케이션은 VPC 엔드포인트를 사용하여 크로스 계정을 연결할 수 있습니다. 계정이 VPC 엔드포인트를 공유하지 않으므로 `Account A:111111111111`, `Account B:222222222222`, `Account C:333333333333`에 자체 VPC 엔드포인트가 필요합니다. Cassandra 클라이언트 드라이버에게 Amazon Keyspaces는 다중 노드 클러스터가 아닌 단일 노드처럼 보입니다. 연결 시 클라이언트 드라이버는 DNS 서버에 도달하여 계정의 VPC에서 사용 가능한 엔드포인트 중 하나를 반환합니다.

퍼블릭 엔드포인트를 사용하거나 각 계정에 프라이빗 VPC 엔드포인트를 배포하여 공유 VPC 엔드포인트 없이 여러 계정의 Amazon Keyspaces 테이블에 액세스할 수도 있습니다. 공유 VPC를 사용하지 않는 경우 각 계정에는 자체 VPC 엔드포인트가 필요합니다. 이 예제에서는 `Account A:111111111111`, `Account B:222222222222`, `Account C:333333333333`에 자체 VPC 엔드포인트가 있어야 `Account A:111111111111`의 테이블에 액세스할 수 있습니다. 이 구성에서 VPC 엔드포인트를 사용하는 경우 Amazon Keyspaces는 Cassandra 클라이언트 드라이버에 다중 노드 클러스터 대신 단일 노드 클러스터로 나타납니다. 연결 시 클라이언트 드라이버는 DNS 서버에 도달하여 계정의 VPC에서 사용 가능한 엔드포인트 중 하나를 반환합니다. 하지만 클라이언트 드라이버는 `system.peers` 테이블에 액세스하여 추가 엔드포인트를 검색할 수 없습니다. 사용 가능한 호스트가 적기 때문에 드라이버의 연결 수가 줄어듭니다. 이를 조정하려면 드라이버의 연결 풀 설정을 3배 늘립니다.

![\[공유 VPC가 없는 동일한 AWS 리전 에서 동일한 조직이 소유한 세 개의 계정을 보여주는 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/keyspaces/latest/devguide/images/keyspaces_cross-account_noVPC.png)


`Account A:111111111111`는 `Account B:222222222222` 및가 액세스`Account C:333333333333`해야 하는 리소스(Amazon Keyspaces 테이블)가 포함된 계정이고 `Account A:111111111111`는 *신뢰할 수* 있는 계정입니다. `Account B:222222222222` 및 `Account C:333333333333`는의 리소스(Amazon Keyspaces 테이블)에 액세스해야 하는 보안 주체가 있는 계정`Account A:111111111111`이므로 `Account B:222222222222` 및 `Account C:333333333333`는 *신뢰할* 수 있는 계정입니다. 신뢰하는 계정은 IAM 역할을 공유하여 신뢰 받는 계정에 권한을 부여합니다. 다음 절차에서는 `Account A:111111111111`에서 필요한 구성 단계를 간략하게 설명합니다.

**`Account A:111111111111`에 대한 구성**

1. 에서 Amazon Keyspaces 키스페이스 및 테이블을 생성합니다`Account A:111111111111`.

1. Amazon Keyspaces 테이블에 대한 전체 액세스 권한과 Amazon Keyspaces 시스템 테이블에 대한 읽기 액세스 권한이 `Account A:111111111111` 있는에서 IAM 역할을 생성합니다.

   ```
   {
      "Version":"2012-10-17",		 	 	 
      "Statement":[
         {
            "Effect":"Allow",
            "Action":[
               "cassandra:Select",
               "cassandra:Modify"
            ],
            "Resource":[
               "arn:aws:cassandra:us-east-1:111111111111:/keyspace/mykeyspace/table/mytable",
               "arn:aws:cassandra:us-east-1:111111111111:/keyspace/system*"
            ]
         }
      ]
   }
   ```

1. `Account B:222222222222` 및의 보안 주체가 역할을 신뢰할 수 있는 계정으로 수임할 `Account C:333333333333` 수 `Account A:111111111111` 있도록에서 IAM 역할에 대한 신뢰 정책을 구성합니다. 방법은 다음 예제와 같습니다.

   ```
   {
     "Version": "2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "AWS": [
             "arn:aws:iam::222222222222:role/Cross-Account-Role-B",
             "arn:aws:iam::333333333333:role/Cross-Account-Role-C"
           ]
         },
         "Action": "sts:AssumeRole",
         "Condition": {}
       }
     ]
   }
   ```

   크로스 계정 IAM 정책에 대한 자세한 내용은 IAM 사용 설명서의 [크로스 계정 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html)을 참조하세요.

1. 에서 VPC 엔드포인트를 구성`Account A:111111111111`하고 및가 VPC 엔드포인트를 `Account A` 사용하여에서 역할을 수임`Account B:222222222222``Account C:333333333333`할 수 있는 권한을 엔드포인트에 연결합니다. 이러한 권한은 연결된 VPC 엔드포인트에 유효합니다. VPC 엔드포인트 정책에 대한 자세한 내용은 [Amazon Keyspaces의 인터페이스 VPC 엔드포인트에 대한 액세스 제어](vpc-endpoints.md#interface-vpc-endpoints-policies) 섹션을 참조하세요.

   ```
   {{
     "Version": "2012-10-17",		 	 	 
     "Statement": [
       {
         "Sid": "AllowAccessfromSpecificIAMroles",
         "Effect": "Allow",
         "Action": "cassandra:*",
         "Resource": "*",
         "Principal": "*",
         "Condition": {
           "ArnEquals": {
             "aws:PrincipalArn": [
               "arn:aws:iam::222222222222:role/Cross-Account-Role-B",
               "arn:aws:iam::333333333333:role/Cross-Account-Role-C"
             ]
           }
         }
       }
     ]
   }
   ```

**`Account B:222222222222` 및 `Account C:333333333333`에서의 구성**

1. `Account B:222222222222`및 `Account C:333333333333`에서 새 역할을 만들고 `Account A:111111111111`에서 생성된 공유 역할을 주체가 맡도록 허용하는 다음 정책을 연결합니다.

   ```
   {
       "Version": "2012-10-17",		 	 	 
       "Statement": {
               "Effect": "Allow",
               "Action": "sts:AssumeRole",
               "Resource": "arn:aws:iam::111111111111:role/keyspaces_access"
           }
   }
   ```

   보안 주체가 공유 역할을 수임하도록 허용하는 것은 AWS Security Token Service ()의 `AssumeRole` API를 사용하여 구현됩니다AWS STS. 자세한 내용은 [ IAM 사용 설명서의 소유한 다른의 IAM 사용자에게 액세스 권한 제공을 참조 AWS 계정 하세요](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html).

1. `Account B:222222222222` 및에서 SIGV4 인증 플러그인을 활용하는 애플리케이션을 생성할 `Account C:333333333333`수 있습니다. 그러면 애플리케이션이 공유 역할을 수임하여에 있는 Amazon Keyspaces 테이블에 연결할 수 있습니다`Account A:111111111111`. SIGV4에 대한 자세한 내용은 [Amazon Keyspaces에 프로그래밍 방식으로 액세스하기 위한 자격 증명 만들기](programmatic.credentials.md) 섹션을 참조하세요. 다른 AWS 계정의 역할을 수임하도록 애플리케이션을 구성하는 방법에 대한 자세한 내용은 SDK 및 도구 참조 안내서의 [인증 및 액세스를](https://docs.aws.amazon.com/sdkref/latest/guide/access.html) 참조하세요. *AWS SDKs *