modernizing your aws architecture -...

New EC2 Instance Types and Moving to VPC

John Reif, Solutions Architect, [email protected]

July 17, 2014

Modernizing Your AWS Architecture

Customer Usage Patterns / Feedback

Processer Architecture

Evolution

Network Performance

Optimizations

New Instance Type Refresh New Generation

Key Inputs for New Instance Types

Performance Factors: CPU

Intel Xeon E5-2670 (Sandy Bridge) CPUs

• Available in AWS M3, CC2, CR1, G2 instance types

Intel Xeon E5-2680 v2 (Ivy Bridge) CPUs

• Available in AWS C3, R3, I2 instance types

• 2.8 GHz in C3, Turbo enabled up to 3.6 GHz

Intel® Advanced Vector Extensions (Intel® AVX):

• 256 bit instruction set extension

• For applications that are floating-point (FP) intensive

• The “Ivy Bridge” microarchitecture enhances this with the addition of float 16 format conversion instructions

Performance Factors: Networks

AWS proprietary, 10Gb networking

• CC2, M3, and all later instance types

• Highest performance in .8xlarge instance sizes

• Full bi-section bandwidth in placement groups

• No network oversubscription

Enhanced Networking

• Available on C3, R3, I2 (in VPC with HVM)

• Over 1M PPS performance, reduced instance-to-instance latencies, more consistent performance

• Built into Amazon Linux, but supported in many flavors - (including Windows)

Performance Factors: Accelerators

NVIDIA GPUs! • For computing and for remote graphics

• NVIDIA GPUs with up to 1,536 CUDA cores and 4 GB of video memory

• In EC2 CG1 and G2 instances

• NVIDIA GRID K520 – G2

• Tesla M-Class M2050 – CG1

• GPU accelerators augment CPU-based computing by offloading specialized processing

• Performance gains depend on application-level support

2006 m1.small

2007

m1.xlarge

m1.large

m1.small 2009

m2.2xlarge

m2.4xlarge

c1.medium

c1.xlarge

m1.xlarge

m1.large

m1.small

2011

cc2.8xlarge

cc1.4xlarge

cg1.4xlarge

t1.micro

m2.xlarge

m2.2xlarge

m2.4xlarge

c1.medium

c1.xlarge

m1.xlarge

m1.large

m1.small

2012-2013

cr1.8xlarge hs1.8xlarge

m3.xlarge

m3.2xlarge

hi1.4xlarge

m1.medium

cc2.8xlarge

cc1.4xlarge

cg1.4xlarge

t1.micro

m2.xlarge

m2.2xlarge

m2.4xlarge

c1.medium

c1.xlarge

m1.xlarge

m1.large

m1.small

2010

cc1.4xlarge

cg1.4xlarge

t1.micro

m2.xlarge

m2.2xlarge

m2.4xlarge

c1.medium

c1.xlarge

m1.xlarge

m1.large

m1.small

2008

c1.medium

c1.xlarge

m1.xlarge

m1.large

m1.small

new

existing

Instance History

2013-2014

cr1.8xlarge

hs1.8xlarge

m3.xlarge

m3.2xlarge

hi1.4xlarge

m1.medium

cc2.8xlarge

cc1.4xlarge

cg1.4xlarge

t1.micro

m2.xlarge

m2.2xlarge

m2.4xlarge

c1.medium

c1.xlarge

m1.xlarge

m1.large

m1.small

g2.2xlarge

c3.large

c3.xlarge

c3.2xlarge

c3.4xlarge

c3.8xlarge

m3.medium

m3.large

i2.large

i2.xlarge

i2.4xlarge

i2.8xlarge

r3.large

r3.xlarge

r3.2xlarge

r3.4xlarge

r3.8xlarge

Increasing choice…

July, 2014

t2.micro

cr1.8xlarge

hs1.8xlarge

m3.xlarge

m3.2xlarge

hi1.4xlarge

m1.medium

cc2.8xlarge

cc1.4xlarge

cg1.4xlarge

t1.micro

m2.xlarge

m2.2xlarge

m2.4xlarge

c1.medium

c1.xlarge

m1.xlarge

m1.large

m1.small

t2.small

t2.medium

g2.2xlarge

c3.large

c3.xlarge

c3.2xlarge

c3.4xlarge

c3.8xlarge

m3.medium

m3.large

i2.large

i2.xlarge

i2.4xlarge

i2.8xlarge

r3.large

r3.xlarge

r3.2xlarge

r3.4xlarge

r3.8xlarge

1

3

5

7

11 12

18 35 38

Instance Families

General Purpose: M1, M3, T2

Compute Optimized: C1, CC2, C3

Memory Optimized: M2, CR1, R3

Storage Optimized: HI1, HS1, I2

GPU: CG1, G2

Micro: T1, T2

