Good practices to design and implement IT architecture based

on AWS

About us• 11+ years of professional experience in Unix and 7+ years in Cloud Computing administration• Founder at LCloud – “Linxsys Cloud”, AWS Partner from

2012, first AWS Partner in Poland• We are after 150+ AWS projects• Enterprise experience:

• Email: jacek.biernat@linxsys.pl

Design for Failure – High Available solution

One of the major reasons for migration to Cloud Computing:- Avoid single points of failure- Assume everything fails

Our goal: Application should continue to function even if the underlying physical hardware fails or is removed or replicated

A simple Architecture

High Available Environment

Stateless solutions

Do not modify the application code:

Stateless solutions

Do not modify the application code:

- Network-Attached Storage (NAS) solution with Raid 1 via network: DRBD, GlusterFS

Stateless solutions

Do not modify the application code:

- Network-Attached Storage (NAS) solution with Raid 1 via network: DRBD, GlusterFS

- Amazon Elastic File System (EFS)

Stateless solutions

Do not modify the application code:

- Network-Attached Storage (NAS) solution with Raid 1 via network: DRBD, GlusterFS

- Amazon Elastic File System (EFS) - Mount Amazon S3 bucket as file system: s3fs,

s3ql

Stateless solutions

Do not modify the application code:

- Network-Attached Storage (NAS) solution with Raid 1 via network: DRBD, GlusterFS

- Amazon Elastic File System (EFS) - Mount Amazon S3 bucket as file system: s3fs,

s3ql- Amazon Elastic Load Balancer with sticky

session (sometimes is enough)

Stateless solutions

Modify the application code:

Stateless solutions

Modify the application code:

- Our database tier

Stateless solutions

Modify the application code:

- Our database tier- Amazon S3

Stateless solutions

Modify the application code:

- Our database tier- Amazon S3- Amazon Elasticache (Redis), Amazon

DynamoDB

When an AWS AZ in EU-West itself fails ?

When the Entire EU West region is affected ?

Proposal of solutions when a region is not available

Proposal of solutions when a region is not available

• RTO and RPO is max. 24 hours– Amazon Cloudformation templates– Copy backup to second region

Proposal of solutions when a region is not available

• RTO and RPO is max. 24 hours– Amazon Cloudformation templates– Copy backup to second region

• RTO and RPO is max. 5 minutes– Amazon Cloudformation templates– Configure Replication data between regions

Proposal of solutions when a region is not available

• RTO and RPO is max. 24 hours– Amazon Cloudformation templates– Copy backup to second region

• RTO and RPO is max. 5 minutes– Amazon Cloudformation templates– Configure Replication data between regions

• Keep two active environments Master-Master– Use a queue solution (Amazon DynamoDB, SQS)

Implement Elasticity

Don’t assume health or fixed location of components. Use designs that are resilient to

reboot and re-launch.

Standardized Application Stacks

Approaches to designing AMI

1. Inventory of fully baked AMI

2. Base AMI with fetch on boot

3. AMI with Agent to management system

Fully baked AMI

Tools for fully baked AMI

• AWS Console• AWS API with scripts

Base AMI

Base AMI

• Jenkins/Team City• Amazon Cloudformation

Base AMI

• Jenkins/Team City• Amazon Cloudformation• Ansible playbooks• Aminator

AMI with Agent to management system

Tool to management system

• Puppet• Chef• Ansible

Micro-services and elastic resource pools with AWS

• Each service is decoupled from the rest and deployed individually

• We run multiple services on the same instances

• An automated deployment system takes care of all services lifecycle details

Amazon EC2 Container Service (ECS) – a fully managed platform

Thank you for your attention