AWS Cost Saving Tip 17: Add Amazon RDS Read Replica's on need basis and save costs

Many online applications are usually Read intensive in nature. Though the usage of Cache, NoSQL, CDN are becoming part of the core architecture in many such applications, still most of them are heavily dependent upon Traditional RDBMS (like MySQL, Oracle) for serving their requests.
Architects usually design their DB tier with Master + Read Slaves model to cater the read intensive needs of the application. Writes and Immediate Write + Reads are directed to Master and all other Read queries are balanced between Read Slaves. Translating this model to AWS infrastructure means, using RDS MySQL Master + Multiple Read Replica Slaves.

To know more about Load balancing Amazon RDS Read Replica's Click here

Scenario: Weekly load volatility impacts: 

Online Ticketing and Travel companies are usually prone to weekly fluctuations in their load pattern. Imagine during peak load they need five M2.4XLarge RDS MySQL Read Replica's to serve their read intensive site.

As an Infra Architect you have two options in the Elastic AWS world: 

Option 1: Run your DB tier with peak capacity all days of the week. ( May be suitable for Traditional infra environments, but a bad idea in AWS infra)

Option 2: Elastically increase the number of RDS Read Replica instances during the peak period and decrease the number of instances once the peak period is over. (AWS is built for leveraging such cases)

Number of EC2 Instances	Number of days in a week	EC2 Instance Type	Weekly($)	Monthly($)
5	7	M2.4XLarge	1860	7442
			1860	7442
2	4	M2.4XLarge	425	1701
5	3	M2.4XLarge	797	3189
			1222	4890

Cost for Option 1: Running all 5 of them for a Week costs : $1860
Cost for Option 2: Running with 2 RR normally for 4 days a week and elastically increasing to Five M2.4Xlarge during the peak days(i.e. three days a week) will cost : $1222

Savings: From the above analysis you can observe that elastically increasing/Decreasing Amazon RDS RR based on your load you can achieve ~30 % cost savings in a week for the mentioned use case.

To know more about "How Amazon Auto Scaling can save costs on your Web/App Tier ? Click here "

Scenario: Impact during Campaigns 

Imagine your online business demands big campaigns once every quarter. The campaign usually runs for 2 weeks and traffic increases 4-5X during these times. During normal period you run 1 RDS Read replica and during campaigns you need 5 RDS Read replicas. 

If the campaign is planned once a year during holiday season, companies lease hardware, but if the campaign is every quarter or more frequent it becomes irrelevant to lease-build-maintain peak capacity.

Number of EC2 Instances	Number of Months	EC2 Instance Type		Monthly($)
5	10	M2.4XLarge	All times	98877
				98877
1	10	M2.4XLarge	Other times	16479
5	2*	M2.4XLarge	During campaigns	16479
				32959

Instance Hours per day: 744

*Campaign weeks are aggregated to months

US-Oregon region - $2.215 (M2.4Xlarge RDS RR pricing as on posting)

Cost for Option 1: Running all 5 of them for a year costs :  98877 USD

Cost for Option 2: Running with 1 RR on regular weeks and elastically increasing to Five M2.4Xlarge during the peak weeks will cost : 32959 USD a year

Savings: From the above analysis you can observe that elastically increasing/Decreasing Amazon RDS RR you can achieve ~55 % cost savings in a year.

For in depth analysis on Amazon RDS Second tier Read Replica's Click here 

Other Cost Saving Tips

Cost Saving Tip 1: Amazon SQS Long Polling and Batch requests
Cost Saving Tip 2: How right search technology choice saves cost in AWS ?
Cost Saving Tip 3: Using Amazon CloudFront Price Class to minimize costs
Cost Saving Tip 4 : Right Sizing Amazon ElastiCache Cluster
Cost Saving Tip 5: How Amazon Auto Scaling can save costs ?
Cost Saving Tip 6: Amazon Auto Scaling Termination policy and savings
Cost Saving Tip 7: Use Amazon S3 Object Expiration
Cost Saving Tip 8: Use Amazon S3 Reduced Redundancy Storage  
Cost Saving Tip 9: Have efficient EBS Snapshots Retention strategy in place 
Cost Saving Tip 10: Make right choice between PIOPS vs Std EBS volumes and save costs 
Cost Saving Tip 11: How elastic thinking saves cost in Amazon EMR Clusters ? 
Cost Saving Tip 12: Add Spot Instances with Amazon EMR 
Cost Saving Tip 13: Use Amazon Glacier for archive data and save costs 
Cost Saving Tip 14: Plan your deletion in Amazon Glacier and avoid cost leakage 

