It appears the CloudFront SaaS Manager requires CNAME records to point to CloudFront, which is inefficient, doesn't support zone apex records, and has been long since solved by R53 and standard CloudFront via ALIAS records
For example, any use of ALIAS records will fail on certificate issuance for the distribution tenant:
aws route53 change-resource-record-sets \
--hosted-zone-id **** \
--change-batch '{
"Changes": [
{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "lab1.cloudshiftdev.io",
"Type": "A",
"AliasTarget": {
"HostedZoneId": "Z2FDTNDATAQYW2",
"DNSName": "****.cloudfront.net",
"EvaluateTargetHealth": false
}
}
}
]
}'
aws cloudfront create-distribution-tenant \
--distribution-id **** \
--name business-id-12345 \
--domains '[{
"Domain": "lab1.cloudshiftdev.io"
}]' \
--parameters Name=business-id,Value=12345 \
--connection-group-id **** \
--managed-certificate-request '{
"ValidationTokenHost": "cloudfront"
}' \
--enabled
This fails with An error occurred (InvalidArgument) when calling the CreateDistributionTenant operation: The provided Domain Name is not valid. Could not verify Domain Name ownership. It may not be pointing to a valid CloudFront resource. (same error doing this operation in the console).
Switching to a CNAME record works - to the extent that CNAME records are usable, which isn't the case for zone apex records.
Concerningly, the blog post "Reduce your operational overhead today with Amazon CloudFront SaaS Manager" grossly misrepresents this, showing zone apex domains (e.g. my-flower-store.com) as being DNS verified - but that could only have happened doing manual verification (modifying web server configuration or dropping verification token files), not using the touted "reduce operational overhead" that CF/ACM integration provides.
Standard CF distributions support - and recommend - DNS alias records (its required for zone apex, and offers improved performance); gross design flaw/regression to ship CF multi-tenant that doesn't support alias records / zone apex domains. And: aside from that single blog post, none of the CF documentation mentions using CNAME records (or not supporting alias records). Non-specific statements such as "Update your DNS records to route traffic from each domain to the CloudFront routing endpoint.".
Its not an option to use the manual verification methods offered by CF/ACM integration, as these require an existing service to host a well-known token file/redirect - for new domains there's nothing existing, which CF handles nicely (when its a CNAME record).
