This document discusses considerations for migrating applications to AWS. It identifies some key factors such as understanding the application stack and its components, security requirements, and current configuration. Standalone applications and loosely coupled applications are generally better candidates for migration than tightly integrated applications. It is recommended to do a proof of concept early to identify gaps. The document outlines the migration process and how on-premises infrastructure can be mapped to AWS architectures. CloudFormation templates can be used to automate infrastructure provisioning. Open source and paid toolkits can assist with monitoring and migration. Partnering with an experienced organization can help tailor the solution.

1. MIGRATING APPLICATIONS
TO AWS
Suliman Lei : Cloud Infrastructure Architect @Delaware North

2. MIGRATION CONSIDERATIONS
 Migration Approach & Best Practices
 Understand Application Stack’s (not Servers)
 components that make up the application
 CPU/Ram /Disk average utilization
 Security (public facing vs. private facing)
 Know the application owner
 Asking the right question!
 How is the application currently configured ?
 Is there current documentation
 Networking / Storage / Compute capacity.

3. IDENTIFY APPLICATIONS TO MOVE
Standalone applications easy to move
Applications with loosely coupled
integrations are good candidates.
Tightly integrated applications are hard to
move (e.g. Active directory is tightly
coupled, may be better to build new and
start replication).

4. INVEST IN PROOF OF CONCEPT EARLY
Proof of concept will answer tons of
questions quickly
Will identify gaps and touch points
Give you a good estimation of the task
ahead.

5. MIGRATION CONTINUUM

6. MIGRATION PROCESS

7. ON-PREMISES INFRASTRUCTURE
MAPPED TO AWS

8. ON-PREMISES INFRASTRUCTURE
MAPPED TO AWS

9. ELB CAN ACHIEVE HA
– ARCHITECTURE

10. CLOUD FORMATION (CF)
 Allows you to create and provision resources in a reusable
template fashion.
 Allows you to source control your infrastructure by building
templates that enable you create/delete resources on demand.
 Templates are built using Java Script Object Notation (JSON)
syntax
 Can use git to version your infrastructure
 Boto is a awsome and powerful tool

11. ANATOMY OF CF TEMPLATE
 Template is made up of 6 sections
 Declaration – Must follow AWS Template format version.
 Parameters – Values that can be passed at creation time
 Mappings – Key/Value pairs of information
 Conditions
 Resources – Can be database, EC2, S3, DynamoDb – Only Required portion.
 Outputs

12. TOOL KITS
 Use open source when possible
 Nagios
 Graphite
 virtuallyGhetto (vmware tools and scripts)
 Good Migration tool kits (paid)
 CloudEndure
 Block by block copy of instance to AWS

13. THE RIGHT PARTNER
 The right partner can make all the difference.
 CloudReach bring agility and expertise to the table
 Easy and fun to work with.
 Tailor fit the solution.