Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Current »

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!
  • 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

  • Machines cannot be moved between virtualization types
  • We currently use HVM. The original Hydra box was PV, but we're not longer using that style of box.

AWS - Instance types

Currently we are using multiple instance types. Generally for production boxes we use either m4.large or t2.medium instance types.

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 Fedora 8 GB of RAM was useful
  • m class instances have a static CPU value allowing us maintain full use of the CPU for intensive tasks

The t2.medium instance was chosen for the following reasons

  • Approximately 50% of the cost of m4.large instances
  • Able to handle usage patterns in bursts of activity rather than sustained heavy load
  • Reasonable resources for moderate usage

Some other tools use smaller or larger instances based on needs. Monitoring and update boxes tend to be very small.

AWS - Volume types

In all instances where disk speed is an issue, select general purpose SSDs. If a disk is smaller than 100 GB this also usually easier.

In cases where disk capacity is the primary factor, select either Cold HDD or Throughput HDD volumes. They have a minimum size of 500 GB

  • Cold HDDs are slower but half the cost, and in cases where usage is light are preferred.
  • Throughput HDDS are faster and should be chosen when disk speed is a larger concern.

Fedora uses a Cold HDD for data storage due to reduced usage and the need to keep costs down.

Elastic IPs

AWS Security Groups used for ArchivesSpace

AWS Machines and Addresses (Obsolete)

  • No labels