1

I have an AWS EC2 instance with an of type t2.micro. I wish to change the instance type to m3.medium without losing the bindings that I have set up within IIS.

I currently have a binding for HTTPS.

I have an instance with an EBS instance as the storage so I know I won't lose the files, but I will lose the settings.

What steps can I take in order to retain the bindings when I change the instance type. Is there a way to configure this to be set when the instance comes back up again?

HTTPS Binding

Step by Step to Reproduce Behaviour

  1. Launched EC2 t2.micro using elastic beanstalk
  2. Created a self signed certificate in IIS
  3. Added binding to application within IIS (HTTPS binding), choosing the self signed certificate as the certificate to be used
  4. Changed the instance type within the Elastic Beanstalk settings page
  5. Looked at the bindings and the HTTPS one is gone within IIS and so is the self signed certificate.

I was also able to reproduce this behaviour by selecting Stop from the EC2 list page. A new instance is automatically created again and this results in a lost binding and self signed certificate.

The files for my website are retained in both cases.

8
  • What "bindings" are you referring to? – EEAA Dec 1 '15 at 21:37
  • Please see the update with the screenshot showing the bindings. These are set within IIS by clicking Bindings... when the application is selected. – Luke Dec 1 '15 at 21:41
  • Why do you think those will go away when you change instance type? – EEAA Dec 1 '15 at 21:42
  • I just did it and these settings disappeared. It seems that these settings are stored in IIS on the non-persistent storage of the instance. – Luke Dec 1 '15 at 21:45
  • 2
    The IIS settings are stored on the EBS volume. Changing the instance type will preserve your settings. If they were not preserved, then they were lost for other reasons. – Matt Houser Dec 1 '15 at 21:53
2

The problem is that you are customizing a running Elastic Beanstalk instance. Don't do this.

Many changes that you make to the Elastic Beanstalk application will terminate and re-create your EC2 instance based on the original AMI image. This is why you're losing your settings.

Instead, create a custom AMI image with your custom IIS settings, then modify your EB application to use that custom AMI image.

As a general rule, don't modify your EB instances directly. Do not RDP into them and make changes because they will be lost when the instance is terminated.

Update

To create a custom AMI image:

  1. Find the source AMI image of your EB application. This can be found in the EB settings.
  2. Launch your own instance based on this AMI image that is not part of your EB application.
  3. RDP and customize this instance.
  4. Stop the instance and create an image of it using sysprep.
  5. Update your EB application to use this new AMI image.
6
  • Thank you, I just discovered the AMI section and started creating one just as you posted. This begs the question, if the general rule should be not to RDP to make changes, how should changes like adding a binding be made before I create the image? – Luke Dec 1 '15 at 22:39
  • If you can answer that I'd be really appreciative. – Luke Dec 1 '15 at 22:51
  • @Coulton Feel free to ask that as a new question, that probably deserves more elaboration than a comment can fit. – Anthony Neace Dec 1 '15 at 23:09
  • I think you misunderstood my answer. Using RDP to make changes is fine, just don't do it directly on an Elastic Beanstalk instance. – Matt Houser Dec 1 '15 at 23:31
  • I have updated my answer here to include custom AMI image instructions. – Matt Houser Dec 1 '15 at 23:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.