Accounts

As of 3/12/2020 we now have access to 2 distinct AWS accounts:

• Science History IT, Account # 335460257737  which is where the Digital Collections, ArchiveSpace, and other projects our group manages live.
  
• CommunityHistoryProject  Account # 225397940402 which is where the Community History S3 Buckets live for billing purposes.

Accessing different Accounts

If you are an admin in the main account, you can switch accounts to access the Community History Project account.

1. Log into your normal AWS account
2. In the upper right, look for your user name. Click on it.
3. In the drop down that appears, select the "Switch Role" option
4. Enter in the Account Number of the account you want to access, and then the Role
   1. Role is the IAM permission set that has access to the second account
      1. For CommunityHistoryProject it is chp-admin
5. You may set a name for this, otherwise it will inherit the IAM permission as the name
6. Submit the change, you will now see the new role in a distinct color where your username used to be and the new account number, (chp-admin @NEW_ACCOUNT).
7. You are now logged into the new account with admin permissions.

AWS - add new user

• IAM (identity & access management) > Users > Create New Users.
• Enter user name, uncheck 'generate an access key', create
• select newly-created username > 'permissions' tab > Attach policy (you can look at policies on other users if needed)
• 'security credentials' tab > 'assign an auto-generated password', check 'require user to create a new password at next sign-in'
• download the security credentials.
• (another option is to have the person stand right next to you and give themselves a temporary password)
• Stick the credentials somewhere safe!
• Machines cannot be moved between virtualization types
• Get user to sign on and reset password.

AWS - Virtualization methods and limits

Currently AWS supports two distinct and different virtualization methods, paravirtual (PV) and hardware virtual (HV). See this page (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html) for all the details.

For our purposes there are a few key facts

...

• Older Hydra setups for CHF used m3 on a paravirutal method. Current setups use a HVM m4 instance. Recreating old machines needs to use an old AMI.
  
• Inside the same type, you can change the type from the EC2 dashboard by selecting Action→Instance Setting→Change Instance type. This is scriptable.

AWS - Instance types

Currently we are using AWS m4 instances on HV virtuzalization. HVM currently supports performance levels that match PV methods and open up the potential for improved network tools or GPU based computing.

The m4.large instance type was chosen due to the following requirements

•   Java is RAM hungry and so to make full use of tools like Solr and Fedora 8 GB of RAM was useful
• m class instances have a static CPU value allowing us to have a standard level of performance, as we do not currently have details on usage patterns this seems the safest option.

Development and test instances should use the t2.large instance for the following reasons

• Identical RAM profile
• 14% cost reduction on hourly machines
• Baseline CPU limits are lower than m4 (they can burst higher) but this should not ever be an issue in development.
• Reserved pricing is the same so offers no benefit on long term instances.
  

If we do not need the full RAM use for development, t.2 medium instances are approximately 50% of the cost of a m4.large.