How to Separate Aspera Console and Shares onto Two Different EC2 Instances


This article outlines the steps for separating Aspera Console and Shares onto two different EC2 instances. This will involve spinning up an Aspera Server on Demand (SOD)/Application Platform on Demand (APOD) EC2 instance, backing up Aspera Console, restoring the backup on the new instance, and disabling Console on the old instance. These steps were tested with Console


The SOD/APOD AMI must be shared into your AWS account.

SSH access to your EC2 instances.

Aspera Console is the same version on both instances (your current Aspera On Demand and the one that will be booted up).


  1. Spin up the SOD/APOD AMI in your AWS account.
  2. While waiting for the SOD/APOD instance to boot, log into your Aspera Console's web UI.
  3. Once logged in, go to Configuration > Database. Click Back Up....
  4. In the Save to field enter /tmp. Click Back Up Now. This will create a backup directory in /tmp.
  5. Once the new SOD/APOD instance has finished booting up, transfer the backup directory onto it. To transfer via ascp, you will need to do the following:
    1. Log into your new SOD/APOD by inputting its IP/DNS name into a web browser. The default username is "admin" and the default password is its instance id.
    2. You will be prompted to input your entitlement information. If you do not know this information, you can find it on your other instance by going to ConfigurationLicense. Click Save once you have inputted your entitlement information into your new instance.
    3. Go to Nodes editAccounts. Find the "xfer2" user and click edit
    4. Click on Authorization to expand it. For Incoming Transfers and Outgoing Transfers uncheck the "OVERRIDE" box. This will change "EFFECTIVE VALUE" to "allow". Click Save Changes.
    5. SSH into your new SOD/APOD instance and change to be the root user. Using a text editor such as vi, open "/etc/ssh/sshd_config" and change PasswordAuthentication no to PasswordAuthentication yes. Save and quit the file. Restart sshd by entering "service sshd restart".
    6. SSH into your original Aspera On Demand instance and transfer the Aspera Console back up directory to your new instance using ascp. The syntax will look similar to this:
      1. ascp console_full_backup_timestamp/ xfer2@

      2. For password, enter the new instance's instance id.
      3. Change PasswordAuthentication yes back to PasswordAuthentication no and restart sshd if you do not plan on using passwords for authentication.
  6. Now that the back up directory is on your new instance, we will restore Console onto this instance.
  7. Stop Console by entering "asctl console:stop".
  8. Restore Console by entering "asctl -v console:restore /mnt/ephemeral/data/xfer2/console_full_backup_timestamp/". If the restore fails, ensure that you are providing the full path to the backup directory and that both instances have the same version of Aspera Console.
  9. Modify the node API users on your new SOD/APOD instance:
    1. List your node API users: "/opt/aspera/bin/asnodeadmin -l --internal".
    2. Modify each, using the node API password from your previous instance (instance id, by default):
      • /opt/aspera/bin/asnodeadmin -m -u xfer2 -x xfer2 -p {node-password}

      • /opt/aspera/bin/asnodeadmin -m -u xfer -x xfer -p {node-password}

      • /opt/aspera/bin/asnodeadmin -m -u nodeadmin -x aspera_console -p {node-password} --internal

  10. Restart asperanoded: "service asperanoded restart".
  11. Start Console by entering "asctl console:start".
  12. Log into the web UI of your new SOD/APOD instance. Go to Nodes edit Credentials and click Test Credentials. If the test fails, ensure that the old instance has the proper ports open (port 9092 for the Node API, SSH). Ensure that everything is running as expected.
  13. Disable Console on the old instance:
    1. SSH into the instance
    2. asctl console:disable
  14. Shares and Console have now been successfully moved onto two different instances.

Other Resources

Powered by Zendesk