If doing more than 100 requests implying the AWS CLI associate-address sub-command, subsequent calls will cost $0.10 each, so If doing to much scale in/out or have a monitoring/automated tool that frecuenly make API calls using this sub-command, the bill is not going to be cheap:

  • Scale in (remove instances)
  • Scale out (add instances)

additional remap

Long story short, The associate-address sub-command, is an idempotent operation, if you call "aws ec2 associate-address" with the same combination of instance and EIP as the one currently in place, it won't return an error; instead, it will return and count as successful, regardless of whether an actual allocation was done or not. Consequently, being it counted as a successful request, you'll be billed accordingly.

Idempotent operations take an important role, basically because you expect that operation will not result in different results no matter how many times you operate the idempotent operations. (Idempotent = Re-runnable).

This can be avoided by using private addresses and Load balancers, but in cases where you need to deal with Elastic IP's this maybe an issue, mainly for monitoring scripts or periodic checks, or use the describe-address and based on the result decide to use or not the associate=address sub-command

🔗associate-address

Associates an Elastic IP address with an instance or a network interface. This is an idempotent operation. If you perform the operation more than once, Amazon EC2 doesn't return an error, example:

$ aws ec2 associate-address --instance-id i-24ea6379 --allocation-id eipalloc-b58d24da
{
    "AssociationId": "eipassoc-b7b117df"
}

http://docs.aws.amazon.com/cli/latest/reference/ec2/associate-address.html

After running the previous command 100 times, the following requests will cost each $0.10 per Elastic IP address remap either the association didn't succeed or if it was made to an existing IP.

Basically this means that if you have something that periodically checks your instances and tries to remap or ensure that your elastic IP is pointing you a desired instance:

    10.0.1.3 ---> 58.41.28.32

After doing 100 calls, the following request will cost $0.10 each.

🔗Auto scaling

While creating an auto-scaling group, could be the need to map each of the instances to use an Elastic IP's, based on the scaling in/out policies this would imply that after reaching the 100 limit, each reboot will cost $0.10.

🔗Example of how to use the associate-address from a startup script

#!/bin/sh

# KEYWORD: firstboot
# PROVIDE: set_hostname
# REQUIRE: NETWORKING
# BEFORE:  SERVERS

. /etc/rc.subr

name="set_hostname"
rcvar=set_hostname_enable
start_cmd="set_hostname_run"
stop_cmd=":"

export AWS_ACCESS_KEY_ID=aws_access_key_id
export AWS_SECRET_ACCESS_KEY=aws_secret_access_key
export AWS_DEFAULT_REGION=the_region

TAG_NAME="Salt"
INSTANCE_ID=$(/usr/local/bin/curl -s http://169.254.169.254/latest/meta-data/instance-id)
REGION=$(/usr/local/bin/curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone | sed 's/.$//')
TAG_VALUE=$(/usr/local/bin/aws ec2 describe-tags --filters "Name=resource-id,Values=${INSTANCE_ID}" "Name=key,Values=$TAG_NAME" --region ${REGION} --output=text | cut -f5)

set_hostname_run()
{
	hostname ${INSTANCE_ID}
	sysrc hostname="${INSTANCE_ID}"
	sysrc salt_minion_enable="YES"
	echo ${INSTANCE_ID} > /usr/local/etc/salt/minion_id
	pw usermod root -c "root on ${INSTANCE_ID}"
	if [ ! -z "${TAG_VALUE}" ]; then
		echo "node_type: ${TAG_VALUE}" > /usr/local/etc/salt/grains
	fi
	# allocate IP X.X.X.X
	/usr/local/bin/aws ec2 associate-address --instance-id $INSTANCE_ID --allocation-id eipalloc-xxxxxxxx
}

load_rc_config $name
run_rc_command "$1"