AWS Community Day Kochi 2019 - Sponsor Talks Journey from a traditional on-prem Datacenter to AWS: Challenges and Opportunities By Thomas Brennekke , Founder & President, Network Redux

1. We provide expertise,
you grow your business!

2. Thomas Brenneke
Founder & President, Network Redux
LLC
Managed AWS Managed Teams
LinkedIn: linkedin.com/thomasbrenneke
Website: www.networkredux.com
Queries: sales@networkredux.com

3. Challenges and Opportunities
Journey from a traditional on-premise Datacenter to AWS:

4. Migrations to the cloud
Rehosting Replatforming Refactor
lift and shift lift-tinker-and-shift rebuild to be cloud native

5. The Story
How did we migrate an Enterprise Private Cloud environment from on-premise to AWS Cloud?
Challenges Strategy Planning Execution Future
● #1 direct reservation
platform and booking
engine in Europe.
● Millions of requests
from all major travel
and booking platforms
like Google, Expedia,
and Booking.com.
● Security and compliance
requirements
● Replatforming ● Hybrid Cloud
Environment
● Dedicated Dev,
Stage, Prod
Environments
● Fast switching with
maximum 2 minutes
maintenance window
● Fallback to on-prem
in 2 minutes
● Autoscaling
environment with
CI/CD pipeline using
CodePipeline and
CodeDeploy
● MySQL chained
replication and
switch over in 2
minutes
● Kubernetes,
Microservices and
Containers

6. About the client’s On- Premise platform
● Private Cloud environment in our Seattle on-
premise data center
● N+1 Architecture, HA and redundancy in each
layer of the application stack
● Juniper SRX cluster in firewall layer handling
traffic control, IPS & IDS
● HaProxy in front-end load balancing layer
● Multiple web and application service instances
● DRBD data layer to share the static assets
between web servers.
● Redis Sentinel cluster for caching and sessions
storage
● Multiple database clusters with master/slave
replication for application and logging
requirements.
● Additional management and monitoring servers
● PCI DSS compliance infrastructure

7. Why AWS?
● Moving the infrastructure to an E.U. Region since most the client base is based within this geography.
● Exploring and utilizing the elasticity and size of a public cloud platform and removing managing hardware devices.
● Implementing Autoscaling and deploying the application platform over multiple Availability Zones.
● Moving away from legacy svn-based deployment methods and implement DevOps best practices and CI/CD pipelines
● Implementing Cloudfront for media and static assets delivery

8. The Plan
● Identifying the AWS services to replace on-prem
services.
● Implement the infrastructure following CIS and
PCI/DSS best practices.
● Serve media and static assets via Cloudfront.
● Configuration management using Ansible
● Infrastructure management using
Cloudformation.
● Setup Chained replication for Database clusters
into AWS from current slaves to avoid significant
delay and efforts for the final data sync.
● CI/CD Pipeline by integrating Gitlab,
CodePipeline and CodeDeploy.
● Setup Auto Scaling for compute and database
layers.
● Monitoring the platform using the combination of
NewRelic, Cloudwatch and PMM.
DNS Layer Route53
Load balancing Layer Elastic Load Balancer (ELB)
CDN Layer Cloudfront and S3
Compute Layer EC2 AutoScaling
Caching Layer Elasticache
Database Layer Aurora RDS
Storage Layer Elastic File Storage (EFS)
CI/CD CodePipeline and CodeDeploy
SSL Certificates AWS Certificate Manager (ACM)
Application Firewall Web Access Firewall (WAF)
Others Cloudwatch, CloudTrail, Config,
NewRelic, Percona Monitoring and
Management, Prometheus

9. AWS Architecture - Accounts
● Dedicated AWS accounts for Management, QA, Stage
and Production environments.
● All Management instances such as Bastion, VPN, log
aggregation, monitoring servers reside in Management
account.
● IAM accounts are configured in the Management
account and access to other environments are granted
to developers and administrators using IAM Switch role
functionality.
● Dedicated AWS Accounts for QA, Stage & Production
Environments.
● Complete isolation between QA, Stage, Production
environments.
● Management traffic is routed through VPC Peering.

10. AWS Architecture
● Custom VPC spanning across multiple AZs
● Dedicated private subnets for each layer of services and
inter-service traffic restricted using Security Groups and
ACLs
● Application servers deployed in Auto Scaling Group.
● CI/CD pipeline for the deployment using AWS
CodeDeploy and CodePipeline.
● Multi-AZ Elasticache cluster for caching Layer
● Multi-AZ Aurora database clusters for database layer.
Read replica Auto Scaling to handle peak traffic.
● EFS to share common data and env files between web
servers.
● Distributing media assets using Cloudfront CDN
● WAF integrated with ELB
● SSL Certificates are managed using ACM

11. AWS Migration - Step 1: Infrastructure
● Configured dedicated AWS Account for each
environment.
● Benchmark AWS Account using CIS and PCI/DSS best
practices.
● Provision the VPC network infrastructure using
CloudFormation.
● Configure VPC Flow Logs, Cloudtrail, Cloudtrail Alarms,
Config Service and all other basic utilities.

12. AWS Migration - Step 2: Services
● Provision all services in all layers using CloudFormation
templates.
● Ensure HA and redundancy in each layer by deploying
Multi-AZ / Auto Scaling services.
● Configure Security Group rules and Network ACLs for
connectivity between services.

13. AWS Migration - Step 3: CI/CD
● Configured a deployment pipeline integrating Gitlab,
CodePipeline and CodeDeploy.

14. AWS Migration - Step 4: Initial Test
● Confirm Route53
● Confirm ELB, SSL Certs, Ciphers
● Confirm and test AutoScaling for Compute instances
● Confirm EGRESS traffic via NAT Gateway and whitelist
NAT Gateway IP Address with third-party partners.
● Confirm access to EFS filesystem.
● Confirm CI/CD pipeline and deployments.
● Confirm Elasticache cluster and connectivity from web
Instances.
● Confirm Aurora clusters and connectivity from web
instances
● Restore sample database and test the application stack
● Confirm WAF
● Confirm CDN

15. AWS Migration - Step 5: Migration/Rollback Plan
● DNS was previously migrated to Route53, and we reduced TTLs to the minimum for all public endpoints.
● Deploy latest application and put in maintenance mode with AWS specific configurations.
● Configure a Chain Replication (On-prem slave to a interim DB instance, and from there replicate to Aurora)
Migration Plan Rollback Plan
○ Put the application into maintenance mode in on-
prem environment
○ Break replications and promote Aurora as stand-
alone cluster
○ Switch DNS records to point to the ELB
○ Configure a replication in the reverse order
(Aurora cluster to the interim DB instance and
from there to on-prem slave)
○ Confirm application and remove maintenance
mode
○ Put the application into maintenance mode
○ Break replication and promote on-prem slave as
stand-alone master.
○ Configure applications on on-prem to point to the
standby slave.
○ Revert DNS records to point back to on-prem.
○ Confirm application and remove maintenance
mode

16. AWS Migration - Database Migration Services?
● We require absolute control over the database transfer and replication setup.
● We need to configure the replication as quickly as possible using log positions during the
migration/rollback
● Configured replication through an IPSec tunnel between AWS VPC and on-prem environment
● We needed to finish the final migration within 2 minutes

17. AWS Migration - Final Migration: Stage 1

18. AWS Migration - Final Migration: Stage 2

19. AWS Migration - Final Migration

20. AWS Migration - Future
● Roadmap for 2020
○ Move away from legacy application architecture to microservice based architecture
○ Implement Kubernetes for container orchestration

21. Thank You!