In my last post, I explained that I was going to demonstrate taking my example SaaS – in this case, a trouble ticket system-to its world of potential customers by building it on Amazon Web Services. Once you’ve got a business plan and made some basic design decisions, it’s time to take it to the next level.

Because I am automating the build of my IaaS layer on AWS, I don’t have to buy a room full of computers just in case demand goes through the roof for my trouble-ticket service. Now is where I use AWS CloudFormation templates to help me get it off the ground.

Rent the IaaS layer from AWS

As with all computer products, this support system is built upon layers of IT. The bedrock hardware and networking will be rented from AWS. The OS will be Amazon’s OS, based on Redhat’s Enterprise Linux.

A minimum viable prototype

It’s a bargain basement approach to creating a minimum viable prototype. This OS does not come with a licensing charge. The system is built using Drupal and modules.

When an artist draws a picture, they start with an outline to get the big picture in place, and then move onto the small details. I don’t want to go straight into a heavy development stage to make my new system. I want a basic support system that proves all the big pieces work together. I can add Drupal and a handful of modules to AWS to sketch out my big picture.

Use AWS CloudFormation to do the hard work

CloudFormation is a service that builds a system for you. It can create instances, add a load balancer, monitoring, and so on. CloudFormation is only available in the US. This actually isn’t as limiting as it sounds — you can still create resources in eu-west-1 zone, sa-east-1 and elsewhere.

As with all AWS services, there are a few ways to make CloudFormation do its thing.

  • Developers can use the API (Application Programming Interface).
  • System administrators can use CLI (Command Line Interface) scripts.
  • Normal people can use the web interface.

The CloudFormation engine gets most of its instructions from a template file. The sample I use here has some blanks to be filled in. The web interface displays a form for the user to complete.

The template and values instruct the AWS CFN elves to build many things.

  • Build two EC2 machines in different AZs (Availability Zones). These are basic machines, not ones with added Drupal source. That comes later.
  • Put a load balancer in front of these machines.
  • Build one RDS database and make it more resilient by spreading it across AZs.
  • Add CloudWatch detailed monitoring for these resources.
  • Install a load of applications from a few repositories.
  • Copy a bunch of files.
  • Run a script as the root user, to finish off the installation.

Sample templates

AWS provide sample templates to get new customers going without having to wade through the documentation. I’m going to use one of the open source templates that fire up popular applications like the Joomla CMS, the Redmine project management tool, and a working LAMP stack. Each one of these has three versions:

  • a version where everything runs on a single box,
  • the application gets its own virtual machine and the database is moved to RDS (Relational Database Service), Amazon’s database PaaS
  • a high-availability version where the app is scaled out to ??? VMs and the database is on RDS

Create a key-pair.

If you have already created an EC2 virtual machine, you already have a key pair and can skip this part.

  1. Open the AWS console. A list of Amazon Web Services appears.
  2. Navigate to the Key Pairs page. EC2 Dashboard > Key Pairs.
  3. Create a key pair. Type in a name, Amazon generates the public and private keys, and hands over a text file containing the private key. The text looks a bit like this: many lines of Base64 encoded binary data.









  4. Save the file somewhere safe. You will need it later, when you use SSH to log into your virtual machine. I saved mine as “aws-privkey-for-planetlarg.pem”.
  5. Close the AWS console.

Make some configuration decisions.

The template has some place-holders for values. A Specify Parameters form will ask you to fill in the gaps. Use values that work for you.

  1. Choose some values.
    • SiteName – a label for the Drupal site. You don’t have to choose a web site domain name, but it’s a good idea.
    • WebServerCapacity – how many VMs to start (i.e., how big to scale out)
    • DBUsername – database authentication name
    • MultiAZDatabase – false to cheaper and riskier, true for pricier and safer ??
    • DBClass – One of the DBInstanceClass values, from tiny (db.t1.micro to huge (db.m2.4xlarge)
    • SiteEMail – The e-mail address of the site administrator (you)
    • DBAllocatedStorage – storage size in GB
    • InstanceType – EC2 machine size, from tiny (t1.micro) to huge (hs1.8xlarge).
    • DBPassword – database authentication password
    • SiteAdmin – drupal administrator authentication name
    • SitePassword drupal administrator authentication password
    • DBName – database label
    • KeyName – Your security key pair label. If you haven’t got one, you must create one.
  2. Copy all this information for future reference. It is useful to your developers and administrators.

You are now part of the way through the process and have hardly touched the online resources. This is a sign of a well separated design phase.