Security is a critical pillar at AWS, and HPC data is often a mission critical asset. The lab environment you have just created is working in your own account, which means you have full control and ownership of your data and applications. In this module, you will review the AWS approach to security and some of the key technologies you can use to keep your HPC applications and data secure.

Topics covered:

  • The AWS Shared Responsibility Model
  • Using AWS Identity and Access Management (IAM)
  • Network Security
  • Authentication

When evaluating the security of your HPC infrastructure in the Cloud, it is important to understand and distinguish between:

  • Security measures that the cloud service provider (AWS) implements and operates – "security of the cloud"
  • Security measures that the customer implements and operates, related to the security of customer content and applications that make use of AWS services – "security in the cloud"

While AWS manages security of the cloud, security in the cloud is your responsibility. Customers retain control of what security they choose to implement to protect their own content, platform, applications, systems and networks, no differently than they would for applications in an on-site datacenter.


It is important to understand that the lab’s security is part of your responsibility, as it is a solution deployed inside your AWS account. To learn more, you can attend a free 4 hours on-line training or read the AWS Security whitepaper.

For greater security and organization, you can give access to your AWS account to specific users—identities that you create with custom permissions. For the HPC environment you launched in the previous module, you used the AWS root user, which is the single sign-in identity that has complete access to all AWS services and resources in the account. For your production workload, it is best practice to create and use an alternative user (known as an IAM User) with sufficient permissions to deploy the CloudFormation template.

The whole lab is contained in a newly created Virtual Private Cloud (VPC), which provides isolation from other environments and applications you might be running in the same account. Inside this VPC, multiple Subnets are used to host EC2 services, including VMs and Load Balancers.

In the lab’s template, the CIDR range you provided as a parameter is used to restrict HTTPS access to the Application Load Balancer and SSH access to the head node of the cluster(s) using Security Groups and other VPC components. Be aware that the HTTPS and SSH certificates are different, and the HTTPS one is self-signed, and therefore it is not recommended for production use.

A security group acts as a virtual firewall to allow and prevent traffic to an instance based on source CIDR, protocol and port. One or more security groups are associated with an instance. Rules are added to a security group to allow traffic to or from its associated instances. You can modify the rules for a security group at any time. The new rules are automatically applied to all instances that are associated with the security group.

Security groups associated with an instance are displayed from the EC2 console with the description of the instance, as shown in the screenshot below. For more information, see the user guide for Amazon EC2 Security Groups.


The screenshot above displays the Amazon EC2 console and highlights security groups. Box 1 highlights the security group of a selected Amazon EC2 instance and Box 2 highlights an alternate way to access your security groups through the EC2 console.

Because users managed inside the AWS Identity and Access Management can only be used for native AWS services, the lab implements user authentication via the Simple AD, a simple offering in the AWS Directory Service, which offers Microsoft Active Directory compatibility.

This authentication solution is used both to validate the user credentials in the EnginFrame web access, which runs on the cluster’s head node, as well as to propagate users in the cluster nodes as they are dynamically created and removed, and provides a uniform name space to ensure consistent file access on EFS.

As you design and build your HPC infrastructure, you may consider switching to the Microsoft AD Directory Service product, to improve the Windows compatibility and establish trust relationship between an AWS hosted directory and your on-premises directories.

Amazon EC2 uses public key authentication for privileged access to Ec2 instances. Public key authentication is more secure than password authentication, using a public key to encrypt transferred data while the terminal recipient uses the private key to decrypt the data. The public and private keys are known as a key pair.

The key pair associated with the Master and Compute instances is entered as a parameter during the launch of the lab. It is required to log onto both the master and the compute instances as the ec2-user account, which has sudo permissions and has no password.

Use the public IP address and the ssh key to log onto your instances as follows: