CloudFormation stack attack

I’m studying for the AWS Certified DevOps Engineer exam and CloudFormation is a big topic.

Understanding more complex ways of configuring interrelated stacks is mandatory for this exam.

Since I like to learn by doing, I started wondering if I could create a set of minimal CloudFormation templates that could demonstrate all the ways stacks can be interconnected.

This post is the result of that effort.

Architectural Heuristics: Requirements, Constraints, Desires, Applicability, Limitations and Alternatives

I’ve found enumerating architectural heuristics for patterns to be very helpful as it helps in:

1. We track architecture born from “design by architecture” efforts.

2. My own memories of the value of patterns when looking at what I’ve done in the past for new solutions.

3. Others will quickly see all the value points of the solution provided and help decide whether to invest in learning how it works.

4. Distinguishing between purpose-designed and incidental elements makes it easier to customize and refactor your code.

I especially like the model used Constraints, Requirements, Desires, Serendipity, Applicability, Limitations and Alternatives Because it helps show the optimization of the results without writing everything as “requirements”. This model is also more open to new architectural elements that arise from the construction work itself.

• Requirement: (satisfied) Create a practical reference pattern.
• Requirement: (satisfied) Demonstrate all the major ones native How to interconnect CloudFormation templates/stack.
  • Constraints: (satisfied) Use the simplest stack possible. (Exception: Reusing the ASG stack is not as simple for this purpose, but it makes it easier to demonstrate and debug the results.)
  • Constraints: (satisfied) With minimum number of stacks.
• Request: (satisfied) while providing configuration flexibility (e.g. overrides)
• Request: (satisfied) Creates a stack that can work standalone and can be associated with each other without modification (other than specifying parameters).

Option 1: Stack works standalone

I started with the previously published CloudFormationRebootRequiredPatchinginASG.yaml. This can be deployed standalone by entering the parameters and deploying. CloudFormationELB.yaml also works this way.

Create CloudFormationRebootRequiredPatching in ASG.yaml in the CloudFormation console

Option 2: Add ELB stack and use manual parameters for ASG stack

You can deploy CloudFormationELB.yaml and pass the resulting ELB name to CloudFormationRebootRequiredPatchinginASG.yaml through the ELBName parameter. This integrates her two stacks and can be done manually or automated by calling the AWS CLI.

Create CloudFormationELB.yaml in the CloudFormation console

Option 3: Add an ELB stack and use Export => Import to ASG stack.

The stack name in CloudFormationELB.yaml can be specified as the ParentStackName parameter in CloudFormationRebootRequiredPatchinginASG.yaml, and the ASG stack assumes that the ELBName is exported as “ParentStackName-ELBName”. Consistent naming with ELBName on parameters, exports, and imports helps maintain data passing. Less confusing method.

If the ELB stack is creating only one resource, the flexibility of passing the stack name to the ASG stack is less obvious. But consider if the ELB stack had pre-created a large amount of his AWS resources that would be utilized by his ASG stack. Using a single parameter across stacks allows you to pass many references.

The parameters are optional (as shown in the standalone deployment) or you can specify both. If both are specified, the ELBName parameter takes precedence over her ParentStackName-ELBName. The vision is that if a parent stack creates a set of resources, you should have the flexibility to override just one of them if needed. This parameter structure and supporting conditions show how to obtain the parent stack and how to override certain parent stack parameters.

Option 4: Nested stacks

The template CloudFormationUsingNestedStacks.yaml links CloudFormationELB.yaml and CloudFormationRebootRequiredPatchinginASG.yaml as a nested stack and automatically handles data passed between them through the ASG stack’s ParentStackName parameter.

Create a CloudFormation using NestedStacks.yaml in the CloudFormation console

summary

In my eyes, most of the design heuristics are met, but if you know of additional native ways to interlink cloud formation stacks, I’d love to hear from you.

Code for this post

The repositories below are where this code is updated with enhancements and bug fixes.

CloudFormationELB.yaml => [[Create Now]](

CloudFormationRebootRequiredPatchinginASG.yaml => **[Create Now]**

CloudFormationUsingNestedStacks.yaml => **[Create Now]**