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.
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 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.
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.
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.
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 (webservices@amazon.com) 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.
Get Programming Amazon Web Services now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
