10 Solutions to Common CloudFormation Errors

By Cami La Porte, Software Engineer — TensorIoT

You know how this horror story starts. It’s late in the evening and you’ve completed development on a robust system using AWS Resources and are ready to upload your CloudFormation stack. You’ve heavily tested your system and passed with flying colors, so you confidently take a sip of your coffee and click “Upload”. However, before you put your coffee cup down, you notice a glaring error at the top of your screen that brings your smooth evening to a grinding stop.

If this sounds familiar, you’re not alone. I’ve personally encountered many CloudFormation errors that have tripped up the final stages of development. While CloudFormation is a simple and powerful tool, for those less experienced (or sleep-deprived), it can be laborious trying to troubleshoot the errors. Which is why I decided to write this blog post: “10 Solutions to Common CloudFormation Errors’’.

In this blog post you will find 10 common problems that could be causing your CloudFormation to error out as well as the solutions to help you avoid the dreaded “ROLLBACK_INITIATED”.

10. Syntax & Formatting

One of the most common errors encountered while using CloudFormation is a Syntax or Formatting Error. Your options for utilizing either JSON or YAML templates can lead to these minor hiccups that are easily encountered when it’s late in the evening. These issues could be as simple as missing an indent or bracket and are usually pointed out when uploading the CloudFormation.

The solution for this fix is simple, review the line in error and correct the syntax/format. At times it could get a bit hard to see after staring at the screen for hours on end, but the AWS console does a great job of letting you know if there is a minor error such as this, it will even give you a line number which is extremely useful in pinpointing that specific error. You may need to do a bit of problem solving if that line does not contain an actual error, as it could be one above it. Another option is to utilize features within your editor, such as VSCode, which will underline issues it detects in your code. Either way, this is one of the easiest problems to solve and I hope that you’re blessed with these being the only problems you encounter.

9. Region-Specific Resources

In some situations, you may be required to stand up your system in a different region than what you developed in. This may result in an error because the region you’re creating the system in does not have one or more of the resources you’ve specified in the CloudFormation Template.

This problem can only really be solved with proper planning and having researched this during the architecture phase in development. Depending on the resource, you may be able to develop around it which, unfortunately, could add more time and potentially more costs. Your best bet would be to find another suitable region that supported these resources which still fit your or the client’s needs.

8. Missing Required Properties

You’ve scoured the CloudFormation Template Reference Documentation and built your JSON or YAML file based on their examples. When you finally uploaded your stack, you ran into a “missing required property” error. These errors often occur when a resource has several properties, making it a challenge to remember which properties are required and which are not. In multiple instances, I found that I created a resource via AWS Console and didn’t even realize a property was required until creating the CloudFormation!

Double checking the CloudFormation Template Reference Documentation is how to best fix this issue. When you scroll down past the initial JSON/YAML example code, you’ll notice a breakdown of the properties and a description of each one. There will also be a field titled “Required” which will state a YES or NO value. Most of the resources only need this field to be adjusted, but in some cases where it states that it’s “Conditional” you may have to dig a bit deeper into the research to see how to properly set up that resource property.

7. Environmental Variables

When creating a CloudFormation that includes Lambda Function resources, you should check whether those Lambdas have Environmental Variables. If they do and you don’t specify them in your CloudFormation template, you’ll most likely run into an error with your CloudFormation stack that can stop you from proceeding further.

If you have read the AWS CloudFormation Template Reference Documentation, under the Lambda Functions section, there is an Environment section that shows us how to structure the code block within your template. During your development, if an environmental variable is needed, it would be best to incorporate that immediately into your stack as a parameter than can be changed later on if necessary.

6. Not Having Sufficient Permissions

Setting up your resources through a simple YAML file is so easy that you may forget simple permission requirements. Depending on the architecture of your project, your resources might need to interact with each other, which means they require sufficient permissions to do so. For example, if you have a Lambda Function that is set to write entries into a database, but that Lambda does not have permission to do so, you will encounter an error. This can easily be fixed by adding the necessary permissions to the role for that resource. When troubleshooting whether or not you have sufficient privileges, I like to start with admin and work my way down to the absolute necessary permissions. That way I wont be blocked during development and can avoid adding unnecessary privileges.

