You are previewing Programming Amazon Web Services.

Programming Amazon Web Services

Cover of Programming Amazon Web Services by James Murty Published by O'Reilly Media, Inc.
  1. Programming Amazon Web Services
    1. SPECIAL OFFER: Upgrade this ebook with O’Reilly
    2. A Note Regarding Supplemental Files
    3. Preface
      1. What’s in This Book?
      2. Ruby and Interactive Examples
      3. Conventions Used in This Book
      4. Using Code Examples
      5. Safari® Enabled
      6. How to Contact Us
      7. Acknowledgments
    4. 1. Infrastructure in the Cloud
      1. Amazon Web Services for Infrastructure
      2. Thinking Like Amazon
      3. Reality Check
      4. Interfaces: REST and Query Versus SOAP
    5. 2. Interacting with Amazon Web Services
      1. REST-Based APIs
      2. User Authentication
      3. Performing AWS Requests
    6. 3. S3: Simple Storage Service
      1. S3 Overview
      2. Interacting with S3
      3. Buckets
      4. Objects
      5. Alternative Hostnames
      6. Access Control Lists
      7. Server Access Logging (Beta)
      8. Signed URIs
      9. Distributing Objects with BitTorrent
    7. 4. S3 Applications
      1. Share Large Files
      2. Online Backup with AWS::S3
      3. S3 Filesystem with ElasticDrive
      4. Mediated Access to S3 with JetS3t
    8. 5. EC2: Elastic Compute Cloud (Beta)
      1. EC2 Overview
      2. Interacting with EC2
      3. Keypairs
      4. Network Security by IP
      5. Finding Amazon Machine Images
      6. Controlling Instances
      7. Log In to an Instance
      8. Security Groups
      9. Managing and Sharing AMIs
      10. Console Output and Instance Reboot
    9. 6. Using EC2 Instances and Images
      1. EC2 Instances in Detail
      2. Data Management in EC2
      3. Modifying an AMI
      4. Registering an AMI
      5. Create an AMI from Scratch
    10. 7. EC2 Applications
      1. Dynamic DNS
      2. On-Demand VPN Server with OpenVPN
      3. Web Photo Album with Gallery 2
    11. 8. SQS: Simple Queue Service
      1. SQS Overview
      2. Interacting with SQS
      3. Queues
      4. Messages
      5. Queue Attributes
      6. Queue Access Control
    12. 9. SQS Applications
      1. Messaging Simulator
      2. Distributed Application Services with BOTO
      3. Automated Management of EC2 Instance Pools with Lifeguard
    13. 10. FPS: Flexible Payments Service (Beta)
      1. FPS Overview
      2. Interacting with FPS
      3. Managing Your Tokens
      4. Acquiring Third-Party Tokens
      5. Pay Now Widgets
    14. 11. FPS Transactions and Accounts
      1. Performing FPS Transactions
      2. Account Management and Information
    15. 12. FPS Advanced Topics
      1. Gatekeeper Language Guide
      2. Micropayments with FPS
      3. Building a Marketplace Application
      4. Subscribing to FPS Event Notifications
    16. 13. SimpleDB (Beta)
      1. SimpleDB Overview
      2. Interacting with SimpleDB
      3. Domains
      4. Items and Attributes
      5. Representing Data in SimpleDB
      6. Performing Queries
      7. Stock Price Database: A Mini SimpleDB Application
    17. A. AWS Resources
      1. AWS Online Resources
      2. Client Tools
      3. API Libraries
      4. Third-Party AWS Solutions
    18. B. AWS API Error Codes
      1. S3: Simple Storage Service
      2. EC2: Elastic Compute Cloud
      3. SQS: Simple Queue Service
      4. FPS: Flexible Payments Service
      5. SimpleDB
    19. Index
    20. About the Author
    21. Colophon
    22. SPECIAL OFFER: Upgrade this ebook with O’Reilly

Reality Check

It should go without saying that the infrastructure services provided by AWS will not be suitable for every circumstance or application. There are a number of things you need to consider carefully before deciding whether a full or partial move to Amazon’s virtual infrastructure is appropriate in your situation. In this section we will briefly discuss some of the common objections to making such a move and suggest counter-arguments to these objections. Our aim is not to persuade you one way or another, but to raise the issues you need to consider before you make up your own mind.

Web Services Are Dependent on a Reliable Network

The infrastructure provided by AWS is only available when you have a working Internet connection and a clear network path to the services. It is vital to have a high-speed Internet connection. If you have an intermittent or slow connection to the Internet, these services will not be a practical option. Even with a fast connection, with the fragility of networking hardware and the vagaries of Internet traffic routing, it is likely that sooner or later you will be unable to reach AWS for a brief period of time. If your application is completely dependent on AWS, this could result in downtime for your application and disruption for your customers. With these kinds of issues, it may not be possible for Amazon to help, especially if the problem is caused by network resources outside its control.

Amazon seeks to be resistant to traffic routing problems by making its services accessible multiple data center locations. These data centers are generally located in the United States, though S3 is also available from data centers located in Europe. Overall, for any web-based resource, there is always the possibility of losing connectivity, and you need to take this risk into account when planning your application.

Amazon Does Not Offer Service Level Agreements for All Its Web Services

