Creating a Template

In the Cluster Manager console, go to Templates.

Duplicate the existing default template: EC2 Default. Select Duplicate from the Action drop-down menu.

Enter the following information in the Provider section.

Setting	Description
IAM Role	The name of the role you set for the transfer nodes.
AMI Identifier	The unique identifier of the transfer node AMI.
Instance Type	Your AMI's instance type. Aspera recommends instance types with at least 7.5 GB memory and adequate network performance.
Region	The region where the cluster will bise deployed. This has to be the same region where the S3 buckets are located that are accessed by the cluster.
Subnet IDs	The ID of your VPC subnet. Cluster nodes are distributed across the different subnets in a round-robin fashion.
Security Groups	The security group created for use by the transfer nodes.
Availability Zone (Optional)	Specify the specific zone or zones for launching a cluster. If not set, the cluster manager distributes the nodes across the availability zones in your chosen region.
Elastic IP Addresses (eip_pool)	The Elastic IP (EIP) addresses assigned to your cluster. EIP addresses are only needed if transfer clients require IP address whitelisting.
Tags	An array of key-value pairs that used to tag cluster node instances. You can define multiple tags. They are assigned to every new cluster node that is launched. ATCM automatically adds a tag "cc" with the DNS name of the Cluster Manager instance as the value.
Volume Size	The size (GB) of the root partition of the transfer nodes. The default is 20 GB.
Swap Volume	Defines the volume size and volume type of the swap volume. For more information on available volume type, see the Amazon EBS Volume Types article on the AWS website: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html

{
    "type": "AWS_EC2",
    "aws_credentials": {
        "iam_role_name": "node_iam_role"
    },
    "ami_identifier": "ami-identifier",
    "instance_type": "type.size",
    "subnet_ids": [
        "subnet-identifier",
        "subnet-identifier"
    ],
    "availability_zones": [ 
        "available_zone1",
        "available_zone2" 
        ]
    "security_groups": [
        "security_group"
    ],
    "key_name": "key_name",
    "eip_pool": "eip_pool_address",
    "region": "region",
    "tags": {
        "Department": "department",
        "Project_ID": "ID"
    }
    "volume_size": "disk_size"
    "swap_volume": {
        "size": volume_size,
        "type": "volume_type"
    }
}

For example:

{
    "type": "AWS_EC2",
    "aws_credentials": {
        "iam_role_name": "atc-node"
    },
    "ami_identifier": "ami-fb25e890",
    "instance_type": "m4.xlarge",
    "subnet_ids": [
        "subnet-03beee3b",
        "subnet-9ce3e2ef"
    ],
    "availability_zones": [
        "us-east-1"
        "us-west-1"
    ]
    "security_groups": [
        "atp-node"
    ],
    "key_name": "aws_dev_ops",
    "eip_pool": "eipalloc-43cef945",
    "region": "us-west-2",
    
    "tags": {
        "Department": "dev_ops",
        "Project_ID": "AXF-1234"
    }
    "volume_size": "20"
    "swap_volume": {
        "size": 8,
        "type": "gp2"
    }
}

Instead of authenticating with an IAM role, you can isntead choose to authenticate with your Amazon Access and Secret Access Keys. You can create and obtain your Access Key ID and Secret Access Key ID by following the steps on the Amazon website: http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSGettingStartedGuide/AWSCredentials.html. Instead of using the iam_role_name element in the aws_credentials object, use the access_key_id and the secret_access_key elements:

