AWS DevOps & Developer Productivity Blog

Simplify cross-account and cross-Region stack output references with AWS CloudFormation and CDK’s new Fn::GetStackOutput

AWS CloudFormation makes it easy to model and provision your cloud application infrastructure as code. CloudFormation templates can be written directly in JSON or YAML, or they can be generated by tools like the AWS Cloud Development Kit (CDK). Resources are created and managed by CloudFormation as units called Stacks.

Managing infrastructure across multiple AWS accounts and Regions is a common pattern for organizations adopting AWS best practices like multi-account strategies. However, sharing infrastructure values, such as VPC IDs, subnet configurations, or database endpoints, between stacks in different accounts or Regions has historically required multiple manual steps. Today, we’re excited to announce Fn::GetStackOutput, a new CloudFormation intrinsic function that lets you reference stack outputs across accounts and Regions directly in your CloudFormation templates and AWS CDK applications.

In this post, we walk through how Fn::GetStackOutput works in both CloudFormation and CDK, compare it with the existing Fn::ImportValue approach, and show you how to get started with practical examples.

The challenge: sharing values across accounts and Regions

When building multi-account AWS environments, teams frequently need to share infrastructure values across organizational boundaries. For example:

  • A networking team maintains a shared VPC in a central account, and application teams in other accounts need to reference the VPC ID.
  • A security team deploys shared security groups, and workload accounts need to consume them.
  • A platform team provisions foundational resources in one Region, and teams deploying in other Regions need those values.

Previously, you had two options:

  1. Fn::ImportValue with exports worked well within the same account and Region but did not support cross-account or cross-Region references.
  2. Manual approaches such as copying values between templates, passing parameters through CI/CD pipelines, or maintaining custom automation to keep values in sync.

Both approaches added operational overhead and increased the risk of configuration drift when values changed.

Introducing Fn::GetStackOutput

Fn::GetStackOutput is a new CloudFormation intrinsic function that resolves stack output references at deployment time. It provides two key advantages over the existing export/import model:

  1. Cross-account and cross-Region support. You can reference outputs from stacks in any account and Region (within the same partition).
  2. No exports required. You can reference any stack output directly, without the producing stack needing to declare an Export.

How it works

When CloudFormation processes a template containing Fn::GetStackOutput, it:

  1. Identifies the referenced stack and output.
  2. If a RoleArn is specified, assumes that role to access the target account.
  3. Calls DescribeStacks to retrieve the output value from the specified stack and Region.
  4. Resolves the value and continues template processing.

The function accepts four parameters:

  • StackName (required): The name of the stack that contains the output you want to reference.
  • OutputName (required): The logical ID of the output to reference. This is the key defined in the Outputs section of the referenced stack’s template, not an export name.
  • Region (optional): The AWS Region where the referenced stack is deployed. Defaults to the Region of the stack being created or updated.
  • RoleArn (optional): The ARN of an IAM role with cloudformation:DescribeStacks permissions on the referenced stack. Use this parameter when referencing a stack in a different AWS accoun

Walkthrough: four scenarios

Let’s walk through a practical example. Suppose you have a networking stack that creates a VPC:

`# ProducerStack - deployed in us-west-2, account 111111111111
Resources:
  MyVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
Outputs:
  VpcId:
    Value: !Ref MyVPC 
`

Now let’s see how to reference this VPC ID from different stacks.

Scenario 1: Same account, same Region

The simplest case. Both stacks are in us-west-2 in account 111111111111:

`Resources:
  MyInstance:
    Type: AWS::EC2::Instance
    Properties:
      VpcId:
        Fn::GetStackOutput:
          StackName: ProducerStack
          OutputName: VpcId
`

No Region or RoleArn needed. CloudFormation uses the current stack’s Region and execution role.

Scenario 2: Same account, different Region

Your consumer stack is in us-east-1, but the VPC is in us-west-2:

`Resources:
  MyInstance:
    Type: AWS::EC2::Instance
    Properties:
      VpcId:
        Fn::GetStackOutput:
          StackName: ProducerStack
          OutputName: VpcId
          Region: us-west-2
`

The Region parameter tells CloudFormation where to find the referenced stack.

Scenario 3: Different account, same Region

Your consumer stack is in account 222222222222, and the VPC is in account 111111111111:

`Resources:
  MyInstance:
    Type: AWS::EC2::Instance
    Properties:
      VpcId:
        Fn::GetStackOutput:
          StackName: ProducerStack
          OutputName: VpcId
          RoleArn: arn:aws:iam::111111111111:role/GetStackOutputRole
`

The RoleArn specifies a role in the producer account with cloudformation:DescribeStacks permissions.

Scenario 4: Different account and different Region

Combine both parameters for the most flexible scenario:

`Resources:
  MyInstance:
    Type: AWS::EC2::Instance
    Properties:
      VpcId:
        Fn::GetStackOutput:
          StackName: ProducerStack
          OutputName: VpcId
          RoleArn: arn:aws:iam::111111111111:role/GetStackOutputRole
          Region: us-west-2
`

Setting up IAM for cross-account access

When referencing stacks in other accounts, the IAM role specified in RoleArn needs cloudformation:DescribeStacks permissions:

`{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["cloudformation:DescribeStacks"],
      "Resource": "*"
    }
  ]
}
`

For a more restrictive policy, scope the Resource to the specific stack ARN you want to reference.

The IAM role should be assumable by your consumer stack’s execution role. For this example, we’ll grant generic access to account 222222222222 in the trust policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "222222222222"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Fn::GetStackOutput vs. Fn::ImportValue

If you’re already using Fn::ImportValue, you may be wondering when to use which. Here’s a comparison:

