support routing policy setting for ARecord class

[geekybaiyi]

Please support routing policy parameters for ARecord in CDK.

Not all parameters are supported in CDK Route53 module currently. https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-route53-recordset.html

any plan to support those in the future?

---

This is a :rocket: Feature Request

[NGL321]

Hi @geekybaiyi,

Thank you for submitting the request! From what I could tell in the docs, it looks like all the parameters supported in Cloudformation are supported in the CDK.

Could you tell me which parameters you are missing?

[geekybaiyi]

how about these ? "Failover" , "GeoLocation", "MultiValueAnswer", "Region", "SetIdentifier", "Weight"

[nmussy]

Indeed, they are missing from the L2 ResourdSet construct. You can access them right now via the CfnRecordSet resource, for example:

const zone = HostedZone.fromLookup(this, 'zone', {domainName: 'example.com'});

const record = new ARecord(this, 'A', {
    zone,
    target: RecordTarget.fromIpAddresses('1.1.1.1'),
    recordName: 'www',
});

const recordSet = (record.node.defaultChild as CfnRecordSet);
recordSet.failover = 'PRIMARY';

[geekybaiyi]

I noticed an PR is created associated with this issue. any idea when it would be merged? thx!

[itaykat]

How can one reach CfnRecordSet from an ApplicationLoadBalancedFargateService object?

[ryanvaloris]

The CfnRecordSet seems to be missing the Latency routing policy as well. Is there a timeline for when that will be added?

Additionally, the policies also appear to be configurable for more than just A Records. CNAMEs for example allow this policy.

[jdnz]

@ryanvaloris you can enable latency routing by setting the region and setIdentifier of the CfnRecordSet, e.g.

const record = new ARecord(this, 'apiA', {
    zone: zone,
    target: target,
    recordName: apiName,
});

const recordSet = (record.node.defaultChild as CfnRecordSet);
recordSet.region = region;
recordSet.setIdentifier = region;

[theGreatHeisenberg]

Is there a way to create cross region Arecord or CNAME? I want to implement latency based routing where I will creating CNAMEs for latency based routing.

parentZone CNAME IADZone
parentZone CNAME PDXZone

Where parentZone, IADZone, and PDXZone are all in different AWS accounts . Is there a way to create this via CDK? Possibly using CrossAccountZoneDelegationRecord?

[eugene-screenmeet]

@ryanvaloris you can enable latency routing by setting the region and setIdentifier of the CfnRecordSet, e.g.

const record = new ARecord(this, 'apiA', {
    zone: zone,
    target: target,
    recordName: apiName,
});

const recordSet = (record.node.defaultChild as CfnRecordSet);
recordSet.region = region;
recordSet.setIdentifier = region;

You the real MVP

[shadogar]

We shouldn't have to be going into the L1 construct like this. The L2 should support all of the routing policies. Is this ticket still on the roadmap? I see it's been around for 3 years now

[andremmfaria]

Bumping this feature request. This L2 construct would be awesome to have.

[UriConMur]

Hi, Im expecting to be able to setup the type as weighted and Im doing it this way:

const aRecord = new ARecord(this.scope, resourceId, {
      zone: this.hostedZone,
      target: RecordTarget.fromAlias(new CloudFrontTarget(distribution)),
      recordName: domain,
    })
    const recordSet = aRecord.node.defaultChild as CfnRecordSet
    recordSet.setIdentifier = 'UniqueWeightedIdentifier' // this needs to be unique from all your other A Weighted Records
    recordSet.weight = 200

And it works fine, it will be easier of we can add this using constructor props.

[mvs5465]

Bump on this request but for CNAME records.

[renatoargh]

It's already more than 2 years since jdnz amazing answer... do we know if there's already a nicer way to support latency-based A records from CDK? 👀

[badmintoncryer]

Hi there. I've implemented weighted routing (https://github.com/aws/aws-cdk/pull/28705) for RecordSet class, so you can configure it easily from L2 now. It is possible to set not only A records but all other types of records as well.

Additionally, I plan to implement features such as latency based routing (https://github.com/aws/aws-cdk/pull/28723) and IP-based routing(https://github.com/aws/aws-cdk/pull/28833) or so.

I believe it will still take some time before the merge, but please wait a little longer.

[flaxpanda]

Hi there. I've implemented weighted routing (#28705) for RecordSet class, so you can configure it easily from L2 now. It is possible to set not only A records but all other types of records as well.

Additionally, I plan to implement features such as latency based routing (#28723) and IP-based routing(#28833) or so.

I believe it will still take some time before the merge, but please wait a little longer.

thanks @badmintoncryer!

[github-actions[bot]]

This issue has received a significant amount of attention so we are automatically upgrading its priority. A member of the community will see the re-prioritization and provide an update on the issue.

[wladyslawczyzewski]

hi there. I have already implemented the Failover routing strategy - but haven't published it yet as it has some dependencies to health checks on which I'm working on rn #9481

[related-issues-bot-for-aws[bot]]

Hi @geekybaiyi,

Thanks for opening this issue! After reviewing the details, we found some other discussions that may be closely related:

Related Issues

• #26753: This issue addresses the same fundamental limitation in Route53's L2 constructs, requesting exposure of the L1 CfnRecordSet properties in higher-level constructs. Both issues aim to avoid the current workaround of accessing the L1 construct through node.defaultChild to configure routing policies. The current issue specifically lists routing policies like "Failover", "GeoLocation", "MultiValueAnswer", "Region", "SetIdentifier", and "Weight" that need to be exposed, while this issue uses weighted routing as its example.

• #28722: This issue specifically requests support for latency-based routing in Route53's L2 constructs, which requires the "Region" and "SetIdentifier" parameters mentioned in the current issue. Both issues identify the same limitation that users currently need to access the underlying CfnRecordSet to configure routing policies.

• #28939: This issue specifically focuses on implementing multivalue answer routing support in Route53's L2 constructs, which is explicitly mentioned as "MultiValueAnswer" in the list of unsupported parameters in the current issue. Both issues recognize the need to extend L2 constructs to avoid resorting to L1 CfnRecordSet directly.

• #9478: This issue requests support for geolocation routing in Route53's L2 constructs, which is explicitly listed as "GeoLocation" in the unsupported parameters mentioned in the current issue. Both issues address the same limitation where L2 constructs don't expose routing policy configuration options available in CloudFormation.

• #28801: This issue requests support for IP-based routing in Route53's L2 constructs. While not explicitly mentioned in the current issue's list of parameters, it represents another routing policy type that follows the same pattern - requiring L2 construct support to avoid working directly with the L1 CfnRecordSet.

This message was generated automatically to help connect related conversations and improve discoverability

Please react with 👍 or 👎 to let us know if this response was helpful!

Thank you for helping improve CDK! 🙌