Disaster Recovery using AWS

Architecture Blueprints

Harish Ganesan
Co founder & CTO
8KMiles
www.twitter.com/harish11g
http://www.linkedin.com/in/harishganesan
 Introduction

• Explore various ways of architecting Disaster

recovery using Amazon cloud (AWS)
• Sample architecture element contains Managed
DNS servers , Load Balancers and Data
replicators
• Failover , Scalability , Load Balancing ,
Monitoring ,Back up/Recovery and High
Availability is factored in the architecture Blue
prints
DR Architecture blueprints using AWS

• Blue print1 :Both Main Site and Disaster

recovery site in AWS Cloud

• Blue print2 : Main site in AWS cloud and

Disaster recovery site in Traditional customer
data center

• Blue print3 : Main site in customer data center

and Disaster recovery site in AWS cloud
 List of AWS used in DR Blue prints

• AWS Security groups

• AWS Elastic Load balancing
• AWS Auto Scaling
• AWS EC2 & EBS
• AWS CloudWatch
• AWS Elastic IP
• AWS S3
List of Other Architectural components used

• Managed DNS
• LAMP (or) LAMJ stack
• MySQL Master- Master replication
• SOLr Search servers
• Schedulers and Back ground programs
Blue Print 1 : Main and DR website in AWS

Main web site is hosted Disaster Recovery (DR)

in AWS USA east region web site is hosted in
AWS Europe region
Blue Print 1 : Main and DR website in AWS

Main website in
AWS Cloud

AWS Europe region

AWS USA east region

Disaster Recovery
website in AWS
Cloud
 Blue Print 1: Main and DR website in AWS
GEO IP / Directional DNS Servers directs the user requests to
Main site in AWS USA region. In case of Disaster in Main site
1 AWS USA region , the web requests are directed to DR site in
Europe

GEO IP / Directional DNS Servers

Main Site - AWS USA DR Site - AWS Europe

Region Region
AWS Auto scaling / AWS Elastic Load AWS Auto scaling / AWS Elastic Load
Balancer Balancer
ELB redirects incoming requests to
2 same Web / APP server based on C C
Session Sticky Algorithm
L L
Web/App Servers
Elastic IP O Web/App Servers
Elastic IP O
EBS U EBS U
EC2 D EC2 D
MySQL
Master
W MySQL
Master
W
Search Servers A Search Servers A
3 MySQL
T MySQL
T
Master Schedulers/BG C Master Schedulers/BG C
MySQL Master –
Master Data H H
replication
D D

Master – Master Data

replication
 Blue Print 1 : Architecture Explanation

• Main website(MWS) hosted in AWS USA east

• Disaster recovery website(DRW) hosted in AWS
Europe
• Managed DNS passes the web requests to Main
website under normal circumstances
• AWS Elastic Load Balancer of MWS passes the
request to appropriate web/app servers
• Web / App servers are Amazon EC2 instances
configured with AWS EBS
• Web / App servers are enabled with Boot from EBS
Continued
Blue Print 1 : Architecture Explanation

• Web/App servers are configured with AWS

auto scaling ( Min 2 and Max 20)
• MySQL Data base servers are configured in
Master-Master replication mode
• MySQL M-M replication inside Main site
(MWS)
• MySQL M-M replication between Main and DR
site ( Asynchronous mode)
• MySQL Servers are Amazon EC2 instances with
AWS EBS ( Both Main and DR site) Continued
Blue Print 1 : Architecture Explanation

• MySQL servers are manually scaled in Main site

• Main website (MWS) is monitored using AWS
CloudWatch
• An exact replica of Main website infrastructure
can be run as DR website in AWS Europe
• Web/App servers in DR website can be
configured with AWS auto scaling ( Min 1 and
Max 10)
• In event of failure , managed DNS will pass the
requests to DR website in Europe Continued
Blue Print 1 : Architecture Explanation

• Disaster recovery (DR) website can take over the