Fn::ImportValue:

  • Same account, same Region: Supported
  • Cross-account: Not supported
  • Cross-Region: Not supported
  • Requires explicit Export: Yes
  • Reference type: Strong — blocks deletion of the exporting stack
  • Referential integrity: Yes

Fn::GetStackOutput:

  • Same account, same Region: Supported
  • Cross-account: Supported
  • Cross-Region: Supported
  • Requires explicit Export: No
  • Reference type: Weak — resolved at stack create or update time
  • Referential integrity: No

Use Fn::ImportValue when you need strong referential integrity within the same account and Region. CloudFormation prevents you from deleting a stack that exports values consumed by other stacks.

Use Fn::GetStackOutput when you need cross-account or cross-Region references, or when you want to avoid managing explicit exports.

Understanding weak references

An important difference to understand: Fn::GetStackOutput creates weak references. This means:

  • The referenced stack doesn’t know it’s being referenced. Unlike exports, there is no dependency tracking between the producer and consumer stacks.
  • Deleting the producer stack is not blocked. If you delete the producer stack or remove the referenced output, CloudFormation does not prevent you. However, the next time the consumer stack is created or updated, the operation will fail because the reference can no longer be resolved. Because of this, deleting the producer stack may cause impact in the consumer stack.
  • Changes are not automatically propagated. If the output value changes in the producer stack, the consumer stack is not automatically updated. You need to run an update on the consumer stack to pick up the new value.

Best practices for weak references

  • Enable deletion protection on producer stacks that other stacks depend on.
  • Use stack policies to prevent accidental modifications to critical outputs.
  • Document dependencies between stacks so teams are aware of cross-stack relationships.
  • Scope IAM roles narrowly by restricting DescribeStacks permissions to specific stack ARNs when possible.

Using Fn::GetStackOutput with AWS CDK

CDK now uses Fn::GetStackOutput to automatically resolve cross-region and cross-account references in the same app. Previously, this required opting in through the crossRegionReferences Stack parameter.

Here’s an example of how cross-account references work in CDK:

class Provider extends Stack {
  public readonly vpc: ec2.Vpc;

  constructor(scope: Construct, id: string, props: StackProps) {
    super(scope, id, props);
    this.vpc = new ec2.Vpc(this, 'MyVpc', { maxAzs: 2 }); 
  }
}

interface ConsumerProps extends StackProps {
  readonly vpc: ec2.IVpc;
}

class Consumer extends Stack {
  constructor(scope: Construct, id: string, props: ConsumerProps) {
    super(scope, id, props);
    new ec2.SecurityGroup(this, 'MySG', {
      vpc: props.vpc,
      description: 'SG in Consumer using VPC from Provider',
    }); 
  }
}

const app = new App({
  context: {
    // choice between 'strong', 'weak', or 'both'
    '@aws-cdk/core:defaultCrossStackReferences': 'weak',
  },
});

const provider = new Provider(app, 'Provider', {
  env: { account: '111111111', region: 'us-west-2' },
});

new Consumer(app, 'Consumer', {
  env: { account: '111111111', region: 'us-west-2' },
  vpc: provider.vpc,
});

The CDK synthesizes this into a template using Fn::GetStackOutput with no additional configuration required from the user. Since this is a cross-account reference, CDK will also generate a new IAM role that can be assumed by the consumer stack.

In case of same account, cross-region, or same account and region, you can tell the CDK whether to generate strong or weak references, using the @aws-cdk/core:defaultCrossStackReferences context key. Here is how it works:

  • Flag=strong (default when unset):
    • Same account and Region: generates a Fn::ImportValue reference
    • Same account, cross-Region: generates an ExportWriter/ExportReader pair (legacy custom resources)
    • Cross-account: not possible, falls back to weak
  • Flag=both:
    • Same account and Region: generates a Fn::GetStackOutput reference and an Export, but not Fn::ImportValue
    • Same account, cross-Region: generates a Fn::GetStackOutput reference and an ExportWriter, but not the ExportReader
    • Cross-account: generates a Fn::GetStackOutput reference and a cross-account IAM role
  • Flag=weak:
    • Same account and Region: generates a Fn::GetStackOutput reference
    • Same account, cross-Region: generates a Fn::GetStackOutput reference
    • Cross-account: generates a Fn::GetStackOutput reference and a cross-account IAM role

You can also resolve cross-region or cross-account references between stacks in different CDK Applications explicitly using the Fn.getStackOutput() method. For more information, see the CDK documentation.

Getting started

To start using Fn::GetStackOutput:

  1. Output the value you want to reference. See CloudFormation template Outputs syntax to understand declaring an output.
  2. For cross-account references, create an IAM role in the producer account with cloudformation:DescribeStacks permissions.
  3. Add the function to your template. Use the Fn::GetStackOutput syntax with the appropriate parameters.
  4. Deploy your stack. CloudFormation resolves the reference during the create or update operation.

Conclusion

Fn::GetStackOutput simplifies multi-account and multi-Region infrastructure management by enabling direct references between stacks without requiring explicit exports or custom workarounds. Whether you’re using CloudFormation templates directly or building with the AWS CDK, this new capability reduces operational overhead and the risk of configuration drift across your organization.

This feature is available in all AWS Regions where CloudFormation is supported. To learn more, visit the Fn::GetStackOutput documentation in the CloudFormation Template Reference Guide.

Author:

Idriss Laouali Abdou

Idriss is a Sr. Product Manager Technical on the AWS Infrastructure-as-Code team based in Seattle. He focuses on improving developer productivity through AWS CloudFormation and StackSets Infrastructure provisioning experiences. Outside of work, you can find him creating educational content for thousands of students, cooking, or dancing.