?

Which instance type for my application?

http://aws.amazon.com/ec2/instance-types/

Suggested Instance Type Migration

M1

C1

M2

M3

C3

R3

HI1 I2

Suggested Instance Type Migration

m1.m

m1.s

t1.mi t2.mi

t2.s

t2.m

M3 Instance Types

• New M3 instance sizes with 1, 2 vCPUs

• SSD instance storage available on all M3

• M3 is the best value for general purpose computing

• M1 -> M3 migration is encouraged for higher, more consistent performance

AWS Confidential

Use Cases: Small and mid-size databases, data processing tasks that require additional memory

t2 Instance Types

• New t2 instance sizes with 1 or 2 vCPUs

• No locally attached ephemeral/instance store disk

• t2 is the best value for workloads that burst occasionally

• CPU credit system for predictable burst performance

• CloudWatch metrics for CPUCreditUsage and CPUCreditBalance

• Available On Demand or with Reserved Instances, not available in Spot

• Only available in VPC

• m1.small -> t2.small/t2.medium migration is encouraged for better price/performance

Use Cases: Small databases, web applications, build servers, development environments

C3: CPU-Optimized Instance Type

• 2.8 GHz Ivy Bridge CPU

• Various instance sizes with 2, 4, 8, 16, 32 vCPUs

• From 3.75GiB to 60GiB RAM

• From 40GB to 640GB SSD

• High PPS, low-latency Enhanced Networking (up to 1M PPS, VPC)

• Supporting Cluster Placement Groups for all sizes

• M1 to C3 migration is suggested for applications needing high compute performance and more consistent performance

New Family

Use cases: Web/App, worker tiers, HPC, ad serving, hadoop, others

R3: Memory-Optimized Instance Type


• Multiple instances sizes with 2, 4, 8, 16, 32 vCPUs

• Up to 244 GiB RAM (~ 8GiB/vCPU)

• SSD Based Instance Storage

• High PPS, low-latency Enhanced Networking (VPC only)

• M2 to R3 migration is suggested for applications needing

higher performance and more GB RAM

New Family

Use cases: High performance NoSQL/SQL databases, caching, in memory workloads (DB, Spark, Impala, etc.), large enterprise apps

I2: High-IOPS Instance Type


• Various instances sizes with 4, 8, 16, 32 vCPUs

• 30.5, 61, 122, 244 GiB RAM

• 16 vCPU: 3.2 TB SSD; 32 vCPU: 6.4 TB SSD

• 365K random read IOPS for 32 vCPU instance

• High PPS, low-latency Enhanced Networking (VPC only)

• HI1 to I2 migration will make sense for many applications

New Type

Use cases: NoSQL databases (Cassandra, MongoDB, etc.), shared file systems, high-I/O computing

Comparing M1 and M3

M1.XLARGE

Processor: multiple generations

vCPU: 4

ECU: 8

RAM: 15GB

Storage: 4 X 420GB HDD

Price US-East-1*: $0.350 per hour

M3.XLARGE

Processor: Intel Xeon E5-2670

vCPU: 4

ECU: 13

RAM: 15GB

Storage: 2 X 40GB SSD


*Current On Demand Price as of 7/17/14 for Linux/Unix in US-East-1

Comparing t2.small and m1.small

M1.SMALL


vCPU: 1

ECU: 1

RAM: 1.7 GB



T2.SMALL

Processor: Intel Xeon Family

vCPU: 1

ECU: Variable

RAM: 2 GB

Storage: EBS Only


With EBS GP2 (8 GB): $0.0551 per hour


Comparing C1 and C3

C1.XLARGE


vCPU: 8

ECU: 20

RAM: 7GB



C3.2XLARGE

Processor: Intel Xeon E5-2680 v2

vCPU: 8

ECU: 28

RAM: 15GB




Comparing M2 and R3

M2.XLARGE


vCPU: 2

RAM: 17.1GB



R3.LARGE

Processor: Intel Xeon E5-2680 v2

vCPU: 2

RAM: 15GB




Summary: Reasons to Migrate

• Newer instance types such as M3, C3, I2 and R3:

• Faster, newer Intel processors • SSD-based instance storage • Higher performance networking • Advanced features such as support for HVM AMIs,

AVX and XSAVE flags

• T2 – burstable CPU for price/performance optimization

• Workloads that have bursty CPU patterns

• Can fit within the baseline performance of the t2.micro, t2.small or t2.medium

Considerations for not migrating

20

• Some instance types are not available in the Sao Paolo Region – r3, i2, hs1, g2

• Larger amounts of locally attached disk (instance store) important for your workload

• Existing Reserved Instances for older instance types

• Consider using those for other needs (management servers, monitoring, general purpose, etc.)

• Reserved instance marketplace - http://aws.amazon.com/ec2/purchasing-options/reserved-