Cost Saving Tip 15: Plan your Amazon Glacier Retrieval strategy and avoid cost leakage 

Cost Saving Tip 16: Periodically remove your unwanted AWS resources and save costs (new)

Exploring Amazon RDS MySQL Second Tier Read Replica

AWS recently introduced Second Tier Replica for RDS MySQL.You can use this feature to shift the load from primary master DB to the replica in first tier and prepare your application for handling extremely high level of read traffic.  In this post we are going to explore this feature in following aspects :

• Steps to configure Multi-Tiered Amazon RDS MySQL Read replicas
• Second Tier Read Replica Deployment architectures
• Important Points to note

Amazon RDS MySQL version 5.6.12 on AWS WEST region was used. 

Steps to configure Multi- Tiered Amazon RDS MySQL Read Replicas

Configuration steps for the following architecture is given in this post :

Step 1: Creating Read Replica from Master and Place at Tier 1:

To create RDS MySQL Read replica navigate to the dashboard of Amazon RDS, select the Amazon RDS MySQL Master(named "sampledb") and use the option of “Create Read Replica”. 

Name the newly created Amazon RDS Read replica as "sampledb-level1" and place it in Tier 1. The Tier 1 Amazon RDS MySQL read Replica can be created in same AZ of Master or in a different AZ for High Availability. When the Tier replica is placed in Different AZ , you should factor few extra milliseconds of latency during replication.

Explore the status from Master DB: Post successful creation of the Tier 1 Read Replica, You can see the Read Replica Id's from exploring the details of the Master DB. Illustrated in Below Screen shot :

Explore the status from Tier 1 Read Replica : When you explore the Tier 1 Read Replica details, you will find it is pointing to the to Master DB. Illustrated in Below Screen Shot :

Step 2: Creating Second Tier Read Replica from Tier 1 Read replica :
To create Second Tier Read replica navigate to the dashboard of Amazon RDS, select the Amazon RDS Tier 1 Read Replica (sampledb-leve1) as the source and use the option of “Create Read Replica”.

Name the newly created Amazon RDS Read replica as "sampledb-level2" and place it in Second Tier 2. The Second Tier -2 Amazon RDS MySQL read Replica can be created in same AZ of Tier 1/Master or in a different AZ for High Availability. 

Explore the status from Tier 2 Read Replica : When you explore the Tier 2 Read Replica details, you will find it is pointing to the to Tier 1 - sampledb-level1 as replication source. Illustrated in Below Screen Shot :

To Load Balance AWS RDS Read Replica's Refer this article : http://harish11g.blogspot.com/2013/08/Load-balancing-Amazon-RDS-MySQL-read-replica-slaves-using-HAProxy.html

Second Tier Read Replica Deployment Architectures

One of the main complexity behind Multi-Level replication is that, if Tier 1 Read Replica if not properly architected/placed, it can be a single point of failure. Imagine a case where you need 4 Read Replicas for your Master DB. You can take following approaches as illustrated below while designing your infrastructure for this requirement.

In Architecture-1, Tier-1 Read replica is a Single Point of Failure. Instead if you split Tier-1 itself into two separate fleets it offers better availability than architecture-1. Since both Tier-1 RR put replication load on Master DB , you can by pass this using Hot Standby instance. Benefits of this approach is explained below in the best practice architecture. 

Best Practice High Availability Architecture for Second Tier Read Replica:

Condition 1 - Master DB Failure : Hot Standby becomes new master and Tier-1 Read Replicas points automatically to new source
Condition 2- Tier-1 Read Replica Failure : Entire Tier-1 and Associated Tier-2 has to be recreated. The Alternate Active Fleet of Tier-1+Tier-2 will serve the requests for high availability.
Condition 3 - Tier-2 Read Replica Failure : Only the non performing Tier-2 Read Replica instance has to be recreated
Condition 4- AZ NW problem: In event AZ-3 is failed, Requests are served by alternate fleet of Tier-1+Tier-2 in another AZ(AZ-4).

