Server on Demand with EIP and Autoscale




This article describes a process for provisioning your Server on Demand within the Amazon Autoscale service. This deployment is relevant for organizations that want to add some robustness to their Server on Demand deployment. The AWS Autoscale service is capable of monitoring a single instance, and if that instance should be deleted, a new instance will be launched. Here is a diagram of the solution.




Note: This article covers a single instance of Server on Demand (without Console) running in Autoscale. For running multiple instances, additional software and configuration is required to manage the cluster. Please contact Aspera about the Aspera Cluster Manager.



  1. You have a subscription to Aspera Server on Demand (SOD).
  2. You are familiar with the AWS services:  S3, Autoscale, Route53 (optional), Elastic IP, IAM role
  3. You have obtained an Elastic IP (EIP) for your Server on Demand instance
  4. You can ssh to your Server on Demand instance, using the ssh key
  5. You have created an IAM role for access to S3
  6. You have created a security group for your Server on Demand instance
  7. You have an AWS Access Key and Secrete for use with your instance
  8. (Optional - but recommended) You have a hostname for your Server on Demand that is registered in DNS pointing to your EIP


Procedure - Overview

  1. Configure your Server to use your EIP and Hostname
  2. Install and configure an EIP auto-configuration utility
  3. Add your own customization to the system (optional)
  4. Create a new AMI image of your configured system
  5. Configure a new Autoscale group and launch configuration for this new image


Procedure - details

  1. Launch and configure Server with EIP and Hostname (or IP)
    1. EIPs are assigned using the AWS console, or command line.  We urge you to assign the EIP address early in the SOD boot process.  The SOD boot scripts are designed to detect the EIP and auto configure SOD accordingly.  If you configure your EIP after SOD is fully booted, you will have to manually adjust a configuration file.  That process is documented in this knowledge base article.
    2. Hostname:  Configure your Aspera server to have knowledge of the Servers hostname.  This can be done via editing the aspera.conf file.  Here is an example command where I set the hostname to  You can also put an IP address instead of the hostname.
      asconfigurator -x "set_server_data;server_name,"
      You can confirm that this worked by looking at the file /opt/aspera/etc/aspera.conf.  You will see the configuration in the <server_name> section.
    3. Configure the server to stop re-configuring hostname on each reboot.  This is accomplished by editing the init script /etc/init.d/asp-ondemand-secondboot-reconfigure, and commenting out the following line (e.g. add the '#' at the beginning of the line) (NOTE: The default behavior of the system is designed for dynamic environments, where the IP address may chance on system reboot, which obviously will not work in this fixed IP / Hostname configuration.)
      #  /opt/aspera/ondemand/bin/ -A
  2. Install and configure an EIP auto-configuration utility
    1. Upon system reboot, it is required that SOD be auto assigned the same EIP.  As of the time of this article, there is no AWS facility for auto-assigning an EIP from within a booting instance.  (The AWS tooling assumes there is a human booting the system, or there is a pool of addresses). Fortunately someone has solved this problem and posted the solution. The steps are documented below.
    2. Login via SSH to your SOD system and sudo to root.  Install the aws-ec2-assign-elastic-ip utility:
      # curl "" -o ""
      # python
      # pip install aws-ec2-assign-elastic-ip
    3. Test the utility with your EIP, Access key and Secret, for example:
      aws-ec2-assign-elastic-ip --region us-west1 --secret-key FQkJs8uwSYijGcy4/IawBr0FsRCr8tPb3nDkCoFe --access-key ALIWIUKNOGS43OELHMTA --valid-ips
  3. Configure the default user data init script to run earlier in the boot process. The default init script is configured to be the last init script run in run level 3.  In our case, we want the EIP address assigned earlier in the boot sequence.  You need to adjust the default symbolic link, as follows.
    # cd /etc/rc.d/rc3.d/
    # rm -rf S99cloud-init-user-scripts
    # ln -s ../init.d/cloud-init-user-scripts S25cloud-init-user-scripts
  4. Create a new AMI image from your configured Server on Demand system
    1. Prior to creating a new image, you should shut down all services and clear log files
    2. Login to your AWS console, navigate to the EC2 > Images, select your running SOD image and from the ACTIONS menu, select Image > Create Image.
    3. Make a note of the new image AMI ID
  5. Configure a launch configuration and autoscale group
    1. Login to the AWS console, and navigate to the EC2 > Autoscale > Launch configuration.
    2. Click on Create new Launch configuration.
    3. Navigate to My AMI's and select the newly created AMI, click next.
    4. Select the Instance type (e.g. m3-xlarge) and click next.
    5. Specify the configuration details (e.g. IAM Role and Name) and click next.
    6. Select Advanced and add the following script into the userdata section. Adjust the script to your EIP, Access Key, Secret and region:
      aws-ec2-assign-elastic-ip --region us-west1 --secret-key FQkJs8uwSYijGcy4/IawBr0FsRCr8tPb3nDkCoFe --access-key ALIWIUKNOGS43OELHMTA --valid-ips
    7. Confirm that the storage space meets your requirement and click next.
    8. Specify the security group that provides sufficient access (e.g. SSH (optional) and TCP/UDP 33001)
    9. Review the configuration options and select an ssh key required to access the system.
    10. At this point, you have a launch configuration and you need to create the Autoscaling group.
    11. Create a new Autoscaling group, specify a name for your group.  
    12. Leave the default of 1 instance for this group (note;  For multiple Server instances - there are additional steps).
    13. (Optional) Specify the subnet that you are running your instance in.
    14. Specify an availability zone for your instance
    15. (Optional) Under advanced option, specify a custom health check grace period.
    16. (Optional) Create an autoscaling group notification and click next.
    17. (Optional - but suggested) Create a tag for your auto scaling group.
    18. Review all configured options and save the auto scaling group.

At this point, the AWS Autoscale group should launch an instance according to your specification.  You can view the running instance in your EC2 instances.  If nothing is there, please navigate back to the Autoscale Group configuration and review the Activity History and Instances for more information.

Powered by Zendesk