You are on page 1of 111

Masterclass

Elastic Compute Cloud


Ryan Shuttleworth Technical Evangelist
@ryanAWS

Masterclass
A technical deep dive beyond the basics
Help educate you on how to get the best from AWS technologies
Show you how things work and how to get things done
Broaden your knowledge in ~45 mins

Amazon EC2
On-demand compute to run application workloads
Easy come easy go disposable resource
We provide the infrastructure, you decide what you run

Complete control
Elastic capacity

Flexible

What is EC2?
Reliable

Secure
Inexpensive

Elastic capacity
Customer 1

Customer 2

Customer n

Hypervisor

Securely
segregated
Shared
environment

Virtual Interfaces
Customer 1
Security
Groups

Customer 2
Security
Groups

Firewall
Physical Interfaces

Customer n
Security
Groups

Elastic capacity
Customer 1

Customer 2

Customer n

Hypervisor

Securely
segregated
Shared
environment

Virtual Interfaces
Customer 1
Security
Groups

Customer 2
Security
Groups

Firewall
Physical Interfaces

Customer n
Security
Groups

AMI

Amazon Machine
Image

Instance

AMI

Amazon Machine
Image

Running or
Stopped machine

EC2

Instance

AMI

Amazon Machine
Image

Running or
Stopped machine

VPC

EC2

Instance

AMI

VPC

AZ
Amazon Machine
Image

Running or
Stopped machine

Region

Instance

AMI

EC2

EC2

VPC

VPC

AZ
Amazon Machine
Image

Availability Zone

Running or
Stopped machine

Region

Instance

AMI
EBS

EC2

EC2

VPC

VPC

EBS

EBS

EBS

AZ
Amazon Machine
Image

EBS

EBS

Availability Zone

Running or
Stopped machine

Region

Instance

AMI
EBS

EC2

EC2

VPC

VPC

EBS

EBS

EBS

AZ
Amazon Machine
Image

Running or
Stopped machine

EBS

EBS

Availability Zone
EBS
Snapshots

S3 Buckets
S3

Region

Instance

Unit of control

Instance

Unit of scale

Unit of resilience

Unit of control

Your stack

Instance

Unit of scale

Unit of resilience

Scale out

Instance

Unit of control

Instance

Unit of scale
Instance

Unit of resilience
Instance

Instance

Unit of control

Instance

Unit of scale
Instance

Unit of resilience
Instance

Instance

Unit of control

Instance

Unit of scale
Instance

Unit of resilience
Instance

Instance

Unit of control

Instance

Unit of scale

Unit of resilience
Instance

Instance

Unit of control

Instance

Unit of scale
Instance

Unit of resilience
Instance

Instance types
Choose the right unit for your workload

High I/O 4XL 60.5 GB


35 EC2 Compute Units
16 virtual cores
2*1024 GB SSD-based local instance storage

256

Hi-Mem 4XL 68.4 GB


26 EC2 Compute Units
8 virtual cores

128

Memory (GB)

Hi-Mem XL 17.1 GB
6.5 EC2 Compute Units
2 virtual cores

32

Extra Large 15 GB
8 EC2 Compute Units
4 virtual cores

16

M3 XL 15 GB
13 EC2 Compute Units
4 virtual cores
EBS storage only

Medium 3.7 GB,


2 EC2 Compute Units
1 virtual core
Large 7.5 GB
4 EC2 Compute Units
2 virtual cores

4
Small 1.7 GB,
1 EC2 Compute Unit
1 virtual core

Hi-Mem Cluster Compute 8XL


244 GB
88 EC2 Compute Units
16 virtual cores
240 GB SSD

10 GB
Inter-Instance
Network

Hi-Mem 2XL 34.2 GB


13 EC2 Compute Units
4 virtual cores

64

High Storage 8XL 117 GB


35 EC2 Compute Units,
24 * 2 TB ephemeral drives
10 GB Ethernet

M3 2XL 30 GB
26 EC2 Compute Units
8 virtual cores
EBS storage only

Cluster Compute 8XL 60.5 GB


88 EC2 Compute Units

Cluster Compute 4XL 23 GB


33.5 EC2 Compute Units

Cluster GPU 4XL 22 GB


33.5 EC2 Compute Units,
2 x NVIDIA Tesla Fermi
M2050 GPUs

High-CPU XL 7 GB
20 EC2 Compute Units
8 virtual cores

High-CPU Med 1.7 GB


