Outputs for cross-stack references in AWS - Commands & Configuration

Introduction

When you build cloud resources in separate groups called stacks, you often need to share information between them. Outputs let one stack share values like resource IDs or URLs so another stack can use them easily.

When you create a database in one stack and want to connect your app in another stack to that database.

When you deploy a network setup in one stack and need to use its subnet IDs in another stack.

When you want to share a storage bucket name created in one stack with another stack that uploads files.

When you separate your infrastructure into parts for easier management but still need them to work together.

When you want to avoid hardcoding resource details and instead get them dynamically from another stack.

Config File - main.yaml

main.yaml

AWSTemplateFormatVersion: '2010-09-09'
Resources:
  MyBucket:
    Type: AWS::S3::Bucket
Outputs:
  BucketNameOutput:
    Description: "Name of the S3 bucket"
    Value: !Ref MyBucket
    Export:
      Name: MyBucketName

This CloudFormation template creates an S3 bucket resource named MyBucket. The Outputs section defines BucketNameOutput which shares the bucket's name. The Export key with Name: MyBucketName makes this output available for other stacks to import by this name.

Commands

This command creates a stack named 'bucket-stack' using the template file 'main.yaml'. It provisions the S3 bucket and sets up the output for sharing.

Terminal

aws cloudformation deploy --template-file main.yaml --stack-name bucket-stack

Expected Output

Waiting for stack create/update to complete...

Successfully created/updated stack - bucket-stack

→

--template-file - Specifies the CloudFormation template file to use

→

--stack-name - Names the stack to create or update

This command lists all exported output values from all stacks, showing the shared names and their values.

Terminal

aws cloudformation list-exports

Expected Output

Exports:

- ExportingStackId: arn:aws:cloudformation:us-east-1:123456789012:stack/bucket-stack/abcd1234

  Name: MyBucketName

  Value: bucket-stack-mybucket-1a2b3c4d5e6f7g

This command deploys another stack 'app-stack' using 'app.yaml' and passes the bucket name from the exported output as a parameter to connect resources.

Terminal

aws cloudformation deploy --template-file app.yaml --stack-name app-stack --parameter-overrides BucketName=bucket-stack-mybucket-1a2b3c4d5e6f7g

Expected Output

Waiting for stack create/update to complete...

Successfully created/updated stack - app-stack

→

--parameter-overrides - Passes parameters to the stack, here using the exported bucket name

Key Concept

If you remember nothing else from this pattern, remember: outputs let one stack share resource details that other stacks can import to connect resources safely and dynamically.

Common Mistakes

Not adding the Export name in the output section

Without Export, other stacks cannot import the output value, so cross-stack sharing fails.

Always include the Export key with a unique name in the output you want to share.

Trying to import an output that does not exist or has a different export name

The stack import will fail because it cannot find the matching exported output.

Check the export names carefully using 'aws cloudformation list-exports' before importing.

Hardcoding exported values instead of importing them dynamically

Hardcoding causes errors if resource names change or stacks are redeployed with different values.

Use CloudFormation's ImportValue function or pass parameters dynamically from exported outputs.

Summary

Define outputs with Export names in one stack to share resource details.

Use AWS CLI to deploy stacks and list exported outputs.

Import exported values in other stacks to connect resources dynamically.

Practice

1. What is the main purpose of using Outputs in AWS CloudFormation stacks?

easy

A. To share important values like resource IDs between different stacks

B. To delete resources automatically after stack deletion

C. To increase the stack creation speed

D. To encrypt stack resources

Solution

1. Step 1: Understand Outputs role

   Outputs provide a way to expose key information from one stack.

2. Step 2: Identify sharing purpose

   This information can be used by other stacks to reference resources like IDs or names.

3. Final Answer:

   To share important values like resource IDs between different stacks -> Option A

4. Quick Check:

   Outputs share values across stacks = A [OK]

Hint: Outputs share values between stacks, not speed or encryption [OK]

Common Mistakes:

• Thinking Outputs delete resources
• Believing Outputs speed up stack creation
• Confusing Outputs with encryption

2. Which syntax correctly exports an output value named MyBucketName for cross-stack use in CloudFormation?

easy

A. "Outputs": { "BucketName": { "Value": "MyBucket", "Export": "MyBucketName" } }

B. "Outputs": { "BucketName": { "Value": { "Ref": "MyBucket" }, "ExportName": "MyBucketName" } }