requests seamlessly from the main website in
this architecture
• DR website can also auto scale its capacity
depending upon the load , in short it can handle
whatever the main site is architected for
• Once the Main site is up, the Managed DNS will
pass the web requests and DR website can
Shrink down automatically to minimum capacity
 Blue Print 1 : Positives

• Inter regional DR for High Availability

• DR site can act immediately in event of Main
site failure
• DR site is designed to handle same load as the
Main site
• No compromises on the DR site with respect to
Scalability, Security , Monitoring and Stability
• Elastic: DR site can expand and Shrink according
to load like Main site
• Cost effective and Highly available architecture
 Blue Print 1 : Negatives

• Complete Dependency on AWS cloud

• Technical intricacies in moving EBS volumes , S3
snapshots , AMIs between AWS USA and Europe
regions
• Migration cost of moving both Main and DR site
to the AWS Cloud
• Impacts on existing customer data center
contracts
• Impact of typical cloud problems like Slow IO,
privacy and regulations apply here
 Blue Print 1 : Architectural Objectives

Objectives Main site DR site

Elastic Load balancing  

Auto Scaling  
Failover  
High Availability  
Monitoring  
Management  
Replication inside a region  
Replication across regions  
Security  
Backups  
Recovery  
 Solution Components : EC2 and EBS

• Elastic Block Storage (EBS)

– Amazon Elastic Block Store (EBS) provides block level
storage volumes for use with Amazon EC2 instances.
– Amazon EBS is particularly suited for applications
that require a database, file system, or access to raw
block level storage.
– Our Use case :Application executables ,
configurations , Data base files and OS are installed
in the AWS EBS in this reference architecture .
 Solution Components : AWS S3

• Simple Storage Service (S3)

– Amazon S3 provides a simple web services interface
that can be used to store and retrieve any amount of
data, at any time, from anywhere on the web.
– Our Use case : The application data files that are
uploaded , AWS EBS snapshots are stored in S3.
 Solution Components : AWS ELB

• Elastic Load Balancer (ELB)

– Elastic Load Balancing automatically distributes
incoming application traffic across multiple Amazon
EC2 instances.
– Elastic Load Balancing detects unhealthy instances
within a pool and automatically reroutes traffic to
healthy instances until the unhealthy instances have
been restored.
– Our Use case : Load Distributed among Servers
located in Multiple AZ and Dynamically Auto Scaled
EC2 instances
Solution Components : AWS Auto Scaling

• Auto Scaling
– Auto Scaling allows you to automatically scale your
Amazon EC2 capacity up or down according to
conditions you define.
– Auto Scaling is particularly well suited for
applications that experience hourly, daily, or weekly
variability in usage.
– Our Use case : EC2 Server instances dynamically
Scaled up and Down depending upon the Load using
the Auto scaling
Solution Components : AWS CloudWatch

• AWS CloudWatch
– Amazon CloudWatch enables you to monitor your
Amazon web services in real-time.
– Amazon CloudWatch helps us to access up-to-the-
minute statistics, graphs, and set alarms for our
metric data.
– Our Use case : EC2 servers , EBS , ELB are monitored
and alerts are sent using AWS CloudWatch
Solution Components : Managed DNS

• Managed DNS
– a solution that can monitor the health of multiple
endpoints or websites and automatically failover at
DNS level in case of a failure at the primary website
– Our Use case : Used for transparent switch between
Main and Disaster recovery website during failures
Solution Components : MySQL replication

• MySQL Replication
– MySQL will be setup in Master – Master replication
mode
– M-M setup offers failover inside data center as well
as across Data centers
– Data Replication will be done asynchronously
– Our Use case : Data is replicated between Main and
DR website MySQL database using Master-Master
replication
 Blue Print 2 : Main site in AWS

Main web site is hosted

in AWS USA east region

Disaster Recovery (DR)

web site is hosted in USA
West in a Traditional
data center
Blue Print 2 : Main site in AWS

Main website in
AWS Cloud

Traditional Data center- USA

AWS USA east West

DR website in
Traditional data
center
 Blue Print 2: Main site in AWS – DR site in Traditional DC