5 EC2 Compute Units
2 virtual cores
Micro 613 MB
Up to 2 ECUs (for
short bursts)

1
1

8
16
32
EC2 Compute Units

64

128

256

Start small
Easy to up-size

AMIs

Amazon
maintained

Community
maintained

Your machine
images

Set of Linux and Windows


images

Images published by other


AWS users

AMIs you have created from


EC2 instances

Kept up to date by Amazon


in each region

Managed and maintained by


Marketplace partners

Can be kept private or shared


with other accounts

http://aws.amazon.com/amazon-linux-ami/

AMIs

Linux

Enterprise Linux

Windows

Small instance from


$0.060 per hour

Small instance from


$0.120 per hour

Small instance from


$0.115 per hour

Small instance from


$0.090 per hour

Instance types

On-demand instances
Unix/Linux instances start at
$0.02/hour
Pay as you go for compute power
Low cost and flexibility
Pay only for what you use, no up-front
commitments or long-term contracts
Use Cases:
Applications with short term, spiky, or
unpredictable workloads;
Application development or testing

Instance types

On-demand instances

Reserved instances

Unix/Linux instances start at


$0.02/hour

1- or 3-year terms

Pay as you go for compute power

Pay low up-front fee, receive significant hourly


discount

Low cost and flexibility

Low Cost / Predictability

Pay only for what you use, no up-front


commitments or long-term contracts

Helps ensure compute capacity is available


when needed

Use Cases:
Applications with short term, spiky, or
unpredictable workloads;
Application development or testing

Use Cases:
Applications with steady state or predictable
usage
Applications that require reserved capacity,
including disaster recovery

Instance types

Heavy utilization RI
> 80% utilization
Lower costs up to 58%

On-demand instances

Reserved instances

Unix/Linux instances start at


$0.02/hour

1- or 3-year terms

Pay as you go for compute power

Pay low up-front fee, receive significant hourly


discount

Low cost and flexibility

Low Cost / Predictability

Pay only for what you use, no up-front


commitments or long-term contracts

Helps ensure compute capacity is available


when needed

Use Cases:
Applications with short term, spiky, or
unpredictable workloads;
Application development or testing

Use Cases:
Applications with steady state or predictable
usage
Applications that require reserved capacity,
including disaster recovery

Use Cases: Databases, Large Scale HPC,


Always-on infrastructure, Baseline

Instance types

Heavy utilization RI
> 80% utilization
Lower costs up to 58%

On-demand instances

Reserved instances

Unix/Linux instances start at


$0.02/hour

1- or 3-year terms

Pay as you go for compute power

Pay low up-front fee, receive significant hourly


discount

Low cost and flexibility

Low Cost / Predictability

Pay only for what you use, no up-front


commitments or long-term contracts

Helps ensure compute capacity is available


when needed

Use Cases:
Applications with short term, spiky, or
unpredictable workloads;
Application development or testing

Use Cases:
Applications with steady state or predictable
usage
Applications that require reserved capacity,
including disaster recovery

Use Cases: Databases, Large Scale HPC,


Always-on infrastructure, Baseline

Medium utilization RI
41-79% utilization
Lower costs up to 49%
Use Cases: Web applications, many heavy
processing tasks, running much of the time

Instance types

Heavy utilization RI
> 80% utilization
Lower costs up to 58%

On-demand instances

Reserved instances

Unix/Linux instances start at


$0.02/hour

1- or 3-year terms

Pay as you go for compute power

Pay low up-front fee, receive significant hourly


discount

Low cost and flexibility

Low Cost / Predictability

Pay only for what you use, no up-front


commitments or long-term contracts

Helps ensure compute capacity is available


when needed

Use Cases:
Applications with short term, spiky, or
unpredictable workloads;
Application development or testing

Use Cases: Databases, Large Scale HPC,


Always-on infrastructure, Baseline

Medium utilization RI
41-79% utilization
Lower costs up to 49%
Use Cases: Web applications, many heavy
processing tasks, running much of the time

Use Cases:

Light utilization RI
Applications with steady state or predictable
usage
Applications that require reserved capacity,
including disaster recovery

15-40% utilization
Lower costs up to 34%
Use Cases: Disaster Recovery, Weekly /
Monthly reporting, Elastic Map Reduce

Instance types

On-demand instances

Reserved instances

Spot instances

Unix/Linux instances start at


$0.02/hour

