AWS SLAs

The AWS services that have SLAs and the SLAs themselves can be found here:

http://aws.amazon.com/ec2/sla/

http://aws.amazon.com/route53/sla/

http://aws.amazon.com/rds/sla/

http://aws.amazon.com/s3/sla/

RDS cross region snapshots

Great news for AWS RDS users looking to provide extra DR protection to their SQL Server, Oracle and MySQL databases: http://aws.amazon.com/about-aws/whats-new/2013/10/31/announcing-point-and-click-copy-of-amazon-rds-db-snapshots-across-aws-regions/

AWS EBS PIOPS : block size and IOPS

Having spent more time in the database world than in the web development world, I am accustomed to measuring (database) performance/through put in terms of IOPS or TPS.  The web/video/image world like to use MB/sec.  Why I am saying this? Because it relates to the conversation about getting a certain level of PIOPS (based upon a 16 KB block) on AWS EBS and how this effects MB/sec.  MB/sec, I am beginning to understand, and maybe move to the 'dark side', is the ultimate measure of disk 'performance'.  

Example: A 2000 Provisioned IOPS volume can handle:

•2000 16KB read/write per second, or 1000 32KB read/write per second, or 500 64KB read/write per second 

•You will get consistent 32 MB/sec throughput (with 16KB or higher IOs)

•Perform an index creation action and sends I/O of 32K, IOPS becomes 1000, you still get 32MB/sec throughput

•On best effort, you may get up to 40 MB/sec throughput 

So, you may be better off using a 64 KB block size but your PIOPS will show up as lower but your MB/sec could be better.

AWS RDS : Changing OS time zone

This entry helps you change the database time zone: http://cloudconclave.blogspot.com/2013/08/aws-rds-timezone.html

However, it does not address changed the operating system time zone.  With RDS, the OS timezone can’t be changed (UTC, by design).  Each database engine supports different functions that query OS (for Oracle it is sysdate),   database engine, or session level parameters for timezone information . 

Here’s a quick synopsis of each DB engine’s datetime function details which identifies which calls are OS, database instance, or session based and which include timezone information or if its implied:

·         MySQL: http://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html

·         Oracle: http://docs.oracle.com/cd/B19306_01/server.102/b14225/ch4datetime.htm#g1010984

·         SQL Server: http://msdn.microsoft.com/en-us/library/ms186724.aspx

AWS RDS timezone

Changing the time zone can be found here:

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.html

Near the bottom you will find this:

Setting the Database Time Zone

You can alter the time zone of a database by running the rdsadmin_util procedure as shown in the following table. You can use any time zone name or GMT offset that is accepted by Oracle.

Oracle Method	Amazon RDS Method
alter database set time_zone = '+3:00';	exec rdsadmin.rdsadmin_util.alter_db_time_zone('+3:00');

After you alter the time zone, you must reboot the DB Instance for the change to take effect.

There are additional restrictions on setting time zones listed in the Oracle documentation.

AWS : Storing Session State

AWS SimpleDB, Memcache and DynamoDB can all be used.  DynamoDB is a good option as there is already a session provider for DynamoDB :

http://aws.typepad.com/aws/2012/09/managing-aspnet-session-state-with-dynamodb.html

For SQL Server, you can also look at session management in SQL server for persistence  and use built in .net session provider modules.

You can also manage session state using AWS RDS for SQL Server, MySQL or Oracle.

Horizontal Scaling of Oracle on AWS

Just came across this solution.
Parelastic: http://www.parelastic.com (MySQL only at this time)

I really enjoyed the 'sharding sucks' mantra.  Being an 'old school' Oracle guy, the new world answer to  database scaling is sharding...I think that is very naive.

I know of these two companies in this space as well:

Scalearc (MySQL and SQL Server)

Scalebase : http://www.scalebase.com (MySQL only at this time)

AWS Provisioned I/Os

Provisioned IOPS volumes are designed to deliver within 10% of the provisioned IOPS performance 99.9% of the time. Therefore, PIOPS are very good choice when running RDBMS systems like Oracle on EC2 or RDS.