ElastiCache Redis : How to Backup & Launch from RDB Snapshots ?

ElastiCache Redis is a powerful KV store offering both in-memory and persistent store for Key Values.When we persist data in ElastiCache Redis, it is obvious that we need to constantly backup Redis to recover the data during failures. By default there is no option to easily create the snapshot from the running ElastiCache Redis cluster. We need to install Redis on Self Managed EC2 node and point it to ElastiCache Redis Master for the snapshot process. This post explains about the step by step method for Redis cluster snapshot creation.

Redis Snapshot Architecture :

• ElastiCache cluster with master redis node of size cache.m1.large in AZ1 and Replication group with one read replica node of size cache.m1.large in AZ2
• Self managed Redis installed on EC2 for snapshots on AZ1

Stage 1: Creating a Snapshot for ElastiCache redis Persistent store.

Step 1) Launch an EC2 instance on the same Availability zone where the ElastiCache Redis master node runs. 
If the Redis Snapshot EC2 node is temporary (or) replication/Backup performance is very critical then keep the Redis Snapshot node in the same AZ as the ElastiCache Redis Master Node.  
If Redis Snapshot node is going to permanently run and high availability of the backup mechanism is very critical, run this on different AZ from master redis node. 

Step 2)Download and install the Redis software on your newly launched EC2 instance. Make sure the Redis snapshot ec2 version and ElastiCache Redis Master version are compatible.

$ wget http://redis.googlecode.com/files/redis-2.6.4.tar.gz $ tar xzf redis-2.6.4.tar.gz $ cd redis-2.6.4 $ make

Step 3)Start the Redis Server on the newly launched EC2 instance. It will be listening on the port 6379

# src/redis-server  [1513] 10 Jan 10:25:45.083 * Max number of open files set to 10032  [1513] 10 Jan 10:25:45.085 # Server started, Redis version 2.6.4

Step 4)Open another terminal window and connect locally to the Redis Snapshot EC2 instance 

# src/redis-cli -h localhost -p 6379  redis localhost:6379>

Step 5)To synchronize the data between the local Redis Snapshot EC2 instance and the ElastiCache Redis master use the following command in the Redis Snapshot EC2. 

SLAVEOF redissnapshot.qcdze2.0001.usw2.cache.amazonaws.com 6379

where "redissnapshot.qcdze2.0001.usw2.cache.amazonaws.com 6379" is the endpoint of the ElastiCache Master Redis node.

Bringing a Additional Redis EC2 node for snapshots into the infrastructure is not ideal. It adds extra cost and manual labor effort to setup, automate and manage this Redis Snapshot EC2. I hope AWS ElastiCache team will release a mechanism where we can easily take the snapshots from the ElastiCache Cluster itself. 

Note: Before this step ensure that security group permissions are opened between the Redis Snapshot EC2 and ElastiCache Redis Cluster.

Step 6)Once the synchronization is done between Redis Snapshot node and ElastiCache Redis Master, you can take snapshot using the command BGSAVE or SAVE in the snapshot EC2 Node. The snapshot file named "dump.rdb" is created in the disk.

Step 7) You can optionally detach it from the ElastiCache cluster by using the command on redis-cli  “SLAVEOF NO ONE”. This step is recommended if your redis cluster size is few GB's and you are backing up persistent data once/4 times a day, as you can save costs by not unnecessarily running your Redis snapshot EC2 instance for 24 hours and automatically bring it up whenever needed.

We conducted a small test to check whether all the above steps are successfully reflected. 

We pumped the ElastiCache Redis cluster with 1.8GB of Data spanning few hundred millions of KV data with each record in few <KB size. We observed the time taken to sync the data is about ~5 minutes on m1.large capacity in same AZ deployment. 

• If your Redis is heavily used it is better to use Higher EC2 capacities for the ElastiCache Cluster and Snapshot node. Bigger the nodes, better the NW/IO and lesser the replication lag. 
• If you are running a small cluster with few GB's then creating the Redis Snapshot Node on demand will save costs. If your cluster is big, data is critical and backup frequencies are less, then run Snapshot EC2 node continuously for better performance.

