This chapter doesn’t delve too deeply into platform specifics, but it does help you understand what you need to do to get a basic setup running.
Now that you have some idea of what you’re getting and what you need in order to get it, it’s time to get your free account. The rest of the book assumes that you have a free account to use. Going through the various procedures is the best way to build an understanding of AWS. Yes, some people can get a feeling for how things work just by reading, but doing things hands on really is better.
The chapter ends by having you perform a simple task using AWS, just to get a feel for how it works. Don’t worry: You really can’t mess up the account. If you do make an unfortunate choice, starting over is easy enough. Nothing will get damaged by the exercise in this chapter – it’s totally safe. Make sure you have some fun doing it! After all, cloud computing should be an easier and more efficient way to perform administrative tasks, and you’ll find that it truly is as the book progresses.
Amazon does provide the means for using many of its cloud services for free. In fact, you can see some of these services at http://aws.amazon.com/free/. However, as you look through the list of services, you see that the some expire, others don’t. In addition, some have limits and others don’t. Those that do have limits don’t have the same limits, so you need to watch usage carefully. It’s really quite confusing. The following sections help clarify what Amazon actually means by saying some services are free.
Expiring services versus nonexpiring services
Many of the AWS services you obtain through the free tier have expiration dates, and you need to consider this limitation when evaluating and possibly using the service to perform useful work. Figure 2-1 shows an example of a service with an expiration date. Notice that you must begin paying for the service 12 months after you begin using it.
FIGURE 2-1: Some services have an expiration date when you must begin paying for them.
In some cases, the product itself doesn’t have an expiration date, but the service on which it runs does. For example, when viewing the terms for using the free software, the software itself is indeed free. However, in order to run the software, you must have the required service, which does come with an expiration date (see Figure 2-2).
FIGURE 2-2: Software may be free, but the service on which it runs might not be.
You also have access to some products that are both free and have no expiration date. These nonexpiring offers still have limitations, but you don’t have to worry about using those products within the limits for however long you want (or until Amazon changes the terms). Figure 2-3 shows examples of these kinds of services.
FIGURE 2-3: A few services don’t come with expiration dates.
Knowing the terms under which you use a service is essential. The free period for services with an expiration date goes all too quickly, and you may suddenly find yourself paying for something that you thought remained free for a longer time frame. Given that Amazon can change the terms of usage at any time, you need to keep checking the terms of service for the services that you use. A service that lacks an expiration date today may have an expiration date tomorrow.
The material in this book works on several different platforms, including Windows, Linux, and Mac OS X. However, presenting screenshots of every platform you can use with AWS isn’t practical because the book would end up filled with pictures rather than content. For this reason, the screenshots you see in the book are from a Windows 7 system using the Firefox browser, where appropriate. Depending on the operating system, browser, and other software you use, you may not see precisely the same screenshots on your system. In looking at the graphics, you should compare content rather than precise appearance. Any differences in appearance are normal, and you don’t need to worry about them.
Considering the usage limits
Look again at Figures 2-1 through 2-3. Note that all these products have some sort of usage limit attached to them – even the free software – because of the software’s reliance on an underlying service. (Some software relies on more than one service, so you must also consider this need.) For example, you can use Amazon Elastic Compute Cloud (EC2) for 750 hours per month as either a Linux or Windows setup. A 31-day month contains 744 hours, so you really don’t have much leeway if you want to use the EC2 service continuously.
The description then provides you with an example of usage. Amazon bases the usage terms on instances. Consequently, you have access to a single Linux or single Windows setup. If you wanted to work with both Linux and Windows, you would need two instances and could use them for only 15 days and 15 hours each month. In short, you need to exercise care in how you set up and configure the services to ensure that you don’t exceed the usage limits.
The free, nonexpiring services also have limits. For example, when working with Amazon DynamoDB, you have access to 25GB of storage, 25 units of read capacity, and 25 units of write capacity. Theoretically, this is enough capacity to handle 200 million requests each month. However, whether you can actually use all that capacity depends on the size of the requests and how you interact with the service. You could easily run out of storage capacity long before you run out of request capacity when working with larger files, such as graphics. Again, you need to watch all the limits carefully or you could find yourself paying for a service that you thought was free.
No matter how many services AWS offers, you still require some amount of hardware to use the services. The amount of hardware you require when working with services in the cloud is minimal because the AWS hardware does all the heavy lifting. When working with services locally, you need additional hardware because AWS is no longer doing the heavy lifting for you. Therefore, you should consider different hardware requirements depending on where you host the AWS service. The following sections help you obtain additional information about working with both cloud and local services.
Hosting the services in the cloud
Hidden in the AWS documentation is all sorts of useful information about various services. For example, AWS Storage Gateway (http://aws.amazon.com/documentation/storage-gateway/) will connect an on-premises software appliance (an application combined with just enough operating system capability to run on hardware or on a virtual machine) with cloud-based storage. In other words, you use the gateway to connect your application to the data storage it requires. It might seem as if running the gateway in the cloud would be a good idea because you wouldn’t need to invest in additional hardware. However, when you look at the requirements shown in Figure 2-4, you see that using an EC2 instance allows you to run only gateway-cached volumes and gateway-VTLs (you can’t run gateway-stored volumes). You don’t need to know what these terms mean, but you do need to understand that the cloud present limits that you must consider during any planning stage.
FIGURE 2-4: Using cloud-based services can come with limitations.
After