I spent way more time than expected getting a few different resources imported to existing CloudFormation stacks. It seems like it should be easy, but there were a couple issues I ran into along the way that I hadn’t seen documented anywhere.
|Error||The following resource types are not supported for resource import|
|Solution||Remove unused conditional resources from template|
I needed to import an existing EC2 instance into a stack. The import failed, complaining that several resource types weren’t able to be imported. The only resource in the template that didn’t already exist was the instance itself, so why the errors?
After some trial and error, I found that it was due to using conditions. There were several resources defined in the stack to be conditionally created based on the parameters - things like creating either an application load balancer or a network load balancer. It appears that on import, CloudFormation doesn’t check the conditions and was failing because some of those conditional resources weren’t of an importable type.
After manually removing all the unused conditional resources, the stack imported successfully.
|Error||Template body in template URL of resource [ResourceName] doesn’t match with the actual template|
|Solution||Remove dynamic references from the template to import|
I had a stack that needed imported into the root stack. When trying to do this, CloudFormation failed because the contents of the template given in the root stack didn’t match the contents of the template currently in use. But… it did! I downloaded both, and confirmed they were exactly the same!
The issue was that the template used dynamic references for some values. It seems like CloudFormation was comparing the new template, with unresolved references, to the current template with references resolved.
To work around this, I manually updated the template to use static values in place of the dynamic references.