Changing the name of a Load Balancer on AWS Console

Question

After navigating to Menu > EC2 > Load Balancing > Load Balancers, I found that an important load balancer I inherited was named "testing", where it should be named something more meaningful for future dev ops (i.e. "search"). This load balancer is currently in use with a few instances running.

I'd like to change the name of this load balancer if possible, or at minimum find some way to make it clear on the AWS Console this load balancer is for our "search" functionality. I added a Tag to the LB, but there's no way to make tags visible on the table.

Is there any way to change the name of the load balancer, or at least add a "display name" or "notes" column to the console's UI?

Unlatch

Sounds like a raw deal. If your applications are routing to this ELB through a Route 53 record, it isn't an incredibly involved process to simply copy these ELB's settings to a new ELB and cut the Route 53 record over to the new ELB. – Coenocyte

@AnthonyNeace I didn't see your comment, initially, and I appear to have inadvertently stolen your suggestion. Apologies. If you'd like to post that, I'll be happy to defer and take mine down. – Sophist

@Michael-sqlbot No worries, it's all good and good to stay! I'm happy that a solid answer was posted. – Coenocyte

Answer 1

You can't change the name of a load balancer, because that would break the sites that use the load balancer.

ELBs have an associated hostname, that looks like this:

${balancer_name}-${opaque_identifier}.${region}.elb.amazonaws.com

(The ${opaque_identifier} is assigned by the ELB provisioning infrastructure to disambiguate same-named ELBs belonging to different accounts, but has no documented external meaning.)

Renaming the load balancer, if it were allowed, would necessarily change this hostname, which is how sites are pointed to the balancer, using CNAME records or A-record aliases (in Route 53)... and that would break the sites, since they would then be pointing to a nonexistent hostname.

The simplest solution is to create a new balancer with the name you want, using the same configuration, then migrate to it: with the old one still functioning normally, attach the new balancer to the same back-end instances, wait for them to show "in service" ... test ... then change the DNS entries pointing to the old balancer to point to the new balancer ... wait for the TTLs on the old DNS records to elapse, for the new balancer to pick up the traffic, and for the old balancer to show no traffic in the Cloudwatch metrics ... verify behavior ... then delete the old balancer.

Having the same set of instances attached to multiple ELBs is a supported configuration, so you should not have any transitional issues with this if you configure the new balancer identical to the old one, with the same subnets, security groups, listener configurations, etc.

Sophist

I see. Is there no way to add a column to the Console UI that just says "This load balancer is actually x"? – Unlatch

The closest thing is a tag, but that's only accessible from the "Tags" tab -- but -- unlike the EC2 Instances view, where the Name tag appears on the main screen, and you can add additional tag keys for display -- the Load Balancers view doesn't appear to have that feature. – Sophist

Yeah, that's what I've done so far, but it isn't enough. All I need is for future developers to not be confused. Hopefully they'll add a feature to let tags be displayed. Thanks for your input – Unlatch

It's quite unbelievable that a company this size does not realise they'll need an ID for identification and just uses the name. Rather outdated and clunky design. – Construction

Answer 2

ALL resources in AWS should use an immutable uid as the 'name' that is used internally. The name that one sees in the console / returned by describe-whatever> CLI, etc, should just be a property that can be changed anytime. EC2's name is just a changeable tag so why not everything else?

One of the problems with uid is AWS still clinging to the 'accounts' paradigm whereas most places have an organisation with several accounts. Yet everyone has to deal with resource models that have account-scope instead of organisation-scope. It reminds me of Active Directory in the days when there was no such thing as a forest.

Carat