The replication action with timing is detailed below:

[1595] 10 Jan 11:03:06.676 # Server started, Redis version 2.6.4  [1595] 10 Jan 11:03:06.676 * The server is now ready to accept connections on port 6379  [1595] 10 Jan 11:03:18.018 * SLAVE OF redissnapshot.qcdze2.0001.usw2.cache.amazonaws.com:6379 enabled (user request)  [1595] 10 Jan 11:03:18.779 * Connecting to MASTER...  [1595] 10 Jan 11:03:18.975 * MASTER <-> SLAVE sync started  [1595] 10 Jan 11:03:18.975 * Non blocking connect for SYNC fired the event.  [1595] 10 Jan 11:03:18.977 * Master replied to PING, replication can continue...  [1595] 10 Jan 11:06:03.949 * MASTER <-> SLAVE sync: receiving 1943998490 bytes from master  [1595] 10 Jan 11:08:13.348 * MASTER <-> SLAVE sync: Loading DB in memory  [1595] 10 Jan 11:09:37.430 * MASTER <-> SLAVE sync: Finished with success  [1595] 10 Jan 11:09:37.441 * 100 changes in 300 seconds. Saving...  [1595] 10 Jan 11:09:39.970 * Background saving started by pid 1635  [1595] 10 Jan 11:16:44.860 # User requested shutdown...  [1595] 10 Jan 11:16:44.860 * Saving the final RDB snapshot before exiting.  [1595] 10 Jan 11:19:10.270 * DB saved on disk  [1595] 10 Jan 11:19:10.270 # Redis is now ready to exit, bye bye...

Test whether the same key values are synced between Master Redis Node in ElastiCache Cluster and Redis Snapshot EC2. The below steps illustrate the same: 

# src/redis-cli -h redissnapshot.qcdze2.0001.usw2.cache.amazonaws.com -p 6379  redis redissnapshot.qcdze2.0001.usw2.cache.amazonaws.com:6379> get 100sent  "1001234567890123456789012345678901234567890abcdefghijklmopqrstuvwxyz" redis redissnapshot.qcdze2.0001.usw2.cache.amazonaws.com:6379> get 10sent  "101234567890123456789012345678901234567890abcdefghijklmopqrstuvwxyz"

Important Observation:
Always sync the Redis Snapshot EC2 node with the ElastiCache Redis master node and not with the read slave in the redis replication group. Following error will be displayed when trying to sync with the slave. 

#Connecting to MASTER... #MASTER <-> SLAVE sync started #Non blocking connect for SYNC fired the event. #Master replied to PING, replication can continue... # MASTER aborted replication with an error: ERR Can't SYNC with a slave

We tried the above approach to check whether we can reduce the workload on Redis Master node and take the backups from Slave redis Nodes. As AWS as rightly named it is " Redis Read Replica Nodes" and you cannot use it for snapshot replication. 

Stage 2: Launching ElastiCache Redis Cluster from the existing Snapshot taken above.

Step 1) Import the data to the S3 bucket (redisaws) and assign open/download permission for the email id aws-scs-s3-readonly@amazon.com. Note : The aws-scs-s3-readonly account is used exclusively for customers uploading Redis snapshot data from Amazon S3.

Step 2) Launch a new ElastiCache Redis cluster from the "dump.rdb" snapshot taken in the earlier stage 1 - step 6 from Redis Snapshot node. Lets understand what is RDB in detail.

• RDB is a very compact single file point in time representation of your Redis data and are perfect for backups. Being a single compact file it can be transferred to alternate AZ and AWS regions quite fast and is ideal during outages/DR. RDB also allows faster restarts of Redis Master with big datasets in new ElastiCache Clusters nodes. Both these points helps us achieve better RPO and RTO during DR scenario using RDB. 
• RDB needs to fork() often in order to persist on disk using a child process. Fork() can be time consuming if the dataset is big, and may result in Redis Master to stop serving clients for some millisecond or even for one second if the dataset is very big and the CPU performance is not great. Also since the Redis Snapshot instance in this architecture is not used for accepting reads/writes and it is primarily used only for replication + snapshot it will add again minimal load on the master node during replication. Factor the ElastiCache Master Redis node capacity taking both these parameters into consideration.
• Note : RDB is NOT good if you need to minimize the chance of data loss in case Redis Master stops working. It is suggested to use RDB model with ElastiCache Redis Replication group cluster for better Availability and integrity.

