How to wing the AWS certification exam

Solutions-Architect-AssociateA couple of months ago I undertook the AWS Solutions Architect – Associate exam, which I happily passed with a score of 85%.

Whilst I went into the exam with almost no preparation at all, I’ve put together some tips to best prepare yourself for the exam.

Please note that when you undertake the exam, you are required to sign a NDA, which forbids from sharing the contents of the exam questions.

The certification

AWS certifications are valid for 2 years and are useful to test your knowledge, boost your credentials plus you get access to the Amazon Partner Network.

The next level after the associate exam is the professional exam. The main differences between the two are:

Associate level

  • Technical
  • Troubleshooting
  • Common scenarios

Professional level

  • Much more in depth
  • Complex scenarios

The associate exam duration is 80 minutes whilst the professional exam duration is 170 minutes. You are taken into the exam room (you cannot bring anything at all with you), the questions are multiple choice answers. At the end of the exam you are immediately presented with the results on the screen.

If you fail the exam, you’ll have to wait 30 days before you can try again.


The exam questions are well written, it’s not an exam you can just study for and hope you’ll pass, you need to have plenty of hands-on experience. And the best experience you can get is in your profession.

Some tips to best prepare yourself:

  • Practice, practice, practice !
  • Read the AWS whitepapers
  • Sign up to Cloud Academy
  • Sign up to Linux Academy
  • Read the AWS sample questions and discuss them with your colleagues
  • Undertake the AWS practice exam (US$20: 20 questions / 30 mins)

The Cloud and Linux Academy have online courses and lots of quizzes. The official AWS practice exam is useful to undertake last, as you get to practice against the timer which can be distracting.

AWS Solutions Architect – Associate exam

The scoring breakdown for the exam I undertook is:

  • Designing highly available, cost efficient, fault tolerant, scalable systems
  • Implementation / Deployment
  • Security
  • Troubleshooting

My impressions are:

  • It’s not easy, the questions are well composed for architects with plenty of experience
  • Some of the questions are long
  • AWS states one year minimum experience, it depends on how many services you got exposed to. Despite having used AWS extensively since 2008, I found some of the questions challenging
  • The questions are high level but also hands-on
  • The exam covers most main AWS services

For the AWS services covered, whilst each exam is different, they cover roughly:

  • 75% EC2 (ELB, EBS, AMI…), VPC & IAM roles
  • 25% other services (Storage Gateway, Route53, Cloudfront, SQS, RDS, SES, DynamoDB etc…)

Exam gotchas

For the Solutions Architect exam:

  • There are architecture for totally different scenarios
  • Be mindful of cost effective vs best design vs default architecture
  • Security is very important to know (e.g. Security groups, /ACL statefull/stateless etc…)
  • Good practice with troubleshooting is essential
  • Some questions can be easily answered by elimination

Exam tips

Some tips for when you sit the exam:

  • Prepare yourself
  • Take your time
  • Don’t pay too much attention to the timer
  • Read the questions carefully
  • Mark questions for review later
  • Leave at least 10/15 mins to review

The AWS certification exam can be stressful but also fun, good luck if you intend to undertake it !


Infrastructure automation with Terraform

TerraformHashicorp, the cool guys behind Vagrant, Packer etc… have done it again and come up with a simple way build, modify and destroy cloud infrastructure. It is pure infrastructure as code which can be version controlled. But the best part is that it can work with many cloud platforms: AWS, Google Cloud, Digital Ocean, Heroku etc…

Getting Started

The official documentation can be found here.

Download the zip package from for your O.S., extract and move the executables into your /usr/local/bin (or add the folder to your $PATH).

Verify the installation by executing:

We‘ll be using AWS as the provider so you will need an access and secret key for your user account.

Create a folder where you will keep all your .tf files. You can later add this folder to Git version control.

Provisioning a single EC2 instance

Create a file called with the following:

The provider line tells Terraform to use the aws provider using the keys and region provided.
The aws_instance instructs Terraform to create a instance with a tag “web” using the Ubuntu 14.04 LTS AMI.

Before building infrastructure Terraform can give you a preview of the changes it will apply to the infrastructure:

