Aspera on Cloud Overview: Self Managed vs Saas Transfer

The IBM Aspera on Cloud or AoC offering is a cloud-based file transfer service that allows organizations to transfer files built on the cutting-edge IBM technology known as FASP. Aspera FASP or Fast and Secure Protocol is an incredibly secure and resilient file-transfer protocol that is able to transfer files up to 100 times faster than FTP or HTTP. 

The Aspera on Cloud solution can be deployed in two unique deployments, either as a self-managed or SaaS-based Aspera server to facilitate the file transfer. Before we dig into the use cases for both deployments, let’s briefly discuss the architectural components of Aspera on Cloud.

Aspera on Cloud consists of two components, an Aspera on Cloud application that is installed locally on the host machine and the Aspera Transfer Server. 

The Aspera on Cloud Application:

The Aspera on Cloud application is installed on the host machine to facilitate communication between the host machine and the Aspera Transfer Server. This local application allows users to seamlessly drag and drop files onto the Aspera web-based interface to initiate a file transfer to the cloud-based Aspera Transfer Server.

The Aspera on Cloud Transfer Server:

The Aspera on Cloud Transfer Server is a cloud-based server that facilitates the file transfer to and from endpoints. Here, users can quickly and seamlessly transfer files from their workstation to the Aspera Transfer Server and allow for users to download that same file from the Aspera Transfer Server allowing for speed, security, and reliability of the transfer process.

Self-Managed Vs. SaaS Managed Transfer

As noted, specific components of the Aspera on Cloud solution, in particular, the Aspera Transfer Server, can be implemented either as self-managed or Saas Managed. In the following article, we will look at the unique pros and cons of implementing the Aspera on Cloud Transfer server in a self-managed orientation or SaaS managed.

	SaaS	Self-hosted
Compute Costs	Included	Yes, Client account
Scaling	Included	Yes, Client would need to build and manage
Object Storage Support	Yes, only specific regions in public clouds	Yes, all regions
Block Storage	No	Yes
Egress	$0.03/GB beyond included amount	Billed through Client account
Infrastructure Management	No, cluster managed by IBM Aspera	Yea, Client Manages
Version Upgrades	Included	Yes, customer must upgrade as needed
Irdeto Integration	Yes, Irdeto Watermarking (requires Irdeto subscription as well)	No, would require custom development
APIs for custom integrations	Yes	Yes

Testing Self-Managed Vs. SaaS Managed Transfer

As a way to get a deeper understanding of the self-managed and SaaS managed process, we highly recommend trialing both services in your own VPC. In order to start the evaluation, sign up for the trial here:

https://www.ibm.com/account/reg/us-en/signup?formid=urx-30538

**Please reach out to us at engineering@pacgenesis.com and we can assist with getting the evaluation up and running.

SaaS set-up: Attaching Cloud Storage

You can attach an existing AWS S3 storage to your AoC organization. Once attached, you can make the bucket and its contents available to your AoC users.

Use this procedure when you have an existing AWS S3 and want to make it (or content from it) accessible to users in your AoC workspaces. If you already have an existing Aspera transfer node (which can be on-prem or in the cloud, and managed by you or by Aspera) with its Node URL and password, see Adding a Node to the Organization.

Note: To attach other storage types (for example, IBM COS, MS Azure, Google), see Attaching Cloud Storage to Your AoC Organization.

AoC Access Keys

Once you attach the AWS S3 bucket, you can give various users access to specifically designated parts of the storage using AoC access keys. Distinct from the AWS S3 bucket access keys, these native AoC access keys are an additional layer of security that allows you to securely access the bucket through AoC and other Aspera client applications. You can create multiple AoC access keys to the same AWS S3 bucket to partition access to specific areas of the storage. For details, see Creating Transfer and Access Credentials.

Note: Once you attach the S3 bucket, you can use the Aspera GUI to transfer to your cloud storage; see Using the Transfer Service from the Desktop Client GUI.

Prerequisites

• You must have transfer service administrator (ATS admin) access to Aspera on Cloud.
• You must have administrative access to the AWS S3 configuration portal.
• The AWS S3 bucket must be in a region that is supported by the Aspera transfer service. To view the supported regions, to see IP addresses for whitelisting in your firewall configuration, and to retrieve your transfer service server URL, follow this link: https://ats.aspera.io/pub/v1/servers/AWS.
• You must have an AWS S3 IAM Role to use for trust relationship policies. You need to add this role in the AWS portal Trust relationships tab. Note the role name so you can add it in the following procedure; for example, “Aspera-Role”. To create an IAM role, see Creating an AWS S3 IAM Role and Policy.
• To provide extra security for your environment, see the procedure below called “Enhance Access Security for an AWS S3 Bucket”.