Step 3) Once the ElastiCache cluster is launched. Connect to the cluster endpoint and check for the existence of the same key values tested in the dump.

src/redis-cli -h rds.qcdze2.0001.usw2.cache.amazonaws.com -p 6379  redis rds.qcdze2.0001.usw2.cache.amazonaws.com:6379> get 10sent  "101234567890123456789012345678901234567890abcdefghijklmopqrstuvwxyz"  redis rds.qcdze2.0001.usw2.cache.amazonaws.com:6379> get 100sent  "1001234567890123456789012345678901234567890abcdefghijklmopqrstuvwxyz"

You can notice from the above that the key values are same and the new ElastiCache node was created properly with original data.


This post was co authored with Senthil 8K Miles

Amazon ELB Multi region migration checklist

Amazon Elastic Load Balancing has a Amazon EC2 Regional scope. It needs to be migrated to alternate Amazon EC2 region in event of DR or during new migration setup . I am sharing my experience in this post as few checklists/areas that needs to be taken care during this Amazon ELB migration to alternate EC2 region:

1. Amazon ELB automatically distributes incoming application traffic across multiple Amazon EC2 instances in Multiple Availability Zones. Amazon EC2 regions have different levels of AZ's, US-East EC2 region has 5 AZ's and Singapore has 2 AZ's. When you are migrating the ELB make sure your configuration matches the levels of target Amazon EC2 region Availability zones .
2. When Amazon ELB is created on target Amazon EC2 region, the ELB endpoint will be different from the source one. This has to be re configured on your Route 53 and other thick clients during migration.
3. Since the ELB end point is different, if you had raised any pre-warming request to AWS support , please raise it again for the target region with new ELB end point. This is valid in use cases where you are moving the traffic from primary region to target region in event of outage. 
4. SSL certificates associated on the old Elastic Load Balancing service (source regions) need to be re configured to the new Elastic Load Balancing service in the Target region.
5. Security Groups are region specific and has to be migrated/recreated in the target region. Make sure the security groups of ELB in target region matches the source region
6. Amazon ELB is not an isolated service and usually it will be used in production with Amazon EC2, Auto Scaling group and Cloud Watch Alarms. In addition there will be health checks, time outs, thresholds etc configured specifically for an application in Amazon ELB. You need to ensure that all these items associated with Amazon ELB are transferred target region for proper functioning of the application. Using Amazon CloudFormation templates for creating infrastructure properties will surely help and ease the efforts involved during such ELB migration.
7. To load balance your EC2 instances launched in default VPC, you have to create your load balancers within your default VPC. When you create a load balancer within default VPC, Elastic Load Balancing automatically creates a security group by defining the ports specified for the load balancer to be opened. Default VPC is currently not available in US-East. In case your Source region is US-West and you are planning your DR or migration with Target region as US-East, you need to be aware of this situation. 
8. In case Amazon ELB and Internal ELB are used inside Amazon VPC, you should ensure that the IP address ranges being used in source and target regions matches and aligns properly, so that routing and load balancing continues to work after migration. 

Other Multi Region Migration articles:

Security Groups - Multi Region Migration checklist

Elastic IP - Multi region Migration checklist, tips , best practices

EC2 AMI Copy - Multi Region Migration

MySQL Amazon EC2 Cross region Master-Slave Replication using SSL

Amazon EBS Snapshot copying- Performance, Tips and How to

Amazon EC2 AMI Copy Feature - Performance, Tips and How To

MySQL Amazon EC2 Cross region Master-Slave Replication using SSL

