Expiring services versus non-expiring 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 examples of services with an expiration date. Notice that you must begin paying for the service 12 months after you begin using it.

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, to run the software, you must have the required service, which does come with an expiration date (see Figure 2-2). In this case, the Amazon Mobile Analytics depend on Amazon S3 (listed near the bottom of the description). You have access to 100 million events per month free, but in order to export your event data, you need S3, which has an expiration date. Notice also that after you reach the 100 million events level, you must pay an additional amount for each additional million events, so free doesn’t necessarily remain free.

You also have access to some products that are both free and have no expiration date. These nonexpiring offers still have limitations (and often caveats), 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 an example of this kind of service. Notice that the service is free, doesn’t expire, and doesn’t depend on a service that expires. However, you must pay for both throughput and storage, so a cost is still involved.

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.

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 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 (see Figure 2-4 for details). 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.

Hosting the services locally

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-5, you see that the AWS Storage Gateway comes with specific hardware, instance, and storage requirements. (Only the hardware requirements appear in Figure 2-5.) The important thing to understand is that the cloud presents limits that you must consider during any planning stage.

After you make certain that you can run your intended configuration, you can begin to consider the advantages and disadvantages of working in the cloud. For example, when hosting the service in the cloud, you get automatic scaling as needed, and Amazon performs many of the administrative tasks for you. Chapter 1 discusses many of the advantages of the cloud. However, for a realistic perspective, you must offset these advantages with awareness of the disadvantages, such as:

• Potential for lower application speed
• Need to maintain a reliable Internet connection
• Loss of flexibility
• Vendors going out of business

Even though basic hardware needs become less expensive, you do need to consider additional expenses in the form of redundancies. Most organizations find that the hardware costs of moving to the cloud are substantially less than maintaining a full IT department, which is why they make the move. However, you must make the move with the understanding that you have other matters to consider when you do.

Hosting the services in the cloud

When hosting services locally, you need to provide all the required infrastructure, which can get expensive. AWS does provide guidance on the minimum requirements for hosting a service locally. For example, Figure 2-5 shows the requirements for the AWS Storage Gateway.

A good rule of thumb when hosting services locally is to view any vendor-supplied requirements as minimums. If you don’t plan to load the service heavily, these minimums usually work. However, when you click the Optimizing Gateway Performance link, the first suggestion you see is to add resources to your gateway, as shown in Figure 2-6. Planning for too much capacity is better than for not enough, but getting the configuration as close as possible to what you need will always help financially.

Not all the services will work locally, but you may be surprised to find that many do. The issue is one of defining precisely how you plan to use a given service and the trade-offs that you’re willing to make. For example, when hosting a service locally, you may find it hard to provide the same level of connectivity that you could provide to third parties when hosting the same service in the cloud.

Defining a good development environment

After you know about the resources required for AWS and have accounted for the basics of your setup, you need to consider your development environment. The first issue you must consider is one of language. AWS doesn’t care what IDE you use (although the choice of IDE determines which features you have available for remote access), but it does care about language. You must verify that AWS supports the language of your choice for the service you want to access. For example, Figure 2-7 shows the choices for Simple Queue Service (SQS).

You can create a deployment environment using EC2. The tutorial at http://docs.aws.amazon.com/cli/latest/userguide/tutorial-ec2-ubuntu.html describes how to perform this task. The main advantage of this approach is that you can theoretically develop AWS applications from anywhere because development no longer requires a local system with specific resources. However, this approach is most definitely not free, and it means that you must have a reliable Internet connection from wherever you want to perform development tasks — which is not a problem at work, but possibly an issue at home. The cloud-based development approach uses the AWS Command Line Interface (CLI), which is a tool you begin using in the “Installing the Command Line Interface Software” section of Chapter 5.

The main reason to use a localized development environment is that you retain access to local resources and the code libraries that your organization currently relies on to perform development tasks. This option also has an advantage in reliability because you don’t rely on a remote connection to use it. If your Internet connection goes down, you can continue developing code (but testing isn’t possible until the connection is restored). When using this option, you do need additional bandwidth — at least for testing purposes and permissions for the AWS access through the organization’s firewall.

You aren’t limited to just two options when working with AWS. For example, you could use a local development environment but place your code on S3. The use of cloud-based data storage means that you can have localized setups in several locations (so that you retain access to local resources) and still gain advantages of cloud-based development, such as having access to your code from any location where you have a development environment configured. The tutorial at http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/chapter-devenv.html is also interesting because it tells you how to configure your development environment to use Elastic Beanstalk for project, source control, and repository use. As with a localized development environment, you still need required permissions for Internet access and enough bandwidth to handle the increase in data requests to make this option work well. In fact, the bandwidth requirements are higher than a local configuration, and the development environment must work with remote resources.

Choosing the correct development environment isn’t easy, as described by articles such as the one at https://blog.rackspace.com/the-case-for-using-aws-for-development-environments. In many cases, the choice becomes one of personal preference and organizational requirements. For example, using a cloud-based development solution might not be an option when dealing with sensitive development tasks; security needs could trump other wants.

Obtaining an account

Before you can really do anything other than plan, you need an account. Discovering the wonders of AWS is a hands-on activity, so you really do want to work with it online. Consequently, this book assumes that you’ve gone through the free sign-up process described in the following steps:

1. Navigate your browser to http://aws.amazon.com/.

   The main Amazon Web Services page appears.