Procedure: How to Attach the Bucket to AoC

This procedure requires you to use both the Aspera on Cloud Admin interface and the AWS portal interface.

1. In the Aspera on Cloud Admin app, do the following:
   1. Go to Nodes and storage > Nodes > Create new.
   2. Click Attach my cloud storage.
      If this option does not appear at the top of the page, you do not have transfer service admin (ATS admin) privileges. You must ask a user who has ATS admin privileges to add this privilege to your user profile. The transfer service admin should go to Users, filter for your user name, then click the row to open your user record; then, in the Admin roles section, click the check box labeled ATS admin, then Save.
   3. Enter a Node name for the transfer service node; this name refers to the AWS S3 storage.
   4. If a pre-configured network policy is required for this node, click the Network policy field and select the intended policy.
      For details, see Creating Network Policies.
   5. If a pre-configured node configuration policy is required for this node, click the Configuration policy field and select the intended policy.
      For details, see Creating Node Configuration Policies.
   6. In the Storage field, select Amazon S3.
   7. In the Region field, select the Amazon region that contains the S3 bucket.
   8. In the Storage class field, select the desired setting.
   9. In the Server-side encryption field, select the desired encryption type, if any.
      Note: You can enable encryption only on nodes that are not configured for watermarking. See this article for details.
   10. If you selected AWS KMS in the previous field, enter the KMS key ID ARN or key alias ARN in the KMS key ID or key alias ARN field.
       KMS key ID ARN:
       Syntax: arn:aws:kms:<region>:<account_number>:key/<encryption_key_id>
       Example: “arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab”
       KMS key alias ARN:
       Syntax: arn:aws:kms:<region>:<account_number>:alias/<encryption_key_alias>
       Example: “arn:aws:kms:us-west-2:111122223333:alias/my_key_alias”
       Note: Be sure to include the AWS bucket region in the ARN.
   11. Copy the contents of the Trust relationship policy field. If necessary, you can edit the policy before you copy it.
       Important: The trust relationship JSON updates with each page load.
       • Before you copy the trust policy, be sure that you have correctly configured the region (step 1g above).
       • After you copy the trust relationship, be sure to save the configuration or otherwise verify the page is not reloaded.
   12. If the page reloads after you copy the trust relationship, there will be a mismatch between the trust relationship in AoC and the trust relationship in the AWS console.

1. Log in to the AWS portal and do the following:
   1. Go to Services > IAM > Roles. Find the IAM role you created for the trust relationship policy; for example, “Aspera-Role”.
   2. Click to select the role and go to the Trust relationships tab.
   3. Click Edit trust relationship.
   4. Paste the policy you copied from the Aspera on Cloud Trust relationship policy field in step 1h. Be sure the paste operation replaces all existing text.
   5. Click Update Trust Relationship.
   6. Copy the role ARN (Amazon Resource Name) for this role.
2. Return to the Aspera on Cloud Nodes > Create new > Transfer node window and do the following:
   1. Paste the role ARN that you copied from the AWS portal in the AoC IAM Role ARN field.
   2. Complete the form with the S3 bucket and path.
      • To grant access to the entire bucket, enter / (that is, a slash character).
        
      • To grant access to a specific directory in the bucket, enter /<path_name> (that is, slash+path_name).
        
   3. Click Save.
      Note: If you see the error message, “Unable to create ATS access key and secret”, see Creating a New Access Key for a troubleshooting procedure.
   4. Download or copy and save the Aspera on Cloud access key and secret according to local site practice. These credentials allow you to access this node for content management and configuration activities. If you download, Aspera generates a text file with the default name KeySecret.txt. Aspera recommends that you rename this file to make it easier to track and manage.
      Important: Aspera on Cloud does not store the secret. Once you complete this step, you can no longer retrieve the secret. You must track these credentials according to your own local site security practices.
   5. To protect content in this bucket with Aspera encryption at rest, do one of the following:
      • To use Aspera’s native key management capabilities, see Use Aspera-Managed Keys for Server-Side Encryption at Rest.
      • To use your own key management service (KMS), see Bring Your Own Key for Server-Side Encryption at Rest
   6. Click Save to complete creation of the new transfer service node. See this new node in the list of nodes by going to Nodes and storage > Nodes.

This storage can now be used to support a workspace.

• To share a folder in the bucket with members of an existing workspace, see Sharing a Folder with a Workspace.
• To create a new workspace hosted on this bucket, see Creating a New Workspace.
• To create native AoC access keys to the bucket or a partition of the bucket, see Creating Transfer and Access Credentials.

