AWS Implementation
In case AWS is the resource provider, the "isolated environment" corresponds to a VPC. Unfortunately, it's impossible to completely restrict all permissions to a VPC due to the way the permission system (IAM) in AWS is build, e.g., access to images (AMIs) can't be restricted on this level. The described procedure in this section will lock down the permissions for the orchestrator instance as much as possible.
Note
If the fact that some resources are accessible account-wide is a problem, it can be an option to create a completely separate acount using the Organizations feature of AWS. The procedure described below is not affected whether a separate account is created or an existing account is used to create the VPC.
In order to perform the following steps, the logged in user account needs to have permissions to
- create an SSH key pair,
- create a VPC,
- create IAM roles, policies, and instance profiles,
- create subnets, security groups, routing tables, and a gateway,
- create instances and attach an instance profile to an instance.
Please perform the following steps after logging in to the AWS console.
Marketplace Subscription#
In order to use the Amazon AMIs of the used Linux distribution (Rocky Linux 8) you need to subscribe to the marketplace offer of Rocky Linux. This is free of charge and requires only to accept the license agreement of Rocky Linux displayed when clicking on the link above (click on the "Continue to subscribe" button on the page which opens).
Region Selection#
Select the region in which the Virtual Cluster should be deployed in the top right corner of the AWS console.
Note
A Virtual Cluster cannot span multiple regions on AWS. It can span multiple availability zones though. This allows to handle limited zone capacity when it comes to the availability of instances as it allows to provision cluster instances in multiple zones.
Allow to Create Spot instances (Optional)#
If the Virtual Cluster should be able to use Spot instances, the AWS account needs to allow the spot.amazonaws.com service to create EC2 instances. Please follow the steps in the AWS documentation if you want to use Spot instances in the Virtual Cluster.
Create/Upload Key Pair#
Select the EC2 service from the top menu and then select "Key Pairs" from the side bar. You can either choose to create a new SSH key pair and share the private key later on with the Solutions Architect/Operator team of Schrödinger or, if you've been provided with a public SSH key by a Schrödinger Solutions Architect/Operator already, you can choose to upload this key instead. Assign a name to the new key pair which makes it easy to remember what the purpose of the key pair is.
Apply CloudFormation Template#
In this step the environment and the permissions will be applied using a CloudFormation template. Select CloudFormation from the Services menu at the top of the console and click on "Create Stack".
Upload the CloudFormation template file you got from Schrödinger as a new template. You can either inspect the resources and permissions this template will create by clicking on "View in Designer" or just click "Next".
Select a name for the stack and for the Virtual Cluster itself on the next
page. All created resources will be using the specified name and the naming
policy is typically <vc-name>-<resource-name>, e.g., the frontend subnet gets
the name <vc-name>-frontend. The CloudFormation template allows to use existing
parts of the infrastructure shown in the system diagram
as discussed in the following sections.
System Name and SSH Key#
The system name specified is used to identify all instances which are part of the Virtual Cluster. This is especicially important if the Virtual Cluster shares network resources with other instances. The SSH key which was created or uploaded as part of the previous steps can be specified from the dropdown list.
External Network Access#
The Virtual Cluster exposes a single instance (frontend instance) for external access. Access can happen through an internet gateway and a public IP address whereas access permissions can be restricted using a security group. A single IP address or address range can be specified for a newly created security group, or the ID of an existing security group can be specified which will be attached to the frontend instance during the deployment of the cluster itself. Additionally, there is the option to allocate elastic IP addresses for the case of access via an internet gateway. If access happens through a VPN gateway for example these options can be set to false.
VPC#
The Virtual Cluster subnets need to be part of a VPC. Either an existing VPC can be used by pointing to it using the VPC ID or a new VPC can be created by specifying the CIDR range of the VPC.
Note
The specified CIDR range is ignored if a VPC ID is specified. The same logic is used for the other resources in the rest of this document as well, i.e., an existing resource is used if an ID is specified and the options for the properties of the resource (e.g., CIDR range for subnets) is ignored (even if specified).
Gateway for Egress Traffic#
An internet or VPN gateway for the egress traffic can be specified in case of an existing VPC (if a new VPC is created an internet gateway is created and attached to the new VPC automatically). If no gateway ID is specified for an existing VPC an internet gateway is created and attached to the existing VPC automatically. If the frontend network (see Subnets section below) exists it is assumed that the routing for egress traffic has been configured for this network such that the system can reach out to the internet.
System Location/Availability Zones#
The Virtual Cluster can span across multiple availability zones in a single region which is relevant when instance availability is a concern. A system which is allowed to create instances in different zones can typically grow to a larger size (in terms of the number of compute instances) as it can check whether an instance type is available in another zone when there is insufficient capacity in one of the zones. Select an availability zone from the dropdown list.
Subnets#
The Virtual Cluster needs at least one subnet which contains all its instances. However, the standard system contains at least two distinct subnets (frontend and backend) which separates the instances which can be accessed from the external network and the instances which just allow access from within the Virtual Cluster. Either non-overlapping CIDR ranges for new subnets or subnet IDs of existing subnets can be specified.
Note
If subnet IDs are specified the number of these subnet IDs needs to match the number of availability zones selected in the section above.
Click "Next". You may want to enable the termination protection in the "Stack creation options" section to prevent accidental deletion attempts on the stack.
Click "Next". Confirm the deployment of IAM roles and policies displayed in the last step of the wizard and click on "Submit" to create the Virtual Cluster environment. Creation of the stack will need a few minutes to complete.
Note
The IAM roles are required to assign the permissions to build and manage the Virtual Cluster infrastructure to the orchestration instance.
After the stack has been created successfully, it will show the IP address of the orchestrator instance and the frontend instance. This information is required by the Solutions Architect/Operator team of Schrödinger to access the orchestrator instance and deploy the rest of the Virtual Cluster infrastructure.
