Cover image for Amazon Route 53: How to automatically update IP addresses without using Elastic IPs

Amazon Route 53: How to automatically update IP addresses without using Elastic IPs

aws_john profile image John Rotenstein Updated on ・3 min read

Here's a handy way to automatically update an A-Record in Amazon Route 53 whenever an EC2 instance changes IP address.

Scenario: You have a domain name in Amazon Route 53 pointing to an Amazon EC2 instance. However, if the instance is stopped and started, its public IP address changes. This breaks the A-Record since it is pointing to the wrong IP address.

"Wait!" you might say, "Why not simply use an Elastic IP address?"

(An Elastic IP address is a static IP address that can be assigned to resources in an Amazon VPC. The IP address stays the same until you return the Elastic IP address to AWS.)

Yes, using an Elastic IP address on the instance will prevent the A-Record from breaking. However, AWS gives a default limit of 5 Elastic IP addresses per region. You can request a limit increase, but what if you need lots of them?

As an example, a service might provide a separate Amazon EC2 instance for each customer, to ensure secure separation of data. Each customer is given a domain name to access their server (acme.example.com). The required number of Elastic IP addresses could be huge.

Fortunately, there is a fairly simple way to achieve the objective without needing any Elastic IP addresses.



The architecture is quite simple:

  • When the EC2 instance starts, it should get its new public IP address and update its own record in Route 53
  • The DNS name to update is stored in a Tag on the EC2 instance
  • The script should execute every time the EC2 instance starts (that is, every time it starts, not just the first boot)


First, there should be a Record Set in Amazon Route 53 that defines the existing domain name.

Route 53 Record Set

It is currently pointing to the public IP address of an EC2 instance.

Next, add some tags to the EC2 instance that will be used by the script:

  • DNS Name: The DNS Name to associate with the instance
  • Hosted Zone ID: Uniquely identifies the Zone record in Route 53 that needs to be updated (get it from your Route 53 Hosted Zone record)

EC2 instance tags

Whenever the EC2 instance starts, it will run a script that will:

  • Grab the information from the above tags
  • Retrieve the instance's current public IP address
  • Update the Route 53 record set with the new IP address
# Extract information about the Instance
INSTANCE_ID=$(curl -s
AZ=$(curl -s
MY_IP=$(curl -s

# Extract tags associated with instance
ZONE_TAG=$(aws ec2 describe-tags --region ${AZ::-1} --filters "Name=resource-id,Values=${INSTANCE_ID}" --query 'Tags[?Key==`AUTO_DNS_ZONE`].Value' --output text)
NAME_TAG=$(aws ec2 describe-tags --region ${AZ::-1} --filters "Name=resource-id,Values=${INSTANCE_ID}" --query 'Tags[?Key==`AUTO_DNS_NAME`].Value' --output text)

# Update Route 53 Record Set based on the Name tag to the current Public IP address of the Instance
aws route53 change-resource-record-sets --hosted-zone-id $ZONE_TAG --change-batch '{"Changes":[{"Action":"UPSERT","ResourceRecordSet":{"Name":"'$NAME_TAG'","Type":"A","TTL":300,"ResourceRecords":[{"Value":"'$MY_IP'"}]}}]}'

To execute the script automatically each time the instance starts (as opposed to User Data scripts that only run on the first boot), put the above script in this directory:


Finally, the EC2 instance will need an IAM Role assigned that has permission to run the above commands:

    "Version": "2012-10-17",
    "Statement": [
            "Effect": "Allow",
            "Action": "ec2:DescribeTags",
            "Resource": "*"
            "Effect": "Allow",
            "Action": "route53:ChangeResourceRecordSets",
            "Resource": "arn:aws:route53:::hostedzone/HOSTED-ZONE-ID"

How to test

To test the script, simply Stop the instance then Start it again.

This will result in a new public IP address being assigned to the instance. The script will call Amazon Route 53 to update the record set. This might take a minute to update.

Then, return to Route 53 and look at the IP address assigned to the A-Record. It should be updated with the new IP address.

Posted on Feb 14 by:

aws_john profile

John Rotenstein


Technical Evangelist at AWS


Are you a developer, architect, or community member interested in the cloud? The AWS Developer Relations team loves teaching about AWS and programming for customers of any background


markdown guide

Nice idea, sounds very useful! But I'm still stuck with one question.
Doesn't this introduce a major security risk ? When your ec2 would get compromised, the attacker has the permissions to update your hosted zone. Because of this, he/she could potentially point your domain to their site.
Or I might be missing something, not quite sure.


I love your phraseology: "When your ec2 would get compromised", rather than "If". With a pessimistic attitude like that, you'd make a good security professional! (We're hiring!)

You are correct — it is always important to grant only the permissions that are required, lest the credentials accidentally, or intentionally, are used for other purposes. The above policy limits the potential changes that a specific Hosted Zone. I'm not sure whether it is possible to lock-down further to a specific Record Set.

For the really security-minded, you could have the instance call an AWS Lambda function that makes the call on its behalf. This way, the instance would not have any permissions to change the Route 53 information. The Lambda function would require such permission, but Lambda could be considered more "locked-down" than an Amazon EC2 instance.


You should be able to use CloudWatch Events to trigger the Lambda on EC2 instance state-changes. This way you don't even need to grant permissions to Lambda. Something like aws.amazon.com/premiumsupport/know...


Thank you for clearing that up! The lambda could also do some validation when updating the record set, so that the record could only point to targets that you own yourself.


Great article.

I just tried it out, and there was just one little detail that I was banging my head against for the last hour: the shell script needs to start with a shebang like: #!/bin/bash.

Until, I made this change to the script, it was not executing properly on each boot, and I was constantly running into this error in /var/log/cloud-init.log :

2020-02-17 06:57:29,292 - util.py[WARNING]: Failed running /var/lib/cloud/scripts/per-boot/auto-bootIP-route53.sh

I got the hint that the shebang line was needed from this:

cloudinit.util.ProcessExecutionError: Exec format error. Missing #! in script?

that I found over here. Your script is working great now!

I'd also like to point out that you might want to change this line:
"Resource": "arn:aws:route53:::hostedzone/Z3NAOAAAA11BB22"
to something like "Resource": "arn:aws:route53:::hostedzone/<YOUR_ROUTE53_ZONE_ID_here>". Just in case someone is not alert enough to modify the literal ZoneId in their IAM policy, when copy+pasting from the article :)

Overall, super-useful post. Thank you!


Oops! Sorry for causing you that problem. I've now updated the post.


I followed your instructions (I guess...) and I am getting the following error :
An error occurred (AccessDenied) when calling the ChangeResourceRecordSets operation: User: arn:aws:sts::6XXXXXXXX118:assumed-role/UpdateRoute53/i-XXXXXXXXX is not authorized to perform: route53:ChangeResourceRecordSets on resource: arn:aws:route53:::hostedzone/XXXXXXXX2I
I add the policy to the EC2 instance and the user (mine respectively) but I still get this error. Do you have an idea of what I could have done wrong ?

thanks in advance,



That's odd!

The IAM policy is specifically granting permission to call ChangeResourceRecordSets on the Hosted Zone. All I can suggest is that you check that you have put the correct HOSTED_ZONE_ID in the IAM Policy. It should start with a 'Z'.


Thanks John, as usual the problem was between the chair and the keyboard. This was exactly my mistake.


Is there any other setting required for the the script to run on boot? I followed exactly same steps mentioned in this article but the script doesn't fire up, no log entry in the cloud-init.log as well. I'm able to execute the script manually and the record set is getting updated.


Nevermind I managed to fix it, the script had to be made executable and also had to update /etc/cloud/cloud.cfg file's - scripts-per-boot to - [scripts-per-boot, always]