I just returned from a training trip in London and Paris; I had the privilege of meeting some really great people and had a lot of fun doing the training. Still shaking the cobwebs of jet lag out of my head though 
I often feel I learn as much from the training as my students do. On this particular trip, a few issues and points of interest were raised so I thought I would summarize a few of them in this blog.
EC2 Reserved Instance Pricing is now available for the EU region
Similar to a futures market for computing power, EC2 Reserved Instances are a great way to lock in a price; now it is available in Europe.
We are excited to announce that Amazon Elastic Compute Cloud (Amazon EC2) Reserved Instances are now available in Europe. Reserved Instances give you the option to make a low, one-time payment for each instance you want to reserve and in turn receive a significant discount on the hourly usage charge for that instance. After the one-time payment for an instance, that instance is reserved for you, and you have no further obligation; you may choose to run that instance for the discounted usage rate for the duration of your term, or if and when you do not use the instance, you will not pay usage charges on it.
Please visit http://aws.amazon.com/ec2 for more information on Reserved Instances, including pricing for the Europe Region.
VAT and tax help
Helpful tax info (including some information related to VAT) can be found here: http://aws.amazon.com/tax-help/
SQS is now available in the EU
This is really new, Simple Queue Service is now available in the EU region - http://aws.amazon.com/about-aws/whats-new/2009/04/09/announcing-amazon-sqs-wsdl-version-2009-02-01-and-amazon-sqs-in-europe/.
Handling Amazon Web Services Disputes
This is not the most pleasant thing to talk about, and I don’t think there have been any major disputes so far, but European AWS users should note section #14 in the user agreement (http://aws.amazon.com/agreement/) about how disputes are handled.
14. Disputes
14.1. Notwithstanding anything to the contrary, we may seek injunctive or other relief in any state, federal, or national court of competent jurisdiction for any actual or alleged infringement of Amazon’s or any third party’s intellectual property and/or proprietary rights. Any dispute relating in any way to your visit to the AWS Website or to products or services sold or distributed by AWS or its affiliates in which the aggregate total claim for relief sought on behalf of one or more parties exceeds $7,500 shall be adjudicated in any state or federal court in King County, Washington, and you consent to exclusive jurisdiction and venue in such courts. You further acknowledge that our rights in the Amazon Properties are of a special, unique, extraordinary character, giving them peculiar value, the loss of which cannot be readily estimated and may not be adequately compensated for in monetary damages.
14.2. Governing Law. By using the Services, you agree that the laws of the State of Washington, without regard to principles of conflicts of laws, will govern this Agreement and any dispute of any sort that might arise between you and us. The parties expressly exclude application of the United Nations Convention for the International Sale of Goods to this Agreement.
Service Level Agreements
This is not specific to Europe of course, but it came up during the training so I thought I would try and gather the various SLA information.
The SLA for EC2 can be found here http://aws.amazon.com/ec2-sla/, here are some highlights:
AWS will use commercially reasonable efforts to make Amazon EC2 available with an Annual Uptime Percentage (defined below) of at least 99.95% during the Service Year. In the event Amazon EC2 does not meet the Annual Uptime Percentage commitment, you will be eligible to receive a Service Credit…
The SLA for S3 can be found here http://aws.amazon.com/s3-sla/, again here are some highlights:
AWS will use commercially reasonable efforts to make Amazon S3 available with a Monthly Uptime Percentage (defined below) of at least 99.9% during any monthly billing cycle (the “Service Commitment”). In the event Amazon S3 does not meet the Service Commitment, you will be eligible to receive a Service Credit…
There is no SLA for SQS right now, but here are a few bits of information about security, usage, etc.
From the Amazon User Agreement:
5.4.1. Provided that you comply with the terms of this Agreement and our policies and procedures for the use of Amazon SQS, you may use Amazon SQS in connection with data owned or lawfully obtained by you (such data, to the extent to which actually used in connection with Amazon SQS, “Your Amazon SQS Content”). You acknowledge that neither we nor our licensors are responsible in any manner, and you are solely responsible, for your Amazon SQS, we will not sell or license your Amazon SQS Content and will not disclose Your Amazon SQS Content except as we may determine to be necessary or desirable to comply with the Agreement, the request of a governmental or regulatory body, subpoenas or court orders, or for other legal purposes.
5.4.2. Your use of Amazon SQS is subject to the limits specified in the most recent user documentation, including limits on the available number of queues or messages, message size, and the number of days during which a message or inactive queue can be maintained. You may not knowingly create and maintain inactive queues. We may delete, without liability of any kind, any of your Amazon SQS Content that sits in a queue or any queue that remains inactive for more than the number of days specified in the user documentation.
Some relevant SQS FAQs (http://aws.amazon.com/sqs/faqs/):
- Q: How reliably is my data stored in Amazon SQS? Amazon SQS stores all queue and message information in Amazon’s network of highly reliable, highly available data centers. All messages are stored redundantly on multiple servers and in multiple data centers, which means that no single computer or network failure renders SQS messages inaccessible.
Q: How can I secure the messages in my queues? Authentication mechanisms are provided to ensure that messages stored in Amazon SQS queues are secured against unauthorized access. Only the AWS account owners can access the queues they create.
Amazon SQS uses proven cryptographic methods to authenticate your identity, either through the use of your Access Key ID and request signature, or through the use of an X.509 certificate. For the details of how to use either of these authentication mechanisms with Amazon SQS, please see the Amazon SQS Developer Guide.
- Q: What happens if there is no activity against a queue for an extended period of time? We reserve the right to delete a queue if none of the following requests have been issued against the queue for more than 30 consecutive days: SendMessage, ReceiveMessage, DeleteMessage, GetQueueAttributes and SetQueueAttributes. You should design your application with this in mind.
Since CloudFront is based on S3, there isn’t too much more to say in terms of SLA. One interesting thing to note, if you expect to serve a lot of content:
By default, a customer’s Amazon CloudFront distributions support peak data transfer speeds of 1,000 megabits per second and peak request rates of 1,000 requests per second. If you expect more than this amount of traffic, please complete the form below. We will add more capacity to your distributions within 2 business days.
The form mentioned in the quote above can be found here http://aws.amazon.com/cloudfront-request/
SimpleDB is still in beta so there is no SLA associated with it. Not too much to note about it - one blurb in the Amazon usage rights about old data being deleted after 6 months of inactivity.
5.9.2. You must comply with the terms of the technical documentation applicable to (including the Amazon SimpleDB Developer Guide) as posted by us and updated by us from time to time on the AWS Website, including, without limitation, any limitations on the number and total size of domains, items and attributes that may be stored on the Amazon SimpleDB servers. We may delete, without liability of any kind, any of your Amazon SimpleDB Content that has not been accessed in the previous 6 months.
That’s the major small-print stuff I wanted to point out. If I missed anything please let me know.
Thanks!
Eric.
April 15th, 2009 at 3:17 am
[...] Originally posted here: Learn Amazon Web Services » Blog Archive » Lessons learned from … [...]