As AWS continues to expand, enterprise customers are looking to our partner ecosystem to assist in migrating their workloads to the cloud. This session describes the challenges, lessons learned and best practices for large scale application migrations. We will use real examples from our consulting partners and AWS Professional Services to illustrate how to move workloads to the cloud while modernizing the associated applications to take advantage of AWS’ unique benefits. We will also dive into how to use an array of AWS services and features to improve a customer’s security posture as they are migrating and once they are up and running in the cloud
5. Discover Design Transform Transition Operate Optimize
Plan RunBuild
• Detailed
migration plan
• Estimate effort
• Security & risk
assessment
• Network
topology
• Migrate
• Deploy
• Validate
• Assessment &
profiling
• Prioritization
• Data
requirements &
classification
• Business logic
& infrastructure
dependencies
• Pilot testing
• Transition to
support
• Release
management
• Cutover &
decommission
• Staff training
• Monitoring
• Incident
management
• Provisioning
• Monitoring-
driven
optimization
• Continuous
integration and
continuous
deployment
App migration
assessment
Re-hosting
(lift and shift)
App portfolio optimization
Re-platforming
(lift and reshape)
Migration methodology
6. Planning your migration
Migrating to the cloud can take one of many paths
Discover,
Assess (Enterprise
Architecture and
Applications)
Lift and Shift
(Minimal
Change)
Migration and
UAT Testing Operate
Refactor
for AWS
Application
Lift and shift
Move the App
Infrastructure
Plan Migration
and Sequencing
Determine
Migration Path
Decommission
Do Not Move
Create Cloud
Strategy
Design, Build AWS
Environment
Move the
Application
Determine
Migration
Process
Manually Move
App and Data
Third-Party Tools
AWS VM Import
Refactor
for AWS
Rebuild Application
Architecture
Vendor
S/PaaS
(if available)
Third-Party Migration Tool
Manually Move App and Data
Determine
Migration Process
Replatform
(typically legacy
applications)
Recode App
Components
Rearchitect
Application
Recode
Application
Architect AWS Environment
and Deploy App, Migrate Data
Signoff
Tuning Cutover
Org/Ops
Impact
Analysis
Identify
Ops Changes
Change
Management
Plan
12. AWS Foundation Services
Compute Storage Database Networking
AWS Global
Infrastructure Regions
Availability Zones
Edge
locations
AWS is responsible for the security of the cloud
13. AWS Foundation Services
Compute Storage Database Networking
AWS Global
Infrastructure Regions
Availability Zones
Edge
Locations
Client-side data
encryption
Server-side data
encryption
Network traffic
protection
Platform, applications, identity & access management
Operating system, network, & firewall configuration
Customer applications & contentCustomers
Customers configure their security in the cloud
20. Identifying applications to move
Standalone applications are easy to move
Application with loosely coupled SOA-based
integrations are good candidates
Tightly integrated application needs more planning
‘Low hanging fruit’
• Dev/Test applications, self-contained web applications (LAMP stack), social media product
marketing campaigns, training envrionments, pre-sales demo portal, software downloads, trial
applications
Watch out for
• 32 bit, non-Linux/Windows, multi-cast (Oracle RAC), client/server applications, engineered
systems (Exadata, Netezza), massive file servers, vertically challenged software/applications
21. Getting a bread box estimate: minimum information
Compute : Number of servers/VMs including RAM,
CPU, OS, and boot drive size (Amazon EC2)
Storage mapping to transactional, backup, archival,
and log/file system/applications (Amazon EBS, Amazon Glacier, and Amazon S3)
Data transfer out for networking
Internet or dedicated networking including security
requirements (AWS Direct Connect and VPN)
Region where processing is happening
22. Getting a bread box estimate: nice to have
HA requirements for each workload (ELB, Route53)
Scalability requirements for each workload (ELB,
Route53, Auto Scaling, CloudFront)
DR requirements for each workload
Storage IOPS requirements for each workload
Compute requirements for management/monitoring
Backup requirements for each workload that can
not be supported by EBS snapshots
23. Getting a bread box estimate: really nice
Workload stratification file servers, security, RDBMS,
ERP, big data, security, management/monitoring etc.
HIPPA and PCI requirements for each workload
HPC requirements for each workload
Extremely high CPU, memory requirements
Top third-party vendors for packaged apps
IDS/IPS, WAF, management, monitoring, logging, etc.
24. Invest in proof of concept early
Proof of concept will answer tons of questions and get your
feet wet with AWS quickly
Will help identify gaps and touch points
Give you a good estimation of the migration costs
Give you a good estimation of the AWS runtime costs
25. Migrating data into AWS cloud
• File transfer to Amazon S3 or EC2 using S/FTP, SCP, UDP, Attunity
• NFS mount accessible from on premise and AWS
• Configure on-premises backup application (like NetBackup, CA,
CommVault, Riverbed) to use Amazon S3
• AWS Storage Gateway for asynchronous backup to Amazon S3
• AWS Import/Export service: Ship your disk to AWS
• Database backup tools like Oracle Secure Backup
• Database replication tools like GoldenGate, Dbvisit
• AWS Direct Connect 100 Mbps to 10 Gbps
26. Migrating data into AWS
Data size*
* relative to Internet bandwidth and latency
Datavelocityrequired
UDP transfer software
(e.g., Aspera, Tsunami, …)
Attunity CloudBeam
AWS Storage Gateway,
Riverbed, NFS
AWS Import / ExportTransfer to S3
over Internet
One-time upload with
constant delta updates
Days
Hours
TBsGBs
28. Enforce consistent security on your hosts
Launch
instance
EC2
AMI catalog Running instance
Your instance
Hardening
Audit and logging
Vulnerability management
Malware and HIPS
Whitelisting and integrity
User administration
Operating system
Configure
instance
Configure and harden EC2 instances based on security and compliance needs
Host-based protection software
Restrict access where possible
Connect to existing services
29. Separate static assets
and move servers away from the edge
Inbound HTTP
CloudFront
Amazon S3
WAFDynamic
App
App
AppPeering
30. Identity and Access Management
Create appropriate principles, authorization, and privileges for AWS resources
Multi-factor authentication
AWS Identify and
Access Management
Policies
User
Groups
Roles
Principle of least privilege
User User Hardware Virtual
IAM AWS administrative users
Root account
Note: Always associate the account owner ID with
an MFA device and store it in a secured place!
31. AWS IAM hierarchy of privileges
AWS account owner
(root)
AWS IAM
User
Temporary
security
creds
Permissions Example
Unrestricted access to all
enabled services and
resources.
Action: *
Effect: Allow
Resource: *
(implicit)
Access restricted by
group and user policies
Action:
[‘s3:*’,’sts:Get*’]
Effect: Allow
Resource: *
Access restricted by
generating identity and
further by policies used
to generate token
Action: [ ‘s3:Get*’ ]
Effect: Allow
Resource:
‘arn:aws:s3:::mybucket/*’
Enforce principle of least privilege with Identity and Access Management (IAM)
users, groups, and policies and temporary credentials
32. Principle of least privilege with IAM
• Login to an account with a less privileged user
– Read-only
– EC2 launch-only
• Change role for privileged action
– Administer IAM
– Terminate instance
– Delete snapshots
Protection against accidents or mistakes
(e.g., similar to DisableApiTermination=true)
33. Consolidate your IAM users
• Put all IAM users and groups in
one account
• All other accounts use AWS IAM
roles
Best practices:
• Tie into consolidated billing hierarchy
• Users in IAM account are only
authorized to assume roles in other
accounts
• No AWS-billable resources in this
account
34. Governance through IAM policies
...
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:region:account:network-interface/*"
],
"Condition": {
"ArnNotEquals": {
"ec2:Subnet": "arn:aws:ec2:region:account:subnet/subnet-12345678"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:region::image/ami-12345678",
"arn:aws:ec2:region:account:subnet/subnet-12345678",
"arn:aws:ec2:region:account:security-group/sg-12345678"
]
"Condition": {
"StringEquals": {
"ec2:ResourceTag/BillingCode": “4000"
},
"StringEquals": {
"ec2:ResourceTag/Environnent": “Prod”
...
Deny RunInstances without
appropriate subnet
Require RunInstances to
have specific AMI, subnet,
security group, …
Require RunInstances to
have specific tags
35. Implementing “smart” AWS policies
• The 5 Ws of auditability:
– Who?
– What?
– Where?
– When?
– Why?
• What we really want is an “if and only if” statement:
– You can deploy this change in production “if and only if” it
actually worked in test
Controlled by AWS IAM
Not controlled by IAM
36. Federate with AWS Directory Service & IAM
Directory Users
Directory Groups
IAM_Admins
Read_Only
EC2_Admin
Group ‘n’
…
AWS Directory Services
Mgmt Acct
IAM_Admin
IAM Role Mapping
Read_Only
EC2_Admin
Role ‘n’
38. Condé Nast data center migration drivers
• Existing data center needed >$1 million in upgrades
• Financial pressure to close facility by July 2014
• Increase resource efficiency, both people and technology
39. Condé Nast data center migration scope
• 47 application groups
• 350+ servers
• 400+ TB storage
40. Application migration methodology
• Condé Nast provided a detailed inventory of their Delaware DC assets
• Utilization metrics were critical for Reserved Instance analysis and to
explore elasticity
• Application assessment determined migration order
• Migration scheduled in waves
• Change window: Migrations occurred over weekends
• Coordinating the change window with various teams was key
• Applications run in hybrid mode during the migration
• Once a server was migrated successfully it was decommissioned
41. Application migration: virtual machines
• Condé Nast was highly virtualized (VMware)
• Veeam: stage VMs to Amazon S3
– Supports change block tracking which minimizes downtime during migration
• AWS VM Import/Export: migrate staged VMs to Amazon EC2
– Eliminates VM data migration as a part of the change window
• Large databases: created directly on AWS and then data
synchronized
42. AWS VPC and networking
Key criteria to support waves of migration:
• AWS Direct Connect: 10 GB DX to AWS
• IP addressing: Avoid overlapping IPs
• Service names
43. AWS Identity and Access Management (IAM)
Key criteria:
• IAM policies
• Identify groups and permissions
• Application tagging
44. Phased migration
• Live migration from premises was too slow
– Large change windows meant that production systems were
frozen for a long time
• Solutions:
– Use a tool (Veeam) to backup and ongoing synchronization of
VMs to Amazon S3
– Use a staging farm to run VM Import/Export
45. VM Import/Export considerations
• Root partitions cannot span multiple disks
– Solution: Eliminate this on premises before migration
• Volumes > 1 TB not supported
– Solution: Spread data across volumes
• VM Import/Export requires stream-optimized VMDK
– Solution: conversion process was scripted
• Nonvirtualized servers were virtualized on premises
before migration
• Unsupported operating systems were upgraded to
supported OS before migrating
46. Lessons learned at Condé Nast
• Know your limitations
• Evaluate and understand your infrastructure environment
• Sign-up for enterprise support early and involve a TAM early on
• Get your operations staff trained on AWS
• Challenge yourself and make sound architecture decisions;
changing in future can be difficult
• Document every decision made, especially the anti-patterns
• Work directly with application owners; nothing beats hands-on
experience
Rehost
Data migration
High level estimate
Where will you spend your time
Focus on tecnnology and process.
Dispel misunderstandings around rehost : more then just moving a VM and across a portofolio (rehost)
Complexities of data migration and impact on production cut over (data migration)
Getting a high level estimate : migration cost and run time costs (high level estimate)
Where will you spend your time on a migration (more then compute migration)
Migration process – continue consistency, repeatablility, streamlined workflow, and most importantly ensure standardization
Testing, application analysis, pilot … where are you spending your time. See migrate.
Training at end?
This is not an sequentail process.
Rehost and rearchitect and when do you re-architect : before or after moving.
Nothing around compute and storage here
I don’t’ see anything about compute on here. Many more other components other then compute and storage.
VPC and acccount set up: One VPC, using subnets and security groups to control access. Accounts for each application, each organization, each developer.
Security is here today
Billing and cost management : Trusted advisor, CloudHealh CloudCruiser, CloudCheckr
RPO and RTO
Monitoring: SumoLogic, Splunk, CA, BMC DataDog, NewRelic, Boundary
Without getting into the industry debate about public vs. private cloud it’s clear that most cloud benefits cannot be realized with on-premise virtualization technologies. In the on-premise virtualization model, you often have to buy expensive hardware and software which virtually eliminates the cost benefits of cloud computing. Although on-premise virtualization allows you to quickly provision new servers, your ability to scale up is limited to your physical infrastructure. You still need to buy physical servers to grow. If you want to scale down you won’t see significant cost-savings as you already paid for the hardware. These limitations of the on-premise virtualization model impact your ability to innovate fast and free up money to invest in new projects.
NAS is file based, SAN is block based.
Short for Multiprotocol Label Switching, an IETF initiative that integrates Layer 2 information about network links (bandwidth, latency, utilization) into Layer 3 (IP) within a particular autonomous system--or ISP--in order to simplify and improve IP-packet exchange.
MPLS gives network operators a great deal of flexibility to divert and route traffic around link failures, congestion, and bottlenecks.
Without getting into the industry debate about public vs. private cloud it’s clear that most cloud benefits cannot be realized with on-premise virtualization technologies. In the on-premise virtualization model, you often have to buy expensive hardware and software which virtually eliminates the cost benefits of cloud computing. Although on-premise virtualization allows you to quickly provision new servers, your ability to scale up is limited to your physical infrastructure. You still need to buy physical servers to grow. If you want to scale down you won’t see significant cost-savings as you already paid for the hardware. These limitations of the on-premise virtualization model impact your ability to innovate fast and free up money to invest in new projects.
Use Security Groups as whitelists, allowing only what is needed.
Use NACLs as blacklists, blocking specific ports or IPs as desired.
Best Practice that helps implement separation of duties and fosters an agile DevOps environment:
- NetSec team builds NACLs for top-level blacklisting – between specific subnets, blocking specific IP ranges, specific ports
- NetSec team manages one set of security groups for administrative access needs (SSH, RDP, DNS, NTP, Logging, etc.)
- DevOps/Apps teams manage one set of security groups for the application needs (HTTPS, SQL*NET, etc.)
Whiteboard opportunity:
Q: How can Security Groups provide more protection than traditional network firewalls?
A: They filter traffic between hosts, whereas network firewalls only filter traffic between subnets.
We’ll go over a few examples from our partners who have worked closely with our business development teams to offer solutions that work well for the enterprise.
Most support auto scaling
Can help you with HIPAA, PCI compliance
Transitive routing
Host-based IPS, IDS, boot volume encryption, overcome AWS limits
Managed services (e.g. threat analysis)
Get your feet wet with Amazon Web Services
Learning AWS
Build reference architecture
Be aware of the security features
Build a Prototype/Pilot
Build support in your organizatio
n
Validate the technology
Test legacy software in the cloud
Perform benchmarks and set expectations
We have noticed some of our SMBs and startup companies in our ecosystem skipped the classification and other stages I discussed above and dove right into a proof of concept. There is no doubt that a proof of concept will answer tons of questions very quickly. During the proof of concept it is important that you get your feet wet with Amazon Web Services, get trained from Amazon (we have AWS University and have launched a training course in Seattle).
Andy started multiple projects in parallel. He regularly focused on Proof of concept.
Store target file(s) on a file share.
Configure policies on target S3 buckets
Encrypt / Compress data sets on premise
Transfer files via regular file transfer (S3, SFTP, SCP, FTP, Custom UDP etc) – Increase transfer rate using third-party solutions (Aspera, Attunity)
Retrieve encrypted file from S3 using the same options
Test Integrity / Security / Operations / Performance
Add parallelization for performance optimization
Configure on premise NetBackup (or CA, CommVault, Riverbed Whitewater etc. there are many options) to use S3
Backup and Restore directly from host agent
Backup agent communicates with cloud (S3) over Internet links
Use NetBackup Encryption, Compression, DeDupe, Backup Management tools
Check Security / Integrity / Functionality / Performance / Operations / Speed
Integrates on-prem IT environments with Cloud storage for remote office backup and DR
Utilizes a virtual appliance that sits in customer datacenter
Exposes compatible iSCSI interface on front end
Provides low-latency on-prem performance
Asynchronously uploads data to AWS where it is stored in Amazon S3 as Amazon EBS snapshots
Point-in-Time snapshots accessible locally and from Amazon EBS
Encryption via SSL and Amazon S3 Server Side Encryption
Snapshot scheduling
WAN compression
Supported in all public Regions
Bandwidth Throttling
Talk about relative Costs but highlight that this is about getting data their fast…
Rectangle not ovals.
Border line in size (GB vs TB) and speed (Hours vs Days)
Backup…can use storage gateway if less than 5 TB a day as this is max with storage gateway (also need a backup software to get data from disk to storage gateway), Riverbed is a great solution as they offer 2 TB an hour and no back up storage needed. CommVault is another
One take-away here: web servers don’t need an IGW
Manage AWS Accounts & Policies
IAM Users/Groups
IAM Roles