0
votes

I'm just starting my serverless/cloudformation/AWS SAM journey. I've created a stack that has a resource of type AWS::CloudFormation::Stack, and I've separated some of my resources into that child stack.

When I do sam build and then sam deploy, I get the following error:

Embedded stack arn:aws:cloudformation:us-
west-2:111111111111:stack/ParentStack-
ChildStack-1QK94LXRA71CS/f9885e30-631c-11eb-
bfd8-021cb123b7ed was not successfully created: The
following resource(s) failed to create: [DynamoDBTable]. 
-
The following resource(s) failed to create:
[ChildStack].

Of course, what I really want to know is which resource in the nested stack failed to create, and why. When I copy/paste the resources from the child stack into the parent .yaml file and rebuild/redeploy, I see:

 One or more parameter values were invalid: Some index key
 attributes are not defined in AttributeDefinitions. Keys:
 [userID], AttributeDefinitions: [userId] (Service:
 AmazonDynamoDBv2; Status Code: 400; Error Code:
 ValidationException; Request ID:
 SMJDHUT0CQKM8IBQJVMAIJM4RRVV4KQNSO5AEMVJF66Q9ASUAAJG;    
 Proxy: null)

This is what I want to see in the output when I build the parent stack: the errors that caused the child stack to fail.

This has led me to use a rather tortuous workflow: build the resources in the main stack, then separate them to an independent stack when they build properly. There's got to be a better way, and I'm sure the community knows something here that I don't.

How do y'all debug child stacks when you're on the CloudFormation train?

1

1 Answers

0
votes

This is normal behaviour you have to take help from the AWS Console or use AWSW CLI in this case.

Deploy error reporting is not showing the reason of failure when using nested stacks. #5974

Feature Requests for nested stacks

Why doesn't the error tell me what's wrong?:

CloudFormation passes the creation and updating of a resource to the service responsible for those resources. When a resource fails to create/update, the resource's backing service returns a reason to the stack, which gets logged as the Status Reason within the events. Child Stack is a CloudFormation::Stack resource, so it's being created by CloudFormation. As far as CloudFormation knows, it didn't run into an error trying to actually do anything. Everything it did relate to the CloudFormation side of things was fine; the blame is with the Service resource, which failed to create it. Therefore, Child Stack tells Parent-Stack that it only failed because Service failed to create, not because of a problem on the CloudFormation Service side of things.

you can read more about it here CloudFormation troubleshooting