RDS does not give you super privileges. That is why you won’t be able to change the global time zone by simply executing:

SET GLOBAL time_zone = 'US/Pacific';


The default_time_zone db parameter is not modifiable.

In this Amazon forum thread, you can clearly see the AWS guy saying that there is no way to change the time zone of a RDS instance.

It is very important to understand that unlike Java (or other programming languages), MySQL does not store time zone in its date, datetime or timestamp datatypes. That is why it’s important that all the dates are stored in one time zone. Most people prefer to store them in their own time zone for easier calculations.

Since you cannot change the database server settings, you will have to change your application. Here are some approaches you can take to make sure that the date and time stored in your database is in your desired time zone.

1) Set time zone per database connection
When ever you create a connection, set time zone using

SET time_zone = 'US/Pacific';

This time zone will be valid only for the connection. That is why it must be done for every single connection you open. If you have a java application, you can use a wrapper around the JDBC driver to accomplish this.

Please note that MySQL allows you to specify time zone by its name (such as ‘US/Pacific’) or by the difference in hours (such as ‘-8:00′). If you are in a part of United States or any other part of the world that uses day light savings, do not use the difference of hours option for obvious reasons.

Named time zones can only be used if the time zone related tables are populated in MySQL. Thankfully they seem to be populated in RDS.

2) Use convert_tz function
You can use MySQL’s convert_tz function to convert the time zone. For example:


insert into my_table (created_date) values (convert_tz(now(), 'GMT', 'US/Pacific'));


For more information on convert_tz function visit convert_tz documentation on MySQL website

3) Set the date/time pragmatically in your application code in every query.
Thus if you have created_date column in your table, do not rely on timestamp datatype’s default value. The default value will be in UTC time zone. Set the value explicitly using application code. If you are using a prepared statement this becomes very easy. All you have to make sure is to pass a date object with appropriate time zone set in it. In order for your application to calculate correct date, you have to make sure that your application instance’s time zone is set to your time zone.

Amazon ec2 instances allow you to change their default time zones. If your web server is also deployed in ec2, I would suggest you to bundle an AMI with your time zone and use it to launch all your instances. I think most of the ubuntu public AMIs have time zone set to UTC.

Here are the easy steps:

1) Install ubuntu desktop on your server instance
By default X server, GNOME etc is not installed on your ubuntu instance. You can install it by simply executing the following commands:

export DEBIAN_FRONTEND=noninteractive
sudo -E apt-get update
sudo -E apt-get install -y ubuntu-desktop

It will install lot of stuff. So don’t get surprised if it takes 10 to 15 minutes to finish it.

2) Install FreeNX server on your server
The following commands assume that you are using ubuntu 9.10 (Karmic Koala) image.

sudo add-apt-repository ppa:freenx-team
sudo apt-get update
sudo aptitude install -y freenx
sudo /usr/lib/nx/nxsetup --install


If you are using older ubuntu versions, please visit FreeNX server installation page on ubuntu website to get the instructions for installing FreeNX server.

While executing the last command, you will get the following prompt:

It is recommended that you use the NoMachine key for
easier setup. If you answer "y", FreeNX creates a custom
KeyPair and expects you to setup your clients manually.
"N" is default and uses the NoMachine key for installation.

I would say answer ‘N’ which is the default. If you answer Y, you will have to generate keys and put them at a specific location in the client.

3) Enable password authentication on the ssh server
Edit /etc/ssh/sshd_config and set PasswordAuthentication to yes. By default password authentication is disabled.
You will need to restart ssh process by executing

sudo /etc/init.d/ssh restart

Now that you have enabled password authentication, you should make sure that the the user you are going to use for using remote desktop has a password. Cannonical’s karmic images come with ‘ubuntu’ user. This user does not have a password. You can set a password by executing

sudo passwd ubuntu

4) Install and setup NX client
Now install the NoMachineNX client on your Desktop. You can download the client form http://www.nomachine.com/download.php. You can install it by simply double clicking the downloaded file. Once you install it, click on the NX Connection wizard to setup a new connection. Fill in the values as shown below. Make sure that you put in your server address in the host field.

And that’s it! NX client will create a desktop shortcut for the server connection (Only if you choose to do so). Double click the shortcut, fill in the username (ubuntu) and the password (set in step 3) and you are in!

Auto Scaling allows you to automatically scale your Amazon EC2 capacity up or down according to conditions you define.

Simply put, it can start and stop ec2 instances based on a condition you define. This is especially important in an environment where you pay more for more capacity. Thus if a website has a defined traffic pattern such as traffic peaks every afternoon and goes down in the night, you can have autoscaling start more web servers in the afternoon and shut down unnecessary ones in the night. Isn’t that amazing?

You need to be using an elastic load balancer to configure auto scaling. Configuring autoscaling consists of three steps:
1) Create launch configuration
2) Create auto scaling group
3) Create auto scaling trigger