{
    ...
    "aws_credentials": { 
        "access_key_id": "access_key",
        "secret_access_key": "secret_key"
    ...
}

For example:

{
    ...
    "aws_credentials": { 
        "access_key_id": "AKIAIOSFODNN7EXAMPLE",
        "secret_access_key": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
    ...
}

Alternatively, you can authenticate with your Amazon Access amd Secret Access Keys instead.

Note: If the Cluster Manager is running outside of AWS, but you want to launch nodes in AWS with an IAM role, you have to specify both an Access Key and an IAM Role in the cluster template. The Cluster Manager uses the Access Key, but instructs the nodes to run in AWS with the given role.

{
    ...
    "aws_credentials": {
          "access_key_id": "access_key",
          "secret_access_key": "secret_key",
          "iam_role_name": "node_iam_role"
    ...
}

For example:

{
    ...
    "aws_credentials": {
          "access_key_id": "AKIAIOSFODNN7EXAMPLE",
          "secret_access_key": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
          "iam_role_name": "atc-node"
    ...
}

Enter the following information in the DNS Configuration section.

Setting	Description
Type	Set the type to `"AWS_Route53"`. This is the only DNS service currently supported.
Hosted Zone	The hosted zone name. The name must include the final dot (for example, `dev_ops.company.com.`).
Hosted Zone ID	The hosted zone ID is optional and is only needed if you have multiple hosted zones with the same name (for example, the same zone for both private and public networks).
TTL	The time to live in seconds for DNS responses.

Configuration with IAM Roles

Cluster nodes connect to Route 53 using the permissions with which the node is running. If the node is running with an IAM role (in other words, the "iam_role_name" option is used in the Provider section), then that role needs the necessary permissions to access Route 53. The Cluster Manager must be using an IAM role with the same Route 53 policy as the node (see Creating IAM Roles).

{
    "type": "AWS_ROUTE53",
    "hosted_zone": "hosted_zone.",
    "hosted_zone_id": "hosted_zone_id"
    "ttl": 1
}

Important: The hosted zone name must include the final dot.

For example:

{
    "type": "AWS_ROUTE53",
    "hosted_zone": "dev_ops.company.com.",
    "hosted_zone_id": "Z1ZXQD414LGXRA"
    "ttl": 1
}

Using an Assume Role for Authentication

If your atc-manager and atc-node IAM roles do not include the atc-route53-policy, you can create a separate atc-route53 IAM role (see Creating the Route 53 IAM Role) and have the manager and the nodes assume that role's permissions. To configure this, add an "aws_credentials" object with an "assume_role_arn" element as follows:

{
    "type": "AWS_ROUTE53",
    "aws_credentials": {
        "assume_role_arn" : "arn:aws:iam::YOUR_AWS_ACCOUNT_ID:role/atc-route53"
    },
    "hosted_zone": "hosted_zone",
    "hosted_zone_id": "hosted_zone_id"
    "ttl": 1
}

For example:

{
    "type": "AWS_ROUTE53",
    "aws_credentials": {
        "assume_role_arn" : "arn:aws:iam::123456789012:role/atc-route53"
    },
    "hosted_zone": "dev_ops.company.com.",
    "hosted_zone_id": "Z1ZXQD414LGXRA"
    "ttl": 1
}

Using AWS Access Keys for Authentication

If your atc-manager and atc-node IAM roles do not include the atc-route53-policy, you can authenticate to Route 53 with access keys. The access key must be associated with an AWS user that needs to have permission to update Route 53. You need both your Access Key and Secret Access Key IDs. You can create and obtain your Access Key ID and Secret Access Key ID by following the steps on the Amazon website: http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSGettingStartedGuide/AWSCredentials.html.

{
    "type": "AWS_ROUTE53",
    "aws_credentials": {
        "access_key_id": "access_key",
        "secret_access_key": "secret_key"
    },
    "hosted_zone": "hosted_zone",
    "hosted_zone_id": "hosted_zone_id"
    "ttl": 1
}

For example:

{
    "type": "AWS_ROUTE53",
    "aws_credentials": {
        "access_key_id": "AKIAIOSFODNN7EXAMPLE",
        "secret_access_key": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
    },
    "hosted_zone": "dev_ops.company.com.",
    "hosted_zone_id": "Z1ZXQD414LGXRA"
    "ttl": 1
}

If you need to use a firstboot script to customize your nodes, enter your script into the Firstboot Script field.

You can customize your transfer nodes by specifying a first-boot script when launching the cluster. This script is run before all other first-boot scripts. For more information on using first-boot scripts, see Customizing Cluster Nodes Using the Custom First-boot Scripts.

Click Save Changes.