Introduction

CloudFormation can easily reference attributes of resources it creates in the same stack, but it cannot arbitrarily look up the DNSName of an existing unmanaged ELB just by name. If the load balancer already exists outside the current stack, the usual solutions are to pass the DNS name as a parameter, import it from another stack export, or fetch it through a custom resource.

What Works Natively in CloudFormation

If the ELB is created in the same template, you can reference its attributes directly.

1Resources:
2  MyLoadBalancer:
3    Type: AWS::ElasticLoadBalancing::LoadBalancer
4    Properties:
5      Listeners:
6        - LoadBalancerPort: "80"
7          InstancePort: "80"
8          Protocol: HTTP
9
10Outputs:
11  LoadBalancerDns:
12    Value: !GetAtt MyLoadBalancer.DNSName

That is the easy case because CloudFormation owns the resource and knows its attributes.

Existing ELB Outside the Stack

If the ELB already exists and is not managed by the current stack, you cannot write:

Value: !GetAtt ExistingElb.DNSName

unless ExistingElb is actually a resource in the template. CloudFormation is declarative, not a general AWS query engine for arbitrary existing resources.

That is why people usually choose one of these patterns instead.

Option 1: Pass the DNS Name as a Parameter

The simplest solution is to supply the DNS name explicitly:

1Parameters:
2  ExistingElbDnsName:
3    Type: String
4
5Resources:
6  AppRecord:
7    Type: AWS::Route53::RecordSet
8    Properties:
9      HostedZoneName: example.com.
10      Name: app.example.com.
11      Type: CNAME
12      TTL: "60"
13      ResourceRecords:
14        - !Ref ExistingElbDnsName

This is simple and predictable, though it does shift responsibility to the stack caller.

Option 2: Export and Import From Another Stack

If the ELB is managed by another CloudFormation stack, export its DNS name there and import it here.

Producer stack:

1Outputs:
2  SharedElbDns:
3    Value: !GetAtt MyLoadBalancer.DNSName
4    Export:
5      Name: shared-elb-dns

Consumer stack:

1Resources:
2  AppRecord:
3    Type: AWS::Route53::RecordSet
4    Properties:
5      HostedZoneName: example.com.
6      Name: app.example.com.
7      Type: CNAME
8      TTL: "60"
9      ResourceRecords:
10        - !ImportValue shared-elb-dns

This is the cleanest approach when both stacks are already under CloudFormation control.

Option 3: Use a Custom Resource

If the ELB exists outside CloudFormation and you must discover it dynamically, use a Lambda-backed custom resource that calls the AWS API and returns the DNS name.

That approach is more flexible, but also heavier:

• you must write and maintain the Lambda
• you must handle permissions
• stack updates become more complex

Use it only when parameters or exports are not practical.

Another practical variant is to resolve the DNS name outside CloudFormation and store it in a place such as Systems Manager Parameter Store, then pass or read that value during stack deployment. That keeps the template simpler than a full custom-resource lookup while still avoiding hardcoded environment-specific values.

Common Pitfalls

The most common mistake is assuming CloudFormation can look up any existing AWS resource attribute by name in pure template syntax. It cannot.

Another issue is confusing classic ELB, ALB, and NLB resource types. The attribute names and CloudFormation resource types differ, so make sure the template matches the actual load balancer type.

A third pitfall is storing environment-specific DNS names directly in the template when they really belong in parameters, exports, or a configuration system. Hardcoding them reduces reuse.

Finally, if another stack already owns the load balancer, prefer exports and imports over ad hoc duplication. That keeps stack boundaries explicit.

Summary

• '!GetAtt ... DNSName works only for ELBs defined in the same stack.'
• CloudFormation cannot natively query arbitrary existing unmanaged ELBs by name.
• Use parameters for simple external references.
• Use Export and ImportValue when another CloudFormation stack already owns the ELB.
• Use a custom resource only when you truly need dynamic discovery of existing infrastructure.