Cross Account VPC Endpoint Access

Interface endpoints can be shared across VPCs - see https://www.linkedin.com/pulse/how-share-interface-vpc-endpoints-across-aws-accounts-steve-kinsman/ for how to do it.

However the DynamoDB VPC endpoint is a gateway endpoint which can't be shared - see https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-ddb.html for example which says "Endpoint connections cannot be extended out of a VPC. Resources on the other side of a VPN connection, VPC peering connection, transit gateway, or AWS Direct Connect connection in your VPC cannot use a gateway endpoint to communicate with DynamoDB".

In reality there's no reason to share a gateway endpoint as they are free. Just create them in each VPC.

We can use the VPC endpoints to access dynamo DB from Account a via the AWS lambda function in Account B. We will create the cross-account role in Account A for Account B to access dynamo DB via the AWS lambda function using cross-account with STS.

Here we need to create two endpoints:

1. For DynamoDB
2. For STS

const AWS = require('aws-sdk')
var sts = new AWS.STS({endpoint:'https://sts.us-west-2.amazonaws.com'});

exports.handler = async (event) => {
    let stsParams = {
        RoleArn: <Cross-Account-RoleARN>
        DurationSeconds: 3600,
        RoleSessionName: <RoleSessionName> // any string
    };
    const stsResults = await sts.assumeRole(stsParams).promise();
    let dynamodb = new AWS.DynamoDB({
        region: <Region>,
        accessKeyId: stsResults.Credentials.AccessKeyId,
        secretAccessKey: stsResults.Credentials.SecretAccessKey,
        sessionToken: stsResults.Credentials.SessionToken,
        apiVersion: '2012-08-10'
    });
    var params = {
        TableName: <DynamoDB-TableName>
    };
    let scan = await dynamodb.scan(params).promise();
    console.log({ scan });
};

Yes, it is possible to set up a cross-account VPC endpoint in AWS. This can be done by creating a VPC endpoint in one account and then creating a VPC peering connection to the other account. Once the VPC peering connection is established, the VPC endpoint in the first account can be used to access resources in the second account. It is necessary to note that the VPC peering connection must be in the "active" state for the cross-account VPC endpoint to work correctly.

Afaik Dynamodb can only use the VPC Endpoint in the local account. In this case you need the dynamodb vpc endpoint in B for the lambda.

I don't know what exact parameters are passed on the API call when you do the sts assume. I would enable the cloudtrail data events for Dynamodb in both accounts and run the request. Disable the Condition in the policy and analyse the logs.

My expectation is dat the dynamodb api call is not for a database in the same account, the vpce parameter isn't passed on.

Yes you need to create dynamodb gateway endpoints in account B(where your lambda resides). Configure the route table for the endpoint as applicable. If your lambda is outside your own created vpc of Account B - you don't need to do anything else. You can just call STS to assumeRole for account A and you should be fine accessing dynamoDB since the STS networking happens via Internet and dynamoDb network is private via endpoint. If lambda inside your created vpc - as long as it is in subnet having internet access in its route table the "public" one you should be fine and things happen just like mentioned earlier. But if your lambda is inside "private" subnet then you need to additionally create interface endpoint and add to the route table for STS to work if there is no NAT available in your "public" subnet. Here the STS api call will happen privately via AWS network without requiring internet access.