Versions Compared

Old Version 3

changes.mady.by.user Former user

Saved on

compared with

New Version 4

changes.mady.by.user Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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