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/
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
• 2.5 GHz Ivy Bridge CPU
• 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
• 2.5 GHz Ivy Bridge CPU
• 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
Price US-East-1*: $0.280 per hour
*Current On Demand Price as of 7/17/14 for Linux/Unix in US-East-1
Comparing t2.small and m1.small
M1.SMALL
Processor: multiple generations
vCPU: 1
ECU: 1
RAM: 1.7 GB
Storage: 1 X 160GB HDD
Price US-East-1*: $0.058 per hour
T2.SMALL
Processor: Intel Xeon Family
vCPU: 1
ECU: Variable
RAM: 2 GB
Storage: EBS Only
Price US-East-1*: $0.054 per hour
With EBS GP2 (8 GB): $0.0551 per hour
*Current On Demand Price as of 7/17/14 for Linux/Unix in US-East-1
Comparing C1 and C3
C1.XLARGE
Processor: multiple generations
vCPU: 8
ECU: 20
RAM: 7GB
Storage: 4 X 420GB HDD
Price US-East-1*: $0.520 per hour
C3.2XLARGE
Processor: Intel Xeon E5-2680 v2
vCPU: 8
ECU: 28
RAM: 15GB
Storage: 2 X 60GB SSD
Price US-East-1*: $0.420 per hour
*Current On Demand Price as of 7/17/14 for Linux/Unix in US-East-1
Comparing M2 and R3
M2.XLARGE
Processor: multiple generations
vCPU: 2
RAM: 17.1GB
Storage: 1 X 420GB HDD
Price US-East-1*: $0.245 per hour
R3.LARGE
Processor: Intel Xeon E5-2680 v2
vCPU: 2
RAM: 15GB
Storage: 2 X 60GB SSD
Price US-East-1*: $0.175 per hour
*Current On Demand Price as of 7/17/14 for Linux/Unix in US-East-1
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
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/
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]