Multi-AZ Hot Standby Implementation is a recommended best practice when it comes to Multi-tiered Read replica implementation

• It is recommended to create Tier 1 Read Replicas from Multi-AZ DB instance to offload read queries from the source master DB instance for high traffic sites. If the source instance of a Multi-AZ deployment fails over to the secondary, any associated read replicas will be switched to use the secondary as their replication source automatically. This model guarantees high availability.
• Also when you initiate the creation of a Tier 1 read replica, Amazon RDS takes the DB Snapshot of your Standby DB instance (instead of Source DB) and begins replication. This model saves I/O suspension on your source DB during the snapshot process 

Other Points to Note:

Note : 
To Load Balance AWS RDS Read Replica's Refer this article : http://harish11g.blogspot.com/2013/08/Load-balancing-Amazon-RDS-MySQL-read-replica-slaves-using-HAProxy.html

P1) Circular replication are not allowed in this tiered replica creation process. 
P2)Third Tier cannot be created. Actually in production, very rarely we need third tier and it is not important feature
P3) When the "X" Tier replica is placed in Different AZ , you should factor few extra milliseconds of latency during replication.
P4) Before a DB instance (Master or Tier 1) can serve as a replication source, you must enable automatic backups on the source DB instance by setting the backup retention period to a value other than 0. This requirement does not apply to second tier replica as they are not source DB instance for another read replica.So create “Read Replica” option will appear only when the Backup Retention is set to minimum of 1 day for any level Read Replica creation. When we "create Read Replica" by default RR is created with Backup Retention set to 0. Use the modify option Illustrated in below screenshot and set the  Backup Retention Period.  :

P5) We have used t1.micro as RDS DB for article explanatory purpose. For production use cases please use proper instance types after proper capacity planning.
P6) AWS has released Parallel replica creation process, where you can create multiple Tier 1 and Tier 2 replicas in parallel. Since you no longer need to wait for one replica creation before starting the next one, it becomes easy to create multiple RR quickly. Without this feature, it would take hours to create a large Multi-tiered Replica setup.
P7) If a replica lags too far behind for your environment, the normal practice is to scale up or consider deleting and recreating the read replica. Imagine you have architecture where there are two Tier 1 and three Second Tier RR as illustrated in below architecture:

Now since Tier -1 RR is lagging , you are planning to delete and recreate the same. When you delete the Tier-1 RR, All the Second Tier Read Replica's will now become Standalone , Single AZ DB's. Once you have recreated the Tier -1 RR again and managed to retain the original end point as well, you cannot re-point these Second Tier RR to Tier -1 again. You need to recreate all 3 second tier from the Tier -1 again. For a application with heavy DB dependency and read traffic, it means 1/2 of the fleet is now down. This can lead to uncomfortable performance situation. This is not a ideal condition and AWS RDS team can take this in their Road Map. For such cases, it is better to create a new Tier -1 and Second tier fleet first , update your LB/App configs and then delete the old lagging fleet 
P8)Why it is better to have Multi-tiered Read Replica as the last resort in your architecture ?
8.a)Currently 30 Read Replica can be created overall for a master in two tiers. 30 Read replica is more than sufficient and usually turns out to be costly architecture approach. Use this approach only for cases, which demand heavy read and when application code cannot accommodate changes and are highly DB dependent.
8.b)It is recommended in DB world to stay away from Multi-level replication as much possible. Your architecture will be much simpler with one master and "X" replica slaves, rather than having tiered replica's. As we observed in above deployment architectures, the second tier replica slave will be a trouble to manage in event of replication delay, crashes and network problems affecting the Tier-1 RR or the Master DB. 
8.c)In case your application code can be redesigned, it is recommended to take following approaches before resorting to Second Tier replicas architecture

• Functional partition the RDS MySQL with Hot Stand By and Read Replica's
• Re-balance the DB load by using alternate data stores provided by AWS like DynamoDB, ElastiCache, CloudSearch etc.

If the above methods does not work for you, take the Second tier Read replica approach.

Thanks Senthil and Ram of 8KMiles for taking part in this analysis.

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)