instances/marketplace/

• Some instance types are HVM only – t2, r3, i2, g2

• Some instance types are PV only – m2, c1, m1, t1

• t2 instance types are EBS and VPC only

• EBS optimized networking support varies by instance family and size

http://aws.amazon.com/ec2/purchasing-options/reserved-instances/marketplace/






EBS & EBS Optimized Networking

21

• EBS Optimized consideration

• m3.large does not support EBS optimized but

m1.large does support it at 500 Mbps

• EBS Standard Volumes (Magnetic)

• 1 GB – 1 TB in size

• Snapshots for durability

• ~100 IOPS

• PIOPS (SSD)

• 100-4,000 IOPS per volume

• Maximum ratio of 30:1 IOPS to GB

General Purpose EBS Volumes (SSD)

22

• Baseline of 3 IOPs/GB of provisioned storage

• Any size volume burstable up to 3000 IOPS for periods of time (credits based)

• IO included in the volume cost, you only pay per GB of provisioned storage

• Example

• 100 GB GP2 volume will have a base of 300 IOPs with the ability to burst to 3,000 IOPS

• Considerations

• Initial balance of 5,400,000 I/O credits per volume – enough for sustained use at 3,000 IOPS for 30 minutes

• 1 TB volume will never exhaust credits

• Maximum credit balance is 5,400,000 I/O credits

• Bursting will deplete the credit balance faster for smaller volumes

VPC Features

Specify your own private IP

address range from any

ranges you choose & specify a

private IP address when

launching instances

Control DHCP options and

DNS

Divide your private IP address

range into one or more public

or private subnets

Control inbound and outbound

access to and from individual

instances – SG’s & NACLS

Assign multiple IP address and

attach multiple ENIs and EIPs

to EC2 instances

Bridge your VPC and your

onsite IT infrastructure with an

encrypted VPN connection

Use ELB for internal load

balancing with private

addresses

Connect multiple VPCs in the

same region easily using VPC

Peering

What would you like to see?

Amazon VPC:

Private, isolated

section of the AWS

Cloud

Public Subnet

Private Subnet

Public Subnet

Availability Zone B

Private Subnet

Instance A 10.1.1.11 /24

Instance C 10.1.3.33 /24

Instance B 10.1.2.22 /24

Instance D 10.1.4.44 /24

VPC CIDR: 10.1.0.0 /16

Availability Zone A

VPC Overview AWS Region

Amazon S3

Bucket DynamoDB

Where we’ve been 2009

• Amazon VPC is announced

2010

• AWS Management Console

• Support for Auto Scaling

• User specified IPs per instance

• EU-West-1 region

• Amazon EBS backed instances

• Tagging support

2011

• Internet Gateway/Optional VGW

• Security groups

• Network ACLs

• Route tables

• Instance metadata

• Elastic IPs

• Dedicated instances

• NAT Instances

• DHCP Options

2011

• Spot Instances in VPC

• Elastic Load Balancing in VPC

• Amazon Elastic MapReduce in VPC

• Expansion to all regions

• Multiple Availability Zones

• Multiple VPCs per account

• Multiple VPN connections per VPC

• Elastic network interfaces

2012

• t1.micro

• cc2.8xlarge instances in VPC

• Multiple IPs per interface

• AWS CloudFormation for VPC

• AWS Elastic Beanstalk in VPC

• Amazon RDS in VPC

• Amazon ElastiCache in VPC

• NoBGP support for VPN/static routing

• ELB Internal Load Balancing

2013

• VPC becomes the default platform for all new AWS accounts

• DNS Hostnames in VPC

• AWS OpsWorks for VPC

• Amazon Redshift in VPC

• Ephemeral Public IPs

2014

• VPC Peering within a Region

• Additional AWS Elastic Beantalk topology support

• AutoScaling for dedicated instances in VPC

Public Subnet

Private Subnet

Public Subnet

Availability Zone B

Private Subnet

Instance A 10.1.1.11 /24

Instance C 10.1.3.33 /24

Instance B 10.1.2.22 /24

Instance D 10.1.4.44 /24

VPC CIDR: 10.1.0.0 /16

Route Table

Destination Target

10.1.0.0/16 local

Availability Zone A

.1

.1 .1

.1

VPC Routing

Public Subnet

Availability Zone A

Private Subnet

Public Subnet

Availability Zone B

Private Subnet

Instance A 10.1.1.11 /24

Instance C 10.1.3.33 /24

Instance B 10.1.2.22 /24

Instance D 10.1.4.44 /24

VPC CIDR: 10.1.0.0 /16

Virtual Private Gateway (VGW)

Internet Gateway

(IGW)

Only 1 IGW and 1 VGW per VPC

VPN connection

Customer data center

Customer data center

AWS Direct