It uses Git diff syntaxing to show the differences with the current state of the infrastructure. Currently there’s no aws_instance tagged “web”, hence the line has a +
The “computed” values means that they will be known after the resource has been created.

To apply the .tf run:

Now check the AWS console, the instance has successfully been created !

The terraform.tfstate file which gets generated is very important as it contains the current state of the infrastructure in AWS. For this reason it’s important to version control it in Git if others are working on the infrastructure (not at the same time).

Modifying the infrastructure

Edit your file and changed the instance type from t2.micro to t2.small then check what will change:

The value for instance_type has changed, apply the new changes:

Instead of stopping the existing instance and upscaling it, it destroys and creates a new aws_instance resource.

Destroying the infrastructure

Before destroying infrastructure, Terraform needs to generate a destroy plan which lists the resources to destroy, to a file here named destroy.tplan

The line with – confirms that the aws_instance resource tagged web will be destroyed, lets apply the destruction plan:

Provisioning a multi-tiered VPC

Terraform can provision a VPC using most of the available VPC resources, except a few which are missing.

Here we provision 2 web instances, 2 application instances and a nat instance within 2 tier VPC, complete with appropriate security groups, load balancers, route tables, internet gateway, elastic IP etc…

The gist can be viewed here.


Terraform is an use out of the box ready and easy to use tool to build infrastructure using only a couple of lines. It’s very practical to quickly build a proof of concept infrastructure.

Using the AWS provider, it’s missing a couple of resources such as Elastic Network Interfaces, Access Control Lists, Security Groups egress rules, VPC DHCP options plus it does not support User Data (it can only execute remote ssh commands). However at version 0.2.1 it is still very early days and no doubt we will be seeing lots of improvements to Terraform in the future !

Auto Scaling with Amazon EC2

Autoscaling on AWSAuto scaling is the Amazon Web Service which can automatically run additional (or terminate) EC2 instances depending on, for example, the amount of web traffic.

A typical scenario in a web environment would be: if you have a minimum of 2 web servers up and running 24h a day across two availability zones (for high availability) and you get an unexpected increase in traffic when you launch a new product or service. The web servers may struggle to keep up with the increase in traffic and start to slow down.

The solution is to provision additional servers (EC2 instances) and distribute the incoming web requests across the group of web servers.

Later,  say at night,  when the traffic decreases, some EC2 instances can be removed as they would no longer be needed and you’d be back to running the website on the minimum of 2 servers again.

Auto scaling also helps to lower costs of running servers as you only pay for what you use, per hour.


This guide describes how to achieve basic auto scaling. In this example, we’ll be configuring auto scaling within a Virtual Private Cloud (VPC), and each of the two availability zones (here ap-southeast-2a and ap-southeast-2b) are configured with a subnet which can be reached from the internet (in the public VLAN). We’re assuming the VPC connected with an internet gateway and the subnets, have already been created

We’ll be using the new AWS command line interface, to install it:

Then we need to configure the CLI with the AWS credentials and default region:

Run complete to populate the available commands when you press tab:

The AWS CLI reference guide is accessible at

We also need the Elastic Load Balancer API, which isn’t yet covered by the CLI:

Export the Java and ELB home directories plus your credentials and default ELB region URL (or place them in your home directory .bachrc file):

To achieve auto scaling, we’ll be completing in the following order:

  1. Creating an Amazon Machine Image (AMI)
  2. Creating an Elastic Load Balancer (ELB)
  3. Creating a Simple Notification Service (SNS) topic
  4. Creating Auto Scaling configurations and policies
  5. Creating CloudWatch metric alarms

Amazon Machine Image Creation

We need to build our own custom AMI which is configured with the web server (apache2, nginx etc…) and contains the website code.

Create the image when the instance is running or stopped, provide a name and description:

An AMI identifier is returned which we’ll need later.

Elastic Load Balancer Creation

Create the load balancer which will forward http traffic to the instances on the 2 public subnets. Specify a security group for the ELB which will allow http protocol traffic on port 80 for both ingress and egress:

