Can you rename a resource in a CloudFormation template?
Let's say I've created a stack template that creates a single lambda function.
GetTheFunnyPhraseText:
Type: AWS::Serverless::Function
Properties:
CodeUri: ../Lambda/
Handler: GetFunnyPhrase.handler
FunctionName: GetFunnyPhrase
Role: !GetAtt [ ExecuteFunctionGetFunnyPhrase, Arn ]
For whatever reason, I want to change the resource name GetTheFunnyPhraseText to GetFunnyPhrase. Is there a mechanism to change the name?
A couple things I tried...
Changing the resource name in the template. It looks like this acts like a delete on GetTheFunnyPhraseText and create of GetFunnyPhrase. Problem here is the resource creation happens before the resource deletion causing the action to fail because the Lambda function exists.
Create two drafts of the template. Draft-1: Change the function name for the existing resource(s). Draft-2: Delete the old resource (omit their definition from the template) and add the new resource. Execute the draft templates in sequence: 1st then 2nd. This works. It's just gross.
For folks that suggest not naming the function, understood; put a pin in that piece of feedback for the moment.
Now that CloudFormation import is available it's technically possible to do this, although it's tedious.
Here's what you'd need to do:
Update the definition for GetTheFunnyPhraseText to add DeletionPolicy: "Retain", upload to CloudFormation
Remove GetTheFunnyPhraseText entirely from your template. Upload to CloudFormation. This will not actually delete the underlying Lambda because of the previously added DeletionPolicy
Revert your template back to the previous state in Step #1 (add GetTheFunnyPhraseText back) and change the logical name to GetFunnyPhrase
Start the "Stack Actions" > "Import resources into stack" workflow.
Upload your reverted template (with the changed logical name, still including the DeletionPolicy)
The import process will notice the new GetFunnyPhrase logical name and ask you what actual FunctionName should be mapped to that name. Provide the existing GetFunnyPhrase Lambda name and complete the import.
Finally, you can re-upload your template and remove the DeletionPolicy
A tedious process for sure, but technically possible if you really don't want to delete the existing resource.
No! Renaming a resource's logical name is not possible in Cloud Formation.
As you tested as well, CloudFormation sees it as the removal of the old resource and creation of the new one. This is so because the logical resource IDs are bound to the physical IDs of the resources by CloudFormation after creation. But for CloudFormation template language, it only recognizes the logical ID while parsing the template so any changes to that would mean the resource associated to it is going to be changed.
In some resource types though you can set the physical IDs yourself by using certain name properties which are resource-specific, for example a resource AWS::RDS::DBInstance may have a property DBInstanceIdentifier which will be the physical name of the db instance itself.
Related
As in the title of my post, it is possible? I don't see any options.
Also, the job details include advanced properties that include the name of my script, for example, job-name.py When the python script is renamed, will the job name also change? I'm afraid I might mess something up after the change.
Thanks in advance
From CloudFormation docs (https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-glue-job.html) is stated that changing the name parameter would replace the job so I would say no.
Expanding on the answer from #zoran2709:
From CloudFormation docs (https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-glue-job.html) is stated that changing the name parameter would replace the job so I would say no.
In the console, it doesn't look like you can. If you defined this job in CloudFormation, you can update the name of the job, but it will replace the resource with a new one. I would recommend setting the UpdateReplacePolicy on the resource to Retain just to be safe. Checkout the docs here:
If you update a resource property that requires that the resource be replaced, CloudFormation recreates the resource during the update. Recreating the resource generates a new physical ID. CloudFormation creates the replacement resource first, and then changes references from other dependent resources to point to the replacement resource. By default, CloudFormation then deletes the old resource. Using the UpdateReplacePolicy, you can specify that CloudFormation retain or, in some cases, create a snapshot of the old resource.
Beginning with a new stack I get the error message as in the title.
I am using SAM, and I am confused, why it wants to update the macro.
I thought, this macro is provided by aws and I wonder why it is requesting to modify it.
My template spins up a lambda, a database and a REST api, but does even try to touch existing macros.
My template did contain the TableName tag for a DynamoDb.
As I am aware, named tables cannot be updated, if resource replacement required. I was not trying to do updates on that resource though.
The table existed before I cloudformed that new stack though.
Seems it's common practice to make use of count on a resource to conditionally create it in Terraform using a ternary statement.
I'd like to conditionally update an AWS Route 53 entry based on a push_to_prod variable. Meaning I don't want to delete the resource if I'm not pushing to production, I only want to update it, or leave the CNAME value as it is.
Has anyone done something like this before in Terraform?
Currently as it stands interpolation syntax isn't supported in lifecycle tags. You can read more here. Which will make this harder because you could use the "Prevent Destroy". However, without more specifics I am going to take my best guess on how to get your there.
I would use the allow_overwrite property on the Route53 record and set that based on your flag. That way if you are pushing to prod you can set it it false. Which should trigger creating a new one. I haven't tested that.
Also note that if you don't make any changes to the Route53 resource it should trigger any changes in Terraform to be applied. So updating any part of the record will trigger the deployment.
You may want to combine this with some lifecycle events, but I don't have enough time to dig into that specific resource and how it happens.
Two examples I can think of are:
type = "${var.push_to_prod == "true" ? "CNAME" : var.other_value}" - this will have a fixed other_value, there is no way to have terraform "ignore" the resource once it's being managed by terraform.
or
type = "${var.aws_route53_record_type}" and you can have dev.tfvars and prod.tfvars, with aws_route53_record_type defined as whatever you want for dev and CNAME for prod.
The thing is with what you're trying to do, "I only want to update it, or leave the CNAME value as it is.", that's not how terraform works. Terraform either manages the resource for you or it doesn't. If it's managing it, it'll update the resource based on the config you've defined in your .tf file. If it's not managing the resource it won't modify it. It sounds like what you're really after is the second solution where you pass in two different configs from your .tfvars file into your .tf file and based off the different configs, different resources are created. You can couple this with count to determine if a resource should be created or not.
When using CloudFormation templates, I find the "Custom Resource" feature, with its Lambda backing function implementation, very useful to handle all kinds of tasks that CloudFormation does not provide good support for.
Usually, I use custom resources to setup things during stack creation (such as looking up AMI names) or clean up things during deletion (such as removing objects from S3 or Route53 that would block deletion) - and this works great.
But when I try to actually use a "custom resource" to manage an actual custom resource, that has to be created during stack creation, deleted during stack deletion, and - this is where the problem lies - sometimes updated with new values during a stack update, the CloudFormation integration behaves unexpectedly and causes the custom resource to fail.
The problem seems to be that during a stack update where one of the custom resource properties has changed, during the stack's UPDATE_IN_PROGRESS stage, CloudFormation sends an update event to the backing Lambda function, with all values set correctly and a copy of the old values sent as well. But after the update completes, CloudFormation starts the UPDATE_COMPLETE_CLEANUP_IN_PROGRESS stage and sends the backing Lambda function a delete event (RequestType set to Delete).
When that happens, the backing lambda function assumes the stack is being deleted and removes the custom resource. The result is that after an update the custom resource is gone.
I've looked at the request data in the logs, and the "cleanup delete" looks identical to a real "delete" event:
Cleanup Delete:
{
RequestType: 'Delete',
ServiceToken: 'arn:aws:lambda:us-east-2:1234567890:function:stackname-resname-J0LWT56QSPIA',
ResponseURL: 'https://cloudformation-custom-resource-response-useast2.s3.us-east-2.amazonaws.com/arn%3Aaws%3Acloudformation%3Aus-east-2%3A1234567890%3Astack/stackname/3cc80cf0-5415-11e8-b6dc-503f3157b0d1%7Cresnmae%7C15521ba8-1a3c-4594-9ea9-18513efb6e8d?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20180511T140259Z&X-Amz-SignedHeaders=host&X-Amz-Expires=7199&X-Amz-Credential=AKISOMEAWSKEYID%2Fus-east-2%2Fs3%2Faws4_request&X-Amz-Signature=3abc68e1f8df46a711a2f6084debaf2a16bd0acf7f58837b9d02c805975df91b',
StackId: 'arn:aws:cloudformation:us-east-2:1234567890:stack/stackname/3cc80cf0-5415-11e8-b6dc-503f3157b0d1',
RequestId: '15521ba8-1a3c-4594-9ea9-18513efb6e8d',
LogicalResourceId: 'resname',
PhysicalResourceId: '2018/05/11/[$LATEST]28bad2681fb84c0bbf80990e1decbd97',
ResourceType: 'Custom::Resource',
ResourceProperties: {
ServiceToken: 'arn:aws:lambda:us-east-2:1234567890:function:stackname-resname-J0LWT56QSPIA',
VpcId: 'vpc-35512e5d',
SomeValue: '4'
}
}
Real Delete:
{
RequestType: 'Delete',
ServiceToken: 'arn:aws:lambda:us-east-2:1234567890:function:stackname-resname-J0LWT56QSPIA',
ResponseURL: 'https://cloudformation-custom-resource-response-useast2.s3.us-east-2.amazonaws.com/arn%3Aaws%3Acloudformation%3Aus-east-2%3A1234567890%3Astack/stackname/3cc80cf0-5415-11e8-b6dc-503f3157b0d1%7Cresname%7C6166ff92-009d-47ac-ac2f-c5be2c1a7ab2?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20180524T154453Z&X-Amz-SignedHeaders=host&X-Amz-Expires=7200&X-Amz-Credential=AKISOMEAWSKEYID%2F20180524%2Fus-east-2%2Fs3%2Faws4_request&X-Amz-Signature=29ca1d0dbdbe9246f7f82c1782726653b2aac8cd997714479ab5a080bab03cac',
StackId: 'arn:aws:cloudformation:us-east-2:123456780:stack/stackname/3cc80cf0-5415-11e8-b6dc-503f3157b0d1',
RequestId: '6166ff92-009d-47ac-ac2f-c5be2c1a7ab2',
LogicalResourceId: 'resname',
PhysicalResourceId: '2018/05/11/[$LATEST]c9494122976b4ef3a4102628fafbd1ec',
ResourceType: 'Custom::Resource',
ResourceProperties: {
ServiceToken: 'arn:aws:lambda:us-east-2:1234567890:function:stackname-resname-J0LWT56QSPIA',
VpcId: 'vpc-35512e5d',
SomeValue: '0'
}
}
The only interesting request field that I can see is the physical resource ID is different, but I don't know what to correlate that to, to detect if it is the real delete or not.
The problem seems to be the sample implementation of the sendResponse() function that is used to send the custom resource completion event back to CloudFormation. This method is responsible for setting the custom resource's physical resource ID. As far as I understand, this value represents the globally unique identifier of the "external resource" that is managed by the Lambda function backing the CloudFormation custom resource.
As can be seen in the CloudFormation's "Lambda-backed Custom Resource" sample code, as well as in the cfn-response NPM module's send() and the CloudFormation's built-in cfn-response module, this method has a default behavior for calculating the physical resource ID, if not provided as a 5th parameter, and it uses the CloudWatch Logs' log stream that is handling logging for the request being processed:
var responseBody = JSON.stringify({
...
PhysicalResourceId: context.logStreamName,
...
})
Because CloudFormation (or the AWS Lambda runtime?) occasionally changes the log stream to a new one, the physical resource ID generated by sendResponse() is changing unexpectedly from time to time, and confuses CloudFormation.
As I understand it, CloudFormation managed entities sometimes need to be replaced during an update (a good example is RDS::DBInstance that needs replacing for almost any change). CloudFormation policy is that if a resource needs replacing, the new resource is created during the "update stage" and the old resource is deleted during the "cleanup stage".
So using the default sendResponse() physical resource ID calculation, the process looks like this:
A stack is created.
A new log stream is created to handle the custom resource logging.
The backing Lambda function is called to create the resource and the default behavior set its resource ID to be the log stream ID.
Some time passes
The stack gets updated with new parameters for the custom resource.
A new log stream is created to handle the custom resource logging, with a new ID.
The backing Lambda function is called to update the resource and the default behavior set a new resource ID to the new log stream ID.
CloudFormation understands that a new resource was created to replace the old resource and according to the policy it should delete the old resource during the "cleanup stage".
CloudFormation reaches the "cleanup stage" and sends a delete request with the old physical resource ID.
The solution, at least in my case where I never "replace the external resource" is to fabricate a unique identifier for the managed resource, provide it as the 5th parameter to the send response routine, and then stick to it - keep sending the same physical resource ID received in the update request, in the update response. CloudFormation will then never send a delete request during the "cleanup stage".
My implemenation (in JavaScript) looks something like this:
var resID = event.PhysicalResourceId || uuid();
...
sendResponse(event, context, status, resData, resID);
Another alternative - which would probably only make sense if you actually need to replace the external resource and want to adhere to the CloudFormation model of removing the old resource during cleanup - is to use the actual external resource ID as the physical resource ID, and when receiving a delete request - to use the provided physical resource ID to delete the old external resource. That is what CloudFormation designers probably had in mind in the first place, but their default sample implementation causes a lot of confusion - probably because the sample implementation doesn't manage a real resource and has no update functionality. There is also zero documentation in CloudFormation to explain the design and reasoning.
It’s important to understand the custom resource life cycle, to prevent your data from being deleted.
A very interesting and important thing to know is that CloudFormation
compares the physical resource id you returned by your Lambda function
to the one you returned previously. If the IDs are different,
CloudFormation assumes the resource has been replaced with a new
resource. Then something interesting happens.
When the resource update logic completes successfully, a Delete
request is sent with the old physical resource id. If the stack update
fails and a rollback occurs, the new physical resource id is sent in
the Delete event.
You can read more here about custom resource life cycle and other best practices
How do we create Launch configurations in cloudformation with specific name.? I looked at the docs https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-launchconfig.html, there is no property that sets the name of the launch configuration that we create in template.
Is there any way?
You should not try to name the LaunchConfiguration yourself, as cloudformation need to setup its own name to be able to update it later.
Usually, the LauchConfiguration will be named according to the stack and resource name from the template, something like: {stack-name}-{resource-name}-{AWS-generated-id}, this gived me for example: amp-g2g-preprod-api-ec2-ApiLaunchConfiguration-1PQ85HXBX7DVC.
If you need to reference anywhere else your LaunchConfiguration, use {"Ref":"..."} from within the template, or use output export/import from another template.