Introduction

CloudFormation supports cross-stack references with Export and Fn::ImportValue, but only inside the same AWS account and Region. If you need one stack in us-east-1 to feed values into a stack in eu-west-1, there is no direct native cross-region import.

What CloudFormation Supports Natively

Within a single Region, one stack can export an output and another stack can import it.

1Outputs:
2  VpcId:
3    Value: !Ref AppVpc
4    Export:
5      Name: shared-network-vpc-id

A second stack in the same Region can consume that exported value:

1Resources:
2  WebSecurityGroup:
3    Type: AWS::EC2::SecurityGroup
4    Properties:
5      GroupDescription: Web tier security group
6      VpcId: !ImportValue shared-network-vpc-id

That pattern is useful and well supported, but it stops at the Region boundary. If the producer and consumer stacks live in different Regions, Fn::ImportValue will not bridge them.

Why the Cross-Region Attempt Fails

CloudFormation keeps exports region-scoped. Export names must be unique only within a Region, and imports look up those names only in that same Region.

So a template deployed in eu-west-1 cannot directly import an export created in us-east-1, even if both stacks belong to the same AWS account. This is the main point that trips teams up: "cross-stack reference" is not the same thing as "cross-region reference."

Practical Alternatives

If you must pass values across Regions, use one of these designs instead of trying to force Fn::ImportValue.

1. Pass Values Through Your Deployment Pipeline

If you already deploy with CDK pipelines, GitHub Actions, CodePipeline, or Terraform orchestration around CloudFormation, the simplest answer is often:

1. deploy stack A in Region 1,
2. read its outputs with the AWS CLI or SDK,
3. pass those values as parameters into stack B in Region 2.

aws cloudformation describe-stacks \
  --region us-east-1 \
  --stack-name network-stack

Then inject the output into the second deployment as a parameter:

Parameters:
  SharedVpcId:
    Type: String

This keeps the cross-region dependency explicit and easy to reason about.

2. Replicate Shared Values Into a Regional Store

Another pattern is to write the value into a service that your second Region can read from, such as Systems Manager Parameter Store or AWS Secrets Manager, then replicate or recreate the value in the target Region as part of deployment.

The important design point is that CloudFormation is no longer doing a direct cross-region import. It is reading from a value store that your workflow maintains.

3. Use StackSets for Repeated Regional Infrastructure

If the real goal is not to read one Region's output but to deploy similar infrastructure into several Regions, StackSets may be the better fit. StackSets distribute templates across Regions and accounts, which often removes the need for one region to import another region's output in the first place.

Example: Parameter-Driven Consumer Stack

A consumer stack that accepts the value explicitly is often the cleanest design:

1AWSTemplateFormatVersion: '2010-09-09'
2Parameters:
3  SharedBucketName:
4    Type: String
5
6Resources:
7  ReplicationRole:
8    Type: AWS::IAM::Role
9    Properties:
10      AssumeRolePolicyDocument:
11        Version: '2012-10-17'
12        Statement:
13          - Effect: Allow
14            Principal:
15              Service: s3.amazonaws.com
16            Action: sts:AssumeRole

Now the deployment system, not CloudFormation import semantics, becomes responsible for supplying SharedBucketName.

Watch Out for Export Lifecycle Rules

Even in the same Region, exports create coupling. Once another stack imports an exported value, the exporting stack cannot freely modify or delete that output until the imports are removed.

That is another reason teams sometimes prefer parameter passing or nested stacks when the dependency is very tight.

When Nested Stacks Help

Nested stacks are useful when the resources belong to one larger deployment unit. They let you pass outputs between child stacks under one parent stack. This still does not create a cross-region import feature, but it is often the right answer when someone asks for cross-stack references and both stacks really belong together.

Common Pitfalls

The biggest pitfall is assuming Fn::ImportValue works globally across AWS Regions. It does not.

Another mistake is building hard infrastructure dependencies between Regions when a deployment pipeline parameter would be simpler and easier to recover.

Teams also forget the lifecycle restriction on exports. If an exported value is imported elsewhere, updates and deletes become more constrained.

Finally, do not force cross-region dependencies unless the architecture truly needs them. Multi-region systems are easier to operate when each Region can stand up from well-defined inputs rather than live cross-region coupling.

Summary

• 'Export plus Fn::ImportValue works only within the same AWS account and Region.'
• Native CloudFormation cross-region imports are not supported.
• For cross-region sharing, pass outputs through your deployment pipeline or a replicated value store.
• Use StackSets when the real goal is consistent multi-region deployment.
• Keep cross-region dependencies explicit so updates and recovery stay manageable.