1- or 3-year terms

Bid on unused EC2 capacity

Pay as you go for compute power

Pay low up-front fee, receive significant hourly


discount

Spot Price based on supply/demand,


determined automatically

Low cost and flexibility

Low Cost / Predictability

Cost / Large Scale, dynamic workload handling

Pay only for what you use, no up-front


commitments or long-term contracts

Helps ensure compute capacity is available


when needed

Use Cases:
Applications with short term, spiky, or
unpredictable workloads;
Application development or testing

Use Cases:
Use Cases:

Applications with flexible start and end times

Applications with steady state or predictable


usage

Applications only feasible at very low compute


prices

Applications that require reserved capacity,


including disaster recovery

Launch an instance
Commands, keypairs & security groups

Region
Instance size
AMI
Key pair
Security group

key pairs
secure access

Public Key
Inserted by Amazon into
each EC2 instance that
you launch

EC2
Instance
Comms secured
with private key

Private Key
Downloaded and stored
by you

Keypairs & Secrets

Keypairs

Used to authenticate
when accessing and
instance

Credentials
Access key and secret key
used to authenticate
against APIs

x.509

Used to authenticate
against some APIs

security groups
instance firewalling

Port 80
(HTTP)

Port 22
(SSH)

Security Group

instance

Name
Description
Protocol
Port range
IP Address, range, or
another security group

PS C:> New-EC2Instances
-ImageId ami-269dbb63
-KeyName mykey
-SecurityGroupId sg-9cf9e5d9
-InstanceType t1.micro

$>

ec2-run-instances ami-54cf5c3d
--instance-count 2
--group webservers
--key mykey
--instance-type m1.small

>>> import boto.ec2


>>> conn = boto.ec2.connect_to_region("us-east-1")
>>> conn.run_instances(
'ami-54cf5c3d',
key_name='mykey',
instance_type='m1.small',
security_groups=['webservers'])

Wait a minute
I want to use those tools too

IAM Roles and EC2 tools


1. Start an EC2 Linux instance
2. Assign an IAM role at launch time:

3. Sets up all the tools you need & manages


API access credentials

