Launching an AWS EC2 instance and then connecting to it via the Remote SSH plugin requires some cumbersome manual steps. Moreover, large parts of this process must be repeated for every machine you wish to connect from (i.e. generating SSH keys and authorising them on your instance).
This extension aims to make that experience quick and portable across machines that you already connect to AWS with.
EC2 instances are provisioned on your behalf with CloudFormation and the connection is established via AWS SSM so all you have to do is set up your AWS CLI credentials and decide what type of machine you wish to use.
The extension allows you to:
- Create remote development EC2 instances that shut down automatically when inactive
- Connect to your development instances via SSM
- Start and stop your existing EC2s
- Terminate your development environments when you no longer need them
- Select alternative AWS profiles and regions
-
Make sure you have Node.js >= 16 installed on your system
-
Make sure you have your AWS CLI credentials set up, there are various extensions that can simplify this step for you such as the offical AWS Toolkit
- Your credentials need administrative rights in order to provision infrastructure, you can reduce any possibility of interfering with your existing infrastructure by using a seperate AWS account for your remote development environment
- You can add the AdministratorAccess managed policy to your associated IAM group or user in order to allow this extension to create and terminate your development machines
-
Make sure that your AWS Account has a default VPC that your development instances can be launched in
-
(Optional) If you would like to connect to existing EC2s (not created by this extension) then you need to make sure that Session Manager is set up for them
-
Decide which GPU instance you wish to use, we'll select a
g4dn.xlargemachine type in this example -
Make sure that you have a sufficient EC2 service quota limit applied for running the instance, you'll find this under the "Amazon Elastic Compute Cloud (Amazon EC2) > Running On-Demand G and VT instances" section of the Service Quotas console
-
Decide which DLAMI you wish to use and find the corresponding image ID, we'll use Amazon Linux 2 base DLAMI in this example and search for the image ID using the AWS CLI command:
aws ec2 describe-images --region us-east-1 --owners amazon --filters 'Name=name,Values=Deep Learning Base AMI (Amazon Linux 2) Version ??.?' 'Name=state,Values=available' --query 'reverse(sort_by(Images, &CreationDate))[:1].ImageId' --output text
- Click the
+icon at the top of the extension's EC2 explorer panel, fill in each of the sections according to steps 1-3 and start the process of creating the CloudFormation stack
- The DLAMI we've selected requires a root volume size of at least 100GB
- Make sure that you enter the image ID from step 3 in the final box
-
Once the process is complete, you'll see your GPU machine appear in the instances list, connect to the instance by clicking on the "Connect in a new window" button next to the machine name
-
You can verify that the NVIDIA driver is installed and working by running the
nvidia-smicommand in the terminal of your new machine
-
Cleaning up: you can delete all the resources associated with this example by stopping the instance and clicking on the trash icon once the instance has stopped
Development machines are based on Amazon Linux machine images with docker pre-installed for compatibility with a wide range of EC2 instance types. The simplest way to customise your environment is to configure a Dev Container for your project and launch it once you're connected to the remote machine.
If you need greater control of the base machine image (e.g. to use a DLAMI with a GPU instance) then you can simply specify the optional image ID when launching your development environment.
The development environment includes a CloudWatch alarm to stop the instance if the CPU utilisation falls below a threshold for a certain period of time. The alarm name is set up as ${STACK_NAME}InactivityAlarm-Inactivity and you can adjust it within the AWS console directly to suit your needs.
You can modify the permissions granted to the instance by editing the IAM role named ${STACK_NAME}InstanceRole. Configuring access in this way removes the need to set up AWS access keys when working within the instance and any Dev Containers you run on it.