Connect

Route Table

Destination Target

10.1.0.0/16 local

Internal CIDR VGW

Route Table

Destination Target

10.1.0.0/16 local

Internal CIDR VGW

VPC Connectivity

Peering Connection

NAT

28

Considerations for migration • EC2 instances in VPC with private addresses only – How to reach services on

the internet at scale with high availability?

1. Give every instance a public IP

2. Use a highly available NAT architecture with a NAT in each AZ and monitoring for NAT failure

3. Highly scalable NAT/Proxy tier with internal ELB & AutoScaling

• No SecurityGroup <-> SecurityGroup rules between EC2 classic and VPC

1. Use CIDRs for the migration period

2. Request a CIDR block of EIP’s for VPC for migration purposes (requires AWS Business

support)

29

Considerations for migration

• Replicate databases from EC2 Classic to VPC

• Run a hybrid architecture (IGW is not a single point of failure or

bottleneck)

• EC2 Classic EIP’s cannot be moved to VPC

• Detach/reattach EBS volumes, create AMI’s, take RDS/Redshift

snapshots to launch in VPC

• Engage an AWS Partner? - http://aws.amazon.com/partners

Availability Zone A Availability Zone B

Private Subnet

Internet

Amazon S3 Amazon Dynamo DB

AWS

region

Public Subnet Public Subnet NAT

Customers

Public load balancer

Web Servers

• Image processing app with high outbound network to Amazon S3

Direct to Amazon S3

Public ELB Subnet

Private Subnet

Public ELB Subnet

Multi-AZ Auto Scaling group

Auto Scaling group

• Public Elastic Load Balancer receives incoming customer HTTP/S requests

• Auto Scaling assigns public IP to new web servers

• With public IPs, web servers initiate outbound requests directly to Amazon S3

• NAT device still in place for private subnets

Option 1: Avoid NAT

Availability Zone A

Private Subnet

Availability Zone B

Private Subnet

Internet

Amazon S3

AWS

region

Public Subnet Public Subnet NAT

• Use Auto Scaling for NAT availability

• Create 1 NAT per Availability Zone

• All private subnet route tables to point to same zone NAT

• 1 Auto Scaling group per NAT with min and max size set to 1

• Let Auto Scaling monitor the health and availability of your NATs

• NAT bootstrap script updates route tables programmatically

Auto scale HA NAT

NAT

Amazon DynamoDB

Option 2: Example HA NAT

Option 3: Vertically scale HA NAT’s

Use the 1 HA NAT per Availability Zone design Vertically scale your NAT instance type to one with a High Network Performance rating Keep a close watch on your network metrics

t2.medium Low to Moderate

m3.large Moderate

m3.xlarge, c3.2xlarge High

t2.micro Low to Moderate

Availability Zone A

Private Subnet (s) Private Subnet (s)

AWS region

Intranet App

Intranet App

Availability Zone B

Scalable/Highly Available NAT Proxy

Internal ELB

ELB Private Subnet ELB Private Subnet

Proxy Public Subnet Proxy Public Subnet

Amazon

S3

HTTP/S

Multi AZ Auto scaling Group

Squid Proxy layer deployed

between internal load

balancer and the IGW

border.

Only proxy subnets have

route to IGW.

Proxy security group allows

inbound only from Elastic

Load Balancing security

group.

Proxy restricts which URLs

may pass. In this example,

s3.amazonaws.com is

allowed.

Egress NACLs on proxy

subnets enforce HTTP/S

only.

Option 4: Example Scalable/HA NAT

34

Customer examples

• Kiip – • http://blog.engineering.kiip.me/post/14317098482/ec2-to-vpc-executing-a-zero-downtime-migration

• Lucid Software – • http://www.slideshare.net/AmazonWebServices/amazon-ec2-to-amazon-vpc-a-case-study-cpn301-aws-

reinvent-2013

• http://nineofclouds.blogspot.com/2013/01/vpc-migration-planning.html

• Cloud66 – • http://blog.cloud66.com/how-we-moved-from-ec2-classic-to-ec2-vpc/

http://blog.engineering.kiip.me/post/14317098482/ec2-to-vpc-executing-a-zero-downtime-migration















http://www.slideshare.net/AmazonWebServices/amazon-ec2-to-amazon-vpc-a-case-study-cpn301-aws-reinvent-2013























http://nineofclouds.blogspot.com/2013/01/vpc-migration-planning.html





http://blog.cloud66.com/how-we-moved-from-ec2-classic-to-ec2-vpc/


















35

Thank You!

Find out more: • aws.amazon.com/ec2/instance-types • aws.amazon.com/vpc • aws.amazon.com/whitepapers

• VPC Networking

• Contact me – John Reif – [email protected]

mailto:[email protected]

modernizing your aws architecture -...

Documents