GEO IP / Directional DNS Servers directs the user requests to
Main site in AWS USA region. In case of Disaster in Main site,
1 the web requests are directed to DR site in USA West

GEO IP / Directional DNS Servers

Main Site - AWS USA DR Site – Traditional DC in

Region USA west
AWS Auto scaling / AWS Elastic Load
Manual scaling / Load Balancer
Balancer
ELB redirects incoming requests to
2 same Web / APP server based on C
Session Sticky Algorithm M
L
O
Elastic IP O
Web/App Servers Web/App Servers N
EBS U
I
EC2 D
T
MySQL W MySQL
Master Master
Search Servers O
Search Servers A
R
3
T
MySQL MySQL S
Master Schedulers/BG C Master Schedulers/BG
MySQL Master –
Master Data H
replication
D D

Master – Master Data

replication
Blue Print 2 : Architecture Explanation

• Main website(MWS) hosted in AWS USA east

• DR website(DRW) hosted in Traditional data
center in USA West
• Managed DNS passes the web requests to Main
website under normal circumstances
• AWS Elastic Load Balancer of MWS passes the
request to appropriate web/app servers
• Web / App servers are enabled with Boot from
EBS in Main site
Continued
Blue Print 2 : Architecture Explanation

• Web/App servers are configured with AWS

auto scaling ( Min 2 and Max 20) in Main site
• MySQL Data base servers are configured in
Master-Master replication mode
• MySQL M-M replication inside Main site
(MWS)
• MySQL M-M replication between Main and DR
site ( Asynchronous mode)
• MySQL Servers are Amazon EC2 instances with
AWS EBS in Main site Continued
Blue Print 2 : Architecture Explanation

• MySQL Servers are virtualized instances

configured with Network storage in DR site
• MySQL servers are manually scaled in both sites
• Main website (MWS) is monitored using AWS
CloudWatch
• DR website will be monitored using Traditional
data center tools
• Web/App servers in DR website runs on minimal
capacities
Continued
Blue Print 2 : Architecture Explanation

• In event of failure , managed DNS will pass the

requests to DR website in USA West
• DR website can take over the requests
seamlessly from the main website
• DR website cannot scale its capacity depending
upon the load , since it is runs on a minimal non
elastic capacity it cannot handle similar loads of
Main site
 Blue Print 2 : Positives

• DR site MAY act immediately in event of Main

site failure (depending upon hot /warm/cold DR
strategies)
• Leverage the existing infra contracts with
Traditional data center provider
• Cloud adoption and migration in phases (first
main site followed by DR site)
• Main Site handles load and DR site is a low cost
Stop gap alternative during failures
• Partial dependency on AWS
 Blue Print 2 : Negatives

• Very complicated architecture for management

– 2 types of monitoring , provisioning, backup
,Security etc , In short 2 different infrastructure
architectures has to be maintained by the sys
admins
– Can turn in to a maintenance nightmare if not
administered well
• DR site cannot handle and sustain the loads of
Main site .
• Cannot guarantee High availability
• Cost ineffective on the Sys Administration front
 Blue Print 2 : Architectural Objectives

Objectives Main site DR site

Elastic Load balancing  X

Auto Scaling  X
Failover  
High Availability  X
Monitoring  
Management  
Replication inside a region  
Replication across regions  
Security  
Backups  
Recovery  
 Blue Print 3 : DR site in AWS

Main web site is hosted

in Traditional Data center
in USA east region

Disaster Recovery (DR)

web site is hosted in
AWS USA West Region
 Blue Print 3 : DR site in AWS

DR website in AWS
Cloud

Traditional Data center- USA

AWS USA west east

Main website in
Traditional data
center
Blue Print 3: DR site in AWS – Main site in Traditional DC
GEO IP / Directional DNS Servers directs the user requests to
Main site in USA east region. In case of Disaster in Main site,
1 the web requests are directed to DR site in AWS USA West
region

GEO IP / Directional DNS Servers

