Cross Account resource import and source account tracking

I propose adding a source AWS AccountId property to all Constucts to keep track of the account the resource was defined in.

With the import feature it allows me to pull in “stubs” of resource from other accounts and use it for cross-account operations.

Right now some resources use ARNs which keeps implicilty track of the source account and allow usage of cross account ARNs in for example policies. But not all resources use ARNs. In addition the account Id is not usable independently of the ARN.

Use Case

I thought about use cases like having a APIGW in one account and a Lambda in another account. CDK has already a feature for importing resources. I could import a lambda function by ARN and use it in the code to wire up with APIGW or generate metrics:

Account A – define the Lambda and import APIGW

const fun = lambda.Function( …);
const apigw = apigateway.fromRestApiId(…); // import from account B
apigw.addLambda(fun); // yeah, it’s not exactly as it works today but you get the idea. It would setup the necessary permissions to allow APIGW from account B to call the lambda

Account B – define the APIGW and a cross account tdashboard

const fun = lambda.Function.fromArn("arn:aws:.."); // import from account A by using the ARN
 
dashboard.addWidgets(new GraphWidget({   // build cross account dashboard by using source account Id
  left: [fun.metricErrors()]
});
 
new apigateway.LambdaRestApi(this, 'myapi', {
  handler: fun // actually that case is most likely already working since the ARN is just forwarded
});

That is already working as long as everything is in the same account. But since right now the fromArn is not persisting the AccountId it’s not possible to use the account Id for something like cross account dashboards.

Proposed Solution

I’m wondering if there is the possibility to keep track of AccountId for each construct. Per default it would be always the current account but in case an ARN is used or the AccountId is overridden the other account is used. That would allow for using the AccountId cross account or deny cross account usage in case it’s not supported (like for cross account metrics which is does not work today). Right now that only implicitly works for everything which uses with ARNs since the ARN is including the AccountId.

Something like that should work:

const fun = lambda.Function.fromArn("arn:aws:..");
fun.accountId;

or

const apigw = apigateway.fromRestApiId(“xsthhtkn12”, accountId);
apigw.accountId;

Other

Right now only a few resources support cross account (S3, SNS, Lambda, APIGW, Metrics, Dashboards, SSM Documents, ALB, KMS, SQS, VPCe, maybe more?) but I assume the usage of cross account resources will increase rapidly soon. I was wondering if someone as similar thoughts about making cross account usage easier.

related:

• example of cross account pipelines (by using ARNs): https://github.com/aws-samples/aws-cdk-examples/pull/161

• support for cross account dashboards: https://github.com/aws/aws-cdk/issues/5261

• 👋 I may be able to implement this feature request

• ⚠️ This feature might incur a breaking change

---

This is a 🚀 Feature Request

[skinny85]

I was thinking we need this too. Probably a region property as well, not only account.

[nija-at]

completed here - https://github.com/aws/aws-cdk/pull/8280