Well before Amazon VPC many customers had deployed their application on AWS classic public cloud. Still many customers are inside AWS classic cloud and have not yet migrated to Amazon VPC. Keeping them in mind, This post explains the configuration steps to enable database replication between MySQL Master and Slave on two different Amazon EC2 regions (on AWS Classic cloud). 

• MySQL Master is setup in US-East and Slave is setup in APAC. 
• Asynchronous replication is enabled between Master and Slave over internet. To protect the data in transit SSL encryption is used. It is bad idea to transfer DB data over Amazon EC2 regions in clear without protection.
• This technique is useful only for MySQL on EC2 on AWS Classic cloud. For replication of MySQL in Amazon VPC, i recommend VPN between the Amazon EC2 regions. To know more about this refer Amazon VPC- VPN article.
• Since the Data is encrypted and decrypted by MySQL EC2 instances itself, it adds additional burden on EC2 instance. Usually MySQL is Memory/IO intensive, but adding SSL enc/dec function to it, we need to power it with more CPU as well. 
• It is recommended to use larger EC2 instances with very good CPU,Memory and IO bandwidth for such cases. CPU is needed for SSL, Memory for MySQL and IO for replication over internet. Thought it is possible to set this up with small/medium EC2, it will not give good performance.
• Elastic IP is a mandatory recommendation for this replication process
• This setup is usually good for warm Disaster Recovery mode, Where MySQL is already up to date on alternate Amazon EC2 region and you need to bring the Web/App/LB tier using CloudFormation templates in event of primary location outage.
• RDS MySQL does not offer Inter Region DR currently, so it is out of scope of this article.
• Since the replication happens over internet between MySQL Master and Slave EC2, X amount(secs -->mins) of replication lag is natural. Please factor this in your RPO/RTO objectives of your DR.
• This is not a replacement to backup policy because an accidentally issued DELETE command will also be carried out on the slave; but replication can help protect against hardware failures though. So it is recommended to take regular backups and snapshots and transfer them to alternate amazon ec2 region.For copying AMI,Snapshots and Security groups to Alternate Amazon EC2 region, Refer articles:

1. http://harish11g.blogspot.com/2013/05/Amazon-EC2-AMI-Copy-between-Multiple-Amazon-EC2-regions-performance-tips-how-to.html
2. http://harish11g.blogspot.com/2013/05/Amazon-EBS-Snapshot-Copy-Multiple-Amazon-EC2-regions-howto-performance-tips-practices.html
3. http://harish11g.blogspot.com/2013/05/Migrating-Amazon-Security-groups-to-Multi-Region-setup.html

Step 1: Setup MySQL Master/Slave replication with SSL:

Launch Two RHEL 64 bit EC2 instance with MySQL Database on EC2. The entire setup is done inside AWS Classic cloud and not Amazon VPC. Master MySQL Amazon EC2 is in US-EAST (Master US-East-1a) region and One Amazon EC2 for MySQL Slave in Asia Pacific Singapore region (ap-southeast-1a)

Install MySQL on EC2 and configure some basic steps:

yum update

rpm -Uvh http://mirror.nus.edu.sg/Fedora/epel/6/x86_64/epel-release-6-7.noarch.rpm

rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-6.rpm

yum --enablerepo=remi -y install mysql mysql-server

service mysqld start

chkconfig --levels 235 mysqld on

mkdir /var/log/mysql

touch /var/log/mysql/mysql-bin.log

chown -R mysql:mysql /var/log/mysql

Disable IPTABLES:

service iptables stop

service ip6tables stop

Step 2: Configure the following steps on MySQL Master & Slave Amazon EC2's 

To enable SSL, Edit the my.cnf file

vim /etc/my.cnf

Add a line with the word ssl to the [mysqld] section:  

ssl

Restart MySQL

mysql> show variables like '%ssl%';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| have_openssl  | YES   |

| have_ssl      | YES   |

| ssl_ca        |       |

| ssl_capath    |       |

| ssl_cert      |       |

| ssl_cipher    |       |