5. Policy Errors

Similar to permission issues, you may have the appropriate permissions for your resources, but instead the policy is not correctly set. For example, you may have set up an SQS resource within your CloudFormation file, but failed to specify the SQS Policy Condition, which is a requirement when setting up SQS. Fix this error simply by ensuring you have the proper policies attached to the resource. One exercise that works for me when I’m stuck at what policy I need to add, is I create a resource through the console directly and attach it to the existing architecture. Once I get that properly configured, I dissect that resource and copy the policy values over manually.

4. Issues with “Fn:GetAtt”

One of the greatest features of using CloudFormation is the ability to invoke “get attribute,” which eliminates the need to repeatedly write parameters in your code. However, with the more complicated resource setups, you might need multiple arguments in order to complete the resource deployment. An example of this is when calling logical ID’s you need to follow the expected template <LogicalID>.<Attribute> and without the Attribute, the CloudFormation Stack will fail. Relying on the AWS documentation can only get you so far, as we often create more complex applications than the example allows. I find browsing other examples from public sources such as bitbucket or trolling stack overflow is usually helpful, even if it’s seeing how another developer invoked the resource.

3. DependsOn

As you begin to develop more complex architectures, you’ll encounter a situation where you resources need to be created in a specific order within your stack. In order to get around this, you’re able to use the “DependsOn” tag within your resource code block and specify the LogicalID of the resource that needs to be successfully created prior to starting the tagged resource. This is extremely helpful when you have intricate resource dependencies, such as running custom resources prior to setting up portions of the architecture. A diagram of your application’s architecture can help visualize these dependencies early on and will help you determine which resource has dependencies.

2. Resource Already Exists/Too Many

You might run into a situation where your resource setup is perfect, but you are unable to create your resource due to one already existing. This can happen when your naming convention is not unique enough and CloudFormation believes you’re trying to duplicate a resource. Another related issue arises if you hit the cap for that particular resource on your account. You can make yourself aware of these limitations by referencing the proper documentation for the service. Another solution, which is more process-focused, is to determine a suitable naming convention for your resources which will help you easily name services as you develop. (Ex: ProjectName_Resource_Description)

1. Custom Resource Needs to Return

When dealing with custom resources, you will need to ensure that the custom resource is returning to the next resource to avoid any deployment issues. This error is fairly tricky to troubleshoot because the error is dependent upon the custom resource that you’re setting up. Build an Output within your template for the custom resource data passthrough in ordg er to successfully set up the custom resource . You can find documentation on this here.

Honorable Mention: User Error

Finally, as an honorable mention, there’s a possibility that plain old “user error” is causing your CloudFormation stacks to fail. Humans aren’t perfect and we developers tend to get so wound up in tracking down solutions to our problems that we often overlook the most simple issues. Here’s quick list of common human errors:

• Not reading Error Messages — Oftentimes we skim through an error message and pick up only the key words which sends us quickly opening up another tab and barreling down the rabbit hole. Make sure you’re taking the time to read the error message thoroughly in order to fully understand that problem.
• Naming Error — There are countless times that my tired eyes overlooked names that I’ve seen so often in my template, where I realized that I referenced the incorrect resource or changed the name in one place but forgot to do it in another. Check and make sure the names match up to the resource you’re trying to troubleshoot.
• Indent/Spacing/Extra White Space — With how many IDE’s there are out there, there’s a possibility that you’ve got an error that can’t easily be seen within the characters of your code. An incorrect indent or hidden spaces can potentially throw an error and won’t always be caught in the first pass.
• Typo — Something as simple as a typo that’s dumping your cloudformation stack into the trash. If you’ve been at it for a while, consider taking a break or a quick walk and coming back to it with fresh eyes. You may catch a loose “.” or a stray letter by doing so.

CloudFormation is an extremely powerful service and makes our lives as AWS developers infinitely easier. While it can be frustrating having stop-and-go scenarios during deployment, taking the time to review your code, documentation, and even this article will help you get unstuck and back to the development process. Eventually, you’ll figure out the issue and be blessed with the beauty of these green letters: CREATION_COMPLETE.

To watch our webinar with in depth explanations from Cami, you can join here- https://my.demio.com/ref/4FvAV1UrvZibk3rb