Change of instance type & family on a pair of AWS CSRv's (v17.3.4a)

[james.brunner]

Hi there,

We've got a pair of CSRv's (v17.3.4a) running in AWS on c4.2xlarge instances but the CPU's are running a tad hot (75% sustained during the work day due to high IPSEC loads but well within their licenses, but the underlying AWS instances have a CPU load alarm). Our other CSRs around the world are on the newer c5.2xlarge instance type and have much lower load.

I'd like to change our loaded CSRs instance type from c4.2xlarge to the newer c5 family and up them to 4xlarge.

But, a long time ago (Jan 2018/Meltdown/Spectre) we tried to change instance types after the AWS patch that hit our instances and, while it worked somewhat (badly), the advice was to rebuild them anyway.

You can imagine I'd rather not rebuild this time around if I don't have to - has anyone else made an instance type/family change on a more modern 17.x CSR and been successful?

Thanks!

JB.

[james.brunner · Accepted solution]

Just to complete the story, the answer is yes. You can change the instance type without borking the CSR.

However, going from the AWS c4 to c5 instance families does mean the new instance will use enhanced networking interfaces, so you have to enable the ena-support attribute on your instance. This is not available through the AWS console but can be executed via the AWS CLI through the console once the instance is shutdown.

The process I used was:

1) Shut down the instance

2) Take an AMI backup in case you need to revert back to a clean state under the c4 configuration

3) Change instance type from c4.2xlarge to c5.4xlarge

4) Execute from the AWS CLI: aws ec2 modify-instance-attribute --instance-id i-xxxxxxxxxxxxxxxxx --ena-support

5) Start the instance

6) Make use of the new 'Nitro' instance feature by using the "EC2-Console" access to the instance to watch it boot in real-time.

It did take 10-15 mins to come back up from cold so the console stayed blank for a looooong time - nervous time! Since booting it has been running 50-60% less on the CPU (in the AWS console) and so far, no high latency or packet loss at peak times.

Hope this helps someone in the future.

JB.