Amazon does not provide Service Level Agreements (SLAs) for all its services. This means that it does not always define the level of service it will guarantee to AWS customers, nor does it offer compensation should the level of service fall below expectations. Of the five infrastructure services discussed in this book, only S3 has an SLA. For some organizations, the lack of a formal service agreement will make the AWS offerings too risky to accept. Even for groups or individuals without such strict requirements, the lack of an SLA can be disquieting, because Amazon generally only promises “best-effort” service. In addition to this, the AWS Terms and Conditions agreement permits the termination of AWS accounts at the sole discretion of Amazon. In legal terms, there does not seem to be a strong commitment by Amazon to providing high-quality service to AWS customers.

Looking at the AWS offering from a nonlegal perspective, Amazon’s commitment seems clear and solid. The services are continually evolving, new services are added periodically, and Amazon staff at all levels from CEO down is actively evangelizing the service and maintaining a dialogue with AWS users to improve the offering. If actions speak louder than words, the future of AWS seems assured.

Even if you are not prepared to rely completely on AWS without greater assurances, the services can still provide a worthwhile resource to use in the meantime, provided you have a backup plan in case things go awry.

AWS is still a relatively new suite of services, and Amazon has so far been willing to provide an SLA for the oldest and most stable of the services: S3. It is possible that as its services mature, and as AWS users maintain pressure on the company to do so, Amazon will eventually offer SLAs for its other services as well.

Data Security and Privacy

Developers of web applications that store, transmit, or process sensitive information need to be mindful of their responsibility to protect the security of this information and keep it private. Exposing this information to a third party, like Amazon, by using AWS infrastructure services can potentially reduce the degree of control you can maintain over the data, and transmitting the information to and from these services over the Internet can also pose a risk. In the effort to maintain the security and privacy of your data, there are three things you need to consider:

  • User authentication;

  • Secure transmission; and

  • Secure storage

Although Amazon uses industry standard mechanisms to protect data through user authentication and secure transmission, you may need to do some extra work to guarantee your data is stored securely.

AWS user authentication is provided by the access mechanism for the APIs. A client program that sends requests to an AWS service is required to authenticate itself by signing the request message. Requests are digitally signed with the credentials of the AWS account holder, proving that they could only have been generated by a client in possession of the credentials and allowing Amazon to detect if they are altered in transit. This means you can be sure that you are the only person able to access your services and the data they contain. We will discuss the request signing procedure for AWS in more detail in User Authentication” in Chapter 2.

It is easy to secure your AWS service communication channels using the standard HTTP over SSL protocol. Amazon makes the infrastructure web service APIs available over both the standard HTTP protocol and the secure version, HTTPS. By using HTTPS for all your communication with the services, you can ensure your data is automatically encrypted in transit, and by taking advantage of the endpoint authentication mechanism available in the SSL protocol, you can guarantee that you only communicate with an authentic Amazon server.

The onus is on you, as an AWS developer, to ensure the secure storage of your data in AWS. Data stored within Amazon’s infrastructure is protected by the user authentication mechanisms that control access to the information based on the client’s credentials. For highly sensitive data, you need to consider the risk that the information could be accessed by malevolent individuals who gain access to the service from inside Amazon or by stealing your AWS credentials. To properly protect sensitive information, it should be encrypted prior to being transmitted or stored, making it indecipherable even if someone manages to access the stored data. Because Amazon’s services require no particular data format, you are free to encrypt information in any way you wish, but support for doing so is not built in to the services.

Specialized Infrastructure Requirements

If you have specific infrastructure requirements for your web application that do not align with the capabilities of AWS, you may have no choice but to find an alternative infrastructure provider or build your own. To be sure AWS can meet your needs, you will have to research the capabilities and limitations of Amazon’s services, and determine whether any limitations can be overcome by rethinking your approach or designing around them.

To obtain the detailed technical information you will need to make these judgments, we encourage you to do two things. First, read the chapters in this book that discuss the technical and usage details of the services to gain an understanding of how the APIs work. Once you are in a position to ask detailed questions, you can take advantage of the considerable expertise and advice offered by the developers and Amazon staff who populate the AWS forums.

Communication Channels for Fault Reporting and Resolution

One of the main weaknesses of the AWS environment is the lack of clear channels of communication between AWS users and Amazon.

There is no direct channel for notifying Amazon when you are experiencing service faults, for escalating unresolved problems, or for obtaining information about any actions Amazon is taking to resolve the issues. Although there is an email address advertised for making technical enquiries () this has not proven to be an effective means of notifying Amazon of service faults. The only channel currently available for sending such notifications and for following up on service issues is through the Developer Connection online discussion forums.

When faults occur in the AWS, the forums are also the only place you will find any detailed information or status reports. Most of this information is generated by other service users and is not officially made available by Amazon. Amazon does not provide a publicly accessible status page that shows the current health of services or details about current issues, and its staff does not tend to proactively post details about service outages in the forums, probably because the staff prefers to spend its time fixing the issue. This is an area in which Amazon could definitely improve, and we hope it will do so as the services become more mature and its customers demand a more acceptable solutions.

The best content for your career. Discover unlimited learning on demand for around $1/day.