The DNS_NAME is returned which is the A record endpoint of the website (you can then add an Alias to the A record in Route53 DNS for

Note the name of the load balancer you created which we’ll need later.

Simple Notification Service

It’s good to get notifications by email whenever an auto scaling event has been triggered, this is achievable by creating an SNS topic:

It returns an Amazon Resource Name (ARN) which we need to subscribe to next with an email address:

Check the inbox and confirm the subscription.

Note the ARN which we’ll need later as well.

Auto Scaling Creation

There are several steps for creating and configuring the auto scaling.

Launch Configuration

First we need to configure a launch configuration where you specify the AMI (created previously), the key pair name, security group(s) (which allows incoming traffic on port 80) and finally the instance type:

Auto scaling group

Next we create the auto scaling group where we specify how many EC2 instances we want running at least at any time, the maximum of EC2 instances to run, how many we wish to start with, the load balancer name (created previously), the two availability zones, the two subnets, some ELB settings and finally a tag for the instances. Here we’ll be starting with 2 instances minimum, which will also be the desired capacity and we’ll be allowing a maximum of 8 instances to be launched when there’s a lot of load on the servers:

The health check type option specified that the ELB will be determining whether an instance is healthy/online using a 60 second wait period after the instance has been launched.

As soon as the auto scaling group has been created, the desired capacity number of instances are immediately launched into the two availability zones/subnets. You can check what auto scaling actions have been executed by running:

Auto scaling notifications

We need to tell the auto scaling group to which ARN a notification must be sent whenever a scale up/down event has happened, using the ARN previously created:

Auto scaling policies

We have 2 instances running in the group, set by the desired capacity option. We need to create two policies which will be executed when we want to scale up (scaling adjustment 1) and down (-1):

Note the two ARNs which we’ll need in the next part.

The cooldown setting instructs the auto scaling group not to perform any scaling operations for 300 seconds after one is triggered. This is to prevent many scaling activities to be executed within a short timeframe.

CloudWatch Alarms Creation

The final part is to create some alarm events which will trigger the scale up and down auto scaling policies. Cloud Watch provides several metrics such as CPU utilisation, disks utilisation, network in/out etc…

Here we’ll be using the CPU utilisation metric which is a commonly used for auto scaling; a high percentage of utilisation obviously means the instance is overloaded and needs to have load taken off.

Using the policy ARN created earlier for scaling adjustment 1, create the metric alarm which will fire when the average CPU utilisation is greater than 80% twice over a period of 5 minutes:

Then create the metric for scaling adjustment -1 which will fire when the CPU utilisation is less than 80% :

Note: the Cloud Watch metrics used for auto scaling are global averages of all instances in the auto scaling group, they are not instance specific metrics (which can be viewed separately).

Testing the auto scaling

Now that we have configured auto scaling, generate some traffic on the website, using the load balancer A record (or alias) and watch the magic happen !

You will be notified by email when auto scaling events are triggered. Or you can run aws autoscaling describe-scaling-activities

Browse to the Cloud Watch interface on the console and watch the CPU Alarms states changing between ALARM and OK states for both scale up and down events.

Note that by default the metrics are refreshed every 5 minutes (it can be changed to by minute intervals) and that the cooldown period of 300 seconds will ignore any state changes after an auto scaling event.

A good way to generate traffic is to use bees with machine guns which I’ve described how to use here: /load-testing-on-ec2-using-bees-with-machine-guns/


Attempting to terminate instances directly will not stop the auto scaling. Instead you need to change the min and max size to 0 in the auto scaling group, any running instances will be terminated:

Then remove the auto scaling group and launch configurations:

Check that they have all been deleted:

The scaling policies and cloudwatch metric alarms get deleted automatically.


There are many other options available to configure auto scaling, here we’ve shown the basics using web servers. Auto scaling can be used for any kind of servers, such as application servers running inside a private VPC and using an internal load balancer to distribute the traffic from the web servers.

There are many metrics to choose from to create the policy alarms and you can also create your own ones.

Auto scaling can also be configured using a crontab policy, instead of having metrics launching extra instances, you can run additional instances at a certain time then terminate them after they have executed a batching job for example.

Finally use Cloud Formation templates to simplify auto scaling deployments.


For those who aren’t very comfortable using the API or CLI, auto scaling support has now been added to the AWS Management Console.

It is very easy to use and configure. See the official blog post at