| ssl_key       |       |

+---------------+-------+

7 rows in set (0.00 sec)

The response shows that now SSL is enabled.

Step 3: Steps to create SSL Certificates on MySQL EC2

Now we need to create the CA, server and client certificates that we need for the SSL connections.  Create these certificates in the directory /etc/mysql/certs/

Step 3.1 : On MySQL Master EC2 - create CA/Server/Client Certificate:

mkdir -p /etc/mysql/certs

cd /etc/mysql/certs

openssl genrsa 2048 > ca-key.pem

openssl req -new -x509 -nodes -days 1000 -key ca-key.pem > ca-cert.pem

Create server certificate:

openssl req -newkey rsa:2048 -days 1000 -nodes -keyout server-key.pem > server-req.pem

openssl x509 -req -in server-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > server-cert.pem

Create client certificate:

openssl req -newkey rsa:2048 -days 1000 -nodes -keyout client-key.pem > client-req.pem

openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem

NOTE: Please use “Unique Common Names” while creating certificates otherwise SSL will not work.

Add the following ssl-ca, ssl-cert, and ssl-key lines under [mysqld] section in /etc/my.cnf

[mysqld]

ssl
ssl-ca=/etc/mysql/certs/ca-cert.pem
ssl-cert=/etc/mysql/certs/server-cert.pem
ssl-key=/etc/mysql/certs/server-key.pem

Restart MySQL to load the SSL configurations

Step 3.2 : Configure the certificates on MySQL Slave EC2 

Copy the following certificate files to MySQL Slave EC2 using SCP to a new directory called /etc/mysql/certs/

ca-cert.pem,client-cert.pem,client-key.pem,server-cert.pem,server-key.pem

Add the following in MySQL Slave /etc/my.cnf under [mysqld]

[mysqld]

ssl

ssl-ca=/etc/mysql/certs/ca-cert.pem

ssl-cert=/etc/mysql/certs/client-cert.pem

ssl-key=/etc/mysql/certs/client-key.pem

Restart MySQL to load the SSL configuration.

Step 4: Configuring replication settings

Step 4.1: On MySQL Master Amazon EC2 

Add the following in /etc/my.cnf under [mysqld]

server_id               = 1

log_bin                 = /var/log/mysql/mysql-bin.log

#log_bin_index      = /var/log/mysql/mysql-bin.log.index

max_binlog_size    = 100M

expire_logs_days   = 1

Restart MySQL

service mysqld restart

Execute the following in MySQL EC2 shell terminal of Master:     

Note:The REQUIRE SSL string is optional; if you leave it out, slave_user will be allowed to connect through encrypted and also non encrypted connections. If you use REQUIRE SSL, then only encrypted connections are allowed between slave and master.

$ mysql -u root -p

mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave_user1'@'%' IDENTIFIED BY 'mysql_mslave1' REQUIRE SSL;

mysql> FLUSH PRIVILEGES;

mysql> FLUSH TABLES WITH READ LOCK;

mysql> show master status;

+------------------+----------+--------------+------------------+

| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |

+------------------+----------+--------------+------------------+

| mysql-bin.000001 |      335  |              |                  |

+------------------+----------+--------------+------------------+

1 row in set (0.00 sec)

mysql> unlock tables;

mysql> quit

            

Step 4.2:On MySQL Slave EC2 instance :

Edit the my.cnf file

server-id                = 2

log_bin                  = /var/log/mysql/mysql-bin.log

#log_bin_index       = /var/log/mysql/mysql-bin.log.index

max_binlog_size     = 100M

expire_logs_days    = 1

Restart MySQL

service mysqld restart

Execute the following in MySQL EC2 shell terminal of Slave:     

mysql -u root -p

mysql> slave stop;

mysql> CHANGE MASTER TO MASTER_HOST='ec2-IP-49.compute-1.amazonaws.com', MASTER_USER='slave_user1', MASTER_PASSWORD='mysql_mslave1', MASTER_LOG_FILE='mysql-bin.000004', MASTER_LOG_POS=107,MASTER_SSL=1, MASTER_SSL_CA = '/etc/mysql/certs/ca-cert.pem', MASTER_SSL_CERT = '/etc/mysql/certs/client-cert.pem', MASTER_SSL_KEY = '/etc/mysql/certs/client-key.pem';