Create launch configuration
Launch configuration provides information about the instance to be launched. You can see that an AMI, instance type, availability zone and security groups are specified when a luanch configuration is created.

as-create-launch-config web --image-id ami-656583ff --instance-type m1.small --group ssh,web --key my-keypair


Create autoscaling group
A launch configuration is attached with an autoscaling group. The group consists of pool of instances. You can specify minimum and maximum size of the pool

as-create-auto-scaling-group myasgroup --launch-configuration web --availability-zones us-east-1a --min-size 4 --max-size 10 --cooldown 120 --load-balancers myloadbalancer


Create autoscaling trigger
The trigger defines the conditions to start or stop ec2 instances. For example:

as-create-or-update-trigger my-latency-trigger --auto-scaling-group myasgroup --dimensions "LoadBalancerName=myloadbalancer" --measure Latency --period 60 --statistic Average --lower-threshold 0.25 --upper-threshold 0.75 --breach-duration 300 --lower-breach-increment=-1 --upper-breach-increment 1 --namespace "AWS/ELB" --unit Seconds

will create a latency trigger with 0.25 as the lower threshold and 0.75 seconds as the upper threshold. If your website latency goes beyond 0.75 seconds, this trigger will be activated and hence an instance will be launched (as specified by upper breach increment). Besides latency you can use different dimensions monitored by cloudwatch such as request count, health host count and unhealthy host count.

That’s it! It’s that simple. More information about autoscaling can be read here.

In pre RDS era, you would have fired up an instance, installed MySQL yourself on it, configured an EBS volume so that the database data storage is persistent. You would have setup a cron to snapshot your EBS volume. But RDS saves the headache of managing an EBS volume and your instance separately. It offers you installed MySQL with persistent storage. It also offers you automated database backup. And setting it up is as easy as 1,2,3…

Here is what you do to setup a database using RDS:

1) Sign up for RDS by visiting http://aws.amazon.com/rds.

2) Install RDS tools on your local machine so that you can execute RDS setup commands. You can download the toolkit from the download page.
Installation of the client toolkit involves the following procedure:

a) Unzip the downloaded file into a suitable folder, say /home/vaibhav/software/rds-tools

b) Make sure that you have java 1.5 or up installed on your machine and  JAVA_HOME variable is set. If not install the latest version of java and set JAVA_HOME to the folder where java is installed.

c) Set AWS_RDS_HOME=/home/vaibhav/software/rds-tools in your .bashrc or execute the following command to set AWS_RDS_HOME for this session

export AWS_RDS_HOME=/home/vaibhav/software/rds-tools

d)Add AWS_RDS_HOME to your path by executing export PATH=$PATH:$AWS_RDS_HOME/bin

e) Rename credential-file-path.template in AWS_RDS_HOME (/home/vaibhav/software/rds-tools) to any name of your choice say credentials.txt. Set AWS_CREDENTIAS_FILE variable by executing

export AWS_CREDENTIAL_FILE=<the path of the file created above - credentials.txt

3) Now let’s create a security group before creating a database instance. This is because we would like to supply this security group while creating an instance. A security group can be created by executing

rds-create-db-security-group --db-security-group-name database  --db-security-group-description 'Default mysql database security group'

This will create a security group called database. If you want to connect to the mysql server from your local machine, you will need to add authorization to this group by executing

rds-authorize-db-security-group-ingress --db-security-group-name database -i 71.168.56.100/32

Here 71.168.56.100/32 is the ip address range of the network from which you want to access the database and 123456789012 is your Amazon AWS account number

4) Now create the database instance. The database instance can be created by executing the following command:

rds-create-db-instance --db-instance-identifier reporting --allocated-storage 5 --db-instance-class db.m1.small --engine MySQL5.1 --master-username master --master-user-password s0mePassw0rd --db-name MyFirstDb --availability-zone us-east-1a --preferred-maintenance-window Sun:12:00-Sun:16:00 --preferred-backup-window 10:00-12:00 --db-security-groups database --headers


There are few parameters that you need to understand very well before executing this command. The preferred-maintenance-window is the 4 hour time period Amazon requires to apply patches and to carry out other maintenance tasks on the database server. preferred-backup-window is the daily two hour window in which your database will be backed up. The database won’t be down in the period, but its performance could get affected because of the backup operation. Please note that both the time periods must be specified in UTC time. If you are going to access this database from an Amazon ec2 instance then choose an availability zone that is the same as the web server so that you are not charged for the bandwidth. You should change other parameters such as the database instance type, allocated storage as per your requirement. More information on these parameters can be obtained from the CLI reference page. The instance name will be reporting as specified. To find out its address, you can simply execute

rds-describe-db-instances

This command will list all the db instances with their dns names. The dns name will be something like reporting.crly0gpnhroz.us-east-1.rds.amazonaws.com. The port will also be in the output (3306). You can use this dns name and port to connect to the database using any mysql client.