AWS::Route53::RecordSet should allow to be imported into a new stack

[OlafConijn]

Quick Sample Summary:

I would expect resources of type AWS::Route53::RecordSet to be importable using CloudFormation

Category (required) - Will help with tagging and be easier to find by other users to +1

Networking & Content (VPC, Route53, API GW,...)

[PatMyron]

more generally tracking in #276

As CloudFormation Registry types now automatically support resource import operations, a migration of this type to the newer Registry framework should pick this up automatically

[pmmsignify]

This should not be closed. AWS::Route53::RecordSet is still not importable:
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-import-supported-resources.html

[AlecZebrick]

+1 just came across this myself

[benbridts]

For anyone stumbling on this issue, there is a workaround for "simple" records:

1. In the old stack: make every record a weighted records with (eg) weight 1 and AWS::StackName as SetIdentifier
2. In the new stack: create a new resource that's exactly the same as the old stack (same weight, AWS::StackName as identifier)
3. Remove the record from the old stack
4. Make the record in the new stack a simple record

[AlecZebrick]

That would be nice, but what if you're trying to import records which were not created by cloudformation at all? In my case trying to import 20 records into a stack, but all of the records were created by hand. No problems importing the hosted zone itself, a little weird that the records are limited

[benbridts]

@AlecZebrick You should be able to make them weighted with the CLI or console (and use e.g. "manual" as SetIdentifier)

I would like every resource to be supported by imports, but AWS teams have to do a migration for older resources to get there (not sure why they were working on that in 2022 and it has not been deployed yet)

[PatrykPetryszen]

+1 we can't wait once this feature will be available.

[totojack]

+1

[Luchiap]

Work at AWS support here, even though this github is closed, there is an internal feature request open for this.
As a workaround that worked in my testing:
Let's say you have a hosted zone in console which has records in it and you want to import this into a cloudformation template.
You first need to import the hosted zone. A stack and a template gets generated out of it. The records are not in that template yet.
Then you need to update the stack and you need to add the exact records that are in the console. Cloudformation will not create new records and it will not fail (on existing records already).
It will simply 'import' them into the stack.

You can use Former2 tool to get the exact resource infrastructure of the records.

[garrethmcdaid-zd]

@Luchiap Can you elaborate on your answer?

I did as you suggested, and created a stack by importing just the zone.

I then attempted to use update-stack and add the records, but Cloudformation tried to create the and failed because they already exist.

[Luchiap]

@garrethmcdaid-zd this did not happen to me, nor my support client at the time.
You have to be super sure you are using the exact resource information of the existing records. Have you used former2?

[garrethmcdaid-zd]

@Luchiap Can you confirm you used the CLI update-stack operation when doing this?

I'm just can't error messages to state that the records already exist.

[andrej-p]

Just to share - I have the similar situation - I need to start managing a route53 zone with CFN.

I have created a template file with all the resource records I want to add to the CFN stack (just a subset of the actual records in the actual zone - the rest of the records are either SOA, NS, or ACM verification records, or records managed in other stacks, so I did not need to add them).

During my testing in one domain I was able to just run the stack creation without importing the zone, and all the records (which already existed in the zone and were defined in the template) were successfully added to the stack and I could have kept managing them through CFN.

In other domain I experienced an issue that the www.domain.tld CNAME could not have been created - it failed with [Tried to create resource record set [name='www.domain.tld.', type='CNAME'] but it already exists].
Then it deleted all the entries that I tried to "import" from the actual zone 😓

Please use DeletionPolicy: Retain while working on this 😄

I've tried creating the stack with "Preserve successfully provisioned resources", which has "imported" the resources, but has left the stack in the CREATE_FAILED state. I was then able to delete the resources that were not successfully "created" from the zone, and have been able to run the stack update which has created them without issues. This is not cool because of the downtime while they get recreated.

I've then tried recreating the stack from scratch, and...it has successfully "imported" all the resources! :exploding: I guess that something was broken around that www.domain.tld entry from the tests I ran, so that is cool!

So, the whole process here was:

1. add the ResourceRecords I want to manage to the template with DeletionPolicy: Retain
2. run a creation of the new stack, which did not delete any existing stack, it just enabled managing them through CFN

I like CFN more and more, to be honest.

[luk2302]

What @Luchiap wrote is correct: CloudFormation will allow you to auto-import existing records IFF the record is absolutely identical. This means the type, the name, the value and even the TTL need to match.
Then CF will internally do 4 things:

• issue a ChangeResourceRecordSets call to create the record - this call will fail because the record already exists
• issue a ListResourceRecordSetsInfo call to get the current record
• compare the retrieved record with the desired record and only if they match will it continue to
• issue a second ChangeResourceRecordSets with a DELETE and a CREATE action for the same record explaining in the comment of the API call "Making no-op change to get a ChangeId"

You can double-check all that using CloudTrail.

After this CF now knows and tracks the record and can from now on update and also delete the record(s). This means the record(s) is actually a resource for which CF supports an auto-import feature, without actually supporting a manual import.