Main Site – Traditional DC in DR Site - AWS USA west

USA east Region
AWS Auto scaling / AWS Elastic Load
Manual scaling / Load Balancer
Balancer
ELB redirects incoming requests to
2 same Web / APP server based on C
M Session Sticky Algorithm
L
O
Elastic IP O
Web/App Servers N Web/App Servers
EBS U
I
EC2 D
T
MySQL MySQL W
Master
Search Servers O Master
Search Servers A
R
3
T
MySQL S MySQL
Master Schedulers/BG Master Schedulers/BG C
MySQL Master –
Master Data H
replication
D D

Master – Master Data

replication
Blue Print 3 : Architecture Explanation

• Main website(MWS) hosted in USA east in

Traditional Data center
• DR website(DRW) hosted in AWS USA west
region
• Managed DNS passes the web requests to Main
website under normal circumstances
• Load Balancer of Main site passes the request to
appropriate web/app servers

Continued
Blue Print 3 : Architecture Explanation

• Web/App servers are configured with Manual

scaling in Main site
• MySQL Data base servers are configured in
Master-Master replication mode
• MySQL M-M replication inside Main site
(MWS)
• MySQL M-M replication between Main and DR
site ( Asynchronous mode)

Continued
Blue Print 3 : Architecture Explanation

• MySQL servers are manually scaled in both sites

• DR website (MWS) is monitored using AWS
CloudWatch
• Main website will be monitored using
Traditional data center tools
• Web/App servers in Main website runs on
minimal capacities

Continued
Blue Print 3 : Architecture Explanation

• In event of failure , managed DNS will pass the

requests to DR website in USA West
• DR website can take over the requests
seamlessly from the main website
• DR website running in AWS UAS west can easily
scale its capacity depending upon the load
 Blue Print 3 : Positives

• DR site can act immediately in event of Main site

failure
• Leverage the existing infra contracts with
Traditional data center provider
• Cloud adoption and migration in phases (first DR
site followed by Main site)
• Main Site handles predictable load and Elastic DR
site will act as Stop gap alternative during failures
• Partial dependency on AWS
• Cost effective
 Blue Print 3 : Negatives

• Very complicated architecture for management

– 2 types of monitoring , provisioning, backup
,Security etc , In short 2 different infrastructure
architectures has to be maintained by the sys
admins
– Can turn in to a maintenance nightmare if not
administered well
• Cannot guarantee High availability
• Cost ineffective on the Sys Administration front
 Blue Print 3 : Architectural Objectives

Objectives Main site DR site

Elastic Load balancing X 

Auto Scaling X 
Failover  
High Availability  
Monitoring  
Management  
Replication inside a region  
Replication across regions  
Security  
Backups  
Recovery  
 DR Architecture blueprints suitability

• Blue print1 :Both Main Site and Disaster recovery

site in AWS Cloud
– Suitable for web applications , Mobile apps , social and
gaming websites
– Unpredictable load bursts , growing companies
• Blue print2 : Main site in AWS cloud and Disaster
recovery site in Traditional customer data center
– Enterprises web applications, online Media companies
etc which already have 1-2 years contracts signed with
traditional data centers
– Fairly predictable or “On & Off” workload bursts
 DR Architecture blueprints suitability

• 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
Which is the right Cloud based disaster
recovery strategy for me?
Leave it to the experts , we will
solve this

Cloud Adoption Strategy

Cloud Architecture Consulting
Cloud Migration
Cloud Application Development
Cloud Implementation

“Let's get the job done”

 Why 8KMiles ?

• Amazon Systems Integrator

• Migrated 350+ servers for start-ups, small businesses and
Enterprises
• In-depth understanding of Cloud infrastructure services
“All you need is an idea and the cloud will execute it for you.” (Structure 2010 event)
- Dr Werner Vogels , CTO of Amazon on 8KMiles

For more details on how 8KMiles Cloud Consulting can help

your business , contact

cloud@8kmiles.com
http://cloudblog.8kmiles.com
http://cloud.8kmiles.com