Cross-Stack Resource Sharing in AWS CDK: Direct References vs SSM Parameters

Overview

Two primary patterns exist for sharing resources between CDK stacks: passing direct object references and using SSM Parameter Store. Each has distinct trade-offs affecting deployment flexibility, coupling, and operational complexity.

Approach 1: Direct Reference Passing

How it works: Export stack exposes resource as public property; importing stack receives object via props.

// bin/import-export.ts:12-16
const statefulExport = new StatefulExportStack(app, 'StatefulExportStack');
const statelessExport = new StatelessExportStack(app, 'StatelessExportStack', {
  table: statefulExport.table,
});

Under the hood: CDK auto-generates CloudFormation exports/imports via Fn::ImportValue¹.

Advantages

• Type-safe compile-time checking
• Zero additional AWS services required
• Explicit stack dependencies in code²

Limitations

• Update blocking: Cannot modify/delete exporting stack while values referenced³
• Same-region only: Cross-region not supported⁴
• 200 export limit per stack⁵
• Tight coupling: Creates hidden CloudFormation dependencies that CDK abstracts away⁶

Approach 2: SSM Parameter Store

How it works: Export stack writes values to Parameter Store; import stack reads at deploy time.

// lib/stateful-param.ts:19-22
new cdk.aws_ssm.StringParameter(this, "TableArnParameter", {
  parameterName: props.tableArnParameterName,
  stringValue: table.tableArn,
});

// lib/stateless-param.ts:13-16
const tableArnParameter = cdk.aws_ssm.StringParameter
  .fromStringParameterName(this, 'TableArnParameter', props.tableArnParameterName);
const tableArn = tableArnParameter.stringValue;

Advantages

• Decoupled stacks: No CloudFormation export/import dependencies²⁶
• Update flexibility: Can modify exporting stack without breaking dependents
• No export limits: Unlimited parameters per stack
• Cross-account support: Possible with IAM permissions⁷
• Hierarchical organization: /myapp/stateless/tableArn structure
• Usable outside CloudFormation: CLI, Lambda, etc can read same params

Limitations

• IAM permissions required: Read access to SSM needed
• No CloudFormation validation: Stack can deploy even if parameter missing
• Deployment coordination: Must deploy exporting stack first; no automatic ordering⁶
• Slightly higher complexity: Additional construct vs direct props

When to Use Each

Direct References:

• Tightly coupled stacks in same CDK app
• Resources rarely change
• Need type safety and compile-time validation
• Same-region deployments

SSM Parameters:

• Independent deployment lifecycles needed
• Cross-account/cross-app scenarios
• Want update flexibility on exporting stack⁶
• Configuration values that change without redeployment²

Critical Gotcha: The Export Lock

Most critical limitation: once CloudFormation export exists, cannot delete/rename until ALL importing stacks removed³. As Chariot Solutions notes: "the rules that govern cross-stack references won't let you redeploy the first stack"⁶.

SSM params avoid this entirely—exporting stack fully independent.

Best Practice per AWS

AWS re:Post recommends SSM parameters for production: "sharing references with SSM parameters...unties the relationship between exporting stack and importing stack"².

Sources