Introduction

In AWS, a Route 53 alias record can point at certain AWS-managed targets such as Application Load Balancers, CloudFront distributions, API Gateway domains, and S3 website endpoints. A common question is whether the hosted zone and the target resource must live in the same AWS account. The short answer is no: cross-account alias records are possible, but the record must be created with the correct target DNS name and hosted zone ID, and the target service still has to be configured to accept the custom domain.

What a Cross-Account Alias Record Really Is

An alias record is a Route 53 record type that behaves like a DNS alias to supported AWS resources. It looks like an A or AAAA record in your hosted zone, but Route 53 resolves it to the underlying AWS target for you.

In a cross-account setup, the key point is that DNS resolution does not care which AWS account owns the target. Route 53 only needs the correct target information. That means:

• account A can own the hosted zone
• account B can own the ALB or CloudFront distribution
• Route 53 in account A can still create an alias record to that resource

The main operational difference is that the AWS console may not auto-discover the target when it is in another account. In that case, infrastructure code or the CLI is usually easier than point-and-click configuration.

The Values You Need

For most alias targets, you need two values:

• the target DNS name
• the target hosted zone ID used by that AWS service

For an ALB, those values come from elbv2 describe-load-balancers. For CloudFront, the DNS name is the distribution domain name and the hosted zone ID is the fixed CloudFront zone ID used for alias records.

Here is a realistic CLI example for an ALB in another account once you know its values:

1cat > /tmp/change-batch.json <<JSON
2{
3  "Comment": "Create cross-account alias record",
4  "Changes": [
5    {
6      "Action": "UPSERT",
7      "ResourceRecordSet": {
8        "Name": "app.example.com.",
9        "Type": "A",
10        "AliasTarget": {
11          "HostedZoneId": "Z35SXDOTRQ7X7K",
12          "DNSName": "internal-my-alb-123456.us-east-1.elb.amazonaws.com.",
13          "EvaluateTargetHealth": false
14        }
15      }
16    }
17  ]
18}
19JSON
20
21aws route53 change-resource-record-sets \
22  --hosted-zone-id Z1234567890ABC \
23  --change-batch file:///tmp/change-batch.json

This works because the hosted zone record is independent of the AWS account that owns the load balancer.

Service-Specific Constraints Still Apply

Cross-account aliasing is not just a DNS problem. The target service must also be configured correctly.

For CloudFront, the distribution in the target account must include your custom domain in its alternate domain names, and the certificate must cover that hostname. If you point cdn.example.com at a distribution that is not configured for cdn.example.com, requests will fail even though DNS resolves correctly.

For an ALB, the DNS alias works as long as network routing, listener rules, and certificates are correct. Route 53 does not validate your HTTPS listener or security group settings.

For private targets, be careful with visibility. A public hosted zone pointing at an internal ALB may resolve in public DNS, but the resource will not be reachable from the public internet. That is not a Route 53 problem; it is a network design problem.

Console Versus Infrastructure Code

In the console, same-account resources are often selectable from a drop-down list. In cross-account scenarios, that convenience can disappear. The safer pattern is to store the target values explicitly and create the record through code.

A Terraform example looks like this:

1resource "aws_route53_record" "app" {
2  zone_id = "Z1234567890ABC"
3  name    = "app.example.com"
4  type    = "A"
5
6  alias {
7    name                   = "my-app-123456.us-east-1.elb.amazonaws.com"
8    zone_id                = "Z35SXDOTRQ7X7K"
9    evaluate_target_health = false
10  }
11}

This is easier to review and avoids depending on console behavior that differs across accounts.

When a CNAME Is the Better Fit

If the target is not one of Route 53's supported alias destinations, use a CNAME for subdomains. Alias records are an AWS convenience feature, not a general cross-account indirection system.

Also remember that the root domain cannot be a CNAME in normal DNS practice. If you need example.com to point at an AWS target, alias is one of the reasons Route 53 is attractive.

Common Pitfalls

A common mistake is assuming cross-account aliasing requires IAM trust between the hosted-zone account and the target-resource account. For DNS resolution, it usually does not. You need the correct target values, not a role assumption flow.

Another mistake is using the wrong hosted zone ID. For alias targets, that is the target service's hosted zone ID, not your Route 53 hosted zone ID.

People also forget service-specific validation. CloudFront must be configured for the custom hostname, and ALB listeners must handle the incoming host correctly.

Finally, public and private DNS are easy to mix up. A public record can still point at something that is only reachable privately.

Summary

• Route 53 alias records can point to supported AWS resources in another account
• The hosted zone and target resource do not need to share an AWS account
• You need the target DNS name and the target service hosted zone ID
• Cross-account targets are often easier to configure through CLI or infrastructure code than through the console
• DNS can be correct while the application still fails because the target service is not configured for the hostname
• Use a CNAME only when the destination is not a supported alias target and the record is not the zone apex