The first basic pattern that we will cover is the snapshot pattern. This pattern is the basis for many other patterns described throughout this book and includes the way to create an S3-backed, point-in-time snapshot of a running instance from the AWS console. To do this, we will select a running instance from the EC2 console and select the root device volume from the instance pull-up frame, which will bring up a pop-up for the volume as shown in the following screenshot:

Click the EBS ID link from the pop-up. This will bring you to the Volumes section of the AWS console with the previously selected volume in context. From here, select the Actions drop-down and select Create Snapshot as shown in the following screenshot:

You will now be prompted for a name and description, but they are optional so go ahead and click Create. The next window will give you a success prompt with a snapshot identifier. If you select the snapshot id, it will take you to the Snapshot section of...

The pattern covered here is called the stamp pattern because it covers how to replicate a bootable operating system similar to a rubber stamp of sorts. By creating an image of an operating system that is pre-configured for a purpose, it can be easily replicated by simply bringing it up when needed in the same way a stamp works by creating a template.

We will actually create a new AMI to use throughout this book from this method. The AWS Linux AMI, by default, does not allow sudo without a TTY terminal. There's a simple fix for this but it must be run every time we boot from the AWS Linux AMI unmodified. Instead, we will make this fix to their image and package it into our own AMI.

This is useful because Vagrant requires sudo to be usable for many of its features such as folder synchronization, and provisioners such as Puppet and Chef. If you were to try to run Vagrant on their base AMI, you would get an output such as:

$ vagrant up --provider aws
Bringing machine &apos...

The scale up pattern is a method that allows a server to change size and specifications dynamically, and as needed. Imagine a running web instance that does a bit of computation per request. Initially, it performs extremely well, but over time traffic becomes heavier and causes the computation time to increase. A couple of options exist to solve this problem, but all have their own benefits and issues.

One option could be to spin up a second instance (or scale outwards), but this means double the cost, as well as any maintenance required to be performed on each server. For applications in the Cloud, it is important not only to think of the cost involved in the server, but also the implied costs, such as operational. The easiest solution might be to change the specs on the current server or scaling up. A benefit of this method is that, if the processing peak can be predicted, such as the beginning of the month or the end of the month transactions, this method can be automated...

We have discussed up to this point how to scale up in resources on an instance but not how to scale out. Scaling up an instance can only help in a few limited examples, but the more important issue is how to add processing power without affecting the client or the systems interacting with our services. To do this, we will tie together a few different EC2 resources. The resource diagram, as shown, will help to visualize what we are trying to accomplish:

The general process for this pattern is:

To demonstrate this, we will first create an elastic load balancer. Browse to the Load Balancers portion of the AWS console and select Create Load Balancer as seen in the following screenshot:

At the Define Load Balancer prompt, give it a descriptive name in the Load Balancer Name text box...