Uncannier Software

It's not enough to just be uncanny

Tomcat in AWS – Part 1 – EC2 Base AMI

This article is the start of a series covering how to create a Tomcat server in AWS EC2.

I recently went through the process of migrating a Java web application to a Tomcat server in Amazon Web Services. It wasn’t diabolically difficult, but it was long and involved. In sharing this series, I hope to make the process easier for someone else.

In this series, I create the server with a MySQL (MariaDB) database, and with an Apache Web Server front-end. This gives an all-in-one server, suitable for Java application sites with modest traffic. I use Ubuntu 18.04 LTS as the base AMI, but the instructions are easily adapted to pretty much any Linux distribution. Likewise adaptable to most relational databases. I assume you already have an AWS account.

The parts in the series are as follows:

  1. EC2 Base AMI: Launching a virgin instance in EC2.
  2. Apache Web Server: Installing Apache HTTP Server as a front-end to Tomcat.
  3. Tomcat Installation: Installation and security hardening of Tomcat.
  4. MySQL (MariaDB): Installation and configuration of MariaDB on the same server as Tomcat, and integration with Tomcat.
  5. HTTPS/SSL: Using Lets Encrypt & Certbot to support HTTPS/SSL.

Strategy for Tomcat in AWS

AWS provides numerous ways to get your Java applications running using a Tomcat server:

  1. EC2: Create your own server from scratch, using a virgin Linux AMI.
  2. EC2: Use a marketplace AMI like Bitnami Tomcat.
  3. Elastic Beanstalk and RDS: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/java-tomcat-platform.html

There’s no right or wrong way, but in this series I cover the first option. It’s my preference because I want to understand what’s under the hood. I also have this aversion to checking into Amazon’s Hotel California.

You can check out any time you like, but you can never leave!

Eagles “Hotel California” 1977

Launching an EC2 Instance

This will be straightforward if you’ve done pretty much anything of consequence in AWS before. If not, Amazon has excellent documentation. Here I focus on a few specifics.

Choose AMI

You could select pretty much any Linux AMI. I have a slavish and probably irrational devotion to Ubuntu, so I’ve gone for Ubuntu 18.04 LTS Server.

Choose Instance Type

The instance type you need will depend heavily on the nature of your site. In my experience, a t2.micro is sufficient to serve a site with tens of thousands of users per day. YMMV.

Configure Instance, Add Storage & Tags

The settings you want will be very specific to your needs. In my case, I accepted all configuration defaults except that I elected to Enable termination protection. And I selected 30GB of general purpose storage because it’s the free tier limit.

Configure Security Group

Only three inbound ports need to be open. 22 is purely for you to manage the site; you should consider to limit access to this port to your IP address. You only need 443 if you want to support HTTPS. However, if you think you only want to support HTTP, then I recommend you think again: https://developers.google.com/web/fundamentals/security/encrypt-in-transit/why-https

As we’ll see later, 80 is only needed to allow for redirection from HTTP to HTTPS.


You can now review and launch your EC2 instance. In attempting to launch, AWS will require a key-pair to be associated with the instance to allow for management over SSH.


You can now see the running instance. Note that the Public IP address is dynamic; if you terminate and re-start the instance, it will have a new IP address.

Elastic IP

An Elastic IP address is a way of reserving an IP address that never changes. In my unhumble opinion, I think it’s the exact opposite of what the name implies, so I think Amazon got that name wrong. Nonetheless, if you want your server to always have the same Public IP address, you should create an Elastic IP address.

EC2 -> NETWORK & SECURITY -> Elastic IPs and click Allocate New Address.

Click through and allocate a new address. With the Elastic IP created, it can now be named and associated with the running instance.

At this point, the new instance Public IP address is changed to the Elastic IP. You have a virgin Ubuntu 18.04 LTS server at a known and fixed Public IP address.

SSH Management

The previously-saved PEM private key can be used to SSH in as follows (substituting the correct Public IP address):

ssh -i foorbarcom.pem ubuntu@

Route 53

It’s likely you want a domain name for your server. I won’t cover this in detail as there aren’t many things to customize, and Amazon’s documentation is good. There are three major parts to the process:

  1. Register a domain.
  2. Created a hosted zone.
  3. Create the appropriate records in the hosted zone so that your Public IP address is mapped to the domain name.

Tagged ,

Leave a Reply

Your email address will not be published. Required fields are marked *