Deploy Ubuntu Desktop Jammy Jellyfish on AWS EC2
You need a desktop quick and disposable. You need extra resources for a task where you depend on a GUI or a set of programs. Or you need a disposable desktop because you want to take “incognito mode” into the next level.
Whatever your reason may be, this how-to will take you straight to a running Jammy Jellyfish Ubuntu Desktop in the cloud with no extra configurations needed.
As an addition, and just for showing-off how Ubuntu is a first citizen on Arm architectures on cloud I’m going to use the AWS Graviton instances (which also happen to be way cheaper!)
What you’ll need
- An AWS Account
- Basic knowledge of aws EC2, security groups and VPC (i.e. Make sure the instance can download packages from the internet and you can connect to the port 3389 from outside)
- An RDP client (I will use Remmina since I’m on Ubuntu already)
What you’ll learn
How to install Ubuntu Desktop on top of an Ubuntu server and configure it to remotely access the ubuntu-session.
Step 1: Create the security group
We need to create a security group to configure how we want to connect to the server. We need to open the port 3389 for connecting with RDP. If we want to include SSH remote access, we need to also add port 22.
Go to the EC2 console and click on Security Groups under Network & Security in the left-hand menu. Click the button Create security group in the upper-right corner. In the next screen, enter a name, a description and the VPC where the machine will be running.
The rest can be left with the default values.
Click on Create security group button.
Step 2: Create the instance
Go to the EC2 console and select Launch instance. In the next screen you can add a name to your server and select Ubuntu from the Operating list options.
Select Ubuntu server 22.04 LTS and the desired architecture (ARM is cheaper than AMD64 but some of the apps you may want to install after may not be available.
Select the instance type. The minimal recommended configuration is 2vCPU and 4GiB of RAM (bare minimal because video rendering will be done by the CPU too).
Select your key-pair or create a new one. This will only be needed if you want to connect through SSH into the machine (useful for troubleshooting if something doesn’t work).
Next step, under Network settings, select the security group we created on step 1.
Finally, go to the Advanced details and expand the section. This is where the magic happens.
Scroll to the bottom and enter the following into the user data box.
The supplied script has the Ubuntu user password in plain text
This is a bad practice, but it is used to show full automation and remove any manual steps.
#!/bin/bash DEBIAN_FRONTEND=noninteractive apt-get update && apt-get upgrade -y apt-get install -y ubuntu-desktop^ apt-get install -y xrdp usermod -a -G ssl-cert xrdp systemctl restart xrdp # make sure TCP port 3389 is open and accessible #create a script in /usr/local/bin/ubuntu-session cat > /usr/local/bin/ubuntu-session <<- "EOF" #!/bin/sh export GNOME_SHELL_SESSION_MODE=ubuntu export DESKTOP_SESSION=ubuntu-xorg export XDG_SESSION_DESKTOP=ubuntu-xorg export XDG_CURRENT_DESKTOP=ubuntu:GNOME exec /usr/bin/gnome-session --session=ubuntu EOF chmod +x /usr/local/bin/ubuntu-session update-alternatives --install /usr/bin/x-session-manager x-session-manager /usr/local/bin/ubuntu-session 60 # Finally setting up a passwd for the ubuntu user (bad practice to add passwds here) echo -e "my_password\nmy_password\n" | passwd ubuntu
Step 3: Wait and connect.
Now we need to wait for the machine allocation and for the scripts to install and configure everything. As a reference, this example took me 15 minutes to be up and running on an 2vCPU, 4GiB ram ARM A1 machine, while the same test took me 7 minutes only in a similar configuration on AMD64 machine (t2.medium). Interesting.
To connect, open your RDP client (as Remmina if you are on Ubuntu), insert the IP, and voilà.
Resolution and color depth are configured in the client.
That’s all Folks!
In less than 15 minutes you can get an Ubuntu Desktop machine ready to use with no need to do anything manual. The real use case should be to have persistent storage such as EBS, EFS or S3 attached to have some way to keep your files so you could delete the machine instead of just shutting it down (how cool is that?).
You could also generate your own AMI, by using EC2 Image Builder, a manual snapshot or packer to speed up the deployment process (you can also avoid having to log-in to the web console if using awscli).
It is interesting to see also that launching Ubuntu desktop on Arm instances just works. While you will see slightly less performance, you also will notice that the cost is significantly less.
Other further points to consider if you want to use this for “more than just fun”:
- Don’t hard code user passwords in cloud scripts (they will end up in plain text inside the machine)
- There is no persistence. Once you destroy the machine, all get erased. Consider mounting an S3 bucket on a specific folder for saving your files.
- You may want to either change ports to avoid using the standard ones, or adding your IP range for incoming connections
- Everything can be automated to even not having to log-in into the AWS Web Console.
- You should create your own self-signed certificate for securing the connection.