# Configure cross-account access to Amazon Keyspaces with VPC endpoints
You can create and use separate AWS accounts to isolate resources and for use in different environments, for example development and production. This topic walks you through cross-account access for Amazon Keyspaces using interface VPC endpoints in an Amazon Virtual Private Cloud. For more information about IAM cross-account access configuration, see [Example scenario using separate development and production accounts](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html#id_roles_common-scenarios_aws-accounts-example) in the IAM User Guide.
For more information about Amazon Keyspaces and private VPC endpoints, see [Using Amazon Keyspaces with interface VPC endpoints](vpc-endpoints.md).
**Topics**
+ [Configure cross-account access in a shared VPC](access.cross-account.sharedVPC.md)
+ [Configure cross-account access without a shared VPC](access.cross-account.noVPC.setup.md)
# Configure cross-account access to Amazon Keyspaces using VPC endpoints in a shared VPC
You can create different AWS accounts to separate resources from applications. For example, you can create one account for your Amazon Keyspaces tables, a different account for applications in a development environment, and another account for applications in a production environment. This topic walks you through the configuration steps required to set up cross-account access for Amazon Keyspaces using interface VPC endpoints in a shared VPC.
For detailed steps how to configure a VPC endpoint for Amazon Keyspaces, see [Step 3: Create a VPC endpoint for Amazon Keyspaces](vpc-endpoints-tutorial.create-endpoint.md).
In this example we use the following three accounts in a shared VPC:
+ `Account A:111111111111` – This account contains infrastructure, including the VPC endpoints, the VPC subnets, and Amazon Keyspaces tables.
+ `Account B:222222222222` – This account contains an application in a development environment that needs to connect to the Amazon Keyspaces table in `Account A:111111111111`.
+ `Account C:333333333333` – This account contains an application in a production environment that needs to connect to the Amazon Keyspaces table in `Account A:111111111111`.
![\[Diagram showing three different accounts in owned by the same organization in the same AWS Region that use a shared VPC.\]](http://docs.aws.amazon.com/keyspaces/latest/devguide/images/keyspaces_cross-account_sharedVPC.png)
`Account A:111111111111` is the account that contains the resources (an Amazon Keyspaces table) that `Account B:222222222222` and `Account C:333333333333` need to access, so `Account A:111111111111` is the *trusting* account. `Account B:222222222222` and `Account C:333333333333` are the accounts with the principals that need access to the resources (an Amazon Keyspaces table) in `Account A:111111111111`, so `Account B:222222222222` and `Account C:333333333333` are the *trusted* accounts. The trusting account grants the permissions to the trusted accounts by sharing an IAM role. The following procedure outlines the configuration steps required in `Account A:111111111111`.
**Configuration for `Account A:111111111111`**
1. Use AWS Resource Access Manager to create a resource share for the subnet and share the private subnet with `Account B:222222222222` and `Account C:333333333333`.
`Account B:222222222222` and `Account C:333333333333` can now see and create resources in the subnet that has been shared with them.
1. Create an Amazon Keyspaces private VPC endpoint powered by AWS PrivateLink. This creates multiple endpoints across shared subnets and DNS entries for the Amazon Keyspaces service endpoint.
1. Create an Amazon Keyspaces keyspace and table.
1. Create an IAM role in `Account A:111111111111` that has full access to the Amazon Keyspaces table, read access to the Amazon Keyspaces system tables, and is able to describe the Amazon EC2 VPC resources as shown in the following policy example.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "CrossAccountAccess",
"Effect": "Allow",
"Action": [
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeVpcEndpoints",
"cassandra:*"
],
"Resource": "*"
}
]
}
```
1. Configure a trust policy for the IAM role in `Account A:111111111111` so that `Account B:222222222222` and `Account C:333333333333` can assume the role as trusted accounts. This is shown in the following example.
```
{
"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": {}
}
]
}
```
For more information about cross-account IAM policies, see [Cross-account policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html) in the IAM User Guide.
**Configuration in `Account B:222222222222` and `Account C:333333333333`**
1. In `Account B:222222222222` and `Account C:333333333333`, create new roles and attach the following policy that allows the principal to assume the shared role created in `Account A:111111111111`.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
Allowing the principal to assume the shared role is implemented using the `AssumeRole` API of the AWS Security Token Service (AWS STS). For more information, see [ Providing access to an IAM user in another AWS account that you own](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) in the IAM User Guide.
1. In `Account B:222222222222` and `Account C:333333333333`, you can create applications that utilize the SIGV4 authentication plugin, which allows an application to assume the shared role to connect to the Amazon Keyspaces table located in `Account A:111111111111` through the VPC endpoint in the shared VPC. For more information about the SIGV4 authentication plugin, see [Create credentials for programmatic access to Amazon Keyspaces](programmatic.credentials.md). For more information on how to configure an application to assume a role in another AWS account, see [Authentication and access](https://docs.aws.amazon.com/sdkref/latest/guide/access.html) in the *AWS SDKs and Tools Reference Guide*.
# Configuring cross-account access to Amazon Keyspaces without a shared VPC
If the Amazon Keyspaces table and private VPC endpoint are owned by different accounts but are not sharing a VPC, applications can still connect cross-account using VPC endpoints. Because the accounts are not sharing the VPC endpoints, `Account A:111111111111`, `Account B:222222222222`, and `Account C:333333333333` require their own VPC endpoints. To the Cassandra client driver, Amazon Keyspaces appears like a single node instead of a multi-node cluster. Upon connection, the client driver reaches the DNS server which returns one of the available endpoints in the account’s VPC.
You can also access Amazon Keyspaces tables across different accounts without a shared VPC endpoint by using the public endpoints or deploying a private VPC endpoint in each account. When not using a shared VPC, each account requires its own VPC endpoint. In this example `Account A:111111111111`, `Account B:222222222222`, and `Account C:333333333333` require their own VPC endpoints to access the table in `Account A:111111111111`. When using VPC endpoints in this configuration, Amazon Keyspaces appears as a single node cluster to the Cassandra client driver instead of a multi-node cluster. Upon connection, the client driver reaches the DNS server which returns one of the available endpoints in the account’s VPC. But the client driver is not able to access the `system.peers` table to discover additional endpoints. Because there are less hosts available, the driver makes less connections. To adjust this, increase the connection pool setting of the driver by a factor of three.
![\[Diagram showing three different accounts in owned by the same organization in the same AWS Region without a shared VPC.\]](http://docs.aws.amazon.com/keyspaces/latest/devguide/images/keyspaces_cross-account_noVPC.png)
`Account A:111111111111` is the account that contains the resources (an Amazon Keyspaces table) that `Account B:222222222222` and `Account C:333333333333` need to access, so `Account A:111111111111` is the *trusting* account. `Account B:222222222222` and `Account C:333333333333` are the accounts with the principals that need access to the resources (an Amazon Keyspaces table) in `Account A:111111111111`, so `Account B:222222222222` and `Account C:333333333333` are the *trusted* accounts. The trusting account grants the permissions to the trusted accounts by sharing an IAM role. The following procedure outlines the configuration steps required in `Account A:111111111111`.
**Configuration for `Account A:111111111111`**
1. Create an Amazon Keyspaces keyspace and table in `Account A:111111111111`.
1. Create an IAM role in `Account A:111111111111` that has full access to the Amazon Keyspaces table and read access to the Amazon Keyspaces system tables.
```
{
"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. Configure a trust policy for the IAM role in `Account A:111111111111` so that principals in `Account B:222222222222` and `Account C:333333333333` can assume the role as trusted accounts. This is shown in the following example.
```
{
"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": {}
}
]
}
```
For more information about cross-account IAM policies, see [Cross-account policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html) in the IAM User Guide.
1. Configure the VPC endpoint in `Account A:111111111111` and attach permissions to the endpoint that allow the roles from `Account B:222222222222` and `Account C:333333333333` to assume the role in `Account A` using the VPC endpoint. These permissions are valid for the VPC endpoint that they are attached to. For more information about VPC endpoint policies, see [Controlling access to interface VPC endpoints for Amazon Keyspaces](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"
]
}
}
}
]
}
```
**Configuration in `Account B:222222222222` and `Account C:333333333333`**
1. In `Account B:222222222222` and `Account C:333333333333`, create new roles and attach the following policy that allows the principal to assume the shared role created in `Account A:111111111111`.
```
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111111111111:role/keyspaces_access"
}
}
```
Allowing the principal to assume the shared role is implemented using the `AssumeRole` API of the AWS Security Token Service (AWS STS). For more information, see [ Providing access to an IAM user in another AWS account that you own](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) in the IAM User Guide.
1. In `Account B:222222222222` and `Account C:333333333333`, you can create applications that utilize the SIGV4 authentication plugin, which allows an application to assume the shared role to connect to the Amazon Keyspaces table located in `Account A:111111111111`. For more information about the SIGV4 authentication plugin, see [Create credentials for programmatic access to Amazon Keyspaces](programmatic.credentials.md). For more information on how to configure an application to assume a role in another AWS account, see [Authentication and access](https://docs.aws.amazon.com/sdkref/latest/guide/access.html) in the *AWS SDKs and Tools Reference Guide*.