mysql> START SLAVE;

mysql> SHOW SLAVE STATUS;

 ** there should be a message "Waiting for master to send event"

mysql>quit

Step 5: Test for MySQL AWS Inter Region Replication between MySQL Master & Slave:

On MySQL Master EC2 instance

mysql -u root -pmysql> create database rep_test_US_APAC;

mysql> use rep_test_US_APAC;

mysql> CREATE TABLE t1(c1 int,c2 var(100));

Note: In MySQL Slave Amazon EC2 in APAC You can find that database and the table is created. Next step, Insert data into the Master MySQL EC2, in few seconds/minutes replication lag check you can find that the data is present on the slave. Stop inserting the records to master and verify that the slave is up to date, Check the replication lag status on Slave EC2 by applying following command

$ mysql -u root -p -e 'show slave status\G' | grep -i seconds

Seconds_Behind_Master: 0

SHOW SLAVE STATUS \G

Note:It is important that both Slave_IO_Running and Slave_SQL_Running have the value "Yes" in the output (otherwise something went wrong, and you should check your configuration steps again and /var/log/syslog to find out about any errors); as you're using an SSL connection now, you should also find values in the fields Master_SSL_Allowed, Master_SSL_CA_File, Master_SSL_Cert, and Master_SSL_Key.

This article was co-authored with ramprasad. His linkedin handle in.linkedin.com/in/ramprasadguru

Part 15: Amazon EBS Snapshot copying- Performance, Tips and How to

Most of us know that EBS snapshots have Amazon EC2 regional scope. In case you are planning to geographically expand or have data backed up on different Amazon EC2 region at regular intervals to minimize data loss and recovery time, you can use EBS snapshot copy feature for this purpose.
The copied EBS snapshot behaves the same like regular snapshots, i.e. it can be used to create new EBS volumes which can then be attached to an EC2 instance in the destination region. Since the data is moved across regions in the form of snapshots, you will be charged only for the data transferred to copy the snapshot and to store the copied snapshot at the destination region.
Following table illustrates the time it takes to copy EBS snapshots from Different Source and Destination Amazon EC2 regions. Data used was a 50 GB compressed file stored on an Amazon EBS volume which was taken as a snapshot and transferred using EBS snapshot copy process. Since AWS keeps improving their infrastructure every day, the time taken may vary in coming months/years. But the figures mentioned below can used as an reference to plan your Recovery time objectives and migrations:

EBS Snapshot Copy vs Amazon EC2 Regions matrix :

Source Region	Destination region	File Size/Type/EBS Volume Size	Time Taken
USA-East	Singapore	50 GB Compressed file in EBS Volume	1 hr 24 min
USA-East	US-West (Oregon)	50 GB Compressed file in EBS Volume	24 min
USA-East	Europe (Ireland)	50 GB Compressed file in EBS Volume	45 min

Points to note about Amazon EBS snapshot copy :

• Unlike the create snapshot operation, which is incremental in nature, the EBS copy snapshot operation copies all of the bytes in the snapshot every time. It is recommended to use EBS snapshot copy once a day for larger databases with Multi region DR to reduce data transfer cost . Only if your DB is not a large one and you need better RTO/RPO + your IT budget can afford it, you should reduce this frequency accordingly.
• EBS Snapshots now support incremental copies. The first time you copy an EBS snapshot of a volume to a particular Region, all of the data will be copied.  The second and subsequent copies of snapshots from the same volume to the same destination region will be incremental: only the data that has changed since the last copy will be transferred. As a result, the snapshot will transfer less data and complete more quickly than before. It is recommended to use EBS snapshot copy across regions frequently if you need better RTO/RPO for DR.  . To know more about how EBS Snapshots works ? click here
• Currently RDS Snapshot copy is not supported. In case you need to move data to different Amazon Region you will have to manage it through RDS dumps or implement your own programmatic replication in EC2+RDS, till AWS RDS team introduces this feature. Customers who need their database to be backed up on different region on AWS, adopt some of the following strategies, let us take MySQL as the DB and explore some techniques:
• Configure MySQL on Amazon EC2 with Master-Slave mode. Freeze the file system and take regular snapshots in the source region. Copy these snapshots once or twice a day depending upon the RTO/RPO and DR budget using EBS Snapshot copy feature.
• Configure MySQL on Amazon EC2 with Master-Slave mode. Have another Slave running on Destination region which asynchronously updates records from the Master in source region. Secure the entire transport using SSL or VPN between regions.