{
"Statement": [
{
"Effect": "Allow",
"NotAction": "iam:*",
"Resource": "*"
}
]

1. Up and running with CLI tools in a couple


of minutes just SSH on and use
2. Terminate/stop instance when you are
done

Now you have tools


Try this

$>

ec2-run-instances ami-54cf5c3d
--instance-count 1

$>

What about all


this?

ec2-run-instances ami-54cf5c3d
--instance-count 1
--group webservers
--key mykey
--instance-type m1.small

$>

Defaults

ec2-run-instances ami-54cf5c3d
--instance-count 1
--group Default
--key NONE
--instance-type default(m1.small)

$>

ec2-run-instances ami-54cf5c3d
--instance-count 1
--group Default
--key NONE
--instance-type default(m1.small)

Instances dont need keypairs


But how do you configure it if you cant log
onto it?

Bootstrapping

Bake an AMI
Start an instance
Configure the instance
Create an AMI from
your instance
Start new ones from
the AMI

Bootstrapping

Bake an AMI

vs

Configure dynamically

Start an instance

Launch an instance

Configure the instance

Use metadata service


and cloud-init to
perform actions on
instance when it
launches

Create an AMI from


your instance
Start new ones from
the AMI

Bootstrapping

Bake an AMI
Build your base images
and setup custom
initialisation scripts
Maintain your golden
base

Configure dynamically
Use bootstrapping to
pass custom
information in and
perform post launch
tasks like pulling code
from SVN

Bootstrapping

Bake an AMI

Time consuming
configuration (startup time)
Static configurations (less
change management)

Configure dynamically

Bootstrapping

Bake an AMI

Configure dynamically

Continuous deployment
(latest code)
Environment specific (devtest-prod)

Goal is bring an instance up in a


useful state
The balance will vary depending upon your application

Instance
request

User
data

Instance
request

User
data

Meta-data
service

Instance
request

User
data

Meta-data
service

Instance

Shell script in user-data will be executed on launch:


#!/bin/sh
yum -y install httpd php mysql php-mysql
chkconfig httpd on
/etc/init.d/httpd start

Amazon Windows EC2Config Service executes userdata on launch:


<script>dir > c:\test.log</script>
<powershell>any command that you can run</powershell>

AWS Powershell Tools (use IAM roles as before)


<powershell>
Read-S3Object -BucketName myS3Bucket
-Key myFolder/myFile.zip
-File c:\destinationFile.zip
</powershell>
63

Automation
Less fingers, less mistakes

Security

Availability

Instances locked
down by default

Drive higher
availability with selfhealing

Why do this?
Flexible

Efficiency

Shell, Powershell,
CloudFormation,
Chef, Puppet,
OpsWorks

Audit and manage


your estate with less
time & effort

Scale
Manage large scale
deployments and drive
autoscaling

Some does and donts

Do
Use IAM roles
Go keyless if you can
Strike a balance between
AMI and dynamic
bootstrapping

Some does and donts

Do

Dont

Use IAM roles

Put your API access keys


into code (and then publish
to GIT) or bake into AMIs
(and share)

Go keyless if you can


Strike a balance between
AMI and dynamic
bootstrapping

Block storage
Understanding instance storage vs EBS

Instance Storage
Local on host disk
volumes

Data dependent upon


instance lifecycle

Instance Storage

VS

Elastic Block Storage

Local on host disk


volumes

Network attached optimised


block storage

Data dependent upon


instance lifecycle

Data independent of
instance lifecycle

Instance A

Instance Storage

Instance D
Instance B

Local on host disk


volumes

Instance E

Instance C

Data dependent upon


instance lifecycle

Instance F

Instance Store

eph0

Host 1

eph1

eph2

Instance Store

eph3

eph0

Host 2

eph1

eph2

eph3

Instance Storage
Local on host disk
volumes

Data dependent upon


instance lifecycle

If an instance reboots (intentionally or


unintentionally), data in the instance store
persists
Data on instance store volumes is lost under
the following circumstances:
Failure of an underlying drive
Stopping an Amazon EBS-backed instance
Terminating an instance

Options
Differing types of
instance storage

Options
Differing types of
instance storage

One or more ephemeral


(temporary) drives
(instance storage)

One or more EBS


(persistent) drives

EBS snapshots
(backup images)

Network attached optimised


block storage

Workspace
Network

EBS
snapshot

Hypervisor

EC2

Elastic Block Storage

EBS

S3

Data independent of
instance lifecycle

Boot cycle

Elastic Block Storage


Network attached optimised
block storage
EBS
snapshot

Hypervisor

EC2

EBS

S3

Data independent of
instance lifecycle

Boot cycle

Elastic Block Storage

Workspace

Network attached optimised


block storage
EBS
snapshot

Hypervisor

EC2

EBS

S3

Data independent of
instance lifecycle

Boot cycle

Elastic Block Storage

Workspace

Network attached optimised


block storage
Data independent of
instance lifecycle

EBS
snapshot

Hypervisor

EC2

EBS

S3

Boot cycle

Elastic Block Storage

Workspace

Network attached optimised


block storage
Data independent of
instance lifecycle

Network

Hypervisor

EC2

EBS

S3

EBS Persistence

EBS volume is off-instance storage


You pay for the volume usage as long as the data
persists
1. By default, EBS volumes that are attached to a running instance
automatically detach from the instance with their data intact when
that instance is terminated
2. By default, EBS volumes that are created and attached to an instance
at launch are deleted when that instance is terminated. You can
modify this behavior by changing the value of the flag
DeleteOnTermination to false when you launch the instance.

Elastic Load Balancer


Spreading the load and fronting EC2

A regional service
Load balance across availability zones

Elastic Load Balancer

Instance

Instance

Availability Zone

Instance

Instance

Availability Zone

Region

Instance

Instance

Availability Zone

Elastic Load Balancing

Spread

Offload

Health check

Go small and wide

SSL processing on ELB

Balance resources across


AZs

Remove load from EC2


instances

Choose the right healthcheck


point
Check whole layers

1. Persistent HTTP connections enable them and ELB


to Server will be optimized
2. Never address underlying IP always DNS name
Theres a set behind an ELB and real clients spread
across them
They will change as the ELB scales to keep ahead
of demand
3. If you span ELB across AZs have an instance in all Azs
4. De-register instances from an ELB before terminating

AutoScaling
Automate EC2 commissioning and decommisioning

Launch Configuration

Auto-Scaling Group

Auto-Scaling Policy

Describes what Auto Scaling


will create when adding
Instances

Auto Scaling managed


grouping of EC2 instances

Parameters for performing an


Auto Scaling action

Automatic health check to


maintain pool size

Scale Up/Down and by how much

AMI
Instance Type
Security Group
Instance Key Pair
Only one active launch
configuration at a time
Auto Scaling will terminate
instances with old launch
configuration first
rolling update

Automatically scale the number of


instances by policy Min, Max,
Desired
Automatic Integration with ELB

Automatic distribution & balancing


across AZs

ChangeInCapacity (+/- #)
ExactCapacity (#)
ChangeInPercent (+/- %)
Cool Down (seconds)
Policy can be triggered by
CloudWatch events

Create a launch configuration:


as-create-launch-config
--image-id ami-54cf5c3d
--instance-type m1.small
--key mykey
--group webservers
--launch-config 101-launch-config

Create a launch configuration:


as-create-launch-config
--image-id ami-54cf5c3d
--instance-type m1.small
--key mykey
--group webservers
--launch-config 101-launch-config

The usual
suspects

Create an auto scaling group:


as-create-auto-scaling-group 101-as-group
--availability-zones us-east-1a us-east-1b us-east-1c
--launch-configuration 101-launch-config
--load-balancers myELB
--max-size 5
--min-size 1

Create an auto scaling group:


as-create-auto-scaling-group 101-as-group
--availability-zones us-east-1a us-east-1b us-east-1c
--launch-configuration 101-launch-config
--load-balancers myELB
--max-size 5
Whats going to launch
--min-size 1

Create an auto scaling group:


as-create-auto-scaling-group 101-as-group
--availability-zones us-east-1a us-east-1b us-east-1c
--launch-configuration 101-launch-config
--load-balancers myELB
--max-size 5
--min-size 1
Integrate with an ELB?

Create an auto-scaling policy (scale up):


as-put-scaling-policy 101ScaleUpPolicy
--auto-scaling-group 101-as-group
--adjustment=1
--type ChangeInCapacity
--cooldown 300

Create an auto-scaling policy (scale up):


as-put-scaling-policy 101ScaleUpPolicy
--auto-scaling-group 101-as-group
--adjustment=1
--type ChangeInCapacity
--cooldown 300

Period before another action will take place


(Damper)

Create an auto-scaling policy (scale down):


as-put-scaling-policy 101ScaleDownPolicy
--auto-scaling-group 101-as-group
"--adjustment=-1"
--type ChangeInCapacity
--cooldown 300

CloudWatch
Know what is going on

Cloud Watch Alarm:

Takes action:

CPU >= 50% for 5 mins

Scale up policy

CPU < 30% for 10 mins

Scale down policy

Cloud Watch Alarm:

CPU >= 50% for 5 mins

Takes action:

Scale up policy

Cloud Watch Alarm:

Takes action:

CPU >= 50% for 5 mins

CPU < 30% for 10 mins

Deliver message to Q

SNS Topic

Post to endpoint

Send Email

Cloud Watch Alarm:

Takes action:

CPU >= 50% for 5 mins


SNS Topic

Comprehensive
Billing, technical, aggregate &
custom metrics

SNS
Integration

Alarms
Set custom alarms
and thresholds

Push alarms to
SNS topics

CloudWatch
HTTP
Poke HTTP
endpoints for
custom alarm
actions

Email
integration
Custom Metrics
Write your own metrics in via
SDKs

Send alarm
notifications to
emails

Other topics to look at:

Other topics

Resource tagging

Route 53

Rolling deployments

Tag resources like EC2


and have it appear on
billing reports

Front EC2 and ELBs with


Route 53 for control over
DNS

Use Route 53 and ELBs to do


rolling deployments, A/B
testing

Other topics

Beanstalk

OpsWorks

CloudFormation

Manage an entire
autoscaling stack for
popular containers such
as ruby, python etc

Manage stacks as layers


and implement Chef
recipes to automate EC2
configuration

Template everything from


configuration of CloudWatch
alarms, SNS topics, EC2
instances

Summary

Stop doing these:


Provisioning and fixing servers
Treating compute as physical things
Thinking of compute as a finite commitment

Elasticity
Security
Build systems secure by
default

Stateless autoscaling
applications

Automation
Create instances when
you need them, drop
them when not

and start doing these


Replace not fix
Build from scratch, dont
fix something

Be cost aware
Unconstrained
Say goodbye to
traditional capacity
planning

Tag resources, play with


instance types

Watch a demo here:


http://youtu.be/kMExnVKhmYc

aws.amazon.com