2. Click Create a Free Account.

   Unless you already signed into Amazon, you see a Sign In or Create an AWS Account dialog box like the one shown in Figure 2-8. If you already have an Amazon account and want that account associated with AWS, you can sign in using your Amazon account. Otherwise, you need to create a new account.

3. Sign into an account or create a new one as required.

   The Contact Information page appears, as shown in Figure 2-9. Notice that different pages exist for company and personal accounts.

4. Supply the required company or personal contact information. Read and accept the customer agreement.

5. Click Create Account and Continue when you complete the form.

   You see the Payment Information page, shown in Figure 2-10. Be aware that Amazon will bill you for any usage in excess of the free-tier level. Click View Full Offer Details if you have any questions about the level of support provided before you enter your credit or debit card information.

6. Provide the required credit or debit card information, supply the address information needed, and then click Continue.

   You see the Identify Verification page, shown in Figure 2-11. Amazon performs an automated call to verify your identity. You see a PIN provided onscreen. During the call, you say or type this PIN into your telephone keypad. The screen automatically changes as you perform each step of the identification process.

7. Click Continue to Select Your Support Plan.

   You see a listing of support plans, as shown in Figure 2-12. Only the Basic plan is included as part of the free tier. If you want to obtain additional support, you must pay a monthly fee for it. This is an example of one of the potential charges that you might pay for the free-tier service. You have the following support-plan options:

   • Basic: Free support that Amazon offers as part of the free-tier support. Amazon doesn’t offer any support through this option. You must instead rely on community support, which usually works fine for experimentation.
   • Developer: Support that comes at $29/month at the time of this writing. A single developer (or other organizational representative) can contact the Support Center and expect a response within 12 to 24 hours. However, if you’re serious about developing an application and anticipate using third-party products, you really need to consider the Business level.
   • Business: Support that comes at $100/month at the time of this writing. A business user may contact the Support Center by phone and expect a one-hour response to urgent support problems as well as obtain help with third-party products.
   • Enterprise: Support that comes at $15,000/month. This is the level of support provided for organizations that use AWS for mission-critical applications. The response time is only 15 minutes, and Amazon is willing to provide all sorts of technical help. Of course, the price is a tad on the steep side.

8. Choose a support plan and click Continue.

   Normally, you see a welcome page like the one shown in Figure 2-13. (However, you might also see a message saying that Amazon is setting up your account and will send you emails when your account is ready. Wait for the emails to arrive if you see these messages.) At this point, you can sign into the console and try a few tasks. The ten-minute tutorials are helpful in getting you started. The next section of the chapter gives you help getting started as well.

Getting access keys

You use access keys with API calls to allow the call to proceed. Without an access key, AWS rejects any requests made. Access keys come in two parts: public and secret. To safeguard your setup, the private key must remain private. During the creation process, you download both keys. Make sure you keep them in a safe place.

The following steps help you create the access keys you need to work with the examples in the book. You can’t use any of the coded examples without an access key. The access key found in the book’s code is an example key. It won’t return a usable result.

1. Navigate your browser to https://console.aws.amazon.com/iam/.

   You see the Identity and Access Management (IAM) Console, shown in Figure 2-14.

2. Click Groups in the Navigation pane.

   You see an option for creating a new group, as shown in Figure 2-15.

3. Click Create New Group.

   AWS asks you to provide a group name.

4. Type a group name (the book uses Developers) and click Next Step.

   AWS asks you to attach a policy to the group, as shown in Figure 2-16. Normally you choose a policy that provides just the level of access required by that group. For the purposes of this book, because you spend time exploring much of AWS, you choose a more encompassing policy. However, when working in a production environment, remember to use policies carefully.

5. Select AdministratorAccess and click Next Step.

   You see a Review page where you can review the group’s settings.

6. Click Create Group.

   The group is now ready for use. You see it in the Groups tab of the IAM Console. However, you still need to create a user account to obtain the required access keys.

7. Select Users in the Navigation pane.

   You see the Users tab of the IAM Console, shown in Figure 2-17.

8. Click Add User.

   AWS asks you to provide a username, as shown in Figure 2-18. Note that this page also provides the means for configuring the kind of user access.

9. Type a username (the book uses John).

   AWS lets you add more than one user at a time, as long as both users have the same requirements.

10. Select both Access Type entries.

    You require both access types to interact with the examples in the book.

11. Configure the password settings for the user you want to create.

    The default is to autogenerate a password and then require the user to change it during the next login. Because you want to create an account for yourself, you can save time by creating a custom password and deselecting the option that requires the user to change the password during the next login.

12. Click Next: Permissions.

    AWS asks you to set permission for the user, as shown in Figure 2-19.

13. Choose Add User to Group and then select the Developers entry in the list of groups shown.

14. Click Next: Review.

    AWS shows you the configuration for your user.

15. Click Create User.

    AWS generates the user and the user’s access key.

16. Click Download .CSV.

    Your browser downloads a .CSV file containing the public and secret keys for your user account. Keep these keys in a safe location.

You can create new access keys as needed by accessing the user’s entry on the Users tab of the IAM Console and choosing the Security Credentials tab of the individual user’s account. The Security Credentials tab contains a Create Access Key in the Access Keys area. Every time you create a new access key, you have the option of downloading a .CSV file containing the public and secret keys. To remove an existing key, click the X next to that key’s entry on the Security Credentials tab.