How to do Amazon EBS Snapshot Copy between Regions ?


In this article we are copying a Snapshot from US-EAST Virginia Region to Asia Pacific Singapore Region.
EBS Snapshot Copy is done using the AWS Management Console:
1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/
2. In the Navigation pane click Snapshots under the Amazon Elastic Block Store menu

3. In the EBS Snapshot page select the Snapshot ID you need to copy to destination region and Click Copy.

4. In the Copy snapshot dialog box you need to fill the following details.
Destination Region: The region where you want to copy the snapshot. In this case it is Asia Pacific (Singapore)
Description: Description of the snapshot. By default you can retain the one as shown in the below figure.

5. Click Yes, Copy button and the following dialog screen will be shown as confirmation.

6. To check the progress of the snapshot copy go to the Destination region (Asia Pacific Singapore in this case) and check the progress in the EBS snapshot page.

EBS Article Series (continued..)

Part 1: Understanding Amazon Elastic Block Store
Part 2: Understanding Standard EBS Volumes
Part 3: Understanding EBS PIOPS Volumes
Part 4: Understanding EBS-Optimized Instances
Part 5: Understanding Latency in EBS
Part 7: 10% of your provisioned IOPS 99.9% of the time
Part 8: Performance Tuning - Pre Warming the EBS volume
Part 9: Performance Tuning - EBS Striping
Part 10: Performance Tuning - IO Block Size
Part 11: Understanding Amazon EBS Snapshots
Part 12: Securing Amazon EBS volumes - EBS Encryption using SecureCloud (new)
Part 13: Amazon EBS Security Best practices and tips
Part 14: How proper EBS Snapshot Retention strategy can save costs (new)
Part 15: Amazon EBS Snapshot copying- How-to, Performance and Tips (new)

Architecting Disaster Recovery Infrastructure using Amazon Web Services (AWS )

This article on Architecting Disaster Recovery infrastructure using Amazon Web Services (AWS ) explores the following blue prints
Blue print1 : Both Main Web Site and Disaster Recovery site in Amazon Web Services (AWS) Cloud
Blue print2 : Main site in Amazon Web Services cloud and Disaster recovery site in Traditional customer data center
Blue print3 : Main site in customer data center and Disaster recovery site in AWS cloudThe architecture blueprints also contains advanced elements like Managed DNS servers , Load Balancers and Data replicators into consideration. AWS technologies like AWS Security groups ,AWS Elastic Load balancing,AWS Auto Scaling,AWS EC2 ,AWS EBS ,AWS CloudWatch ,AWS Elastic IP and AWS S3 are used in the setup.

Blue print 1 : Both Main Site and Disaster recovery site in AWS Cloud is suitable for web applications , Mobile apps , social and gaming websites with Unpredictable load bursts and growing load requirements

Blue print 2 : Main site in AWS cloud and Disaster recovery site in Traditional customer data center is suitable for  Enterprise web applications, online Media companies etc which already have 1-2 years contracts signed with traditional data centers. Their load is fairly predictable or “On & Off” workload bursts
Blue print3 : Main site in customer data center and Disaster recovery site in AWS cloud Suitable for applications with predictable loads , SMB companies which already have 1-2 years contracts signed with traditional data centers.

Disaster Recovery using Amazon Web Services (AWS)