Cloudfront + alternate domain a record + idempotent deployments... how?

[lamontadams]

I have a public cloudfront distribution that provides a single domain for the purposes of proxying into multiple backend services via origin + behavior rules. I want to be able to perform idempotent deployments requiring no manual interventions. After some experimentation, it seems in addition to providing the alternate domain to the cloudfront construct, I am also responsible for adding the domain alias into route53.

So, my cdk stack contains this (very simplified) code:

import { nanoid } from "nanoid";
import { ARecord, HostedZone, RecordTarget } from "aws-cdk-lib/aws-route53";
import { CloudFrontTarget } from "aws-cdk-lib/aws-route53-targets";
import { Distribution } from "aws-cdk-lib/aws-cloudfront";

export const repro = (scope: any) => {
  const zone = HostedZone.fromHostedZoneAttributes(scope, nanoid(), {
    hostedZoneId: "xxxxxx",
    zoneName: "some-app.com",
  }) as HostedZone;
  new ARecord(scope, nanoid(), {
    zone,
    recordName: "sub-domain",
    target: RecordTarget.fromAlias(
      new CloudFrontTarget(
        Distribution.fromDistributionAttributes(scope, nanoid(), {
          distributionId: "xxxxxx",
          domainName: "xxxxxx.cloudfront.net",
        })
      )
    ),
  });
};

The desired outcome is, an a record is created in route 53 pointing sub-domain.some-app.com to the cloudfront.net distribution domain, and that the resulting cdk stack can be deployed over repeatedly.

The reality is, running my repro code alone twice results in a failed deployment with the error: "[Tried to create resource record set [name='sub-domain.some-app.com.', type='A'] but it already exists]".

If I remove the A record from route53, I am able to deploy the stack again, but subsequent deployments fail with the same error.

I see ARecord has a "deleteExisting" property which seems like it would prevent this error, but this is marked as deprecated and dangerous... and would also, I assume, result in non-zero downtime during deployments while the DNS record was deleted and recreated.

Is this scenario - managing route53 ARecords via cdk in an idempotent manner - just explicitly not supported then? Are there any suggested workarounds that don't require manual intervention on each deployment or downtime (neither are acceptable in my scenario)?

Thanks.