Optional: Enhance Access Security for an AWS S3 Bucket

You can apply an optional policy to enhance AWS S3 bucket access security. Use the procedure below to restrict access to the bucket from any IP address except those you specifically designate; this restriction is also known as whitelisting. This policy will still allow the Aspera transfer service to access the bucket for transfer operations.

1. In the Amazon console, go to the intended bucket, then click Permissions > Block public access.
2. Configure the options as shown in the following screen shot, being sure not to block cross-account access.
3. Go to Permissions > Bucket Policy.
4. Enter the same policy that you applied to the associated role.
5. Copy the “Principal” stanza from the trust relationship in the role to the bucket policy, as show in the screen shot below.
6. If desired, use this JSON example, changing the following:
   • Replace the sample “Principal” stanza shows below with the actual “Principal” stanza from the trust relationship in the associated role.
   • For the variable <region>, substitute the region for your bucket.
   • For the variable <bucket_name>, substitute the bucket name.
   • For the variable <allowed_IP_address>, substitute the allowed IP address(es), formatted in a JSON array (for example: [“192.0.2.0/24“, “203.0.113.0/24“]
   • For the variable <ats_vpc>, substitute the AWS virtual private cloud ID or VPC endpoint ID 

Find the required VPC ID and VPCE ID listed by AWS region below:

Self-Managed Set up: Attaching your Self Managed Aspera Server

You can add your own IBM Aspera High-Speed Transfer Server to your AoC organization. Your transfer server may be on-premises, in a private cloud, or in a public cloud. You must first configure the transfer server specifically for use with AoC, and then add it to AoC with the Admin application. This process is often referred to as tethering a node, and once the process is completed the server is referred to as a tethered node.

You can also use the Aspera on Cloud transfer service to connect your existing cloud storage. For details, see Attaching Cloud Storage to Your AoC Organization.

Prerequisite

Before you can add your transfer server to AoC, you must configure it as described in Configuring an Aspera Transfer Server as a Node for Aspera on Cloud.

Adding a Node

To complete this procedure, you must have the following information available:

• Node URL.
• Node SSH fingerprint. Aspera recommends that you secure transfers with the SSH fingerprint from the transfer node (but it is not required). For information about retrieving the node fingerprint, see Securing Your SSH Server in the IBM Aspera High-Speed Transfer Server Admin Guide.
• If you are going to use an existing access key for the node (that you created on the transfer server), you need the access key ID and secret.
• If you are going to create an access key in the process of adding the transfer server (node) to your organization, you need the Node user name and password, and information about the storage you are using. For local storage, this is simply the path on the node. For cloud storage, you need to know the details of that storage (for IBM COS, Amazon S3, Microsoft Azure Blob, or Microsoft Azure Files). For example, for Amazon S3, you need the storage class, IAM Assume role credentials, endpoint, bucket, and path.

Note:

If you have multiple Aspera on Cloud organizations that use the same storage, you must use separate access keys for each organization.

1. In the Admin application, go to Nodes > Create new.
2. Enter the name that you want to use for this node.
3. Enter the node’s URL and asperanoded port.
   For example https://www.example.com:443.
   CAUTION:
   Be sure to use the asperanoded port as configured for your tethered-node server. See Configuring User-Managed Transfer Server Services for Aspera on Cloud Authentication.
4. Optionally, enter the node SSH fingerprint.
5. To apply a configured network policy to this node, click the downward caret in the Network Policy field and select the intended policy; see Creating Network Policies.
6. To apply a configured node configuration policy to this node, click the downward caret in the Configuration Policy field and select the intended policy; see Creating Node Configuration Policies.
7. Provide an access key/secret pair.
   If you have already created a key/secret pair for this node on your transfer server, click Use existing and enter the node access key and secret. Then click Save, and you are done with this procedure.
   Otherwise, click Create new access key and proceed with the following steps.
8. Enter the Node user name.
9. Enter the Node user password.
10. Select the storage type, and configure storage details with data relevant to this storage type.
11. Click Save.
12. Click Download Access Key Pair.
13. Download or copy and save the Aspera on Cloud access key and secret according to local site practice. These credentials allow you to access this node for content management and configuration activities. If you download, Aspera generates a text file with the default name KeySecret.txt. Aspera recommends that you rename this file to make it easier to track and manage. You must download or copy these credentials to proceed.
    Important: Store the key and secret in a secure and accessible location according to local site security practices. Aspera on Cloud does not store the secret. Once you complete this step, you can no longer retrieve the secret.
14. Click OK.
15. To protect content on this node with Aspera encryption at rest, do one of the following:
    • To use Aspera’s native key management capabilities, see Use Aspera-Managed Keys for Server-Side Encryption at Rest.
    • To use your own key management service (KMS), see Bring Your Own Key for Server-Side Encryption at Rest
16. Click Save.

CAUTION:

For user-managed nodes (on-premises or cloud-based), schedule backups of the Redis database on your node. The Redis database contains your file IDs, permissions, access keys, and other node data. If it is corrupted and you do not have a backup, you must manually recreate your workspace. For instructions on creating backups, see “Backing up and Restoring a Node Database” in the IBM Aspera High-Speed Transfer Server Admin Guide.

Updating Node Status

Aspera on Cloud polls the transfer node for node settings every five minutes; configuration changes you make to the node (for example, changes to aspera.conf) are propagated to Aspera on Cloud at that polling interval. If necessary, you can initiate an immediate poll from Aspera on Cloud to the node so that node configuration changes are reflected immediately in Aspera on Cloud behaviors.

1. Go to Nodes and storage > Nodes.
2. Filter, search, or browse for the intended node in the node list.
3. Double-click the node row and select Update Status, then click OK to confirm
4. • Local

Local Term	Local Definition
Path	The absolute path on the storage.

• Amazon S3

Amazon S3 Term	Amazon S3 Definition
Storage class	Select as appropriate: (1) Standard, or (2) Reduced redundancy, or (3) Infrequent access.
Server-side encryption	Select as appropriate: (1) None, (2) AES-256, or (3) AWS KMS. This configures encryption on the server in AWS.
KMS key ID ARNorKMS key alias ARN	If using AWS KMS server-side encryption:The AWS Key Management Service key ID, in the format arn:aws:kms:<region>:<account_number>:key/<encryption_key_id>.KMS key ID example: “arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab”.orThe AWS Key Management Service key alias, in the format arn:aws:kms:<region>:<account_number>:alias/<encryption_key_alias>.KMS key alias example: “arn:aws:kms:us-west-2:111122223333:alias/my_key_alias”Note: Be sure to include the AWS bucket region in the ARN.
IAM Role ARN	The Amazon Resource Name (ARN) of the IAM role to assume.
External ID	The unique identifier used by third parties when assuming roles in their customers’ accounts. The storage account holder sets this ID. To find it, go to the AWS management console, then click Roles > yourRole > Trust Relationship. Find your trust relationship in the list, and see the External ID listed in the ‘Conditions’ column for that relationship. Not all trust relationships include an external ID.
Session name	The role session name that uniquely identifies a session when the same role is assumed by different principals or for different reasons.
Bucket	The bucket name.
Endpoint	The URL that is the entry point to the storage for a web service. Example: s3.amazon.com.
Path	The relative path under the bucket.

• IBM COS

IBM COS Term	IBM COS Definition
Access key ID	The ID of the access key for the IBM COS.
Secret access key	The secret that matches the key.
Bucket	The bucket name.
Endpoint	The URL that is the entry point to the storage for a web service. Example: s3.us.cloud-object-storage.appdomain.cloud.
Path	The relative path under the bucket.

• Microsoft Azure Blob

MS Azure Blob Term	MS Azure Blob Definition
API type	Select as appropriate: (1) Block, or (2) Page.
Storage credentials	The access key for SAS URL for the storage.
Storage account	The storage account provides a unique namespace in Azure for your data. Every object that you store in Azure Storage has an address that includes your unique account name. The combination of the account name and the Azure Storage blob endpoint forms the base address for the objects in your storage account.
Access key	The key ID associated with the storage account.
Container	The name of the container that organizes a set of blobs. A container is similar to a directory in a file system.
Path	The relative path in the container.

• Microsoft Azure Files

MS Azure Files Term	MS Azure Files Definition
API type	Select as appropriate: (1) Block, or (2) Page.
Storage account	The storage account provides a unique namespace in Azure for your data. Every object that you store in Azure Storage has an address that includes your unique account name. The combination of the account name and the Azure Storage blob endpoint forms the base address for the objects in your storage account.
Password	The password to the storage account.
Path	The relative path on the storage.

Ask Us Your Aspera Questions

If you’d like to learn more about Aspera on Cloud, specifically get a deeper understanding of the value in a self-managed configuration versus a Managed SaaS configuration, consider reaching out to the team at PacGenesis! Here at PacGenesis, as an IBM Gold-status Partner, we’ve made it a priority to help organizations adopt new file transfer solutions such as Aspera. With over 10 years of experience and hundreds of satisfied clients supported, we’re certain that we can help your organization with any questions or concerns related to file transfer capabilities.

To reach us, call us at (512) 766-8715 or email us at sales@pacgenesis.com.

512-766-8715