A Review of AWS CloudFormation Cross-Stack Reference

In addition to the announced AWS CloudFormation YAML support, AWS also announced cross-stack references for CloudFormation. (For Flux7 commentary on YAML support, please see our blog post earlier this week here.) As our AWS experts work daily with CloudFormation, we were very interested in this news and couldn’t wait to roll up our sleeves and take a look for ourselves.


As you likely already know, CloudFormation is instrumental because it helps you model and set up your AWS resources through templates that describe all the resources you want to use. And, CloudFormation takes care of provisioning and configuring those resources so you don’t have to. Now with the ability to cross-stack reference, users will be able to easily do common things like share IAM roles, VPC information and security groups.

This allows a CloudFormation template to reference values from an existing CloudFormation stack. This is useful in many scenarios when a new CloudFormation stack is expected to integrate with an existing one. For example, let’s suppose we are developing the CFT to deploy a simple 2-tier webapp like WordPress. It’s best practice to create the networking resources, VPC, subnets, routes, and NACLs as a separate CF stack than the application stack which has Amazon Elastic Load Balancers – ELBs-  EC2 instances, and Amazon RDS. First, the next stack is deployed and the VPC created. Next, When the application stack is to be created, the template requires that we provide the VPC id and subnet ids of the existing network stack as inputs. This is required for CF to create the ELB, EC2 instances, and RDS in the correct VPC and subnets. Cross-stack references makes this scenario easy where the app stack can directly reference outputs of the network stack and get the VPC ids and subnets by just knowing the name of the network stack.

Prior to support for cross-stack references — a reference from one stack to resources in another stack — users would have to manually look up the resources in one stack and use input parameters to include those resources in another stack. Or, users could use Lambda in combination with CloudFormation’s custom resources to create a function that would automatically retrieve the input parameters for you. In either case, the process was more laborious than it needed to be. Yet, illustrates well why we are happy to see AWS add even greater automation to continually improve ease of management and operability.

As we dive in, we see that we can easily share these items (like the aforementioned IAM roles, security groups and VPC information) by adding an “Export” declaration to a normal CloudFormation stack output and use a new intrinsic function to access them. That new function, Fn::ImportValue, does have a few restrictions that are important to note if you are setting out on your first cross-stack reference with it. Namely, the export names must be unique within an account and region; and the function will not allow you to create references across regions. In addition, AWS smartly will not allow you to delete a stack that is being referenced by another stack and your outputs cannot be changed or removed while they are being referenced by a stack.

We are especially excited about cross-stack reference in CloudFormation as it relates to Service Catalog. We are, for example, currently working on a project for a major hospitality organization using both Service Catalog and CloudFormation. As you may know, Service Catalog essentially provides automated infrastructure provisioning through easy buttons. Ops teams create these buttons and make them available to internal customers such as developers, engineers, or QA to easily request, receive and provision pre-approved infrastructure.

 

For more analysis of Service Catalog, click here.

And, this is where the real magic happens. In ServiceCatalog, the products we distribute to end users are composed of catalogs created by importing CloudFormation templates. And, as we discussed earlier, these templates define the resources, configurations and parameters that the product needs to work. By being able to easily and in an automated fashion refer to the parameters needed, our work suddenly becomes not only more efficient but less prone to risk created by manual errors.

 

Read more about AWS CloudFormation by clicking the button below

As AWS DevOps consultants with a deep belief in the power of automation for agility, innovation and ultimately business success, we are very excited about the ability to now reference across stacks in CloudFormation without having to do it manually or going to the trouble of creating custom CloudFormation resources.

If you would like to learn more about how AWS, DevOps and greater automation can benefit your organization, reach out to us today. And, to make sure you don’t miss out on our future analysis, click on the button below to receive our blog in your inbox.