Creation and Scheduled deletion of AWS Cloud Formation Stack - amazon-web-services

I am trying to setup an environment on AWS by launching a stack via AWS Cloud Formation template. The stack would be created and then be scheduled for deletion automatically based on the TTL parameter in the template. There seems to be a problem only when the instance is getting launched, it errors out that "Failed to receive 1 resource signal(s) within the specified duration"
If anyone could point out what I am doing wrong in the template, it would be great.
Here is the link for the template in YAML: https://s3.ca-central-1.amazonaws.com/rkbucket028/aws-openshit-cf-template_new.yml
I have already followed this article but there seems to be something wrong with it as well:-
https://aws.amazon.com/blogs/devops/scheduling-automatic-deletion-of-application-environments/#

CloudFormation rolls back if any of the resources have failed to be created (ie didnt responed in the predetermined duration). If you believe that it is only the process that is taking longer and not a genuine failure, you can either incorporate the wait condition, or better use resource creation policy time and count.
Source:
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-creationpolicy.html
PS: Your template url is not accessible. Check your bucket and file permissions on S3 bucket and share the public url

Related

AWS: Preemptively configure LambdaEdge log groups using Terraform

If given the correct permissions, Lambda functions will automatically create CloudWatch log groups to hold log output from the Lambda. Same for LambdaEdge functions with the addition that the log groups are created in each region in which the LambdaEdge function has run and the name of the log group includes the name of the region. The problem is that the retention time is set to forever and there is no way to change that unless you wait for the log group to be created and then change the retention config after the fact.
To address this, I would like to create those log groups preemptively in Terraform. The problem is that the region would need to be set in the provider meta argument or passed in the providers argument to a module. I had originally thought that I could get the set of all AWS regions using the aws_regions data source and then dynamically create a provider for each region. However, there is currently no way to dynamically generate providers (see https://github.com/hashicorp/terraform/issues/24476).
Has anyone solved this or a similar problem in some other way? Yes, I could create a script using the AWS CLI to do this, but I'd really like to keep everything in Terraform. Using Terragrunt is also an option, but I wanted to see if there were any solutions using pure Terraform before I go that route.

AWS CloudFormation stack stuck in the state UPDATE_ROLLBACK_IN_PROGRESS

I wanted to update my stack. The stack failed with error Function not found: arn:aws:lambda....
And stack in status UPDATE_ROLLBACK_IN_PROGRESS more than 5 hours. How do I stop this process?
If you deleted the function outside of CloudFormation, then you can manually create a new function of the same name. This sometimes helps.
You can also wait till the rollback timeouts. And it usually does after a while, but the time varies.
Another reason why it gets stuck in this state could be due to nested stacks:
Nested Stacks are Stuck in UPDATE_COMPLETE_CLEANUP_IN_PROGRESS, UPDATE_ROLLBACK_COMPLETE_CLEANUP_IN_PROGRESS, or UPDATE_ROLLBACK_IN_PROGRESS
In this case a recommended option is indeed to contact support:
To fix the stack, contact AWS customer support.
Recent AWS blog post also describes the issue and possible solutions:
Why is my AWS CloudFormation stack stuck in the state CREATE_IN_PROGRESS, UPDATE_IN_PROGRESS, UPDATE_ROLLBACK_IN_PROGRESS, or DELETE_IN_PROGRESS?
Regarding the time to wait, the timeout varies:
In most situations, you must wait for your AWS CloudFormation stack to time out. The timeout length varies, and is based on the individual resource stabilization requirements that AWS CloudFormation waits for to reach the desired state.
In our case, we have mistakenly passed wrong image name to cloudformation template. After realising the mistake, we tried to stop the stack update, which made the stack stuck for forever in UPDATE_ROLLBACK_IN_PROGRESS status. SO during ECS service creation it got stuck.
Solution:
in Stack event check in which step is in progress. (our case ECS service update)
Go to ECS service.
Click on Update service.
Choose older task definitions.
And Update.
Your Task definition is reset to previous version. And roll back will complete successfully.

CloudFormation - Manual deletion of resource in a stack and update

Using template.yaml, Cloudformation service created stack having three s3 buckets.
I deleted one s3 resource manually.
Say the stack name is stack1
On running the same template.yaml again(unchanged), with stack name stack1, following this update_procedure
does CloudFormation service update the same stack? with that
missing bucket....it is not updating with missing s3 bucket in my case
You can't create two stacks with the same name in the same region. If you were to do this in another region it would create the bucket you deleted but fail to create the other buckets, all assuming you named your buckets in the template. If the buckets we not named (so CloudFormation created the names for you) then it will create all three buckets, but the names will not be the same as they were before.
CloudFormation will not update a stack when you tell it to create a stack.
EDIT:
Based on your updated question, it seems you are asking if the bucket will be recreated. The answer to that is no. CloudFormation sees that nothing has changed in what you've asked for, so no action is taken. As a matter of fact you should get an error when updating, saying something along the lines of "no changes".
There are exceptions to the above "no", but for your purposes here I think it's sufficient.
The easiest solution for you is to remove the S3 bucket, that you deleted, from the template, run the update (it will "delete" it even though it's already gone) and then add it back to the template and update it again. That will cause it to be created again.
If you are worried about this sort of thing happening in the future consider using Drift Detection with CloudFormation.

AWS: How to invoke a lambda when any resource is created

I am trying to more effectively manage the resources we create in our AWS accounts and I would like to start by attaching a lambda or many lambdas whenever a resource is created. At a minimum, I need to tag the resources because we simply can't count on people to do it at all, much less correctly.
For example: I can get an event anytime an object is deleted in S3 but that isn't what I want; I want to know when a bucket it created; either through the console of a CFT or the CLI
The closest thing I can see is CloudFormation events man be monitored. We do a lot of stack creation of resources but not always so this isn't good enough. And, in any event, I would need to know all the resources that were created with that stack which the documentation doesn't make clear if I could even get
Can this be done? If so, how?
CloudTrail tracks user activity and API usage and generates CloudTrail Trails. Trails have Data Events.
CloudTrail Data Events can be passed directly to a Lambda function for processing (and/or S3 and/or CloudWatch).
In my own case we store CloudTrail Events in a S3 bucket but also pass them to a Lambda function that applies a billing tag to all new resources created in the account.
GorillaStack Autotag might be a good starting point as a reference for the function.

aws LAMP_Single_Instance stack create fails

Trying to create a simple LAMP stack on aws using AWS CloudFormation Sample Template LAMP_Single_Instance template.
On creating the stack, I get the following event - "Internal Failure. Rollback requested by user."
No clues provided on why this failed.
You can inspect the CloudFormation events tab on the management console (or with describe-stack-events on the CLI) and check what went wrong. In this single instance stack, probably CloudFormation was unable to create the instance, check the parameter values. For example, the key pair name should not have the ".pem" extension of the file, if that was supplied.