This presentation explores various ways of architecting Disaster Recovery using Amazon Web services (AWS) Cloud The sample architecture element contains Managed DNS servers , Load Balancers and Data replicators , Amazon EC2 , MySQL M-M , AWS EBS ,AWS Elastic Load Balancing, AWS Auto Scaling , AWS CloudWatch and AWS S3

1. Disaster Recovery using AWS
Architecture Blueprints
Harish Ganesan
Co founder & CTO
8KMiles
Harish11g.AWS@gmail.com
www.twitter.com/harish11g
http://www.linkedin.com/in/harishganesan

2. 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

3. 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

4. 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

5. List of Other Architectural components used
• Managed DNS
• LAMP (or) LAMJ stack
• MySQL Master- Master replication
• SOLr Search servers
• Schedulers and Back ground programs

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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  

16. 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 .

17. 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.

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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

32. 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  

33. 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

34. 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

35. 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

36. 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

37. 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

38. 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

39. 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

40. 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

41. 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

42. 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  

43. 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

44. 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

45. Which is the right Cloud based disaster
recovery strategy for me?

46. 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”

47. Contact
Harish11g.aws@gmail.com
http://in.linkedin.com/in/harishganesan
www.twitter.com/harish11g
http://harish11g.blogspot.com
47