C. "Outputs": { "BucketName": { "Value": { "Ref": "MyBucket" }, "Export": { "Name": "MyBucketName" } } }

D. "Outputs": { "BucketName": { "Value": { "GetAtt": ["MyBucket", "Name"] }, "Export": { "Name": "MyBucketName" } } }

Solution

1. Step 1: Check correct Export syntax

   The Export field must be an object with a Name key inside Outputs.

2. Step 2: Validate Ref usage and Export name

   "Outputs": { "BucketName": { "Value": { "Ref": "MyBucket" }, "Export": { "Name": "MyBucketName" } } } uses correct Ref and Export with Name key, matching CloudFormation syntax.

3. Final Answer:

   "Outputs": { "BucketName": { "Value": { "Ref": "MyBucket" }, "Export": { "Name": "MyBucketName" } } } -> Option C

4. Quick Check:

   Export uses Export: { Name: "..." } = A [OK]

Hint: Export must be an object with Name key, not a string [OK]

Common Mistakes:

• Using ExportName instead of Export with Name
• Setting Export as a string instead of object
• Incorrect Value reference syntax

3. Given two stacks, StackA exports an output named VpcId. StackB imports it using Fn::ImportValue. What will happen if StackA's export name changes but StackB is not updated?

medium

A. StackB will ignore the import and deploy without errors

B. StackB will automatically update to the new export name

C. StackB will use the old value cached locally

D. StackB deployment will fail because the import value no longer exists

Solution

1. Step 1: Understand ImportValue dependency

   StackB depends on StackA's export name to import the value correctly.

2. Step 2: Effect of changing export name

   If StackA changes the export name, StackB's import reference breaks and causes deployment failure.

3. Final Answer:

   StackB deployment will fail because the import value no longer exists -> Option D

4. Quick Check:

   ImportValue depends on exact export name = D [OK]

Hint: ImportValue needs exact export name; changes break import [OK]

Common Mistakes:

• Assuming imports auto-update with export name changes
• Believing imports cache old values
• Thinking imports are optional and ignored if missing

4. You have this output in StackA:

{
  "Outputs": {
    "SubnetId": {
      "Value": { "Ref": "Subnet" },
      "Export": { "Name": "SubnetId" }
    }
  }
}

When deploying StackB that imports SubnetId, you get an error about duplicate export names. What is the likely cause?

medium

A. StackB is missing the ImportValue function

B. Another stack already exports the name "SubnetId", causing a conflict

C. The export name "SubnetId" is invalid and not allowed

D. The Ref function is used incorrectly in the output

Solution

1. Step 1: Understand export name uniqueness

   Export names must be unique across all stacks in the same region and account.

2. Step 2: Identify cause of duplicate export error

   The error means another stack already uses "SubnetId" as an export name, causing conflict.

3. Final Answer:

   Another stack already exports the name "SubnetId", causing a conflict -> Option B

4. Quick Check:

   Export names must be unique = C [OK]

Hint: Export names must be unique across stacks to avoid conflicts [OK]

Common Mistakes:

• Thinking export names can be reused in different stacks
• Assuming ImportValue missing causes export conflict
• Believing Ref usage causes export name errors

5. You want to share a VPC ID from StackA to StackB using outputs and imports. StackA exports the VPC ID as VpcIdExport. StackB imports it with Fn::ImportValue: VpcIdExport. Later, you need to update StackA to create a new VPC and export its ID with the same name. What is the best practice to avoid deployment failures in StackB?

hard

A. Change the export name in StackA and update StackB to import the new name

B. Delete StackB before updating StackA, then redeploy StackB after update

C. Keep the export name the same and update StackB without changes

D. Remove the export from StackA and hardcode the VPC ID in StackB

Solution

1. Step 1: Recognize export name immutability

   Export names cannot be changed or deleted without affecting dependent stacks.

2. Step 2: Plan safe update

   To update the VPC and export a new ID, use a new export name and update StackB to import that new name.

3. Step 3: Avoid breaking dependencies

   This avoids deployment failures and keeps stacks consistent.

4. Final Answer:

   Change the export name in StackA and update StackB to import the new name -> Option A

5. Quick Check:

   Update export name and import to avoid conflicts = B [OK]

Hint: Change export name and update imports to avoid breaking stacks [OK]

Common Mistakes:

• Deleting dependent stacks before update
• Keeping export name same causing conflicts
• Hardcoding values instead of using imports